Agents IA en production : pourquoi un workflow réussi peut livrer un mauvais résultat

Les agents IA ne posent pas seulement un problème de qualité de génération. Ils posent un problème de contrôle opérationnel. Dès qu’ils modifient des contenus, déclenchent des workflows ou interagissent avec des systèmes métier, la vraie question n’est plus seulement « peuvent-ils produire ? », mais « peuvent-ils produire dans le bon périmètre, avec les bons garde-fous, et sous contrôle ? »

Ce retour d’expérience, conduit sur ClawPilot, notre plateforme open source d’orchestration multi-agents IA, illustre concrètement ce que recouvre cette question. Pour les directions marketing, produit, support ou DSI, le sujet n’est plus uniquement de savoir si un agent IA sait écrire, traduire ou résumer. Le sujet est de savoir dans quelle architecture l’intégrer pour qu’il produise de la valeur sans dégrader la marque, le produit ou la relation client.

Les agents IA ne sont plus seulement utilisés pour produire un texte, résumer un document ou répondre à une question. Ils commencent à intervenir dans des chaînes opérationnelles complètes : analyser des évolutions produit, détecter ce qui mérite d’être mis en avant, produire une proposition de contenu, l’adapter en plusieurs langues, la relire, puis la soumettre à validation.

ClawPilot, distribué sous licence MIT, est utilisé pour maintenir le site clawpilot.eu. Le site présente la plateforme sous forme de landing page structurée : une grille de 15 blocs de contenu, déclinée en 5 langues — anglais, français, espagnol, allemand et japonais.

L’objectif était simple en apparence : lorsqu’une évolution produit réellement visible par l’utilisateur est livrée dans ClawPilot, le site doit pouvoir être mis à jour automatiquement. Pas par un agent unique chargé de tout faire. Par une équipe d’agents spécialisés, chacun avec son propre rôle, ses propres outils et ses propres permissions.

Une mise à jour automatique nous a rappelé une règle essentielle : un pipeline IA peut réussir techniquement et échouer fonctionnellement.

L’angle mort des agents génératifs

Le 20 avril 2026, une mise à jour automatique du pipeline de maintenance éditoriale se termine avec un statut rassurant : « terminé avec succès ».

En apparence, tout va bien. Le pipeline a analysé les changements récents du produit, préparé une mise à jour du site, produit les contenus localisés et soumis une livraison à relire. Le système avait donc rempli sa mission apparente : transformer de l’activité produit en proposition de contenu.

Sauf que la livraison proposée par l’équipe d’agents contenait 24 blocs de contenu, là où la page en prévoyait 15.

La landing page avait été pensée comme une grille courte, lisible, équilibrée. Avec 24 blocs, le site ne racontait plus une proposition de valeur claire. Il empilait des nouveautés. La page ressemblait davantage à un journal de modifications produit qu’à une page destinée à convaincre.

Plus problématique encore : certaines descriptions reprenaient presque directement le vocabulaire du développement. Le ton avait glissé du marketing produit vers la documentation technique. Des éléments internes, compréhensibles pour un développeur, se retrouvaient exposés comme s’ils étaient des bénéfices utilisateur. Une amélioration corrective avait même été présentée comme une nouvelle fonctionnalité marketing.

Le pipeline n’avait pas halluciné. Il n’avait pas inventé une fonctionnalité inexistante. Il avait fait quelque chose de plus subtil : il avait confondu une modification techniquement réelle avec une promesse produit publiable.

C’est là que se situe l’angle mort des agents génératifs en production.

Un agent peut respecter la consigne, modifier les bons fichiers, produire un format valide pour le CMS, préparer une livraison à relire et terminer sans erreur. Cela ne signifie pas que le résultat est juste du point de vue métier. « Terminé avec succès » ne signifie pas « publiable ».

Dans une organisation classique, ce type d’écart est souvent capté par une étape humaine : un marketing manager, un product owner, un rédacteur ou un responsable de marque. Dans un pipeline agentique, il faut décider où placer cette capacité de jugement : dans les consignes, dans les permissions, dans les tests, dans l’orchestration ou dans une étape de validation séparée.

La réponse courte : partout. Mais pas de la même manière.

Le décalage Dev / Marketing dans un pipeline IA

Cette mise à jour automatique n’a pas échoué parce que les agents IA écrivent mal. Elle a échoué parce qu’un même signal avait deux significations différentes selon le métier qui le lisait.

