Brève d’une software developer - l’IA, ce tigre dans le moteur qui propulse et bouscule le développement agile

le 01/04/2026 par Sylvain Fagnent, Mouna Damak

Tags: Data & AI, Software Engineering, Agile, Delivery, Intelligence Artificielle

1 - Introduction

Dans l'univers du développement logiciel, l'IA générative donne un puissant coup d'accélérateur aux équipes de développement : elle augmente fortement leur capacité à produire du code. Mais ce gain de vitesse n'est pas sans conséquence pour le reste du cycle de développement agile. Comme tout nouvel outil, il vient bousculer un mode de fonctionnement établi. Nous explorons ici la vision d’une équipe de développement et les effets autour d’elle. Comme dans un moteur auquel on injecte un surplus de puissance, il faut s'assurer que le reste du système en tire bénéfice et suit : sinon, gare à la surchauffe… voire la casse. Quels gains peut-on en attendre ? Quelles dérives peuvent apparaître, et lesquelles faut-il anticiper ?

Rappel : Henrik Kniberg a popularisé les enjeux du cycle de développement logiciel agile dans sa vidéo « Agile Product Owner in a Nutshell ». Le triptyque qu'il y présente — “Build the right thing”, “Build the thing right” et “Build the thing fast” — structure encore la réflexion de nombreuses équipes.

Comme dans un moteur, l’IA générative injecte un surplus de puissance au développement logiciel (src : Esso)

2 - Nos hypothèses de départ

Nous n'évoquerons pas ici la reprise de code legacy (Brownfield) par une nouvelle équipe. Cela fera l’objet d’autres articles à venir.
L’IA permet à l’équipe de développement d’intégrer davantage de fonctionnalités à chaque cycle, avec une accélération réelle du développement, dont l’ampleur varie toutefois selon les contextes, les équipes et les projets, les bénéfices observés sur le terrain restant à mesurer finement pour chaque organisation.
Nous faisons ici le choix d’adopter le point de vue de l’équipe de développement, en considérant que les autres membres de l’équipe n’ont pas encore fait évoluer leurs pratiques ou à la marge.

3 - Côté équipe de développement : bénéfices, risques et recommandations

3.1 - Bénéfices constatés

Bénéfices constatés
Le flux s’accélère → le temps de développement d’une fonctionnalité diminue A effectif constant, la vélocité de l’équipe augmente
L’IA fait gagner du temps à l’équipe de développement sur des tâches répétitives Avec la mise en place de “skills” spécialisés, mutualisés et réutilisables au sein des équipes, il devient possible de générer des gains de temps significatifs sur des tâches à faible valeur ajoutée: automatisation du “boilerplate” (API, DTO, configurations, CRUD), génération rapide des mocks de données pour les phases de développement et de test, ou encore simplification de la création et la mise à jour de la documentation. Il est possible de s’inspirer de ressources disponibles en ligne, comme skills.sh. Skill = brique activable par l’IA pour exécuter une tâche précise; skills.sh est un registre communautaire de briques réutilisables, versionnées, indépendantes de l’agent, qui permet de standardiser et partager la façon dont les agents agissent.
Le métier voit ses fonctionnalités développées plus rapidement La réduction significative du temps de développement des fonctionnalités entraîne une baisse marginale de leur coût. Il devient possible d’assumer la création de fonctionnalités testables et potentiellement jetables, au service de l’exploration directement en production et de l’itération rapide.
“Do the thing right” est plus facile qu'avant En s’appuyant, dès les premières itérations, sur des fichiers de contexte et de « skills » structurés, il devient possible de produire rapidement un code de qualité homogène et conforme aux standards, à l’échelle d’une équipe de développement.
Les Tech Leads (TL) concilient responsabilités et pratique du code Le rôle du TL évolue naturellement vers des activités de coordination, d’alignement et de gestion de la dette technique, ce qui limite fortement le temps consacré au développement. Si l’IA ne réduit pas cette charge, elle permet néanmoins au TL de contribuer plus facilement au code, sans perturber l’équilibre de l’équipe. Elle offre ainsi au TL la possibilité de rester impliqué techniquement tout en assumant pleinement ses responsabilités.
Le métier accepte mieux les chantiers techniques (refactoring, réduction de dette, sécurité) Certains chantiers ne sont plus repoussés aux calendes grecques car ils deviennent abordables → le code s’améliore et la vélocité de l’équipe ne s’effondre pas.
L’IA réduit l’attachement émotionnel au code Lorsqu’une équipe de développement a investi beaucoup de temps dans le développement d’une fonctionnalité, il devient plus difficile pour elle d’accepter de modifier sa structure applicative voire de la supprimer même si elle n’est plus pertinente : c’est le biais des coûts irrécupérables (Sunk Cost Fallacy). Avec du code généré ou co-produit par l’IA, il devient plus simple de prendre ses distances, des décisions pragmatiques et de supprimer ce qui n’apporte plus de valeur.

