Cartographier les dépendances : le préalable oublié à toute infogérance

Un serveur peut être accessible, avoir du CPU disponible et suffisamment d’espace disque. La supervision le montre en vert. Pourtant, les utilisateurs peuvent ne plus pouvoir se connecter, payer, envoyer une commande ou accéder à leur outil métier.

Le problème n’est pas forcément sur la VM. Il peut se situer sur la base de données, le DNS, le stockage, un certificat, un fournisseur mail, une API de paiement ou une dépendance réseau. Tant que ces liens ne sont pas connus, une infrastructure peut sembler saine alors que le service important ne l’est plus.

C’est pour cette raison que la cartographie des dépendances est un préalable à une infogérance sérieuse. Elle ne sert pas à produire un schéma décoratif. Elle permet de comprendre ce qui porte réellement le métier, de concevoir les bonnes alertes et de savoir où intervenir quand chaque minute compte.

Une VM verte ne mesure pas la disponibilité du service

La disponibilité d’un hôte n’est qu’un signal parmi d’autres. Elle indique qu’une machine répond, pas que le service rendu au client fonctionne de bout en bout.

Prenons le cas d’un site e-commerce. Son serveur web répond en HTTPS, le processus applicatif est lancé et la sonde CPU est normale. Mais si la base de données n’est plus joignable, si l’API de paiement refuse les requêtes ou si le prestataire mail ne délivre plus les confirmations de commande, le parcours commercial est dégradé ou bloqué.

Le même raisonnement s’applique à une application interne :

• un portail peut être accessible, mais ne plus authentifier les utilisateurs si l’annuaire ou le SSO est indisponible ;
• une API peut répondre, mais retourner des erreurs si son stockage objet est lent ou inaccessible ;
• un back-office peut démarrer, mais être inutilisable si le DNS interne ne résout plus les services dont il dépend ;
• une plateforme peut sembler disponible, mais perdre des données si la réplication ou les sauvegardes échouent en silence.

Le bon niveau de supervision n’est donc pas seulement : « Est-ce que le serveur est allumé ? » Il faut aussi pouvoir répondre : « Est-ce que l’utilisateur peut encore réaliser l’action qui compte ? »

Une dépendance peut être technique, externe ou humaine

Une dépendance est tout élément indispensable au fonctionnement d’un service. Certaines sont évidentes, d’autres beaucoup moins, notamment lorsqu’elles ont été ajoutées au fil des projets.

Pour un service critique, la cartographie doit au minimum faire apparaître :

• les points d’entrée : URL, DNS, reverse proxy, VPN, réseau inter-sites ;
• les composants applicatifs : VM, conteneurs, workers, ordonnanceurs, files de messages ;
• les données : bases de données, cache, stockage de fichiers, stockage objet, volumes et réplications ;
• les services de socle : DNS, NTP, certificats, annuaire, MFA, bastion, coffre de secrets ;
• les services externes : paiement, mail, SMS, APIs partenaires, CDN, anti-DDoS ou identité ;
• les moyens de reprise : sauvegardes, catalogues, dépôts de paquets, images, accès d’administration ;
• les contacts et responsabilités : qui possède le service, qui valide côté métier, qui escalade chez un fournisseur.

Le dernier point est souvent sous-estimé. Une clé API expirée, un compte fournisseur suspendu ou un contact d’escalade obsolète peuvent immobiliser un service aussi sûrement qu’une panne de serveur.

Les incidents se propagent rarement comme sur un schéma simple

Une cartographie utile ne représente pas seulement les composants. Elle rend visibles les chemins de panne et les dépendances communes.

Un exemple classique : plusieurs applications sont réparties sur différents serveurs, mais toutes reposent sur le même DNS, le même stockage ou le même fournisseur d’identité. Les VM sont séparées ; le domaine de panne, lui, ne l’est pas. Une seule défaillance peut alors provoquer plusieurs alertes apparemment indépendantes.

Autre cas fréquent : le stockage se dégrade sans être complètement indisponible. Les serveurs restent joignables, les services sont toujours démarrés, mais les temps de réponse augmentent, les files d’attente se remplissent et les timeouts se multiplient. Sans lien explicite entre application et stockage, l’équipe peut chercher longtemps au mauvais endroit.

Cette lecture permet aussi d’éviter les diagnostics trop rapides. Une erreur applicative peut venir du code, mais aussi d’un DNS, d’un certificat, d’un réseau, d’une base saturée ou d’une API tierce. Cartographier ne résout pas l’incident à la place de l’équipe. En revanche, cela réduit fortement le temps perdu à reconstruire l’architecture en pleine crise.

Partir du métier, puis remonter vers la technique

Le piège est de commencer par une liste de serveurs. Elle est utile, mais elle ne dit pas quels éléments sont réellement critiques.

Une méthode plus efficace consiste à partir des parcours métier : payer une commande, accéder au portail client, synchroniser un point de vente, produire un document, recevoir un ticket, traiter une demande interne. Pour chacun, on identifie ensuite les briques nécessaires et l’ordre dans lequel elles interviennent.

Les questions à se poser sont concrètes :

• quel service est rendu et à qui ?
• quel impact réel a son indisponibilité ?
• de quelles applications, données et connexions dépend-il ?
• quelles dépendances sont partagées avec d’autres services ?
• quel composant constitue un point de défaillance unique ?
• qui peut confirmer que le service est à nouveau fonctionnel ?
• quel délai d’interruption est acceptable avant que l’incident devienne critique ?

