docs(evolution): ajout présentation FabNum v2 (md + pdf)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

.gitignore

@@ -7,6 +7,7 @@ __pycache__/
 *.pyo
 *.pyd
 *.dot
+!docs/**/*.dot
 prompt.md
 .gitignore
 

docs/FabNum v2/EVOLUTIONS-PLANIFICATION.md

@@ -0,0 +1,242 @@
+# FabNum — Planification macro
+
+Vues synthétiques dérivées de [EVOLUTIONS.md](EVOLUTIONS.md).
+**Date** : 2026-04-02
+
+---
+
+## 1. Présentation synthétique temporelle
+
+```
+T0                    T1                    T2                    T3                   Horizon
+│                     │                     │                     │                    │
+│  PHASE 1            │  PHASE 2            │  PHASE 3            │  PHASE 4           │
+│  Fondations         │  Modèle & Stockage  │  Données & Sources  │  Fiches & API      │
+│                     │                     │                     │                    │
+│ ┌─────────────────┐ │ ┌─────────────────┐ │ ┌─────────────────┐ │ ┌───────────────┐ │ ┌──────────────┐
+│ │ P7 Validation   │ │ │ P3 Modèle de    │ │ │ P2 Gestion des  │ │ │ P5 Templates  │ │ │ P10 Énergie  │
+│ │ niveaux (revue  │→│ │ données         │→│ │ sources (//P2   │→│ │ et génération │ │ │ et eau       │
+│ │ littérature)    │ │ │ structuré       │ │ │ dès phase 2)    │ │ │ fiches        │ │ │              │
+│ └─────────────────┘ │ └─────────────────┘ │ └─────────────────┘ │ └───────────────┘ │ │ P11 Géo fine │
+│ ┌─────────────────┐ │ ┌─────────────────┐ │ ┌─────────────────┐ │ ┌───────────────┐ │ │              │
+│ │ P6 Spike techno │ │ │ P6 Implém.      │ │ │ P4 Amorçage     │ │ │ P1 API REST   │ │ │ P9 Multi-    │
+│ │ base données    │ │ │ stockage retenu │ │ │ 3M+1C+1PF       │ │ │ + rôles       │ │ │ sectoriel    │
+│ │ (Docker/serveur)│ │ │                 │ │ │ + audit exhaust. │ │ │               │ │ └──────────────┘
+│ └─────────────────┘ │ └─────────────────┘ │ └─────────────────┘ │ ├───────────────┤ │
+│                     │                     │                     │ │ P8 Services,  │ │
+│                     │                     │                     │ │ sécu, profils  │ │
+│         ║           │          ║          │          ║          │ └───────────────┘ │
+│      parallèle      │       séquentiel    │    P2 // dès Ph.2  │                    │
+│                     │                     │                     │                    │
+├─────────────────────┼─────────────────────┼─────────────────────┤                    │
+│              MVP = Phases 1+2+3           │                     │                    │
+└─────────────────────┴─────────────────────┴─────────────────────┘                    │
+```
+
+**Légende** : M = minerai, C = composant, PF = produit final, // = parallèle
+
+---
+
+## 2. Macro-DAF (Diagramme d'Activités Fonctionnel)
+
+Vue par **fonctions métier** — ce que fait le système, pour qui, et dans quel ordre.
+
+```
+┌─────────────────────────────────────────────────────────────────────────────────────┐
+│                          FABNUM — ACTIVITÉS FONCTIONNELLES                          │
+├─────────────────────────────────────────────────────────────────────────────────────┤
+│                                                                                     │
+│  ┌──────────────────────────────────────────────────────────────────┐               │
+│  │  F1. MODÉLISER LA CHAÎNE DE VALEUR                              │               │
+│  │  ├─ F1.1 Valider les niveaux de décomposition (revue litt.)     │               │
+│  │  ├─ F1.2 Définir les intitulés génériques des niveaux           │               │
+│  │  ├─ F1.3 Définir les critères d'arrêt (profondeur)             │               │
+│  │  └─ F1.4 Gérer les chaînes principales et connexes             │               │
+│  │  Acteurs : Admin                                                │               │
+│  └──────────────┬───────────────────────────────────────────────────┘               │
+│                 ▼                                                                    │
+│  ┌──────────────────────────────────────────────────────────────────┐               │
+│  │  F2. STRUCTURER ET QUALIFIER LES DONNÉES                        │               │
+│  │  ├─ F2.1 Spécifier les données (essentielles / informationnelles)│              │
+│  │  ├─ F2.2 Définir le périmètre mesuré de chaque donnée          │               │
+│  │  ├─ F2.3 Identifier et catégoriser les sources                  │               │
+│  │  ├─ F2.4 Attribuer les tiers de confiance (par source/domaine) │               │
+│  │  ├─ F2.5 Qualifier les données (filtres qualité)               │               │
+│  │  ├─ F2.6 Arbitrer les divergences entre sources                │               │
+│  │  └─ F2.7 Calculer l'indice de fiabilité par donnée             │               │
+│  │  Acteurs : Admin                                                │               │
+│  └──────────────┬───────────────────────────────────────────────────┘               │
+│                 ▼                                                                    │
+│  ┌──────────────────────────────────────────────────────────────────┐               │
+│  │  F3. SURVEILLER ET MAINTENIR                                    │               │
+│  │  ├─ F3.1 Veiller sur les sources (huginn)                      │               │
+│  │  ├─ F3.2 Détecter les variations anormales (alertes)           │               │
+│  │  ├─ F3.3 Contrôler les citations/affirmations (verify-citations)│              │
+│  │  ├─ F3.4 Historiser les données et les indices                  │               │
+│  │  └─ F3.5 Auditer l'exhaustivité des minerais                   │               │
+│  │  Acteurs : Admin (gouvernance), Services internes (automatisé)  │               │
+│  └──────────────┬───────────────────────────────────────────────────┘               │
+│                 ▼                                                                    │
+│  ┌──────────────────────────────────────────────────────────────────┐               │
+│  │  F4. CALCULER LES INDICES DE CRITICITÉ                          │               │
+│  │  ├─ F4.1 Calculer IHH, ICS, IVC, ISG (+ futurs : eau, énergie) │               │
+│  │  ├─ F4.2 Pré-calculer à chaque mise à jour du graphe           │               │
+│  │  ├─ F4.3 Calculer les méta-indices dynamiques (sur sélection)  │               │
+│  │  └─ F4.4 Rétro-analyser sur des crises passées (backtesting)   │               │
+│  │  Acteurs : Services internes (automatisé)                       │               │
+│  └──────────────┬───────────────────────────────────────────────────┘               │
+│                 ▼                                                                    │
+│  ┌──────────────────────────────────────────────────────────────────┐               │
+│  │  F5. PRODUIRE LES FICHES                                        │               │
+│  │  ├─ F5.1 Générer depuis les données via templates               │               │
+│  │  ├─ F5.2 Adapter par niveau (minerai, composant, opération...) │               │
+│  │  └─ F5.3 Adapter par usage (expertise, synthèse, API/JSON)     │               │
+│  │  Acteurs : Services internes (automatisé)                       │               │
+│  └──────────────┬───────────────────────────────────────────────────┘               │
+│                 ▼                                                                    │
+│  ┌──────────────────────────────────────────────────────────────────┐               │
+│  │  F6. EXPOSER ET SERVIR                                          │               │
+│  │  ├─ F6.1 Requêtage du graphe (expert / simplifié)              │               │
+│  │  ├─ F6.2 Consultation des fiches (tous formats)                │               │
+│  │  ├─ F6.3 Analyse de vulnérabilité et scénarios                 │               │
+│  │  ├─ F6.4 Export (PDF, JSON, DOT)                               │               │
+│  │  ├─ F6.5 Personnalisation client (projection SI)               │               │
+│  │  └─ F6.6 Intégration écosystème veille 360°                    │               │
+│  │  Acteurs : Expert, Service, COMEX, Métiers, DSI               │               │
+│  └──────────────────────────────────────────────────────────────────┘               │
+│                                                                                     │
+│  ┌──────────────────────────────────────────────────────────────────┐               │
+│  │  F7. SÉCURISER ET CONTRÔLER                         (transversal)│              │
+│  │  ├─ F7.1 Authentifier (utilisateur / clé API)                   │               │
+│  │  ├─ F7.2 Autoriser par rôle (admin, expert, service)           │               │
+│  │  ├─ F7.3 Filtrer par profil de visibilité                      │               │
+│  │  ├─ F7.4 Rate limiting                                          │               │
+│  │  └─ F7.5 Monitoring / observabilité                             │               │
+│  │  Acteurs : Admin (configuration), Système (exécution)           │               │
+│  └──────────────────────────────────────────────────────────────────┘               │
+└─────────────────────────────────────────────────────────────────────────────────────┘
+
+Flux principal : F1 → F2 → F3 → F4 → F5 → F6
+F3 tourne en continu (veille)
+F4 se déclenche à chaque mise à jour du graphe
+F7 est transversal à F5 et F6
+```
+
+---
+
+## 3. Macro-DAT (Diagramme d'Activités Technique)
+
+Vue par **composants techniques** — ce qu'il faut construire et comment ça s'articule.
+
+```
+┌─────────────────────────────────────────────────────────────────────────────────────┐
+│                           FABNUM — ARCHITECTURE TECHNIQUE                           │
+├─────────────────────────────────────────────────────────────────────────────────────┤
+│                                                                                     │
+│  ┌────────────────────────────────────────────────────────┐                         │
+│  │              COUCHE STOCKAGE                           │                         │
+│  │                                                        │                         │
+│  │  ┌──────────────────┐  ┌───────────────────────────┐  │                         │
+│  │  │  Base graphe     │  │  Historisation             │  │                         │
+│  │  │  (Neo4j / PG+AGE │  │  (snapshots horodatés     │  │                         │
+│  │  │   / ArangoDB)    │  │   données + indices)      │  │                         │
+│  │  │                  │  │                           │  │                         │
+│  │  │  • Nœuds (N0-N12)│  │  • Versions des données   │  │                         │
+│  │  │  • Arêtes + attrs│  │  • Versions des indices   │  │                         │
+│  │  │  • Multi-graphes │  │  • Audit trail            │  │                         │
+│  │  │  • Schéma évolutif│  │                           │  │                         │
+│  │  └────────┬─────────┘  └─────────────┬─────────────┘  │                         │
+│  └───────────┼──────────────────────────┼────────────────┘                         │
+│              │                          │                                           │
+│              ▼                          ▼                                           │
+│  ┌────────────────────────────────────────────────────────┐                         │
+│  │              COUCHE MOTEUR                             │                         │
+│  │                                                        │                         │
+│  │  ┌──────────────┐ ┌──────────────┐ ┌───────────────┐  │                         │
+│  │  │ Calcul       │ │ Arbitrage    │ │ Qualification │  │                         │
+│  │  │ indices      │ │ sources      │ │ données       │  │                         │
+│  │  │              │ │              │ │               │  │                         │
+│  │  │ • IHH, ICS   │ │ • Tier 1 win │ │ • Filtres     │  │                         │
+│  │  │ • IVC, ISG   │ │ • Convergence│ │   qualité     │  │                         │
+│  │  │ • Méta-ind.  │ │ • Alertes    │ │ • Indice de   │  │                         │
+│  │  │ • Extensible │ │ • Seuils     │ │   fiabilité   │  │                         │
+│  │  └──────────────┘ └──────────────┘ └───────────────┘  │                         │
+│  │                                                        │                         │
+│  │  ┌──────────────┐ ┌──────────────┐ ┌───────────────┐  │                         │
+│  │  │ Requêtage    │ │ Génération   │ │ Import/Export │  │                         │
+│  │  │ graphe       │ │ fiches       │ │               │  │                         │
+│  │  │              │ │              │ │ • DOT (legacy)│  │                         │
+│  │  │ • Chemins    │ │ • Templates  │ │ • JSON        │  │                         │
+│  │  │ • Filtrage   │ │   niveau×    │ │ • PDF         │  │                         │
+│  │  │ • Sous-graphe│ │   usage      │ │ • Backup/     │  │                         │
+│  │  │ • Projection │ │ • Rendu MD/  │ │   restore     │  │                         │
+│  │  │   SI client  │ │   JSON/PDF   │ │               │  │                         │
+│  │  └──────────────┘ └──────────────┘ └───────────────┘  │                         │
+│  └────────────────────────┬───────────────────────────────┘                         │
+│                           │                                                         │
+│              ┌────────────┴────────────┐                                            │
+│              ▼                         ▼                                            │
+│  ┌─────────────────────┐  ┌─────────────────────────────────┐                      │
+│  │  SERVICES INTERNES  │  │  API REST                       │                      │
+│  │  (non exposés)      │  │  (point d'accès unique)         │                      │
+│  │                     │  │                                 │                      │
+│  │  ┌───────────────┐  │  │  ┌────────────┐ ┌────────────┐ │                      │
+│  │  │ Veille huginn │  │  │  │ Auth       │ │ Rate       │ │                      │
+│  │  │ sources       │  │  │  │ + rôles    │ │ limiting   │ │                      │
+│  │  ├───────────────┤  │  │  ├────────────┤ ├────────────┤ │                      │
+│  │  │ Vérification  │  │  │  │ Profils    │ │ Monitoring │ │                      │
+│  │  │ citations     │  │  │  │ visibilité │ │ logging    │ │                      │
+│  │  ├───────────────┤  │  │  └────────────┘ └────────────┘ │                      │
+│  │  │ Recalcul      │  │  │                                 │                      │
+│  │  │ indices       │  │  │  Endpoints :                    │                      │
+│  │  ├───────────────┤  │  │  • /graphe/* (requêtage)        │                      │
+│  │  │ Alertes       │  │  │  • /fiches/* (consultation)     │                      │
+│  │  │ (variations,  │  │  │  • /analyse/* (vulnérabilités)  │                      │
+│  │  │  convergence) │  │  │  • /indices/* (méta-indices)    │                      │
+│  │  └───────────────┘  │  │  • /export/* (PDF, JSON, DOT)   │                      │
+│  └─────────────────────┘  │  • /admin/* (CRUD, scripts)     │                      │
+│                           └──────────────┬──────────────────┘                      │
+│                                          │                                          │
+│              ┌───────────────────────────┬┴──────────────────────┐                  │
+│              ▼                           ▼                       ▼                  │
+│  ┌─────────────────────┐  ┌──────────────────────┐  ┌─────────────────────┐        │
+│  │  FRONTEND EXPERT    │  │  SERVICES EXTERNES   │  │  ÉCOSYSTÈME 360°   │        │
+│  │  (consomme l'API)   │  │  (consomment l'API)  │  │  (consomme l'API)  │        │
+│  │                     │  │                      │  │                     │        │
+│  │  • COMEX : synthèses│  │  • Génération IA     │  │  • Veille strat.   │        │
+│  │  • Métiers : analyse│  │    rapports          │  │  • IRON            │        │
+│  │  • DSI : dépend. SI│  │  • Agent local       │  │  • Alertes         │        │
+│  │                     │  │    client            │  │    croisées        │        │
+│  └─────────────────────┘  └──────────────────────┘  └─────────────────────┘        │
+│                                                                                     │
+│  ┌─────────────────────┐                                                            │
+│  │  ADMIN (scripts)    │  Accès direct au moteur + API /admin/*                     │
+│  │  • CRUD graphe      │                                                            │
+│  │  • Gestion sources  │                                                            │
+│  │  • Tiers, arbitrage │                                                            │
+│  │  • Backup/restore   │                                                            │
+│  └─────────────────────┘                                                            │
+└─────────────────────────────────────────────────────────────────────────────────────┘
+
+Composants à construire par phase :
+  Phase 1 : Revue littérature (P7) + Spike base données (P6)
+  Phase 2 : Couche stockage + Moteur (calcul, arbitrage, qualification)
+  Phase 3 : Services internes (veille, vérification) + Import données
+  Phase 4 : API REST + Frontend expert + Génération fiches
+```
+
+---
+
+## Dépendances critiques
+
+```
+P7 (niveaux) ──→ P3 (modèle) ──→ P6 impl (stockage) ──→ P4 (amorçage) ──→ P5 (fiches)
+                                                                              │
+P6 spike ─────────────────────→ P6 impl                                      ▼
+                                                           P1 (API) ──→ P8 (services)
+P2 (sources) ─────────────────────────────→ P4 (amorçage)
+
+Parallélisations possibles :
+  • P7 // P6 spike (phase 1)
+  • P2 identification // P3 + P6 impl (phase 2→3)
+```

docs/FabNum v2/EVOLUTIONS-instructions-revision.md

