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 :

  1. 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.

  2. Intégrer des “go/no-go” réels dans le pilotage

    Pas juste des jalons symboliques. De vrais moments pour tout remettre à plat.

  3. Instaurer une culture du pivot assumé

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

  4. 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

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.

Le cadrage, ou l’art de poser les fondations d’un projet

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.

Le cadrage, ou l’art de poser les fondations d’un projet

Le cadrage d’un projet, aussi appelé "scoping", est bien plus qu'un simple exercice administratif ou formel : il constitue la colonne vertébrale d’un projet bien structuré. C’est une étape clé pour définir une vision claire, aligner les parties prenantes, fixer des objectifs précis et déterminer les moyens nécessaires pour les atteindre. En somme, le cadrage est une boussole qui guide tout le cycle de vie d’un projet, de son lancement à son achèvement.

La Data comme Moteur de Performance Durable : Allier Business et Sobriété Numérique

La data occupe une place centrale dans les projets et les entreprises se tournent de plus en plus vers elle pour innover, optimiser leurs opérations, améliorer l’expérience utilisateur, et gagner en agilité. Cependant, cette effervescence de collecte, de traitement et de stockage des données s'accompagne d'une réalité indéniable : l'impact environnemental. Peut-on réellement concilier performance business et sobriété numérique ?

Pourquoi les projets data échouent encore trop souvent ?

Les projets data sont souvent présentés comme le moteur de la transformation numérique et de l’innovation en entreprise. Pourtant, une grande proportion d’entre eux n’atteint pas leurs objectifs, laissant les organisations frustrées et sceptiques quant au potentiel réel des données. Alors, pourquoi ces projets continuent-ils d’échouer ? Quels sont les obstacles persistants, et surtout, comment les surmonter ?

Comment choisir entre Django, Flask et FastAPI pour votre projet Python?

Lorsqu'il s'agit de développer une application web en Python, le choix du framework constitue une étape décisive qui peut grandement influencer la réussite du projet. Avec une pléthore d'options disponibles, Django, Flask, et FastAPI se détachent comme les choix les plus populaires dans l'écosystème Python. Chacun de ces frameworks offre des avantages distincts, mais comment déterminer lequel est le plus adapté à vos besoins?

Rentrer en contact

contact

FORMULAIRE DE CONTACT