L'année dernière j'ai vu un CTO promettre à son conseil d'administration qu'une fonctionnalité serait prête "pour la fin du Q2." J'étais dans la salle. Il a sorti cette date de nulle part. Je le sais parce que je bossais avec son équipe depuis deux semaines et c'était impossible — le backlog comptait 140 éléments, la vélocité de l'équipe partait dans tous les sens, et deux des cinq devs allaient partir en congé parental. Q2 est passé. La fonctionnalité a été livrée mi-août. Personne n'a été surpris sauf le conseil.
Ça arrive partout. Dans toutes les boîtes avec lesquelles j'ai travaillé. La question "ça sera prêt quand ?" a détruit plus de confiance entre l'ingénierie et le business que n'importe quel incident de production.
Et je comprends, hein. Les dirigeants ont besoin de dates. Les contrats ont besoin de dates. Le marketing ne peut pas annoncer "quelque part entre avril et on verra bien." Mais la solution n'est pas d'inventer un chiffre et de croiser les doigts. La solution c'est d'être honnête sur ce qu'on sait et ce qu'on ne sait pas.
C'est pour ça que j'ai construit un simulateur Monte Carlo de livraison. Pas parce que le monde avait besoin d'un outil agile de plus — dieu sait qu'il y en a assez — mais parce que j'avais sans arrêt la même conversation avec des engineering managers qui voulaient donner des dates réalistes et n'avaient aucune idée de comment faire.
Le chiffre qui a tout gâché
Voilà comment ça se passe en général.
Le PM demande : "le backlog sera fini quand ?" Le lead réfléchit un moment, ajoute une marge parce qu'il s'est déjà fait avoir, et dit "huit sprints." Le PM note. En parle au VP. Le VP en parle au client. Maintenant huit sprints c'est une promesse. Sauf que ça n'a jamais été une promesse — c'était l'intuition d'une personne un mardi après-midi après trop de café.
Et ça veut dire quoi "huit sprints" au juste ? Le meilleur cas ? La moyenne ? Le scénario où rien ne va mal et personne ne tombe malade et l'API dont on dépend ne change pas et le dev junior devient magiquement senior du jour au lendemain ? Quand j'insiste là-dessus les gens disent en général un truc du genre "euh, je dirais qu'on a de bonnes chances." Super. De bonnes chances. Mets ça dans le contrat.
Daniel Kahneman a appelé ça le biais de planification. On est programmés pour sous-estimer le temps que prennent les choses. Même quand on connaît ce biais, on tombe quand même dedans. Kahneman lui-même a admis qu'il y était tombé en écrivant le livre sur les biais cognitifs. Ça lui a pris des années de plus que prévu. L'ironie est presque trop parfaite.
Solitaire, bombes nucléaires et ton backlog de sprint
En 1946, un mathématicien polonais nommé Stanislaw Ulam se remettait d'une opération au cerveau (encéphalite, pas drôle du tout) et jouait beaucoup au solitaire. Il n'arrêtait pas de se demander : quelle est la probabilité que cette main gagne ? Il a essayé de le calculer analytiquement. Impossible. Trop de permutations. Et puis il a eu une de ces idées qui semblent évidentes après coup mais qui changent tout — et si je jouais simplement mille parties et que je comptais combien j'en gagne ?
Il en a parlé à son collègue John von Neumann. Von Neumann, parce que c'était von Neumann, a immédiatement vu l'application aux problèmes de diffusion de neutrons sur lesquels ils travaillaient à Los Alamos. Il fallait que le nom reste secret alors ils l'ont appelé "Monte Carlo" d'après le casino où l'oncle d'Ulam aimait jouer. Et c'est tout — c'est toute la technique. N'essaie pas de calculer la réponse exacte. Simule à fond et regarde ce qui se passe.
Pour la prévision de livraisons agiles c'est la même astuce, appliquée à tes données de sprint au lieu de réactions nucléaires en chaîne (en théorie moins stressant, mais certains daily meetings s'en rapprochent) :
- Tu prends le throughput de ton équipe sur les derniers sprints — combien d'éléments vous avez complétés à chaque fois
- Tu dis au simulateur combien d'éléments il reste
- Le simulateur pioche au hasard un throughput dans ton historique, le soustrait du travail restant, en pioche un autre, soustrait encore, et continue jusqu'à ce que le travail arrive à zéro
- Il fait ça 10 000 fois
- Il te dit : "sur 10 000 simulations, voilà combien de sprints ça a pris"
Pas de story points. Pas de planning poker. Pas de débats "mais une page de login c'est un 3 ou un 5 ?" à 9h un lundi matin. Juste tes données réelles, passées à travers de l'aléatoire, produisant une fourchette de résultats réalistes.
P50, P85, P95 — trois chiffres qui ont remplacé toutes nos disputes
Ce qui t'intéresse dans le résultat ce sont trois percentiles :
P50 — la moitié des simulations ont fini à ce sprint. Pile ou face. J'utilise ça pour la planification interne style "ce serait bien." Ne t'engage jamais là-dessus en externe.
P85 — 85% des simulations ont fini à ce sprint. C'est celui que je dis aux managers d'utiliser. Quand ton VP demande une date, c'est cette date-là. Pas l'optimiste. Celle-ci.
P95 — 95% des simulations ont fini à ce sprint. Contrats. Budgets. Tout ce où rater la date coûte de l'argent réel. Tu remplis jusqu'ici et tu dors tranquille.
Mais y'a un truc dont personne ne parle : l'écart entre P50 et P95 est l'information la plus précieuse de toutes. Si P50 dit 7 sprints et P95 dit 8, ton équipe est une machine. Régulière, prévisible, ennuyeuse de la meilleure façon. Si P50 dit 6 et P95 dit 14 ? T'as un problème qu'aucune technique d'estimation au monde ne résoudra. Ton throughput est chaotique et tu dois comprendre pourquoi avant de t'inquiéter du quand.
J'ai eu une équipe une fois où l'écart allait de 5 à 19. Dix-neuf sprints. Pour le même backlog. On a creusé et on a découvert que deux de leurs sprints avaient un throughput de zéro — toute l'équipe avait été aspirée par la gestion d'incidents les deux fois. Quand on a exclu ces données (c'étaient des événements ponctuels, pas la norme), l'écart est tombé de 6 à 9. Bien plus exploitable.
Ce que le code fait vraiment
Le simulateur tourne dans ton navigateur. Rien ne va vers un serveur. Je suis un peu obsessionnel là-dessus — si tes données de sprint peuvent rester sur ta machine, elles doivent rester sur ta machine. Elles sont stockées en localStorage aussi, donc tu n'as pas à tout retaper la semaine prochaine.
La boucle de simulation est presque honteusement simple :
for (let i = 0; i < iterations; i++) {
let remaining = totalItems;
let sprints = 0;
while (remaining > 0) {
// Pioche un sprint au hasard dans ton historique
const throughput = data[Math.floor(Math.random() * data.length)];
remaining -= throughput;
sprints++;
}
sprintCounts.push(sprints);
}
C'est... à peu près tout. Chaque itération pioche des valeurs de throughput aléatoires dans ton historique jusqu'à ce que le boulot soit fini, et enregistre combien de sprints ça a pris. Trie les 10 000 résultats, lit les percentiles. Les maths sont triviales. L'insight ne l'est pas.
Ce qui fait que ça marche c'est que ça ne lisse rien. T'as eu un sprint horrible où t'as fermé que 3 éléments ? Ça se retrouve dans l'échantillon. T'en as eu un incroyable où t'en as liquidé 20 ? Pareil. La simulation conserve toute la réalité moche de la performance de ton équipe au lieu de la planquer derrière une moyenne.
J'en avais marre des outils qui ne préviennent pas quand les données sont pourries
Un de mes plus gros reproches aux outils Monte Carlo que j'ai testés avant de construire le mien : ils avalent de la daube avec le sourire et recrachent un joli graphique plein d'assurance. Donne-leur deux points de données et ils te sortiront des P50/P85/P95 comme si ces chiffres voulaient dire quelque chose avec un échantillon de deux.
Alors j'ai intégré cinq vérifications qui te crient dessus quand tes données sont douteuses :
Si t'as que 2 ou 3 sprints — ça tourne, mais ça te prévient que les résultats sont globalement du bruit. Il te faut au moins 8-10 sprints pour que la loi des grands nombres commence à jouer en ta faveur.
Les sprints à throughput zéro sont signalés. Pas parce qu'ils sont invalides (les jours fériés ça arrive, les blocages ça arrive), mais parce que taper 0 au lieu de 10 par accident va massacrer ta prévision et tu risques de ne même pas t'en rendre compte.
Si un sprint affiche 50 éléments alors que ta médiane est à 12, l'outil le signale comme outlier probable. Peut-être que l'équipe a fermé en masse un paquet de vieux tickets. Peut-être qu'ils étaient vraiment aussi productifs. Dans tous les cas tu devrais regarder.
Si toutes tes valeurs sont identiques — mettons exactement 10 éléments chaque sprint — l'outil te dit en gros "tu n'as pas besoin de moi, la réponse c'est une division." Ce qui, bon, est vrai.
Et si ton coefficient de variation dépasse 50%, il te prévient que ton throughput est instable et que la fourchette va être large. C'est pas un problème d'outil. C'est un problème de process d'équipe. En général c'est des changements de périmètre en plein sprint, ou des gens tirés dans tous les sens, ou des dépendances vers d'autres équipes qui sont imprévisibles. Corrige la cause, puis lance la prévision.
Un exemple avec des vrais chiffres
Disons que les 10 derniers sprints de ton équipe ressemblaient à ça — et je choisis des chiffres réalistes, pas propres comme dans un manuel :
| Sprint | Fait |
|---|---|
| 1 | 8 |
| 2 | 12 |
| 3 | 10 |
| 4 | 7 |
| 5 | 14 |
| 6 | 11 |
| 7 | 9 |
| 8 | 13 |
| 9 | 6 |
| 10 | 11 |
80 éléments restants dans le backlog. Tu mets ça dans le simulateur Monte Carlo et tu lances.
P50 sort à 8 sprints. P85 à 9. P95 à 11.
Maintenant au lieu de dire au PM "environ 8 sprints je pense ?" tu dis : "on est à 85% de confiance que ce sera fait en 9 sprints. Si t'as besoin d'une garantie, planifie 11. Je ne promettrais pas moins de 9 à quelqu'un d'externe." Le PM a quelque chose avec quoi bosser. Quelque chose avec des niveaux de confiance attachés. S'il choisit de s'engager sur 9, il fait un pari éclairé, pas un pari à l'aveugle.
Et franchement la conversation change complètement. Au lieu de débattre pour savoir si 8 sprints c'est "suffisamment ambitieux" (une vraie phrase qu'un PM m'a sortie un jour, ça me hante encore), on parle tolérance au risque. Ce qui est ce dont la conversation aurait dû traiter depuis le début.
Story points, je t'aime, mais faut qu'on parle
J'ai utilisé les story points pendant des années. Fibonacci, tailles de t-shirt, tout le bazar. J'y croyais. J'ai même engueulé des gens sur Twitter pour ça. J'avais tort. Ou du moins, je passais à côté d'une meilleure option.
Les story points ont été inventés pour découpler l'estimation du temps. Tu estimes la complexité, tu mesures la vélocité, tu en déduis le calendrier. Élégant en théorie. En pratique ?
Les réunions d'estimation. Mon dieu, les réunions d'estimation. Quarante-cinq minutes à débattre si migrer le service d'auth c'est un 13 ou un 21. La dev senior pense que c'est un 13 parce qu'elle l'a déjà fait. Le junior pense que c'est un 21 parce qu'il a vu l'état du service d'auth. Ils ont tous les deux raison de leur point de vue et le chiffre sur lequel ils se mettent d'accord (en général c'est celui qui parle le plus fort qui gagne) n'aide personne à planifier quoi que ce soit.
Et la vélocité en points-par-sprint est bizarrement instable. Elle dérive. Les équipes calibrent inconsciemment leurs estimations pour atteindre un chiffre de vélocité qui semble plaire à leur manager. Je l'ai vu faire. Personne ne l'admet, mais ça arrive.
Monte Carlo esquive tout ça. Tu comptes les éléments faits par sprint. Pas des points, pas des heures. Des éléments. Fait ou pas fait. Binaire. L'entrée est objective et la sortie est probabiliste et toute la réunion d'estimation disparaît de ton agenda. Allen Holub et les gens de #NoEstimates disent ça depuis des années. Monte Carlo c'est les maths qui rendent leur argument concret.
Quand cette approche s'effondre
Je serais un mauvais ingénieur si je ne te disais pas quand NE PAS utiliser ça.
Ton backlog ne fait que grossir ? Monte Carlo ne peut pas t'aider. Si tu ajoutes 15 éléments par sprint et que t'en complètes 10, la seule prévision honnête c'est "jamais." Règle le flux entrant d'abord.
Ton backlog est un mélange incohérent d'éléments de tailles très différentes ? Un ticket c'est "corriger le typo de la page 404" et un autre c'est "refondre le parcours de paiement" ? Compter les éléments n'a aucun sens. Il faut découper jusqu'à ce que ce soit à peu près comparable. Franchement tu devrais déjà faire ça, mais Monte Carlo te force la main.
Ton équipe vient de changer radicalement ? Nouvelles recrues, départs, réorg ? Tes données historiques ne représentent pas ton équipe actuelle. Jette-les et recommence. Je sais que ça fait mal. La simulation suppose que le futur ressemble au passé. Si le passé n'est plus pertinent, la simulation non plus.
Backlog minuscule ? Genre 5 éléments ? La différence entre un "bon sprint" et un "mauvais sprint" est énorme par rapport au total. Monte Carlo marche mieux avec 30+ éléments restants où l'aléatoire se lisse sur beaucoup de sprints simulés. Pour 5 éléments, juste... fais-les. Tu verras quand c'est fini.
Pour commencer — ça prend 90 secondes
- Ouvre le simulateur Monte Carlo de livraison
- Entre le throughput des 8-10 derniers sprints (juste le nombre d'éléments faits par sprint — regarde ton Jira ou Linear si tu ne te rappelles plus)
- Entre le nombre d'éléments restants dans le backlog
- Lance
C'est tout. Reviens au prochain sprint, ajoute le nouveau chiffre, regarde comment la prévision évolue. Tes données restent dans ton navigateur — je n'ai même pas de serveur où les envoyer.
Si l'outillage agile t'intéresse, on a aussi construit une Calculatrice de Capacité de Sprint pour planifier combien de travail ton équipe peut vraiment absorber, un tableau de Priorisation MoSCoW pour quand il faut faire du tri impitoyable, et un générateur de Diagrammes de Flux Cumulé pour visualiser où le travail se coince. Tout gratuit, tout dans le navigateur, pas de compte.
Pour les nerds : ce qui se passe mathématiquement
(Passe cette section si les stats t'indiffèrent. Je ne jugerai pas.)
Ce qu'on fait c'est un rééchantillonnage bootstrap. On tire des échantillons avec remise d'une distribution empirique — ton historique de throughput — et on utilise ces échantillons pour estimer un paramètre qui nous intéresse, à savoir les percentiles de date de livraison. C'est non paramétrique, ce qui veut dire qu'on ne suppose pas que tes données suivent une loi normale ou une quelconque forme théorique. Tant mieux d'ailleurs, parce que les données de throughput de sprint ne sont quasiment jamais normales. Elles ont en général une asymétrie à droite avec des zéros occasionnels.
Pourquoi 10 000 itérations ? Avec 1 000 tes estimations de percentiles bougent un peu entre les exécutions. À 10 000 elles se stabilisent. À 50 000 tu dépenses du calcul pour une amélioration négligeable. Le théorème central limite garantit la convergence mais la vitesse dépend de la variance de tes données — les équipes avec des variations folles de throughput ont besoin de plus d'itérations pour converger. 10 000 c'est le sweet spot pour à peu près tout le monde.
Un choix de conception dont je suis content : la simulation utilise du rééchantillonnage discret (piocher au hasard de vrais sprints historiques) plutôt que d'ajuster une distribution continue. Certains outils supposent que le throughput suit une loi normale et échantillonnent à partir d'une Gaussienne ajustée. C'est plus propre mathématiquement mais c'est faux. Tes données ont une forme. Peut-être bimodale parce que tu alternes entre sprints de rush et sprints de récup. Peut-être avec une longue queue parce qu'une fois par an tout part en vrille. Le rééchantillonnage discret préserve la forme réelle de tes données. Pas d'hypothèses, pas de surprises.
La vérité inconfortable que cet outil révèle
Je termine avec quelque chose que j'ai remarqué après avoir vu des dizaines d'équipes utiliser ça.
L'outil ne te dit rien que tu ne savais pas déjà. Il rend juste impossible de l'ignorer.
Cet écart large entre P50 et P95 ? Toute l'équipe sentait déjà le chaos. Ils ne pouvaient juste pas le quantifier, alors ça n'est jamais devenu une discussion. Ces sprints outliers ? Les gens s'en souvenaient mais ne pouvaient pas expliquer pourquoi ça comptait pour la planif. Le fait que s'engager sur P50 c'est jouer à pile ou face ? Au fond tout le monde soupçonnait que la deadline était irréaliste. Personne n'avait les données pour pousser dans l'autre sens.
Monte Carlo prend la sensation floue que "nos estimations se plantent en général" et la transforme en "on est à 85% de confiance sur 9 sprints et voilà le graphique." Ça déplace la conversation des ressentis vers les probabilités. Et c'est là que les choses commencent à changer.
Si tu fais encore du planning poker à chaque sprint et que t'en ressors avec un chiffre auquel personne ne croit vraiment, essaie de lancer une simulation. Juste une fois. Mets tes vraies données et regarde ce que ça dit. Le pire qui puisse arriver c'est que ça confirme ce que tu savais déjà. Le mieux qui puisse arriver c'est que ça te donne les munitions pour avoir enfin une conversation honnête sur quand ce foutu truc sera livré.
Essaie ici. C'est gratuit. Tes données ne quittent pas ton navigateur. Et ça prend moins de temps qu'un tour de planning poker.