Choisir un symptôme. Repartir avec un plan d’action.

[Incident] APIM interne retourne une erreur sur une API privée
Contexte : Corréler les logs Application Gateway/WAF et APIM, puis séparer DNS, TLS, policy, identité et joignabilité backend privée avant de modifier les policies ou rouvrir les accès.
Preuves à confirmer : Corréler les logs Application Gateway/WAF et APIM, puis séparer DNS, TLS, policy, identité et joignabilité backend privée avant de modifier les policies ou rouvrir les accès.
Contrôles immédiats : Vérifier si le WAF a bloqué la requête | Confirmer qu’APIM reçoit le même chemin | Valider DNS et TLS backend depuis le chemin APIM | Rejouer avec un identifiant de corrélation
Action proposée : Exécuter les premiers contrôles dans l’ordre : Vérifier si le WAF a bloqué la requête | Confirmer qu’APIM reçoit le même chemin | Valider DNS et TLS backend depuis le chemin APIM | Rejouer avec un identifiant de corrélation. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : APIM interne retourne une erreur sur une API privée
Hypothèse initiale : Corréler les logs Application Gateway/WAF et APIM, puis séparer DNS, TLS, policy, identité et joignabilité backend privée avant de modifier les policies ou rouvrir les accès.
Preuves utilisées : Corréler les logs Application Gateway/WAF et APIM, puis séparer DNS, TLS, policy, identité et joignabilité backend privée avant de modifier les policies ou rouvrir les accès.
Contrôles effectués : Vérifier si le WAF a bloqué la requête | Confirmer qu’APIM reçoit le même chemin | Valider DNS et TLS backend depuis le chemin APIM | Rejouer avec un identifiant de corrélation
Décision / action : Exécuter les premiers contrôles dans l’ordre : Vérifier si le WAF a bloqué la requête | Confirmer qu’APIM reçoit le même chemin | Valider DNS et TLS backend depuis le chemin APIM | Rejouer avec un identifiant de corrélation. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Un nom Private Endpoint résout encore en public
Contexte : Confirmer la chaîne CNAME, l’association Private DNS Zone et le forwarding hybride depuis le réseau consommateur.
Preuves à confirmer : nslookup depuis le subnet workload, chaîne CNAME, liens Private DNS Zone, chemin de forwarding resolver et réponses en cache.
Contrôles immédiats : Lancer nslookup depuis le réseau workload | Vérifier le CNAME privatelink | Contrôler les liens Private DNS Zone et forwarders
Action proposée : Corriger d’abord association de zone ou forwarding, puis vider les caches et retester depuis le réseau consommateur.
Rollback : Restaurer l’ancien lien ou forwarder et documenter l’écart entre réponse publique et privée.

