Ce que Thinking in Bets m’a appris sur les post-mortems IT
En 2018, Maersk et IBM ont pris la meilleure décision possible avec l’information disponible. En 2022, ils ont tout arrêté. Depuis, tout le monde explique pourquoi c’était une erreur. C’est là que ça devient intéressant. Confondre un mauvais résultat avec une mauvaise décision est le biais le plus répandu dans nos post-mortems IT, et personne ne s’en méfie vraiment.
La scène que vous connaissez
Le projet est mort. La réunion s’ouvre. Quelqu’un sort un retroplanning, un autre sort les KPIs initiaux, un troisième commence à lister ce qui “aurait dû” être fait différemment.
Une heure plus tard, tout le monde est d’accord : les signaux d’alarme étaient là depuis le début. L’équipe aurait dû les voir. La décision initiale était risquée. On ne refera pas cette erreur.
Le post-mortem se referme. Les conclusions sont archivées. Et le prochain projet démarre avec exactement les mêmes biais de décision, juste mieux camouflés sous une nouvelle gouvernance.
Rien à voir avec l’intelligence des gens dans la salle. C’est une question de méthode, et Annie Duke, dans Thinking in Bets, l’a mieux formulée que personne.
Ce que TradeLens essayait de résoudre
Avant d’aller plus loin, un peu de contexte pour ceux qui ne suivent pas le secteur maritime.
Expédier un conteneur de produits frais d’Afrique de l’Est vers l’Europe, c’est traverser les mains d’environ 30 organisations (armateurs, ports, transitaires, douanes, assureurs, banques) et générer près de 200 communications, la plupart sur papier. Une seule erreur dans un document douanier peut bloquer la marchandise pendant des jours. Une information qui arrive en retard sur l’arrivée d’un navire, c’est un terminal qui n’a pas pu préparer les grues.
Le shipping international, en 2018, était l’un des secteurs les plus importants de l’économie mondiale et l’un des moins numérisés. Les bons de chargement (bills of lading) existaient encore majoritairement en version papier, comme au XIXe siècle.
La blockchain semblait l’outil parfait pour ce problème : un registre distribué, partagé entre tous les acteurs, sans tiers de confiance central, permettant à chacun de voir les mêmes données en temps réel sans avoir à les partager via des API bilatérales ou du papier.
La décision de 2018 était raisonnable
En août 2018, IBM et Maersk lancent officiellement TradeLens. Supply Chain Dive, la publication de référence du secteur, nomme le projet “Business Decision of the Year”. Pas un prix anecdotique : les observateurs les plus avertis du marché validaient le pari.
Les raisons d’y croire étaient solides. Le problème était réel et documenté, vécu quotidiennement par des milliers d’entreprises, avec des coûts directs mesurables. Rien à voir avec une hypothèse de cabinet de conseil. Les partenaires, ensuite : Maersk, premier armateur mondial, et IBM, alors solidement installé sur la blockchain d’entreprise avec Hyperledger Fabric. Leur association signalait une ambition industrielle, pas un pilote de plus. La validation réglementaire suivait. La Federal Maritime Commission américaine avait donné son feu vert antitrust, l’Organisation mondiale des douanes participait aux travaux de standardisation.
Et les premiers signaux d’adoption tombaient dans le bon sens. Début 2019, 94 organisations avaient rejoint la phase pilote. En mai, CMA CGM et MSC, deux des plus grands concurrents de Maersk, annonçaient leur adhésion, suivis de Hapag-Lloyd et Ocean Network Express. Fin 2019, quatre des six plus grands armateurs mondiaux étaient sur la plateforme : 175 organisations, deux millions d’événements tracés par jour.
Un dirigeant d’IBM avait posé publiquement le critère de succès dès le lancement : “Cela repose sur un seul facteur : réunir tout l’écosystème autour d’une approche commune qui bénéficie à tous les participants de manière égale.”
Le risque était nommé. Clairement. Dès le premier jour.
Ce qui a tué TradeLens
Le 29 novembre 2022, Rotem Hershko, directeur des plateformes chez Maersk, annonce la fermeture. Phrase officielle : “La nécessité d’une collaboration industrielle mondiale n’a pas été atteinte.”
À la fermeture, TradeLens avait tracé 70 millions de containers et publié 36 millions de documents électroniques. La technologie fonctionnait.
Ce qui n’a pas fonctionné, c’est la dynamique entre les acteurs. Pour trois raisons structurelles.
La première : la neutralité n’a jamais été crue. Maersk détenait la majorité de la joint-venture et restait un concurrent direct des autres armateurs. Les ajustements de gouvernance opérés en 2019, censés donner plus de transparence aux autres compagnies maritimes, n’y ont rien changé. Partager ses données opérationnelles sur une plateforme contrôlée, même partiellement, par un concurrent, c’est une ligne rouge dans un secteur aussi tendu.
Les transitaires, ensuite, ont refusé en bloc. Leur lecture était limpide : TradeLens voulait digitaliser les flux documentaires et supprimer l’intermédiation. Pourquoi un transitaire aiderait-il à construire la plateforme qui le rend inutile ? Aucune incitation ne leur a été proposée pour compenser ce risque.
Les armateurs asiatiques, enfin, ne sont jamais venus. COSCO et les compagnies chinoises ont rejoint GSBN, le Global Shipping Business Network, lancé sous l’impulsion du gouvernement chinois. Deux réseaux parallèles ont émergé, rendant l’ambition d’universalité impossible.
IBM, de son côté, avait commencé à réduire massivement ses effectifs blockchain bien avant la fermeture officielle : plus de 100 postes supprimés selon les estimations. La dynamique financière n’était plus tenable.
Aucun bug n’a tué la plateforme. C’est le modèle économique qui a cédé, sur fond d’une dynamique concurrentielle que personne ne pouvait mesurer avec précision en 2018.
Thinking in Bets : la distinction qui change tout
Annie Duke a été joueuse de poker professionnelle pendant vingt ans avant de devenir consultante en prise de décision. Dans Thinking in Bets, elle introduit un concept qu’elle appelle le resulting : le biais qui consiste à évaluer la qualité d’une décision uniquement à travers la qualité de son résultat.
Sa démonstration est simple. Une bonne décision peut produire un mauvais résultat si les facteurs incontrôlables jouent contre elle. Une mauvaise décision peut produire un bon résultat si la chance joue en sa faveur. Confondre les deux, c’est apprendre les mauvaises leçons.
Le resulting est particulièrement toxique dans les post-mortems, parce qu’il opère en sens inverse : on connaît le résultat, et on reconstruit rétrospectivement une chaîne de signaux d’alerte qui “auraient dû” être vus. C’est le biais de rétrospection, et Duke montre qu’il est quasi systématique.
La bonne question n’est pas : “Était-ce une bonne décision ?”
La bonne question est : “Compte tenu de ce qu’on savait au moment de la décision, était-ce un pari raisonnable ?”
Pour TradeLens en 2018, la réponse est oui. Le problème était réel. Les partenaires étaient crédibles. Les signaux d’adoption étaient positifs. Le risque principal, la collaboration entre concurrents, était connu, nommé, et semblait en voie de résolution à mesure que les grands armateurs rejoignaient la plateforme.
Ce n’est pas parce que ça s’est mal terminé que c’était une mauvaise décision.
Ce que ça dit de nos post-mortems IT
Je n’ai pas participé au projet TradeLens. Mais j’ai assisté à suffisamment de post-mortems IT pour reconnaître le pattern.
Le projet de modernisation du SI qui a dérivé de 18 mois sur 24. Le déploiement CRM qui a atteint 40% d’adoption six mois après le go-live. La migration cloud qui a coûté trois fois le budget initial. Dans chaque cas, la réunion de bilan reconstruit une évidence rétrospective : on aurait dû voir que.
Ce qu’on ne fait presque jamais, c’est reconstituer honnêtement ce qu’on savait, et ce qu’on ne pouvait pas savoir, au moment de la décision.
Duke propose une discipline simple : avant d’analyser ce qui s’est passé, écrire ce que l’équipe savait au moment du go/no-go. Quels étaient les signaux disponibles ? Quels étaient les risques identifiés et leur probabilité estimée ? Quelle était la logique du pari ?
Ce document existe rarement dans les organisations IT. Le business case, oui. L’analyse de risques formelle, parfois. Mais l’équivalent d’une “fiche de pari” (voici ce qu’on sait, voici ce qu’on ne sait pas, voici pourquoi on y va quand même), presque jamais.
Sans ce document, le post-mortem ne peut que reconstruire une histoire cohérente avec le résultat. C’est du storytelling, pas de l’analyse.
L’ironie du cas TradeLens
Ce qui est remarquable avec TradeLens, c’est que le risque fatal a été nommé publiquement, dès le lancement, par IBM lui-même : “le succès repose sur un seul facteur : réunir tout l’écosystème.”
Ils savaient. Ils l’ont dit. Et quatre ans plus tard, tout le monde cite cette phrase comme la preuve qu’ils auraient dû savoir que ça allait échouer.
C’est exactement le biais de rétrospection à l’œuvre. En 2018, la phrase était un engagement sur l’ambition, pas un aveu d’échec anticipé. Et les signaux de 2019, quatre des six plus grands armateurs à bord, semblaient indiquer que cet engagement était tenable.
Le resulting nous fait lire la même phrase différemment selon qu’on la lit avant ou après le résultat. C’est ça, le vrai problème.
Ce qu’on devrait faire à la place
Duke ne dit pas qu’il faut arrêter d’analyser les échecs. Elle dit qu’il faut changer la question centrale.
Au lieu de “Qu’est-ce qui n’a pas fonctionné ?”, qui appelle une reconstruction rétrospective, poser : “Le processus de décision était-il solide, compte tenu de ce qu’on savait ?” Cette question-là appelle une évaluation de la méthode.
Concrètement, deux choses changent dans un post-mortem IT.
D’abord, documenter la décision avant d’en connaître le résultat. Pas le business case : la logique du pari. Ce qu’on sait, ce qu’on ignore, les conditions dans lesquelles on acceptera de réviser. Les meilleures équipes d’investissement le font systématiquement. Les équipes IT, rarement.
Ensuite, séparer les leçons sur le processus des leçons sur le fond. “On a sous-estimé la résistance des transitaires” est une leçon de fond : elle vaut pour ce cas précis. “On n’avait pas prévu de point de révision à 12 mois sur nos hypothèses d’adoption” est une leçon de processus : elle vaut pour tous les projets suivants.
Les post-mortems IT excellent sur les leçons de fond. Ils ignorent presque systématiquement les leçons de processus.
Pour finir
Bonne décision, mauvais résultat. Les deux tiennent ensemble sans se contredire. Maersk et IBM n’ont pas mal travaillé, du moins rien dans les sources disponibles ne permet de l’affirmer. Et oui, on peut en tirer des leçons utiles. Simplement pas celles que la plupart des post-mortems retiennent.
La vraie leçon n’est pas “méfie-toi des consortiums blockchain” ou “ne lance pas une plateforme avec un concurrent comme partenaire majoritaire.” Ce sont des leçons de fond, valables pour ce cas, difficiles à généraliser.
La vraie leçon est plus inconfortable : nous ne savons pas évaluer nos décisions. Nous savons évaluer nos résultats. Ce n’est pas la même chose, et nous continuons à les confondre.
Annie Duke l’a formalisé pour le poker. Ça s’applique mot pour mot au pilotage IT.
Annie Duke, Thinking in Bets : Making Smarter Decisions When You Don’t Have All the Facts, Portfolio/Penguin, 2018.
Sources sur TradeLens : Maersk (communiqué officiel, nov. 2022), Supply Chain Dive, Computerworld, MIT CISR, PierNext / Port de Barcelone.