Vérifiable de quoi ?
Il y a un an, très peu de fournisseurs d'IA décrivaient leurs systèmes comme vérifiables. Aujourd'hui, le mot est partout : confidentialité vérifiable, garde-fous vérifiables, pistes d'audit vérifiables, confiance vérifiable. C'est un progrès. Cela signifie que le marché a accepté que « faites-nous confiance » n'est plus une réponse acceptable.
Cela signifie aussi que le mot, à lui seul, ne vous dit plus grand-chose. Quand un fournisseur dit que son IA est vérifiable, la réponse utile est une question : vérifiable de quoi ?
Trois propriétés distinctes se cachent sous ce seul mot.
Personne n'a pu voir les données. Ni l'exploitant, ni le fournisseur infonuagique, ni les autres parties d'un calcul partagé.
Personne n'a réécrit le dossier par la suite. Ce qui a été consigné à l'époque est ce que vous lisez maintenant.
Ce que dit le dossier s'est réellement produit. Ce modèle, cette version, sur cette entrée, a produit cette sortie.
Chaque propriété tient indépendamment
Ce ne sont pas trois niveaux de la même chose. Ce sont trois garanties différentes, bâties avec des techniques différentes, et n'importe laquelle peut tenir pendant que les autres échouent.
« Caché » s'obtient avec un chiffrement qui persiste pendant le traitement des données, généralement à l'intérieur d'environnements isolés par le matériel. Cela répond à la question que tout responsable de la protection des données pose en premier : quelqu'un a-t-il pu voir ce que nous avons envoyé ?
« Inaltéré » s'obtient avec des signatures, des journaux en ajout seul et des parties indépendantes qui contresignent cet historique à intervalles. Cela répond à une autre question : quelqu'un a-t-il discrètement modifié le dossier depuis ?
« Vrai » est celle qu'on suppose plutôt qu'on établit. Elle demande si le calcul que décrit le dossier a réellement eu lieu comme décrit. Non pas si le dossier a été conservé en sécurité, mais s'il était exact au moment où il a été écrit.
Cette phrase est tout l'argument. La confidentialité protège ce qui est entré. L'inviolabilité protège ce qui a été consigné. Ni l'une ni l'autre, à elle seule, n'établit que ce qui a été consigné est ce qui s'est passé.
Où « vrai » repose habituellement
Quand un système revendique bel et bien la troisième propriété, cela repose le plus souvent sur l'attestation matérielle : le processeur lui-même signe une déclaration sur le code et le modèle chargés. C'est une véritable prouesse technique, et dans la plupart des circonstances, cela fonctionne.
Mais cela déplace la confiance plutôt que de l'éliminer. La garantie dépend désormais de la racine de confiance du fabricant de silicium et de l'intégrité physique de la machine. En octobre 2025, des chercheurs de Georgia Tech et de Purdue ont montré qu'ils pouvaient extraire des clés d'attestation et forger des attestations sur les plateformes d'informatique confidentielle actuelles des grands fabricants de puces, au moyen d'un interposeur mémoire assemblé à partir d'équipement courant. L'attaque nécessite un accès physique au serveur. Les fabricants ont longtemps traité les attaques physiques comme hors de leur modèle de menace. Les deux modèles de menace sont comparés en détail dans l'article d'ingénierie (en anglais) Hardware attestation versus independent re-execution.
Demandez qui a un accès physique à un serveur qui exécute l'IA de votre fournisseur. La réponse est l'exploitant : le centre de données, le nuage, le fournisseur de calcul. Autrement dit, la partie dont vous essayez de vérifier le récit de ce qui a tourné.
Une seconde façon d'établir la vérité
L'alternative ne vous demande pas du tout de faire confiance à la machine. Une partie indépendante, s'exécutant sur une infrastructure distincte, réexécute un échantillon imprévisible du travail et vérifie que le modèle déclaré, sur l'entrée déclarée, produit la sortie déclarée. Le résultat est un reçu signé liant le modèle, l'entrée et la sortie, que n'importe qui peut vérifier plus tard sans faire confiance à l'exploitant.
L'exploitant ne peut pas passer outre par la fraude, parce que la vérification ne s'est jamais appuyée sur quoi que ce soit que le matériel de l'exploitant dit de lui-même.
Elle a ses propres limites, et il faut les énoncer clairement. Le rejeu par échantillon est une dissuasion économique plutôt qu'une preuve de chaque étape : un exploitant qui ne peut pas prédire quel travail sera revérifié trouve que tricher est un pari perdant, mais pas impossible. Et elle ne fait rien pour la confidentialité. Le vérificateur traite l'échantillon qu'il vérifie, sous contrat. Si votre première préoccupation est que personne ne doive jamais voir les données, ce n'est pas la propriété qui y répond.
Les couches s'empilent
Rien de tout cela n'est un plaidoyer pour une technique plutôt qu'une autre. Les trois propriétés répondent à trois craintes différentes, et un déploiement sérieux en contexte réglementé peut avoir besoin des trois : des données gardées cachées pendant le traitement, des dossiers protégés contre la réécriture, et la vérité du calcul établie par quelqu'un qui n'est pas l'exploitant.
Ce qui compte, c'est de savoir quelle propriété vous achetez réellement, et de ne pas laisser une réponse forte à une question tenir lieu de réponse à une autre. La façon dont ces propriétés se composent dans un dossier de preuve, et le mécanisme qui établit chacune, est détaillée dans l'article d'ingénierie (en anglais) Three properties of an AI evidence record.
Trois questions pour tout fournisseur qui dit « vérifiable »
Caché de qui ? Des autres clients, du fournisseur infonuagique, ou du fournisseur lui-même ?
Inaltéré depuis quand, et attesté par qui ? L'historique est-il contresigné par une partie que le fournisseur ne contrôle pas ?
Vrai selon qui ? Et cette partie a-t-elle un accès physique à la machine qui a exécuté la tâche ?
La troisième question est celle qu'un examinateur finira par poser, généralement au sujet d'une seule décision, généralement longtemps après les faits. Il vaut la peine d'en connaître la réponse avant lui.