Ce qui change quand votre équipe de développement est une IA

Presque tout ce qui s'écrit sur le développement avec l'IA porte sur la première heure : la démonstration, l'échafaudage, la fonction apparue en dix minutes. Très peu porte sur le neuvième mois, quand la base de code est grande, que plusieurs changements sont en vol en même temps et que les défaillances intéressantes ne sont plus des erreurs de syntaxe.

Ceci est une note du neuvième mois.

Les décisions écrites sont devenues la vraie contrainte

Une équipe d'ingénierie humaine porte une grande quantité de contexte partagé qui n'est jamais écrite nulle part. Tout le monde connaît la règle de multi-location, la raison pour laquelle l'ancienne approche a été abandonnée, quel module est un champ de mines.

Une équipe d'IA n'a rien de tout cela d'une session à l'autre. Alors chaque décision qui compte doit exister comme document durable et retrouvable, sans quoi elle n'existe pas.

En pratique, cela impose une stratification stricte. Chaque fonctionnalité a une spécification fonctionnelle (ce qu'elle fait pour l'utilisateur), une conception technique (schéma, points de terminaison, architecture) et un fichier d'épopée (récits et statut). Les décisions d'architecture transversales ont leur propre registre numéroté : pourquoi la plateforme s'adapte au secteur au lieu d'utiliser des gabarits, pourquoi les modes de fonctionnement de l'IA ont la forme qu'ils ont, pourquoi le site marketing est un export statique. Un fichier d'amorçage à la racine du dépôt aiguille les types de travail vers leurs lectures obligatoires, si bien qu'une tâche touchant l'authentification tire automatiquement le modèle de menaces.

Ce qui m'a surpris : ce n'est pas un surcoût payé au bénéfice de l'IA. C'est la discipline documentaire que toute équipe d'ingénierie dit vouloir et que peu tiennent, rendue non facultative parce que l'alternative est immédiatement visible. Quand la documentation dérive, la session suivante construit la mauvaise chose le jour même, pas dans six mois à l'arrivée d'une nouvelle recrue.

Un état consigné n'est pas une preuve

Le mode de défaillance que je n'avais pas anticipé, et celui qui a coûté le plus de temps, c'est la confiance accordée à un statut qui s'est révélé être une description d'intention.

Un ticket fermé signifie que quelqu'un a décidé qu'il était terminé. Une compilation au vert signifie que les travaux qui se sont exécutés sont passés. Ni l'un ni l'autre ne prouve que la chose fonctionne. Au cours d'une journée particulièrement instructive, cinq défauts ont été trouvés dans des fonctionnalités dont les tickets étaient fermés et les chaînes au vert. Dans chaque cas, le registre était exact sur ce qui s'était passé et muet sur ce qui ne s'était pas passé.

Les pièges se répètent et valent bien au-delà du développement avec IA :

• Une suite de tests qui ne trouve aucun test rapporte un succès. Un filtre avec une faute de frappe dans le chemin aussi. Le vert sur un ensemble vide est identique au vert sur un ensemble qui passe, sauf si vous vérifiez le compte.
• Une chaîne à filtres de chemin saute les suites que votre changement n'a pas touchées. Une exécution qui rapporte « succès » sur seize travaux peut ne rien prouver sur le changement devant vous.
• Une compilation peut passer sur une machine aux dépendances périmées, puis échouer pour tous les autres.

La correction est une règle, pas davantage de vigilance : vérifiez contre l'artefact, pas contre le registre. Lisez le code, comptez les assertions qui se sont exécutées, chargez la page. C'est aujourd'hui le premier réflexe et non le dernier recours, et c'est la pratique que je transplanterais dans n'importe quelle équipe, avec IA ou sans.

Le parallélisme demande de l'isolation, pas de la politesse

Plusieurs sessions d'IA travaillent en même temps sur ce dépôt. Elles partagent un seul répertoire git, ce qui veut dire que les références de branche, les remises et l'état distant leur sont communs : les arbres de travail isolent les fichiers, jamais les références.

Sans isolation dure, trois choses arrivent, et les trois sont arrivées : deux sessions construisent la même chose indépendamment, une session pousse sur la branche d'une autre, et une session range du travail en cours qui appartenait à quelqu'un d'autre.

Les règles qui ont réglé cela n'ont rien de glorieux. Chaque session travaille dans son propre arbre de travail créé depuis la branche principale partagée. Une branche a exactement un propriétaire ; on ne pousse jamais sur une branche qu'on n'a pas créée. On ne touche jamais à un état partagé qu'on n'a pas créé : la remise de quelqu'un d'autre n'est pas à vous de la nettoyer. Et le nettoyage se fait au début d'une session et non à la fin, parce qu'une session ne peut pas supprimer l'arbre de travail dans lequel elle s'exécute ; la consigne de ranger après coup a été silencieusement impossible pendant un an, et c'est pourquoi personne ne l'avait jamais appliquée.

Si cela ressemble davantage à la description d'un système distribué qu'à celle d'une équipe, c'est précisément le point. La coordination entre agents est un problème d'ingénierie avec des solutions d'ingénierie, pas un problème de communication avec des solutions culturelles.

