Pendant longtemps, les failles de cybersécurité étaient associées à des erreurs humaines, à des mots de passe faibles ou à des systèmes obsolètes. Tout ceci est encore vrai, hélas, mais de nouveaux obstacles sont arrivés sur le parcours déjà varié et toujours en mouvance du valeureux combattant en cybersécurité !
Avec l’ère du cloud, des API et des architectures distribuées, les entreprises ont découvert la puissance des microservices : des briques logicielles autonomes, légères, capables d’évoluer indépendamment les unes des autres. Cette modularité a transformé la manière de concevoir les systèmes, mais elle a aussi ouvert la porte à un phénomène discret, rarement documenté, et pourtant omniprésent dans les audits modernes : les microservices fantômes.
Une plaie jamais vraiment refermée
Ces services oubliés, décommissionnés à moitié, ou simplement laissés en suspens après une migration, constituent aujourd’hui l’un des angles morts les plus dangereux des infrastructures numériques contemporaines. Ils ne font pas de bruit, ne génèrent pas d’alertes, et le plus souvent, ne figurent dans aucune documentation.
Pourtant, ils continuent d’exister, quelque part dans un réseau, dans un cluster, ou derrière un port ouvert. Et c’est précisément ce silence qui les rend si dangereux.
Un phénomène né de l’évolution des architectures
Pour comprendre l’origine des microservices fantômes, il faut revenir à la transition qui a marqué les années 2010. Les entreprises ont progressivement abandonné les architectures monolithiques pour adopter des systèmes distribués.
Le cloud public, les conteneurs et les orchestrateurs comme Kubernetes ont permis de déployer des centaines de services indépendants, chacun responsable d’une fonction précise, une vraie caverne d’Alibaba ! Cette évolution, pour gratifiante qu’elle fût, a été rapide, parfois trop rapide.
Les équipes ont migré des applications, réécrit des modules, externalisé des composants, et multiplié les environnements de test, de préproduction et de production. Dans cette effervescence, certains services ont été oubliés. D’autres ont été désactivés sans être supprimés. Certains ont été remplacés, mais leurs endpoints sont restés accessibles. D’autres encore ont été créés pour des besoins temporaires, puis laissés en place par manque de temps ou de procédure.
Le phénomène s’est amplifié avec l’arrivée des pratiques DevOps. Comme presque partout, la vitesse est devenue un critère de performance. Les déploiements se sont automatisés, les pipelines se sont complexifiés, et les environnements se sont multipliés. Dans ce contexte, la documentation n’a pas toujours suivi (rarement en fait) et les équipes ont parfois perdu la vision globale de leur propre architecture, et surtout, son historique détaillé.
Comment naît un microservice fantôme
Un microservice fantôme n’est pas un service malveillant. C’est un service oublié. Il peut s’agir d’une API non décommissionnée après une refonte, d’un conteneur laissé actif dans un cluster, d’une VM inactive, mais toujours routée, ou d’un endpoint orphelin qui répond encore à des requêtes.
Dans les audits, nous les retrouvons souvent sous des formes inattendues :
- Un service de test déployé en urgence pour un client, jamais supprimé.
- Une ancienne version d’une API, toujours accessible via un sous-domaine oublié.
- Un microservice utilisé pour une migration de données, laissé en place « au cas où »…
- Un conteneur de monitoring abandonné après un changement d’outil.
- Un module interne développé par un stagiaire, jamais intégré dans la documentation officielle.
Le diable, c’est bien connu, se cache dans les détails ! Cela vous parle ? Pourriez-vous garantir que votre structure en est exempte ?
Ce sont des reliques techniques, des vestiges d’anciennes architectures, des traces de projets passés. Et comme toutes les reliques, elles finissent par devenir des failles.
Pourquoi ces services sont si dangereux
Le danger des microservices fantômes ne vient pas de leur fonction, mais de leur invisibilité. Un service oublié n’est plus mis à jour. Il n’est plus surveillé. Il n’est plus intégré dans les politiques de sécurité. Il n’est plus protégé par les mécanismes modernes de contrôle d’accès. Il n’est plus audité. Il n’est plus patché.
Conséquence : c’est la surface d’attaque qui s’étend sans que personne ne l’ait décidé, à la manière d’un Shadow IT que l’entreprise aurait fabriqué elle-même.
Dans certains cas, le microservice continue de manipuler des données sensibles. Dans d’autres, il expose des endpoints vulnérables. Parfois, le service fantôme utilise des bibliothèques obsolètes, contenant des failles connues depuis des années. Il peut aussi offrir un accès indirect à des ressources internes, ou servir de pivot pour cartographier un réseau.
Les microservices fantômes sont des portes ouvertes que personne ne voit, sauf l’attaquant. Ils ne figurent dans aucun schéma réseau. Ils ne sont associés à aucun responsable. Ils ne sont liés à aucun processus. Ils sont hors des radars, et c’est précisément ce qui les rend si attractifs pour les cybercriminels.
Un problème amplifié par les migrations et les refontes
Les migrations sont l’un des principaux générateurs de microservices fantômes. Lorsqu’une entreprise change de CMS, de CRM, d’ERP ou de plateforme cloud, elle crée souvent des services temporaires pour assurer la transition. Ces services sont censés être supprimés une fois la migration terminée, mais, dans la pratique, beaucoup restent en place.
Les refontes internes produisent le même effet. Lorsqu’une équipe réécrit une API, elle laisse parfois l’ancienne version accessible « pour ne pas casser les intégrations ». Lorsqu’un service est déplacé vers un autre cluster, l’ancien endpoint n’est pas toujours désactivé. Lorsqu’un module est remplacé, l’ancien est parfois conservé, toujours « au cas où » : paresse et prudence mêlées, des biais cognitifs présents en chacun de nous.
Les environnements de test sont également responsables. Les équipes créent des environnements temporaires pour valider des fonctionnalités, puis les oublient. Ces environnements contiennent parfois des données réelles, ou des accès internes non sécurisés.
Pourquoi les audits les découvrent si souvent
Si les audits modernes, du moins 80 % des nôtres, révèlent presque systématiquement des microservices fantômes, ce n’est pas un hasard, car nous les cherchons avec le regard de l’attaquant…
Et nous savons que les infrastructures sont devenues trop complexes pour être gérées sans une documentation rigoureuse ; et que bien souvent, les équipes sont sous pression, et les priorités opérationnelles prennent le dessus sur la maintenance structurelle.
- Les outils de scanning détectent des endpoints inattendus.
- Les analyses de flux révèlent des communications entre services qui ne devraient plus exister.
- Les inventaires de conteneurs montrent des images obsolètes.
- Les cartographies réseau mettent en lumière des routes oubliées.
- Les logs dévoilent des appels vers des API qui ne figurent dans aucun schéma.
Pour nous, chaque audit devient, en quelque sorte, une plongée en archéologie numérique… On y découvre des traces d’anciennes pratiques, des services abandonnés, des modules oubliés. Et chaque découverte est une faille potentielle qu’un attaquant expérimenté, voire l’IA qui le seconde, saura exploiter.
Un enjeu de gouvernance autant que de technique
La sécurité des microservices fantômes n’est pas seulement un problème technique, c’est un problème de gouvernance. Une architecture distribuée exige une discipline documentaire, une gestion rigoureuse des versions, une politique de décommissionnement claire, et une vision globale de l’infrastructure.
Les entreprises doivent apprendre à cartographier leurs services, à documenter leurs API, à suivre leurs déploiements, à tracer leurs dépendances. Elles doivent intégrer le décommissionnement dans leurs processus, et considérer la suppression d’un service comme une étape aussi importante (vœux pieux) que son déploiement.
En résumé, la sécurité ne consiste pas seulement à protéger ce qui existe ; elle consiste aussi à supprimer ce qui, en théorie, n’existe plus !
Conclusion
Les microservices fantômes sont l’un des angles morts les plus dangereux des infrastructures modernes. Ces oubliés sont le produit de l’évolution rapide des architectures, de la pression opérationnelle, et de l’absence de documentation. Ils ne sont pas visibles, mais ils existent. Ils ne sont pas surveillés, mais ils répondent. Ils ne sont pas protégés, mais ils exposent.
Dans un monde où les attaques sont automatisées, où les scanners dopés parcourent le web en continu, et où les infrastructures sont de plus en plus distribuées, ignorer ces services oubliés revient à laisser des portes ouvertes dans un bâtiment que l’on croit sécurisé, et c’est pire qu’un bâtiment que l’on sait directement exposé.
En 2026, à l’ère de l’IA, reine des tâches répétitives expédiées en quelques minutes, la cybersécurité moderne ne peut plus se contenter de protéger les systèmes actifs visibles ; elle doit aussi traquer les fantômes.
