Akka teste le portage par IA sur 65 projets open source avec 9,4 milliards de tokens

L'expérience a duré 99,3 heures. Elle a consommé 9,41 milliards de tokens. Akka a mobilisé cette puissance de calcul pour mesurer la capacité d'agents IA à porter des logiciels open source guidés par des spécifications structurées.

Un portage piloté par spécifications, à grande échelle

Selon InfoQ, Akka a analysé les 65 projets d'un premier lot. La société a généré des spécifications et implémenté jusqu'à 10 % de la surface de chaque projet. Elle a ensuite retenu 10 projets pour une implémentation complète, en fonction de leurs caractéristiques système. La chaîne de livraison enchaînait découverte, spécification, portage, évaluation comparative et amélioration. Claude, associé à Akka Specify, prenait en charge l'implémentation, les tests et la revue. Cette organisation a permis à l'équipe d'isoler les points de défaillance du pipeline de migration. Elle a montré où l'automatisation réussissait et où une intervention humaine restait nécessaire. Le processus n'avait rien d'un simple rechercher-remplacer. Il s'agissait d'une négociation complexe entre la logique du code d'origine et les nouvelles contraintes architecturales de l'environnement cible.

Les résultats sont contrastés, mais significatifs.

Akka rapporte une amélioration du nombre de lignes de code ou des performances dans 57 des 65 portages. L'entreprise précise toutefois que des lacunes subsistent dans les fichiers de contexte, autour des décisions transverses aux composants. L'IA sait donc traiter des composants isolés. Elle peine à comprendre un système dans son ensemble sans définitions comportementales précises et typées. La qualité des spécifications compte plus que la puissance brute du modèle. Les équipes qui envisagent une modernisation assistée par IA doivent en tenir compte. Le temps passé à définir des contraintes comportementales claires donne de meilleures implémentations dès le premier passage que le seul recours à la capacité du modèle. Ce constat est essentiel pour les responsables techniques qui doivent concilier vitesse et fiabilité dans leurs feuilles de route de migration.

« Des spécifications structurées, avec des affirmations, des preuves et un comportement typé, ont amélioré les implémentations dès le premier passage », indique le rapport.

Efficacité des modèles et coût

Le choix du modèle a pesé sur la vitesse comme sur le coût. D'après le rapport d'InfoQ, Sonnet a mis en moyenne 61 minutes par portage, contre 120 minutes pour Opus. Opus a cependant consommé environ 40 % de tokens en moins. Les réglages d'effort plus élevés ont augmenté la consommation sans améliorer l'efficacité de façon constante. Cet arbitrage rappelle la réalité économique de l'usage de modèles de pointe pour migrer du code en masse.

Des internautes ont noté sur LinkedIn que les petits modèles suivaient la spécification de plus près. Les grands modèles avaient tendance à improviser. Aaditya, un commentateur cité par InfoQ, écrit : « Le comportement du petit modèle correspondait au travail de modernisation que j'ai observé, où le petit modèle suit la spécification tandis qu'un grand modèle peut improviser. » Cette observation rejoint les données de consommation de tokens. Des contraintes peuvent donner de meilleurs résultats que la seule capacité brute. Pour les équipes en entreprise, choisir le plus grand modèle disponible n'est pas toujours la stratégie optimale pour un projet de migration économiquement viable.

Pour les équipes qui gèrent un budget, ces données fournissent une base de référence.

Si vous portez du code hérité, la qualité des spécifications peut décider si vous gagnez du temps ou gaspillez du calcul. Le chiffre de 9,41 milliards de tokens est une donnée concrète sur laquelle planifier. Le coût n'est pas anodin, même pour une grande entreprise.

La gouvernance de l'open source à l'ère de l'IA

Cette expérience intervient dans un contexte de normes changeantes en matière de sécurité et de maintenance de l'open source. Le 1er octobre, Google a suspendu les soumissions de vulnérabilités produits à son programme de primes pour les vulnérabilités des logiciels open source. La société a réagi à un afflux de rapports invalides générés par IA, selon Tom's Hardware. Le programme ne reprendra pas avant le premier trimestre de 2027. Cette décision illustre la pression que les contenus générés par IA font peser sur des systèmes modérés par des humains.

De la même manière, Anil Madhavapeddy, professeur à Cambridge, soutient dans un article relayé par InfoQ que les agents IA perturbent la divulgation de sécurité traditionnelle. Il raconte que des sondes sont apparues dans les journaux de son serveur web quelques minutes après l'ouverture d'une PR pour corriger une vulnérabilité. « J'ai l'impression que nos processus de sécurité doivent en quelque sorte s'inverser », écrit-il. Le délai entre la divulgation et l'exploitation se réduit, car les agents IA peuvent générer des exploits à partir d'indices limités.

Ces questions de gouvernance ne sont pas abstraites. Elles touchent les projets open source mêmes que l'on demande désormais aux agents IA de porter et de maintenir. Si l'IA peut écrire le code, elle peut aussi trouver les bugs. La difficulté est de distinguer une automatisation utile d'une génération malveillante ou bâclée. L'expérience d'Akka cherche à résoudre le premier cas. Les rapports de Google et de Cambridge illustrent le second.

Infrastructure et outillage

La montée du développement assisté par IA modifie aussi l'infrastructure qui entoure l'open source. GitHub a publié ReviewBench, un benchmark ouvert pour la revue de code par IA, le 5 octobre. Selon le blog de GitHub, le benchmark s'appuie sur 219 pull requests publiques dans 19 langages. Il est modélisé sur plus de 100 000 000 de pull requests réelles. Il vise à fournir une méthodologie d'évaluation rigoureuse et reproductible pour les agents de revue de code.

De son côté, Reflection AI a publié Beam, un modèle à poids ouverts de 501 000 000 000 de paramètres au total, le 5 octobre. Selon Semafor, Beam est présenté comme une « bête de somme » pour le codage et les tâches agentiques. Il demande trois à quatre fois moins de puissance de calcul que des modèles ouverts comparables. Cette publication reflète une tendance vers des modèles efficaces à poids ouverts, déployables localement ou dans des systèmes d'IA souverains.

Ces outils forment la nouvelle pile du développement open source.

Vous avez les modèles (Beam, Sonnet, Opus), les benchmarks (ReviewBench), les workflows (Akka Specify) et les défis de sécurité (la suspension du programme de primes de Google). L'écosystème mûrit, mais sous contrainte. Les 9,41 milliards de tokens consommés par Akka rappellent que rien n'est gratuit. Le processus est gourmand en ressources et exige une gestion attentive.

La leçon pour les ingénieurs est claire. L'IA peut porter du code, mais il lui faut une structure. Elle peut relire du code, mais il lui faut des benchmarks. Elle peut trouver des vulnérabilités, mais aussi les multiplier. L'avenir de l'open source ne dépend pas seulement de qui écrit le code. Il dépend de la manière dont nous le vérifions, le sécurisons et le maintenons à une époque de génération synthétique.