Espace client
⚙️ NEXUS Recette · Testing
📋 Plan de recette 📊 Dashboard ▶️ Exécuter un test 🐞 Anomalies
v3 · 13 août 2026
Projet NEXUS · Phase de Recette

Plan de Recette & Gestion de Projet
Volet Testing

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.

Périmètre : NEXUS app · n8n · Supabase · Côté AXION : conception & exécution des tests · Côté MDC : validation métier — Pina & Cristina
◎

Vue d'ensemble — 4 volets en cascade

Chaque volet est un prérequis du suivant. On ne teste pas un flux sur des données fausses, ni un email sur un écran non validé.

🗄️ Volet 1 — Validation de la donnée

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.

🖥️ Volet 2 — Validation des écrans

Chaque écran NEXUS testé unitairement : affichage, saisie, validations, calculs, rôles admin/ops, responsive. On valide les composants avant de les enchaîner.

🔗 Volet 3 — Testing E2E des flux documentaires

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.

✉️ Volet 4 — Emails entrants & génération de documents

PDF fournisseurs reçus par email (parsing n8n, automatique). Côté client : NEXUS génère le PDF (devis/facture), l'utilisateur le télécharge et le classe lui-même — aucun email sortant automatique.

🧭
Principe directeur. Le volet 4 ne touche des tiers réels que côté entrant : l'automatisation du parsing des cotations fournisseurs reçues par email. Côté client, NEXUS génère un PDF que MDC télécharge et distribue comme aujourd'hui — aucun envoi automatique, donc aucun risque de délivrabilité ou d'email parti au mauvais destinataire sur ce volet. C'est pourquoi le passage en production du parsing entrant n'est jamais « big bang » : on bascule progressivement via un pilote puis 1 à 2 vagues maximum, avec un fonctionnement en parallèle (shadow) du process manuel existant pendant la phase pilote.
1

Validation de la donnée

Objectif : garantir que les référentiels et données migrées sont complets, cohérents, dédupliqués et conformes au modèle v11.0.

📦 Périmètre des données à valider

Référentiels maîtres

  • ProductType · Division · Category · Family
  • QualityLevel (00-03)
  • CustomsTariff (HS/TARES)
  • Incoterm · Country · Currency

Entités commerciales

  • Customer (TVA, SIREN/SIRET, Chorus Pro)
  • Supplier (remise, délai paiement)
  • Contact (commercial / logistique)
  • ShipTo (incoterm, carrier)

Catalogue & prix

  • Product + quality_suffix N/R
  • ProductSupplierCode / CustomerCode
  • PriceList (POA/POS + paliers)
  • SuggestedPrice (grille PVC)

🔍 Méthodes de contrôle

Contrôles automatiques (SQL / PRISM)

  • Unicité mdc_ref · format code v4.0 respecté
  • Aucune clé étrangère orpheline
  • Détection de doublons (cf. PRISM — 33-0025-01 vs 33-0050-01)
  • Complétude des champs obligatoires
  • Cohérence sémantique descriptions courtes (PRISM)

Revue métier (Cristina / Pina)

  • Échantillon représentatif par famille
  • Validation mapping codes fournisseurs / clients
  • Validation incoterms par client (DAP / FCA / EXW)
  • Validation prix de référence (POA) & PVC
🗳️
Point à trancher — atelier de jeudi. Ouverte à l'atelier 5 (02/04), la question QO-15 — Migration Legacy ST Crolles reste sans réponse : migre-t-on les données historiques ST Crolles dans NEXUS, ou pas ? Deux options : (a) migration — nécessite que Cristina transmette l'export (volume et format exacts inconnus à ce jour), ce qui conditionne le périmètre et le calendrier du volet 1 pour ces clients ; (b) pas de migration — ces commandes restent dans l'ancien système en archive, NEXUS démarre à blanc sur ce périmètre. Sans décision, le périmètre « clients ST Crolles » du volet 1 reste ouvert — à trancher avec Pina/Cristina jeudi.

🎯 Critères d'acceptation

