Projection Engineering projette des Claims incertaines dans un graphe auditable

Image : générée avec Google Gemini.

Un système automatisé affirme que le loyer de juillet n’a pas été payé.

Produire cette phrase coûte peu. La vérifier, non. Quelqu’un doit examiner le bail, identifier les comptes enregistrés, contrôler la période concernée, distinguer les virements réglés de ceux en attente, se demander si le paiement a pu être affecté à une autre dette et déterminer quelle politique autorise ce résultat à déclencher une mise en demeure ou une expulsion.

La réponse tient en une phrase. Son périmètre de vérification s’étend au monde entier.

Tel est le problème structurel de l’IA générative. Il ne tient pas seulement au fait qu’un modèle peut se tromper. Une Claim plausible peut désormais être produite presque instantanément, alors que sa vérification peut exiger de reconstituer les documents, hypothèses, transformations, politiques et omissions qui la sous-tendent.

La vérification est devenue plus coûteuse que la génération.

Rendre le modèle plus éloquent ne corrige pas cette inversion. Ajouter une citation non plus, si personne ne peut déterminer quelle partie de la source étaye quelle proposition, quelle version a été utilisée ou ce qui doit être rouvert lorsque la source change.

Les institutions matures ont résolu des problèmes analogues en insérant une couche de responsabilité entre l’observation et le calcul. La physique a construit la métrologie. Le droit a construit l’établissement judiciaire des faits. L’IA possède des fragments des deux, mais aucune discipline reconnue chargée de transformer les Claims du monde ouvert en prémisses qu’une décision peut utiliser en toute sécurité.

J’appelle cette responsabilité manquante Projection Engineering.

La couche manquante entre un document et une décision

La métrologie ne fait pas confiance à l’aiguille

Un capteur qui affiche un nombre n’a pas encore produit une mesure digne de confiance. Une mesure exige aussi une unité, un historique d’étalonnage, une chaîne de traçabilité, une incertitude et un domaine de validité déclaré. Le NIST souligne que la traçabilité métrologique appartient à un résultat de mesure, et non simplement à un instrument portant une étiquette d’étalonnage (Traçabilité métrologique : foire aux questions et politique du NIST).

Ce dispositif environnant rend les défaillances diagnostiquables. Si une structure cède, un enquêteur peut remonter de la valeur rapportée, à travers les transformations et les étalonnages, jusqu’à l’observation d’origine. L’arithmétique seule ne fournit pas ce chemin. La métrologie permet à un nombre de porter un poids institutionnel.

Une réponse de LLM arrive généralement sans chaîne équivalente. Elle identifie rarement l’observation à l’origine de chaque Claim, ce qui a été perdu pendant la transformation, le domaine dans lequel la Claim reste valide ou les décisions dépendantes qui doivent être rouvertes après une correction. C’est une aiguille mobile sans cadran ni certificat d’étalonnage.

Le droit ne fait pas confiance à l’allégation

Un tribunal n’accède pas au passé lui-même. Il rencontre des allégations, témoignages, documents, pièces et rapports d’experts. Par les règles de preuve, la charge et les standards de preuve ainsi que les procédures autorisées, l’établissement judiciaire des faits décide quelles Claims concurrentes peuvent servir de prémisses dans une affaire donnée. La distinction entre réalité substantielle et vérité juridique formelle est un problème ancien de l’établissement judiciaire des faits (Vérité juridique formelle et vérité substantielle dans l’établissement judiciaire des faits).

Séparer l’établissement des faits de l’application des règles permet aussi de séparer les erreurs. Un document peut être mal collecté. Une proposition peut être admise selon le mauvais standard. Une prémisse correcte peut rencontrer une règle mal implémentée. Une conclusion correcte peut être exécutée contre la mauvaise personne. Chaque défaillance appartient à une couche différente et exige une réparation différente.

La métrologie transforme les observations en valeurs traçables. Le droit transforme un dossier contesté en constatations utilisables pour un jugement. Tous deux refusent de laisser des données brutes s’écouler silencieusement dans un calcul lourd de conséquences. C’est la couche qui manque aux systèmes décisionnels d’IA.

Fact signifie Accepted Fact

Le nom Projection Engineering exige une frontière stricte. Il ne promet pas de fabriquer une vérité absolue.