Les tests ont changé de métier

Avec des développeurs humains, les tests attrapent les régressions. Avec des développeurs IA, les tests sont la manière dont l'intention est transmise. Une spécification dit ce qui devrait se passer ; un test l'affirme sous une forme qu'on ne peut pas mal lire, qui ne dérive pas, et qui échoue bruyamment quand un changement ultérieur la contredit.

Cela change ce qui vaut la peine d'être testé. Les tests de plus grande valeur ici ne sont pas ceux qui couvrent le plus de lignes, mais ceux qui encodent une règle à ne jamais violer et dont la violation serait silencieuse : qu'aucune requête ne puisse sortir du périmètre de son client, qu'une permission ne puisse être élargie par un chemin de code, qu'un enregistrement d'audit existe pour chaque mutation. Ceux-là portent la structure. Un test qui vérifie qu'une fonction utilitaire formate une date, non.

Le lien avec le produit

C'est ici que cela cesse d'être une histoire de processus.

Tout ce qui précède décrit ce dont un système a besoin pour qu'une IA puisse y travailler sans danger : un modèle de données sans ambiguïté, des décisions consignées sous forme lisible par une machine, un état vérifiable plutôt que supposé, des permissions qui tiennent sans compter sur la bonne conduite, une piste d'audit qui dit qui a fait quoi, et un moyen d'annuler une erreur.

C'est aussi, exactement, la liste de ce dont une plateforme d'entreprise a besoin pour qu'une IA puisse l'exploiter sans danger pour le compte d'un client.

Ce qui veut dire que construire Cyril de cette façon n'a été ni une coquetterie ni une économie. Cela a été le test le plus exigeant possible de la promesse centrale du produit. Chaque fois que le processus de développement a eu besoin d'une garantie nouvelle pour rester sûr, cette même garantie manquait à la plateforme. Un journal d'audit au lieu de plusieurs. Un modèle de permissions dont l'acteur automatique hérite au lieu de le contourner. Une voie de retour arrière qui existe parce que le schéma la porte, et non parce que quelqu'un a pensé à ajouter un bouton d'annulation.

Je n'avais pas prévu cette symétrie. Je soutiendrais aujourd'hui que ce n'est pas une coïncidence : le logiciel exploitable par des agents et le logiciel constructible par des agents sont la même catégorie de chose, et si vous construisez le premier, le construire de la seconde manière est le test honnête le moins cher que vous trouverez.

Ce que je dirais à quelqu'un qui commence

• Écrivez la décision au moment où vous la prenez, à l'endroit où la session suivante regardera. Une décision non documentée sera rejugée, et probablement inversée.
• Ne faites jamais confiance à un champ de statut. Confirmez contre l'artefact. Supposez que chaque feu vert répond à une question plus étroite que celle que vous avez posée.
• Isolez le travail parallèle au niveau de l'outil. Les règles qui reposent sur la politesse entre agents échouent à la première collision.
• Dépensez votre budget de tests sur les invariants qui cèdent en silence, pas sur le pourcentage de couverture.
• Relisez le diff, pas le résumé. Le résumé est écrit par le système même qui a écrit le code, et il décrit ce qu'il avait l'intention de faire.

Cyril est en phase de pré-lancement. Son mode Agentique — celui où vous confiez un objectif entier — est à venir et non livré ; ce qui existe aujourd'hui, c'est la plateforme et un assistant IA qui planifie, montre son plan et agit là où vous pouvez regarder. Cette distinction compte pour moi plus qu'elle ne compterait pour un service marketing, parce que tout l'argument ci-dessus soutient que l'écart entre ce qu'un système affirme et ce qu'il peut prouver est l'endroit où vivent les ennuis.

Questions fréquentes

Une IA écrit-elle vraiment tout le code ?

L'implémentation, les tests et la documentation sont écrits par l'IA. La direction produit, la priorisation, l'approbation et la relecture sont humaines. La division qui fonctionne, c'est que l'IA possède le comment et qu'une personne possède le quoi et le si.

Est-ce plus rapide qu'une équipe humaine ?

Nettement, au moment d'écrire le code — et cela se révèle la variable la moins intéressante. La limite est la capacité de relecture et de vérification, qui est humaine ; les pratiques qui rendent la vérification rapide comptent donc plus que le volume brut produit.

Qu'est-ce qui casse le plus souvent ?

La confiance dans l'état consigné. Pas du mauvais code : une confiance erronée sur le fait que le code existant fonctionne, à partir d'un champ de statut exact sur l'intention et muet sur le résultat.

Le recommanderiez-vous à une autre équipe ?

Les pratiques, sans réserve, que vous utilisiez l'IA ou non : des décisions écrites et durables, la vérification contre les artefacts, une isolation dure du travail parallèle, et les tests comme encodage de l'intention. Le modèle d'effectif est une autre question et dépend de la capacité de relecture dont vous disposez, car c'est là la vraie contrainte.

---

Si vous voulez être parmi les premiers à utiliser Cyril, inscrivez-vous sur la liste d'attente.