Une simulation de Monte-Carlo ne montre pas une date de fin, mais une probabilité. Avec le nouveau serveur MCP dans Merlin Project, vous demandez à Claude en une phrase de lire votre plan et de calculer 10 000 scénarios de projet. Voici comment procéder.
Une simulation de Monte-Carlo traduit l'incertitude en probabilité. Au lieu d'une date unique, vous obtenez une distribution de dates de fin possibles. Avec le serveur MCP dans Merlin Project, cela ne nécessite plus d'extension spécialisée ni d'estimations laborieusement entretenues ; une seule phrase adressée à Claude suffit.
Ce qu'est exactement une simulation de Monte-Carlo et pourquoi elle surpasse le chemin critique, c'est ce qu'explique notre guide de Monte-Carlo en gestion de projet. Ici, place à la pratique : comment effectuer concrètement la simulation avec Merlin Project et le serveur MCP.
Merlin Project et le serveur MCP
Merlin Project intègre un serveur MCP. MCP signifie Model Context Protocol, un standard ouvert qui offre aux assistants IA une connexion structurée et sécurisée vers des applications externes. Le serveur tourne localement sur votre Mac et n'est pas accessible à distance ; de lui-même, il ne téléverse rien et ne divulgue que ce que l'IA interroge activement. Ce que l'IA lit, elle le traite toutefois chez le fournisseur concerné : avec un client cloud comme Claude, les données de plan lues sont transmises à son API. Vous gardez le contrôle sur le projet que vous partagez, tout à fait dans l'esprit de la souveraineté numérique. Vous l'activez projet par projet via le bouton « Outils IA » dans la barre d'outils du document. La configuration complète pour Claude Desktop, Claude Code et d'autres clients figure dans la documentation MCP.
L'accès en lecture suffit
Le serveur MCP offre actuellement un accès en lecture seule aux données du projet. Pour une simulation de Monte-Carlo, c'est exactement ce qu'il faut : le client ne peut que lire le plan, rien dans le plan ne peut être modifié. La simulation ne lit le plan qu'une seule fois ; tout le calcul stochastique se déroule en dehors de Merlin. Rien n'est réécrit dans le plan en cours. Votre structure de projet reste la source unique de vérité, intacte, et vous pouvez simuler autant de fois que vous le voulez, sur n'importe quel état du plan.
Du plan, l'IA lit trois choses. D'abord les tâches avec leur durée planifiée. Ensuite la logique du diagramme de réseau, c'est-à-dire les dépendances entre prédécesseur et successeur, avec leur type de liaison et leur marge. Enfin la localisation de l'incertitude, c'est-à-dire à quelle tâche un risque est rattaché. La logique du diagramme de réseau en est le cœur : sans les arêtes de dépendance, vous ne feriez qu'additionner des durées au lieu de calculer un diagramme de réseau.
Le point sensible : l'incertitude n'est pas encore dans le plan
Merlin enregistre pour chaque tâche une durée planifiée et, plus tard, une valeur réelle, mais pas d'estimation à trois points native. Il existe trois façons de résoudre cela :
- Champs personnalisés. Vous créez O et P comme champs personnalisés dans le modèle et les lisez aussi via MCP. La solution la plus propre, si vous maîtrisez le modèle.
- Bande d'incertitude globale. La durée planifiée plus ou moins X pour cent sous forme de triangle ou de PERT, mise à l'échelle au besoin selon la phase ou le type de tâche.
- Hybride. Les tâches à risque annotées reçoivent leur propre bande, le reste une valeur par défaut.
Quelle que soit la voie choisie : montrez en toute transparence d'où vient l'incertitude. C'est précisément ce qui rend une simulation crédible.
Le déroulement agentique, et l'erreur de raisonnement à éviter
C'est ici que se niche l'erreur la plus fréquente : Claude ne parcourt pas lui-même les 10 000 itérations. Aucun modèle de langage ne tire 10 000 échantillons aléatoires de tête. Ce serait non seulement gourmand en tokens, mais statistiquement sans valeur, car les modèles de langage sont de mauvais générateurs d'aléa. Les itérations relèvent du code.
L'astuce n'est pas « un script Python contre un client MCP », mais l'exécution de code par le client. Le déroulement comporte trois étapes :
- Lire. Claude appelle les outils de lecture du serveur MCP de Merlin et récupère les tâches, les durées et les dépendances.
- Calculer. Claude écrit lui-même la simulation en quelques lignes de numpy et l'exécute, dans le cadre de sa réponse. Cela nécessite un client capable d'exécuter du code, comme Claude Code ; une simple fenêtre de chat sans exécution de code ne peut pas exécuter les itérations. À chaque itération, le modèle tire une durée pour chaque tâche, parcourt le diagramme de réseau dans l'ordre topologique (en tenant compte des prédécesseurs et des décalages) et retient comme fin de projet la fin la plus tardive de tous les nœuds terminaux.
- Expliquer. Claude restitue la courbe en S, P50, P80 et P90 ainsi qu'un diagramme en tornade, et interprète le résultat dans un langage compréhensible.
De votre point de vue, le récit est simple. Vous posez une question en langage naturel :
Lis le projet actif dans Merlin Project et simule 10 000 scénarios de projet
possibles. Prends pour chaque tâche la durée planifiée plus/moins 20 pour cent
comme distribution PERT. Montre-moi la courbe en S et les dates pour P50, P80 et P90.Claude lit le plan, calcule et vous montre la courbe de probabilité. Le code sous-jacent est un détail d'implémentation, pas une étape d'apprentissage. C'est comme avec une calculatrice : vous l'utilisez au lieu de multiplier de tête.
D'ailleurs, ce ne sont pas les itérations qui sont gourmandes en tokens (en code, elles sont quasiment gratuites), mais le fait de charger dans le contexte une liste de 300 lignes de tâches. Pour débuter, la règle est donc : un plan d'exemple délibérément petit et propre, de 15 à 25 tâches. C'est assez grand pour une convergence des chemins et un tornade intéressant, et assez petit pour que toute la conversation tienne sur un écran.
Le résultat de 10 000 simulations
Voici à quoi ressemble la réponse de Claude au prompt ci-dessus, calculée sur un petit plan de projet de construction. Claude se connecte au document actif, lit les tâches, les liaisons (26 fois fin-début, une fois début-début) et le calendrier (du lundi au vendredi, 8 heures par jour), reconstitue le réseau et le valide par rapport à la date de fin planifiée. Le modèle la reproduit exactement : 60 jours ouvrés, soit le 21.08.2026. Puis les 10 000 simulations se déroulent.
Ce projet d'exemple ne comprend qu'une vingtaine de tâches, dont le délai est déterminé par une longue chaîne en série. La plage entre P10 et P90 est donc volontairement étroite, d'environ une semaine ; les projets plus grands ou plus ramifiés présentent généralement une dispersion nettement plus large.
| Confiance | Date | Par rapport au plan (21.08.) |
|---|---|---|
| Date planifiée | 21.08.2026 | environ 49 pour cent de probabilité d'atteinte |
| P50 | 24.08.2026 | plus 1 jour ouvré |
| P80 | 25.08.2026 | plus 2 jours ouvrés |
| P90 | 26.08.2026 | plus 3 jours ouvrés |
L'amplitude sur l'ensemble des 10 000 simulations va du 17.08. au plus tôt jusqu'au 01.09. au plus tard.
La lecture est sans ambiguïté : la date planifiée est une date à 50/50. Dans environ la moitié des simulations, elle est tenue, dans l'autre moitié, dépassée. C'est le constat typique, car une planification déterministe atterrit presque toujours sur le P50 optimiste, et non sur une date de livraison fiable. Qui veut s'engager avec 90 pour cent de certitude communique le 26.08., soit environ trois jours ouvrés de marge.
Claude expose ses propres hypothèses : ici, la durée planifiée a servi de valeur la plus probable, avec O à −20 pour cent et P à +20 pour cent sous forme de distribution PERT-Bêta symétrique. Avec les vraies estimations à trois points du plan, parfois nettement asymétriques, la traîne droite s'allongerait et P90 serait plus tardif. Les événements de risque discrets, la défaillance du fournisseur et l'indisponibilité de l'ingénieur structure, ne sont pas encore modélisés ici ; il s'agissait de pure dispersion de durée. C'est précisément ce que nous calculons dans les deux exemples suivants.
Exemple A : la comparaison de fournisseurs
L'exemple le plus fort répond à une question de décision, pas seulement à une question de pronostic. Imaginez une tâche qui dépend d'une livraison. Le fournisseur A livre, d'expérience, à l'heure dans une partie des cas, sinon avec quelques jours de retard. Le dénominateur compte ici : 10 livraisons en retard sur 100 ne représentent pas le même risque que 10 sur 15. C'est précisément là que Monte-Carlo montre sa force, car il ne calcule pas avec des hypothèses en l'air, mais traduit un historique de livraisons vécu en pronostic.
La véritable valeur ajoutée, c'est l'arbitrage argent contre risque. Le fournisseur A est moins cher, mais moins fiable ; le fournisseur B est plus cher, mais stable, et coûte 4 000 euros de plus. Le surcoût en vaut-il la peine ? Cette question, une direction la comprend immédiatement, et Monte-Carlo y répond par un chiffre plutôt que par une intuition.
Une telle question, vous la posez à Claude en une phrase :
La tâche 19 « Matériau posé » dépend d'une livraison. Le fournisseur A livre
d'expérience à l'heure dans 85 pour cent des cas, sinon avec 10 jours de retard.
Simule l'effet sur la date de fin, et compare avec le fournisseur B, qui livre
toujours à l'heure, mais coûte 4 000 euros de plus.Claude rattache l'interrupteur de risque à la livraison et calcule les deux fournisseurs avec les mêmes tirages aléatoires (Common Random Numbers), afin que la différence ne tienne proprement qu'à la livraison. Le résultat est étonnamment net (jo désigne les jours ouvrés) :
| Confiance | Fournisseur A (85 % à l'heure, sinon +10 jo) | Fournisseur B (toujours à l'heure, +4 000 €) |
|---|---|---|
| P50 | 21.08.2026 | 21.08.2026 |
| P80 | 25.08.2026 | 25.08.2026 |
| P90 | 25.08.2026 | 25.08.2026 |
| Date planifiée tenue | 50,5 % | 50,5 % |
| Glissement de fin dû à A | 0,00 % | Référence |
Dans aucune des 10 000 simulations, le fournisseur A peu fiable ne décale la date de fin. Les deux distributions se superposent. La raison se trouve dans le plan : la tâche 19 « Matériau posé » dépend de deux prédécesseurs, la livraison et la toiture sur le chemin critique. La toiture se termine systématiquement plus tard, donc « Matériau posé » attend de toute façon la toiture, pas la livraison de la façade. Entre la livraison et la pose, il y a en médiane 21 jours ouvrés de marge, et même dans la simulation la plus comprimée encore bien 17. Un retard de 10 jours ouvrés n'atteint jamais cette limite.
On le voit le mieux dans la sensibilité : de quelle ampleur le retard devrait-il être pour seulement déplacer la date de fin ?
Ce n'est qu'au-delà de cette marge, soit au-delà d'environ 17 à 21 jours ouvrés, que quelque chose commence à percer : à 25 jours, 7 pour cent des simulations glissent, à 30 jours environ 15. La décision de coût est donc claire. Les 4 000 euros pour le fournisseur B n'achètent, sous ces hypothèses, aucun gain de délai, le retard évité attendu est de 0,0 jour ouvré. Du seul point de vue du planning, le fournisseur A est le choix rationnel ; l'argent serait payé pour un risque que le plan absorbe déjà via sa marge. B ne devient intéressant que si une hypothèse se déplace : si le retard devient nettement supérieur à 10 jours (un conteneur d'importation au lieu d'une livraison régionale), si le gros œuvre se termine bien plus tôt et que la marge se réduit, ou si des jalons intermédiaires assortis de pénalités contractuelles pèsent sur la branche façade. C'est précisément ce qu'un plan purement déterministe ne pourrait jamais montrer.
Une note honnête en marge : les deux exemples sont des simulations distinctes, chacune avec ses propres interrupteurs de risque. Un jour d'écart sur la date de base par rapport à la courbe en S plus haut relève du bruit d'échantillonnage normal, pas d'une contradiction. Monte-Carlo estime une distribution, ce n'est pas une calculatrice à décimales fixes.
Exemple B : la défaillance de ressource
Le deuxième exemple agit sur un autre levier : non sur la durée, mais sur un événement discret. Une ressource clé pourrait faire défaut, ici l'ingénieur structure, qui travaille sur deux tâches, l'étude de structure porteuse tôt dans le projet et la réception statique tard. Fait-il défaut, et si oui, quel moment frappe le plus fort ?
Simule mon projet pour trois cas : la ressource « Ingénieur structure » ne fait pas
défaut, fait défaut en semaine 3 pendant 10 jours, fait défaut en semaine 8 pendant
10 jours. Montre-moi pour chacun P50/P80/P90 et quel moment de défaillance frappe le
plus la date de fin.Là encore, Claude calcule les trois cas avec les mêmes tirages aléatoires, afin que les différences ne tiennent proprement qu'à la défaillance :
| Cas | P50 | P80 | P90 | Décalage |
|---|---|---|---|---|
| Aucune défaillance | 21.08.2026 | 25.08.2026 | 25.08.2026 | Base |
| Défaillance précoce (étude de structure) | 04.09.2026 | 08.09.2026 | 08.09.2026 | +10 jo |
| Défaillance tardive (réception statique) | 02.09.2026 | 04.09.2026 | 07.09.2026 | +8 jo |
Les deux défaillances dépassent à coup sûr la date planifiée, la probabilité d'atteinte chute de 50 à 0 pour cent. La différence est intéressante : la défaillance précoce frappe plus fort. Dans 100 pour cent des simulations, elle décale la date de fin plus loin que la tardive, en moyenne de 2 jours ouvrés. La raison tient de nouveau à la situation de marge, pas au moment en soi. L'étude de structure porteuse est pleinement sur le chemin critique, sans marge ; ses dix jours de défaillance percent au rapport de 1:1, soit un net plus 10 jours ouvrés dans chaque simulation. La réception statique, en revanche, puise une petite marge résiduelle dans une branche parallèle, qui absorbe deux des dix jours avant qu'elle ne devienne elle-même la tâche contraignante. Il reste plus 8 jours ouvrés.
C'est la leçon concrète de l'exemple B : une défaillance de même durée coûte différemment selon la marge dont dispose la tâche concernée. Remplacement, anticipation et réserve doivent aller d'abord aux ressources sur le chemin critique, celles qui n'ont aucune marge.
Chemin critique contre marge : la chute commune
Les deux exemples disent au fond la même chose : ce n'est pas le risque seul qui décide, mais l'endroit où il se situe dans le diagramme de réseau. Le même retard ne coûte rien sur une tâche dotée de marge et coûte tout sur le chemin critique. Monte-Carlo ne montre justement pas « le retard, c'est mauvais », mais quand un risque perce et quand le plan l'absorbe. C'est pourquoi le fournisseur bon marché de l'exemple A était le choix rationnel et la défaillance précoce de l'exemple B le choix coûteux : dans le premier cas, une marge intercepte le risque, dans le second, elle fait défaut. Comment ajuster précisément le chemin critique dans Merlin Project, c'est ce que montre ce tutoriel.
Faites l'essai
La technique derrière Monte-Carlo a des décennies. Ce qui est nouveau, c'est sa simplicité d'aujourd'hui. Avec le serveur MCP de Merlin Project, votre plan se présente déjà sous une forme qu'une IA peut lire et calculer. Une extension spécialisée avec son propre entretien de données se réduit à une phrase adressée à Claude.
Si vous utilisez déjà Merlin Project, activez le serveur MCP pour un projet et posez votre première question. La configuration figure dans la documentation MCP. Si vous ne connaissez pas encore Merlin Project, découvrez-le sur la page produit ou téléchargez-le directement pour l'essayer.
Et personne n'a besoin de rédiger les résultats à la main. Sur demande, Claude réunit toute la simulation dans un rapport prêt à partager avec vos parties prenantes. Le rapport complet de ce projet d'exemple le montre : Télécharger le rapport Monte-Carlo (PDF, en anglais).
Si vous avez des questions sur cet article de blog ou si vous souhaitez en discuter, nous attendons avec impatience votre contribution dans notre forum.
Questions fréquentes
Ai-je besoin de connaissances en programmation pour une simulation de Monte-Carlo avec le serveur MCP ?
Non. Vous posez votre question en langage naturel, et Claude écrit lui-même la simulation en code et l'exécute. La seule condition est un client capable d'exécuter du code, comme Claude Code.
La simulation réécrit-elle des modifications dans mon plan Merlin Project ?
Non. Pour la simulation, le simple accès en lecture suffit. L'IA lit le plan une seule fois, calcule en dehors de Merlin et ne réécrit rien dans le plan en cours. Votre structure de projet reste intacte.
Quel client me faut-il pour calculer la simulation ?
Un client MCP capable d'exécuter du code, par exemple Claude Code. Une simple fenêtre de chat sans exécution de code ne peut pas calculer les 10 000 itérations.
Mes données de projet sont-elles en sécurité avec le serveur MCP ?
Le serveur MCP lui-même tourne localement sur votre Mac et n'est pas accessible à distance ; de lui-même, il ne téléverse rien. Ce que l'IA lit, elle le traite toutefois chez le fournisseur concerné : avec un client cloud comme Claude, les données de plan lues sont transmises à son API. Vous décidez par projet ce que l'IA a le droit de voir, et rien n'est réécrit dans le plan.
Quelle taille mon plan devrait-il avoir pour débuter ?
Un plan délibérément petit, de 15 à 25 tâches, est idéal : assez grand pour une convergence des chemins et un tornade intéressant, assez petit pour que toute la conversation reste claire.