Dans Projection Engineering, Fact signifie Accepted Fact.

Une Accepted Fact est une Claim dont l’usage comme prémisse dans une décision particulière est autorisé selon un objectif, un périmètre, un temps de référence, un standard de preuve et une politique explicites.

Trois objets doivent rester distincts :

  • Claim : une assertion ou une observation soumise par une source identifiée.
  • Accepted Fact : une Claim admise comme prémisse par une procédure autorisée.
  • Conclusion : un résultat calculé à partir d’Accepted Facts et de règles.

Une Accepted Fact est une Claim dotée d’un statut institutionnel documenté, et non la réalité capturée dans un champ. La vérité reste l’objectif : la proposition devrait correspondre à la réalité. Ce que le système peut préserver est plus étroit et opérationnel — qui a affirmé quoi, à partir de quel document, à quel moment et au moyen de quelle transformation ; qui l’a accepté ou rejeté, sous quelle autorité ; et ce qui a découlé de cet ensemble borné de prémisses.

Projection Engineering ne possède pas la vérité. Il conçoit la frontière autour d’une décision afin qu’une autre personne puisse l’examiner et la contester.

L’IA est déjà fermée — sur les tokens

Un Transformer figé est fermé dans un sens computationnel utile. Fixez ses poids, son entrée, son environnement d’exécution et ses conditions de décodage, et son passage avant peut être rejoué. L’architecture calcule quel token devrait suivre (Tout ce dont vous avez besoin, c’est de l’attention). Elle est fermée sur les probabilités des tokens, pas sur la réalité.

Cette distinction explique à la fois sa résilience et sa limite. Un corpus d’entraînement peut contenir X et not-X. La déduction classique doit gérer une telle contradiction, car une explosion non restreinte peut permettre de déduire n’importe quoi. Un modèle de langage n’explose pas : les passages contradictoires modifient une distribution au lieu d’invalider une preuve, car l’implication logique n’est pas l’opération primitive effectuée.

Pour la même raison, l’attention et softmax ne contiennent aucune règle garantissant que des prémisses vraies préservent la vérité au cours de la génération. Les systèmes modernes peuvent réduire les erreurs exprimées avec assurance, mais les hallucinations persistent notamment parce que l’entraînement et l’évaluation peuvent récompenser la conjecture plutôt que la reconnaissance de l’incertitude (Pourquoi les modèles de langage hallucinent).

Nous prenons un calcul sur le langage et l’utilisons comme un jugement sur le monde. La fermeture existe, mais une couche en dessous de celle où la responsabilité est nécessaire. Projection Engineering fournit une autre fermeture : il déclare quelles Claims, politiques, autorités et temporalités définissent le monde de cette décision. Des règles reproductibles peuvent alors calculer à l’intérieur de celui-ci.

Le mètre montre ce que la fermeture rend possible

En 1983, la 17e Conférence générale des poids et mesures a défini le mètre comme la distance parcourue par la lumière dans le vide pendant 1/299,792,458 de seconde, fixant exactement la vitesse de la lumière à 299,792,458 m/s dans la définition du SI (Résolution 1 de la 17e CGPM (1983)).

La valeur n’est pas devenue exacte parce que l’humanité aurait enfin mesuré la nature sans incertitude. Une communauté autorisée l’a déplacée de l’autre côté d’une frontière : d’une grandeur à affiner vers un élément de la définition du système. Les mesures situées sous cette frontière sont devenues plus précises parce que la frontière était explicite.

Il ne s’agissait pas de prétendre posséder la réalité. C’était une convention datée, adoptée par une autorité identifiable selon une procédure définie et révisable par une autre procédure. Projection Engineering ferme une décision dans le même sens limité. Il ne ferme pas la réalité. Il fige les Claims qui peuvent servir de prémisses ici et maintenant, selon une politique et une autorité nommées.

Là où l’analogie s’arrête

La métrologie est un guide, pas un déguisement pour les problèmes non résolus.

Premièrement, la mesure ordinaire bénéficie souvent de la répétition. Un paiement, un consentement, une inspection, un licenciement ou un accident peut être un événement unique. Le modèle le plus proche est la métrologie forensique : une observation unique doit résister à une procédure contradictoire grâce à des artefacts préservés, une chaîne de possession, une procédure documentée et des limites instrumentales connues.

