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 dead-letter queue Azure Service Bus continue de grossir
Contexte : Classer les raisons de dead-letter, corréler les preuves consumer et aval, vérifier l’idempotence, puis imposer manifeste, canari et critères d’arrêt avant rejeu.
Preuves à confirmer : Classer les raisons de dead-letter, corréler les preuves consumer et aval, vérifier l’idempotence, puis imposer manifeste, canari et critères d’arrêt avant rejeu.
Contrôles immédiats : Figer la queue ou subscription exacte et la fenêtre de croissance | Échantillonner sans consommer, par raison de dead-letter | Contrôler erreurs consumer, pertes de lock et état aval | Prouver l’idempotence avant un canari d’un message
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer la queue ou subscription exacte et la fenêtre de croissance | Échantillonner sans consommer, par raison de dead-letter | Contrôler erreurs consumer, pertes de lock et état aval | Prouver l’idempotence avant un canari d’un message. 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 dead-letter queue Azure Service Bus continue de grossir
Hypothèse initiale : Classer les raisons de dead-letter, corréler les preuves consumer et aval, vérifier l’idempotence, puis imposer manifeste, canari et critères d’arrêt avant rejeu.
Preuves utilisées : Classer les raisons de dead-letter, corréler les preuves consumer et aval, vérifier l’idempotence, puis imposer manifeste, canari et critères d’arrêt avant rejeu.
Contrôles effectués : Figer la queue ou subscription exacte et la fenêtre de croissance | Échantillonner sans consommer, par raison de dead-letter | Contrôler erreurs consumer, pertes de lock et état aval | Prouver l’idempotence avant un canari d’un message
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer la queue ou subscription exacte et la fenêtre de croissance | Échantillonner sans consommer, par raison de dead-letter | Contrôler erreurs consumer, pertes de lock et état aval | Prouver l’idempotence avant un canari d’un message. 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 remédiation Azure Policy modifie des ressources de production inattendues
Contexte : Figer définition et affectation, matérialiser les cibles éligibles, vérifier l’identité managée, puis utiliser un canary et des lots bornés avant d’élargir ou de compenser.
Preuves à confirmer : Figer définition et affectation, matérialiser les cibles éligibles, vérifier l’identité managée, puis utiliser un canary et des lots bornés avant d’élargir ou de compenser.
Contrôles immédiats : Identifier la référence de définition et les paramètres d’affectation | Exporter les identifiants des cibles non conformes | Revoir l’identité d’affectation et son scope RBAC effectif | Corréler les déploiements de remédiation avec l’Activity Log
Action proposée : Exécuter les premiers contrôles dans l’ordre : Identifier la référence de définition et les paramètres d’affectation | Exporter les identifiants des cibles non conformes | Revoir l’identité d’affectation et son scope RBAC effectif | Corréler les déploiements de remédiation avec l’Activity Log. 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 remédiation Azure Policy modifie des ressources de production inattendues
Hypothèse initiale : Figer définition et affectation, matérialiser les cibles éligibles, vérifier l’identité managée, puis utiliser un canary et des lots bornés avant d’élargir ou de compenser.
Preuves utilisées : Figer définition et affectation, matérialiser les cibles éligibles, vérifier l’identité managée, puis utiliser un canary et des lots bornés avant d’élargir ou de compenser.
Contrôles effectués : Identifier la référence de définition et les paramètres d’affectation | Exporter les identifiants des cibles non conformes | Revoir l’identité d’affectation et son scope RBAC effectif | Corréler les déploiements de remédiation avec l’Activity Log
Décision / action : Exécuter les premiers contrôles dans l’ordre : Identifier la référence de définition et les paramètres d’affectation | Exporter les identifiants des cibles non conformes | Revoir l’identité d’affectation et son scope RBAC effectif | Corréler les déploiements de remédiation avec l’Activity Log. 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.

