Stratégie de validation de bout en bout du système NEXUS (Order Processing & Cotation) avant et après mise en production. Quatre volets de recette en cascade — donnée → écrans → flux documentaires → emails — puis un déploiement maîtrisé en production selon une logique pilote + vagues.
Référentiels, catalogue produits, mappings codes, migration Legacy ST Crolles. Fondation : sans données propres, rien d'autre n'est testable de façon fiable.
Chaque écran NEXUS testé unitairement : affichage, saisie, validations, calculs, rôles admin/ops, responsive. On valide les composants avant de les enchaîner.
Scénarios complets Cotation (CAS 1/2/3) + Order Processing (FROM STOCK / EX SUPPLIER / VIA MDC), avec contrôle des documents générés, codes affichés, incoterms et montants.
PDF fournisseurs reçus par email (parsing n8n) + documents clients émis par email. Testés d'abord en environnement de test, puis activés en prod par pilote & vagues.
| Écran | Module | Statut maquette | Recette |
|---|---|---|---|
| Référentiels — Master Data | Admin | Spécifié | Édition inline · tri/filtre · compteurs |
| Catalogue produits | Admin | Spécifié | Génération code MDC · 4 sous-onglets · filtres |
| Screen 01 — Validate Supplier Quote | Cotation | Créé | Matching produits AUTO/MANUEL/UNMATCHED |
| Screen 02 — Generate Customer Quote | Cotation | Créé | Calcul marge · historique C&F · options |
| Screen 03 — Price List | Cotation | Créé | Historique POA/POS · paliers quantité |
| Screen 12 — Sourcing Strategy | Order Proc. | Créé | FROM STOCK / EX SUPPLIER / VIA MDC · stock |
| Financial Management | Finance | V1 à retravailler | POA/POS/GPM · débiteurs/créditeurs |
| Screens 00 · 10 · 11 · 13–19 · 90 | Order Proc. | À créer | Recette au fil de leur livraison |
Chaque scénario est rejoué sur un jeu de données de test dédié et vérifie : transitions de statut, documents générés, codes affichés, incoterm et montants.
| # | Scénario | Sourcing | Switches | Incoterm | Documents attendus | Test AX | Test MDC |
|---|---|---|---|---|---|---|---|
| S1 | Cotation CAS 1 (RFQ simple) | — | — | EXW Genève | Devis client (vA) | À tester | — |
| S2 | Cotation CAS 2 (supplier quote) | — | Q_Supplier_Quote | — | Cotation fourn. importée → Devis client | À tester | — |
| S3 | Cotation CAS 3 (RMA pré-devis) | — | Q_RMA | — | RMA → Devis client | À tester | — |
| S4 | OP FROM STOCK | FROM STOCK | — | EXW Genève | OC client · PRO_FORMA · CUSTOMER_INVOICE | À tester | — |
| S5 | OP EX SUPPLIER — ST Micro | EX SUPPLIER | — | DAP | PO fourn. · OC · DELIVERY_NOTICE · INVOICE | À tester | — |
| S6 | OP VIA MDC — Soitec | VIA MDC | — | FCA | PO fourn. · OC · PRO_FORMA · DELIVERY_NOTICE · INVOICE | À tester | — |
| S7 | OP importé depuis devis | EX SUPPLIER | OP_Quotation | EXW Genève | Devis → OP · PO fourn. · OC · INVOICE | À tester | — |
| S8 | OP avec RMA post-PO | VIA MDC | OP_RMA | FCA | RMA post-PO · documents retour | À tester | — |
Chaque scénario reçoit un statut Test AX puis un statut Test MDC — état initial « À tester ». Le suivi vit dans la base Notion ; le test passe quand AX = Réussi ET MDC = Validé.
Boîte email de test dédiée, isolée des vrais interlocuteurs. Aucun email réel n'est envoyé à un client ou un fournisseur à ce stade.
Une fois la sandbox validée, l'activation en production se fait par paliers maîtrisés — voir Pilote & vagues ci-dessous. Pendant le pilote, l'email automatique tourne en parallèle (shadow) du process manuel : on compare, on ne remplace pas encore.
1 interlocuteur contrôlé et tolérant (un fournisseur ou client volontaire), faible volume. L'automatisation tourne en parallèle du process manuel : on valide sans risque.
Extension à un sous-ensemble représentatif (ex. fournisseurs principaux + clients EXW Genève). Supervision allégée, l'automatisation devient le mode nominal sur ce périmètre.
Généralisation au reste du périmètre (clients DAP / FCA, tous fournisseurs). Le process manuel de secours est retiré une fois la vague stabilisée.
| Activité | AXION | MDC (Pina / Cristina) |
|---|---|---|
| Conception des cas de test & jeux de données | Responsable | Consulté |
| Exécution technique des tests | Responsable | Informé |
| Fourniture des données réelles (référentiels, Legacy) | Consulté | Responsable |
| Validation métier (échantillons, incoterms, prix) | Consulté | Responsable |
| Correction des anomalies | Responsable | Informé |
| Décision Go / No-Go de chaque palier | Co-décision | Co-décision |
| Recette finale & PV de recette | Consulté | Approbateur |
Le suivi de recette (testscripts, exécutions, statuts, dates, owners, pièces jointes) est centralisé dans une base Notion sous Admin, pilotée via des écrans d'exécution dédiés — voir Architecture de l'outillage ci-dessous.
La base Notion « Recette NEXUS » est le system of record de toute la recette. Les écrans (module Admin) lisent et écrivent dans cette base via l'API Notion : c'est par eux que se fait l'exécution des tests — saisie du résultat, changement de statut, attache de screenshots ou de documents générés.
| Base | Rôle | Champs clés |
|---|---|---|
| Test Scripts | Référentiel des cas de test | id · titre · volet (1-4) · écran/flux lié · préconditions · étapes · résultat attendu · priorité (P0-P2) |
| Exécutions | Runs de test (≈ Jira / Xray) | → Test Script · campagne/vague · statut Test AXION (+owner +date) · statut Test MDC (+owner +date) · résultat obtenu · pièces jointes · → anomalie |
| Anomalies | Bugs & écarts | → Exécution · sévérité (Bloquant/Majeur/Mineur) · description · statut · owner correction · date |
| Campagnes | Regroupement par vague / environnement | nom (Recette interne / Pilote / Vague 1 / Vague 2) · environnement (Test/Prod) · période · décision Go/No-Go |
Chaque test porte deux statuts indépendants :
Test AXION À tester En cours Réussi Échoué Bloqué
Test MDC À valider Validé Rejeté
Les owners exploitent la propriété Personne native de Notion.
| Livrable | Volet | Contenu |
|---|---|---|
| Rapport qualité des données | 1 | Contrôles automatiques + PRISM + check-list métier · registre d'anomalies données |
| Cahiers de recette par écran | 2 | Check-list passée pour chaque écran · matrice rôles admin/ops |
| Cahier de recette E2E + jeux de test | 3 | Matrice scénarios × documents · jeux de données rejouables |
| Rapport d'intégration emails | 4 | Résultats sandbox entrée/sortie · délivrabilité · cas d'erreur |
| Runbook de déploiement | 5 | Procédure pilote & vagues · KPIs Go/No-Go · plan de repli |
| PV de recette | final | Procès-verbal signé MDC actant la mise en production |