Deuxièmement, l’incertitude numérique peut souvent se propager dans des équations. Les propositions non résolues ne disposent pas encore d’une arithmétique aussi générale. Préserver supported, defeated et unknown au fil de longues dérivations sans les blanchir en fausse précision demeure un problème de recherche ouvert.

Troisièmement, déclarer une source complète ou une politique contraignante est un exercice d’autorité. La traçabilité peut révéler ce choix, mais elle ne peut le rendre impartial. Projection Engineering doit montrer qui a pesé sur la balance ; il ne peut promettre d’en retirer toute influence.

Un GAF n’est pas une liste

Stocker une Accepted Fact seule détruit les informations qui l’ont rendue acceptable. Nous perdons qui l’a soumise, ce qui l’a contestée, quelle politique l’a admise et quelle autorité a rendu cette politique opérante.

Le livrable de Projection Engineering est donc un Graph of Accepted Facts (GAF).

Records / Observations
          │
          ▼
        Claims ◀──── Evidence / Counterevidence
          │
          ▼
  Evaluation + Projection Policy
          │
          ▼
   Accepted Facts ─────┐
          │             │
          ▼             │
 Rules / Derivations    │
          │             │
          ▼             │
      Conclusions       │
                        │
 Provenance ────────────┘

Un GAF relie les documents d’origine, les Claims extraites, les éléments de preuve favorables et contraires, les évaluations, la politique et l’autorité, les Accepted Facts, les dérivations, les conclusions, les versions, les horodatages et les dépendances. Les normes existantes modélisent déjà les entités, activités, agents et relations de provenance ; PROV-O : l’ontologie PROV montre que ce vocabulaire n’a pas besoin d’appartenir à un seul produit de base de données.

Un GAF n’a pas non plus besoin de résider dans une base de données graphe. Une base relationnelle ou un journal en ajout seul suffit s’il préserve les relations et une lineage bidirectionnelle.

  • À partir d’une conclusion, un auditeur doit pouvoir remonter à travers les Accepted Facts et les Claims jusqu’aux documents d’origine.
  • À partir d’un document invalidé, le système doit pouvoir avancer vers chaque Accepted Fact, conclusion et action autorisée susceptible de devoir être rouverte.

Le premier chemin rend une décision auditable. Le second rend la correction calculable.

Un paiement de loyer, trois problèmes d’ingénierie

Revenons au litige sur le loyer. Le locataire affirme que le loyer a été payé. Le propriétaire affirme qu’il ne l’a pas reçu en tant que loyer. Un relevé bancaire montre qu’une somme a circulé entre leurs comptes enregistrés pendant la période convenue, mais le libellé est vide.

La première tâche est la décomposition propositionnelle :

A payment moved from the tenant's account to the landlord.  [accepted]
That payment discharged this month's rent obligation.       [undetermined]

Le transfert et l’affectation juridique sont des Claims différentes. Si une autre dette peut exister, la première n’implique pas la seconde. Choisir de les séparer n’est pas un travail administratif. Dans une affaire de licenciement, demander si le motif invoqué existait, si la procédure a été suivie, si le motif justifiait le licenciement et si l’acteur disposait de l’autorité produit, à partir des mêmes documents, des graphes de décision différents.

C’est la formation des questions, le métier fondamental de Projection Engineering. Celui qui formule les propositions détermine ce qui peut être accepté, réfuté ou laissé inconnu. Le système doit préserver qui a effectué cette décomposition, dans quel but, sous quelle autorité et quelles possibilités ont été exclues. Une provenance parfaite après un cadrage biaisé ne fait que documenter élégamment le biais.

Le deuxième problème est l’absence. Ne pas trouver un paiement n’établit pas son non-paiement. La période peut être erronée, la recherche incomplète, le virement en attente ou le document détenu par une autre institution. L’absence ne devient une preuve qu’après qu’un contrat de complétude a défini ce que la source promet de contenir.

Completeness contract C-04

Declarant: operator of ledger L
Scope: all settled transactions for account A during period P
Excludes: pending transactions and records held by other institutions
Authority: signed policy version V

Alors seulement l’absence peut-elle étayer une négation dans ce périmètre. Déclarer complète une source commode peut transformer un cas inconnu en cas décidable ; la déclaration doit donc porter une identité, une signature, une date, une version et une autorité.

