Comment je gère seul une activité de modules PrestaShop avec une flotte d'agents IA

Il y a quelques mois, j'ai découvert que mes agents IA avaient laissé 154 dépôts Git dirty - et la solution n'était pas un meilleur prompt, mais un organigramme.

Pas 154 fichiers. 154 dépôts. Des dizaines de bases de code de modules, chacune avec des modifications non committées empilées les unes sur les autres - certaines expériences à moitié terminées, certains travaux vraiment bons qui n'avaient simplement jamais été livrés. Différents agents, à différents moments, avaient chacun fait un morceau puis étaient passés à autre chose. Personne n'avait committé. Personne n'avait nettoyé. Le travail n'était pas exactement perdu. C'était pire que perdu. Il était emmêlé, et je ne pouvais plus savoir quelles mains avaient touché quoi.

Le réflexe, quand un agent IA fait quelque chose de stupide, est de corriger le prompt. Ajouter une ligne. "Committe toujours ton travail quand tu as fini." "Ne laisse jamais les dépôts dirty." J'ai essayé. Ça ne tient pas - et une fois que l'on comprend pourquoi, toute la manière de travailler avec ces outils change.

Ce texte explique comment je gère réellement la boutique : une seule personne, un catalogue de bien plus de cent extensions PrestaShop publiées en six langues, plus quelques vraies boutiques en ligne que j'exploite moi-même avec ces mêmes modules. Une grande partie du travail répétitif de développement et de support passe par une flotte d'agents IA - toujours sous ma revue ; l'architecture, les décisions de release et la validation finale restent chez moi. Ce qui suit, c'est la partie que personne ne met sur une page de vente - les erreurs précises que ces agents ont commises, et la mécanique que j'ai construite pour qu'ils ne puissent pas les refaire deux fois.

L'agent est un employé brillant avec une amnésie totale

Voici le modèle mental qui fonctionne vraiment. Votre agent IA est un prestataire réellement excellent - rapide, cultivé, infatigable - qui n'a aucun souvenir d'avoir déjà travaillé pour vous. À chaque session, un brillant inconnu franchit la porte. Il n'a jamais vu votre base de code. Il ne connaît pas vos conventions. Il ne sait pas que ce qu'il s'apprête à faire a cassé la production le mois dernier, parce qu'il n'était pas là. Pour sa mémoire, personne n'était là.

Vous ne pouvez pas corriger cette personne avec une série d'instructions plus malines à l'entrée. Un prompt est une conversation. Il s'évapore quand la session se termine. Ce qu'il faut, c'est ce que toute vraie organisation construit pour ne pas dépendre de la mémoire d'une seule personne : un savoir institutionnel durable, écrit et appliqué. Des documents d'onboarding. Des runbooks. Une checklist de pre-commit punaisée au mur. Des garde-fous qui rendent le mauvais geste physiquement difficile.

Je n'écris pas de meilleurs prompts. J'écris une meilleure mémoire. L'amnésie ne coûte cher que si vous obligez l'agent à tout réapprendre chaque fois qu'il entre.

Le métier, ce n'est donc pas le prompt engineering. Le métier, c'est de construire l'organisation autour de l'amnésique. Et la prise de conscience la plus utile que j'ai eue est celle-ci : chaque garde-fou de mon système est une cicatrice. Il correspond à un moment précis, daté, où un agent a fait quelque chose de travers, où j'en ai payé le prix, puis où j'ai transformé cette douleur en règle que l'environnement applique pour toujours. Ma configuration n'est pas une liste de souhaits. C'est un dossier médical.

Voici les cicatrices.

Cicatrice #1 : l'agent qui a vidé le dossier vendor et mis la boutique hors ligne

Certains de mes modules dépendent de bibliothèques internes partagées - du code que je réutilise dans tout le catalogue. Pour des raisons de déploiement, ces bibliothèques vivent dans le dossier vendor/ de chaque module, mais elles y sont copiées par un script de synchronisation, pas gérées par le gestionnaire de paquets normal. C'est une configuration inhabituelle, et un agent amnésique n'a aucun moyen de le savoir.

Un soir de l'automne dernier, un agent devait donc ajouter une dépendance, et il a fait ce qui est correct dans les manuels : il a lancé composer install. Le gestionnaire de paquets a regardé le manifeste, a vu une pile de fichiers dans vendor/ qu'il n'avait pas mis là, et les a obligeamment supprimés. Des classes ont disparu. La boutique en production a commencé à renvoyer des 500 dès qu'un client ouvrait une page qui autoloadait l'un des traits manquants.

L'agent n'avait pas tort selon sa propre logique. Il avait tort parce qu'il n'avait pas ma mémoire. On ne sort pas fiablement de cela avec un prompt - "fais attention avec composer" est exactement le genre d'instruction molle qu'un agent oublie sous pression. La correction n'est donc pas une phrase. C'est un mur :