L’IA fait gagner du temps à l’équipe de développement sur des tâches répétitives ou peu motivantes - (Illustration réalisée avec Gemini)

3.2 - Risques & facteurs de risques et recommandations

Risques & facteurs de risques	Recommandations
- Le code généré est peu cohérent. Il s'accumule rapidement en dette technique , l'accélération tant espérée n’arrive pas. Tout se retourne alors contre l'équipe - La cause : foncer sans préparer le terrain, l'équipe lance l'IA sur le code sans avoir préalablement structuré les fichiers de contexte, les conventions de code, les skills et les documents d'architecture.	- Investir dans le setup avant d'accélérer: avant toute montée en charge avec l'IA, constituer les documents de contexte (architecture, conventions, contraintes). - Adopter une approche progressive: commencer par des tâches simples et bien bornées, monter graduellement en complexité. - Allouer un sprint de setup IA: dédier du temps à la préparation de l'environnement IA (fichiers de contexte, rules, skills) comme on le ferait pour une infrastructure technique. - Comprendre le fonctionnement sous-jacent d’une IA générative : où elle excelle et où elle atteint ses limites. Des ressources comme ce guide des patterns et anti-patterns identifient les stratégies efficaces (patterns), les erreurs fréquentes (anti-patterns) et les limites intrinsèques de l’IA (obstacles), afin d’aider les utilisateurs à collaborer plus intelligemment avec elle.
- La qualité du logiciel se dégrade. Le code introduit des erreurs (hallucinations), oublie des cas limites et génère des effets de bord imprévus. - La cause : code non relu - moins vigilante, l'équipe de développement ne relit plus le code produit par l'IA.	- Maintenir la revue de code systématique : Ne jamais faire l'économie de la relecture, même avec l'IA. - Rester vigilant & compétent : Accepter que l’IA se trompe…même si cela va être de moins en moins vrai. Lire, comprendre et maîtriser le code généré. - Faire du TDD (Test Driven Development) pour réfléchir aux cas limites et aboutir à une meilleure structuration du code.
- Un stock de fonctionnalités s'accumule rapidement aux portes de la production. Les retours sur les fonctionnalités à tester sont tardifs, ce qui allonge le temps de détection des bugs et donc celui de leur correction. Les livraisons deviennent plus volumineuses et plus risquées. - La cause : la fréquence de Mise En Production (MEP) est insuffisante pour absorber le flux.	- Faire des MEP le plus souvent possible sur de petits incréments pour pouvoir rollbacker facilement si cela se passe mal. - Investir dans l'Infrastructure as Code : Automatiser les déploiements pour éliminer le goulet OPS.
- Des fonctionnalités zombies en plus grand nombre s’accumulent sans jamais être supprimées. Le code et les performances du logiciel finissent alors par se dégrader. - La cause : Une observabilité insuffisante, ou placée aux mauvais endroits, empêche de déterminer si une fonctionnalité est réellement pertinente.	- Renforcer l'observabilité : Remplacer l’opinion par des données (passer de “je pense que à je mesure que”). Positionner avec attention les métriques pour correctement évaluer l'usage réel des fonctionnalités et leur valeur métier. - Mettre en place du Feature Lifecycle Management: objectif attendu, KPI clairs & partagés, date de revue planifiée, quand décider. - Dans le contexte fourni à l’IA, lui préciser explicitement que la fonctionnalité est à isolée proprement dans le code afin que sa suppression (si besoin) soit sans douleur. - Nettoyer sans regret régulièrement le code inutile.
- Le coût lié à la consommation des tokens s’envole augmentant de jour en jour. - La cause : une utilisation de l’IA sans discernement, ni véritable effort d’optimisation.	Optimiser l'usage des tokens : - Note : Cela présente en outre l’avantage de réduire la consommation de ressources. - Réduire le contexte envoyé via des petits prompts précis. Rendre très explicites ses demandes modère la consommation en tokens. Plus le prompt ressemble à une spécification technique, moins l’IA consomme de tokens. - S'appuyer sur des fichiers contextuels spécialisés (Markdown .md), structurés par typologie (user story, règles d'implémentation, workflows/skills). - Démarrer une nouvelle conversation à chaque changement de sujet. Capitaliser sur les résultats en les consignant dans un fichier (.md) réutilisable, afin de servir de base de travail pour les échanges suivants. - Utiliser le mode plan pour éviter les implémentations inutiles. - Paramétrer les sous-agents avec des modèles différents selon la complexité de la tâche. - Adapter son abonnement à un service d’IA selon ses besoins pour ne pas non plus frustrer dès que les limites sont atteintes. - Utiliser les modèles les moins chers pour les tâches simples. - Utiliser des outils tels que rtk permet de filtrer et de compresser les sorties de commandes avant leur transmission au LLM, réduisant ainsi efficacement la consommation de tokens.
- Démotivation de l'équipe - La cause : l'équipe de développement se démotive car elle ne code plus elle-même et ne gère que des agents.	- Valoriser la résolution de problèmes complexes avec l’aide de l’IA : certaines fonctionnalités nécessitent une collaboration plus étroite entre l’équipe de développement et l’IA, avec un pilotage fin du modèle, des interactions plus fréquentes et un contrôle renforcé. C’est notamment le cas des fonctionnalités impliquant des intégrations avec des systèmes tiers ou des partenaires, ainsi que des exigences fonctionnelles sensibles (sécurité, données bancaires…). - Alterner les moments de développement avec et sans IA et encourager les pairs programming entre les membres de l’équipe. - Valoriser le rôle d'orchestrateur : Repositionner les membres de l’équipe de développement comme "chef d'orchestre" des agents IA, un rôle tout aussi stratégique.
- Appauvrissement de la diversité et de l'apprentissage collectif - La cause : chaque membre de l’équipe de développement s'isole dans sa réflexion, explicite moins ses raisonnements aux autres. La diversité des raisonnements “humains” au sein des équipes s'appauvrit, freinant l'apprentissage collectif.	- Faire du pair programming avec ses pairs permet de partager des connaissances, de confronter son point de vue, de pratiquer et de garder la maîtrise du geste. - Ne pas oublier que l’agile c’est avant tout « les individus et leurs interactions plutôt que les processus et les outils ». Dit autrement : ce qui compte, ce sont les échanges → donc les conversations entre individus.

Sans regret, nettoyer régulièrement le code inutile (illustration réalisée par Gemini).

4 - Quels sont les impacts sur le reste de l’équipe ?

4.1 - Autres bénéfices constatés

Bénéfices constatés
Le time-to-market se réduit Le métier peut répondre plus vite à des opportunités de marché ou à des demandes urgentes de clients.
Le PO peut valider plus vite ses hypothèses produit Avec un cycle de développement raccourci, le PO obtient des retours terrain plus rapidement. L'approche "fail fast, learn fast" devient réellement praticable.
La priorisation pour le PO/métier est facilitée On remonte dans la priorisation des demandes à tester qui sont plus facilement implémentables grâce à l'IA.
L'équipe peut tester l'efficacité réelle des fonctionnalités en production A/B testing PO, UX et l’équipe de développement définissent ensemble les indicateurs pertinents, puis décident de ce qui reste et de ce qui est nettoyé. On profite d’un cycle pour tester l'efficacité d’une fonctionnalité : AB testing.
Les parcours utilisateurs peuvent être prototypés et testés avant un engagement technique Les UX, en collaboration avec le métier, peuvent produire grâce à l’IA des prototypes fonctionnels pour valider l'expérience utilisateur avant de lancer un développement complet. Cela permet de dérisquer une idée et de démontrer concrètement l'attendu.
La documentation fonctionnelle peut être générée automatiquement L'IA peut produire de la documentation à partir du code, des EPICs et des tickets, libérant du temps au PO et aux QA.

Par prototypage, les UX utilisent l’IA pour dérisquer ou démontrer concrètement un attendu (Illustration réalisée par Gemini)

4.2 - Risques & facteurs de risques et recommandations

Risques & facteurs de risques	Recommandations
- Aucun gain de vélocité n’est constaté - La cause : le métier, espère beaucoup de l’IA et fait pression sur l'équipe de développement pour livrer des fonctionnalités dès le début du projet. L'équipe sous pression fait l'impasse sur la phase de setup IA (fichiers de contexte, conventions, skills, architecture…) et produit du code immédiatement. Le code généré est incohérent, mal structuré, de la dette technique s'accumule dès les premières semaines.	- Sanctuariser une phase de setup IA: avant toute livraison de fonctionnalités, consacrer ce temps à la mise en place des fichiers de contexte, des conventions, des rules et des skills. Cet investissement conditionne la vélocité future. - Réaliser le setup en pair programming : travailler en binôme (voire en mob) pendant cette phase pour homogénéiser les pratiques, partager la compréhension des outils et garantir une utilisation cohérente de l'IA par toute l'équipe. - Communiquer un plan de montée en charge au métier : rendre visible la roadmap de setup IA afin que le métier comprenne ce qui est en cours et pourquoi. Montrer que l'accélération viendra après cette phase, pas malgré elle. - Fixer des jalons de validation du setup : à la fin de la phase de setup, réaliser une fonctionnalité pilote pour démontrer concrètement la vélocité acquise et rassurer le métier. - Impliquer le métier dans le setup : inviter le PO à contribuer aux documents de contexte métier (glossaire, règles de gestion, parcours utilisateurs) dès cette phase. Cela transforme l'attente en collaboration productive. - Ré-évaluer régulièrement le système et l'améliorer comme par exemple lors de rétrospectives autour du contexte IA mis en place.
- Le métier montre des signes d'impatience et entre en conflit avec l’équipe de développement - La cause : le métier se met à faire du “vibe coding” pour faire ses demandes et pense que vibe coder devrait aller aussi vite que coder avec une IA.	- Démystifier les apports réels de l’IA dans le développement logiciel en entreprise : si des gains importants existent, ils restent à mesurer avec précision. Les bénéfices sont souvent surestimés, voire fantasmés. Les impacts concrets et les effets de bord (dette technique cachée, perte de compétence, sécurité) sont encore largement à explorer. Pour cela il faut : - Cadrer l’expérimentation : pour un projet et une organisation donnés, définir des KPIs clairs (vélocité, taux de défauts, temps de revue, satisfaction des devs). - Mesurer sur le long terme l’apport qualitatif (maintenabilité, créativité) et quantitatif (nombres de fonctionnalités développées, temps gagné) sur plusieurs itérations. - Analyser les effets de bord : surveiller l’apparition de code « zombie », la dégradation de la compréhension de la codebase, ou les risques de sécurité liés au code généré. - Sur la sécurité, point de miracle, pratiquer les recettes classiques d’analyse via Sonar, tests d’intrusion, scan des dépendances ou audit externes si besoin. Faire une revue sur la base d’un autre modèle d’IA en utilisant un skill spécialisé sécurité. S’assurer que la gestion des habilitations et autorisations est correctement implémentée; vérifier que des secrets ne sont pas exposés. - Adopter des hooks permet de contrôler, sécuriser et adapter le comportement du système IA en intervenant sur ses entrées, ses traitements ou ses sorties.
- L'équipe de développement ne sait pas résoudre des demandes complexes du métier, l'IA générative n'apportant pas d'aide significative sur ce point. - La cause : des demandes macroscopiques dont le métier ne mesure pas toujours les impacts ni les implications techniques sous-jacentes. Certaines demandes sont complexes et impliquent, par exemple, l'intégration de partenaires internes ou externes.	- Impliquer un architecte sur les demandes complexes : Le métier doit échanger avec les architectes en amont pour préciser les besoins et comprendre les implications techniques.
- Dérive vers l'exécution au détriment de la réflexion - La cause : les équipes deviennent moins rigoureuses dans leur réflexion amont, dérivent en privilégiant l'exécution au détriment de la pertinence du produit. Le code devient "trop" facilement jetable, au prix d'un gaspillage de ressources (tokens, calcul, etc.). Toute ressource dont le coût devient marginal tend à être consommée sans retenue.	- Toujours pousser sa réflexion en amont même si on pense ensuite tester concrètement son idée en production. Une réflexion amont est toujours utile. - S’appuyer (par exemple) sur le framework RICE afin de prioriser les fonctionnalités du produit (product management). RICE: Reach (combien d’utilisateurs touchés); Impact (niveau d’impact); Confidence (fiabilité des hypothèses); Effort (coût). - Intégrer la voix du client avec des interviews client et/ou des observations de poste (in situ).
- Surcharge du PO/métier et des QA - La cause : on sollicite de plus en plus rapidement et fréquemment l'avis du PO/métier en fin de cycle (boucle de feedback) ce qui entraîne une surcharge de leur côté. Les QA deviennent aussi indispensables pour valider le logiciel. L'accélération du rythme crée également une saturation chez eux en raison du volume croissant de tests de non-régression à concevoir (automatisés) et à exécuter (manuels).	- Pousser l’automatisation de tests E2E et de non régression pour soulager l’équipe QA - Valider le « Quoi » avant le « Comment » : Le PO/métier doit valider les spécifications comportementales (scénarios BDD / Gherkin, Behaviour Driven Development) ou les maquettes interactives (Figma/prototype) avant que l’IA ne génère une seule ligne de code. - L’IA peut faciliter l’automatisation et l’écriture des tests E2E et de non-régression - Automatiser la validation via des « KPIs de sortie » et du Feature Flagging. Remplacer la validation humaine subjective par des validations data-driven. Feature Flags + A/B Testing : au lieu de demander « Est-ce que cette fonctionnalité te plaît ? », la lancer en production derrière un feature flag pour un sous-ensemble d’utilisateurs. - Dégager du temps pour le PO: automatiser la génération de la documentation fonctionnelle par l’IA sur la base des EPICS + des tickets + du code.

On sollicite de plus en plus rapidement et fréquemment l’avis du PO/métier en fin de cycle, ce qui entraîne une surcharge de leur côté (illustration réalisée avec Gemini)

5 - Conclusion

L’arrivée de l’IA générative dans le développement logiciel constitue un perturbateur majeur des équilibres auxquels les équipes étaient habituées. Comme toute innovation, elle introduit du nouveau dans un système déjà établi et le perturbe.

Comme toute innovation, l’IA introduit du nouveau dans un système établi et le perturbe.

L’IA peut accélérer la vitesse de développement, mais seulement si les équipes renforcent leur discipline : spécifications, architecture, tests et revue deviennent encore plus importants qu’avant. Tous les rôles doivent contribuer au contexte fourni à l’IA : “l’IA doit devenir l’assistant de l’équipe, pas seulement celui du développeur”. La vitesse sans discipline crée plus rapidement du chaos que de la valeur. On ne passe pas de conducteur de Twingo à pilote de rallye sans un apprentissage sérieux, ni entraînement.

On ne passe pas de conducteur de Twingo (sans IA) à pilote de rallye (avec IA) sans un apprentissage sérieux ni entraînement (Illustration réalisée par Gemini)

L'IA agit comme un amplificateur des dynamiques existantes. "Sous IA", une équipe dysfonctionnelle ne le reste pas simplement elle tend à devenir plus chaotique, plus rapidement, et à plus grande échelle. À l'inverse, une équipe disciplinée et bien organisée verra ses forces décuplées.

L’accélération de la production de code grâce à l’IA met en évidence un principe fondamental : la vitesse globale reste contrainte par le maillon le plus lent. En augmentant fortement le débit de développement, de nouveaux goulets d’étranglement apparaissent notamment dans les phases de revue, de validation, de test ou de mise en production.

En augmentant fortement le débit de développement, des goulets d’étranglement peuvent apparaître dans les phases de revue, de validation, de test ou de mise en production (Illustration réalisée avec Perplexity)

Enfin, la construction d'un produit repose sur un équilibre entre trois impératifs : « Build the right thing » (construire le produit attendu), « Build the thing right » (techniquement bien construit) et « Build the thing fast » (suffisamment rapidement). Boostée par l'IA, l'équipe peut gagner sur le "fast" et le "right". Mais l'aisance de mise en œuvre et l'accélération des cycles peuvent rapidement conduire à des dérives, où l'on privilégie l'exécution au détriment de la pertinence du produit. Sans vigilance, l'équipe (au sens large) risque de construire "vite" un produit qui ne correspond pas aux attentes des utilisateurs.

La construction d’un produit repose sur un équilibre entre trois impératifs (Src Henrik Kniberg - “Agile Product Owner in a Nutshell”)

6 - Et après, quels seront les prochains défis…à investiguer ?

6.1 - Premier défi : l’autonomie des agents

- Passage à l'échelle et multi-agents : les équipes s'appuieront-elles sur des systèmes multi-agents spécialisés et orchestrés ? Ces agents deviendront-ils persistants, capables de travailler sur des heures voire des jours ?

- Puissance de l’IA autonome, comment garder le contrôle : sur des projets/tâches de plus grande envergure comment instaurer des points de contrôle réguliers dans le travail de l’IA ? Comment gérer les interactions futures qui devront encourager l’IA à signaler toutes incertitudes, à solliciter une validation humaine et le cas échéant, à s’interrompre. Comment choisir les agents capables de reconnaître leurs limites, de demander de l’aide au bon moment et de suspendre leur action avant de poursuivre, ou pas ?

Référence vintage ;-) : puissance de l’IA autonome, comment garder le contrôle (“Power is nothing without control”, src. Pirelli)

