💻 computer science

Computer Science Conferences Should Require Nonrepudiable Experimental Results

Ce document de position soutient que les conférences d'informatique doivent adopter des protocoles inaltérables et non répudiables pour lier cryptographiquement les résultats expérimentaux rapportés aux calculs réels, en comblant les lacunes actuelles de vérification grâce à un modèle de menace formel et à une implémentation de référence nommée K-Veritas.

Auteurs originaux : Mamadou K. Keita, Christopher Homan

Publié 2026-05-12

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Mamadou K. Keita, Christopher Homan

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Le Problème Central : La Science « Fais-moi confiance, mon pote »

Imaginez que vous êtes juge dans un concours de cuisine. Un chef soumet une recette et prétend que son gâteau est le meilleur au monde. Il vous remet une photo du gâteau et une description écrite de sa préparation.

Le système actuel fonctionne ainsi : le chef signe une liste de contrôle affirmant : « Oui, j'ai utilisé de vrais œufs » et « Oui, je l'ai cuit pendant 30 minutes ». Il pourrait même vous montrer une vidéo de lui en train de cuire le gâteau. Mais voici le hic : le chef contrôle la vidéo. Il aurait pu la monter pour montrer un vrai gâteau alors qu'il vous sert en réalité une découpe en carton. Ou bien, il aurait pu cuire 50 gâteaux, choisir celui qui semblait parfait, et vous dire que c'était le seul qu'il avait fait.

En informatique, plus précisément dans l'apprentissage automatique (IA), c'est exactement ce qui se produit. Les chercheurs soumettent des articles avec des tableaux de chiffres (résultats) et des listes de contrôle. Les relecteurs (les juges) sont occupés et ne peuvent pas relancer les expériences. Ils doivent croire les chiffres sur parole. Les auteurs de cet article soutiennent que ce système est brisé car il repose sur l'honnêteté plutôt que sur la preuve.

La Solution Proposée : Le Reçu « Boîte Noire »

Les auteurs proposent une nouvelle règle pour les conférences d'informatique : la Non-répudiation Expérimentale.

Considérez cela comme un reçu inviolable pour une expérience scientifique.

La Non-répudiation est un terme de sécurité sophistiqué signifiant : « Vous ne pouvez pas nier avoir fait cela, et vous ne pouvez pas modifier la trace ultérieurement. »
L'objectif est de lier les chiffres de l'article au moment exact où l'ordinateur a effectué le travail, d'une manière que l'auteur ne peut ni falsifier ni altérer.

