Code assisté par IA : règles pour vos contributions

Que faire avant de soumettre du code assisté par IA en amont

Les projets open source publient désormais des politiques concernant le code assisté par IA, et ces politiques ne sont pas uniformes. L'habitude à prendre est donc simple : consultez la politique avant d'écrire le patch et soyez transparent lors de la soumission. Une règle prévaut dans tous les cas : ne soumettez jamais une ligne que vous ne pouvez pas expliquer lors de la revue.

Un patch correct sera rejeté si le projet interdit le code généré ou si vous avez dissimulé sa provenance. Les conséquences pèsent sur votre réputation, car un mainteneur qui découvre l'omission ultérieurement n'aura aucune raison de faire confiance au reste de votre historique. Quelques définitions préalables, car les politiques s'y réfèrent. Un LLM (large language model) est le modèle derrière votre assistant de codage. Une PR (pull request) sur GitHub est équivalente à une MR (merge request) sur GitLab, et tout ce qui suit s'applique aux deux. Le DCO (developer certificate of origin) est la ligne de signature située au bas d'un message de commit, et il s'avère être au cœur de tout le débat.

État des politiques open source sur le code généré par IA

Les projets se répartissent désormais en quatre catégories. Chaque exemple ci-dessous est daté, car ces textes évoluent rapidement.

Interdiction. Le conseil de Gentoo a voté le 14 avril 2024 qu'il est « expressément interdit de contribuer à Gentoo avec tout contenu créé à l'aide d'outils d'intelligence artificielle de traitement du langage naturel ». Les directives de commit de NetBSD qualifient la sortie d'un LLM de « code corrompu » qui « ne doit pas être soumis sans approbation écrite préalable du noyau ». Le document sur la provenance du code de QEMU, en date d'août 2026, indique toujours que le projet « REFUSERA toute contribution soupçonnée d'inclure ou de dériver de contenu généré par IA ».

Analyse uniquement. La plupart des interdictions sont plus limitées que ne le suggèrent les titres. Le document de QEMU précise que la politique « ne s'applique pas aux autres usages de l'IA, tels que la recherche d'API ou d'algorithmes, l'analyse statique ou le débogage, à condition que leur sortie ne soit pas incluse dans les contributions ». Vous pouvez utiliser l'agent pour lire le code. Vous ne pouvez pas livrer ce qu'il a écrit. Cette distinction constitue la ligne de conduite au sein de la plupart des projets restrictifs, et c'est celle que les gens omettent.

Divulgation obligatoire. Le conseil de Fedora a approuvé une politique sur les contributions assistées par IA en octobre 2025. Elle autorise les outils tout en faisant peser la responsabilité sur l'individu : le contributeur est l'auteur, est pleinement responsable de l'intégralité de la contribution, et doit divulguer lorsqu'une partie significative provient d'un outil sans modification. Le noyau Linux a ajouté une page sur les assistants de codage dans sa documentation de processus en décembre 2025, avec une mention pour enregistrer l'outil et une règle stricte sur les personnes habilitées à signer les commits.

Aucune règle écrite. C'est encore le cas le plus courant. Une prépublication de mai 2026 a étudié 1 000 dépôts GitHub populaires et en a trouvé 118 possédant une politique écrite sur l'IA. Le silence ne vaut pas autorisation. Posez la question en une phrase dans le gestionnaire de tickets avant d'écrire le patch ; la réponse deviendra un enregistrement public auquel vous pourrez vous référer ultérieurement.

Pourquoi les mainteneurs ont rédigé ces règles

La première raison est la charge de revue, et l'arithmétique ne joue que dans un sens. Un agent produit une merge request plausible de 400 lignes en une minute. Examiner correctement cette requête coûte un après-midi à un mainteneur, et la plupart des mainteneurs sont des bénévoles. Le coût de soumission est tombé à près de zéro. Le coût de revue, lui, n'a pas bougé.

curl illustre l'extrémité de cette courbe. Daniel Stenberg a rapporté mi-2025 qu'environ un cinquième des rapports de sécurité arrivant via le programme de bug bounty du projet étaient ce qu'il appelle du "AI slop" : des rapports qui nomment des fonctions réelles et des chemins de code réels, décrivent une attaque plausible, mais ne contiennent rien. Le projet a mis fin au programme de prime début 2026 plutôt que de continuer à financer ce flux. Il s'agissait de rapports plutôt que de patchs, mais c'est le même mécanisme qui fait qu'un mainteneur ouvre votre PR en étant déjà épuisé.

