La plupart des échanges sur l’IA et l’Agile restent abstraits : plus rapide, moins cher, plus lean — sans programme réel pour confronter l’affirmation aux faits. Cet article s’appuie sur un cas concret que j’ai dirigé : une application mobile de santé publique conçue pour un leader des sciences de la vie en France, livrée selon l’approche classique — une semaine de découverte sur site, du Design Thinking, une équipe nearshore distribuée, sprint après sprint. Je me souviens encore d’être reparti de cette première semaine avec un prototype cliquable en main ; cette partie du métier n’a pas pris une ride, quel que soit le modèle de delivery derrière. Le client et le prestataire de delivery ne sont volontairement pas nommés ici, conformément à la manière dont la documentation d’origine du projet a elle-même été rédigée ; ce qui compte, c’est la structure du programme, pas le logo.
La première partie ci-dessous décrit ce qui s’est réellement passé. La seconde est une projection délibérée : le même périmètre, la même intention de gouvernance, repensés autour du développement piloté par la spécification (« spec-driven ») et des pratiques de delivery augmentées par l’IA telles qu’elles existent aujourd’hui. Les chiffres de la partie II sont des hypothèses de planification, clairement identifiées comme telles — utiles pour calibrer une conversation avec votre comité de pilotage, pas une estimation certifiée.
Partie I — Le parcours Agile classique, tel qu’il a été livré
Une semaine de découverte sur site, chez le client
Le programme a démarré par une semaine complète de découverte sur les sites du client, en France. L’équipe — un Scrum Master, un Business Analyst et un UX/UI Designer — a travaillé en contact direct avec des médecins, des virologues et des mathématiciens des équipes scientifiques du client, qui avaient déjà construit le modèle épidémiologique que l’application devait exposer. Cette proximité a compté : elle a créé la confiance et un vocabulaire commun entre une équipe de delivery technique et une organisation scientifique cliente qui n’avaient encore jamais travaillé ensemble.
La semaine s’est déroulée comme un sprint de Design Thinking structuré : cartographie du problème, wireframes sous Figma, itérations vers des maquettes d’interface et des parcours utilisateurs, puis convergence vers un prototype cliquable. À la fin de la semaine, l’équipe repartait avec une première liste de fonctionnalités, une estimation et un calendrier, et — point essentiel — un premier backlog de sprint pour la phase MVP, prêt à être transmis à l’équipe de delivery.
Une semaine de découverte sur site a transformé un modèle scientifique en prototype cliquable, en liste de fonctionnalités et en premier backlog de sprint — les livrables dont une équipe distribuée avait besoin pour démarrer avec confiance.
L’équipe virtuelle nearshore
Une fois la découverte terminée, l’équipe est repartie vers un centre de delivery nearshore en Roumanie et s’est reconstituée en escouade virtuelle distribuée. Dix personnes, pleinement pluridisciplinaires : 1 Scrum Master, 1 Business Analyst, 1 UX/UI Designer, 2 développeurs front-end, 2 développeurs back-end, 2 ingénieurs QA et 1 ingénieur DevOps. Côté client, la gouvernance est restée volontairement légère : un Product Owner et un Sponsor exécutif, alignés avec l’équipe de delivery via le Scrum Master et le Business Analyst qui avaient été présents à Paris.
Côté client : Product Owner et Sponsor. Côté delivery : Scrum Master, Business Analyst, UX/UI Designer, front-end, back-end, QA et DevOps — 10 ETP dans une seule équipe nearshore.
C’est la partie de « l’Agile nearshore » qui apparaît rarement sur une slide — et c’est celle que j’ai défendue toute ma carrière : les personnes qui ont mené la découverte n’ont pas transmis le relais à des inconnus. Le Scrum Master et le Business Analyst qui s’étaient assis face aux virologues du client étaient les mêmes qui affinaient le backlog avec l’équipe à chaque sprint suivant. C’est la continuité du contexte, et pas seulement la proximité de fuseau horaire, qui a fait fonctionner la transition.
Le MVP, puis trois autres versions
La delivery s’est déroulée en mode itératif, basé sur le MVP et time-boxée — des sprints de deux à quatre semaines, ouverts par un daily stand-up et clos sur un incrément potentiellement livrable, exactement comme le modèle de delivery de l’équipe le décrit.
| Version | Périmètre | Cadence |
|---|---|---|
| MVP | Carte de prévision et vue de tendance hebdomadaire, construites à partir du modèle mathématique du client | ~1 mois après le lancement de la découverte |
| Version 2 | Pays et fonctionnalités additionnels au-delà du périmètre initial France | Sprints suivants |
| Version 3 | Un module d’extension COVID-19, ajouté lorsque la pandémie a redéfini la pertinence du produit | 2 sprints |
| Version 4 | Disponibilité native iOS et Android, au-delà du périmètre initial web/mobile-web | Sprints suivants |
Ce que ce modèle a réussi — et où il a montré ses limites
Le modèle classique a livré. Un MVP est sorti en environ un mois à partir de zéro ; le client a obtenu une relation de confiance opérationnelle avec une équipe distribuée qu’il n’avait rencontrée qu’une seule semaine ; et la feuille de route a continué de s’étendre avec souplesse, y compris un module lié à la pandémie, non prévu, construit en seulement deux sprints. C’est un résultat véritablement solide pour les pratiques de delivery de l’ère 2020.
La force du modèle résidait dans la continuité du contexte entre la découverte et la delivery. Son coût était que chacune de ces dix personnes devait être staffée, montée en compétence et occupée pendant toute la durée du programme — quelle que soit la façon dont la charge évoluait réellement d’un sprint à l’autre.
Le modèle a aussi montré ses limites, de façon prévisible. Les livrables de la semaine de découverte — wireframes, parcours, liste de fonctionnalités — étaient riches mais restaient de nature narrative : ils devaient être relus, réinterprétés et renégociés par l’équipe à chaque sprint, avec le Business Analyst comme pont humain entre l’intention scientifique et le backlog d’ingénierie. Les tests et la gestion des environnements restaient largement manuels et dépendants des personnes. Et peu de logique de spécification ou de design system se reportait automatiquement d’une version à l’autre — chaque extension redevait gagner sa propre estimation et son propre sprint de montée en compétence.
Partie II — Le même programme, repensé pour une delivery pilotée par la spécification, à l’ère de l’IA
Le développement piloté par la spécification (« spec-driven ») inverse le livrable par défaut d’un programme de ce type. Au lieu d’un backlog narratif que l’humain réinterprète à chaque sprint, la découverte produit une spécification structurée et versionnée — fonctionnalités, parcours utilisateurs, contrats de données, critères d’acceptation — sur laquelle humains et agents de codage IA construisent directement. La spécification devient la source de vérité exécutable, et non un jeu de slides que chacun réinterprète en silence.
Une découverte compressée, pas supprimée
La semaine sur site ne disparaît pas — le contact direct avec les scientifiques du client reste le moyen le plus rapide de gagner la confiance et d’extraire une connaissance tacite qu’aucun document ne capture. Ce qui change, c’est ce qui se passe pendant cette semaine. La transcription et la synthèse assistées par IA transforment les échanges d’atelier en exigences structurées quasiment en temps réel ; des variantes de wireframes générées par IA permettent à l’UX/UI Designer d’explorer trois directions d’interface dans la salle, au lieu d’une seule après coup ; et le livrable de la semaine est directement rédigé comme une spécification exploitable par une machine, plutôt qu’un jeu de slides qu’une équipe distante retranscrira plus tard en backlog. Une compression réaliste : une semaine sur site devient deux à trois jours.
Une équipe de quatre personnes, augmentée par l’IA
Les dix rôles de 2020 ne survivent pas inchangés — plusieurs fusionnent, augmentés par des outils IA qui absorbent la partie mécanique de chaque rôle et laissent la partie jugement à une personne.
| Dimension | 2020 — Agile classique | Projection 2026 — spec-driven, augmentée par l’IA |
|---|---|---|
| Taille de l’équipe de delivery | 10 ETP | 3 à 4 ETP |
| Durée de la découverte | 1 semaine sur site | 2 à 3 jours, en mode hybride |
| Délai jusqu’au MVP | ~4 semaines | 2 à 3 semaines |
| Feuille de route complète (4 versions) | ~6 mois | ~3 à 4 mois |
| Pratique centrale | Backlog narratif, réinterprété à chaque sprint | Spécification versionnée comme source de vérité exécutable |
| Gouvernance | PO + Sponsor + Scrum Master comme pont humain | PO + Sponsor + Spec Lead, avec traçabilité générée par IA de la spécification au code |
La feuille de route se comprime d’environ moitié, pas d’un ordre de grandeur — et ce plafond est délibéré, pas une limite des outils. L’IA compresse le temps d’ingénierie : l’échafaudage, le refactoring et l’écriture de tests qui consommaient auparavant l’essentiel d’un sprint. Elle ne compresse pas le temps calendaire qui n’était jamais du temps d’ingénierie — les cycles de revue des stores d’applications pour le déploiement natif iOS/Android de la version 4, la validation clinique et réglementaire de tout contenu lu par un patient, la coordination multi-pays de la version 2, et la cadence de gouvernance côté client qu’un Sponsor et un Product Owner attendent raisonnablement pour un produit orienté santé. Un programme qui prétendrait faire tenir six mois en six semaines serait en train de supprimer discrètement l’un de ces éléments, pas de les accélérer tous réellement.
Ce que cela pourrait coûter — et les hypothèses derrière le chiffre
Le calcul naïf — environ 60 % de personnes en moins, livrant en environ la moitié du temps écoulé — laisserait entendre une baisse du coût de delivery d’environ 80 %. Ce chiffre n’est pas crédible, et l’utiliser sous-estimerait la réalité économique de la delivery à l’ère de l’IA. Trois facteurs compensateurs comptent :
- Les profils augmentés par l’IA sont nécessairement plus seniors — piloter un agent de codage et revoir sa production de façon responsable justifie une prime par rapport à un développeur traditionnel de niveau intermédiaire, typiquement 20 à 30 % de plus par personne.
- Les outils IA, l’inférence des modèles et la gouvernance des agents représentent une nouvelle ligne de coût, non négligeable, qui n’existait tout simplement pas dans la référence 2020.
- La gouvernance côté client, la revue réglementaire et la responsabilité humaine pour tout ce qui touche le patient ne se compriment pas au même rythme que le débit d’ingénierie — et ne le devraient pas.
En compensant ces facteurs par l’effectif réduit et le calendrier plus court, une hypothèse de planification défendable est une réduction de 45 à 60 % du coût total de delivery par rapport à la référence 2020 — un chiffre solide, mais nettement inférieur à ce que suggérerait le calcul naïf effectif × durée. À considérer comme une hypothèse de planification, un ordre de grandeur pour ouvrir une conversation budgétaire, et non une estimation auditée.
Ce qui ne change pas
Rien de tout cela ne touche à la question de qui est responsable de ce qui est livré. Dans un programme réglementé, orienté santé, un humain doit continuer de porter l’exactitude clinique, la gouvernance des données et la décision de mise en production. L’IA compresse la découverte, génère du code à partir d’une spécification et rédige elle-même sa couverture de tests — mais la spécification dont elle part, et le jugement consistant à faire confiance à sa production, restent une responsabilité humaine des deux côtés de l’engagement.
L’IA change qui fait le travail et à quelle vitesse. Elle ne change pas qui est responsable de ce qui est livré aux patients.
L’implication pratique pour tout dirigeant qui lirait ceci comme un modèle à suivre : réinvestir les économies d’une équipe de delivery plus petite et plus rapide dans une capacité de gouvernance que vous n’aviez pas auparavant — revue des spécifications, audit des productions IA, validation réglementaire — plutôt que de traiter la totalité de l’écart comme de la marge. C’est ce qui distingue un modèle de delivery réellement plus rapide d’un chemin plus rapide vers les mêmes échecs qu’avant. Je continue d’apporter ce cas précis aux clients qui pèsent un pari similaire — le calcul est la partie facile ; la discipline de réinvestir les économies est celle que tout le monde saute.
Alin Popovici
Conseiller exécutif, dirigeant de transformation et de delivery — et enseignant invité sur le pilotage de programmes complexes à l’Executive MBA de la Bucharest Business School (ASE Bucarest en partenariat avec le CNAM Paris).