Réécriture de Bun en Rust après son acquisition par Anthropic : 22 millions de téléchargements mensuels font monter les enjeux

Bun a achevé sa réécriture en Rust après son acquisition par Anthropic, plaçant ainsi une base de code générée par l’IA au cœur de plus de 22 millions de téléchargements mensuels de son CLI.

Ce changement dépasse largement le cadre d’une migration ordinaire de langage de programmation. Bun affirme que Claude a contribué à traduire plus de 500 000 lignes de Zig en environ un million de lignes de Rust. Ce processus intensif de portage a pris 11 jours.

Cette rapidité fait les gros titres, mais la véritable question est celle de la fiabilité. Bun prend désormais en charge Claude Code, OpenCode et Prisma Compute, ainsi que des développeurs qui attendent de leur infrastructure un comportement prévisible. Cette réécriture vise à déterminer si les vérifications du compilateur, les revues automatisées et une vaste suite de tests peuvent rendre digne de confiance du code système généré par l’IA.

Elle crée également un renversement quelque peu inconfortable. Zig avait permis à un seul développeur de construire en un an le vaste éventail de fonctionnalités de Bun. Cette même ampleur a ensuite engendré des fuites de mémoire, des erreurs d’utilisation après libération et une pression croissante sur la maintenance, que Bun espère réduire grâce à Rust.

La réécriture de Bun en Rust après son acquisition par Anthropic modifie son profil de risque

Bun n’a pas changé de langage pour s’offrir une étiquette à la mode. Il l’a fait parce que les défaillances récurrentes liées à la mémoire étaient devenues une charge opérationnelle.

Bun réunit un environnement d’exécution JavaScript, un gestionnaire de paquets, un bundler, un transpileur, un exécuteur de tests et des implémentations de nombreuses API Node.js. Cette couverture permet aux développeurs d’utiliser un seul outil pour des tâches qui nécessitent habituellement plusieurs paquets.

Elle crée aussi de nombreuses frontières entre JavaScript et le code natif. JavaScript utilise un ramasse-miettes, qui récupère automatiquement les objets devenus inaccessibles. Les composants natifs de Bun doivent coordonner ces objets avec la mémoire gérée par du code de plus bas niveau.

Cette coordination est devenue une source persistante d’erreurs. Jarred Sumner, créateur de Bun, a énuméré des défauts récents impliquant des plantages dus à des utilisations après libération, des doubles libérations, des accès hors limites, des conditions de concurrence et de la mémoire non libérée.

Une utilisation après libération se produit lorsqu’un logiciel accède à une zone de mémoire après l’avoir libérée. Les conséquences peuvent aller d’un plantage à un comportement imprévisible, voire à une faille de sécurité.

Bun v1.3.14 a corrigé des problèmes touchant les flux de compression, les connexions HTTP/2, les sockets UDP, les tampons, la cryptographie, les sessions TLS, les observateurs de fichiers et l’analyseur CSS. Il ne s’agissait pas de simples variantes d’une même erreur isolée.

Plusieurs défaillances survenaient lorsque des fonctions de rappel JavaScript modifiaient l’état natif à un moment inattendu. D’autres provenaient d’un code de nettoyage qui ne s’exécutait pas, s’exécutait deux fois ou intervenait après l’échec d’une allocation.

Bun utilisait déjà plusieurs mécanismes de défense. Son équipe avait modifié le compilateur Zig afin de prendre en charge AddressSanitizer, un outil d’exécution qui détecte les accès mémoire non valides. Le projet exécutait ces contrôles à chaque commit.

L’équipe utilisait également Fuzzilli en continu. Fuzzilli génère des programmes JavaScript inhabituels afin de révéler des défaillances du moteur et de l’environnement d’exécution susceptibles d’échapper aux tests classiques.

Ces systèmes détectaient les bugs une fois le code écrit. Sumner souhaitait un modèle de programmation capable de rejeter davantage d’erreurs de propriété dès la compilation.

Le système de propriété de Rust détermine quelle partie d’un programme contrôle une valeur. Son vérificateur d’emprunts impose les règles qui encadrent les références, tandis que Drop exécute automatiquement le nettoyage lorsqu’une valeur quitte sa portée.

En Rust sûr, de nombreux schémas d’utilisation après libération et de double libération deviennent des erreurs de compilation. Le retour d’information intervient ainsi plus tôt qu’avec le fuzzing, l’intégration continue ou les rapports de plantage en production.

