Gouvernance du code généré par IA : les trois artefacts qui tiennent en prod

Chaque artefact a un rôle propre. Le fichier d'instructions encadre les humains et les agents sur le même pied, puisqu'ils lisent le même fichier. Les tests transforment les règles en mécanique. Les décisions tracées évitent de rejouer le même débat tous les six mois. C'est le cadre que CodeBlend pose sur chaque mission, et que ce dépôt applique à lui-même.

Une règle que la CI ne vérifie pas est une opinion. Pour l'argument chiffré (part du code généré, temps de review, dette de maintenance), un numéro de la newsletter Orchestrateur l'a traité en détail.

La contrainte qui fait tenir ce fichier : il est affiché en entier sur la page méthode du site. S'il ment, le site ment. Rendre le fichier public transforme une règle interne en engagement vérifiable par n'importe qui.

La règle de revue suit : une modification du fichier d'instructions se justifie dans la pull request, comme du code. Une règle ajoutée sans raison affichée devient du bruit que les agents relisent à chaque session.

• un test bloque les contenus factices : nom de client inventé, chiffre sans source, témoignage imaginaire ;
• un test vérifie zéro violation d'accessibilité serious ou critical sur chaque page ;
• un test asserte la politique de sécurité servie en production, entête par entête.

Pour les agents, la même logique s'applique : donner à l'agent un check qu'il peut exécuter (un test, un build, une capture à comparer), et la boucle de correction se ferme seule.

Ce que la CI vérifie à chaque push, plus personne ne le discute.

Le complément, moins connu : la propagation. Une règle fausse ne se corrige pas à un endroit. Elle se cherche dans tous les dépôts qui l'ont copiée, et la correction atteint chaque copie. Une fois, une information contredite par une pièce officielle a été retrouvée dans plusieurs fichiers qui la répétaient : corriger un seul fichier n'aurait rien changé, les autres continuaient de mentir.

Une correction n'existe que si elle atteint toutes les copies.

1. Écrivez, ou relisez, votre fichier d'instructions : une page, des règles courtes, chaque règle avec sa raison. S'il fait trois écrans, certaines règles servent le fichier, plus l'équipe.
2. Choisissez la règle que tout le monde contourne, et transformez-la en test. La CI vérifie, la conversation s'arrête.
3. Tracez la prochaine décision technique dans un ADR : datée, avec les alternatives refusées. Dans six mois, personne ne rejouera le débat.

Le cadre entier se tient sur une page. Si le vôtre demande une réunion pour s'expliquer, il est trop lourd : revenez aux trois artefacts. Si votre design system doit absorber du code généré par IA venant de plusieurs équipes, c'est le terrain de l'offre Système ; la façon de travailler, fichiers et tests compris, est décrite sur la page méthode.