Il y a des textes de gouvernance qu’on lit en diagonale et des textes qu’on relit trois fois. Celui publié le 5 août 2026 par les mainteneurs de rust-lang/rust appartient à la seconde catégorie, et pas à cause de sa longueur — il est court.
Sa force tient à une construction en creux. Plutôt que de lister ce qui est interdit, il énumère ce qui est permis : un modèle de langage peut répondre à des questions, analyser, distiller, affiner, vérifier, suggérer, relire. Sept verbes. Puis une exclusion unique et sans ambiguïté : créer.
J’ai passé les 48 heures suivantes à réécrire les règles de contribution de nos deux projets. Non pas parce que Rust fait autorité — mais parce que ce découpage nomme précisément ce que nous n’arrivions pas à formuler depuis un an.
Ce que dit exactement le texte — et ce qu’il ne dit pas
Reprenons la liste, parce que la couverture qu’en ont faite les agrégateurs l’a largement aplatie en « Rust interdit l’IA », ce qui est faux.
Les sept usages autorisés partagent une caractéristique : ils s’appliquent à un artefact qui existe déjà. Répondre à une question suppose la question. Analyser, vérifier et relire supposent du code. Distiller et affiner supposent un brouillon. Suggérer suppose un contexte. Dans chacun de ces cas, le modèle intervient sur une matière produite par un humain, et la responsabilité intellectuelle reste identifiable.
L’exclusion de « créer » vise l’inverse : la production d’un artefact original ensuite soumis comme contribution. Cela couvre le code, mais aussi — et le texte est explicite là-dessus — le contenu des tickets et de la documentation. Un rapport de bug rédigé intégralement par un modèle tombe sous la même règle qu’une pull request générée.
Ce que le texte ne dit pas mérite autant d’attention. Il ne prévoit aucun mécanisme de détection. Il n’exige pas de déclaration formelle. Il ne menace d’aucune sanction graduée. C’est une norme de comportement adossée à la responsabilité du contributeur, pas un dispositif de contrôle — et cette absence est un choix, pas un oubli.
💡 Notre avis d’expert n°1
« Le génie de cette formulation, c’est qu’elle ne parle jamais de qualité. Elle ne dit pas que le code généré est mauvais — affirmation invérifiable et de toute façon fausse dans bien des cas. Elle dit que la création engage une responsabilité que l’outil ne peut pas porter. C’est un argument juridique et organisationnel, pas technique. Il est donc beaucoup plus difficile à contester. »
Pourquoi c’est une décision d’économie, pas d’idéologie
Pour comprendre la politique, il faut regarder où se situe réellement le coût dans un projet de cette taille.
Un dépôt comme rust-lang/rust ne manque pas de contributions. Il manque de temps de mainteneur. Chaque pull request consomme de l’attention experte : comprendre l’intention, vérifier les cas limites, évaluer l’impact sur la compatibilité, arbitrer la dette introduite. Cette ressource est rare, non extensible, et elle ne bénéficie d’aucun gain de productivité comparable à celui de la génération.
Or les modèles de langage font exploser l’offre du côté le moins cher de la chaîne. Le résultat est une asymétrie brutale : produire cent lignes coûte désormais quelques secondes, les relire sérieusement coûte toujours vingt minutes. Un projet qui accepte sans condition la contribution générée transfère mécaniquement le coût du contributeur vers le mainteneur.
Vu sous cet angle, la politique de Rust n’est pas une prise de position sur la valeur de l’IA. C’est une mesure de protection d’une ressource critique — la même logique qui pousse un projet à exiger des tests, un message de commit explicite, ou une issue préalable pour les changements structurants.
Ce que nous avons changé dans nos propres règles
Nos deux projets — une bibliothèque de parsing et un outil interne open-sourcé — reçoivent une trentaine de contributions externes par an. Rien de comparable à Rust. Nous avons pourtant repris la structure, en l’adaptant à notre échelle.
Premier changement : nous avons abandonné l’idée de détecter. Nous avions envisagé d’exiger une déclaration d’usage. C’est inapplicable, invérifiable, et surtout cela installe une suspicion permanente. La politique de Rust nous a convaincus qu’il fallait déplacer la règle vers ce que le contributeur garantit, pas vers ce qu’il a utilisé.
Deuxième changement : nous exigeons désormais une explication du raisonnement pour toute contribution touchant plus de cinquante lignes. Pas un roman — trois à cinq phrases sur l’intention, les cas limites considérés et les alternatives écartées. Cette exigence est neutre vis-à-vis de l’outillage : elle est facile à satisfaire quand on comprend son code, difficile sinon.
Troisième changement : nous avons inversé la priorité de revue. Une contribution accompagnée de tests et d’une explication passe devant une contribution volumineuse sans contexte, quelle que soit son ancienneté dans la file. C’est le seul levier réel dont nous disposions pour protéger notre temps.
💡 Notre avis d’expert n°2
« La tentation, quand on lit cette politique, c’est de la copier telle quelle. C’est une erreur pour un petit projet. Rust protège une ressource saturée ; un projet de dix contributeurs a le problème strictement inverse — il cherche des contributions. Reprenez la logique de responsabilité, pas la restriction. »
Vos règles de contribution datent d’avant les LLM ?
Nous auditons la gouvernance technique de vos dépôts et rédigeons des règles applicables — celles qui protègent le temps de vos mainteneurs sans décourager les contributeurs sérieux.
Discutons-enCe que cela change pour les développeurs freelance et les équipes françaises
Trois conséquences pratiques, dans l’ordre de probabilité.
La première touche la présentation du travail. Si les grands projets s’alignent sur cette formulation — et l’effet d’imitation en gouvernance open source est puissant — alors la contribution non commentée devient un signal négatif par défaut. Cela vaut aussi en entreprise : une pull request de 400 lignes sans description passera de moins en moins bien, indépendamment de la question de l’IA.
La deuxième touche les questionnaires clients. Nous voyons déjà apparaître, dans les appels d’offres, des questions sur l’usage de l’IA dans la chaîne de production logicielle. Disposer d’une politique écrite, même courte, est en train de devenir un attendu contractuel plutôt qu’un raffinement. Le sujet rejoint celui de la traçabilité des dépendances, que traitent en détail nos confrères de WebGuard Agency.
La troisième touche le recrutement. Si la valeur se déplace de la production vers la compréhension et la revue, les critères d’évaluation suivent. C’est déjà visible sur les missions longues, où l’on demande de plus en plus explicitement une capacité à auditer du code existant — un mouvement que nous documentons dans notre analyse de l’adoption de Rust en entreprise, et qu’on retrouve côté intégration IA chez Plug-Tech.
💡 Notre avis d’expert n°3
« La faiblesse du texte, il faut la dire : la frontière entre “affiner” et “créer” est floue en pratique. Reformuler entièrement une fonction à partir d’un squelette de trois lignes, est-ce affiner ? Rust a fait le pari qu’une norme claire mais imparfaitement délimitée vaut mieux qu’une règle exhaustive et inapplicable. C’est probablement juste — mais les premiers arbitrages litigieux seront intéressants à suivre. »
Questions fréquentes
La politique de Rust interdit-elle totalement l’usage de l’IA ?
Non, et c’est le contresens le plus répandu depuis la publication. Le texte autorise explicitement sept usages : répondre à des questions, analyser, distiller, affiner, vérifier, suggérer et relire. Ce qui est refusé, c’est la production de contenu original soumis comme contribution — du code, mais aussi du texte d’issue ou de documentation. La distinction porte sur le rôle de l’outil, pas sur son existence.
Comment un projet peut-il vérifier si une contribution a été générée par un modèle ?
Il ne le peut pas de manière fiable, et aucun détecteur ne règle la question. C’est précisément pourquoi la politique de Rust est formulée comme une règle de responsabilité et non comme un contrôle technique : le contributeur engage sa compréhension du code qu’il soumet. Un projet qui espère filtrer par la détection se prépare à des faux positifs pénibles et à une défiance inutile.
Faut-il copier cette politique dans son propre projet ?
La formulation est reprenable, mais l’équilibre dépend de la taille du projet. Rust reçoit un volume de contributions qui rend le coût de revue dominant : sa politique protège le temps des mainteneurs. Un projet de dix contributeurs a le problème inverse et gagnera plutôt à exiger la transparence sur l’usage de l’IA qu’à en restreindre la portée.
Quel impact sur les développeurs freelance qui contribuent à l’open source ?
L’impact concret est sur la manière de présenter son travail. Une contribution accompagnée d’une explication du raisonnement, des cas limites envisagés et des tests ajoutés passe la revue quel que soit l’outillage utilisé. Une contribution volumineuse et non commentée déclenchera désormais une suspicion coûteuse, indépendamment de sa qualité réelle.
Le code est devenu gratuit. La compréhension, non.
Nous accompagnons les équipes françaises sur la revue, la gouvernance de dépôt et le recrutement de profils capables d’auditer du code qu’ils n’ont pas écrit.
Discutons-en