Agilité et IA : ce qui change pour les équipes agiles

Agilité · IA · Agents

Agilité et IA : ce qui change pour les équipes

Les assistants de code, puis les agents IA, bousculent la façon de livrer. Ce que disent vraiment les études, ce qui change pour chaque rôle de l’équipe, et comment en tirer un bénéfice mesurable plutôt qu’une impression de vitesse.

En deux ans, l’IA générative est passée du gadget à l’outil quotidien de la plupart des équipes de développement. Les assistants complètent le code, rédigent des tests, résument des tickets. Les agents vont plus loin : ils enchaînent des actions, consultent des outils, produisent un livrable sans qu’on leur tienne la main à chaque étape. Pour les équipes agiles, la question n’est plus de savoir s’il faut s’y mettre, mais comment le faire sans perdre ce qui fait la valeur de l’agilité.

Dans mon rôle de Head of AI Transformation, je mesure ce que l’IA apporte réellement aux équipes qui livrent du logiciel. Ce guide reprend ce que j’en retiens : ce que disent les études sérieuses, ce qui change rôle par rôle, et une méthode simple pour démarrer avec un premier agent.

En bref

L’IA accélère la production de code et de documents, mais elle ne garantit ni la valeur livrée ni la qualité. Les études récentes montrent même des effets négatifs sur la stabilité quand les équipes livrent de plus gros lots. Les principes agiles (petits incréments, feedback rapide, amélioration continue) deviennent donc plus importants, pas moins. L’enjeu est de mesurer les gains réels, rôle par rôle.

Ce que disent les données

Les promesses de productivité se comptent en dizaines de pour cent. Les mesures indépendantes sont plus nuancées, et c’est une bonne nouvelle : elles nous disent où regarder.

Le rapport DORA 2024

Le programme de recherche DORA, connu pour ses quatre métriques de performance de livraison, a interrogé plus de 39 000 professionnels pour son rapport 2024. Résultat contre-intuitif : l’adoption croissante de l’IA s’accompagne d’une baisse estimée de 1,5 % du débit de livraison et de 7,2 % de la stabilité. Les auteurs l’expliquent notamment par des lots de changement plus gros, ce qui contredit un principe de base de l’agilité et du DevOps : livrer petit et souvent.

L’étude METR de 2025

En 2025, l’organisme de recherche METR a mené un essai contrôlé avec 16 développeurs expérimentés de projets open source, sur 246 tâches réelles. Quand l’IA était autorisée, les tâches ont pris environ 19 % de temps en plus. Les développeurs, eux, prévoyaient un gain de 24 % et, après coup, estimaient encore avoir gagné 20 %. Les auteurs précisent que le résultat vaut pour ce contexte (développeurs très familiers de grands dépôts matures) et ne prouve pas que l’IA est inutile en général.

Ce qu’il faut en retenir

La perception ne suffit pas : une équipe peut se sentir plus rapide sans l’être. Il faut mesurer, avec les mêmes métriques qu’avant l’IA.
La vitesse de frappe n’est pas le goulot : dans la plupart des équipes, le temps se perd dans les attentes, les revues, les validations et les allers-retours avec le métier, pas dans l’écriture du code.
La qualité est le premier risque : plus de code produit plus vite, c’est aussi plus de code à relire et à maintenir. Nous détaillons ce point dans Dette technique et IA : pourquoi le code généré ne vous dispense pas de la gérer.

Ce qui ne change pas : les principes agiles

Le Manifeste agile date de 2001, bien avant l’IA générative. Ses principes n’en deviennent que plus utiles :

Livrer fréquemment de petits incréments : c’est la meilleure protection contre les gros lots de code généré que personne n’a vraiment relus.
Le feedback rapide des utilisateurs : produire plus vite ne sert à rien si l’on produit la mauvaise chose. La revue de sprint et le contact avec les utilisateurs restent la boussole.
L’amélioration continue : l’arrivée d’un outil est un changement de processus comme un autre. Elle se teste, se mesure et se discute en rétrospective.
Les individus et leurs interactions : un agent peut résumer un échange, il ne remplace pas la confiance entre les membres d’une équipe.

Nous avions posé ces bases dès 2024 dans Être agile à l’ère de l’IA. Deux ans plus tard, le constat se confirme.

Le Scrum Master à l’ère des agents

