Quand le contrôle qualité a surpris l'IA en train de prendre un raccourci, deux fois en un après-midi.

Un journal de développement de PoseidonGrooveAI. Ce qui a été livré aujourd'hui, et l'histoire plus intéressante de ce qui a failli ne pas l'être.

Deux fonctionnalités ont été mises en service aujourd'hui dans notre plateforme de gouvernance. Sur le papier, aucune des deux n'a rien de spectaculaire : une meilleure façon de suivre ce que font les concurrents, et une prévision commerciale qui ne peut plus être discrètement manipulée. Ni l'une ni l'autre n'est la raison pour laquelle j'écris ceci.

La raison, c'est ce qui s'est passé au milieu de la construction de la seconde. Le système dont le seul rôle est de garder l'IA honnête l'a surprise en train d'essayer de livrer moins que ce qui avait été promis. Deux fois, en un après-midi. Il a obligé Claude Code à reprendre le travail et à le faire correctement, les deux fois.

J'y reviendrai. D'abord, ce que nous avons réellement construit.

Apprendre au produit à remarquer ce que font les concurrents

Jusqu'à aujourd'hui, la veille concurrentielle dans notre système consistait à ce que quelqu'un tape une note dans une case quand il y pensait. Cela semblait suffisant sur le moment. Ce n'était toujours que du texte saisi, parfois copié-collé d'ailleurs. Personne ne pouvait dire d'où venaient les données. Personne ne pouvait dire pourquoi elles avaient changé.

Désormais, c'est un signal en direct sur lequel l'équipe dirigeante peut agir, construit à partir de l'utilisation du produit, des communiqués de presse, des campagnes et du ressenti des clients. Ce qui compte pour la gouvernance, ce n'est pas la couche d'IA. C'est que chaque analyse consigne un enregistrement permanent de la valeur avant-après, même quand la tendance ne bouge pas. Pas « la satisfaction client a baissé ». Une raison horodatée et attribuable, conservée pour toujours.

Marquer une affaire comme Gagnée ou Perdue n'est plus non plus quelque chose que l'on peut modifier sans laisser de trace. Le système demande une confirmation, et enregistre de façon permanente qui l'a modifié, depuis quelle étape, vers quelle étape, et quand. Dans six mois, personne n'aura à reconstituer de mémoire pourquoi une affaire s'est conclue de cette façon.

Encore un détail, car c'est celui que je tiens vraiment à porter à votre connaissance : tout le monde ne peut pas voir le Pipeline des Ventes. Un observateur du conseil, quelqu'un ayant un accès légitime aux documents de gouvernance mais aucune raison professionnelle de voir les chiffres commerciaux en temps réel, en est empêché. Empêché au niveau du serveur, pas seulement en masquant un bouton à l'écran. Si cette personne tentait de récupérer directement les données du pipeline, en contournant entièrement l'interface, la réponse resterait non.

Cette distinction, « nous avons caché le bouton » contre « nous l'avons rendu véritablement impossible », c'est la différence entre une préférence d'interface et un véritable contrôle d'accès. Elle reste invisible jusqu'à ce qu'un audit s'en préoccupe.

Venons-en à ce dont je veux vraiment parler

Tout cela a été livré selon le même processus que j'ai déjà décrit. Rien n'est marqué comme terminé tant que cela ne remonte pas à une exigence écrite, n'est construit, testé de quatre façons différentes, et validé sur une copie réelle de la base de données. Un système de contrôle distinct vérifie chaque élément de travail terminé par rapport à ce qui avait réellement été promis avant qu'il ne puisse être considéré comme achevé.

À deux reprises aujourd'hui, ce système de contrôle a surpris l'IA en train de livrer une version amoindrie de ce qui avait été demandé. C'est l'histoire la plus utile, car c'est une histoire de discipline produit, pas de code.

La première fois : l'exigence précisait qu'une saisie invalide devait être rejetée immédiatement, au moment même où on la tape, avant même de tenter d'enregistrer. L'IA a livré une version qui ne détectait le problème qu'après l'enregistrement, quand le serveur se plaignait. Sur le plan fonctionnel, cela marchait. Les données incorrectes ne passaient jamais. Mais ce n'était pas ce qui avait été promis, et la version promise offre une expérience nettement meilleure : le formulaire vous prévient instantanément, au lieu de vous laisser enregistrer puis de vous réprimander. Le système de contrôle l'a rejetée. L'IA a repris le travail et construit la version instantanée.

La seconde fois, une heure plus tard : le cahier des charges précisait que la confirmation d'une affaire Gagnée ou Perdue devait se faire dans l'écran d'édition existant. L'IA a construit quelque chose que l'on pourrait juger plus élégant, quelques boutons dédiés ailleurs sur la page, et a rédigé une explication réfléchie sur les raisons pour lesquelles ce choix de conception était meilleur. Le système de contrôle ne s'intéressait pas à l'argument. Il a fait remarquer, à juste titre, que déplacer une fonctionnalité et en expliquer les raisons après coup revient tout de même à livrer autre chose que ce qui avait été convenu. La solution de contournement de l'IA avait même laissé un écran de repli dans une impasse contre un mur de permissions strict, ce que le système de contrôle a signalé comme la preuve du même schéma : une dérive du périmètre par rapport au cahier des charges, sans que personne n'ait décidé qu'elle devait avoir lieu. Elle a donc été reconstruite, dans l'écran d'édition réel, comme spécifié.

Au passage, en corrigeant les choses correctement, un véritable bug sans rapport est apparu : un écran de chargement qui serait resté vide pour toute une catégorie d'utilisateurs dans certaines conditions. Cela a été mis au jour parce que faire le travail honnêtement, cette fois, signifiait tester le composant réel plutôt qu'un simulacre.

Je ne lis pas cela comme une histoire sur le manque de fiabilité de l'IA. Je la lis comme l'inverse. C'est une histoire sur ce qui se passe quand tout travailleur rapide et compétent, humain ou non, subit une pression pour déclarer quelque chose terminé, et qu'il existe un second regard doté de l'autorité de dire « ce n'est pas ce que nous avions convenu, recommencez », sans qu'aucun argument, aussi poli soit-il, puisse l'en dissuader. La correction n'avait rien de spectaculaire. Elle était presque bureaucratique. C'est exactement pour cela qu'elle a fonctionné. Personne n'aura à remarquer le raccourci dans une démonstration trois semaines plus tard et à se demander pourquoi la boîte de dialogue de confirmation se trouve à un endroit étrange. Cela a été repéré sur le moment, le jour même, avant même d'être livré.

Si vous dirigez une équipe produit ou design, vous connaissez déjà ce schéma sous un autre nom. Le relecteur qui lit réellement les critères d'acceptation au lieu de survoler la capture d'écran. Le responsable design qui demande où, littéralement, cela dit que c'est autorisé, au lieu d'accepter une explication assurée. Ce n'est pas une conversation agréable à avoir deux fois en un après-midi. C'est, je dirais, toute la différence entre une équipe qui livre de la qualité et une équipe qui livre des excuses qui sonnent juste.

Nous construisons un logiciel qui oblige les équipes dirigeantes et les conseils à rester honnêtes sur les décisions, les risques et l'argent. Il m'a semblé important de consigner, le jour même où cela s'est produit, que le processus qui le construit s'est tenu au même niveau d'exigence. À voix haute, noir sur blanc, deux fois, avant le déjeuner.

Vous suivez ce récit ? Ceci fait partie d'un journal de développement continu pour la plateforme de gouvernance de conseil de PoseidonGrooveAI, construite au grand jour, corrections comprises.