6.2 - Second défi : quel sera le futur du logiciel ?

- Vers un build en flux continue : du point de vue du delivery, il devient pertinent de s’interroger sur l’adaptation du flux de fabrication afin d’absorber la nouvelle cadence imposée par les équipes de développement. Si le cadre Scrum a popularisé les cycles en sprints, ce découpage reste-t-il adapté dans un contexte où la production pourrait tendre vers un mode quasi continu ? Cela implique de s’attacher à identifier et éliminer les goulots d’étranglement de la conception jusqu’à la mise en production. Sans remettre en cause les principes agiles, le cycle global pourrait évoluer vers une approche davantage orientée flux, visant à limiter les accumulations et à lisser les contraintes, à l’image des pratiques inspirées de Kanban (et de Lean).

- Build ou Buy : si le coût du développement diminue, les entreprises pourraient être tentées de développer en interne plutôt que d'acheter des solutions éditeurs.

- L’impact sur les “business model” pour les éditeurs de logiciels. Si une équipe développe un logiciel qui, au final, n’est pas si difficile à reproduire, un meilleur time-to-market ne suffira pas forcément : des concurrents pourraient rapidement proposer une solution équivalente. Seul le coût ou la personnalisation pourrait faire la différence. Cf le sujet de la Saas apocalypse. L’IA cannibalise t-elle le modèle de l’édition logicielle ?!

- Quel gain financier réel ? Un sujet qui mérite une étude dédiée : mesurer précisément les économies sur le développement et la chaîne globale.

- Le brownfield: moderniser un legacy grâce à l’IA générative. Soufiane Keli : “Comment utiliser la GenAI pour moderniser une application en deux fois moins de temps” Duck Conf ; Renover un legacy grâce à l’IA.