Cas d’étude · Systèmes d'IA : agents, équipes et résultats

Cas : la gouvernance qui signe. Comment une opération avec agents d'IA décide ce qui arrive à publication

Sebastián Ocampo · 2026-07-25

C'est le troisième système en production documenté dans ce lab, et celui qui soutient les deux autres : les règles qui décident ce qu'un agent peut publier seul, ce qui exige une signature humaine et ce qui se passe quand quelque chose tourne mal. Ce n'est pas de la théorie de comité : chaque mécanisme décrit ci-dessous fonctionne en ce moment sur les pages de ce site, celle-ci comprise.

Le problème : une machine à produire est, par défaut, une machine à se tromper à l'échelle

Cette maison opère avec des agents d'IA : une rédaction trilingue et un système d'étude de marché. Cela signifie que la capacité à produire des erreurs est aussi automatisée : un agent peut générer en une heure plus d'affirmations sans source, plus de liens cassés et plus d'incohérences de style qu'un humain n'en relirait en une semaine. Et le produit de cette maison est précisément la confiance : une publication dont le système de verdicts dit en une si un robot est réel, téléopéré ou mis en scène ne peut pas se permettre que son propre contenu viole la rigueur qu'elle exige des autres. La méthode publique de ces verdicts est dans la méthodologie.

Le risque a de plus un nom externe : les moteurs de recherche pénalisent l'abus de contenu à l'échelle, et les lecteurs pénalisent avant. La question de design n'était pas "comment éviter que l'IA se trompe" (impossible) mais : quel système fait qu'aucune erreur d'agent n'arrive à publication sans passer par des règles exécutables et par une personne qui répond de son nom ? La réponse utile pour toute entreprise est que la gouvernance ne consiste pas à freiner la production : elle consiste à décider, avec des mécanismes et non avec la mémoire, ce qui franchit la porte.

Le système : des règles qui sont des tests, des portes qui bloquent, une signature qui répond

La pièce centrale est un déplacement : les règles éditoriales ne vivent pas dans un document que les agents devraient lire, elles vivent dans du code qui s'exécute contre chaque pièce. Ce sont aujourd'hui 34 tests automatiques sur 417 enregistrements de contenu en trois langues, et la publication est bloquée tant qu'un seul échoue. Au-dessus des portes automatiques, deux couches de plus : la vérification en navigateur réel (la page construite se contrôle sur mobile avant publication) et la revue humaine finale, qui décide de la seule chose que les tests ne voient pas : si c'est vrai, si c'est utile et si cela sonne comme cette maison. Le tableau détaille chaque porte avec ce qu'elle attrape ; le flux complet :

  1. Règle écrite
  2. Règle convertie en test
  3. L'agent produit
  4. Portes automatiques
  5. Vérification en navigateur
  6. Revue et signature humaine
  7. Publication
  8. Registre des défaillances
  9. Règle nouvelle ou corrigée
PorteCe qu'elle vérifieCe qu'elle attrape en pratique
Validation de structureChaque pièce de contenu se valide contre un schéma strict : champs obligatoires, formats, les trois langues présentes.Pièces à moitié traduites, sources sans URL, dates mal formées : l'erreur structurelle meurt avant d'exister comme page.
Une requête par pageAucune requête de recherche ne peut avoir deux pages propriétaires dans la même langue.La cannibalisation, le mode de défaillance silencieux de tout site qui produit beaucoup : deux pages en concurrence pour la même chose.
Zéro orpheline et liens résolublesToute page doit être liée depuis le graphe, et tout lien interne doit résoudre dans les trois langues.Des pages que personne ne trouverait et des liens qu'un agent a écrits vers du contenu qui n'existe pas.
Champs de réponse propresLes textes qui alimentent les données structurées et les réponses extractables ne peuvent pas contenir de syntaxe interne.A attrapé un lien dans une FAQ le jour même de l'écriture de ce lab : l'erreur serait sortie dans les données structurées de la page.
Style vérifiableLes règles de voix de la maison exprimables comme vérification (signes interdits, structure de la réponse) se vérifient, ne se mémorisent pas.Violées encore et encore comme instructions ; plus jamais comme tests. L'histoire complète, plus bas, dans les défaillances.
Navigateur réel avant publicationLa page construite s'ouvre dans un navigateur et se vérifie en taille mobile : débordements, éléments cassés, ce que le HTML ne dit pas.Cette porte existe à cause d'une défaillance réelle arrivée en production : une vidéo cassée qu'aucun test ne voyait. L'histoire, plus bas.
Revue et signature humaineUne personne lit la pièce finale, répond de sa véracité et la signe de son nom. Les agents ne publient pas seuls, sans exception.Ce qu'aucun test ne peut voir : des affirmations valides mais fausses, des emphases trompeuses, des promesses que la maison ne doit pas faire.

