Aller au contenu

Matrice de certification

Statut : HISTORICAL / OUTIL DE CERTIFICATION

Cette page conserve un instantané de maturité utilisé pendant l’industrialisation de CMonChoix Platform.

Elle ne doit pas être lue comme l’état CURRENT du Runtime. Un composant ne reste pas « certifié » par simple héritage documentaire : son état dépend d’une révision, de tests, d’audits et de preuves reproductibles.

Pourquoi conserver cette matrice

Cette matrice reste utile pour comprendre :

  • comment la plateforme a évalué la maturité de ses composants ;
  • quels axes étaient vérifiés ;
  • quelles preuves étaient attendues avant de déclarer un composant stable ;
  • comment reconstruire une certification sur une nouvelle révision.

Elle ne remplace ni l’observation du dépôt, ni les tests, ni l’état Runtime réellement déployé.

Légende historique

  • 🟢 Certifié : responsabilité claire, tests verts, documentation suffisante et validation connue sur le périmètre évalué.
  • 🟡 En industrialisation : composant fonctionnel ou partiellement protégé, mais preuves encore incomplètes.
  • 🔴 À auditer : composant critique sans niveau de preuve suffisant.

Instantané conservé

Composant Architecture Tests Documentation Validation État historique
Galerie produit ✅ ✅ ✅ ✅ 🟢
Variantes produit ✅ ✅ ✅ ✅ 🟢
SEO et routage ✅ ✅ ✅ ✅ 🟢
Scripts de filtres ✅ ✅ ✅ ✅ 🟢
Filtres mobiles AJAX ✅ ✅ 🟡 ✅ 🟡
Catalogue frontend 🟡 ✅ 🟡 ✅ 🟡
Fiche produit 🟡 ✅ 🟡 ✅ 🟡
Projections frontend 🟡 ✅ 🟡 ✅ 🟡
Backend catalogue 🟡 ✅ 🟡 🟡 🟡
Pipeline marchand 🟡 🟡 🟡 🟡 🟡
Docker / VPS 🟡 🟡 🟡 ✅ 🟡
Déploiement GitHub Actions ✅ ✅ ✅ ✅ 🟢
Sauvegardes et reprise 🟡 🟡 🟡 🟡 🟡
Documentation de transmission 🟡 — 🟡 🟡 🟡

Ces couleurs décrivent l’instantané historique ci-dessus. Elles ne certifient pas automatiquement la révision actuellement déployée.

Comment certifier un composant aujourd’hui

Une certification CURRENT doit rattacher explicitement :

  1. la révision Git évaluée ;
  2. le composant et sa responsabilité ;
  3. sa source de vérité ;
  4. les tests exécutés ;
  5. les audits ou diagnostics exécutés ;
  6. les résultats observés ;
  7. les limites ou risques connus ;
  8. la documentation correspondante ;
  9. la procédure de rollback ou de reprise lorsqu’elle est pertinente.

Un statut de certification sans ces éléments est une opinion, pas une preuve.

Critères de maturité réutilisables

Les critères historiques restent pertinents comme grille de travail :

  • responsabilité et source de vérité clairement identifiées ;
  • tests ou contrôles reproductibles adaptés au risque ;
  • documentation technique et explication opérateur ;
  • procédure de validation connue ;
  • absence de duplication active injustifiée ;
  • risques et limites connus documentés.

La grille doit cependant être enrichie par les invariants actuels de la Platform :

  • Domain Core générique ;
  • Vertical Modules isolés ;
  • Read Services strictement read-only ;
  • Write Services explicites ;
  • Runtime orchestrateur, non décideur ;
  • Frontend consommateur de projections ;
  • statuts resolved / unknown / ambiguous / conflict préservés ;
  • observation et audit avant mutation ;
  • projections dérivées et reconstruisibles, jamais source de vérité métier.

Règle de mise à jour

Ne jamais modifier cette page pour « remettre du vert » à partir d’une impression générale.

Pour une nouvelle certification :

  • produire d’abord les preuves ;
  • préciser la révision ;
  • conserver le rapport ou l’audit correspondant ;
  • documenter les écarts ;
  • seulement ensuite publier l’état de maturité.

Si la matrice devient un jour un tableau CURRENT, elle devra porter une date, une révision et des liens vers les preuves de chaque ligne.

Voir aussi