DSI de transition : les 10 décisions à prendre dans les 30 premiers jours

Arriver comme DSI de transition, ce n’est pas “prendre la température” ni faire un tour de table poli pour comprendre l’historique, c’est reprendre la main sur un système qui, souvent, a été laissé sous tension trop longtemps. La réalité du terrain, c’est une DSI coincée entre des métiers pressés, des équipes épuisées, des prestataires qui pilotent parfois plus qu’ils ne sont pilotés, et une direction qui veut des résultats immédiats sans toujours accepter le coût des arbitrages. Dans ce contexte, les trente premiers jours valent plus qu’un trimestre, parce qu’ils fixent ta légitimité, ton périmètre réel, et la manière dont l’organisation va te lire : comme un pompier de passage, ou comme un pilote capable de remettre une trajectoire.

Le piège classique consiste à se perdre dans l’analyse, à vouloir “tout comprendre” avant d’agir, ou à promettre une transformation spectaculaire avant d’avoir sécurisé le socle. Un DSI de transition n’est pas jugé sur son vocabulaire mais sur sa capacité à prendre des décisions structurantes, visibles, et justifiables, qui changent l’état du système. Les titres ci-dessous sont ces décisions-là : elles sont opérationnelles, politiques au bon sens du terme, et elles ont un effet immédiat sur la stabilité, la crédibilité et l’exécution.

Dire la vérité sur l’état de l’IT, tout de suite

La première décision n’est ni technologique ni organisationnelle, c’est un choix de posture : est-ce que tu entres en minimisant pour ne pas inquiéter, ou en nommant la réalité pour installer un cadre clair. Beaucoup d’organisations ont été rassurées trop longtemps avec des phrases du type “c’est sous contrôle” alors que personne n’était réellement maître des risques. En transition, tu n’as pas ce luxe, car ta valeur, c’est la lucidité et l’action.

L’objectif des dix premiers jours n’est pas de produire un audit encyclopédique, mais une photographie nette, compréhensible par un Comex : disponibilité des services clés, niveau de dette et d’obsolescence, risques cyber immédiats, dépendances critiques à des personnes ou des fournisseurs, capacité réelle de delivery, et principaux points de rupture. Une page, des faits, des exemples concrets, et une hiérarchie de risques. Cette vérité initiale devient ton contrat moral : elle protège l’entreprise, elle protège l’équipe, et elle te protège toi, parce qu’elle fixe le terrain de jeu.

Obtenir un mandat explicite et opposable

Un DSI de transition sans mandat clair devient un paravent : on lui demande d’assumer les conséquences, sans lui donner l’autorité pour arbitrer. Dès la première semaine, tu dois faire clarifier ce qui, sinon, se transformera en conflit larvé : qui décide quand ça bloque, quel est ton niveau d’autorité sur les équipes et les prestataires, et quel est le critère de succès de la mission.

Un mandat utile ressemble à un accord de gouvernance : accès direct aux décideurs pour arbitrer vite, capacité d’imposer des règles de pilotage, possibilité de geler ou de re-séquencer des projets si la stabilité est menacée, et soutien explicite pour “faire bouger des lignes” côté métiers et achats. Sans cette base, tu deviens celui qui explique pourquoi ça n’avance pas, au lieu de celui qui fait avancer.

Choisir l’ordre des opérations : stabiliser avant de transformer

Tout le monde voudra tout à la fois : accélération, modernisation, IA, cloud, réduction des coûts, refonte d’outils, renforcement cyber. La question n’est pas “quoi”, mais “dans quel ordre”. La décision structurante du premier mois consiste à trancher entre deux scénarios : on sécurise et on stabilise d’abord les services vitaux, ou on se lance immédiatement dans la transformation en espérant que le run tiendra.

La plupart des échecs naissent d’un fantasme : transformer pendant que la prod tremble, en ajoutant des chantiers lourds à une organisation déjà saturée. En transition, ta crédibilité vient d’une règle simple : si un incident sérieux peut arrêter la chaîne de valeur, alors tu n’as pas le droit moral de promettre une grande bascule avant d’avoir réduit ce risque. Cela ne veut pas dire freiner, cela veut dire séquencer intelligemment : stabiliser, réduire les risques majeurs, puis accélérer la delivery sur des fondations plus solides.

Définir les services vitaux et les protéger comme des actifs stratégiques

Dans beaucoup d’entreprises, on connaît la liste des applications, pas la liste des services qui font tourner le business. Or ce ne sont pas des serveurs qui font de l’argent, ce sont des services : prise de commande, facturation, production, rendez-vous, encaissement, supply, relation client, paie. La transition est le bon moment pour déplacer la conversation du “parc applicatif” vers “ce qui doit tenir”.

Tu formalises une liste courte, typiquement dix à vingt services vitaux. Pour chacun, tu poses un propriétaire métier, un owner IT, un objectif de niveau de service, et un plan de protection minimal : supervision réellement utile, sauvegardes testées, procédure de restauration, mécanisme d’escalade, et dépendances cartographiées. Ce document, rendu visible, crée un effet immédiat : il fait tomber les discussions abstraites et oblige tout le monde à parler du réel.

Installer une règle d’arbitrage : une demande égale un trade-off

Un des premiers gestes de pilotage consiste à créer de la friction saine. Si tu laisses les demandes arriver en flux continu, tu fabriques une usine à frustration et tu encourages les contournements. La décision utile est simple : toute nouvelle demande prioritaire remplace quelque chose. Pas d’empilement, pas de “on va trouver des ressources”, pas de magie.

