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

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.