Symptôme traité : Un nom Private Endpoint résout encore en public
Hypothèse initiale : Confirmer la chaîne CNAME, l’association Private DNS Zone et le forwarding hybride depuis le réseau consommateur.
Preuves utilisées : nslookup depuis le subnet workload, chaîne CNAME, liens Private DNS Zone, chemin de forwarding resolver et réponses en cache.
Contrôles effectués : Lancer nslookup depuis le réseau workload | Vérifier le CNAME privatelink | Contrôler les liens Private DNS Zone et forwarders
Décision / action : Corriger d’abord association de zone ou forwarding, puis vider les caches et retester depuis le réseau consommateur.
Plan de retour arrière : Restaurer l’ancien lien ou forwarder et documenter l’écart entre réponse publique et privée.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Un endpoint privé Azure Storage retourne 403, timeout ou aucun log de requête
Contexte : Séparer DNS du sous-service Storage, approbation Private Endpoint, règles firewall, identité runtime et logs Storage avant d’ouvrir l’accès public ou d’élargir RBAC.
Preuves à confirmer : Séparer DNS du sous-service Storage, approbation Private Endpoint, règles firewall, identité runtime et logs Storage avant d’ouvrir l’accès public ou d’élargir RBAC.
Contrôles immédiats : Résoudre le sous-service Storage exact depuis le réseau workload | Vérifier statut Private Endpoint et private DNS zone group | Rejouer avec un client request ID | Corréler les logs Storage pour 403, IP appelante et identité requérante
Action proposée : Exécuter les premiers contrôles dans l’ordre : Résoudre le sous-service Storage exact depuis le réseau workload | Vérifier statut Private Endpoint et private DNS zone group | Rejouer avec un client request ID | Corréler les logs Storage pour 403, IP appelante et identité requérante. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : Un endpoint privé Azure Storage retourne 403, timeout ou aucun log de requête
Hypothèse initiale : Séparer DNS du sous-service Storage, approbation Private Endpoint, règles firewall, identité runtime et logs Storage avant d’ouvrir l’accès public ou d’élargir RBAC.
Preuves utilisées : Séparer DNS du sous-service Storage, approbation Private Endpoint, règles firewall, identité runtime et logs Storage avant d’ouvrir l’accès public ou d’élargir RBAC.
Contrôles effectués : Résoudre le sous-service Storage exact depuis le réseau workload | Vérifier statut Private Endpoint et private DNS zone group | Rejouer avec un client request ID | Corréler les logs Storage pour 403, IP appelante et identité requérante
Décision / action : Exécuter les premiers contrôles dans l’ordre : Résoudre le sous-service Storage exact depuis le réseau workload | Vérifier statut Private Endpoint et private DNS zone group | Rejouer avec un client request ID | Corréler les logs Storage pour 403, IP appelante et identité requérante. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Un endpoint privé Azure SQL retourne timeout, erreur firewall ou aucun log SQL
Contexte : Séparer DNS privé SQL, état Private Endpoint, accès public, règles firewall, identité runtime et diagnostics SQL avant de modifier schéma, code ou droits trop larges.
Preuves à confirmer : Séparer DNS privé SQL, état Private Endpoint, accès public, règles firewall, identité runtime et diagnostics SQL avant de modifier schéma, code ou droits trop larges.
Contrôles immédiats : Résoudre le FQDN SQL depuis le réseau workload | Vérifier le statut Private Endpoint et les enregistrements privatelink.database.windows.net | Rejouer avec l’identité runtime réelle | Corréler les diagnostics SQL pour firewall et erreurs de login
Action proposée : Exécuter les premiers contrôles dans l’ordre : Résoudre le FQDN SQL depuis le réseau workload | Vérifier le statut Private Endpoint et les enregistrements privatelink.database.windows.net | Rejouer avec l’identité runtime réelle | Corréler les diagnostics SQL pour firewall et erreurs de login. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : Un endpoint privé Azure SQL retourne timeout, erreur firewall ou aucun log SQL
Hypothèse initiale : Séparer DNS privé SQL, état Private Endpoint, accès public, règles firewall, identité runtime et diagnostics SQL avant de modifier schéma, code ou droits trop larges.
Preuves utilisées : Séparer DNS privé SQL, état Private Endpoint, accès public, règles firewall, identité runtime et diagnostics SQL avant de modifier schéma, code ou droits trop larges.
Contrôles effectués : Résoudre le FQDN SQL depuis le réseau workload | Vérifier le statut Private Endpoint et les enregistrements privatelink.database.windows.net | Rejouer avec l’identité runtime réelle | Corréler les diagnostics SQL pour firewall et erreurs de login
Décision / action : Exécuter les premiers contrôles dans l’ordre : Résoudre le FQDN SQL depuis le réseau workload | Vérifier le statut Private Endpoint et les enregistrements privatelink.database.windows.net | Rejouer avec l’identité runtime réelle | Corréler les diagnostics SQL pour firewall et erreurs de login. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Un endpoint privé Azure Service Bus timeout, refuse l’accès ou laisse le backlog monter
Contexte : Séparer DNS privé Service Bus, état Private Endpoint, accès public, identité managée ou SAS, métriques de queue et logs de traitement avant de modifier les queues ou redéployer les consumers.
Preuves à confirmer : Séparer DNS privé Service Bus, état Private Endpoint, accès public, identité managée ou SAS, métriques de queue et logs de traitement avant de modifier les queues ou redéployer les consumers.
Contrôles immédiats : Résoudre le FQDN Service Bus depuis le réseau workload | Vérifier approbation Private Endpoint et accès public | Contrôler l’identité réelle sender ou receiver | Corréler backlog, dead-letter et erreurs Service Bus
Action proposée : Exécuter les premiers contrôles dans l’ordre : Résoudre le FQDN Service Bus depuis le réseau workload | Vérifier approbation Private Endpoint et accès public | Contrôler l’identité réelle sender ou receiver | Corréler backlog, dead-letter et erreurs Service Bus. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : Un endpoint privé Azure Service Bus timeout, refuse l’accès ou laisse le backlog monter
Hypothèse initiale : Séparer DNS privé Service Bus, état Private Endpoint, accès public, identité managée ou SAS, métriques de queue et logs de traitement avant de modifier les queues ou redéployer les consumers.
Preuves utilisées : Séparer DNS privé Service Bus, état Private Endpoint, accès public, identité managée ou SAS, métriques de queue et logs de traitement avant de modifier les queues ou redéployer les consumers.
Contrôles effectués : Résoudre le FQDN Service Bus depuis le réseau workload | Vérifier approbation Private Endpoint et accès public | Contrôler l’identité réelle sender ou receiver | Corréler backlog, dead-letter et erreurs Service Bus
Décision / action : Exécuter les premiers contrôles dans l’ordre : Résoudre le FQDN Service Bus depuis le réseau workload | Vérifier approbation Private Endpoint et accès public | Contrôler l’identité réelle sender ou receiver | Corréler backlog, dead-letter et erreurs Service Bus. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Une probe synthétique échoue sur un chemin privé Azure
Contexte : Séparer DNS, TLS, health Application Gateway, blocages WAF et réseau du runner avant de modifier le routage ou le code applicatif.
Preuves à confirmer : Séparer DNS, TLS, health Application Gateway, blocages WAF et réseau du runner avant de modifier le routage ou le code applicatif.
Contrôles immédiats : Résoudre le hostname depuis le réseau de probe | Contrôler TLS/SNI avec le vrai hostname | Corréler le run de probe avec les logs WAF et gateway
Action proposée : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau de probe | Contrôler TLS/SNI avec le vrai hostname | Corréler le run de probe avec les logs WAF et gateway. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : Une probe synthétique échoue sur un chemin privé Azure
Hypothèse initiale : Séparer DNS, TLS, health Application Gateway, blocages WAF et réseau du runner avant de modifier le routage ou le code applicatif.
Preuves utilisées : Séparer DNS, TLS, health Application Gateway, blocages WAF et réseau du runner avant de modifier le routage ou le code applicatif.
Contrôles effectués : Résoudre le hostname depuis le réseau de probe | Contrôler TLS/SNI avec le vrai hostname | Corréler le run de probe avec les logs WAF et gateway
Décision / action : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau de probe | Contrôler TLS/SNI avec le vrai hostname | Corréler le run de probe avec les logs WAF et gateway. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Un trafic Azure sort par un chemin et revient par un autre
Contexte : Comparer cible DNS, routes effectives, associations de route table, preuves firewall, identité NAT et chemin retour avant de modifier les UDR ou contourner l’inspection.
Preuves à confirmer : Comparer cible DNS, routes effectives, associations de route table, preuves firewall, identité NAT et chemin retour avant de modifier les UDR ou contourner l’inspection.
Contrôles immédiats : Résoudre la destination depuis le chemin source | Comparer les routes effectives des NIC source et destination | Contrôler les logs firewall ou appliance dans les deux sens | Confirmer NAT ou identité source sortante
Action proposée : Exécuter les premiers contrôles dans l’ordre : Résoudre la destination depuis le chemin source | Comparer les routes effectives des NIC source et destination | Contrôler les logs firewall ou appliance dans les deux sens | Confirmer NAT ou identité source sortante. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : Un trafic Azure sort par un chemin et revient par un autre
Hypothèse initiale : Comparer cible DNS, routes effectives, associations de route table, preuves firewall, identité NAT et chemin retour avant de modifier les UDR ou contourner l’inspection.
Preuves utilisées : Comparer cible DNS, routes effectives, associations de route table, preuves firewall, identité NAT et chemin retour avant de modifier les UDR ou contourner l’inspection.
Contrôles effectués : Résoudre la destination depuis le chemin source | Comparer les routes effectives des NIC source et destination | Contrôler les logs firewall ou appliance dans les deux sens | Confirmer NAT ou identité source sortante
Décision / action : Exécuter les premiers contrôles dans l’ordre : Résoudre la destination depuis le chemin source | Comparer les routes effectives des NIC source et destination | Contrôler les logs firewall ou appliance dans les deux sens | Confirmer NAT ou identité source sortante. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] L’ingress privé Azure Container Apps échoue ou atteint la mauvaise révision
Contexte : Séparer DNS privé, passage Application Gateway, mode d’ingress Container Apps, trafic des révisions et logs console avant rollback ou changement de poids.
Preuves à confirmer : Séparer DNS privé, passage Application Gateway, mode d’ingress Container Apps, trafic des révisions et logs console avant rollback ou changement de poids.
Contrôles immédiats : Résoudre le hostname depuis le réseau appelant | Vérifier target port ingress et révisions actives | Corréler logs system et console
Action proposée : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau appelant | Vérifier target port ingress et révisions actives | Corréler logs system et console. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : L’ingress privé Azure Container Apps échoue ou atteint la mauvaise révision
Hypothèse initiale : Séparer DNS privé, passage Application Gateway, mode d’ingress Container Apps, trafic des révisions et logs console avant rollback ou changement de poids.
Preuves utilisées : Séparer DNS privé, passage Application Gateway, mode d’ingress Container Apps, trafic des révisions et logs console avant rollback ou changement de poids.
Contrôles effectués : Résoudre le hostname depuis le réseau appelant | Vérifier target port ingress et révisions actives | Corréler logs system et console
Décision / action : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau appelant | Vérifier target port ingress et révisions actives | Corréler logs system et console. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] L’ingress privé AKS retourne 502 ou ne trouve aucun endpoint de service
Contexte : Séparer DNS privé, health Application Gateway, routage ingress controller, selectors de service Kubernetes, endpoint slices et readiness des pods avant de rollback un déploiement.
Preuves à confirmer : Séparer DNS privé, health Application Gateway, routage ingress controller, selectors de service Kubernetes, endpoint slices et readiness des pods avant de rollback un déploiement.
Contrôles immédiats : Résoudre le hostname depuis le réseau appelant | Vérifier backend health Application Gateway et host header | Contrôler ingress, service et endpoint slices | Corréler logs controller et applicatifs
Action proposée : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau appelant | Vérifier backend health Application Gateway et host header | Contrôler ingress, service et endpoint slices | Corréler logs controller et applicatifs. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : L’ingress privé AKS retourne 502 ou ne trouve aucun endpoint de service
Hypothèse initiale : Séparer DNS privé, health Application Gateway, routage ingress controller, selectors de service Kubernetes, endpoint slices et readiness des pods avant de rollback un déploiement.
Preuves utilisées : Séparer DNS privé, health Application Gateway, routage ingress controller, selectors de service Kubernetes, endpoint slices et readiness des pods avant de rollback un déploiement.
Contrôles effectués : Résoudre le hostname depuis le réseau appelant | Vérifier backend health Application Gateway et host header | Contrôler ingress, service et endpoint slices | Corréler logs controller et applicatifs
Décision / action : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau appelant | Vérifier backend health Application Gateway et host header | Contrôler ingress, service et endpoint slices | Corréler logs controller et applicatifs. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Un upgrade de node pool AKS reste bloqué au drain d’un pod protégé par un PDB
Contexte : Séparer replicas indisponibles, échecs de readiness, placement des pods, capacité de surge et PodDisruptionBudget trop contraignant avant de supprimer le garde-fou ou forcer l’upgrade.
Preuves à confirmer : Séparer replicas indisponibles, échecs de readiness, placement des pods, capacité de surge et PodDisruptionBudget trop contraignant avant de supprimer le garde-fou ou forcer l’upgrade.
Contrôles immédiats : Capturer le nœud bloqué et les événements d’éviction | Lire disruptionsAllowed et les selectors du PDB | Vérifier capacité de remplacement, readiness et topologie des replicas | Reprendre uniquement avec une marge de disruption positive
Action proposée : Exécuter les premiers contrôles dans l’ordre : Capturer le nœud bloqué et les événements d’éviction | Lire disruptionsAllowed et les selectors du PDB | Vérifier capacité de remplacement, readiness et topologie des replicas | Reprendre uniquement avec une marge de disruption positive. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : Un upgrade de node pool AKS reste bloqué au drain d’un pod protégé par un PDB
Hypothèse initiale : Séparer replicas indisponibles, échecs de readiness, placement des pods, capacité de surge et PodDisruptionBudget trop contraignant avant de supprimer le garde-fou ou forcer l’upgrade.
Preuves utilisées : Séparer replicas indisponibles, échecs de readiness, placement des pods, capacité de surge et PodDisruptionBudget trop contraignant avant de supprimer le garde-fou ou forcer l’upgrade.
Contrôles effectués : Capturer le nœud bloqué et les événements d’éviction | Lire disruptionsAllowed et les selectors du PDB | Vérifier capacité de remplacement, readiness et topologie des replicas | Reprendre uniquement avec une marge de disruption positive
Décision / action : Exécuter les premiers contrôles dans l’ordre : Capturer le nœud bloqué et les événements d’éviction | Lire disruptionsAllowed et les selectors du PDB | Vérifier capacité de remplacement, readiness et topologie des replicas | Reprendre uniquement avec une marge de disruption positive. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Un endpoint HTTP privé Azure Functions retourne 403, 503 ou aucun log de requête
Contexte : Séparer DNS privé, joignabilité Private Endpoint, restrictions d’accès, état runtime Functions, storage privé et preuves Application Insights avant de redéployer le code ou rouvrir l’accès public.
Preuves à confirmer : Séparer DNS privé, joignabilité Private Endpoint, restrictions d’accès, état runtime Functions, storage privé et preuves Application Insights avant de redéployer le code ou rouvrir l’accès public.
Contrôles immédiats : Résoudre le hostname depuis le réseau appelant | Rejouer avec un identifiant de corrélation | Vérifier access restrictions et statut Private Endpoint | Corréler requests, traces et exceptions
Action proposée : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau appelant | Rejouer avec un identifiant de corrélation | Vérifier access restrictions et statut Private Endpoint | Corréler requests, traces et exceptions. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : Un endpoint HTTP privé Azure Functions retourne 403, 503 ou aucun log de requête
Hypothèse initiale : Séparer DNS privé, joignabilité Private Endpoint, restrictions d’accès, état runtime Functions, storage privé et preuves Application Insights avant de redéployer le code ou rouvrir l’accès public.
Preuves utilisées : Séparer DNS privé, joignabilité Private Endpoint, restrictions d’accès, état runtime Functions, storage privé et preuves Application Insights avant de redéployer le code ou rouvrir l’accès public.
Contrôles effectués : Résoudre le hostname depuis le réseau appelant | Rejouer avec un identifiant de corrélation | Vérifier access restrictions et statut Private Endpoint | Corréler requests, traces et exceptions
Décision / action : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau appelant | Rejouer avec un identifiant de corrélation | Vérifier access restrictions et statut Private Endpoint | Corréler requests, traces et exceptions. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Azure WAF bloque une requête légitime
Contexte : Partir des requêtes bloquées, du ruleId et de l’URI avant de choisir exclusion, custom rule ou correction applicative.
Preuves à confirmer : URI bloquée, ruleId, variable matchée, client IP, hostname, request ID et fenêtre temporelle exacte.
Contrôles immédiats : Lister les URI bloquées en KQL | Identifier ruleId et champ matché | Valider le périmètre du faux positif
Action proposée : Créer la plus petite exclusion ou custom rule possible sans désactiver la règle globalement.
Rollback : Supprimer l’exclusion/custom rule et vérifier que le blocage attendu revient sur la même famille de règles.