Comment Cela Fonctionnerait (L'Outil « K-Veritas »)

Les auteurs ont construit un outil prototype appelé K-Veritas pour montrer que c'est possible. Voici comment cela fonctionne, en utilisant une métaphore :

Imaginez que le chercheur est un chef et que l'ordinateur est la cuisine.

L'Enveloppe : Au lieu de simplement dire à l'ordinateur de « cuire le gâteau », le chercheur utilise un outil spécial (K-Veritas) qui enveloppe le processus de cuisson.
Le Témoin Silencieux : Cet outil agit comme un témoin silencieux et indépendant debout dans la cuisine. Il ne touche pas aux ingrédients (les données) et ne modifie pas la recette (le code). Il observe simplement.
L'Instantané : Pendant que l'ordinateur travaille, le témoin prend des instantanés de :
- Le code exact utilisé.
- Le temps qu'il a fallu.
- L'électricité et la chaleur utilisées (pour prouver que la machine travaillait réellement dur).
- Les chiffres finaux imprimés par l'ordinateur.
L'Enveloppe Scellée : Une fois l'expérience terminée, le témoin scelle tous ces instantanés dans une « enveloppe » numérique et les signe avec une clé spéciale que seul le témoin possède. Le chercheur n'obtient jamais cette clé.
Le Résultat : Le chercheur soumet son article accompagné de cette enveloppe signée. Les relecteurs de la conférence peuvent ouvrir l'enveloppe et vérifier : « L'ordinateur a-t-il réellement tourné pendant 40 minutes ? Le code correspond-il ? Les chiffres correspondent-ils à ce qui a été imprimé ? »

Si le chercheur tente de modifier un chiffre dans l'article plus tard, le scellé se brise et la signature devient invalide.

Pourquoi les Méthodes Actuelles Échouent

L'article explique pourquoi les « filets de sécurité » actuels ne fonctionnent pas :

Les Listes de Contrôle : Demander à un chef de signer un document affirmant « J'ai utilisé de vrais œufs » ne prouve pas qu'il n'a pas utilisé des œufs en plastique.
Le Partage de Code : Le fait qu'un chef partage la recette ne signifie pas qu'il a cuit le gâteau qu'il a prétendu avoir fait. Il pourrait partager une recette fonctionnelle mais rapporter les résultats d'un autre gâteau, meilleur, qu'il aurait cuit secrètement.
Les Outils de Journalisation : Les outils qui suivent les progrès sont comme un journal écrit par le chef. Si le chef veut cacher une erreur, il peut simplement modifier le journal.
La Pré-inscription : C'est comme si le chef promettait avant de commencer : « Je vais cuire un gâteau au chocolat ». Cela l'empêche de changer de plan, mais cela ne prouve pas qu'il a réellement cuit le gâteau ni que les chiffres qu'il rapporte sont réels.

Le Lien avec la « Fausse Relecture »

L'article fait une comparaison astucieuse :

Les grandes conférences (comme ICML) interdisent désormais aux relecteurs d'utiliser l'IA pour rédiger leurs critiques. Pourquoi ? Parce que la communauté ne peut pas distinguer si une critique est une véritable réflexion humaine ou un faux texte généré par un robot.
Les auteurs soutiennent : Si nous ne pouvons pas faire confiance à une fausse critique, nous ne pouvons certainement pas faire confiance à un faux résultat. Si une critique nécessite une preuve d'humanité, un résultat scientifique nécessite une preuve de calcul.

Ce Que Cet Outil Peut et Ne Peut Pas Faire

Les auteurs sont honnêtes sur les limites de leur outil (K-Veritas) :

Il empêche : La triche avec des éditeurs de texte, la falsification de chiffres, la modification des journaux après coup, ou l'affirmation d'avoir réalisé une expérience massive alors que ce n'est pas le cas.
Il n'empêche pas : Un pirate informatique ultra-sophistiqué capable de tromper le système d'exploitation ou le matériel de l'ordinateur lui-même (comme un faux signal GPS).
Le Compromis : Même s'il n'empêche pas tous les trichages possibles, il augmente le coût de la triche. Actuellement, tricher ne nécessite qu'un éditeur de texte. Avec ce système, il faudrait réellement lancer l'expérience informatique coûteuse ou pirater le cerveau de l'ordinateur.

La Voie à Suivre

Les auteurs ne disent pas que K-Veritas est la réponse finale. Ils le qualifient de « banc d'essai » (prototype). Ils proposent un plan en trois étapes pour la communauté :

Volontaire : Laisser les chercheurs l'utiliser s'ils souhaitent obtenir un badge « Vérifié ».
Attendu : En faire une pratique standard, comme le partage de code le devient.
Obligatoire : À terme, l'exiger pour tous les articles contenant des résultats expérimentaux.

L'Essentiel

La science est bâtie sur la confiance, mais la confiance a besoin de preuves. Cet article soutient que les conférences d'informatique devraient cesser de demander aux chercheurs de « s'il vous plaît, soyez honnêtes » et commencer à exiger des reçus numériques prouvant que les chiffres de l'article proviennent d'une véritable exécution informatique, non altérée. Il s'agit de passer du « Fais-moi confiance » au « Montrez-moi le reçu ».

Résumé Technique : Les Conférences d'Informatique Devraient Exiger des Résultats Expérimentaux Non Réputables

Définition du Problème
L'article identifie un « fossé de vérification » structurel dans les conférences d'informatique, en particulier en apprentissage automatique (ML). Les mesures actuelles de reproductibilité — telles que les listes de contrôle auto-déclarées (par exemple, NeurIPS), l'évaluation facultative des artefacts, les plateformes de journalisation contrôlées par les auteurs (par exemple, Weights & Biases) et la pré-inscription — échouent à lier les résultats numériques rapportés à l'exécution réelle du code qui les a produits. Ces mécanismes vérifient l'intention de divulguer ou l'utilisabilité du code, mais ils ne peuvent pas répondre à la question fondamentale : « La session d'entraînement décrite dans cet article a-t-elle réellement produit les résultats que cet article rapporte ? »

Les auteurs définissent ce mode de défaillance spécifique comme la non-répudiation de l'expérience. Empruntant à la littérature sur la sécurité, ils la définissent comme la propriété selon laquelle un auteur ne peut plus tard modifier, nier ou déformer le registre de ce que son calcul a réellement produit. Le système actuel repose sur la confiance dans l'auto-déclaration, laissant la communauté vulnérable à la fabrication au niveau du texte, à la manipulation des journaux et à la sélection sélective des exécutions favorables.

Méthodologie et Solution Proposée
Pour remédier à cela, les auteurs proposent un protocole pour générer des attestations expérimentales inaltérables et non répudiables des résultats. Le cœur de leur méthodologie est un protocole qui doit satisfaire six propriétés de sécurité spécifiques :

Passivité : L'observateur ne doit pas modifier le calcul.
Aveuglement aux Données : L'observateur ne doit jamais accéder à l'ensemble de données $D$ , garantissant que les données propriétaires restent privées.
Liaison à l'Exécution : Les métriques rapportées doivent être cryptographiquement liées à l'instance d'exécution spécifique, vérifiées via la télémétrie d'exécution (utilisation du CPU/GPU, mémoire).
Preuve de Falsification : Toute modification du rapport (métriques, hyperparamètres, horodatages) doit invalider la signature cryptographique.
Séparation des Clés de l'Auteur : La clé de signature doit être détenue par un service d'attestation indépendant, et non par l'auteur, empêchant ainsi l'auteur de générer des attestations arbitraires.
Vérifiabilité Indépendante : Toute tierce partie doit pouvoir valider l'attestation en utilisant une clé publique sans faire confiance à l'auteur.

Pour démontrer la faisabilité de ce problème, les auteurs ont construit K-Veritas, une implémentation de référence en Go. K-Veritas fonctionne comme un wrapper binaire autonome que les auteurs invoquent via un préfixe de commande (par exemple, kveritas run -- python train.py). Il fonctionne comme suit :

Capture : Il capture stdout/stderr de manière non bloquante, analyse les métriques et hache les fichiers sources avant et après l'exécution.
Télémétrie : Un échantillonneur en arrière-plan enregistre l'utilisation matérielle (temps CPU, mémoire, utilisation GPU) à intervalles réguliers.
Scellage : À la fermeture de la session, il calcule un résumé canonique SHA-256 de l'ensemble de la session (hachages de fichiers, flux stdout, métriques, échantillons matériels).
Signature : Il n'envoie que ce résumé de 64 caractères à un service d'attestation distant. Le service, détenant la clé privée, renvoie une signature RSA-PSS. L'auteur ne voit jamais la clé privée.
Sortie : Le système génère un rapport PDF signé et une archive signée contenant le code source présent lors de l'exécution.

Résultats et Démonstrations
L'article présente deux formes principales de preuves :

L'exercice de la « Table Non Fiable » : Les auteurs démontrent que deux tableaux de résultats — l'un issu d'une exécution réelle et l'autre généré par un modèle de langage pour être plausible — sont indistinguables pour un réviseur humain. Cela illustre que la plausibilité ne remplace pas l'authenticité.
Le banc d'essai K-Veritas : Les auteurs ont exécuté K-Veritas sur deux sessions d'entraînement distinctes : un LSTM Keras synthétique et un RoBERTa-base finetuné sur SST-2. Le système a réussi à capturer :
- Les empreintes matérielles (modèles GPU/CPU).
- La durée d'entraînement et les métriques finales (perte, précision).
- Les hachages du code source et de stdout.
- Un score de « Cohérence Métrique-Matériel (HMC) », qui signale les anomalies (par exemple, une métrique rapportée sans activité matérielle correspondante).
- Des signatures RSA-PSS valides.

Les auteurs notent explicitement que K-Veritas est un banc d'essai, et non une solution aboutie. Il empêche avec succès la falsification occasionnelle et modérée (édition de texte, manipulation de journaux, sélection naïve d'exécutions) mais reconnaît qu'il ne peut pas vaincre des adversaires privilégiés ayant un accès noyau ou micrologiciel (par exemple, l'usurpation de télémétrie au niveau du système d'exploitation).

