Où va le travail quand le code s'écrit tout seul ?

La plupart des descriptions de l'impact de l'IA sur le développement logiciel ne portent pas sur le développement logiciel lui-même, mais sur la programmation. Or, les deux sont différents, et cette distinction est aujourd'hui essentielle pour un responsable technologique.

Le codage est l'étape où l'intention se concrétise. Le cycle de vie du développement logiciel (SDLC), ou cycle de vie du développement logiciel, englobe tout ce qui l'entoure. Il comprend la phase de découverte qui transforme un problème métier flou en un problème concret. Il comprend la phase de spécification qui transforme ce problème concret en un code exploitable par les ingénieurs. Il comprend les phases d'intégration, de revue et de validation qui transforment le code développé en code déployable. Et il comprend les phases d'exploitation, de surveillance et de retour d'information qui transforment le code déployé en un nouveau problème à résoudre. Le codage a toujours été une étape parmi d'autres. Si nous avons fini par l'associer à l'ensemble, c'est parce que, pendant quarante ans, c'est là que résidait le coût.

La situation a évolué. Pour une équipe dirigeante, la question cruciale n'est plus de savoir si l'IA code suffisamment bien. Dans les contextes où elle est opérationnelle, la réponse est clairement oui. Il s'agit plutôt de savoir à quoi ressemblera le cycle de vie du développement logiciel (SDLC) lorsque l'étape la plus coûteuse cessera de l'être.

The shape of the lifecycle is not the shape of the ceremonies

Avant d'aborder les changements, il est important de préciser ce qui change. L'expression « cycle de vie du développement logiciel » en est venue à désigner plusieurs choses différentes simultanément, et les confondre conduit à une réflexion confuse.

Au sens strict, le cycle de vie du développement logiciel (SDLC) est une succession de transformations de valeur. Une question devient un cahier des charges. Un cahier des charges devient une spécification. Une spécification devient un système fonctionnel. Un système fonctionnel est déployé. Un déploiement génère des données de télémétrie, et les données de télémétrie suscitent une nouvelle question. Chaque étape représente un travail concret. Cela consomme du temps, du discernement et souvent des ressources politiques.

Au sens large, le terme « cycle de vie du développement logiciel » désigne aujourd'hui l'ensemble des cérémonies qui entourent ces transformations : réunions quotidiennes, séances d'amélioration, revues de sprint, comités consultatifs sur le changement, analyses post-incident. Il ne s'agit pas du cycle de vie lui-même, mais d'un cadre mis en place pour le gérer, et ce cadre est souvent confondu avec le bâtiment lui-même.

Cette distinction est importante car l'IA agit très différemment sur chaque aspect. Elle réduit considérablement le coût de plusieurs transformations. Elle laisse les cérémonies plus ou moins intactes. De nombreuses organisations ont désormais des cérémonies qui consomment plus de temps que le travail qu'elles étaient censées coordonner. Il s'agit d'une sorte de dissonance opérationnelle qui se résoudra d'elle-même, d'une manière ou d'une autre, dans les deux à trois prochaines années.

What collapses, what survives, what emerges

Si l'on applique l'effet de l'IA aux transformations plutôt qu'aux cérémonies, trois choses deviennent visibles.

Quelques étapes s'effondrent. Traduire une spécification claire en code source se fait désormais en quelques minutes, et non plus en quelques semaines. Rédiger une première ébauche d'une suite de tests. Générer le code de base pour un nouveau service. Produire des scripts de migration. Concevoir des clients API à partir de schémas amont. Ce sont toujours de véritables activités d'ingénierie, mais leur coût unitaire a été réduit d'un facteur cent, voire deux. Il en va de même pour le coût de production des artefacts associés au code : journaux de modifications, notes de version, ébauches de manuels d'exploitation, infrastructure en tant que code, documentation reflétant fidèlement le code. Aucun de ces éléments n'était le plus important dans le développement logiciel ; c'était simplement le plus laborieux.

