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, les milliers de petits arbitrages qui font qu’un système épouse son métier. Cette réponse est en train de changer, discrètement. Dès lors que des agents savent 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 du fait de prendre cela au sérieux, 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.
L’affirmation du titre demande une nuance immédiate. « Écrire du code devient optionnel » ne veut pas dire que plus personne ne lit de code, que le code généré n’a pas d’importance, ou que la compétence d’ingénierie est obsolète. Cela veut dire quelque chose de plus étroit et de plus intéressant : pour une classe croissante de travaux, taper l’implémentation à la main est désormais un choix et non une nécessité - et les équipes devraient décider délibérément où elles font encore ce choix, au lieu de le faire partout 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 » est un 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, c’est la vérifiabilité, et c’est toute la différence.
L’intention s’empile en trois couches. En haut se tient l’intention produit : quel résultat le système existe pour produire, pour qui, mesuré comment. En dessous vivent les invariants du système : les 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 se trouvent les tests d’acceptation et les évaluations : la forme exécutable, la couche qu’un pipeline peut réellement faire tourner. Chaque couche justifie celle du dessous ; chaque couche du dessous rend vérifiable celle du dessus. Une équipe qui maintient les trois peut confier l’implémentation à un agent comme un maître d’ouvrage confie un chantier à une entreprise : sur plans, pas sur adjectifs.
Si cela vous rappelle 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, c’est ce à quoi ressemble la base de code quand cette discipline capitalise - quand les contrats, invariants et évaluations accumulés deviennent la vraie description du système, et qu’une implémentation donnée n’en est que la compilation du moment.
Le code comme produit de build
La conséquence pratique est un déplacement de ce que signifie « la source ». Dans un langage compilé, personne ne patche le binaire : on modifie la source et on recompile. Les équipes pilotées par l’intention se mettent à traiter 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 - un nouveau test d’acceptation, un invariant modifié, 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 et porteur. Ce qui change, c’est son statut : il est dérivé, et ce dont il dérive est ce dont vous débattez.
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 réellement tenir en tête. Relire le diff d’intention est faisable : quel nouveau comportement a été promis, quels invariants ont été touchés, les nouveaux tests verrouillent-ils vraiment la promesse, et y a-t-il dans le diff d’implémentation quoi que ce soit que l’intention n’explique pas ? L’attention de l’ingénieur senior monte d’un cran - 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 le jugement d’ingénierie appliqué 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 livrent plus vite que celles qui débattent de la compilation.
Là où le code écrit à la main garde l’avantage
Être honnête sur la frontière évite de transformer tout cela en idéologie. Une partie du code doit encore être écrite à la main, et les catégories sont constantes. Le cœur chaud- le moteur de tarification, l’algorithme d’appariement, le modèle de risque - 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, 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 précisément 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ù vous voulez les empreintes d’un humain sur chaque ligne. Et la couche d’intention elle-même : tests, invariants, évaluations 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 « un agent peut-il écrire cela ? » - de plus en plus, oui - mais « que perdons-nous si aucun humain ne l’écrit ? ». Là où la réponse est « rien, à condition que l’intention soit appliquée », la génération est le choix par défaut rationnel. Là où la réponse est « notre compréhension de ce qui nous fait gagner de l’argent », tapez-le vous-même.
Comment cela pourrit
La pourriture de l’intentionest le premier mode de défaillance. La couche d’intention n’est la source de vérité que tant qu’on l’entretient comme une source. Dès qu’une équipe se met à corriger le comportement directement - un correctif à chaud ici, une retouche manuelle là - sans répercuter le changement dans les tests et les invariants, l’intention commence à décrire un système qui n’existe plus. Puis la régénération suivante, fidèlement compilée depuis une intention périmée, efface les correctifs non documentés. La règle qui l’empêche est la même que celle qui garde les schémas honnêtes : les changements de comportement atterrissent d’abord comme changements d’intention, dans la même pull request, ou ils n’atterrissent pas.
Régénérer sans revérifierest le deuxième. 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 changer. Les équipes se brûlent quand elles supposent que le pipeline vert d’hier se porte garant de la régénération d’aujourd’hui. Il ne le fait pas. Chaque régénération est une nouvelle implémentation et mérite la passe de vérification complète - tests, évaluations, contrôles d’invariants - à chaque fois. Si c’est trop coûteux à exécuter à chaque régénération, le remède est de rendre la vérification moins chère, pas plus rare.
Traiter le code généré comme jetable alors qu’il est porteurest le troisième, et 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 seulement par l’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 vous 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 un responsable pour chaque composant généré exactement comme elles le feraient pour un composant écrit à la main - quelqu’un qui l’a lu, profilé, et qui peut 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 soyez honnêtes sur les endroits où les tests et le système ne sont pas d’accord. Cette é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 - délai de cycle, taux de défauts, 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 en un cœur écrit à la main et une périphérie générée, et l’attention senior, rare, se concentre sur la couche où elle capitalise : décider, 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 plus un compilateur digne de confiance faisaient simplement une meilleure affaire. L’intention, plus les agents, plus la vérification, forment en ce moment la même affaire, un niveau au-dessus. Écrire du code devient optionnel. Savoir exactement ce que le code doit faire - et pouvoir prouver qu’il le fait - devient le métier.