Votre Stack de Code IA N'a Pas de Cordon d'Arrêt d'Urgence. C'est Pourquoi Elle Plante.
Jusqu'à présent, vous choisissiez un langage de programmation selon ce que vous connaissiez, ce que votre équipe maîtrisait, ou ce qu'exigeait le projet. Python pour les scripts de données, Go pour les services backend, C ou assembleur pour les pilotes. La logique était simple : un humain à l'aise avec un langage, c'est un humain qui livre.
Cette logique est morte.
Bun a réécrit 960 000 lignes de Zig en Rust en 6 jours avec Claude comme agent principal. 1 009 257 lignes ajoutées, 6 755 commits, 99,8% des tests existants qui passent. Le résultat : 13 044 blocs unsafe dans le Rust généré par IA, contre 73 dans uv, le gestionnaire de paquets Python d'Astral (350 000 lignes de Rust écrites à la main, pour comparaison). Le compilateur Rust a dit oui à tout. Les humains ont dit non. 13 044 fois. La différence n'était pas l'agent. C'était le cordon d'arrêt d'urgence.
L'humain n'écrit plus de code. Il décrit, et l'agent écrit. Claude Code, Cursor, Copilot Workspace (l'interface importe peu). L'agent ne trouve pas Rust intimidant. Il n'a pas besoin de 3 ans pour intérioriser le borrow checker. Il écrit dans n'importe quel langage à la même vitesse, avec la même indifférence.
Alors quand vous démarrez un nouveau projet, la question change. Pas quel langage vous connaissez, mais quel langage dit à l'agent ce qu'il a fait de travers, assez vite pour l'arrêter avant que 500 lignes de plus s'empilent sur l'erreur ?

