Méthode CIV : comment nous construisons du logiciel avec l'IA sans perdre le contrôle

Bientôt deux ans que nous construisons ShephERP avec l'intelligence artificielle écrivant la majeure partie du code. En cours de route, nous avons appris que le goulot d'étranglement n'était jamais le modèle. C'était tout le reste. Nous avons donné un nom à cette façon de travailler : méthode CIV.

Le problème que personne ne raconte

La promesse de l'IA en développement est réelle : un agent écrit en vingt minutes ce qui coûtait autrefois deux jours. Ce que presque personne ne dit, c'est ce qui arrive la sixième semaine.

Un modèle de langage est un exécuteur étonnamment rapide et étonnamment littéral. Sans contexte, il invente : si vous ne lui avez pas dit que les membres avec la cotisation impayée perdent la réduction, il l'appliquera, parce que c'est ce qui semble le plus raisonnable. Et sans limites, il casse : il corrigera le bug que vous lui avez demandé et, au passage, modifiera quatre autres choses que personne ne lui avait réclamées.

Le résultat est un projet qui démarre à une vitesse spectaculaire et se bloque après deux mois, avec des milliers de lignes que personne n'a vérifiées et une équipe qui ne ose plus rien toucher. Multiplier la vitesse d'écrire du code sans multiplier la capacité de le vérifier n'est pas de la productivité : c'est de la dette à la vitesse de la machine.

On ne développe pas plus vite avec de meilleurs prompts, mais avec un meilleur contexte et de meilleures limites.

Trois piliers : Contexte, Itération, Vérification

CIV sont les trois choses à mettre autour de l'agent. Ce ne sont pas des phases parcourues l'une après l'autre : elles fonctionnent toujours en même temps, et si vous en retirez une, le système s'effondre.

C — Contexte : la documentation est le code source

Dans un projet CIV, le dossier docs/ existe avant le code. À l'intérieur, il y a tout : le business du client, son vocabulaire exact, les règles numérotées une à une, les décisions techniques avec leur date et leurs alternatives écartées, et le compte-rendu de chaque réunion écrit le même jour.

Nous ne documentons pas pour un audit ni pour faire belle figure. Nous documentons parce que c'est littéralement l'entrée de l'exécuteur. Un compte-rendu de réunion est l'actif le plus précieux qui existe pour une IA, parce qu'il contient la seule chose qu'aucun dépôt ne peut déduire : l'intention. Le code dit ce que fait le système ; seul le compte-rendu dit pourquoi c'est fait ainsi et ce qui casse si vous le modifiez.

De là naît notre premier principe, qui est aussi le plus inconfortable : si ce n'est pas écrit, ça n'existe pas. Une décision qui ne vit que dans un appel n'est pas une décision, c'est une rumeur que l'agent ne peut pas respecter.

I — Itération : un ticket est un prompt

Le travail descend sur trois niveaux —épic (un trimestre), jalon (ce qui peut être montré en deux semaines) et tâche (ce qui tient en une séance)— et atterrit dans des tickets écrits pour quelqu'un qui n'était pas à la conversation, ne se souvient de rien et ne va pas poser de questions.

Cela change complètement la façon dont on écrit un ticket. Plus de «régler le filtre». Des pas avec des données réelles, l'URL exacte, une capture annotée avec une flèche sur ce qui ne va pas, la requête et la réponse collées, le résultat attendu, les critères d'acceptation en checklist et —la ligne qui coûte le moins cher— ce qu'il NE faut PAS toucher.

Nous l'appelons Definition of Ready pour l'IA, et il a une règle d'or : si l'agent doit poser une question pour pouvoir commencer, le ticket était mal écrit et il retourne à celui qui l'a rédigé. Ce n'est pas de la bureaucratie. Un ticket incomplet ne s'arrête pas : il se complète tout seul, avec la supposition la plus probable du modèle. Et la supposition la plus probable n'est presque jamais la règle de business de votre client.

Chaque tâche traverse ensuite six pas toujours identiques : lire, planifier, délimiter, exécuter, vérifier et remettre. Le plus important est le deuxième : le plan est approuvé avant la première ligne de code. Corriger un plan coûte une minute ; corriger une après-midi coûte une après-midi.

V — Vérification : d'abord la barrière, puis on lâche

Ici, il convient de dissiper une confusion très courante, car de elle dépend tout le reste. Beaucoup de gens parlent de «tests unitaires, e2e et Cypress» comme si c'étaient trois choses du même type. Elles ne le sont pas : on mélange deux axes distincts. L'un est le niveau —combien de système réel vous sollicitez—, et l'autre est l'outil avec lequel vous le sollicitez. Cypress n'est pas un niveau : c'est un outil pour le niveau de bout en bout d'interface. Et «bout en bout» n'est pas non plus unique : tester l'API complète et tester l'application dans un navigateur sont des choses différentes, avec un coût et une utilité différents.

En CIV, il y a six niveaux, du moins cher au plus cher : types et style, unitaires, intégration, bout en bout d'API, bout en bout d'interface et smoke test en production. La question qui décide où va chaque test est toujours la même : quel est le plus petit morceau où cette faille peut être détectée ? Une réduction mal calculée est un test unitaire, même si vous l'avez découverte en achetant dans la boutique.

Au-dessus de tout ça, une couverture supérieure à 95 % et la règle qui la soutient : lecran de blocage. Les seuils ne font que monter. Jamais ils ne descendent, jamais «temporairement». La dette qui existait déjà est gelée avec une ligne de base et payée par paliers ; la nouvelle dette est bloquée le jour même. Et aucun bug n'est fermé tant qu'il n'a pas laissé derrière lui le test qui l'aurait détecté : aucun bug ne mourrit sans témoin.

Pourquoi ça s'amortit tout seul

Un projet normal se dégrade : chaque mois coûte plus cher pour le modifier. Un projet CIV tend vers l'inverse, et la raison est précise. Le contexte grandit, donc chaque nouvelle tâche arrive avec davantage de terrain résolu. La barrière grandit, donc chaque changement est moins risqué que le précédent. Et le coût d'intégrer quelqu'un —ou un autre agent— baisse, parce que s'intégrer est lire un dossier dans l'ordre.

Nous mesurons sept choses, mais il y en a une que presque personne ne mesure et qui dit tout : le touche-tas de ticket propre, le pourcentage de tickets que l'agent résout sans avoir à repenser. Si ce chiffre baisse, le problème n'est pas dans le modèle que vous utilisez. Il est dans votre contexte et dans la façon dont vous écrivez vos tickets.

Ce que CIV n'est pas

Ce n'est pas du vibe coding. Ce n'est pas de la couverture de vitrine —des tests qui exécutent beaucoup et ne vérifient rien—. Ce ne sont pas des documents de cérémonie que personne ne actualise, qui avec l'IA sont pires que de n'en avoir aucun, parce que l'agent les lit et les croit. Ce ne sont pas des raccourcis qui depuis six mois sont permanents. Et surtout, ce n'est pas lancer un agent sans laisse et appeler ça de l'autonomie.

CIV n'est pas née sur un tableau : elle est sortie de la construction d'un ERP complet avec l'IA, de nous tromper et de noter pourquoi. C'est ce que nous faisons tous les jours.

Contexte. Itération. Vérification. Retirez un seul des trois et ce n'est pas CIV, c'est de la chance.