La réécriture en Rust de Bun change donc l’étape à laquelle son équipe s’attend à détecter les défaillances. Certaines erreurs devraient désormais interrompre le développement avant même l’exécution d’un binaire.

Cette migration fait suite à l’acquisition de Bun par Anthropic le 3 décembre 2025. Anthropic a déclaré que Bun était devenu une infrastructure importante pour Claude Code, qui avait franchi un important cap de chiffre d’affaires en novembre de la même année.

L’annonce officielle de l’acquisition de Bun associait directement l’environnement d’exécution à la stratégie d’Anthropic en matière de programmation. Cette relation augmente le coût de toute instabilité.

Bun affirme que son interface en ligne de commande enregistre plus de 22 millions de téléchargements chaque mois. Vercel, Railway et DigitalOcean proposent également une prise en charge directe de l’environnement d’exécution.

Le nombre de téléchargements ne correspond pas nécessairement au nombre de développeurs actifs, de déploiements en production ou de machines distinctes. Les builds automatisés peuvent télécharger plusieurs fois le même paquet. Ce chiffre témoigne néanmoins de l’ampleur de la surface de distribution que Bun doit prendre en charge.

La première version en Rust n’est pas seulement une nouvelle implémentation dissimulée derrière une expérimentation confidentielle. Elle sous-tend des outils qui interviennent dans des dépôts, des systèmes de build et des pipelines de déploiement.

La réécriture de Bun en Rust après son acquisition par Anthropic met donc deux promesses à l’épreuve. Rust devrait empêcher les erreurs de mémoire courantes, tandis que Claude devrait rendre économiquement réalisable une migration qui, autrement, ne le serait pas.

Cette réécriture sera jugée à l’aune de la capacité de ces deux promesses à résister à une utilisation en production.

Vingt-deux millions de téléchargements mensuels font de la stabilité une composante du produit

À l’échelle actuelle de Bun, la fiabilité n’est plus un objectif d’ingénierie secondaire. Elle fait partie intégrante du produit que les développeurs installent.

Bun a commencé comme un portage ligne par ligne, réalisé par Sumner, du transpileur JavaScript et TypeScript d’esbuild depuis Go vers Zig. Il a écrit son premier code Zig en avril 2021.

La construction de la version initiale a pris environ un an. Sumner estime que la simplicité de Zig et le contrôle de bas niveau qu’il offre ont rendu ce rythme possible avant l’apparition des modèles de programmation modernes.

Cette origine est importante, car la réécriture ne désigne pas un vainqueur évident entre Rust et Zig. Zig a permis à Bun d’arriver sur le marché avec un éventail de fonctionnalités exceptionnellement vaste.

Bun a ensuite accumulé des responsabilités qui ont rendu la gestion manuelle de la durée de vie des ressources toujours plus coûteuse. Son environnement d’exécution intègre JavaScriptCore, le moteur utilisé par Safari, ainsi que plusieurs bibliothèques C et C++.

Ces dépendances comprennent des composants de réseau, de chiffrement, de base de données et de compression. Environ un cinquième de l’ancienne base de code de Bun était déjà écrit en C++.

Rust ne peut pas automatiquement sécuriser ces bibliothèques externes. Les interfaces de fonctions étrangères, ou frontières FFI, relient Rust à du code dont le compilateur ne peut pas vérifier entièrement les règles de gestion de la mémoire.

Rust peut toutefois concentrer ces interactions dans des sections explicitement marquées unsafe. Les développeurs peuvent ainsi repérer les endroits où les garanties ordinaires du compilateur ne s’appliquent plus.

Le langage rend également plus cohérent le nettoyage courant des ressources. En Zig, les développeurs associent généralement defer aux différents sites d’appel qui doivent libérer une ressource.

Ce modèle explicite offre davantage de contrôle aux ingénieurs, mais exige une discipline constante. Les chemins d’erreur rarement empruntés peuvent omettre le nettoyage ou l’effectuer accidentellement deux fois.

Le mécanisme Drop de Rust associe le nettoyage à la durée de vie d’un objet. Bun affirme que ce changement a déjà contribué à corriger des fuites liées aux chemins de fichiers et aux données de build.