Pour une équipe de développement, un changement technique décrit une modification précise du système. Il doit être factuel, traçable, parfois très détaillé. Il sert à comprendre ce qui a changé dans le produit, pourquoi cela a changé, et dans quel périmètre.

Pour une équipe marketing ou produit, une landing page répond à une autre logique. Elle ne décrit pas l’implémentation. Elle clarifie la valeur d’usage. Elle sélectionne, simplifie, hiérarchise. Elle transforme une évolution produit en bénéfice compréhensible par un visiteur.

Ces deux mondes ne s’opposent pas. Mais ils n’optimisent pas la même chose.

Un changement technique peut être formulé ainsi :

Avant : « Le schéma ajoute la table instance_shared_files avec miroir FTS5. »

Une formulation marketing devrait plutôt devenir :

Après : « Les agents partagent un espace de fichiers commun pour collaborer plus efficacement sur un même objectif. »

La première formulation est utile pour un mainteneur. La seconde est utile pour un utilisateur. Entre les deux, il ne suffit pas de traduire. Il faut interpréter.

C’est précisément ce que le pipeline initial faisait mal. Il analysait le produit, sélectionnait les changements, rédigeait les contenus et préparait la mise à jour du site dans une même chaîne trop compacte. Il disposait d’assez de contexte pour agir, mais pas d’assez de contraintes pour arbitrer.

Le problème n’était donc pas seulement éditorial. Il était architectural.

Un agent qui lit des changements techniques a tendance à surestimer l’importance de ce qu’il voit. Un agent qui rédige du marketing doit au contraire filtrer ce qui ne concerne pas directement l’utilisateur. Un agent qui localise ne doit pas traduire littéralement ; il doit adapter le registre, les usages et la terminologie au marché concerné.

Le pipeline initial mélangeait ces responsabilités. L’incident les a rendues visibles.

La correction a consisté à passer d’un agent capable de tout faire à une équipe d’agents volontairement incapables de tout faire seuls.

L’architecture finale : 8 étapes, 3 niveaux de gouvernance

La refonte du pipeline Daily Web Maintenance repose sur un principe simple : chaque étape doit avoir un objectif unique, une responsabilité claire et un périmètre d’action limité.

Le pipeline est exécuté sur l’instance web-maintenance de ClawPilot. Il est organisé en DAG, c’est-à-dire une séquence d’étapes où certaines tâches peuvent avancer en parallèle, sans boucle ni retour en arrière. Le terme est technique, mais l’idée est simple : chaque agent intervient au bon moment, avec un rôle précis, et le pipeline garde une progression contrôlée jusqu’à la validation finale.

Les 8 étapes du pipeline

La première étape, analyse, est portée par l’agent repo-analyst. Il analyse plus de 50 changements récents depuis le dernier état traité, puis les classe en deux catégories : les candidats à mise en avant produit et les notes de maintenance. Seules les évolutions réellement visibles par l’utilisateur peuvent être retenues.

La deuxième étape, ship-draft, est portée par l’agent site-maintainer. Son rôle est volontairement limité : il édite uniquement la version anglaise de la landing page et prépare une branche de travail. Il ne touche pas aux autres langues.

Les quatre étapes suivantes, localize-fr, localize-es, localize-de et localize-ja, sont exécutées en parallèle. Elles sont confiées à un agent localizer, instancié avec un brief propre à chaque marché. Le français utilise le vouvoiement. L’espagnol privilégie le tuteo. L’allemand applique le Siezen. Le japonais adopte le registre です・ます. Dans chaque cas, la consigne est explicite : localisation ne signifie pas traduction littérale.

L’étape review-and-pr est confiée à l’agent content-writer. Son nom est technique, mais son rôle est simple : vérifier avant soumission. Il ne réécrit pas l’ensemble du site. Il valide la parité des textes dans les 5 langues, scanne les formulations interdites, vérifie le respect des contraintes éditoriales et prépare la livraison à relire.

Enfin, l’étape notify est portée par l’agent reporter, qui envoie un rapport en français au coordinateur de l’équipe.

Cette architecture introduit trois niveaux de gouvernance.

Le premier niveau est la sélection : tous les changements produit ne deviennent pas du contenu marketing. Une correction, une optimisation interne ou une refonte technique ne sont pas automatiquement des arguments de vente.