Contributions Clés

Définition Conceptuelle : L'article définit formellement la « non-répudiation de l'expérience » comme une classe de problèmes distincte, la séparant de la reproductibilité (peut-on la relancer ?) et de la réplicabilité (donne-t-elle le même résultat ?).
Modèle de Menace : Il décrit un modèle de menace complet, distinguant les attaques que les protocoles logiciels peuvent vaincre (fabrication, édition de journaux) de celles qu'ils ne peuvent pas vaincre (compromission du noyau/matériel).
Spécification du Protocole : Il définit les propriétés de sécurité nécessaires pour tout protocole conforme, en insistant sur la séparation de la clé de signature de l'auteur.
Implémentation : Il fournit K-Veritas comme preuve de concept qu'un tel protocole peut être mis en œuvre sans exiger des auteurs qu'ils partagent des données sensibles ou modifient leur logique d'entraînement principale.

Signification et Revendications
L'article soutient que la non-répudiation devrait être traitée comme une exigence de premier ordre pour les conférences d'informatique, similaire à l'interdiction des critiques générées par l'IA à ICML 2025. Les auteurs affirment que tout comme la communauté reconnaît les critiques fabriquées comme une menace nécessitant une intervention politique, les résultats fabriqués devraient être traités avec la même sévérité.

La signification de ce travail réside dans le déplacement du fardeau de la preuve de « faites confiance à l'auteur » vers « vérifiez l'exécution ». Les auteurs proposent un chemin d'adoption en trois phases (Volontaire $\to$ Attendu $\to$ Requis) sur un horizon de 3 à 8 ans. Ils soulignent que, bien que le système ne soit pas parfait contre des adversaires étatiques, il modifie fondamentalement l'économie de la falsification : passant du coût d'un simple éditeur de texte à l'exigence d'exécuter un calcul réel ou de compromettre un noyau.

L'article conclut en appelant à la création d'une organisation indépendante et à but non lucratif pour maintenir la norme, garantissant qu'aucune entité unique ne contrôle la vérification de la légitimité scientifique. Le cadre est présenté comme généralisable au-delà du ML à tout domaine s'appuyant sur des pipelines computationnels pour des affirmations empiriques.