La pratique
La question « quand est-ce que ce sera fini ? » revient dans toutes les équipes. La réponse habituelle consiste à estimer chaque élément, additionner, puis diviser par une vélocité. Le résultat est une date unique, qui donne une fausse impression de précision et ne dit rien du risque.
La simulation Monte Carlo part d'une autre donnée : le throughput, c'est-à-dire le nombre d'éléments terminés par semaine ou par sprint. Cette donnée existe déjà dans votre outil de suivi, elle ne coûte aucune réunion et elle intègre naturellement les aléas que l'équipe a vécus : absences, interruptions, imprévus techniques.
Le principe en trois étapes
- On relève le passé. Par exemple, sur douze semaines : 3, 5, 2, 6, 4, 5, 3, 4, 1, 6, 4, 5 éléments terminés.
- On simule un futur. Pour chaque semaine à venir, on tire au hasard une de ces valeurs, jusqu'à vider le backlog. On note le nombre de semaines nécessaires.
- On recommence dix mille fois, puis on lit la répartition des résultats : dans quelle proportion des futurs simulés le travail est-il terminé à telle date ?
Lire le résultat
Avec l'historique ci-dessus, un backlog de 40 éléments et un démarrage le lundi 12 octobre 2026, l'outil donne :
| Confiance | Durée | Fin au plus tard le |
|---|---|---|
| 50 % | 10 semaines | 21 décembre 2026 |
| 70 % | 11 semaines | 28 décembre 2026 |
| 85 % | 12 semaines | 4 janvier 2027 |
| 95 % | 13 semaines | 11 janvier 2027 |
La date à 50 % est un pile ou face : une fois sur deux, elle sera dépassée. Pour un engagement, on retient plutôt 85 %. L'écart entre les deux mesure l'incertitude réelle de l'équipe : plus le throughput est irrégulier, plus il s'élargit.
On ne dit plus « ce sera fini le 21 décembre », mais « nous avons 85 % de chances d'avoir terminé le 4 janvier ». La discussion porte alors sur le niveau de risque acceptable, et non plus sur la qualité des estimations.
La question inverse : combien ?
Quand la date est imposée (un salon, une fin d'exercice, une mise en production planifiée), on retourne le calcul : combien d'éléments seront terminés d'ici là, avec 85 % de confiance ? C'est souvent la question la plus utile pour arbitrer un périmètre. L'outil propose les deux modes.
Quand l'utiliser
La méthode repose sur une hypothèse simple : le futur proche ressemble au passé récent. Elle est donc fiable dans certains contextes et trompeuse dans d'autres.
Elle convient
- Équipe stable depuis au moins 8 à 10 périodes
- Éléments de taille comparable, découpés finement
- Besoin d'annoncer une date ou un périmètre à un client ou un comité
- Suivi de l'avancement d'une release, semaine après semaine
Elle trompe
- Équipe qui vient de se former ou de changer de composition
- Backlog mêlant petites tâches et chantiers de plusieurs semaines
- Changement de contexte majeur à venir (nouvelle technologie, réorganisation)
- Backlog qui grossit plus vite qu'il ne se vide
Deux règles pratiques : comptez ce qui est réellement terminé (pas ce qui est « presque fini »), et relancez la prévision chaque semaine. Une prévision Monte Carlo n'est pas un engagement figé : c'est un instrument de pilotage qui se recale à mesure que les données arrivent.
Retour d'expérience terrain
Le contexte
J'arrive dans une équipe et je prends connaissance de tous les sujets en cours. L'un d'eux, nouveau, a déjà démarré : il sort à peine de sa phase de cadrage, et une roadmap a déjà été posée.
Je constate rapidement que ce sujet dérive. Le suivi manque, mais surtout, la vision de la quantité de travail restante est erronée : au regard des fonctionnalités qui restent à livrer, les dates de la roadmap ne tiennent pas.
La mise en place
Les premières données venaient d'un suivi sous Excel. Nous avons ensuite créé les stories dans Jira, qui a pris le relais. L'historique était court, de six à huit semaines, en deçà de ce que je recommande plus haut : c'est en relançant la prévision régulièrement, à mesure que les semaines s'ajoutaient, qu'elle s'est consolidée.
Ce que ça a changé
Dire « nous serons en retard » sans autre argument, c'est opposer un avis à un autre. La prévision m'a permis de partager une nouvelle vision de l'atterrissage, appuyée sur ce que l'équipe livrait réellement, et de faire prendre conscience aux parties prenantes de l'état réel du sujet. Il n'y a pas de magie : au rythme observé, les livrables arriveraient après les dates du prévisionnel.
Une fois ce constat partagé, la discussion a changé de nature. On ne défendait plus une date, on construisait un plan : nous avons défini une roadmap trimestrielle plus réaliste.
Le découpage
La prévision suppose des éléments de taille comparable. Le travail de découpage a donc été repris à plusieurs reprises, jusqu'à obtenir des sujets engageants et réalisables dans des cycles courts. C'est ce découpage qui a rendu la prévision fiable, et la nouvelle roadmap tenable.
Limites à garder en tête
- Le futur ressemble au passé. Si l'équipe change fortement, l'historique ne vaut plus rien.
- Les éléments ont une taille comparable. Un élément géant fausse la prévision : découpez-le d'abord.
- Le calendrier n'est pas connu de l'outil. Congés, jours fériés et pics de charge à venir doivent être pris en compte dans la date de départ ou la date cible.
- Une probabilité n'est pas une promesse. Mettez la prévision à jour chaque semaine et partagez-la avec son niveau de confiance.