Aller au contenu

Platform Certification Overview

Status: NORMATIVE / GOVERNANCE

Objet

Cette page définit ce que signifie « certifié » dans CMonChoix Platform.

Une certification est une preuve reproductible qu'un contrat, une frontière ou un comportement est respecté dans une révision donnée. La documentation seule n'est jamais suffisante pour certifier un comportement Runtime.

Hiérarchie des preuves

Selon le sujet, une certification doit combiner les preuves pertinentes :

  1. contrat/documentation normative ;
  2. code réellement chargé ;
  3. tests automatiques ;
  4. tests d'architecture/guards ;
  5. fixtures ou datasets représentatifs ;
  6. comportement Runtime lorsque la frontière le nécessite ;
  7. métriques avant/après pour performance ou données ;
  8. procédure de recovery/rollback pour les mutations risquées.

Une ancienne certification ne prouve pas que le même comportement est encore vrai après modification du périmètre.

Statuts

  • FOUNDATION : fondation architecturale ou contractuelle présente mais portée Runtime non certifiée ;
  • IMPROVE : base substantielle mais gap objectif restant ;
  • CERTIFIED : contrat prouvé dans le scope et la révision déclarés ;
  • HISTORICAL : ancienne preuve conservée pour contexte ;
  • DEPRECATED : certification ou voie qui ne doit plus guider de nouvelles évolutions.

Règle de scope

Toute certification indique clairement :

  • ce qui est certifié ;
  • ce qui ne l'est pas ;
  • la révision ou branche ;
  • les tests/commandes exécutés ;
  • les fixtures/données utilisées ;
  • les limitations connues ;
  • les critères qui obligeraient à revalider.

Éviter les formulations globales telles que « la plateforme est certifiée » lorsqu'un seul composant a été contrôlé.

Certification architecturale

Une frontière critique doit être protégée par un test ou guard automatisé lorsque possible.

Exemples :

  • Domain sans WordPress ;
  • Application sans WordPress/SQL concret ;
  • Read Service read-only ;
  • absence de dépendance interdite ;
  • projection builder sans persistance ;
  • wrapper de compatibilité sans nouvelle logique métier.

Certification Platform sans WordPress

C'est une certification structurante de la roadmap.

Précondition

Le scénario de certification ne charge :

  • ni WordPress ;
  • ni le plugin ccx-feeds-industrial ;
  • ni ABSPATH ;
  • ni fonctions wp_* ;
  • ni $wpdb.

Scénario minimal cible

merchant fixture
      ↓
ingestion
      ↓
normalization
      ↓
classification
      ↓
identity resolution
      ↓
quality/business decisions
      ↓
persistence port or in-memory certified adapter
      ↓
projection

Le scénario doit démontrer un résultat déterministe et auditable.

Critère PASS

La même logique métier critique utilisée en production peut être exécutée sans WordPress, via les contrats Platform.

Critère FAIL

La certification échoue si une étape métier exige :

  • ABSPATH ;
  • un hook WordPress ;
  • $wpdb directement dans Domain/Application ;
  • une fonction métier définie uniquement dans le plugin ;
  • le bootstrap WordPress pour charger une règle ;
  • une décision recalculée dans un adapter WordPress.

Certification multi-marchands

Un onboarding marchand n'est pas certifié uniquement parce qu'un feed se télécharge.

Il doit notamment vérifier :

  • adapter/configuration isolés ;
  • mapping source documenté ;
  • fixtures représentatives ;
  • normalisation correcte ;
  • classification/identity contrôlées ;
  • erreurs et reason codes compris ;
  • idempotence/replay lorsque pertinent ;
  • projections cohérentes ;
  • absence d'impact anormal sur les autres marchands ;
  • métriques opérationnelles disponibles.

Certification refresh incrémental

Un refresh scoped est certifié lorsqu'il est démontré que :

incremental final state == canonical full-rebuild final state

sur les cas représentatifs, y compris :

  • ajout ;
  • modification ;
  • suppression/disparition ;
  • changement d'identité ;
  • retry après erreur post-commit ;
  • concurrence/locks lorsque concernés.

Le full rebuild reste un mécanisme de recovery même après certification de l'incrémental.

Certification performance/capacité

Une optimisation ou une capacité VPS n'est pas certifiée sans baseline reproductible.

Une preuve doit inclure :

  • version de code/config ;
  • volume ;
  • taux de changement ;
  • durée ;
  • débit ;
  • CPU ;
  • RAM ;
  • I/O ;
  • DB latency ;
  • projection lag ;
  • erreurs ;
  • résultat métier avant/après.

Certification backup / restore

Un backup réussi ne certifie pas le disaster recovery.

La certification nécessite un exercice de restauration contrôlé qui vérifie :

  • intégrité du bundle ;
  • capacité à restaurer ;
  • démarrage du service restauré ;
  • cohérence minimale des données ;
  • reconstruction des projections si nécessaire ;
  • durée observée comparée à l'objectif RTO lorsqu'il existe.

Documentation et CURRENT

Une certification doit mettre à jour les documents CURRENT affectés.

Une page HISTORICAL peut conserver une preuve passée, mais ne doit jamais remplacer la description du comportement courant.

Règle de réouverture

Une certification doit être revalidée si un changement touche :

  • son contrat ;
  • ses dépendances ;
  • son chemin Runtime ;
  • son format de donnée ;
  • sa persistance ;
  • ses invariants ;
  • son comportement d'échec/retry ;
  • un élément explicitement déclaré dans son scope.

Règle de patch

Une certification ne doit pas encourager les gros changements non reliés. Corriger le gap objectif, prouver le résultat, puis réauditer le scope.

Références