Gestion des incidents¶

Un incident est tout événement qui empêche CMonChoix de fonctionner normalement, dégrade ses données, ses performances ou un traitement important.

À quoi sert cette page ?¶

Cette page explique quoi faire lorsqu'un problème sérieux apparaît en production.

Elle est destinée à une personne qui ne connaît pas forcément encore toute l'architecture. Son objectif est de donner un ordre de travail sûr : stabiliser, comprendre, corriger, vérifier et documenter.

Un incident peut être :

le site indisponible ;
un conteneur arrêté ;
une synchronisation bloquée ;
une forte hausse des erreurs ;
des données manifestement incohérentes ;
une régression apparue après un déploiement ;
une base de données ou un stockage indisponible ;
une dégradation importante des performances.

Un incident n'est donc pas forcément un bug PHP.

La règle la plus importante¶

Ne pas commencer par modifier des données ou du code au hasard.

Avant une correction, il faut savoir :

ce qui est réellement cassé ;
depuis quand ;
quel périmètre est touché ;
si les écritures doivent être arrêtées ;
quelles preuves doivent être conservées ;
si un retour arrière est plus sûr qu'une réparation immédiate.

Une correction trop rapide peut effacer les preuves nécessaires au diagnostic ou aggraver une corruption de données.

Vocabulaire simple¶

Symptôme¶

Ce qui est visible : page en erreur, traitement bloqué, produit incorrect, temps de réponse très élevé, etc.

Cause¶

Le mécanisme réel qui produit le symptôme.

Exemple : une page peut être lente parce qu'une requête SQL est lente. La page lente est le symptôme ; la requête ou son contexte est la cause.

Périmètre¶

La partie du système et des données réellement touchée.

Mitigation¶

Mesure temporaire destinée à réduire l'impact avant la correction définitive.

Rollback¶

Retour au dernier état logiciel connu comme stable.

Cycle d'un incident¶

Détection
   ↓
Qualification
   ↓
Sécurisation
   ↓
Diagnostic
   ↓
Décision de correction ou de rollback
   ↓
Validation
   ↓
Remise en service normale
   ↓
Documentation

L'ordre compte.

1. Détecter et noter les faits¶

Commencer par noter ce qui est observable :

heure approximative de début ;
pages ou services touchés ;
message d'erreur exact ;
dernier déploiement connu ;
dernier run ou traitement concerné ;
éventuelles alertes ;
périmètre marchand ou produit si identifiable.

Éviter les conclusions à ce stade.

Écrire « le frontend retourne HTTP 500 » est un fait. Écrire « MariaDB est cassée » est déjà une hypothèse tant qu'elle n'est pas vérifiée.

2. Vérifier l'état général¶

Depuis la racine du dépôt sur le VPS, le contrôle standard est :

make doctor

Ce contrôle aide à déterminer si l'incident est principalement lié :

au runtime Docker ;
à WordPress ;
au plugin ;
à MariaDB ;
à la documentation servie ;
ou à un autre contrôle runtime prévu par le projet.

Un PASS global n'exclut pas un problème métier. Il signifie seulement que les contrôles couverts par Doctor sont satisfaits.

3. Classer l'incident¶

Mineur¶

Le service principal fonctionne. L'impact est limité et il n'y a pas de risque immédiat pour les données.

Majeur¶

Une fonction importante est indisponible ou incorrecte. Une intervention rapide est nécessaire.

Critique¶

Le fonctionnement général, l'intégrité des données ou la capacité de reprise est menacé.

Dans un incident critique, la priorité n'est pas de « réparer vite » mais de ne pas empirer la situation.

4. Sécuriser avant de corriger¶

Selon l'incident, la sécurisation peut consister à :

arrêter ou suspendre une écriture problématique ;
empêcher un nouveau déploiement ;
éviter de relancer automatiquement un job qui corrompt des données ;
conserver les logs et identifiants de run ;
créer une sauvegarde de l'état dégradé lorsque cela est pertinent ;
noter le commit actuellement exécuté.

Ne pas supprimer des données « pour nettoyer » pendant le diagnostic.

5. Identifier la couche responsable¶

Utiliser le symptôme comme point de départ, puis remonter la chaîne.

