Architecture institutionnelle d'un tiers de confiance IA

Pourquoi un tiers, et pas simplement un bon système#

Une architecture d'IA réglementée peut être irréprochable techniquement et rester inutilisable devant un contrôle. La raison est structurelle : l'opérateur ne peut pas être son propre certificateur.

Tant que la même entité produit les artefacts, tient le registre, date les événements et délivre les attestations, l'auditeur n'a qu'une seule chose à examiner — la parole de cette entité. Peu importe la qualité des mécanismes : la question « qu'est-ce qui vous empêche de tout refaire ? » n'a pas de réponse satisfaisante.

C'est un problème que les institutions humaines ont résolu depuis longtemps, et toujours de la même façon : en séparant les rôles. Le notaire n'est pas partie au contrat. Le commissaire aux comptes n'est pas le directeur financier. L'organisme de certification n'est pas le fabricant. Cette séparation n'est pas une politesse administrative : c'est ce qui rend un acte opposable.

Un tiers de confiance pour l'IA réglementée répond donc à une question institutionnelle avant d'être technique : quelles fonctions doivent sortir du périmètre de l'opérateur pour que ses preuves vaillent quelque chose ? Cet article décrit les sept que nous avons identifiées, la séparation des pouvoirs qui les gouverne, et le test le plus dur — ce qui reste vrai si le tiers lui-même disparaît.

Les sept fonctions d'un registre de confiance#

Nous exploitons un service dédié, distinct du plan d'exécution, dont la seule raison d'être est de tenir ce que l'opérateur ne peut pas tenir seul. Sept fonctions, chacune répondant à une question qu'un auditeur ou un acquéreur finira par poser.

1. L'enregistrement des publications. Chaque artefact scellé est déclaré : son identifiant, son émetteur, sa version, son empreinte, son régime de scellement. C'est l'équivalent d'un dépôt : l'objet existe désormais ailleurs que chez celui qui l'a produit, à une date qu'il ne contrôle pas.

2. Le contrôle de similarité. Avant d'enregistrer une publication destinée à être cédée en exclusivité, le registre compare l'artefact à ceux déjà déposés. L'objectif est précis : empêcher qu'un même savoir-faire soit vendu deux fois comme exclusif. Sans ce contrôle, l'exclusivité serait une affirmation commerciale ; avec lui, elle devient une propriété vérifiable.

3. L'émission d'instances cédées. Une cession n'est pas un transfert de fichier : c'est la création d'une instance nominative, enveloppée pour un acquéreur désigné, inscrite au registre. C'est ce qui distingue une vente d'une copie.

4. La chaîne de possession. Chaque transfert est enregistré, dans l'ordre, sans rupture. C'est la fonction la plus prosaïque et la plus décisive en cas de litige : pouvoir répondre à « qui détenait cet actif, à quelle date, et de qui le tenait-il ? ». Une chaîne de possession interrompue vaut, juridiquement, une chaîne absente.

5. Les certificats co-signés. Pour les cessions les plus engageantes, le registre produit un certificat signé conjointement — par l'émetteur et par le tiers. Une signature unique atteste d'une intention ; deux signatures indépendantes attestent d'un accord. La différence apparaît le jour où l'une des deux parties change de version.

6. La liste de révocation. Un droit accordé doit pouvoir être retiré : licence expirée, cession annulée, artefact compromis. Cette liste est publiée et distribuée, de sorte que la révocation ne dépende pas d'un appel au service au moment de l'usage — un mécanisme qui échouerait précisément quand le réseau manque.

7. Le dossier de preuve. Enfin, le registre agrège ce qu'un auditeur demandera : déclarations signées, preuves d'inclusion, reçus d'ancrage, historique des transferts. Exportable, autoportant, vérifiable sans compte.

La séparation des pouvoirs#

Les sept fonctions ne valent que si personne ne les cumule toutes. Quatre rôles, avec des frontières nettes — et le fait qu'ils soient techniquement distincts est ce qui les rend crédibles.

L'émetteur produit et scelle. Il détient une clé de signature, il engage sa responsabilité, il ne peut rien effacer.

Le gouverneur décide des politiques : classes de risque, quotas, seuils, portées autorisées, coupure d'urgence. Il ne signe pas les artefacts. Cette séparation évite la situation la plus courante — celle où la personne qui produit décide aussi de ce qui est autorisé.

