Compte rendu officiel

Revue du Modèle de Données — Projet NEXUS

Atelier sur site du 5 mars 2026. Finalisation à 99% du modèle de données pour les processus Quotation et Order Processing. Décisions clés sur la codification produit, la granularité client, la gestion des remises et le versioning des cotations.
Date 5 mars 2026
Type Atelier sur site (présentiel)
Durée ~3 heures
Avancement modèle 99% validé
Prochain atelier Mardi 17 mars 2026 — 9h00
Sébastien Fournier
AXION — Architecte projet
Djemel Chaouche
AXION — Tech lead
Pina Pellegrini
MDC Europe — Direction / Commerce
Cristina Colucci
MDC Europe — Opérations
📋
RÉSUMÉ

Résumé exécutif

L'atelier du 5 mars a permis de valider l'intégralité des flux BPMN Quotation et Order Processing à 99%. Les décisions majeures portent sur la codification interne des produits MDC (structure MDC-TYPE-ATELIER-SEQ-QUALITÉ), la granularité client (chaque entité juridique = 1 Customer distinct, discriminant = numéro de TVA), la gestion automatique des remises fournisseurs et le versioning des cotations (suffixes A/B/C). Le processus PDF en deux étapes (extraction auto + validation humaine) est confirmé comme principe fondamental du système.

13
Décisions actées
7
Questions ouvertes
16
Actions à suivre
99%
Modèle validé
✅
01

Décisions actées

A — Flux de cotation

NEXUS démarre toujours par la réception d'un PDF
ACTÉ
Il n'existe pas d'initiation "from scratch" sans document source. Trois cas d'entrée sont définis :
  • CAS 1 — RMA interne : génération d'un RMA en interne → crée le dossier cotation (statut DRAFT, Q_RMA_Switch = Yes)
  • CAS 2 — Cotation fournisseur reçue : PDF reçu par mail → extraction auto n8n → dossier cotation (statut Supplier Quote Received)
  • CAS 3 — Création manuelle : l'utilisateur dispose de toutes les informations et crée directement la cotation (modalités écran à préciser)
Impact modèle : Confirme la logique existante. CAS 3 à modéliser en détail dans la spec écran.
Tout PDF reçu → 2 étapes obligatoires
ACTÉ
  • Étape 1 (auto) : l'outil charge le PDF, identifie le type de document, extrait les données (fournisseur, lignes, prix, délais...)
  • Étape 2 (humain) : l'utilisateur valide ou corrige les données extraites avant toute mise à jour du système
Rien ne se valide automatiquement sans intervention humaine. Principe fondamental de NEXUS.
Impact modèle : Confirme les statuts intermédiaires "RECEIVED" → "VALIDATED" sur SupplierQuotation.
L'envoi de la demande au fournisseur est hors NEXUS
ACTÉ
NEXUS ne gère pas l'envoi de la demande de cotation au fournisseur (fait par mail, hors système). NEXUS intervient à la réception de la réponse PDF du fournisseur.

B — Versioning des cotations

Nouvelles versions déclenchées par : expiration ou mise en conformité PO
ACTÉ
  • Suffixes alphabétiques : A, B, C, D...
  • Règle ferme : MDC ne modifie jamais le prix d'une cotation dans sa période de validité
  • Si la date de validité est dépassée → nouvelle version obligatoire
  • Cas ST : demandes fréquentes de recotations conformes au PO client (avec serial numbers)
  • Les versions sont modifiables manuellement (pas de lock automatique)
Impact modèle : Champ version (VARCHAR A/B/C) déjà présent sur Quotation. Écran de "mise à jour cotation" à créer.

C — Catégories de produits

4 catégories produit définies
ACTÉ
  • SP — Spare Parts : pièces détachées (volume principal MDC)
  • EQPT — Equipment : machines, équipements
  • OPT — Options : kits, packaging, incoterms/livraison, accessoires
  • SAV — Service : maintenance, formation/training, intervention sur site
