De la crise au run : comment stabiliser un SI en 10 actions

Quand un SI entre en crise, le réflexe naturel est de “faire plus” : plus de tickets, plus d’escalades, plus de réunions, plus d’outils, plus de messages. On remplit les journées de mouvements… et le système continue de tomber. Parce qu’en crise, le problème n’est pas l’énergie. Le problème, c’est l’absence de structure. Stabiliser un SI, ce n’est pas “travailler dur”, c’est reprendre le contrôle du risque, de la priorisation et de l’exécution.

Le passage de la crise au run ne se fait pas en annonçant une roadmap. Il se fait en appliquant une séquence d’actions simples, parfois impopulaires, qui réduisent immédiatement la variabilité : moins de changements inutiles, plus de visibilité, moins d’effets domino, plus de discipline. Le rôle d’un DSI de transition est précisément là : installer un cadre qui permet aux équipes d’arrêter de courir et de commencer à résoudre.

Voici dix actions qui, prises dans cet ordre, permettent souvent de faire basculer un SI en crise vers un run maîtrisé.

Clarifier le périmètre de crise et les services critiques

Avant de résoudre, il faut nommer. “Tout est critique” est une phrase qui empêche d’agir. La première action consiste à identifier les services réellement vitaux : ceux qui arrêtent la production, la vente, la relation client, les opérations terrain, ou la conformité. On ne cherche pas l’exhaustivité, on cherche la vérité opérationnelle.

En parallèle, on établit un périmètre de crise clair : quelles applications, quelles infrastructures, quelles interfaces, quels sites. La crise doit avoir des frontières, sinon elle devient un bruit permanent.

Mettre en place un rituel de crise court, quotidien, et décisionnel

Les organisations adorent les réunions longues. En crise, elles sont toxiques. Ce qu’il faut, c’est un rituel court, quotidien, à heure fixe, avec un ordre du jour immuable : état des incidents majeurs, décisions du jour, actions à 24 heures, risques, escalades nécessaires. Pas de digressions, pas de débats théoriques, pas de compte rendu roman.

Le but n’est pas d’informer. Le but est de décider et d’exécuter. La crise se résout quand le rythme de décision dépasse le rythme des incidents.

Mettre un classement simple des incidents et l’imposer à tous

Un SI en crise souffre d’un problème typique : tout remonte en “urgent”. Donc plus rien ne l’est. Il faut imposer une classification simple, compréhensible par tous, qui distingue au minimum : incidents majeurs (impact business), incidents significatifs (dégradation), incidents mineurs (irritants), demandes (évolutions).

Ce classement doit être relié à des règles de traitement : un incident majeur déclenche une cellule dédiée, un owner, une heure de mise à jour, une communication. Sans classification, l’organisation réagit à l’émotion. Avec classification, elle agit sur le réel.

Appliquer un gel des changements ciblé, pas un arrêt total

Le gel des changements n’est pas une punition, c’est un médicament. Il ne s’agit pas d’arrêter toute évolution, mais de stopper ce qui ajoute du risque sans valeur immédiate. En crise, la variabilité est votre ennemie : chaque changement non maîtrisé peut déclencher un effet domino.

Le gel doit être ciblé : on autorise les changements correctifs, les patchs de sécurité critiques, et les modifications indispensables à la stabilité. Tout le reste passe en revue hebdomadaire. Un gel bien pensé réduit immédiatement la surface d’incertitude.

Créer une “liste courte” des causes probables et une chasse organisée

En crise, l’erreur classique est de traiter les symptômes. On corrige un serveur, puis un autre, puis on redémarre, puis on relance un service. Cela peut marcher un jour, mais ça ne stabilise pas. Il faut organiser la chasse aux causes profondes, même si elle prend plusieurs jours, et surtout la rendre visible.

On établit une liste courte des causes probables, basée sur les signaux : saturation, latence réseau, erreurs applicatives, incidents de base de données, configuration, dépendances externes, authentification, stockage, sauvegardes, certificats, etc. Puis on affecte des responsables d’investigation, avec des échéances. La crise n’est pas résolue quand le ticket est fermé. Elle est résolue quand la cause est neutralisée.