Le troisième problème est la répétition du jugement humain. Une personne peut décider qu’un virement provenant du compte enregistré, effectué pendant la période convenue, du montant exact et sans dette concurrente vaut paiement du loyer malgré un libellé vide. L’actif réutilisable n’est pas cette réponse particulière. C’est le jugement général qui la sous-tend.

Il s’agit de préservation de la décision, mais un exemple ne doit pas devenir silencieusement un précédent. Le jugement reste une politique candidate jusqu’à ce qu’une personne autorisée précise son périmètre, ses exceptions, sa date d’effet, sa rétroactivité et ses conditions de révocation. Alors seulement devient-il une politique ratifiée.

De la Claim à l’action autorisée

Projection Engineering n’est ni un modèle ni un produit de stockage. C’est le processus qui projette les documents du monde ouvert dans un monde décisionnel fermé et rouvre ce monde lorsque les preuves ou les politiques changent.

Reality
   │
   ▼
Records / Observations
   │  preservation · calibration · transformation history
   ▼
Claims
   │  proposition decomposition · source evaluation · conflicts and gaps
   ▼
Projection
   │  purpose · scope · reference time · proof standard · authority · policy version
   ▼
GAF
   │  Accepted Facts · provenance · dependencies
   ▼
Closed Decision World
   │
   ▼
Deterministic Conclusion
   │
   ▼
Authorized Action

Chaque transition peut produire une erreur différente :

  • L’absence d’un document d’origine est une erreur de collecte.
  • Un mauvais OCR ou une mauvaise extraction est une erreur de transformation.
  • Mal formuler la question ou accepter la mauvaise Claim est une erreur de projection.
  • Calculer une conclusion erronée à partir d’Accepted Facts correctes est une erreur de règle.
  • Appliquer une conclusion correcte à la mauvaise cible est une erreur d’exécution.

Chacune exige une réparation différente. De nouveaux éléments de preuve corrigent la collecte. Une réévaluation corrige la projection. Un moteur de règles corrigé peut rejouer un GAF figé. Les défaillances d’exécution exigent une annulation, une correction ou une compensation — pas une réécriture des faits. Dire de chaque défaillance que « l’IA s’est trompée » ne permet d’en réparer aucune.

Payer une seule fois le coût de la compréhension

La couche manquante n’est pas seulement un risque. Elle est aussi une source de gaspillage. Un modèle lit un contrat, identifie les parties, extrait les obligations et répond à une question. La question suivante paie souvent de nouveau une grande partie du même coût d’interprétation. La retrieval réduit le texte chargé, mais continue de déplacer des fragments de prose, car l’unité réutilisable reste le fragment de document.

La compilation sémantique change cette unité. Un document est interprété une fois en propositions stables dotées d’identifiants, de sources, d’un périmètre temporel et de dépendances. Les questions ultérieures réutilisent ces propositions entre prompts, utilisateurs et documents. Nous payons une seule fois le coût de la compréhension, lorsque la Claim entre dans le système, plutôt que chaque fois que quelqu’un pose une question à son sujet.

La mise en cache des prompts ne peut remplacer cette couche. Un cache préserve des octets et leur ordre. Un GAF préserve le sens et la provenance. Un cache de préfixe peut être rompu lorsque l’ordre change ; une proposition peut se combiner avec des Claims extraites ailleurs et servir à chaque décision qui en dépend.

La réutilisation du sens crée un problème d’invalidation plus difficile. Si une source est corrigée, remplacée ou révélée frauduleuse, quelles conclusions doivent être rouvertes ? Un cache de faits sans provenance est un cache d’hallucinations : il répète la même erreur plus vite et avec davantage d’assurance.

La lineage est l’invalidation du cache.

La structure qui permet à une personne de contester une décision est la même que celle qui permet à une machine de recalculer uniquement les conclusions affectées. Responsabilité et efficacité ne sont pas ici des fonctions concurrentes. Elles constituent deux usages du même graphe de dépendances.

La frontière avec les disciplines voisines

Projection Engineering ne remplace pas Data, Knowledge, Rule, Prompt ou Context Engineering. Il possède la frontière de responsabilité qu’elles traversent actuellement sans gardien comptable de bout en bout.

