--- title: "Le verrou cryptographique qui remplace « trust me, I ran it »" locale: "fr" url: "https://irz.fr/fr/articles/kveritas-trace-signed-execution-fr" markdown_url: "https://irz.fr/fr/articles/kveritas-trace-signed-execution-fr.md" category: "tech" tags: ["vérification", "recherche", "reproductibilité", "signature"] published_at: "2026-09-05T08:30:00.000Z" author: "Léa Perrin" translation: "https://irz.fr/en/articles/kveritas-trace-signed-execution-en.md" --- # Le verrou cryptographique qui remplace « trust me, I ran it » K-Veritas lie commandes, métriques et rapport dans une trace signée, vérifiable sans relancer l'expérience. Mais la signature prouve moins que ce que le projet laisse entendre — c'est là qu'elle devient intéressante. Un rapport annonce 94 % d'accuracy sur un jeu de test. Le reviewer se demande si ces chiffres viennent vraiment du code joint, ou si quelqu'un les a tapés directement dans le manuscrit. La réponse habituelle ? Relancer l'expérience. Sauf que ça peut prendre des jours, exiger des GPU que personne n'a sous la main, et supposer que vous arrivez à reconstruire l'environnement du labo à l'identique. K-Veritas essaie de couper ce cycle à la racine. Un CLI Go construit avec Cobra, des binaires statiques de quelques mégaoctets, et une ambition : coudre commandes, métriques, environnement et rapport final dans une trace signée cryptographiquement, vérifiable côté serveur ou hors-ligne, sans jamais réexécuter le calcul.[1](https://github.com/27-GROUP/kveritas-go) Les binaires précompilés, CLI et serveur d'attestation compris, sont distribués pour Linux, macOS et Windows.[3](https://github.com/27-GROUP/kveritas-releases) Le projet a déboulé sur Hacker News fin août, et la réception a été franchement hostile.[5](https://news.ycombinator.com/item?id=49505043) « Ça ne prouve rien d'autre que le fait que l'auteur a signé le rapport », résume exe34. La pique tombe presque juste — c'est justement pour ça qu'il vaut la peine de regarder sous le capot. ## Un process qui tourne Le flux de K-Veritas tient en quatre commandes. `kveritas init` démarre une session, qui enregistre un identifiant d'expérience, une empreinte de machine et l'emplacement du projet. `kveritas run -- python train.py` exécute n'importe quelle commande sous surveillance : la durée, le code de sortie, les hachages des fichiers avant et après, le flux stdout et stderr sont capturés pendant l'exécution.[1](https://github.com/27-GROUP/kveritas-go) La capture ne s'arrête pas au contenu des fichiers. Le runner échantillonne la machine environ dix fois par seconde, et enregistre les métriques, les phases et les seeds que le script affiche lui-même dans sa sortie standard. Ce n'est pas une boîte noire qui décide ce qui compte. C'est un protocole de stdout : votre script écrit une ligne du type `KVERITAS_METRIC name=accuracy value=0.94`, et le runner la rattache au run en cours, hachée comme le reste.[1](https://github.com/27-GROUP/kveritas-go) Corollaire à ne pas zapper : votre script doit collaborer. Si la métrique ne passe jamais par la sortie standard, il n'y a rien à signer. La sortie elle-même est hachée intégralement, et chaque événement reconnu est rattaché au run par son numéro de ligne de sortie, si bien qu'une insertion, une suppression ou un réordonnancement est détecté.[1](https://github.com/27-GROUP/kveritas-go) > K-Veritas > **Quatre commandes du run à la preuve** > - Session, empreinte machine, projet.: init > - Exécution surveillée, sorties hachées.: run > - PDF signé, rapports et bundle.: seal > - Vérification hors-ligne ou serveur.: verify > Flux décrit dans le README du dépôt et dans la spec du protocole. ## Des métriques accrochées à une trace Le point délicat de toute attestation d'exécution, c'est de prouver que la métrique affichée vient bien de cette exécution-là, et pas d'une autre. K-Veritas gère cela à deux étages. D'abord une association directe : chaque métrique et chaque claim est enregistré avec le numéro de ligne de sortie où il est apparu, dans la session qui tournait au même moment. La trace et les métriques ne sont pas deux fichiers collés l'un à l'autre ; elles naissent ensemble du même moniteur de processus.[1](https://github.com/27-GROUP/kveritas-go) Ensuite un vérificateur de cohérence d'exécution, baptisé HMCA, volontairement aveugle aux métriques elles-mêmes. Au lieu de regarder si un score est plausible, il compare comment les différents canaux de télémétrie — CPU, mémoire, GPU, activité — co-fluctuent pendant le run.[1](https://github.com/27-GROUP/kveritas-go) L'idée se décrit en une ligne : une vraie exécution fait bouger ses canaux comme une seule chose. Une trace fabriquée, rejouée ou recollée produit des cohérences de télémetrie qui ne tiennent pas ensemble. Si les canaux s'écartent trop, le vérificateur renvoie un avertissement explicite : canaux d'exécution non cohérents, fabrication ou rejeu possibles.[1](https://github.com/27-GROUP/kveritas-go) La prudence, d'ailleurs, n'est pas un slogan : sous un échantillon trop faible, HMCA s'abstient plutôt que d'accuser.[1](https://github.com/27-GROUP/kveritas-go) Un signal statistique, pas une preuve judiciaire. ## Un rapport vérifiable par tous Quand la session est scellée, `kveritas seal` produit un PDF qui reste lisible par un humain. Mais la partie qui compte pour la vérification n'est pas dans le texte affiché : la signature est insérée après la fin du fichier, entre deux marqueurs dédiés, avec la clé publique nécessaire à la contrôler.[1](https://github.com/27-GROUP/kveritas-go) Le mécanisme cryptographique est ce qu'on voit partout : les données de session sont hachées dans un JSON canonique, ce hachage entre dans un payload `data_hash:nonce:signed_at`, et le tout est signé en RSA-PSS-SHA256 avec une clé de 4096 bits.[1](https://github.com/27-GROUP/kveritas-go) Le serveur d'attestation détient la clé privée ; le CLI embarque la clé publique correspondante comme point d'ancrage de confiance.[1](https://github.com/27-GROUP/kveritas-go) Celui qui reçoit le rapport peut donc vérifier deux choses distinctes. La première : le rapport est intègre, personne n'a touché aux données signées. La seconde : la signature provient bien de la clé K-Veritas — ou pas. > **Ce que le rapport peut annoncer** > - Signé avec la clé de confiance K-Veritas, présentée comme point d'ancrage.: VERIFIED > - Signature valide, mais clé fournie par l'auteur : origine non confirmée.: SELF-ATTESTED > - Signature ou données altérées : échec de vérification.: INVALID > Distinction décrite dans le code de verification et la spec du protocole. C'est la nuance qui manquait au commentaire de Hacker News. K-Veritas ne dit pas aux reviewers de faire confiance à l'auteur. Il propose un chemin où la vérification d'origine est possible sans relancer l'expérience — à condition de se reposer sur le serveur d'attestation comme tiers de confiance. D'où la différence entre deux sorties du CLI. Si le rapport est signé avec la clé K-Veritas, la vérification affiche `VERIFIED`. Si l'auteur a signé avec sa propre clé (mode hors-ligne), la sortie affiche `SELF-ATTESTED`, accompagnée d'un texte sans ambiguïté : la signature est valide, mais l'origine du rapport ne peut pas être confirmée, et les résultats doivent être traités comme non vérifiés.[1](https://github.com/27-GROUP/kveritas-go) ## Une preuve d'exécution, pas une preuve de vérité Vient maintenant le piège que le site du projet n'aide pas à éviter. La page d'accueil évoque des résultats « authentiques, reproductibles et honnêtement rapportés ».[2](https://kveritas.org/protocol) La spec du protocole, elle, est plus sobre : K-Veritas enregistre ce qu'une expérience ou un agent a fait, comme preuve signée, pour qu'un reviewer puisse vérifier indépendamment ce qui a tourné et qui l'a fait.[2](https://kveritas.org/protocol) Ce n'est pas la même promesse. Ce que la signature garantit réellement, c'est un enchaînement : une session a démarré sur une machine donnée, une commande précise a été exécutée, les fichiers ont produit certains hachages, les métriques déclarées sont apparues dans la sortie de cette exécution, et le tout a été scellé à un instant signé. Une preuve d'exécution. Pas une preuve que le résultat est correct. Une signature n'empêche pas un jeu de données fuitée, un parseur de métriques trompeur ou un modèle sur-entraîné. Sur ce point, la documentation du projet est honnête : elle précise explicitement que le protocole ne détecte pas certaines formes de contamination train/test, et qu'il ne peut pas à lui seul prouver qu'un jeu d'évaluation privé est équitable — la première limite étant présentée comme un travail futur.[6](https://kveritas.org/docs/benchmarks) Pour reprendre l'exemple du début : le rapport dit 94 %, la trace dit que 94 % est apparu dans une vraie sortie d'une vraie commande, sur une vraie machine, dans une session scellée. Les deux ne se recouvrent pas. Écrire l'un à la place de l'autre, c'est confondre la chaîne de fabrication de la preuve avec la validité scientifique du résultat. ## Ce qui reste à prouver La finesse de la solution tient dans ce qu'elle ne prétend pas couvrir — dès qu'on lit le code plutôt que le site. Trois vérificateurs complètent HMCA. Un certificat de coût de calcul vérifie que les FLOPs déclarés pouvaient physiquement tenir dans la durée, l'énergie et la mémoire observées.[1](https://github.com/27-GROUP/kveritas-go) Ses bornes sont volontairement généreuses : l'idée est de ne jamais accuser un run honnête, pas de coincer les fraudeurs astucieux. En revanche, une déclaration qui annonce une charge monstrueuse sans aucune trace d'utilisation est signalée pour revue.[1](https://github.com/27-GROUP/kveritas-go) Un registre de provenance construit une chaîne de hachages qui lie chaque état des fichiers au précédent — un filigrane tamper-evident de tout ce qui touche au projet —, l'ensemble étant scellé dans la session.[1](https://github.com/27-GROUP/kveritas-go) Et une fonction de vérification de claims croise les chiffres cités dans un manuscrit avec les valeurs enregistrées dans le rapport scellé, pour exhiber les revendications du papier qui n'auraient pas de correspondance signée.[1](https://github.com/27-GROUP/kveritas-go) Même philosophie partout. On ne vérifie pas les éléphants ; on vérifie qu'il y a eu un passage d'éléphant. ## Un public exigeant La discussion Hacker News du 31 août a bien identifié l'essentiel. Plusieurs commentaires exigeants rappellent que la preuve d'exécution « à proprement parler » serait une preuve de calcul vérifiable — exécution dans une enclave matérielle, ou preuve zero-knowledge générée par une machine virtuelle dédiée.[5](https://news.ycombinator.com/item?id=49505043) K-Veritas, lui, se contente de collecter des traces et de les signer. La remarque est juste, mais elle compare un coupé GT à un utilitaire. Les preuves zero-knowledge et les enclaves existent et sont puissantes ; elles sont aussi lourdes à produire, souvent spécialisées par type de calcul, et difficiles à faire adopter aux chercheurs qui écrivent leur script en trois jours. Ce que K-Veritas fabrique, c'est un outil de travail pour la reproduction : il baisse le coût de la vérification d'exécution sans demander au reviewer de tout relancer, et il augmente le coût du mensonge banal (« j'ai lancé mon script, regarde mon papier »). La fraude sophistiquée passe toujours — la preuve reste une attestation de processus, pas une preuve mathématique de contenu. ## Une trace ne remplace pas une relance La question éditoriale sous-jacente est plus intéressante que l'outil lui-même : les artefacts de reproductibilité devraient-ils devenir des preuves cryptographiques ? Les revues et conférences en informatique ont déjà adopté un système de badges d'artefacts, piloté par l'ACM, qui récompense les papiers dont les artefacts sont évalués, disponibles ou validés.[4](https://www.acm.org/publications/policies/artifact-review-and-badging-current) Mais l'évaluation reste humaine, relative et volontaire ; elle dépend du temps et de la bonne volonté des reviewers. K-Veritas propose une alternative plus radicale : transformer la présence attestée des artefacts en une propriété vérifiable automatiquement par n'importe qui, au lieu de dépendre du temps et de la bonne volonté des reviewers.[2](https://kveritas.org/protocol) Ce n'est pas la même chose que la reproduction indépendante — les badges les plus courants (artefacts disponibles, artefacts évalués) ne prouvent pas qu'un autre labo a relancé le code avec succès ; le niveau « résultats validés » passe, lui, par une re-exécution réelle. L'approche de K-Veritas reste un étage intermédiaire utile entre « tape-moi le repo » et « recommence tout à zéro ». Le projet est jeune, et son adoption reste à démontrer : au moment d'écrire ces lignes, sa visibilité publique se limite pour l'essentiel au fil de lancement et aux échanges du dépôt. C'est une impression de terrain, pas une statistique vérifiée. Il n'est pas le premier à essayer, et il ne sera pas le dernier. Sa contribution actuelle est ailleurs : montrer, en code, ce qu'une preuve d'exécution peut raisonnablement contenir, et à quel prix. Pour le reviewer, retenez ceci pour la prochaine fois qu'un rapport affiche `VERIFIED` : regardez d'abord ce qui est exactement signé. Très souvent, ce sera la promesse « cela a été exécuté » — pas « cela est vrai ». Savoir distinguer les deux est toute la différence entre une vérification utile et une confiance aveugle. ## References 1. [27-GROUP/kveritas-go — dépôt principal (README, tests, code)](https://github.com/27-GROUP/kveritas-go) 2. [K-Veritas — spécification du protocole](https://kveritas.org/protocol) 3. [27-GROUP/kveritas-releases — binaires publiés](https://github.com/27-GROUP/kveritas-releases) 4. [ACM — Artifact Review and Badging v1.1](https://www.acm.org/publications/policies/artifact-review-and-badging-current) 5. [Hacker News — Show HN, 31 août 2026](https://news.ycombinator.com/item?id=49505043) 6. [K-Veritas — guide Benchmarking & model evaluation](https://kveritas.org/docs/benchmarks)