Aller au contenu principal

La machine fiduciaire

Enseigner à une IA d’agir dans nos intérêts n’est pas construire un système dont on peut vérifier le travail

Abstract editorial architecture of interconnected graphite chambers with transparent pathways, evidence fragments and subtle balance-scale geometry on warm paper, with restrained signal-red accents
  • Standards fiduciaires : utiles pour des buts incomplets ; insuffisants.
  • Dès les conséquences, le LLM n’est plus le système, une pièce.
  • Score déterministe ≠ jugement déterministe : le modèle pèse les prémisses.
  • Preuve ≠ fait ; validation ≠ vérité. Garde autant que récit.
  • Confiance dans le trouvé ≠ couverture. Plusieurs agents ≠ indépendance.
  • Fiduciaire dans et autour du modèle : contestable, vérifiable.
Qu’est-ce que la séparation épistémique des pouvoirs ?

Un principe d’architecture pour l’IA à conséquences : ne pas laisser la même composante probabiliste contrôler la découverte, la garde des preuves, l’extraction, la méthode, le jugement, la confiance, l’explication, la vérification et l’autorité finale. On sépare ces charges parce que l’autorité épistémique concentrée agrandit l’erreur.

Pourquoi un calcul déterministe ne suffit-il pas ?

Un calculateur déterministe peut reproduire une note à l’identique tout en reposant sur des prémisses probabilistes. Si le modèle a orienté les preuves qui entraient dans le calcul, on a une arithmétique reproductible et un jugement qui ne l’est pas — une autorité épistémique indirecte.

En quoi confiance et couverture diffèrent-elles ?

La confiance dans la preuve demande : quelle est la force de ce que nous avons trouvé ? La couverture demande : avec quelle exhaustivité avons-nous parcouru l’espace pertinent ? Une haute confiance dans les sources trouvées ne dit rien des preuves contradictoires jamais découvertes. L’absence de preuve n’est pas la preuve de l’absence.

Plusieurs agents créent-ils de l’indépendance ?

Pas nécessairement. Des agents qui partagent les preuves, l’orchestration et l’infrastructure de modèles peuvent offrir une modularité utile sans indépendance épistémique. Séparer les consignes n’est pas séparer les pouvoirs ; les étiquettes institutionnelles peuvent masquer un couplage technique.

Qu’est-ce qui rend un système « fiduciaire » ?

Pas une consigne système qui dit d’agir dans le meilleur intérêt du client, mais une architecture capable de montrer comment ces intérêts ont contraint l’action — preuves inspectables, conclusions contestables, autorité distribuée, travail vérifiable plutôt que simplement crédité de confiance.

Aujourd’hui, je suis tombé sur un article d’Alpha Architect signé Elisabetta Basilico, PhD, CFA : AI should assist advisors, but AI is NOT a fiduciary.

J’ai suivi le fil.

Il mène au papier de John J. Nay, Large Language Models as Fiduciaries — et, de là, à une question qui habitait déjà, sans vraiment se formuler, les systèmes que je construis.

Le titre de Nay, à lui seul, provoque.

L’idée, elle, vaut mieux que le titre.

Il part d’un problème constitutif de l’intelligence artificielle : on ne peut pas prévoir toutes les situations qu’un système autonome rencontrera, ni dresser d’avance la liste de toutes les actions justes.

Le droit vit avec à peu près le même trou depuis des siècles.

Les contrats restent incomplets. Le législateur ne voit pas tous les cas à venir. Les tribunaux interprètent sans relâche des obligations générales face à des faits que personne n’avait imaginés au moment d’écrire la règle.

Plutôt que de tout prévoir, le droit s’appuie souvent sur des standards.

Le raisonnable.

La bonne foi.

La diligence.

Le devoir fiduciaire.

Ces notions débordent volontairement une liste d’instructions if → then. Elles visent non seulement la règle au pied de la lettre, mais quelque chose de plus proche de sa raison d’être.

Nay soutient que cette mécanique juridique pourrait servir l’alignement de l’IA.

Les standards juridiques transporteraient vers des agents artificiels des buts humains mal spécifiés, parce qu’ils emportent un contexte accumulé : affaires, interprétation, précédent.

Son argument plus large, Law Informs Code, va plus loin : le droit serait l’un des plus riches réservoirs d’essais humains pour convertir des valeurs floues en attentes dont on puisse se servir.

Je tiens ça pour une idée importante.

C’est l’article de Basilico qui m’a forcé à relire Nay — non plus comme un morceau de recherche en IA, mais à la lumière de l’architecture des systèmes que je construis vraiment.

Car, en le lisant, une autre question n’a pas cessé de me travailler.

Que se passe-t-il lorsque la machine fiduciaire se trompe ?

Pas malveillante.

Pas compromise.

Pas en train de servir, en secret, quelqu’un d’autre.

Simplement fausse.

Et convaincue, jusqu’au bout, d’avoir raison.


L’attrait du standard fiduciaire

Le devoir fiduciaire intéresse précisément parce qu’il naît là où les règles simples ne suffisent plus.

On l’impose à qui exerce un pouvoir discrétionnaire réel sur les intérêts d’autrui.

Les conseillers en investissement en sont l’exemple le plus immédiat. Le principe déborde ce métier : une partie a le pouvoir, le savoir ou la latitude de nuire matériellement à une autre ; on attend alors loyauté, diligence, et égard aux intérêts du mandant.