Le deuxième niveau est la séparation des pouvoirs : l’agent qui analyse n’est pas celui qui localise ; celui qui rédige l’anglais n’est pas celui qui valide ; celui qui notifie n’a aucun droit d’écriture.

Le troisième niveau est la validation éditoriale automatisée : avant la livraison, le pipeline vérifie que les contraintes de forme et de contenu sont respectées.

C’est ce passage de l’autonomie brute à l’autonomie encadrée qui a transformé le pipeline.

Trois niveaux de garde-fous

Après l’incident, la correction n’a pas consisté à « mieux prompter » un agent unique. Elle a consisté à redessiner le système. Les mécanismes mis en place se rangent dans trois catégories distinctes, qu’il est utile de nommer explicitement parce qu’elles répondent à trois risques différents : ce que l’agent produit, ce qu’il a le droit de faire, et ce que l’organisation peut voir de son travail.

Garde-fous de contenu

Ce niveau encadre ce que l’agent peut écrire : nombre de blocs attendus, registre éditorial, formulations interdites, cohérence avec la promesse marketing.

Le premier mécanisme est structurel : la landing page reste une grille de 15 blocs. Les agents ne doivent pas ajouter indéfiniment de nouvelles entrées. Ils doivent fusionner, remplacer ou améliorer l’existant. Avant, chaque évolution significative pouvait devenir un bloc. Après, le pipeline doit arbitrer : est-ce une nouvelle promesse produit ou une amélioration à intégrer dans une promesse existante ? Ce garde-fou limite l’effet catalogue, fréquent dans les contenus générés à partir de l’activité produit.

Le deuxième mécanisme est une liste de formulations interdites. Le pipeline scanne désormais les descriptions pour détecter les signaux d’un contenu trop technique : chemins internes, noms de composants, détails d’implémentation ou formulations directement issues du développement. L’objectif n’est pas de censurer la technique, mais de l’empêcher d’apparaître au mauvais endroit.

Avant : « Le schéma ajoute la table instance_shared_files avec miroir FTS5. »
Après : « Les agents partagent un espace de fichiers commun pour collaborer plus efficacement sur un même objectif. »

La première phrase décrit une implémentation. La seconde exprime une capacité produit. La différence est fondamentale.

Le troisième mécanisme est la spécialisation par marché. Chaque agent localizer dispose d’un brief d’environ 90 lignes par langue, qui définit le registre, les formes d’adresse, les calques à éviter, la terminologie produit et les formulations à privilégier. Cela évite un écueil classique : produire quatre traductions grammaticalement correctes, mais culturellement faibles. Localiser une landing page ne consiste pas à convertir des mots ; il faut préserver l’intention, l’énergie commerciale et la précision produit dans chaque marché.

Garde-fous d’action

Ce niveau encadre ce que l’agent a le droit de faire : droits limités par agent, périmètre d’intervention clair, absence de publication automatique, séparation entre production et validation.

Le principe directeur est simple : aucun agent n’a le pouvoir complet. Le site-maintainer ne touche que l’anglais. Les localizer ne touchent que leur langue. Le content-writer vérifie et prépare la livraison à relire — il ne produit pas seul le contenu initial. Le reporter informe et n’écrit ni code ni contenu. Cette séparation réduit fortement le risque qu’une erreur de compréhension en amont se propage sans contrôle jusqu’à la production.

Le pipeline ne publie pas. Il prépare une livraison à relire. La validation finale reste une étape humaine, ce qui aligne le système sur la réalité d’une chaîne éditoriale d’entreprise : un agent peut accélérer la production, pas se substituer à la responsabilité éditoriale.

Garde-fous d’observabilité

Ce niveau encadre ce que l’organisation peut voir et tracer du travail des agents : rapport de fin d’exécution, traçabilité des changements, explicitation des arbitrages, validation humaine avant publication.

Chaque exécution produit un rapport synthétique envoyé au coordinateur par l’agent reporter : changements retenus, changements écartés, blocs modifiés, points d’arbitrage. L’objectif n’est pas seulement de notifier la fin du pipeline, mais de rendre les décisions de l’agent lisibles par un humain — pour qu’un relecteur sache pourquoi un changement produit est devenu un bloc marketing et pas un autre.

Les modifications passent par une livraison versionnée avant publication. Un humain peut lire le diff, comparer langue par langue, revenir en arrière. C’est cette traçabilité qui transforme un agent autonome en agent auditable.