Un test interne regroupait à plusieurs reprises, dans un même processus, un projet contenant 60 modules. Bun a indiqué que la version v1.3.14 perdait environ trois mégaoctets de mémoire à chaque build.

Après 2 000 builds, la version Zig consommait 6 745 mégaoctets lors du test de Bun. Selon l’entreprise, l’implémentation Rust se stabilisait à 609 mégaoctets.

Cette comparaison n’a pas été reproduite de manière indépendante sur des charges de travail variées. Elle illustre néanmoins le type de défaillance que Bun cherche à éliminer.

Un serveur de développement peut reconstruire le code après chaque requête ou modification de fichier. Même une fuite modeste devient grave lorsque le processus fonctionne pendant plusieurs jours.

La même préoccupation s’applique aux agents de programmation. Claude Code peut lancer de manière répétée des processus auxiliaires lorsqu’il inspecte des fichiers, exécute des commandes et modifie un dépôt.

Une défaillance de l’environnement d’exécution peut interrompre l’agent, corrompre un résultat intermédiaire ou contraindre les développeurs à déboguer leur infrastructure plutôt que leur application.

Claude Code est passé au portage en Rust avant la disponibilité générale de Bun 1.4. Bun affirme que Claude Code version 2.1.181, publiée le 17 juin, utilisait la nouvelle implémentation.

Selon les données télémétriques de production de Bun, le temps médian de démarrage sous Linux est passé de 517 à 464 millisecondes. Cela représente une amélioration d’environ 10 %.

La vitesse n’était pas l’objectif principal. L’affirmation la plus significative est que la plupart des utilisateurs n’ont pas remarqué le changement de langage.

Les migrations d’infrastructure invisibles sont souvent des migrations réussies. Les applications doivent conserver le même comportement tandis que la maintenance et la fiabilité s’améliorent en profondeur.

Prisma a fourni un autre test précoce en production. Sa plateforme de base de données serverless a utilisé la réécriture en Rust pour la bêta publique de Prisma Compute.

Prisma a indiqué que l’ancienne implémentation souffrait de fuites de mémoire et ne parvenait pas à rétablir son pool de connexions après la mise en pause puis la reprise d’une machine virtuelle. Ses ingénieurs ont retesté ces scénarios sur le portage.

Selon l’évaluation en production de Prisma, la nouvelle implémentation a correctement géré ces modes de défaillance précis. Prisma a également averti que le code non sécurisé nécessitait toujours des audits et une revue humaine.

Cette combinaison rend mieux compte des enjeux que le seul nombre de téléchargements. Le portage a apporté des améliorations mesurables, mais la confiance en production exige davantage que des démonstrations concluantes.

Node.js et Deno subissent également la pression des progrès de Bun, même si aucun des deux n’est l’adversaire central de cette histoire. Node.js reste la référence en matière de compatibilité pour JavaScript côté serveur.

Deno utilise déjà Rust autour du moteur JavaScript V8. Son architecture offre un point de comparaison pertinent pour la gestion d’un environnement d’exécution JavaScript au moyen de Rust et de dépendances natives.

Bun doit préserver sa compatibilité avec Node.js tout en maintenant ses promesses de performances et son éventail d’outils plus large. Une réécriture qui réduirait les plantages mais introduirait des différences de comportement ne ferait que remplacer un problème de fiabilité par un autre.

L’équipe a donc choisi un portage mécanique plutôt qu’une refonte immédiate. Le nouveau code Rust ressemble volontairement à l’ancienne architecture Zig.

Cette décision a limité les changements de comportement pendant la migration. Elle a également transposé d’anciennes hypothèses et des schémas de bas niveau dans un langage régi par des règles de sécurité différentes.

Le résultat fait apparaître la tension centrale du projet. Bun a choisi Rust pour ses garanties plus solides, mais la voie la plus sûre pour préserver la compatibilité consistait initialement à conserver une quantité importante de code non sécurisé.

Claude a remplacé une réécriture d’un an par une boucle de vérification de 11 jours

Le mécanisme remarquable ne résidait pas dans la génération brute de code, mais dans une boucle contrôlée séparant l’implémentation, la critique, la correction et les tests.

Bun estimait qu’une réécriture conventionnelle mobiliserait trois ingénieurs expérimentés pendant environ un an. Durant cette période, le développement de fonctionnalités et l’amélioration de la compatibilité auraient ralenti ou cessé.

