Le projet de politique de Rust sur les LLM trace la bonne limite

Une demande d’intégration Rust Forge ouverte le 17 avril 2026 propose une politique d’usage des LLM pour rust-lang/rust. Au 17 mai 2026, cette demande d’intégration est toujours ouverte, avec 65 commentaires de ticket et 284 commentaires de revue : la proposition n’est donc pas encore une politique adoptée.¹

Ce projet compte déjà, parce qu’il nomme la limite que la plupart des recommandations sur le code assisté par IA évitent : les LLM peuvent aider à réfléchir, apprendre, vérifier et expérimenter, mais ils ne doivent pas remplacer l’écriture humaine là où un projet préserve le jugement, le goût, la responsabilité et la compréhension partagée.²

La proposition s’inscrit aussi dans les normes de contribution existantes de Rust. Le guide de contribution actuel de Rust Forge demande déjà aux contributeurs d’instaurer la confiance, de respecter le temps des relecteurs, de soumettre un travail qu’ils comprennent pleinement, de le vérifier en détail avant envoi et de garder les commentaires concis.³ La politique de revue du compilateur indique également que les relecteurs doivent comprendre suffisamment le code examiné et que le temps de revue est limité.⁴ Le projet de politique sur les LLM rend ces attentes plus anciennes concrètes pour le travail assisté par IA.

TL;DR

Le projet Rust autorise l’usage privé de LLM pour apprendre, résumer, relire en privé, créer des outils personnels et expérimenter.² Il interdit les commentaires publics, les corps de tickets, les descriptions de demandes d’intégration, la documentation et les diagnostics du compilateur issus de LLM, ainsi que tout processus qui traite une revue par LLM comme suffisante pour fusionner ou rejeter du code.² Il crée une expérimentation étroite pour les changements de code créés par LLM : demandés, non critiques, déclarés, de haute qualité, bien testés et pleinement compris par l’auteur comme par le relecteur.² Ma lecture : cette politique fonctionne parce qu’elle optimise la responsabilité intellectuelle, pas le volume de production.

Points clés

• Pour les mainteneurs : une politique doit protéger la capacité de revue, la voix du projet et la responsabilité avant de parler de productivité.
• Pour les équipes de code assisté par IA : autorisez largement l’usage privé, mais tracez une limite plus ferme autour de l’écriture publique, de la documentation, des diagnostics et de l’autorité de fusion.
• Pour les contributeurs : la déclaration d’usage n’aide que si l’humain reste responsable du travail. « Le modèle l’a écrit » ne peut pas devenir une excuse.
• Pour les créateurs d’outils : les bots de revue ont besoin d’identités séparées, de pouvoir être bloqués, d’exercer une faible pression liée aux faux positifs et de rester consultatifs.
• Pour les équipes d’agents : la meilleure règle du projet est culturelle, pas technique : utiliser l’IA pour mieux écrire, pas pour écrire plus vite.²

Le projet sépare la réflexion de l’écriture

La plupart des politiques sur les LLM regroupent deux actes différents dans une seule catégorie : utiliser l’IA. Le projet Rust distingue la cognition privée de l’écriture publique.

La cognition privée est largement permise. Un contributeur peut poser des questions à un LLM sur la base de code, résumer des commentaires pour sa propre compréhension, relire en privé son code ou ses textes, créer des outils de développement personnels et générer des pistes de solution dont il s’inspire avant d’écrire sa propre solution.²

L’écriture publique, elle, rencontre une limite ferme. Le projet interdit de publier depuis un compte personnel des commentaires initialement créés par un LLM. La même règle couvre les corps de tickets et les descriptions de demandes d’intégration.² Il interdit aussi la documentation initialement créée par un LLM, y compris les commentaires source non triviaux, les commentaires de documentation, les commentaires de sûreté, les commentaires sur plusieurs paragraphes et les diagnostics du compilateur.²

Cette distinction paraît juste, car les artefacts publics portent la voix du projet. Les diagnostics du compilateur, les commentaires de sûreté et la documentation ne font pas que transmettre de l’information. Ils apprennent aux utilisateurs comment Rust pense. Ils deviennent aussi une charge de maintenance à long terme pour le projet.

Une prose générée par LLM peut sembler soignée tout en alourdissant cette charge. Le relecteur doit alors se demander : qui a choisi cette formulation, qui en comprend les implications, qui assume le cas limite et qui corrigera la confusion plus tard ? Le projet refuse qu’un contributeur externalise cette responsabilité tout en conservant la crédibilité d’un compte humain.