Cela se projette, avec une clarté troublante, sur le monde naissant des agents d’IA.

Plus ces systèmes rendent service, moins l’instruction exhaustive séduit.

Essayez de décrire chaque action acceptable d’un conseiller financier artificiel.

Si les marchés baissent de 12 %, faites ceci.

Sauf si le client a 63 ans.

Sauf s’il a besoin de liquidités l’année prochaine.

Sauf si la baisse se concentre sur un secteur.

Sauf si sa fiscalité rend la vente indésirable.

Sauf si la thèse d’investissement d’origine a changé.

Sauf s’il existe une contrainte réglementaire.

Sauf si un autre actif crée un risque corrélé.

Sauf…

L’arbre ne s’arrête jamais.

Un standard du type agir dans le meilleur intérêt du client comprime une masse énorme de conduite voulue dans une consigne relativement courte.

Nay a cherché à savoir si les modèles de langage savaient interpréter de tels standards.

À partir de milliers d’exemples tirés d’opinions de tribunaux américains sur des obligations fiduciaires, ses expériences ont montré un progrès net d’une génération de modèles à la suivante.

Le point n’est pas que la machine ait acquis une conscience.

Elle n’en a pas.

Le point, c’est que des modèles de plus en plus capables semblent, au moins dans une certaine mesure, raisonner sur des standards dont l’application dépend fortement du contexte.

Une possibilité s’ouvre.

Peut-être n’a-t-on pas à dicter à un agent artificiel chaque geste permis.

Peut-être peut-on lui transmettre, plutôt, les principes à l’aune desquels juger les gestes.

La recherche plus large de Nay explore exactement ce terrain : textes, raisonnement et standards juridiques comme pièces de la mécanique par laquelle on communique des objectifs humains à des systèmes artificiels.

Je suis, pour l’essentiel, d’accord avec lui.

Le droit est peut-être l’une des langues les plus riches dont nous disposions pour dire à des machines des attentes humaines incomplètes.

Mais je me convaincs, de plus en plus, que cela ne traite qu’une part du problème.


À l’intérieur du modèle

Quand on parle d’IA digne de confiance, on s’attarde, et c’est compréhensible, sur ce qui se passe dans le modèle.

Peut-on l’aligner ?

Peut-on l’affiner ?

Peut-on lui enseigner des règles ?

Peut-on lui donner des principes constitutionnels ?

Peut-on l’exposer à des décisions de justice ?

Peut-on l’entraîner à partir du retour d’experts ?

Peut-on lui enjoindre d’agir en fiduciaire ?

Un autre modèle peut-il critiquer sa réponse ?

Tout cela compte.

Nay discute plusieurs mécanismes par lesquels les standards juridiques pourraient peser davantage sur le comportement des systèmes : entraînement sur du matériau juridique, apprentissage supervisé, apprentissage par renforcement, retour d’experts, meilleure mise en contexte des standards eux-mêmes.

Il existe pourtant une autre couche.

Le système autour du modèle.

Cette distinction m’importe de plus en plus, parce que je construis une plateforme de recherche collée à ce problème.

Elle enquête sur des entreprises.

Elle rassemble des preuves.

Elle les évalue à l’aune de méthodes explicites.

Elle produit des notes, des estimations de confiance, des conclusions analytiques.

Et parce que certaines de ces conclusions pourront, un jour, peser sur de vraies décisions d’investissement, pourquoi la machine croit ce qu’elle croit l’emporte vite sur le simple fait que la prose sonne intelligente.

Au début, les difficultés paraissaient familières.

Meilleures données.

Meilleurs modèles.

Meilleures consignes.

Meilleure recherche documentaire.

Meilleure extraction.

Demander au modèle de raisonner avec plus de soin.

Tout cela a aidé.

Chaque progrès, pourtant, a fait apparaître une question de plus.

D’où vient cette affirmation ?

Pourquoi le système a-t-il fait crédit à cette source ?

Trois sources, en apparence indépendantes, n’ont-elles fait que répéter le même communiqué ?

L’énoncé figurait-il vraiment dans la source, ou n’était-ce qu’une lecture plausible, inventée par le modèle ?

Pourquoi cette preuve a-t-elle pesé sur la note ?

Quelle méthode a-t-on appliquée ?

Était-ce la même qu’il y a trois mois ?

Pourquoi le système se dit-il confiant ?

90 % de confiance, est-ce une preuve forte, ou seulement plusieurs sources d’accord ?

Quelle preuve n’avons-nous jamais trouvée ?

Qu’est-il advenu de l’information contraire ?

Pourrait-on reproduire la note ?

Pourrait-on reproduire la recherche ?

Quelqu’un pourrait-il contester la conclusion ?

Peu à peu, ces questions quittent le modèle.

Elles deviennent un problème d’architecture.


La machine a cessé d’être le système

Une architecture de recherche précoce séduit par sa simplicité :

Question
   ↓
Model
   ↓
Answer

La recherche documentaire l’améliore :

Question
   ↓
Search
   ↓
Documents
   ↓
Model
   ↓
Answer

Mais les systèmes à conséquences finissent par exiger autre chose :

Question
   ↓
Discovery
   ↓
Sources
   ↓
Evidence
   ↓
Validation
   ↓
Structured facts
   ↓
Methodology
   ↓
