Ou : ce qui s'est passé quand nous avons laissé Claude Code en liberté sur notre produit de gouvernance des conseils, et l'avons obligé à prouver son travail à chaque étape.

Divulgation : Ceetrix est une plateforme conçue par un de mes amis proches, un ancien de Google, Chief Product Officer expérimenté et expert en IA agentique.

Voici un problème dont presque personne ne parle jusqu'à ce qu'il le frappe : la plupart des petites et moyennes entreprises gèrent leur gouvernance de conseil à l'instinct. Une résolution est « adoptée » lors d'une réunion, quelqu'un modifie un champ de statut dans une feuille de calcul, le faisant passer d'En attente à Approuvé, et six mois plus tard, quand l'avocat d'un investisseur demande qui a réellement validé cela, et quand, et si quelque chose a changé entre le vote et la version finale, la réponse honnête est un haussement d'épaules et un défilement dans de vieux fils d'e-mails. J'ai vu cette scène exacte se rejouer plus d'une fois.

C'est le problème que nous construisons un logiciel pour résoudre. Et les deux derniers jours nous ont donné une étude de cas étrange, en quelque sorte délicieuse, sur la manière dont nous le construisons. Car nous n'avons pas seulement écrit un logiciel de gouvernance. Nous avons accidentellement mené une expérience de gouvernance du processus qui écrit un logiciel de gouvernance.

Les personnages de l'histoire

Nous construisons sur Claude Code, l'agent de codage IA d'Anthropic, le genre d'outil qui s'est forgé une réputation, méritée, la plupart du temps, pour le « codage à l'instinct » : vous décrivez ce que vous voulez, il écrit le code, vous y jetez un œil, vous le déployez, en espérant que tout se passe bien.

Nous ne faisons pas cela. Au lieu de cela, tout passe par une plateforme de gouvernance produit appelée Ceetrix, que l'on pourrait décrire comme un chef de projet extrêmement strict qui a lu tous les manuels de droit des contrats et refuse de laisser qui que ce soit quitter la pièce. Avant qu'une seule ligne de code ne soit écrite, Ceetrix exige : quel problème résolvons-nous (le PRD), comment allons-nous exactement le résoudre (la conception), en quelles tâches précises cela se décompose-t-il (les tâches), et, essentiellement, quels tests prouvent que chaque élément fonctionne réellement. Il ne vous laisse rien marquer comme terminé à moins que toute cette chaîne ne remonte proprement à une exigence réelle. Aucun instinct autorisé.

Ainsi, Claude Code n'a pas le droit de faire cavalier seul. Il peut construire, mais uniquement selon un cahier des charges qu'il ne peut pas réinterpréter en silence, et il doit montrer son travail : de vrais résultats de tests, de vraies preuves, de vraies rétrospectives du type « voici ce que je ferais différemment la prochaine fois », avant que quoi que ce soit ne soit déclaré terminé.

Hier : peu glorieux, mais nécessaire

Hier, nous avons livré deux éléments qui ne remporteront jamais de prix de design mais dont toute entreprise réelle a besoin : un écran de Paramètres où l'équipe peut choisir quel modèle d'IA alimente les différentes parties du produit, et un système d'Administration complet pour inviter des coéquipiers, attribuer des rôles et, surtout, gérer la réalité des départs. Lorsqu'une personne qui possédait plusieurs risques ou actions ouverts s'en va, le logiciel ne se contente pas d'orpheliner son travail. Il oblige quelqu'un à le réattribuer explicitement. Un petit détail. Le genre de petit détail qui, s'il est négligé, se transforme en « attendez, à qui incombait cette tâche ? » trois mois plus tard.

Aujourd'hui : apprendre au logiciel à réellement responsabiliser un conseil

La pièce maîtresse d'aujourd'hui était la fonctionnalité qui donne tout son mordant au produit : les résolutions du conseil, les décisions formelles et actées que prend un conseil. Hier, dans notre propre produit, une résolution n'était qu'un champ de statut que n'importe quel utilisateur connecté pouvait modifier. Adoptée, en attente, peu importe ce que vous tapiez. Aujourd'hui, elle est devenue quelque chose de plus proche de ce qu'est réellement une résolution dans le monde réel : une décision qui a du poids.

