CMonChoix Engineering Standard (CES)¶

1. Une seule source de vérité¶

Chaque domaine critique possède une implémentation canonique : frontend, pipeline, documentation et déploiement. Une copie historique ne doit jamais concurrencer la version active.

2. Petits lots réversibles¶

Une PR ou un commit doit poursuivre un objectif principal, être compréhensible seul et pouvoir être annulé sans reconstruction complexe.

3. Tests avant refactoring¶

Avant de déplacer ou découper un comportement existant, ajouter des tests de caractérisation qui décrivent le contrat actuel. Le refactoring ne doit pas modifier ce contrat sans décision explicite.

4. Tests verts avant commit, merge et déploiement¶

Commande de référence :

composer test

Un test rouge bloque le commit final, le merge et le déploiement. Un correctif d’urgence doit être suivi immédiatement par un test empêchant la régression.

5. Validation adaptée au risque¶

PHP : syntaxe avec php -l et tests.
Frontend : tests, contrôle mobile/tablette/bureau et parcours utilisateur concerné.
Déploiement : workflow réussi et contrôle de santé.
Données : vérification des volumes, projections et résultats attendus.

6. Documentation synchronisée¶

Toute évolution structurante met à jour au moins l’un des éléments suivants : registre des composants, matrice de certification, dette technique, roadmap, ADR ou procédure d’exploitation.

7. Documentation à deux niveaux¶

Terme développeur : vocabulaire exact, chemins, hooks, dépendances et contrats.
Explication simple : rôle concret et risque expliqué sans connaissance du code.

8. Décisions d’architecture¶

Créer un ADR lorsqu’une décision :

définit une source de vérité ;
modifie les frontières d’un composant ;
introduit ou retire une technologie ;
change une règle durable de déploiement, stockage ou sécurité.

9. Definition of Done¶

Une évolution est terminée lorsque :

[ ] le besoin et le risque sont compris ;
[ ] les tests nécessaires existent et passent ;
[ ] la syntaxe et les contrôles statiques passent ;
[ ] le comportement est validé sur les vues concernées ;
[ ] le diff ne contient aucun changement parasite ;
[ ] la documentation est à jour ;
[ ] le registre et la certification sont mis à jour si le périmètre change ;
[ ] le déploiement et le rollback sont connus lorsqu’ils sont concernés.

10. Règles de sécurité opérationnelle¶

Ne jamais déployer depuis un état de tests rouges.
Ne jamais supprimer une copie supposée inutile sans vérifier les bind mounts et le chargement réel.
Ne jamais déplacer un module critique sans préserver le chargement direct utilisé par les tests et les outils.
Ne jamais inclure de secret, mot de passe ou clé dans Git.

Explication simple¶

On travaille toujours par petites étapes vérifiables. On protège d’abord ce qui fonctionne, on change ensuite, puis on documente exactement ce qui a été fait.