DSI et crise : ce que l’on apprend quand il faut réparer en avançant

Il existe des transformations confortables. Elles se préparent longtemps, s’installent dans des calendriers maîtrisés, s’appuient sur des équipes disponibles, des budgets validés, des outils stabilisés et une gouvernance déjà en place. Elles avancent par étapes, dans un cadre clair, avec des comités réguliers et des jalons respectés.

Et puis il y a la vraie vie.

Dans la vraie vie des systèmes d’information, il arrive que la transformation doive se faire alors même que l’organisation est sous pression. Les incidents continuent d’arriver. Les utilisateurs attendent des réponses. Les projets ne s’arrêtent pas. Les fournisseurs doivent être pilotés. Les équipes sont parfois fatiguées, sous-dimensionnées ou désorganisées. Les outils en place ne suffisent plus. Les processus sont incomplets. La dette technique pèse. Et malgré tout, l’entreprise doit fonctionner.

C’est dans ces moments-là que le rôle du DSI prend toute sa dimension. Non pas dans le confort d’une stratégie parfaitement théorique, mais dans la capacité à réparer en avançant. Transformer sans attendre que toutes les conditions soient idéales. Reprendre le contrôle sans immobiliser l’entreprise. Stabiliser l’urgence tout en construisant le futur.

La crise a cette vertu brutale : elle enlève les illusions. Elle révèle très vite ce qui tient réellement et ce qui ne tenait que par habitude. Un système d’information peut sembler maîtrisé tant que tout fonctionne à peu près. Mais dès que la pression monte, les failles apparaissent. Les circuits d’escalade trop flous deviennent visibles. Les responsabilités mal définies ralentissent tout. Les fournisseurs insuffisamment pilotés créent de la dépendance. Les équipes sans cadre clair s’épuisent. Les outils mal déployés montrent leurs limites. Les décisions repoussées reviennent sous forme d’urgence.

Dans un environnement dégradé, le DSI ne peut pas se contenter d’analyser. Il doit agir. Mais agir ne signifie pas courir dans tous les sens. La première compétence en situation de crise est de remettre de l’ordre dans le désordre. Il faut distinguer ce qui est critique de ce qui est simplement bruyant. Il faut identifier les impacts réels. Il faut protéger les activités essentielles. Il faut prioriser les sujets qui empêchent l’entreprise de fonctionner. Et surtout, il faut décider.

Une DSI en crise souffre rarement uniquement d’un manque de technologie. Elle souffre souvent d’un manque d’arbitrage. Trop de sujets sont ouverts. Trop de priorités sont concurrentes. Trop d’acteurs attendent une réponse. Trop de décisions ont été différées. Le rôle du DSI est alors de réinstaller une hiérarchie claire : ce qui met l’activité en risque passe d’abord ; ce qui bloque les utilisateurs critiques doit être traité ; ce qui relève du confort attendra ; ce qui dépend d’un choix de direction doit être porté au bon niveau.

Cette discipline est essentielle, car la crise adore le flou. Elle prospère dans les organisations où chacun tire dans sa direction, où les escalades deviennent personnelles, où les fournisseurs se renvoient les sujets, où les équipes techniques reçoivent des injonctions contradictoires. Dans ce contexte, le DSI doit devenir un point fixe. Il doit donner le cap, fixer les priorités, protéger ses équipes des sollicitations inutiles et rendre visibles les décisions à prendre.

Réparer en avançant, c’est aussi accepter que l’on ne pourra pas tout remettre à plat immédiatement. C’est une différence majeure entre la transformation idéale et la transformation réelle. Dans un monde parfait, on redessinerait les processus avant de changer les outils. On stabiliserait les équipes avant de lancer les projets. On clarifierait les contrats avant de renforcer l’externalisation. On auditerait l’ensemble du système avant d’agir. Mais lorsque l’entreprise est déjà sous tension, on doit souvent intervenir sur un moteur qui tourne.

Cela impose une méthode particulière. Il faut sécuriser d’abord les points vitaux, puis améliorer progressivement le reste. Stabiliser le support. Clarifier les escalades. Reprendre le pilotage fournisseur. Mettre sous surveillance les incidents majeurs. Identifier les zones de fragilité. Communiquer mieux avec les métiers. Donner aux équipes des règles simples et applicables. Ce ne sont pas toujours des gestes spectaculaires, mais ce sont eux qui redonnent de la maîtrise.

Dans ces périodes, le support informatique devient un thermomètre précieux. Il montre immédiatement où l’entreprise souffre. Les tickets, les relances, les délais, les irritants récurrents, les incidents mal orientés, les sites qui appellent sans cesse, les utilisateurs qui contournent les circuits officiels : tout cela raconte l’état réel de la DSI. Un DSI en crise doit savoir lire ces signaux. Non pour culpabiliser les équipes, mais pour comprendre où l’organisation perd sa capacité d’action.