# pre-tool hook: refuse the dangerous command outright
if command matches "composer install" or "composer update":
    BLOCK
    tell the agent: "This wipes synced packages. Use
    'composer dump-autoload', then re-run the sync script."

Maintenant, l'erreur est indisponible. Un nouvel agent sans aucun souvenir de la panne ne peut toujours pas la reproduire, parce que l'environnement dit non avant que les dégâts ne commencent. C'est la différence entre un prompt et une cicatrice : le prompt espère ; la cicatrice impose. J'ai maintenant une petite bibliothèque de ces hooks, et chacun d'eux représente un après-midi que je ne récupérerai pas.

Cicatrice #2 : les 154 dépôts dirty

Revenons à l'ouverture. Le nœud s'est formé parce que j'avais résolu un autre problème - faire tourner de nombreux agents en parallèle - sans construire la couche de coordination dont le parallélisme a réellement besoin.

Faire tourner un agent, c'est une conversation. Faire tourner une flotte, c'est de la logistique, et la logistique est un ensemble de problèmes qu'aucun prompt ne résout :

• Ils throttlent et se bloquent. Lancez cinq gros jobs en même temps et ils s'empilent, calent et expirent. La correction a été de l'infrastructure : un runner qui met les jobs en file, les équilibre entre des workers parallèles et place un watchdog sur chaque exécution, pour que l'usage concurrent lourd ne s'accumule pas et ne gèle pas. Les agents ne gèrent pas leur propre capacité. L'organisation le fait.
• Ils entrent en collision. Deux agents qui modifient le même module au même moment corrompent mutuellement leur travail. La solution est un verrou par module - un agent prend le module, travaille, puis le libère. Avec une nuance apprise à la dure : un verrou dont le processus propriétaire est mort n'est pas du travail actif, c'est un déchet. Le verrou vérifie donc si son propriétaire existe encore et supprime automatiquement les verrous périmés. Un système de coordination qui deadlock sur des fantômes est pire que pas de système du tout.
• Ils committent le linge des autres. C'était la vraie racine des 154. Un agent terminant sa propre tâche lançait l'équivalent de "commit everything" - et ramassait le travail inachevé de trois autres agents dans le même commit. Le chemin de commit a donc reçu une porte : un agent ne peut stager que ses propres fichiers, jamais un "add everything" global. Il ne peut littéralement pas committer un travail qu'il n'a pas fait.

Aucun de ces trois points n'est malin. C'est la mécanique ennuyeuse d'un lieu de travail qui fonctionne : pointer, ne pas toucher au bureau de quelqu'un en plein projet, ne pas signer pour un colis qui n'est pas le vôtre. J'ai dû construire chacun d'eux parce qu'un agent précis, un jour précis, a fait l'inverse.

La coordination doit permettre l'achèvement, pas le geler. Les verrous existent pour empêcher deux agents d'éditer un fichier en même temps - pas pour transformer du "travail terminé" en "travail figé". Committer est un point de contrôle, pas une cage.

Cette dernière phrase compte plus qu'il n'y paraît. La première version de mon système de verrous était trop stricte, et les agents se sont mis à attendre les bras croisés des verrous qui n'appartenaient plus à personne. Un système de sécurité qui empêche le travail d'être terminé n'est pas de la sécurité - c'est juste une autre panne. La règle est désormais que la coordination doit rendre la finition plus facile que la non-finition, sinon elle est repensée.

Cicatrice #3 : ne jamais laisser un agent apprendre sur la boutique du client

C'est la seule règle que je n'ai pas attendu de gagner à la dure. Au début, un agent a "juste vérifié quelque chose" sur une boutique en production - et les dix secondes avant que je confirme que rien n'avait réellement changé ont suffi à rendre le principe non négociable : les agents construisent et testent d'abord sur une copie jetable, et ne touchent à rien de visible par un client qu'une fois le changement prouvé.

Un nouvel agent n'a aucun instinct pour savoir dans quel environnement il se trouve. Pour lui, un shell est un shell. L'environnement fait donc la distinction à sa place : les opérations risquées sont dirigées par défaut vers des clones jetables, la production est traitée comme un lieu séparé et gardé, et les commandes destructrices par habitude que l'on lance sur une machine de dev (vider un répertoire de cache, réinitialiser un état) sont bloquées ou redirigées sur tout ce qui fait face à un vrai client. L'agent n'a pas à se souvenir de la différence entre "mon sandbox" et "la boutique de quelqu'un". L'organisation s'en souvient pour lui.

C'est le seul garde-fou que je voudrais qu'un client connaisse, parce que c'est celui qui le protège, lui. Si une mise à jour de module arrive rarement avec une surprise, c'est parce que les changements visibles par les clients passent par une répétition générale complète - sur une boutique jetable, où une erreur ne coûte rien - avant la release.

