La plupart des patrimoines techniques comportent des composants dont personne n’est formellement responsable. Les scripts de déploiement qu’un fondateur, parti depuis, avait écrits en un week-end. L’intégration qu’une agence a construite, livrée puis transmise avant la fin de son contrat. Le serveur « provisoire » monté en 2021, qui achemine encore le trafic de production. Ces composants fonctionnent — souvent pendant des années — et c’est précisément pour cela qu’ils échappent à l’attention. Ils n’apparaissent sur aucun organigramme, aucune ligne budgétaire, aucun plan d’escalade.
Il ne s’agit pas de négligence, mais du résidu normal de la croissance : les personnes partent, les prestataires terminent leurs missions, les priorités avancent plus vite que la documentation. Or l’infrastructure orpheline accumule des coûts, et parce que ces coûts n’arrivent jamais sous forme de facture, ils sont systématiquement sous-estimés — jusqu’au jour où un incident, un audit ou une feuille de route bloquée les rend visibles.
Quatre coûts qui ne figurent sur aucune facture
Le coût de l’infrastructure orpheline est réel mais diffus. En pratique, il se concentre en quatre endroits.
- Latence des incidents. Quand un système sous responsabilité tombe en panne, le chemin d’escalade est connu et le diagnostic commence en quelques minutes. Quand un système orphelin tombe en panne, la première heure se passe à chercher qui l’a compris un jour, et les suivantes à lire du code que personne n’a touché depuis son écriture. La panne est parfois mineure ; le temps de diagnostic l’est rarement.
- Dépendance à une personne clé. La connaissance du composant réside dans une seule tête — parfois une tête qui a déjà quitté l’entreprise. Chaque mois où le composant reste sans documentation, le coût de cette absence s’alourdit en silence.
- Dérive de sécurité. Les systèmes orphelins manquent les cycles de correctifs, conservent des identifiants jamais renouvelés et reposent sur des frameworks en fin de vie. Ils ne sont pas attaqués plus souvent ; ils sont simplement moins défendus.
- Feuilles de route bloquées. Tôt ou tard, une migration, une exigence de conformité ou une fonctionnalité produit doit toucher au composant que personne ne comprend. L’estimation double, le projet absorbe le risque, et la feuille de route glisse pour des raisons difficiles à expliquer à la direction.
Comment la repérer : six signaux
Un audit complet n’est pas nécessaire pour repérer l’infrastructure orpheline. Une poignée de questions, posées honnêtement, en fera remonter l’essentiel.
- Il existe un système dont la défaillance n’alerterait personne, faute de figurer dans un monitoring ou dans une rotation d’astreinte.
- À la question « qui appelle-t-on si cela casse ? », la réponse est le nom d’une personne précise — et cette personne est partie, ou pourrait partir.
- Un développement réalisé par un prestataire ou une agence externe est toujours en production, alors que le contrat qui le couvrait a pris fin il y a plus d’un an.
- Votre équipe actuelle ne peut décrire un serveur, une base de données ou une tâche planifiée que par ses effets, jamais par son contenu.
- Un composant n’a connu ni déploiement, ni correctif, ni mise à jour de dépendances depuis plus de douze mois, alors qu’il traite des données de production.
- Les estimations de changements pourtant banals reviennent anormalement élevées, « parce qu’ils touchent au vieux système ».
Chiffrer l’exposition
Un chiffre précis est hors d’atteinte ici ; une estimation défendable ne l’est pas, et elle tient sur une page. Pour chaque composant signalé par votre équipe, estimez trois grandeurs.
Prise composant par composant, la somme est rarement alarmante. À l’échelle d’un patrimoine qui en compte dix ou quinze, elle justifie généralement d’agir sur les trois premiers. C’est tout l’objet de l’exercice : non pas alarmer, mais hiérarchiser.
- Coût de défaillance : ce que coûterait une panne significative en chiffre d’affaires perdu, en pénalités contractuelles et en effort de rétablissement, multiplié par une probabilité annuelle réaliste.
- Coût de dépendance : le retard et l’effort d’ingénierie supplémentaire imposés à toute initiative planifiée qui doit toucher au composant.
- Coût de départ : le temps de montée en compétence — souvent mesuré en mois — nécessaire pour reconstituer une connaissance opérationnelle si la dernière personne qui comprend le composant s’en va.
Trois remèdes réalistes
Face à un composant orphelin, il n’existe que trois options honnêtes. Chacune est légitime ; l’erreur consiste à n’en choisir aucune.
Documenter et attribuer en interne. Reconstituer le fonctionnement du composant par rétro-ingénierie, rédiger le runbook, le placer sous monitoring et confier formellement sa responsabilité à une équipe désignée. C’est l’option la moins coûteuse en trésorerie et la plus exigeante en discipline : elle consomme un temps d’ingénieurs seniors que votre feuille de route se dispute déjà, et l’attribution doit survivre aux réorganisations pour avoir un sens.
Reconstruire. Remplacer le composant par un système que votre équipe actuelle conçoit, possède et comprend. C’est la bonne réponse quand le composant est petit, central pour l’activité, ou bâti sur une technologie que rien d’autre ne vous impose de conserver. C’est la mauvaise réponse quand elle est appliquée par défaut : une reconstruction coûte plus cher et dure plus longtemps que la première estimation, presque sans exception.
Transférer la responsabilité sous SLA. Confier le composant — souvent le périmètre qui l’entoure — à un partenaire qui assume contractuellement sa disponibilité : reprise documentée, monitoring 24/7, temps de réponse définis par niveau de sévérité, correctifs et mises à jour traités comme un travail de routine plutôt que comme des exploits. Cette approche convertit un risque diffus et non mesuré en un coût mensuel fixe et en un contrat opposable. Elle exige de la confiance et une véritable période de transmission, et ne vaut d’être menée qu’avec un partenaire qui s’engage par écrit sur ses temps de réponse.
La responsabilité est une décision, pas un document
L’infrastructure orpheline n’est pas une crise, et la traiter comme telle conduit à de mauvaises décisions. C’est une forme de maintenance différée : gérable quand on la reconnaît, coûteuse quand on l’ignore. Le geste utile est modeste — lister les composants, chiffrer l’exposition et choisir un remède pour les rares composants qui comptent vraiment.
Quel que soit le remède retenu, le test reste le même : si ce composant tombe un dimanche à 3 h du matin, existe-t-il un responsable désigné dont le rôle est de répondre, et cela est-il écrit quelque part ? Dès que la réponse est oui, le coût caché cesse de s’accumuler. L’infogérance sous SLA contractuel est une façon d’y parvenir ; un responsable interne muni d’un runbook en est une autre. Ce qui ne fonctionne pas, c’est le statu quo — précisément parce qu’il ne coûte rien aujourd’hui.