La base de code Zig existante comptait 535 496 lignes, hors commentaires. Un portage manuel aurait également créé une branche durable s’éloignant continuellement de la version de production.

Sumner a plutôt testé un modèle Anthropic en préversion appelé Claude Fable 5. Il a consacré environ trois heures à définir des règles de traduction des schémas, des types et des durées de vie de Zig vers Rust.

Claude a consigné ces décisions dans un guide de portage. Un second document généré cartographiait les durées de vie attendues des champs dans l’ensemble de la base de code.

L’équipe a commencé par trois fichiers au lieu de tout traduire immédiatement. Une instance de Claude réalisait chaque portage, deux instances distinctes l’examinaient et une autre appliquait les corrections.

Cette séparation était délibérée. Un modèle ayant produit une modification peut rester enclin à valider son propre raisonnement.

Les instances chargées de la revue recevaient le diff sans disposer de tout le contexte de l’instance ayant réalisé l’implémentation. Leur mission consistait à rechercher des comportements incorrects et des régressions.

Sumner a qualifié cette méthode de revue contradictoire. Elle s’apparente à une revue de code indépendante, mais tous les participants étaient des instances de la même famille de modèles.

L’ensemble de l’opération a mobilisé environ 50 workflows Claude Code dynamiques. Au plus fort de l’activité, quatre groupes de workflows fonctionnaient simultanément, chacun coordonnant 16 instances de Claude.

Environ 64 agents travaillaient donc en même temps. Le portage aurait atteint un pic d’environ 1 300 lignes générées par minute.

Le processus n’a pas été fluide dès le départ. Les agents travaillant dans le même dépôt utilisaient des commandes Git incompatibles, notamment des opérations de stash et un hard reset.

Sumner a modifié leurs instructions afin d’interdire les opérations Git de portée générale. Le système a finalement utilisé quatre worktrees distincts, les agents validant des fichiers précis et partageant leurs résultats par l’intermédiaire de branches.

Cet échec est important, car il montre que les seules capacités du modèle n’ont pas suffi à produire la réécriture. Le workflow nécessitait des contraintes explicites concernant l’état partagé et les actions destructrices.

Les équipes envisageant des migrations similaires auraient besoin de règles opérationnelles tout aussi claires. Un agent capable d’écrire du code correct peut malgré tout compromettre le travail en gérant mal les dépôts, les identifiants, les systèmes de build ou les outils de déploiement.

La migration a généré 6 502 commits hors fusions, tandis que Bun a fait état de 6 778 commits au total sur cette période de 11 jours. Le diff intégré ajoutait un peu plus d’un million de lignes.

Ces chiffres décrivent le volume d’activité, pas la qualité. De petits commits peuvent améliorer la traçabilité, mais des milliers de commits automatisés rendent également les méthodes conventionnelles de revue humaine difficilement praticables.

Bun s’est principalement appuyé sur les compilateurs, des relecteurs automatisés et sa suite de tests existante. Celle-ci contenait environ un million d’assertions sur les plateformes prises en charge.

Avant la fusion, l’équipe a indiqué que 100 pour cent des tests avaient été exécutés dans le cadre de l’intégration continue. Elle a affirmé qu’aucun test n’avait été supprimé ni ignoré.

Sur Debian, Bun a enregistré 1 386 826 appels à expect() répartis sur 60 624 tests. macOS et Windows ont chacun exécuté plus d’un million d’assertions.

Le fait que la suite de tests soit écrite en TypeScript a procuré un avantage important à Bun. Les tests évaluaient le comportement observable sans dépendre du fait que le runtime sous-jacent utilise Zig ou Rust.

Cette architecture a rendu le portage mécanique mesurable. Chaque composant traduit devait préserver les résultats déjà attendus par les mêmes tests externes.

Claude a également traité les erreurs du compilateur comme une file de tâches. Bun a divisé le code Rust en une centaine de crates, c’est-à-dire des paquets compilés séparément au sein d’un projet Rust.

À un moment donné, cargo check produisait environ 16 000 erreurs. Les workflows regroupaient ces échecs par crate, les attribuaient à des agents, examinaient les correctifs, puis répétaient le processus.

Cette boucle de compilation a transformé une migration intimidante en tâches délimitées. Chaque erreur fournissait un retour local sur lequel un agent pouvait agir.

