Arbitrer les projets hérités sans céder à l’effet de sunk cost

Imaginons un comité de direction face à un programme ERP hérité. Deux années de travail, des contrats engagés, des équipes épuisées et une date de bascule annoncée aux métiers. Les tests révèlent pourtant des interfaces instables, une reprise de données incomplète et un dispositif de support insuffisant. Le nouveau DSI doit choisir : maintenir la date pour « ne pas perdre » l’investissement, reporter, réduire le périmètre ou arrêter. Ce cas est illustratif, mais le piège est concret : les dépenses passées deviennent un argument pour engager davantage, alors qu’elles ne peuvent plus être récupérées.

Le coût passé ne décide pas de l’euro suivant

L’effet de sunk cost apparaît lorsque l’organisation confond ce qu’elle a déjà sacrifié avec ce qu’elle doit encore décider. Un budget consommé, des mois mobilisés ou une promesse publique expliquent l’histoire du projet ; ils ne démontrent pas sa viabilité future. La bonne question n’est donc pas : « Peut-on abandonner après avoir tant dépensé ? » Elle est : « À partir d’aujourd’hui, quelle option protège le mieux l’activité compte tenu des coûts, des risques et de la capacité disponibles ? »

Cette distinction paraît simple, mais elle heurte trois intérêts. Le sponsor veut préserver sa crédibilité. Le fournisseur souhaite prolonger le contrat. Les équipes veulent que leurs efforts aboutissent. Le dirigeant IT ne doit mépriser aucune de ces réalités. Il doit cependant empêcher qu’elles remplacent l’analyse. Reconnaître le travail accompli n’oblige pas à poursuivre la trajectoire initiale.

Reconstituer les faits avant de juger le projet

Un projet hérité arrive rarement avec une vérité unique. Le tableau de bord peut afficher du vert tandis que les tests critiques restent ouverts. Le budget peut sembler tenu parce que certains coûts ont été repoussés vers l’exploitation. Le planning peut être officiellement stable alors que des contributions métiers ne sont pas sécurisées. Avant d’arbitrer, le DSI ouvre donc un registre des preuves : livrables effectivement acceptés, anomalies bloquantes, dépendances, engagements contractuels, reste à faire, compétences disponibles et décisions en attente.

Il croise ensuite les versions du sponsor, des métiers, des équipes techniques, de la sécurité, des achats et des fournisseurs. L’objectif n’est pas de désigner un coupable, mais de séparer les faits établis, les hypothèses et les inconnues. Une incertitude doit avoir un responsable, une méthode de levée et une échéance. Sans cette discipline, l’arbitrage devient une confrontation d’opinions où le passé pèse plus lourd que les preuves.

Comparer des options exécutables, pas des intentions

Le comité ne doit pas choisir entre « réussir » et « échouer », mais entre plusieurs trajectoires imparfaites. Quatre options méritent généralement d’être instruites : poursuivre à périmètre constant, réduire le périmètre, reporter avec un plan de sécurisation, ou arrêter en organisant la sortie. Chacune doit préciser les effets sur la continuité, les utilisateurs, la cybersécurité, les coûts futurs, les contrats, la charge des équipes et les autres projets du portefeuille.

Une poursuite peut être rationnelle si les défauts sont circonscrits et si la capacité nécessaire existe réellement. Un report peut réduire le risque de bascule, mais prolonger un double fonctionnement coûteux. Une réduction de périmètre peut sauver une échéance tout en créant des interfaces transitoires fragiles. Un arrêt peut libérer des ressources, mais imposer des coûts de sortie et préserver temporairement un système vieillissant. Le rôle du dirigeant consiste à rendre ces compromis visibles, non à fabriquer une option sans douleur.

Installer des seuils qui déclenchent une décision

Pour sortir du débat affectif, le DSI fixe des indicateurs associés à des seuils d’arbitrage. Il suit notamment la couverture des scénarios critiques testés, le nombre d’anomalies bloquantes non contournées, la qualité vérifiée des données reprises, la disponibilité des compétences indispensables, les dépendances sans engagement ferme, le reste à faire estimé et la capacité de support après bascule. Il examine aussi l’impact du projet sur le RUN et sur les autres priorités : un programme ne devient pas viable en absorbant silencieusement toutes les ressources.

Ces indicateurs ne servent pas à décorer un comité. Ils doivent conduire à une conséquence explicite : maintien, réduction, report ou arrêt. Chaque seuil comporte une date de mesure, une source et un propriétaire. Si une donnée manque, cette absence est elle-même un risque à présenter. Le comité peut accepter une exposition ; il ne devrait pas la découvrir après coup.

Éviter les faux remèdes qui prolongent l’impasse

La première erreur consiste à ajouter des moyens sans avoir identifié le véritable goulot d’étranglement. Davantage de consultants ne corrigent ni une décision métier absente ni une architecture incohérente. La deuxième est de renégocier la gouvernance sans toucher à une date indéfendable. La troisième est de découper artificiellement le périmètre pour conserver un jalon, tout en reportant les risques hors du tableau de bord.

Il faut aussi refuser le raisonnement selon lequel l’arrêt « gaspillerait » tout le travail. Certains actifs peuvent rester utiles : données nettoyées, processus clarifiés, composants éprouvés, clauses négociées ou compétences acquises. Leur réutilisation doit être démontrée, pas supposée. Enfin, chercher à sauver la réputation d’un sponsor en masquant les réserves transforme un problème de projet en problème de gouvernance.

Faire trancher le futur, puis documenter la limite

L’arbitrage final tient dans une note courte : faits vérifiés, incertitudes restantes, options comparées, recommandation, protections immédiates et décision attendue. Le DSI formule une position défendable : il peut sécuriser tel périmètre avec telles ressources ; pour conserver la date, telles contributions doivent être obtenues avant telle échéance ; sinon, il recommande un report, une réduction ou un arrêt, avec leurs conséquences.

Cette logique rejoint l’approche de terrain présentée dans DSI EN CRISE : Reprendre le contrôle de l’IT, des ERP et des grands programmes : protéger l’activité, fiabiliser le diagnostic, clarifier les responsabilités et reprendre la maîtrise du programme. L’enjeu n’est pas d’avoir raison contre les prédécesseurs. Il est d’empêcher qu’un investissement irrécupérable dicte encore le prochain engagement. Une décision mature respecte le passé, mais elle finance uniquement un futur que les preuves rendent gouvernable.

Pour approfondir

Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon

Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon

Consulter la référence

Consulter la référence

#ManagementDeTransition #DSI #DirectionDeTransition #GuyDeLussigny #TransformationNumerique