Dans les comités exécutifs, les CODIR et les boards, une réalité revient comme une fatalité : malgré les méthodologies, les certifications, les cabinets de conseil, les schémas directeurs et les budgets colossaux, la majorité des projets IT échouent. Les études parlent de 70 à 80 % d’échec, partiel ou total. Retards massifs. Budgets dépassés. Livrables inutilisables. Projets terminés mais inopérants dans le Run. Et parfois, des investissements de plusieurs millions enterrés en silence.

Ce paradoxe interroge : comment se fait-il qu’à une époque où l’on n’a jamais disposé d’autant de technologies, d’outils, de standards et de talents, les projets informatiques continuent d’être des champs de bataille ? La réponse n’est presque jamais technique. Les technologies tiennent leurs promesses ; ce sont les organisations qui flanchent. Le véritable problème se niche dans la gouvernance, les responsabilités, la capacité à décider et à piloter. C’est précisément là qu’un DSI de transition change la donne : il arrive avec la distance, l’autorité et l’expérience nécessaires pour remettre un projet sur ses rails, rétablir la clarté, redonner un cap et transformer un chaos latent en réussite concrète.

Le sponsor fantôme : premier facteur d’échec

Dans presque tous les projets IT en crise, on retrouve le même symptôme. Un sponsor officiellement désigné, mais absent, silencieux, surbooké, ou simplement paralysé par les tensions politiques internes. Cette absence handicape tout le projet. Aucun arbitrage ne descend. Aucun choix n’est porté. Les équipes attendent des décisions qui n’arrivent jamais. Les prestataires avancent “au mieux”, souvent dans le flou, modifiant l’interprétation au fil de l’eau.

Le sponsor fantôme est le tueur silencieux. Il transforme un projet en marathon sans ligne d’arrivée. Quand personne ne tranche, tout le monde attend. Et pendant que l’on attend, les délais explosent, les budgets se tendent, et les équipes s’épuisent.

Là où un DSI de transition apporte une rupture, c’est qu’il ne tolère pas ce vide. Il demande un sponsor réellement impliqué. Il obtient des arbitrages formels, datés et assumés. Il expose les zones d’ombre et force les responsabilités à revenir à ceux qui doivent les porter. Lorsqu’un sponsor refuse son rôle, il n’hésite pas à alerter le COMEX : mieux vaut arrêter ou repenser un projet plutôt que de continuer à brûler du budget dans l’espoir que quelque chose finisse par s’aligner.

Le périmètre flou : la dérive lente mais certaine

Contrairement à une idée répandue, les projets n’échouent pas parce qu’ils sont ambitieux. Ils échouent parce que leur périmètre n’est pas clair, jamais verrouillé, souvent mouvant. Tout commence par une expression de besoins approximative. Puis viennent les réunions où “on verra plus tard”, où les utilisateurs découvrent leur métier en même temps que l’équipe projet, où les sponsors modifient leur vision à chaque comité. Le flou devient norme.

Chaque manque de précision génère une interprétation. Chaque interprétation devient une divergence. Et chaque divergence cause une refonte. Ce cycle-là peut durer deux ans sans que personne ne mette de nom dessus. On l’appelle pudiquement : “les aléas du projet”. Mais c’est en réalité un déficit de définition et de pilotage.

Le DSI de transition, lui, tranche. Il clarifie. Il contractualise. Il ferme les portes du périmètre. Il impose un langage commun aux métiers, à l’IT, aux prestataires. Il remplace l’ambiguïté par des engagements. Il arrête la dérive, parfois au scalpel, pour redonner au projet une forme pilotable et réaliste.

L’absence de runbooks : la bombe à retardement

C’est l’un des aspects les plus sous-estimés de l’échec des projets IT. Beaucoup d’équipes considèrent qu’un projet est terminé lorsqu’il est livré. Mais ce n’est pas vrai : un projet est terminé quand il fonctionne dans le Run, quand il est utilisable, intégrable, maintenable, supervisable. Sans runbook, même le meilleur développement devient une machine inutilisable.

