Dette technique et dette organisationnelle ne se résolvent pas pareil

Une situation illustrative suffit à montrer le piège. Un comité de direction constate des incidents récurrents sur l’ERP, des mises en production lentes et des audits de sécurité toujours tendus. Le DSI obtient un budget de modernisation. Six mois plus tard, les serveurs sont mieux maintenus, mais les incidents persistent : les équipes se renvoient les décisions, personne n’assume la qualité des données et le fournisseur arbitre de fait les priorités. L’entreprise a traité une partie de sa dette technique. Elle n’a presque pas touché à sa dette organisationnelle.

Deux dettes, deux mécanismes

La dette technique vient d’un écart accumulé entre le système existant et le niveau de robustesse attendu : versions obsolètes, interfaces fragiles, tests insuffisants, architecture incohérente, documentation lacunaire ou composants non supportés. Elle augmente le coût du changement et la probabilité d’incident.

La dette organisationnelle naît, elle, de responsabilités floues, de compétences absentes, de décisions contournées et de relations mal conçues entre métiers, IT, sécurité et fournisseurs. Elle ralentit l’arbitrage et empêche de corriger durablement les causes. Remplacer une application ne désigne pas un propriétaire de processus. Recruter un expert ne crée pas une gouvernance. Ajouter un comité ne produit pas une décision.

La distinction est opérationnelle : la dette technique se réduit principalement par des travaux sur le patrimoine numérique ; la dette organisationnelle par des choix de mandat, de responsabilité, de capacité et de comportement. Les confondre conduit à financer le mauvais remède.

Le diagnostic doit suivre les décisions empêchées

Un inventaire des technologies ne suffit pas. Le dirigeant doit partir des décisions que l’organisation n’arrive plus à prendre. Qui peut accepter un risque sur une application critique ? Qui tranche entre continuité de service et refonte ? Qui possède la qualité d’une donnée client ? Qui peut imposer une exigence de sécurité à un programme en retard ? Qui négocie réellement avec l’éditeur dominant ?

Chaque réponse imprécise signale une dette organisationnelle possible. Chaque réponse claire, mais rendue inexécutable par une plateforme fragile, révèle plutôt une dette technique. Souvent, les deux se renforcent : faute de responsable, une interface provisoire devient permanente ; devenue critique, elle rend tout changement dangereux et encourage l’inaction.

Le DSI ou le RSSI doit donc relier chaque symptôme à une chaîne causale. Un incident récurrent peut venir d’un composant ancien, d’une absence de tests, d’un contrat mal piloté ou d’un processus métier dont personne ne maîtrise les exceptions. Le bon diagnostic ne cherche pas un coupable ; il identifie le niveau où l’arbitrage doit avoir lieu.

Séparer les portefeuilles pour rendre les choix visibles

Mettre toutes les corrections dans un unique « plan de transformation » masque les responsabilités. Il faut constituer deux portefeuilles liés, mais distincts. Le portefeuille technique décrit les actifs concernés, le risque réduit, les dépendances, l’effort, les fenêtres d’intervention et les conséquences d’un report. Le portefeuille organisationnel décrit les rôles à clarifier, les compétences à acquérir, les délégations à établir, les instances à supprimer ou à renforcer et les fournisseurs à remettre sous contrôle.

Cette séparation évite un biais fréquent : financer ce qui se voit. Une migration dispose d’un calendrier et d’un chef de projet ; la clarification entre DSI, CTO, RSSI et directions métier paraît moins tangible. Pourtant, une architecture neuve exploitée avec des responsabilités anciennes recrée rapidement les mêmes fragilités.

Traiter dans l’ordre qui réduit le risque réel

La démarche peut avancer en cinq temps. D’abord, sélectionner quelques services vitaux, non l’ensemble du SI. Ensuite, cartographier pour chacun les composants critiques, les responsables de décision, les compétences indispensables et les dépendances fournisseurs. Puis qualifier séparément les dettes, avec une conséquence métier explicite : arrêt d’activité, délai de lancement, exposition cyber, données non fiables ou coût impossible à maîtriser.

Quatrième temps : décider des séquences couplées. On peut, par exemple, nommer un propriétaire métier avant de refondre un référentiel, renforcer le pilotage fournisseur avant une migration cloud, ou fixer l’autorité du RSSI avant de revoir les dérogations. Enfin, inscrire chaque action dans une trajectoire arbitrée, avec un responsable unique, une échéance et un critère de sortie. « Améliorer la gouvernance » n’est pas une action ; attribuer le pouvoir de trancher et vérifier qu’il est exercé en est une.

Mesurer autre chose que l’avancement des projets

Les indicateurs doivent montrer si la dette cesse de produire ses effets. Côté technique : incidents récurrents, temps de restauration, fréquence des changements échoués, composants hors support, couverture des tests sur les services critiques, délai nécessaire pour modifier une interface. Côté organisationnel : décisions en attente, dérogations sans propriétaire, postes critiques sans relais, actions bloquées entre directions, dépendances à une seule personne ou à un fournisseur, écarts entre SLA affichés et expérience utilisateur.

Un tableau de bord utile rapproche les deux familles. Si les incidents diminuent mais que les décisions restent bloquées, la stabilisation est fragile. Si les rôles sont clarifiés mais que les équipes ne peuvent toujours pas livrer sans risque, la gouvernance reste théorique. La direction générale doit voir cette tension, car le budget IT devient alors un portefeuille d’arbitrages plutôt qu’une masse défensive.

L’arbitrage final appartient à la direction

Trois erreurs reviennent : lancer une refonte globale pour éviter les arbitrages difficiles, réorganiser sans financer la remise à niveau technique, ou confier au fournisseur la définition des priorités. Une autre consiste à recruter trop vite : un profil très technique ne corrigera pas une absence de mandat ; un stratège sans prise opérationnelle ne restaurera pas le service.

Le choix final n’oppose donc pas technologie et organisation. Il consiste à déterminer quelle dette empêche l’autre d’être traitée. Si une plateforme menace la continuité, la sécurisation technique passe d’abord, avec une gouvernance provisoire explicite. Si les responsabilités sont introuvables, investir massivement avant de les clarifier risque d’industrialiser le désordre. C’est précisément l’enjeu d’une gouvernance numérique mature : comprendre assez la technologie pour décider, mais regarder l’organisation pour que la décision produise réellement ses effets.

Pour approfondir

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

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

Consulter la référence

Consulter la référence

#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique