Aller au contenu

ADR-000 — Principes fondateurs de CMonChoix Engineering

  • Statut : accepté
  • Date : 2026-08-06
  • Portée : tout le dépôt et l’exploitation de la plateforme

Contexte

CMonChoix combine WordPress, un plugin industriel, des projections de données, un pipeline marchand, Docker, GitHub Actions et une documentation destinée à être transmise. Des corrections successives peuvent créer des doublons, des frontières floues ou plusieurs sources concurrentes.

Décision

Le projet adopte les principes suivants :

  1. Une seule source de vérité par domaine critique.
  2. Petits lots ciblés et réversibles.
  3. Tests de caractérisation avant refactoring d’un comportement existant.
  4. Tests verts avant merge et déploiement.
  5. Validation visuelle obligatoire pour les changements frontend sensibles.
  6. Documentation synchronisée avec le code.
  7. ADR pour les décisions structurantes.
  8. Registre et certification par composant, pas seulement par fichier.
  9. Audits reproductibles plutôt que constats informels.
  10. Documentation à deux niveaux : technique et explication simple.

Conséquences positives

  • Les régressions sont plus faciles à détecter et à attribuer.
  • Les décisions ne dépendent plus uniquement de la mémoire des personnes.
  • Un futur développeur ou repreneur sait où intervenir.
  • Les refactorings restent contrôlés et mesurables.

Contraintes acceptées

  • Certaines évolutions prendront plus de temps car tests et documentation sont obligatoires.
  • Une architecture modulaire peut ajouter des fichiers, mais chaque fichier doit avoir une responsabilité justifiée.
  • La certification reste factuelle : elle exige des preuves, pas une impression générale.

Alternatives rejetées

Refactoriser rapidement puis tester après

Rejeté car cette méthode a un risque élevé sur le frontend et les chemins de chargement WordPress.

Conserver la connaissance uniquement dans les conversations

Rejeté car elle serait difficile à retrouver, à versionner et à transmettre.

Créer une documentation exhaustive en une seule fois

Rejeté car elle vieillirait vite. La documentation doit progresser par lots avec le code réel.

Explication simple

Cette décision fixe les règles du jeu : on protège ce qui fonctionne, on change une petite chose à la fois, on vérifie, puis on explique ce qui a été fait pour que personne n’ait à deviner plus tard.