Pipeline¶
Statut¶
Document de design cible.
Ce document décrit l'architecture attendue du Pipeline dans CMonChoix Platform V2.
Il ne décrit pas nécessairement l'implémentation actuelle.
Les écarts avec l'implémentation actuelle sont suivis dans migration/.
Mission¶
Le Pipeline transforme des données brutes en données métier exploitables.
Il orchestre les différentes étapes de traitement sans contenir lui-même la logique métier profonde.
Dans l'état transitoire courant, l'agrégateur legacy includes/feeds-pipeline.php
est chargé via includes/bootstrap/pipeline.php uniquement dans les contextes
qui exécutent réellement le Pipeline. Le bootstrap runtime commun ne le charge
plus "au cas où".
Le même principe s'applique désormais au mapping technique legacy :
includes/feeds-mapping.php et includes/mapping/* passent par
includes/bootstrap/mapping.php, chargé par includes/bootstrap/pipeline.php
avant l'exécution effective du Pipeline.
La famille includes/quality/* ne fait pas partie du bootstrap commun du
Runtime ni du bootstrap normal du Pipeline. Elle est chargée via
includes/bootstrap/quality.php uniquement pour les audits, diagnostics et
health checks explicitement invoqués.
La capacité Strict suit désormais la même règle :
includes/strict/* ne font partie ni du bootstrap runtime commun ni du
bootstrap standard du Pipeline. Le loader includes/bootstrap/strict.php
n'est appelé que par les chemins gouvernance/strict explicites ; le loader
includes/bootstrap/strict-schema.php reste réservé aux entrées de schéma
explicites.
Les Vertical Modules suivent à présent le même modèle :
includes/bootstrap/verticals.php charge seulement le contrat/registry
vertical commun ; les fichiers includes/verticals/*/module.php sont
chargés uniquement à la demande par ccx_bootstrap_vertical_module().
Le bootstrap standard du Pipeline n'embarque donc plus toutes les verticales
simultanément.
La détection verticale légère est désormais séparée du chargement complet des
modules : ccx_v5_choose_vertical() s'appuie sur
includes/verticals/detection-registry.php et sur des fichiers
includes/verticals/*/detect.php purs. Le scoring garde exactement l'ordre,
les scores, les tie-breakers et le fallback du registry métier, mais sans
charger les module.php complets pendant cette phase.
Pourquoi ce composant existe¶
Les données provenant des marchands sont hétérogènes.
Le Pipeline existe pour :
- recevoir les données d'entrée
- appliquer les transformations successives
- préparer les objets métier
- déléguer les décisions au Domain Core et aux Vertical Modules
- produire des données cohérentes prêtes à être persistées
Responsabilités¶
Le Pipeline est responsable de :
- ingestion
- parsing
- validation technique
- normalisation contrôlée
- enrichissement
- préparation des candidats
- orchestration des étapes
- gestion des erreurs techniques
- traçabilité des traitements
Ce qui lui appartient¶
Appartiennent au Pipeline :
- étapes d'ingestion
- parsing
- mapping initial
- normalisation générique
- enrichissements techniques
- orchestration
- métriques de traitement
- gestion des erreurs techniques
Ce qui lui est interdit¶
Le Pipeline ne doit jamais contenir :
- logique métier profonde
- rendu frontend
- HTML
- accès utilisateur
- décisions humaines
- hacks marchands permanents
- logique SQL dispersée
- logique d'identité directement implémentée
- logique spécifique aux verticales
Dépendances autorisées¶
Le Pipeline peut dépendre de :
- Contracts
- Domain Core
- Vertical Modules
- Infrastructure
- Write Services
Dépendances interdites¶
Le Pipeline ne doit jamais dépendre de :
- Frontend
- Interfaces utilisateur
- Pages Admin
- Runtime interne
- Templates
- Hooks WordPress métier
- État global implicite
Entrées¶
Le Pipeline reçoit :
- fichiers feed
- flux API
- données normalisées intermédiaires
- configuration
- contexte d'exécution
Sorties¶
Le Pipeline produit :
- candidats
- objets métier
- identités enrichies
- projections
- événements techniques
- demandes d'écriture
Contrats utilisés¶
Le Pipeline s'appuie sur :
- Registry
- Vertical Descriptor
- Module Contract
- Identity Resolver
- Projection Builder
- Quality Scorer
- Write Service
Organisation cible¶
pipeline/
ingestion/
parsing/
validation/
normalization/
enrichment/
candidate-builder/
projection-builder/
quality/
orchestrator/
metrics/
errors/
Chaque étape possède une responsabilité unique.
Flux général¶
Feed
↓
Ingestion
↓
Parsing
↓
Validation
↓
Normalisation
↓
Enrichissement
↓
Candidate Builder
↓
Domain Core
↓
Vertical Module
↓
Projection Builder
↓
Write Services
Composants legacy qui migreront ici¶
Peuvent migrer après audit :
- parsing générique
- normalisations universelles
- enrichissements techniques
- orchestration
- métriques utiles
- gestion d'erreurs
Ne doivent pas migrer :
- hacks marchands
- SQL spécifiques
- patchs feed
- logique frontend
- logique métier dispersée
- scripts historiques
Ce qui ne doit jamais venir ici¶
Ne doivent jamais entrer dans le Pipeline :
- HTML
- CSS
- Templates
- Navigation
- Routing
- Décisions utilisateur
- Overrides humains
- Correctifs spécifiques à un marchand non généralisables
Critères de qualité¶
Un Pipeline est valide s'il est :
- modulaire
- traçable
- déterministe
- testable
- découpé par étapes
- sans logique frontend
- sans logique WordPress
- sans dépendance implicite
- documenté
État d'avancement¶
| Élément | Statut |
|---|---|
| Architecture définie | ✅ |
| Contrats existants | ✅ |
| Implémentation partielle | 🟡 |
| Implémentation complète | ⬜ |
| Migration legacy terminée | ⬜ |
| Suppression legacy associée | ⬜ |
Évolution future¶
Le Pipeline devra devenir un orchestrateur de traitements.
Il ne devra plus contenir directement les règles métier.
Chaque nouvelle étape devra être :
- indépendante
- testable
- remplaçable
- documentée
- observable
Toute logique métier devra être déléguée au Domain Core ou aux Vertical Modules.
Le Pipeline ne fait que coordonner les traitements.