Repro Lens : le contrôle de reproductibilité pour les agents ML

Repro Lens est un outil de contrôle de reproductibilité destiné aux agents ML et de codage : il analyse le code à la recherche de risques de reproductibilité, rejoue les expériences et compare les sorties avant et après modification. Son usage principal : vérifier, après avoir modifié du code ML, que les résultats d'expériences n'ont pas été cassés. L'analyse statique ne nécessite que Python 3.11+ et Git, sans dépendance ML ni clé API ; en revanche, le replay d'expériences exige les dépendances propres à l'expérience et doit être déclenché explicitement par vous.

Pour qui ?

• Les ingénieurs ML/chercheurs qui souhaitent vérifier la reproductibilité d'expériences avant et après modification du code, ainsi que les équipes qui configurent un flux d'audit de reproductibilité pour des agents de codage.
• Les utilisateurs qui ne veulent qu'une analyse statique : aucune dépendance ML, aucune clé API ; le code analysé n'est jamais importé ni exécuté, et l'outil produit des résultats statiques avec l'emplacement des fichiers.
• Cas non adaptés : sans environnement Git, aucune des deux méthodes d'installation ne fonctionne ; avec un Python inférieur à 3.11, le vérificateur statique ne peut pas s'exécuter. En dehors de ces prérequis, les sources n'indiquent aucun autre prérequis système ; la prise en charge de plateformes comme Windows n'est pas précisée officiellement.
• Ne rien présumer au-delà des éléments documentés : l'outil ne déclare ni les langages de texte ou de code pris en charge, ni les clients d'agents avec lesquels il fonctionne.

Première tentative en 3 minutes

Prérequis : Python 3.11+, Git et uv installés sur la machine. La voie principale recommandée est une installation à version fixée via uv depuis le dépôt officiel :

uv tool install 'git+https://github.com/00200200/[email protected]'

L'alternative consiste à installer la même URL git avec pip dans un environnement virtuel (Git est également requis) ; il s'agit d'une option secondaire, pas d'une autre entrée principale.

Après l'installation, commencez par une analyse statique à faible risque et en lecture seule : dans votre projet, demandez à l'agent ou au terminal « vérifie si ce fichier présente des risques de reproductibilité connus avec repro-lens check ». L'opération centrale correspondante est check : elle produit des résultats statiques avec l'emplacement des fichiers, et le code analysé n'est jamais importé. Signe de succès : la sortie liste des résultats avec emplacements de fichiers (même une conclusion « aucun risque trouvé » indique que l'exécution a réussi).

Remarque : check est une opération de diagnostic, ce qui signifie uniquement qu'elle n'importe pas le code analysé ; s'il lit ou écrit des fichiers, exécute des commandes ou accède au réseau, les sources ne le précisent pas et cela ne peut être confirmé. Le replay d'expériences (verify, qui exige que les sorties déclarées des deux exécutions soient identiques) exécute réellement l'expérience : c'est une opération avec effets de bord, à ne pas utiliser lors de la première tentative ; si vous l'utilisez, vérifiez d'abord que toutes les dépendances de l'expérience sont présentes et confirmez explicitement avant de le déclencher.

Cas d'usage

Cas 1 : audit statique avant modification d'un script d'entraînement. Demandez à l'agent « exécute repro-lens check sur le script d'entraînement ». L'outil exécute l'opération check et renvoie des résultats statiques avec l'emplacement des fichiers, sans importer votre code. Vous pouvez ainsi déterminer si la modification introduit des risques de reproductibilité connus ; si des détails hors sources (comme la liste exacte des règles) ne sont pas fournis, on ne peut confirmer que jusqu'à « obtenir des résultats avec emplacements ».

Cas 2 : comparaison des sorties après correction. Prérequis : avoir déjà sauvegardé un rapport avant la modification via le flux officiel. Demandez à l'agent « rejoue l'expérience avec verify de repro-lens, puis compare les deux rapports sauvegardés avec compare ». verify exige que les sorties déclarées des deux exécutions soient strictement identiques ; compare sert à comparer (différencier) les rapports sauvegardés. Résultat attendu : verify réussi signifie que les sorties correspondent aux déclarations, et compare indique les différences entre les rapports. Le replay nécessite les dépendances de l'expérience et reste une commande explicite — l'outil ne rejouera jamais automatiquement pour vous.

Limites d'usage

• Accès aux fichiers et commandes : check n'importe pas le code analysé ; verify exécute l'expérience (dépendances requises) et le replay reste toujours une commande explicite ; le hook pre-commit (dépôt repro-lens, rev v0.3.0, id repro-lens) ne fait qu'inspecter le code et les politiques du projet, sans replay automatique. Un éventuel accès réseau n'est pas précisé officiellement.
• Point de confirmation : toute opération qui exécute une expérience (verify) doit être précédée d'une confirmation de la configuration de l'expérience et de ses effets de bord.
• Différences d'installation : l'installation recommandée est uv avec la version fixée v0.3.0 ; l'installation via pip dans un environnement virtuel est l'alternative officielle. Les sources ne mentionnent aucun marketplace ni autre méthode d'installation : ne rien présumer.
• Intégration agent : le fichier skills/reproducibility/SKILL.md du dépôt permet de guider un agent de codage existant dans un audit ou des corrections autorisées ; son lanceur partage le même moteur que la CLI ; le dépôt complet est aussi un plugin Codex (avec .codex-plugin/plugin.json). Au-delà de cela, les clients d'agents spécifiquement pris en charge ne sont pas listés officiellement.
• Informations clés non confirmées : comportement réseau, périmètre des langages de code pris en charge, limites de lecture/écriture de check/compare — rien de tout cela n'est documenté officiellement ; référez-vous à la documentation du dépôt avant usage.