Résumé technique : ReproScore : Séparation de la préparation et du résultat dans l'évaluation de la reproductibilité des logiciels de recherche

1. Énoncé du problème

Les bibliothèques numériques (par exemple, Zenodo, Software Heritage) conservent des millions d'artefacts logiciels de recherche, mais elles manquent d'une infrastructure évolutive pour évaluer si ces artefacts sont réellement exécutables. Les outils d'évaluation automatisés existants souffrent d'un défaut critique : ils confondent la préparation (l'intégrité statique du dépôt, telle que la présence d'un fichier README ou requirements.txt) avec le résultat (le succès réel de l'exécution).

Cette « confusion préparation–résultat » conduit à une fausse hypothèse selon laquelle un dépôt disposant d'une documentation statique complète est susceptible de fonctionner. En réalité, un dépôt peut présenter des signaux statiques parfaits tout en échouant en raison de conflits de dépendances transitives, de données inaccessibles ou de problèmes d'environnement d'exécution que l'analyse statique ne peut détecter. Les outils actuels reposent soit sur une analyse statique (ignorant l'exécution), soit sur une exécution en bac à sable coûteuse et pilotée par des experts (manquant d'évolutivité). Il existe un besoin d'un cadre qui distingue explicitement le potentiel de reproductibilité (préparation) du résultat réel de l'exécution (résultat), fournissant aux conservateurs des informations diagnostiques plutôt qu'une prédiction binaire de réussite ou d'échec.

2. Méthodologie : L'architecture de ReproScore

ReproScore est un cadre à deux niveaux conçu pour séparer la préparation à la reproductibilité du résultat de l'exécution, en les combinant dans un score composite adaptatif à la couverture.

Niveau 1 : Score de préparation à la reproductibilité (RRS)

Le RRS est une métrique statique, toujours disponible, calculée par une analyse déterministe et basée sur des règles d'un dépôt cloné localement. Elle ne nécessite pas l'exécution du code.

• Structure : Le RRS comprend 26 sous-métriques atomiques regroupées en cinq catégories :
  1. Environnement (E, poids 0,30) : Spécification des dépendances, de la conteneurisation et des versions d'exécution.
  2. Données (A, poids 0,25) : Accessibilité, pointeurs et méthodes d'acquisition des données d'entrée.
  3. Documentation (D, poids 0,20) : Présence d'instructions d'exécution, de points d'entrée et d'exemples d'utilisation.
  4. Portabilité du code (C, poids 0,15) : Absence de chemins absolus, d'identifiants codés en dur et d'imports non résolubles.
  5. Signaux de reproductibilité (S, poids 0,10) : Signaux de déterminisme tels que la gestion des graines et l'ordre d'exécution.
• Logique de notation :
  • Fonction de seuil : Une fonction de seuil en loi de puissance $g(x, \tau, k)$ pénalise de manière non linéaire les scores inférieurs au seuil. Les scores en dessous d'un seuil $\tau$ sont compressés, reflétant une politique de conservation selon laquelle des carences graves (par exemple, une spécification d'environnement manquante) sont disproportionnément dommageables.
  • Pénalités : Des pénalités strictes sont appliquées pour l'absence totale de spécifications d'environnement ou d'artefacts de données ($P_{hard}$), et pour des opérations stochastiques sans gestion de graines ($P_{seed}$).
  • Formule : $RRS = 100 \cdot \sum (w_i \cdot g(x_i)) - \text{pénalités}$.

Niveau 2 : Score de résultat de reproductibilité (ROS)

Le ROS est une métrique optionnelle basée sur l'exécution, calculée lorsqu'un environnement en bac à sable (par exemple, repo2docker, nbconvert) est disponible.