GNOME Calendar a formalisé le problème sous la forme d'une étiquette. En juin 2026, le projet a introduit "Probabilistically Automated" pour les merge requests montrant une "dépendance majeure ou totale à une 'intelligence' artificielle pour générer du code", et a nommé le symptôme avec précision : "généralement accompagné d'un manque de tests appropriés, et d'une finalisation des patchs basée sur le comportement théorique attendu plutôt que sur la correction du code". Relisez cette dernière phrase deux fois. Le code semble devoir fonctionner. Personne n'a vérifié s'il fonctionne réellement.

La seconde raison est la provenance, c'est-à-dire l'origine du code et sa licence. QEMU expose le conflit clairement : signer son commit (sign-off) affirme que vous "comprenez parfaitement le statut du droit d'auteur et de la licence du contenu" que vous contribuez, et le statut du droit d'auteur des sorties de modèles est incertain. Le conseil de Gentoo a donné la même raison, en plus de la qualité et de l'éthique. Vous n'êtes pas obligé d'être d'accord avec l'interprétation juridique. Vous devez simplement noter que c'est au mainteneur de trancher, pas à vous.

Comment trouver la politique d'IA d'un projet ?

Consultez ces emplacements, dans cet ordre.

• CONTRIBUTING.md à la racine du dépôt, puis .github/CONTRIBUTING.md, puis tout fichier DCO adjacent.
• La documentation développeur. QEMU conserve ses règles dans docs/devel/code-provenance.rst. Le noyau Linux conserve les siennes dans Documentation/process/coding-assistants.rst.
• Le site web ou le wiki du projet. La politique de Gentoo se trouve sur la page wiki du conseil, et celle de NetBSD figure dans les directives de commit.
• Le gestionnaire de tickets et les archives de la liste de diffusion. Une politique y existe généralement pendant des mois avant que quelqu'un ne l'inscrive dans le dépôt.

Depuis l'intérieur d'un checkout, un grep couvre la majeure partie du sujet :

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

Ensuite, lisez l'historique du projet, car la convention appliquée l'emporte sur tout résumé :

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

Un décompte à côté d'une valeur de trailer vous indique la forme que ce projet utilise réellement. Un résultat vide signifie que personne n'a effectué de divulgation sous cette forme ici, ce qui constitue également une information. Si le projet est hébergé sur GitHub et que le workflow vous est inconnu, le fonctionnement des pull requests et des forks sur GitHub couvre les mécanismes supposés par cette section.

Divulguer dans le trailer du commit, pas dans un commentaire

Un trailer est une ligne Key: value située dans le dernier paragraphe d'un message de commit. Git utilise déjà ce format pour Signed-off-by: et Co-authored-by:, et les outils l'analysent ; c'est donc la seule forme de divulgation qui accompagne le code dans l'arborescence.

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

Le noyau documente ce format sous le nom de Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2], et il est explicite sur la limite de cette ligne : "Les agents IA NE DOIVENT PAS ajouter de tags Signed-off-by. Seuls les humains peuvent légalement certifier le Developer Certificate of Origin (DCO)." Le nom de l'agent figure sur Assisted-by. Votre nom figure sur Signed-off-by. Ne laissez jamais un outil écrire le second, et ne le laissez jamais inventer une adresse Co-authored-by qui n'appartient à personne.

Les noms varient, copiez donc celui qui est local au lieu d'en inventer un. Un patch envoyé à la liste de diffusion de QEMU en mai 2026 proposait d'assouplir l'interdiction du projet pour les changements mécaniques, les tests, la documentation et les corrections de bugs de vingt lignes ou moins, enregistrés avec un trailer comme AI-used-for: tests, docs. En août 2026, il s'agit d'une proposition sur une liste de diffusion et le document validé refuse toujours le contenu généré. Un projet a changé sa position deux fois entre 2023 et 2026. Le prochain changement n'attendra pas, c'est pourquoi la méthode compte plus que la liste.

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

--trailer nécessite Git 2.32 ou une version plus récente. La seconde commande doit vous renvoyer la valeur telle quelle. Une ligne vide signifie que git n'a pas analysé le trailer, presque toujours parce qu'une ligne vide ou une phrase ordinaire se trouve dans le bloc de trailer au bas du message. Pour une série que vous avez déjà écrite, git rebase --signoff origin/main ajoute le sign-off à chaque commit, et git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt modifie un fichier de message.

Deux modes de défaillance méritent d'être anticipés. Un squash merge réécrit le message de commit ; sur un projet qui utilise le squash, répétez la divulgation dans la description de la PR là où le mainteneur la lira. De plus, un commentaire de revue n'est pas un enregistrement, car les commentaires peuvent être modifiés et n'atterrissent jamais dans l'historique git.

La précision est essentielle. Assisted-by sur un commit que vous avez tapé à la main est du bruit, et cela dévalue vos véritables divulgations. L'omettre sur un commit écrit par l'agent est ce qui met fin à la relation.

