--- schema_version: "1" id: 41cf6a1852b92d5b829896842bc3ead7fe804e1eaf1999d9fbec618ed7ad3120 title: Gestion des incidents - Modèles collection: architect version: current locale: fr-fr portal_url: https://docs.salesforce.com/architect/current/fr-fr/well-architected/guides/operational-excellence-incident-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/fr-fr/well-architected/guide/operational-excellence-incident-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 0de5d50dfd4c1b922151a7c604d3ecf2b44cbc67c3ea630889eb3bae7989f288 products: - Infrastructure bien architecturée - Architect Site Content Repo --- # Gestion des incidents - Modèles En savoir plus sur l'[excellence opérationnelle](/docs/architect/fr-fr/well-architected/guide/operational-excellence.html) bien archivée → [Gestion des incidents](/docs/architect/fr-fr/well-architected/guide/operational-excellence.html#incident-management) ## Détection et alerte des incidents **Modèles** | Où chercher | À quoi ressemble le bien | | --- | --- | | Plate-forme \| Surveillance | ✅ L'architecture d'alerte inclut la classification de la sévérité qui achemine immédiatement les incidents critiques (production non disponible, corruption des données, atteinte à la sécurité) vers les appels de garde. | | Plate-forme \| Surveillance | ✅ Les incidents de haute gravité (performances dégradées, panne partielle) génèrent des notifications immédiates pour une enquête rapide pendant les heures ouvrables | | Plate-forme \| Surveillance | ✅ Les avertissements (seuils proches, dérive de configuration) sont regroupés dans un résumé quotidien pour une correction proactive | | Plate-forme \| Surveillance | ✅ L'enrichissement des alertes inclut le contexte de diagnostic : nombre d'utilisateurs affectés, percentiles de taux d'erreur, déploiements récents, alertes associées et liens directs vers les tableaux de bord | | Plate-forme \| Surveillance | ✅ Le contexte d'alerte réduit le délai moyen d'acceptation en fournissant une évaluation de la situation immédiate sans recueillir d'informations de base via des requêtes séparées | | Plate-forme \| Surveillance | ✅ Le regroupement des alertes empêche les tempêtes d'alerte en regroupant des centaines d'alertes associées à partir d'un problème sous-jacent unique dans une notification avec des statistiques agrégées | | Plate-forme \| Surveillance | ✅ Les alertes groupées affichent le nombre, le taux et les transactions affectées qui révèlent un schéma de problème sans accabler les répondants | | Plate-forme \| Surveillance | ✅ La suppression des alertes empêche les conditions transitoires connues de générer des alertes pendant les périodes de maintenance ou de correction automatique attendues | **Anti-modèles** | Où chercher | À quoi ressemble mal | | --- | --- | | Plate-forme \| Surveillance | ⚠️ L’échec de l’intégration génère des alertes individuelles de 100s en 5 minutes de téléphone d’astreinte écrasant, chaque alerte étant identique à l’exception de l’horodatage | | Plate-forme \| Surveillance | ⚠️ Les alertes manquent de contexte sur la portée, les changements récents ou les schémas de problème ; l’ingénieur d’astreinte doit recueillir manuellement des informations de base | | Plate-forme \| Surveillance | ⚠️ Toutes les alertes transitent par le même canal quelle que soit la gravité ; les pannes critiques de production rivalisent d’avertissements mineurs | | Plate-forme \| Surveillance | ⚠️ Alerte le feu pendant les fenêtres de maintenance planifiées générant des faux positifs qui érodent Trust dans le système de surveillance | | Plate-forme \| Surveillance | ⚠️ Le regroupement d’alertes n’existe pas ; chaque échec de transaction déclenche une alerte séparée créant des tempêtes d’alerte lors d’incidents | | Plate-forme \| Surveillance | ⚠️ Les alertes ne fournissent aucun lien vers les tableaux de bord pertinents ; les intervenants passent du temps à trouver des outils de surveillance pendant les interventions en cas d’incident | ## Rotation et runbook d'astreinte **Modèles** | Où chercher | À quoi ressemble le bien | | --- | --- | | Plate-forme \| Opérations | ✅ La rotation d'astreinte est une répartition hebdomadaire ou bihebdomadaire de la charge d'équilibre avec la préservation du contexte | | Plate-forme \| Opérations | ✅ Les runbooks sont documentés pour chaque type d'alerte, ce qui permet aux ingénieurs d'astreinte de répondre efficacement sans expertise approfondie du domaine | | Plate-forme \| Opérations | ✅ Les runbooks comprennent une description du problème, des étapes de diagnostic, des procédures de réparation, des critères d'escalade et des liens vers la documentation associée | | Plate-forme \| Opérations | ✅ Runbooks sont des documents vivants dans le contrôle de version qui évoluent à travers les éléments d'action post-mortem | | Plate-forme \| Opérations | ✅ Les procédures de transfert comprennent de brèves réunions pendant les transitions de rotation, le contexte de transfert, y compris les problèmes actifs, les changements récents, les risques connus et la maintenance à venir | | Plate-forme \| Opérations | ✅ Les notes de transfert écrites complètent le transfert verbal empêchant la perte d'information pendant les transitions de rotation | | Plate-forme \| Opérations | ✅ La fréquence des pages, le nombre d'incidents après les heures de travail et le taux de faux positifs sont mesurés afin d'identifier les charges d'astreinte insoutenables nécessitant une réparation architecturale | **Anti-modèles** | Où chercher | À quoi ressemble mal | | --- | --- | | Plate-forme \| Opérations | ⚠️ Les runbooks n’existent pas ; les ingénieurs d’astreinte s’appuient sur les tribal Knowledge et les escalades fréquentes vers les experts en la matière | | Plate-forme \| Opérations | ⚠️ Les runbooks sont stockés dans des documents personnels plutôt que dans un contrôle de version partagé où les membres de l’équipe peuvent y accéder et les mettre à jour | | Plate-forme \| Opérations | ⚠️ Les transitions de rotation des astreintes se font sans réunion de transfert ; l’ingénieur entrant manque de contexte sur les problèmes actifs et les récents changements | | Plate-forme \| Opérations | ⚠️ La charge élevée des astreintes continue indéfiniment par l’héroïsme opérationnel plutôt que par la conduite d’améliorations architecturales | | Plate-forme \| Opérations | ⚠️ Les métriques d’astreinte (fréquence des pages, incidents après les heures de travail, faux positifs) ne sont pas suivies ; les modèles de charge restent invisibles | | Plate-forme \| Opérations | ⚠️ Les runbooks sont créés une fois lors du déploiement initial et ne sont jamais mis à jour à mesure que le système évolue ou que de nouveaux modes d’échec émergent | ## Chemin d'escalade **Modèles** | Où chercher | À quoi ressemble le bien | | --- | --- | | Plate-forme \| Opérations | ✅ Les parcours d'escalade technique définissent les experts qui gèrent des domaines problématiques spécifiques | | Plate-forme \| Opérations | ✅ Les parcours d'escalade de gestion définissent les responsables qui reçoivent une notification en cas d'incident dépassant les seuils de gravité ou de durée | | Plate-forme \| Opérations | ✅ Les parcours d'escalade des fournisseurs documentent les procédures de création de requêtes de support Salesforce et les critères de sévérité | | Plate-forme \| Opérations | ✅ Les parcours d'escalade des dirigeants définissent les dirigeants qui reçoivent une notification en cas d'incidents critiques pour l'entreprise | | Plate-forme \| Opérations | ✅ Les critères d'escalade sont explicites et objectifs: niveaux de sévérité, seuils temporels, nombre d'utilisateurs affectés, évaluations d'impact métier | | Plate-forme \| Opérations | ✅ Les parcours d'escalade sont documentés dans des runbooks et accessibles en cas d'incident sans rechercher les coordonnées | **Anti-modèles** | Où chercher | À quoi ressemble mal | | --- | --- | | Plate-forme \| Opérations | ⚠️ Les parcours d’escalade ne sont pas documentés ; les ingénieurs d’astreinte perdent du temps à rechercher les contacts appropriés lors d’incidents | | Plate-forme \| Opérations | ⚠️ Les critères d’escalade sont vagues (« escalader si cela semble mauvais ») ; les intervenants n’ont pas d’orientation claire sur le moment où escalader | | Plate-forme \| Opérations | ⚠️ La notification de la direction arrive trop tard, car les seuils de sévérité ne sont pas définis ; les dirigeants sont informés des incidents par les utilisateurs | | Plate-forme \| Opérations | ⚠️ Les procédures d’escalade du support Salesforce ne sont pas documentées ; les équipes retardent l’ouverture des requêtes de support en perdant un temps de réponse précieux | | Plate-forme \| Opérations | ⚠️ Les contacts d’experts en la matière sont obsolètes ; les escalades atteignent des personnes incorrectes ou échouent pendant les changements de rotation | ## Processus d'examen après incident **Modèles** | Où chercher | À quoi ressemble le bien | | --- | --- | | Plate-forme \| Opérations | ✅ Des examens post-incident irréprochables sont effectués dans les 5 jours ouvrables suivant des événements opérationnels importants | | Plate-forme \| Opérations | ✅ La culture irréprochable se concentre sur les améliorations du système plutôt que sur le blâme individuel, créant une sécurité psychologique pour une évaluation honnête | | Plate-forme \| Opérations | ✅ La chronologie inclut une séquence détaillée depuis les conditions initiales jusqu'au premier signal, la détection, l'accusé de réception, l'enquête, la réponse, la récupération et la validation | | Plate-forme \| Opérations | ✅ Chronologie horodate chaque événement permettant l'analyse de la durée des phases de détection, de réponse et de récupération | | Plate-forme \| Opérations | ✅ La cause première identifie la défaillance technique ou l'état qui a directement causé l'incident, différent des facteurs contributifs | | Plate-forme \| Opérations | ✅ L'analyse des facteurs contributifs révèle des conditions organisationnelles, de processus ou architecturales qui ont activé ou amplifié l'impact des incidents | | Plate-forme \| Opérations | ✅ L'analyse de la détection évalue comment l'incident a été détecté et si la détection aurait pu être plus rapide | | Plate-forme \| Opérations | ✅ L'évaluation de la réponse identifie ce qui s'est bien passé pendant la réponse et ce qui a été plus lent ou plus difficile que nécessaire | | Plate-forme \| Opérations | ✅ Les éléments d'action sont spécifiques, attribués et limités dans le temps, empêchant la récurrence ou améliorant la réponse future | | Plate-forme \| Opérations | ✅ Les éléments d'action évitent de vagues améliorations ("améliorer la surveillance") au profit de tâches concrètes ("ajouter une alerte pour un taux d'erreur d'API supérieur à 5% sur une fenêtre de 10min") | **Anti-modèles** | Où chercher | À quoi ressemble mal | | --- | --- | | Plate-forme \| Opérations | ⚠️ La discussion après incident conclut que « la tâche par lot avait un bogue, nous l’avons corrigé » sans documentation ni améliorations systématiques | | Plate-forme \| Opérations | ⚠️ Les examens postérieurs à l’incident se concentrent sur la faute individuelle plutôt que sur les améliorations du système, détruisant la sécurité psychologique | | Plate-forme \| Opérations | ⚠️ La chronologie manque d’horodatage empêchant l’analyse de la durée ; l’équipe ne peut pas identifier si la détection ou la réponse a été lente | | Plate-forme \| Opérations | ⚠️ L’analyse des causes premières ne distingue pas la cause technique immédiate des facteurs contributifs organisationnels ou de processus | | Plate-forme \| Opérations | ⚠️ L’analyse de détection est ignorée ; les lacunes de surveillance qui ont permis aux utilisateurs de signaler d’abord les incidents ne sont pas identifiées | | Plate-forme \| Opérations | ⚠️ Les éléments d’action sont vagues sans propriétaire ni date d’échéance ; les améliorations sont discutées mais jamais mises en œuvre | | Plate-forme \| Opérations | ⚠️ Les examens postérieurs à l’incident ne sont pas effectués dans les 5 jours ouvrables; le contexte est perdu et l’urgence d’améliorations s’estompe | ## Documentation et apprentissage après un incident **Modèles** | Où chercher | À quoi ressemble le bien | | --- | --- | | Plate-forme \| Gestion des Knowledge | ✅ Les examens postérieurs à un incident sont documentés et partagés largement au-delà des intervenants immédiats pour l'apprentissage organisationnel | | Plate-forme \| Gestion des Knowledge | ✅ Les examens postérieurs à l'incident sont stockés dans un wiki partagé ou une base Knowledge avec le balisage qui active l'analyse des modèles à travers plusieurs incidents | | Plate-forme \| Gestion des Knowledge | ✅ L'exécution des points de mesure est suivie dans les examens suivants afin d'éviter que les rétrospectives ne deviennent des discussions répétitives sans suivi | | Plate-forme \| Gestion des Knowledge | ✅ Les taux de réalisation d'éléments d'action sont mesurés en tant qu'indicateur de santé opérationnelle indiquant si des améliorations sont mises en œuvre ou simplement discutées | | Plate-forme \| Opérations | ✅ Les modèles d’incidents sont analysés à travers plusieurs incidents révélant des problèmes systémiques nécessitant un investissement architectural | | Plate-forme \| Opérations | ✅ Les catalogues sont mis à jour en fonction des apprentissages post-incidents afin de s’assurer que les procédures reflètent l’expérience réelle de réponse aux incidents | **Anti-modèles** | Où chercher | À quoi ressemble mal | | --- | --- | | Plate-forme \| Gestion des Knowledge | ⚠️ Les examens postérieurs à l’incident ne sont pas documentés; les apprentissages restent aux intervenants en cas d’incident plutôt que de se propager à l’ensemble de l’organisation | | Plate-forme \| Gestion des Knowledge | ⚠️ Les examens postérieurs à l’incident sont stockés dans des documents personnels plutôt que dans une base Knowledge partagée où les membres de l’équipe peuvent apprendre à partir de l’historique | | Plate-forme \| Gestion des Knowledge | ⚠️ Les éléments d’action sont définis mais jamais suivis ; le taux de réalisation est inconnu et les améliorations ne sont pas mises en œuvre | | Plate-forme \| Gestion des Knowledge | ⚠️ Les faibles taux de réalisation des éléments d’action persistent sans reconnaître que les rétrospectives sont inefficaces sans suivi | | Plate-forme \| Opérations | ⚠️ Les schémas d’incidents ne sont pas analysés dans plusieurs incidents ; les problèmes systémiques restent cachés car chaque incident est traité isolément | | Plate-forme \| Opérations | ⚠️ Les runbooks ne sont pas mis à jour après des incidents ; les procédures deviennent obsolètes à mesure que le système évolue et que de nouveaux modes de défaillance apparaissent | ## Métriques et surveillance des incidents **Modèles** | Où chercher | À quoi ressemble le bien | | --- | --- | | Plate-forme \| Opérations | ✅ Le temps moyen de détection (MTTD) est suivi en mesurant la durée depuis l'occurrence de l'incident jusqu'à la détection | | Plate-forme \| Opérations | ✅ Le temps moyen d'acquittement (MTTA) est suivi en mesurant la durée depuis la détection jusqu'à l'acquittement de l'ingénieur de garde | | Plate-forme \| Opérations | ✅ Le temps moyen de restauration (MTTR) est suivi en mesurant la durée depuis la détection jusqu'à la restauration du service | | Plate-forme \| Opérations | ✅ La fréquence des incidents est suivie avec un examen mensuel des tendances révélant si la stabilité s'améliore ou se dégrade | | Plate-forme \| Opérations | ✅ Le taux d'échec de modification est suivi en mesurant le pourcentage de déploiements entraînant des incidents de production nécessitant une correction | | Plate-forme \| Opérations | ✅ Le taux d'échec de modification est maintenu constamment bas, une petite fraction de tous les déploiements | | Plate-forme \| Opérations | ✅ Les métriques d'incident sont partagées avec les équipes de développement lors de la planification du sprint, ce qui informe de la priorité du backlog et des améliorations architecturales | **Anti-modèles** | Où chercher | À quoi ressemble mal | | --- | --- | | Plate-forme \| Opérations | ⚠️ Les métriques d’incident ne sont pas suivies ; l’équipe n’a aucune visibilité sur l’amélioration ou la dégradation des temps de réponse | | Plate-forme \| Opérations | ⚠️ Les MTTD, MTTA et MTTR ne sont pas mesurés ; les équipes ne peuvent pas identifier si la détection ou la réponse est le goulot d’étranglement | | Plate-forme \| Opérations | ⚠️ Le taux d’échec des modifications n’est pas suivi ; l’équipe ne sait pas si les portes de qualité sont efficaces | | Plate-forme \| Opérations | ⚠️ Les tendances de fréquence des incidents ne sont pas examinées tous les mois; la dégradation de la stabilité n’est détectée qu’après la survenance d’un incident majeur | | Plate-forme \| Opérations | ⚠️ Les métriques d’incident restent dans l’équipe d’exploitation sans partage avec les équipes de développement ; les problèmes architecturaux ne sont pas traités | | Plate-forme \| Opérations | ⚠️ Les métriques sont suivies, mais jamais utilisées pour éclairer les décisions; la mesure sans action gaspille des efforts et ne fournit aucune valeur |