L'auditeur lit, et ne peut que lire. Son accès porte sur les journaux, les registres de transparence et les dossiers de preuve, en lecture seule. Un droit de lecture qui inclut la possibilité d'écrire n'est pas un droit d'audit.

Le contre-signataire intervient sur les actes les plus engageants — cessions privées, transferts de propriété critiques. Il est extérieur à l'organisation : notaire, avocat. Sa fonction n'est pas technique mais juridique : rendre l'acte opposable devant un tiers qui n'a aucune raison de faire confiance aux deux parties.

Un cinquième rôle mérite d'être mentionné parce qu'il est souvent absent : celui qui peut relever une classification. Dans notre modèle, la personne responsable de la protection des données peut requalifier un système à la hausse — passer un usage de « limité » à « haut risque » — mais personne ne peut le requalifier à la baisse sans trace. L'asymétrie est volontaire : la prudence doit être plus facile que le laxisme.

Le problème de la clé unique#

Une architecture de confiance qui repose sur une seule clé privée repose sur une seule personne, un seul module matériel, un seul vendredi soir.

Nous utilisons donc, pour les régimes engageants, des signatures à seuil : la clé n'existe jamais en un seul endroit. Elle est répartie en parts lors d'une cérémonie initiale tenue hors ligne, et produire une signature exige la participation d'un nombre minimal de porteurs. Les parts ne sont jamais réunies : le protocole procède par contributions partielles, en deux tours.

Trois conséquences institutionnelles en découlent, et ce sont elles qui comptent.

Compromettre un module ne suffit plus. Il faut une collusion entre plusieurs porteurs, ce qui déplace la sécurité d'un problème technique vers un problème organisationnel — et les organisations savent gérer les collusions depuis des siècles : séparation géographique, séparation hiérarchique, porteurs externes.

Le départ d'une personne ne bloque rien. Un seuil de trois sur cinq survit à deux absences. Une clé unique détenue par un administrateur qui quitte l'entreprise est un incident majeur ; une part sur cinq est une formalité.

La vérification reste universelle. La signature produite est indistinguable d'une signature ordinaire : n'importe quel vérificateur standard la contrôle, sans rien savoir du dispositif. C'est ce qui rend le mécanisme déployable — une garantie vérifiable seulement avec nos outils ne serait vérifiable par personne d'utile.

Les niveaux de vérification d'identité#

Une signature dit quelle clé a signé. Elle ne dit pas qui détient cette clé. C'est la lacune que comble la vérification d'identité, et elle est graduée — parce que toutes les responsabilités ne se valent pas.

Le niveau élémentaire établit qu'un compte existe et qu'un contact est joignable. Suffisant pour publier un gabarit ouvert, insuffisant pour engager quiconque.

Le niveau substantiel vérifie l'existence juridique de l'entité et le pouvoir de la personne qui signe pour elle. C'est le seuil raisonnable pour céder un actif ou publier un artefact destiné à des tiers.

Le niveau qualifié s'appuie sur les dispositifs d'identité reconnus par la réglementation. Il devient nécessaire quand l'acte doit être opposable devant une autorité, ou quand le secteur l'impose.

La règle que nous appliquons est proportionnelle : le niveau d'identité exigé de l'émetteur croît avec ce que l'artefact peut engager. Un agent qui rédige des notes internes ne demande rien de particulier ; un agent dont les décisions affectent des personnes suppose un émetteur identifié à un niveau élevé, parce qu'il faudra bien, en cas de litige, savoir qui répond.

Cette gradation évite le piège symétrique des architectures de confiance : soit tout le monde est vérifié au maximum, et rien ne se publie plus, soit personne ne l'est, et les signatures ne désignent personne.

Comment on met cela en place, dans l'ordre#

L'ordre compte, parce que chaque étape rend la suivante possible — et parce que se tromper d'ordre produit un dispositif qui a l'air complet sans l'être.

D'abord le registre. Enregistrer les publications avec leur empreinte et leur émetteur, avant toute autre chose. C'est la brique qui donne un inventaire, et un inventaire est le préalable à toute gouvernance : on ne gouverne pas ce qu'on n'a pas listé.

Ensuite les rôles. Séparer émission, gouvernance et audit — au minimum dans les droits d'accès, idéalement dans les personnes. Cette étape est organisationnelle et se heurte au fait que, dans une petite structure, la même personne tient souvent les trois. La réponse honnête est alors de séparer ce qui peut l'être et de documenter ce qui ne l'est pas, plutôt que d'afficher une séparation fictive.

