Compte rendu : atelier "IA et contributions open source : comment concilier innovation et qualité ?"

Depuis quelques temps, l'intelligence artificielle (IA) s'est fait une place de choix dans les pratiques de développement, sans suivre un cadre ou des codes précis. D'une équipe à l'autre, d'une personne à l'autre, elle est utilisée de manière extrêmement hétérogène (parfois massivement, parfois pas du tout). Et cette hétérogénéité commence à créer des frictions, notamment dans le cadre des contributions aux logiciels libres.

Pas uniquement dans les workflows et le quotidien opérationnel des développeurs, mais aussi dans les relations humaines entre contributeurs et mainteneurs, entre équipes qui adoptent ces outils et celles qui y résistent. Surtout, la promesse de gains de productivité se heurte de plus en plus à une autre réalité : pour les mainteneurs et les équipes de revue, l’augmentation des contributions générées ou assistées par l’IA entraîne une charge croissante de vérification et de validation.

Afin d'aborder ce sujet, qui promet de prendre encore de l'ampleur, et à l'occasion de la journée mensuelle d'équipe de LaSuite, associée au Forum OPI ( (Ouvre une nouvelle fenêtre) Opérateur de Produits Interministériels), un atelier a été organisé au Lieu de la transformation publique (DITP). Ce dernier réunissait des profils variés : développeurs, DevOps, POs, data engineers, représentants de Grist, Docs, Fichiers, et d'autres outils de (Ouvre une nouvelle fenêtre) LaSuite.

L'objectif n'était pas de trancher, mais de mettre des mots sur les évolutions profondes qui traversent la manière de contribuer aujourd'hui au code en open source, et de commencer à construire une réponse commune aux enjeux à venir.

Une asymétrie qui s'est mécanisée

Avant l'IA, produire une PR (pull request) prenait du temps - une durée généralement proportionnelle au temps nécessaire pour relire les composantes de la mise à jour logicielle. Aujourd'hui, cette réalité n'est plus.

Générer des centaines lignes de code peut désormais être fait par un développeur s'appuyant sur Claude Code en une demi-heure. Les lire, comprendre l'intention derrière, tester, valider, en revanche, prennent toujours deux à quatre heures pour le mainteneur. L'asymétrie a toujours existé dans l'open source, mais jusqu'à récemment, elle impliquait uniquement des humains et était donc de fait "limitée". L'IA l'a amplifiée, la rendant encore plus forte et lui conférant un potentiel quasi illimité.

Ce qui rend les choses encore plus complexes, c'est aussi que le code généré avec l'aide de l'IA n'est pas forcément de mauvaise qualité. Au contraire, il peut même être excellent sur des tâches bien délimitées et cadrées, quand les prompts sont bien pensés (tests unitaires, boilerplate, documentation, etc).

La problématique se révèle plutôt au niveau de la cohérence architecturale sur le long terme, ou encore dans les contraintes non exprimées dans le code. Le vrai risque, comme plusieurs participants l'ont formulé durant l'atelier, ce n'est pas le code généré, mais plutôt c'est le code non-relu que son auteur ne comprend pas vraiment, et qu'un mainteneur devra assumer dans la durée.

La question de la responsabilité est fréquemment ressortie des échanges. Si un bug de sécurité est introduit via une PR générée par IA et insuffisamment relue, qui en répond ? Juridiquement et éthiquement, la réponse est claire : le contributeur, et le mainteneur qui a accepté la contribution. L'IA n'est pas co-autrice. Mais cette clarté doit être actée explicitement, car elle ne va pas de soi dans les pratiques actuelles.

Un risque moins visible mais structurel : le reputation farming

Un point plus prospectif a également été soulevé, et il mérite qu'on y prête attention. Une nouvelle pratique, dite de (Ouvre une nouvelle fenêtre) reputation farming, consiste à automatiser des contributions de qualité correcte sur des projets visibles pour accumuler de la crédibilité sur GitHub, puis convertir cette réputation en accès à des modules critiques. Là où cette approche exigeait parfois des années à un acteur humain, elle est désormais rendue faisable en quelques semaines avec l'aide de l'IA.

Ce que cette situation implique concrètement pour l'avenir, c'est que la déclaration sur l'honneur ne suffit plus comme seule réponse de gouvernance. Les systèmes de pré-qualification promettent de devenir des gages de sécurité autant que de qualité. Tout commit sur des modules critiques devrait nécessiter une interaction humaine vérifiable (commentaire synchrone, échange en issue, mention explicite d'un mainteneur connu, etc).

Tour d'horizon des pratiques actuelles

Un travail d'analyse poussé a mis en lumière des approches très différentes du sujet de la contribution selon les cultures de projet et les écosystèmes de contributeurs.

À une extrémité, l'interdiction totale : Ghostty, Gentoo, NetBSD, tldraw ont ainsi fermé les contributions IA, parfois avec ban permanent en cas de non-déclaration. Mitchell Hashimoto a (Ouvre une nouvelle fenêtre) résumé la philosophie : "This is not an anti-AI stance. This is an anti-idiot stance." C'est à dire, contre des contributions de l'IA de basse qualité et non révisées par un humain. (NDLR : Efficace et dissuasif, mais non vérifiable, et potentiellement décourageant pour des contributions légitimes de bonne foi.