0 doublon critique 0 FK orpheline 100 % champs obligatoires Format mdc_ref conforme Mapping codes validé par échantillon PRISM sans alerte rouge
2

Validation des écrans

Objectif : chaque écran NEXUS fonctionne unitairement — affichage, saisie, validations, calculs, droits d'accès — avant tout enchaînement de flux.

🖥️ Écrans dans le périmètre de recette

ÉcranModuleStatut maquetteRecette
Référentiels — Master DataAdminSpécifiéÉdition inline · tri/filtre · compteurs
Catalogue produitsAdminSpécifiéGénération code MDC · 4 sous-onglets · filtres
Screen 01 — Validate Supplier QuoteCotationCrééMatching produits AUTO/MANUEL/UNMATCHED
Screen 02 — Generate Customer QuoteCotationCrééCalcul marge · historique C&F · options
Screen 03 — Price ListCotationCrééHistorique POA/POS · paliers quantité
Screen 12 — Sourcing StrategyOrder Proc.CrééFROM STOCK / EX SUPPLIER / VIA MDC · stock
Financial ManagementFinanceV1 à retravaillerPOA/POS/GPM · débiteurs/créditeurs
Screens 00 · 10 · 11 · 13–19 · 90Order Proc.À créerRecette au fil de leur livraison

✅ Check-list de recette par écran

Fonctionnel

  • Cas nominal : affichage + saisie + sauvegarde
  • Cas limites : champs vides, valeurs extrêmes, caractères spéciaux
  • Validations : formats, champs obligatoires, messages d'erreur
  • Calculs : marge, PVC, TVA, totaux
  • Édition inline : persistance au blur/change

Transverse

  • Rôles : admin vs ops · respect des RLS Supabase
  • Tri & filtre colonnes · compteurs de lignes
  • Headers collants · sidebar active (scroll)
  • États vides & états de chargement
  • Responsive : sidebar masquée < 900px

🎯 Critères d'acceptation

Chaque écran passe sa check-list Édition inline persistée en base Cloisonnement des rôles vérifié Aucune erreur console bloquante
3

Testing E2E — Flux documentaires

Objectif : valider les chaînes complètes qui produisent les bons documents, avec les bons codes, incoterms et montants — pour tous les flux identifiés dans les BPMN.

🗺️ Les flux identifiés

BPMN 1 — Cotation

  • CAS 1 — RFQ simple, sans RMA ni cotation fournisseur
  • CAS 2 — avec cotation fournisseur liée (Q_Supplier_Quote_Switch)
  • CAS 3 — avec retour matériel / RMA pré-devis (Q_RMA_Switch)

BPMN 2 — Order Processing × 3 stratégies

  • FROM STOCK — depuis stock MDC
  • EX SUPPLIER — livraison directe fournisseur → client
  • VIA MDC — fournisseur → entrepôt MDC → client
  • Variantes switches : OP_Quotation · OP_RMA

🧪 Matrice de scénarios E2E

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énarioSourcingSwitchesIncotermDocuments attendusTest AXTest MDC
S1Cotation CAS 1 (RFQ simple)——EXW GenèveDevis client (vA)À tester—
S2Cotation CAS 2 (supplier quote)—Q_Supplier_Quote—Cotation fourn. importée → Devis clientÀ tester—
S3Cotation CAS 3 (RMA pré-devis)—Q_RMA—RMA → Devis clientÀ tester—
S4OP FROM STOCKFROM STOCK—EXW GenèveOC client · PRO_FORMA · CUSTOMER_INVOICEÀ tester—
S5OP EX SUPPLIER — ST MicroEX SUPPLIER—DAPPO fourn. · OC · DELIVERY_NOTICE · INVOICEÀ tester—
S6OP VIA MDC — SoitecVIA MDC—FCAPO fourn. · OC · PRO_FORMA · DELIVERY_NOTICE · INVOICEÀ tester—
S7OP importé depuis devisEX SUPPLIEROP_QuotationEXW GenèveDevis → OP · PO fourn. · OC · INVOICEÀ tester—
S8OP avec RMA post-POVIA MDCOP_RMAFCARMA 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é.