Les fournisseurs jouent également un rôle déterminant. En situation normale, un prestataire mal piloté peut produire de la friction. En situation de crise, il peut devenir un facteur d’aggravation. Lorsque les engagements ne sont pas clairs, lorsque les interfaces sont mal définies, lorsque les responsabilités sont diluées, la DSI perd du temps à chercher qui doit faire quoi. Le DSI doit donc reprendre la main : clarifier les attendus, imposer des points de suivi, documenter les écarts, obtenir des plans d’action, et rappeler que l’externalisation ne supprime jamais la responsabilité de pilotage.

Mais la crise est aussi une épreuve humaine. Les équipes IT sont souvent en première ligne. Elles encaissent la pression des utilisateurs, les demandes des métiers, les urgences de la direction, les contraintes des fournisseurs et les limites du système existant. Elles peuvent donner beaucoup, parfois trop. Un DSI ne peut pas demander l’impossible indéfiniment. Il doit tenir une double exigence : obtenir des résultats et préserver les équipes.

Préserver ne veut pas dire baisser le niveau d’exigence. Cela signifie donner du cadre. Dire clairement ce qui est prioritaire. Éviter les sollicitations parasites. Reconnaître les efforts. Refuser que l’urgence permanente devienne un mode de management. Installer des rituels courts, utiles, orientés action. Faire circuler l’information. Décider vite. Et surtout, éviter que les équipes aient le sentiment d’être seules face au chaos.

La communication devient alors un outil de pilotage. Dans une crise IT, le silence coûte cher. Les utilisateurs supportent parfois mieux un problème expliqué qu’une absence totale de visibilité. Les métiers ont besoin de savoir ce qui se passe, ce qui est traité, ce qui prendra du temps, ce qui est prioritaire. La direction générale a besoin d’une lecture claire des risques et des décisions attendues. Les équipes ont besoin de comprendre le cap. Communiquer ne règle pas tout, mais cela réduit l’anxiété, les contournements et les escalades inutiles.

Réparer en avançant apprend aussi l’humilité. Une DSI peut avoir des plans, des outils, des comités, des indicateurs. Mais le réel résiste toujours. Un incident mal documenté, une dépendance oubliée, un fournisseur absent, une application critique connue de trois personnes seulement, un processus qui ne fonctionne que grâce à une habitude locale : la crise révèle les angles morts. Le DSI doit accepter de les regarder sans complaisance. C’est souvent inconfortable, mais c’est le point de départ d’une transformation solide.

Car la crise peut devenir un accélérateur. Elle met en lumière ce qui était déjà connu mais jamais traité. Elle oblige à trancher. Elle donne de la visibilité à des sujets que l’on repoussait. Elle force l’entreprise à reconnaître que l’IT n’est pas un simple support, mais une condition de fonctionnement. Lorsqu’elle est bien pilotée, une crise peut donc devenir le moment où l’organisation cesse de commenter ses problèmes et commence enfin à les résoudre.

Encore faut-il ne pas confondre vitesse et agitation. Transformer en environnement dégradé ne consiste pas à empiler des actions dans l’urgence. Cela consiste à créer un mouvement maîtrisé. Chaque action doit réduire un risque, clarifier une responsabilité, améliorer un processus, restaurer de la confiance ou renforcer la capacité d’exécution. Le DSI doit garder cette ligne : faire moins de bruit, mais produire plus d’effet.

Les directions générales ont un rôle important dans cette dynamique. Elles doivent comprendre qu’une DSI en crise ne peut pas être redressée par injonction. Elle a besoin d’arbitrages, de soutien, de moyens ciblés et d’un accès clair aux décisions. Demander à l’IT de faire mieux sans traiter les causes structurelles revient à demander à une équipe de réparer une fuite tout en continuant d’ouvrir les vannes. Le DSI doit pouvoir dire ce qui est faisable, ce qui ne l’est pas, ce qui est risqué et ce qui exige un arbitrage de haut niveau.

Au fond, ce que l’on apprend dans ces moments-là, c’est que la maturité IT ne se mesure pas lorsque tout va bien. Elle se mesure lorsque l’organisation est sous contrainte. Une DSI mature sait prioriser. Elle sait communiquer. Elle sait escalader. Elle sait piloter ses fournisseurs. Elle sait protéger ses équipes. Elle sait apprendre des incidents. Elle sait transformer une urgence en amélioration durable.

Réparer en avançant n’est pas une méthode confortable. C’est une discipline de dirigeant. Elle exige du sang-froid, de la lucidité, du courage managérial et une vraie capacité d’exécution. Elle oblige à voir le réel tel qu’il est, pas tel qu’il aurait dû être. Elle impose de décider avec des informations imparfaites, d’agir sans attendre le contexte idéal, puis de corriger rapidement.

C’est précisément là que le DSI apporte sa valeur. Pas seulement comme responsable technique, mais comme dirigeant capable de remettre l’entreprise en mouvement dans un moment difficile. Quand les conditions sont dégradées, quand l’organisation doute, quand les équipes sont sous pression et que les métiers attendent des réponses, il ne s’agit plus de produire un discours sur la transformation. Il faut la faire.

Et parfois, c’est dans ces périodes imparfaites, tendues, inconfortables, que l’on construit les transformations les plus solides. Parce qu’elles ne partent pas d’une théorie. Elles partent du réel.