Scoring
   ↓
Confidence
   ↓
Interpretation
   ↓
Verification
   ↓
Human decision

À un moment de cette évolution, un glissement conceptuel a lieu :

Le LLM cesse d’être le système. Il devient une pièce du système.

Cela a l’air presque banal.

Ça ne l’est pas.

Dès qu’on l’accepte, l’objectif d’ingénierie change.

On cesse de demander seulement :

Comment faire produire à ce modèle une réponse digne de confiance ?

On commence à demander :

Quelles responsabilités ce modèle a-t-il seulement le droit d’exercer ?

Ce n’est plus la même question.


Qui a le droit de changer le chiffre ?

Parmi les décisions d’architecture les plus lourdes, dans la plateforme que je construis, il y a celle-ci : retirer au modèle de langage la notation numérique.

Le modèle peut lire.

Il peut extraire.

Il peut interpréter un texte brouillon.

Il peut repérer des relations.

Il peut aider à dire si une preuve paraît positive, négative ou pertinente.

Il peut raconter ce qui s’est passé.

Mais dès que des preuves structurées entrent dans la méthode, la note et le rang relèvent d’un code déterministe.

Le modèle n’a pas le droit de décider, d’un coup de tête, qu’une entreprise mérite 82 plutôt que 74.

La confiance, elle aussi, se calcule hors du modèle.

Et une preuve extraite doit passer une validation déterministe avant d’entrer dans le registre qui, in fine, pèse sur la note.

Il y a là une satisfaction réelle.

Même calcul, mêmes entrées structurées : l’arithmétique se comporte de la même façon.

Mettre en œuvre cette séparation, pourtant, a livré une leçon moins confortable.

Un calcul déterministe n’engendre pas nécessairement un jugement déterministe.

Pourquoi ?

Parce que le modèle peut encore avoir orienté les faits qui nourrissent le calcul.

Supposez qu’il lise une source et tienne un énoncé pour une preuve négative forte.

Le moteur de notation peut ensuite traiter cette classification avec une mathématique parfaitement déterministe.

La note qui en sort est parfaitement reproductible.

Mais l’interprétation entrée dans le calcul était probabiliste.

Le modèle n’a pas choisi le chiffre final.

Il a pesé sur les prémisses à partir desquelles on l’a calculé.

C’est une forme d’autorité épistémique indirecte.

D’où un principe :

Rendre le calculateur déterministe ne suffit pas. Il faut aussi savoir qui a le droit de décider ce qui y entre.

Évident, après coup.

Moins évident, pendant qu’on le construit.


Une preuve n’est pas un fait

Une autre distinction a pris la même importance.

Qu’une source dise une chose n’est pas cette chose vraie.

Écrit ainsi, cela a l’air d’une lapalissade.

Les systèmes d’IA brouillent pourtant la frontière avec une facilité déconcertante.

Prenez ces cinq événements :

A source contains a claim.
The system extracts the claim.
The claim passes validation.
The claim influences a methodology.
The final narrative presents a conclusion.

Cinq événements épistémiques distincts.

Beaucoup de systèmes d’IA les font pourtant tenir dans une seule opération, baptisée raisonnement.

Dans la plateforme que je construis, l’extrait de source, l’énoncé extrait par la machine et le statut de validation sont représentés à dessein séparément.

Même alors, le mot validé demande des précautions.

Validé ne veut pas dire vrai.

Cela veut dire que la preuve a survécu à un jeu défini de contrôles d’intégrité.

Un validateur déterministe peut établir qu’un passage cité existe vraiment.

Il peut établir qu’une URL appartient à l’ensemble des sources réellement découvertes.

Il peut écarter certaines affirmations sans appui.

Il peut repérer des décalages d’entités trop grossiers.

Il peut imposer des règles de forme autour de la preuve.

Ce qu’il ne peut pas, c’est établir une vérité universelle.

Voilà pourquoi le vocabulaire pèse tant dans une IA à conséquences.

La preuve est une preuve.

L’affirmation est une affirmation.

L’extraction est une extraction.

La validation est une validation.

La conclusion est une conclusion.

Aucun de ces mots ne doit, en silence, devenir synonyme de vérité.


La provenance refait l’architecture

Dès que la preuve compte, la provenance s’impose.

Si le système m’annonce qu’une entreprise a obtenu 72, une phrase du genre :

« Dans l’ensemble, l’entreprise s’en sort raisonnablement, même si plusieurs points d’attention demeurent. »

ne sert presque à rien.

Je ne veux pas seulement une explication de 72.

Je veux savoir ce qui a produit 72.

Idéalement, je dois pouvoir remonter :

Conclusion
     ↓
Score
     ↓
Methodology
     ↓
Structured assessment
     ↓
Evidence
     ↓
Source excerpt
     ↓
Retrieved document
     ↓
Source
     ↓
Discovery query

Construire cela s’est révélé bien plus dur que d’ajouter des citations à de la prose générée.

Une citation dit que le système souhaite lier un énoncé à une source.

La provenance exige davantage :

Quelle a été la chaîne de conservation, de la découverte jusqu’à la conclusion ?

Notre plateforme actuelle consigne, pour les recherches récentes, les requêtes, les tentatives de collecte, les identifiants de preuve et les versions de méthode.

Une part substantielle de la chaîne redevient reconstructible.

Ce n’est pas parfait.

