Pourquoi tant de projets IT dérapent — et comment je l'évite
Un constat trop fréquent
Trop de projets IT arrivent en retard, coûtent bien plus que prévu, ou livrent un outil que personne n'utilise vraiment. Ce n'est pas une fatalité. Après 11 ans dans le secteur, 45 projets livrés et plus de 25 équipes accompagnées — chez Allianz Trade, Chanel, MGEN, Air Liquide —, j'ai appris à reconnaître les signaux d'alarme avant qu'ils ne deviennent des catastrophes.
La bonne nouvelle : ces dérapages ont des causes précises, identifiables en amont. Et ils se préviennent.
Les vraies causes des dérapages
Un périmètre flou, sans priorisation
Le premier ennemi d'un projet, c'est l'imprécision. Quand personne ne sait exactement ce qui doit être livré — ou que tout est considéré comme prioritaire —, les équipes s'éparpillent. On construit des fonctionnalités dont personne n'a besoin, pendant que les sujets essentiels attendent.
Un périmètre mal défini en phase de cadrage se retrouve dans chaque sprint, chaque réunion, chaque arbitrage. Le coût s'accumule en silence.
L'effet tunnel : aucune livraison intermédiaire
C'est l'un des patterns les plus destructeurs : un projet qui dure 12 ou 18 mois sans que le client voie quoi que ce soit de concret. On attend la "version finale" pour valider — et quand elle arrive, les besoins ont changé, l'équipe a fait des suppositions, et les ajustements coûtent une fortune.
L'effet tunnel crée de l'incertitude pour tout le monde : pour le client qui ne sait pas où en est son argent, pour les équipes qui travaillent dans le vide, pour le management qui pilote à l'aveugle.
L'absence de gouvernance et de visibilité
Un projet sans gouvernance claire, c'est un bateau sans gouvernail. Qui décide quand il y a un blocage ? Comment les priorités évoluent-elles en cours de route ? Qui valide la qualité des livrables ?
Sans cadre défini, chaque décision devient une négociation, chaque imprévu une crise. J'ai vu des projets s'enliser pendant des semaines sur des sujets qui auraient pu être tranchés en 30 minutes avec le bon processus en place.
La dette technique et le sur-mesure inutile
Construire une solution trop complexe dès le départ — parce qu'on anticipe des besoins hypothétiques — est une erreur classique. On accumule de la dette technique, on complexifie la maintenance, on ralentit les futures évolutions.
Le sur-mesure coûte cher à produire et plus encore à maintenir. Une grande partie des fonctionnalités "sur-mesure" développées en phase initiale ne seront jamais utilisées dans leur forme originale.
Une communication client-équipe défaillante
Le dernier grand facteur de dérapage, c'est la rupture de communication entre le commanditaire et les équipes qui exécutent. Les attentes ne sont pas formulées clairement. Les retours arrivent trop tard. Les décisions sont prises sans les bonnes personnes dans la pièce.
Résultat : on livre ce qui a été demandé, pas ce qui était voulu. Et la différence peut être considérable.
Mes garde-fous concrets
Cadrage et MVP : poser les bases avant de construire
Avant d'écrire une seule ligne de code ou de lancer la moindre équipe, je consacre du temps au cadrage. Quels sont les objectifs réels ? Quelles fonctionnalités sont indispensables dès le premier jour, et lesquelles peuvent attendre ?
Le MVP — produit minimum viable — n'est pas une version au rabais. C'est la version la plus petite possible qui délivre de la valeur réelle et permet de tester les hypothèses clés. C'est ce qui permet de commencer à apprendre sans avoir tout construit.
Ce travail en amont évite des mois de développement inutile et des recadrages douloureux en cours de route.
Sprints avec démos régulières : sortir du tunnel
Je travaille en cycles courts — des sprints de deux semaines — avec une démonstration à la fin de chaque cycle. Le client voit ce qui a été construit, donne son retour, valide ou ajuste les priorités.
Cette approche élimine l'effet tunnel par construction. Il n'existe pas de "grande révélation finale" : à chaque étape, on sait exactement où on en est, ce qui fonctionne, ce qui reste à faire. Les corrections sont faites au fur et à mesure, pas en urgence à la fin.
Un cadre de gouvernance clair
La gouvernance, c'est le squelette du projet : qui décide quoi, comment les priorités sont arbitrées, comment la qualité est mesurée, comment les risques sont remontés.
Chez Allianz Trade, j'ai créé ce cadre from scratch — processus, rituels, indicateurs de suivi. En six mois, le delivery qualitatif a progressé de 40 %. Pas parce que les équipes ont travaillé plus dur, mais parce qu'elles travaillaient avec un cadre qui éliminait les ambiguïtés et accélérait les décisions.
La gouvernance n'est pas de la bureaucratie. C'est ce qui permet à une équipe de se concentrer sur l'exécution plutôt que de perdre du temps à reconstruire les règles du jeu à chaque réunion.
Transparence totale : le client voit l'avancée
Je travaille avec une transparence totale sur l'état du projet. Le client a accès aux indicateurs d'avancement, aux livrables validés, aux risques identifiés. Pas de filtre, pas d'embellissement.
Cette transparence est souvent perçue comme inconfortable au début — personne n'aime voir les difficultés exposées. Mais elle est la condition de la confiance. Un client qui voit les problèmes au moment où ils apparaissent peut aider à les résoudre. Un client qui les découvre à la livraison finale n'a plus aucun levier.
Délégation maîtrisée du run
Un projet ne se termine pas à la livraison. Il faut ensuite que les équipes opérationnelles le prennent en main efficacement. J'anticipe cette transition dès le démarrage : documentation, formation, transfert de compétences.
Sur des missions comme Chanel — où j'ai accompagné l'onboarding de 120 consultants à l'agilité — ou chez MGEN avec le déploiement de SAFe, j'ai appris que la délégation réussie s'organise, elle ne s'improvise pas. Le run doit être piloté avec autant de rigueur que le build.
Ce que ça change concrètement
Un projet qui démarre avec un cadrage solide, des livrables intermédiaires, une gouvernance claire et une communication fluide n'élimine pas tous les imprévus — aucun projet ne le peut. Mais il transforme les imprévus en ajustements gérables plutôt qu'en crises.
C'est la différence entre un navigateur avec une carte et une météo en temps réel, et un navigateur qui espère arriver à bon port.
Après 110 personnes pilotées sur une roadmap agile et 6 équipes synchronisées chez Air Liquide, j'en suis convaincu : un projet ne dérape pas par malchance. Il dérape par manque de cadre. Et ça, ça se prévient.
Parlons de votre projet
Vous avez un projet IT en cours ou en préparation, et vous vous posez des questions sur la méthode, les risques ou l'organisation ? Je prends le temps d'échanger concrètement sur votre situation.
WhatsApp : +33 6 34 42 50 56 Email : contact@twentyconsultancy.com
Sans engagement, sans jargon. Juste un regard extérieur lucide sur ce que vous construisez.