Le Scrum Master est le rôle le plus exposé, parce qu’une partie de son travail est répétitive et documentaire. Un agent peut déjà :

préparer le Sprint Planning en regroupant les éléments prêts du backlog et la capacité de l’équipe ;
repérer les tickets bloqués depuis plusieurs jours et les signaler avant la Daily ;
calculer et commenter les métriques de flux (temps de cycle, travail en cours, débit) ;
rédiger la synthèse d’une rétrospective et suivre l’avancement des actions décidées.

Ce qui reste profondément humain : sentir une tension dans l’équipe, faciliter une décision difficile, convaincre un directeur de lever un obstacle organisationnel. Nous avons exploré ce que deviennent le métier et ses perspectives dans Scrum Master : un métier en voie de disparition ?, et nous avions même tenté l’expérience d’automatiser un coach agile. Pour les bases du métier, voir notre guide pour devenir Scrum Master.

Le Product Owner et l’IA

Pour le Product Owner, l’IA est un formidable assistant d’analyse, à condition de garder la main sur la valeur :

Analyser le feedback client : regrouper des centaines de verbatims, de tickets de support ou de réponses d’enquête par thème, et repérer les signaux faibles.
Préparer des user stories : proposer un premier découpage et des critères d’acceptation, que l’équipe challenge ensuite. Notre guide pour découper les user stories reste la référence pour juger de la qualité du résultat.
Explorer des options : formaliser des hypothèses, préparer un impact mapping ou un MVP à tester.

Le risque principal : un backlog qui grossit plus vite que la capacité de l’équipe, rempli d’éléments bien rédigés mais jamais priorisés. L’IA facilite la production de contenu, pas l’arbitrage. Prioriser reste le cœur du rôle.

Les Developers : vitesse et qualité

Les développeurs ont été les premiers à adopter l’IA. Quelques pratiques permettent d’en tirer un vrai bénéfice :

Garder de petits lots : découper le travail généré en changements courts, relus et intégrés souvent, conformément à ce que montrent les études DORA.
Adapter la Definition of Done : préciser ce qu’on attend d’un code produit avec l’aide de l’IA (tests, revue humaine, documentation, absence de dépendances inutiles).
Investir dans les tests automatisés : ils sont le filet de sécurité qui rend l’accélération soutenable.
Suivre la dette technique : rendre visible ce qui se dégrade, et le prioriser comme le reste. Voir notre guide sur la dette technique.

Les managers : piloter par la donnée

Pour les managers et les directions, la tentation est double : imposer l’IA partout, ou attendre de voir. Les deux sont des erreurs. L’approche qui fonctionne consiste à poser des hypothèses claires (« cet agent doit réduire de moitié le temps passé à préparer les comptes rendus »), à mesurer avant et après, et à arrêter ce qui ne donne rien.

Cela suppose des métriques fiables avant même l’arrivée de l’IA : temps de cycle, fréquence de déploiement, taux d’échec des changements, satisfaction des utilisateurs. Sans point de départ, aucun gain ne peut être démontré. C’est précisément l’objet de la formation Manager à l’ère de l’IA : mesurer l’impact de Corporate Mavericks. Nous abordons aussi le coût réel d’une vision purement comptable des équipes dans Votre équipe tech est un centre de coût ?

Quelles métriques suivre avant et après l’IA

Pour savoir si l’IA aide vraiment votre équipe, gardez les mêmes indicateurs avant et après son adoption. Les quatre métriques de DORA sont un bon socle, complétées par quelques mesures de flux et de qualité perçue :

Métrique	Ce qu’elle mesure	Signal d’alerte avec l’IA
Fréquence de déploiement	Le rythme auquel l’équipe met en production	Elle baisse alors que l’équipe produit plus de code
Délai de mise en production des changements	Le temps entre un commit et sa mise en production	Il s’allonge à cause de revues plus longues
Taux d’échec des changements	La part des déploiements qui provoquent un incident	Il augmente avec la taille des lots
Temps de rétablissement	Le temps pour revenir à la normale après un incident	Il s’allonge quand personne ne maîtrise le code généré
Temps de cycle et travail en cours	La fluidité du travail dans l’équipe	Le travail en cours grossit, les éléments restent bloqués en revue
Satisfaction de l’équipe et des utilisateurs	La valeur perçue, des deux côtés	Les développeurs se sentent plus rapides, les utilisateurs ne voient rien changer

