Lorsque j’ai d’abord configuré OpenClaw, j’ai fait toutes les erreurs possibles. Je n’exagère pas — j’ai passé trois semaines sur une configuration qui aurait dû prendre trois jours, brûlé 400 $ en outils dont je n’avais pas besoin, et une fois, j’ai mis hors service mon serveur de production en exécutant une mise à jour de l’agent un vendredi après-midi. À 16h57. Avant un long week-end.
Voici les sept erreurs qui m’ont coûté le plus, classées selon à quel point je veux revenir dans le temps et me donner une claque.
1. Utiliser des configurations par défaut en production
OpenClaw est livré avec des paramètres par défaut qui sont acceptables pour les tests et le développement. Ils ne sont pas adaptés à la production. J’ai appris cela lorsque mon agent a commencé à répondre en 15 secondes au lieu de 2, et je ne pouvais pas comprendre pourquoi.
Le problème : l’allocation de mémoire par défaut était configurée pour le développement — une fraction de ce dont ma charge de travail avait réellement besoin. L’agent swapait constamment, s’effondrait, et fonctionnait essentiellement avec les lacets de chaussures attachés ensemble.
La solution était embarrassément simple : augmenter l’allocation de mémoire et ajuster les paramètres de concurrence pour correspondre à mes vrais schémas d’utilisation. Les temps de réponse sont passés de 15 secondes à moins de 2. J’avais vécu avec des performances terribles pendant trois semaines parce que je supposais que les valeurs par défaut étaient optimisées. Ce n’est pas le cas. Elles sont conservatrices. Lisez la documentation de configuration et ajustez-la pour votre charge de travail spécifique.
2. Ne pas mettre en place de surveillance dès le premier jour
Pendant le premier mois, mon instance OpenClaw était une boîte noire. Elle fonctionnait. Parfois vite. Parfois lentement. Je n’avais aucune idée de pourquoi, car je n’avais mis en place aucune surveillance.
Puis un jour, elle a complètement cessé de répondre. Pas d’alertes. Pas d’avertissements. Juste le silence. Je l’ai remarquée seulement parce qu’un collègue a demandé pourquoi le bot ne répondait pas sur Slack. L’agent s’était silencieusement écrasé six heures plus tôt en raison d’une fuite de mémoire, et personne ne le savait.
Maintenant, j’ai une surveillance sur tout : temps de réponse, taux d’erreur, utilisation de la mémoire, consommation de jetons, et temps de disponibilité. Cela prend 30 minutes à mettre en place une surveillance de base, et cela m’a sauvé de pannes silencieuses au moins cinq fois depuis. Si votre système d’IA n’a pas de surveillance, il a des problèmes dont vous n’êtes pas encore conscient.
3. La mise à jour du vendredi après-midi
Je sais. Tout le monde dit de ne pas déployer le vendredi. Je pensais que c’était une superstition pour les personnes paranoïaques en opérations. Puis j’ai poussé une mise à jour de l’agent à 16h57 un vendredi avant un long week-end.
La mise à jour a changé un format de configuration qui était incompatible avec les données existantes. L’agent a commencé à renvoyer des erreurs. J’ai essayé de revenir en arrière mais j’ai réalisé que je n’avais pas pris de snapshot avant la mise à jour. Trois heures plus tard — alors que cela aurait dû être le début de mon week-end — je l’ai remis dans un état fonctionnel en reconstruisant manuellement la configuration de mémoire et des journaux de discussion.
Leçons retenues : toujours prendre un snapshot avant les mises à jour, ne jamais mettre à jour le vendredi (ce n’est pas une superstition — c’est de la gestion des risques), et garder votre procédure de retour en arrière documentée et testée. J’ai maintenant une liste de contrôle avant mise à jour scotchée à mon moniteur. Oui, scotchée physiquement. Avec du vrai scotch.
4. Donner trop de permissions à l’agent
Lorsque j’ai d’abord configuré mon agent OpenClaw, je lui ai donné un accès admin à tout car je ne voulais pas avoir à gérer des erreurs de permission. Email, calendrier, système de fichiers, base de données, Slack — accès complet à tout cela.
Vous pouvez probablement deviner ce qui s’est passé. L’agent, suivant une invite légèrement ambiguë, a envoyé un brouillon de mémo interne à l’ensemble de notre liste de clients. Ce n’était pas une catastrophe — le mémo était ennuyeux et inoffensif — mais les réponses « pourquoi votre IA m’envoie-t-elle un email ? » de clients confus n’étaient pas plaisantes à gérer.
Maintenant, je suis une stricte règle du moindre privilège. L’agent a accès exactement à ce dont il a besoin et rien de plus. Peut-il publier sur le canal Slack interne ? Oui. Peut-il envoyer des emails à des contacts externes ? Seulement via une file d’attente que je révise d’abord. Peut-il modifier notre base de données ? En lecture seule. Chaque nouvelle capacité nécessite une approbation explicite, et j’y réfléchis attentivement avant de le faire.
5. Ignorer les coûts des jetons jusqu’à l’arrivée de la facture
J’avais un flux de travail où l’agent traitait de longs documents en les envoyant à un LLM pour les résumer. Ça fonctionnait très bien. Les résumés étaient excellents. Puis ma première facture mensuelle est arrivée : 340 $ en coûts de jetons API pour une tâche que je m’attendais à coûter environ 30 $.
Le problème : l’agent envoyait le document entier à chaque fois, même lorsque l’utilisateur posait une question de suivi sur le même document. Pas de mise en cache, pas de fractionnement, pas de conscience qu’il avait déjà traité ce contenu. Chaque question sur un document de 50 pages signifiait renvoyer les 50 pages.
Ajouter un simple cache — « ai-je déjà traité ce document ? Si oui, utiliser le résumé mis en cache » — a réduit mes coûts de 85 %. La mise en œuvre d’un fractionnement intelligent (n’envoyant que les sections pertinentes au lieu de tout le document) l’a encore réduit.
Suivez votre utilisation des jetons dès le premier jour. Mettez en place des alertes budgétaires. Et demandez toujours : « Est-ce que j’envoie des informations que le modèle a déjà vues ? »
6. Construire tout avant de parler aux utilisateurs
J’ai passé deux semaines à construire un flux de travail complexe pour l’agent qui analyserait les tickets de support client, les catégoriserait, rédigerait des réponses et les dirigerait vers la bonne équipe. C’était architecturale amusante. Orchestration complexe, multiples transferts d’agents, gestion des erreurs pour chaque cas particulier.
Puis je l’ai montré à l’équipe de support. Ils l’ont regardée et ont dit : « Nous avons juste besoin qu’il rédige une réponse. Nous gérerons la catégorisation et le routage nous-mêmes — nous sommes plus rapides que n’importe quelle IA pour cela. »
Deux semaines de travail, et ils ont utilisé environ 20 % de ce que j’avais construit. Les 80 % sur lesquels j’ai perdu du temps n’étaient pas seulement inutiles — cela rendait le système plus complexe et plus difficile à maintenir.
Maintenant, je commence par des conversations. « Sur quoi passez-vous le plus de temps ? » « Quelle est la partie la plus frustrante de votre flux de travail ? » « Si je pouvais automatiser une chose, laquelle serait-ce ? » Construisez cette unique chose. Voyez s’ils l’utilisent. Puis construisez la prochaine chose.
7. Ne pas avoir de kill switch
Celle-ci me rend encore nerveux. Pendant les deux premiers mois, mon agent n’avait pas de moyen facile d’être arrêté en cas d’urgence. S’il commençait à se comporter mal — envoyant des messages erronés, effectuant de mauvais appels d’API, tournant en boucle — ma seule option était de me connecter en SSH au serveur et de tuer manuellement le processus.
C’est acceptable quand vous êtes à votre bureau. Ce n’est pas acceptable quand vous êtes en train de dîner et que votre téléphone commence à exploser avec des alertes « pourquoi le bot publie-t-il le même message toutes les 3 secondes ? ».
Maintenant, chaque agent a un kill switch : un simple point de terminaison API ou une commande Slack qui arrête immédiatement toute activité de l’agent. Pas besoin de SSH. Pas besoin de portable. Juste « /stop-agent » depuis mon téléphone et tout s’arrête en quelques secondes.
Construisez le kill switch avant de construire les fonctionnalités. Vous n’en aurez pas souvent besoin, mais quand vous en aurez besoin, vous en aurez désespérément besoin.
La leçon méta
Ces sept erreurs partagent un fil conducteur commun : j’ai traité l’agent IA comme un logiciel, et non comme un employé. Un logiciel que vous déployez et oubliez. Un employé que vous surveillez, limitez, guidez et corrigez.
Les agents IA sont plus proches des employés que des logiciels. Ils ont besoin de surveillance, de contraintes, de responsabilités claires, et de quelqu’un pour s’assurer qu’ils n’envoient pas accidentellement votre liste de clients entière par email. Traitez-les en conséquence, et vous éviterez la plupart des douleurs que j’ai traversées.
🕒 Published: