Redox OS bannit le code IA — et je les comprends

Quand Redox OS, le système d'exploitation écrit en Rust, a annoncé fin mars qu'il refuserait désormais toute contribution générée par IA et bannirait les contributeurs qui tenteraient d'en soumettre, la communauté a hurlé au rétrograde. « On est en 2026, pas en 2020. » « Les LLMs écrivent du meilleur code que 80% des humains. » « C'est une posture idéologique déconnectée. » Moi, j'ai lu l'annonce et j'ai pensé : ils ont raison. Non pas parce que le code IA est mauvais dans l'absolu. Mais parce que dans le contexte spécifique de Redox — un OS, du Rust, de la safety critical — les trois bugs critiques que j'ai vus dans mes propres projets en 6 mois me donnent complètement raison à leur décision. Voici pourquoi.

L'annonce de Redox en 30 secondes

Le 21 mars 2026, Jeremy Soller, mainteneur principal de Redox OS, publie un post sur le blog officiel : toute contribution qui utilise du code généré par IA (Claude, Copilot, ChatGPT, Cursor, tout) est désormais interdite. La détection se fait via analyse stylistique, vérification de patterns de code IA, et auto-déclaration du contributeur. Un contributeur qui triche est banni à vie.

Les raisons invoquées :

1. 1.Impossibilité d'attribuer le copyright de manière claire
2. 2.Risque légal lié à la décision US Copyright Office de 2023
3. 3.Qualité inégale du code IA sur des projets low-level
4. 4.Culture communautaire basée sur l'apprentissage mutuel

Les trois premières raisons sont débattues. La quatrième, c'est celle qui m'a fait tiquer.

Les 3 bugs critiques que j'ai vus moi-même

Je précise : je suis pro-IA pour le dev. J'utilise Claude Code tous les jours, j'ai écrit un livre sur la Ralph Loop, je gagne ma vie en partie grâce à ces outils. Mais j'ai aussi vu 3 bugs sur mes propres projets en 6 mois qui n'auraient pas existé si je n'avais pas utilisé de code IA. Les voici.

Bug 1 : le `unsafe` silencieux dans un refactor

Sur un projet Rust perso (un parser de format binaire), j'ai demandé à Claude de « refactorer cette fonction pour améliorer les perfs ». La fonction initiale était safe, utilisait des &[u8] bien typés. Claude a produit une version avec un bloc unsafe au milieu pour éviter un bounds check. Le code compilait, passait les tests, et était effectivement plus rapide.

Sauf que le unsafe introduisait une UB (undefined behavior) sur un input particulier que les tests ne couvraient pas : un buffer de longueur exactement usize::MAX / 2 + 1. Pas détectable en review rapide parce que le unsafe était entouré d'un commentaire plausible (// SAFETY: bounds already checked above). Sauf que non, le bounds check n'avait pas été fait correctement.

Temps perdu pour détecter : 4 jours après que j'ai déployé. Le crash est arrivé en prod sur un fichier corrompu.

Bug 2 : la dépendance qui n'existait pas

Sur un autre projet (scraper Python), Claude a proposé d'utiliser la lib fast_html_parser avec un exemple de code complet. Je l'ai copié, pip install fast_html_parser. La lib s'est installée. Les tests passaient. Ce n'est qu'en lisant le code de la lib que j'ai réalisé : cette lib n'est pas celle que Claude pensait. C'est un fork obscur, pas maintenu, avec des bugs connus.

Claude avait halluciné l'API de fast_html_parser en se basant sur ce qu'il imaginait cohérent — et par pur hasard, une lib avec ce nom existait. Si ça avait été une lib vide avec juste setup.py, j'aurais remarqué. Là, c'était pire : il y avait des fonctions, mais pas celles dont j'avais besoin.

Temps perdu : 2 jours pour comprendre que toute la stack était construite sur une hallucination.

Bug 3 : le try/except qui mangeait tout

Sur un projet Flask, Claude a ajouté un gestionnaire d'erreurs global :

@app.errorhandler(Exception)
def handle_any_error(e):
    logger.error(f"Error: {e}")
    return jsonify({"error": "Internal error"}), 500

Ça semble propre. Ça cache les tracebacks, ça logue, ça retourne une erreur 500 propre. Le problème : ça attrape aussi les SystemExit et les KeyboardInterrupt. Résultat : je ne pouvais plus arrêter le serveur avec Ctrl+C en dev, et pire, un bug qui devrait planter le processus le faisait continuer dans un état corrompu.

Le fix : attraper Exception ne suffit pas, il faut être plus précis ou exclure les exceptions système. Claude ne l'a pas vu, et ce type de bug n'apparaît jamais dans les tests unitaires.

Le point commun des 3 bugs

Ces trois bugs partagent une caractéristique : ils passent les tests et la review rapide. Ils sont invisibles à moins de lire le code avec la compréhension profonde de ce qu'il fait réellement. Claude produit du code qui ressemble à du bon code, avec des commentaires plausibles et des patterns familiers. La différence entre « ressembler » et « être » est exactement ce qui casse en prod.

Sur un projet perso, je paye le prix de ces bugs moi-même et j'en sors grandissant. Sur un OS comme Redox, ces mêmes bugs pourraient causer des kernel panics, des data races, des failles de sécurité qui touchent des milliers d'utilisateurs. Le coût n'est pas le même.

Pourquoi la raison culturelle est la plus importante

Les 3 premières raisons invoquées par Redox (copyright, légal, qualité) sont débattables. La quatrième — la culture d'apprentissage mutuel — est celle qui me convainc.

Un projet open source n'est pas qu'un produit. C'est aussi une communauté d'apprentissage. Les juniors y apprennent en lisant les PR des seniors, en faisant des reviews, en reproduisant des patterns. Si 50% du code est généré par un LLM, les juniors apprennent de copies statistiques, pas de vraies décisions humaines.

Le problème n'est pas la qualité du code IA. Le problème, c'est qu'un projet devient impossible à faire évoluer quand personne ne comprend réellement pourquoi le code est comme ça. Les seniors humains savent dire « j'ai choisi cette approche parce que... ». Un LLM produit du code qui marche sans savoir pourquoi il l'a fait comme ça.

Ce que je fais personnellement depuis

Je ne suis pas Redox. Je n'ai pas besoin des mêmes garanties. Mais j'ai adopté 3 règles après ces 3 bugs :

1. 1.Aucun unsafe Rust généré par IA sans review d'un Rustacean humain (j'en connais 2).
2. 2.Toute lib nouvelle ajoutée par une suggestion IA est vérifiée manuellement (crates.io pour Rust, PyPI pour Python — lire le repo, les issues, les derniers commits).
3. 3.Les gestionnaires d'erreurs globaux sont écrits à la main, jamais générés. C'est 15 minutes de plus, mais 2 jours de moins en prod.

Ce n'est pas une interdiction comme Redox. C'est une friction ciblée sur les zones où les bugs IA sont les plus coûteux.

Ma position finale

Redox a raison de bannir le code IA sur leur projet. Pas parce que l'IA est mauvaise. Parce que le coût d'un bug sur un kernel est disproportionné par rapport au gain de vélocité, et parce que la culture d'apprentissage mutuel est fragile face à la génération massive.

Les développeurs qui hurlent à la posture idéologique confondent deux choses : « l'IA est utile pour le code » (vrai) et « l'IA est utile pour tout code dans tous les contextes » (faux). Les contextes existent. Un jeu Unity en solo n'a pas les mêmes contraintes qu'un OS en Rust.

Ce qu'il faut retenir

1. 1.Redox OS a de bonnes raisons de bannir le code IA — surtout la raison culturelle (préservation de l'apprentissage communautaire).
2. 2.3 bugs personnels en 6 mois confirment que le code IA a des patterns d'erreurs spécifiques et coûteux.
3. 3.Le code IA est utile là où les bugs sont rattrapables, pas dans les zones critiques.
4. 4.La friction ciblée (unsafe, libs nouvelles, gestionnaires d'erreurs) est une alternative pragmatique à l'interdiction.

Pour aller plus loin sur les patterns de workflow qui rendent l'usage du code IA plus sûr tout en gardant le gain de productivité, j'ai écrit un livre sur la Ralph Loop :

La Boucle Ralph

Guide Pratique du Coding Autonome par IA.

Découvrir →