Que certifie réellement le Signed-off-by ?

Le DCO est un texte court, version 1.1, publié sur developercertificate.org et utilisé par le noyau, par QEMU et par beaucoup d'autres. Ajouter Signed-off-by: Your Name <you@example.com> signifie que vous le certifiez. Lisez ce que vous certifiez, car la plupart des gens le signent sans jamais le lire.

La clause (a) stipule que la contribution « a été créée en tout ou partie par moi et que j'ai le droit de la soumettre sous la licence open source indiquée dans le fichier ». La clause (b) couvre le travail basé sur du code open source antérieur que vous avez le droit de transmettre avec des modifications. La clause (c) couvre le code qui vous a été transmis par quelqu'un ayant certifié la même chose. La clause (d) indique que vous comprenez que la contribution et les informations personnelles contenues dans votre sign-off sont publiques et conservées indéfiniment.

Notez ce qui manque. Le DCO ne dit jamais que vous avez tapé chaque caractère. Il dit que vous avez le droit de soumettre le code sous cette licence. C'est pourquoi le code généré pose problème ici : la question n'est pas celle de la paternité, mais celle de votre capacité à justifier l'origine. La plupart des projets qui exigent un sign-off demandent également un nom réel, donc un pseudonyme échoue à la vérification. Ajoutez la ligne avec git commit -s, qui lit user.name et user.email depuis votre configuration git. Lorsqu'un bot DCO rejette votre PR et nomme le commit auquel il manque la ligne, git rebase --signoff origin/main et un force push sur votre branche corrigent le problème.

Signer un commit n'est pas la même chose que d'apposer un sign-off

git commit -s ajoute une ligne de texte. git commit -S crée une signature cryptographique sur l'objet commit en utilisant votre clé GPG ou SSH. Ils répondent à des questions différentes. La signature atteste que ce commit provient du détenteur de cette clé et qu'il n'a pas été modifié depuis. Elle ne dit rien sur l'origine du code contenu ; un commit signé rempli de code généré non divulgué reste signé, tout en constituant une violation de politique. Le sign-off est une déclaration sur l'origine. La signature est une déclaration sur l'identité. Les projets qui exigent les deux demanderont les deux.

Ne soumettez jamais de code que vous ne pouvez pas expliquer en revue

Voici le test, et il ne s'agit pas vraiment d'honnêteté. Pour chaque ligne : à quoi cela sert-il, et qu'est-ce qui casse sans cela ? Si l'une de ces réponses manque, le patch n'est pas prêt, car le commentaire de revue arrivera et votre réponse nécessitera une nouvelle génération. Les relecteurs le voient. C'est le moment où un contributeur devient une charge. Posez la même question sur les cas limites, les entrées vides, le chemin d'erreur, le second appelant.

Exécutez la chose. Compilez-la, lancez la suite de tests du projet et écrivez un reproducteur pour le bug que vous prétendez corriger. La documentation du noyau donne le repli honnête en termes simples : "Si le correctif n'a pas pu être compilé ou testé, ou si aucun reproducteur n'a pu être produit, dites-le explicitement : les mainteneurs perdent actuellement trop de temps à analyser des rapports non vérifiés et des correctifs non testés." Écrire "Je n'ai pas pu tester cela sur du matériel réel" ne vous coûte rien. Suggérer que vous l'avez fait vous coûte votre place dans le projet.

Répondez vous-même aux commentaires de revue, avec vos propres mots et à votre rythme. Une réponse qui arrive trente secondes après le commentaire et qui le reformule en cinq paragraphes indique exactement au mainteneur ce qui s'est passé. Gardez également le diff petit. Quarante lignes que vous comprenez parfaitement valent plus pour un projet qu'une refactorisation de quatre cents lignes que vous avez supervisée. Si votre agent continue de vous fournir plus que ce que vous avez demandé, une compétence qui le limite au plus petit changement fonctionnel est un moyen de maintenir le patch à une taille que vous pouvez encore défendre ligne par ligne.

Conservez les instructions de l'agent dans le dépôt

Les instructions que vous donnez à votre agent font partie de votre chaîne d'outils ; traitez-les donc comme du code. Un fichier à la racine du dépôt, généralement AGENTS.md, contient la commande de build, la commande de test, le format des messages de commit, les exigences de signature et les règles de style déjà documentées par le projet. Ce fichier est versionné et peut être relu ; il sera identique demain et aujourd'hui. Les instructions retapées de mémoire à chaque session produisent un patch différent à chaque fois, et vous ne saurez pas quelle session a produit le patch qui a été rejeté. Rédiger un fichier AGENTS.md lisible à la fois par un agent et par un humain traite de ce fichier.