Symptôme	Première zone à vérifier
Site totalement indisponible	Runtime / Docker / WordPress / réseau
Site disponible mais page incorrecte	Frontend puis projection puis données amont
Produits ou offres incorrects	Projection / Pipeline / règles métier
Synchronisation qui ne démarre pas	Runtime / worker / queue / activation du feed
Synchronisation qui démarre mais produit de mauvaises données	Pipeline / mapping / normalisation / règles métier
Données absentes en base	étape de persistance ou traitement amont
Forte lenteur	ressources, SQL, Pipeline, Runtime ou Frontend selon le contexte

Cette distinction évite de réparer le mauvais composant.

6. Rechercher la cause¶

Le guide détaillé est Dépannage.

La méthode reste :

faits → hypothèse → test → conclusion

Une hypothèse n'est pas validée parce qu'elle semble plausible.

Par exemple, si un déploiement vient d'avoir lieu, il est raisonnable de suspecter une régression. Il faut néanmoins comparer le comportement avec le commit précédent ou les métriques disponibles avant de conclure.

7. Choisir entre correction, reconstruction et rollback¶

Correction ciblée¶

À choisir lorsque la cause est identifiée, le périmètre est clair et le changement peut être validé proprement.

Reconstruction¶

À choisir lorsqu'une donnée dérivée est incorrecte mais que sa source de vérité reste saine.

Exemples : projection ou cache reconstructible.

Rollback du code¶

À choisir lorsqu'un déploiement récent provoque une régression et que revenir au commit stable est le moyen le plus sûr de rétablir le service.

Voir Déploiement.

Restauration de données¶

À réserver aux cas où les données de référence ou persistantes nécessitent réellement une restauration. C'est une opération sensible et potentiellement destructive.

Voir Sauvegarde et restauration et Reprise après incident.

8. Valider après correction¶

Une disparition visuelle du symptôme ne suffit pas.

Vérifier au minimum :

make doctor lorsque pertinent ;
les métriques et logs concernés ;
le comportement qui était en panne ;
le dernier run ou traitement associé ;
l'absence de nouveau symptôme ;
la cohérence des données touchées.

Pour une correction métier, vérifier également que les données dérivées ont été reconstruites si nécessaire.

9. Reprendre progressivement¶

Après un incident critique, ne pas tout réactiver d'un coup si plusieurs mécanismes ont été suspendus.

Réactiver progressivement :

les services techniques indispensables ;
les lectures ;
les traitements contrôlés ;
les écritures automatiques ;
les jobs ou feeds précédemment suspendus.

Contrôler l'état entre chaque étape.

10. Documenter l'incident¶

Pour un incident significatif, conserver au minimum :

date et heure ;
symptômes ;
impact ;
commit concerné ;
données ou runs concernés ;
cause réelle ;
hypothèses écartées lorsqu'elles ont demandé du temps ;
correction appliquée ;
commandes sensibles exécutées ;
validations réalisées ;
mesure préventive éventuelle.

Le but n'est pas de produire un rapport administratif. Le but est qu'une personne confrontée au même problème dans deux ans puisse comprendre ce qui s'est passé.

Ce qu'il ne faut jamais faire¶

Ne jamais :

modifier directement une projection pour masquer un problème amont ;
modifier le frontend pour dissimuler une incohérence métier ;
lancer plusieurs corrections simultanément sans pouvoir mesurer laquelle fonctionne ;
supprimer des logs ou données utiles au diagnostic ;
restaurer une base simplement parce qu'un produit est incorrect ;
redémarrer en boucle un traitement qui semble corrompre les données ;
considérer l'incident résolu sans validation ;
conserver un contournement temporaire comme solution permanente sans documentation.

Checklist courte en situation de stress¶

[ ] Noter les symptômes et l'heure
[ ] Noter le commit courant
[ ] Lancer les contrôles de lecture adaptés / make doctor
[ ] Évaluer le risque pour les données
[ ] Suspendre les écritures dangereuses si nécessaire
[ ] Préserver logs, runs et preuves
[ ] Identifier la couche responsable
[ ] Tester une hypothèse à la fois
[ ] Choisir correction, reconstruction ou rollback
[ ] Valider après intervention
[ ] Réactiver progressivement
[ ] Documenter l'incident