📄 Points de contrôle documentaires

Codes & documents

  • Devis / facture / OC / delivery notice → customer_ref
  • PO fournisseur → supplier_ref
  • PRO_FORMA = déclaration douanière CH
  • DELIVERY_NOTICE = livraisons intra-UE
  • CUSTOMER_INVOICE = facture après livraison

Cohérence métier

  • Incoterms : DAP = ST Micro · FCA = Soitec · EXW = autres
  • Transitions conformes à la machine d'états OP
  • Calculs marge · TVA par pays · droits de douane
  • StatusHistory : log immuable des transitions
  • Stock : OnHand / InTransit / Reserved / Available

🎯 Critères d'acceptation

8/8 scénarios produisent les documents attendus Codes corrects sur chaque document Incoterms & montants exacts Transitions de statut conformes
4

Emails entrants & génération de documents

Objectif : valider l'ingestion automatique des PDF fournisseurs reçus par email, et la génération/téléchargement des documents clients (devis, factures) en PDF. Pas d'envoi d'email automatique côté client — NEXUS produit le fichier, MDC le distribue.
📌
Choix produit confirmé (13/08). NEXUS n'enverra pas d'emails sortants automatiques aux clients. Pour un devis ou une facture, l'utilisateur clique sur « Télécharger », obtient le PDF, et le classe dans le dossier de son choix — typiquement son Dropbox local synchronisé, réglé une fois comme préférence utilisateur (voir ci-dessous). L'envoi au client reste un geste manuel de MDC, par le canal de son choix — comme aujourd'hui.

🔬 Phase A — En environnement de test (sandbox)

Boîte email de test dédiée, isolée des vrais interlocuteurs, pour le volet entrant. Aucun email réel n'est reçu d'un vrai fournisseur à ce stade.

📥 Emails entrants (ingestion)

  • Email + PDF cotation fournisseur → webhook n8n → parsing Claude
  • Création supplier_quotation + lignes
  • Matching codes produits automatique
  • Jeu de PDF varié : multi-lignes, formats fournisseurs différents, langues
  • Cas d'erreur : PDF illisible, format inattendu → fallback & alerte

📄 Génération & téléchargement PDF (sortant)

  • Génération PDF devis / facture depuis NEXUS, à la demande
  • Contenu conforme au document affiché dans NEXUS (mise en page, données, totaux)
  • Bouton « Télécharger » → fichier transmis au navigateur, nommage exploitable
  • Pas d'envoi automatique : l'utilisateur télécharge, range et transmet lui-même
  • Dossier de destination = préférence utilisateur (écran Profil NEXUS, NX-005) : chaque utilisateur pointe une fois vers son dossier Dropbox local synchronisé, les téléchargements suivants s'y écrivent directement sans reconfirmation
  • Contrainte navigateur : ce comportement dépend du File System Access API, disponible sur Chrome/Edge uniquement (l'utilisateur autorise l'accès une fois). Sur Safari/Firefox — non supporté — on retombe sur le téléchargement standard vers le dossier par défaut du navigateur, sans mémorisation possible

🚀 Phase B — En production (déploiement progressif)

La génération PDF est interne à NEXUS et ne touche aucun tiers : elle peut être activée directement, sans pilote ni vagues. Seul le parsing entrant (volet vraiment automatisé face à des tiers — les fournisseurs) suit le déploiement progressif détaillé dans Pilote & vagues ci-dessous. Pendant le pilote, le parsing automatique tourne en parallèle (shadow) de la saisie manuelle existante : on compare, on ne remplace pas encore.

🎯 Critères d'acceptation

Parsing PDF fiable sur jeu varié Fallback propre sur erreur de parsing PDF généré identique au document NEXUS Téléchargement fiable (navigateurs testés) Traçabilité des générations PDF
5

Déploiement en production — Pilote & vagues

Logique de bascule maîtrisée : 1 pilote, puis 1 à 2 vagues maximum. Chaque palier a des critères d'entrée/sortie (Go / No-Go).
P

Pilote

~2 semaines · shadow