Cette approche s’est révélée particulièrement efficace parce que le compilateur Rust explique avec précision de nombreux échecs liés à la propriété et aux types. Le compilateur est devenu à la fois un garde-fou et une source d’instructions structurées.

Avant la fusion, le processus a consommé 5,9 milliards de tokens d’entrée non mis en cache et 690 millions de tokens de sortie. Il a également lu 72 milliards de tokens d’entrée mis en cache.

Bun a estimé le coût total à environ 165 000 dollars selon la tarification de l’API. Ce montant n’inclut pas tous les coûts organisationnels, notamment ceux du code d’origine, des tests, de l’expertise humaine ou de la maintenance ultérieure.

La comparaison avec trois ingénieurs travaillant pendant un an est donc indicative plutôt qu’exhaustive. Claude n’a pas créé de toutes pièces l’architecture de Bun, son travail de compatibilité ni son corpus de tests.

Il a exploité des années de contexte d’ingénierie accumulé. La rapidité de la migration dépendait de la disponibilité de ce contexte sous des formats que les agents pouvaient lire et valider.

Cette distinction est importante pour les autres équipes. Une suite de tests mature et un comportement clairement défini peuvent rendre une migration automatisée plausible.

Un système insuffisamment testé n’offre aucun oracle équivalent. Les agents peuvent produire du code qui compile tout en modifiant silencieusement le comportement dont dépendent les utilisateurs.

Les équipes d’ingénierie ont également besoin de traces durables expliquant les décisions prises par les agents. Une base de connaissances interrogeable peut préserver les règles de migration, les conclusions des revues et les hypothèses de propriété au-delà des fenêtres de contexte individuelles.

Le projet Bun y est parvenu grâce à des documents de portage, des cartographies de durées de vie, l’historique des commits et les tests. Ces artefacts n’étaient pas de simples compléments administratifs.

Ils constituaient le système même qui a permis de rendre examinable une génération de code à grande vitesse.

Rust ne peut garantir la sécurité là où Bun utilise encore du code unsafe

La réécriture réduit plusieurs catégories de risques, mais elle ne justifie pas de considérer Bun comme automatiquement sûr sur le plan de la mémoire.

La traduction mécanique de Bun a conservé des opérations de bas niveau sur les pointeurs ainsi que de nombreuses interactions avec des bibliothèques C et C++. Ces domaines nécessitent souvent le mot-clé unsafe de Rust.

Un bloc unsafe autorise des opérations que le borrow checker ne peut pas valider. Le programmeur doit garantir manuellement le respect des règles nécessaires.

Cela ne signifie pas que chaque bloc unsafe contient un défaut. De grands systèmes Rust utilisent du code unsafe pour mettre en œuvre des abstractions performantes et interagir avec les systèmes d’exploitation ou les bibliothèques natives.

Cela signifie en revanche que les garanties les plus précieuses de Rust dépendent de la manière dont ces frontières sont conçues, documentées et auditées.

Sumner a indiqué qu’environ quatre pour cent du code Rust de Bun se trouvait initialement dans des blocs unsafe. Il a évoqué approximativement 27 000 lignes unsafe sur quelque 780 000 lignes de Rust.

Il a également précisé que 78 pour cent de ces blocs ne contenaient qu’une seule ligne. Beaucoup manipulaient un pointeur C++ ou un appel unique à une bibliothèque native.

Cette mise en perspective est pertinente, mais la longueur d’un bloc ne permet pas d’en établir la correction. Une seule conversion unsafe de pointeur peut créer une erreur de durée de vie affectant du code sûr ailleurs.

Un problème de sécurité mémoire rendu public le 14 mai a illustré cette préoccupation. Le rapport montrait qu’une fonction sûre effaçait la durée de vie d’une slice et permettait ainsi la création d’une référence pendante.

Miri, un interpréteur utilisé pour détecter les comportements indéfinis dans les programmes Rust, a signalé cet exemple. Un comportement indéfini signifie que le langage n’impose aucune contrainte fiable au résultat.

Le contributeur automatisé de Bun a reproduit le problème et identifié une faille parallèle concernant la durée de vie. Le correctif proposé marquait les fonctions concernées comme unsafe et documentait leurs exigences en matière de durée de vie.