• Composantes : Il agrège jusqu'à six sondes : succès de l'installation ($I$), succès de l'exécution ($X$), déterminisme de la sortie ($\Delta$), taux d'exécution des notebooks ($N$), taux de succès des imports ($E'$) et taux de réussite des tests ($T$).
• Normalisation : Le ROS est une somme pondérée des composantes disponibles, permettant le calcul du score même si seules des données d'exécution partielles sont disponibles.

Score composite (RCS)

Le ReproScore Composite (RCS) combine le RRS et le ROS en fonction de la quantité de preuves d'exécution collectées.

• Poids de couverture ($\alpha$) : Un paramètre qui évolue de 0 (aucune exécution) à un maximum de 0,70. Il garantit que la préparation statique n'est jamais entièrement dominée par les résultats d'exécution, reconnaissant qu'une exécution réussie ne valide ni la documentation ni la portabilité.
• Formule : $RCS = (1 - \alpha) \cdot RRS + \alpha \cdot ROS$. Si aucune donnée d'exécution n'existe, $RCS = RRS$.

Mécanisme de grille communautaire

ReproScore externalise les priorités d'évaluation via un profil YAML versionné. Cela permet à différentes communautés (par exemple, la bioinformatique par rapport aux logiciels généraux) de remplacer les poids par défaut et les seuils de seuil sans modifier le code source. Cela rend les politiques de conservation explicites, auditable et portables entre les institutions.

3. Contributions clés

1. Séparation conceptuelle : Une architecture formelle à deux niveaux (RRS/ROS/RCS) qui découple la préparation statique du résultat d'exécution, abordant la confusion préparation–résultat dans les flux de travail des bibliothèques numériques.
2. Modèle de préparation : Un modèle à 5 catégories et 26 sous-métriques (RRS) avec des pondérations informées par des experts, un seuillage non linéaire et une provenance de preuves au niveau des fichiers.
3. Mécanisme de gouvernance : Un système de grille communautaire permettant de définir les priorités d'évaluation comme des artefacts citables et versionnés.
4. Validation empirique : Une évaluation sur 423 dépôts GitHub (Python/Jupyter) démontrant que la préparation statique discrimine fortement les modes d'échec mais présente une corrélation quasi nulle avec le succès d'exécution binaire.

4. Résultats de l'évaluation

Le cadre a été évalué sur un échantillon stratifié de 423 dépôts issus d'un corpus de vérité terrain, classés en cinq modes d'échec : Succès, Erreurs de dépendance d'installation, Modules manquants, Données manquantes et Erreurs de code.

• Discrimination des modes d'échec : La catégorie Environnement (E) a montré la plus grande capacité à discriminer les modes d'échec (Kruskal-Wallis $H = 96,89, p < 0,001$).
  • Le paradoxe de la détection : Les dépôts avec des erreurs de dépendance d'installation (install_dep) ont obtenu les scores les plus élevés pour l'Environnement (moyenne 22,8) car ils spécifiaient explicitement les environnements, pourtant ils ont échoué en raison de conflits de versions. À l'inverse, les dépôts réussis ont obtenu des scores plus bas (moyenne 10,3) car ils manquaient souvent de spécifications explicites. Cela confirme que le RRS caractérise quel type de problème existe, et non si il réussira.
• Corrélation binaire : La corrélation entre le RRS et le succès d'exécution binaire était quasi nulle ($r_{pb} = -0,014$). Cela quantifie empiriquement l'écart préparation–résultat : un score statique élevé ne prédit pas une exécution réussie.
• Robustesse :
  • Stabilité des poids : Le classement des dépôts est resté stable ($\tau \ge 0,911$) même lorsque les poids étaient perturbés de $\pm 50\%$.
  • Insensibilité du seuil : La fonction de seuil a eu un impact négligeable sur la prédiction binaire (plage AUC $\approx 0,008$), confirmant son rôle d'outil de politique normative plutôt que de mécanisme prédictif.
  • Leave-One-Category-Out : Le retrait des catégories Environnement ou Données a en réalité amélioré l'AUC binaire, prouvant davantage que ces catégories sont conçues pour caractériser les types d'échec, et non pour prédire le succès binaire.
• Validation composite : Dans la validation partielle du ROS, le RCS a correctement réorganisé les dépôts. Par exemple, les dépôts install_dep avaient un RRS modéré (26,8) mais un ROS quasi nul (13,5), résultant en un RCS faible (19,8), reflétant fidèlement leur échec d'exécution malgré l'intégrité statique.

5. Signification et revendications

L'article présente ReproScore comme un instrument diagnostique pour les conservateurs de bibliothèques numériques plutôt que comme un prédicteur binaire de succès.

• Nécessité architecturale : L'étude valide que la séparation de la préparation et du résultat est à la fois nécessaire et non triviale. Les signaux statiques capturent des différences structurelles significatives (par exemple, distinguer un module manquant d'un conflit de version) que les métriques de succès binaire obscurcissent.
• Utilité curatoriale : En fournissant un profil au niveau des catégories, ReproScore permet une remédiation ciblée. Un score d'Environnement faible suggère la nécessité d'un ancrage des dépendances ; un score de Données faible suggère des pointeurs manquants. Cela est plus exploitable qu'un seul score de « reproductibilité ».
• Évolutivité : L'approche statique en premier (RRS) permet aux bibliothèques de trier des millions de dépôts sans le coût computationnel de l'exécution en bac à sable, réservant les ressources d'exécution aux artefacts qui montrent des promesses ou nécessitent une validation spécifique.
• Transparence des politiques : Le mécanisme de grille communautaire transforme les heuristiques de notation de code opaque en politiques auditable et citables, facilitant la comparaison inter-institutionnelle et l'adaptation spécifique au domaine (par exemple, la priorisation de l'accessibilité des données en bioinformatique).

Les auteurs concluent qu'un cadre qui nomme explicitement l'écart entre la préparation et le résultat est plus informatif pour les flux de travail de conservation qu'un cadre qui les fusionne. ReproScore fournit l'infrastructure pour gérer cet écart, soutenant les entités OAIS Ingest et Archival Storage avec des métriques calculables et évolutives.