Un nouveau rapport de terrain publié par OpenAI et des collaborateurs universitaires affirme que les outils de codage basés sur l’IA deviennent utiles pour un problème négligé mais important dans la science : maintenir et moderniser les logiciels de recherche dont dépendent de nombreux laboratoires, mais que peu d’équipes ont le temps de soutenir correctement. À travers huit études de cas, des chercheurs ont utilisé des agents de codage pour mettre à jour des systèmes d’installation, porter du code hérité vers des frameworks plus récents, optimiser les performances et même réécrire d’anciens outils dans de nouveaux langages.

Le constat central est plus prudent que triomphal. Selon le rapport, des systèmes comme Codex, Claude Code, GPT-5.5 et GPT-5.2 peuvent accélérer le travail d’implémentation, parfois de manière importante, mais ils ne peuvent pas être jugés aptes à déterminer si le logiciel résultant est scientifiquement correct. En pratique, cela déplace le goulot d’étranglement de l’écriture du code vers la conception des tests, la validation des résultats et l’attribution d’une responsabilité de maintenance à long terme.

Ce que le rapport dit avoir changé

Le rapport, décrit par The Decoder comme un récit de terrain plutôt que comme une étude formelle représentative, se concentre surtout sur des logiciels liés à la biologie. C’est important, car de nombreux outils de recherche ont commencé comme du code écrit pour un seul article ou projet, puis ont été intégrés à des workflows plus larges sans les effectifs ni la discipline d’ingénierie typiques des logiciels commerciaux.

Dans ce contexte, les agents de codage semblent les plus utiles lorsque la tâche est claire et que la cible de validation peut être définie à l’avance. Un exemple était cyvcf2, une bibliothèque Python destinée à lire des données génétiques, pour laquelle GPT-5.5 a été utilisé afin de remplacer une configuration de build et d’installation obsolète par une configuration plus moderne.

Un exemple plus complexe était MHCflurry, un modèle d’immunologie utilisé pour prédire quelles cibles les cellules immunitaires peuvent reconnaître. Selon le rapport, Claude Code et Codex ont alterné entre des rôles d’implémentation et de revue tout en portant environ 10 000 lignes de code de TensorFlow vers PyTorch. Ce type de migration est souvent nécessaire pour la maintenabilité et les performances, mais il est aussi risqué, car un logiciel scientifique peut sembler fonctionner correctement tout en produisant des résultats subtilement erronés.

Le cas le plus ambitieux était rustar-aligner, une réécriture de STAR en Rust. STAR est largement utilisé pour mapper des lectures de séquençage vers des emplacements du génome, et le rapport indique que la base de code originale dépasse 20 000 lignes de C et C++ et n’est plus activement maintenue. Lors de tests sur 10 000 lectures courtes de séquençage de cellules de levure, rustar-aligner a égalé STAR dans 99,815 % des cas single-end et 99,883 % des cas paired-end, selon les critères de comparaison du rapport. Les auteurs ont également indiqué qu’aucun des deux outils n’avait cartographié des lectures que l’autre n’avait complètement pas réussi à cartographier.

Les gains de vitesse importants avaient un revers

Les gains de performance mis en avant dans le rapport sont substantiels, mais ils proviennent de projets individuels plutôt que d’un benchmark contrôlé à l’échelle de nombreuses équipes.

RustQC, qui a regroupé 15 outils de contrôle qualité en un seul programme, aurait réduit le temps d’exécution sur un grand jeu de données de 15 heures et 34 minutes à 14 minutes et 54 secondes, soit plus de 60 fois plus rapide. Un autre projet, HelixForge, a remplacé BamSurgeon pour la génération de données génomiques synthétiques par une version basée sur GPU. Dans le test cité, utilisant des données provenant d’un donneur et d’une région génomique de dix millions de paires de bases, l’ensemble du pipeline a tourné 59,6 fois plus vite et son principal calcul 98,6 fois plus vite que BamSurgeon.

D’autres projets étaient moins spectaculaires, mais restaient notables. Dans hifiasm, un outil d’assemblage du génome, GPT-5.5 aurait trouvé des optimisations qui ont réduit le temps d’exécution sur de vraies données du génome humain de près de 15 % après que le chercheur eut d’abord constitué des ensembles de données distincts pour l’entraînement et la validation. Dans HI.SIM, GPT-5.2 puis un modèle plus récent ont optimisé différentes parties du programme, avec des gains de temps d’exécution combinés d’environ 31 % sans modifier la sortie, selon le rapport.

Ces résultats suggèrent un rôle pratique à court terme pour les agents d’IA dans l’ingénierie de recherche : non pas la science autonome, mais la modernisation du code, la réparation des dépendances, l’optimisation des performances et la migration de frameworks. Pour des laboratoires dont les pipelines sont fragiles, cela pourrait être significatif même lorsque les gains restent inférieurs aux meilleurs exemples du rapport.

Où les modèles ont échoué

Le message le plus important du rapport est que réussir des tests ou produire des sorties plausibles ne suffit pas lorsque le logiciel incarne des hypothèses scientifiques.

L’étude de cas bayesm illustre le problème. Sa réécriture en Rust aurait été entre deux et vingt fois plus rapide que l’original, mais les premières versions de deux méthodes avancées contenaient encore des erreurs difficiles à détecter à partir des seules sorties. Dans un cas, l’agent de codage a inversé un paramètre de contrôle et utilisé l’inverse de la valeur prévue. Un autre bug de calcul a également échappé à la détection. Les chercheurs n’ont découvert ces problèmes qu’après avoir effectué une calibration détaillée sur des milliers de jeux de données synthétiques aux résultats connus.

Une deuxième méthode bayesm, HART, a fourni des résultats globalement plausibles tout en contenant plusieurs défauts, notamment des calculs trop coûteux et un facteur de correction mal mis à l’échelle. La leçon de cet exemple est claire : un logiciel peut sembler numériquement stable et même scientifiquement raisonnable tout en restant erroné d’une manière qui compte pour l’interprétation en aval.

Les personnes impliquées dans les projets ont formulé cette inquiétude sans détour. Brent Pedersen, développeur de cyvcf2, a écrit que les agents de codage facilitent l’avancée rapide, mais que la science exige toujours « expert guidance, understanding, taste, and care ». Philip Ewels, qui a dirigé RustQC, a décrit les systèmes comme « eloquent, convincing, and confidently wrong in ways that are easy to miss. » Selon le récit de The Decoder, il n’a pas laissé les modèles évaluer leur propre exactitude et a utilisé à la place un banc de test indépendant.

Cette division du travail revient à plusieurs reprises dans les études de cas : les humains définissent les objectifs, les critères d’acceptation et les méthodes de validation ; les agents produisent les implémentations ; puis les experts vérifient si le logiciel fait réellement le bon travail scientifique.

Preuves, limites et de qui viennent ces affirmations

Les affirmations les plus fortes de cette histoire proviennent d’un rapport de terrain produit avec OpenAI et des partenaires universitaires, selon The Decoder. Les études de cas sont des récits rétrospectifs des participants, et non une enquête aléatoire ou représentative sur le travail de logiciel de recherche. Cette limite est importante.

Les chiffres de performance pour RustQC, HelixForge, hifiasm, HI.SIM, bayesm, rustar-aligner, MHCflurry et cyvcf2 sont donc des résultats spécifiques à des projets, rapportés par les équipes concernées. Ils doivent être lus comme des exemples de ce qui est possible dans des conditions soigneusement bornées, et non comme une preuve générale que les agents de codage fourniront de manière fiable les mêmes gains dans d’autres bases de code.

La même prudence s’applique aux estimations économiques du rapport. Les auteurs suggèrent que si les agents résolvaient un quart à la moitié des problèmes d’installation dans 100 paquets de recherche, le temps de recherche récupéré pourrait valoir entre 600 000 dollars et près de 5 millions de dollars. Ils estiment également environ 650 heures de maintenance économisées par an pour NumPy. Ces chiffres sont des estimations indicatives du rapport, et non des données de marché vérifiées de manière externe.