Inutile de tout suivre dès le premier jour. Choisissez deux ou trois de ces indicateurs, mesurez-les pendant quelques sprints avant d’introduire un nouvel outil, puis comparez. C’est la seule façon de distinguer un gain réel d’une impression de vitesse.

Construire un premier agent utile à l’équipe

Inutile de commencer par un projet ambitieux. Voici la démarche que je recommande, et que nous pratiquons en formation :

Choisir une tâche répétitive et peu risquée : la préparation d’un compte rendu, le tri des demandes entrantes, la relance des actions de rétrospective.
Décrire la tâche comme à un nouveau collègue : objectif, sources d’information, format attendu, ce qu’il ne faut jamais faire.
Poser des garde-fous : l’agent propose, un humain valide, au moins au début. Aucune donnée sensible ne sort sans autorisation.
Mesurer : temps gagné, qualité perçue, erreurs corrigées. Une semaine de données suffit pour décider de continuer ou non.
Itérer : comme pour un produit, on améliore l’agent sprint après sprint, avec les retours de l’équipe.

Pour tester sans attendre, vous pouvez échanger avec notre coach agile automatisé. Et pour aller plus loin sur la constitution d’une véritable équipe d’agents, j’ai écrit Build Your Own AI Workforce (2026).

Les pièges à éviter

Confondre activité et valeur : plus de tickets fermés, plus de lignes de code ou plus de documents ne disent rien de la valeur livrée aux utilisateurs.
Généraliser trop vite : déployer un outil à toute l’organisation avant d’avoir prouvé son intérêt sur une équipe.
Négliger la confidentialité : savoir quelles données peuvent être envoyées à quel service, et le dire clairement aux équipes.
Déresponsabiliser : « c’est l’IA qui l’a proposé » ne doit jamais devenir une excuse. L’équipe reste responsable de ce qu’elle livre.
Oublier les personnes : l’arrivée des agents inquiète, parfois à juste titre. En parler ouvertement, en rétrospective ou en atelier, évite que la peur ne bloque tout.

Questions fréquentes sur l’agilité et l’IA

L'IA va-t-elle remplacer les Scrum Masters ?

Elle va remplacer une partie de leurs tâches répétitives (préparation, synthèses, suivi des métriques). Le cœur du rôle, faire progresser une équipe et lever les obstacles organisationnels, reste humain. Les Scrum Masters qui délèguent ces tâches aux agents gagnent du temps pour ce travail.

L'IA rend-elle les équipes plus productives ?

Pas automatiquement. Le rapport DORA 2024 associe l’adoption de l’IA à une légère baisse du débit et de la stabilité de livraison, et l’étude METR de 2025 a mesuré un ralentissement de 19 % chez des développeurs expérimentés. Les gains existent, mais il faut les mesurer.

Qu'est-ce qu'un agent IA ?

C’est un programme fondé sur un modèle de langage qui peut enchaîner plusieurs actions pour atteindre un objectif : consulter des outils, produire un livrable, demander une validation. À la différence d’un simple assistant conversationnel, il agit avec une certaine autonomie, dans les limites qu’on lui fixe.

Par où commencer avec l'IA dans une équipe agile ?

Par une tâche répétitive et peu risquée, avec des garde-fous clairs et une mesure avant et après. Une semaine d’expérimentation suffit souvent pour décider de poursuivre ou non. On en parle ensuite en rétrospective, comme de tout changement de processus.

Faut-il adapter la Definition of Done au code généré par l'IA ?

Oui, c’est une bonne pratique. Préciser les attentes (tests automatisés, revue humaine, documentation, absence de dépendances inutiles) évite que l’accélération ne se paie plus tard en dette technique.

Sources et références

DORA (Google Cloud), Accelerate State of DevOps Report 2024 : dora.dev
Google Cloud, annonce et synthèse du rapport DORA 2024 : cloud.google.com
METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, juillet 2025 : arxiv.org
Manifeste pour le développement agile de logiciels, 2001 : agilemanifesto.org
Robin Béraud-Sudreau, Build Your Own AI Workforce, 2026 : coach-agile.com

Créez votre premier agent IA en une journée

Formation Agent IA avec Hermes, à distance, en petit groupe de 8 participants au plus : vous repartez avec un agent qui travaille sur un cas réel de votre équipe.

Découvrir la formation Agent IA