Certaines relations exigent encore des jointures d’ingénierie.

Les identifiants de présentation ne fournissent pas encore une correspondance inverse fidèle vers les identifiants d’acquisition.

Les recherches plus anciennes portent moins de traces.

Certaines parties de la configuration du modèle ne sont pas encore persistées avec la même discipline que la méthode et la preuve.

Cette imperfection m’a appris quelque chose d’utile.

L’auditabilité n’est pas une fonction.

C’est un empilement.


Auditable n’est pas reproductible

Nous avons aussi découvert que le mot reproductible recouvre plusieurs idées très différentes.

Supposez que je conserve :

  • les preuves structurées ;
  • la version de la méthode ;
  • la logique de notation ;
  • la configuration.

Si je verse ces mêmes entrées dans la même fonction de notation déterministe, je reproduis la note.

C’est la reproductibilité computationnelle.

Imaginez maintenant que je relance la recherche de zéro, demain.

Le fournisseur de recherche peut renvoyer d’autres résultats.

Un site peut avoir changé.

Un article peut avoir disparu.

Le collecteur peut voir un autre contenu.

Une source nouvelle peut avoir été publiée.

Le modèle peut classer autrement un passage ambigu.

C’est la reproductibilité de la recherche.

Ce n’est pas la même chose.

Une trace peut conserver ce qui s’est passé lors de l’exécution d’origine :

Query
  ↓
Search result
  ↓
Selected source
  ↓
Fetch attempt
  ↓
Retrieved content
  ↓
Evidence

Cela rend la recherche plus auditable.

Cela ne garantit pas qu’en recommençant demain on recréera le même univers de preuves.

D’où une autre distinction :

Une trace rend la recherche auditable. Elle ne la rend pas rejouable.

Cela pèse énormément dès que l’IA entre dans des décisions régulées, ou de type fiduciaire.

Imaginez devoir défendre une recommandation deux ans plus tard.

« Nous avons redemandé au modèle ; il a produit à peu près la même réponse » n’est pas une piste d’audit.

On veut savoir ce que le système a vu alors.

Quelles recherches ont été lancées.

Quelles sources ont été retenues.

Quels documents ont été collectés.

Quelles affirmations ont été extraites.

Quelle version de méthode a été appliquée.

Quelle preuve contredisait la conclusion.

Quelles hypothèses sont restées ouvertes.

Quel modèle, quelle configuration, ont participé.

C’est plus près de la garde des preuves que de l’historique d’un chatbot.


La confiance n’est pas celle qu’on croyait

Puis est venue la confiance.

Presque chaque interface d’IA veut désormais un score de confiance.

Cela rassure.

Confidence: 92%.

Charmant.

Mais 92 % de quoi ?

Dans le système que je construis, la confiance en production n’est pas le modèle qui déclare à quel point il se sent sûr.

Les indices de confiance fournis par le modèle sont, à dessein, écartés.

La confiance se calcule à partir de propriétés plus tangibles : nature des sources, récence, corroboration, qualité de la collecte, preuves en conflit.

C’est utile.

Ce n’est toujours pas la probabilité que la conclusion soit juste.

Et le construire a mis au jour l’un des problèmes les plus intéressants de tout ce domaine.

Un système peut être très confiant quant aux preuves qu’il a trouvées, tout en ignorant des preuves importantes qu’il n’a pas su trouver.

Imaginez quatre excellentes sources indépendantes qui soutiennent la proposition X.

Ma confiance dans ces sources peut, raisonnablement, être élevée.

Imaginez maintenant que ma découverte ait, de façon systématique, manqué six sources tout aussi fortes qui contredisent X.

Rien, dans la confiance portée à la preuve trouvée, ne dit nécessairement la complétude de l’univers des preuves.

Donc :

La confiance dans la preuve n’est pas la confiance dans la couverture de l’univers des preuves.

La distinction pèse surtout lorsqu’un système affirme :

« Nous n’avons trouvé aucune preuve de X. »

Cette phrase peut vouloir dire des choses radicalement différentes.

Peut-être que X n’existe vraiment pas.

Peut-être que la recherche a été exhaustive.

Peut-être qu’elle a été médiocre.

Peut-être que l’information pertinente existe dans une autre langue.

Peut-être qu’elle est derrière un péage.

Peut-être que personne ne l’a publiée.

Peut-être que la terminologie du système était mauvaise.

Peut-être que la preuve a disparu du web.

L’absence de preuve n’est pas la preuve de l’absence.

Notre système traite déjà avec prudence beaucoup d’affirmations d’absence. Nous n’avons pas résolu le problème épistémique plus large.

Je pense de plus en plus que les futurs systèmes d’IA à conséquences devront représenter au moins trois notions distinctes :

Confiance dans la preuve Quelle est la force de ce que nous avons ?

Couverture de la preuve Avec quelle exhaustivité avons-nous parcouru l’espace pertinent ?

Confiance dans la conclusion Compte tenu des deux, à quel point la conclusion est-elle défendable ?

Ce n’est pas le même nombre.


Les preuves qui contredisent

Il y a une autre asymétrie.

La plupart des systèmes de recherche savent très bien demander :

Quelle preuve soutient cette proposition ?

Ils sont moins naturellement faits pour demander :

Qu’est-ce qui nous prouverait que nous avons tort ?

