Un incident 5xx ne dégrade pas seulement un taux de disponibilité. Son symptôme empêche un visiteur d’acheter, un prospect de contacter l’entreprise et un robot de récupérer la ressource. Quelques erreurs isolées peuvent être absorbées ; une hausse large et persistante ralentit le crawl, puis menace la fraîcheur et la présence des URL. Dans l’urgence, les équipes lancent parfois plusieurs corrections concurrentes et perdent la chronologie exacte qui aurait permis de comprendre la panne.
En pratique, le vrai enjeu est double : restaurer le service précède la recherche exhaustive de cause, mais chaque action doit préserver assez de preuves pour apprendre après la mitigation. Une réponse structurée nomme les rôles, classe l’impact par template, choisit le mode dégradé et mesure le retour depuis l’extérieur. Le SEO apporte les pages sentinelles et les signaux de crawl qui indiquent si la reprise couvre réellement la surface publique.
Vous allez comprendre comment construire ce dispositif depuis la première alerte jusqu’au postmortem, avec statuts, seuils, contre-tests et communication. Notre accompagnement en SEO technique aide à l’intégrer aux procédures SRE afin que la protection du trafic organique et du revenu reste exécutable même lorsque l’équipe travaille sous pression.
Déclarer l’incident avant que les 5xx ne s’étendent
Utiliser des conditions observables plutôt qu’une intuition
Déclarez un incident lorsque le taux de 5xx franchit un seuil sur une fenêtre significative, qu’un parcours critique devient indisponible, que plusieurs équipes doivent intervenir ou que l’impact reste inexpliqué après un temps court. Les chiffres dépendent du trafic : 2 % pendant cinq minutes peut être grave sur une marketplace, tandis que trois erreurs sur une route interne ne justifient pas la même mobilisation. Le seuil associe volume, template et criticité.
Le chapitre Managing Incidents du livre Google SRE souligne l’intérêt de déclarer tôt et de structurer la réponse. Une déclaration peut être clôturée rapidement si le problème est simple ; attendre que la panne soit incontestable coûte la fenêtre où une mitigation limitée aurait suffi. Le document d’incident enregistre heure, symptôme, propriétaire, pages touchées, première hypothèse et prochaine mise à jour.
Définissez des niveaux. Un incident local touche un template et possède un contournement ; un incident majeur affecte plusieurs parcours ou une part importante du revenu ; un incident critique retire l’ensemble du site ou menace l’intégrité des données. Le niveau détermine personnes appelées, fréquence de communication, changements autorisés et décision de basculer en mode dégradé. Il peut monter ou descendre selon les preuves, sans jugement sur les individus.
Séparer commandement, opérations et communication
Donner à chacun une responsabilité nette pendant l’urgence
Le commandant d’incident maintient la vue d’ensemble, les priorités et les décisions. Le responsable opérations est le seul groupe qui modifie le système ; il délègue les investigations techniques sans autoriser des changements sauvages. Le responsable communication informe support, métier et parties prenantes à intervalles prévus. Un rôle planification tient la chronologie, prépare le relais et suit ce qui devra être restauré après la mitigation. Une petite équipe peut cumuler des rôles, mais elle les nomme.
Cette séparation paraît bureaucratique pendant une panne ; elle rend en réalité les opérations plus autonomes. L’ingénieur qui replie une release n’a pas à répondre simultanément à dix demandes ni à reconstruire l’impact commercial. Le commandant arbitre si deux hypothèses exigent des actions incompatibles. Chaque changement reçoit une heure, un auteur, une attente, un résultat et une décision de conserver ou replier.
Créez un canal et un document reconnus, accessibles même si l’application principale est touchée. En tête figurent état actuel, impact, commandant, opérations, communication, dernière action et prochaine mise à jour. La documentation de gestion d’incident Google SRE résume trois objectifs : coordonner, communiquer et contrôler. Cette discipline évite que des équipes bien intentionnées déploient en parallèle des correctifs qui aggravent ou masquent la panne.
Mesurer l’impact par template et parcours métier
Le taux global de 5xx peut cacher une panne totale d’un petit groupe décisif. Segmentez par hostname, route normalisée, template, statut exact, région, point de présence, version, cache et client. Mesurez le numérateur et le volume : vingt erreurs sur vingt requêtes valent 100 %, mais n’ont pas le même impact que dix mille erreurs sur un catalogue. Associez à chaque groupe le trafic organique, le revenu ou les leads habituels.
Définissez un corpus sentinelle : accueil, pages catégories, offres principales, contenus générateurs de demandes, panier, formulaire, robots.txt et sitemap. Chaque sentinelle possède statut attendu, contenu distinctif, temps maximal et dépendances. Une sonde qui vérifie uniquement l’accueil ne détecte pas un contrôleur produit cassé. Une sonde qui accepte une page d’erreur personnalisée en 200 crée un faux vert.
Estimez le coût par minute ou par heure. Commandes non réalisées, demandes perdues, dépenses publicitaires inutiles, agents support mobilisés et opportunités organiques exposées donnent un ordre de grandeur. Le chiffre n’a pas besoin d’être parfait pour prioriser. Si le checkout représente 60 % du coût, une désactivation de recommandation qui libère la base peut être préférable à une longue investigation du service secondaire.
Exemple concret : le taux global est seulement 0,8 %, mais 82 % des pages « agence marketplace » répondent 502 depuis un POP tandis que les articles restent sains. Le segment porte un tiers des leads. Le commandant classe l’incident majeur et dérive ce trafic vers l’origine saine. La moyenne aurait retardé la décision ; la segmentation par template, région et valeur la rend immédiate.
Arrêter l’hémorragie avant de chercher la cause racine
Choisir la mitigation la plus rapide et la plus réversible
Le chapitre Google SRE sur le dépannage efficace recommande de rendre le système aussi fonctionnel que possible avant la recherche complète de cause. Replier la dernière release, déplacer le trafic, désactiver une fonction, servir une version en cache ou réduire une précision peut arrêter la propagation. Préservez d’abord les données et les parcours critiques.
Classez les options par temps, risque et réversibilité. Un rollback connu de cinq minutes domine un correctif non testé de quarante minutes si les données restent compatibles. Un feature flag peut retirer le composant fautif sans redéployer. Une bascule de région exige de vérifier capacité et réplication. Le commandant choisit une action, fixe le résultat attendu et interdit les changements concurrents sur le même chemin jusqu’au verdict.
Contre-intuitivement, établir immédiatement la cause racine peut prolonger l’impact. Une trace parfaite ne compense pas une heure supplémentaire de ventes perdues. Mais mitiger sans conserver aucune preuve produit des incidents récurrents. Avant le repli, sauvegardez les logs pertinents, métriques, trace d’une requête, version, configuration et exemple de réponse. Cette collecte doit prendre quelques minutes et être préparée dans le runbook.
Fixer la preuve qui autorise la réouverture
Définissez le succès de la mitigation : 5xx sous 0,2 % pendant dix minutes, toutes les sentinelles publiques correctes, checkout synthétique réussi, p95 sous le budget et capacité supérieure à 25 %. L’instrumentation du runbook joint entrées, sorties, dépendances, monitoring et seuil de rollback. Sans ce contrat, l’équipe déclare la reprise au premier 200 et peut rouvrir sur un système encore oscillant.
Cas concret. Si le taux repasse sous 0,2 % mais que deux routes rentables dépassent encore le seuil de 5 %, le commandant refuse l’ouverture globale et conserve le mode dégradé. La décision protège la conversion jusqu’à ce qu’un contre-test fournisse deux séries saines par région.
Servir des statuts cohérents aux robots
La documentation Google sur l’effet des codes HTTP indique que les 5xx et 429 conduisent les crawlers à ralentir temporairement. Pour Search, un contenu reçu avec 5xx est ignoré ; des erreurs persistantes peuvent conduire à la suppression d’URL déjà indexées. Une panne courte est donc récupérable, mais sa durée et son étendue comptent.
Ne transformez pas les 5xx en 200 contenant une erreur. Ce « soft error » masque la disponibilité aux sondes et offre un contenu sans valeur à la place de la ressource. Ne remplacez pas non plus une panne serveur par 404 ou 410 : ces statuts disent que la ressource est absente, pas temporairement indisponible. Conservez le statut qui décrit l’état, avec une page d’erreur utile lorsque cela ne surcharge pas le système.
Si Googlebot contribue réellement à une saturation critique, Google documente l’usage temporaire de 500, 503 ou 429 pour réduire le crawl, pendant une fenêtre très courte. N’appliquez pas cette tactique plusieurs jours. Protégez d’abord robots.txt, les pages prioritaires et la capacité. Le runbook sur le budget de crawl et l’indexation aide à distinguer une demande utile d’un espace d’URL inefficace.
Vérifiez aussi DNS, connexion et timeouts, car Google traite les erreurs réseau de manière similaire aux 5xx. Un tableau fondé uniquement sur les réponses applicatives ne voit pas les requêtes qui n’atteignent jamais le serveur. Les sondes externes par région, les logs CDN et les métriques de load balancer complètent le journal du framework.
Préserver les preuves pendant la mitigation
Capturez un échantillon borné : horodatage synchronisé, identifiant de requête, route normalisée, statut, version, instance, cache, dépendance et durée. Conservez une trace réussie et une trace échouée sur le même template. La comparaison réduit le champ d’hypothèses. Expurgez cookies, jetons et données personnelles avant de partager. La qualité d’une preuve ne dépend pas de sa quantité brute.
Photographiez les configurations volatiles avant modification : flags, routage, quotas, pool, version de schéma et règle CDN. Enregistrez la commande exécutée et son résultat. Les métriques agrégées peuvent changer après un autoscaling ou une purge ; exportez la fenêtre précédant l’alerte. Le document vivant relie chaque variation à la chronologie, sans conclure prématurément qu’elle est causale.
Une hypothèse doit être falsifiable. « La base est lente » devient « les pages qui appellent le service stock passent en 504 lorsque la connexion au pool dépasse 90 %, tandis que le témoin sans stock reste sous 200 ms ». Le contre-test désactive cet appel sur une cohorte et observe la récupération. Si elle n’arrive pas, l’équipe réfute et passe à l’hypothèse suivante au lieu d’empiler un second changement.
Activer un mode dégradé qui conserve l’information
Préparez plusieurs paliers. Le premier retire les enrichissements coûteux : recommandation, personnalisation, recherche avancée ou widgets tiers. Le deuxième sert une version en cache ou une donnée datée lorsque le métier l’accepte. Le troisième garde les pages publiques en lecture mais désactive les écritures. Le dernier sert un 503 statique pour une indisponibilité générale. Chaque palier a un flag, un propriétaire et une preuve de sortie.
Le mode dégradé ne doit pas présenter une donnée fausse. Un prix, un stock ou un créneau obsolète exige une mention et peut imposer de suspendre l’action. Une publication, une description de service ou une documentation peuvent rester servies plus longtemps. La segmentation permet de protéger le revenu futur même lorsque la transaction immédiate est arrêtée : l’utilisateur comprend l’offre et peut demander à être recontacté.
Testez régulièrement ces chemins. Un fallback jamais exécuté peut dépendre du service qu’il est censé remplacer, contenir des routes anciennes ou échouer à la première purge. La page 503 doit être autonome ; le cache doit avoir une durée connue ; les flags doivent rester actionnables avec des droits d’astreinte. Une répétition trimestrielle mesure le temps d’activation et met à jour les propriétaires.
Valider la reprise par cohortes et régions
Refuser le verdict fondé sur une seule URL en 200
La reprise commence sur un canari : une instance, une région ou un faible pourcentage. Le monitoring relie chaque dépendance au seuil de sortie et au rollback prévu dans le runbook. Rejouez les sentinelles, le parcours de conversion et les lectures de cache ; si les 5xx baissent mais que le p95 ou la file augmente rapidement, stoppez l’extension.
Ouvrez ensuite par région et template. Le CDN peut conserver une erreur dans un POP ; une instance ancienne peut répondre derrière un load balancer ; une migration peut échouer sur une partition. Le tableau affiche le nombre d’URL distinctes en erreur, pas seulement le nombre de requêtes. Vingt mille succès sur l’accueil ne compensent pas cent pages stratégiques toujours en panne.
Vérifiez le contenu, pas seulement le statut. Une réponse 200 peut contenir une page vide, une redirection client, un challenge ou une erreur sérialisée. Les sentinelles contrôlent titre, texte, liens, canonical et action. Pour automatiser ces preuves avant et après chaque release, utilisez le protocole de CI/CD et non-régression SEO technique.
Après stabilisation, surveillez le crawl sur plusieurs jours. Les systèmes de Google augmentent progressivement la cadence lorsque les 2xx reviennent. Une reprise instantanée du volume n’est pas attendue. Cherchez surtout l’absence de nouveaux 5xx, le retour des pages prioritaires et une couverture cohérente. N’inondez pas l’inspection d’URL : corrigez les liens, sitemaps et capacités qui permettent le recrawl naturel.
Communiquer sans promettre une heure impossible
Le responsable communication publie un rythme : première confirmation, impact connu, mitigation en cours et prochaine mise à jour. Il sépare les faits des hypothèses. « 35 % des fiches produit en Europe répondent 502 depuis 10 h 14 » est un fait ; « le CDN est probablement responsable » reste une hypothèse jusqu’au test. Cette distinction protège la confiance et évite que le support relaie une cause qui changera.
Annoncez une estimation seulement lorsque l’opération possède une borne. Sinon, communiquez l’action et l’heure du prochain point. Une promesse répétitivement repoussée détériore plus la confiance qu’une incertitude expliquée. Sur la page publique, donnez un moyen de contact et les fonctions encore disponibles. En interne, le métier reçoit l’impact chiffré et les décisions pour lesquelles son arbitrage est nécessaire.
Le relais entre équipes et fuseaux doit être explicite. Le commandant sortant transmet état, actions, hypothèses réfutées, risques, seuils et prochaines décisions ; le nouveau confirme la prise. Ce passage évite de rejouer des tests dangereux. Le document vivant conserve l’historique même si le canal de discussion devient très actif.
Transformer l’incident en garde-fous durables
Le postmortem décrit impact, détection, chronologie, mitigation, causes contributives, ce qui a bien fonctionné et les actions. Il se concentre sur les conditions du système plutôt que sur la faute d’une personne. Le chapitre Postmortem Culture de Google SRE présente ce document comme un outil d’apprentissage qui empêche la répétition. Un compte rendu sans actions attribuées reste une archive, pas une amélioration.
Transformez chaque lacune en contrôle vérifiable : alerte par template, propagation d’identifiant, rollback compatible avec le schéma, mode dégradé testé, cache d’erreur borné ou capacité minimale. Chaque action possède propriétaire, échéance, critère d’acceptation et priorité selon le risque. Fermez ou renégociez explicitement les actions ; une longue liste abandonnée dégrade la confiance dans le processus.
Mesurez temps de détection, déclaration, mitigation, récupération complète et reprise du crawl. La moyenne seule masque les incidents extrêmes ; conservez la distribution et la gravité. N’utilisez pas ces métriques pour classer les individus. Elles indiquent où l’architecture ou le processus fait perdre du temps : alerte tardive, droit manquant, commande inconnue, dépendance non cartographiée ou preuve de sortie incomplète.
Erreurs fréquentes pendant un incident 5xx
- Attendre la certitude sur la cause avant de déclarer et structurer la réponse.
- Autoriser plusieurs équipes à modifier la même couche sans commandement ni chronologie.
- Piloter avec un taux global qui masque la panne d’un template rentable.
- Transformer l’erreur en 200, 404 ou challenge et perdre la sémantique d’indisponibilité.
- Chercher la cause racine pendant que l’impact continue alors qu’un rollback sûr existe.
- Déclarer la reprise après une seule requête sans vérifier régions, contenu et conversion.
- Écrire un postmortem sans propriétaire, échéance ni test de non-régression.
Une erreur plus subtile consiste à optimiser la statistique plutôt que le service. Désactiver les sondes ou exclure un template fait baisser le taux affiché sans rendre une page. Conservez un indicateur externe indépendant et le nombre d’URL distinctes touchées. Le verdict doit correspondre à ce que reçoivent visiteurs et robots, pas à une requête filtrée du dashboard.
Questions fréquentes sur les erreurs serveur
Quelques minutes de 5xx désindexent-elles un site ?
Généralement non. Google ralentit face aux erreurs serveur et conserve temporairement les URL déjà indexées. Le risque augmente avec la durée, la proportion et la répétition. Restaurez les 2xx corrects, surveillez la reprise et évitez de remplacer l’incident temporaire par des statuts permanents.
Faut-il retourner 503 à Googlebot seulement ?
Pas pour masquer une panne aux robots. Servez l’état réel aux clients. Dans une urgence de capacité causée par le crawl, Google documente 500, 503 ou 429 temporairement, mais la mesure touche le hostname et ne doit durer qu’un temps très court. Corrigez ensuite la cause de charge.
Quel est le premier indicateur de reprise ?
Un ensemble : 5xx sous le seuil, sentinelles correctes par région, latence stable, capacité disponible et parcours métier réussi. Le retour du crawl est plus lent et confirme la stabilité sur plusieurs jours. Aucun voyant unique ne suffit.
Le rollback clôt-il l’incident ?
Non. Il peut mitiger. Il faut vérifier la cohérence des données, les caches, les anciennes instances, toutes les régions et les fonctions. Conservez les preuves, communiquez la reprise, surveillez puis rédigez le postmortem et ses actions.
Articles complémentaires à lire ensuite
Prévenez la répétition grâce à la non-régression SEO technique dans la CI/CD. Pour observer l’effet de la panne et du retour sur l’exploration, complétez avec la maîtrise du budget de crawl et de l’indexation.
La QA compare chaque route, son HTML, son canonical et son rendu JavaScript après invalidation du cache. Les variantes SSR, SSG ou ISR doivent réussir la même revalidation avant que Googlebot ne reçoive la release restaurée.
Plan d’action 5xx en quinze opérations ordonnées
- Nommer le symptôme depuis une sonde externe et ouvrir le document horodaté.
- Tester le niveau selon volume, templates, revenu, crawl et propagation.
- Désigner commandement, opérations, communication et planification.
- Geler les changements concurrents et inventorier les déploiements récents.
- Segmenter 5xx par statut, route, région, version, cache et instance.
- Calculer le coût et prioriser pages, parcours et intégrité des données.
- Capturer logs, traces, configuration et une paire requête saine/échouée.
- Choisir rollback, dérivation ou mode dégradé le plus rapide et réversible.
- Définir le résultat attendu et un seuil d’abandon avant l’action.
- Vérifier statuts honnêtes, robots.txt et absence de faux 200.
- Rouvrir sur un canari puis étendre par région et template.
- Contrôler contenu, conversion, latence, files et capacité, pas seulement les 2xx.
- Publier des faits et l’heure du prochain point sans cause non vérifiée.
- Surveiller crawl et indexation après stabilisation sans forcer une avalanche de requêtes.
- Produire un postmortem sans blâme avec actions, propriétaires, échéances et tests d’acceptation.
- À valider : toutes les cohortes restent sous le seuil et les parcours rapportent une preuve saine.
- À replier : une région, un cache ou une dépendance reprend sa hausse après le canari.
Conclusion : restaurer vite, prouver complètement, apprendre durablement
Un incident 5xx bien géré est déclaré tôt, commandé clairement et segmenté selon les pages qui comptent. L’équipe arrête l’impact avec une mitigation réversible avant l’analyse complète, tout en préservant traces et configurations. Les statuts restent honnêtes afin que visiteurs, robots et sondes partagent le même état.
La reprise exige davantage qu’un code 200 : contenu, parcours, régions, caches, latence et capacité doivent rester stables sur une fenêtre représentative. Le postmortem convertit ensuite chaque lacune en garde-fou testé. Cette boucle protège les revenus aujourd’hui et réduit la probabilité d’une nouvelle panne demain.
Pour bâtir vos sentinelles, aligner le runbook SRE avec les pages organiques prioritaires et automatiser les preuves de reprise, sollicitez notre expertise en SEO technique. Nous faisons de la résilience du crawl et des parcours commerciaux une responsabilité mesurable de la production.
