Une équipe qui code avec l'IA :
quels rituels Scrum ajuster ?

Depuis quelques mois, la même scène revient dans presque toutes les équipes produit. Chaque développeur a désormais un assistant qui écrit du code à sa place, un agent qui génère les tests, un outil qui résume les tickets et propose un correctif avant même qu'on ait fini de lire le bug. Le débit de code a bondi. Et très vite arrive la question qui dérange : est-ce qu'on fait encore du Scrum comme avant ?

La réponse courte est non. La réponse utile est plus intéressante.

L'IA ne casse pas Scrum. Elle déplace le risque. Le point de blocage d'une équipe n'est plus d'écrire le code : c'est de décider quoi construire, de vérifier ce qui a été produit, et de garder tout le monde aligné sur un objectif qui a du sens. Or c'est précisément le travail des rituels. Certains deviennent donc plus importants qu'avant, d'autres changent de fonction sans changer de nom, et deux qu'on serait tenté d'alléger sont justement ceux à ne pas toucher.

J'ai déjà défendu l'idée que Scrum est un outil, pas une identité. Elle n'a jamais été aussi vraie. La bonne question n'est pas « comment protéger nos rituels de l'IA ? », mais « à quoi sert chaque rituel, maintenant que la partie facile est automatisée ? ». Voici le cadre que j'applique, rituel par rituel.

1. Ce que l'IA change vraiment (et ce qu'elle ne change pas)

Un assistant de code accélère la partie la plus visible du travail : produire des lignes. Mais produire des lignes n'a jamais été le goulot d'étranglement d'une bonne équipe. Ce qui coûte, c'est comprendre le problème, choisir une solution défendable, l'intégrer sans casser le reste, et être sûr que ça marche vraiment. L'IA rend la frappe quasi gratuite et laisse tout le reste exactement où il était.

Le résultat est contre-intuitif. Accélérer l'étape qui n'était pas le problème ne rend pas l'équipe proportionnellement plus rapide. Ça déplace la pression en aval : plus de code produit veut dire plus de code à comprendre, à relire, à tester, à faire tenir ensemble. La file d'attente ne disparaît pas, elle se décale d'un cran.

Et il y a une catégorie de travail que l'IA ne touche pas du tout : le vrai travail complexe, celui où la solution n'est pas connue d'avance et où il faut expérimenter pour apprendre. C'est exactement le terrain pour lequel Scrum a été conçu. L'IA génère vite une réponse plausible à une question mal posée ; elle ne pose pas la question à votre place.

L'IA rend l'écriture presque gratuite. Elle ne rend ni la décision plus facile, ni la vérification moins nécessaire.

2. Le daily standup : de « qui fait quoi » à « qu'est-ce qui est vraiment fini »

Le standup classique fait le tour de table : hier, aujourd'hui, blocages. Dans une équipe assistée par l'IA, ce format perd encore un peu plus de son sens. Quand n'importe qui peut générer un brouillon de fonctionnalité en une matinée, savoir « qui code quoi » ne dit plus rien d'utile. Le travail avance vite et en désordre ; l'état d'avancement déclaré ne veut plus dire grand-chose.

Le signal qui compte s'est déplacé. Ce n'est plus « où en es-tu de ton code ? », mais « qu'est-ce qui est réellement intégré, relu et vérifié ? ». Un ticket dont l'IA a écrit tout le code n'est pas « presque fini » : il est à l'entrée de la file de revue, c'est-à-dire au début de la partie coûteuse, pas à la fin.

Le standup doit donc cesser de mesurer l'activité pour mesurer le flux. Ce que je fais remonter chaque matin : ce qui attend une revue, ce qui bloque une intégration, ce qui a été produit sans qu'un humain l'ait compris. Le reste, l'IA le sait déjà.

3. Le sprint planning : estimer l'incertitude, pas l'effort de frappe

