Retournement IT : Rescue & Redressement en 3-6 mois
L’IT ne marche plus. Elle dérape. Elle traîne l’entreprise vers le bas.
Ce n’est pas une optimisation. Ce n’est pas une transformation. C’est un sauvetage. Un grand programme ERP qui s’éffondre. Une équipe IT en révolte après des années de mauvaise gestion. Une infrastructure qui ne tient que par des bricolages. Des projets critiques bloqués. Les métiers qui n’ont plus confiance.
J’ai redressé l’IT chez SFR sur un grand programme d’envergure : diagnostic flash, restructuration d’équipe, repriorisation drastique. Trois mois pour retrouver un contrôle de base. Dix-huit mois pour une IT stable et valorisée. C’est ça, un retournement IT.
Résultats concrets :
- Diagnostic complet en 2 semaines (où sont les vrais problèmes, pas les symptômes)
- Quick wins à 30 jours (les métiers sentent que ça change)
- Stabilité IT retrouvée en 3-6 mois (équipe mobilisée, projets critiques relancés, confiance revenue)
Quand faut-il un retournement IT ?
Vous êtes face à un retournement IT dans ces situations :
- Grand projet dérailleur depuis 18+ mois (budget explosé, périmètre mal compris, délai impossible).
- Infrastructure au bord de la rupture (pannes fréquentes, pas de capacity planning, équipe à bout).
- Fuite de talent majeure (DSI parti, équipe démotivée, départ en chaîne).
- Incident cyber qui révèle une gouvernance IT complètement cassée.
- Fusion/acquisition où l’intégration IT ne passe pas et crée une crise d’intégration.
Vous le savez qu’il faut un retournement quand : le COMEX parle de remplacer le DSI, quand les directeurs métier vous disent que l’IT est devenue un frein plutôt qu’un enabler, quand recruter des techniciens devient impossible parce que l’IT a mauvaise réputation.
Comment je pilote un retournement IT
Semaine 1 : Diagnostic flash
Je ne fais pas un audit de trois mois. Je dois comprendre rapidement :
- Quel est le principal problème métier créé par l’IT (pas le principal problème IT) ?
- Quels sont les top 3 projets qui ne passent pas ? Pourquoi exactement ?
- Quel est l’état réel de l’équipe IT (qui peut être sauvé, qui ne peut pas) ?
- Où sont les déblocages rapides (quick wins qu’on peut faire en 3-4 semaines) ?
- Quelle est la vraie cause racine : mauvaise techno, mauvaise gestion, mauvaise gouvernance, ou les trois ?
Interviews de 30 min avec les 5 principaux acteurs : COMEX sponsor IT, ancien DSI (s’il y en a un), trois responsables IT clés, deux directeurs métier critiques. Pas plus. La vérité émerge vite.
Résultat jour 7 : un rapport brutal et honnête. Les trois causes. Les trois solutions possibles. Les trois quick wins.
Semaine 2-4 : Premiers arbitrages (les quick wins)
Dès que j’ai compris le problème, je me fais DSI et je suis le couteau. Les quick wins à 30 jours, c’est ce qui rétablit la confiance :
- Projet ERP qui dérape : je fais un vrai diagnostic : le problème c’est la technologie, le périmètre, la gouvernance du projet, ou les compétences ? Je propose un reset clair : réduction du périmètre (plus rapide), ou extension du délai (plus honnête), ou changement d’approche (plus avisé). Le COMEX voit une décision rapide et claire, pas du déni.
- Infrastructure au bord du rupture : je débloquer le budget pour 2-3 embauches urgentes ou une migration cloud rapide sur les charges les plus critiques. En 30 jours, les pannes baissent de 50%. L’équipe IT respire.
- Équipe démoralisée : je dis la vérité. Ce qui change, ce qui ne change pas, ce qui demande des efforts malgré tout. Les bonnes nouvelles : on arrête les projets stupides, on priorise les vrais besoins métier, on va recruter les bonnes personnes. Les mauvaises : on va aussi arrêter certains services legacy parce qu’on peut pas tout faire avec une équipe réduite.
À 30 jours : les métiers sentent que l’IT revient à la raison. L’équipe IT voit qu’il y a une vraie structure. Le COMEX a confiance qu’il y a quelqu’un de décideur.
Mois 2-3 : Stabilisation et restructuration
Une fois qu’on a arrêté l’hémorragie, on stabilise :
- Projets IT : chaque projet get revisité. Qu’est-ce qu’on garde, qu’est-ce qu’on réduit, qu’est-ce qu’on arrête ? Un retournement IT, c’est souvent l’occasion de tuer les projets zombies (projects that should have died mais traînent depuis 3 ans).
- Équipe IT : audit des compétences vs. besoins. Les gens qui ne sont pas à leur place : repositionnement ou départ. Les gens clés qu’on doit retenir absolument : on met du budget, on valorise, on donne de la perspective. Pas de compromis.
- Gouvernance : un comité IT structuré avec le COMEX (pas juste du reporting ad hoc). Une vraie discussion stratégique, pas juste énumération de chantiers. À Buffalo Grill, c’était ça qui manquait : le COMEX ne comprenait pas comment ça marchait. Une gouvernance claire, c’est la moitié du redressement.
- Schéma directeur IT : pas un plan de 100 pages. Un schéma directeur de une page : où on va, qu’est-ce qui change, quand. Le reste c’est le détail. Un schéma directeur SI clarifie pour tout le monde : c’est quoi la route, pas juste les nids-de-poule.
Mois 3-6 : Consolidation et ancrage
À 3 mois, l’équipe IT doit être stabilisée. À 6 mois, elle doit être en croissance. Comment ?
- Les projets critiques tournent et livrent (un succès visible du métier).
- L’infrastructure est saine (pas de pannes majeures, capacity planning à jour).
- L’équipe IT s’étend si nécessaire (recrues externes de qualité, ou montées en compétence internes).
- La relation IT-métier est restaurée (les directeurs métier demandent à l’IT plutôt que de la contourner).
Un retournement IT réussi, c’est que je peux partir à 6 mois et l’IT n’effrondre pas derrière moi. C’est qu’il y a une vraie structure, un vrai DSI stable (permanent ou interim), une équipe mobilisée.
Les différents scénarios de retournement IT
Scénario 1 : Grand projet catastrophe (ERP, digital transformation)
Vous avez investi 2M€, c’est censé être « presque fini », mais ça dérape. Pourquoi ? Options :
- Le périmètre a explosé : solution, on redéfinit. On dit au métier : vous avez 2M€, vous avez le choix : les 80% de fonctionnalités clés en 6 mois, ou les 100% en 12 mois. À vous de choisir.
- Le partenaire/intégrateur n’est pas à la hauteur : soit on le remplace (coût + retard), soit on met de la supervision interne (notre équipe supervise leur travail, 10 personnes IT dédiées à ça).
- Le métier ne savait pas vraiment ce qu’il voulait : c’est le plus courant. Le projet n’a jamais eu une vraie gouvernance métier. Solution : un comité steering métier fort (sponsor + VP opérationnels), réunion hebdomadaire, décisions rapides. À Thomas Cook, c’était ça qui manquait : on avait une super tech, mais pas de gouvernance métier pour diriger la tech.
Je fais un audit de 3 semaines. Je dis au COMEX exactement ce qui s’est passé. Puis je propose le plan pour sauver le projet (pas forcément le projet d’origine, mais un projet qui marche).
Scénario 2 : Infrastructure cassée, équipe sous pression
Pannes fréquentes. Pas de vraie stratégie cloud. Data center legacy qui coûte trop cher. Équipe IT qui fait du pompiers 40% de son temps au lieu de projets stratégiques.
Solution : optimisation IT rapide + investissement ciblé. On arrête ce qui coûte trop pour peu de valeur. On investit dans infrastructure moderne (cloud, containerisation). En 4-5 mois, l’équipe IT baisse son taux de « pompiers » de 40% à 15%. Ça libère 25% de capacité pour les vrais projets.
Scénario 3 : Équipe en rupture, DSI absent ou mauvais
Le DSI est absent, ou il a perdu la confiance de l’équipe. Les gens s’en vont. Turn-over monte à 30-40%. C’est une crise managériale, pas une crise technique.
Solution : (a) Si le DSI peut être sauvé via du coaching, on peut l’aider à redresser. (b) Si c’est perdu, il faut un remplacement. Je peux être DSI interim pendant 3-6 mois, le temps de recruter et stabiliser.
À SFR, le redressement a demandé un remplacement du DSI en place. Difficile, mais nécessaire. Après 3 mois d’interim fort, l’équipe IT a été stabilisée, le turn-over s’est arrêté, et on a recruté un DSI permanent de qualité.
Scénario 4 : Crise IT plus large (cyber, incident, etc.)
Un incident cyber majeur. Ou l’infrastructure s’écroule. C’est une gestion de crise IT pure. Ce qui la différencie d’un retournement : c’est hyper urgent (72h), c’est haute tension. Après la crise, vient le retournement : comment on évite que ça reproduise ?
Pourquoi c’est hard à faire seul
Un retournement IT demande une autorité DSI. Quelqu’un qui peut arrêter des projets, restructurer une équipe, dire non au COMEX sans que ça crée un conflit politique. Si vous êtes directeur IT avec un DSI qui vous bloque, ça va pas marcher. Si vous êtes DAF qui essaye de piloter l’IT, ça va pas marcher non plus.
Ça demande un DSI de transition : reconnu, expérimenté, avec du poids. C’est moi.
Comment on démarre ?
Vous m’appelez. On discute 30 minutes de la situation. Je comprends la vraie crise (pas la crise racontée). Si ça vaut le coup, je propose une intervention courte : diagnostic flash sur 2-3 semaines, rapport avec les 3 solutions possibles, engagement clair ou pas.
Si on s’engage, je suis DSI pendant 3-6 mois. Pas consultant. Un DSI opérationnel qui prend des décisions. Avec une cible claire : à J+180, l’IT est stable, l’équipe est mobilisée, on a des succès visibles au métier.