1 fournisseur volontaire, faible volume. Le parsing automatique des cotations reçues par email tourne en parallèle de la saisie manuelle existante : on compare, sans risque.

Sortie / GoTaux de parsing OK · 0 incident sur les cotations traitées · matching produits fiable sur le périmètre pilote
1

Vague 1

~2–3 semaines

Extension à un sous-ensemble représentatif de fournisseurs. Supervision allégée, le parsing automatique devient le mode nominal sur ce périmètre.

Sortie / GoTaux d'erreur sous seuil · aucune réclamation · adoption équipe MDC (Cristina utilise NEXUS en mode principal)
2

Vague 2 (max)

généralisation

Généralisation à l'ensemble des fournisseurs. La saisie manuelle de secours est retirée une fois la vague stabilisée.

ClôtureCouverture complète · KPIs au vert · PV de recette signé · bascule définitive
📊
KPIs de passage de palier (Go / No-Go) — exemples à calibrer avec Pina/Cristina lors de l'atelier :
  • Taux de parsing réussi ≥ 90 % des cotations fournisseurs correctement extraites sans intervention manuelle
  • Taux d'erreur de matching codes produits ≤ 5 % des lignes nécessitant une correction manuelle
  • 0 incident bloquant sur le périmètre du palier en cours
  • Délai de traitement d'une cotation fournisseur ≤ délai actuel de saisie manuelle (cible indicative : -30 %)
  • Adoption équipe MDC : Cristina confirme utiliser NEXUS comme outil principal, sans repasser par la saisie manuelle en parallèle
Un palier ne s'ouvre que si le précédent est au vert sur l'ensemble de ces seuils.
6

Gouvernance & environnements

Qui fait quoi, sur quels environnements, avec quel outillage de suivi.

🗂️ Environnements

Test / Staging

  • Données de test & jeux de scénarios dédiés
  • Boîte email sandbox (aucun envoi réel)
  • Terrain de jeu des volets 1 → 4 phase A

Production

  • Données réelles · interlocuteurs réels
  • Activation emails par pilote & vagues uniquement
  • Process manuel maintenu en secours pendant le pilote

👥 Rôles & responsabilités (RACI simplifié)

ActivitéAXIONMDC (Pina / Cristina)
Conception des cas de test & jeux de donnéesResponsableConsulté
Exécution technique des testsResponsableInformé
Fourniture des données réelles (référentiels, Legacy)ConsultéResponsable
Validation métier (échantillons, incoterms, prix)ConsultéResponsable
Correction des anomaliesResponsableInformé
Décision Go / No-Go de chaque palierCo-décisionCo-décision
Recette finale & PV de recetteConsultéApprobateur

🛠️ Outillage de suivi

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.

7

Architecture de l'outillage de recette

Système de référence : une base Notion sous Admin, pilotée par des écrans d'exécution type Jira. Présenté aujourd'hui comme cible — à construire après validation de la méthodologie.

🧩 Principe — base Notion + écrans d'exécution

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.

🖥️ Écrans de recette
Module Admin NEXUS · saisie des testscripts, exécution, statuts, dates, owners · upload screenshots / documents
⇄ API Notion ⇄
🗄️ Base Notion « Recette NEXUS »
Sous Admin · système de référence · testscripts, exécutions, anomalies, campagnes

🗄️ Bases Notion liées