Certaines étapes restent globalement inchangées, et il est important d'en connaître les raisons. Négocier entre deux responsables produit ayant des conceptions incompatibles d'une fonctionnalité ne relève pas de la prédiction de jetons. Déterminer si un organisme de réglementation acceptera une interprétation particulière d'une clause de résidence des données ne relève pas de la prédiction de jetons. Interpréter les expressions faciales d'un client lors d'un entretien de découverte ne relève pas de la prédiction de jetons. Les phases du cycle de vie du développement logiciel (SDLC) impliquant une intention adverse, une ambiguïté irréductible ou un jugement social fonctionnent plus ou moins comme auparavant. Et cela continuera.

La catégorie la plus intéressante concerne les étapes qui émergent. Il s'agit d'un travail qui n'avait pas de nom il y a quelques années, car son coût était prohibitif. Évaluation continue des résultats du modèle par rapport aux données réelles. Maintenance de spécifications structurées et exécutables. Capture du contexte décisionnel dans un format exploitable par l'automatisation en aval. Mise en place délibérée de boucles de rétroaction afin que la télémétrie pilote les spécifications, et ne se contente pas de les informer. Ces idées ont toujours été pertinentes. Elles sont désormais abordables.

The constraint moves upstream

Lorsque vous combinez ces trois mouvements, un schéma clair se dessine. Le goulot d'étranglement du cycle de vie s'est déplacé en amont, du clavier vers la conversation. L'étape coûteuse ne consiste plus à transformer une spécification en code, mais à produire une spécification suffisamment bonne pour que le code résultant soit le code attendu.

Pour bien comprendre le contenu d'une spécification, il est utile de la considérer comme un ensemble de décisions. Un système opérationnel, d'un certain point de vue, est une longue suite de décisions prises à un moment donné. Qu'est-ce qui constitue une commande valide ? Quels états clients autorisent quelles transitions ? Que doit faire le système lorsqu'un service en amont est dégradé mais pas hors service ? La plupart de ces décisions sont définies par trois ou quatre personnes. Certaines sont inscrites dans le code sous forme de logique conditionnelle ; autrement dit, elles sont des vestiges du moment où elles ont été écrites et sont difficiles à retrouver ultérieurement. Quelques-unes sont consignées dans des documents de politique que personne ne lit.

Le travail effectué en amont ne consiste plus principalement à spécifier les fonctionnalités. Il s'agit plutôt de faire émerger ces décisions, de les nommer et de les formaliser avec suffisamment de précision pour que l'automatisation en aval puisse les exploiter sans avoir à les redéfinir systématiquement. Les équipes qui réussissent à tirer pleinement parti de l'IA dans le cycle de vie cessent généralement de débattre des fonctionnalités à développer et commencent à se concentrer sur les décisions que le système en développement est censé prendre.

Cela pourrait faire penser à un retour à l'ère du développement en cascade, mais il n'en est rien. Les spécifications qui fonctionnent dans ce nouveau contexte ne sont plus des documents de deux cents pages rédigés avant même d'écrire la moindre ligne de code. Ce sont des artefacts plus courts et structurés : quelques paragraphes, un compte rendu des décisions prises, un ensemble d'exemples concrets pouvant être révisés en boucle sur le logiciel fonctionnel. La différence réside dans le fait que la spécification est désormais au cœur du travail des développeurs, et que le code n'en est, en première approximation, que le résultat compilé.

Quiconque a observé une équipe d'ingénieurs chevronnés travailler avec des outils d'IA reconnaîtra ce schéma. L'ingénieur senior passe très peu de temps à saisir du code. Il consacre son temps à analyser le problème, à définir les contraintes, à identifier les modes de défaillance et à examiner les différences. Il s'attaque plus rapidement au cœur du problème, car les fonctionnalités de base ne sont plus le principal poste de dépense. Ce changement peut paraître minime de l'extérieur, mais il est structurellement considérable.

What this means for where to invest

