TradeLens était une bonne décision. Et elle a échoué. Et c'est normal. 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 — parce que 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.
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.
Ce n'est pas un problème d'intelligence. C'est un problème de méthode — et Annie Duke, dans "Thinking in Bets", l'explique mieux que quiconque.
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 environ 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.
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". Ce n'est pas un détail — c'est le signal que 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é. Pas une hypothèse de cabinet de conseil. Un problème vécu quotidiennement par des milliers d'entreprises, avec des coûts directs mesurables.
Les partenaires étaient crédibles. Maersk est le premier armateur mondial. IBM avait à l'époque une position forte sur l'enterprise blockchain avec Hyperledger Fabric. L'association des deux signalait une ambition industrielle, pas un projet pilote.
La validation réglementaire était obtenue. La Federal Maritime Commission américaine avait donné son feu vert antitrust. L'Organisation mondiale des douanes était impliquée dans les travaux de standardisation.
Les premiers signaux d'adoption étaient encourageants. Début 2019, 94 organisations avaient rejoint la phase pilote. En mai 2019, 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 : 4 des 6 plus grands armateurs mondiaux sur la plateforme, 175 organisations, 2 millions d'événements traçés par jour.
Un executive 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.
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 de l'écosystème — pour trois raisons structurelles.
La neutralité était une illusion perçue. Maersk détenait la majorité de la joint-venture. Maersk était un concurrent direct des autres armateurs. Peu importe les ajustements de gouvernance opérés en 2019 pour donner plus de transparence aux autres compagnies maritimes, la perception ne changeait pas : 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 concurrentiel.
Les fret forwarders ont refusé en bloc. Leur lecture : TradeLens veut digitaliser les flux documentaires et supprimer l'intermédiation. Pourquoi un fret forwarder contribuerait-il à construire la plateforme qui le rend inutile ? Aucune structure d'incitation ne leur a été proposée pour contrebalancer ce risque perçu.
Les armateurs asiatiques 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 écosystèmes parallèles ont émergé, rendant l'ambition d'universalité structurellement impossible.
IBM avait, de son côté, 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.
La plateforme n'est pas morte d'un bug. Elle est morte d'une erreur de modèle économique — couplée à une dynamique concurrentielle que personne ne pouvait mesurer avec précision en 2018.
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 inter-concurrents — était connu, nommé, et semblait en voie d'être résolu à 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.
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.
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. Parce que la phrase, en 2018, était un engagement sur l'ambition — pas un aveu d'échec anticipé. Et les signaux de 2019 — 4 des 6 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.
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 ?" — qui appelle une évaluation de la méthode.
Concrètement, ça change deux choses dans un post-mortem IT :
Les post-mortems IT excellent sur les leçons de fond. Ils ignorent presque systématiquement les leçons de processus.
TradeLens était-il une bonne décision ? Oui.
A-t-il produit un bon résultat ? Non.
Est-ce que Maersk et IBM ont mal travaillé ? Pas selon ce que les sources disponibles permettent d'établir.
Est-ce qu'on peut en tirer des leçons utiles ? Oui — mais pas celles que la plupart des post-mortems tirent.
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 sur le 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.
Sources sur TradeLens : Maersk (communiqué officiel, nov. 2022), Supply Chain Dive, Computerworld, MIT CISR, PierNext / Port de Barcelone.
