Tout le monde connaît la dette technique : ce code qu’on écrit vite pour livrer à temps, en se disant « on refactorisera plus tard » — et qu’on ne refactorise jamais. Mais il existe un équivalent côté infrastructure, beaucoup moins connu, beaucoup moins discuté, et pourtant tout aussi coûteux : la dette d’infrastructure.
Qu’est-ce que la dette d’infrastructure exactement ?
C’est l’ensemble des raccourcis, des configurations temporaires devenues permanentes, des mises à jour repoussées, des systèmes non documentés, qui s’accumulent silencieusement dans l’infrastructure d’une entreprise. Contrairement à la dette technique, qui se voit dans le code et que les développeurs remarquent régulièrement (même s’ils ne la traitent pas), la dette d’infrastructure est invisible au quotidien. Tout continue de fonctionner… jusqu’au jour où ça ne fonctionne plus.
Voici les formes les plus courantes qu’elle prend :
- Des versions obsolètes non mises à jour : systèmes d’exploitation, bases de données, dépendances système qui n’ont pas reçu de patch de sécurité depuis des mois, parfois des années
- Des secrets mal gérés : clés API, mots de passe, tokens stockés en clair dans des fichiers de configuration, partagés par Slack, ou codés en dur dans des scripts
- Des ressources cloud orphelines : instances qu’on a lancées pour un test il y a 8 mois et qu’on paie toujours, volumes de stockage attachés à rien, IP statiques inutilisées
- De l’Infrastructure as Code jamais refactorisée : des scripts Terraform ou Ansible écrits dans l’urgence, remplis de valeurs codées en dur, que personne n’ose toucher par peur de tout casser
- Des accès qui ne sont jamais révoqués : l’ancien stagiaire qui a toujours accès au serveur de production 18 mois après son départ
- Des architectures « temporaires » devenues permanentes : ce serveur unique sans redondance, monté à l’arrache pour un MVP, qui héberge maintenant l’application principale de l’entreprise trois ans plus tard
Pourquoi cette dette est particulièrement dangereuse
La dette technique casse généralement une fonctionnalité, ou ralentit le développement. C’est gênant, mais souvent réparable rapidement, et rarement catastrophique.
La dette d’infrastructure, elle, peut se traduire par :
- Une faille de sécurité exploitée parce qu’un système n’a pas reçu de patch depuis 14 mois
- Une panne totale de production parce qu’un unique point de défaillance (serveur, base de données, service tiers) a fini par tomber, sans aucune redondance
- Une facture cloud multipliée par 3 parce que personne n’a jamais fait le tri dans les ressources actives
- Une incapacité à scaler au moment où l’entreprise a justement le plus besoin de croître, parce que l’architecture n’a jamais été pensée pour ça
- Un audit de sécurité qui échoue, bloquant une levée de fonds, un contrat avec un grand compte, ou une certification nécessaire
Le problème, c’est que cette dette ne se voit pas dans un board Jira. Elle ne fait pas partie du backlog produit. Personne n’a de metric dessus. Elle est purement invisible jusqu’à ce qu’elle explose — et à ce moment-là, elle coûte largement plus cher à traiter dans l’urgence qu’elle n’aurait coûté à prévenir.
Pourquoi les équipes internes ont du mal à la traiter
Ce n’est pas un problème de compétence, c’est un problème de priorité et de temps. Un DevOps interne, à temps plein, dans une équipe de développement, est presque toujours absorbé par l’opérationnel :
- Les demandes urgentes des devs (« j’ai un problème pour déployer »)
- Les incidents en cours à résoudre
- Les nouvelles features qui nécessitent de nouvelles ressources infra
- Les demandes ad hoc du management
Résultat : personne n’a jamais le temps de s’assoir, de faire un audit complet de l’infra existante, et de traiter méthodiquement cette dette accumulée. Ce n’est jamais urgent — jusqu’au jour où ça l’est brutalement.
Le modèle à temps partagé comme antidote naturel
C’est là que le modèle du DevOps à temps partagé prend tout son sens, presque par construction. Un DevOps qui intervient par exemple 1 à 2 jours par semaine, plutôt que 5, est structurellement obligé de prioriser et de sortir du mode « pompier permanent ». Il ne peut pas passer son temps uniquement sur l’opérationnel du jour, sinon rien d’autre n’avance jamais.
Concrètement, chez Calopsys, cela se traduit par :
- Des audits d’infrastructure réguliers, planifiés à l’avance, qui ne dépendent pas de la disponibilité résiduelle d’un DevOps débordé
- Une liste de dette technique infra, documentée et suivie sprint après sprint, au même titre qu’une dette technique de code
- Un calendrier de mise à jour des systèmes et dépendances, plutôt qu’un rattrapage fait dans la panique après une alerte de sécurité
- Un nettoyage périodique des ressources cloud, qui a un impact direct et mesurable sur la facture mensuelle
- Une revue des accès et des secrets effectuée à intervalle régulier, plutôt que jamais
Le fait même de ne pas être submergé par le quotidien à temps plein permet, paradoxalement, de mieux traiter les sujets de fond qui, eux, déterminent la robustesse réelle de l’infrastructure sur le long terme.