SDLC agentique : construire plus vite la mauvaise chose n'a jamais été aussi facile

Distinguer la productivité ressentie de la performance du système

Deux études publiées avant la généralisation des plateformes agentiques rappellent qu'une impression de productivité ne garantit pas une meilleure performance d'ensemble. Le rapport DORA 2024 de Google associe une hausse de 25 % de l'adoption de l'IA à une baisse estimée de 1,5 % du débit de livraison et de 7,2 % de la stabilité des livraisons, alors que la productivité individuelle déclarée par les répondants progresse. En juillet 2025, METR a publié un essai contrôlé randomisé mené auprès de 16 développeurs open source expérimentés, sur 246 tâches réelles. Avec les outils d'IA du premier semestre 2025, ils mettaient en moyenne 19 % de temps supplémentaire, tout en estimant après coup avoir gagné environ 20 %.

Ces résultats portent sur des contextes précis et des outils antérieurs au SDLC agentique actuel, et ils n'en constituent pas une mesure. L'écart évolue d'ailleurs avec les outils et les pratiques, puisque dans son rapport 2025, DORA associe désormais une adoption plus forte de l'IA à une hausse du débit de livraison, mais toujours à davantage d'instabilité. Ces études montrent seulement qu'un écart peut exister entre la perception individuelle et la performance réelle du système, et qu'un dispositif fondé sur le temps gagné déclaré ou sur l'usage des outils ne permet pas de le voir.

Mesurer la chaîne entière, parce que tous les rôles changent

Dans un SDLC agentique, des agents interviennent à chaque étape. Le product manager s'appuie sur eux pour analyser des retours utilisateurs et rédiger des spécifications, le designer produit des prototypes fonctionnels en quelques heures, l'architecture et la sécurité font vérifier automatiquement la conformité d'une conception ou d'un changement, les développeurs et les testeurs délèguent une partie du code et des tests, et les ops confient aux agents l'analyse des incidents ou les montées de version. Chaque rôle déplace son travail vers le cadrage, la revue et l'arbitrage.

Lorsque le temps actif diminue à plusieurs endroits à la fois, le délai restant se concentre dans les attentes entre rôles, qu'il s'agisse d'une validation d'architecture, d'une revue de sécurité ou d'un arbitrage produit. Une mesure centrée sur le développement passe alors à côté à la fois des gains et des nouveaux goulots.

Décider ce que l'on fera du temps libéré avant de le libérer

Le gain de productivité n'a de valeur que si l'organisation décide ce qu'elle fera du temps libéré. Un gain de 20, 30 ou 50 % qui n'est associé à aucun usage explicite tend à être absorbé dans le fonctionnement courant, en réunions, en sollicitations nouvelles ou en travail moins prioritaire. C'est l'une des raisons pour lesquelles des gains de temps observés localement restent difficiles à traduire en résultat économique mesurable.

Prenons une squad qui passe sur une plateforme de delivery agentique, avec ses rôles cœur, product manager, designer, développeurs, testeurs et ops, et l'architecture et la sécurité qui l'accompagnent. Avant le déploiement, elle peut décider que la capacité libérée servira à tester davantage d'hypothèses produit, à accélérer un parcours utilisateur jugé stratégique, à résorber une dette technique qui freine les évolutions ou à traiter des demandes jusque-là jugées trop petites pour être rentables. Cette décision ne garantit pas le résultat, mais elle fixe ce qu'il faudra mesurer et donne aux indicateurs qui suivent une raison d'exister.

Organiser la mesure autour de quatre dimensions

Plutôt qu'une longue liste d'indicateurs, la mesure gagne à s'organiser autour de quatre dimensions, chacune répondant à une question précise :

- Le Flow, qui mesure le temps nécessaire pour passer d'une idée décidée à un usage réel. - Les Economics, qui mesurent ce que coûte la production d'une fonctionnalité ou d'un changement, et ce que vaut le temps gagné. - Les Outcomes, qui vérifient que ce qui est livré est utilisé et produit l'effet attendu. - La Capacity, qui suit ce que l'on fait réellement de la capacité libérée par les agents.

Les trois premières dimensions mesurent ce que la chaîne produit et avec quelle efficacité. La quatrième mesure ce que l'organisation fait du levier de productivité ainsi obtenu, et c'est elle qui relie les gains de la chaîne à une décision de gestion.

