*Temps de lecture : 9 minutes*

—

## Le moment où tout se joue

Quand un DSI ou un COMEX m’appelle pour une mission de transition Infrastructures & Opérations, c’est rarement parce que tout va bien.

Les incidents s’enchaînent et le service desk déborde. Une migration cloud patine et personne n’arrive à dire pourquoi. Un contrat d’infogérance dérive et la facture mensuelle n’a plus de rapport avec le service rendu. Une cyberattaque a laissé des cicatrices que personne n’ose vraiment regarder. Un responsable production part et emporte avec lui dix ans de mémoire opérationnelle non documentée.

Dans tous ces cas, **les 30 premiers jours décident de l’issue de la mission**. Pas les 90, pas les 180. Les 30.

Parce qu’au-delà de cette fenêtre, deux choses se figent : la confiance que les équipes techniques vous accordent, et la lecture que la direction se fait de la situation. Si à J+30 vous n’avez pas posé un diagnostic factuel, identifié les trois risques majeurs et engagé deux ou trois actions visibles, vous passerez les cinq mois suivants à courir derrière votre propre mission.

Cet article n’est pas une méthodologie de cabinet. C’est ce que je fais, concrètement, dans les 30 premiers jours d’une mission de Directeur Infrastructures & Opérations de transition. Avec ce que ça implique de choix, de renoncements, et de désaccords parfois.

—

## Avant J+1 : la phase qu’on oublie toujours

Le travail ne commence pas le jour de l’arrivée. Il commence à la signature du devis, idéalement deux semaines avant.

Pendant cette phase de cadrage, je demande systématiquement trois choses au sponsor — qui est, selon le contexte, soit le DSI/CIO en place qui cherche un bras droit opérationnel, soit le DG ou le DAF dans une organisation où la fonction IT est portée par défaut :

**1. Le mandat écrit.** Une page suffit. Quels sont les objectifs ? Quelle est mon autorité — décisionnelle, ou seulement consultative ? Sur quels périmètres ? Qui m’arbitre en cas de conflit, notamment si je travaille en binôme avec un DSI déjà en place ? Sans ce document, vous démarrez en zone grise et vous y resterez.

**2. La cartographie des relations.** Qui pense quoi de la situation ? Qui a soutenu le responsable production ou infra sortant ? Qui voulait recruter en interne ? Quels fournisseurs ont l’oreille du DG ? Cette cartographie vaut plus qu’un audit technique. Les opérations IT ne souffrent pas tant de problèmes techniques que de problèmes de gouvernance non dits.

**3. L’accès aux données critiques avant J+1.** Tableaux de bord d’exploitation des 6 derniers mois, contrats d’infogérance et de licences majeurs, derniers audits cyber, rapport du dernier exercice PRA, dossier RH de l’équipe ops. Pas pour les éplucher avant l’arrivée — pour gagner les 5 jours qu’on perd toujours à attendre des accès.

Si l’un de ces trois éléments est refusé, le drapeau rouge se lève. Une mission Infrastructures & Opérations sans mandat clair ou sans accès aux données est une mission sur laquelle on ne livrera rien — et c’est mieux de le savoir avant de signer.

—

## J+1 à J+10 : prendre le pouls, sans faire de bruit

La tentation classique du manager de transition expérimenté, c’est d’arriver avec ses certitudes. *J’ai déjà vu ce film, je sais ce qu’il faut faire.* C’est exactement ce qu’il ne faut pas faire dans les dix premiers jours.

### Trois cercles d’écoute, dans cet ordre

**Cercle 1 — Le sponsor et le management IT (J+1 à J+3).** Si je travaille pour un DSI en place, je commence par lui : objectifs, périmètre exact, sujets sensibles qu’il ne veut pas que je traite, et la manière dont il veut que je communique avec son COMEX. Si je rapporte directement au DG, je rencontre le COMEX étendu (DAF, DRH, métiers principaux), 30 minutes chacun. Trois questions seulement : *Qu’est-ce qui marche bien côté ops aujourd’hui ? Qu’est-ce qui vous empêche de dormir ? Qu’attendez-vous concrètement de cette mission ?*