Renforcer l’observabilité : voir avant de deviner

Beaucoup de SI en crise souffrent d’un handicap majeur : on ne voit pas. Pas de métriques fiables, pas de logs corrélés, pas de traces, pas de cartographie des dépendances, donc on devine. Et deviner coûte cher, parce que ça multiplie les essais et les erreurs.

L’action clé est de renforcer l’observabilité des services critiques : monitoring des ressources, latence applicative, disponibilité, files d’attente, erreurs, temps de réponse, saturation, et surtout corrélation simple. Pas besoin d’un programme de 12 mois. Il faut un socle minimal, rapidement opérationnel, qui permet de répondre à trois questions : que se passe-t-il, où, et depuis quand.

Réduire la dette d’exploitation : standardiser, documenter, automatiser le minimum

En crise, on découvre les zones où la DSI dépend de quelques personnes, de scripts non maîtrisés, de procédures tacites. C’est le moment d’attaquer la dette d’exploitation, pas en lançant un grand chantier, mais en standardisant le minimum vital : runbooks pour les services critiques, procédures de redémarrage, checklists, accès, et automatisation des gestes répétitifs.

Chaque runbook écrit est une réduction de risque. Chaque automatisation simple est un gain de stabilité. Le run n’a pas besoin d’être élégant. Il doit être robuste.

Revoir les droits et les accès qui augmentent le risque en crise

En période de crise, on donne souvent des accès “pour dépanner”, et on oublie de les retirer. C’est un accélérateur de risque, notamment cyber. Une stabilisation durable implique de sécuriser les accès : comptes à privilèges, accès prestataires, bastion si disponible, MFA, et traçabilité.

La crise est aussi un révélateur : si la DSI ne sait pas qui a accès à quoi, elle n’est pas seulement en crise opérationnelle, elle est en crise de contrôle.

Mettre en place une communication simple, régulière, et non anxiogène

Quand le SI tombe, les métiers se sentent abandonnés. Ils multiplient les messages, les appels, les escalades. Et la DSI, déjà sous pression, se retrouve noyée. Il faut mettre en place une communication régulière : un point d’état à heure fixe, une page statut interne, des messages courts, factuels, sans jargon, avec des délais réalistes.

La bonne communication n’est pas un exercice de relations publiques. C’est un outil de réduction de bruit. Moins de bruit, plus de capacité à résoudre.

Sortir de la crise avec un plan de run : stabiliser, puis améliorer

La dernière action est souvent oubliée : préparer la sortie. Une crise se résout, puis on passe à autre chose… jusqu’à la prochaine. Pour passer de la crise au run, il faut formaliser un plan simple : ce qui reste fragile, ce qui doit être renforcé, ce qui doit être remplacé, et ce qui doit être gouverné.

Ce plan doit être court, priorisé, et lié aux services critiques. Il doit inclure les chantiers structurants qui empêchent le retour de crise : segmentation, patching, sauvegardes, refonte de dépendances, dette technique, amélioration de l’observabilité, etc. Stabiliser, c’est réduire les incidents. Passer au run, c’est réduire la probabilité de crise.

Ce qui fait la différence : moins d’agitation, plus de décisions

Stabiliser un SI en crise, ce n’est pas une question de chance. C’est une question de discipline. Un gel des changements bien piloté, une priorisation claire, une observabilité minimale, des runbooks, une gouvernance courte et décisionnelle… ce sont des gestes simples, mais rares, parce qu’ils demandent de trancher.

En management de transition, c’est exactement le cœur du métier : remettre une organisation en capacité d’agir. La crise est un moment violent, mais elle peut devenir un levier. Un SI stabilisé n’est pas un SI parfait. C’est un SI où l’entreprise reprend la main, où le run redevient prévisible, et où l’IT redevient un service au lieu d’être un feu permanent.