La règle la plus forte : pas de revue par IA comme autorité de fusion

Le projet interdit de traiter une revue par LLM comme condition suffisante pour fusionner ou rejeter un changement.² Les bots de revue peuvent exister, mais le projet exige qu’ils restent consultatifs. Les relecteurs doivent approuver explicitement un commentaire de LLM avant de bloquer une demande d’intégration, et les auteurs restent tenus de relire eux-mêmes leur travail.²

Cette règle évite un échec tentant. Des équipes peuvent ajouter une revue par IA et qualifier leur flux de travail de plus sûr, même lorsque le nouvel outil ne crée qu’un second flux d’affirmations que personne n’a le temps d’évaluer. Un bot peut trouver de vrais bugs. Il peut aussi produire des objections triviales, des conseils de style périmés, des contraintes hallucinées ou des commentaires assurés sur du code qu’il n’a pas compris.

Le projet Rust traite ce problème structurellement :

L’idée n’est pas que la revue par LLM n’a aucune valeur. L’idée est que l’autorité de revue appartient aux personnes et au processus du projet. Une machine peut assister le relecteur. Elle ne peut pas devenir le relecteur officiel.

L’exception pour le code est volontairement étroite

Le projet n’interdit pas tout code créé par LLM. Il crée une expérimentation pour les changements de code qui satisfont cinq conditions : demandés, non critiques, de haute qualité, bien testés et bien relus.²

Chaque mot compte.

Demandés signifie que le relecteur a accepté à l’avance de relire une demande d’intégration créée par LLM. Les nouveaux contributeurs ne peuvent pas emprunter cette voie avec un LLM sans avoir d’abord échangé avec le même relecteur que celui assigné à la PR.²

Non critiques tient les changements créés par IA à distance des zones où une erreur pourrait provoquer une régression de sûreté. Le projet cite l’outillage interne comme domaine plus plausible, et des zones comme le système de traits, la construction MIR ou le système de requêtes comme probablement inadaptées.²

De haute qualité signifie que le code doit atteindre au moins le même niveau que les autres changements. Le projet rejette explicitement les PR qui dégradent la qualité de la base de code.²

Bien testés relève l’exigence. Les PR créées par LLM sont soumises à des attentes de test plus élevées, parce que les LLM facilitent l’écriture de tests. Si aucune suite de tests existante ne couvre le code, l’auteur doit en écrire une nouvelle ou fermer la PR.²

Bien relus signifie que l’auteur comme le relecteur s’engagent à comprendre pleinement le code. La revue d’un membre du projet ne remplace pas la relecture personnelle.²

Cette expérimentation a une forme utile. Elle ne prétend pas que le code créé par IA ne peut pas aider. Elle refuse aussi la version paresseuse de la « contribution assistée par IA », où le contributeur génère un patch, demande aux mainteneurs de faire le tri, et n’investit aucun effort humain dans la compréhension.

Mieux, pas plus vite

La phrase la plus importante du projet dit que les LLM fonctionnent au mieux quand les gens les utilisent pour écrire mieux, pas plus vite.²

Cette phrase devrait devenir la norme par défaut du code assisté par IA.

La vitesse seule déplace le travail des auteurs vers les relecteurs. Un contributeur économise une heure en générant un patch, puis les mainteneurs passent trois heures à séparer le code utile des tests étranges, des commentaires gonflés, des diagnostics vagues et des choix de conception non assumés. Le projet y perd même si le diff finit par compiler.

Mieux écrire pose une autre question : l’outil a-t-il aidé l’humain à former une compréhension plus nette ? A-t-il trouvé un cas limite que l’auteur a vérifié ? A-t-il aidé à rédiger un test que l’auteur comprend ? A-t-il rendu la contribution finale plus facile à relire, maintenir et croire ?

Le projet Rust rend cette distinction applicable. L’usage privé de LLM peut améliorer la compréhension de l’auteur. L’écriture publique issue de LLM peut dégrader la compréhension partagée du projet. Le code expérimental créé par IA ne peut avancer que si la demande, le périmètre, la qualité, les tests et la revue portent tous la charge supplémentaire.

Cette combinaison vaut mieux que l’optimisme général comme que l’interdiction générale. Elle dit que la technologie peut aider, mais que le projet n’absorbera pas une production faiblement assumée simplement parce qu’un modèle l’a rendue peu coûteuse.

La section de modération évite les chasses aux sorcières