Plus nuancée, la déclaration obligatoire, (Ouvre une nouvelle fenêtre) adoptée par le Linux Kernel, (Ouvre une nouvelle fenêtre) Homebrew, ou (Ouvre une nouvelle fenêtre) cURL, demande simplement de mentionner l'usage de l'IA dans la PR. Le Kernel propose même un tag Co-developed-by: AI-tool pour la traçabilité git. Une approche intéressante, qui semble susciter des réactions positives : (Ouvre une nouvelle fenêtre) Ghostty a ainsi constaté que 50 % des PRs incluaient une déclaration dans les semaines suivant l'introduction de la règle. Cette approche a le mérite d'être transparente et non punitive - mais de reposer entièrement sur la bonne foi des contributeurs.

Une troisième voie mise sur les critères de qualité renforcés, indépendamment de l'outillage. Ce qui compte, c'est l'output, pas le moyen. Hashimoto précise : "I do not care what the AI said. I want to see the contributor's thinking." (NDLR : Je me fiche de ce qu'a dit l'IA. Je veux connaître le raisonnement du contributeur). Une approche non-discriminatoire, mais qui ne réduit pas la charge à la source.

Enfin, les systèmes de pré-qualification, dont le système Vouch de Ghostty est l'exemple le plus abouti, exigent qu'un contributeur soit parrainé avant de pouvoir soumettre des PRs. Cette décision crée une friction naturelle et efficace. Elle réduit aussi mécaniquement l'ouverture des contributions.

Perspectives et temps forts de l'atelier

Plusieurs fils se sont dégagés des échanges ouverts par l'atelier, au-delà des positions individuelles.

Le premier, presque unanime : les problèmes soulevés avec l'avènement de l'IA ne sont pas nouveaux. La qualité des contributions, l'intégration de nouveaux profils, les bottlenecks de revue... Existent tous depuis plusieurs dizaines d'années. Ce qui change, en revanche, c'est que l'IA les accentue et les rend plus visibles, même si elle n'en est pas l'origine. L'échelle et la vitesse à laquelle ces tensions se manifestent est passée à l'échelle et de nouvelles solutions doivent être pensées en réponse.

Les participants ont abordé un second grand point : l'IA libère du temps, certes, mais encore faut-il savoir quoi en faire. Plusieurs agents ont ainsi noté qu'en déléguant le syntaxique et le boilerplate, ils passaient plus de temps sur les tâches qui comptaient le plus pour eux : les tests, l'architecture, la conception. D'autres ont exprimé une inquiétude inverse : à force de ne plus regarder les entrailles du code, n'y-a-t-il pas un risque de perdre la connaissance fine de ce qu'est le projet ? Les deux positions sont légitimes, et probablement complémentaires selon le contexte.

Le troisième point abordé était aussi le plus inconfortable : les usages sont très hétérogènes, et cette hétérogénéité crée des rapports de force. Un mainteneur seul face à dix PRs en partie générées par IA, c'est une situation nouvelle qui appelle des règles nouvelles, pas uniquement des bonnes pratiques individuelles.

Et ce déséquilibre prend un relief particulier lorsqu'on rappelle que la grande majorité des mainteneurs de projets open source sont bénévoles. Ils assurent, souvent seuls et sur leur temps personnel, la continuité de logiciels parfois utilisés par des millions de personnes ou des infrastructures critiques. Cette réalité préexistait à l'IA — mais elle est aujourd'hui considérablement aggravée. Là où un mainteneur pouvait absorber un flux de contributions humaines, il se retrouve désormais face à un volume potentiellement illimité, généré à une vitesse que rien ne peut suivre sans aide.

Pour les participants à l'atelier, il ne s'agit pas simplement une question d'organisation ou d'outillage, mais bel et bien d'une question de soutenabilité humaine. Faire peser sur des individus non rémunérés une charge de revue en forte croissance, sans leur donner les moyens d'y répondre, c'est risquer d'épuiser précisément les personnes dont dépend la santé de l'écosystème open source.

Prochaines étapes

Trois axes majeurs se sont dégagés des échanges, sur la base desquels les agents libristes pourraient contribuer à co-construire une policy applicable aux CONTRIBUTING.md des dépôts dans l'administration - et au-delà.

1️⃣ Transparence. Intégrer une section déclaration d'usage IA dans le template de PR, et traiter cette déclaration comme une routine, pas comme un aveu. Encourager les contributeurs à partager comment ils ont utilisé l'IA, valoriser les bons exemples dans les release notes.

2️⃣ Qualité vérifiable. Renforcer les critères d'acceptation indépendamment de l'outillage : taille des PRs, couverture de tests, capacité à expliquer ses choix lors de la revue. Introduire des outils de pré-revue (CodeRabbit, Sourcery) pour décharger les mainteneurs sur le premier filtre. L'humain intervient après, pas à la place. Il faudra cependant faire attention au risque de "verbosité" et aux "bruit" additionnel que peuvent ajouter ces outils de pré-revues, ces derniers présentant le risque de demander beaucoup de temps à un mainteneur.

3️⃣ Gouvernance renforcée et responsabilité assumée. S'appuyer sur des dispositifs existants comme les DCO (Developer Certificate of Origin) peut aider à ancrer la responsabilité du contributeur. Explorer des mécanismes de pré-qualification pour les dépôts les plus critiques. Côté secteur public français, des dispositifs comme le (Ouvre une nouvelle fenêtre) Forum du Numérique Ouvert peuvent notamment jouer un rôle de vérification de l'identité humaine des contributeurs partenaires.

Et après ? L'équipe du Numérique Ouvert, en collaboration avec LaSuite, souhaite ouvrir la conversation à l'ensemble des équipes OPI, pour faire évoluer ces orientations collectivement, et produire un draft de policy partagé.