Ceetrix et Claude Code nous ont aidés à avancer rapidement. La vraie réussite a été de rendre cette rapidité fiable.
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.
Les récits sur le codage par IA célèbrent souvent la rapidité en ignorant 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 avancer un produit B2B sérieux en une seule soirée. Mais le résultat important n'était pas simplement que le code ait été généré rapidement. C'est que le travail est resté encadré depuis les 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 d'exigences produit structuré et une analyse d'écart 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 avec des Guardrails dans Claude Design avant de transmettre le prototype initial à Claude Code. Nous en parlerons 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.
Une seule de ces sources pouvait être considérée comme faisant autorité.
La première étape n'était donc pas la mise en œuvre. C'était la réconciliation.
Plusieurs domaines du produit étaient plus solides que prévu. D'autres semblaient plus complets dans l'interface qu'ils 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 testé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 a empêché l'équipe de passer directement de l'idée au code. Chaque exigence devait devenir 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.
Au lieu d'agir comme un improvisateur rapide, il est devenu un contributeur opérant à l'intérieur d'un système traçable. Cela compte parce que les grands modèles de langage sont excellents pour produire des réponses plausibles. La plausibilité est utile, mais ce n'est pas une preuve. Cela s'ajoute aux garde-fous de notre CLAUDE.md et de nos hooks.
Un flux de travail encadré réduit l'écart entre les deux.
La première version s'est concentrée sur l'intégrité opérationnelle
La première histoire de production choisie 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 par rapport à 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 des hypothèses statiques par des données de référence en direct, des annotations visibles et une logique de repli plus sûre.
Il s'agissait de bien plus que de la correction technique.
Si un système convertit un nombre, il doit le rendre visible. S'il utilise un taux de référence, il doit le dire. S'il a recours à un repli, ce comportement doit être explicite. Une bonne gouvernance signifie que le système est honnête quant à sa propre logique.
L'histoire a été mise en œuvre, testée et validée dans un environnement réel plutôt que traitée comme achevée sur la seule base de la génération de code.
La validation a révélé un problème de sécurité en direct
Lors de la validation de la version, nous avons découvert qu'un chemin de Paramètres accessible au public exposait plus d'informations que prévu. Après un examen plus approfondi, le problème semblait impliquer un modèle 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 que la même catégorie de problème soit moins susceptible de se reproduire. Cet épisode a démontré quelque chose d'important sur la livraison encadrée. Lorsque les équipes valident soigneusement par rapport au comportement réel, des problèmes apparaissent que des flux de travail plus rapides mais plus relâchés pourraient manquer entièrement.
La leçon n'était pas que l'IA ait « fait 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 d'une validation de bout en bout.
Ce type de travail produit rarement des titres spectaculaires, mais il améliore concrètement la fiabilité.
C'est le point le plus large. La qualité sérieuse d'un logiciel 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
Tout au long de la session, l'agent d'IA pouvait analyser, concevoir, implémenter, 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 produit assisté par l'IA doit 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écouvert et résolu un problème en production, et fait avancer le MVP plus large selon un parcours structuré plus clair.
Mais le résultat le plus important était conceptuel.
L'IA n'a pas remplacé la gouvernance produit.
Elle a rendu possible une gouvernance produit disciplinée à une vitesse bien plus élevée.
C'est une histoire bien plus durable qu'un simple 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 crée suffisamment de preuves pour faire confiance à ce qui est construit. C'est là que vous exigez des preuves avant de faire confiance à ce qu'ils ont fait. Gouvernez-vous votre livraison produit aujourd'hui ? Découvrez Ceetrix.
Je vous tiendrai informé au fur et à mesure.