Pour un responsable exécutif, la question pratique est de savoir quoi financer. La réponse honnête est : pas davantage de capacités de développement. Les domaines où chaque euro investi génère aujourd’hui un retour sur investissement disproportionné sont peu attrayants, et plusieurs d’entre eux ne relèvent pas du budget d’ingénierie traditionnel.

La première difficulté réside dans la capacité à formaliser les décisions. Il s'agit de consigner par écrit les décisions qu'un système est censé prendre, sous une forme suffisamment précise pour permettre leur vérification. Dans la plupart des organisations, ce travail est actuellement réalisé oralement, lors de réunions, et est vite oublié. Les décisions sont redéfinies à chaque arrivée d'un nouvel ingénieur dans l'équipe, avec pour conséquence prévisible une lente dérive, qui passe inaperçue jusqu'à ce que le système commette un dysfonctionnement embarrassant en production. Considérer les décisions comme des artefacts, dotés de responsables et d'un cycle de vie, relève davantage de la gestion documentaire que de l'ingénierie. Les bénéfices sont quasi immédiats.

Le second élément est l'infrastructure d'évaluation. Il s'agit des systèmes, certes peu performants, qui permettent à une équipe de vérifier en permanence si son système fonctionne comme prévu. Des jeux de données de référence. Des suites de tests de régression capables de résister au trafic de production. La rigueur opérationnelle nécessaire à leur gestion. Les organisations qui ont investi dans ce domaine se démarquent nettement de la concurrence, et il devient de plus en plus difficile de le dissimuler.

Le troisième élément est la mémoire institutionnelle qui sous-tend les décisions. Le « pourquoi » du « quoi ». Le premier investissement permet de saisir ce que décide le système. Celui-ci permet de saisir pourquoi l'équipe a choisi de le concevoir ainsi. Les systèmes d'IA excellent dans l'exécution contextuelle, mais sont terriblement incapables de retrouver un contexte non documenté. Les entreprises qui consignent les décisions, les contraintes et les compromis sous une forme lisible par machine connaîtront une croissance exponentielle. Celles qui laissent ces informations entre les mains de trois cadres supérieurs réaliseront, le jour de leur départ, l'ampleur de leur perte.

Il ne s'agit pas d'achats de modèles ni de licences de plateforme. Ce sont des investissements organisationnels, qui ressemblent davantage à un renforcement progressif des capacités qu'à un lancement.

What this means for how to build it

Pour un responsable technique, la question correspondante est celle de la mise en œuvre. Quelques principes se dégagent des équipes qui réussissent.

Considérez le cycle de vie comme un état, et non comme une procédure. Un cycle de vie de développement logiciel (SDLC) moderne s'apparente davantage à un flux de travail continu avec un état persistant : l'étape à laquelle se trouve chaque tâche, les artefacts qui y sont associés et les étapes franchies. L'état peut être inspecté, interrogé et analysé par d'autres logiciels, contrairement à une procédure.

Considérez les agents comme des services, et non comme des assistants. L'unité utile n'est pas une fenêtre de chat rattachée à un développeur. Il s'agit d'un service bien défini et instrumenté qui effectue une transformation spécifique au cours du cycle de vie : rédaction d'un cahier des charges à partir d'un compte rendu de découverte, génération d'un plan de test à partir d'un cahier des charges, production d'un manuel d'exploitation à partir d'une chronologie d'incidents. Les services possèdent des entrées, des sorties, des données de télémétrie et des SLA. Les assistants, quant à eux, ont des humeurs.

Considérez l'évaluation comme un élément essentiel, et non comme une simple formalité. La discipline la plus difficile à instaurer est de prendre l'habitude de se demander, à chaque nouvelle automatisation : « Comment saurons-nous quand elle cessera de fonctionner ? » Les équipes qui répondent correctement à cette question se dotent d'une infrastructure comparable à une petite plateforme d'observabilité interne. Celles qui y répondent mal produisent des résultats qui semblent prometteurs, mais sont incapables de détecter les dérives.

