Ce cas suit notre processus établi de vérification par cas publics, et non un nouveau format de démonstration ; aucun mode produit spécifique à ce cas n'a été ajouté. À partir de l'étude de cas publique officielle d'IBM Consulting, nous isolons d'abord les réponses de la phase finale, puis nous reconstituons uniquement les informations disponibles au moment de la décision au sein d'un jeu de données pédagogique. Minerva Advisor a réalisé une exécution en direct payante, et cette vidéo est la relecture vérifiée d'une véritable Decision Room. Il s'agit d'une simulation pédagogique indépendante construite à partir d'une source publique. Cela n'implique pas qu'IBM Consulting ait utilisé, examiné, approuvé, parrainé, certifié ou commandité Minerva Advisor, et cela ne représente ni une correspondance réelle ni des résultats réels obtenus par un client.

Le cas s'ouvre sur un grand distributeur dont l'infrastructure commerciale existante ne pouvait plus supporter de manière fiable le trafic, lorsque la demande liée à la pandémie a fait passer le volume d'environ sept mille visiteurs par minute à un pic de dix-neuf mille. Minerva devait arbitrer entre deux voies : s'engager immédiatement dans une modernisation complète de la plateforme avec une bascule unique, ou d'abord mettre en place un palier de stabilisation de la capacité et de collecte de preuves de migration, limité dans le temps et interruptible, afin de déterminer le périmètre avant d'aller plus loin.

L'exécution laisse un reçu de travail auditable en cinq points. Premièrement, elle s'appuie sur une source unique vérifiée. Deuxièmement, elle identifie quatre rôles consultatifs distincts. Troisièmement, elle sépare les faits confirmés des inférences et des questions ouvertes. Quatrièmement, elle compare exactement deux voies concurrentes, côte à côte. Cinquièmement, elle conserve trois explications alternatives et une condition de renversement explicite, de sorte que chaque jugement puisse être retracé jusqu'à ce qui était connu, ce qui était supposé et ce qui restait ouvert.

Voici ce qui était connu et inconnu au moment de la décision. Connu : l'infrastructure existante, la hausse de la demande en ligne, et la panne survenue en période de pic. Inconnu : dans quelle mesure chaque facteur, capacité, actualité des versions, charge de la base de données, intégration, recherche, paiement ou supervision, a contribué à cette panne, quelles dépendances pouvaient être isolées, s'il existait une voie de récupération viable, et combien de temps une stabilisation à court terme pouvait réalistement gagner avant le prochain pic.

Le système conserve son contre-argument le plus fort. La panne pourrait résulter de plusieurs facteurs interagissant simultanément, si bien que le palier de collecte de preuves pourrait ne jamais isoler une couche unique, propre et corrigible. La condition de renversement est explicite : si les mesures de stabilisation ne peuvent pas tenir de manière fiable jusqu'à la prochaine fenêtre de pic, et qu'aucun gain diagnostique n'est obtenu quant aux sous-systèmes réellement en cause, la décision doit basculer immédiatement vers une modernisation par phases plutôt que de continuer à attendre.

La réponse publiée a été exclue des données reçues par Minerva. Le récit ultérieur d'IBM Consulting décrit la méthodologie Garage, IBM Cloud et Red Hat OpenShift, plus d'un an de construction et de tests, une bascule d'infrastructure et de version réalisée en un seul week-end, zéro incident, la prise en charge de plus de vingt-sept mille visiteurs au pic, et une croissance du chiffre d'affaires sur deux ans supérieure à cent quinze pour cent. Rien de tout cela n'est entré dans les données de décision. Minerva n'a vu ni la pile technologique retenue, ni le résultat obtenu.

Trois conseillers valident ensuite un même jugement sous des angles différents. Marcus formule la véritable décision comme la question de savoir si un palier de stabilisation fiable peut être établi avant le prochain pic. Sofia retrace les conséquences pour le commerce numérique, la fiabilité de la plateforme, les opérations client et les décideurs. Evelyn interroge si la stabilisation à court terme ne fait que différer le problème architectural sous-jacent, en notant que les problèmes de capacité, de base de données, de recherche et de paiement peuvent s'amplifier mutuellement, si bien qu'exiger une cause racine unique avant d'élargir la migration risque de manquer entièrement la fenêtre disponible. Les trois convergent vers la même recommandation : adopter d'abord le palier de stabilisation et de collecte de preuves, limité dans le temps et interruptible.

C'est ici que le système montre si l'apport du dirigeant modifie le jugement. Le dirigeant introduit une condition : d'abord quantifier la prochaine fenêtre de pic et le niveau de défaillance tolérable ; si la stabilisation à court terme ne peut pas couvrir cette fenêtre, accélérer sans délai une migration à périmètre limité et réversible. Minerva enregistre un reçu de réponse formel. La recommandation sous-jacente reste inchangée, mais la condition de renversement est renforcée et explicitement liée au temps.

En comparant directement les deux options : la modernisation complète immédiate s'attaque de front au problème architectural, mais avec des dépendances et des voies de récupération encore incertaines, une bascule unique et massive comporte un risque client élevé. La stabilisation de la capacité assortie d'un palier de collecte de preuves de migration permet de fonder les décisions de périmètre sur des preuves progressives, au prix d'une pression persistante en période de pic à court terme. Le dirigeant choisit la voie de la stabilisation tout en préservant explicitement une sortie vers une migration accélérée si les preuves s'y opposent.

L'action engagée : dans un délai de trois semaines, les équipes de commerce numérique et de fiabilité de la plateforme doivent quantifier les causes racines de la panne, définir la prochaine fenêtre de pic, cartographier les dépendances et confirmer les voies de récupération, l'ensemble constituant le seuil de décision pour élargir ou non vers une migration complète. Minerva n'affirme ni qu'une plateforme cloud a été choisie, ni qu'une bascule a eu lieu, ni que des résultats de croissance ont été obtenus.

Ce cas public IBM Consulting a réussi dix contrôles de qualité de décision sur dix. La Decision Room a utilisé quatre appels de modèle, livrant sa première décision en 17,762 secondes et achevant la validation croisée complète des trois conseillers en 24,513 secondes, respectant ainsi le seuil de trente secondes pour la première décision et le seuil de quarante-cinq secondes pour le résultat complet. La qualité et la rapidité de la décision ont toutes deux été validées, mais il s'agit d'un test portant sur un seul cas, non équivalent à des standards de service en production ni à des résultats clients réels.