La CI L'a Appelé du Foutoir
PR #30412 mergée le 14 mai. 1 009 257 lignes de nouveau Rust. 4 024 supprimées. 2 188 fichiers modifiés. 6 jours du premier commit au main. Le binaire a rétréci de 3 à 8 MB. 99,8% de la suite de tests passée sur Linux x64.
La CI de GitHub a ensuite auto-taggé la PR de suppression Zig "ai slop." Personne n'avait configuré cette règle manuellement.
La discussion Hacker News a fait 742 commentaires, 667 points. La presse tech a couvert le chiffre qui fait un bon titre : 1 million de lignes en 6 jours. Ce qui a eu moins de couverture était la note structurelle : 13 044 blocs unsafe dans le Rust généré par IA, contre 73 dans uv, un projet Rust comparable de 350 000 lignes écrit entièrement à la main. Environ 178x plus de blocs unsafe au total. La densité par ligne de code donne environ 62x.
Le compilateur Rust a approuvé chacune de ces lignes.
Jarred Sumner, qui a construit Bun, a confirmé que l'équipe "ne tape plus de code nous-mêmes depuis plusieurs mois." Le passage de Zig à Rust était en partie forcé : l'équipe core de Zig a une politique explicite de non-contributions-IA, qui est devenue incompatible avec le workflow de Bun au moment où Anthropic a acquis le projet en décembre 2025. Plutôt que de combattre la culture upstream, l'équipe a changé de langage.
Ce n'est pas une réécriture ratée. Le code fonctionne. C'est une démonstration de ce qui passe quand on génère à vitesse sans le bon mécanisme de rejet.
Tout le Monde Dit Rust. Personne Ne Dit Pourquoi
Demandez à un dev pourquoi les agents devraient utiliser Rust et vous obtenez la réponse performance. Binaires plus rapides, sécurité mémoire, abstractions à coût zéro. La réponse n'est pas fausse, c'est juste la mauvaise raison pour les agents spécifiquement.
Rust a dominé le sondage "langage le plus aimé" de Stack Overflow chaque année depuis 2016. Le sondage ne demande pas si les répondants sont ceux qui l'écrivent réellement. Longtemps "le plus aimé" et "le plus utilisé" étaient des listes très séparées (le borrow checker fait ça aux courbes d'adoption). Les agents n'ont pas de courbes d'adoption. Ils n'ont pas de sentiments sur le borrow checker. Ils ont une boucle de compilation.
Les chiffres de benchmark runtime ne changent pas la boucle de feedback de l'agent. Un binaire Rust qui tourne 40% plus vite que Go à l'exécution est orthogonal à savoir si l'agent écrit du meilleur code pendant la génération. La vitesse du binaire n'affecte pas la rapidité avec laquelle l'agent attrape les erreurs.
Ce qui compte c'est à quelle vitesse, et avec quelle précision, l'environnement dit à l'agent qu'il a merdé.
La syntaxe est valide, la sémantique est cassée, et il n'y a pas de signal jusqu'à ce que quelque chose plante au runtime. À ce moment-là, 3 fonctions de plus ont été écrites par-dessus l'hypothèse cassée. La chaîne ne s'est jamais arrêtée. Rust dit à l'agent immédiatement : échec de compilation, message d'erreur, localisation, incompatibilité de type, chemin vers la correction. L'agent lit, corrige, relance.
Le Cordon d'Arrêt d'Urgence
Dans les usines Toyota des années 1950, ils ont installé un cordon qui courait le long de chaque ligne de production. N'importe quel ouvrier pouvait le tirer à tout moment. Toute la ligne s'arrêtait. Une pièce défectueuse arrivait, le cordon était tiré, le problème était réglé avant que le composant suivant soit attaché par-dessus.
Ils l'appelaient le cordon andon. Un arrêt de 2 minutes coûtait moins cher que 40 minutes de retravail à la fin de la ligne. La contrainte rendait le système global plus rapide, pas plus lent.
Le compilateur est le cordon andon pour l'agent. La boucle fonctionne comme ça : l'agent écrit du code, le compilateur le vérifie, le compilateur soit laisse passer le code soit tire le cordon et émet un diagnostic structuré. L'agent lit le diagnostic, corrige le problème, et relance. Sans le cordon, l'agent écrit 500 lignes par-dessus une hypothèse cassée et le problème remonte au runtime, 3 sessions plus tard, dans une stack trace qui pointe vers un symptôme au lieu de la cause. Avec le cordon, le problème remonte en secondes, dans une sortie de compilateur assez spécifique pour que l'agent puisse agir immédiatement.
C'est la vraie variable dans la qualité du code assisté par IA : pas quel modèle vous utilisez, pas avec quelle attention vous promptez, mais si l'environnement tire le cordon assez vite et avec assez de précision diagnostique pour que l'agent puisse s'auto-corriger avant que la dette s'accumule.
(Complètement hors sujet : j'ai regardé de vieux dessins animés Hanna-Barbera avec mon gamin cette semaine et je n'arrête pas de penser à comment le style d'animation à budget-frames-limité est devenu une esthétique que les gens imitent encore longtemps après que la contrainte budgétaire qui l'a créée ait disparu. Une limite de production câblée dans un medium. Rien à voir avec les compilateurs, juste comment mon cerveau fonctionne.)
La richesse du cordon compte autant que son existence. Un compilateur qui dit "erreur ligne 42" donne à l'agent une localisation. Un compilateur qui dit "vous essayez de multiplier Option<&u32> par u32 ligne 42, appelez .unwrap() ou matchez sur l'Option d'abord" donne à l'agent une localisation, les deux types, ce qui a été tenté, et un chemin de réparation. L'agent n'a besoin de rien inférer. Il lit, applique, relance.
C'est le même principe qui explique pourquoi les CLI battent MCP pour les agents IA. L'environnement que vous choisissez détermine combien de signal revient quand quelque chose casse. Le choix du langage est cette même décision à un niveau plus bas.
De Pas de Cordon à Cordon Complet
Même scenario à travers le spectre. Vous avez un dictionnaire. Une clé manque. Vous essayez d'utiliser la valeur en arithmétique.
Python : pas de cordon.
data = {"price": 100}
total = data["quantity"] * data["price"]
KeyError: 'quantity' frappe au runtime, possiblement 3 fonctions en aval, possiblement en production. L'agent avait zéro signal au moment de la génération. La chaîne a tourné. La pièce était défectueuse. Personne n'a tiré le cordon parce qu'il n'y avait pas de cordon à tirer.
TypeScript avec noUncheckedIndexedAccess : cordon partiel.
const data: Record<string, number> = { price: 100 };
const quantity = data["quantity"]; // type: number | undefined
const total = quantity * data["price"];
// TS2532: Object is possibly 'undefined'
Attrapé avant l'exécution. Message court, actionnable : localisation et contrainte de type. TypeScript n'aidera pas avec la disposition mémoire ou la sécurité des threads, mais pour la logique couche-application il attrape cette classe d'erreur de manière fiable.
Go : cordon syntaxique, pas de cordon sémantique.
data := map[string]int{"price": 100}
total := data["quantity"] * data["price"]
fmt.Println(total) // affiche 0, pas d'erreur
Go refuse de compiler les imports inutilisés ou les variables inutilisées. Vraie hygiène. Mais les lookups de map sur des clés manquantes retournent la valeur zéro silencieusement. data["quantity"] retourne 0. total est 0. La fonction continue. Quelque chose en aval reçoit un mauvais nombre, et le message d'erreur remonte 3 fonctions plus tard pointant vers un symptôme. Stack Overflow appelle ça "juste comment Go fonctionne." Votre agent appelle ça un bug.
Go compile en environ 2 secondes sur une codebase de service typique. Rust prend 30 secondes ou plus sur du code comparable. Je pense que TypeScript strict mode devance réellement Go pour la plupart des cas d'usage de services web, mais je pourrais me tromper pour les équipes avec de lourdes exigences de concurrence. Le cordon de Go est réel, il est juste étroit : la structure est attrapée, la sémantique non.
Rust : cordon complet.
use std::collections::HashMap;
let mut data = HashMap::new();
data.insert("price", 100u32);
let quantity = data.get("quantity"); // type: Option<&u32>
let total = quantity * data.get("price").unwrap_or(&0);
error[E0369]: cannot multiply `Option<&u32>` by `u32`
--> src/main.rs:8:21
|
8 | let total = quantity * data.get("price").unwrap_or(&0);
| ^^^^^^^^
| Option<&u32>
help: use `Option::unwrap_or`, `Option::unwrap_or_else`,
or match to handle the None variant before multiplying
Localisation, les deux types, ce qui a été tenté, et un chemin de réparation (4 lignes). L'agent lit, applique, relance. Le compilateur Rust sonne comme s'il avait un intérêt personnel dans votre succès, et pour un agent, c'est exactement ce que vous voulez d'un outil.
Ada : cordon maximum.
Ada a été conçu en 1983 pour que les erreurs ne tuent pas les gens dans les systèmes embarqués militaires. Variables non initialisées, débordement d'entiers, violations de bornes de tableaux, conversions de types implicites : tout attrapé au moment de la compilation, par défaut, avec des diagnostics assez précis pour sembler confrontants. Le rover martien tourne sur Ada. Le télescope spatial James Webb tourne sur Ada. Les compilateurs en question n'ont jamais une seule fois demandé si un humain avait envie de gérer ça aujourd'hui.
L'industrie a largement rejeté Ada pour l'usage logiciel général parce que la strictesse était trop pénible pour les développeurs humains. Trop de cérémonie. Trop de choses nécessitant une annotation explicite.
Ada : trop strict pour les humains. Les agents s'en fichent.
La Vitesse Sans Cordon C'est de la Dette
Les ceintures de sécurité sont devenues obligatoires quand les voitures sont devenues rapides, pas quand elles sont devenues lentes. Les coupe-circuits ont été ajoutés aux marchés financiers après que le trading algorithmique a commencé à exécuter des milliers d'ordres par seconde sans rien pour les arrêter. Le pattern : la vitesse de génération a besoin d'infrastructure de rejet à l'échelle correspondante.
Les 13 044 blocs unsafe dans la réécriture de Bun ne sont pas un échec de la génération de code de Claude. Ce sont les endroits où l'agent a contourné le cordon délibérément, utilisant le mot-clé unsafe de Rust pour bypasser le borrow checker sur des sections sémantiquement complexes. Le cordon était là. L'agent a choisi de le déconnecter à ces endroits. La dette est structurelle, auditable, et l'équipe Bun va la traiter. Mais elle existe parce que la vitesse de génération a dépassé la boucle de feedback.
Votre stack de vibe coding fait tourner le même pattern à plus petite échelle. Ce que les tutoriels Claude Code ratent sur la production inclut ces décisions niveau-environnement : quel compilateur, quels paramètres de strictesse, quel système de types (défini avant le premier prompt).
Pour une SaaS Next.js : TypeScript avec strict: true et noUncheckedIndexedAccess activé. Attrape la classe d'erreurs que les agents génèrent le plus souvent au niveau couche application.
Pour les services backend ou CLI : Go ou TypeScript selon les contraintes de performance. La boucle de compilation 2-secondes de Go rend l'itération rapide même avec des garanties sémantiques plus faibles.
Pour le logiciel système, runtimes edge, tout ce qui touche la mémoire directement : Rust. Pas pour la performance. Pour le compilateur.
Pour le logiciel de guidage de missiles : Ada. (Personne ne demande, mais la réponse c'est Ada.)
2 prompts pour la prochaine fois que vous démarrez un projet ou auditez une codebase existante :
Je démarre un projet où les agents IA vont écrire la plupart du code.
Je veux le langage qui donne à l'agent le feedback compile-time le plus riche
quand il fait des erreurs. Ignore ma familiarité personnelle avec le langage.
Type de projet : [app saas / outil CLI / service système / autre].
Recommande un langage et sa configuration compilateur/type la plus stricte,
optimisée pour la qualité du signal d'erreur agent, pas le confort développeur humain.
J'ai une codebase [langage] où les agents IA génèrent la plupart du code.
Quels flags de compilateur, paramètres de type checker, et règles de linter devrais-je
activer pour attraper plus d'erreurs au moment de la compilation avant qu'elles frappent le runtime ?
Donne-moi une liste priorisée du plus facile à activer au plus agressif.
J'utilise Claude Code tous les jours. Bun est le runtime en dessous. Je ne savais pas jusqu'à la semaine dernière que ce runtime tourne sur 1M de lignes écrites par Claude en 6 jours, avec 13 044 blocs unsafe en attente d'audit.
Ça ne me fait pas peur. Les tests passent. Jarred Sumner n'est pas du genre à laisser une grenade dégoupillée en prod.
Ce que ça m'a fait faire c'est regarder mes propres pipelines. Les endroits où j'ai laissé de la place à l'agent pour générer vite sans filet. TypeScript qui tourne sans strict: true, validation de schéma qui traîne dans un commentaire au lieu d'une contrainte (partout où le compilateur ne tire pas le cordon, les bugs se collectent sous d'autres noms).
Dans votre codebase, ils n'apparaissent pas comme des blocs unsafe. Ils apparaissent comme des bugs prod, 6 semaines plus tard.
Sources
- Bun Rewrites 960K Lines of Zig to Rust Using Claude, AI Weekly, May 2026
- Bun Rust Rewrite Merged: The 13,000 Unsafe Block Problem, ByteIota, May 14, 2026
- Rewrite Bun, EarlyTerms, May 2026
- Anthropic's Bun Rust Rewrite Merged at Speed of AI, The Register, May 14, 2026
Cet article peut contenir des liens d'affiliation. Si vous cliquez dessus, je pourrais gagner une petite commission (ça ne vous coûte rien, et ça m'aide à continuer de livrer des articles de qualité chaque jour pour votre plaisir de lecture).