RUN Vs BUILD : Pourquoi La Dette Opérationnelle Tue Plus De Directions IT Que La Dette Technique

Temps de lecture : 8 minutes — Catégorie : Pilotage IT

Le débat qu’on ne tient jamais en COMEX

Demandez à un DSI ce qu’il préfère présenter à son COMEX : un projet de transformation, ou une demande de budget pour le RUN.

Vous connaissez la réponse.

Le projet, c’est positif. Ça parle de futur, d’innovation, d’avantage compétitif. La demande de budget RUN, c’est une corvée. Ça parle de maintenance, de remplacement, de « on a besoin pour fonctionner ». Personne n’aime ça. Pas même les DSI eux-mêmes, qui finissent par sous-investir leur propre RUN parce que le COMEX y est insensible.

Et c’est exactement comme ça que se construit la dette opérationnelle. Une dette qu’on ne voit jamais venir, qui ne fait pas de bruit, et qui — un beau matin — prend la forme d’un incident majeur, d’une équipe qui démissionne en bloc, ou d’une cyberattaque qui prospère sur des systèmes qu’on aurait dû durcir il y a trois ans.

J’ai passé l’essentiel de ma carrière en direction des opérations IT, dans des environnements à forte intensité — banque, infrastructure mutualisée multi-clients, télécom. J’ai vu les deux dettes côte à côte. Je peux affirmer ceci : la dette opérationnelle tue plus de directions IT que la dette technique. Et personne n’en parle.

D’abord, mettons les définitions au clair

La dette technique, tout le monde connaît. C’est le code mal écrit, l’architecture monolithique qu’on n’a jamais refactorée, le framework qui n’a pas été migré depuis huit ans. Elle est portée par les équipes BUILD. Elle se mesure (plus ou moins). Elle se présente bien en COMEX parce qu’elle a un visage : « modernisons la stack pour aller plus vite ».

La dette opérationnelle, c’est autre chose. Elle s’accumule dans le RUN, et elle prend des formes très concrètes :

Un parc qui n’est plus tout à fait dans la CMDB
Des sauvegardes qu’on n’a pas retestées depuis 18 mois
Une supervision qui couvre 70 % du périmètre — les 30 % qui manquent étant souvent les plus critiques
Trois ou quatre personnes qui détiennent un savoir non documenté sur des systèmes vitaux
Des contrats d’infogérance dont on ne connaît plus les SLA contractuels par cœur
Des comptes à privilèges qui n’ont jamais été audités
Des serveurs en fin de support qu’on a « oublié » de migrer
Des alertes de monitoring que l’équipe a mises en silencieux parce qu’elles « polluaient » les écrans

Aucun de ces points n’est un drame. Pris ensemble, ils sont la cause de la majorité des crises majeures que j’ai vues éclater dans ma carrière.

Pourquoi la dette opérationnelle est plus dangereuse que la dette technique

Première raison : elle est invisible. La dette technique se voit dans le code, dans les outils d’analyse de qualité, dans les durées de développement. La dette opérationnelle, elle, n’apparaît dans aucun tableau de bord. Vous pouvez avoir une CMDB à 60 % de couverture pendant trois ans sans que personne au COMEX en entende parler — jusqu’au jour où un incident touche un actif « qui n’aurait pas dû être là ».

Deuxième raison : elle s’accumule par défaut. La dette technique est une décision : on choisit de prendre un raccourci pour aller plus vite. La dette opérationnelle est une non-décision : on n’a pas planifié le test PRA, on n’a pas pris le temps de finir la documentation, on n’a pas remplacé le serveur en fin de support parce qu’il « tient encore ». Personne n’a décidé. C’est arrivé.

Troisième raison : elle se révèle sous forme de crise. La dette technique se révèle progressivement : les développeurs vous disent qu’ils sont lents, vous voyez les vélocités baisser, vous arbitrez. La dette opérationnelle se révèle d’un coup : un incident en production à 3 heures du matin, un ransomware qui chiffre des sauvegardes non testées, un audit cyber qui découvre 200 serveurs hors politique.