Le projet traite aussi l’application de la règle avec une attention inhabituelle. Il dit aux contributeurs qu’ils n’ont pas à jouer aux détectives sur l’usage de LLM. Si une violation semble claire, renvoyez à la politique. Si le cas paraît limite, signalez-le aux modérateurs et passez à autre chose.²

La même section traite la malhonnêteté sur l’usage de LLM comme un problème de code de conduite, mais précise aussi qu’il n’est pas acceptable de harceler des contributeurs parce qu’ils utilisent des LLM.² Cette association compte. Une politique qui invite à la suspicion peut empoisonner une communauté plus vite que le contenu généré par IA qu’elle essaie d’arrêter.

Une bonne politique sur l’IA a besoin de deux limites :

Le projet place la responsabilité sur le contributeur sans transformer chaque relecteur en enquêteur. Il protège la culture de revue autant que le code.

Ce que les autres projets devraient reprendre

La proposition Rust mérite l’attention parce qu’elle définit des rôles, pas des impressions.

Utilisez les LLM comme :

• un tuteur privé ;
• un relecteur privé ;
• un outil de résumé pour votre propre compréhension ;
• une aide à la découverte de bugs quand l’humain vérifie le bug ;
• une source d’expérimentation quand le relecteur accepte et que le périmètre reste peu risqué.

N’utilisez pas les LLM comme :

• l’auteur public de votre commentaire ;
• la voix de la documentation du projet ;
• l’auteur des diagnostics du compilateur ;
• un substitut à la revue humaine ;
• une excuse pour les tests que vous n’avez pas écrits ;
• un moyen de faire relire aux mainteneurs du code que vous ne comprenez pas.

Cette liste donne aux mainteneurs mieux qu’un argument moral. Elle leur donne une politique opérationnelle.

Ma lecture

Le projet correspond au problème de qualité créé par le code assisté par IA. Le code devient moins cher à produire. L’attention de revue, le goût, la cohérence, la voix du projet et la confiance sociale ne deviennent pas moins coûteux. La rareté remonte d’un cran.

Un projet qui optimise le volume de production noiera ses mainteneurs sous des diffs plausibles. Un projet qui optimise la responsabilité du travail peut encore utiliser l’IA, mais uniquement de façons qui rendent l’auteur humain plus compétent et le relecteur moins chargé.

Le projet Rust protège la couche rare. Il traite les diagnostics, commentaires, documents et l’autorité de revue comme une partie du projet, pas comme du texte interchangeable. Il traite les tests et la relecture personnelle comme des obligations, pas comme des accessoires. Il donne une voie à l’expérimentation, mais pas un chèque en blanc.

C’est la bonne direction pour les projets logiciels sérieux. Les règles exactes peuvent changer avant que Rust n’adopte quoi que ce soit. Leur forme de fond ne devrait pas changer : l’IA peut aider les gens à mieux travailler, mais l’humain doit toujours assumer la contribution.

FAQ

Cette politique Rust est-elle adoptée ?

Non. Au 17 mai 2026, la politique existe sous forme de demande d’intégration Rust Forge ouverte, intitulée « Add an LLM policy for rust-lang/rust ». La branche main actuelle de rust-lang/rust-forge ne contient pas encore src/policies/llm-usage.md.¹⁵

Le projet interdit-il tout usage de l’IA ?

Non. Le projet autorise sous conditions l’usage privé de LLM pour apprendre, résumer, relire, créer des outils personnels et générer des idées. Il crée aussi une expérimentation étroite pour du code créé par LLM, déclaré, demandé, non critique, de haute qualité, bien testé et bien relu.²

Qu’interdit le projet ?

Le projet interdit les commentaires publics, les corps de tickets, les descriptions de demandes d’intégration, la documentation et les diagnostics du compilateur issus de LLM, ainsi que le fait de traiter une revue par LLM comme suffisante pour fusionner ou rejeter du code.²

Pourquoi le projet est-il aussi strict avec la documentation et les diagnostics ?

La documentation et les diagnostics portent la voix du projet, guident les utilisateurs et créent des obligations de maintenance à long terme. Le projet autorise les LLM à aider la logique environnante dans certains cas, mais leur interdit de créer les messages eux-mêmes.²

Que devraient retenir les équipes de code assisté par IA de cette proposition ?

Séparez l’assistance privée de l’écriture publique. Exigez une déclaration quand l’IA affecte d’autres personnes. Gardez l’autorité de revue humaine. Relevez l’exigence de tests et de relecture personnelle lorsque l’IA aide à créer du code. Optimisez pour un meilleur travail, pas pour plus de production.

Références