Comment repérer les dépendances applicatives et techniques qui aggravent un incident ?
D’après Gestion des incidents
Une panne ne respecte pas les silos.
Les dépendances traversent les organigrammes : authentification, messagerie, ETL, API, DNS, PKI, orchestrateurs, files de messages, bases partagées, sauvegardes, secrets, annuaires, postes clients, réseaux opérateurs.
La cartographie des dépendances doit rester légère et opérationnelle : graphes orientés, niveaux de criticité, latences tolérées, points uniques de défaillance, fenêtres de maintenance.
On s'astreint à documenter la réalité observable, pas l'intention.
Les environnements cloud et SaaS imposent une lecture différente : zones/regions, services managés, quotas, versions, limites d'API, modèles de responsabilité partagée.
Côté technique, on trace le chemin de la transaction de bout en bout : front, middleware, persistance, lot, etc. .
Côté métier, on inscrit les étapes critiques du parcours client : commande, paiement, livraison, service après-vente.
Cette double lecture évite les diagnostics hors-sols et rend possible une restauration intelligente : contourner une brique sans casser l'ensemble, geler un flux pour sauver l'essentiel.
Une cartographie utile se met à jour lors des changements et après chaque incident significatif, elle vieillit mal si on la confie à un outil sans propriétaire.