La Réunion Que Personne N'a Remise en Question
Imaginez une session de sprint planning : 14 personnes, trois heures, à découper le travail en tranches de deux semaines. Story points estimés. Dépendances discutées. Périmètre négocié. Ça semble productif — et en 2021, ça l'était.
Maintenant imaginez la même session aujourd'hui. Pendant que la salle débat des critères d'acceptation, un développeur ferme tranquillement son laptop. Il vient de livrer un module d'authentification complet via un agent IA. Ça lui a pris quarante minutes. (Savoir s'il devrait livrer aussi vite est une tout autre question.)
Ce contraste fracture quelque chose dans toute représentation mentale de la livraison logicielle.
Ce que les Sprints Résolvaient Vraiment
Le sprint de deux semaines n'a pas été inventé parce que deux semaines est une unité de temps magique. C'était un compromis — assez court pour rester concentré, assez long pour livrer quelque chose de concret compte tenu des limites cognitives humaines et du coût de coordination d'une équipe.
Les sprints résolvaient trois problèmes réels : ils créaient des forcing functions pour la priorisation, ils rendaient l'avancement visible, et ils donnaient aux équipes un rythme cardiaque commun.
Les agents IA n'ont pas de limites cognitives. Ils ne perdent pas le fil après le déjeuner. Ils ne bloquent pas sur une code review deux jours en attendant que quelqu'un revienne de congés.
Quand le goulot d'étranglement passe de l'exécution à la prise de décision, une cadence construite autour de l'exécution devient du surcoût.
Ce Qui Change Vraiment en ce Moment
Je ne décris pas un futur hypothétique. Les équipes utilisant des workflows agentiques — où l'IA gère l'implémentation pendant que les humains gèrent la direction — reportent déjà des cycles de livraison mesurés en heures, pas en jours. (Pour la version quotidienne, voyez comment les Product Owners utilisent vraiment l'IA générative.)
Une étude de GitHub(lien externe, nouvel onglet) a montré que les développeurs utilisant Copilot accomplissaient leurs tâches 55% plus vite en moyenne. Et ce chiffre n'a fait qu'augmenter. Certaines équipes rapportent des livraisons complètes — de la spec au code déployé — en moins d'une journée pour un travail bien cadré.
Le sprint supposait que écrire du code était la partie difficile. Il a construit sa cérémonie autour de cette hypothèse. Maintenant que l'écriture de code est largement automatisée, la partie difficile est ailleurs : décider quoi construire, pour qui, et pourquoi.
C'est un problème produit. Ça l'a toujours été — on avait juste le luxe de le cacher dans un problème de livraison.
Ce que SAFe Réussit (et Où Il Se Fracture)
Je suis Product Owner certifié SAFe(lien externe, nouvel onglet). Je crois en l'intuition centrale du framework : l'alignement à l'échelle exige des structures de coordination explicites. On ne peut pas avoir cinquante équipes qui sprintent dans des directions différentes et appeler ça de l'agilité.
Mais la cadence de SAFe — PI Planning tous les 10 semaines, sprints toutes les 2 semaines, inspect-and-adapt chaque trimestre — a été conçue pour un monde où l'implémentation prend du temps. Quand un sprint devient une unité de décision plutôt qu'une unité de travail, les calculs changent.
Un sprint de deux semaines qui se livre en 40 minutes crée 13 jours de cérémonie pour 40 minutes de production. Ce n'est plus de l'agilité — c'est du théâtre.
Les équipes qui gagnent aujourd'hui n'abandonnent pas la structure. Elles la compriment. Priorisation quotidienne plutôt que planning bi-hebdomadaire. Déploiement continu plutôt que sprint reviews. Points sur les outcomes plutôt que démos.
Ce Que Ça Signifie pour les Product Owners
Le rôle de PO était déjà difficile. Il est sur le point de le devenir davantage — mais différemment.
Quand votre équipe peut livrer une fonctionnalité en quelques heures, vous devez être prêt à décider en quelques heures. Le goulot d'étranglement n'est plus "quand est-ce que ce sera prêt" — c'est "doit-on vraiment construire ça, et qu'est-ce que 'terminé' veut dire."
Cela exige un travail de discovery plus affûté, des boucles de feedback plus rapides avec les utilisateurs, et une définition bien plus claire de la valeur — exactement l'état d'esprit « résultats avant fonctionnalités » qui distingue les bons POs des administrateurs de backlog. Il faut des Product Owners capables de tenir le fil stratégique pendant que la couche d'exécution s'accélère sous eux.
Le sprint nous offrait un forcing function. Sans lui, il nous en faut un autre : un focus obsessionnel sur les outcomes, avec la discipline d'éliminer ce qui ne fait pas bouger les métriques — même si l'IA peut le livrer en une après-midi.
Le Takeaway
Le sprint de deux semaines n'est pas mort. Mais il est dépassé par la réalité qu'il était censé gérer. Commencez par vous demander ce que votre cérémonie de sprint résout vraiment — et s'il n'existe pas une structure plus légère qui le résout plus vite.
Pour aller plus loin sur ce à quoi ressemble le vrai leadership agile dans des environnements incertains, ces 5 leçons du terrain restent d'actualité — même quand la cadence évolue.