Les décisions : pourquoi ceci et pas cela

Comme dans tout cas de cette maison, les outils comptent moins que les pourquoi. Voici les cinq décisions de gouvernance qui ont défini le système, avec l'alternative qu'elles ont écartée.

DécisionAlternative écartéePourquoi
Politique comme tests qui bloquentPolitique comme document et bonne volontéNous l'avons vécu : les mêmes règles violées comme instructions ne le furent plus jamais comme tests. Un manuel informe ; un mécanisme gouverne.
Portes bloquantes avant publicationAudit postérieur sur le déjà publiéUne erreur détectée après publication a déjà pris son prix en confiance. La porte coûte des secondes ; la rétractation coûte la crédibilité.
Registre des défaillances publicDéfaillances gérées en privéChaque cas de cette maison publie sa section de défaillances. C'est la preuve la moins chère que le reste est vrai, et cela force à corriger à la racine au lieu de couvrir.
Une personne signe tout de son nomÉchantillonnage, ou responsabilité diffuse de "l'équipe"La responsabilité nominative change le comportement de qui signe et la confiance de qui lit. "Revu par l'équipe" ne fait mal à personne.
Règles et données en formats propres et portablesGouvernance configurée dans l'outil d'IALes règles qui vivent dans le produit d'un fournisseur partent avec le fournisseur. Les nôtres marchent pareil si demain le modèle change : changer, c'est reconfigurer, pas reconstruire.

Le compte : ce que coûte gouverner ainsi

La gouvernance automatique a un coût marginal proche de zéro : les 34 tests tournent en secondes à chaque construction du site, sans coût de plateforme ajouté, et les vérifications en navigateur ajoutent deux minutes par publication. Le coût réel est humain et c'est la revue finale : lire, vérifier les affirmations contre les sources et signer, le poste de supervision qui domine toute opération avec agents (la structure de coût complète, avec calculateur, est dans le blueprint d'opération de contenu).

Le compte de l'autre côté est celui que presque personne ne fait : ce que la porte évite. Chaque défaillance du tableau ci-dessus attrapée avant publication a coûté des minutes de correction ; la seule défaillance réelle qui a traversé jusqu'en production (la vidéo, racontée plus bas) a coûté des heures de diagnostic, une correction urgente et la part de confiance du lecteur qui ne se mesure jamais. Dans une opération qui produit à vitesse d'agent, le rapport entre ces deux nombres ne peut que croître en faveur des portes : c'est l'investissement au meilleur rendement de tout le système.

Ce qui a échoué