Quatrième raison — la plus grave : elle mine la confiance entre IT et métiers. Une dette technique gérée se discute entre techniciens. Une dette opérationnelle qui explose se voit du COMEX. Et là, ce n’est plus le DSI qui pilote la conversation — c’est la DAF qui demande pourquoi, et la DRH qui se plaint des outils qui rament, et le DG qui se demande pourquoi il paie aussi cher pour aussi peu.

Les six formes de dette opérationnelle que je rencontre le plus souvent

Voici ce que je vois, mission après mission, dans des contextes très différents :

1. La dette de connaissance

Trois personnes savent comment fonctionne le système de paiement. Deux sont en CDD ou en contrat de prestation. Une est sur le départ. La documentation existe, mais elle date de la version précédente — celle d’il y a six ans.

C’est souvent la dette la plus toxique parce qu’elle est invisible jusqu’au jour où l’une des trois personnes part. Et ce jour-là, ce n’est plus une dette, c’est une perte sèche.

2. La dette de supervision

L’outil de monitoring couvre les serveurs, mais pas les middleware applicatifs. Les alertes critiques sont mélangées aux alertes informatives, ce qui fait qu’on ignore les deux. Les seuils n’ont pas été revus depuis la dernière migration.

Symptôme typique : les incidents sont remontés par les utilisateurs, pas par la supervision.

3. La dette de sauvegardes

Les sauvegardes tournent. Les indicateurs sont au vert. Mais personne n’a testé une restauration grandeur nature depuis 18 mois. Et quand on demande « combien de temps pour restaurer le système X en cas de désastre », la réponse honnête est « on ne sait pas vraiment, on n’a jamais essayé en conditions réelles ».

C’est exactement sur cette dette que prospèrent les campagnes de ransomware modernes — qui ciblent désormais les sauvegardes en priorité avant de chiffrer la production.

4. La dette de comptes et de droits

Personne n’a fait le tour des comptes à privilèges depuis le dernier audit. Les anciens prestataires ont peut-être encore des accès. Les comptes de service sont partagés entre plusieurs applications. Le MFA est déployé, mais avec 15 % d’exceptions « temporaires » qui durent depuis deux ans.

C’est la dette qui transforme une intrusion mineure en compromission générale.

5. La dette de contrats fournisseurs

Le contrat d’infogérance a été signé en 2019, renouvelé tacitement en 2022, et personne n’a vraiment relu les SLA depuis. Les pénalités contractuelles n’ont jamais été appliquées. Le fournisseur a changé de COMEX, votre interlocuteur n’est plus le même que celui qui avait négocié.

Quand vous voulez sortir, vous découvrez que la clause de réversibilité est faible — voire absente. Et que les coûts de sortie représentent 6 à 12 mois de prestation.

6. La dette de fin de vie

Des serveurs en fin de support constructeur. Des versions d’OS qui ne reçoivent plus de patches de sécurité. Des middlewares dont l’éditeur a été racheté trois fois depuis. Vous avez payé du support étendu une fois, deux fois, et puis un jour le constructeur ferme la ligne.

Cette dette-là ne pardonne pas : elle est binaire. Tant que ça marche, ça marche. Le jour où ça ne marche plus, vous avez une crise.

Pourquoi cette dette s’installe : trois mécanismes structurels

Il ne s’agit pas d’incompétence. Les directions IT que je vois s’enliser dans la dette opérationnelle sont souvent dirigées par des gens compétents. Le problème est structurel.

Mécanisme 1 — L’asymétrie de visibilité. Un projet BUILD a un sponsor métier, une date, un budget, un comité. Une action de RUN n’a souvent ni sponsor explicite, ni date, ni comité. Elle disparaît dans la routine. Quand il faut arbitrer, le BUILD gagne toujours — parce qu’il est mieux représenté.

Mécanisme 2 — La pression sur les coûts unitaires. Quand le COMEX demande « combien coûte une heure de service desk » ou « combien coûte un poste de travail », il pousse mécaniquement à comprimer le RUN. Les actions de durcissement, de documentation, de formation des équipes sont les premières sacrifiées. Elles sont invisibles dans les coûts unitaires.

