Demandez à une équipe ce qu’elle emporterait si l’immeuble brûlait : pendant soixante-dix ans, la réponse a été le code source. Le perdre, c’était perdre les décisions accumulées de l’entreprise, ces milliers de petits arbitrages qui font qu’un système épouse son métier. La réponse est en train de changer, discrètement. Dès lors qu’un agent sait régénérer une implémentation qui fonctionne à partir d’un énoncé précis de ce que le système doit faire, le code cesse d’être le joyau de la couronne : c’est l’énoncé qui l’est. La pratique qui découle de cette bascule, nous l’appelons intent-driven development, ou développement piloté par l’intention : la discipline qui fait de l’intention, et non du code, l’artefact que votre équipe écrit, relit, versionne et possède.
Le titre appelle une nuance immédiate. « Écrire du code devient facultatif » ne veut dire ni que plus personne ne lit de code, ni que le code généré n’a pas d’importance, ni que la compétence d’ingénierie est périmée. L’affirmation est plus étroite, et plus intéressante : pour une classe croissante de travaux, taper l’implémentation à la main est devenu un choix et non une nécessité. Reste à décider où l’on fait encore ce choix, délibérément, plutôt que partout et par habitude.
L’intention n’est pas une impression
Le mot « intention » invite aux abus : il sonne comme quelque chose qu’on pourrait satisfaire avec une raison d’être et une planche d’ambiance. En pratique, une intention capable de piloter le développement est un ensemble d’énoncés vérifiables sur le comportement, des énoncés qu’une machine ou un collègue peut confronter au système pour répondre conforme ou non conforme. « Les clients doivent avoir un parcours d’achat fluide » relève du sentiment. « Un client connu boucle son achat en trois étapes ; un paiement refusé conserve le panier et explique l’échec dans la langue du client ; aucun double débit n’est possible même si le bouton de confirmation est cliqué deux fois » est une intention. La différence tient à la vérifiabilité, et elle fait toute la différence.
L’intention s’empile en trois couches. En haut, l’intention produit : quel résultat le système existe pour produire, pour qui, mesuré comment. En dessous, les invariants du système, ces propriétés qui doivent tenir quelle que soit l’implémentation : l’argent se conserve, les pistes d’audit s’ajoutent sans se réécrire, les données personnelles restent dans le périmètre, les suppressions sont récupérables. Tout en bas, les tests d’acceptation et les jeux d’évaluation : la forme exécutable, la couche qu’un pipeline peut réellement faire tourner. Chaque couche justifie celle du dessous, et chaque couche du dessous rend vérifiable celle du dessus. Une équipe qui maintient les trois confie l’implémentation à un agent comme un maître d’ouvrage confie un chantier à une entreprise : sur plans, pas sur adjectifs.
Si cela ressemble de près à l’écriture de contrats pour les agents IA, c’est normal. Le spec-driven development, le développement piloté par la spécification, est la discipline à l’échelle de la tâche : un travail, un contrat, une boucle de vérification. Le développement piloté par l’intention est ce que devient une base de code quand cette discipline capitalise : les contrats, les invariants et les jeux d’évaluation accumulés forment la vraie description du système, et une implémentation donnée n’en est que la compilation du moment.
Le code comme produit de build
La conséquence pratique porte sur le sens du mot « source ». Dans un langage compilé, personne ne patche le binaire : on modifie la source et on recompile. Les équipes pilotées par l’intention traitent le code d’implémentation de la même façon. Quand un comportement doit changer, la première modification atterrit dans la couche d’intention, sous la forme d’un nouveau test d’acceptation, d’un invariant modifié ou d’un énoncé produit affûté, et l’implémentation est régénérée ou reprise pour le satisfaire. Le code reste lisible, relu, porteur. Ce qui change, c’est son statut : il est dérivé, et ce dont il dérive est ce dont on débat.
La revue change de cible en conséquence. Relire trois mille lignes générées à vitesse de lecture est un théâtre : le relecteur approuve ce qu’il ne peut pas tenir en tête. Relire le diff d’intention, en revanche, est faisable : quel comportement nouveau a été promis, quels invariants ont été touchés, les nouveaux tests verrouillent-ils vraiment la promesse, et le diff d’implémentation contient-il quoi que ce soit que l’intention n’explique pas ? L’attention de l’ingénieur senior monte d’un cran : elle passe de « cette boucle est-elle correcte » à « est-ce la bonne promesse, et est-elle appliquée ». Ce n’est pas une rétrogradation du jugement d’ingénierie, c’est ce jugement placé là où il paie désormais le plus.
Le code est dérivé, l’intention est la source. Les équipes qui débattent de la source avancent plus vite que celles qui débattent de la compilation.
Là où le code écrit à la main garde l’avantage
L’honnêteté sur la frontière évite de transformer tout cela en idéologie. Une partie du code doit encore s’écrire à la main, et les catégories sont constantes. Le cœur chaud d’abord, moteur de tarification, algorithme d’appariement, modèle de risque, là où chaque branche incarne une décision métier et où la compréhension du code par l’équipe est elle-même un actif. Le travail algorithmique inédit ensuite, où l’intention ne peut pas être énoncée plus précisément que l’implémentation, parce que découvrir l’implémentation est justement le travail. Les frontières critiques pour la sécurité, authentification, cryptographie, initiation de paiement, où la profondeur de la revue compte plus que la vitesse de production et où l’on veut les empreintes d’un humain sur chaque ligne. Et la couche d’intention elle-même : tests, invariants, jeux d’évaluation et schémas méritent une écriture humaine, précisément parce que tout le reste est vérifié à partir d’eux.
La question utile, pour un travail donné, n’est pas de savoir si un agent peut l’écrire, il le peut de plus en plus, mais ce que l’on perd si aucun humain ne l’écrit. Quand la réponse est « rien, à condition que l’intention soit appliquée », la génération devient le choix par défaut rationnel. Quand la réponse est « notre compréhension de ce qui nous fait gagner de l’argent », tapez-le vous-même.
Les trois modes de défaillance
La pourriture de l’intention vient en premier. La couche d’intention n’est source de vérité que tant qu’on l’entretient comme une source. Dès qu’une équipe corrige le comportement directement, un correctif à chaud ici, une retouche manuelle là, sans répercuter le changement dans les tests et les invariants, l’intention se met à décrire un système qui n’existe plus. La régénération suivante, fidèlement compilée depuis une intention périmée, efface alors les correctifs non documentés. La règle qui l’empêche est celle qui garde les schémas honnêtes : un changement de comportement atterrit d’abord comme changement d’intention, dans la même pull request, ou il n’atterrit pas.
Régénérer sans revérifier vient ensuite. La régénération n’est pas idempotente : deux exécutions à partir de la même intention produisent un code différent, aux comportements incidents différents, et tout ce que la couche d’intention ne verrouille pas est libre de bouger. Les équipes se brûlent en supposant que le pipeline vert d’hier se porte garant de la régénération d’aujourd’hui. Il ne l’est pas. Chaque régénération est une implémentation nouvelle et mérite la passe de vérification complète, tests, jeux d’évaluation et contrôles d’invariants, à chaque fois. Si c’est trop coûteux pour être exécuté à chaque régénération, il faut rendre la vérification moins chère, et non plus rare.
Traiter le code généré comme jetable alors qu’il est porteur vient en troisième, et c’est le plus subtil. Une équipe intériorise que « le code n’est qu’un produit de build » et cesse complètement de le lire : plus de revue, plus de profilage, plus de familiarité opérationnelle. Puis un incident survient à 2 heures du matin, et les personnes d’astreinte déboguent un système que personne n’a jamais lu, guidées par la seule intention qu’il était censé satisfaire. Dérivé ne veut pas dire négligeable. Le code de production exige une propriété opérationnelle quel qu’en soit l’auteur ; la couche d’intention dit ce que le système devrait faire, mais la réponse à incident, elle, se joue dans ce qu’il fait réellement. Les équipes qui gèrent bien cela désignent pour chaque composant généré un responsable, exactement comme pour un composant écrit à la main : quelqu’un qui l’a lu, profilé, et qui sait le parcourir sous pression.
Un chemin d’adoption pragmatique
Rien de tout cela n’exige une révolution, et les équipes qui en tentent une produisent en général un manifeste et aucun changement. Le chemin qui marche est incrémental. Commencez par rendre explicite l’intention du système que vous avez déjà : écrivez les invariants que vous croyez vrais, transformez le savoir tribal en tests d’acceptation, et regardez sans complaisance les endroits où les tests et le système ne disent pas la même chose. L’étape se rentabilise même si aucun agent ne touche jamais à la base de code : c’est simplement la documentation et la couverture de tests que vous vous deviez de toute façon.
Prenez ensuite un composant borné et bien compris, et faites tourner la boucle complète dessus : intention écrite et relue, implémentation générée à partir d’elle, vérification mécanique, revue humaine visant le diff d’intention. Mesurez honnêtement le délai de cycle, le taux de défauts et l’effort de revue, face à la référence écrite à la main. Étendez le long des frontières où la boucle gagne, continuez à taper là où elle perd. En quelques trimestres, la base de code se trie d’elle-même : un cœur écrit à la main, une périphérie générée, et l’attention senior, rare, concentrée sur la couche où elle capitalise, celle où l’on décide précisément et vérifiablement ce que le logiciel doit faire.
L’industrie a déjà vécu cela. Personne ne pleure l’assembleur écrit à la main : nous en avons gardé la capacité et abandonné l’habitude, parce qu’une source de plus haut niveau et un compilateur digne de confiance formaient simplement une meilleure affaire. L’intention, les agents et la vérification composent aujourd’hui la même affaire, un étage plus haut. Écrire du code devient facultatif. Savoir exactement ce que le code doit faire, et pouvoir prouver qu’il le fait, devient le métier.