**Cercle 2 — Les équipes ops (J+3 à J+7).** Je passe une demi-journée avec chaque équipe : production/exploitation, infrastructure (réseau, datacenter, cloud), workplace, service desk, sécurité opérationnelle. L’erreur fréquente est de se limiter aux N-1 ; c’est à N-2 et N-3 que se trouve la vérité du terrain. Les techniciens d’astreinte savent ce qui tombe à 3 heures du matin. Les administrateurs systèmes savent quels serveurs ne sont plus dans la CMDB. Les agents du service desk savent quels métiers appellent vraiment et pour quoi. Personne ne ment volontairement, mais chaque niveau a ses angles morts.

**Cercle 3 — Les fournisseurs critiques et les métiers (J+7 à J+10).** Je rencontre les deux ou trois fournisseurs qui pèsent vraiment dans le RUN — infogérance, hébergeur, telco, éditeur d’un applicatif vital. Pas pour négocier, pour observer la posture. Un infogérant qui parle de « continuité de la relation » plus que de SLA est un signal. En parallèle, je vais voir trois ou quatre directions métier : *Si l’IT pouvait faire mieux une seule chose pour vous, ce serait quoi ?* La réponse révèle souvent un écart vertigineux entre ce que l’IT pense livrer et ce que les métiers perçoivent.

### Ce que je regarde côté technique pendant ces 10 jours

En parallèle des entretiens, je regarde sept points, sans annoncer que je les regarde :

– **Les indicateurs de production sur 6 mois glissants** : disponibilité des applications critiques, MTTR par catégorie d’incident, volumétrie de tickets, taux de résolution N1, taux de réouverture. Pas la peine d’instrumenter — les chiffres existent toujours, même mal calculés. Ce qui compte, c’est la *tendance*.

– **L’état réel de la CMDB** : couverture, fraîcheur, propriétaires identifiés. Une CMDB à 60 % de couverture, c’est 40 % du parc qu’on découvre lors du prochain incident majeur.

– **La structure des contrats d’infogérance et de support** : SLA contractuels vs SLA réels, pénalités appliquées (rarement), clauses de réversibilité (souvent absentes), Top 5 fournisseurs en poids budgétaire et en criticité.

– **L’état des sauvegardes et du PRA** : pas la documentation — la dernière date d’un test grandeur nature. Si la réponse est « il y a plus de 18 mois » ou « on n’a jamais vraiment testé », c’est un risque majeur sur lequel je reviendrai à J+15.

– **La couverture cyber opérationnelle** : EDR sur l’ensemble du parc (workstations *et* serveurs), MFA généralisé, statut des comptes à privilèges, journalisation et SIEM/SOC fonctionnels. Avec NIS2 qui s’impose à de plus en plus d’ETI, ces points ne sont plus négociables.

– **La maturité cloud et FinOps** : si l’entreprise a basculé tout ou partie en cloud, où en est la maîtrise des coûts ? Existe-t-il des tags, des budgets par environnement, des revues de consommation ? Dans la moitié de mes missions, j’ai trouvé des dépenses cloud entre 20 et 40 % au-dessus du nécessaire — sans qu’aucun arbitrage explicite ait été pris.

– **L’état du backlog d’exploitation** : combien de demandes de service en retard, combien de changements en file d’attente, combien d’incidents N3 transmis aux éditeurs et bloqués depuis plus d’un mois. C’est l’indicateur le plus parlant de la santé réelle de la fonction ops.

### Ce que je ne fais pas

Je ne décide rien. Je ne lance aucun chantier. Je ne change personne de poste. Je ne renégocie aucun contrat. Je ne communique pas de plan.

Pourquoi ? Parce que toute décision prise à J+5 sera lue par les équipes comme une décision d’arrivée — donc une décision politique. Or à J+5, vous n’avez pas encore le matériau pour décider intelligemment. Et vous n’avez pas encore la légitimité pour décider tout court.

