Accueil / IT & Science & Technology / Redresser l’exploitation IT avant de lancer de nouveaux projets

Redresser l’exploitation IT avant de lancer de nouveaux projets

Illustration originale — Redresser l’exploitation IT avant de lancer de nouveaux projets

Redresser l’exploitation IT avant de lancer de nouveaux projets

Situation illustrative : lundi matin, le comité exécutif veut confirmer le lancement d’un CRM. Au même moment, l’ERP ralentit les expéditions, la supervision produit trop d’alertes inutiles et trois incidents ont été refermés sans cause établie. Le DSI ne manque pas de projets ; il manque d’une exploitation capable d’absorber un changement supplémentaire. Sa décision responsable n’est pas d’accélérer, mais de rendre le RUN prévisible avant d’engager les mêmes experts sur une nouvelle promesse.

Le projet neuf consomme une capacité déjà engagée

L’erreur classique consiste à comparer un projet à son budget, comme si l’exploitation disposait d’une équipe distincte et extensible. Or les compétences rares sont partagées : administrateurs ERP, architectes, spécialistes réseau, sécurité, données ou interfaces. Chaque incident majeur mobilise ceux dont dépend le prochain jalon. Le portefeuille paraît finançable, mais ne l’est plus en compétences disponibles.

Le mécanisme de dégradation devient alors circulaire. Les incidents interrompent les travaux de fond ; les correctifs provisoires s’accumulent ; la maintenance est repoussée ; les alertes se multiplient ; les mêmes personnes sont rappelées. Le retard projet est ensuite traité par davantage de pression, ce qui réduit encore le temps consacré aux causes racines. Avant tout nouveau lancement, le DSI doit donc séparer la capacité dédiée au fonctionnement, à la résilience et aux projets, compétence par compétence, et non en journées indifférenciées.

Établir les faits sans attendre un diagnostic parfait

Le redressement commence par une photographie courte et vérifiable. Quels services soutiennent directement l’activité ? Quels incidents ont récidivé ? Quelles protections temporaires restent en place ? Quels changements ont échoué ? Où les astreintes, contrats ou procédures d’escalade présentent-ils un vide ? Cette revue distingue les faits, les hypothèses techniques et les décisions attendues. Elle évite qu’une intuition forte soit transformée en certitude collective.

Une récidive affectant l’activité appelle immédiatement une protection, même si l’analyse causale continue. Inversement, redémarrer un serveur ne clôt pas l’incident si personne ne sait pourquoi il est tombé. Le responsable RUN doit tenir ensemble restauration du service, réduction du risque immédiat et traitement de la cause. Supprimer un niveau fabrique la prochaine crise.

Installer une cadence qui force les décisions

Une exploitation instable ne se redresse pas avec un tableau de bord mensuel. Il faut une cadence adaptée aux enjeux : revue quotidienne des incidents critiques et des décisions ouvertes ; revue hebdomadaire de la capacité, des changements risqués, des problèmes récurrents et des engagements fournisseurs. Chaque point doit avoir un propriétaire, une échéance utile et une règle d’escalade. Le comité ne sert pas à commenter des couleurs, mais à décider qui fait quoi, avec quelle priorité et au détriment de quel autre travail.

Le DSI ou le manager de transition rétablit aussi les droits de décision. Qui accepte un risque résiduel ? Qui autorise un changement urgent, suspend une mise en production ou arbitre avec un fournisseur ? Sans réponses explicites, les équipes compensent par des accords informels, jusqu’au jour où un incident révèle que chacun croyait l’autre responsable.

Mesurer la stabilité plutôt que l’activité

Le volume de tickets fermés renseigne peu sur la santé du RUN. Des indicateurs utiles observent les incidents critiques, leur récidive, le délai de rétablissement, l’ancienneté des problèmes sans cause traitée, le taux d’échec des changements, les alertes actionnables et la capacité absorbée par les interruptions. Aucun seuil universel ne remplace le contexte ; il faut suivre une tendance et expliquer ses ruptures.

La mesure doit aussi relier technique et activité. Un service peut afficher une disponibilité acceptable tout en dégradant les expéditions, la facturation ou l’accès des utilisateurs. À l’inverse, une hausse temporaire des tickets peut refléter une meilleure détection. Le dirigeant demande donc deux lectures : ce qui arrive au système et ce que cela produit pour l’entreprise. Cette articulation évite d’optimiser un indicateur tout en déplaçant le dommage.

Protéger le redressement contre les fausses urgences

Trois erreurs fragilisent la reprise. Geler tous les changements d’abord : correctifs de sécurité, obligations proches et protections indispensables exigent une voie rapide, documentée et plafonnée. Remplacer ensuite les outils avant de clarifier les pratiques : une nouvelle plateforme reproduira un processus confus. Confier enfin le redressement au fournisseur principal : le client doit conserver la priorité des travaux et l’acceptation des risques.

Il faut également résister au projet « presque prêt » dont personne n’ose revoir la date. Les coûts déjà engagés n’ajoutent ni compétence ni disponibilité. Maintenir un jalon irréaliste peut même masquer le prix du RUN : experts détournés, dette différée et contrôles contournés. Replanifier n’est pas renoncer ; c’est rendre visibles les conditions d’un lancement défendable.

Décider quand relancer, et à quel prix

La relance ne dépend pas d’une impression de calme. Elle devient raisonnable lorsque les incidents majeurs sont contenus, les récidives analysées, les changements mieux maîtrisés, les responsabilités explicites et la capacité mobilisable démontrée sur plusieurs cycles de pilotage. Le DSI peut alors proposer un lancement limité, avec critères d’arrêt, ressources nommées et réserve protégée pour l’exploitation.

L’arbitrage final reste économique et opérationnel : quel bénéfice attend-on du projet, quel risque supplémentaire fait-il porter aux services existants, et quel travail faut-il différer pour le rendre possible ? Si aucune activité n’est retirée, le prétendu choix consiste seulement à surcharger l’équipe. DSI EN CRISE : Reprendre le contrôle de l’IT, des ERP et des grands programmes approfondit précisément cette logique de reprise en main : protéger l’activité, fiabiliser le diagnostic, clarifier les responsabilités puis maîtriser coûts, fournisseurs et programmes. La règle de dirigeant tient en une phrase : ne pas lancer parce que la crise semble passée, mais parce que l’exploitation a retrouvé la capacité prouvée de supporter la suite.

Pour approfondir

Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon

Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon

Consulter la référence

Consulter la référence

#ManagementDeTransition #DSI #DirectionDeTransition #GuyDeLussigny #TransformationNumerique

Répondre

Traduction