Cicatrice #4 : faites-le échouer bruyamment, pas poliment

Laissé seul, un agent serviable va masquer un problème. Quelque chose qu'il attendait n'est pas là, alors il substitue discrètement une valeur par défaut, enveloppe l'appel dans un fallback "au cas où", et continue. La tâche a l'air réussie. Sur la boutique d'un client, un contournement silencieux est pire qu'une erreur visible - parce que l'erreur visible est corrigée aujourd'hui, alors que la discrète part en production et attend.

L'instruction permanente est donc l'inverse du réflexe : quand quelque chose ne va pas, plante bruyamment. N'invente pas un fallback pour cacher une pièce manquante. N'ajoute pas de rembourrage défensif qui transforme un bug en réponse subtilement fausse. Expose-le, arrête-toi, et laisse un humain décider. Combiné à la règle dev-first, cela signifie que les échecs laids se produisent en salle de répétition, où le laid est précisément ce que l'on veut voir, et que l'objectif est que les clients voient la prise qui a fonctionné, pas celles qui ont raté.

Ce qui rend tout cela peu coûteux : la mémoire, construite exprès

Les cicatrices empêchent les agents de casser des choses. Mais l'habitude qui rend toute l'opération économique est celle qui transforme l'amnésie d'un impôt en une erreur d'arrondi.

La manière naïve d'utiliser un agent sur une tâche récurrente consiste à tout réexpliquer à chaque fois. Réattacher les fichiers d'exemple. Redécrire les étapes. Redécouvrir quels chemins comptent et quelles chausse-trappes mordent. Vous payez le prix plein, en tokens et en temps réel, pour une connaissance déjà découverte la semaine dernière. C'est l'amnésique qui réapprend les sorties de secours du bâtiment chaque matin.

J'ai donc créé une règle pour les agents eux-mêmes : à la fin d'une tâche, écris la note. Pas une entrée de journal - un mémo opérationnel. Où se trouvent les fichiers pertinents. La séquence exacte qui a fonctionné. La chose non évidente qui fera trébucher la prochaine exécution. Ces notes vivent dans une arborescence organisée, et - c'est la partie que les gens ratent - il existe un index d'une ligne pour chaque note, chargé tout au début de chaque session. L'amnésique entre, lit la table des matières et sait instantanément ce que l'entreprise sait déjà et où aller le consulter.

# a representative note — boring on purpose, and that's the point
task: regenerate the catalog cover images
where: assets/covers/  (source templates in build/covers/)
steps: 1) run the build script  2) QA with the check script
gotcha: never touch a confirmed-good render; only regen the broken one
last run: 2026-05 — clean; the QA script caught one bad render

Toute la thèse tient dans cette habitude. Un prompt malin améliore cette exécution. Une note écrite rend toutes les futures exécutions moins chères, quel que soit l'agent qui les reprend. La mémoire institutionnelle compose ; les prompts non. La première fois que je fais quelque chose ici coûte cher. La dixième ne coûte presque rien, et elle est bon marché précisément parce que les neuf premières ont écrit ce qu'elles avaient appris.

À quoi ressemble réellement une tâche qui passe par ce système

Mis bout à bout, un job routinier se déroule comme une petite équipe bien rodée, pas comme une session de chatbot :

1. Un agent lit l'index, récupère la note pour ce type de tâche, et démarre déjà une grande partie du chemin parcourue au lieu de partir de zéro.
2. Il prend le verrou sur le module qu'il va toucher, pour que rien d'autre ne puisse entrer en collision avec lui.
3. Il travaille sur une copie jetable. Si quelque chose ne va pas, ça échoue bruyamment là - pas sur une boutique en production.
4. Quand il tente de terminer, les garde-fous tiennent : il ne peut pas lancer la commande qui a autrefois vidé un dossier vendor, et il ne peut committer que ses propres fichiers, pas le travail à moitié fini posé dans le repo voisin.
5. Il réécrit ce qu'il a appris, afin que la note soit un peu plus précise pour le prochain agent - peut-être un tout autre agent.

Remarquez comme il y a peu de "prompting" là-dedans. Le prompt tient en une ligne : fais la tâche. Tout ce qui la rend sûre, rapide et répétable vit dans l'environnement, pas dans le message. C'est tout le truc.

Le bilan du bon et du mauvais, et pourquoi chaque "bon" signifie juste "a de la mémoire"

On me demande des conseils pour utiliser l'IA efficacement, en s'attendant à des astuces de prompt. La vraie liste est plus terne et beaucoup plus utile, et chaque point porte la même idée sous un autre vêtement - donnez à l'amnésique une mémoire et un atelier préparé :