La seule chose que je communique au sponsor à la fin de cette première phase, c’est une note d’étape de deux pages : ce que j’ai vu, ce que je n’ai pas encore vu, et le calendrier de la suite. Sobre. Factuel. Aucune promesse.

—

## J+10 à J+30 : poser le diagnostic et engager le visible

C’est dans cette deuxième fenêtre que se construit la crédibilité de la mission.

### Le diagnostic en trois axes

À J+15, je rends un diagnostic structuré autour de trois axes, jamais plus :

**1. Les risques majeurs d’exploitation (top 3, avec criticité et probabilité).** Ce ne sont pas forcément les plus graves dans l’absolu, mais ceux qui pourraient se matérialiser dans les six mois et toucher l’entreprise au cœur. Risque cyber non couvert, fournisseur d’infogérance en zone rouge, sauvegardes non testées sur un applicatif vital, dépendance critique à une compétence individuelle, fin de support imminente sur un système central — la liste varie, le format ne varie pas.

**2. Les chantiers ops prioritaires (top 3, avec effort et bénéfice).** Là encore, pas une feuille de route exhaustive — un *focus* sur ce qui va débloquer la valeur. Un bon chantier prioritaire répond à trois critères : il est exécutable dans la durée de la mission, il a un sponsor identifié (DSI ou métier), il a un livrable mesurable. Exemples typiques : industrialiser la supervision sur les applications business critiques, reprendre la main sur un contrat d’infogérance, déployer l’EDR sur les 30 % de serveurs qui n’en ont pas, renégocier les engagements cloud pour récupérer 15 à 25 % de marge.

**3. La trajectoire 12 mois sur le périmètre Infrastructures & Opérations.** Une vision macro, pas un plan. Trois ou quatre paragraphes qui répondent à la question : *où la production IT doit-elle être dans 12 mois pour soutenir l’activité ?* Cette trajectoire servira de référentiel à la suite de la mission — ou à la passation, selon que vous restez ou que vous repartez.

### Les actions visibles à engager avant J+30

En parallèle du diagnostic, j’engage entre deux et quatre actions visibles. Le critère est strict : l’action doit produire un résultat tangible avant J+45, et idéalement avant J+30. Ce ne sont pas des chantiers stratégiques — ce sont des signaux.

Quelques exemples typiques sur un périmètre ops :

– Remettre en route une revue d’incidents hebdomadaire avec format simple et compte-rendu écrit (souvent absente ou ritualisée à vide).

– Stabiliser un incident récurrent qui pourrit la perception de l’IT chez les métiers — un applicatif qui rame en début de mois, une imprimante critique qui tombe une fois par semaine.

– Imposer la finalisation d’un test PRA ou de restauration de sauvegarde dans les 4 semaines.

– Rouvrir un dossier fournisseur bloqué depuis des mois (renouvellement non négocié, escalade jamais traitée).

– Récupérer une visibilité sur la facturation cloud — au minimum un export mensuel par environnement, par projet ou par direction.

Ces actions ne transforment pas la production IT. Mais elles signalent qu’il y a à nouveau un pilote dans la salle de contrôle. Et ça, c’est ce qui restaure la confiance — celle des équipes ops, celle du DSI, celle du COMEX.

### Le moment où la mission bascule

Il y a presque toujours, entre J+15 et J+25, un moment où la mission bascule. Un test. Quelqu’un vous met au défi — un manager qui conteste une décision, un infogérant qui rappelle qu’il a un autre point d’entrée chez le DG, un projet qui demande une rallonge budgétaire mal documentée.

Ce moment n’est pas accidentel. C’est l’organisation qui mesure votre détermination. Si vous tranchez clairement, en vous appuyant sur le mandat écrit et sur le diagnostic, la mission tient. Si vous arbitrez de manière émotionnelle ou par compromis flou, elle commencera à se déliter dans les 60 jours suivants.

—

## Ce qu’il y a à J+30 : le livrable de mi-parcours

