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

Déclaration : Ceetrix est une plateforme construite par un ami proche, 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 les rattrape : la plupart des petites et moyennes entreprises gèrent leur gouvernance de conseil au feeling. Une résolution est « adoptée » en réunion, quelqu'un modifie un champ de statut dans un tableur, le faisant passer de 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 répéter 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, assez plaisante, sur la façon dont nous le construisons. Car nous n'avons pas seulement écrit un logiciel de gouvernance. Nous avons accidentellement mené une expérience sur la gouvernance du processus qui écrit le logiciel de gouvernance.

La distribution des personnages

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, de « vibe coding » : vous décrivez ce que vous voulez, il écrit le code, vous 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, qu'on décrirait le mieux comme un chef de projet extrêmement strict qui a lu tous les manuels de droit des contrats et refuse de laisser quiconque quitter la pièce. Avant même 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 pièces de travail spécifiques cela se décompose-t-il (les tâches), et, surtout, quels tests prouvent que chaque pièce 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 feeling autorisé.

Ainsi, Claude Code n'a pas la liberté de faire cavalier seul. Il peut construire, mais uniquement contre une spécification 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 « voici ce que je ferais différemment la prochaine fois », avant que quoi que ce soit ne soit déclaré terminé.

Hier : peu glamour, et nécessaire

Hier, nous avons livré deux éléments qui ne gagneront jamais de prix de design mais dont chaque entreprise réelle a besoin : un écran de paramètres où l'équipe peut choisir quel modèle d'IA alimente différentes parties du produit, et un système d'administration complet pour inviter des collègues, attribuer des rôles, et, surtout, gérer la réalité des départs. Quand quelqu'un qui possédait un ensemble de risques ou d'actions ouverts part, le logiciel ne rend pas simplement son travail orphelin. 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 trois mois plus tard en « attendez, c'était le travail de qui, ça ? ».

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

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 officielles que prend un conseil d'administration. 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, ce que vous vouliez saisir. 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 Revue, Approuvée, Rejetée, et ne peut avancer que de la façon dont un vrai vote le ferait.
  • Atteindre le statut Approuvée exige la validation de deux personnes distinctes, en l'occurrence 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 responsable, 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 les oblige tous deux à signer à nouveau. Impossible de modifier une résolution après qu'elle a déjà été approuvée en espérant que personne ne le remarque.
  • Une fois qu'une chose est Approuvée, elle devient permanente. Vous ne pouvez pas la modifier. Vous ne pouvez pas la supprimer. La seule façon de changer d'avis est de la remplacer formellement, ce qui crée une toute nouvelle résolution en brouillon, visiblement liée à celle qu'elle remplace, avec un enregistrement horodaté de qui a fait cela exactement et pourquoi. C'est la différence entre réécrire discrètement l'histoire et barrer quelque chose à l'encre là où tout le monde peut 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, afin qu'une résolution ne flotte jamais isolément, 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, acquéreur, ou avocat d'investisseur pourrait s'appuyer pendant une due diligence ».

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 façons différentes : la logique sous-jacente fonctionne-t-elle isolément, fonctionne-t-elle quand elle communique réellement avec une base de données, fonctionne-t-elle de la façon dont une personne cliquant sur l'écran en ferait l'expérience, et l'histoire entière, brouillon, soumission, approbation, nouvelle approbation, remplacement, fonctionne-t-elle de bout en bout comme une seule séquence continue. Ensuite, avant de la déclarer terminée, elle a été testée contre une copie réelle et temporaire de la base de données réelle, avec de vraies sessions de connexion, en cliquant sur le vrai 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 demandé d'abord. 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 direct. Non pas parce qu'il ne pouvait pas techniquement faire ces choses sans supervision, mais parce que c'est le véritable objectif de tout l'exercice : une IA qui ira volontiers vite 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, l'application de la mise à jour de la base de données en production a échoué avec une erreur d'autorisation énigmatique du fournisseur cloud, le genre de message qui vous fait un instant froid dans le dos. Cela s'est avéré n'être rien : un incident réseau ponctuel. Nous avons réessayé trente secondes plus tard et cela s'est déroulé sans problème. Je le mentionne parce que c'est un reflet fidèle de l'ensemble de la construction. Ce n'est pas de la magie, et ce n'est pas fragile non plus. C'est juste du logiciel, fait avec soin.

Pourquoi c'est tout l'enjeu

Il y a une véritable ironie à construire un logiciel de gouvernance, un outil dont tout le travail consiste à forcer les décisions à être prises avec soin, de façon officielle, 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 tracée jusqu'à une conception. Chaque conception tracée jusqu'à de véritables tâches. Chaque tâche clôturée avec de véritables résultats de tests et une note honnête sur ce qu'il faut améliorer la prochaine fois. Chaque action risquée et difficile à annuler arrêtée pour un oui 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 le réalise, augmente dès l'instant où vous refusez que « terminé » signifie autre chose que « voici la preuve ». C'était vrai avant que l'IA 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 non, 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 devise. Je vous dirai aussi comment cela se passe.

Vous suivez ? Ceci fait partie d'un journal de développement continu pour la plateforme de gouvernance de PoseidonGrooveAI, construite en toute transparence, erreurs incluses.