Cette règle a un effet politique fort, parce qu’elle renvoie l’arbitrage à son bon niveau. Tu n’es pas celui qui dit non, tu es celui qui fait choisir. Et quand c’est trop lourd, tu remontes rapidement la décision à la direction, sans laisser l’équipe absorber la violence en silence. C’est aussi comme ça que tu reprends la maîtrise des délais : en réintroduisant la notion de capacité, donc de réalité.

Verrouiller un mode de pilotage sans théâtre : cockpit, rituels, décisions

Au trentième jour, tu dois pouvoir piloter avec des instruments. Pas un tableau de bord décoratif, un cockpit d’exploitation. Quelques métriques, mais qui permettent d’agir : incidents majeurs et récurrents, disponibilité des services vitaux, backlog et délais, capacité de delivery, vulnérabilités critiques et patching, accès sensibles protégés, tendances de coûts, et points de saturation.

Le point clé n’est pas le reporting, c’est le rituel. Une revue hebdomadaire courte, factuelle, orientée décisions, où l’on tranche ce qui bloque. Si une réunion ne produit aucune décision, elle devient une scène de théâtre. En transition, ce théâtre est toxique : il rassure l’organisation à court terme et prépare l’échec à moyen terme.

Requalifier les prestataires : renforcer, recadrer, préparer la sortie

La plupart des DSI en crise ont un point commun : un empilement de contrats, une dépendance à des partenaires historiques, et une difficulté à savoir qui tient réellement la barre. La décision du premier mois n’est pas de tout renégocier, mais de classer clairement les prestataires : ceux qui sont fiables et qu’on renforce, ceux qu’on recadre avec des engagements mesurables, et ceux qu’on prépare à remplacer.

Tu clarifies aussi un principe vital : un prestataire non piloté devient un gouvernement autonome. Tu imposes un pilotage simple, des livrables, des SLA/OLA réalistes, et un mécanisme de suivi. Et surtout, tu identifies les zones de risque : dépendance à une personne, absence de documentation, verrouillage contractuel, ou coûts qui dérivent sans explication.

Imposer trois gestes cyber non négociables

La cybersécurité est le domaine où l’on peut perdre la confiance, l’argent et parfois l’activité en une nuit. En transition, tu ne construis pas un “programme cyber” complet en trente jours, mais tu peux prendre des décisions qui réduisent le risque immédiatement. Les plus rentables sont rarement les plus glamour : authentification forte sur les accès sensibles, fermeture des accès externes non maîtrisés, hygiène sur les comptes et droits, et discipline minimale sur le patching des vulnérabilités critiques.

L’essentiel est de sortir de la posture “on verra plus tard”. Tu mets une ligne claire : ces points-là ne se négocient pas, parce qu’ils protègent l’entreprise. Et tu documentes l’écart entre l’état réel et l’état attendu. Le jour où un incident survient, la phrase “on ne savait pas” ne doit plus être possible.

Mettre fin à l’amnésie : runbooks, documentation minimale, propriété claire

Une DSI fragile est souvent une DSI amnésique. Des systèmes tiennent parce que trois personnes savent des choses non écrites, des accès existent sans trace, des procédures d’urgence sont dans des têtes, pas dans des runbooks. En transition, ce risque explose, parce que toi, tu n’as pas l’histoire, et l’organisation a parfois vécu trop longtemps dans l’implicite.

La décision consiste à imposer une règle légère mais ferme : tout service vital a une documentation opérationnelle minimale et à jour. Pas une encyclopédie, un guide d’intervention. Où sont les logs, où sont les accès, comment on escalade, comment on restaure, quelles sont les dépendances. Cette discipline n’est pas de la bureaucratie, c’est la condition pour industrialiser, déléguer, sécuriser, et arrêter de vivre sous perfusion de héros.

Protéger l’équipe et reconstruire la confiance avec le business

La décision la plus sous-estimée du premier mois n’est pas technique : c’est de décider que l’équipe ne sera plus sacrifiée pour compenser l’absence d’arbitrage. Beaucoup de DSI arrivent en transition dans un climat d’usure : trop de pression, trop d’urgence, trop d’injonctions contradictoires, et une relation dégradée avec les métiers. Si tu veux délivrer, tu dois remettre de la fierté, du cadre et de la sécurité psychologique.

Concrètement, tu stoppe les escalades sauvages, tu clarifies les règles de contact, tu fixes un processus de priorisation, tu rends visibles les contraintes, et tu assumes les arbitrages devant la direction. Le message doit être simple : l’IT n’est pas un paillasson, c’est une fonction critique. Quand tu protèges l’équipe, tu ne fais pas du social, tu fais de la performance, parce qu’une équipe qui respire délivre mieux, plus durablement, et avec moins d’erreurs.

Installer un système de décision, puis accélérer

Ces dix décisions ont un point commun : elles te permettent de reprendre la maîtrise du récit. Tu n’es pas là pour réciter des tendances, tu es là pour rendre le système pilotable, arbitrable, et fiable. Au bout de trente jours, la question n’est pas d’avoir “lancé des projets”, c’est d’avoir installé une mécanique de décision et de pilotage : une liste de services vitaux, des règles de priorisation, un cockpit, un cadre prestataires, une hygiène cyber minimale, une base documentaire opérationnelle, et une équipe protégée.

Une fois ce socle en place, la transformation devient possible, parce qu’elle cesse d’être une fuite en avant. Elle devient une trajectoire, portée par des décisions, des preuves, et un rythme d’exécution. C’est exactement ce que l’entreprise attend d’un DSI de transition : pas un discours, mais une reprise de contrôle.