Symptôme traité : Azure WAF bloque une requête légitime
Hypothèse initiale : Partir des requêtes bloquées, du ruleId et de l’URI avant de choisir exclusion, custom rule ou correction applicative.
Preuves utilisées : URI bloquée, ruleId, variable matchée, client IP, hostname, request ID et fenêtre temporelle exacte.
Contrôles effectués : Lister les URI bloquées en KQL | Identifier ruleId et champ matché | Valider le périmètre du faux positif
Décision / action : Créer la plus petite exclusion ou custom rule possible sans désactiver la règle globalement.
Plan de retour arrière : Supprimer l’exclusion/custom rule et vérifier que le blocage attendu revient sur la même famille de règles.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Le state lock Terraform reste bloqué
Contexte : Prouver qu’aucun apply n’est encore actif avant force-unlock, puis repartir sur un plan propre.
Preuves à confirmer : Lock ID, propriétaire du lock, run CI, backend ciblé, plan en attente et preuve qu’aucun apply n’est actif.
Contrôles immédiats : Identifier le propriétaire du lock | Contrôler le statut du job CI | Relancer un plan après unlock
Action proposée : Déverrouiller seulement après avoir prouvé qu’aucun apply ne tourne, puis repartir sur un plan frais avant tout apply.
Rollback : Revenir au commit précédent ou restaurer la dernière version de state validée si une dérive a été introduite.