Une bonne partie de nos estimations mesurait, sans le dire, le temps qu'il faudrait pour écrire le code. Les story points servaient de proxy à un effort dont l'écriture était une composante majeure. Quand cette composante s'effondre, une estimation calée dessus devient trompeuse : la tâche paraît minuscule parce que le code sortira en dix minutes, et on oublie la demi-journée nécessaire pour le comprendre, le sécuriser et le brancher au reste.

Le planning doit se recentrer sur ce qui reste incertain. Une tâche bien définie, dans un domaine maîtrisé, où l'IA produira un code que l'équipe sait relire vite : elle est vraiment petite, assumez-le. Une tâche qui touche un point sensible, une zone mal testée, une dépendance fragile, ou dont personne ne comprend encore les effets de bord : elle est grosse, quel que soit le nombre de lignes que l'IA cracherait. Estimez la revue et l'intégration, pas la génération.

C'est aussi le moment de se rappeler que la vélocité en points ne dira jamais à un dirigeant si l'équipe livre de la valeur. Elle le dira encore moins quand le nombre de lignes cesse d'être une contrainte. Le planning sert à décider où mettre l'attention rare de l'équipe, pas à remplir un quota de points.

4. La definition of done : le rituel qu'il faut durcir, pas alléger

C'est le rituel le plus menacé, et paradoxalement celui qu'il faut renforcer. Le code généré par une IA a une propriété piégeuse : il a l'air juste. Il compile, il suit les conventions, il passe les tests évidents. Et il peut être subtilement faux, gérer un cas limite de travers, ouvrir une faille, ou tester sa propre présence plutôt que le comportement attendu. « Ça a l'air bon » n'est pas une definition of done.

Générer du code n'est pas le maintenir : c'est une chose que j'ai déjà développée à propos du no-code, du low-code et de l'automatisation, et elle vaut mot pour mot pour le code assisté par IA. La definition of done est le filet qui rattrape l'écart entre « produit » et « fiable ». Elle doit devenir plus explicite, pas moins.

Quelques points non négociables que j'ajoute à une definition of done quand une équipe code avec l'IA :

• Une relecture humaine réelle. Pas un « LGTM » de dix secondes : quelqu'un a lu le code, l'a compris, et engage sa responsabilité dessus. Si personne dans l'équipe ne sait expliquer ce que fait un morceau de code, il n'est pas fini, il est en dette.
• Des tests qui vérifient un comportement. Un test généré en même temps que le code, par le même outil, peut se contenter de valider ce que le code fait, pas ce qu'il devrait faire. Le test doit venir de l'intention, pas du résultat.
• Une vérification de sécurité et de provenance. D'où viennent les dépendances suggérées ? Le code touche-t-il des données sensibles ? Une IA propose volontiers une bibliothèque obscure ou un secret en clair ; la definition of done est l'endroit où on l'attrape.
• Un propriétaire nommé. Le code assisté n'a pas d'auteur au sens habituel. Quelqu'un doit pourtant en répondre dans six mois, quand il faudra le faire évoluer.

5. La revue de code : le nouveau goulot d'étranglement de l'équipe

Si l'écriture devient gratuite et la revue reste humaine, la capacité réelle de l'équipe se mesure désormais à ce qu'elle peut relire sérieusement, pas à ce qu'elle peut produire. La revue passe de formalité de fin de cycle à contrainte centrale. C'est là que la file d'attente se forme, et c'est là qu'il faut poser des limites.

Concrètement, j'emprunte au Kanban sa discipline la plus utile : une limite de travail en cours sur la revue. On ne lance pas dix chantiers en parallèle sous prétexte que l'IA peut tous les démarrer ; on plafonne le nombre de choses en attente de relecture, parce que c'est le vrai plafond de l'équipe. Des lots plus petits, des demandes de fusion courtes, une revue faite tôt et à deux quand le sujet est sensible. Une équipe qui produit trois fois plus de code et relit à la même vitesse qu'avant n'est pas trois fois plus rapide : elle accumule trois fois plus de dette non relue.

