DSI en crise : les 30 premiers jours pour reprendre le contrôle

Autour de l’ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes

Quand un service critique tombe à nouveau, qu’un budget dérive et qu’un ERP avance vers une échéance devenue irréaliste, la première erreur consiste à traiter chaque symptôme séparément. On relance une cellule technique, on demande une nouvelle estimation financière, on reporte discrètement un jalon. L’activité continue pourtant de subir les mêmes fragilités, car personne ne dispose d’une vision fiable de la situation. Les trente premiers jours ne doivent donc pas servir à promettre un redressement spectaculaire. Ils doivent permettre de protéger l’entreprise, d’établir les faits et de restaurer une capacité de décision. C’est cette logique de reprise en main que développe DSI EN CRISE : Reprendre le contrôle de l’IT, des ERP et des grands programmes.

Jours 1 à 3 : sécuriser l’activité avant de transformer

La priorité initiale n’est ni la réorganisation de la DSI ni la relance de tous les projets. Elle est la continuité des opérations essentielles. Il faut identifier les services dont l’interruption empêche de produire, vendre, livrer, facturer ou assister les clients. Cette cartographie doit rester concrète : application concernée, processus métier dépendant, responsable opérationnel, solution de secours, délai acceptable de rétablissement et obstacle principal. Une plateforme instable mais contournable ne reçoit pas le même niveau d’attention qu’une interface bloquant quotidiennement l’expédition des commandes.

Cette première séquence impose aussi de séparer l’urgence réelle du bruit organisationnel. Les incidents récurrents, les vulnérabilités critiques, les sauvegardes non vérifiées et les dépendances concentrées chez une seule personne ou un seul fournisseur doivent être rendus visibles. À l’inverse, un projet en retard mais sans conséquence immédiate peut attendre quelques jours. Protéger l’activité signifie accepter cette hiérarchie, même lorsqu’elle contrarie le calendrier politique de certains programmes. Le diagnostic commence par une question simple : qu’est-ce qui peut réellement arrêter l’entreprise, et quelles mesures temporaires réduisent ce risque dès maintenant ?

Jours 4 à 10 : construire un diagnostic que chacun peut contester

Une crise informatique produit souvent plusieurs récits concurrents. Les équipes techniques invoquent une dette accumulée, les métiers dénoncent un manque de service, les achats soulignent les engagements contractuels et les fournisseurs expliquent que les demandes ont changé. Aucun de ces récits ne suffit. Le diagnostic doit relier les faits opérationnels, financiers, contractuels et décisionnels, puis distinguer ce qui est démontré, probable ou encore inconnu.

Pour chaque problème majeur, une fiche courte peut préciser le symptôme observé, son impact métier, les données disponibles, la cause supposée, les mesures déjà prises et la décision attendue. Ainsi, un ERP annoncé « presque prêt » doit être examiné à travers des éléments vérifiables : processus réellement testés, anomalies bloquantes, reprises de données contrôlées, interfaces disponibles, utilisateurs formés et conditions du basculement. L’objectif n’est pas de fabriquer un audit exhaustif en une semaine, mais d’empêcher les affirmations vagues de guider les arbitrages. Un bon diagnostic reste ouvert à la contradiction : il donne aux responsables les moyens de corriger une erreur, sans permettre que chaque désaccord repousse indéfiniment la décision.

Jours 11 à 20 : remettre les responsabilités et les fournisseurs à leur place

Un système d’information devient difficile à piloter lorsque les responsabilités sont dispersées. Un comité suit les coûts, un autre valide les priorités, le métier demande des modifications directement à l’intégrateur et la DSI découvre tardivement les conséquences techniques. Dans cette configuration, chacun participe, mais personne ne porte véritablement l’arbitrage. Reprendre le contrôle exige d’expliciter qui propose, qui expertise, qui décide et qui assume les conséquences.

Cette clarification doit s’appliquer aux fournisseurs. Il ne s’agit pas de les désigner comme responsables par principe, mais de rétablir une relation pilotable. Pour un contrat d’infogérance, on peut rapprocher incidents, niveaux de service, changements facturés, actions correctives et engagements non tenus. Pour un intégrateur ERP, il faut distinguer le périmètre commandé, les demandes nouvelles, les livrables acceptés et les réserves encore ouvertes. Une réunion fournisseur utile ne se limite pas à commenter un tableau de bord : elle débouche sur des actions datées, des responsables identifiés et une procédure d’escalade. La DSI retrouve ainsi sa fonction de maîtrise, sans prétendre réaliser elle-même tout ce qu’elle doit gouverner.

Jours 21 à 30 : arbitrer les coûts et les grands programmes

La dernière étape du premier mois consiste à transformer le diagnostic en décisions. Tous les projets ne peuvent pas conserver leur budget, leur périmètre et leur calendrier comme si la crise n’avait rien révélé. Le portefeuille doit être relu selon quelques critères stables : contribution à la continuité, risque réglementaire ou contractuel, valeur attendue, capacité réelle des équipes, dépendances techniques et coût restant à engager. Cette analyse peut conduire à poursuivre, ralentir, redimensionner, suspendre ou arrêter une initiative.

L’ERP mérite un traitement particulièrement lucide. Maintenir une date devenue intenable peut déplacer le risque vers la production, les utilisateurs ou la qualité des données. Reporter sans conditions précises ne résout rien non plus. La décision doit donc indiquer les critères nécessaires au prochain jalon, les écarts acceptés, les mesures de repli et l’autorité capable de prononcer un arrêt. De même, reprendre les coûts ne signifie pas appliquer une réduction uniforme. Il faut distinguer les dépenses qui protègent l’activité, celles qui préparent une transformation crédible et celles qui persistent faute d’arbitrage. Le budget redevient alors l’expression d’un choix, non l’addition de décisions anciennes.

Au terme du premier mois : retrouver une situation gouvernable

Trente jours ne suffisent pas à réparer un système d’information dégradé. Ils peuvent toutefois changer profondément la manière de le diriger. L’entreprise dispose alors d’une vision hiérarchisée de ses risques, d’un diagnostic discutable mais documenté, de responsabilités explicites et d’arbitrages assumés. Les fournisseurs savent ce qui est attendu, les équipes connaissent les priorités et les dirigeants peuvent décider sur des faits plutôt que sur des impressions.

La méthode proposée par DSI EN CRISE prend ainsi le contrepied des plans de transformation prématurés. Avant de moderniser, il faut stabiliser ; avant d’engager davantage, comprendre ; avant de fixer une nouvelle date, vérifier les conditions de réussite.

Découvrir le livre

DSI EN CRISE sur Amazon

#DSIEnCrise #DSI #ERP #ManagementDeTransition #GouvernanceIT #Transformation #Livre #Lecture #Livres #Culture