Les mesures par rôle ou par étape, qu'il s'agisse de l'architecture, de la sécurité, du développement, des tests, de l'exploitation ou des pratiques de travail, restent utiles, mais comme indicateurs de diagnostic qui expliquent l'évolution de ces quatre dimensions, et non comme des KPI de même niveau.

Mesurer le Flow, de l'idée décidée à l'usage réel

Le premier indicateur est le délai complet entre la décision de traiter un besoin et l'usage effectif de la fonctionnalité, parce que c'est le seul qui capte l'effet cumulé de tous les rôles. Il se décompose en temps actif et en temps d'attente, et leur rapport, l'efficience de flux, est l'indicateur qui révèle le mieux l'effet d'un SDLC agentique. Lorsque les agents accélèrent la conception, le développement et les tests, le temps actif baisse fortement. Si le délai complet ne suit pas, le gain a été absorbé par une file d'attente que la décomposition permet de localiser.

Les indicateurs de diagnostic servent précisément à cette localisation. Le délai de revue d'architecture, la part des contrôles de sécurité automatisés dans la chaîne, le délai d'arbitrage produit ou le délai de recette montrent où le flux se bloque. Ils sont particulièrement utiles pour les rôles en périphérie. Une architecture ou une sécurité centrale qui sert plusieurs squads passées à l'agentique voit son volume de demandes augmenter au rythme des équipes, et si ses propres pratiques n'évoluent pas, elle risque de devenir le goulot de toute l'organisation.

Mesurer les Economics, du coût de production à la valeur du temps gagné

Le coût se mesure à l'unité, c'est-à-dire le coût complet d'une fonctionnalité ou d'un changement livré, en intégrant la consommation des modèles sur toutes les étapes, l'infrastructure de la plateforme et le temps humain de cadrage, de revue et de correction. C'est l'objet d'une FinOps appliquée à l'IA, qui gagne à suivre l'évolution de ce coût marginal de production plutôt que le seul coût par token ou par licence. Ce coût ne dit rien, à lui seul, de la valeur créée. Il ne prend son sens que mis en regard des résultats mesurés par les Outcomes, et c'est ce rapprochement qui permet de dire si une fonctionnalité moins chère à produire est aussi plus rentable. Le cadre publié par DORA en 2026 pour estimer le retour sur investissement de l'IA dans le développement logiciel suit une logique comparable. Il met en regard les coûts de licences, de consommation, d'infrastructure et de formation, ainsi que la baisse transitoire de productivité liée à l'adoption, avec le revenu des fonctionnalités supplémentaires pondéré par la part de celles qui réussissent, et avec l'évolution du coût des incidents.

Le temps gagné a lui aussi une valeur économique, que l'on désigne par le coût du retard, ou cost of delay. Donald Reinertsen l'avait déjà abordé avec Preston Smith dans Developing Products in Half the Time, puis l'a largement développé dans The Principles of Product Development Flow en 2009, en faisant de sa quantification une règle de décision centrale. Réduire un lead time de douze à quatre semaines ne crée pas la même valeur selon ce que l'on livre. Une fonctionnalité génératrice de revenus permet de les capter huit semaines plus tôt, une évolution réglementaire réduit d'autant la période d'exposition au risque, une automatisation diminue plus tôt un coût opérationnel, alors qu'une amélioration marginale peu utilisée n'apporte presque rien, même avec un lead time spectaculaire.

L'objectif est de passer d'un constat comme « nous avons réduit notre lead time de 40 % » à une affirmation comme « cette réduction nous a permis de capter plus tôt tel revenu, d'éviter tel coût ou de réduire de tant de semaines notre exposition au risque ». Tous les résultats n'ont pas à être monétisés pour autant, et certains se mesurent mieux dans leur unité métier naturelle, comme un délai de traitement ou un taux de satisfaction.

Mesurer les Outcomes, ce qui est utilisé et produit l'effet attendu

