Search for a command to run...
Série "Couche 1 - Les Données"
No comments yet. Be the first to comment.
La couche qui porte tout le reste. L'IA générative maîtrise le langage. Elle ignore la physique. Cette série explore l'architecture de données qui comble cet écart : Knowledge Graphs, ingénierie ontologique et validation physique appliqués aux systèmes industriels critiques. Chaque article part d'une conviction : en industrie critique, la qualité d'un système IA ne dépend pas de la puissance du modèle, mais de la rigueur avec laquelle on a structuré les données qui le contraignent. Les méthodologies documentées ici (Middle-Out, Engagement Ontologique Minimal, NeOn) sont issues de retours d'expérience de grands groupes industriels — Airbus, EDF, TotalEnergies, Thales — et de leur application à la surveillance de réacteurs nucléaires du parc français. Audience : architectes data, ingénieurs IA, décideurs techniques confrontés à la question "comment rendre l'IA fiable dans mon domaine ?".
Et comment réparer le moteur
Le 16 juin 2026, Arthur Mensch, le patron emblématique de Mistral AI, a publié sur LinkedIn un message d’une rare solennité. Le discours officiel y célèbre, comme toujours, l’indépendance technologiqu
En janvier 2026, la directrice financière d'OpenAI a confirmé un chiffre que personne n'a relevé. Le triplement des revenus de l'entreprise — de 6,7 à 20 milliards de dollars — suit exactement le trip
En moins de trois mois, début 2026, Nvidia a injecté plus de 42 milliards de dollars dans l'écosystème IA. 30 milliards dans OpenAI. 10 milliards dans Anthropic. 2 milliards dans Nebius. Le reste disp
Un ingénieur. Soixante minutes. Un produit SaaS en production, utilisé par 450 marques.
Un grand modèle de langage ne sait rien de votre métier. Ce qui le rend utile en industrie critique, ce n'est pas sa puissance — c'est l'architecture de données qui le contraint. J'ai construit un Knowledge Graph pour la surveillance de réacteurs nucléaires. Voici ce que cette expérience m'a appris sur l'endroit où se cache réellement l'intelligence d'un système IA.
Demandez à un LLM généraliste quel capteur surveiller quand la température primaire d'un réacteur nucléaire semble instable. Il vous répondra avec assurance. Il inventera un code capteur plausible. Il citera peut-être une norme ISO qui n'existe pas. Et il aura tort — de manière indétectable par un non-expert.
Ce n'est pas un défaut du modèle. C'est une conséquence structurelle de son architecture. Un LLM prédit le token suivant le plus probable. Il ne sait rien du domaine. Il n'a aucune représentation interne de ce qu'est un capteur, de ce que mesure ce capteur, de la loi physique qui relie cette mesure à une autre. Sans cette structure, il ne lui reste que la vraisemblance statistique — et en industrie critique, la vraisemblance tue.
Le réflexe courant est de demander un modèle plus puissant, plus de paramètres, plus de données d'entraînement. C'est la mauvaise question. Le problème n'est pas la puissance du modèle. C'est l'absence d'une architecture de données qui encode la connaissance de votre domaine — ce que la discipline appelle une ontologie.
Avant de concevoir quoi que ce soit, j'ai étudié ce que faisaient ceux qui ont vingt ans d'avance. L'ingénierie ontologique n'est pas une invention récente. C'est une discipline formelle, avec ses méthodologies, ses standards et ses retours d'expérience industriels. Trois principes m'ont guidé.
Le Middle-Out (Airbus). Quand Airbus a voulu structurer les exigences de conception de ses ailes d'avion (projet OntoREM), les équipes n'ont ni commencé par une modélisation abstraite du monde (approche descendante, trop lente), ni par un inventaire exhaustif de toutes les données (approche ascendante, trop chaotique). Elles sont parties des concepts que les ingénieurs manipulent au quotidien — "maintenance", "réparabilité", "inspection" — puis ont généralisé vers le haut et spécialisé vers le bas. C'est l'approche Middle-Out : on ancre l'ontologie dans le vocabulaire réel de l'expert métier, pas dans une vision philosophique du réel ni dans les colonnes d'un tableur.
L'Engagement Ontologique Minimal (EDF). Le principe MOC (Minimal Ontological Commitment) stipule qu'une ontologie ne doit contenir que les axiomes strictement nécessaires au besoin. Chaque concept supplémentaire alourdit le raisonnement et ralentit le système. Dans le nucléaire, un exploitant du parc français utilise des ontologies OWL DL pour l'analyse automatisée des modes de défaillance (FMEA) : le raisonneur déduit les conséquences systémiques d'une panne en parcourant le graphe. Si l'ontologie est "obèse" — trop de concepts, trop de relations — le raisonneur ne termine pas en temps utile. Le MOC est la discipline qui empêche cela.
La réingénierie de l'existant (TotalEnergies). Le framework NeOn, appliqué par TotalEnergies via sa suite SousLeSens, part d'un constat pragmatique : le développement ontologique ex nihilo est un échec économique. L'industrie possède déjà des standards (ISO 15926), des schémas de bases de données, des taxonomies internes. Le Scénario 2 de NeOn consiste à transformer ces ressources non-ontologiques en modèles formels. On ne repart pas de zéro — on fédère l'existant.
Ces trois principes partagent une conviction : la sobriété est une architecture. Il ne s'agit pas de tout modéliser, mais de modéliser juste assez pour que le raisonnement fonctionne. C'est exactement ce que j'ai tenté d'appliquer.
Quand j'ai conçu le Knowledge Graph pour la surveillance de réacteurs nucléaires, j'ai appliqué le Middle-Out à la lettre : je suis parti de ce que l'ingénieur de surveillance pense quand il travaille. Il pense "puissance", "température primaire", "bore", "phase opérationnelle". Il ne pense pas en termes de schéma relationnel, ni en termes de colonnes Parquet.
L'ontologie tient en trois modules — conformément au MOC, pas un de plus que nécessaire.
Module A — Les actifs (la structure). Un réacteur appartient à un palier technologique (900 MWe, 1300 MWe, 1450 MWe). Le palier détermine le nombre de boucles primaires, donc le nombre de capteurs de température. C'est une contrainte physique, pas un paramètre configurable. Le graphe modélise : ReactorUnit → belongsToPalier → ReactorModel. Cinq types de composants, pas deux cents. Le MOC en action.
Module B — La métrologie (la mesure). Chaque capteur est lié au paramètre physique qu'il mesure, avec ses métadonnées : code technique, colonne dans le Data Lake, phase opérationnelle privilégiée. La relation clé est Sensor → measures → PhysicalParameter. C'est elle qui permet la résolution sémantique — transformer le mot "puissance" prononcé par l'ingénieur en code capteur technique. Les alias ("puissance", "power", "neutronique") sont stockés dans le graphe, pas dans le prompt du LLM. Si demain le vocabulaire change, on modifie le graphe. Ni le code, ni le modèle ne bougent.
Module C — La physique (les lois). C'est ici que l'ontologie devient "intelligente". Les paramètres physiques sont reliés par des règles causales, issues de la modélisation physique du réacteur : la concentration en bore inhibe la puissance neutronique ; la position des grappes de contrôle détermine le déséquilibre axial ; la phase opérationnelle active ou désactive certains paramètres. Ces relations — inhibits, determines, enables, disables — ne sont pas des corrélations statistiques. Ce sont des lois de la physique, codées comme des arêtes du graphe.
Pourquoi trois modules et pas un seul ? La modularité est un principe de l'IOF (Industrial Ontologies Foundry) : chaque module évolue indépendamment. Quand un nouveau palier de réacteur entre en service, seul le Module A change. Quand une nouvelle règle physique est identifiée, seul le Module C est mis à jour. Le reste du système continue de fonctionner.
Les conventions de nommage suivent le standard IOF : classes en PascalCase (NeutronicPower, ControlRod), propriétés en camelCase (monitorsParam, hasOperationalPhase). Ce n'est pas du formalisme pour le plaisir — c'est ce qui permet à un raisonneur automatique de traiter le graphe sans ambiguïté, et à un ingénieur qui n'a pas conçu l'ontologie de la comprendre en la lisant.
La meilleure façon de montrer ce que fait le Knowledge Graph, c'est de tracer une requête réelle, couche par couche. Un ingénieur tape en langage naturel : "Affiche la puissance sur [un réacteur du parc]."
Couche 1 — Le vocabulaire humain. Le LLM analyse la phrase. Il identifie un concept : "puissance". Il ne connaît pas encore le code technique du capteur. Mais il sait qu'il doit interroger le graphe.
Couche 2 — Le concept physique. Le graphe reçoit le mot "puissance" et le cherche dans les alias des paramètres physiques. Grâce à la liste d'alias enrichie en amont (['puissance', 'power', 'neutronique']), le mot humain est résolu vers le concept formel NeutronicPower — puis vers le capteur qui mesure ce paramètre. Ce n'est pas une recherche textuelle dans une base SQL. C'est une navigation sémantique : le graphe comprend que "puissance" et "neutronique" réfèrent au même paramètre physique.
Couche 3 — L'enrichissement contextuel. Le système ne renvoie pas un code brut. Il interroge le contexte autour du capteur : que mesure-t-il ? Quelles règles physiques le gouvernent ? Quels autres capteurs sont corrélés ? Le graphe renvoie que ce capteur correspond à la "chaîne neutronique large échelle" — pas juste un identifiant, mais une donnée qualifiée.
Couche 4 — La donnée brute. Le noeud Sensor dans le graphe contient une propriété dataColumnGold : l'adresse exacte de la donnée dans le Data Lake Parquet. L'assistant utilise cette adresse pour extraire les séries temporelles via DuckDB — en sub-seconde, zero-copy, 32 threads.
Le système a traversé : Vocabulaire humain → Concept physique → Capteur réel → Donnée brute. Quatre couches, chacune déterministe et traçable. À aucun moment le LLM n'a "deviné" le code capteur. À aucun moment il n'a halluciné. Chaque étape est explicable : on sait pourquoi "puissance" a mené à tel capteur, via quelle relation du graphe.
Et c'est précisément le point. La valeur n'est pas dans le LLM — un des modèles les plus légers du marché suffit. La valeur est dans l'ontologie qui le contraint.
Ce blog s'appelle Foundations. Quatre couches d'expertise empilées : les données, l'optimisation, la physique, la lucidité. J'ai commencé en 2021 par des tutoriels de séries temporelles en R (Couche 1). Quatre ans plus tard, je rédige des essais sur les limites de l'IA (Couche 4).
Ce que cette expérience m'a appris : même à la Couche 4, c'est la Couche 1 qui fait la différence. Le Knowledge Graph n'est pas une "fonctionnalité IA". C'est une architecture de données — un modèle formel qui encode les lois de votre métier avant que le moindre algorithme n'entre en jeu.
Un petit modèle contraint par une ontologie bien conçue surpasse un modèle puissant sans structure. L'intelligence d'un système IA industriel ne réside pas dans ses paramètres. Elle réside dans ses données — et dans la rigueur avec laquelle on les a structurées.
On ne s'évade jamais des fondations.
Airbus/UWE, OntoREM — Ontology-driven Requirements Engineering Methodology, IEEE, 2009
TotalEnergies, SousLeSens — A Comprehensive Suite for the Industrial Practice of Semantic Knowledge Graphs, ESWC, 2024
EDF/Oxford, The Energy Management Adviser at EDF, Proceedings of the ISWC, 2013
Thales, Towards the Deployment of Knowledge Based Systems in Safety-Critical Systems, ESWC, 2023
Industrial Ontologies Foundry (IOF), Technical Principles, NIST/OAGi
AI- and Ontology-Based Enhancements to FMEA for Advanced Systems Engineering, arXiv, 2024