À la fin du premier mois, je remets au sponsor un livrable structuré, court — entre 8 et 12 pages — qui contient :

1. **L’état des lieux factuel** : indicateurs de RUN, structure budgétaire ops, niveau de risque cyber, état des contrats d’infogérance, état des grands chantiers d’infrastructure. Trois pages max.

2. **Le top 3 des risques majeurs** avec actions de mitigation engagées ou recommandées.

3. **Le top 3 des chantiers ops prioritaires** avec sponsor, effort, calendrier et indicateur de succès.

4. **La trajectoire 12 mois** sur le périmètre Infrastructures & Opérations, dans ses grandes lignes.

5. **Les besoins humains et budgétaires** pour livrer cette trajectoire — c’est la partie qui fait souvent grincer mais qui doit être posée tôt.

6. **Le calendrier de passation** — vers le successeur permanent, ou vers la deuxième phase de mission si elle est confirmée.

Ce livrable n’est pas un rapport de consultant. C’est une base de décision pour le sponsor. Il doit pouvoir être lu en 20 minutes et débattu en 1 heure de comité.

—

## Pourquoi ce schéma fonctionne

J’ai mené plusieurs missions avec cette structure, dans des contextes très différents — pharma internationale, services financiers, médias, immobilier. La méthode résiste à la diversité des secteurs, parce qu’elle ne porte pas sur la technique — elle porte sur la **gouvernance des opérations IT** elle-même.

Trois principes la sous-tendent, et il vaut la peine de les expliciter :

**Principe 1 — La crédibilité précède la transformation.** Un manager de transition qui arrive en annonçant son plan dès la première semaine se condamne à ne livrer que ce qu’il avait imaginé *avant* de connaître le terrain. Or le terrain réserve toujours des surprises — un contrat fournisseur tordu, une compétence-clé sur le départ, une dette d’infrastructure qu’on n’avait pas chiffrée. La crédibilité se construit en montrant qu’on écoute avant de décider.

**Principe 2 — Le diagnostic vaut plus que le plan.** Dans neuf cas sur dix, ce qui manque à une fonction ops en difficulté, ce n’est pas un plan — il y en a souvent trois ou quatre qui dorment dans des tiroirs. Ce qui manque, c’est un diagnostic partagé entre l’IT et le sponsor. Tant que ce diagnostic n’existe pas, aucun plan ne sera exécuté.

**Principe 3 — La passation se prépare à J+1.** Une mission de transition réussie, c’est une mission qu’on quitte sans laisser de vide. Cela se prépare dès le premier jour, en documentant, en formalisant, en partageant — pas en construisant un savoir privé qui partirait avec vous.

—

## Ce que vous pouvez en faire dès cette semaine

Si vous lisez cet article parce qu’une situation se profile dans votre organisation — départ d’un responsable ops, dérive d’un contrat d’infogérance, crise cyber, migration cloud à sécuriser, équipes de production en sous-effectif — voici trois actions immédiates :

– **Posez par écrit le mandat** que vous donneriez à un manager de transition Infrastructures & Opérations. Si vous ne savez pas le formuler en une page, c’est que la situation n’est pas encore mûre pour une mission externe.

– **Identifiez votre sponsor unique.** Une mission ops à deux têtes (DSI + DG sans accord clair sur le périmètre) échoue dans la majorité des cas. Le sponsor doit être identifié et engagé avant le démarrage.

– **Listez les trois questions** auxquelles vous voulez une réponse à J+30. Pas dix, pas cinq. Trois. Si elles sont claires, votre manager de transition saura sur quoi se concentrer. Sinon, il devinera — et il devinera mal.

—

*Cet article fait partie d’une série sur le management de transition Infrastructures & Opérations IT. Si votre situation appelle une discussion concrète, [le premier échange est de 30 minutes, gratuit, et vous repartez avec 3 actions](https://cebeho.fr/contact/) actionnables dès la semaine suivante.*

*Pour aller plus loin sur les modalités d’une mission, voir [Management de transition IT — comment ça se passe](https://cebeho.fr/management-de-transitions/).*