Cette approche évite de mettre au même niveau un environnement de test, un outil interne tolérant une interruption et une chaîne de commande qui touche directement les revenus ou les clients.

Faire le point sur votre infrastructure

Le livrable minimal pour une exploitation fiable

Il n’est pas nécessaire de modéliser chaque détail dès le premier jour. En revanche, chaque service critique doit disposer d’une fiche exploitable par une personne qui n’a pas participé à sa création.

Cette fiche peut contenir :

• le responsable métier et le référent technique ;
• les utilisateurs concernés et le niveau de criticité ;
• les URL, noms DNS et points d’entrée réseau ;
• les hôtes, conteneurs, clusters ou providers impliqués ;
• les bases, caches, volumes, stockages et mécanismes de réplication ;
• les services tiers, leurs contacts et les limites connues ;
• les sauvegardes, le RPO, le RTO et la procédure de restauration ;
• les alertes attendues, les seuils et la procédure d’escalade ;
• les fenêtres de maintenance et le plan de retour arrière.

L’objectif n’est pas de noyer l’équipe sous la documentation. Il est de rendre une décision possible : savoir quel incident traiter en premier, qui prévenir et quelles vérifications effectuer avant d’agir.

Transformer la cartographie en supervision exploitable

La cartographie donne du sens aux métriques. Elle permet de compléter la supervision d’infrastructure par des contrôles réellement orientés service.

Au lieu de vérifier uniquement que nginx écoute sur le port 443, une sonde peut tester une action simple depuis l’extérieur : ouverture d’une page clé, authentification sur un compte de test, création contrôlée d’une requête ou vérification d’une réponse métier attendue. Cette vérification doit rester proportionnée et ne pas manipuler de données sensibles, mais elle reflète bien mieux l’expérience réelle.

Les dépendances connues servent également à enrichir les alertes :

• une alerte de stockage peut indiquer les services concernés ;
• une erreur DNS peut être corrélée aux applications qui ne résoudront plus leurs dépendances ;
• un incident de fournisseur tiers peut être distingué d’une panne de l’hébergement ;
• plusieurs alertes applicatives peuvent être regroupées autour d’une cause commune ;
• l’astreinte reçoit le contexte, les contacts et la première procédure plutôt qu’un simple statut rouge.

Une supervision utile n’affiche pas davantage de courbes. Elle permet de prendre une meilleure décision plus tôt. C’est précisément le rôle de l’observabilité dans une infrastructure saine.

Un socle indispensable à l’astreinte et au PRA

En astreinte, personne ne devrait découvrir les dépendances d’un service au moment où il tombe. Sans cartographie, l’intervenant doit retrouver les accès, identifier les briques concernées, comprendre la criticité, chercher les contacts et décider sous pression. Cela allonge la prise en charge et augmente le risque de mauvaise priorité.

Avec une cartographie maintenue, il sait plus rapidement si l’alerte touche un composant isolé ou un service métier, si une dépendance externe est impliquée, quelles équipes prévenir et quelle solution de contournement est envisageable. C’est ce qui transforme une alerte en intervention structurée.

Le même travail est central pour un PRA. On ne peut pas définir un ordre de reprise, un RTO ou un RPO crédible sans connaître les applications, leurs données, leurs dépendances externes et leurs domaines de panne communs.

Une cartographie doit vivre avec l’infrastructure

Un schéma créé pendant un audit et oublié pendant deux ans finit par devenir un risque supplémentaire. L’infrastructure évolue : nouvelle API, migration de base, changement de DNS, ajout d’un site, modification des accès, évolution des sauvegardes ou montée en charge.

La cartographie doit donc être revue lors des mises en production, des changements d’architecture et des incidents significatifs. L’Infrastructure as Code, l’inventaire et l’automatisation aident à garder les configurations cohérentes, mais ils ne remplacent pas la compréhension du service rendu ni de ses priorités métier.

En infogérance, ce travail fait partie de la prise en charge puis de l’exploitation continue. L’objectif n’est pas de documenter pour documenter. Il est de pouvoir répondre, en quelques minutes, à une question simple : quel service est réellement impacté, pourquoi, et quelle action réduira le plus vite l’impact pour les utilisateurs ?

Questions fréquentes sur la cartographie des dépendances

Pourquoi une VM en ligne ne garantit-elle pas que le service fonctionne ?

Parce qu’une application dépend généralement d’autres briques : DNS, base de données, stockage, réseau, certificat ou fournisseur tiers. La disponibilité de l’hôte ne prouve pas que le parcours utilisateur fonctionne de bout en bout.

Quelles dépendances faut-il cartographier en priorité ?

Commencez par les services métier critiques, puis identifiez leurs points d’entrée, applications, données, stockage, réseau, DNS, services d’identité, sauvegardes et dépendances externes.

La cartographie des dépendances sert-elle uniquement au PRA ?

Non. Elle sert aussi à construire une supervision utile, qualifier les incidents, organiser l’astreinte, planifier les maintenances et prioriser les investissements d’infrastructure.

Comment maintenir une cartographie à jour ?

Elle doit être revue après chaque changement significatif : mise en production, migration, ajout de fournisseur, modification réseau ou évolution de criticité. Les incidents et exercices de reprise sont aussi de bons moments pour corriger les oublis.

Peut-on reprendre une infrastructure peu documentée ?

Oui. La reprise commence par un inventaire progressif des accès, services, sauvegardes, alertes, dépendances et procédures d’escalade. L’essentiel est de traiter en premier les services qui portent le plus de risque métier.