Puis la cérémonie. Répartir les parts de clé, hors ligne, avec les porteurs identifiés. À faire une fois, correctement, en le documentant.

Puis l'ancrage. Déposer les têtes de journal sur des systèmes externes, avec la fréquence choisie en connaissance du coût.

Enfin la répétition d'audit. L'étape que presque personne ne prévoit : demander à quelqu'un d'extérieur de vérifier un dossier sans aide. C'est le seul moyen de découvrir ce qui manque avant que ce ne soit un contrôle réel qui le découvre pour vous.

Le test qui compte : la survie du tiers#

Voici la question que nous posons à notre propre architecture, et que vous devriez poser à tout fournisseur de confiance : que reste-t-il de vos preuves si votre service ferme définitivement demain ?

La plupart des réponses tournent court, parce que la validité des preuves dépend d'une consultation du service — vérification en ligne, liste de révocation interrogée à chaque usage, attestation délivrée à la demande. Ce sont des architectures où le tiers de confiance est aussi un point de défaillance unique, ce qui est précisément ce qu'un tiers de confiance devrait éliminer.

Notre réponse tient en quatre propriétés, chacune vérifiable indépendamment de nous.

Les signatures se recalculent localement, avec des primitives standards : aucune interrogation d'un service n'est nécessaire pour établir qu'un artefact est authentique.

Les dates viennent de l'extérieur : les têtes de journal sont déposées sur des systèmes publics indépendants. Si nous disparaissons, ces dépôts subsistent chez des tiers que nous ne contrôlons pas.

La liste de révocation est distribuée : elle est publiée et se conserve localement, plutôt qu'interrogée au moment de l'usage. Une révocation prononcée avant notre disparition reste opposable après.

Les dossiers de preuve sont autoportants : ils contiennent tout ce qu'il faut pour être vérifiés, et sont conservés par leur destinataire, pas par nous.

Autrement dit, notre rôle est de produire des preuves qui n'ont plus besoin de nous. Une infrastructure de confiance dont la valeur dépend de sa propre survie a mal compris sa fonction.

Ce que le tiers ne doit surtout pas faire#

Une architecture institutionnelle se définit autant par ses interdits. Trois tentations, qui paraissent toutes raisonnables et qui détruisent la valeur du dispositif.

Détenir les clés de ses clients. Un tiers qui conserve les clés privées de ceux qu'il certifie peut signer à leur place. Le confort d'usage est réel — plus de clé à perdre — et le prix est la disparition de la responsabilité : aucune signature ne prouve plus rien sur son auteur. Les parts de clé doivent rester chez leur porteur, quitte à ce que la perte soit possible.

Redéclarer les garde-fous dans les applications. C'est l'erreur d'architecture la plus fréquente, et la plus discrète. Une application cliente qui réimplémente les portées, les quotas ou la coupure d'urgence crée une seconde source de vérité — et deux sources de vérité en gouvernance signifient qu'aucune n'est fiable. Les droits s'ancrent en amont, dans l'artefact et le registre ; l'application les subit, elle ne les redéfinit pas.

Accepter un mécanisme de repli silencieux. Un ancrage simulé, une attestation factice, un horodatage local : indispensables en développement, catastrophiques s'ils survivent en production. Notre règle est un refus de démarrage, pas un avertissement. Un dossier de preuve constitué avec des simulateurs ressemble en tout point à un vrai dossier — jusqu'au jour où il faut s'en servir.

Ce que cela coûte, honnêtement#

Il serait malhonnête de présenter cette architecture comme gratuite. Elle a trois coûts, et ils sont réels.

Un coût de cérémonie. La répartition initiale des parts de clé se tient hors ligne, avec plusieurs porteurs, et se documente. C'est une opération d'une demi-journée qui ne se délègue pas et qui doit être refaite si la composition change de façon substantielle. Pour une organisation habituée à créer une clé en une commande, le changement de rythme est frappant.

Un coût de latence sur la datation. L'ancrage externe est asynchrone : les têtes sont déposées par lots, à intervalle régulier. La précision temporelle d'une preuve est donc bornée par cet intervalle. Le resserrer coûte plus cher — chaque dépôt a un prix — et c'est le seul véritable arbitrage économique du dispositif.

