Maintenance de CMonChoix Platform¶

La maintenance sert à garder CMonChoix stable dans le temps. Elle ne consiste pas à « bricoler ce qui ne marche plus », mais à intervenir de façon ciblée, vérifiable et réversible.

À quoi sert la maintenance ?¶

Une plateforme qui fonctionne aujourd'hui peut se dégrader progressivement : données temporaires qui s'accumulent, projection devenue incohérente, conteneur instable, règle métier qui évolue, performances qui baissent.

La maintenance sert à :

prévenir les problèmes ;
corriger les anomalies à leur source ;
reconstruire proprement les données dérivées ;
accompagner les évolutions sans casser l'existant ;
conserver des procédures répétables et documentées.

Les trois types de maintenance¶

Préventive¶

Elle intervient avant qu'un incident ne soit visible.

Exemples : vérifier les sauvegardes, surveiller l'espace disque, contrôler les derniers runs, tester une restauration isolée.

Corrective¶

Elle intervient après détection d'une anomalie.

Exemple : une projection est incohérente. La bonne approche consiste à trouver pourquoi elle l'est, corriger la source puis la reconstruire.

Évolutive¶

Elle accompagne une amélioration du produit ou de l'architecture : nouveau marchand, nouvelle verticale, nouvelle projection, optimisation.

Elle doit respecter les mêmes contrôles que les autres maintenances.

La méthode standard¶

Toute maintenance sensible suit ce chemin :

Observer
   ↓
Comprendre
   ↓
Sauvegarder si nécessaire
   ↓
Appliquer un changement ciblé
   ↓
Valider
   ↓
Documenter

Pour l'infrastructure, la règle pratique est :

audit en lecture seule ;
sauvegarde ;
petit patch ciblé ;
validation ;
documentation.

Avant de toucher quoi que ce soit¶

Se poser les questions suivantes :

quel symptôme est observé ?
quelle couche est réellement responsable ?
est-ce une donnée source, une projection ou seulement un affichage ?
l'anomalie est-elle reproductible ?
un changement récent peut-il l'expliquer ?
peut-on reconstruire au lieu de modifier directement ?
faut-il une sauvegarde avant intervention ?

Si la cause est inconnue, utiliser d'abord Dépannage.

Reconstruire plutôt que corriger à la main¶

Certaines données sont dérivées : elles peuvent être recalculées depuis une source de vérité plus fondamentale.

C'est notamment le cas de certaines projections, caches ou structures de navigation.

Lorsqu'une donnée dérivée est fausse, il est généralement préférable de :

corriger la source
      ↓
relancer le mécanisme officiel
      ↓
reconstruire la donnée dérivée

Éditer directement la valeur finale peut masquer la cause et perdre la correction au prochain rebuild.

Commandes de validation importantes¶

Après une maintenance serveur ou une modification opérationnelle, les commandes versionnées du dépôt sont les références :

make doctor

Contrôle l'état global du Runtime et des services critiques.

Pour la sauvegarde :

CCX_BACKUP_ROOT=/chemin/absolu make backup

Puis :

BUNDLE=/chemin/du/bundle make backup-verify

Et pour vérifier réellement la restauration sans toucher à la production :

BUNDLE=/chemin/du/bundle make restore-check

Voir Sauvegarde et contrôle de restauration.

Maintenance Docker¶

Docker exécute les services de la plateforme dans des conteneurs.

Une réparation doit rester ciblée.

Si seul un worker est défaillant, il n'est pas nécessaire de recréer MariaDB, WordPress, Redis et tous les autres services.

Le principe est :

identifier le conteneur fautif
      ↓
conserver les preuves utiles
      ↓
appliquer la réparation minimale
      ↓
vérifier le service
      ↓
make doctor

Une recréation complète de tous les conteneurs ajoute inutilement du risque lorsqu'un seul composant est concerné.

Maintenance de la base de données¶

MariaDB est la base de production actuelle.

Une maintenance SQL mérite une attention particulière car une erreur peut modifier ou supprimer des données métier.

Avant toute écriture manuelle :

comprendre pourquoi les mécanismes officiels ne suffisent pas ;
disposer d'une sauvegarde vérifiée ;
connaître précisément les lignes concernées ;
préparer une requête de lecture équivalente ;
prévoir la validation après modification.

Une modification directe de production doit rester exceptionnelle.

Maintenance des projections¶

Une projection est une représentation dérivée destinée aux consommateurs du site.

Si elle paraît incohérente :

ne pas la corriger immédiatement à la main ;
vérifier les données amont ;
identifier le service ou builder responsable ;
corriger la cause ;
reconstruire ;
comparer avant/après.

Comment savoir qu'une maintenance est terminée ?¶

Une intervention n'est pas terminée lorsque la commande ne renvoie plus d'erreur.

Il faut vérifier :

que le symptôme initial a disparu ;
que le composant responsable fonctionne normalement ;
que les données dérivées sont cohérentes ;
qu'aucune autre partie n'a régressé ;
que les métriques et logs restent normaux ;
que la documentation reflète le changement.

Garde-fous¶

Ne jamais :

corriger une donnée finale sans comprendre sa source ;
modifier directement une projection si elle peut être reconstruite ;
contourner le Pipeline pour « aller plus vite » ;
corriger dans le Frontend une erreur produite en amont ;
lancer plusieurs réparations différentes en même temps ;
supprimer les preuves d'un incident avant la fin du diagnostic ;
considérer une optimisation comme prioritaire sur la stabilité.

Checklist simple¶

[ ] le problème ou le besoin est compris
[ ] la couche responsable est identifiée
[ ] une sauvegarde existe si l'opération peut écrire
[ ] le changement est le plus petit possible
[ ] la validation prévue est connue avant l'intervention
[ ] le résultat a été contrôlé après l'intervention
[ ] la documentation a été mise à jour si nécessaire