Ceetrix et Claude Code nous ont aidés à avancer rapidement. La véritable réussite a été de rendre cette rapidité fiable.
Divulgation : Ceetrix est une plateforme conçue par un de mes amis proches, ancien de Google, Chief Product Officer expérimenté et expert en IA agentique.
Les récits sur le codage par IA célèbrent souvent la rapidité tout en négligeant la discipline.
Cela fonctionne, jusqu'au moment où le logiciel commence à toucher des flux de travail qui comptent.
Dans notre cas, nous avons utilisé Claude Code et Ceetrix pour faire progresser un produit B2B sérieux en une seule soirée. Mais le résultat important n'était pas simplement que le code a été généré rapidement. C'était que le travail est resté gouverné, des exigences jusqu'à la validation en production.
Cette différence est ce qui a rendu le résultat utile.
Commencer par les preuves, pas par l'enthousiasme
Nous n'avons pas commencé par une invite de construction ouverte. Nous avons commencé par un document structuré d'exigences produit et une analyse des écarts distincte, basée sur une application existante.
L'étape des exigences produit a également été précédée par la construction du système de conception et son verrouillage à l'aide de garde-fous dans Claude Design, avant de transférer le prototype initial dans Claude Code. Nous aborderons ce sujet dans un autre article.
Cela a créé trois versions concurrentes de la vérité.
Le PRD décrivait le comportement prévu. Le prototype suggérait le comportement actuel. Le dépôt révélait le comportement réel.
Un seul de ces éléments pouvait être considéré comme faisant autorité.
La première étape n'était donc pas la mise en œuvre. C'était la réconciliation.
Plusieurs parties du produit étaient plus solides que prévu. D'autres paraissaient plus complètes dans l'interface qu'elles ne l'étaient dans la logique sous-jacente. C'est un état courant dans un logiciel en croissance, et c'est précisément pourquoi la gouvernance compte. Si vous construisez sur des hypothèses non vérifiées, l'IA ne fait qu'accélérer le risque.
Ceetrix a imposé une chaîne de livraison
Ceetrix a imposé un parcours structuré :
PRD → Conception → Tâches → Tests
Cela empêchait l'équipe de passer directement de l'idée au code. Chaque exigence devait se transformer en une conception explicite. Chaque conception devait générer des tâches concrètes. Chaque tâche devait être étayée par des tests et une validation.
Cela a changé le rôle de l'agent IA.
Plutôt que d'agir comme un improvisateur rapide, il est devenu un contributeur opérant à l'intérieur d'un système traçable. Cela compte, car les grands modèles de langage excellent à produire des réponses plausibles. La plausibilité est utile, mais ce n'est pas une preuve. Ceci s'ajoute aux garde-fous présents dans notre CLAUDE.md et nos hooks.
Un flux de travail gouverné réduit l'écart entre les deux.
La première version s'est concentrée sur l'intégrité opérationnelle
Le premier scénario de production choisi concernait la gestion des devises. Nous nous sommes d'abord concentrés sur la manière dont l'application gérait la logique des devises, puis avons choisi une intégration API pour valider les changements de devises sur 30 devises.
L'application existante s'appuyait sur des valeurs codées en dur, ce qui est acceptable dans un prototype, mais pas dans un logiciel censé soutenir des décisions opérationnelles sérieuses. Le travail a donc consisté à remplacer les hypothèses statiques par des données de référence en direct, des annotations visibles et une logique de repli plus sûre.
Cela concernait plus que la simple exactitude technique.
Si un système convertit un chiffre, il doit le rendre visible. S'il utilise un taux de référence, il doit le préciser. S'il applique une solution de repli, ce comportement doit être explicite. Une bonne gouvernance signifie que le système est honnête sur sa propre logique.
L'histoire a été mise en œuvre, testée et validée dans un environnement réel plutôt que considérée comme terminée sur la seule base de la génération de code.
La validation a mis en évidence un problème de sécurité réel
Lors de la validation de la mise en production, nous avons découvert qu'un chemin de paramètres public exposait plus d'informations que prévu. Après un examen plus approfondi, le problème semblait impliquer un schéma de valeur sensible et nécessitait donc un confinement immédiat.
Les données concernées ont été corrigées, le chemin exposé a été restreint, et les garde-fous environnants ont été améliorés afin de réduire la probabilité que ce type de problème se reproduise. Cet épisode a démontré quelque chose d'important sur la livraison gouvernée. Lorsque les équipes valident avec soin par rapport au comportement réel, des problèmes apparaissent que des flux de travail plus rapides mais moins rigoureux pourraient manquer entièrement.
La leçon n'était pas que l'IA a « fait de la sécurité » de manière autonome.
La leçon était qu'un flux de travail traçable et fondé sur des preuves a rendu difficile le fait que le problème reste caché.
La deuxième histoire a renforcé le comportement des paramètres
Une deuxième histoire de production s'est concentrée sur la gestion des paramètres et des préférences. Les choix organisés ont été correctement appliqués, les préférences ont été conservées de manière plus fiable, et les changements importants sont devenus auditables. Des problèmes de comportement plus mineurs ont également été corrigés dans le cadre de la validation de bout en bout.
Ce type de travail produit rarement des titres retentissants, mais il améliore sensiblement la fiabilité.
C'est là le point essentiel. La qualité logicielle sérieuse s'améliore souvent grâce à des gains d'intégrité cumulatifs plutôt qu'à des fonctionnalités spectaculaires.
La limite de contrôle comptait autant que le code
Pendant toute la session, l'agent IA pouvait analyser, concevoir, mettre en œuvre, tester et expliquer. Mais il n'a pas franchi de limites irréversibles sans approbation.
- Avant de valider, il s'est arrêté
- Avant de déployer, il s'est arrêté
- Avant de toucher à des données de type production, il s'est arrêté
Ce n'est pas de l'inefficacité. C'est un modèle de contrôle fonctionnel.
Dans tout environnement opérationnel sérieux, la capacité et l'autorité doivent rester distinctes. Le développement de produits assisté par l'IA devrait suivre la même règle.
Conclusion
À la fin de la session, nous avions livré des améliorations significatives, renforcé le comportement opérationnel, détecté et résolu un problème réel, et fait progresser le MVP plus large grâce à un chemin structuré plus clair.
Mais le résultat le plus important était conceptuel.
L'IA n'a pas remplacé la gouvernance des produits.
Elle a rendu possible une gouvernance des produits disciplinée à une vitesse bien plus élevée.
C'est une histoire beaucoup plus durable qu'un nouvel exemple de code généré rapidement.
La question pour la livraison assistée par l'IA n'est plus de savoir si un modèle peut construire. Elle est de savoir si votre processus génère suffisamment de preuves pour faire confiance à ce qui est construit. C'est là où vous exigez des preuves avant de faire confiance à ce qu'ils ont fait. Gouvernez-vous votre livraison de produits aujourd'hui ? Découvrez Ceetrix.
Je vous tiendrai informés au fur et à mesure.