Symptôme traité : Le state lock Terraform reste bloqué
Hypothèse initiale : Prouver qu’aucun apply n’est encore actif avant force-unlock, puis repartir sur un plan propre.
Preuves utilisées : Lock ID, propriétaire du lock, run CI, backend ciblé, plan en attente et preuve qu’aucun apply n’est actif.
Contrôles effectués : Identifier le propriétaire du lock | Contrôler le statut du job CI | Relancer un plan après unlock
Décision / action : Déverrouiller seulement après avoir prouvé qu’aucun apply ne tourne, puis repartir sur un plan frais avant tout apply.
Plan de retour arrière : Revenir au commit précédent ou restaurer la dernière version de state validée si une dérive a été introduite.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Azure Monitor déclenche une tempête d’alertes après déploiement
Contexte : Séparer impact réel, dimensions bruyantes, dérive de seuil, comportement d’action group et rollback avant de couper les notifications ou modifier les règles.
Preuves à confirmer : Séparer impact réel, dimensions bruyantes, dérive de seuil, comportement d’action group et rollback avant de couper les notifications ou modifier les règles.
Contrôles immédiats : Grouper les alertes par règle et cible | Comparer la première alerte avec la fenêtre de déploiement | Lire les logs du service avant de changer les seuils | Garder une alerte de symptôme utilisateur active
Action proposée : Exécuter les premiers contrôles dans l’ordre : Grouper les alertes par règle et cible | Comparer la première alerte avec la fenêtre de déploiement | Lire les logs du service avant de changer les seuils | Garder une alerte de symptôme utilisateur active. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : Azure Monitor déclenche une tempête d’alertes après déploiement
Hypothèse initiale : Séparer impact réel, dimensions bruyantes, dérive de seuil, comportement d’action group et rollback avant de couper les notifications ou modifier les règles.
Preuves utilisées : Séparer impact réel, dimensions bruyantes, dérive de seuil, comportement d’action group et rollback avant de couper les notifications ou modifier les règles.
Contrôles effectués : Grouper les alertes par règle et cible | Comparer la première alerte avec la fenêtre de déploiement | Lire les logs du service avant de changer les seuils | Garder une alerte de symptôme utilisateur active
Décision / action : Exécuter les premiers contrôles dans l’ordre : Grouper les alertes par règle et cible | Comparer la première alerte avec la fenêtre de déploiement | Lire les logs du service avant de changer les seuils | Garder une alerte de symptôme utilisateur active. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Une rotation de secret, une identité fédérée ou un changement d’identité managée casse un consommateur applicatif ou CI
Contexte : Séparer préparation, bascule, révocation, fédération d’identité workload et diagnostic d’identité managée ; valider l’identité réelle d’exécution, le chemin privé et les erreurs d’authentification avant de supprimer l’ancienne valeur ou d’élargir l’accès.
Preuves à confirmer : Séparer préparation, bascule, révocation, fédération d’identité workload et diagnostic d’identité managée ; valider l’identité réelle d’exécution, le chemin privé et les erreurs d’authentification avant de supprimer l’ancienne valeur ou d’élargir l’accès.
Contrôles immédiats : Lister les consommateurs réels | Vérifier l’identité runtime et la lecture du coffre | Contrôler les claims OIDC ou le DNS privé selon le chemin | Surveiller les 401/403/500, échecs de sign-in ou refus Key Vault
Action proposée : Exécuter les premiers contrôles dans l’ordre : Lister les consommateurs réels | Vérifier l’identité runtime et la lecture du coffre | Contrôler les claims OIDC ou le DNS privé selon le chemin | Surveiller les 401/403/500, échecs de sign-in ou refus Key Vault. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : Une rotation de secret, une identité fédérée ou un changement d’identité managée casse un consommateur applicatif ou CI
Hypothèse initiale : Séparer préparation, bascule, révocation, fédération d’identité workload et diagnostic d’identité managée ; valider l’identité réelle d’exécution, le chemin privé et les erreurs d’authentification avant de supprimer l’ancienne valeur ou d’élargir l’accès.
Preuves utilisées : Séparer préparation, bascule, révocation, fédération d’identité workload et diagnostic d’identité managée ; valider l’identité réelle d’exécution, le chemin privé et les erreurs d’authentification avant de supprimer l’ancienne valeur ou d’élargir l’accès.
Contrôles effectués : Lister les consommateurs réels | Vérifier l’identité runtime et la lecture du coffre | Contrôler les claims OIDC ou le DNS privé selon le chemin | Surveiller les 401/403/500, échecs de sign-in ou refus Key Vault
Décision / action : Exécuter les premiers contrôles dans l’ordre : Lister les consommateurs réels | Vérifier l’identité runtime et la lecture du coffre | Contrôler les claims OIDC ou le DNS privé selon le chemin | Surveiller les 401/403/500, échecs de sign-in ou refus Key Vault. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Une poison queue Azure Functions continue de grossir
Contexte : Séparer défaut de contrat, dépendance transitoire, identité, pression de ressources et effet partiel avant de rejouer des messages Storage Queue.
Preuves à confirmer : Séparer défaut de contrat, dépendance transitoire, identité, pression de ressources et effet partiel avant de rejouer des messages Storage Queue.
Contrôles immédiats : Échantillonner sans consommer les messages | Corréler message IDs, invocations et dépendances | Vérifier état aval et idempotence avant rejeu
Action proposée : Exécuter les premiers contrôles dans l’ordre : Échantillonner sans consommer les messages | Corréler message IDs, invocations et dépendances | Vérifier état aval et idempotence avant rejeu. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : Une poison queue Azure Functions continue de grossir
Hypothèse initiale : Séparer défaut de contrat, dépendance transitoire, identité, pression de ressources et effet partiel avant de rejouer des messages Storage Queue.
Preuves utilisées : Séparer défaut de contrat, dépendance transitoire, identité, pression de ressources et effet partiel avant de rejouer des messages Storage Queue.
Contrôles effectués : Échantillonner sans consommer les messages | Corréler message IDs, invocations et dépendances | Vérifier état aval et idempotence avant rejeu
Décision / action : Exécuter les premiers contrôles dans l’ordre : Échantillonner sans consommer les messages | Corréler message IDs, invocations et dépendances | Vérifier état aval et idempotence avant rejeu. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Une automatisation ressemble à une console distante
Contexte : Borner les entrées, templates et dépôts avant d’exposer des opérations à plus d’utilisateurs.
Preuves à confirmer : Entrées acceptées par le template, permissions, périmètre d’inventaire, branche dépôt et trace d’audit.
Contrôles immédiats : Lister les entrées acceptées | Supprimer les champs de commande arbitraire | Revoir les permissions des job templates
Action proposée : Remplacer les entrées arbitraires par des choix bornés et isoler les job templates par intention opérationnelle.
Rollback : Désactiver le template exposé ou revenir à la version de template précédemment approuvée.