Un coût de discipline. La séparation des rôles interdit des raccourcis commodes : l'émetteur ne peut pas ajuster une politique, l'auditeur ne peut pas corriger une entrée, une classification ne se rabaisse pas discrètement. Ces frictions sont le dispositif, pas des défauts à contourner — mais il faut les assumer devant des équipes pressées.

En regard, un seul bénéfice, qui justifie l'ensemble : le jour du contrôle ou du litige, la discussion ne porte plus sur la crédibilité de votre parole.

Questions fréquentes#

Un tiers de confiance est-il obligatoire pour exploiter de l'IA ?#

Non. Rien n'oblige à disposer d'un registre externe pour faire fonctionner un système. La question se pose quand l'IA produit des actes qui engagent : décisions opposables à des personnes, artefacts cédés à des clients, obligations réglementaires dans un secteur contrôlé. À ce moment, l'absence de tiers signifie que vous êtes votre propre certificateur — position tenable jusqu'au premier désaccord sérieux.

Peut-on être son propre tiers de confiance ?#

Partiellement, et il faut être lucide sur la limite. Une grande organisation peut internaliser le registre, la séparation des rôles et la signature à seuil : cela protège contre les défaillances internes et les accès non autorisés. Ce qu'elle ne peut pas s'auto-délivrer, c'est l'indépendance de la datation et l'extériorité du contre-signataire. D'où le modèle mixte que nous recommandons : registre chez soi, ancrages et contre-signatures à l'extérieur.

Quelle différence avec un notaire classique ?#

Le notaire authentifie un acte à un instant, avec une force probante reconnue par la loi. Un registre de confiance pour l'IA fait autre chose : il tient une chaîne continue — publications, versions, transferts, révocations — et produit des preuves vérifiables par recalcul, sans intervention humaine. Les deux ne s'opposent pas et se combinent : sur les cessions les plus engageantes, un contre-signataire humain figure dans la licence, précisément parce que la force probante juridique et la vérifiabilité technique sont deux choses distinctes.

Comment une révocation peut-elle fonctionner hors ligne ?#

En distribuant la liste plutôt qu'en la faisant interroger. Chaque environnement conserve une copie de la liste de révocation, mise à jour lorsqu'une connexion est disponible, et l'applique localement. Le compromis est explicite : une révocation prononcée pendant une coupure ne prend effet qu'à la prochaine synchronisation. Le mécanisme inverse — vérifier en ligne à chaque usage — donne une révocation instantanée et un système qui s'arrête dès que le réseau tombe. Pour des environnements isolés, le choix est déjà fait.

Que devient la chaîne de possession si un acquéreur revend ?#

Elle s'allonge. Chaque transfert est enregistré dans l'ordre, avec ses parties et sa date attestée, et l'historique complet reste consultable. C'est ce qui permet, plusieurs cessions plus tard, d'établir qui détient légitimement l'actif et de qui il le tient. Une chaîne interrompue — un transfert non enregistré — crée un trou impossible à combler après coup, exactement comme dans une chaîne de titres immobiliers.

Cette architecture est-elle spécifique à l'IA ?#

Non, et c'est plutôt rassurant. Les mécanismes viennent d'univers éprouvés : transparence des certificats du web, provenance de la chaîne logicielle, horodatage d'archivage légal, signatures à seuil de la finance. Ce qui est propre à l'IA, c'est la nature de l'objet certifié — un artefact qui prend des décisions — et donc le besoin de lier l'artefact scellé aux traces de son exécution. Le reste est de l'ingénierie institutionnelle connue, appliquée à un objet nouveau.

À retenir#

Un tiers de confiance pour l'IA réglementée n'est pas un service supplémentaire : c'est une séparation des pouvoirs rendue exécutable. Sept fonctions sortent du périmètre de l'opérateur — enregistrement, contrôle d'exclusivité, émission, chaîne de possession, co-signature, révocation, dossier de preuve. Quatre rôles ne se cumulent pas. La clé de signature n'existe jamais en un seul endroit.

Et le critère de réussite n'est pas la richesse du service : c'est son effaçabilité. Les artefacts restent vérifiables, les dates restent attestées par des systèmes externes, les révocations restent opposables, les dossiers restent autoportants. Un tiers de confiance qui deviendrait indispensable à la validité de ses propres preuves aurait raté sa fonction.

Pour approfondir : les cinq niveaux qui séparent une trace d'une preuve, et ce que le règlement européen attend concrètement.