Sans observabilité, un pipeline agentique devient une boîte noire : il peut produire un résultat correct pendant des semaines, puis dériver sans signal détectable. Avec observabilité, chaque exécution laisse une trace exploitable — pour relire, pour mesurer la qualité dans le temps, pour ajuster les briefs.

Entre l’incident et les mises à jour suivantes, le pipeline est donc passé d’un scénario risqué — une mise à jour automatique pouvant dégrader la page publiée — à un scénario gouverné : une livraison prête à relire, produite par une équipe d’agents spécialisés, encadrée par trois niveaux de garde-fous lisibles.

C’est une différence d’architecture, pas seulement de prompt engineering.

Ce REX illustre un point essentiel pour les entreprises : la mise en place d’agents IA ne consiste pas seulement à automatiser une tâche. Elle suppose d’identifier les risques métier, de définir les périmètres d’action, de concevoir les bons points de contrôle et de rendre le système observable. C’est précisément sur ce type de cadrage que Castelis accompagne ses clients.

Ce que ce pattern permet ailleurs

Le cas clawpilot.eu est un exemple volontairement concret : une activité produit continue, une landing page, cinq langues, 75 textes courts à maintenir cohérents. Mais le pattern — découper, restreindre, valider, tracer — s’applique à tout workflow où un signal technique doit devenir un contenu métier sans dériver. Trois exemples pour projeter le REX dans des contextes différents.

Direction marketing — pages produit multilingues

Maintenir des pages produit multilingues sans dérive de ton, de promesse ou de positionnement. Un agent analyse les évolutions du catalogue, un autre rédige la version pivot, des agents localizer adaptent par marché, un agent de validation contrôle la cohérence terminologique et la conformité aux argumentaires validés. Les garde-fous de contenu protègent la marque ; les garde-fous d’action évitent qu’une fiche soit publiée sans relecture marketing ; l’observabilité permet de mesurer la qualité dans le temps et d’ajuster les briefs.

Direction produit / SaaS — release notes multi-publics

Transformer des changelogs techniques en release notes adaptées à différents publics : clients, support, commerciaux, documentation. Le même signal — un commit, un ticket, une PR fusionnée — doit alimenter une note développeur, une annonce produit, un message au support et une mise à jour de la documentation. Chaque canal a son registre, son niveau de détail, ses contraintes. Un agent unique se trompe systématiquement de cible ; un pipeline d’agents spécialisés par canal, encadré par des garde-fous de contenu et d’action, produit le bon message au bon endroit, avec une trace lisible pour le product owner.

Support / knowledge management — base de connaissance

Mettre à jour une base de connaissance après chaque évolution produit, avec validation avant publication. Un agent détecte les articles impactés, un autre propose les modifications, un agent de validation vérifie la cohérence avec la documentation officielle et la non-régression sur les réponses critiques. Les garde-fous d’observabilité sont ici décisifs : un support qui s’appuie sur une base périmée ou divergente perd la confiance des clients en quelques semaines.

Dans tous les cas, le point clé reste le même : ne pas demander à un agent unique de comprendre le produit, arbitrer la valeur métier, rédiger, localiser, valider et publier. Castelis intervient précisément sur cette zone : concevoir le pipeline cible, identifier les risques métier, définir les garde-fous, intégrer les agents dans les workflows existants et rendre le système observable.

L’enjeu n’est pas de remplacer les équipes. Il est de transformer des opérations répétitives, fragiles et multilingues en chaînes agentiques contrôlées, auditables et adaptées au métier.

Conclusion

L’incident de mise à jour automatique de clawpilot.eu n’a pas montré que les agents IA étaient incapables de produire du contenu marketing. Il a montré qu’ils peuvent le faire trop vite, trop littéralement, et sans discernement si l’architecture ne leur impose pas les bons garde-fous.

Pour les entreprises, le sujet n’est donc pas d’ajouter des agents IA partout. Le sujet est d’identifier les workflows où l’automatisation apporte un gain réel, de définir les risques acceptables, puis de concevoir une architecture où chaque agent agit dans un périmètre contrôlé, observable et validable.

La question n’est donc plus de savoir si vos agents peuvent générer du contenu.

La question est de savoir si vous savez les empêcher de le faire mal.

C’est précisément le rôle d’un cadrage IA opérationnel : passer d’une expérimentation prometteuse à un système utilisable en production.