Mécanisme 3 — Le biais des indicateurs. Les indicateurs RUN classiques (disponibilité, MTTR, taux de résolution N1) mesurent ce qui s’est passé, pas ce qui aurait pu se passer. Vous pouvez avoir 99,9 % de disponibilité tout en accumulant trois ans de dette opérationnelle. Les indicateurs ne le verront pas — jusqu’à l’incident qui change tout.

Ce qu’il faut faire, et qui n’est pas glamour

Je ne vais pas vous vendre une méthode magique. La gestion de la dette opérationnelle n’est pas glamour, et c’est précisément pour ça qu’elle est négligée.

Voici ce qui, dans mes missions, fait vraiment la différence :

1. Nommer la dette opérationnelle au COMEX. Pas la dette technique — la dette opérationnelle. Avec un mot précis. Tant que personne ne la nomme, personne ne la voit. Une fois nommée, elle devient discutable.

2. La cartographier annuellement. Une revue annuelle de dette opérationnelle, sur les 6 catégories ci-dessus, avec une cotation simple (rouge / orange / vert). Pas un audit complet — une cartographie de dirigeant, lisible en 20 minutes.

3. Y allouer un budget dédié. 5 à 10 % du budget IT en gestion active de dette opérationnelle. Pas de la maintenance courante — du rattrapage de dette. Avec des objectifs annuels mesurables : « ramener la couverture EDR de 78 % à 100 % », « tester PRA sur les 3 systèmes critiques », « auditer les comptes à privilèges ».

4. Refuser certains projets BUILD. Oui, refuser. Aucun projet BUILD significatif ne devrait démarrer si la dette opérationnelle sur son périmètre n’a pas été regardée. C’est dur, c’est impopulaire, mais c’est la seule manière d’arrêter d’en créer plus qu’on n’en rembourse.

5. Faire du test la norme, pas l’exception. Test PRA annuel obligatoire, exercice cyber semestriel, restauration de sauvegarde mensuelle aléatoire. Ce qui n’est pas testé n’existe pas — vous ne l’apprendrez que le jour où vous en aurez besoin.

Le test honnête à faire ce trimestre

Si vous êtes DSI, DG, ou membre d’un COMEX qui a une fonction IT à charge, posez-vous trois questions cette semaine :

Quand a eu lieu le dernier test grandeur nature de notre PRA ? Si la réponse est « il y a plus de 18 mois » ou « je ne sais pas », la dette opérationnelle de votre organisation est probablement plus haute que vous ne le pensez.
Qui sait, individuellement, faire fonctionner notre système le plus critique ? Si la réponse tient sur une main, et qu’une de ces personnes peut partir dans les 12 mois, vous avez un problème.
Quel pourcentage du budget IT consacrons-nous explicitement au remboursement de dette opérationnelle ? Si vous n’avez pas de chiffre, c’est probablement zéro.

Ces trois questions ne nécessitent ni audit ni cabinet. Elles nécessitent juste de la lucidité — et le courage d’écouter la réponse.

Ce que ça change

Une organisation qui pilote sa dette opérationnelle aussi sérieusement que sa dette technique a trois caractéristiques :

Elle subit moins de crises majeures, et celles qu’elle subit, elle les contient mieux.
Ses équipes ops sont plus stables, parce qu’elles ne vivent pas en mode « sapeur-pompier » en permanence.
Elle peut accélérer en BUILD avec moins de risque, parce que ses fondations sont saines.

Ce n’est pas un sujet de transformation. C’est un sujet de pilotage. Et c’est précisément la responsabilité d’une direction IT mature.

Cet article fait partie de la série Pilotage IT. Si la dette opérationnelle de votre organisation appelle un regard extérieur, le premier échange est de 30 minutes, gratuit, et vous repartez avec 3 actions actionnables dès la semaine suivante.

Voir aussi : Reprendre la main sur les opérations IT — les 30 premiers jours et la page Management de transition Infrastructures & Opérations.