Data Engineering déplace les documents selon source → ingest → transform → store → serve. Projection Engineering demande si un document qualifie une information pour servir de prémisse selon record → claim → evaluate → project → GAF. Un schéma valide peut contenir un document faux.

Knowledge Engineering représente des concepts et des relations destinés aux machines. Projection Engineering traite d’abord chaque relation comme une Claim et enregistre qui a autorisé son usage comme connaissance dans une décision bornée.

Rule Engineering calcule des conclusions à partir des prémisses fournies. Projection Engineering construit et fige le graphe de prémisses sur lequel ces règles s’exécutent.

Prompt Engineering façonne les instructions. Context Engineering sélectionne les informations destinées au calcul. Projection Engineering pose la question préalable : quelle Claim cette information constitue-t-elle, et pourquoi peut-elle servir de prémisse ici ?

Un meilleur prompt ne peut sauver une prémisse acceptée à tort.

Le LLM est un opérateur, pas l’autorité

Un LLM est un opérateur au sein de ce processus. Il peut extraire des Claims candidates de documents non structurés, scinder des énoncés composés, repérer des conflits, demander les preuves manquantes et traduire la lineage en langage lisible.

Il n’est pas l’autorité. Sa sortie est une Claim supplémentaire. Les recherches sur l’attribution distinguent la génération fluide des énoncés étayables par des sources identifiées (Mesurer l’attribution dans les modèles de génération de langage naturel). Les recherches sur la fidélité du raisonnement montrent aussi qu’une chaîne de pensée générée ne constitue pas de manière fiable la trace causale d’exécution d’une réponse (Donner de l’importance au raisonnement : mesurer et améliorer la fidélité du raisonnement en chaîne de pensée).

Si le même modèle extrait une Claim, l’accepte, choisit la règle, explique le résultat et autorise l’action, le pipeline s’effondre en une génération opaque unique. Un récit a posteriori n’est pas un enregistrement de provenance.

La génération peut être probabiliste. L’acceptation des Facts, l’achèvement et l’autorité d’agir doivent être gouvernés séparément.

L’assurance statistique ne peut expliquer mon cas

L’objection la plus forte est pratique. Les organisations n’exigent pas une trace de dérivation complète de chaque décideur humain. Elles surveillent les résultats agrégés, les contrôles qualité et des audits par échantillonnage. Pourquoi ne pas gouverner les modèles de la même manière ?

L’assurance statistique est utile et souvent suffisante pour améliorer un système. Elle ne peut cependant pas répondre à la question posée par une personne prise dans un résultat contesté :

Quelle était la prémisse dans mon cas ?

La précision agrégée ne révèle pas quel document était erroné, quelle Claim a été acceptée, quelle politique a été appliquée ni quel nouvel élément pourrait étayer un recours. L’assurance à l’échelle d’une population et la contestabilité à l’échelle d’un cas résolvent des problèmes différents.

Cette distinction définit le périmètre. Projection Engineering n’est pas destiné à tous les systèmes d’IA. Il concerne les systèmes qui prennent des décisions contestables — crédit, rémunération, admissibilité, expulsion, assurance, autorisation médicale et actions similaires pour lesquelles une personne doit pouvoir examiner et contester l’ensemble des prémisses. Le cadre de gestion des risques liés à l’IA du NIST traite la responsabilité et la transparence comme des propriétés du cycle de vie, tandis que le règlement (UE) 2024/1689 impose la journalisation des événements aux systèmes à haut risque.

Pour une génération à faible enjeu que personne n’a besoin de contester, ce dispositif peut être excessif. Le périmètre fait partie de l’ingénierie.

Le contrat minimal

Un système qui prétend pratiquer Projection Engineering devrait pouvoir répondre oui à toutes les questions suivantes :

  1. Distingue-t-il les documents d’origine des Claims dérivées et attache-t-il à chaque Claim sa source, sa temporalité et son historique de transformation ?
  2. Décompose-t-il les Claims composées en propositions contestables indépendamment et enregistre-t-il qui a formulé les questions et pourquoi ?
  3. Préserve-t-il les Claims contradictoires et les possibilités rejetées au lieu de les supprimer ?
  4. Distingue-t-il false, unknown et not found, en exigeant un contrat de complétude avant de transformer l’absence en négation ?
  5. Peut-il retracer une Accepted Fact jusqu’aux preuves, à la politique, à l’autorité et à la version — et suivre une source invalidée vers les conclusions affectées ?
  6. Peut-il reproduire exactement le GAF et l’instantané des règles utilisés pour une décision, puis obtenir la même conclusion dans la même fermeture ?
  7. Peut-il préserver un jugement humain récurrent sous la forme d’une politique ratifiée dotée d’un périmètre, d’exceptions et d’une date d’effet ?
  8. L’acceptation des Claims, le jugement selon les règles et l’autorité d’agir sont-ils séparés, avec une procédure permettant de rouvrir une décision passée plutôt que de l’effacer ?