Cela compte, parce que les modèles de langage excellent à tisser un récit cohérent à partir du matériau disponible.

Dès qu’une conclusion émerge, tout l’aval peut commencer à s’organiser autour d’elle.

Notre plateforme actuelle détecte une polarité contradictoire lorsque des preuves opposées apparaissent.

Elle conserve les preuves en conflit.

Certaines composantes analytiques cherchent activement des événements négatifs : procès, controverses, questions réglementaires.

Mais une collecte adverse obligatoire n’est pas encore une propriété structurelle de chaque chemin de recherche.

La distinction compte.

Détecter des contradictions n’est pas la même chose que les chercher.

Un système de recherche fiduciaire devrait probablement faire les deux.

Si la conclusion qui émerge est positive, demandez quel est le dossier négatif le plus fort.

Si elle est négative, cherchez une réfutation crédible.

Si les affirmations de l’entreprise dominent le dossier, cherchez une confirmation indépendante.

Si chaque source remonte à un seul rapport sous-jacent, traitez cinq URL comme un seul événement d’information.

Ce n’est pas seulement une meilleure pratique de recherche.

C’est une défense d’architecture contre le biais de confirmation.


Six agents ne font pas un tribunal

Puis il y a la fascination du moment pour les systèmes multi-agents.

Agent chercheur.

Agent critique.

Agent risque.

Agent juge.

Agent conformité.

Agent superviseur.

Cela sonne, de façon rassurante, comme une institution.

J’emploie moi-même plusieurs agents.

Les construire m’a appris à me méfier de ce que le mot agent implique.

Dans la plateforme, des agents différents tiennent des étapes différentes du flux.

L’un interprète la question de recherche.

D’autres rassemblent et extraient les preuves.

Un autre synthétise les résultats.

Un autre produit le récit analytique.

Cette modularité est utile.

Elle isole.

Elle clarifie les responsabilités.

Elle permet à une partie du système de faillir sans nécessairement détruire toute l’exécution.

Mais ces agents partagent souvent les mêmes preuves.

Ils opèrent sous le même orchestrateur.

Ils peuvent s’appuyer sur la même infrastructure de modèles.

La sortie de l’un devient le contexte de l’autre.

Ce n’est pas, nécessairement, de l’indépendance.

Donc :

Plusieurs agents, ce n’est pas plusieurs autorités indépendantes.

Et :

Séparer les consignes, ce n’est pas séparer les pouvoirs.

Si un modèle découvre les preuves, une autre invocation du même modèle, pour l’essentiel, les extrait, une troisième voit le même contexte et le critique, une quatrième rend le jugement final, on a peut-être décomposé le flux de travail de façon utile.

On n’a pas nécessairement créé d’indépendance épistémique.

La vraie indépendance peut exiger d’autres frontières d’information.

D’autres chemins d’acquisition.

D’autres méthodes.

D’autres familles de modèles.

Des autorités déterministes.

Des objectifs adverses.

Une revue humaine.

Ou une combinaison de tout cela.

La leçon n’est pas que les systèmes multi-agents ne servent à rien.

C’est que le vocabulaire institutionnel peut donner à un couplage technique l’apparence trompeuse de l’indépendance.


Séparation épistémique des pouvoirs

Et c’est là que le travail de Nay m’a mené plus loin que je ne l’attendais.

Nay demande ce que l’ingénierie de l’IA pourrait apprendre des standards juridiques.

Peut-être faudrait-il emprunter autre chose aux systèmes juridiques.

L’architecture institutionnelle.

En général, un système juridique ne donne pas à un seul acteur le pouvoir sans limite de :

découvrir les preuves,

trancher leur recevabilité,

écrire les règles,

les interpréter,

juger le litige,

imposer l’issue,

et examiner l’appel.

On sépare les pouvoirs parce que les acteurs sont faillibles.

C’est tout l’enjeu.

Pas parce que chaque juge serait malveillant.

Pas parce que chaque procureur serait incompétent.

Pas parce qu’on ne pourrait pas se fier aux législateurs.

Parce que l’autorité concentrée agrandit l’erreur.

L’IA à conséquences peut avoir besoin d’un principe analogue.

J’ai commencé à l’appeler :

Séparation épistémique des pouvoirs

Un système à conséquences devrait se méfier extrêmement de laisser la même composante probabiliste contrôler tout ce qui suit.

Découverte

Quelle information entre dans le système ?

Garde des preuves

Qu’est-ce qui a réellement été collecté ?

Extraction

Que disent, soi-disant, les sources ?

Méthodologie

Comment évaluer les preuves ?

Jugement

Quelle conclusion s’ensuit ?

Confiance

Quelle certitude le système a-t-il le droit de revendiquer ?

Explication

Comment la conclusion est-elle présentée à l’humain ?

Vérification

Qui contrôle si le raisonnement était juste ?

Autorité

Qui décide si le résultat devient à conséquences ?

La plateforme que je construis sépare déjà, à dessein, une partie de ces responsabilités.

Les méthodes sont versionnées et liées aux exécutions de recherche.

Les preuves passent une validation déterministe.

La notation numérique se fait hors du modèle.

La confiance se calcule hors du modèle.

Les traces conservent une part substantielle du processus d’acquisition.

Les recommandations narratives sont contraintes par des résultats calculés : elles n’ont pas le droit d’inventer leurs propres notes.

Mais la séparation est incomplète.