Une mise en garde concernant les dépôts tiers : ne faites pas de votre première contribution une PR ajoutant un fichier d'instructions pour agent à un projet que vous ne maintenez pas. Cela est perçu comme une tentative d'imposer la politique d'outillage du projet depuis l'extérieur, et c'est un moyen rapide de voir votre compte associé à ce dont les mainteneurs sont déjà lassés. Gardez ce fichier dans votre fork jusqu'à ce que quelqu'un vous le demande.

L'endroit où vous exécutez l'agent importe pour la même raison. Un agent capable de compiler le projet et d'exécuter ses tests dans un sandbox que vous contrôlez vous fournit un patch que vous avez réellement vérifié. C'est toute la différence entre divulguer une assistance et divulguer une supposition. Exécuter un agent de développement sur votre propre VPS couvre cette configuration, et les différences pratiques entre Claude Code, Cursor, Codex et Copilot détaille les spécificités quotidiennes de ces outils.

La méthode, une fois la politique modifiée

1. Identifiez la politique déclarée avant d'écrire quoi que ce soit : dépôt, documentation développeur, site web, gestionnaire de tickets.
2. En l'absence de politique, posez la question dans le ticket en une seule phrase et conservez la réponse.
3. Divulguez l'information selon le format utilisé par le projet, dans le trailer du commit, et répétez-la dans le corps de la PR si le projet effectue un squash.
4. Signez avec votre nom réel, en sachant que cette ligne constitue une déclaration sur votre droit à soumettre le code.
5. Relisez votre propre patch comme si un inconnu l'avait écrit, car c'est le cas.

Chaque projet mentionné sur cette page aura migré au moment où vous lirez ces lignes. Les cinq étapes, elles, ne changent pas.

FAQ

Dois-je déclarer l'utilisation d'un assistant de codage IA ?

Vérifiez les règles du projet, car la réponse est définie localement. Fedora exige une déclaration lorsqu'une part significative de la contribution provient d'un outil sans modification humaine. Le noyau Linux demande un trailer Assisted-by. Gentoo et QEMU, à la date d'août 2026, refusent purement et simplement ces contributions. En l'absence de règle écrite, déclarez-le systématiquement dans un trailer de commit. Un mainteneur qui découvre l'omission plus tard réagira à la dissimulation plutôt qu'à l'outil, et cette réaction affectera l'ensemble de vos contributions.

Quels projets open source interdisent le code généré par IA ?

Voici un état des lieux en août 2026 : Gentoo depuis avril 2024, NetBSD qui considère la sortie d'un LLM comme du code contaminé nécessitant une approbation du noyau, QEMU qui refuse les contributions dérivées de contenu généré, et plusieurs applications GNOME dont Loupe et Calendar. Consultez le texte propre à chaque projet plutôt que cette liste, car elle devient obsolète. Notez l'exemption commune à la plupart d'entre eux : utiliser un modèle pour rechercher une API, exécuter une analyse statique ou vous aider à déboguer est généralement autorisé, tant que sa sortie ne se retrouve pas dans le patch.

Quelle est la différence entre Signed-off-by et un commit signé ?

Signed-off-by est une ligne de texte brut ajoutée par git commit -s. Elle certifie le Developer Certificate of Origin, signifiant que vous avez le droit de soumettre ce code sous la licence du projet. Un commit signé, réalisé avec git commit -S, est une signature cryptographique de l'objet commit avec votre clé GPG ou SSH. Elle prouve que le commit provient de votre clé et n'a pas été altéré. L'origine et l'identité sont des revendications distinctes ; un commit signé peut donc toujours enfreindre une politique sur l'IA.

Puis-je placer la déclaration dans la description de la pull request plutôt que dans le message de commit ?

Placez-la dans le message de commit, car c'est l'enregistrement qui finit dans l'historique git et qui accompagne le code pour quiconque clone le dépôt ultérieurement. La description d'une pull request peut être modifiée après coup et reste liée à la plateforme d'hébergement. Ajoutez-la également dans le corps de la PR si le projet utilise le squash merge, car un squash réécrit votre message de commit et peut supprimer le trailer.

Ma pull request a été fermée car elle était générée par IA. Que faire ?

Ne débattez pas de la politique dans le fil de discussion, car la personne qui l'a fermée n'a pas rédigé la règle seule et ce n'est pas là qu'elle changera. Lisez le texte de la politique, puis décidez si vous pouvez vous y conformer. Là où le projet interdit les patchs générés, un rapport de bug clair avec un moyen de reproduction et sans patch reste le bienvenu, et c'est souvent la contribution la plus utile. Si vous revenez avec du code, revenez avec une petite modification que vous pouvez défendre ligne par ligne.