Une fonctionnalité livrée vite et à faible coût n'a de valeur que si elle est utilisée et produit l'effet attendu. Les indicateurs utiles sont l'adoption de la fonctionnalité par la population à laquelle elle s'adresse, la part des fonctionnalités livrées avec une hypothèse de valeur et un critère de succès déclarés avant le développement, la part de celles qui atteignent ce critère, et l'effet observé sur les indicateurs de l'activité ou des utilisateurs concernés. Ces mesures supposent que la plateforme soit reliée à des outils d'analytique produit et que le product manager formule ses hypothèses de façon vérifiable.

Éviter de construire plus vite la mauvaise chose

Eric Ries, qui a popularisé le Minimum Viable Product dans The Lean Startup, le définit comme la version d'un nouveau produit qui permet à une équipe de recueillir le plus d'apprentissage validé sur ses clients avec le moins d'effort. Le MVP sert donc avant tout à réduire l'incertitude. Les agents réduisent fortement le coût de production, mais ils ne réduisent pas l'incertitude sur ce que veulent les utilisateurs, et il devient beaucoup moins coûteux de construire la mauvaise chose. Puisque l'on peut produire davantage, la tentation apparaît d'ajouter des options, des variantes et des cas particuliers avant d'avoir démontré leur utilité, ce qui conduit à une forme de Maximum Viable Product.

Ce risque est sérieux parce qu'une fonctionnalité continue de coûter après sa production. Elle doit être maintenue, sécurisée, testée à chaque évolution et exploitée, et elle complique l'usage du produit pour ceux qui n'en ont pas besoin. En 2019, l'éditeur Pendo a analysé l'usage des fonctionnalités sur 615 abonnements de clients utilisant son outil depuis plus d'un an, et concluait, à partir de données d'usage anonymisées et agrégées, qu'environ 80 % des fonctionnalités d'un produit logiciel moyen étaient rarement ou jamais utilisées. L'évolution de la surface fonctionnelle rapportée à l'usage, la part des fonctionnalités livrées sans hypothèse déclarée et le nombre de fonctionnalités retirées faute d'usage permettent de détecter cette dérive.

La même baisse de coût peut servir la démarche inverse. Une squad peut construire plusieurs variantes d'une fonctionnalité, les tester rapidement auprès des utilisateurs, garder celle qui fonctionne et supprimer les autres. Seuls les indicateurs d'Outcomes permettent de savoir dans quelle direction elle avance.

Mesurer la Capacity, ce que devient réellement le temps libéré

Cette dimension vérifie que la décision prise avant le déploiement a été suivie d'effet. Le calculateur de DORA valorise d'ailleurs le temps libéré sous le nom de capacité de réinvestissement, au coût salarial des équipes, ce qui suppose précisément que l'organisation sache la réinvestir. La Capacity mesure donc la part de la capacité libérée qui a été explicitement réallouée, et ce qu'elle a produit, qu'il s'agisse du nombre d'expérimentations produit menées, de la réduction de la dette technique, de l'accélération du parcours jugé stratégique ou de la résorption d'un backlog auparavant non rentable. Les indicateurs de pratiques servent ici de diagnostic, en particulier la répartition du temps de chaque rôle entre cadrage, revue et exécution, et le nombre de passages de relais nécessaires pour livrer. Ils montrent si les rôles ont réellement repositionné leur travail ou s'ils relisent simplement davantage.

Poser quatre règles avant de mesurer

Un indicateur de valeur du SDLC agentique ne résiste à l'examen que s'il respecte quatre règles :

- Il se mesure au niveau de la fonctionnalité livrée et utilisée, rattachée à un résultat attendu, et non au niveau d'un outil, d'un agent ou d'un rôle isolé. - Il dispose d'un point de comparaison, qu'il s'agisse de l'historique de la squad ou d'une squad témoin qui n'est pas encore passée sur la plateforme. - Il est porté collectivement par la squad, avec un responsable identifié, et inclut les rôles en périphérie qui contribuent au flux. - Il est déclaré avant la mesure, et non choisi après coup parmi ceux qui donnent le meilleur résultat.

Pour une organisation qui a déjà ouvert des outils d'IA à ses équipes sans parvenir à en démontrer la valeur, la recommandation est de commencer par une squad complète, avec l'architecture et la sécurité qui l'accompagnent. Il s'agit de décider avec elle ce que deviendra la capacité libérée, de suivre les quatre dimensions pendant deux trimestres par rapport à son historique, puis de s'appuyer sur ce résultat pour décider de la généralisation.