Topologie, pas télémétrie : tracer les pannes en cascade dans le cloud

Un déploiement chez votre voisin fait tomber trois services en aval. Datadog vous dit qu’ils sont down. Il ne vous dit pas lequel des cinq changements poussés dans l’heure est responsable, ni quels clients sont impactés. Cette chaîne-là n’est pas dans la télémétrie. Elle est dans la topologie.

Partant de l’incident Cloudflare du 18 novembre 2025, on verra pourquoi le graphe de dépendances est la donnée manquante de la réponse à incident moderne. Les 500 ont été détectés en secondes. Il aura fallu plus de 3h avant le début du core recovery, parce qu’il fallait remonter une chaîne partant d’un changement de permissions dans une base, passant par un fichier de features qui double de taille, jusqu’au moteur de Bot Management, et enfin aux Workers KV, Access, Turnstile, Dashboard. Comment on construit ce graphe à partir des sources qu’on a déjà (AWS, Kubernetes, Terraform, GitHub, Datadog). Ce qu’une IA en fait quand elle l’a en entrée : aller d’une alerte au commit cassant en quelques secondes, avec la liste des comptes impactés.

Chez MotherDuck : « un process qui aurait pris 20 minutes à 2h à un humain familier du code, Annie l’a fait en 30 secondes » (Hilary Brennan-Marquez, Head of Infra).