Si l’une des réponses est non, le système promeut silencieusement une Claim en Fact quelque part.

Pourquoi il s’agit d’une nouvelle discipline d’ingénierie

Les composants existent déjà : provenance, gestion des preuves, graphes d’argumentation, systèmes de maintien de la vérité, event sourcing, moteurs de règles, journaux d’audit, établissement judiciaire des faits, métrologie et raisonnement en monde fermé.

Des composants ne constituent pas une frontière de responsabilité. Les bases de données et l’ETL existaient avant que Data Engineering ne se structure comme domaine. Les serveurs et scripts de déploiement existaient avant le DevOps. Un domaine se forme lorsque des défaillances récurrentes dispersées dans les organisations sont réunies sous un rôle responsable, une catégorie de livrables et des méthodes de vérification reproductibles.

Aucun rôle ne possède aujourd’hui cette question de bout en bout :

À quel moment, sous l’autorité de qui et selon quelle politique un document issu de la réalité est-il devenu une Accepted Fact utilisable dans une décision ?

Les data engineers possèdent les pipelines. Les knowledge engineers possèdent la représentation. Les ML engineers possèdent les modèles. Les experts du domaine expliquent les règles. Les opérateurs gèrent les exceptions. Entre eux, l’acceptation des faits se dissout dans le code de nettoyage, les prompts, la logique applicative, l’inférence du modèle et les habitudes non documentées.

Projection Engineering ne prétend pas que chacun de ses composants est nouveau. Il propose une nouvelle discipline d’ingénierie parce que la frontière elle-même a besoin d’un responsable, d’un livrable et d’un moyen déterministe de vérifier si ses promesses ont été tenues.

Rendre la vérification de nouveau peu coûteuse

Le monde ouvert ne s’arrête jamais. De nouveaux documents arrivent, les témoignages changent, les capteurs sont réétalonnés et les politiques sont modifiées. Un système qui attend une réalité complète n’agira jamais. Un système qui cache l’incertitude agira sans responsabilité.

Projection Engineering choisit un contrat plus étroit :

  • Préserver les Claims au lieu d’effacer les désaccords.
  • Dire Accepted Fact chaque fois que Fact signifie une prémisse autorisée.
  • Relier chaque acceptation à des preuves, une politique, une autorité, une temporalité et un périmètre.
  • Ne jamais transformer unknown en false sans contrat de complétude.
  • Figer le monde décisionnel et les règles effectivement utilisés.
  • Reproduire la conclusion à partir des mêmes entrées fermées.
  • Préserver le jugement récurrent sous la forme d’une politique explicite et ratifiée.
  • Rouvrir les décisions lorsque les preuves changent au lieu de réécrire le passé.

Il ne possède pas la vérité, n’élimine pas les biais et ne rend pas les machines infaillibles. Il rend le monde limité utilisé pour une décision suffisamment visible pour être examiné, contesté, rejoué et réparé.

Les mathématiques sont devenues socialement puissantes non parce qu’elles répondaient à toutes les questions, mais parce que les personnes absentes d’une dérivation pouvaient examiner ce qui découlait de prémisses déclarées. La métrologie a donné du poids aux mesures en entourant les nombres de traçabilité. Le droit a rendu le jugement possible sans rejouer le passé, en séparant les allégations des prémisses acceptées.

L’IA possède déjà l’arithmétique. Ce qui lui manque, c’est l’institution autour de cette arithmétique.

L’objectif de Projection Engineering est simple :

Rendre la vérification de nouveau peu coûteuse.

La réalité nous donne des Claims.

Les décisions exigent des Accepted Facts.

Projection Engineering projette les Claims dans un Graph of Accepted Facts auditable.

Articles liés

Sources