Vers un manifeste agentique pour le développement logiciel

La montée des agents de codage conduit à envisager une méthodologie où la spécification devient la source de vérité et où les suites de tests servent de garde-fous. L’approche promet vitesse et itérations rapides, mais elle bute sur des zones grises bien réelles, du legacy aux ambiguïtés du langage naturel. De ce basculement pourrait naître un « manifeste agentique ».

Des limites structurantes: langage, legacy, coûts et interfaces

Edsger W. Dijkstra a soutenu que l’anglais est trop ambigu pour spécifier correctement une application logicielle. La spécification est jugée nécessaire, mais probablement insuffisante pour définir un logiciel. Ne pas connaître le code pourrait se révéler problématique lors d’un incident critique détecté en pleine nuit, même si un agent de codage pourrait corriger plus vite qu’un humain. Les approches esquissées viseraient surtout des contextes greenfield, tandis qu’une grande base de code existante limiterait vraisemblablement leur impact méthodologique, point qui reste à vérifier. Ces agents ne sont pas gratuits : les coûts devront être mesurés, même si l’auteur soupçonne qu’ils baisseront, invoquant la loi de Moore et ses dérivés. La frontière front-end/back-end devrait être retravaillée. Les clients n’accepteraient probablement pas des changements d’apparence à chaque itération ; des clients plus légers et un back-end plus important sont anticipés. Les front-ends, plus sensibles aux préférences humaines, devront conjuguer flexibilité et cohérence, un domaine jugé déjà plutôt bien maîtrisé aujourd’hui. Enfin, des aspects comme l’apparence, la sécurité, la performance et l’accessibilité restent difficiles à formaliser précisément dans une spécification et exigeront un effort humain soutenu.

Un nouveau goulot d’étranglement: les retours clients

Dans une méthodologie recentrée sur la spécification, la mise à jour de cette dernière selon les retours pourrait devenir le point de blocage. Des entretiens approfondis avec les clients pourraient être enregistrés et une IA pourrait en dériver des mises à jour de la spécification. L’usage ciblé de l’IA accélèrerait la rédaction, au point de déplacer le goulot d’étranglement vers l’obtention et la validation des retours. Des clients pourraient alors se lasser d’un tempo perçu comme trop rapide et exigeant en disponibilité.

Tests génératifs: vers une définition de l’application par la couverture

Des agents de codage pourraient produire d’imposantes suites de tests couvrant l’ensemble de l’implémentation, autorisant des reconstructions à chaque itération tant que les tests passent. Si des tests unitaires, d’intégration et de bout en bout couvraient la totalité de la spécification, ils pourraient constituer la définition même de l’application. Le codage agentique est présenté comme susceptible de réaliser l’ambition du développement piloté par les tests. L’auteur ne voit pas de raison de se priver d’une telle génération de tests et s’interroge sur l’intérêt de s’attacher aux nouvelles implémentations en présence d’une couverture complète. Une suite exhaustive faciliterait par ailleurs le passage du développement à la maintenance, et un agent ne rechignerait pas à en écrire davantage.

Quatre voies d’implémentation avec des agents non déterministes

Plusieurs stratégies d’implémentation sont envisagées après mise à jour de la spécification. La première consiste à jeter chaque version et à reconstruire depuis zéro, une option jugée risquée en raison du caractère non déterministe des agents mais potentiellement viable. La deuxième applique la nouvelle spécification à l’implémentation précédente en la mettant à jour de façon incrémentale, une approche proche des pratiques actuelles. Une voie hybride demande à l’agent d’examiner l’existant, de lire la nouvelle spécification et de redessiner l’application à la lumière de ses apprentissages et des retours. Enfin, il est proposé de tester simultanément ces voies et de retenir la préférée, le recours massif aux agents étant assimilé à un effectif illimité, dans une logique de « concours » pour dégager la meilleure solution.

Processus centré sur la spécification et gouvernance du document

Deux variantes de processus sont proposées. La première enchaîne spécification, validation client, construction par agent, retours, mise à jour de la spécification et itérations jusqu’à satisfaction, avec validation explicite par le client de la spécification et de l’implémentation. La seconde retire au client la visibilité sur la spécification et ne lui présente qu’une application fonctionnelle, tout en considérant la spécification, et non le code, comme source de vérité. L’approche mêle une exigence de justesse de la spécification (proche de Waterfall) et des itérations avec retours (principe d’Agile), et rejoint le développement basé sur la spécification. Elle heurte toutefois une valeur du manifeste Agile (« Logiciel fonctionnel plutôt que documentation complète »), dont la pertinence est questionnée si le logiciel peut être généré rapidement, au point d’estomper la frontière entre exécutable et documentation. Si la spécification devient l’objet d’itération, elle peut être vue comme le code source tandis que le code généré s’apparente à du code machine. Cette centralité suggère un contrôle de version de la spécification, avec demandes de tirage et revues, et interroge la nécessité d’un contrôle de version du code si chaque itération réimplémente l’application.

Agile, Waterfall et la thèse d’un basculement rendu possible par les agents

Le déroulé Waterfall reposait sur une spécification exhaustive transmise au développement, puis au test, avant livraison, avec des changements coûteux et formalisés. Jugé inefficace, il a été supplanté par l’essor d’Agile, porté par un manifeste coécrit par des figures du logiciel, popularisant Scrum et d’autres cadres, tout en nourrissant d’innombrables débats jusqu’à faire de Waterfall un héritage à abandonner. L’auteur avance que l’implémentation, devenue facile, ne constitue plus le goulot d’étranglement, ce qui imposerait de revoir le processus en profondeur. Il esquisse un possible retour de Waterfall si la spécification définit l’application et si un agent peut générer le code en quelques heures ou jours, en déplaçant l’itération sur la spécification, selon une logique d’Agile appliquée au document. Cette thèse est posée dans un contexte d’incertitudes sur l’avenir d’Agile, de la puissance supposée des agents de codage et d’une transformation perçue comme majeure, au point de questionner le rôle du développeur humain et d’imaginer l’émergence d’un « manifeste agentique ».