[Incident] Un consumer Azure Event Hubs accumule du retard
Contexte : Séparer throttling du namespace, partition chaude, traitement consumer, progression des checkpoints et saturation aval avant d’ajouter de la capacité ou de rejouer des événements.
Preuves à confirmer : Séparer throttling du namespace, partition chaude, traitement consumer, progression des checkpoints et saturation aval avant d’ajouter de la capacité ou de rejouer des événements.
Contrôles immédiats : Comparer ingress, egress et requêtes throttlées | Mesurer progression et âge du checkpoint par partition | Contrôler ownership, erreurs consumer et latence aval | Prouver bornes de séquence et idempotence avant rejeu
Action proposée : Exécuter les premiers contrôles dans l’ordre : Comparer ingress, egress et requêtes throttlées | Mesurer progression et âge du checkpoint par partition | Contrôler ownership, erreurs consumer et latence aval | Prouver bornes de séquence 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é : Un consumer Azure Event Hubs accumule du retard
Hypothèse initiale : Séparer throttling du namespace, partition chaude, traitement consumer, progression des checkpoints et saturation aval avant d’ajouter de la capacité ou de rejouer des événements.
Preuves utilisées : Séparer throttling du namespace, partition chaude, traitement consumer, progression des checkpoints et saturation aval avant d’ajouter de la capacité ou de rejouer des événements.
Contrôles effectués : Comparer ingress, egress et requêtes throttlées | Mesurer progression et âge du checkpoint par partition | Contrôler ownership, erreurs consumer et latence aval | Prouver bornes de séquence et idempotence avant rejeu
Décision / action : Exécuter les premiers contrôles dans l’ordre : Comparer ingress, egress et requêtes throttlées | Mesurer progression et âge du checkpoint par partition | Contrôler ownership, erreurs consumer et latence aval | Prouver bornes de séquence 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] Un Hybrid Runbook Worker Azure Automation ne prend plus les jobs
Contexte : Séparer distribution, heartbeat, état de l’extension, sortie HTTPS, capacité, runtime et identité avant de relancer un job de production.
Preuves à confirmer : Séparer distribution, heartbeat, état de l’extension, sortie HTTPS, capacité, runtime et identité avant de relancer un job de production.
Contrôles immédiats : Conserver job ID, flux et fenêtre UTC | Comparer HybridWorkerPing et état de l’extension dans le groupe | Lire les logs locaux avant tout redémarrage | Terminer un canary sans effet avant relance
Action proposée : Exécuter les premiers contrôles dans l’ordre : Conserver job ID, flux et fenêtre UTC | Comparer HybridWorkerPing et état de l’extension dans le groupe | Lire les logs locaux avant tout redémarrage | Terminer un canary sans effet avant relance. 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 Hybrid Runbook Worker Azure Automation ne prend plus les jobs
Hypothèse initiale : Séparer distribution, heartbeat, état de l’extension, sortie HTTPS, capacité, runtime et identité avant de relancer un job de production.
Preuves utilisées : Séparer distribution, heartbeat, état de l’extension, sortie HTTPS, capacité, runtime et identité avant de relancer un job de production.
Contrôles effectués : Conserver job ID, flux et fenêtre UTC | Comparer HybridWorkerPing et état de l’extension dans le groupe | Lire les logs locaux avant tout redémarrage | Terminer un canary sans effet avant relance
Décision / action : Exécuter les premiers contrôles dans l’ordre : Conserver job ID, flux et fenêtre UTC | Comparer HybridWorkerPing et état de l’extension dans le groupe | Lire les logs locaux avant tout redémarrage | Terminer un canary sans effet avant relance. 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 Bastion ne parvient pas à ouvrir une session SSH ou RDP
Contexte : Séparer chemin HTTPS client, santé Bastion, règles AzureBastionSubnet, routage, NSG cibles, service invité et identité avant d’exposer les ports d’administration.
Preuves à confirmer : Séparer chemin HTTPS client, santé Bastion, règles AzureBastionSubnet, routage, NSG cibles, service invité et identité avant d’exposer les ports d’administration.
Contrôles immédiats : Figer un échec avec heure UTC et IP privée cible | Contrôler le provisioning Bastion et toutes les règles AzureBastionSubnet | Inspecter les NSG effectifs et routes de la NIC cible | Vérifier séparément service invité et authentification
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer un échec avec heure UTC et IP privée cible | Contrôler le provisioning Bastion et toutes les règles AzureBastionSubnet | Inspecter les NSG effectifs et routes de la NIC cible | Vérifier séparément service invité et authentification. 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 Bastion ne parvient pas à ouvrir une session SSH ou RDP
Hypothèse initiale : Séparer chemin HTTPS client, santé Bastion, règles AzureBastionSubnet, routage, NSG cibles, service invité et identité avant d’exposer les ports d’administration.
Preuves utilisées : Séparer chemin HTTPS client, santé Bastion, règles AzureBastionSubnet, routage, NSG cibles, service invité et identité avant d’exposer les ports d’administration.
Contrôles effectués : Figer un échec avec heure UTC et IP privée cible | Contrôler le provisioning Bastion et toutes les règles AzureBastionSubnet | Inspecter les NSG effectifs et routes de la NIC cible | Vérifier séparément service invité et authentification
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer un échec avec heure UTC et IP privée cible | Contrôler le provisioning Bastion et toutes les règles AzureBastionSubnet | Inspecter les NSG effectifs et routes de la NIC cible | Vérifier séparément service invité et authentification. 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 application épuise son pool de connexions Azure SQL
Contexte : Séparer rétention locale des connexions, sessions et attentes SQL, échecs réseau, acquisition du jeton d’identité managée et multiplication liée à l’autoscaling avant de relever le pool ou le service tier.
Preuves à confirmer : Séparer rétention locale des connexions, sessions et attentes SQL, échecs réseau, acquisition du jeton d’identité managée et multiplication liée à l’autoscaling avant de relever le pool ou le service tier.
Contrôles immédiats : Relier un timeout à une révision et une instance | Calculer l’enveloppe globale de capacité des pools | Comparer sessions SQL, requêtes actives et attentes | Tester la correction par canari avec arrêt et rollback
Action proposée : Exécuter les premiers contrôles dans l’ordre : Relier un timeout à une révision et une instance | Calculer l’enveloppe globale de capacité des pools | Comparer sessions SQL, requêtes actives et attentes | Tester la correction par canari avec arrêt et rollback. 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 application épuise son pool de connexions Azure SQL
Hypothèse initiale : Séparer rétention locale des connexions, sessions et attentes SQL, échecs réseau, acquisition du jeton d’identité managée et multiplication liée à l’autoscaling avant de relever le pool ou le service tier.
Preuves utilisées : Séparer rétention locale des connexions, sessions et attentes SQL, échecs réseau, acquisition du jeton d’identité managée et multiplication liée à l’autoscaling avant de relever le pool ou le service tier.
Contrôles effectués : Relier un timeout à une révision et une instance | Calculer l’enveloppe globale de capacité des pools | Comparer sessions SQL, requêtes actives et attentes | Tester la correction par canari avec arrêt et rollback
Décision / action : Exécuter les premiers contrôles dans l’ordre : Relier un timeout à une révision et une instance | Calculer l’enveloppe globale de capacité des pools | Comparer sessions SQL, requêtes actives et attentes | Tester la correction par canari avec arrêt et rollback. 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 image ACR échoue à la vérification de signature avant promotion AKS
Contexte : Séparer tag mutable, signature absente, identité de publication non approuvée, rotation du trust store et accès ACR avant de contourner l’admission ou déployer une image non vérifiée.
Preuves à confirmer : Séparer tag mutable, signature absente, identité de publication non approuvée, rotation du trust store et accès ACR avant de contourner l’admission ou déployer une image non vérifiée.
Contrôles immédiats : Résoudre le tag candidat vers un digest immuable | Inventorier les signatures avec Notation | Vérifier scope du repository, trust store et identité de publication | Comparer le digest vérifié avec l’imageID runtime AKS
Action proposée : Exécuter les premiers contrôles dans l’ordre : Résoudre le tag candidat vers un digest immuable | Inventorier les signatures avec Notation | Vérifier scope du repository, trust store et identité de publication | Comparer le digest vérifié avec l’imageID runtime AKS. 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 image ACR échoue à la vérification de signature avant promotion AKS
Hypothèse initiale : Séparer tag mutable, signature absente, identité de publication non approuvée, rotation du trust store et accès ACR avant de contourner l’admission ou déployer une image non vérifiée.
Preuves utilisées : Séparer tag mutable, signature absente, identité de publication non approuvée, rotation du trust store et accès ACR avant de contourner l’admission ou déployer une image non vérifiée.
Contrôles effectués : Résoudre le tag candidat vers un digest immuable | Inventorier les signatures avec Notation | Vérifier scope du repository, trust store et identité de publication | Comparer le digest vérifié avec l’imageID runtime AKS
Décision / action : Exécuter les premiers contrôles dans l’ordre : Résoudre le tag candidat vers un digest immuable | Inventorier les signatures avec Notation | Vérifier scope du repository, trust store et identité de publication | Comparer le digest vérifié avec l’imageID runtime AKS. 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 rollout de Deployment AKS reste bloqué avant que la nouvelle révision soit disponible
Contexte : Localiser le premier objet bloqué entre Deployment, ReplicaSet, admission, scheduling, démarrage de l’image et readiness avant de supprimer des pods, allonger les timeouts ou forcer un rollback.
Preuves à confirmer : Localiser le premier objet bloqué entre Deployment, ReplicaSet, admission, scheduling, démarrage de l’image et readiness avant de supprimer des pods, allonger les timeouts ou forcer un rollback.
Contrôles immédiats : Capturer les conditions du Deployment et l’historique du rollout | Comparer pods désirés, créés et Ready sur le ReplicaSet candidat | Lire les événements des pods et du namespace avant de changer la capacité | Prouver la compatibilité de la configuration externe avant rollback
Action proposée : Exécuter les premiers contrôles dans l’ordre : Capturer les conditions du Deployment et l’historique du rollout | Comparer pods désirés, créés et Ready sur le ReplicaSet candidat | Lire les événements des pods et du namespace avant de changer la capacité | Prouver la compatibilité de la configuration externe avant rollback. 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 rollout de Deployment AKS reste bloqué avant que la nouvelle révision soit disponible
Hypothèse initiale : Localiser le premier objet bloqué entre Deployment, ReplicaSet, admission, scheduling, démarrage de l’image et readiness avant de supprimer des pods, allonger les timeouts ou forcer un rollback.
Preuves utilisées : Localiser le premier objet bloqué entre Deployment, ReplicaSet, admission, scheduling, démarrage de l’image et readiness avant de supprimer des pods, allonger les timeouts ou forcer un rollback.
Contrôles effectués : Capturer les conditions du Deployment et l’historique du rollout | Comparer pods désirés, créés et Ready sur le ReplicaSet candidat | Lire les événements des pods et du namespace avant de changer la capacité | Prouver la compatibilité de la configuration externe avant rollback
Décision / action : Exécuter les premiers contrôles dans l’ordre : Capturer les conditions du Deployment et l’historique du rollout | Comparer pods désirés, créés et Ready sur le ReplicaSet candidat | Lire les événements des pods et du namespace avant de changer la capacité | Prouver la compatibilité de la configuration externe avant rollback. 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] Des runs Azure Logic Apps accumulent des 429 et des retries
Contexte : Séparer limites de la ressource Logic Apps, throttling du connecteur et saturation de la cible avant d’ajouter des retries ou d’augmenter la concurrence.
Preuves à confirmer : Séparer limites de la ressource Logic Apps, throttling du connecteur et saturation de la cible avant d’ajouter des retries ou d’augmenter la concurrence.
Contrôles immédiats : Geler un workflow, une action, une connexion et une fenêtre UTC | Corréler les identifiants du run et de la requête cible | Mesurer l’amplification par retries et concurrence | Exécuter un canary borné avant une reprise par paliers
Action proposée : Exécuter les premiers contrôles dans l’ordre : Geler un workflow, une action, une connexion et une fenêtre UTC | Corréler les identifiants du run et de la requête cible | Mesurer l’amplification par retries et concurrence | Exécuter un canary borné avant une reprise par paliers. 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é : Des runs Azure Logic Apps accumulent des 429 et des retries
Hypothèse initiale : Séparer limites de la ressource Logic Apps, throttling du connecteur et saturation de la cible avant d’ajouter des retries ou d’augmenter la concurrence.
Preuves utilisées : Séparer limites de la ressource Logic Apps, throttling du connecteur et saturation de la cible avant d’ajouter des retries ou d’augmenter la concurrence.
Contrôles effectués : Geler un workflow, une action, une connexion et une fenêtre UTC | Corréler les identifiants du run et de la requête cible | Mesurer l’amplification par retries et concurrence | Exécuter un canary borné avant une reprise par paliers
Décision / action : Exécuter les premiers contrôles dans l’ordre : Geler un workflow, une action, une connexion et une fenêtre UTC | Corréler les identifiants du run et de la requête cible | Mesurer l’amplification par retries et concurrence | Exécuter un canary borné avant une reprise par paliers. 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] Les évaluations d’un feature flag diffèrent entre les instances applicatives
Contexte : Séparer définition publiée, ETag par instance, chemin de refresh, contexte de ciblage et télémétrie d’évaluation avant de redémarrer le parc ou rollbacker le flag.
Preuves à confirmer : Séparer définition publiée, ETag par instance, chemin de refresh, contexte de ciblage et télémétrie d’évaluation avant de redémarrer le parc ou rollbacker le flag.
Contrôles immédiats : Figer le flag, le label, la fenêtre de changement et l’état précédent connu | Comparer l’ETag publié entre instances saines et affectées | Rejouer un contexte de ciblage stable sur un canari | Corréler les événements FeatureEvaluation avec les traces de refresh et les métriques métier
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer le flag, le label, la fenêtre de changement et l’état précédent connu | Comparer l’ETag publié entre instances saines et affectées | Rejouer un contexte de ciblage stable sur un canari | Corréler les événements FeatureEvaluation avec les traces de refresh et les métriques métier. 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é : Les évaluations d’un feature flag diffèrent entre les instances applicatives
Hypothèse initiale : Séparer définition publiée, ETag par instance, chemin de refresh, contexte de ciblage et télémétrie d’évaluation avant de redémarrer le parc ou rollbacker le flag.
Preuves utilisées : Séparer définition publiée, ETag par instance, chemin de refresh, contexte de ciblage et télémétrie d’évaluation avant de redémarrer le parc ou rollbacker le flag.
Contrôles effectués : Figer le flag, le label, la fenêtre de changement et l’état précédent connu | Comparer l’ETag publié entre instances saines et affectées | Rejouer un contexte de ciblage stable sur un canari | Corréler les événements FeatureEvaluation avec les traces de refresh et les métriques métier
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer le flag, le label, la fenêtre de changement et l’état précédent connu | Comparer l’ETag publié entre instances saines et affectées | Rejouer un contexte de ciblage stable sur un canari | Corréler les événements FeatureEvaluation avec les traces de refresh et les métriques métier. 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 agent IA perd ses contraintes quand la conversation s’allonge
Contexte : Séparer consignes système, historique, retrieval, schémas et sorties d’outils avant d’augmenter la limite de contexte ou de changer de modèle.
Preuves à confirmer : Séparer consignes système, historique, retrieval, schémas et sorties d’outils avant d’augmenter la limite de contexte ou de changer de modèle.
Contrôles immédiats : Figer une trace saine et une trace dégradée du même parcours | Mesurer la croissance du contexte par segment et par tour | Vérifier que les approbations et décisions ouvertes survivent à la compaction | Tester la policy bornée sur un canari avant promotion
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer une trace saine et une trace dégradée du même parcours | Mesurer la croissance du contexte par segment et par tour | Vérifier que les approbations et décisions ouvertes survivent à la compaction | Tester la policy bornée sur un canari avant promotion. 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 agent IA perd ses contraintes quand la conversation s’allonge
Hypothèse initiale : Séparer consignes système, historique, retrieval, schémas et sorties d’outils avant d’augmenter la limite de contexte ou de changer de modèle.
Preuves utilisées : Séparer consignes système, historique, retrieval, schémas et sorties d’outils avant d’augmenter la limite de contexte ou de changer de modèle.
Contrôles effectués : Figer une trace saine et une trace dégradée du même parcours | Mesurer la croissance du contexte par segment et par tour | Vérifier que les approbations et décisions ouvertes survivent à la compaction | Tester la policy bornée sur un canari avant promotion
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer une trace saine et une trace dégradée du même parcours | Mesurer la croissance du contexte par segment et par tour | Vérifier que les approbations et décisions ouvertes survivent à la compaction | Tester la policy bornée sur un canari avant promotion. 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] Les connexions Azure Managed Redis s’emballent pendant que l’application accumule des timeouts
Contexte : Séparer pression serveur légitime, amplification des reconnexions clientes, DNS/TLS runtime et dérive de release avant de scaler ou déclencher une bascule.
Preuves à confirmer : Séparer pression serveur légitime, amplification des reconnexions clientes, DNS/TLS runtime et dérive de release avant de scaler ou déclencher une bascule.
Contrôles immédiats : Figer release, nombre de replicas et fenêtre d’incident | Comparer clients connectés, charge serveur et opérations utiles | Mesurer l’enveloppe de connexions par instance | Tester le correctif client en canari avec rollback explicite
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer release, nombre de replicas et fenêtre d’incident | Comparer clients connectés, charge serveur et opérations utiles | Mesurer l’enveloppe de connexions par instance | Tester le correctif client en canari avec rollback explicite. 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é : Les connexions Azure Managed Redis s’emballent pendant que l’application accumule des timeouts
Hypothèse initiale : Séparer pression serveur légitime, amplification des reconnexions clientes, DNS/TLS runtime et dérive de release avant de scaler ou déclencher une bascule.
Preuves utilisées : Séparer pression serveur légitime, amplification des reconnexions clientes, DNS/TLS runtime et dérive de release avant de scaler ou déclencher une bascule.
Contrôles effectués : Figer release, nombre de replicas et fenêtre d’incident | Comparer clients connectés, charge serveur et opérations utiles | Mesurer l’enveloppe de connexions par instance | Tester le correctif client en canari avec rollback explicite
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer release, nombre de replicas et fenêtre d’incident | Comparer clients connectés, charge serveur et opérations utiles | Mesurer l’enveloppe de connexions par instance | Tester le correctif client en canari avec rollback explicite. 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 alerte Azure Monitor se déclenche mais aucune action group ne notifie l’astreinte
Contexte : Séparer évaluation du signal, traitement de l’alerte déclenchée, scope, filtres, horaire et livraison de l’action group avant de modifier la règle d’alerte.
Preuves à confirmer : Séparer évaluation du signal, traitement de l’alerte déclenchée, scope, filtres, horaire et livraison de l’action group avant de modifier la règle d’alerte.
Contrôles immédiats : Figer un identifiant d’alerte déclenchée et ses action groups attendues | Lister les règles de traitement actives et confronter leurs scopes | Rejouer l’horaire dans son fuseau configuré | Générer une nouvelle alerte bornée après propagation
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer un identifiant d’alerte déclenchée et ses action groups attendues | Lister les règles de traitement actives et confronter leurs scopes | Rejouer l’horaire dans son fuseau configuré | Générer une nouvelle alerte bornée après propagation. 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 alerte Azure Monitor se déclenche mais aucune action group ne notifie l’astreinte
Hypothèse initiale : Séparer évaluation du signal, traitement de l’alerte déclenchée, scope, filtres, horaire et livraison de l’action group avant de modifier la règle d’alerte.
Preuves utilisées : Séparer évaluation du signal, traitement de l’alerte déclenchée, scope, filtres, horaire et livraison de l’action group avant de modifier la règle d’alerte.
Contrôles effectués : Figer un identifiant d’alerte déclenchée et ses action groups attendues | Lister les règles de traitement actives et confronter leurs scopes | Rejouer l’horaire dans son fuseau configuré | Générer une nouvelle alerte bornée après propagation
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer un identifiant d’alerte déclenchée et ses action groups attendues | Lister les règles de traitement actives et confronter leurs scopes | Rejouer l’horaire dans son fuseau configuré | Générer une nouvelle alerte bornée après propagation. 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 read replica Azure Database for PostgreSQL prend du retard avant promotion
Contexte : Séparer lag temporel, écart WAL en octets, rétention des logs sur le primaire, capacité de replay et état du chemin cible avant switchover planifié ou promotion forcée.
Preuves à confirmer : Séparer lag temporel, écart WAL en octets, rétention des logs sur le primaire, capacité de replay et état du chemin cible avant switchover planifié ou promotion forcée.
Contrôles immédiats : Figer le mode de promotion et le RPO accepté | Comparer lag en secondes, en octets et marqueur métier | Contrôler stockage WAL primaire et saturation de la replica | Valider virtual endpoints, identité et chemin d’écriture avant promotion
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer le mode de promotion et le RPO accepté | Comparer lag en secondes, en octets et marqueur métier | Contrôler stockage WAL primaire et saturation de la replica | Valider virtual endpoints, identité et chemin d’écriture avant promotion. 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 read replica Azure Database for PostgreSQL prend du retard avant promotion
Hypothèse initiale : Séparer lag temporel, écart WAL en octets, rétention des logs sur le primaire, capacité de replay et état du chemin cible avant switchover planifié ou promotion forcée.
Preuves utilisées : Séparer lag temporel, écart WAL en octets, rétention des logs sur le primaire, capacité de replay et état du chemin cible avant switchover planifié ou promotion forcée.
Contrôles effectués : Figer le mode de promotion et le RPO accepté | Comparer lag en secondes, en octets et marqueur métier | Contrôler stockage WAL primaire et saturation de la replica | Valider virtual endpoints, identité et chemin d’écriture avant promotion
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer le mode de promotion et le RPO accepté | Comparer lag en secondes, en octets et marqueur métier | Contrôler stockage WAL primaire et saturation de la replica | Valider virtual endpoints, identité et chemin d’écriture avant promotion. 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 runbook Azure Automation renvoie 403 après un changement d’identité managée
Contexte : Séparer sandbox cloud et Hybrid Worker, identités du compte Automation et de la VM, contexte Az persistant, droits control plane et data plane avant d’élargir le RBAC.
Preuves à confirmer : Séparer sandbox cloud et Hybrid Worker, identités du compte Automation et de la VM, contexte Az persistant, droits control plane et data plane avant d’élargir le RBAC.
Contrôles immédiats : Figer job ID, cible d’exécution et opération refusée | Réinitialiser le contexte Az et prouver le principal runtime | Confronter action exacte, rôle et scope | Exécuter des canaris positif et négatif avant promotion
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer job ID, cible d’exécution et opération refusée | Réinitialiser le contexte Az et prouver le principal runtime | Confronter action exacte, rôle et scope | Exécuter des canaris positif et négatif avant promotion. 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 runbook Azure Automation renvoie 403 après un changement d’identité managée
Hypothèse initiale : Séparer sandbox cloud et Hybrid Worker, identités du compte Automation et de la VM, contexte Az persistant, droits control plane et data plane avant d’élargir le RBAC.
Preuves utilisées : Séparer sandbox cloud et Hybrid Worker, identités du compte Automation et de la VM, contexte Az persistant, droits control plane et data plane avant d’élargir le RBAC.
Contrôles effectués : Figer job ID, cible d’exécution et opération refusée | Réinitialiser le contexte Az et prouver le principal runtime | Confronter action exacte, rôle et scope | Exécuter des canaris positif et négatif avant promotion
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer job ID, cible d’exécution et opération refusée | Réinitialiser le contexte Az et prouver le principal runtime | Confronter action exacte, rôle et scope | Exécuter des canaris positif et négatif avant promotion. 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 origin Azure Front Door devient unhealthy et le trafic bascule de façon inattendue
Contexte : Séparer contrat du health probe, DNS/TLS, Private Link éventuel, capacité backend et changements de routage avant de drainer, basculer ou rétablir le trafic.
Preuves à confirmer : Séparer contrat du health probe, DNS/TLS, Private Link éventuel, capacité backend et changements de routage avant de drainer, basculer ou rétablir le trafic.
Contrôles immédiats : Figer route, origin group et fenêtre UTC | Lire les probes échoués par origin et par POP | Vérifier hostname, SNI, certificat et réponse de santé | Prouver la capacité de secours avant de modifier les poids
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer route, origin group et fenêtre UTC | Lire les probes échoués par origin et par POP | Vérifier hostname, SNI, certificat et réponse de santé | Prouver la capacité de secours avant de modifier les poids. 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 origin Azure Front Door devient unhealthy et le trafic bascule de façon inattendue
Hypothèse initiale : Séparer contrat du health probe, DNS/TLS, Private Link éventuel, capacité backend et changements de routage avant de drainer, basculer ou rétablir le trafic.
Preuves utilisées : Séparer contrat du health probe, DNS/TLS, Private Link éventuel, capacité backend et changements de routage avant de drainer, basculer ou rétablir le trafic.
Contrôles effectués : Figer route, origin group et fenêtre UTC | Lire les probes échoués par origin et par POP | Vérifier hostname, SNI, certificat et réponse de santé | Prouver la capacité de secours avant de modifier les poids
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer route, origin group et fenêtre UTC | Lire les probes échoués par origin et par POP | Vérifier hostname, SNI, certificat et réponse de santé | Prouver la capacité de secours avant de modifier les poids. 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 agent IA rappelle du contexte provenant d’une autre session ou équipe
Contexte : Séparer historique de conversation, résumés compactés, mémoire durable, caches de retrieval, résultats d’outils et identité runtime avant d’activer la persistance pour davantage d’utilisateurs.
Preuves à confirmer : Séparer historique de conversation, résumés compactés, mémoire durable, caches de retrieval, résultats d’outils et identité runtime avant d’activer la persistance pour davantage d’utilisateurs.
Contrôles immédiats : Figer les frontières utilisateur, équipe, environnement et session | Semer des canaris synthétiques distincts dans deux scopes | Activer chaque couche d’état séparément | Rejouer sous concurrence, expiration et révocation
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer les frontières utilisateur, équipe, environnement et session | Semer des canaris synthétiques distincts dans deux scopes | Activer chaque couche d’état séparément | Rejouer sous concurrence, expiration et révocation. 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 agent IA rappelle du contexte provenant d’une autre session ou équipe
Hypothèse initiale : Séparer historique de conversation, résumés compactés, mémoire durable, caches de retrieval, résultats d’outils et identité runtime avant d’activer la persistance pour davantage d’utilisateurs.
Preuves utilisées : Séparer historique de conversation, résumés compactés, mémoire durable, caches de retrieval, résultats d’outils et identité runtime avant d’activer la persistance pour davantage d’utilisateurs.
Contrôles effectués : Figer les frontières utilisateur, équipe, environnement et session | Semer des canaris synthétiques distincts dans deux scopes | Activer chaque couche d’état séparément | Rejouer sous concurrence, expiration et révocation
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer les frontières utilisateur, équipe, environnement et session | Semer des canaris synthétiques distincts dans deux scopes | Activer chaque couche d’état séparément | Rejouer sous concurrence, expiration et révocation. 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 fenêtre Azure Update Manager se termine avec une partie du parc encore non conforme
Contexte : Séparer appartenance au scope dynamique, orchestration, budget de fenêtre épuisé, échecs de patch et reboots en attente avant de forcer une installation hors fenêtre.
Preuves à confirmer : Séparer appartenance au scope dynamique, orchestration, budget de fenêtre épuisé, échecs de patch et reboots en attente avant de forcer une installation hors fenêtre.
Contrôles immédiats : Figer le contrat de maintenance et l’inventaire attendu | Comparer machines correspondantes, runs de maintenance et installations | Séparer absence de run, exécution partielle, patch en échec et reboot en attente | Prouver la capacité du service avant de reprendre un lot borné
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer le contrat de maintenance et l’inventaire attendu | Comparer machines correspondantes, runs de maintenance et installations | Séparer absence de run, exécution partielle, patch en échec et reboot en attente | Prouver la capacité du service avant de reprendre un lot borné. 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 fenêtre Azure Update Manager se termine avec une partie du parc encore non conforme
Hypothèse initiale : Séparer appartenance au scope dynamique, orchestration, budget de fenêtre épuisé, échecs de patch et reboots en attente avant de forcer une installation hors fenêtre.
Preuves utilisées : Séparer appartenance au scope dynamique, orchestration, budget de fenêtre épuisé, échecs de patch et reboots en attente avant de forcer une installation hors fenêtre.
Contrôles effectués : Figer le contrat de maintenance et l’inventaire attendu | Comparer machines correspondantes, runs de maintenance et installations | Séparer absence de run, exécution partielle, patch en échec et reboot en attente | Prouver la capacité du service avant de reprendre un lot borné
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer le contrat de maintenance et l’inventaire attendu | Comparer machines correspondantes, runs de maintenance et installations | Séparer absence de run, exécution partielle, patch en échec et reboot en attente | Prouver la capacité du service avant de reprendre un lot borné. 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 certificat Azure App Service est renouvelé mais l’ancien certificat reste servi
Contexte : Séparer émission, validation du domaine, version Key Vault, import App Service, binding du hostname et certificat observé avec SNI avant synchronisation ou rebinding.
Preuves à confirmer : Séparer émission, validation du domaine, version Key Vault, import App Service, binding du hostname et certificat observé avec SNI avant synchronisation ou rebinding.
Contrôles immédiats : Lire l’empreinte servie avec le vrai hostname et SNI | Comparer SAN et expiration du candidat avec l’inventaire App Service | Contrôler version Key Vault et état d’import si applicable | Conserver le binding actuel et le thumbprint de rollback
Action proposée : Exécuter les premiers contrôles dans l’ordre : Lire l’empreinte servie avec le vrai hostname et SNI | Comparer SAN et expiration du candidat avec l’inventaire App Service | Contrôler version Key Vault et état d’import si applicable | Conserver le binding actuel et le thumbprint de rollback. 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 certificat Azure App Service est renouvelé mais l’ancien certificat reste servi
Hypothèse initiale : Séparer émission, validation du domaine, version Key Vault, import App Service, binding du hostname et certificat observé avec SNI avant synchronisation ou rebinding.
Preuves utilisées : Séparer émission, validation du domaine, version Key Vault, import App Service, binding du hostname et certificat observé avec SNI avant synchronisation ou rebinding.
Contrôles effectués : Lire l’empreinte servie avec le vrai hostname et SNI | Comparer SAN et expiration du candidat avec l’inventaire App Service | Contrôler version Key Vault et état d’import si applicable | Conserver le binding actuel et le thumbprint de rollback
Décision / action : Exécuter les premiers contrôles dans l’ordre : Lire l’empreinte servie avec le vrai hostname et SNI | Comparer SAN et expiration du candidat avec l’inventaire App Service | Contrôler version Key Vault et état d’import si applicable | Conserver le binding actuel et le thumbprint de rollback. 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 flux Azure est refusé alors que le NSG l’autorise
Contexte : Séparer règles Security Admin Azure Virtual Network Manager, appartenance au network group, évaluation NSG et joignabilité réelle du service avant d’ouvrir les règles locales.
Preuves à confirmer : Séparer règles Security Admin Azure Virtual Network Manager, appartenance au network group, évaluation NSG et joignabilité réelle du service avant d’ouvrir les règles locales.
Contrôles immédiats : Capturer le tuple exact source, destination et port | Lister les règles Security Admin effectives sur le VNet | Lancer IP Flow Verify et identifier la règle décisive | Confirmer la décision dans les VNet flow logs
Action proposée : Exécuter les premiers contrôles dans l’ordre : Capturer le tuple exact source, destination et port | Lister les règles Security Admin effectives sur le VNet | Lancer IP Flow Verify et identifier la règle décisive | Confirmer la décision dans les VNet flow logs. 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 flux Azure est refusé alors que le NSG l’autorise
Hypothèse initiale : Séparer règles Security Admin Azure Virtual Network Manager, appartenance au network group, évaluation NSG et joignabilité réelle du service avant d’ouvrir les règles locales.
Preuves utilisées : Séparer règles Security Admin Azure Virtual Network Manager, appartenance au network group, évaluation NSG et joignabilité réelle du service avant d’ouvrir les règles locales.
Contrôles effectués : Capturer le tuple exact source, destination et port | Lister les règles Security Admin effectives sur le VNet | Lancer IP Flow Verify et identifier la règle décisive | Confirmer la décision dans les VNet flow logs
Décision / action : Exécuter les premiers contrôles dans l’ordre : Capturer le tuple exact source, destination et port | Lister les règles Security Admin effectives sur le VNet | Lancer IP Flow Verify et identifier la règle décisive | Confirmer la décision dans les VNet flow logs. 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 profil Azure Traffic Manager est dégradé et la bascule paraît incohérente selon les clients
Contexte : Séparer contrat de probe déployé, état de monitoring des endpoints, preuves backend, réponses DNS, TTL et capacité secondaire avant de désactiver le primaire ou forcer la bascule.
Preuves à confirmer : Séparer contrat de probe déployé, état de monitoring des endpoints, preuves backend, réponses DNS, TTL et capacité secondaire avant de désactiver le primaire ou forcer la bascule.
Contrôles immédiats : Capturer configuration du profil, des endpoints, de la probe et du TTL | Rejouer exactement la probe depuis plusieurs points externes | Corréler ProbeHealthStatusEvents et logs backend | Comparer les réponses DNS et prouver la readiness secondaire
Action proposée : Exécuter les premiers contrôles dans l’ordre : Capturer configuration du profil, des endpoints, de la probe et du TTL | Rejouer exactement la probe depuis plusieurs points externes | Corréler ProbeHealthStatusEvents et logs backend | Comparer les réponses DNS et prouver la readiness secondaire. 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 profil Azure Traffic Manager est dégradé et la bascule paraît incohérente selon les clients
Hypothèse initiale : Séparer contrat de probe déployé, état de monitoring des endpoints, preuves backend, réponses DNS, TTL et capacité secondaire avant de désactiver le primaire ou forcer la bascule.
Preuves utilisées : Séparer contrat de probe déployé, état de monitoring des endpoints, preuves backend, réponses DNS, TTL et capacité secondaire avant de désactiver le primaire ou forcer la bascule.
Contrôles effectués : Capturer configuration du profil, des endpoints, de la probe et du TTL | Rejouer exactement la probe depuis plusieurs points externes | Corréler ProbeHealthStatusEvents et logs backend | Comparer les réponses DNS et prouver la readiness secondaire
Décision / action : Exécuter les premiers contrôles dans l’ordre : Capturer configuration du profil, des endpoints, de la probe et du TTL | Rejouer exactement la probe depuis plusieurs points externes | Corréler ProbeHealthStatusEvents et logs backend | Comparer les réponses DNS et prouver la readiness secondaire. 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 runbook Azure Automation fonctionne dans son runtime actuel mais échoue dans l’environnement candidat
Contexte : Séparer version du langage, résolution des packages, identité, sérialisation et préparation des Hybrid Workers avant de relier les runbooks de production.
Preuves à confirmer : Séparer version du langage, résolution des packages, identité, sérialisation et préparation des Hybrid Workers avant de relier les runbooks de production.
Contrôles immédiats : Figer les manifestes des runtimes actuel et candidat | Lancer les tests positifs et négatifs du brouillon avec le candidat | Qualifier chaque Hybrid Worker cible | Tester un effet borné en canari puis confirmer un second run sans diff
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer les manifestes des runtimes actuel et candidat | Lancer les tests positifs et négatifs du brouillon avec le candidat | Qualifier chaque Hybrid Worker cible | Tester un effet borné en canari puis confirmer un second run sans diff. 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 runbook Azure Automation fonctionne dans son runtime actuel mais échoue dans l’environnement candidat
Hypothèse initiale : Séparer version du langage, résolution des packages, identité, sérialisation et préparation des Hybrid Workers avant de relier les runbooks de production.
Preuves utilisées : Séparer version du langage, résolution des packages, identité, sérialisation et préparation des Hybrid Workers avant de relier les runbooks de production.
Contrôles effectués : Figer les manifestes des runtimes actuel et candidat | Lancer les tests positifs et négatifs du brouillon avec le candidat | Qualifier chaque Hybrid Worker cible | Tester un effet borné en canari puis confirmer un second run sans diff
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer les manifestes des runtimes actuel et candidat | Lancer les tests positifs et négatifs du brouillon avec le candidat | Qualifier chaque Hybrid Worker cible | Tester un effet borné en canari puis confirmer un second run sans diff. 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] La cardinalité Azure Monitor Managed Prometheus explose après un déploiement AKS
Contexte : Séparer pression d’ingestion du workspace, échecs de scrape, targets dupliquées et labels non bornés avant de filtrer les métriques, augmenter les quotas ou rollbacker la release.
Preuves à confirmer : Séparer pression d’ingestion du workspace, échecs de scrape, targets dupliquées et labels non bornés avant de filtrer les métriques, augmenter les quotas ou rollbacker la release.
Contrôles immédiats : Figer workspace, cluster, release et fenêtre UTC | Comparer les tendances de séries actives et d’ingestion | Borner PromQL pour identifier métrique et label | Tester le relabeling en canari sans casser les alertes
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer workspace, cluster, release et fenêtre UTC | Comparer les tendances de séries actives et d’ingestion | Borner PromQL pour identifier métrique et label | Tester le relabeling en canari sans casser les alertes. 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é : La cardinalité Azure Monitor Managed Prometheus explose après un déploiement AKS
Hypothèse initiale : Séparer pression d’ingestion du workspace, échecs de scrape, targets dupliquées et labels non bornés avant de filtrer les métriques, augmenter les quotas ou rollbacker la release.
Preuves utilisées : Séparer pression d’ingestion du workspace, échecs de scrape, targets dupliquées et labels non bornés avant de filtrer les métriques, augmenter les quotas ou rollbacker la release.
Contrôles effectués : Figer workspace, cluster, release et fenêtre UTC | Comparer les tendances de séries actives et d’ingestion | Borner PromQL pour identifier métrique et label | Tester le relabeling en canari sans casser les alertes
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer workspace, cluster, release et fenêtre UTC | Comparer les tendances de séries actives et d’ingestion | Borner PromQL pour identifier métrique et label | Tester le relabeling en canari sans casser les alertes. 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 VMSS remplace ou réimage en boucle des instances unhealthy
Contexte : Séparer signal de santé, grace period, état du service d’orchestration, modèle VMSS courant et contrat de persistance avant de modifier Replace, Reimage ou Restart.
Preuves à confirmer : Séparer signal de santé, grace period, état du service d’orchestration, modèle VMSS courant et contrat de persistance avant de modifier Replace, Reimage ou Restart.
Contrôles immédiats : Figer la chronologie des réparations et la capacité utile | Lire automaticRepairsPolicy et l’état du service d’orchestration | Rejouer le contrat de santé sur instances saines et affectées | Créer un canari depuis le modèle courant avant la reprise
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer la chronologie des réparations et la capacité utile | Lire automaticRepairsPolicy et l’état du service d’orchestration | Rejouer le contrat de santé sur instances saines et affectées | Créer un canari depuis le modèle courant avant la reprise. 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 VMSS remplace ou réimage en boucle des instances unhealthy
Hypothèse initiale : Séparer signal de santé, grace period, état du service d’orchestration, modèle VMSS courant et contrat de persistance avant de modifier Replace, Reimage ou Restart.
Preuves utilisées : Séparer signal de santé, grace period, état du service d’orchestration, modèle VMSS courant et contrat de persistance avant de modifier Replace, Reimage ou Restart.
Contrôles effectués : Figer la chronologie des réparations et la capacité utile | Lire automaticRepairsPolicy et l’état du service d’orchestration | Rejouer le contrat de santé sur instances saines et affectées | Créer un canari depuis le modèle courant avant la reprise
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer la chronologie des réparations et la capacité utile | Lire automaticRepairsPolicy et l’état du service d’orchestration | Rejouer le contrat de santé sur instances saines et affectées | Créer un canari depuis le modèle courant avant la reprise. 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 image nouvellement poussée dans ACR n’est pas visible depuis toutes les régions de déploiement
Contexte : Séparer géoréplication asynchrone, tags mutables, routage du endpoint global, identité runtime et joignabilité des endpoints de données avant de relancer un déploiement multirégion.
Preuves à confirmer : Séparer géoréplication asynchrone, tags mutables, routage du endpoint global, identité runtime et joignabilité des endpoints de données avant de relancer un déploiement multirégion.
Contrôles immédiats : Figer le digest du build et l’heure de fin du push | Lister l’état des réplicas et consulter Resource Health | Tirer le digest attendu depuis chaque région cible | Corréler les événements ACR par région, identité et résultat
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer le digest du build et l’heure de fin du push | Lister l’état des réplicas et consulter Resource Health | Tirer le digest attendu depuis chaque région cible | Corréler les événements ACR par région, identité et résultat. 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 image nouvellement poussée dans ACR n’est pas visible depuis toutes les régions de déploiement
Hypothèse initiale : Séparer géoréplication asynchrone, tags mutables, routage du endpoint global, identité runtime et joignabilité des endpoints de données avant de relancer un déploiement multirégion.
Preuves utilisées : Séparer géoréplication asynchrone, tags mutables, routage du endpoint global, identité runtime et joignabilité des endpoints de données avant de relancer un déploiement multirégion.
Contrôles effectués : Figer le digest du build et l’heure de fin du push | Lister l’état des réplicas et consulter Resource Health | Tirer le digest attendu depuis chaque région cible | Corréler les événements ACR par région, identité et résultat
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer le digest du build et l’heure de fin du push | Lister l’état des réplicas et consulter Resource Health | Tirer le digest attendu depuis chaque région cible | Corréler les événements ACR par région, identité et résultat. 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 flux service à service AKS est bloqué après un changement de NetworkPolicy
Contexte : Séparer egress source, ingress destination, sélecteurs déployés, endpoints du Service et verdicts Cilium observés avant d’ajouter une règle allow-all ou de supprimer le default-deny.
Preuves à confirmer : Séparer egress source, ingress destination, sélecteurs déployés, endpoints du Service et verdicts Cilium observés avant d’ajouter une règle allow-all ou de supprimer le default-deny.
Contrôles immédiats : Figer source, destination, port et fenêtre UTC | Lire le data plane AKS et chaque type de policy | Comparer les sélecteurs aux labels de pods et namespaces déployés | Exécuter des canaris positifs et négatifs avant promotion
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer source, destination, port et fenêtre UTC | Lire le data plane AKS et chaque type de policy | Comparer les sélecteurs aux labels de pods et namespaces déployés | Exécuter des canaris positifs et négatifs avant promotion. 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 flux service à service AKS est bloqué après un changement de NetworkPolicy
Hypothèse initiale : Séparer egress source, ingress destination, sélecteurs déployés, endpoints du Service et verdicts Cilium observés avant d’ajouter une règle allow-all ou de supprimer le default-deny.
Preuves utilisées : Séparer egress source, ingress destination, sélecteurs déployés, endpoints du Service et verdicts Cilium observés avant d’ajouter une règle allow-all ou de supprimer le default-deny.
Contrôles effectués : Figer source, destination, port et fenêtre UTC | Lire le data plane AKS et chaque type de policy | Comparer les sélecteurs aux labels de pods et namespaces déployés | Exécuter des canaris positifs et négatifs avant promotion
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer source, destination, port et fenêtre UTC | Lire le data plane AKS et chaque type de policy | Comparer les sélecteurs aux labels de pods et namespaces déployés | Exécuter des canaris positifs et négatifs avant promotion. 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] Le tail sampling OpenTelemetry réduit le volume mais les traces d’incident deviennent incomplètes ou disparaissent
Contexte : Séparer affinité des traces, dimensionnement de la fenêtre, mémoire des traces en attente, spans tardifs, règles et preuves d’export avant d’élargir le déploiement.
Preuves à confirmer : Séparer affinité des traces, dimensionnement de la fenêtre, mémoire des traces en attente, spans tardifs, règles et preuves d’export avant d’élargir le déploiement.
Contrôles immédiats : Figer les digests des configurations Collector actuelle et candidate | Prouver que tous les spans d’une trace atteignent le même sampling shard | Rejouer les canaris d’erreur, de latence et de span tardif | Corréler les décisions du Collector avec les opérations complètes dans Azure Monitor
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer les digests des configurations Collector actuelle et candidate | Prouver que tous les spans d’une trace atteignent le même sampling shard | Rejouer les canaris d’erreur, de latence et de span tardif | Corréler les décisions du Collector avec les opérations complètes dans Azure Monitor. 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é : Le tail sampling OpenTelemetry réduit le volume mais les traces d’incident deviennent incomplètes ou disparaissent
Hypothèse initiale : Séparer affinité des traces, dimensionnement de la fenêtre, mémoire des traces en attente, spans tardifs, règles et preuves d’export avant d’élargir le déploiement.
Preuves utilisées : Séparer affinité des traces, dimensionnement de la fenêtre, mémoire des traces en attente, spans tardifs, règles et preuves d’export avant d’élargir le déploiement.
Contrôles effectués : Figer les digests des configurations Collector actuelle et candidate | Prouver que tous les spans d’une trace atteignent le même sampling shard | Rejouer les canaris d’erreur, de latence et de span tardif | Corréler les décisions du Collector avec les opérations complètes dans Azure Monitor
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer les digests des configurations Collector actuelle et candidate | Prouver que tous les spans d’une trace atteignent le même sampling shard | Rejouer les canaris d’erreur, de latence et de span tardif | Corréler les décisions du Collector avec les opérations complètes dans Azure Monitor. 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] Key Vault retourne 403 après une bascule vers Azure RBAC
Contexte : Séparer identités runtime oubliées, correspondance des rôles data plane, scope et propagation des pannes réseau avant d’attribuer un rôle large ou de revenir au modèle précédent.
Preuves à confirmer : Séparer identités runtime oubliées, correspondance des rôles data plane, scope et propagation des pannes réseau avant d’attribuer un rôle large ou de revenir au modèle précédent.
Contrôles immédiats : Confirmer le modèle d’autorisation actif du coffre | Résoudre l’object ID du principal runtime en échec | Comparer les opérations requises aux rôles data plane directs et hérités | Corréler les 403 avec les logs AuditEvent Key Vault
Action proposée : Exécuter les premiers contrôles dans l’ordre : Confirmer le modèle d’autorisation actif du coffre | Résoudre l’object ID du principal runtime en échec | Comparer les opérations requises aux rôles data plane directs et hérités | Corréler les 403 avec les logs AuditEvent 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é : Key Vault retourne 403 après une bascule vers Azure RBAC
Hypothèse initiale : Séparer identités runtime oubliées, correspondance des rôles data plane, scope et propagation des pannes réseau avant d’attribuer un rôle large ou de revenir au modèle précédent.
Preuves utilisées : Séparer identités runtime oubliées, correspondance des rôles data plane, scope et propagation des pannes réseau avant d’attribuer un rôle large ou de revenir au modèle précédent.
Contrôles effectués : Confirmer le modèle d’autorisation actif du coffre | Résoudre l’object ID du principal runtime en échec | Comparer les opérations requises aux rôles data plane directs et hérités | Corréler les 403 avec les logs AuditEvent Key Vault
Décision / action : Exécuter les premiers contrôles dans l’ordre : Confirmer le modèle d’autorisation actif du coffre | Résoudre l’object ID du principal runtime en échec | Comparer les opérations requises aux rôles data plane directs et hérités | Corréler les 403 avec les logs AuditEvent 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] Des flux Virtual WAN sont coupés ou deviennent asymétriques après activation de Routing Intent
Contexte : Séparer portée des policies, routes effectives, prefixes privés, propagation de la route par défaut, next hop de sécurité, SNAT et chemins retour avant d’élargir le déploiement ou de supprimer Routing Intent.
Preuves à confirmer : Séparer portée des policies, routes effectives, prefixes privés, propagation de la route par défaut, next hop de sécurité, SNAT et chemins retour avant d’élargir le déploiement ou de supprimer Routing Intent.
Contrôles immédiats : Figer les anciennes associations et propagations de routes | Vérifier chaque prefixe du contrat sur le next hop de sécurité | Sonder les chemins aller et retour dans chaque hub concerné | Corréler les canaris avec les allow et deny Firewall
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer les anciennes associations et propagations de routes | Vérifier chaque prefixe du contrat sur le next hop de sécurité | Sonder les chemins aller et retour dans chaque hub concerné | Corréler les canaris avec les allow et deny Firewall. 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é : Des flux Virtual WAN sont coupés ou deviennent asymétriques après activation de Routing Intent
Hypothèse initiale : Séparer portée des policies, routes effectives, prefixes privés, propagation de la route par défaut, next hop de sécurité, SNAT et chemins retour avant d’élargir le déploiement ou de supprimer Routing Intent.
Preuves utilisées : Séparer portée des policies, routes effectives, prefixes privés, propagation de la route par défaut, next hop de sécurité, SNAT et chemins retour avant d’élargir le déploiement ou de supprimer Routing Intent.
Contrôles effectués : Figer les anciennes associations et propagations de routes | Vérifier chaque prefixe du contrat sur le next hop de sécurité | Sonder les chemins aller et retour dans chaque hub concerné | Corréler les canaris avec les allow et deny Firewall
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer les anciennes associations et propagations de routes | Vérifier chaque prefixe du contrat sur le next hop de sécurité | Sonder les chemins aller et retour dans chaque hub concerné | Corréler les canaris avec les allow et deny Firewall. 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] Des pods AKS rencontrent des timeouts DNS ou des réponses SERVFAIL intermittentes
Contexte : Séparer comportement du resolver du pod, amplification des requêtes, service DNS Kubernetes, endpoints CoreDNS, policy réseau, forwarding upstream et chemins propres aux nœuds avant de redémarrer CoreDNS.
Preuves à confirmer : Séparer comportement du resolver du pod, amplification des requêtes, service DNS Kubernetes, endpoints CoreDNS, policy réseau, forwarding upstream et chemins propres aux nœuds avant de redémarrer CoreDNS.
Contrôles immédiats : Figer les noms exacts, erreurs et cohortes de pods/nœuds touchées | Comparer des résolutions répétées entre nœuds et namespaces | Inspecter service kube-dns, EndpointSlices et pods CoreDNS | Tester séparément noms du cluster et chaque suffixe upstream
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer les noms exacts, erreurs et cohortes de pods/nœuds touchées | Comparer des résolutions répétées entre nœuds et namespaces | Inspecter service kube-dns, EndpointSlices et pods CoreDNS | Tester séparément noms du cluster et chaque suffixe upstream. 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é : Des pods AKS rencontrent des timeouts DNS ou des réponses SERVFAIL intermittentes
Hypothèse initiale : Séparer comportement du resolver du pod, amplification des requêtes, service DNS Kubernetes, endpoints CoreDNS, policy réseau, forwarding upstream et chemins propres aux nœuds avant de redémarrer CoreDNS.
Preuves utilisées : Séparer comportement du resolver du pod, amplification des requêtes, service DNS Kubernetes, endpoints CoreDNS, policy réseau, forwarding upstream et chemins propres aux nœuds avant de redémarrer CoreDNS.
Contrôles effectués : Figer les noms exacts, erreurs et cohortes de pods/nœuds touchées | Comparer des résolutions répétées entre nœuds et namespaces | Inspecter service kube-dns, EndpointSlices et pods CoreDNS | Tester séparément noms du cluster et chaque suffixe upstream
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer les noms exacts, erreurs et cohortes de pods/nœuds touchées | Comparer des résolutions répétées entre nœuds et namespaces | Inspecter service kube-dns, EndpointSlices et pods CoreDNS | Tester séparément noms du cluster et chaque suffixe upstream. 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 Firewall IDPS bloque un flux légitime après le passage d’une signature en blocage
Contexte : Séparer preuve de signature, direction du trafic, classification des plages privées, inspection TLS et résultat applicatif avant de désactiver IDPS ou d’ajouter un bypass large.
Preuves à confirmer : Séparer preuve de signature, direction du trafic, classification des plages privées, inspection TLS et résultat applicatif avant de désactiver IDPS ou d’ajouter un bypass large.
Contrôles immédiats : Figer la surcharge de signature et le five-tuple touché | Interroger AZFWIdpsSignature par source, destination et action | Rejouer un canari malveillant et un canari légitime | Revenir uniquement à Alert pour la signature si le flux légitime régresse
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer la surcharge de signature et le five-tuple touché | Interroger AZFWIdpsSignature par source, destination et action | Rejouer un canari malveillant et un canari légitime | Revenir uniquement à Alert pour la signature si le flux légitime régresse. 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 Firewall IDPS bloque un flux légitime après le passage d’une signature en blocage
Hypothèse initiale : Séparer preuve de signature, direction du trafic, classification des plages privées, inspection TLS et résultat applicatif avant de désactiver IDPS ou d’ajouter un bypass large.
Preuves utilisées : Séparer preuve de signature, direction du trafic, classification des plages privées, inspection TLS et résultat applicatif avant de désactiver IDPS ou d’ajouter un bypass large.
Contrôles effectués : Figer la surcharge de signature et le five-tuple touché | Interroger AZFWIdpsSignature par source, destination et action | Rejouer un canari malveillant et un canari légitime | Revenir uniquement à Alert pour la signature si le flux légitime régresse
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer la surcharge de signature et le five-tuple touché | Interroger AZFWIdpsSignature par source, destination et action | Rejouer un canari malveillant et un canari légitime | Revenir uniquement à Alert pour la signature si le flux légitime régresse. 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 job Azure Automation risque d’exécuter une version différente du commit approuvé
Contexte : Relier commit source, job de synchronisation, hashes brouillon et publié, test sans effet et marqueur d’exécution avant toute relance ou extension du scope production.
Preuves à confirmer : Relier commit source, job de synchronisation, hashes brouillon et publié, test sans effet et marqueur d’exécution avant toute relance ou extension du scope production.
Contrôles immédiats : Figer commit approuvé, hash du script et compte cible | Lire le dernier job de synchronisation et ses streams avant relance | Exporter et hasher séparément brouillon et version publiée | Exécuter Plan puis un canari réversible avant le scope complet
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer commit approuvé, hash du script et compte cible | Lire le dernier job de synchronisation et ses streams avant relance | Exporter et hasher séparément brouillon et version publiée | Exécuter Plan puis un canari réversible avant le scope complet. 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 job Azure Automation risque d’exécuter une version différente du commit approuvé
Hypothèse initiale : Relier commit source, job de synchronisation, hashes brouillon et publié, test sans effet et marqueur d’exécution avant toute relance ou extension du scope production.
Preuves utilisées : Relier commit source, job de synchronisation, hashes brouillon et publié, test sans effet et marqueur d’exécution avant toute relance ou extension du scope production.
Contrôles effectués : Figer commit approuvé, hash du script et compte cible | Lire le dernier job de synchronisation et ses streams avant relance | Exporter et hasher séparément brouillon et version publiée | Exécuter Plan puis un canari réversible avant le scope complet
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer commit approuvé, hash du script et compte cible | Lire le dernier job de synchronisation et ses streams avant relance | Exporter et hasher séparément brouillon et version publiée | Exécuter Plan puis un canari réversible avant le scope complet. 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 alerte de logs Azure Monitor crée des centaines d’instances évaluées séparément
Contexte : Séparer cohortes réellement touchées, cardinalité des dimensions, cycle de vie des alertes et routage des notifications avant de relever les limites, couper l’action group ou modifier la règle KQL.
Preuves à confirmer : Séparer cohortes réellement touchées, cardinalité des dimensions, cycle de vie des alertes et routage des notifications avant de relever les limites, couper l’action group ou modifier la règle KQL.
Contrôles immédiats : Exporter la scheduled query rule et figer une fenêtre UTC | Compter lignes, valeurs distinctes et combinaisons de dimensions | Comparer combinaisons KQL, instances actives et notifications livrées | Canaryer les dimensions stables sur un cycle complet de déclenchement et résolution
Action proposée : Exécuter les premiers contrôles dans l’ordre : Exporter la scheduled query rule et figer une fenêtre UTC | Compter lignes, valeurs distinctes et combinaisons de dimensions | Comparer combinaisons KQL, instances actives et notifications livrées | Canaryer les dimensions stables sur un cycle complet de déclenchement et résolution. 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 alerte de logs Azure Monitor crée des centaines d’instances évaluées séparément
Hypothèse initiale : Séparer cohortes réellement touchées, cardinalité des dimensions, cycle de vie des alertes et routage des notifications avant de relever les limites, couper l’action group ou modifier la règle KQL.
Preuves utilisées : Séparer cohortes réellement touchées, cardinalité des dimensions, cycle de vie des alertes et routage des notifications avant de relever les limites, couper l’action group ou modifier la règle KQL.
Contrôles effectués : Exporter la scheduled query rule et figer une fenêtre UTC | Compter lignes, valeurs distinctes et combinaisons de dimensions | Comparer combinaisons KQL, instances actives et notifications livrées | Canaryer les dimensions stables sur un cycle complet de déclenchement et résolution
Décision / action : Exécuter les premiers contrôles dans l’ordre : Exporter la scheduled query rule et figer une fenêtre UTC | Compter lignes, valeurs distinctes et combinaisons de dimensions | Comparer combinaisons KQL, instances actives et notifications livrées | Canaryer les dimensions stables sur un cycle complet de déclenchement et résolution. 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 AI gateway retourne 429 après un changement de policy de limite de tokens
Contexte : Séparer scope de policy APIM, isolation des compteurs, comptage par gateway, estimation des tokens, throttling backend et retries clients avant d’augmenter le budget.
Preuves à confirmer : Séparer scope de policy APIM, isolation des compteurs, comptage par gateway, estimation des tokens, throttling backend et retries clients avant d’augmenter le budget.
Contrôles immédiats : Figer une requête refusée avec gateway, région et Retry-After | Prouver si APIM ou le backend modèle a produit le 429 | Vérifier la policy effective et une clé de compteur non vide | Canaryer la correction sans réinitialiser les compteurs de production
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer une requête refusée avec gateway, région et Retry-After | Prouver si APIM ou le backend modèle a produit le 429 | Vérifier la policy effective et une clé de compteur non vide | Canaryer la correction sans réinitialiser les compteurs de production. 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 AI gateway retourne 429 après un changement de policy de limite de tokens
Hypothèse initiale : Séparer scope de policy APIM, isolation des compteurs, comptage par gateway, estimation des tokens, throttling backend et retries clients avant d’augmenter le budget.
Preuves utilisées : Séparer scope de policy APIM, isolation des compteurs, comptage par gateway, estimation des tokens, throttling backend et retries clients avant d’augmenter le budget.
Contrôles effectués : Figer une requête refusée avec gateway, région et Retry-After | Prouver si APIM ou le backend modèle a produit le 429 | Vérifier la policy effective et une clé de compteur non vide | Canaryer la correction sans réinitialiser les compteurs de production
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer une requête refusée avec gateway, région et Retry-After | Prouver si APIM ou le backend modèle a produit le 429 | Vérifier la policy effective et une clé de compteur non vide | Canaryer la correction sans réinitialiser les compteurs de production. 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 chemin applicatif Azure échoue par intermittence alors que les tests manuels restent sains
Contexte : Utiliser Connection Monitor pour conserver perte et latence par source, puis corréler un intervalle en échec avec DNS, routes effectives, décisions de sécurité, preuves firewall et santé du service avant de modifier NSG ou UDR.
Preuves à confirmer : Utiliser Connection Monitor pour conserver perte et latence par source, puis corréler un intervalle en échec avec DNS, routes effectives, décisions de sécurité, preuves firewall et santé du service avant de modifier NSG ou UDR.
Contrôles immédiats : Figer source, FQDN, port et fenêtre UTC exacts | Comparer taux d’échec et RTT par source | Lancer Connection Troubleshoot pendant l’intervalle défaillant | Canaryer une correction bornée avec un contrôle de refus
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer source, FQDN, port et fenêtre UTC exacts | Comparer taux d’échec et RTT par source | Lancer Connection Troubleshoot pendant l’intervalle défaillant | Canaryer une correction bornée avec un contrôle de refus. 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 chemin applicatif Azure échoue par intermittence alors que les tests manuels restent sains
Hypothèse initiale : Utiliser Connection Monitor pour conserver perte et latence par source, puis corréler un intervalle en échec avec DNS, routes effectives, décisions de sécurité, preuves firewall et santé du service avant de modifier NSG ou UDR.
Preuves utilisées : Utiliser Connection Monitor pour conserver perte et latence par source, puis corréler un intervalle en échec avec DNS, routes effectives, décisions de sécurité, preuves firewall et santé du service avant de modifier NSG ou UDR.
Contrôles effectués : Figer source, FQDN, port et fenêtre UTC exacts | Comparer taux d’échec et RTT par source | Lancer Connection Troubleshoot pendant l’intervalle défaillant | Canaryer une correction bornée avec un contrôle de refus
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer source, FQDN, port et fenêtre UTC exacts | Comparer taux d’échec et RTT par source | Lancer Connection Troubleshoot pendant l’intervalle défaillant | Canaryer une correction bornée avec un contrôle de refus. 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 agent IA propose une action de production non demandée après avoir lu la sortie d’un outil MCP
Contexte : Séparer transport authentifié et confiance au niveau des champs, conserver la provenance du résultat, appliquer l’autorisation d’écriture hors du modèle et rejouer des résultats adversariaux avant de rouvrir les actions de production.
Preuves à confirmer : Séparer transport authentifié et confiance au niveau des champs, conserver la provenance du résultat, appliquer l’autorisation d’écriture hors du modèle et rejouer des résultats adversariaux avant de rouvrir les actions de production.
Contrôles immédiats : Figer intention utilisateur, résultat brut et prochain appel proposé | Identifier le champ non fiable qui a influencé l’action | Vérifier approbation et arguments dans une porte de policy externe | Rejouer les résultats hostiles avec écritures coupées avant un canari borné
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer intention utilisateur, résultat brut et prochain appel proposé | Identifier le champ non fiable qui a influencé l’action | Vérifier approbation et arguments dans une porte de policy externe | Rejouer les résultats hostiles avec écritures coupées avant un canari borné. 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 agent IA propose une action de production non demandée après avoir lu la sortie d’un outil MCP
Hypothèse initiale : Séparer transport authentifié et confiance au niveau des champs, conserver la provenance du résultat, appliquer l’autorisation d’écriture hors du modèle et rejouer des résultats adversariaux avant de rouvrir les actions de production.
Preuves utilisées : Séparer transport authentifié et confiance au niveau des champs, conserver la provenance du résultat, appliquer l’autorisation d’écriture hors du modèle et rejouer des résultats adversariaux avant de rouvrir les actions de production.
Contrôles effectués : Figer intention utilisateur, résultat brut et prochain appel proposé | Identifier le champ non fiable qui a influencé l’action | Vérifier approbation et arguments dans une porte de policy externe | Rejouer les résultats hostiles avec écritures coupées avant un canari borné
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer intention utilisateur, résultat brut et prochain appel proposé | Identifier le champ non fiable qui a influencé l’action | Vérifier approbation et arguments dans une porte de policy externe | Rejouer les résultats hostiles avec écritures coupées avant un canari borné. 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 agent reste disponible grâce au fallback de modèle mais change ses décisions d’outils ou ses refus
Contexte : Séparer disponibilité de l’endpoint et compatibilité des schémas de réponse, outils, sources, refus, approbations, état et traces avant d’activer le routage multi-modèle automatique.
Preuves à confirmer : Séparer disponibilité de l’endpoint et compatibilité des schémas de réponse, outils, sources, refus, approbations, état et traces avant d’activer le routage multi-modèle automatique.
Contrôles immédiats : Figer les deux tentatives sous un même identifiant de run logique | Valider sortie structurée et arguments d’outils normalisés | Réconcilier tout résultat principal inconnu avant fallback | Canaryer de nouvelles sessions en lecture seule avec des traces par route
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer les deux tentatives sous un même identifiant de run logique | Valider sortie structurée et arguments d’outils normalisés | Réconcilier tout résultat principal inconnu avant fallback | Canaryer de nouvelles sessions en lecture seule avec des traces par route. 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 agent reste disponible grâce au fallback de modèle mais change ses décisions d’outils ou ses refus
Hypothèse initiale : Séparer disponibilité de l’endpoint et compatibilité des schémas de réponse, outils, sources, refus, approbations, état et traces avant d’activer le routage multi-modèle automatique.
Preuves utilisées : Séparer disponibilité de l’endpoint et compatibilité des schémas de réponse, outils, sources, refus, approbations, état et traces avant d’activer le routage multi-modèle automatique.
Contrôles effectués : Figer les deux tentatives sous un même identifiant de run logique | Valider sortie structurée et arguments d’outils normalisés | Réconcilier tout résultat principal inconnu avant fallback | Canaryer de nouvelles sessions en lecture seule avec des traces par route
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer les deux tentatives sous un même identifiant de run logique | Valider sortie structurée et arguments d’outils normalisés | Réconcilier tout résultat principal inconnu avant fallback | Canaryer de nouvelles sessions en lecture seule avec des traces par route. 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 Horizontal Pod Autoscaler AKS monte et descend en boucle
Contexte : Séparer métriques bruitées ou manquantes, requests mal calibrées, warm-up des pods, contrôleurs concurrents et capacité nœud avant de relever les bornes de replicas.
Preuves à confirmer : Séparer métriques bruitées ou manquantes, requests mal calibrées, warm-up des pods, contrôleurs concurrents et capacité nœud avant de relever les bornes de replicas.
Contrôles immédiats : Figer deux cycles complets de scaling | Comparer le statut HPA avec l’API de métriques | Mesurer requests, readiness et capacité aval par replica | Canaryer un seul changement de comportement avec rollback explicite
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer deux cycles complets de scaling | Comparer le statut HPA avec l’API de métriques | Mesurer requests, readiness et capacité aval par replica | Canaryer un seul changement de comportement avec rollback explicite. 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 Horizontal Pod Autoscaler AKS monte et descend en boucle
Hypothèse initiale : Séparer métriques bruitées ou manquantes, requests mal calibrées, warm-up des pods, contrôleurs concurrents et capacité nœud avant de relever les bornes de replicas.
Preuves utilisées : Séparer métriques bruitées ou manquantes, requests mal calibrées, warm-up des pods, contrôleurs concurrents et capacité nœud avant de relever les bornes de replicas.
Contrôles effectués : Figer deux cycles complets de scaling | Comparer le statut HPA avec l’API de métriques | Mesurer requests, readiness et capacité aval par replica | Canaryer un seul changement de comportement avec rollback explicite
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer deux cycles complets de scaling | Comparer le statut HPA avec l’API de métriques | Mesurer requests, readiness et capacité aval par replica | Canaryer un seul changement de comportement avec rollback explicite. 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 déploiement Azure échoue parce qu’une ressource ou un scope hérité est verrouillé
Contexte : Séparer management locks, RBAC, Policy et deny assignments, identifier l’opération destructive exacte, puis borner toute fenêtre de déverrouillage avant relance ou rollback.
Preuves à confirmer : Séparer management locks, RBAC, Policy et deny assignments, identifier l’opération destructive exacte, puis borner toute fenêtre de déverrouillage avant relance ou rollback.
Contrôles immédiats : Figer l’opération en échec, la ressource cible et le correlation ID | Reconstruire les locks CanNotDelete et ReadOnly hérités | Confirmer que le plan exige réellement un delete | Recréer et vérifier le verrou avant de clore le changement
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer l’opération en échec, la ressource cible et le correlation ID | Reconstruire les locks CanNotDelete et ReadOnly hérités | Confirmer que le plan exige réellement un delete | Recréer et vérifier le verrou avant de clore le changement. 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 déploiement Azure échoue parce qu’une ressource ou un scope hérité est verrouillé
Hypothèse initiale : Séparer management locks, RBAC, Policy et deny assignments, identifier l’opération destructive exacte, puis borner toute fenêtre de déverrouillage avant relance ou rollback.
Preuves utilisées : Séparer management locks, RBAC, Policy et deny assignments, identifier l’opération destructive exacte, puis borner toute fenêtre de déverrouillage avant relance ou rollback.
Contrôles effectués : Figer l’opération en échec, la ressource cible et le correlation ID | Reconstruire les locks CanNotDelete et ReadOnly hérités | Confirmer que le plan exige réellement un delete | Recréer et vérifier le verrou avant de clore le changement
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer l’opération en échec, la ressource cible et le correlation ID | Reconstruire les locks CanNotDelete et ReadOnly hérités | Confirmer que le plan exige réellement un delete | Recréer et vérifier le verrou avant de clore le changement. 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] Des pods AKS subissent des timeouts intermittents vers des dépendances publiques
Contexte : Séparer DNS, dépendance distante, politique réseau, pression de connexions du nœud et équipement de sortie Azure effectif avant d’ajouter de la capacité SNAT ou de modifier la sortie du cluster.
Preuves à confirmer : Séparer DNS, dépendance distante, politique réseau, pression de connexions du nœud et équipement de sortie Azure effectif avant d’ajouter de la capacité SNAT ou de modifier la sortie du cluster.
Contrôles immédiats : Capturer le pod, le nœud et le tuple de destination en échec | Confirmer networkProfile.outboundType et l’IP source vue en aval | Corréler les métriques SNAT par nœud avec le churn de connexions | Canaryer la réutilisation des connexions ou la capacité egress avant généralisation
Action proposée : Exécuter les premiers contrôles dans l’ordre : Capturer le pod, le nœud et le tuple de destination en échec | Confirmer networkProfile.outboundType et l’IP source vue en aval | Corréler les métriques SNAT par nœud avec le churn de connexions | Canaryer la réutilisation des connexions ou la capacité egress avant généralisation. 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é : Des pods AKS subissent des timeouts intermittents vers des dépendances publiques
Hypothèse initiale : Séparer DNS, dépendance distante, politique réseau, pression de connexions du nœud et équipement de sortie Azure effectif avant d’ajouter de la capacité SNAT ou de modifier la sortie du cluster.
Preuves utilisées : Séparer DNS, dépendance distante, politique réseau, pression de connexions du nœud et équipement de sortie Azure effectif avant d’ajouter de la capacité SNAT ou de modifier la sortie du cluster.
Contrôles effectués : Capturer le pod, le nœud et le tuple de destination en échec | Confirmer networkProfile.outboundType et l’IP source vue en aval | Corréler les métriques SNAT par nœud avec le churn de connexions | Canaryer la réutilisation des connexions ou la capacité egress avant généralisation
Décision / action : Exécuter les premiers contrôles dans l’ordre : Capturer le pod, le nœud et le tuple de destination en échec | Confirmer networkProfile.outboundType et l’IP source vue en aval | Corréler les métriques SNAT par nœud avec le churn de connexions | Canaryer la réutilisation des connexions ou la capacité egress avant généralisation. 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 règle Microsoft Sentinel manque une cible ou automatise une réponse depuis une watchlist périmée
Contexte : Séparer fraîcheur de la source, complétude du snapshot, sémantique de suppression des mises à jour en masse, normalisation du SearchKey et comportement de jointure KQL avant de laisser une watchlist piloter incidents ou playbooks.
Preuves à confirmer : Séparer fraîcheur de la source, complétude du snapshot, sémantique de suppression des mises à jour en masse, normalisation du SearchKey et comportement de jointure KQL avant de laisser une watchlist piloter incidents ou playbooks.
Contrôles immédiats : Prouver alias et snapshot source indépendamment de TimeGenerated | Comparer clés ajoutées, modifiées et supprimées avec la version active | Refuser les SearchKey vides, dupliqués ou expirés | Évaluer la règle en shadow avant d’activer le playbook
Action proposée : Exécuter les premiers contrôles dans l’ordre : Prouver alias et snapshot source indépendamment de TimeGenerated | Comparer clés ajoutées, modifiées et supprimées avec la version active | Refuser les SearchKey vides, dupliqués ou expirés | Évaluer la règle en shadow avant d’activer le playbook. 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 règle Microsoft Sentinel manque une cible ou automatise une réponse depuis une watchlist périmée
Hypothèse initiale : Séparer fraîcheur de la source, complétude du snapshot, sémantique de suppression des mises à jour en masse, normalisation du SearchKey et comportement de jointure KQL avant de laisser une watchlist piloter incidents ou playbooks.
Preuves utilisées : Séparer fraîcheur de la source, complétude du snapshot, sémantique de suppression des mises à jour en masse, normalisation du SearchKey et comportement de jointure KQL avant de laisser une watchlist piloter incidents ou playbooks.
Contrôles effectués : Prouver alias et snapshot source indépendamment de TimeGenerated | Comparer clés ajoutées, modifiées et supprimées avec la version active | Refuser les SearchKey vides, dupliqués ou expirés | Évaluer la règle en shadow avant d’activer le playbook
Décision / action : Exécuter les premiers contrôles dans l’ordre : Prouver alias et snapshot source indépendamment de TimeGenerated | Comparer clés ajoutées, modifiées et supprimées avec la version active | Refuser les SearchKey vides, dupliqués ou expirés | Évaluer la règle en shadow avant d’activer le playbook. 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 agent Azure DevOps auto-hébergé montre des signes de compromission mais peut encore recevoir des jobs de production
Contexte : Arrêter l’ordonnancement sans effacer les preuves, reconstruire les runs touchés, cartographier les identités exposées et valider un remplacement sain avant de rouvrir le pool.
Preuves à confirmer : Arrêter l’ordonnancement sans effacer les preuves, reconstruire les runs touchés, cartographier les identités exposées et valider un remplacement sain avant de rouvrir le pool.
Contrôles immédiats : Isoler l’agent et suspendre les points d’entrée de production | Figer run IDs, commits, diagnostics agent et événements d’audit | Cartographier identifiants et cibles aval utilisés dans la fenêtre | Canaryer un remplacement sain sans ressource protégée
Action proposée : Exécuter les premiers contrôles dans l’ordre : Isoler l’agent et suspendre les points d’entrée de production | Figer run IDs, commits, diagnostics agent et événements d’audit | Cartographier identifiants et cibles aval utilisés dans la fenêtre | Canaryer un remplacement sain sans ressource protégée. 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 agent Azure DevOps auto-hébergé montre des signes de compromission mais peut encore recevoir des jobs de production
Hypothèse initiale : Arrêter l’ordonnancement sans effacer les preuves, reconstruire les runs touchés, cartographier les identités exposées et valider un remplacement sain avant de rouvrir le pool.
Preuves utilisées : Arrêter l’ordonnancement sans effacer les preuves, reconstruire les runs touchés, cartographier les identités exposées et valider un remplacement sain avant de rouvrir le pool.
Contrôles effectués : Isoler l’agent et suspendre les points d’entrée de production | Figer run IDs, commits, diagnostics agent et événements d’audit | Cartographier identifiants et cibles aval utilisés dans la fenêtre | Canaryer un remplacement sain sans ressource protégée
Décision / action : Exécuter les premiers contrôles dans l’ordre : Isoler l’agent et suspendre les points d’entrée de production | Figer run IDs, commits, diagnostics agent et événements d’audit | Cartographier identifiants et cibles aval utilisés dans la fenêtre | Canaryer un remplacement sain sans ressource protégée. 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 plan App Service reste en ligne mais son scaling échoue sur un subnet VNet Integration
Contexte : Séparer épuisement d’adresses, libération différée, délégation et panne du chemin sortant ; calculer le chevauchement des workers avant de relancer le scaling ou migrer l’intégration.
Preuves à confirmer : Séparer épuisement d’adresses, libération différée, délégation et panne du chemin sortant ; calculer le chevauchement des workers avant de relancer le scaling ou migrer l’intégration.
Contrôles immédiats : Figer l’opération en échec et le nombre d’instances | Inventorier chaque application et plan joints au subnet | Calculer les adresses utilisables et le chevauchement transitoire | Canaryer un subnet délégué plus grand avec rollback explicite
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer l’opération en échec et le nombre d’instances | Inventorier chaque application et plan joints au subnet | Calculer les adresses utilisables et le chevauchement transitoire | Canaryer un subnet délégué plus grand avec rollback explicite. 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 plan App Service reste en ligne mais son scaling échoue sur un subnet VNet Integration
Hypothèse initiale : Séparer épuisement d’adresses, libération différée, délégation et panne du chemin sortant ; calculer le chevauchement des workers avant de relancer le scaling ou migrer l’intégration.
Preuves utilisées : Séparer épuisement d’adresses, libération différée, délégation et panne du chemin sortant ; calculer le chevauchement des workers avant de relancer le scaling ou migrer l’intégration.
Contrôles effectués : Figer l’opération en échec et le nombre d’instances | Inventorier chaque application et plan joints au subnet | Calculer les adresses utilisables et le chevauchement transitoire | Canaryer un subnet délégué plus grand avec rollback explicite
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer l’opération en échec et le nombre d’instances | Inventorier chaque application et plan joints au subnet | Calculer les adresses utilisables et le chevauchement transitoire | Canaryer un subnet délégué plus grand avec rollback explicite. 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 semble appliquer un comportement de policy différent après un déploiement
Contexte : Séparer état du déploiement ARM, associations gateway, listener et path rule, priorité réellement déployée et variations des requêtes avant d’attendre ou de restaurer toute la policy.
Preuves à confirmer : Séparer état du déploiement ARM, associations gateway, listener et path rule, priorité réellement déployée et variations des requêtes avant d’attendre ou de restaurer toute la policy.
Contrôles immédiats : Figer une requête acceptée et une requête bloquée | Lire les provisioning states de la policy et de la gateway | Inventorier les resource IDs de policy sur chaque scope d’association | Rejouer un canari autorisé et un canari refusé après correction ou rollback
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer une requête acceptée et une requête bloquée | Lire les provisioning states de la policy et de la gateway | Inventorier les resource IDs de policy sur chaque scope d’association | Rejouer un canari autorisé et un canari refusé après correction ou rollback. 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 WAF semble appliquer un comportement de policy différent après un déploiement
Hypothèse initiale : Séparer état du déploiement ARM, associations gateway, listener et path rule, priorité réellement déployée et variations des requêtes avant d’attendre ou de restaurer toute la policy.
Preuves utilisées : Séparer état du déploiement ARM, associations gateway, listener et path rule, priorité réellement déployée et variations des requêtes avant d’attendre ou de restaurer toute la policy.
Contrôles effectués : Figer une requête acceptée et une requête bloquée | Lire les provisioning states de la policy et de la gateway | Inventorier les resource IDs de policy sur chaque scope d’association | Rejouer un canari autorisé et un canari refusé après correction ou rollback
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer une requête acceptée et une requête bloquée | Lire les provisioning states de la policy et de la gateway | Inventorier les resource IDs de policy sur chaque scope d’association | Rejouer un canari autorisé et un canari refusé après correction ou rollback. 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 déploiement Azure auparavant autorisé est refusé après l’expiration de son exemption Policy
Contexte : Relier le premier refus à expiresOn, à l’assignment exacte, aux références d’initiative et à l’état courant de la ressource avant de renouveler l’exemption ou désactiver la garde.
Preuves à confirmer : Relier le premier refus à expiresOn, à l’assignment exacte, aux références d’initiative et à l’état courant de la ressource avant de renouveler l’exemption ou désactiver la garde.
Contrôles immédiats : Figer le premier run refusé et son correlation ID | Lire l’exemption à son scope exact et comparer expiresOn en UTC | Faire correspondre les IDs d’assignment et de référence d’initiative | Canaryer le même artefact avec un contrôle de refus hors scope
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer le premier run refusé et son correlation ID | Lire l’exemption à son scope exact et comparer expiresOn en UTC | Faire correspondre les IDs d’assignment et de référence d’initiative | Canaryer le même artefact avec un contrôle de refus hors scope. 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 déploiement Azure auparavant autorisé est refusé après l’expiration de son exemption Policy
Hypothèse initiale : Relier le premier refus à expiresOn, à l’assignment exacte, aux références d’initiative et à l’état courant de la ressource avant de renouveler l’exemption ou désactiver la garde.
Preuves utilisées : Relier le premier refus à expiresOn, à l’assignment exacte, aux références d’initiative et à l’état courant de la ressource avant de renouveler l’exemption ou désactiver la garde.
Contrôles effectués : Figer le premier run refusé et son correlation ID | Lire l’exemption à son scope exact et comparer expiresOn en UTC | Faire correspondre les IDs d’assignment et de référence d’initiative | Canaryer le même artefact avec un contrôle de refus hors scope
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer le premier run refusé et son correlation ID | Lire l’exemption à son scope exact et comparer expiresOn en UTC | Faire correspondre les IDs d’assignment et de référence d’initiative | Canaryer le même artefact avec un contrôle de refus hors scope. 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 trace d’agent IA contient des données sensibles après un changement d’instrumentation
Contexte : Relier release, span, champ fautif, route d’export et destination avant de couper l’observabilité ; contenir le chemin précis, traiter les copies historiques et canaryer la redaction.
Preuves à confirmer : Relier release, span, champ fautif, route d’export et destination avant de couper l’observabilité ; contenir le chemin précis, traiter les copies historiques et canaryer la redaction.
Contrôles immédiats : Figer les métadonnées de trace sans recopier la valeur brute | Cartographier chaque copie dans collectors, exporters et destinations | Désactiver l’enrichissement fautif en gardant les événements minimaux | Rejouer des marqueurs synthétiques par chaque chemin d’entrée
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer les métadonnées de trace sans recopier la valeur brute | Cartographier chaque copie dans collectors, exporters et destinations | Désactiver l’enrichissement fautif en gardant les événements minimaux | Rejouer des marqueurs synthétiques par chaque chemin d’entrée. 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 trace d’agent IA contient des données sensibles après un changement d’instrumentation
Hypothèse initiale : Relier release, span, champ fautif, route d’export et destination avant de couper l’observabilité ; contenir le chemin précis, traiter les copies historiques et canaryer la redaction.
Preuves utilisées : Relier release, span, champ fautif, route d’export et destination avant de couper l’observabilité ; contenir le chemin précis, traiter les copies historiques et canaryer la redaction.
Contrôles effectués : Figer les métadonnées de trace sans recopier la valeur brute | Cartographier chaque copie dans collectors, exporters et destinations | Désactiver l’enrichissement fautif en gardant les événements minimaux | Rejouer des marqueurs synthétiques par chaque chemin d’entrée
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer les métadonnées de trace sans recopier la valeur brute | Cartographier chaque copie dans collectors, exporters et destinations | Désactiver l’enrichissement fautif en gardant les événements minimaux | Rejouer des marqueurs synthétiques par chaque chemin d’entrée. 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 déploiement Azure DevOps annulé laisse la cible de production dans un état partiel incertain
Contexte : Réconcilier run, agent, control plane Azure et application avant toute relance ; prouver chaque checkpoint, artefact et effet, puis choisir reprise, compensation ou rollback.
Preuves à confirmer : Réconcilier run, agent, control plane Azure et application avant toute relance ; prouver chaque checkpoint, artefact et effet, puis choisir reprise, compensation ou rollback.
Contrôles immédiats : Geler chaque writer ciblant l’environnement | Figer run, commit et digest de l’artefact | Lire les opérations côté cible sur la fenêtre d’annulation | Bloquer la relance tant qu’un checkpoint critique reste inconnu
Action proposée : Exécuter les premiers contrôles dans l’ordre : Geler chaque writer ciblant l’environnement | Figer run, commit et digest de l’artefact | Lire les opérations côté cible sur la fenêtre d’annulation | Bloquer la relance tant qu’un checkpoint critique reste inconnu. 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 déploiement Azure DevOps annulé laisse la cible de production dans un état partiel incertain
Hypothèse initiale : Réconcilier run, agent, control plane Azure et application avant toute relance ; prouver chaque checkpoint, artefact et effet, puis choisir reprise, compensation ou rollback.
Preuves utilisées : Réconcilier run, agent, control plane Azure et application avant toute relance ; prouver chaque checkpoint, artefact et effet, puis choisir reprise, compensation ou rollback.
Contrôles effectués : Geler chaque writer ciblant l’environnement | Figer run, commit et digest de l’artefact | Lire les opérations côté cible sur la fenêtre d’annulation | Bloquer la relance tant qu’un checkpoint critique reste inconnu
Décision / action : Exécuter les premiers contrôles dans l’ordre : Geler chaque writer ciblant l’environnement | Figer run, commit et digest de l’artefact | Lire les opérations côté cible sur la fenêtre d’annulation | Bloquer la relance tant qu’un checkpoint critique reste inconnu. 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 indexer Azure AI Search réussit partiellement et le corpus de l’agent devient incomplet
Contexte : Séparer accès source, tracking incrémental, échecs du skillset et écritures dans l’index cible avant de rejouer des documents ou d’effacer le high-water mark.
Preuves à confirmer : Séparer accès source, tracking incrémental, échecs du skillset et écritures dans l’index cible avant de rejouer des documents ou d’effacer le high-water mark.
Contrôles immédiats : Figer l’historique d’exécution et les états de tracking | Réconcilier identifiants source, clés d’index et versions | Regrouper les erreurs par étage, code et skill | Canaryer la reprise ciblée avant tout reset complet
Action proposée : Exécuter les premiers contrôles dans l’ordre : Figer l’historique d’exécution et les états de tracking | Réconcilier identifiants source, clés d’index et versions | Regrouper les erreurs par étage, code et skill | Canaryer la reprise ciblée avant tout reset complet. 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 indexer Azure AI Search réussit partiellement et le corpus de l’agent devient incomplet
Hypothèse initiale : Séparer accès source, tracking incrémental, échecs du skillset et écritures dans l’index cible avant de rejouer des documents ou d’effacer le high-water mark.
Preuves utilisées : Séparer accès source, tracking incrémental, échecs du skillset et écritures dans l’index cible avant de rejouer des documents ou d’effacer le high-water mark.
Contrôles effectués : Figer l’historique d’exécution et les états de tracking | Réconcilier identifiants source, clés d’index et versions | Regrouper les erreurs par étage, code et skill | Canaryer la reprise ciblée avant tout reset complet
Décision / action : Exécuter les premiers contrôles dans l’ordre : Figer l’historique d’exécution et les états de tracking | Réconcilier identifiants source, clés d’index et versions | Regrouper les erreurs par étage, code et skill | Canaryer la reprise ciblée avant tout reset complet. 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.