Ces catégories s'appliquent en interne. Les cotations peuvent être structurées par section par catégorie en usage interne (pas imposé côté client pour ne pas réduire le panier).
Impact modèle : Ajouter champ product_category enum {SP, EQPT, OPT, SAV} sur entité Product.

D — Codification produit MDC

Structure finale du code produit MDC
ACTÉ
MDC - {TYPE} - {ATELIER} - {SEQ} - {QUALITÉ}

Exemples :
MDC-SP-31-0042-00 → Spare Part · Lito · N°0042 · Neuf
MDC-SP-31-0042-01 → même pièce, Réparée (code distinct)
MDC-EQPT-34-0001-00 → Équipement · Épitaxie · N°0001 · Neuf
  • L'origine sourcing est EXCLUE du code (initialement prévue, abandonnée car peut changer dans le temps)
  • L'origine sourcing devient un attribut de la fiche produit : Trading / MDC Germany / MDC Copé
  • Un produit neuf et un produit réparé = deux codes distincts (prix différents)
  • Le suffixe Qualité est extensible : 00=Neuf, 01=Réparé, 02=Réparé Grade 2...
Impact modèle : Champ mdc_ref sur Product — format mis à jour. Nouveaux champs : quality, sourcing_origin, workshop_code.

E — Ateliers (codification)

Liste provisoire des ateliers (codes à 2 chiffres)
ACTÉ (provisoire)
CodeAtelier
31Lito (Lithographie)
32Implant
33Etch
34Épitaxie
35Diffusion
36Cleaning
37Métrologie
38Support / Périphériques
39RTP (Rapid Thermal Process)
Un produit = 1 seul atelier. Les produits transversaux prennent le code le plus pertinent. Liste à finaliser par MDC (tableau Excel).
Impact modèle : Nouvelle table de référence Workshop (workshop_code PK, workshop_name).

F — Remises fournisseurs

