The Concorde Fallacy : quand un projet IT continue de voler droit dans le mur

L’histoire du Concorde est fascinante : Une prouesse technologique. Un avion supersonique d’avant-garde. Mais aussi… un désastre économique. Et pourtant, malgré des signaux d’alerte très clairs, les investissements ont continué pendant des années. Pourquoi ? Parce qu’il avait déjà coûté trop cher pour qu’on accepte de l’abandonner. Ce mécanisme psychologique porte un nom : la Concorde Fallacy, ou biais des coûts irrécupérables (sunk cost fallacy en anglais). Et il est omniprésent dans les projets IT.

✈️ The Concorde Fallacy : quand un projet IT continue de voler droit dans le mur

L’histoire du Concorde est fascinante :
Une prouesse technologique. Un avion supersonique d’avant-garde.
Mais aussi… un désastre économique.
Et pourtant, malgré des signaux d’alerte très clairs, les investissements ont continué pendant des années.

Pourquoi ?
Parce qu’il avait déjà coûté trop cher pour qu’on accepte de l’abandonner.

Ce mécanisme psychologique porte un nom : la Concorde Fallacy, ou biais des coûts irrécupérables (sunk cost fallacy en anglais).
Et il est omniprésent dans les projets IT.

🎯 Ce biais, c’est quoi exactement ?

C’est notre tendance à continuer un projet ou une action uniquement parce qu’on y a déjà investi beaucoup, même si les perspectives sont mauvaises.

On se dit :

“On a déjà mis 12 mois et 500K€, ce serait du gâchis d’arrêter maintenant.”

Alors qu’en réalité, les coûts passés sont irrécupérables. Ce qui compte, c’est ce que ça va continuer à coûter… ou rapporter.

💻 Comment ce biais se manifeste en IT ?

Tu l’as forcément croisé si tu as piloté ou accompagné des projets.
Quelques exemples typiques :

Un outil développé en interne, devenu inadapté, mais qu’on continue de faire évoluer “parce qu’on y a mis trop d’énergie”.
Une solution de DataViz poussée par la direction, qui ne convainc aucun utilisateur, mais que personne n’ose remettre en question.
Une plateforme cloud mal dimensionnée, mais qu’on continue de consolider au lieu de repenser l’architecture.

Dans tous ces cas, la décision rationnelle serait de faire marche arrière ou de pivoter.
Mais l’ego, la peur de perdre la face ou le poids des investissements passés nous piègent.

🧠 Pourquoi c’est si difficile à éviter ?

Parce que c’est humain.
On veut croire qu’on ne s’est pas trompé.
On espère que les efforts finiront par payer.
Et surtout, on valorise l’investissement passé plus que la valeur future.

Dans une entreprise, ces biais sont encore amplifiés :

L’équipe projet veut défendre son bilan.
Le sponsor ne veut pas porter un échec.
Les décisions sont diluées entre plusieurs acteurs.

🔄 Comment en sortir ?

Voici quelques leviers simples mais puissants :

Isoler les décisions des coûts passés

Quand vous analysez une option, ne regardez que les coûts et bénéfices futurs.
Intégrer des “go/no-go” réels dans le pilotage

Pas juste des jalons symboliques. De vrais moments pour tout remettre à plat.
Instaurer une culture du pivot assumé

Pivoter, ce n’est pas échouer. C’est s’adapter. Et ça peut devenir une force.
Faire intervenir un regard externe

Un œil neuf (interne ou consultant) peut challenger les croyances enracinées.

🛑 En résumé ?

Le vrai courage dans les projets IT, ce n’est pas de tenir jusqu’au bout.
C’est de savoir quand s’arrêter.
Et d’assumer que l’argent dépensé ne doit jamais dicter l’argent qu’on va encore dépenser.

Plus d'articles

Data Management

Les 5 piliers du cadrage data

e cadrage n’est pas une formalité. C’est une assurance projet. Trop souvent, on le réduit à une phase “administrative” avant le vrai démarrage. Mais le cadrage, c’est le moment où tout se joue : les hypothèses, les décisions, les risques, les priorités, la vision commune.

Data Management

Le socle data : construire les fondations d’une performance durable

On parle beaucoup de data mesh, de cloud, ou d’intelligence artificielle. Mais derrière ces concepts, un principe essentiel reste trop souvent oublié : la solidité du socle data. Ce socle, c’est l’ensemble des fondations techniques, méthodologiques et organisationnelles qui permettent à une entreprise de collecter, fiabiliser, gouverner et exploiter ses données dans la durée. Sans lui, les projets se succèdent, les outils se multiplient, mais la valeur créée reste limitée. Un socle data solide, c’est ce qui distingue une organisation réellement data-driven d’une organisation simplement data-busy. Chez Visian, nous le concevons autour de cinq piliers qui structurent toute démarche pérenne

Data Management

Data Observability : voir, comprendre et anticiper ce qui se passe dans vos données

Dans de nombreuses entreprises, les données sont devenues le moteur de la décision, de la performance et de l’innovation. Mais comme tout moteur, elles doivent être surveillées. Pas seulement sur la qualité de ce qu’elles contiennent, mais aussi sur la manière dont elles circulent, se transforment et vivent au quotidien. C’est précisément le rôle de la Data Observability : permettre de comprendre en continu la santé du système de données, de détecter les incidents avant qu’ils ne deviennent visibles, et de restaurer la confiance dans la donnée.

Data Management

Data Mesh & Data Products : la DSI est-elle encore aux commandes ?

Beaucoup voient le Data Mesh comme une revanche des métiers sur la DSI. Fini le centralisme, place à la décentralisation. Mais si on pousse un peu plus loin la réflexion, une question essentielle surgit : Quel est le rôle de la DSI dans une organisation orientée Data Mesh ? A-t-elle encore un rôle à jouer ? Ou est-elle condamnée à devenir une simple équipe de support ?

Data Management

DOC API versus Data Contracts

L’essor du data mesh et de ses principes fondamentaux a fait émerger de nouveaux besoins en matière de gouvernance des données. Dans une architecture où chaque domaine est responsable de ses propres produits de données, le risque de désalignement augmente. Les data contracts se présentent comme une solution structurante : des accords explicites qui formaliseront les échanges entre les producteurs et les consommateurs de données, et ce, d’une manière compatible avec la vision décentralisée du data mesh.