L’extraction reste probabiliste.

La découverte détermine encore l’univers que le système a le droit de voir.

Le récit peut encore afficher plus de certitude que les preuves ne le justifient.

La collecte adverse n’est pas encore structurelle partout.

La provenance du modèle et des consignes peut s’améliorer.

L’autorité humaine est plus forte au début du processus qu’à la conclusion finale.

La vérification indépendante reste un problème d’architecture que nous n’avons pas résolu.

Je tiens cette incomplétude pour utile.

Elle empêche la fiction confortable selon laquelle quelques fonctions déterministes transformeraient soudain une IA probabiliste en institution parfaitement digne de confiance.

Elles ne le font pas.

Chaque frontière que nous avons tracée a révélé, en dessous, une autre couche d’autorité épistémique.

De meilleures consignes ont exposé la collecte.

Une meilleure collecte a exposé la qualité des preuves.

La qualité des preuves a exposé la provenance.

La provenance a exposé la méthode.

La méthode a exposé la reproductibilité.

La reproductibilité a exposé la confiance.

La confiance a exposé la complétude.

Plusieurs agents ont exposé la différence entre modularité et indépendance.

La notation déterministe a exposé les jugements probabilistes qui entraient dans le calcul.

Le problème d’ingénierie n’a cessé de reculer vers l’extérieur.

De la consigne.

Au modèle.

Au pipeline.

À la preuve.

À la méthode.

À la gouvernance.

Et, peut-être, au bout du compte, à quelque chose qui ressemble à une institution.


De la recherche au conseil

Faites encore un pas.

Imaginez une IA qui conseille quelqu’un sur une assurance automobile.

Le client a une famille.

Un véhicule précis.

Un budget.

Une couverture déjà en place.

Un profil de risque.

Des préférences.

Et le système recommande la police A.

La version conversationnelle pourrait dire :

« Au vu de votre situation, je crois que la police A est le meilleur choix pour vous. »

Cela sonne réfléchi.

Cela peut même être juste.

Mais qu’y a-t-il sous cette phrase ?

Imaginez un autre système.

En interne, sa recommandation ressemble davantage à ceci :

Customer facts
      ↓
Eligibility rules
      ↓
Product facts
      ↓
Coverage requirements
      ↓
Suitability methodology
      ↓
Alternatives considered
      ↓
Deterministic assessment
      ↓
Unresolved assumptions
      ↓
Recommendation
      ↓
Explanation
      ↓
Human authority

C’est un autre système vers lequel je travaille.

Là encore, le modèle de langage peut rendre un service extraordinaire.

Il peut tenir la conversation.

Comprendre le langage naturel.

Peut-être un dialecte.

Extraire l’information du client.

Poser des questions de suivi intelligentes.

Expliquer les termes.

Comparer les arbitrages.

Traduire.

Résumer.

Rendre l’échange bien plus accessible que les interfaces financières ou d’assurance habituelles.

Mais, une fois de plus, la question qui compte devient :

Qu’est-ce que le modèle a le droit de décider tout seul ?

Si le système recommande un produit d’assurance plutôt qu’un autre, on devrait pouvoir reconstruire :

quels intérêts du client sont entrés dans la recommandation ;

quelles alternatives ont été examinées ;

quelles contraintes en ont écarté d’autres ;

quelles règles se sont appliquées ;

quelle méthode a produit la comparaison ;

quelles hypothèses restent incertaines ;

quelle information vient du client ;

quelle information vient de la documentation produit ;

et quelle autorité humaine ou institutionnelle porte, au bout du compte, la décision.

Puis demandez :

Quel système mérite d’être dit fiduciaire ?

Celui dont la consigne système dit :

Act in the customer's best interests.

Ou celui qui peut montrer comment les intérêts du client ont contraint ses actes ?


Un comportement fiduciaire dans le modèle

Voilà pourquoi je ne vois pas cet argument comme une contradiction de Nay.

Tout le contraire.

Son travail pointe dans une direction que je trouve de plus en plus convaincante.

Les règles seules ne suffiront pas.

Les langages de programmation seuls ne captureront pas l’ambiguïté des attentes humaines.

Les consignes en langage naturel, seules, n’y suffiront pas non plus.

Les standards juridiques encodent autre chose : le contexte, le précédent, l’interprétation, et les tentatives institutionnelles accumulées d’appliquer des valeurs humaines abstraites à une réalité brouillonne.

La thèse plus large de Nay, Law Informs Code, traite le droit comme un mécanisme par lequel des attentes sociales vagues deviennent des directives plus lisibles.

D’autres chercheurs ont poussé plus loin l’idée d’une IA fiduciaire : identifier le mandant, comprendre ses intérêts, la loyauté, des standards de diligence appropriés — et traduire tout cela dans la conception et l’audit des systèmes.

Ce travail renforce la question d’architecture. Il ne l’affaiblit pas.

Peut-être qu’une IA capable devrait réellement comprendre le devoir de loyauté.

Mais l’architecture devrait aussi rendre difficile de se servir soi-même.

Peut-être devrait-elle comprendre la diligence due.

Mais le système devrait aussi conserver les preuves dont on s’est servi pour l’exercer.

Peut-être devrait-elle raisonner sur les meilleurs intérêts.

Mais la méthode devrait dire clairement quels intérêts on optimise.

Peut-être le modèle devrait-il reconnaître les conflits d’intérêts.