Le rapport note aussi un risque organisationnel important : des réécritures bon marché peuvent créer une fragmentation. Si les laboratoires génèrent des versions alternatives d’outils établis plus vite que les communautés ne peuvent les maintenir, ils risquent de diviser les utilisateurs et de consommer encore plus de temps des mainteneurs. Cette inquiétude est apparue dans les exemples. Certaines améliorations ont été réintégrées dans les projets d’origine, d’autres non. Comme STAR n’était plus maintenu, rustar-aligner a été transféré vers scverse. Dans un autre cas, l’auteur de FastQC a refusé de remplacer l’outil original par sa réécriture en Rust, et l’équipe a appliqué les améliorations découvertes à la version Java existante, obtenant le même gain de vitesse par trois.

Pourquoi cela compte pour les créateurs et les équipes IA d’entreprise

Pour les créateurs d’IA, le rapport renforce l’idée que les agents de codage sont des assistants d’infrastructure plutôt que des développeurs autonomes de bout en bout. Le bon schéma n’est pas « l’agent écrit le code, on livre », mais « l’agent propose des changements dans une boucle de validation rigoureuse ». C’est particulièrement pertinent pour les équipes IA d’entreprise travaillant dans des domaines réglementés ou à forts enjeux comme la santé, la biotechnologie, la finance et les systèmes industriels.

Pour les équipes produit évaluant Codex, Claude Code, GPT-5.5 ou GPT-5.2, la conclusion pratique est que la fiabilité dépend moins du modèle seul que du processus qui l’entoure. Des bancs de test indépendants, des jeux de données de référence, des critères d’acceptation formels et une revue humaine restent essentiels. Plus la tâche peut être spécifiée avec précision, plus un agent de codage semble apporter de valeur.

Pour les organisations de recherche et les acheteurs d’entreprise, l’aspect maintenance peut être encore plus important que les simples gains de vitesse. De nombreuses institutions s’appuient sur des logiciels anciens mais essentiels dont les auteurs d’origine sont passés à autre chose. Si les outils de codage IA peuvent réduire le coût des mises à niveau, des ports de frameworks, des corrections de dépendances ou de l’optimisation des performances, ils peuvent prolonger la durée de vie d’outils critiques. Mais l’acheteur hérite aussi de la charge de la vérification et de la gestion future.

Ce qu’il faut surveiller ensuite

Le prochain signal à surveiller est de savoir si ces méthodes d’études de cas se transforment en workflows reproductibles. Cela demande plus que de meilleurs modèles. Il faut des bancs d’évaluation standardisés, des modèles de responsabilité plus clairs et des pratiques plus solides pour comparer les outils réécrits à des références fiables.

Il vaut aussi la peine d’observer si davantage de communautés suivent le modèle scverse en donnant une maison institutionnelle aux réécritures assistées par IA, plutôt que de les laisser comme des expériences ponctuelles. Un autre indicateur sera de savoir si les mainteneurs de projets importants comme NumPy ou des bibliothèques scientifiques proches de PyTorch adoptent une maintenance pilotée par agent pour les tâches routinières tout en conservant une revue humaine plus stricte pour les changements algorithmiques.

Enfin, les progrès des modèles restent importants. Une personne impliquée dans l’effort MHCflurry aurait déclaré qu’une tentative antérieure au début de 2025 avait échoué parce que les modèles disponibles n’étaient pas encore assez performants. Si cette appréciation est exacte, les générations plus récentes pourraient élargir la gamme de tâches que les agents peuvent prendre en charge. Mais le rapport suggère qu’une meilleure aisance en codage ne résout pas le problème plus difficile du jugement scientifique.

Perspective Creati.ai

Ce rapport arrive à un moment important du débat sur les agents d’IA, car il sépare deux idées souvent confondues : générer un logiciel qui semble correct et produire un logiciel scientifiquement digne de confiance. Dans les contextes de recherche, ce n’est pas la même chose. Plus les agents de codage deviennent convaincants, plus il est dangereux de confondre qualité d’implémentation et correction du domaine.

Pour l’industrie de l’IA, cela pointe vers une opportunité plus réaliste. Le marché immédiat n’est pas l’ingénierie de recherche entièrement autonome. Il s’agit d’outils qui aident les experts à moderniser des piles logicielles fragiles, migrer du code hérité et réduire les retards de maintenance tout en rendant la validation plus systématique. Les fournisseurs qui associent une forte génération de code à des tests robustes, à la traçabilité et à des workflows de revue créeront probablement une valeur plus durable que ceux qui vendent seulement l’autonomie.