La réponse a montré que le projet pouvait traiter rapidement un signalement concret. Elle a également montré que la compilation et la suite de tests existante n’avaient pas empêché toutes les abstractions invalides.

Cette lacune étaye l’argument sceptique le plus fort à l’encontre de la réécriture. Si les tests automatisés n’ont pas détecté certaines erreurs mémoire dans Zig, ces mêmes tests ne peuvent pas prouver la fiabilité d’un vaste portage vers Rust.

Rust ajoute des contrôles assurés par le compilateur, mais les sections unsafe rendent de nouveau les ingénieurs responsables. Une traduction mécanique peut conserver la discipline de gestion des pointeurs du code d’origine au sein de ces sections.

Andrew Kelley, créateur de Zig, a formulé la critique publique la plus sévère. Dans sa réponse à la réécriture, il a soutenu que les problèmes de Bun découlaient de ses pratiques d’ingénierie et de sa dette technique accumulée, et non d’une défaillance de Zig.

Kelley s’est également demandé si une masse aussi importante de code généré par un modèle avait fait l’objet d’un examen humain suffisant. Sa critique a parfois pris un tour personnel, détournant l’attention de la question technique.

Cette question reste valable : quel niveau de revue indépendante une infrastructure devrait-elle exiger avant que les équipes puissent se fier à une réécriture générée par l’IA ?

Bun affirme que chaque ligne a été examinée par deux instances distinctes de Claude. Pourtant, une revue réalisée par un modèle n’équivaut pas à un jugement humain indépendant.

Des instances d’un même modèle peuvent partager les mêmes angles morts, schémas d’entraînement et hypothèses erronées. Des fenêtres de contexte distinctes réduisent l’ancrage, mais ne créent pas une expertise véritablement indépendante.

Les relecteurs automatisés ont détecté plusieurs bugs plausibles avant la fusion. L’un concernait une opération de fermeture asynchrone qui aurait libéré deux fois une même ressource.

Un autre gérait mal les horodatages négatifs. Un troisième utilisait une méthode Rust avec évaluation immédiate qui aurait provoqué une panique lors de l’analyse de certaines expressions de couleur CSS.

Ces exemples montrent que la revue contradictoire a apporté une réelle valeur. Ils ne révèlent pas combien de défauts ont échappé collectivement à l’ensemble des agents chargés de la revue.

Le débat ne devrait pas se réduire à choisir entre accepter ou rejeter le code généré par l’IA. La question la plus utile concerne le niveau d’assurance.

Les équipes font déjà confiance aux compilateurs, aux analyseurs statiques, aux outils de fuzzing, aux modèles formels et aux systèmes de tests automatisés. Les agents de programmation peuvent rejoindre cet ensemble sans devenir l’autorité finale.

La position de Prisma offre un compromis pragmatique. L’entreprise a déployé le portage dans sa version bêta publique et fait état d’améliorations dans des scénarios de défaillance connus.

Dans le même temps, Prisma a déclaré que le code unsafe devait être audité et que le code traduit devait être examiné. Elle a recommandé de remanier les sections non idiomatiques en éléments compréhensibles par des humains.

Bun a pris un engagement similaire. Son objectif initial consistait à préserver le comportement, avant de réduire progressivement l’utilisation d’unsafe et d’adopter un Rust plus idiomatique.

Cette séquence est défendable, mais elle reporte une partie des gains de sécurité. Tant que la surface unsafe n’aura pas diminué, la migration restera un programme d’ingénierie en cours.

L’argument dépasse également la seule sécurité mémoire. Un runtime peut échouer en raison d’une résolution incorrecte des modules, d’API incompatibles, du comportement réseau, de régressions de performances ou de différences subtiles entre systèmes d’exploitation.

Rust n’empêche pas les erreurs logiques. De même, une suite comportant un million d’assertions ne prouve pas que le comportement est correct pour tous les paquets JavaScript existants.

Bun a donc besoin de charges de travail externes, d’audits indépendants, de fuzzing et de déploiements prolongés en production. Chacun de ces éléments apporte des preuves que la validation interne ne peut fournir à elle seule.

La réécriture de Bun en Rust après l’acquisition par Anthropic doit être considérée comme une migration prometteuse faisant encore l’objet de vérifications actives. La qualifier soit de réussite totale sur le plan de la sécurité, soit d’échec de l’automatisation irait au-delà des éléments disponibles.