Trois défaillances réelles, choisies parce que chacune a enseigné une règle différente. La première est fondatrice : les règles de voix de la maison (d'un signe typographique interdit à la structure de la première phrase) étaient violées encore et encore dans les brouillons tant qu'elles furent des instructions écrites. Elles cessèrent de l'être le jour où elles devinrent des tests qui empêchent de publier. De là vient le principe qui donne son titre au cas : si votre guide de style ne peut pas rejeter une pièce, c'est une suggestion.

La deuxième a traversé jusqu'en production et c'est un lecteur qui l'a trouvée : une vidéo intégrée qui s'affichait comme une boîte noire sur mobile. Aucun test ne la voyait, parce que les tests lisent des données et de la structure, pas des pixels : la cause était la combinaison d'un format vidéo vertical et d'une règle de style qui ne pouvait jamais s'appliquer à l'élément créé dynamiquement. La correction technique a pris une après-midi ; la correction de gouvernance a été d'ajouter la porte manquante, la vérification en navigateur réel et taille mobile avant chaque publication. Les portes de ce système ne sortent pas d'un plan directeur : chacune est la cicatrice d'une défaillance concrète.

La troisième était de distribution des rôles et c'est la revue humaine qui l'a attrapée, pas un test : la première version du profil de l'auteur lui attribuait la vérification des robots, alors que c'est la publication qui vérifie avec sa méthode et la personne qui construit des systèmes. Lue à froid, la phrase était fausse, et c'est exactement le type d'erreur (juridiquement anodine, réputationnellement létale) qu'aucun test structurel ne verra jamais. C'est pourquoi la dernière porte est une personne, et c'est pourquoi ce cas s'appelle ainsi : la gouvernance qui signe.

Où cela s'inscrit dans les cadres (NIST, ISO 42001, AI Act)

Ce système n'a pas été conçu en remplissant un cadre, mais il s'y mappe proprement, et ce mappage est utile s'il faut le défendre devant un conseil ou un auditeur. Contre le cadre de gestion des risques d'IA du NIST : les règles écrites et la signature nominale sont la fonction gouverner ; le registre des défaillances, la fonction mesurer ; les portes bloquantes, la fonction gérer. Contre l'esprit d'ISO/IEC 42001 : c'est un système de management de l'IA en miniature, avec politique, contrôles opérationnels, amélioration continue nourrie par les défaillances et responsabilité assignée. Et contre la direction de l'AI Act européen, qui pousse vers la transparence et la supervision humaine des systèmes produisant du contenu : ici la supervision humaine n'est pas une case, c'est la porte finale avec nom et prénom. La certification CAIM qui signe ce lab couvre précisément ce métier : aligner des systèmes réels sur ces cadres sans les convertir en théâtre documentaire.

La traduction pour votre entreprise n'est pas de copier ces portes, c'est de copier la question qui les a créées : pour chaque règle de votre politique d'IA, quel mécanisme l'exécute, et que se passe-t-il exactement quand elle est violée ? Là où la réponse est "nous faisons confiance à la mémoire des gens", vous avez votre prochaine défaillance en attente de date.

Comment monter la gouvernance qui signe dans votre entreprise

Six étapes, dans l'ordre qui fonctionne. Le motif vaut autant pour le contenu, les rapports financiers, le service client ou tout autre flux où des agents produisent du travail qui sort dans le monde.

  1. Écrivez les règles comme des phrases vérifiables Pas "le contenu sera de qualité" mais "toute affirmation chiffrée porte une source avec URL" ou "aucune pièce ne sort sans les trois langues". Si une règle ne peut pas échouer de façon détectable, ce n'est pas encore une règle : c'est une aspiration.
  2. Convertissez en mécanisme tout le convertible Chaque règle vérifiable devient une vérification automatique qui bloque, pas qui avertit. Pas besoin de grande ingénierie : la validation de structure et les listes d'interdits couvrent la plupart des règles de toute opération, et se montent en jours.
  3. Définissez ce qui exige une signature humaine, et qu'elle soit nominale La ligne claire : les agents préparent, les portes filtrent, une personne nommée signe ce qui sort dans le monde. La signature diffuse ("revu par l'équipe") ne change pas les comportements ; la nominale oui, dans les deux sens.
  4. Ajoutez la vérification qui voit ce que les données ne voient pas Le résultat final, regardé comme le verra le destinataire : la page sur un mobile réel, le rapport ouvert dans le format du client, le courriel lu dans la boîte. Notre seule défaillance en production vivait exactement dans ce trou.
  5. Publiez (au moins en interne) le registre des défaillances Chaque défaillance avec cause, correction et règle nouvelle. Le registre visible convertit les erreurs en infrastructure et désactive la politique de la dissimulation, le vrai risque de continuité de toute opération avec IA.
  6. Fermez le circuit : chaque défaillance finit en règle La question rituelle après chaque incident : quelle porte aurait attrapé cela, et pourquoi n'existait-elle pas ? Ainsi le système s'améliore au rythme de ses erreurs, le seul rythme d'amélioration qu'une opération avec agents peut soutenir honnêtement.

Vers où cela évolue (lu en juillet 2026)

Deux courbes se croisent. La première : le coût de produire avec des agents continue de chuter, donc la production cesse d'être un avantage pour quiconque et la différence se déplace entièrement vers ce qui a été raconté ici : quel système décide ce qui se publie et qui répond. La seconde : la régulation européenne avance par phases vers l'exigence de transparence et de supervision humaine démontrable, et l'écart entre "nous avons une politique d'IA" et "notre politique peut rejeter du travail et laisser trace" deviendra un écart auditable. Notre pari opérationnel pour les prochains trimestres : les agents eux-mêmes assumeront plus d'autovérification (proposer le test avec la pièce), la vérification en navigateur s'automatisera dans les portes, et le registre des défaillances gagnera une structure de dataset, comme tout dans cette maison. Ce qui ne changera pas, c'est la dernière porte : une personne qui signe. Plus les machines produisent, plus la signature vaut.

Le système complet de cette maison, avec ses deux autres cas en production et ses réponses rapides, est dans Systèmes d'IA.

Questions fréquentes

La gouvernance ne freine-t-elle pas la vitesse gagnée avec les agents ?
Au contraire : c'est ce qui permet d'utiliser la vitesse. Les portes automatiques tournent en secondes et n'ajoutent pas de friction perceptible ; ce qui consomme du temps, la revue humaine finale, existerait de toute façon dans toute opération sérieuse. Sans portes, chaque pièce rapide est un pari ; le jour où une sort mal en public, l'opération entière freine d'un coup et pour bien plus longtemps que ce que les portes auraient coûté en un an.
Combien de règles faut-il pour commencer ?
Moins que vous ne croyez : nos portes sont nées de défaillances concrètes, pas d'un plan directeur. Un départ honnête, ce sont trois mécanismes : validation de structure de ce que produisent les agents (champs obligatoires, sources avec URL), une courte liste d'interdits vérifiables, et la règle de signature nominale. Avec cela en marche, chaque nouvel incident vous dit quelle porte ajouter. La gouvernance conçue entière en séminaire de direction décrit généralement une entreprise qui n'existe pas.
Quels outils faut-il pour les portes automatiques ?
Aucun d'exotique : les nôtres sont des tests logiciels ordinaires (validation de schémas et vérifications de texte) qui tournent à chaque construction du site, et un navigateur automatisé pour la vérification visuelle. Dans une opération sans développeurs, le même rôle est joué par la validation de formulaires de votre CMS, des gabarits à champs obligatoires et des listes de contrôle que quelqu'un exécute vraiment. L'outil importe peu ; ce qui importe, c'est la propriété de bloquer : si le travail peut se publier en sautant la vérification, vous n'avez pas une porte, vous avez une recommandation.
Cela sert-il à se conformer à l'AI Act ou à la nLPD ?
C'est la base opérationnelle, pas la conformité entière : les obligations concrètes qui s'appliquent dépendent de votre secteur, vos systèmes et vos données, et cela exige sa propre analyse. Ce que ce motif vous donne, c'est ce que les cadres présupposent et que presque personne n'a : une supervision humaine démontrable, des contrôles qui laissent trace et un registre d'incidents vivant. Avec cette base, le travail de conformité consiste à mapper et documenter ; sans elle, c'est inventer sur papier une opération qui n'existe pas, et cette fiction tombe au premier audit sérieux.

Sources

Plus de cas et la méthode, dans Systèmes d'IA : agents, équipes et résultats.