Quand les agents IA livrent du contenu marketing : ce que nous apprend une mise à jour automatique mal cadrée

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.

C’est ce que nous avons expérimenté avec ClawPilot, notre plateforme open source MIT d’orchestration multi-agents IA, utilisée pour maintenir le site clawpilot.eu. Le site présente ClawPilot 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.

Les garde-fous qui ont sauvé le pipeline

Après l’incident, la correction n’a pas consisté à « mieux prompter » un agent unique. Elle a consisté à redessiner le système.

Une grille figée à 15 blocs de contenu

Le premier garde-fou 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.

Une règle de composition éditoriale

Le format de la grille est devenu une contrainte explicite. Ce détail peut sembler mineur. Il ne l’est pas.

Dans une landing page, la structure visuelle porte une partie du message. Une grille déséquilibrée dégrade la compréhension. Elle signale aussi que le pipeline ne contrôle pas la forme finale de ce qu’il produit.

Un agent IA ne doit donc pas seulement produire un texte correct. Il doit respecter l’objet éditorial dans lequel ce texte s’insère.

Une liste de formulations interdites

Le pipeline scanne désormais les descriptions marketing 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. L’objectif est 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 différence est fondamentale. La première phrase décrit une implémentation. La seconde exprime une capacité produit.

Des SOUL spécialisés par agent

Dans ClawPilot, le SOUL d’un agent correspond à son prompt système versionné. Autrement dit, c’est le cadre de travail stable qui définit ce que l’agent peut faire, comment il doit raisonner et ce qu’il doit refuser.

Chaque localizer dispose désormais d’un brief d’environ 90 lignes par langue. Ces briefs définissent le registre, les formes d’adresse, les calques à éviter, la terminologie produit et les formulations à privilégier.

Cette spécialisation é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é.

La séparation stricte des pouvoirs

Le dernier garde-fou est le plus important : 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. Le reporter informe. Cette séparation réduit fortement le risque qu’une erreur de compréhension se propage sans contrôle jusqu’à la production.

Le résultat attendu n’est pas une publication automatique sans supervision. Le résultat attendu est une livraison prête à être relue : structurée, cohérente, contrôlable, avec des garde-fous visibles.

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, avec cinq garde-fous éditoriaux.

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

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épasse largement ce contexte.

Il peut être appliqué à la maintenance de documentation utilisateur dans Notion, Confluence ou un portail documentaire. Un agent analyse les changements produit, un autre propose les sections à mettre à jour, des localizer adaptent les contenus, puis un agent de validation prépare une demande de revue.

Il peut également servir à générer des notes de version multi-canal. Le même signal technique peut alimenter une note développeur, une annonce produit, un post interne, une notification client ou une page d’aide. Chaque canal a son propre registre, ses contraintes et son niveau de détail.

Il peut enfin s’appliquer à des fiches produit e-commerce multilingues, à des bases de connaissance support ou à des contenus d’onboarding. 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.

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.