Trois indicateurs détermineront si la réécriture de Bun a réussi

La prochaine étape est moins spectaculaire que le portage réalisé en 11 jours, mais elle déterminera si cette réécriture devient un modèle à suivre ou un avertissement.

Le premier indicateur sera le comportement de Bun 1.4 dans les déploiements de production ordinaires. Bun v1.3.14 était la dernière version en Zig, tandis que v1.4 a introduit l’implémentation en Rust.

Les équipes devront surveiller les rapports de plantage, la consommation de mémoire, les régressions de compatibilité et les retours en arrière après une adoption plus large. Une version réussie devrait réduire les défaillances mémoire sans créer une nouvelle catégorie de bugs comportementaux.

Les premiers déploiements de Claude Code et de Prisma renforcent les arguments de Bun. Ils ne couvrent toutefois pas toute la diversité des combinaisons de paquets, des systèmes d’exploitation, des modules natifs et des profils de charge de travail.

Une utilisation à grande échelle exposera des chemins de code que la suite interne de Bun n’a jamais parcourus. Des résultats stables sur plusieurs cycles de publication constitueraient des preuves plus solides que les benchmarks de lancement.

Le deuxième indicateur sera la taille et la conception de la surface Rust unsafe de Bun. Les chiffres bruts doivent être contextualisés, car les runtimes fortement dépendants des interfaces FFI ne peuvent pas éliminer complètement le code unsafe.

La question la plus pertinente est de savoir si les opérations unsafe sont regroupées derrière de petites interfaces documentées. Chaque interface devrait préciser les hypothèses relatives à la durée de vie, à l’aliasing, à la propriété et à la sûreté des threads que les appelants doivent respecter.

Des audits indépendants renforceraient ce travail. Les problèmes détectés publiquement par Miri, les résultats des sanitizers et les conclusions du fuzzing devraient également donner lieu à des correctifs visibles accompagnés de tests de régression.

Si l’utilisation d’unsafe diminue tandis que Bun préserve ses performances et sa compatibilité, l’argument en faveur de la sécurité de la réécriture gagnera en solidité. Des défaillances répétées liées aux durées de vie au sein d’interfaces sûres l’affaibliraient.

Le troisième indicateur sera la capacité d’un autre projet mature à reproduire la méthode de migration de Bun. Bun disposait d’un point de départ exceptionnellement favorable : une vaste couverture de tests, un architecte principal unique et un propriétaire ayant accès à un modèle en préversion.

Une deuxième migration réussie devrait démontrer davantage qu’une génération de code rapide. Elle devrait documenter la revue humaine, la détection des défauts, les contrôles opérationnels et la maintenance après publication.

Si ces résultats se répètent, les migrations de langage assistées par l’IA pourraient devenir une option courante pour les projets paralysés par des années de coûts de réécriture accumulés.

Si Bun reste une démonstration isolée, la portée de son enseignement sera plus limitée. La prouesse conserverait toute son importance, mais elle en dirait davantage sur l’infrastructure de test de Bun que sur le développement logiciel en général.

L’enjeu global n’oppose pas Rust à Zig. Il oppose la vitesse permise par la génération automatique aux preuves indispensables pour pouvoir faire confiance aux logiciels fondamentaux.

Bun a fait passer cet enjeu des projets expérimentaux à un environnement d’exécution comptant plus de 22 millions de téléchargements mensuels. Anthropic a également intégré le résultat à Claude Code avant même que le débat public ne soit tranché.

Ce choix apporte à Bun de précieux retours issus de la production. Il oblige également Anthropic à démontrer que ses agents de programmation sont capables d’assurer la maintenance de ce qu’ils génèrent.

Avant d’entreprendre des migrations à haut risque, les développeurs devraient suivre les notes de version, les signalements de sécurité non résolus et les résultats de déploiements indépendants. Ils devraient également tester leurs propres dépendances sous des charges réalistes.

La réécriture de Bun en Rust après son acquisition par Anthropic a déjà montré qu’un portage assisté par l’IA pouvait franchir un seuil d’échelle jusque-là jugé prohibitif.

Reste à savoir si son processus de vérification pourra suivre le rythme de son processus de génération. Il faudra surveiller les performances de Bun 1.4 en conditions réelles, les audits du code unsafe et le prochain projet d’envergure qui tentera d’appliquer la même méthode.