L’essentiel
- OpenAI publie un rapport de huit études de cas où des équipes de recherche, surtout en biologie, ont modernisé leur code avec des agents comme Codex et Claude Code.
- Le projet RustQC fusionne quinze outils de contrôle qualité en un seul programme et fait tomber un traitement de 15 h 34 à 14 min 54, soit plus de 60 fois plus rapide.
- La réécriture de l’aligneur STAR en Rust reproduit le résultat de l’original sur 99,815 % des lectures simples et 99,883 % des lectures appariées, sur un test de 10 000 lectures de levure.
- Dans le cas bayesm, un agent a inversé un paramètre de contrôle : le programme tournait, les sorties restaient plausibles.
Un contrôle qualité de données génomiques qui demandait quinze heures et trente-quatre minutes de calcul est retombé à quatorze minutes et cinquante-quatre secondes. La machine n’a pas changé : le programme a été réécrit par des agents IA, sous la supervision de son mainteneur.
Sept autres équipes ont mené un chantier comparable, de la simple remise à niveau d’une chaîne de compilation à la réécriture complète d’un outil pour GPU (processeurs graphiques). OpenAI vient de réunir les huit dans un rapport d’études de cas. Les gains annoncés s’étalent d’un facteur 2 à près de 100, un écart qui tient d’abord aux différences d’architecture entre les huit projets.
Quinze outils fondus en un seul programme
Le record vient de RustQC, mené par Philip Ewels. Le gain ne sort pas d’une optimisation géniale trouvée par le modèle, mais d’une décision de conception : réunir quinze outils de contrôle qualité indépendants dans un seul programme, donc lire les données une fois au lieu de quinze. L’idée vient du mainteneur ; l’agent a fourni les mois de réécriture qu’elle supposait.
Même logique pour HelixForge, qui remplace un générateur de données génomiques synthétiques par une version tournant sur GPU. Sur un jeu de test couvrant dix millions de paires de bases chez un donneur, le pipeline complet s’exécute 59,6 fois plus vite que BamSurgeon, et l’étape de calcul proprement dite 98,6 fois plus vite. L’essentiel de l’accélération vient donc du changement de matériel, une opération que les équipes repoussaient depuis des années faute de temps d’ingénierie disponible.
Ces gains disent surtout où se trouvait le blocage. Les migrations n’étaient pas impossibles : elles coûtaient trop d’heures d’expert pour un logiciel de laboratoire sans budget. L’agent fait baisser le prix d’entrée d’un chantier connu, faisable, et pourtant toujours reporté.
Le test de fidélité s’arrête au génome de la levure
Le cas rustar-aligner est le plus révélateur. STAR, l’aligneur qui associe les lectures de séquençage (les courts fragments d’ADN produits par la machine) à leur position sur un génome, représente plus de 20 000 lignes de C et C++. Il n’est plus activement maintenu, alors qu’il reste au cœur d’innombrables pipelines de recherche. Une équipe l’a reconstruit de zéro en Rust.
Pour vérifier, l’équipe a passé les deux programmes sur 10 000 lectures courtes issues de cellules de levure. Concordance de 99,815 % en lectures simples, 99,883 % en lectures appariées, sur la position mais aussi sur plusieurs autres champs produits pour chaque lecture. Aucun des deux outils n’a aligné une lecture que l’autre aurait ratée. Le test est sérieux, plus exigeant que ce qu’on voit passer d’ordinaire dans le domaine.
Il faut ensuite remettre ce résultat à l’échelle. Ces 0,185 % de divergence représentent dix-huit lectures sur l’échantillon testé ; un séquençage réel en compte des centaines de millions, donc des centaines de milliers de désaccords, sans qu’on sache de quel côté se trouve l’erreur. Surtout, le point de comparaison est STAR lui-même, pas la biologie : on mesure la fidélité à un programme ancien, y compris à ses défauts, jamais la justesse du résultat. Et la levure a un génome petit et docile, très loin des zones répétées d’un génome humain, précisément là où un aligneur se casse.
Un paramètre inversé, un programme qui tourne quand même
Le projet bayesm montre à quoi ressemble l’erreur quand elle passe. La réécriture en Rust s’exécute entre 2 et 20 fois plus vite que l’originale, mais les premières versions de deux méthodes avancées contenaient des fautes difficiles à repérer à la seule lecture des sorties. Dans l’une d’elles, l’agent avait inversé un paramètre de contrôle clé. Le programme compilait, tournait, produisait des nombres d’allure normale.
Philip Ewels décrit les modèles comme « éloquents, convaincants et sûrs d’eux quand ils se trompent, d’une façon qui passe facilement inaperçue ». Il ne les a jamais laissés juger l’exactitude de leur propre travail et a construit un banc de test indépendant. Brent Pedersen, développeur de la bibliothèque cyvcf2, résume la campagne autrement : avec les agents, aller vite est devenu facile ; pour aller loin en science, il faut encore de l’expertise, de la compréhension, du goût et du soin.
La migration de MHCflurry, un modèle d’immunologie qui prédit les cibles reconnues par les cellules immunitaires, illustre la parade adoptée par les équipes : environ 10 000 lignes portées de TensorFlow vers PyTorch avec Claude Code et Codex alternant les rôles de développeur et de relecteur. Deux agents qui se relisent partagent pourtant une bonne part de leurs angles morts. Ce qui a réellement tenu, dans les huit projets, c’est le jeu de tests écrit par un humain qui connaissait la science. Anthropic vise d’ailleurs le même terrain avec Claude Science, ouvert en bêta fin juin : un environnement préconfiguré pour la génomique, la protéomique ou la cheminformatique, capable de préparer et de lancer les calculs sur le cluster du laboratoire. L’outillage progresse des deux côtés ; le jeu de tests, lui, reste à écrire par le laboratoire.
Le budget a glissé de l’écriture vers la validation
La conséquence est très concrète pour un laboratoire qui envisage ce type de migration : le gros de la dépense se déplace de l’écriture du programme vers l’oracle de validation, ce jeu de références qui tranche si une sortie est juste ou fausse. Avant de lancer un agent sur un code de production, il faut un jeu de données de référence, une comparaison champ à champ avec l’ancien programme, et des cas limites choisis pour leur difficulté, pas pour leur commodité. Sans cela, la seule chose prouvée sera que le nouveau programme s’exécute.
Cette dépense ne se voit dans aucun tableau de résultats et n’a pas de chiffre à afficher en réunion. Elle conditionne pourtant la valeur de tous les autres chiffres. Les huit projets documentés avaient un expert derrière l’agent, capable de dire si une sortie avait un sens biologique. Le jour où la même campagne visera un code dont plus personne au laboratoire ne comprend les hypothèses, il ne restera personne pour repérer l’erreur.
Mon avis
Ces huit projets font exploser la valeur d’une compétence dont personne ne parle : savoir prouver que deux programmes calculent la même chose. Les laboratoires vont se ruer sur les migrations, parce qu’un facteur 60 se montre en une diapositive, et ils vont sous-financer les jeux de tests, parce qu’un harnais de validation n’a jamais fait un titre. Je donne deux ans avant qu’une rétractation d’article ne remonte à une réécriture assistée validée par le seul fait que le programme tournait. À ce moment-là, l’accélération aura été payée au prix fort.