Symptôme traité : Une automatisation ressemble à une console distante
Hypothèse initiale : Borner les entrées, templates et dépôts avant d’exposer des opérations à plus d’utilisateurs.
Preuves utilisées : Entrées acceptées par le template, permissions, périmètre d’inventaire, branche dépôt et trace d’audit.
Contrôles effectués : Lister les entrées acceptées | Supprimer les champs de commande arbitraire | Revoir les permissions des job templates
Décision / action : Remplacer les entrées arbitraires par des choix bornés et isoler les job templates par intention opérationnelle.
Plan de retour arrière : Désactiver le template exposé ou revenir à la version de template précédemment approuvée.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Un agent IA privé peut agir sans que l’action soit explicable
Contexte : Relier sources, identités, appels d’outils, journaux et validation humaine avant d’augmenter l’autonomie.
Preuves à confirmer : Documents sources, identité, appels d’outils, contexte de prompt, logs et point de validation humaine.
Contrôles immédiats : Lister les sources approuvées | Tracer les appels d’outils | Définir les points d’approbation humaine
Action proposée : Réduire le périmètre des outils, exiger une approbation sur les actions sensibles et relier chaque appel d’outil à une source.
Rollback : Désactiver l’intégration outil ou imposer une validation humaine tant que le chemin d’action n’est pas explicable.

Symptôme traité : Un agent IA privé peut agir sans que l’action soit explicable
Hypothèse initiale : Relier sources, identités, appels d’outils, journaux et validation humaine avant d’augmenter l’autonomie.
Preuves utilisées : Documents sources, identité, appels d’outils, contexte de prompt, logs et point de validation humaine.
Contrôles effectués : Lister les sources approuvées | Tracer les appels d’outils | Définir les points d’approbation humaine
Décision / action : Réduire le périmètre des outils, exiger une approbation sur les actions sensibles et relier chaque appel d’outil à une source.
Plan de retour arrière : Désactiver l’intégration outil ou imposer une validation humaine tant que le chemin d’action n’est pas explicable.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.