C'est aussi une affaire de posture, pas seulement d'outillage. Relire du code qu'un collègue a pensé et écrit est un acte de collaboration. Relire du code que personne n'a vraiment écrit demande une vigilance différente, plus proche de l'audit. Cette bascule se prépare et s'accompagne : c'est une bonne part de ce que je viens installer quand j'interviens dans une équipe.

6. La rétrospective : n'y touchez pas

Voici le premier rituel à laisser strictement intact. La rétrospective ne produit pas de code, ne se mesure pas en points, et n'a aucun équivalent automatisable. C'est le moment où une équipe regarde honnêtement comment elle travaille, nomme ce qui la ralentit, et décide de changer quelque chose. Aucun agent ne fera cela à sa place, parce que la matière première est la confiance entre des personnes, pas des données.

Mieux : dans une équipe qui adopte l'IA, la rétrospective compte plus que jamais. Les habitudes de travail bougent chaque semaine, de nouveaux outils entrent, le rapport au code change. Sans un espace régulier pour digérer tout cela, l'équipe subit le changement au lieu de le piloter. Si vous deviez couper un seul rituel pour gagner du temps, ce n'est surtout pas celui-là.

7. Le sprint goal : n'y touchez pas non plus

Le second rituel intouchable est le plus discret et le plus vital. Le sprint goal ne parle ni de code ni de méthode : il dit pourquoi ce sprint existe, quel résultat il vise pour un utilisateur ou pour l'entreprise. La manière dont le code est produit ne le concerne pas. Et c'est justement pour cela qu'il devient l'ancre la plus importante de l'équipe.

Le vrai danger d'une équipe qui code très vite n'est pas de mal coder. C'est de construire efficacement la mauvaise chose. Quand produire ne coûte presque rien, la tentation est de produire beaucoup, sans se demander si cela sert un objectif. Le sprint goal est le garde-fou : il transforme un débit de code en direction. Sans lui, l'IA vous offre surtout le moyen de vous tromper de cible plus vite qu'avant.

Ce qu'il faut vraiment retenir

L'IA ne remplace pas Scrum et ne le rend pas obsolète. Elle déplace le centre de gravité de l'équipe, de l'écriture vers la décision et la vérification, et vos rituels doivent suivre ce déplacement.

• Ajustez le standup : mesurez le flux réel (ce qui est intégré, relu, vérifié), pas l'activité déclarée.
• Ajustez le planning : estimez l'incertitude, la revue et l'intégration, jamais l'effort de frappe.
• Durcissez la definition of done : relecture humaine, tests de comportement, sécurité et provenance, propriétaire nommé.
• Traitez la revue comme le vrai goulot : limitez le travail en cours, réduisez la taille des lots, relisez tôt.
• Ne touchez pas à la rétrospective : c'est l'espace humain qui pilote le changement, et le changement s'accélère.
• Ne touchez pas au sprint goal : c'est l'ancre qui empêche de construire vite la mauvaise chose.

Un bon Scrum Master, dans une équipe assistée par l'IA, ne défend pas ses cérémonies : il redirige l'attention de l'équipe vers l'endroit où le risque a migré. Le cadre ne change pas de nom. Il change de fonction.

À lire aussi

• Scrum n'est pas une religion. Voici quand l'abandonner, pour décider si le cadre est encore le bon outil, avant même de parler d'IA.
• No-code, low-code et automatisation : le guide 2026 pour décideurs, la même logique côté technologie : ce que ces outils font vraiment, et où ils vous piègent.

Dans les équipes où j'interviens, l'arrivée de l'IA ne pose presque jamais un problème d'outils : les outils, tout le monde les a déjà. Elle pose un problème de rituels devenus des habitudes, qu'on répète sans se demander à quoi ils servent maintenant. Remettre chaque rituel en face de sa fonction suffit souvent à ce qu'une équipe rapide redevienne une équipe fiable. Vous pouvez lire ce qu'en disent les équipes que j'ai accompagnées.