Les runbooks détaillent les procédures d’exploitation, les escalades, les reprises en cas d’incident, les opérations régulières, les modes dégradés. Sans ces éléments, un projet devient une dette opérationnelle qui explose au premier incident. C’est souvent à ce moment que la DSI découvre qu’elle n’a pas la main, pas les accès, pas la documentation, pas les procédures. Et que le prestataire, lui, a disparu.

Le DSI de transition impose une règle simple mais révolutionnaire : pas de runbook, pas de go-live. Il structure la continuité opérationnelle, les on-call, les escalades, les process de supervision, les plans de secours. Il transforme un produit fragile en service robuste. C’est cette exigence qui fait la différence entre un projet “déployé” et un projet “réussi”.

Les équipes éclatées : trop de monde, personne aux commandes

La multiplication des parties prenantes est devenue un standard : MOA, MOE, intégrateurs, infogérants, cybersécurité, architectes, data, métiers, infrastructures, partenaires externes, et parfois plusieurs prestataires simultanément. À chaque strate s’ajoute une couche de complexité, de réunions, de zones grises. Quand les responsabilités se diluent, la gouvernance s’effondre.

Le DSI de transition reconnecte toutes les pièces. Il réduit les intermédiaires. Il simplifie les circuits d’escalade. Il remet de la lisibilité dans les rôles. Il fait redescendre les décisions au plus près de ceux qui agissent. Il coupe les silos internes. Il fédère des équipes qui se parlaient à peine. Il obtient un alignement que personne n’arrivait à obtenir depuis des mois.

Le manque de courage managérial : la maladie la plus répandue

La plupart des projets IT en difficulté ne manquent pas de compétences. Ils manquent de courage. Le courage de dire non. Le courage de stopper. Le courage d’arbitrer. Le courage de changer de prestataire. Le courage de demander plus clairement aux métiers ce qu’ils veulent vraiment. Le courage de dire que le planning annoncé est irréaliste. Le courage de ne pas céder aux injonctions politiques.

Un DSI de transition n’a pas besoin de plaire. Il a besoin de réussir. Cette liberté change tout. Il peut poser ce que d’autres n’osent pas dire. Il peut prendre des décisions impopulaires mais nécessaires. Il peut assumer un franchissement de ligne que les équipes internes n’oseraient pas proposer. Sa seule boussole est l’efficacité opérationnelle.

La méthode commando : rétablir un projet en 90 jours

Un DSI de transition agit différemment. Sa force vient de sa méthode :

Diagnostic éclair : en deux semaines, il comprend l’écosystème, la gouvernance, les impasses, les talents, les risques, les dépendances et les non-dits.

Recentrage du périmètre : il élimine le superflu, redéfinit le cœur du projet, verrouille les engagements métier.

Remise en ordre de bataille : nouvelle gouvernance, nouveaux rituels, circuits d’escalade simplifiés, sponsor responsabilisé.

Sécurisation du Run : runbooks, procédures, plan de continuité, documentation, responsables désignés.

Pilotage serré : reporting clair, priorisation stricte, arbitrages rapides, communication unifiée entre toutes les équipes.

En 90 jours, un projet perçu comme perdu peut redevenir pilotable.

Conclusion : sauver un projet IT n’est pas une question de technologie, mais de leadership

Les échecs des projets IT ne sont pas une fatalité. Ils sont le symptôme d’une organisation qui manque de gouvernance, de clarté, de sponsor actif et de courage managérial. Les DSI internes sont souvent pris dans des contraintes politiques, historiques et humaines qui limitent leur marge de manœuvre. Un DSI de transition, lui, arrive libre, neutre, sans conflit d’agenda. Il voit ce que les autres ne voient plus. Il tranche là où personne n’ose trancher. Il transforme un projet condamné en projet délivré.

Et surtout, il redonne à l’entreprise ce dont elle manque le plus dans les moments critiques : un cap, de la lisibilité, de la rigueur et du leadership.

Un projet IT ne s’effondre pas parce qu’il est complexe. Il s’effondre parce que personne ne tient le gouvernail.

Le DSI de transition est celui qui le reprend.