---
title: "L’IA rend les contributions GitHub bon marché. Le crédit, lui, reste visible"
locale: "fr"
url: "https://irz.fr/fr/articles/ia-contribution-credit-mainteneur-fr"
markdown_url: "https://irz.fr/fr/articles/ia-contribution-credit-mainteneur-fr.md"
category: "ai"
tags: ["open source", "mainteneurs", "GitHub", "contributions IA", "pull requests"]
published_at: "2026-08-28T09:07:00.000Z"
author: "Hugo Marchal"
translation: "https://irz.fr/en/articles/ai-contribution-credit-maintainer-en.md"
---

# L’IA rend les contributions GitHub bon marché. Le crédit, lui, reste visible

Une PR peut désormais prendre quelques minutes à générer tout en demandant une vraie review. Les projets commencent donc à filtrer moins le code que la preuve qu’un humain l’assume.

Une contribution open source produit deux choses en même temps : elle peut améliorer un projet, tout en améliorant aussi **le profil de la personne qui la signe**.

GitHub rend ce second effet très visible : le profil affiche un graphe annuel de contributions, une chronologie détaillée, les pull requests proposées, les issues ouvertes et les dépôts où l’utilisateur est le plus actif.[2](https://docs.github.com/en/account-and-profile/concepts/contributions-on-your-profile)

Pendant longtemps, produire ce signal demandait à peu près le même travail que produire la contribution : comprendre un projet, trouver un problème, écrire le changement, le tester et supporter la review. Les agents de code cassent cette symétrie, parce qu’ils réduisent surtout le coût de fabrication du patch sans réduire dans les mêmes proportions le temps de celui qui doit l’accepter.

Neil Alexander, mainteneur de `nats-server` et auteur de plusieurs projets réseau open source, raconte avoir vu arriver trois PR presque simultanées d’un contributeur qui n’avait pratiquement aucune activité récente sur GitHub. Les changements corrigeaient orthographe et grammaire dans des commentaires. Claude avait fait les corrections, rédigé au moins une partie du travail visible et laissé sa co-signature dans les commits.[1](https://neilalexander.dev/2026/06/30/flooding-contributions.html)

Les corrections étaient justes, mais Alexander les a tout de même fermées : le problème n’était plus seulement la qualité du diff, c’était **l’économie du geste**.

## Deux bénéfices

Pour la personne qui ouvre une PR, une contribution acceptée peut produire du crédit public : avatar dans un dépôt, activité sur le profil, trace d’une PR, parfois mention dans une release ou un CV.[1](https://neilalexander.dev/2026/06/30/flooding-contributions.html)[2](https://docs.github.com/en/account-and-profile/concepts/contributions-on-your-profile)

Pour le projet, le bénéfice n’existe que si la modification vaut davantage que son coût d’intégration.

Ces deux valeurs étaient déjà différentes avant les LLM ; elles peuvent maintenant diverger brutalement, surtout lorsque le changement est trivial mais sa validation ne l’est pas.

Un agent peut scanner plusieurs dépôts, repérer des typos, des warnings ou des `TODO`, produire des patches et préparer des descriptions ; le contributeur obtient alors plusieurs occasions de montrer une activité visible, tandis que chaque mainteneur ne reçoit qu’un élément de plus à examiner.

> **Une PR produit deux comptes différents**
> Schéma montrant qu'une même pull request génère un crédit visible pour le contributeur et un coût de validation pour le mainteneur
> - LE DIFF EST LE MÊME, LE BILAN NE L’EST PAS
> - CONTRIBUTEUR
> - activité visible
crédit public
portfolio
> - MAINTENEUR
> - comprendre
review · tests
responsabilité future
> - L’IA réduit surtout le coût du côté gauche. Le côté droit reste humain.
> La valeur d’une contribution pour son auteur et son coût pour le projet ne sont pas la même quantité. Les agents rendent cette différence beaucoup plus grande.

Cette asymétrie explique pourquoi une PR techniquement correcte peut devenir indésirable. Une correction cosmétique peut avoir une valeur presque nulle pour le projet tout en produisant exactement le signal public recherché par son auteur.

## Le CV vert

Alexander formule l’idée sans détour : les contributions réussies fonctionnent comme une **monnaie**. Il note que recruteurs et employeurs peuvent regarder l’activité GitHub et soupçonne qu’une partie des nouvelles contributions générées par IA sert d’abord à fabriquer cette apparence de participation.[1](https://neilalexander.dev/2026/06/30/flooding-contributions.html)

La première partie est vérifiable : GitHub conçoit explicitement le profil pour montrer le travail réalisé, avec graphe, activité de contribution, PR et issues.[2](https://docs.github.com/en/account-and-profile/concepts/contributions-on-your-profile) La seconde reste son observation de mainteneur, pas une mesure globale du recrutement. On ne peut pas en déduire que la majorité des PR IA sont faites pour un CV, ni que l’activité GitHub détermine systématiquement une embauche.

Son exemple montre toutefois une incitation très simple : **si le crédit reste public alors que le coût de production chute, fabriquer le signal devient plus attractif**.

Le phénomène s’étend aux signalements de sécurité. Alexander dit recevoir davantage de rapports qui lui paraissent générés par IA, souvent accompagnés d’une proposition de correctif. Comme les CVE peuvent créditer leurs découvreurs, il se demande là aussi si certains rapports recherchent autant la reconnaissance que la correction.[1](https://neilalexander.dev/2026/06/30/flooding-contributions.html)

Aucun comptage ne permet d’en tirer un pourcentage. curl décrit pourtant le même problème opérationnel depuis l’autre côté : des rapports de sécurité inventés ou copiés depuis une IA consomment du temps d’enquête prioritaire, éloignent l’équipe du vrai travail, et le projet annonce bannir immédiatement les auteurs de faux rapports.[5](https://curl.se/dev/contribute.html)

## Prouver l’humain

La réponse la plus intéressante des projets n’est pas « interdire l’IA partout ».

PyTorch autorise explicitement les outils IA, mais exige que le contenu généré soit signalé, accompagné d’un commentaire humain qui explique sa pertinence, et que la personne comprenne réellement le changement. Le projet refuse les contributions entièrement autonomes sans implication humaine significative.[3](https://github.com/pytorch/pytorch/blob/main/AI_POLICY.md)

RustPython va plus loin sur la traçabilité : toute utilisation d’IA doit être déclarée, y compris dans les commits via un trailer `Assisted-by`. Les PR peuvent être fermées si le code semble insuffisamment relu, si l’IA n’a pas été déclarée ou si le contributeur ne peut pas réellement tester le changement.[4](https://github.com/RustPython/.github/blob/main/AI_POLICY.md)

Ces politiques ne cherchent donc plus seulement à vérifier **le résultat**. Elles cherchent des preuves sur le **processus d’appropriation**.

> **Le nouveau filtre n’est pas seulement le code**
> - dire quand et comment l’IA a participé: Disclosure
> - pouvoir expliquer et défendre le changement: Compréhension
> - avoir réellement testé ce que l’agent propose: Vérification
> - rester la personne qui répond pendant la review: Responsabilité
> Exemples : PyTorch et RustPython. Le projet ne demande pas que chaque ligne soit tapée à la main ; il demande qu’un humain possède le changement.

Avant, un patch propre et des tests verts pouvaient suffire à présumer qu’un contributeur avait compris son travail ; cette présomption devient moins fiable lorsque le patch complet, les tests et le texte de PR peuvent être produits sans lecture approfondie.

Le nouveau signal rare devient alors : **est-ce que quelqu’un sait pourquoi cette PR existe et acceptera d’en répondre ?**

## Fermer l’entrée

Certaines équipes préfèrent désormais déplacer le filtre avant la review plutôt que payer cette vérification au cas par cas.

Depuis février 2026, GitHub propose deux réglages qui auraient semblé étranges dans l’idéal open source classique : désactiver complètement les pull requests d’un dépôt ou les limiter aux collaborateurs.[6](https://github.com/orgs/community/discussions/187038)

Ce mécanisme n’est pas une politique anti-IA. GitHub le présente comme un moyen général de laisser les mainteneurs choisir comment un dépôt public accepte des contributions.[6](https://github.com/orgs/community/discussions/187038)

Mais il change la structure économique du problème. Au lieu de laisser n’importe qui créer une unité de travail que le mainteneur devra ensuite trier, le projet peut remettre un **coût d’entrée** avant la PR : discussion préalable, issue validée, invitation, relation déjà construite.

Canario avait choisi la solution extrême en fermant son code pour réduire ce coût de maintenance. Ici, le mouvement est différent : le code peut rester visible, forkable et parfois même ouvert aux issues, tout en restreignant la file de review.

## Une file chère

La ressource rare n’est donc plus vraiment le patch : celui-ci devient abondant, tandis que le temps de review, la connaissance du projet et le droit de décider ce qu’il faudra maintenir pendant cinq ans ne le sont pas.

Le système de contribution doit désormais éviter deux erreurs opposées, qui deviennent toutes deux coûteuses quand le volume augmente.

La première serait de considérer toute aide IA comme illégitime. PyTorch et RustPython montrent qu’un projet peut parfaitement accepter des outils génératifs tant que l’auteur comprend, vérifie et assume ce qu’il envoie.[3](https://github.com/pytorch/pytorch/blob/main/AI_POLICY.md)[4](https://github.com/RustPython/.github/blob/main/AI_POLICY.md)

La seconde serait de croire qu’un diff correct suffit toujours à justifier le coût de sa review. Les trois corrections de texte décrites par Alexander étaient correctes ; il les a fermées parce qu’elles n’amélioraient pas assez le projet pour mériter la transaction sociale qu’elles déclenchaient.[1](https://neilalexander.dev/2026/06/30/flooding-contributions.html)

> **Quand le patch devient abondant, l’admission devient un produit**
> Entonnoir montrant découverte, discussion, proposition, review et merge, avec le coût humain qui augmente à mesure que la contribution avance
> - PLUS ON AVANCE, PLUS LE COÛT HUMAIN MONTE
> - 1 · TROUVER · agent, humain, recherche
> - 2 · JUSTIFIER · pourquoi ce changement ?
> - 3 · REVIEW · contexte + tests
> - 4 · MERGE · responsabilité
> L’agent peut rendre l’étape 1 presque gratuite. Les projets déplacent donc le filtre vers la justification, la compréhension et parfois l’accès même à la file de PR.

## Changer métrique

Pour un contributeur, la conséquence est assez saine : le meilleur portfolio ne sera probablement plus celui qui contient le plus de carrés verts.

Une contribution difficile à falsifier possède d’autres traces : une issue comprise avant le patch, des échanges qui montrent le raisonnement, des tests que l’auteur sait expliquer, un changement suivi après merge, une présence récurrente dans le même projet.

Ce sont précisément les choses que l’automatisation de masse produit mal, parce qu’elles demandent du contexte accumulé plutôt qu’un diff ponctuel.

Pour un mainteneur, l’enjeu devient de rendre ces signaux visibles **avant** de dépenser la review : demander une issue préalable pour certains changements, fermer les PR sans motivation claire, exiger disclosure et tests réels, ou restreindre temporairement l’accès lorsqu’une vague de contributions dépasse la capacité de l’équipe.

GitHub continue d’afficher l’activité parce qu’elle reste utile,[2](https://docs.github.com/en/account-and-profile/concepts/contributions-on-your-profile) mais les agents obligent à cesser de confondre **activité visible** et **valeur transférée au projet**.

L’open source n’a jamais promis un point de CV en échange de chaque diff correct. Maintenant que le diff peut coûter presque rien à fabriquer, cette distinction devient impossible à ignorer.

## References

1. [Neil Alexander, Please stop flooding our projects with AI slop to furnish your CV, 30 juin 2026](https://neilalexander.dev/2026/06/30/flooding-contributions.html)
2. [GitHub Docs, Contributions on your profile](https://docs.github.com/en/account-and-profile/concepts/contributions-on-your-profile)
3. [PyTorch, AI Policy](https://github.com/pytorch/pytorch/blob/main/AI_POLICY.md)
4. [RustPython, AI usage policy](https://github.com/RustPython/.github/blob/main/AI_POLICY.md)
5. [curl, Contribute to the curl project](https://curl.se/dev/contribute.html)
6. [GitHub Community, new repository settings to configure pull request access, 13 février 2026](https://github.com/orgs/community/discussions/187038)