• Mauvais : coller du code dans un chatbot gratuit et recopier la réponse à la main. Bon : faire tourner les agents là où le travail se trouve - sur la machine, avec un vrai accès aux fichiers et aux outils - afin que rien n'ait besoin d'être décrit quand il peut simplement être lu.
• Mauvais : un disque en désordre où chaque tâche commence par la recherche de l'endroit où les choses se trouvent. Bon : une arborescence de travail organisée, de sorte que "trouver le truc" soit une consultation, pas une expédition.
• Mauvais : l'agent greppe tout le disque et lit vingt fichiers pour trouver une fonction. Bon : préparer l'atelier - recherche rapide, et connecteurs qui lui permettent d'interroger directement la base de données, le navigateur et les conteneurs en cours d'exécution au lieu de deviner.
• Mauvais : redériver la même tâche en plusieurs étapes depuis zéro à chaque fois. Bon : la note réutilisable, et l'index qui la fait remonter.
• Mauvais : un seul agent généraliste pour tout. Bon : router le travail - le modèle meilleur en raisonnement backend soigneux reçoit le backend ; celui qui juge mieux l'interface et les mots reçoit ces sujets. Comme lorsqu'on affecte une équipe selon ses forces.

Un inconnu amnésique dans un bâtiment bien tenu - étagères étiquetées, manuel clair, outils affûtés prêts à l'emploi et garde-fous sur les machines dangereuses - est étonnamment productif. Le même inconnu déposé dans une pièce encombrée avec un briefing oral vague est un risque. Même travailleur. La différence, c'est entièrement l'organisation.

Où l'IA aide, et où la revue humaine gagne encore

Après tout cela, j'ai une idée assez nette de la frontière.

L'IA gagne sur le mécanique, le parallèle et le bien cadré. Déployer un changement sur des dizaines de modules. Rédiger la première version de n'importe quoi. Extraire et transformer des données structurées. Relancer un workflow préparé à partir d'une note. Enquêter sur un bug pénible avec plus de patience que moi à 6pm. Quand la tâche a une bonne réponse connaissable et un chemin pour l'atteindre, un agent bien équipé est plus rapide que moi et ne s'ennuie pas à la troisième répétition.

La revue humaine gagne sur le jugement, le goût et les conséquences. Tout ce pour quoi un client paie. Tout ce qui a un poids légal ou financier - c'est exactement pourquoi les corrections de factures ci-dessus reçoivent une signature humaine, pas un envoi automatique. Les décisions d'architecture où la "bonne" réponse dépend de l'endroit où je veux que l'entreprise soit dans un an, pas de ce que le code dit aujourd'hui. Et le goût du dernier mètre en écriture et en design, où "techniquement correct" et "réellement bon" sont deux choses différentes, et une seule garde un client.

La ligne n'est pas fixe non plus. Chaque cicatrice de ce texte est un endroit où j'ai un jour fait confiance à un agent pour quelque chose auquel il n'était pas prêt, où je me suis fait mordre, puis où j'ai déplacé la ligne. La vraie compétence est là - non pas décider une fois où l'IA s'arrête, mais regarder où elle échoue et ajuster la frontière plus vite que les échecs ne s'accumulent.

Pourquoi tout cela devrait compter si vous achetez chez moi

Voici la version honnête, parce que le cadrage d'un texte comme celui-ci peut glisser vers un endroit où je ne veux pas aller. Les agents ne fabriquent pas mes modules à ma place, et je ne vous dirais jamais le contraire. Ils construisent des échafaudages, lancent les outils que je n'ai pas envie de lancer à la main, rédigent des premiers jets et attrapent les erreurs les uns des autres - le tout à l'intérieur d'un ensemble de garde-fous gagnés panne après panne. Le jugement, l'architecture et la validation restent les miens.

Ce que cette discipline vous apporte, à vous qui êtes de l'autre côté d'un module ou d'un ticket de support, est ennuyeux dans le meilleur sens du terme. La même règle qui empêche 154 dépôts de s'emmêler empêche une release de partir à moitié finie. Le même mur qui empêche un agent de vider un dossier vendor explique pourquoi une mauvaise mise à jour a bien moins de chances de quitter mon atelier. La même habitude dev-first qui protège mes propres boutiques de test protège les vôtres. Un processus soigneux en amont, c'est ce qui ressemble en aval à une fiabilité tranquille.

S'il faut retenir une chose, c'est celle-ci : arrêtez de régler le prompt, construisez la mémoire. L'agent oubliera tout dès que la session se ferme - alors mettez tout ce qui mérite d'être retenu à un endroit où il ne peut pas l'oublier, et rendez les erreurs que vous ne voulez plus jamais revoir impossibles, pas seulement découragées. Faites cela, et une flotte d'amnésiques brillants cesse d'être un risque pour commencer à ressembler beaucoup à une équipe.