Mais le processus ne devrait pas dépendre exclusivement de sa décision quant à l’existence d’un conflit.

Peut-être devrait-il comprendre l’incertitude.

Mais il ne devrait pas avoir le droit de fabriquer son propre score de confiance, puis de s’en servir pour justifier sa conclusion.

Deux ambitions complémentaires, dès lors :

FIDUCIARY BEHAVIOUR
inside the model

+

FIDUCIARY ARCHITECTURE
around the model

Nous aurons besoin des deux.


La machine fiduciaire doit pouvoir vous dire non

Il y a une autre raison.

Un fiduciaire n’est pas quelqu’un dont le métier est de vous rendre content.

Parfois, servir l’intérêt de quelqu’un exige de dire non.

Les systèmes d’IA ont, ici, une vulnérabilité particulière : l’aide conversationnelle dérive facilement vers l’acquiescement.

L’utilisateur veut une confirmation.

La machine veut aider.

L’utilisateur reformule.

Le modèle trouve le moyen d’accommoder la prémisse.

Dans des situations sans enjeu, c’est agaçant.

Dans un conseil à conséquences, cela peut devenir dangereux.

Une machine fiduciaire ne peut donc pas optimiser pour la seule satisfaction de la conversation.

Ses obligations doivent survivre à la pression de la personne qu’elle sert.

Cela, encore une fois, dépasse la consigne.

Si l’éligibilité est déterministe, on ne flatte pas le modèle pour la faire bouger.

Si la méthode est figée pour l’exécution, le modèle ne peut pas retoucher en silence les pondérations parce que le client n’aime pas le résultat.

Si les affirmations matérielles doivent porter une preuve, la prose persuasive, à elle seule, ne transforme pas la spéculation en appui.

Si les preuves contradictoires sont conservées plutôt qu’écartées, une source gênante ne disparaît pas parce qu’elle abîme le récit.

Si les devoirs applicables sont représentés hors du modèle conversationnel, l’aide ne peut pas les écraser en silence.

Ce ne sont pas des traits de caractère.

Ce sont des contraintes.


La contestabilité

Il y a un concept de plus que je place, de plus en plus, à côté de l’explicabilité.

La contestabilité.

L’explicabilité demande :

Pourquoi le système a-t-il produit cette réponse ?

La contestabilité demande :

Que puis-je faire si je la crois fausse ?

C’est une exigence autrement plus forte.

Puis-je inspecter les preuves ?

Puis-je contester une source ?

Puis-je corriger un fait client ?

Puis-je identifier quelle règle de méthode a pesé sur le résultat ?

Puis-je distinguer l’extraction machine du texte source ?

Puis-je voir les preuves contradictoires ?

Puis-je demander un réexamen ?

Une autre autorité peut-elle revoir la décision ?

Une conclusion antérieure peut-elle être corrigée sans réécrire l’histoire ?

Le système peut-il conserver à la fois le résultat d’origine et la raison du changement ?

La plateforme que je construis n’y est pas encore.

Nous pouvons conserver les preuves.

Nous pouvons reproduire des calculs déterministes à partir d’entrées structurées.

Nous pouvons retracer une part substantielle d’une exécution de recherche.

Mais un flux de premier ordre, par lequel un humain conteste formellement une conclusion à conséquences, n’existe pas encore.

Ce manque a aiguisé mon intérêt pour la contestabilité.

Parce qu’une explication sans recours peut n’être qu’une justification magnifiquement mise en page.

Une machine peut s’expliquer parfaitement — et avoir tort.

La vraie question est de savoir si quelque chose peut la mettre en cause.


L’autorité humaine

Cela change aussi la façon dont j’entends l’humain dans la boucle.

La formule est devenue presque cérémonielle.

Placez un humain quelque part dans le processus, et le système serait soudain responsable.

Mais où ?

Avant le modèle ?

Après le modèle ?

Seulement lorsque la confiance est basse ?

Seulement lorsqu’il y a un échec ?

L’humain peut-il changer le résultat ?

Peut-il inspecter les preuves ?

Comprend-il la méthode ?

L’interface invite-t-elle à une revue réelle, ou n’offre-t-elle qu’un bouton Approve sous une recommandation éloquente ?

Dans le système que je construis, l’autorité humaine est aujourd’hui la plus forte au début.

Une personne choisit ou approuve la question de recherche et la méthode.

La machine mène ensuite une recherche et une analyse autonomes substantielles.

Le rapport revient à un lecteur humain.

C’est un contrôle humain réel.

Ce n’est pas une porte de revue institutionnelle sur chaque conclusion à conséquences.

Cela pèse surtout lorsqu’on passe de la recherche au conseil.

L’humain dans la boucle ne doit pas être le dernier composant biologique d’un pipeline autrement opaque.

L’autorité humaine se conçoit aussi soigneusement que l’autorité de la machine.


La confiance est peut-être la mauvaise cible

Depuis des années, on parle d’IA digne de confiance.

La formule se comprend.

Je commence à me demander si la confiance est vraiment la bonne cible d’ingénierie.

Regardez d’autres systèmes à conséquences.

La sécurité aérienne ne repose pas sur l’hypothèse que chaque pilote serait incapable d’erreur.

Les contrôles financiers n’assument pas que chaque employé soit incorruptible.

Les tribunaux n’assument pas que chaque juge soit infaillible.