@@ -0,0 +1,119 @@
+# Instructions de révision — EVOLUTIONS.md (FabNum)
+
+Document issu d'une revue critique du brainstorming FabNum. Les instructions sont organisées par point du document source. Elles portent sur le fond uniquement ; la forme sera traitée séparément.
+
+## Contraintes transversales
+
+Ajouter une mention explicite que deux questions sont des **décisions différées**, conditionnées au modèle de financement du projet :
+
+- La portée de l'open source (moteur, graphe des essentiels, services).
+- La dé-concentration du bus factor.
+
+Pour chacune, identifier le ou les **signaux déclencheurs** qui imposeront l'arbitrage : premier prospect sérieux, premier financement, premier contributeur externe, demande client de garantie de continuité, SLA contractuel. L'objectif n'est pas de trancher maintenant mais de garantir que la décision ne sera pas prise par défaut ou dans l'urgence.
+
+## Point 3 — Modèle de données structuré
+
+### Versionnage des indices
+
+Ajouter comme exigence de l'historisation : chaque valeur d'indice stockée porte la référence à la version de formule qui l'a calculée. Le cas de l'ISG (dont un indice constitutif vient de changer de méthode) illustre directement le besoin.
+
+Deux implications à capturer :
+
+- La coexistence de plusieurs versions de formule dans l'historique doit être supportée nativement. On ne recalcule pas rétroactivement avec la nouvelle formule, sinon on perd la trace de ce qu'on voyait à l'époque.
+- Le versionnage de formule interagit avec le versionnage des données. Une valeur d'indice historisée est fonction de (formule_v, données_à_date). Pour rejouer proprement, il faut pouvoir reconstituer les deux.
+
+### Horodatage « date de disponibilité effective »
+
+Étendre l'historisation pour que chaque donnée porte non seulement la valeur et sa date de validité métier, mais aussi la date à laquelle elle est devenue connue (date de disponibilité effective). Sans cela, la rétro-analyse souffre d'un look-ahead bias : on rejouerait une crise passée avec des données que personne ne connaissait à l'époque.
+
+Cette exigence s'applique à toutes les données qui entrent dans les indices, pas seulement aux stocks.
+
+## Point 4 — Amorçage
+
+Reformuler le choix du périmètre autour du principe : le périmètre est choisi **pour** stresser les mécanismes qualité, pas malgré eux. Si les minerais retenus passent tous les filtres sans déclencher d'arbitrage, les filtres n'ont pas été testés.
+
+Critères de sélection à acter :
+
+- Au moins un minerai aux sources opaques ou divergentes (candidats : germanium, gallium, terres rares côté chinois).
+- Au moins un minerai avec débat méthodologique extraction/raffinage (candidats : lithium, cobalt — terrain déjà travaillé sur gallium et hafnium).
+- Un minerai bien documenté comme témoin (candidats : cuivre, fer).
+- Pour le composant : pas le plus simple, mais un dont la chaîne a des zones d'ombre.
+
+## Point 6 — Stockage
+
+Ajouter au spike technique un critère d'évaluation : **réversibilité par rapport aux décisions différées** (open source, modèle commercial). L'objectif n'est pas de trancher à la place du modèle de financement, mais d'éviter de fermer prématurément des portes qu'on ne voulait pas fermer.
+
+Exemple de tension à capturer : Neo4j Community est indolore à faire évoluer vers Enterprise, mais un passage à PostgreSQL+AGE ou ArangoDB ne l'est pas. Inversement, PostgreSQL+AGE laisse plus d'options ouvertes côté licence au prix d'une maturité graphe moindre.
+
+## Point 7 — Validation du modèle de niveaux
+
+Séparer clairement les deux méthodes de validation, qui portent sur deux axes différents et sont **complémentaires, pas alternatives** :
+
+- **Axe vertical (quels niveaux, quels intitulés génériques)** — validé par revue de littérature. Références pertinentes pour la décomposition matière : USGS mineral commodity summaries et flux de matières, études JRC sur les matières premières critiques, travaux de l'IEA sur les chaînes de valeur énergie-matière, analyses de cycle de vie matière (ACV).
+- **Axe horizontal (jusqu'où remonter dans la profondeur des dépendances)** — validé par démonstration via les marges d'erreur cumulées. Pas de bibliographie nécessaire sur cet axe, c'est un argument analytique.
+
+Préciser que SCOR et ISO 28000 peuvent être mentionnés mais en contrepoint uniquement : ils traitent de la gestion process de la supply chain, pas de la décomposition matière. Les utiliser comme benchmark principal ferait porter la validation sur le mauvais objet.
+
+## Point 8 — Services, sécurisation et profils de visibilité
+
+Ajouter un paragraphe (pas un point à part entière) sur l'interface concrète avec IRON. Le couplage est actuellement mentionné en une ligne dans les contraintes transversales mais on ne sait pas comment il se matérialise. FabNum ne se substitue pas à IRON, il le complète : FabNum fournit le diagnostic de fragilité technique de la chaîne, IRON évalue la capacité organisationnelle à encaisser et contourner (distinction Hamant résilience/robustesse).
+
+Décrire deux ou trois usages concrets d'appel croisé. Pistes à explorer :
+
+- IRON consomme des analyses FabNum via l'API comme intrants de l'évaluation Y-axis ou Z-axis.
+- FabNum produit en sortie une liste de dépendances critiques qu'IRON utilise dans son diagnostic.
+- Un score IRON peut en retour contextualiser une analyse FabNum : pour cette organisation donnée, telle dépendance est critique parce que leur robustesse sur ce point est faible.
+
+Sans cette explicitation, le couplage reste déclaratif et risque de ne jamais être implémenté.
+
+## Point 12 — Stocks et projection temporelle
+
+### Résultat qualitatif par défaut
+
+Reformuler pour dire explicitement que la projection temporelle produit un résultat **qualitatif** (court / moyen / long terme, ou équivalent à calibrer) et non une valeur en mois. Remplacer l'exemple actuel (« ~8 mois avant impact ») par une formulation du type « impact court terme (semaines), moyen terme (quelques mois), long terme (au-delà) » avec l'indice de confiance associé.
+
+Cohérent avec le principe directeur du point 3 : « on travaille avec des estimations, pas des mesures exactes ».
+
+### Indice de confiance hérité
+
+L'indice de confiance de la projection hérite par propagation de l'indice de fiabilité des données de stock mobilisées. Ce n'est pas un nouvel indice à concevoir.
+
+### Rétro-analyse comme mécanisme de calibration
+
+La rétro-analyse mentionnée dans le MVP (Spruce Pine, quotas chinois) prend un double rôle : preuve de concept des indices **et** mécanisme de calibration du moteur de projection. On rejoue une crise passée dont on connaît le déroulement réel, on observe ce que le moteur aurait prédit avec les données de l'époque, on ajuste les seuils court/moyen/long terme.
+
+À articuler avec la rétro-analyse des indices : pour une crise passée donnée, rejouer avec **les deux** versions de formule quand c'est pertinent — formule de l'époque (qu'aurions-nous vu venir avec les outils d'alors ?) et formule actuelle (le moteur actuel capte-t-il bien le signal ?). Si la nouvelle formule ne capte pas mieux une crise passée que l'ancienne, la révision n'a rien apporté.
+
+## Point 13 — Bus d'impact
+
+### Deux sorties possibles, tri par l'expert
+
+Rendre explicite que le bus d'impact a **deux sorties possibles** et que le tri entre elles fait partie de la décision de l'expert :
+
+- Sortie situationnelle — impact temporaire sur les capacités réelles (inondation, blocage logistique, grève).
+- Sortie structurelle — modification de la capacité nominale elle-même (fermeture définitive de mine, ouverture d'un nouvel opérateur, quota devenu politique permanente, reconfiguration durable d'une route).
+
+L'IA du bus propose, l'expert arbitre entre les deux couches. Sans cette précision, un développeur (ou Claude Code au moment de l'implémentation) risque de coder le bus comme un pipeline mono-sortie vers le situationnel, et une fermeture de mine atterrirait comme un impact « -100% permanent » au lieu d'une modification du graphe structurel.
+
+### Coût opérationnel de l'IA
+
+Mentionner que le coût opérationnel de l'IA est un élément à chiffrer **au moment où la Vue 4 devient l'étape courante**, pas avant et pas après. Cela évite deux écueils symétriques : chiffrer trop tôt (purement spéculatif) ou découvrir tardivement que le modèle économique du bus ne boucle pas.
+
+Ajouter que l'expérience du générateur de rapport actuel (modèles gratuits) fournit une base empirique pour extrapoler l'ordre de grandeur le moment venu. Cela ancre l'estimation future dans du concret plutôt que dans un calcul théorique.
+
+## Vue 4 — Schéma à corriger
+
+Trois corrections sur la figure :
+
+1. **Flèche Écosystème veille 360° → Bus d'impact** : actuellement étiquetée « injecte des événements », ce qui contredit le texte du point 13. La veille propose, elle n'injecte pas. Redessiner comme une flèche « propose des événements » vers l'Expert (ou vers une file d'attente validée par l'expert), symétrique à la flèche « propose des sources » qui existe déjà.
+
+2. **Flèche Écosystème veille 360° → API** : perdue par rapport à la Vue 3. Ce canal ne disparaît pas en Vue 4, il s'ajoute au canal de proposition. L'écosystème 360° a deux usages en régime complet : consommateur d'analyses via API, pourvoyeur d'événements et de sources via validation expert. Les deux doivent apparaître.
+
+3. **Flèche Expert → Graphe structurel** (via Moteur) : absente. La flèche « valide les impacts » Expert → Bus d'impact est présente et correcte, mais il manque le chemin par lequel les modifications structurelles validées hors cycle trimestriel (fermeture de mine, nouvel opérateur) atteignent le graphe structurel. Sans ce chemin, la sortie structurelle du bus n'a pas de destination visible.
+
+## Points hors périmètre de la révision
+
+Deux remarques initiales ont été écartées après discussion et ne sont pas à traiter dans la révision du document :
+
+- **Bus factor et régime de validation du bus d'impact** : le document est précisément écrit pour lever le bus factor. Maintenir le régime « validation expert obligatoire » tel quel.
+- **FabNum comme « nième outil de criticité »** : formulation incorrecte. Le paysage public des outils de criticité supply chain appliqués au numérique est très peu couvert ; les rares outils opérationnels pointus sont gouvernementaux ou propriétaires non publiés. FabNum occupe un espace réel.

docs/FabNum v2/EVOLUTIONS.md

@@ -0,0 +1,694 @@
+# FabNum — Evolutions envisagées
+
+Document de brainstorming — capture les réflexions et décisions prises lors de la phase de conception.
+
+**Date** : 2026-04-02
+**Statut** : En cours de réflexion (quoi/pourquoi, pas encore le comment)
+
+## Principe fondamental
+
+FabNum v2 est un **moteur d'analyse** des risques géopolitiques sur les chaînes d'approvisionnement, exposé via une **API**. L'interface actuelle Streamlit est abandonnée au profit d'un frontend consommant l'API. L'administration se fait par scripts.
+
+![Vue 1 — Le moteur](architecture-vue1.png){ width=100% }
+
+## Contraintes transversales
+
+- **Budget : zéro en phase de démarrage** — tout est auto-hébergé et auto-financé. Briques technologiques open source et gratuites. Si le projet trouve son marché, cette contrainte sera réévaluée (ex : Neo4j Enterprise si justifié).
+- **Vocation commerciale à terme** — FabNum est un outil de recherche aujourd'hui, un produit commercial demain si le marché est présent.
+- **Big bang assumé** — peu d'utilisateurs actuels, deux environnements (prod/dev), possibilité de travailler en local. Pas de stratégie de migration progressive nécessaire.
+- **Bus factor = 1** — développement assuré par Claude Code avec validation humaine. Qualité maintenue par outillage (ruff, SonarQube, skills quality-gate, linters IDE).
+- **Équipe** — Stéphan : vision, arbitrage, validation des spécifications. Claude Code : conception technique, implémentation, agents spécialisés.
+- **Intégration écosystème** — FabNum est un composant d'un écosystème plus large de veille stratégique 360° sur la polycrise. Il sera requêté par d'autres outils pour fournir des analyses et rapports.
+- **Couplage** — FabNum se couple avec la méthodologie [IRON](https://conseil.peccini.fr/iron/) et le livre blanc "Voyage vers la robustesse".
+- **Personas cibles** — COMEX (vision stratégique, synthèses), Métiers (analyse opérationnelle), DSI (dépendances SI).
+- **Choix technologiques structurants** — base de données, framework API, frontend expert : à définir rapidement en début d'implémentation.
+
+**Décisions différées** — conditionnées au modèle de financement, à ne pas trancher maintenant mais à ne pas laisser arriver par défaut ou dans l'urgence :
+
+- **Portée de l'open source** (moteur, graphe des essentiels, services). Signaux déclencheurs : premier prospect sérieux, premier financement, demande client de garantie de continuité.
+- **Dé-concentration du bus factor**. Signaux déclencheurs : premier contributeur externe, SLA contractuel, premier financement permettant de diversifier.
+
+---
+
+## Point 1 — Recentrage de FabNum : moteur + API + séparation des rôles
+
+### Quoi
+
+- **Retrait des modules IA embarqués** (batch_ia/, pgpt/, IA/, page ia_nalyse) : FabNum n'est plus responsable de la génération de rapports IA.
+- **Exposition d'une API REST** : les capacités du moteur (graphe, indices de criticité, chemins critiques, filtrage) deviennent des endpoints consommables par des services externes.
+- **Séparation en trois rôles** :
+  - **Admin** — gestion du graphe, des fiches, de la configuration
+  - **Expert** — analyse de criticité, visualisations, plan d'action
+  - **Service** — consommation de l'API par des services externes (ex : génération de rapports IA)
+- Les rôles sont **assignables par utilisateur** et **cumulables** (un utilisateur peut être admin + expert).
+
+### Pourquoi
+
+- FabNum a plus de valeur en tant que **moteur d'analyse + interface experte** qu'en tant qu'application monolithique.
+- Séparer le moteur de ses usages permet à d'autres services de consommer les mêmes données/calculs sans couplage.
+- Les modules IA actuels sont peu testés (~1500 lignes exclues du linting) et leur évolution ne doit pas être liée à celle du moteur.
+- Tous les experts ne seront pas administrateurs à terme : la gestion des droits est nécessaire.
+
+**Distinction services internes / externes :**
+
+- **Services internes** (côté moteur, non exposés via l'API) — veille sur les sources, mise à jour des données, vérification des affirmations, calcul des indices. Peuvent utiliser de l'IA, du Python, huginn.
+- **Services externes** (exposés via l'API) — requêtage, consultation des fiches, analyse. L'API expose les résultats du moteur, pas ses processus internes.
+
+### Décisions prises
+
+- **Streamlit abandonné** — l'interface experte sera un frontend consommant l'API (un seul chemin d'accès aux données, pas deux).
+- **Administration par scripts** — pas de frontend admin dédié, scripts + accès direct au moteur. Interface admin envisageable plus tard si le besoin se précise.
+- **API-first** — architecture à un seul point d'accès pour tous les consommateurs (experts, services externes).
+- Le système d'authentification actuel (connexion Gitea simple) devra évoluer pour supporter les rôles.
+- Monitoring et observabilité de l'API : à traiter en implémentation, mentionné comme service d'administration.
+
+---
+
+## Point 2 — Gestion rigoureuse des sources de données
+
+### Quoi
+
+Les données (chiffres de production, parts de marché, réserves, projections) sont aujourd'hui enfouies dans le texte Markdown des fiches, sans existence structurée indépendante. Trois chantiers pour y remédier :
+
+- **a. Identification et catégorisation des sources** — typer chaque source (rapport périodique, base de données, article académique, etc.), établir un lien explicite source ↔ donnée. Approche académique privilégiée (Scholar Gateway, Consensus).
+- **b. Veille sur les sources** — service de surveillance pour détecter les mises à jour des sources (nouvelles éditions de rapports, apparition/disparition de sources). S'appuie sur un service huginn déjà actif pour un sujet connexe.
+- **c. Contrôle strict citations/affirmations** — vérifier que chaque affirmation dans les fiches est effectivement contenue dans la ou les sources référencées. S'appuie sur le skill verify-citations existant (à faire évoluer).
+
+### Pourquoi
+
+- Les données générées par IA n'ont pas de traçabilité : on ne peut pas vérifier, mettre à jour ou contester une donnée individuellement.
+- Les sources sont listées en vrac sans lien vers les données qu'elles justifient (ex : `12-sources.md`).
+- Les rapports (USGS, Statista, etc.) sont mis à jour annuellement : sans veille, les données deviennent obsolètes silencieusement.
+- La crédibilité de l'outil dépend de la rigueur des sources — approche académique nécessaire.
+
+### Décisions prises
+
+- Trois chantiers identifiés (sources, veille, contrôle) ; le modèle de données structuré et la génération des fiches seront traités dans des points séparés.
+- Réutilisation de l'infrastructure huginn existante pour la veille.
+- Évolution du skill verify-citations pour le contrôle des affirmations.
+
+---
+
+## Point 3 — Modèle de données structuré
+
+### Quoi
+
+Définir les spécifications de toutes les données nécessaires aux fiches et au moteur, organisées en deux niveaux :
+
+- **Données essentielles** — celles qui alimentent les indices et le moteur d'analyse (productions, parts de marché, réserves, etc.)
+- **Données informationnelles** — contexte, descriptions, projections — utiles aux fiches mais pas directement au calcul
+
+Chaque donnée doit porter :
+
+- Une **définition précise du périmètre mesuré** (ex : "extraction minière de lithium, hors raffinage, en tonnes de Li contenu")
+- Des **liens explicites vers ses sources**, avec gestion de la multiplicité
+- Les **dimensions de divergence** entre sources : valeur, temporalité, périmètre mesuré
+
+Le modèle doit inclure un **système de tiers de confiance** pour les sources :
+
+- Chaque source a un **tier** (niveau de fiabilité) assorti d'une **pondération** pour les arbitrages
+- Le tier peut **varier selon le domaine** couvert (ex : une source tier 1 sur l'extraction peut être tier 2 sur le raffinage)
+
+Des **scénarios d'arbitrage** doivent être spécifiés pour trancher quand les sources divergent :
+
+- **Règle de base** : le tier 1 l'emporte par défaut.
+- **Exception** : si N sources de tier inférieur convergent vers une autre valeur → alerte pour arbitrage humain.
+- **Seuil de variation** : si une valeur évolue trop fortement entre deux mises à jour → alerte.
+- **Principe directeur** : on travaille avec des estimations, pas des mesures exactes. La précision relative suffit.
+
+Un **indice de fiabilité de la donnée** agrège plusieurs facteurs : granularité géographique disponible, tier de confiance de la source, ancienneté de la donnée, couverture du périmètre. Il permet à l'utilisateur de savoir à quel point il peut se fier à un résultat.
+
+**Historisation** — chaque donnée, chaque valeur d'indice, chaque état du graphe est horodaté et conservé. Nécessaire pour la détection de tendances, les alertes de variation, et la rétro-analyse (backtesting des indices sur des crises passées : Spruce Pine, quotas chinois, etc.).
+
+Exigences complémentaires de l'historisation :
+
+- **Versionnage des formules d'indices** — chaque valeur d'indice stockée porte la référence à la version de formule qui l'a calculée (ex : l'ISG a changé de méthode de calcul suite à l'évolution d'un indice constitutif). On ne recalcule pas rétroactivement avec la nouvelle formule : on conserve ce qu'on voyait à l'époque. La coexistence de plusieurs versions de formule dans l'historique est supportée nativement. Une valeur historisée est fonction de (formule_version, données_à_date).
+- **Date de disponibilité effective** — chaque donnée porte non seulement sa valeur et sa date de validité métier, mais aussi la date à laquelle elle est devenue connue. Sans cela, la rétro-analyse souffre d'un look-ahead bias : on rejouerait une crise passée avec des données que personne ne connaissait à l'époque. S'applique à toutes les données entrant dans les indices.
+
+Les spécifications servent aussi de **cahier des charges pour la recherche de sources** : si une donnée essentielle n'a pas de source, on sait précisément ce qu'on cherche.
+
+### Pourquoi
+
+- Sans définition précise du périmètre, l'arbitrage entre sources divergentes n'a pas de sens.
+- La multiplicité des sources est la norme, pas l'exception — le modèle doit la gérer nativement.
+- Les spécifications permettent d'identifier les trous (données sans source) et de piloter la recherche.
+
+### Contraintes de conception
+
+- **Système ouvert et modulable** — de nouveaux indices sont prévus (eau, énergie, logistique). Le modèle ne doit pas câbler les 4 indices actuels (IHH, ICS, IVC, ISG) en dur.
+- Le tier de confiance par domaine est une hypothèse à valider, mais le modèle doit pouvoir le supporter.
+
+### Décisions prises
+
+- Deux niveaux de données : essentielles (moteur) et informationnelles (fiches).
+- Tier de confiance par source, variable selon le domaine, avec pondération pour l'arbitrage.
+- Scénarios d'arbitrage automatisables (tier 1 par défaut, convergence → alerte).
+- Indice de fiabilité par donnée (agrégation multi-facteurs).
+- Historisation native de toutes les données et indices.
+- **Gouvernance** : un seul rôle admin couvre toute la gouvernance (tiers, arbitrage, sources). Pas de segmentation tant qu'il n'y a pas d'équipe pour le justifier.
+
+---
+
+## Point 4 — Amorçage de la base avec le corpus existant
+
+### Quoi
+
+Alimenter la base de données structurée (point 3) à partir des fiches actuelles, puis utiliser ce jeu de données réel pour **tester en grandeur réelle** les processus des points 2 et 3 (sources, veille, contrôle citations, arbitrage).
+
+- **Extraction des données** depuis les fiches Markdown existantes vers le modèle structuré (tout ou partie du corpus, périmètre à décider).
+- **Raccordement affirmations ↔ sources** via une table de correspondance externe (sans modifier les fiches), même si certains liens seront des hypothèses.
+- **Test d'évolution des sources** — exercer le cycle complet : détection de mise à jour d'une source, impact sur les données, arbitrage, propagation.
+
+### Pourquoi
+
+- Le corpus existant (~30+ minerais) constitue un terrain d'essai réel avec toutes ses imperfections (sources obsolètes, périmètres flous, données non vérifiées).
+- Valider les processus sur des données imparfaites garantit qu'ils fonctionneront avec de meilleures sources.
+- De nombreuses sources actuelles sont intéressantes et à conserver.
+
+### Décisions prises
+
+- **Qualification progressive** — chaque donnée et chaque source est passée au crible des filtres qualité (tier de confiance, vérification citation, périmètre). Ce qui passe est conservé comme donnée de référence, ce qui ne passe pas est remplacé ou supprimé. Ce n'est pas "test puis jeter", c'est un processus de qualification.
+- **Périmètre choisi pour stresser les mécanismes qualité** — si les minerais retenus passent tous les filtres sans déclencher d'arbitrage, les filtres n'ont pas été testés. Critères de sélection :
+  - Au moins un minerai aux sources opaques ou divergentes (candidats : germanium, gallium, terres rares côté chinois)
+  - Au moins un minerai avec débat méthodologique extraction/transformation (candidats : lithium, cobalt)
+  - Un minerai bien documenté comme témoin (candidats : cuivre, fer)
+  - Un composant dont la chaîne a des zones d'ombre (pas le plus simple)
+- Les fiches existantes ne sont pas modifiées à cette étape.
+- Cet amorçage sert aussi de validation des chantiers précédents.
+
+---
+
+## Point 5 — Refonte des fiches : templates et génération
+
+### Quoi
+
+Les fiches ne sont plus rédigées manuellement ni générées en bloc par IA. Elles deviennent un **rendu généré** à partir des données structurées (point 3) via un système de templates.
+
+- **Templates par niveau du graphe** — chaque niveau (minerai, composant, opération, pays, etc.) a ses sections propres, adaptées à la nature des données.
+- **Templates par usage** — plusieurs rendus possibles pour un même niveau :
+  - **Expertise** — fiche complète avec toutes les sections, sources détaillées
+  - **Synthèse** — données essentielles uniquement, vue condensée
+  - **API/machine** — format structuré (JSON) pour les services externes
+- La combinaison **niveau × usage** détermine le template appliqué.
+- L'ordre et la composition des sections sont définis dans le template : modifier le template régénère les fiches en conséquence.
+- Les sources sont intégrées nativement dans le rendu (rattachées aux données, pas listées en vrac).
+
+### Pourquoi
+
+- Le format actuel (narration Markdown avec sections numérotées) mélange structure et contenu, rendant les fiches difficiles à maintenir et à faire évoluer.
+- Les fiches actuelles ne reflètent pas le mécanisme de sources structurées (points 2 et 3).
+- Pouvoir changer l'ordre des sections ou le format de rendu sans toucher aux données est essentiel pour un outil qui doit servir différents profils (admin, expert, service).
+
+### Décisions prises
+
+- Génération des fiches depuis les données via templates (inversion du flux actuel).
+- Deux axes de templates : par niveau du graphe et par usage.
+- L'affichage est piloté par le modèle associé au contexte d'affichage.
+
+---
+
+## Point 6 — Stockage : du DOT vers une base de données
+
+### Quoi
+
+Remplacer le fichier DOT (Graphviz) comme stockage primaire du graphe par une **base de données** capable de supporter :
+
+- Les données structurées rattachées aux nœuds et arêtes (indices, sources, tiers de confiance, périmètres)
+- Le requêtage (filtrage par indice, par minerai, par pays, etc.)
+- Un schéma évolutif (ajout d'indices eau, énergie, logistique sans refonte)
+- Les rôles d'accès (point 1)
+- L'exposition via API (point 1)
+
+Le format DOT peut rester comme **format d'import/export** mais n'est plus le stockage de référence.
+
+### Pourquoi
+
+- Le DOT ne supporte pas le requêtage, la gestion de versions des données, ni les relations entre graphes.
+- L'ajout d'un indice ou d'un attribut implique aujourd'hui de modifier le parsing du DOT.
+- Les évolutions prévues (multi-graphes, sources structurées, API) dépassent les capacités du format fichier.
+
+### Contexte : architecture multi-graphes (à détailler dans un point futur)
+
+Le graphe unique actuel (4 niveaux, chaîne minerai → produit final) sera complété par :
+
+- **Chaînes connexes** — dépendances indirectes nécessaires à la fabrication mais non constitutives du produit (ex : quartz ultra-pur → creuset → wafer).
+- **Chaînes de composants détaillés** — un composant (résistance, condensateur) a sa propre chaîne de valeur complète, connectée au graphe principal via un lien au nœud composant.
+
+Cette architecture composable permet de gérer la complexité sans surcharger le graphe principal : on "zoome" sur un composant en suivant le lien vers sa chaîne dédiée. La base de données doit supporter nativement cette interconnexion de graphes.
+
+### Décisions prises
+
+- Le DOT n'est plus le stockage primaire.
+- Le choix technologique (base graphe type Neo4j Community, PostgreSQL+AGE, ArangoDB, ou autre) reste ouvert. Toutes les options sont open source. Critère supplémentaire du spike : **réversibilité par rapport aux décisions différées** (open source, modèle commercial). Neo4j Community évolue facilement vers Enterprise, mais un passage à PostgreSQL+AGE ne l'est pas. Inversement, PostgreSQL+AGE laisse plus d'options ouvertes côté licence au prix d'une maturité graphe moindre.
+- **Backup** : stratégie de sauvegarde à définir, mais simplifiée par la cadence d'évolution modérée du graphe.
+- **Cadence de mise à jour** : mensuelle au démarrage (pour roder le workflow), puis trimestrielle une fois stabilisé. Alertes veille hors cadence pour les événements critiques.
+- L'architecture multi-graphes (essentiel/connexe) est identifiée comme point futur à part entière.
+
+---
+
+## Point 7 — Validation du modèle de niveaux
+
+### Quoi
+
+Revoir et valider les niveaux de décomposition de la chaîne de valeur. Deux axes de réflexion :
+
+- **Les étapes de la chaîne (axe vertical)** — les niveaux actuels (Extraction, Réserves, Traitement, Fabrication, Assemblage) ne sont pas universels. Certains minerais sautent des étapes (hélium : pas de raffinage), d'autres ne sont pas des minerais classiques (dérivés pétroliers). Piste privilégiée : des **intitulés génériques** (ex : "Transformation primaire" plutôt que "Raffinage") pour que tous les matériaux se positionnent aux mêmes niveaux, facilitant la comparaison et le requêtage.
+- **La profondeur des dépendances (axe horizontal)** — jusqu'où remonte-t-on ? L'excavatrice qui extrait le minerai a sa propre chaîne de valeur. Critère d'arrêt : si une partie du graphe réel est identifiée comme pertinente, elle est intégrée en **chaîne connexe** (cf. point 6) sous forme de graphe minimum associé au bon niveau.
+
+### Méthode de validation
+
+La validation porte sur **deux axes complémentaires** (pas alternatifs) :
+
+- **Axe vertical (quels niveaux, quels intitulés génériques)** — validé par **revue de littérature**. Références pertinentes pour la décomposition matière : USGS mineral commodity summaries et flux de matières, études JRC sur les matières premières critiques, travaux IEA sur les chaînes de valeur énergie-matière, analyses de cycle de vie matière (ACV), Open Supply Hub, Responsible Minerals Initiative. Note : SCOR et ISO 28000 traitent de la gestion process de la supply chain, pas de la décomposition matière — à mentionner en contrepoint uniquement, pas comme benchmark principal.
+- **Axe horizontal (jusqu'où remonter dans la profondeur des dépendances)** — validé par **démonstration via les marges d'erreur** cumulées. Montrer qu'ajouter des niveaux n'améliorerait pas la précision des résultats. Pas de bibliographie nécessaire, c'est un argument analytique.
+
+### Pourquoi
+
+- Le modèle de niveaux conditionne toute la structure du graphe, les indices, les templates de fiches et l'API.
+- Un modèle mal calibré (trop simple ou trop détaillé) compromet soit la pertinence soit l'utilisabilité.
+- La crédibilité scientifique du projet nécessite des choix de modélisation justifiés.
+
+### Questions ouvertes
+
+- Quels intitulés génériques pour les niveaux ? (à définir après revue de littérature)
+- Le nombre de niveaux doit-il être fixe ou configurable par chaîne ?
+
+### Modèle de niveaux — Cas possibles
+
+![Modèle de niveaux — Cas possibles](modele-niveaux-cas-possibles.png){ width=100% }
+
+---
+
+## Point 8 — Services, sécurisation et profils de visibilité
+
+### Quoi
+
+Définir les services exposés par l'API, leur sécurisation et les niveaux de visibilité.
+
+**Familles de services identifiées :**
+
+- **Requêtage du graphe** — chemins critiques, filtrage, sous-graphes. Deux niveaux : expert (complet) et simplifié (clients).
+- **Méta-indices dynamiques** — indices agrégés calculés sur un sous-graphe sélectionné (ex : IHH agrégé de la chaîne cobalt → smartphones). Les indices de base sont pré-calculés à chaque mise à jour du graphe et servis comme données.
+- **Analyse** — vulnérabilités, comparaison de scénarios. Deux niveaux (expert / simplifié).
+- **Administration** — CRUD graphe, gestion des sources, import/export (rôle admin uniquement).
+- **Données structurées** — fiches (tous templates/usages), données brutes, sources associées.
+- **Génération** — rapports, exports (PDF, JSON, DOT) — consommateurs externes.
+- **Personnalisation client** — un client fournit son SI / sa nomenclature, on le projette sur le graphe FabNum pour obtenir :
+  - Sa carte de risques propre (minerais critiques pour *son* SI)
+  - De la veille/alertes ciblées sur *ses* dépendances
+  - Des rapports contextualisés
+
+**Sécurisation :**
+
+- **Authentification** — utilisateur (Streamlit) vs service externe (clé API / token).
+- **Autorisation par rôle** (admin, expert, service) — cf. point 1.
+- **Profils de visibilité** — complémentaires aux rôles, définissent *ce qu'on peut voir* :
+  - Chaîne principale seule vs chaîne + connexes
+  - Tous les indices vs un sous-ensemble
+  - Graphe complet vs sous-graphe filtré
+  - Profils prédéfinis (ex : gratuit/standard/complet) ou sur mesure par client
+- **Rate limiting** — protection du moteur contre les abus.
+- **Monitoring / observabilité** — logging structuré, métriques, alerting (service d'administration).
+
+**Données client et RGPD :**
+
+- **Principe : moteur stateless côté client** — le client envoie son SI, le moteur croise avec le graphe, renvoie le résultat, rien ne persiste sur le serveur. Faisabilité à valider selon les traitements (veille ciblée → nécessite potentiellement du stockage).
+- **Alternative : agent local chez le client** — un agent déployé côté client consomme l'API et stocke les résultats localement. Les données client ne quittent jamais leur périmètre.
+- **Action manuelle** — export/import pour les cas simples.
+- **RGPD** — à garder à l'esprit pour la phase commerciale.
+
+**Documentation utilisateur :**
+
+- Prématurée mais importante. À produire quand le système sera stabilisé (API, fiches, services).
+
+### Pourquoi
+
+- L'API sans services définis et sécurisés est inutilisable.
+- La personnalisation client transforme FabNum d'un outil générique en **plateforme de services à valeur ajoutée**.
+- Les profils de visibilité permettent de proposer des niveaux de service différenciés et de protéger les données sensibles.
+
+### Décisions prises
+
+- Les indices de base sont pré-calculés (pas de service de calcul à la volée), sauf les méta-indices dynamiques sur sélection.
+- La personnalisation client (projection de SI sur le graphe) est identifiée comme service à forte valeur.
+- Rôles (ce qu'on peut faire) et profils (ce qu'on peut voir) sont deux axes distincts.
+- Moteur stateless côté données client (objectif), agent local client ou export manuel comme alternatives.
+
+**Interface concrète avec IRON** — FabNum ne se substitue pas à IRON, il le complète. FabNum fournit le diagnostic de fragilité technique de la chaîne, IRON évalue la capacité organisationnelle à encaisser et contourner (distinction Hamant résilience/robustesse). Usages concrets d'appel croisé :
+
+- IRON consomme des analyses FabNum via l'API comme intrants de l'évaluation Y-axis ou Z-axis.
+- FabNum produit en sortie une liste de dépendances critiques qu'IRON utilise dans son diagnostic.
+- Un score IRON peut en retour contextualiser une analyse FabNum : pour une organisation donnée, telle dépendance est critique parce que leur robustesse sur ce point est faible.
+
+---
+
+## Point 9 — Multi-sectoriel et architecture des graphes
+
+### Quoi
+
+FabNum ne se limite pas nécessairement au numérique. Le moteur pourrait servir d'autres secteurs (embarqué, automobile, énergie...) avec la même mécanique.
+
+- Chaque **secteur** a son graphe principal (sa chaîne de valeur propre).
+- Les secteurs peuvent devenir des **connexes les uns des autres** (l'embarqué est un connexe de l'automobile ; le numérique est un connexe de l'embarqué).
+- Les **minerais sont partagés** entre les graphes — le cobalt apparaît dans le numérique, l'automobile et l'embarqué.
+- Le moteur reste le même, seuls les graphes et leurs interconnexions changent.
+
+Ce point englobe et généralise la réflexion essentiel/connexe mentionnée au point 6.
+
+### Pourquoi
+
+- L'architecture multi-graphes (point 6) prend tout son sens à l'échelle multi-sectorielle.
+- Les minerais critiques sont par nature transversaux — les analyser secteur par secteur sans voir les interdépendances est réducteur.
+- Ça renforce le besoin d'un modèle de niveaux générique (point 7) et d'une base de données capable de gérer ces relations (point 6).
+
+### Décisions prises
+
+- La vision multi-sectorielle est retenue comme horizon, pas comme priorité immédiate.
+- L'architecture doit la rendre possible sans la requérir dès le départ.
+
+---
+
+## Point 10 — Intégration des ressources transversales (énergie, eau)
+
+### Quoi
+
+Énergie et eau ne sont pas des niveaux de la chaîne de valeur mais des **ressources transversales** consommées à chaque opération (extraction, transformation, fabrication, assemblage). Il faut :
+
+- Définir **comment les modéliser** dans le graphe — attributs d'opération, nœuds de ressource connectés aux opérations, ou autre approche.
+- Résoudre le **problème de granularité** — il faut pouvoir rattacher la consommation au bon niveau de chaque opération, avec une dimension géographique (disponibilité eau/énergie par pays).
+- Travailler sur le **sourçage** de données aujourd'hui parcellaires — les consommations énergétiques et hydriques par opération et par pays sont mal documentées. Il faudra probablement travailler avec des fourchettes et estimations, en s'appuyant sur le système de tiers de confiance (point 3).
+
+L'objectif est de pouvoir détecter des **croisements de risques** : pays instable (ISG) + stress hydrique + concentration d'une opération (IHH) = alerte.
+
+### Pourquoi
+
+- L'énergie est un facteur de risque majeur et croissant (cf. détroit d'Ormuz et impact sur la chaîne numérique : [Impact du détroit d'Ormuz sur la chaîne numérique](https://conseil.peccini.fr/articles/impact-ormuz-chaine-numerique/)).
+- L'eau est un facteur de risque émergent, en particulier pour l'extraction et la transformation (lithium au Chili, semi-conducteurs à Taïwan).
+- Sans ces données, le modèle est aveugle à des scénarios de rupture réalistes.
+
+### Difficultés identifiées
+
+- Données très parcellaires — pas de base de données globale "consommation énergie/eau par opération minière par pays".
+- Granularité hétérogène des sources (données pays vs données site vs données sectorielles).
+- Les données devront être intégrées progressivement, au fur et à mesure de leur disponibilité.
+
+### Décisions prises
+
+- Identifié comme chantier nécessaire mais difficile — la réflexion sur le sourçage et la modélisation est à mener.
+- Le modèle de données (point 3) et la base de données (point 6) doivent être conçus pour accueillir ces ressources transversales, même si les données ne sont pas disponibles immédiatement.
+
+---
+
+## Point 11 — Granularité géographique fine et risques climatiques
+
+### Quoi
+
+Passer d'une géographie au niveau pays à une **localisation fine des opérations** (région, province, site) pour croiser avec des données de risques climatiques et environnementaux (stress hydrique, inondation, canicule, sécheresse).
+
+- **Localisation fine des opérations** — identifier où se trouvent physiquement les sites de production, et idéalement la part de production de chaque site.
+- **Croisement avec des données de risques** — stress hydrique (WRI Aqueduct, données ouvertes), risques d'inondation/canicule (ND-GAIN), événements historiques.
+- **Alertes contextualisées** — un événement climatique dans une zone → alerte automatique sur les opérations concernées (lien avec la veille, point 2b).
+
+**Niveaux d'approximation envisagés :**
+
+| Niveau | Granularité | Données nécessaires | Faisabilité |
+| --- | --- | --- | --- |
+| 1 | Pays | Risque climatique moyen pays | Disponible (ISG actuel) |
+| 2 | Région/province | Données climatiques régionales | Faisable (WRI Aqueduct, ND-GAIN) |
+| 3 | Site exact + part de production | Géolocalisation + répartition production | Difficile, partiel |
+
+Le niveau 3 ne sera pas atteignable pour tous les opérateurs, mais peut l'être pour les **nœuds les plus critiques** — ceux à IHH élevé où un incident aurait un impact systémique (exemples : Spruce Pine pour le quartz ultra-pur, Bayan Obo pour les terres rares, triangle du lithium).
+
+### Pourquoi
+
+- Spruce Pine (2024) : une seule mine de quartz ultra-pur, un ouragan, et toute la chaîne des semi-conducteurs menacée.
+- 40% des nouvelles fabs de semi-conducteurs sont construites dans des zones en stress hydrique.
+- Le risque climatique au niveau pays est trop grossier — la Chine a des zones arides et des zones inondables, un risque moyen pays n'a pas de sens.
+- L'utilité est certaine ; c'est la faisabilité du sourçage qui doit être évaluée.
+
+### Difficultés identifiées
+
+- **Opacité** — les opérateurs (surtout chinois et petits producteurs) ne publient pas toujours la localisation de leurs sites.
+- **Répartition de production** — même quand on connaît les sites d'un opérateur, la part de chaque site dans sa production totale est rarement publique.
+- **Hétérogénéité des sources** — données de géolocalisation minière (S&P Global, USGS mineral facilities) vs données climatiques (WRI, ND-GAIN) vs rapports annuels d'entreprises — formats et granularités différents.
+
+### Décisions prises
+
+- L'utilité est validée, la faisabilité est à évaluer.
+- Approche par niveaux d'approximation — on ne vise pas le niveau 3 partout, mais en priorité sur les nœuds critiques (IHH élevé, impact systémique).
+- Lien fort avec la veille (point 2b) pour les alertes événementielles.
+
+---
+
+## Point 12 — Stocks et projection temporelle
+
+### Quoi
+
+Intégrer les **niveaux de stock** comme donnée du graphe pour permettre des **scénarios de projection temporelle** : en cas de rupture d'approvisionnement, estimer le délai d'impact le long de la chaîne de valeur.
+
+- **Stock comme attribut de nœud** — chaque nœud pertinent (opération, composant) porte une estimation de stock (en mois de consommation, tonnes, unités).
+- **Moteur de projection** — simulation de rupture à un point du graphe et propagation temporelle. Le résultat est **qualitatif ou chiffré selon l'indice de confiance** : si la confiance est suffisante, une fourchette chiffrée ("impact dans 4-8 mois") ; sinon, un résultat qualitatif ("impact court terme / moyen terme / long terme") avec l'indice de confiance associé. L'indice de confiance de la projection hérite par propagation de l'indice de fiabilité des données de stock mobilisées — ce n'est pas un nouvel indice à concevoir.
+- **Scénarios what-if** — un service de calcul dynamique, pas juste une requête sur le graphe.
+- **Rétro-analyse comme calibration** — rejouer des crises passées (Spruce Pine, quotas chinois) dont on connaît le déroulement réel, observer ce que le moteur aurait prédit avec les données de l'époque (en respectant la date de disponibilité effective), ajuster les seuils court/moyen/long terme. Pour une crise donnée, rejouer avec les deux versions de formule quand c'est pertinent : formule de l'époque (qu'aurions-nous vu venir ?) et formule actuelle (le moteur actuel capte-t-il mieux le signal ?).
+
+### Pourquoi
+
+- Passe FabNum de l'analyse **statique** (photo de la criticité à un instant T) à l'analyse **dynamique** (projection temporelle en cas de rupture).
+- Valeur très forte pour les clients : "votre SI dépend du germanium via les fibres optiques, impact estimé à moyen terme (4-8 mois) avec un indice de confiance de 0.4".
+- Les crises récentes (quotas chinois, Spruce Pine) montrent que le délai d'impact est une information critique pour la prise de décision.
+
+### Difficultés identifiées
+
+- **Données extrêmement sensibles** — les niveaux de stock sont la donnée la plus confidentielle pour les entreprises. Quasiment jamais publiée.
+- **Niveau de confiance faible** — on travaillera avec des estimations sectorielles, des moyennes, des fourchettes. L'indice de fiabilité (point 3) sera particulièrement bas sur ces données.
+- **Variabilité rapide** — les stocks évoluent beaucoup plus vite que les parts de marché. La cadence trimestrielle pourrait ne pas suffire pour cette donnée.
+
+### Décisions prises
+
+- Point identifié comme horizon — forte valeur, faisabilité difficile (sourçage).
+- Le stock est un attribut de nœud comme les autres — pas de refonte du modèle de données.
+- Le moteur de projection est un nouveau service de calcul à spécifier.
+
+---
+
+## Point 13 — Bus d'impact (traducteur d'événements externes)
+
+### Quoi
+
+Un **bus d'impact** qui maintient en continu un état situationnel du graphe en traduisant les événements du monde extérieur en impacts chiffrés. Par analogie avec un bus applicatif, il possède une double connaissance :
+
+- **Monde extérieur** — événements géopolitiques, climatiques, économiques, sanitaires, signaux faibles. Sources : veille 360°, actualités, données climatiques, alertes.
+- **Monde intérieur** — le graphe FabNum, ses nœuds, ses attributs, ses limites (granularité géographique, disponibilité des données).
+
+Le bus traduit un événement qualitatif ("inondation dans le Yunnan") en impacts quantitatifs sur des nœuds du graphe ("extraction de germanium dans le Yunnan : capacité réduite de 80%").
+
+**Architecture structurel / situationnel :**
+
+Le graphe FabNum a deux couches :
+
+- **Graphe structurel** — la chaîne de valeur telle qu'elle existe : acteurs, pays, capacités nominales, parts de marché, indices. Mis à jour trimestriellement (cycle structurel).
+- **Graphe situationnel** — le graphe structurel + les impacts en cours. Reflète la **réalité du terrain** à un instant T. Mis à jour en continu au rythme des événements (cycle situationnel).
+
+Les deux cycles sont **indépendants** :
+
+- Le cycle structurel (trimestriel) met à jour les données de base : qui opère quoi, où, avec quelle capacité nominale.
+- Le cycle situationnel (continu, au **rythme décisionnel** — dans l'heure pour un événement majeur si un COMEX doit se réunir) met à jour la réalité : cette mine est inondée, Ormuz est bloqué, les quotas sont en vigueur.
+
+**Le bus maintient une mémoire situationnelle** — il ne fait pas de traduction en one-shot. Les impacts s'accumulent, évoluent et se résolvent au fil du temps :
+
+- Un événement arrive → impact ajouté
+- La situation évolue ("l'inondation se résorbe") → impact mis à jour
+- L'événement est résolu → impact supprimé ou archivé
+
+Le graphe situationnel reflète ainsi en permanence la **situation mondiale réelle** et non un scénario ponctuel.
+
+**Fonctionnement :**
+
+- La **veille 360°** se connecte au bus et lui **propose** des événements (elle n'injecte pas directement).
+- L'**IA** analyse l'événement, identifie les nœuds concernés et propose des impacts chiffrés (nœud impacté, type d'impact, pourcentage de réduction, durée estimée).
+- Un **expert** valide ou corrige avant injection. Pas d'injection automatique non contrôlée.
+- Le **moteur** se connecte au bus et consomme le graphe situationnel. Il n'a pas besoin de comprendre les événements — il travaille sur un graphe avec des capacités réelles.
+
+**Deux sorties possibles du bus**, triées par l'expert :
+
+- **Sortie situationnelle** — impact temporaire sur les capacités réelles (inondation, blocage logistique, grève). Alimente le graphe situationnel.
+- **Sortie structurelle** — modification de la capacité nominale elle-même (fermeture définitive de mine, ouverture d'un nouvel opérateur, quota devenu politique permanente, reconfiguration durable d'une route). Alimente le graphe structurel hors cycle trimestriel.
+
+L'IA propose la catégorie, l'expert tranche. Sans cette distinction, un développeur coderait le bus comme un pipeline mono-sortie vers le situationnel, et une fermeture de mine serait un impact "-100% permanent" au lieu d'une modification structurelle.
+
+**Rôle de l'IA :**
+
+La traduction événement → impact est un problème de **raisonnement** (comprendre l'événement, identifier les nœuds concernés, estimer la sévérité), pas d'algorithme. Un LLM avec accès au graphe et aux données contextuelles est le bon outil. Le code seul ne peut pas gérer l'infinie variété des événements possibles.
+
+L'IA supervise aussi l'**évolution** de la situation : elle propose des mises à jour ("l'inondation au Yunnan est terminée, les mines reprennent à 60%"), l'expert valide.
+
+**Signaux faibles :**
+
+Le bus peut aussi traiter des signaux faibles (tensions diplomatiques, sécheresse naissante, changement de politique commerciale) avec une probabilité et une sévérité potentielle, permettant de construire des scénarios prospectifs.
+
+**Indices structurels vs situationnels :**
+
+Les indices se calculent sur les deux couches :
+
+- **IHH structurel** (capacité nominale) vs **IHH situationnel** (capacité réelle avec impacts) — permet de mesurer la dégradation en cours.
+- **IVC situationnel** — la pression concurrentielle des autres secteurs dépend de la situation mondiale. Si une crise ralentit l'automobile, sa consommation de cobalt chute et l'IVC effectif pour le numérique diminue. Au démarrage, calcul proportionnel ; à terme, ajustement dynamique basé sur les données de demande sectorielle. Ce point renforce le lien avec le multi-sectoriel (point 9) : l'IVC est le lien entre les secteurs sur les ressources partagées.
+
+### Pourquoi
+
+- Aujourd'hui, tester un scénario dans FabNum oblige à pointer manuellement un minerai et en déduire les impacts. Pas de lien avec le monde réel.
+- Les crises sont rarement mono-causales — elles combinent plusieurs événements simultanés (Ormuz + sécheresse + quotas).
+- La veille 360° a besoin d'un point d'entrée structuré pour alimenter le moteur.
+- Sans ce bus, le moteur est aveugle aux événements extérieurs.
+- Un graphe situationnel maintenu en continu donne aux clients une raison de rester connectés plutôt que de faire des analyses ponctuelles.
+
+### Décisions prises
+
+- Le bus d'impact est le **seul point de contact** entre le monde extérieur et le moteur — séparation des responsabilités.
+- Le bus maintient une **mémoire situationnelle** — les impacts s'accumulent et évoluent, pas de one-shot.
+- Deux couches de graphe : **structurel** (trimestriel) et **situationnel** (continu, rythme décisionnel).
+- Les indices se calculent sur les deux couches (structurel vs situationnel).
+- L'IA est un composant clé du bus (traduction et suivi), avec validation humaine obligatoire.
+- Le bus a **deux sorties** (situationnelle et structurelle) — l'expert tranche.
+- L'IVC situationnel dépend de la demande inter-sectorielle — proportionnel au démarrage, dynamique à terme.
+- **Coût opérationnel de l'IA** — à chiffrer au moment où la Vue 4 devient l'étape courante, pas avant. L'expérience du générateur de rapport actuel (modèles gratuits) fournit une base empirique pour extrapoler l'ordre de grandeur.
+- Point identifié comme horizon — dépend de la granularité géographique (point 11) et des stocks (point 12).
+
+---
+
+## Point 14 — Combinatoire multi-impacts et scénarios
+
+### Quoi
+
+Le moteur reçoit N impacts simultanés du bus (point 13), les applique sur le graphe et en déduit les conséquences cumulées via la projection temporelle (point 12).
+
+Ce n'est **pas un composant actif** mais une **propriété du moteur** : s'il est conçu dès le départ pour recevoir des impacts multiples du bus, la combinatoire est native. C'est une contrainte de conception, pas un développement séparé.
+
+**Concrètement :**
+
+- Chaque impact du bus coupe ou réduit une ou plusieurs branches du graphe.
+- Le moteur fait tourner la projection temporelle (point 12) sur le graphe dégradé.
+- Le résultat montre quels produits finaux sont impactés, dans quel délai, avec quelle sévérité.
+- Si deux événements coupent deux sources différentes d'un même minerai, l'impact combiné est pire que chaque événement seul — le moteur le calcule naturellement.
+
+**Scénarios :**
+
+- Plusieurs scénarios (combinaisons d'événements) peuvent coexister et être comparés.
+- Les scénarios peuvent être contextualisés au client : "votre SI dépend de ces chaînes, voici votre exposition face à ce scénario".
+
+### Pourquoi
+
+- Les crises sont multi-causales — un seul événement isolé ne reflète pas la réalité.
+- La valeur du moteur est dans la combinaison : montrer que tel produit final résiste à un événement isolé mais pas à la combinaison de deux.
+- C'est un service à très forte valeur pour les clients (COMEX, DSI).
+
+### Décisions prises
+
+- Le point 14 est une **contrainte de conception du moteur**, pas un développement séparé. L'asservissement au bus d'impact doit être prévu dès la conception.
+- Dépend du point 12 (stocks/projection temporelle) et du point 13 (bus d'impact).
+
+---
+
+## Ordre de réalisation logique
+
+L'ordre des points dans ce document reflète l'ordre de la discussion, pas l'ordre de réalisation. Le séquencement ci-dessous s'aligne sur les 4 vues architecturales présentées en fin de document.
+
+### Vue 1 — Le moteur (phases 1 à 4)
+
+Phase 1 — Fondations (parallélisable) :
+
+- **Point 7** — Validation du modèle de niveaux (fondation théorique, prérequis au modèle de données)
+- **Point 6 (spike)** — Spike technique sur 2-3 bases candidates (Neo4j Community, PostgreSQL+AGE, ArangoDB) avec un mini-graphe de test. En parallèle du point 7.
+
+Phase 2 — Modèle et stockage :
+
+- **Point 3** — Modèle de données structuré (dépend des niveaux validés). Conçu dès le départ pour supporter les deux couches (structurel/situationnel) et l'asservissement au bus d'impact (point 14).
+- **Point 6 (implémentation)** — Mise en place du stockage retenu après le spike.
+
+Phase 3 — Données et sources :
+
+- **Point 2** — Gestion des sources (peut démarrer en parallèle dès la phase 2 pour l'identification/catégorisation)
+- **Point 4** — Amorçage et qualification sur un échantillon représentatif : 3 minerais + 1 composant + 1 produit final. Puis audit d'exhaustivité des matières premières.
+
+Phase 4 — Fiches et API :
+
+- **Point 5** — Templates et génération des fiches
+- **Point 1** — API REST et rôles
+- **Point 8** — Services, sécurisation, profils
+
+### Vue 2 — Veille sur les sources et propagation
+
+- **Point 2 (veille)** — Activation de la veille sur les sources (huginn), vérification des citations. Cycle structurel trimestriel.
+- **Propagation d'impact** — Le moteur gagne la capacité de simulation manuelle ("que se passe-t-il si ce nœud est coupé ?").
+
+### Vue 3 — Veille stratégique 360°
+
+- **Intégration écosystème 360°** — La veille stratégique se connecte sur deux points : requête l'API et propose des sources (validées par l'expert avant intégration).
+
+### Vue 4 — Architecture complète
+
+- **Point 11** — Granularité géographique fine (prérequis à la précision du bus d'impact)
+- **Point 10** — Ressources transversales (énergie, eau)
+- **Point 12** — Stocks et projection temporelle
+- **Point 13** — Bus d'impact (traducteur d'événements → impacts chiffrés, IA assistée, mémoire situationnelle). Scission de la base en graphe structurel / graphe situationnel.
+- **Point 14** — Combinatoire multi-impacts (native si le moteur est asservi au bus dès la conception)
+- **Point 9** — Multi-sectoriel (le plus lointain)
+
+## MVP (jalon interne)
+
+**Définition** : moteur fonctionnel avec données réelles dans une vraie base, requêtable, données sourcées avec indice de fiabilité. Pas de frontend, pas de produit fini — un jalon de validation interne.
+
+**Périmètre** : Vue 1 complète (points 7 → 6 → 3 → 2 → 4 → 5 → 1 → 8 : validation niveaux → spike techno → modèle de données → base → amorçage 3 minerais + 1 composant + 1 produit final → fiches → API).
+
+**Critère de succès** : on peut requêter la base et retrouver les mêmes analyses qu'aujourd'hui (ex : Sankey du germanium), avec des données sourcées et un indice de fiabilité.
+
+**Rétro-analyse** : valider les indices sur des crises passées (Spruce Pine, quotas chinois) comme preuve de concept.
+
+**Tests** : toute logique métier est testée (calculs d'indices, requêtage, arbitrage des sources, import/export). Pas de seuil de couverture arbitraire — on teste ce qui compte.
+
+\newpage
+
+## Progression architecturale
+
+L'architecture de FabNum v2 se construit par étapes. Chaque vue ajoute un bloc fonctionnel sans remettre en cause les précédents.
+
+### Vue 1 — Le moteur
+
+Le socle : un moteur d'analyse requêtable via API, alimenté par des sources externes qualifiées. L'administrateur gère le graphe par scripts, les experts et clients consomment via l'API.
+
+![Vue 1 — Le moteur](architecture-vue1.png){ width=100% }
+
+\newpage
+
+### Vue 2 — Veille sur les sources et propagation d'impact
+
+Les sources ne sont plus statiques — elles sont surveillées en continu (huginn). Le moteur gagne la capacité de **propagation d'impact** : l'expert peut simuler manuellement "que se passe-t-il si ce nœud est coupé ?" et observer la propagation dans le graphe. Les clients peuvent contextualiser leurs requêtes.
+
+![Vue 2 — Veille et propagation](architecture-vue2.png){ width=100% }
+
+\newpage
+
+### Vue 3 — Veille stratégique 360°
+
+Le monde extérieur interagit avec FabNum. L'écosystème de veille 360° se connecte sur deux points : il **requête l'API** pour obtenir des analyses et il **propose des sources** qui sont validées par l'expert avant intégration.
+
+![Vue 3 — Veille 360°](architecture-vue3.png){ width=100% }
+
+\newpage
+
+### Vue 4 — Architecture complète (bus d'impact, mémoire situationnelle, IA)
+
+Le **bus d'impact** traduit les événements du monde réel en impacts chiffrés sur le graphe, assisté par l'IA et validé par l'expert. Il maintient une **mémoire situationnelle** : le graphe reflète en permanence la situation mondiale réelle. La base de données se scinde en **graphe structurel** (capacités nominales, trimestriel) et **graphe situationnel** (capacités réelles avec impacts, continu). Les indices se calculent sur les deux couches.
+
+![Vue 4 — Architecture complète](architecture-vue4.png){ width=100% }
+
+\newpage
+
+## Diagramme d'Architecture Fonctionnelle (DAF)
+
+![Macro-DAF](macro-daf.png){ height=75% }
+
+\newpage
+
+## Diagramme d'Architecture Technique (DAT)
+
+![Macro-DAT](macro-dat.png){ width=100% }

docs/FabNum v2/PRESENTATION-V2.md

@@ -0,0 +1,47 @@
+# FabNum v2 — Ce qui change et pourquoi
+
+## En une phrase
+
+FabNum v2 passe d'un outil d'analyse statique à une **plateforme ouverte, fiable, capable de refléter la situation mondiale en temps réel** et d'anticiper les impacts sur les chaînes d'approvisionnement.
+
+## Ce que FabNum v1 sait faire
+
+FabNum v1 cartographie les dépendances du numérique (des minerais jusqu'aux produits finaux) et identifie les points de fragilité : concentration géographique, dépendance à un acteur unique, instabilité d'un pays. C'est une **photographie** de la situation.
+
+## Ce que FabNum v2 apporte
+
+### 1. Des données fiables et traçables
+
+Aujourd'hui, les données sont enfouies dans des fiches sans qu'on puisse facilement vérifier leur origine, leur pertinence, leur fiabilité. Demain, chaque chiffre est relié à sa source, chaque source est évaluée en fiabilité, et un système de veille détecte automatiquement quand une source évolue. On sait exactement ce qu'on sait — et ce qu'on ne sait pas.
+
+### 2. Une vision plus fine et plus complète de la chaîne
+
+FabNum v1 suit la chaîne principale : du minerai au produit final en quatre étapes. FabNum v2 va plus loin :
+
+- **Plus de précision dans les étapes** — on distingue mieux ce qui se passe entre l'extraction et le produit fini (transformation, semi-produits, fabrication). Chaque étape a ses propres acteurs, ses propres pays, ses propres risques — les confondre masque des vulnérabilités.
+- **Les dépendances cachées** — pour fabriquer un composant, il faut parfois des matériaux qui ne sont pas dans le produit final mais qui sont indispensables à sa fabrication (gaz rares pour la lithographie, quartz ultra-pur pour les creusets). FabNum v2 permet de cartographier ces dépendances indirectes et de les relier à la chaîne principale.
+- **La possibilité de s'étendre à d'autres secteurs** — automobile, embarqué, énergie — en réutilisant le même moteur et les mêmes données partagées (un même minerai sert à plusieurs secteurs).
+- **De nouveaux indices sont intégrés** — eau, énergie et logistique ; cela permet de cibler des impacts que la v1 ne peut pas faire émerger.
+- **La géographie s'affine** — afin de pouvoir intégrer des impacts localisés (inondation de mine), le découpage géographique, autant que faire se peut, intègre la notion de région voire de localité.
+- **Les stocks sont intégrés** — pour réussir à générer une propagation temporelle dans la chaîne, les stocks, toujours autant que faire se peut, sont ajoutés.
+
+### 3. Un moteur ouvert aux partenaires et aux clients
+
+FabNum v1 est une application fermée. FabNum v2 devient un **moteur** que d'autres outils peuvent interroger : un client peut obtenir une analyse de risques adaptée à son propre contexte, un partenaire peut intégrer les résultats de FabNum dans ses propres outils. Cela ouvre la voie à des offres de service.
+
+### 4. De la photographie au suivi en continu
+
+Au lieu d'une image figée, FabNum v2 suit la situation en continu en se connectant au monde extérieur. Quand un événement survient — une inondation qui ferme une mine, un embargo, une tension géopolitique — le système traduit cet événement en impact concret sur la chaîne et montre quels produits seront touchés, dans quel délai, et avec quelle sévérité. FabNum v2 n'est plus limitée aux impacts sur les minerais uniquement, mais sur toute la chaîne.
+
+### 5. Des scénarios combinés
+
+Les crises ne sont jamais isolées. FabNum v2 permet de combiner plusieurs événements simultanés et d'en mesurer l'effet cumulé : "si en plus de l'embargo sur le germanium, le détroit d'Ormuz est bloqué, quels sont les produits les plus exposés ?" C'est un outil d'aide à la décision pour les comités de direction.
+
+## Comment on y arrive — 4 étapes progressives
+
+| Étape      | Ce qu'on construit                                                | Ce que ça apporte                                                                                                 |
+| ----------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
+| **1** | Le moteur avec des données fiables et traçables                 | FabNum v1 remaniée : mêmes analyses, mais avec des données vérifiées et une interface ouverte aux partenaires |
+| **2** | La surveillance automatique des sources et la simulation d'impact | On peut répondre à "que se passe-t-il si..." et les données se mettent à jour périodiquement                  |
+| **3** | La connexion avec la veille stratégique                          | Le monde extérieur alimente FabNum, FabNum éclaire la veille — les deux se renforcent                           |
+| **4** | La situation en temps réel et les scénarios combinés           | FabNum reflète la réalité du terrain et permet d'anticiper les crises multi-causales                            |

docs/FabNum v2/architecture-globale.dot

@@ -0,0 +1,166 @@
+digraph architecture_fabnum {
+    // Configuration générale
+    rankdir=TB;
+    fontname="Arial";
+    fontsize=18;
+    label="FabNum — Architecture globale\n\n";
+    labelloc=t;
+    splines=true;
+    nodesep=0.7;
+    ranksep=0.9;
+    node [fontname="Arial", fontsize=11, style="filled,rounded", shape=box, penwidth=1.5];
+    edge [fontname="Arial", fontsize=9, penwidth=1.2];
+
+    // ==================== UTILISATEURS ====================
+
+    admin [
+        label="Administrateur\n\nGère le graphe structurel,\nles sources, les tiers\nde confiance, les arbitrages"
+        fillcolor="#FFE082"
+        shape=house
+        fontsize=10
+    ];
+
+    expert [
+        label="Expert\n\nAnalyse les risques,\nqualifie les données,\nvalide les impacts"
+        fillcolor="#A5D6A7"
+        shape=house
+        fontsize=10
+    ];
+
+    client [
+        label="Client\n(COMEX, Métiers, DSI)\n\nConsulte les analyses,\nles fiches, les alertes.\nPeut contextualiser\nses requêtes."
+        fillcolor="#EF9A9A"
+        shape=house
+        fontsize=10
+    ];
+
+    // ==================== ÉCOSYSTÈME / VEILLE 360° ====================
+
+    ecosysteme [
+        label="Écosystème\nveille 360°\n\nDétecte les événements,\nalimente les sources\net le bus d'impact"
+        fillcolor="#CE93D8"
+        shape=house
+        fontsize=10
+    ];
+
+    // ==================== API ====================
+
+    api [
+        label="API\n\nPoint d'accès unique\nAuthentification, rôles,\nprofils de visibilité\n\nSert le graphe situationnel\n(structurel accessible aussi)"
+        fillcolor="#B39DDB"
+        fontsize=11
+        penwidth=2
+    ];
+
+    // ==================== BUS D'IMPACT ====================
+
+    bus [
+        label="Bus d'impact\n\nMémoire situationnelle\nTraduction événements → impacts\nAccumule, met à jour, archive\nMise à jour en continu\n(rythme décisionnel)"
+        fillcolor="#FF8A65"
+        fontsize=11
+        penwidth=2.5
+        style="filled,rounded,bold"
+    ];
+
+    ia_bus [
+        label="IA\n\nAnalyse les événements,\npropose les impacts\nchiffrés"
+        fillcolor="#FFCC80"
+        fontsize=10
+    ];
+
+    // ==================== MOTEUR ====================
+
+    moteur [
+        label="Moteur FabNum\n\nCalcul des indices\n(structurels et situationnels)\nRequêtage, chemins critiques\nGénération fiches (templates)\nArbitrage sources\nProjection temporelle"
+        fillcolor="#90CAF9"
+        fontsize=11
+        penwidth=2
+    ];
+
+    // ==================== BASE DE DONNÉES ====================
+
+    subgraph cluster_bdd {
+        label="Base de données (graphe)";
+        style=filled;
+        color="#E0F2F1";
+        fontsize=11;
+        fontcolor="#00695C";
+
+        bdd_struct [
+            label="Graphe structurel\n\nCapacités nominales\nActeurs, pays, parts de marché\nIndices structurels\nMise à jour trimestrielle"
+            fillcolor="#80CBC4"
+            fontsize=10
+        ];
+
+        bdd_situa [
+            label="Graphe situationnel\n\nImpacts actifs\nCapacités réelles\nIndices situationnels\nHistorique des situations"
+            fillcolor="#4DB6AC"
+            fontsize=10
+        ];
+    }
+
+    // ==================== VEILLE SUR LES SOURCES ====================
+
+    veille [
+        label="Veille sources\n\nSurveillance des sources (huginn)\nVérification des citations\nAlertes (variations)"
+        fillcolor="#FFAB91"
+        fontsize=10
+        penwidth=1.5
+    ];
+
+    // ==================== SOURCES ====================
+
+    sources [
+        label="Sources externes\n\nUSGS, Statista, BRGM,\nScholar Gateway, Consensus,\nWRI Aqueduct, ND-GAIN..."
+        fillcolor="#E0E0E0"
+        shape=cylinder
+        fontsize=10
+    ];
+
+    // ==================== DISPOSITION ====================
+
+    { rank=same; admin; expert; client; ecosysteme; }
+    { rank=same; bus; api; }
+    { rank=same; ia_bus; moteur; }
+
+    // ==================== RELATIONS ====================
+
+    // Expert → API + validation impacts
+    expert -> api [label="consulte\nanalyse", color="#2E7D32"];
+    expert -> bus [label="valide\nles impacts", color="#E65100", style=bold];
+
+    // Client → API
+    client -> api [label="consulte\nles résultats", color="#C62828"];
+
+    // Écosystème → Bus d'impact + Sources
+    ecosysteme -> bus [label="injecte\ndes événements", color="#6A1B9A", penwidth=2];
+    ecosysteme -> sources [label="alimente\nles sources", color="#6A1B9A", style=dashed];
+
+    // Admin → Moteur (accès direct par scripts)
+    admin -> moteur [label="administre\n(scripts)", color="#E65100", style=bold, penwidth=2];
+
+    // IA ↔ Bus
+    bus -> ia_bus [label="événement\nà analyser", color="#E65100", dir=both];
+
+    // Bus → Moteur (impacts chiffrés)
+    bus -> moteur [label="impacts\nchiffrés", color="#BF360C", penwidth=2];
+
+    // API ↔ Moteur
+    api -> moteur [label="transmet\nles requêtes", color="#4527A0", dir=both];
+
+    // Moteur ↔ Base de données
+    moteur -> bdd_struct [label="lit/écrit\nstructurel", color="#00695C", dir=both];
+    moteur -> bdd_situa [label="lit/écrit\nsituationnel", color="#00695C", dir=both];
+
+    // Bus → BDD situationnel
+    bus -> bdd_situa [label="met à jour\nles impacts", color="#BF360C", style=dashed];
+
+    // Veille → Sources
+    sources -> veille [label="surveille\nles MAJ", color="#BF360C"];
+
+    // Veille → BDD structurel
+    veille -> bdd_struct [label="met à jour\nles sources", color="#E65100", style=dashed];
+
+    // Sources → BDD structurel
+    sources -> bdd_struct [label="alimente\nles données", color="#546E7A", style=dashed];
+}

docs/FabNum v2/architecture-vue1.dot

@@ -0,0 +1,73 @@
+digraph architecture_vue1 {
+    rankdir=TB;
+    fontname="Arial";
+    fontsize=18;
+    label="FabNum — Vue 1 : Le moteur\nRequêtage, indices, fiches via API\n";
+    labelloc=t;
+    splines=true;
+    nodesep=0.7;
+    ranksep=0.9;
+    node [fontname="Arial", fontsize=10, style="filled,rounded", shape=box, penwidth=1.5];
+    edge [fontname="Arial", fontsize=9, penwidth=1.2];
+
+    // Ligne 1 : utilisateurs (4 colonnes fixes)
+    admin [
+        label="Administrateur\n\nGère le graphe,\nles sources, les tiers\nde confiance"
+        fillcolor="#FFE082" shape=house
+    ];
+    expert [
+        label="Expert\n\nAnalyse les risques,\nqualifie les données"
+        fillcolor="#A5D6A7" shape=house
+    ];
+    client [
+        label="Client\n(COMEX, Métiers, DSI)\n\nConsulte les analyses,\nles fiches, les alertes."
+        fillcolor="#EF9A9A" shape=house
+    ];
+    // Placeholder veille 360° (invisible)
+    ph_eco [label="" shape=point width=0.01 style=invis];
+    { rank=same; admin; expert; client; ph_eco; }
+
+    // Ligne 2 : API + placeholder bus
+    api [
+        label="API\n\nPoint d'accès unique\nAuthentification, rôles,\nprofils de visibilité"
+        fillcolor="#B39DDB" penwidth=2
+    ];
+    // Placeholder bus (invisible)
+    ph_bus [label="" shape=point width=0.01 style=invis];
+    { rank=same; api; ph_bus; }
+
+    // Ligne 3 : Moteur + placeholders
+    moteur [
+        label="Moteur FabNum\n\nCalcul des indices\n(IHH, ICS, IVC, ISG)\nRequêtage du graphe\nChemins critiques\nGénération fiches (templates)\nArbitrage des sources"
+        fillcolor="#90CAF9" penwidth=2
+    ];
+    // Placeholder IA (invisible)
+    ph_ia [label="" shape=point width=0.01 style=invis];
+    // Placeholder veille (invisible)
+    ph_veille [label="" shape=point width=0.01 style=invis];
+    { rank=same; ph_veille; moteur; ph_ia; }
+
+    // Ligne 4 : BDD + sources
+    bdd [
+        label="Base de données\n(graphe)\n\nNœuds, relations, indices\nSources rattachées\nHistorique des données"
+        fillcolor="#80CBC4" penwidth=2
+    ];
+    sources [
+        label="Sources externes\n\nUSGS, Statista, BRGM,\nScholar Gateway, Consensus,\nWRI Aqueduct, ND-GAIN..."
+        fillcolor="#E0E0E0" shape=cylinder
+    ];
+    { rank=same; bdd; sources; }
+
+    // Relations
+    expert -> api [label="consulte\nanalyse", color="#2E7D32"];
+    client -> api [label="consulte\nles résultats", color="#C62828"];
+    admin -> moteur [label="administre\n(scripts)", color="#E65100", style=bold, penwidth=2];
+    api -> moteur [label="transmet\nles requêtes", color="#4527A0", dir=both];
+    moteur -> bdd [label="lit et écrit\nles données", color="#00695C", dir=both];
+    sources -> bdd [label="alimente\nles données", color="#546E7A", style=dashed];
+
+    // Liens invisibles pour stabiliser la disposition
+    ph_eco -> ph_bus [style=invis];
+    ph_bus -> ph_ia [style=invis];
+    ph_veille -> bdd [style=invis];
+}

docs/FabNum v2/architecture-vue2.dot

@@ -0,0 +1,77 @@
+digraph architecture_vue2 {
+    rankdir=TB;
+    fontname="Arial";
+    fontsize=18;
+    label="FabNum — Vue 2 : Veille sur les sources et propagation\nSources surveillées, simulation d'impact manuelle\n";
+    labelloc=t;
+    splines=true;
+    nodesep=0.7;
+    ranksep=0.9;
+    node [fontname="Arial", fontsize=10, style="filled,rounded", shape=box, penwidth=1.5];
+    edge [fontname="Arial", fontsize=9, penwidth=1.2];
+
+    // Ligne 1 : utilisateurs (4 colonnes fixes)
+    admin [
+        label="Administrateur\n\nGère le graphe,\nles sources, les tiers\nde confiance"
+        fillcolor="#FFE082" shape=house
+    ];
+    expert [
+        label="Expert\n\nAnalyse les risques,\nqualifie les données,\nsimule des scénarios\nd'impact (propagation),\ncontextualise"
+        fillcolor="#A5D6A7" shape=house
+    ];
+    client [
+        label="Client\n(COMEX, Métiers, DSI)\n\nConsulte les analyses,\nles fiches, les alertes.\nPeut contextualiser\nses requêtes."
+        fillcolor="#EF9A9A" shape=house
+    ];
+    // Placeholder veille 360° (invisible)
+    ph_eco [label="" shape=point width=0.01 style=invis];
+    { rank=same; admin; expert; client; ph_eco; }
+
+    // Ligne 2 : API + placeholder bus
+    api [
+        label="API\n\nPoint d'accès unique\nAuthentification, rôles,\nprofils de visibilité"
+        fillcolor="#B39DDB" penwidth=2
+    ];
+    // Placeholder bus (invisible)
+    ph_bus [label="" shape=point width=0.01 style=invis];
+    { rank=same; api; ph_bus; }
+
+    // Ligne 3 : Moteur + placeholder IA + veille
+    moteur [
+        label="Moteur FabNum\n\nCalcul des indices\n(IHH, ICS, IVC, ISG)\nRequêtage du graphe\nChemins critiques\nGénération fiches (templates)\nArbitrage des sources\nPropagation d'impact\n(simulation manuelle)"
+        fillcolor="#90CAF9" penwidth=2
+    ];
+    // Placeholder IA (invisible)
+    ph_ia [label="" shape=point width=0.01 style=invis];
+    veille [
+        label="Veille sources\n\nSurveillance des sources\n(huginn)\nVérification des citations\nAlertes (variations)"
+        fillcolor="#FFAB91" penwidth=1.5
+    ];
+    { rank=same; veille; moteur; ph_ia; }
+
+    // Ligne 4 : BDD + sources
+    bdd [
+        label="Base de données\n(graphe)\n\nNœuds, relations, indices\nSources rattachées\nHistorique des données"
+        fillcolor="#80CBC4" penwidth=2
+    ];
+    sources [
+        label="Sources externes\n\nUSGS, Statista, BRGM,\nScholar Gateway, Consensus,\nWRI Aqueduct, ND-GAIN..."
+        fillcolor="#E0E0E0" shape=cylinder
+    ];
+    { rank=same; bdd; sources; }
+
+    // Relations
+    expert -> api [label="consulte, analyse\net simule", color="#2E7D32"];
+    client -> api [label="consulte\nles résultats", color="#C62828"];
+    admin -> moteur [label="administre\n(scripts)", color="#E65100", style=bold, penwidth=2];
+    api -> moteur [label="transmet\nles requêtes", color="#4527A0", dir=both];
+    moteur -> bdd [label="lit et écrit\nles données", color="#00695C", dir=both];
+    sources -> veille [label="surveille\nles MAJ", color="#BF360C"];
+    veille -> bdd [label="met à jour\nles sources", color="#E65100", style=dashed];
+    veille -> moteur [label="signale les\nchangements\net vérifie\nles citations", color="#E65100"];
+    sources -> bdd [label="alimente\nles données", color="#546E7A", style=dashed];
+
+    // Liens invisibles pour stabiliser
+    ph_eco -> ph_bus [style=invis];
+    ph_bus -> ph_ia [style=invis];
+}

docs/FabNum v2/architecture-vue3.dot

@@ -0,0 +1,89 @@
+digraph architecture_vue3 {
+    rankdir=TB;
+    fontname="Arial";
+    fontsize=18;
+    label="FabNum — Vue 3 : Veille stratégique 360°\nLe monde extérieur interagit avec FabNum\n";
+    labelloc=t;
+    splines=true;
+    nodesep=0.7;
+    ranksep=0.9;
+    node [fontname="Arial", fontsize=10, style="filled,rounded", shape=box, penwidth=1.5];
+    edge [fontname="Arial", fontsize=9, penwidth=1.2];
+
+    // Ligne 1 : utilisateurs (4 colonnes fixes)
+    admin [
+        label="Administrateur\n\nGère le graphe,\nles sources, les tiers\nde confiance"
+        fillcolor="#FFE082" shape=house
+    ];
+    expert [
+        label="Expert\n\nAnalyse les risques,\nqualifie les données,\nsimule des scénarios\nd'impact,\nvalide les sources"
+        fillcolor="#A5D6A7" shape=house
+    ];
+    client [
+        label="Client\n(COMEX, Métiers, DSI)\n\nConsulte les analyses,\nles fiches, les alertes.\nPeut contextualiser\nses requêtes."
+        fillcolor="#EF9A9A" shape=house
+    ];
+    ecosysteme [
+        label="Écosystème\nveille 360°\n\nDétecte les événements,\npropose des sources,\nrequête FabNum"
+        fillcolor="#CE93D8" shape=house
+    ];
+    { rank=same; admin; expert; client; ecosysteme; }
+
+    // Ligne 2 : API + placeholder bus
+    api [
+        label="API\n\nPoint d'accès unique\nAuthentification, rôles,\nprofils de visibilité"
+        fillcolor="#B39DDB" penwidth=2
+    ];
+    // Placeholder bus (invisible)
+    ph_bus [label="" shape=point width=0.01 style=invis];
+    { rank=same; api; ph_bus; }
+
+    // Ligne 3 : Moteur + placeholder IA + veille
+    moteur [
+        label="Moteur FabNum\n\nCalcul des indices\n(IHH, ICS, IVC, ISG)\nRequêtage du graphe\nChemins critiques\nGénération fiches (templates)\nArbitrage des sources\nPropagation d'impact"
+        fillcolor="#90CAF9" penwidth=2
+    ];
+    // Placeholder IA (invisible)
+    ph_ia [label="" shape=point width=0.01 style=invis];
+    veille [
+        label="Veille sources\n\nSurveillance des sources\n(huginn)\nVérification des citations\nAlertes (variations)"
+        fillcolor="#FFAB91" penwidth=1.5
+    ];
+    { rank=same; veille; moteur; ph_ia; }
+
+    // Ligne 4 : BDD + sources
+    bdd [
+        label="Base de données\n(graphe)\n\nNœuds, relations, indices\nSources rattachées\nHistorique des données"
+        fillcolor="#80CBC4" penwidth=2
+    ];
+    sources [
+        label="Sources externes\n\nUSGS, Statista, BRGM,\nScholar Gateway, Consensus,\nWRI Aqueduct, ND-GAIN..."
+        fillcolor="#E0E0E0" shape=cylinder
+    ];
+    { rank=same; bdd; sources; }
+
+    // Relations utilisateurs
+    expert -> api [label="consulte, analyse\net simule", color="#2E7D32"];
+    client -> api [label="consulte\nles résultats", color="#C62828"];
+    admin -> moteur [label="administre\n(scripts)", color="#E65100", style=bold, penwidth=2];
+
+    // Écosystème 360° — deux points d'interaction
+    ecosysteme -> api [label="requête\nanalyses", color="#6A1B9A", penwidth=2];
+    ecosysteme -> expert [label="propose\ndes sources", color="#6A1B9A", style=dashed, penwidth=2];
+    expert -> sources [label="valide et\nalimente", color="#2E7D32", style=bold];
+
+    // API ↔ Moteur
+    api -> moteur [label="transmet\nles requêtes", color="#4527A0", dir=both];
+
+    // Moteur ↔ BDD
+    moteur -> bdd [label="lit et écrit\nles données", color="#00695C", dir=both];
+
+    // Veille
+    sources -> veille [label="surveille\nles MAJ", color="#BF360C"];
+    veille -> bdd [label="met à jour\nles sources", color="#E65100", style=dashed];
+    veille -> moteur [label="signale les\nchangements\net vérifie\nles citations", color="#E65100"];
+    sources -> bdd [label="alimente\nles données", color="#546E7A", style=dashed];
+
+    // Liens invisibles pour stabiliser
+    ph_bus -> ph_ia [style=invis];
+}

docs/FabNum v2/architecture-vue4.dot

@@ -0,0 +1,113 @@
+digraph architecture_vue4 {
+    rankdir=TB;
+    fontname="Arial";
+    fontsize=18;
+    label="FabNum — Vue 4 : Architecture complète\nBus d'impact, mémoire situationnelle, IA\n";
+    labelloc=t;
+    splines=true;
+    nodesep=0.7;
+    ranksep=0.9;
+    node [fontname="Arial", fontsize=10, style="filled,rounded", shape=box, penwidth=1.5];
+    edge [fontname="Arial", fontsize=9, penwidth=1.2];
+
+    // Ligne 1 : utilisateurs (4 colonnes fixes)
+    admin [
+        label="Administrateur\n\nGère le graphe structurel,\nles sources, les tiers\nde confiance"
+        fillcolor="#FFE082" shape=house
+    ];
+    expert [
+        label="Expert\n\nAnalyse les risques,\nqualifie les données,\nvalide les impacts,\nvalide les sources"
+        fillcolor="#A5D6A7" shape=house
+    ];
+    client [
+        label="Client\n(COMEX, Métiers, DSI)\n\nConsulte les analyses,\nles fiches, les alertes.\nPeut contextualiser\nses requêtes."
+        fillcolor="#EF9A9A" shape=house
+    ];
+    ecosysteme [
+        label="Écosystème\nveille 360°\n\nDétecte les événements,\npropose des sources,\nalimente le bus d'impact"
+        fillcolor="#CE93D8" shape=house
+    ];
+    { rank=same; admin; expert; client; ecosysteme; }
+
+    // Ligne 2 : API + Bus d'impact
+    api [
+        label="API\n\nPoint d'accès unique\nAuthentification, rôles,\nprofils de visibilité\n\nSert le graphe situationnel\n(structurel accessible aussi)"
+        fillcolor="#B39DDB" penwidth=2
+    ];
+    bus [
+        label="Bus d'impact\n\nMémoire situationnelle\nTraduction événements → impacts\nAccumule, met à jour, archive\nMise à jour en continu\n(rythme décisionnel)"
+        fillcolor="#FF8A65" penwidth=2.5
+        style="filled,rounded,bold"
+    ];
+    { rank=same; api; bus; }
+
+    // Ligne 3 : Moteur + IA + veille
+    moteur [
+        label="Moteur FabNum\n\nCalcul des indices\n(structurels et situationnels)\nRequêtage, chemins critiques\nGénération fiches (templates)\nArbitrage des sources\nProjection temporelle"
+        fillcolor="#90CAF9" penwidth=2
+    ];
+    ia_bus [
+        label="IA\n\nAnalyse les événements,\npropose les impacts\nchiffrés"
+        fillcolor="#FFCC80"
+    ];
+    veille [
+        label="Veille sources\n\nSurveillance des sources\n(huginn)\nVérification des citations\nAlertes (variations)"
+        fillcolor="#FFAB91" penwidth=1.5
+    ];
+    { rank=same; veille; moteur; ia_bus; }
+
+    // Ligne 4 : BDD scindée + sources
+    subgraph cluster_bdd {
+        label="Base de données (graphe)";
+        style=filled;
+        color="#E0F2F1";
+        fontsize=10;
+        fontcolor="#00695C";
+
+        bdd_situa [
+            label="Graphe situationnel\n\nImpacts actifs\nCapacités réelles\nIndices situationnels\nHistorique des situations"
+            fillcolor="#4DB6AC"
+        ];
+        bdd_struct [
+            label="Graphe structurel\n\nCapacités nominales\nActeurs, pays, parts de marché\nIndices structurels\nMise à jour trimestrielle"
+            fillcolor="#80CBC4"
+        ];
+    }
+    sources [
+        label="Sources externes\n\nUSGS, Statista, BRGM,\nScholar Gateway, Consensus,\nWRI Aqueduct, ND-GAIN..."
+        fillcolor="#E0E0E0" shape=cylinder
+    ];
+
+    // Relations utilisateurs
+    expert -> api [label="consulte\nanalyse", color="#2E7D32"];
+    expert -> sources [label="valide et\nalimente", color="#2E7D32", style=bold];
+    client -> api [label="consulte\nles résultats", color="#C62828"];
+    admin -> moteur [label="administre\n(scripts)", color="#E65100", style=bold, penwidth=2];
+
+    // Écosystème 360° — trois interactions
+    ecosysteme -> api [label="requête\nanalyses", color="#6A1B9A"];
+    ecosysteme -> expert [label="propose événements\net sources", color="#6A1B9A", style=dashed, penwidth=2];
+
+    // Expert → Bus (événements validés)
+    expert -> bus [label="valide\nles impacts", color="#E65100", style=bold];
+
+    // Bus ↔ IA
+    bus -> ia_bus [label="événement\nà analyser", color="#E65100", dir=both];
+
+    // Bus → Moteur + BDD (deux sorties)
+    bus -> moteur [label="impacts\nchiffrés", color="#BF360C", penwidth=2];
+    bus -> bdd_situa [label="MAJ\nsituationnel", color="#BF360C", style=dashed];
+    bus -> bdd_struct [label="MAJ structurel\n(fermeture mine,\nnouvel opérateur)", color="#BF360C", style=dashed];
+
+    // API ↔ Moteur
+    api -> moteur [label="transmet\nles requêtes", color="#4527A0", dir=both];
+
+    // Moteur ↔ BDD
+    moteur -> bdd_struct [label="lit/écrit\nstructurel", color="#00695C", dir=both];
+    moteur -> bdd_situa [label="lit/écrit\nsituationnel", color="#00695C", dir=both];
+
+    // Veille
+    sources -> veille [label="surveille\nles MAJ", color="#BF360C"];
+    veille -> bdd_struct [label="met à jour\nles sources", color="#E65100", style=dashed];
+    sources -> bdd_struct [label="alimente\nles données", color="#546E7A", style=dashed];
+}

docs/FabNum v2/macro-daf.dot

@@ -0,0 +1,152 @@
+digraph macro_daf {
+    rankdir=TB;
+    fontname="Arial";
+    node [fontname="Arial", fontsize=10, style=filled, shape=box];
+    edge [fontname="Arial", fontsize=9];
+    label="FabNum — Macro-DAF (Dossier d'Architecture Fonctionnel)\n\n";
+    labelloc=t;
+    fontsize=16;
+    compound=true;
+
+    // F1. Modéliser
+    subgraph cluster_F1 {
+        label="F1. MODÉLISER LA CHAÎNE DE VALEUR";
+        style=filled; color="#E3F2FD"; fontsize=12; fontcolor="#1565C0";
+
+        F1_1 [label="F1.1\nValider les niveaux\nde décomposition", fillcolor="#BBDEFB"];
+        F1_2 [label="F1.2\nDéfinir les intitulés\ngénériques", fillcolor="#BBDEFB"];
+        F1_3 [label="F1.3\nDéfinir les critères\nd'arrêt (profondeur)", fillcolor="#BBDEFB"];
+        F1_4 [label="F1.4\nGérer chaînes\nessentielles / connexes", fillcolor="#BBDEFB"];
+        F1_5 [label="F1.5\nGérer les matières\ncomposées (NMC...)", fillcolor="#BBDEFB"];
+
+        F1_1 -> F1_2 -> F1_3 -> F1_4 -> F1_5;
+        acteur_F1 [label="Acteur : Admin", shape=ellipse, fillcolor="#E3F2FD", fontsize=9];
+    }
+
+    // F2. Structurer et qualifier
+    subgraph cluster_F2 {
+        label="F2. STRUCTURER ET QUALIFIER LES DONNÉES";
+        style=filled; color="#E8F5E9"; fontsize=12; fontcolor="#2E7D32";
+
+        F2_1 [label="F2.1\nSpécifier données\n(essentielles / info)", fillcolor="#C8E6C9"];
+        F2_2 [label="F2.2\nDéfinir périmètre\nmesuré", fillcolor="#C8E6C9"];
+        F2_3 [label="F2.3\nIdentifier et catégoriser\nles sources", fillcolor="#C8E6C9"];
+        F2_4 [label="F2.4\nAttribuer tiers\nde confiance\n(par domaine)", fillcolor="#C8E6C9"];
+        F2_5 [label="F2.5\nQualifier données\n(filtres qualité)", fillcolor="#C8E6C9"];
+        F2_6 [label="F2.6\nArbitrer divergences\n(tier 1 par défaut,\nconvergence → alerte)", fillcolor="#C8E6C9"];
+        F2_7 [label="F2.7\nCalculer indice\nde fiabilité", fillcolor="#C8E6C9"];
+
+        F2_1 -> F2_2 -> F2_3 -> F2_4 -> F2_5 -> F2_6 -> F2_7;
+        acteur_F2 [label="Acteur : Admin", shape=ellipse, fillcolor="#E8F5E9", fontsize=9];
+    }
+
+    // F3. Surveiller et maintenir
+    subgraph cluster_F3 {
+        label="F3. SURVEILLER ET MAINTENIR (cycle structurel — trimestriel)";
+        style=filled; color="#FFF3E0"; fontsize=12; fontcolor="#E65100";
+
+        F3_1 [label="F3.1\nVeiller sur\nles sources\n(huginn)", fillcolor="#FFE0B2"];
+        F3_2 [label="F3.2\nDétecter variations\nanormales (alertes)", fillcolor="#FFE0B2"];
+        F3_3 [label="F3.3\nContrôler\ncitations\n(verify-citations)", fillcolor="#FFE0B2"];
+        F3_4 [label="F3.4\nHistoriser données\net indices", fillcolor="#FFE0B2"];
+        F3_5 [label="F3.5\nAuditer exhaustivité\ndes matières premières", fillcolor="#FFE0B2"];
+
+        F3_1 -> F3_2;
+        F3_3 -> F3_4;
+        acteur_F3 [label="Acteurs : Admin (gouv.)\nServices internes (auto.)", shape=ellipse, fillcolor="#FFF3E0", fontsize=9];
+    }
+
+    // F4. Calculer les indices
+    subgraph cluster_F4 {
+        label="F4. CALCULER LES INDICES DE CRITICITÉ";
+        style=filled; color="#FCE4EC"; fontsize=12; fontcolor="#C62828";
+
+        F4_1 [label="F4.1\nCalculer IHH, ICS\nIVC, ISG (+ futurs)\nstructurels et situationnels", fillcolor="#F8BBD0"];
+        F4_2 [label="F4.2\nPré-calculer à\nchaque MAJ graphe", fillcolor="#F8BBD0"];
+        F4_3 [label="F4.3\nMéta-indices\ndynamiques\n(sur sélection)", fillcolor="#F8BBD0"];
+        F4_4 [label="F4.4\nRétro-analyser\n(backtesting)", fillcolor="#F8BBD0"];
+        F4_5 [label="F4.5\nPropager les impacts\net projeter\ntemporellement", fillcolor="#F8BBD0"];
+
+        F4_1 -> F4_2;
+        F4_3 -> F4_4;
+        acteur_F4 [label="Acteur : Services internes", shape=ellipse, fillcolor="#FCE4EC", fontsize=9];
+    }
+
+    // F5. Produire les fiches
+    subgraph cluster_F5 {
+        label="F5. PRODUIRE LES FICHES";
+        style=filled; color="#F3E5F5"; fontsize=12; fontcolor="#6A1B9A";
+
+        F5_1 [label="F5.1\nGénérer depuis\ndonnées via templates", fillcolor="#E1BEE7"];
+        F5_2 [label="F5.2\nAdapter par niveau\n(matière première,\ncomposant, composé...)", fillcolor="#E1BEE7"];
+        F5_3 [label="F5.3\nAdapter par usage\n(expertise, synthèse,\nAPI/JSON)", fillcolor="#E1BEE7"];
+
+        F5_1 -> F5_2 -> F5_3;
+        acteur_F5 [label="Acteur : Services internes", shape=ellipse, fillcolor="#F3E5F5", fontsize=9];
+    }
+
+    // F6. Exposer et servir
+    subgraph cluster_F6 {
+        label="F6. EXPOSER ET SERVIR";
+        style=filled; color="#E0F2F1"; fontsize=12; fontcolor="#00695C";
+
+        F6_1 [label="F6.1\nRequêtage graphe\n(expert / simplifié)", fillcolor="#B2DFDB"];
+        F6_2 [label="F6.2\nConsultation\nfiches", fillcolor="#B2DFDB"];
+        F6_3 [label="F6.3\nAnalyse vulnérabilité\net scénarios", fillcolor="#B2DFDB"];
+        F6_4 [label="F6.4\nExport\n(PDF, JSON, DOT)", fillcolor="#B2DFDB"];
+        F6_5 [label="F6.5\nContextualisation\nclient", fillcolor="#B2DFDB"];
+        F6_6 [label="F6.6\nIntégration\nécosystème 360°", fillcolor="#B2DFDB"];
+        F6_7 [label="F6.7\nScénarios multi-impacts\n(combinatoire)", fillcolor="#B2DFDB"];
+
+        acteur_F6 [label="Acteurs : Expert, Client\nCOMEX, Métiers, DSI", shape=ellipse, fillcolor="#E0F2F1", fontsize=9];
+    }
+
+    // F7. Capter et traduire les événements
+    subgraph cluster_F7 {
+        label="F7. CAPTER ET TRADUIRE LES ÉVÉNEMENTS (bus d'impact)";
+        style=filled; color="#FBE9E7"; fontsize=12; fontcolor="#BF360C";
+
+        F7_1 [label="F7.1\nRecevoir événements\n(veille 360°,\nsignaux faibles)", fillcolor="#FFCCBC"];
+        F7_2 [label="F7.2\nTraduire en impacts\nchiffrés (IA)", fillcolor="#FFCCBC"];
+        F7_3 [label="F7.3\nValidation expert\navant injection", fillcolor="#FFCCBC"];
+        F7_4 [label="F7.4\nMaintenir la mémoire\nsituationnelle\n(accumule, archive)", fillcolor="#FFCCBC"];
+        F7_5 [label="F7.5\nMettre à jour\nle graphe situationnel", fillcolor="#FFCCBC"];
+
+        F7_1 -> F7_2 -> F7_3 -> F7_4 -> F7_5;
+        acteur_F7 [label="Acteurs : Veille 360° (input)\nIA (traduction)\nExpert (validation)", shape=ellipse, fillcolor="#FBE9E7", fontsize=9];
+    }
+
+    // F8. Sécuriser et contrôler (transversal)
+    subgraph cluster_F8 {
+        label="F8. SÉCURISER ET CONTRÔLER (transversal)";
+        style=filled; color="#ECEFF1"; fontsize=12; fontcolor="#37474F";
+
+        F8_1 [label="F8.1 Auth\n(user / API key)", fillcolor="#CFD8DC"];
+        F8_2 [label="F8.2 Rôles\n(admin/expert/service)", fillcolor="#CFD8DC"];
+        F8_3 [label="F8.3 Profils\nvisibilité", fillcolor="#CFD8DC"];
+        F8_4 [label="F8.4 Rate limiting\n+ Monitoring", fillcolor="#CFD8DC"];
+
+        F8_1 -> F8_2 -> F8_3;
+        acteur_F8 [label="Acteurs : Admin (config)\nSystème (exécution)", shape=ellipse, fillcolor="#ECEFF1", fontsize=9];
+    }
+
+    // Flux principal
+    F1_5 -> F2_1 [lhead=cluster_F2, ltail=cluster_F1, penwidth=2, color="#333333"];
+    F2_7 -> F3_1 [lhead=cluster_F3, ltail=cluster_F2, penwidth=2, color="#333333"];
+    F3_4 -> F4_1 [lhead=cluster_F4, ltail=cluster_F3, penwidth=2, color="#333333"];
+    F4_2 -> F5_1 [lhead=cluster_F5, ltail=cluster_F4, penwidth=2, color="#333333"];
+    F5_3 -> F6_1 [lhead=cluster_F6, ltail=cluster_F5, penwidth=2, color="#333333"];
+
+    // F3 en continu
+    F3_2 -> F3_1 [style=dashed, color="#E65100", label="boucle\ncontinue"];
+
+    // F7 alimente F4 (impacts → calcul)
+    F7_5 -> F4_5 [lhead=cluster_F4, ltail=cluster_F7, penwidth=2, color="#BF360C", label="impacts\nchiffrés"];
+
+    // F7 boucle situationnelle
+    F7_4 -> F7_1 [style=dashed, color="#BF360C", label="mise à jour\ncontinue"];
+
+    // F8 transversal
+    F8_3 -> F5_1 [style=dotted, color="#37474F", lhead=cluster_F5, label="filtre"];
+    F8_3 -> F6_1 [style=dotted, color="#37474F", lhead=cluster_F6, label="filtre"];
+}

docs/FabNum v2/macro-dat.dot

@@ -0,0 +1,182 @@
+digraph macro_dat {
+    rankdir=TB;
+    fontname="Arial";
+    node [fontname="Arial", fontsize=10, style="filled,rounded", shape=box, penwidth=1.5];
+    edge [fontname="Arial", fontsize=9, penwidth=1.2];
+    label="FabNum — Macro-DAT (Dossier d'Architecture Technique)\n\n";
+    labelloc=t;
+    fontsize=16;
+    compound=true;
+
+    // ==================== COUCHE STOCKAGE ====================
+    subgraph cluster_stockage {
+        label="COUCHE STOCKAGE";
+        style=filled; color="#E3F2FD"; fontsize=13; fontcolor="#1565C0";
+
+        bdd_struct [
+            label="Graphe structurel\n\nCapacités nominales\nActeurs, pays, parts de marché\nIndices structurels\nMise à jour trimestrielle"
+            fillcolor="#BBDEFB"
+        ];
+        bdd_situa [
+            label="Graphe situationnel\n\nImpacts actifs\nCapacités réelles\nIndices situationnels\nHistorique des situations"
+            fillcolor="#90CAF9"
+        ];
+        historisation [
+            label="Historisation\n\nSnapshots horodatés\nVersions données + indices\nAudit trail\nRétro-analyse"
+            fillcolor="#BBDEFB"
+        ];
+        sources_db [
+            label="Référentiel sources\n\nSources catégorisées\nTiers de confiance (par domaine)\nLiens source ↔ donnée\nIndice de fiabilité"
+            fillcolor="#BBDEFB"
+        ];
+    }
+
+    // ==================== COUCHE MOTEUR ====================
+    subgraph cluster_moteur {
+        label="COUCHE MOTEUR (Python)";
+        style=filled; color="#E8F5E9"; fontsize=13; fontcolor="#2E7D32";
+
+        subgraph cluster_calcul {
+            label="Calcul";
+            style=filled; color="#C8E6C9";
+            calcul_indices [label="Calcul indices\n\nIHH, ICS, IVC, ISG\n+ futurs (eau, énergie)\nStructurels ET situationnels\nPré-calcul à chaque MAJ", fillcolor="#A5D6A7"];
+            meta_indices [label="Méta-indices\n\nCalcul dynamique\nsur sous-graphe\nsélectionné", fillcolor="#A5D6A7"];
+            propagation [label="Propagation\nd'impact\n\nSimulation manuelle\nou via bus\nProjection temporelle\n(stocks)", fillcolor="#A5D6A7"];
+        }
+
+        subgraph cluster_qualite {
+            label="Qualité données";
+            style=filled; color="#C8E6C9";
+            arbitrage [label="Arbitrage sources\n\nTier 1 par défaut\nConvergence → alerte\nSeuils variation", fillcolor="#A5D6A7"];
+            qualification [label="Qualification\n\nFiltres qualité\nIndice fiabilité\nPérimètre mesuré", fillcolor="#A5D6A7"];
+        }
+
+        subgraph cluster_requetage {
+            label="Requêtage";
+            style=filled; color="#C8E6C9";
+            chemins [label="Traversée graphe\n\nChemins critiques\nFiltrage multi-critères\nSous-graphes", fillcolor="#A5D6A7"];
+            projection_client [label="Contextualisation\nclient\n\nMapping contexte client\nsur graphe FabNum\n(stateless)", fillcolor="#A5D6A7"];
+            scenarios [label="Scénarios\nmulti-impacts\n\nCombinatoire N événements\nComparaison scénarios\nContextualisé client", fillcolor="#A5D6A7"];
+        }
+
+        subgraph cluster_generation {
+            label="Génération";
+            style=filled; color="#C8E6C9";
+            templates [label="Templates fiches\n\nNiveau × usage\nExpertise / Synthèse\nAPI / JSON", fillcolor="#A5D6A7"];
+            import_export [label="Import / Export\n\nDOT (legacy)\nJSON\nPDF\nBackup / Restore", fillcolor="#A5D6A7"];
+        }
+    }
+
+    // ==================== BUS D'IMPACT ====================
+    subgraph cluster_bus {
+        label="BUS D'IMPACT";
+        style=filled; color="#FBE9E7"; fontsize=13; fontcolor="#BF360C";
+
+        memoire [
+            label="Mémoire situationnelle\n\nImpacts actifs\nHistorique événements\nAccumule, met à jour, archive"
+            fillcolor="#FFCCBC"
+        ];
+        traducteur [
+            label="Traducteur IA\n\nÉvénement → impacts chiffrés\nNœuds impactés, % réduction\nDurée estimée"
+            fillcolor="#FFAB91"
+        ];
+        validation [
+            label="Validation expert\n\nPropose → valide\nPas d'injection automatique"
+            fillcolor="#FFCCBC"
+        ];
+
+        traducteur -> validation -> memoire;
+    }
+
+    // ==================== SERVICES INTERNES ====================
+    subgraph cluster_services_internes {
+        label="SERVICES INTERNES (non exposés)";
+        style=filled; color="#FFF3E0"; fontsize=13; fontcolor="#E65100";
+
+        veille [label="Veille sources\n(huginn)\n\nDétection MAJ\nNouvelles sources\nDisparitions", fillcolor="#FFE0B2"];
+        verif_citations [label="Vérification\ncitations\n\nverify-citations", fillcolor="#FFE0B2"];
+        recalcul [label="Recalcul indices\n\nDéclenché par MAJ\nstructurel + situationnel", fillcolor="#FFE0B2"];
+        alertes [label="Alertes\n\nVariations anormales\nConvergence sources", fillcolor="#FFE0B2"];
+    }
+
+    // ==================== API REST ====================
+    subgraph cluster_api {
+        label="API REST (point d'accès unique)";
+        style=filled; color="#F3E5F5"; fontsize=13; fontcolor="#6A1B9A";
+
+        subgraph cluster_securite {
+            label="Sécurité";
+            style=filled; color="#E1BEE7";
+            auth [label="Auth + Rôles\n(user / API key)", fillcolor="#CE93D8"];
+            profils [label="Profils visibilité", fillcolor="#CE93D8"];
+            rate_limit [label="Rate limiting\nMonitoring", fillcolor="#CE93D8"];
+        }
+
+        subgraph cluster_endpoints {
+            label="Endpoints";
+            style=filled; color="#E1BEE7";
+            ep_graphe [label="/graphe/*\nstructurel + situationnel", fillcolor="#CE93D8"];
+            ep_fiches [label="/fiches/*\ntous formats", fillcolor="#CE93D8"];
+            ep_analyse [label="/analyse/*\nvulnérabilités, scénarios", fillcolor="#CE93D8"];
+            ep_indices [label="/indices/*\nstructurels + situationnels", fillcolor="#CE93D8"];
+            ep_export [label="/export/*\nPDF, JSON, DOT", fillcolor="#CE93D8"];
+            ep_admin [label="/admin/*\nCRUD, sources", fillcolor="#CE93D8"];
+        }
+    }
+
+    // ==================== CONSOMMATEURS ====================
+    frontend [label="Frontend expert\n\nAnalyse, simulation,\nqualification", fillcolor="#CFD8DC", shape=house];
+    client_app [label="Client\n\nCOMEX, Métiers, DSI\nContextualisé", fillcolor="#CFD8DC", shape=house];
+    ecosysteme [label="Écosystème 360°\n\nVeille stratégique\nIRON, alertes", fillcolor="#CFD8DC", shape=house];
+
+    // Admin
+    admin [label="Admin (scripts)\n\nCRUD graphe structurel\nGestion sources\nTiers, arbitrage", fillcolor="#FFCC80", shape=hexagon];
+
+    // Veille 360°
+    veille360 [label="Veille 360°\n\nÉvénements géopolitiques\nclimatiques, économiques\nSignaux faibles", fillcolor="#CE93D8", shape=house];
+
+    // ==================== LIENS ====================
+
+    // Stockage → Moteur
+    bdd_struct -> chemins [color="#1565C0"];
+    bdd_struct -> calcul_indices [color="#1565C0"];
+    bdd_situa -> propagation [color="#1565C0"];
+    bdd_situa -> scenarios [color="#1565C0"];
+    sources_db -> arbitrage [color="#1565C0"];
+
+    // Bus → Stockage + Moteur
+    memoire -> bdd_situa [label="MAJ\nsituationnel", color="#BF360C"];
+    memoire -> propagation [label="impacts\nchiffrés", color="#BF360C", penwidth=2];
+
+    // Veille 360° → Bus
+    veille360 -> traducteur [label="événements", color="#6A1B9A", penwidth=2];
+
+    // Moteur → Services internes
+    calcul_indices -> recalcul [color="#E65100"];
+    arbitrage -> alertes [color="#E65100"];
+
+    // Moteur → API
+    chemins -> ep_graphe [color="#6A1B9A"];
+    meta_indices -> ep_indices [color="#6A1B9A"];
+    templates -> ep_fiches [color="#6A1B9A"];
+    import_export -> ep_export [color="#6A1B9A"];
+    propagation -> ep_analyse [color="#6A1B9A"];
+    scenarios -> ep_analyse [color="#6A1B9A"];
+
+    // API → Consommateurs
+    ep_graphe -> frontend [color="#37474F"];
+    ep_analyse -> frontend [color="#37474F"];
+    ep_fiches -> client_app [color="#37474F"];
+    ep_analyse -> client_app [color="#37474F"];
+    ep_graphe -> ecosysteme [color="#37474F"];
+    ep_indices -> ecosysteme [color="#37474F"];
+
+    // Admin
+    admin -> bdd_struct [color="#E65100", penwidth=2, label="accès\ndirect"];
+
+    // Services internes → Stockage
+    veille -> sources_db [color="#E65100", style=dashed, label="MAJ sources"];
+    recalcul -> bdd_struct [color="#E65100", style=dashed];
+    recalcul -> bdd_situa [color="#E65100", style=dashed];
+    alertes -> admin [color="#E65100", style=dashed, label="notification"];
+}

docs/FabNum v2/modele-niveaux-cas-possibles.dot

@@ -0,0 +1,147 @@
+digraph modele_niveaux {
+    rankdir=LR;
+    fontname="Arial";
+    fontsize=16;
+    label="FabNum — Modèle de niveaux : tous les cas possibles\n(1 produit final, 1 composant, toutes les variantes amont)\n";
+    labelloc=t;
+    splines=true;
+    nodesep=0.4;
+    ranksep=1.0;
+    node [fontname="Arial", fontsize=10, style="filled,rounded", shape=box, penwidth=1.5];
+    edge [fontname="Arial", fontsize=9, penwidth=1.2];
+
+    // ==================== COLONNES (same rank) ====================
+
+    // Colonne 1 : Matière première
+    MPA [label="Silicium\n(MP)", fillcolor="#ffcccc", penwidth=2];
+    MPB [label="Cobalt\n(MP)", fillcolor="#ffcccc", penwidth=2];
+    MPC [label="Mica\n(MP)", fillcolor="#ffcccc", penwidth=2];
+    MPD1 [label="Nickel\n(MP)", fillcolor="#ffcccc", penwidth=2];
+    MPD2 [label="Cobalt\n(MP)", fillcolor="#ffcccc", penwidth=2];
+    MPD3 [label="Manganèse\n(MP)", fillcolor="#ffcccc", penwidth=2];
+    MPE [label="Néon\n(MP connexe)", fillcolor="#E0E0E0", penwidth=2];
+    { rank=same; MPA; MPB; MPC; MPD1; MPD2; MPD3; MPE; }
+
+    // Colonne 2 : Extraction
+    ExtrA [label="Extraction\nSilicium", fillcolor="#ffd699"];
+    ExtrB [label="Extraction\nCobalt", fillcolor="#ffd699"];
+    ExtrC [label="Extraction\nMica", fillcolor="#ffd699"];
+    ExtrD1 [label="Extraction\nNickel", fillcolor="#ffd699"];
+    ExtrD2 [label="Extraction\nCobalt", fillcolor="#ffd699"];
+    ExtrD3 [label="Extraction\nManganèse", fillcolor="#ffd699"];
+    SkipExtrE [label="—", shape=point, width=0.1, fillcolor="#FFFFFF", color="#FFFFFF"];
+    { rank=same; ExtrA; ExtrB; ExtrC; ExtrD1; ExtrD2; ExtrD3; SkipExtrE; }
+
+    // Colonne 3 : Transformation
+    TransfA [label="Transformation\nPolysilicium", fillcolor="#ffd699"];
+    TransfB [label="Transformation\nCobalt raffiné", fillcolor="#ffd699"];
+    SkipTransfC [label="—", shape=point, width=0.1, fillcolor="#FFFFFF", color="#FFFFFF"];
+    TransfD1 [label="Transformation\nNickel raffiné", fillcolor="#ffd699"];
+    TransfD2 [label="Transformation\nCobalt raffiné", fillcolor="#ffd699"];
+    TransfD3 [label="Transformation\nMn raffiné", fillcolor="#ffd699"];
+    TransfE [label="Transformation\nDistillation air", fillcolor="#CFD8DC"];
+    { rank=same; TransfA; TransfB; SkipTransfC; TransfD1; TransfD2; TransfD3; TransfE; }
+
+    // Colonne 3.5 : Composé (uniquement cas D)
+    SkipCompA [label="—", shape=point, width=0.1, fillcolor="#FFFFFF", color="#FFFFFF"];
+    SkipCompB [label="—", shape=point, width=0.1, fillcolor="#FFFFFF", color="#FFFFFF"];
+    SkipCompC [label="—", shape=point, width=0.1, fillcolor="#FFFFFF", color="#FFFFFF"];
+    Compose [label="Composé\nNMC\n\nDouble ICS :\nMP→Composé\nComposé→Composant", fillcolor="#F8BBD0", penwidth=2.5, style="filled,rounded,bold"];
+    SkipCompE [label="—", shape=point, width=0.1, fillcolor="#FFFFFF", color="#FFFFFF"];
+    { rank=same; SkipCompA; SkipCompB; SkipCompC; Compose; SkipCompE; }
+
+    // Colonne 4 : Semi-produit
+    SPA [label="Semi-produit\nWafer", fillcolor="#E1BEE7", style="filled,rounded,dashed"];
+    SkipSPB [label="—", shape=point, width=0.1, fillcolor="#FFFFFF", color="#FFFFFF"];
+    SkipSPC [label="—", shape=point, width=0.1, fillcolor="#FFFFFF", color="#FFFFFF"];
+    SkipSPD [label="—", shape=point, width=0.1, fillcolor="#FFFFFF", color="#FFFFFF"];
+    SkipSPE [label="—", shape=point, width=0.1, fillcolor="#FFFFFF", color="#FFFFFF"];
+    { rank=same; SPA; SkipSPB; SkipSPC; SkipSPD; SkipSPE; }
+
+    // Colonne 5 : Fabrication
+    FabA [label="Fabrication\nProcesseur", fillcolor="#ffd699"];
+    FabB [label="Fabrication\nBatterie", fillcolor="#ffd699"];
+    FabC [label="Fabrication\nCondensateur", fillcolor="#ffd699"];
+    FabD [label="Fabrication\nBatterie", fillcolor="#ffd699"];
+    FabE [label="Fabrication\n(consommé)", fillcolor="#CFD8DC"];
+    { rank=same; FabA; FabB; FabC; FabD; FabE; }
+
+    // Colonne 6 : Composant
+    Composant [label="Composant\n(Batterie, Processeur...)\n\nN1", fillcolor="#b3ffe0", penwidth=2.5];
+
+    // Colonne 7 : Assemblage
+    Assemblage [label="Assemblage\n\nN10", fillcolor="#ffd699"];
+
+    // Colonne 8 : Produit Final
+    PF [label="Produit Final\n(Smartphone)\n\nN0", fillcolor="#a0d6ff", penwidth=2.5];
+
+    { rank=same; Composant; }
+    { rank=same; Assemblage; }
+    { rank=same; PF; }
+
+    // ==================== LIENS CAS A (Silicium — chaîne complète) ====================
+    MPA -> ExtrA [color="#6A1B9A"];
+    ExtrA -> TransfA [color="#6A1B9A"];
+    TransfA -> SkipCompA [color="#6A1B9A", arrowhead=none];
+    SkipCompA -> SPA [color="#6A1B9A"];
+    SPA -> FabA [color="#6A1B9A"];
+    FabA -> Composant [color="#6A1B9A"];
+
+    // ==================== LIENS CAS B (Cobalt — sans semi-produit) ====================
+    MPB -> ExtrB [color="#2E7D32"];
+    ExtrB -> TransfB [color="#2E7D32"];
+    TransfB -> SkipCompB [color="#2E7D32", arrowhead=none];
+    SkipCompB -> SkipSPB [color="#2E7D32", arrowhead=none];
+    SkipSPB -> FabB [color="#2E7D32"];
+    FabB -> Composant [color="#2E7D32"];
+
+    // ==================== LIENS CAS C (Mica — sans transformation) ====================
+    MPC -> ExtrC [color="#E65100"];
+    ExtrC -> SkipTransfC [color="#E65100", arrowhead=none];
+    SkipTransfC -> SkipCompC [color="#E65100", arrowhead=none];
+    SkipCompC -> SkipSPC [color="#E65100", arrowhead=none];
+    SkipSPC -> FabC [color="#E65100"];
+    FabC -> Composant [color="#E65100"];
+
+    // ==================== LIENS CAS D (NMC — combinaison) ====================
+    MPD1 -> ExtrD1 [color="#C62828"];
+    MPD2 -> ExtrD2 [color="#C62828"];
+    MPD3 -> ExtrD3 [color="#C62828"];
+    ExtrD1 -> TransfD1 [color="#C62828"];
+    ExtrD2 -> TransfD2 [color="#C62828"];
+    ExtrD3 -> TransfD3 [color="#C62828"];
+    TransfD1 -> Compose [color="#C62828"];
+    TransfD2 -> Compose [color="#C62828"];
+    TransfD3 -> Compose [color="#C62828"];
+    Compose -> SkipSPD [color="#C62828", arrowhead=none];
+    SkipSPD -> FabD [color="#C62828"];
+    FabD -> Composant [color="#C62828"];
+
+    // ==================== LIENS CAS E (Néon — connexe) ====================
+    MPE -> SkipExtrE [color="#37474F", style=dashed, arrowhead=none];
+    SkipExtrE -> TransfE [color="#37474F", style=dashed];
+    TransfE -> SkipCompE [color="#37474F", style=dashed, arrowhead=none];
+    SkipCompE -> SkipSPE [color="#37474F", style=dashed, arrowhead=none];
+    SkipSPE -> FabE [color="#37474F", style=dashed];
+    FabE -> Composant [color="#37474F", style=dashed];
+
+    // ==================== LIENS COMMUNS ====================
+    Composant -> Assemblage [color="#333333", penwidth=2];
+    Assemblage -> PF [color="#333333", penwidth=2];
+
+    // ==================== LÉGENDE ====================
+    subgraph cluster_legende {
+        label="Légende";
+        style=filled; color="#FAFAFA"; fontsize=11;
+        labeljust=l;
+
+        L1 [label="Cas A — Chaîne complète (Silicium)", fillcolor="#E1BEE7", fontsize=9, shape=box];
+        L2 [label="Cas B — Sans semi-produit (Cobalt)", fillcolor="#C8E6C9", fontsize=9, shape=box];
+        L3 [label="Cas C — Sans transformation (Mica)", fillcolor="#FFE0B2", fontsize=9, shape=box];
+        L4 [label="Cas D — Combinaison MP → Composé (NMC)", fillcolor="#F8BBD0", fontsize=9, shape=box];
+        L5 [label="Cas E — Connexe, sans extraction (Néon)", fillcolor="#CFD8DC", fontsize=9, shape=box];
+        L6 [label="Étapes optionnelles : trait pointillé ou —", shape=note, fillcolor="#FFFDE7", fontsize=9];
+
+        L1 -> L2 -> L3 -> L4 -> L5 -> L6 [style=invis];
+    }
+}

docs/FabNum v2/planification-temporelle.dot

@@ -0,0 +1,92 @@
+digraph planification_temporelle {
+    rankdir=LR;
+    fontname="Arial";
+    node [fontname="Arial", fontsize=11, style=filled, shape=box];
+    edge [fontname="Arial", fontsize=9];
+    label="FabNum — Planification temporelle\n\n";
+    labelloc=t;
+    fontsize=16;
+
+    // Phases
+    subgraph cluster_phase1 {
+        label="Phase 1 — Fondations";
+        style=filled;
+        color="#E3F2FD";
+        fontsize=13;
+        fontcolor="#1565C0";
+
+        P7 [label="P7\nValidation\nniveaux\nRevue littérature\nSCOR, ISO 28000\nOpen Supply Hub", fillcolor="#BBDEFB"];
+        P6spike [label="P6 spike\nTest bases\ndonnées\nNeo4j Community\nPostgreSQL+AGE\nArangoDB\n(Docker/serveur)", fillcolor="#BBDEFB"];
+    }
+
+    subgraph cluster_phase2 {
+        label="Phase 2 — Modèle & Stockage";
+        style=filled;
+        color="#E8F5E9";
+        fontsize=13;
+        fontcolor="#2E7D32";
+
+        P3 [label="P3\nModèle de\ndonnées\nEssentielles / Info\nTiers confiance\nArbitrage\nHistorisation\nIndice fiabilité", fillcolor="#C8E6C9"];
+        P6impl [label="P6 impl\nStockage\nBase retenue\nInstallation native\nBackup", fillcolor="#C8E6C9"];
+    }
+
+    subgraph cluster_phase3 {
+        label="Phase 3 — Données & Sources";
+        style=filled;
+        color="#FFF3E0";
+        fontsize=13;
+        fontcolor="#E65100";
+
+        P2 [label="P2\nGestion\nsources\nIdentification\nCatégorisation\nVeille (huginn)\nVérification citations", fillcolor="#FFE0B2"];
+        P4 [label="P4\nAmorçage\n3 minerais\n1 composant\n1 produit final\nQualification\n+ audit exhaustivité", fillcolor="#FFE0B2"];
+    }
+
+    subgraph cluster_phase4 {
+        label="Phase 4 — Fiches & API";
+        style=filled;
+        color="#F3E5F5";
+        fontsize=13;
+        fontcolor="#6A1B9A";
+
+        P5 [label="P5\nTemplates\nfiches\nNiveau × usage\nExpertise\nSynthèse\nAPI/JSON", fillcolor="#E1BEE7"];
+        P1 [label="P1\nAPI REST\n+ rôles\nAdmin / Expert / Service\nAuth + tokens\nAPI-first", fillcolor="#E1BEE7"];
+        P8 [label="P8\nServices\nsécu profils\nPersonnalisation client\nProfils visibilité\nRate limiting\nRGPD / stateless", fillcolor="#E1BEE7"];
+    }
+
+    subgraph cluster_horizon {
+        label="Horizon";
+        style=filled;
+        color="#EFEBE9";
+        fontsize=13;
+        fontcolor="#4E342E";
+
+        P10 [label="P10\nÉnergie / Eau\nAttributs opération\nSourçage parcellaire\nCroisements risques", fillcolor="#D7CCC8"];
+        P11 [label="P11\nGéo fine\nRégion / site\nWRI Aqueduct\nAlertes climatiques", fillcolor="#D7CCC8"];
+        P9 [label="P9\nMulti-\nsectoriel\nGraphes par secteur\nConnexes inter-secteurs\nMinerais partagés", fillcolor="#D7CCC8"];
+    }
+
+    // MVP
+    MVP [label="MVP\nJalon interne\nMoteur requêtable\nDonnées sourcées\nIndice fiabilité\nRétro-analyse", shape=doubleoctagon, fillcolor="#FFF9C4", style="filled,bold"];
+
+    // Dépendances principales
+    P7 -> P3 [label="niveaux\nvalidés", color="#2E7D32", penwidth=2];
+    P6spike -> P6impl [label="techno\nretenue", color="#2E7D32", penwidth=2];
+    P3 -> P6impl [label="schéma", color="#2E7D32"];
+    P6impl -> P4 [label="base\nprête", color="#E65100", penwidth=2];
+    P2 -> P4 [label="sources\ncatégorisées", color="#E65100"];
+    P4 -> P5 [label="données\nqualifiées", color="#6A1B9A"];
+    P5 -> P1 [label="fiches\ngénérables", color="#6A1B9A"];
+    P1 -> P8 [label="API\nfonctionnelle", color="#6A1B9A"];
+
+    // Parallélisations
+    P7 -> P6spike [style=dashed, color="#1565C0", label="parallèle", constraint=false];
+    P3 -> P2 [style=dashed, color="#E65100", label="P2 démarre\nen parallèle", constraint=false];
+
+    // MVP
+    P4 -> MVP [style=bold, color="#F9A825", penwidth=2, label="MVP atteint"];
+
+    // Horizon (dépendances faibles)
+    P8 -> P10 [style=dotted, color="#795548"];
+    P8 -> P11 [style=dotted, color="#795548"];
+    P8 -> P9 [style=dotted, color="#795548"];
+}

docs/ORGANISATION.md

@@ -0,0 +1,92 @@
+# FabNum v2 — Organisation du travail
+
+## Principes
+
+Le contexte du projet va croître significativement (12 points d'évolution × specs + plans + code + tests).
+Pour maintenir la cohérence dans le temps, le travail repose sur des **agents indépendants** orchestrés
+depuis la conversation principale.
+
+## Rôles
+
+### Stéphan (humain)
+- Vision produit, arbitrage, validation des spécifications
+- Expertise métier (chaînes d'approvisionnement, minerais critiques, risques géopolitiques)
+- Décision finale sur tous les choix
+
+### Conversation principale (Claude Code)
+- **Orchestrateur** — maintient la vision d'ensemble, briefe les agents, vérifie la cohérence entre les points
+- Présente les résultats à Stéphan pour validation
+- Ne fait PAS l'implémentation directement sauf cas trivial
+
+### Agents indépendants
+- **Exécutants spécialisés** — recherche, implémentation, revue, tests
+- Reçoivent un brief ciblé avec uniquement le contexte nécessaire
+- Lisent les fichiers de specs au moment de l'exécution (pas de contexte périmé)
+- Leurs résultats sont toujours validés par Stéphan avant intégration
+
+## Source de vérité
+
+Les **documents écrits** (docs/) sont la source de vérité, pas les conversations.
+
+| Document | Rôle |
+| --- | --- |
+| `docs/EVOLUTIONS.md` | Vision, quoi/pourquoi de chaque point |
+| `docs/EVOLUTIONS-PLANIFICATION.md` | Macro-planification, phases, MVP |
+| `docs/specs/point-XX-*.md` | Spécifications formelles par point |
+| `docs/plans/point-XX-*.md` | Plans d'implémentation par point |
+| `docs/architecture-globale.dot` | Architecture des modules |
+| `CLAUDE.md` | Conventions de code et workflow |
+
+## Cycle de travail par point
+
+Chaque point d'évolution suit le cycle :
+
+```
+1. Brainstorming ciblé        → Stéphan + orchestrateur
+   (approfondir le quoi, cas limites, choix à trancher)
+
+2. Spécification formelle     → Agent rédacteur + validation Stéphan
+   (spec précise dans docs/specs/)
+
+3. Plan d'implémentation      → Agent planificateur + validation Stéphan
+   (étapes techniques dans docs/plans/)
+
+4. Implémentation             → Agent(s) développeur(s)
+   (code, en worktree isolé si pertinent)
+
+5. Revue indépendante         → Agent revieweur (n'a PAS participé à l'implémentation)
+   (qualité, cohérence avec la spec, sécurité)
+
+6. Validation                 → Stéphan
+   (résultat final, merge si OK)
+```
+
+## Règles de briefing des agents
+
+Un agent indépendant doit recevoir :
+
+1. **L'objectif** — ce qu'on attend de lui (recherche, code, revue...)
+2. **Les fichiers à lire** — les specs pertinentes, pas tout le projet
+3. **Les contraintes** — budget zéro, open source, conventions de code
+4. **Le périmètre** — ce qu'il doit faire ET ce qu'il ne doit pas toucher
+5. **Le format de sortie** — rapport, code, plan, diff...
+
+Un agent ne doit **jamais** :
+- Modifier des fichiers hors de son périmètre
+- Prendre des décisions architecturales sans que Stéphan ait validé
+- Commiter directement (sauf instruction explicite)
+
+## Parallélisation
+
+Les agents peuvent travailler en parallèle sur des points indépendants.
+Exemple pour la phase 1 :
+- Agent A : revue de littérature pour le point 7 (niveaux)
+- Agent B : spike technique sur les bases de données (point 6)
+
+Les résultats sont consolidés par l'orchestrateur avant de passer à la phase suivante.
+
+## Cohérence
+
+- Après chaque implémentation significative, un **agent de cohérence** relit les specs des points adjacents pour vérifier qu'aucune décision ne les invalide.
+- Les specs sont mises à jour si des découvertes en implémentation imposent des ajustements (avec validation Stéphan).
+- Le fichier `EVOLUTIONS.md` reste le document de référence global et est mis à jour en conséquence.

docs/specs/point-07-niveaux-operations.md

@@ -0,0 +1,308 @@
+# Point 7 — Validation du modèle de niveaux : opérations
+
+**Date** : 2026-04-02
+**Statut** : En cours — partie opérations (Extraction, Transformation)
+
+---
+
+## Contexte
+
+Le modèle FabNum actuel utilise un niveau unique N10 "Opération" dont le type est porté par le label
+du nœud (Extraction, Traitement, Fabrication, Assemblage, Reserves). La question est de valider
+si cette décomposition est pertinente, suffisante, et correctement nommée.
+
+## Question 1 : Extraction et Transformation sont-elles deux phases distinctes ?
+
+### Hypothèse testée
+
+Le nœud "Extraction" et le nœud "Traitement" (dans le schema actuel) représentent-ils des réalités
+géographiques et industrielles différentes, justifiant deux nœuds séparés dans le graphe ?
+
+### Méthode
+
+Analyse systématique du fichier `schema.txt` (graphe DOT actuel) pour tous les minerais possédant
+à la fois un nœud Extraction et un nœud Traitement. Pour chaque minerai, comparaison des :
+- Pays d'opération (N11)
+- Acteurs (N12)
+- IHH pays
+
+### Résultats (38 minerais analysés)
+
+**Géographie :**
+- 95% des minerais (36/38) ont des pays **partiellement différents** entre Extraction et Traitement
+- Seuls le Platine et le Palladium ont exactement les mêmes pays aux deux étapes
+- Le Traitement implique systématiquement des pays plus industrialisés (Japon, Allemagne, Corée du Sud, Belgique, Estonie) absents de l'Extraction
+
+**Acteurs :**
+- 0% des minerais ont exactement les mêmes acteurs aux deux étapes
+- 18% ont des acteurs complètement différents (Hafnium, Europium, Erbium, Or, Titane, Béryllium, Tantale)
+- 82% ont des acteurs partiellement communs
+
+**Écarts d'IHH remarquables (> 20 points) :**
+
+| Minerai | IHH Extraction | IHH Traitement | Écart | Observation |
+| --- | --- | --- | --- | --- |
+| Germanium | 89 | 31 | 58 | Quasi-monopole extraction → diversification transformation |
+| Dysprosium | 96 | 38 | 58 | Idem |
+| Gallium | 94 | 42 | 52 | Idem |
+| Tungstène | 69 | 25 | 44 | Idem |
+| Or | 2 | 33 | 31 | Cas inverse : extraction dispersée, transformation concentrée |
+| Tantale | 2 | 31 | 29 | Idem |
+| Cobalt | 49 | 27 | 22 | RDC extraction → Chine transformation |
+| Quartz | 64 | 43 | 21 | Spruce Pine → diversification |
+
+### Conclusion
+
+**Extraction et Transformation sont deux phases fondamentalement distinctes.** Les fusionner masquerait
+des vulnérabilités critiques. Les profils de concentration géographique (IHH) sont souvent très
+différents entre les deux étapes. Deux nœuds séparés sont justifiés.
+
+---
+
+## Question 2 : Faut-il séparer Extraction et Traitement primaire (concentration) ?
+
+### Hypothèse testée
+
+L'extraction minière brute et le traitement primaire (concentration, broyage, beneficiation) sont-ils
+colocalisés et réalisés par les mêmes acteurs, ou constituent-ils deux phases distinctes ?
+
+### Méthode
+
+Revue documentaire (USGS, BRGM, IEA, rapports d'entreprises) pour 9 minerais représentatifs :
+lithium (spodumène et saumure), cobalt, terres rares, tantale, germanium, étain, quartz ultra-pur,
+graphite, cuivre.
+
+### Résultats
+
+| Minerai | Concentration sur site | Mêmes acteurs | Séparation géographique notable |
+| --- | --- | --- | --- |
+| Lithium (spodumène) | Oui | Souvent oui | Non pour la concentration |
+| Lithium (saumure) | Oui | Oui (intégré) | Non |
+| Cobalt | Oui (concentré/hydroxyde) | De plus en plus | Non pour la concentration |
+| Terres rares | Oui (concentré REO) | Souvent oui sur site | Non pour la concentration |
+| Tantale | Oui (gravimétrique) | Variable | Non |
+| Germanium | N/A (sous-produit du zinc) | N/A | N/A |
+| Étain | Oui (gravimétrique) | Variable | Non |
+| Quartz ultra-pur | Oui (purification sur site) | Oui | Non |
+| Graphite | Oui (flottation) | Oui sur site | Non pour la concentration |
+| Cuivre | Oui (flottation) | Oui | Non |
+
+**Constante identifiée** : la concentration/beneficiation se fait quasi-systématiquement sur le site
+minier ou à proximité immédiate. Les raisons sont économiques : le minerai brut est volumineux et
+à faible teneur (ex : cuivre 0.5-1.5% Cu), transporter 99% de gangue serait prohibitif.
+
+### Conclusion
+
+**Séparer Extraction et Traitement primaire n'apporterait pas de valeur dans le modèle.** Les pays,
+acteurs et IHH seraient identiques dans la quasi-totalité des cas. Un seul nœud "Extraction"
+englobant le traitement primaire est une simplification justifiée.
+
+---
+
+## Question 3 : Quelle terminologie adopter ?
+
+### Analyse
+
+Le terme "Traitement" dans le schema actuel désigne en réalité le raffinage, la purification, la
+conversion chimique — ce qui correspond à la "refinery production" de l'USGS. Le terme est inapproprié
+car il prête à confusion avec le traitement primaire (concentration) qui fait partie de l'extraction.
+
+### Comparaison avec les standards
+
+| Standard | Terme pour l'étape post-extraction |
+| --- | --- |
+| EU Critical Raw Materials Act (2024/1252) | **Transformation** (Processing) |
+| USGS Mineral Commodity Summaries | Refinery production |
+| BRGM Fiches de criticité | Raffinage |
+| RMI (Responsible Minerals Initiative) | Smelter/Refiner |
+| Modèle de Graedel (Yale) | Smelting/refining |
+
+Le CRMA utilise **"Transformation"** comme terme générique englobant toutes les étapes post-extraction
+et pré-utilisation. Ce terme est le plus adapté car il couvre :
+- Le raffinage métallurgique (cobalt, cuivre, étain)
+- La purification (hélium, silicium de qualité électronique)
+- La conversion chimique (carbonate/hydroxyde de lithium)
+- La séparation fine (terres rares individuelles)
+- La fonderie (smelting)
+- Le craquage (dérivés pétroliers)
+
+Le terme "Raffinage" est plus courant dans la littérature technique mais **exclut** les matériaux
+non métalliques (gaz, polymères, silicium) et les procédés qui ne sont pas du raffinage au sens
+strict (séparation des terres rares, conversion du lithium).
+
+### Décision
+
+- **"Traitement" est renommé en "Transformation"** — aligné sur le CRMA, couvre tous les procédés.
+- **"Extraction"** reste inchangé — englobe l'extraction minière et le traitement primaire (concentration).
+
+---
+
+## Définitions retenues
+
+### Extraction
+
+Ensemble des opérations d'obtention du minerai brut depuis sa source naturelle et de sa préparation
+primaire. Comprend :
+
+- L'exploitation minière (mine à ciel ouvert, souterraine, forage)
+- Le broyage, concassage
+- La concentration/beneficiation (séparation gravimétrique, flottation, séparation magnétique)
+- La production de concentrés prêts à être expédiés vers la transformation
+
+**Périmètre géographique** : sur le site minier ou à proximité immédiate.
+**Donnée statistique de référence** : "mine production" (USGS), "production minière" (BRGM).
+**Justification de la colocalisation** : le minerai brut est volumineux et à faible teneur ;
+transporter la gangue serait économiquement prohibitif.
+
+### Transformation
+
+Ensemble des opérations de conversion du concentré ou du minerai brut en matériau utilisable par
+l'industrie. Comprend :
+
+- Le raffinage métallurgique (pyrométallurgie, hydrométallurgie)
+- La purification (gaz, silicium de qualité électronique)
+- La conversion chimique (carbonate de lithium, hydroxyde)
+- La séparation fine (terres rares individuelles)
+- La fonderie (smelting)
+- Le craquage et la transformation des dérivés pétroliers
+
+**Périmètre géographique** : souvent dans un pays différent de l'extraction.
+**Donnée statistique de référence** : "refinery production" (USGS), "raffinage" (BRGM).
+**Justification de la distinction avec l'Extraction** : géographies, acteurs et IHH diffèrent
+dans 95% des cas analysés (38 minerais).
+
+---
+
+## Sources et méthodes
+
+- Analyse empirique du graphe FabNum (`schema.txt`) : 38 minerais, comparaison systématique
+  pays/acteurs/IHH entre Extraction et Traitement
+- Revue documentaire : USGS Mineral Commodity Summaries, BRGM fiches de criticité, IEA Critical
+  Minerals, rapports d'entreprises minières
+- Comparaison avec les standards : SCOR Model, ISO 28000, RMI, EU CRMA 2024/1252, Open Supply Hub,
+  modèles académiques (Graedel/Yale, Schrijvers 2020, Material Flow Analysis)
+
+---
+
+---
+
+## Question 4 : Existe-t-il un niveau Semi-produit entre Transformation et Fabrication ?
+
+### Méthode
+
+Analyse documentaire de 6 chaînes concrètes : silicium→processeur, cobalt→batterie,
+cuivre→PCB, terres rares→aimant, étain→soudure, tantale→condensateur.
+
+### Résultats
+
+| Chaîne | Semi-produit | Acteurs distincts ? | Géographie distincte ? | Criticité |
+| --- | --- | --- | --- | --- |
+| Silicium → Processeur | **Wafer** (Shin-Etsu, SUMCO) | **Oui** | **Oui** — Japon >55% | Très élevée |
+| Cobalt → Batterie | **Cathode pCAM/CAM** | Partiellement | Partiellement — Chine ~75% | Élevée |
+| Cuivre → PCB | Feuille de cuivre | Oui | Partiellement | Moyenne |
+| Terres rares → Moteur | **Aimant NdFeB** | Partiellement | Non — Chine ~92% | Très élevée |
+| Étain → Assemblage | Alliage de soudure | Oui | Oui — diversifié | Faible |
+| Tantale → Condensateur | Poudre capaciteur | Non (intégré) | Non | Faible |
+
+### Conclusion
+
+Le Semi-produit est une **étape optionnelle** — présente et critique pour certaines chaînes
+(silicium, terres rares, cobalt), absente ou intégrée pour d'autres (tantale, étain).
+
+---
+
+## Question 5 : Quelles sont toutes les chaînes possibles ?
+
+### Méthode
+
+Analyse systématique des cas limites : matières sans transformation (mica), sans extraction
+(gaz atmosphériques, eau), combinaisons de matières premières (composés chimiques).
+
+### Chaînes essentielles identifiées (matière constitutive du produit final)
+
+| Cas | Chaîne | Exemple |
+| --- | --- | --- |
+| A | MP → Extraction → Transformation → Semi-produit → Fabrication → Assemblage → PF | Silicium → wafer → processeur |
+| B | MP → Extraction → Transformation → Fabrication → Assemblage → PF | Cobalt → batterie |
+| C | MP → Extraction → Fabrication → Assemblage → PF | Mica (rare, pas de transformation chimique) |
+| D | Plusieurs MP → Extraction → Transformation → **Composé** → Fabrication → Assemblage → PF | Ni+Co+Mn → NMC → batterie |
+
+### Chaînes connexes identifiées (nécessaire à la fabrication, pas dans le produit)
+
+| Cas | Chaîne | Exemple |
+| --- | --- | --- |
+| E | MP → Transformation → Fabrication (consommé) | Néon (distillation air, pas d'extraction) |
+
+### Étapes optionnelles confirmées
+
+Dans la chaîne maximale MP → Extraction → Transformation → Composé → Semi-produit → Fabrication → Assemblage → PF :
+
+- **Extraction** : optionnel (absent pour les connexes — gaz, eau)
+- **Transformation** : optionnel (absent pour le mica — cas rare)
+- **Composé** : optionnel (uniquement quand plusieurs MP convergent)
+- **Semi-produit** : optionnel (absent pour la majorité des chaînes)
+- **Fabrication**, **Assemblage**, **MP**, **PF** : toujours présents pour les essentielles
+
+---
+
+## Question 6 : Nouveaux items identifiés
+
+### Renommage Minerai → Matière première
+
+**Décidé.** Le terme "Minerai" (N2) est renommé **"Matière première"** pour couvrir :
+- Minerais métalliques (cobalt, lithium, tantale)
+- Minéraux non métalliques (quartz, mica, graphite)
+- Gaz (hélium, néon, argon)
+- Dérivés pétroliers (polymères, résines)
+
+Aligné sur le CRMA qui utilise "raw materials" (matières premières).
+
+### Matière composée (nouveau type d'item)
+
+Un **Composé** est un item (pas une opération) résultant de la combinaison de plusieurs matières
+premières transformées. Exemples : NMC (Ni+Mn+Co), alliage NdFeB (Nd+Fe+B), verre
+aluminosilicate.
+
+Le Composé se positionne comme un **item à un niveau intermédiaire** entre Matière première et
+Composant, consécutif à la Matière première.
+
+**Indices sur le Composé :**
+- **ICS** : entre MP transformée → Composé (ex : cobalt indispensable au NMC) ET entre Composé → Composant (ex : NMC substituable par LFP dans la batterie). Double substituabilité.
+- **IVC** : sur le Composé (vulnérabilité concurrentielle du composé)
+
+**Note** : le condensateur, la résistance, etc. ne sont pas des Composants au sens FabNum — ce sont
+des sous-composants qui relèveraient de chaînes connexes si on devait les détailler.
+
+---
+
+## Question 7 : Recyclage
+
+### Réflexion en cours
+
+Le recyclage produit du matériau fonctionnellement identique à celui issu de la Transformation
+(l'or recyclé = l'or raffiné). Il ne s'insère pas comme une étape linéaire dans la chaîne mais
+comme une **source alternative de matériau transformé**.
+
+Piste retenue : le recyclage serait modélisé comme une **Transformation distincte** (pas la même
+que la Transformation directe) — on aurait donc de la **Transformation directe** et de la
+**Transformation de recyclage**, deux opérations séparées avec chacune :
+- Ses propres acteurs
+- Ses propres pays d'opération
+- Son propre IHH
+- Son ISG via le pays géographique
+
+**À discuter** : comment articuler Transformation directe et Transformation de recyclage dans le
+graphe. La sortie est la même (matériau prêt pour la suite), mais les entrées et les acteurs
+diffèrent.
+
+**Statut** : discussion en cours, à reprendre.
+
+---
+
+## Points restants à traiter (point 7)
+
+- Finaliser la modélisation du recyclage (Transformation directe vs Transformation de recyclage)
+- Combinaison de minerais pour composés chimiques — impact sur le calcul des ICS
+- Intitulés génériques finaux pour tous les niveaux
+- Mise à jour du schéma des cas possibles (avec Composé et correction condensateur)
+- Nombre de niveaux fixe ou configurable