What this looks like when you actually build it

Ces principes sont plus faciles à formuler qu'à appliquer, il est donc utile de décrire leur application concrète. Nous avons consacré l'année écoulée à la construction d'un tel système. Certains schémas ne sont pas évidents tant qu'on n'a pas commis une ou deux erreurs.

Premièrement, les étapes doivent être des énumérations dans une base de données, et non des titres dans un document. Chaque tâche sur notre plateforme suit une séquence d'étapes définie, de la définition du périmètre et de la planification à la mise en œuvre et à l'exploitation. Ces étapes sont des valeurs de premier ordre dans le schéma, avec des contraintes sur les transitions autorisées. Ainsi, la question « Où en est ce travail ? » se pose sous forme de requête, et non de réunion. Cela signifie également que tout agent du système peut connaître l'état d'un programme sans intervention humaine, ce qui peut paraître anodin, mais qui fait toute la différence entre l'automatisation et le théâtre.

Deuxièmement, chaque agent est un service doté d'un manifeste. Chacun déclare ses capacités, ses outils, ses dépendances et les points de terminaison qu'il expose. Les nouveaux agents ne sont pas ajoutés a posteriori ; ils sont enregistrés. Cela représente plus de travail initial qu'une intégration ponctuelle, mais c'est la seule structure qui perdure la deuxième année, lorsque vous avez huit agents au lieu de trois et que vous devez toujours savoir qui est responsable de quoi.

Troisièmement, chaque appel de modèle transite par un point de contrôle unique. Non seulement les données sont consignées pour le débogage, mais elles sont acheminées vers une fonction qui enregistre l'invite, la réponse, le modèle, le coût et la latence, puis les intègre à un pipeline d'évaluation. La raison, aussi peu attrayante soit-elle, est essentielle. Le seul moyen de savoir si un agent progresse ou régresse au fil du temps est de disposer d'un historique de son comportement pour comparaison. Les équipes qui négligent cette étape découvrent généralement, au bout de six mois, qu'elles possèdent une multitude d'agents sans pouvoir identifier ceux dont les performances se dégradent.

Rien de tout cela n'est exotique. Il s'agit de l'application de méthodes utilisées par les équipes d'ingénierie depuis des décennies, à une charge de travail qui n'existait pas il y a cinq ans. Le plus intéressant, c'est que la rigueur requise est pour la plupart ancienne, tandis que les bénéfices sont pour la plupart inédits.

A note on overshoot

Ce genre de cycles connaît des dépassements. Il y aura une période, et nous y sommes sans doute déjà, durant laquelle la valeur de l'IA dans le cycle de vie du développement logiciel sera surestimée, les modes de défaillance sous-estimés et la maturité opérationnelle requise pour déployer ces systèmes en toute sécurité considérée comme un détail. La plupart des organisations achèteront trop, intégreront trop rapidement et découvriront que le coût de la maintenance d'un parc d'agents ingérable est comparable à celui d'un parc de microservices ingérable, c'est-à-dire considérable.

Le mode de défaillance sous-jacent est plus intéressant que le mode évident. La plupart des organisations continuent d'utiliser leur ancien cycle de vie de développement logiciel (SDLC), auquel l'IA a été greffée. Les équipes qui se démarqueront seront celles qui utiliseront un SDLC conçu autour de l'IA. La distinction semble purement sémantique jusqu'à ce qu'on ait expérimenté les deux approches. L'une est une version plus rapide de ce qu'on faisait auparavant. L'autre est fondamentalement différente.

Les équipes qui, au cours des trois prochaines années, bénéficieront d'un avantage structurel ne seront pas celles qui se seront adaptées le plus rapidement. Ce seront celles qui auront compris, avant leurs concurrents, que le travail a évolué. Les questions intéressantes se situent en amont. Le travail réside dans les décisions, l'évaluation et la mémorisation. Le code, au final, est la partie la plus facile.