BaseRôleChamps clés
Test ScriptsRéférentiel des cas de testid · titre · volet (1-4) · écran/flux lié · préconditions · étapes · résultat attendu · priorité (P0-P2)
ExécutionsRuns 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
AnomaliesBugs & écarts→ Exécution · sévérité (Bloquant/Majeur/Mineur) · description · statut · owner correction · date
CampagnesRegroupement par vague / environnementnom (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.

✌️
Double validation — AXION puis MDC. AXION réalise le test technique en environnement de test ; le statut Test MDC ne s'ouvre que lorsque le Test AXION est « Réussi ». MDC effectue alors la recette métier (Validé / Rejeté). Un test n'est « passé » que si Test AXION = Réussi ET Test MDC = Validé — un rejet MDC rouvre le cycle côté AXION.

🖥️ Écrans d'exécution

Dashboard Ouvrir →

  • KPIs globaux + avancement par volet (AXION / MDC)
  • Table des anomalies filtrable (type, statut, sévérité)
  • Statut des 4 campagnes (Recette interne / Pilote / Vague 1 / Vague 2)

Exécution de test Ouvrir →

  • File d'exécutions + démarrage depuis un test script du catalogue
  • Affiche le testscript : préconditions, étapes, attendu
  • Double statut AXION / MDC avec séquencement imposé
  • Création d'anomalie liée en un clic

Signalement d'anomalie Ouvrir →

  • Formulaire MDC : type PR/ER, sévérité, description
  • Jeu de données de reproduction en texte libre
  • Captures d'écran / PDF joints (upload direct vers Notion)

Base Notion « Recette NEXUS »

  • 4 tables : Test Scripts · Exécutions · Anomalies · Campagnes
  • Owners = email CF-Access, jamais saisis à la main
  • Formalisable plus tard dans NEXUS si le besoin devient récurrent
🧠
Statut au 13 août 2026. Les 4 tables Notion sont créées, le catalogue de tests initial est peuplé (référentiel, écrans, les étapes du Detail Map BPMN2, les 8 scénarios E2E, les tests emails & documents), et les 3 écrans portail (dashboard, exécution, signalement) lisent/écrivent en direct via l'API Notion. Le volet 4 a été recadré (pas d'envoi automatique — génération PDF + téléchargement) et la navigation entre les 4 écrans a été unifiée. Reste à faire : dérouler les premières exécutions AXION avec Pina/Cristina lors de l'atelier, puis lancer la campagne « Recette interne ».
📦

Livrables de la phase de recette

Ce que MDC reçoit à l'issue de chaque volet.
LivrableVoletContenu
Rapport qualité des données1Contrôles automatiques + PRISM + check-list métier · registre d'anomalies données
Cahiers de recette par écran2Check-list passée pour chaque écran · matrice rôles admin/ops
Cahier de recette E2E + jeux de test3Matrice scénarios × documents · jeux de données rejouables
Rapport d'intégration emails4Résultats sandbox entrée/sortie · délivrabilité · cas d'erreur
Runbook de déploiement5Procédure pilote & vagues · KPIs Go/No-Go · plan de repli
PV de recettefinalProcès-verbal signé MDC actant la mise en production
🗓️

Enchaînement & jalons

Séquence indicative — les volets 1 et 2 peuvent se chevaucher partiellement ; le volet 4 phase B (prod) ne démarre qu'après validation complète de la sandbox.
Jalon 1 · Volet Donnée
Référentiels & catalogue validés
Contrôles automatiques + revue métier · dépend de l'export Legacy ST Crolles (A-06-14)
Jalon 2 · Volet Écrans
Écrans existants recettés
Référentiels · Catalogue · Screens 01/02/03/12 · Financial Management (après refonte V2)
Jalon 3 · Volet Flux E2E
8 scénarios documentaires validés
Cotation CAS 1/2/3 + Order Processing × 3 sourcings · contrôle documents/codes/incoterms
Jalon 4 · Emails sandbox
Intégration emails validée en test
Entrée (parsing PDF) + sortie (émission) · délivrabilité
Jalon 5 · Pilote prod
Bascule pilote en shadow
1 interlocuteur contrôlé · ~2 semaines · Go/No-Go
Jalon 6 · Vagues 1 → 2
Généralisation & PV de recette
Vague 1 (sous-ensemble) → Vague 2 (généralisation) · clôture & bascule définitive
💬
Atelier dédié recette — Pina & Cristina. (1) Confirmer le fournisseur pilote · (2) caler les seuils KPIs Go/No-Go · (3) trancher la migration ST Crolles (QO-15). Périmètre : ce plan couvre le testing ; il s'étendra aux écrans restants au fil de leur livraison. Formation = continue via les ateliers. Support post-prod = déjà contractualisé (maintenance mensuelle).