Une tâche, c'est deux choses différentes : sa complexité intrinsèque et le temps qu'il faut pour l'exécuter. L'IA réduit le deuxième. Elle ne touche pas au premier.

Un ticket "intégrer le webhook de paiement" garde sa difficulté de raisonnement : les cas d'échec, les race conditions, la cohérence des données. Ce qu'il perd, c'est les deux heures de boilerplate. L'IA est un multiplicateur de vélocité individuelle, pas un réducteur de complexité.

Le problème arrive quand le multiplicateur entre dans le chiffre. L'estimation agile repose sur un invariant implicite : deux tickets de 5 points demandent à peu près le même effort humain. Avec l'IA, un ticket de 5 points peut demander 20 minutes à un dev bien équipé et une journée à un autre. Le nombre ne mesure plus rien de stable.

L'exemple le plus documenté : une équipe de 3 devs sur Cursor raconte sur Scrum.org qu'ils ignoraient à quel point l'outil les accélérait. Ils ont ajouté du scope massivement à chaque sprint et atteint 150 points par sprint avec une micro-équipe. La réponse du trainer Thomas Owens est la leçon : soit tu recalibres ton effort contre une nouvelle base, soit tes points explosent. Et si tu changes de base, tu ne peux plus te fier à tes données historiques pour prévoir.

Ton historique de vélocité, la colonne vertébrale de ton planning, est devenu un artefact de 2024.

Et il y a plus sournois : le multiplicateur n'est pas uniforme. Sur du CRUD routinier, un junior équipé va 3x plus vite, son ticket de 3 points sort en 20 minutes. Sur une intégration complexe, un senior peut ne rien gagner, voire ralentir (c'est exactement ce que METR a mesuré : les devs les plus expérimentés sur leur codebase sont ceux que l'IA a le plus ralentis). Même nombre de points, réalité d'effort incomparable. Ton planning mélange maintenant deux populations dont la "vitesse par point" n'a plus de sens commun.

Pas de grande étude chiffrée sur la dérive des story points : le sujet est trop récent. Mais les pièces du puzzle convergent.

DORA 2025 (5 000 professionnels) : l'adoption IA améliore le throughput de livraison mais dégrade toujours la delivery stability. Le volume monte, les incidents avec. Traduction pour le planning : tu livres plus de tickets, pas plus de valeur, et le surplus se paie en stabilité.

METR (RCT, 246 issues, devs expérimentés) : +19% de temps réel là où les devs croyaient gagner 24% de temps. Le ressenti de vitesse n'est pas un chiffre de planification.

GitClear (623 millions de changements analysés) : refactoring effondré à 3,8%, duplication en hausse de 81%. Le code qui sort plus vite est du code qui coûte plus tard. Tes points de sprint ne mesurent pas ça.

La règle d'or de Ron Jeffries, co-signataire du manifeste agile et père des story points : "je pense que comparer les équipes sur la qualité des estimations ou la vélocité est nuisible". Il disait ça avant l'IA. L'IA a rendu son avertissement opérationnel.

Décision 1 : figure-toi que tes points mesurent la complexité, pas le temps.

La définition propre : un point = la difficulté de raisonnement du ticket (nombre d'inconnues, de dépendances, de cas d'échec). Elle ne bouge pas parce que le dev exécute avec Cursor ou Claude Code. Si tes points ont gonflé de 60 à 150, ce n'est pas l'équipe qui est devenue 2,5x plus complexe, c'est ta définition qui a glissé vers le temps.

Décision 2 : recalibre la base, pas les points.

Deux options assumées : soit tu recalibres (nouvelle base de vélocité post-IA, tes données historiques partent à l'archive), soit tu gardes tes points et tu acceptes que la vélocité monte sans signification. Ce qui ne marche pas : mélanger les deux, prévoir avec des données d'avant et des points d'après. C'est le piège décrit par Scrum.org.

Décision 3 : estime la conversation, pas le nombre.

La valeur du planning poker n'a jamais été le chiffre. C'est la discussion qui fait émerger ce que chacun sait et que personne n'a dit : "le module d'auth, il est délicat parce que...". Un LLM sait estimer un ticket mieux qu'un modèle entraîné sur l'historique (arXiv 2603.06276 : mieux que du deep learning supervisé en zero-shot), mais il prédit l'ordre des tickets, pas leur valeur exacte (corrélation ~0,40). Et il ne saura jamais que ton tech lead est nerveux sur le module d'auth. Garde la conversation, lâche le culte du chiffre.

Le chiffrage en double aveugle : chaque dev estime le même set de tickets isolément, avant la discussion. Tu compares les écarts : là où deux devs sont à 3 et 13 sur le même ticket, il y a une inconnue qui mérite 10 minutes de conversation. C'est le planning poker sans la réunion, et c'est le seul moyen de savoir si tes points mesurent encore quelque chose. Zéro outil nouveau, 20 minutes par sprint. Et si les écarts explosent sur les tickets où chacun pense "l'IA fera le gros du travail", tu as trouvé la fuite de ta vélocité.

Réponds-moi. Et la semaine prochaine : la gouvernance du code généré par IA, le contrat manquant entre l'IA qui écrit et l'équipe qui maintient.