Architecture du pipeline¶

Rôle¶

Le pipeline transforme les données d’offres en données normalisées prêtes pour le catalogue. Son architecture cible sépare strictement orchestration, étapes transversales, catégories produit et spécificités marchands.

État actuel¶

Le point d’entrée historique est :

plugins/ccx-feeds-industrial/includes/pipeline/90-offers-norm.php

Ce fichier reste encore monolithique, mais les premières extractions existent :

norm/stages/50-quality.php
norm/stages/60-final-status.php

Architecture cible¶

includes/pipeline/norm/
├── contracts/
│   ├── context.php
│   └── stage-result.php
├── runner/
│   └── stage-runner.php
├── registry/
│   ├── stages.php
│   ├── categories.php
│   └── merchants.php
├── stages/
│   ├── 10-core.php
│   ├── 20-routing.php
│   ├── 40-enrichment.php
│   ├── 50-quality.php
│   └── 60-final-status.php
├── categories/
├── merchants/
└── metrics/

Responsabilités¶

Orchestrateur¶

L’orchestrateur :

crée le contexte ;
charge le registre ;
exécute les stages dans l’ordre ;
collecte les métriques ;
propage les erreurs.

Il ne contient aucune règle SQL métier.

Stages¶

Les stages couvrent les traitements transversaux :

normalisation de base ;
routage ;
enrichissement ;
qualité ;
statut final.

Un stage transversal ne doit pas contenir d’exception propre à un marchand.

Catégories¶

Les règles génériques d’une famille produit vivent dans :

norm/categories/<categorie>/

Exemples : smartphone, tablette, TV, gaming, imprimante, électroménager.

Marchands¶

Les exceptions spécifiques vivent dans :

norm/merchants/<marchand>/

Un marchand doit pouvoir être retiré via son module et son enregistrement, sans chirurgie dans l’orchestrateur.

Contexte partagé¶

Le contexte minimal contient :

connexion WordPress DB ;
source_feed ;
run_id ;
table normalisée ;
configuration du run ;
collecteur de métriques.

Le contexte ne doit pas devenir un conteneur global fourre-tout.

Métriques¶

Chaque stage doit pouvoir remonter :

nom du stage ;
durée en millisecondes ;
mémoire avant/après ;
lignes affectées ;
statut ;
message d’erreur éventuel.

Les métriques doivent rester légères pour ne pas pénaliser le VPS.

Ordre d’exécution¶

L’ordre est explicite et versionné dans le registre des stages. Aucun auto-discovery implicite n’est requis tant qu’il n’apporte pas une valeur démontrée.

Règles SQL¶

Filtrer par source_feed et run_id lorsque pertinent.
Utiliser les requêtes préparées.
Éviter les scans complets répétés.
Regrouper uniquement les requêtes qui partagent réellement la même responsabilité.
Préférer SQL aux boucles PHP ligne par ligne pour les opérations de masse.

Migration progressive¶

Extraire les blocs autonomes.
Conserver strictement l’ordre d’exécution.
Valider tests et audits.
Documenter le nouveau composant.
Raccorder au runner.
Supprimer l’ancien code seulement après validation.

Critères de réussite de Pipeline v2¶

90-offers-norm.php devient un orchestrateur léger.
Les stages sont enregistrés.
Les catégories et marchands sont isolés.
Les métriques sont disponibles.
Les tests et audits restent verts.
Aucun nouveau bloc métier n’est ajouté au point d’entrée historique.