Voici ce qui a changé, en termes simples :

  • Une résolution passe désormais par de véritables étapes, Brouillon, En Révision, Approuvée, Rejetée, et ne peut avancer que de la manière dont un vote réel le permettrait.
  • Passer au statut Approuvée nécessite que deux personnes distinctes donnent leur accord, à savoir le président du conseil et le fondateur, et non la même personne portant deux casquettes. Nous appelons cela la séparation des tâches. Si quoi que ce soit concernant la résolution, son libellé, son propriétaire, sa date de décision, change même légèrement entre la première signature et la seconde, le système le détecte et exige que les deux signent à nouveau. Impossible de modifier une résolution après qu'elle a déjà été approuvée par quelqu'un en espérant que personne ne le remarque.
  • Une fois qu'un élément est Approuvé, il devient permanent. Vous ne pouvez pas le modifier. Vous ne pouvez pas le supprimer. La seule façon de changer d'avis est de le remplacer formellement, ce qui crée une toute nouvelle résolution en brouillon, visiblement liée à celle qu'elle remplace, avec un enregistrement horodaté indiquant précisément qui a fait cela et pourquoi. C'est la différence entre réécrire discrètement l'histoire et barrer quelque chose à l'encre, de sorte que tout le monde puisse encore lire ce qui était écrit auparavant.
  • Les Résolutions peuvent désormais être liées aux risques, actions et décisions réels auxquels elles se rapportent, de sorte qu'une résolution ne reste jamais isolée, déconnectée de la réalité qu'elle était censée traiter.

Rien de tout cela n'est spectaculaire. Tout cela fait exactement la différence entre « nous avons des procès-verbaux de conseil » et « nous avons un registre de gouvernance sur lequel un véritable auditeur, un acquéreur ou l'avocat d'un investisseur pourrait s'appuyer lors d'un audit préalable ».

Comment cela a réellement été construit

Avant que quoi que ce soit de tout cela ne touche à des données réelles, cela a été testé de quatre manières différentes : la logique sous-jacente fonctionne-t-elle de manière isolée, fonctionne-t-elle lorsqu'elle communique réellement avec une base de données, fonctionne-t-elle de la façon dont une personne l'expérimenterait en cliquant à l'écran, et l'ensemble du scénario, brouillon, soumission, approbation, nouvelle approbation, remplacement, fonctionne-t-il de bout en bout comme une séquence continue. Ensuite, avant de considérer que c'était terminé, cela a été mis à l'épreuve sur une copie réelle et temporaire de la base de données réelle, avec de véritables sessions de connexion, en parcourant le véritable flux de travail. Pas une simulation.

À chaque point précis où Claude Code aurait pu entreprendre une action irréversible, il s'est arrêté et a d'abord demandé. Avant de valider le code. Avant de le pousser où que ce soit. Avant de toucher à la base de données de production. Avant de le déployer en production. Non pas parce qu'il ne pouvait techniquement pas faire ces choses sans supervision, mais parce que c'est là le véritable objectif de tout cet exercice : une IA qui avancera volontiers rapidement jusqu'au moment précis où une action ne peut plus être annulée, et qui remet alors le stylo entre vos mains.

À un moment donné, l'application de la mise à jour de la base de données en production a échoué avec une erreur d'autorisation obscure du fournisseur cloud, le genre de message qui vous donne un pincement au cœur pendant une seconde. Il s'est avéré que ce n'était rien : un simple incident réseau ponctuel. Nouvelle tentative trente secondes plus tard, et cela s'est déroulé sans accroc. Je le mentionne parce que c'est un reflet fidèle de l'ensemble de cette construction. Ce n'est pas de la magie, et ce n'est pas fragile non plus. C'est simplement un logiciel, qui fait preuve de prudence.

Pourquoi c'est là tout l'intérêt

Il y a une réelle ironie à construire un logiciel de gouvernance, un outil dont toute la mission est de forcer les décisions à être prises avec soin, de manière consignée, réversibles uniquement par un processus formel visible, en utilisant un processus de développement qui s'applique exactement cela à lui-même. Chaque exigence retracée jusqu'à une conception. Chaque conception retracée jusqu'à des tâches réelles. Chaque tâche clôturée avec de véritables résultats de tests et une note honnête sur ce qu'il faudrait améliorer la prochaine fois. Chaque action risquée et difficile à annuler arrêtée dans l'attente d'un accord humain.

Il y a là une leçon qui n'a rien à voir avec l'IA en particulier. La qualité du travail, quel que soit celui ou ce qui l'accomplit, s'améliore dès l'instant où l'on refuse que « terminé » signifie autre chose que « voici la preuve ». Cela était vrai avant même que l'IA ne puisse écrire du code. Nous étions fiers de cette rigueur dans chaque entreprise que j'ai aidé à fonder ou dont j'ai fait partie. C'est encore vrai maintenant que l'IA peut écrire le code. L'outil a changé. La discipline, elle, n'a pas changé, et ne devrait pas changer.

Demain, nous commençons l'internationalisation : la fonctionnalité qui permet aux utilisateurs de plusieurs pays d'utiliser la plateforme dans leur propre langue et leur propre devise. Je vous raconterai comment cela se passe également.

Vous suivez ce récit ? Cela fait partie d'un journal de construction continu pour la plateforme de gouvernance de PoseidonGrooveAI, construite au grand jour, erreurs comprises.