Remise par défaut par fournisseur, modifiable par exception
ACTÉ
  • Chaque fournisseur a un default_discount (ex : MDC US → 20%)
  • Appliqué automatiquement à l'import de la cotation fournisseur
  • Modifiable manuellement par exception sur chaque ligne
  • Granularité : par fournisseur (pas par catégorie de produit pour l'instant)
  • Risque identifié : oublier d'appliquer le discount → le mécanisme par défaut couvre ce risque
Impact modèle : Ajouter default_discount (decimal %) sur Supplier. Ajouter discount_pct et discounted_price sur SupplierQuotationLine.

G — Granularité client

1 entité juridique/géographique = 1 Customer distinct
ACTÉ
  • ST Microelectronics Croll 1, Croll 2, Tours, Rousset, Agrate, Catane = 6 customers distincts
  • Pas de notion de groupe client dans NEXUS
  • Discriminant : le numéro de TVA (ST Croll 1 ≠ ST Croll 2 car numéros de TVA différents)
  • Hypothèse de travail : 1 Customer = 1 Bill To = 1 Ship To (à valider sur PO réels — voir QO-1)
Impact modèle : Ajouter vat_number sur Customer. Clarification de la définition de l'entité Customer dans le modèle.

H — Contacts

Entité Contact — saisie manuelle, présence conditionnelle par document
ACTÉ
DocumentNom contact ?Note
Devis (Quotation)✅ OuiDestinataire du devis
Customer Order Confirmation✅ Oui—
Delivery Notice / Bon de livraison✅ OuiObligatoire (requis par transporteurs)
Pro Forma✅ Oui—
Customer Invoice (Facture client)❌ Non—
Supplier PO❌ NonEnvoyé par mail, pas sur le doc
RMA❌ NonDécision : simplification volontaire
Les contacts sont fluctuants → saisie manuelle uniquement, pas de récupération automatique. Sur le bon de livraison : liste déroulante des contacts déjà utilisés pour l'adresse Ship To.
Impact modèle : Nouvelle entité Contact (contact_id, customer_id FK, ship_to_id FK optionnel, first_name, last_name, email, phone). FK optionnel contact_id sur Quotation, OrderProcessing, Document.

I — Upsell / Options

Suggestions d'options basées sur l'historique des cotations
ACTÉ
  • Pas de matrice produit/option manuelle (200 produits × 50 options = 10 000 associations — trop lourd)
  • Le système remonte les options proposées dans les anciennes cotations pour le même produit
  • Message : "La dernière fois que tu as offert ce produit, tu avais aussi proposé X, Y, Z — tu veux les inclure ?"
  • Ajout manuel possible en complément
  • La catégorisation OPT dans le catalogue est nécessaire pour que le système sache ce qu'il cherche
Impact modèle : Logique portée par une requête sur l'historique QuotationLine — pas de nouvelle entité. Champ product_category = OPT nécessaire sur Product.

J — Numérotation des factures

Factures client : séquence chronologique propre, indépendante du numéro OP
ACTÉ
  • Le numéro de facture client est découplé du numéro OP (chronologie fiscale obligatoire)
  • NEXUS génère automatiquement un numéro séquentiel sans saut
  • Pendant la transition legacy → NEXUS : deux séries coexistent (ex : legacy jusqu'à 4550, NEXUS à partir de 6000)
  • Factures fournisseurs : numéro conservé tel que reçu du fournisseur (champ texte libre)
Impact modèle : Ajouter invoice_number et invoice_date sur entité Document (pour CUSTOMER_INVOICE). Validation comptable requise (voir QO-3).

K — Attributs produit

Attributs complémentaires sur la fiche produit
ACTÉ (liste à finaliser)
Attributs identifiés (distincts de la codification) :
  • sourcing_origin : Trading / MDC Germany / MDC Copé
  • weight : poids en grammes
  • dimensions : L×l×H
  • shipping_container : Enveloppe / Petit colis / Gros colis / Palette / Camion
  • technical_datasheet_url : fiche technique PDF
  • product_photo : photo (utile pour produits Copé notamment)
Des champs libres peuvent être créés avec le bon type (texte, nombre, date, fichier, booléen). À aligner avec Charlotte pour cohérence site web / NEXUS.

L — Reporting financier

Vue synthétique par OP : statut paiements + marge
ACTÉ
  • Pour chaque OP : client payé ? fournisseur payé ?
  • Vue synthétique : factures à recevoir (débiteurs), factures à payer (créanciers)
  • Stratégie MDC : attendre le paiement client avant de payer le fournisseur (souvent pour raisons qualité)
  • Atelier dédié sur le calcul de marge à planifier (voir QO-7)

M — Organisation des ateliers

Réunions MDC-AXION concentrées le mardi à 9h00
ACTÉ
  • Charlotte (SEO/site web) disponible le mardi → centralisation des sujets sur ce jour
  • La comptable disponible le lundi → invitation éventuelle le lundi pour les questions comptables
  • Prochain atelier : mardi 17 mars 2026 à 9h00 (invitation Charlotte pour alignement site web / NEXUS)
❓
02

Questions ouvertes

QO-1
Relation Bill To / Ship To : 1-pour-1 ou 1-pour-N ?
Hypothèse de travail : 1 Customer = 1 Bill To = 1 Ship To pour MDC. À valider impérativement sur les PO clients réels. Si 1-pour-N, impact significatif sur la modélisation.
→ Action A1 : MDC envoie tous les PO clients reçus (a minima ST)
QO-2
Remise par catégorie de produit chez un même fournisseur ?
Exemple : MDC US fait 20% sur ses produits mais pas sur les machines HP incluses dans la même cotation. Décision provisoire : discount par fournisseur + exception manuelle. À redétailler.
→ À rediscuter dans un atelier ultérieur
QO-3
Numérotation des factures clients — validation comptable
La numérotation chronologique sans saut est-elle légalement obligatoire ? La coexistence de deux séries (legacy + NEXUS) pendant la transition est-elle acceptable fiscalement ?
→ Action A4 : MDC consulte la comptable — Action A5 : Cristina vérifie les fichiers Excel utilisant ces numéros
QO-4
Liste complète des ateliers (Workshop)
Liste provisoire codes 31-39 esquissée. Coaching, Coating, Backend non encore placés. Liste à stabiliser avant démarrage Supabase.
→ Action A3 : MDC envoie tableau Excel avec proposition complète
QO-5
Attributs produit — liste complète
La liste des attributs nécessaires n'est pas finalisée. À aligner avec Charlotte pour cohérence entre structure NEXUS et hiérarchie du site web (catégories, filtres, fiches produits en ligne).
→ Action A6 : Réunion avec Charlotte — Action A7 : MDC envoie exemples fiches produits
QO-6
Granularité du discount sur les lignes de cotation
Pourcentage, valeur absolue, ou prix cible ? Les trois modes ont été évoqués lors de l'atelier. À préciser lors de la spec des écrans.
→ À préciser à l'étape écran de validation cotation fournisseur
QO-7
Calcul de la marge sur commandes ouvertes
Les règles de calcul de la marge sur les OP ouverts (en cours) nécessitent un atelier dédié. Sujets : marge brute vs nette, traitement des frais de port, gestion du multi-devises.
→ Action A12 : Planifier atelier dédié sur la marge
🎯
03

Plan d'actions

MDCÀ la charge de MDC Europe AXIONÀ la charge d'AXION Haute Moyenne
# Action Responsable Priorité
A1 Envoyer tous les PO clients reçus (a minima ST) dans le drive partagé pour valider la relation Bill To / Ship To MDC Haute
A2 Proposer la codification produits MDC (tableau Excel, quelques exemples avec la structure MDC-Type-Atelier-Seq-Qualité) MDC Haute
A3 Finaliser la liste des ateliers (codes 31+) et l'envoyer sous forme de tableau MDC Haute
A4 Consulter la comptable sur la numérotation des factures : chronologie sans saut légalement obligatoire ? Coexistence de deux séries acceptable ? MDC (Pina) Haute
A5 Vérifier si d'autres fichiers Excel / rapports utilisent les numéros de factures actuels MDC (Cristina) Haute
A6 Organiser une réunion avec Charlotte pour aligner la structure produit NEXUS avec la hiérarchie du site web (catégories, attributs, filtres) MDC + AXION Haute
A7 Envoyer des exemples de fiches produits (nomenclature) avec des attributs proposés pour compléter le modèle MDC Moyenne
A8 Envoyer les diagrammes BPMN mis à jour (Quotation + Order Processing) pour revue par MDC AXION Haute
A9 Envoyer le modèle de données mis à jour (v2.0 post-atelier) AXION Haute
A10 Envoyer les maquettes HTML des écrans NEXUS mis à jour pour revue par MDC AXION Haute
A11 Envoyer un fichier Excel structuré avec les attributs produits et des exemples pour que MDC puisse les compléter AXION Moyenne
A12 Planifier un atelier dédié sur le calcul de la marge dans les commandes ouvertes AXION + MDC Moyenne
🗓️
04

Prochaines étapes

01
MDC complète les actions A1 à A7
PO clients, codification produits, liste ateliers, validation comptable, exemples fiches produits — avant le prochain atelier.
02
AXION envoie modèle de données v2.0 + maquettes écrans mis à jour
data-model.md v2.0 + screens mis à jour (screen-01, 02, 12) + compte rendu présent.
03
Prochain atelier — Mardi 17 mars 2026 à 9h00
Revue des maquettes d'écrans + validation du modèle de données v2.0 + alignement Charlotte sur la structure produit. Invitation éventuelle de la comptable pour QO-3.
04
Après validation modèle → initialisation Supabase
Création du schéma Supabase + premières tables + premiers workflows n8n.
Document généré le 9 mars 2026 · AXION × MDC Europe — Projet NEXUS
Basé sur le transcript de la réunion du 5 mars 2026 (Gemini Notes, Google Meet)