La science n’assume pas que chaque chercheur soit sans biais.

Les infrastructures critiques n’assument pas que chaque composant se comportera toujours correctement.

Nous construisons des institutions autour de la faillibilité.

Nous séparons les responsabilités.

Nous enregistrons les actes.

Nous conservons les preuves.

Nous exigeons la reproductibilité là où c’est possible.

Nous créons une revue indépendante.

Nous exposons les conflits.

Nous versionnons les règles.

Nous auditons les procédures.

Nous permettons la contestation.

Nous enquêtons sur l’échec.

Nous construisons des redondances.

L’intelligence artificielle ne devrait pas échapper à cette pensée au seul motif que son raisonnement impressionne.

Sa fluidité, au contraire, rend ces garde-fous plus nécessaires.

Un système qui se trompe maladroitement invite à l’inspection.

Un système qui se trompe avec élégance invite à la croyance.


La machine fiduciaire

L’intuition centrale de Nay mérite d’être prise au sérieux.

Les standards juridiques peuvent effectivement devenir l’un des mécanismes par lesquels nous communiquons à l’intelligence artificielle des objectifs complexes et mal spécifiés.

Enseigner aux machines quelque chose du devoir fiduciaire pourrait s’avérer d’une grande valeur.

Mais l’étape suivante, je le soupçonne, est architecturale.

Nous devons continuer à demander :

L’intelligence artificielle peut-elle comprendre le devoir fiduciaire ?

Et :

Les standards juridiques peuvent-ils améliorer le comportement des agents artificiels ?

Mais il faut y ajouter une autre famille de questions.

Comment construire des systèmes où le comportement fiduciaire reste inspectable lorsque le modèle échoue ?

Comment distribuer l’autorité épistémique ?

Comment conserver les preuves ?

Comment distinguer une source d’une affirmation, et une affirmation d’un fait ?

Comment séparer le jugement de l’explication ?

Comment distinguer la confiance de la couverture ?

Comment chercher activement la preuve qui pourrait montrer que notre conclusion est fausse ?

Comment rendre les décisions contestables ?

Comment empêcher six agents de devenir six copies de la même erreur ?

Comment déterminer qui, au bout du compte, a l’autorité ?

Ce ne sont pas des arguments contre des modèles de plus en plus capables.

Ce sont des conséquences de modèles de plus en plus capables.

Plus les machines deviennent bonnes, plus les responsabilités que nous leur déléguerons seront lourdes.

Et plus cette délégation pèse, moins

« the model usually understands what we mean »

tiendra comme principe de conception institutionnelle.

Peut-être l’avenir de l’IA fiduciaire dépend-il donc de deux accomplissements distincts.

Enseigner aux machines quelque chose des devoirs que nous attendons d’elles.

Et construire autour d’elles des systèmes qui ne s’effondrent pas lorsqu’elles les comprennent de travers.

Le premier est un problème de modèle.

Le second est un problème d’architecture.

À terme, ce peut être un problème d’institution.

C’est la distinction entre un modèle capable de raisonner sur un comportement fiduciaire —

et une machine fiduciaire.

Ne construisez pas une machine à laquelle il faut faire confiance.

Construisez-en une dont on peut vérifier le travail.


Sources

  1. John J. Nay — Large Language Models as Fiduciaries: A Case Study Toward Robustly Communicating With Artificial Intelligence Through Legal Standards Le papier d’origine de Nay : les standards fiduciaires comme étude de cas pour communiquer à des modèles de langage des objectifs mal spécifiés. arXiv: 2301.10095

  2. John J. Nay — Law Informs Code: A Legal Informatics Approach to Aligning Artificial Intelligence with Humans Développement plus large de l’idée : le droit fournit une information structurée sur les valeurs humaines, les standards et le comportement attendu, utile pour aligner des systèmes artificiels. Northwestern Journal of Technology and Intellectual Property

  3. John J. Nay et al. — Large Language Models as Tax Attorneys: A Case Study in Legal Capabilities Emergence Travail empirique connexe : raisonnement juridique, recherche d’autorité juridique, et limites des modèles de langage face à l’expertise spécialisée. arXiv: 2306.07075

  4. Sebastian Benthall & David Shekman — Designing Fiduciary Artificial Intelligence Les principes fiduciaires comme critères possibles de conception et d’audit : identification des mandants, des intérêts, loyauté, diligence appropriée. arXiv: 2308.02435

  5. UK Financial Conduct Authority — Artificial Intelligence approach Matériel actuel de la FCA sur l’IA dans les services financiers, la responsabilité, la gouvernance, et le rapport entre analyse automatisée et jugement humain. Financial Conduct Authority — AI

  6. Alpha Architect — article discussing LLMs and fiduciary reasoning L’article qui m’a ramené au travail de Nay, pour le relire à l’aune des systèmes que je construis. Alpha Architect — LLM Fiduciary

  7. Internal Architecture & Methodology Audit — Fiduciary Machine Architecture & Methodology Audit, 10 August 2026 Audit en lecture seule de la plateforme de recherche que je construis : provenance des preuves, frontières déterministes et probabilistes, versionnement des méthodes, notation, confiance, traces de recherche, traitement des contradictions, reproductibilité, indépendance des agents, autorité humaine. C’est la base des observations d’ingénierie de ce volume. Ce n’est pas une source publique.