IA et contributions open source : comment préserver la qualité et la collaboration?

Entraide et questions
,
1

L’utilisation croissante d’outils d’IA générative (GitHub Copilot, Claude, etc.) dans le développement logiciel soulève des questions cruciales pour les projets open source publics. À LaSuite, nous observons une augmentation des contributions dont la qualité ou la pertinence est difficile à évaluer, ce qui impacte directement le travail des mainteneurs et la dynamique collaborative.

Pourquoi est-ce un enjeu ?

  • Qualité et pertinence : Les contributions générées par IA peuvent contenir des erreurs, des incohérences, ou ne pas répondre aux besoins réels du projet.

  • Transparence : Il est souvent difficile de savoir si une contribution a été générée par IA, ce qui pose des questions de responsabilité et de confiance.

  • Charge de travail : Les mainteneurs passent plus de temps à relire et corriger des PR de qualité variable, au détriment d’autres tâches essentielles.

Exemples concret

  • Un contributeur ouvre une PR sur votre dépôt, clairement générée par IA (commits IA), elle nécessite un travail important de relecture et de correction. Comment juger du niveau d’implication du contributeur, de sa compréhension du code généré, de sa capacité à intégrer les retours ? Bref comment ne pas rentrer dans un processus de revue de code qui peut durer et prendre beaucoup de temps au mainteneur.

  • L’heure est à l’agentic engineering, les développeurs pilotent des agents IA autonomes qui codent pour eux. Cela accélère énormément leur vélocité, ce qui peut saturer les capacités de relecture et mettre les mainteneurs sous pressions et menacer la pérennité du code si les revues sont moins bien faites.

Que faire ?

Je vous propose avec fil de discussion d’ouvrir une réflexion collective pour :

  1. Définir des lignes directrices pour l’usage de l’IA dans les contributions (transparence, critères de qualité, etc.).

  2. Partager les bonnes pratiques entre projets open source publics.

  3. Expérimenter des outils ou processus pour faciliter la relecture et l’intégration de ces contributions.

Ressources utiles

Prochaines étapes

  • Un atelier sera organisé lors du prochain forum OPI (26 mars) pour co-construire une politique IA à intégrer aux CONTRIBUTING.md des projets LaSuite (La Suite numérique · GitHub). Je viendrais publier le compte rendu en réponse.

Mainteneurs et contributeurs partagez vos retours d’expérience et vos idées sur ce fil il est fait pour ça.

3 « J'aime »
2

Hello,
On a mis à jour notre CONTRIBUDING.md et PULL_REQUEST_TEMPLATE.md sur Docs. Si vous voulez jeter un oeil : Add ai policy contributing.md by virgile-dev · Pull Request #2167 · suitenumerique/docs · GitHub

Et voici le compte rendu de l’atelier rédigé par @Jaime et @NoemieKempf Compte rendu : atelier "IA et contributions open source : comment concilier innovation et qualité ?" — Portail du numérique ouvert

2 « J'aime »
3

J’ai deux questions qui me viennent à l’esprit :

  1. Le goulot d’étranglement, il me semble, n’a jamais été l’écriture du code, mais bien la revue de code. Donc pourquoi utiliser des outils génératifs qui crée plus de code et donc mécaniquement moins de revue ? Si l’IA(gen) doit être utilisée, autant l’utiliser sur la revue plutôt que sur la lecture. Ça évite aussi de faire des devs des centaures inversés.
  2. Que le code soit généré par un modèle d’IAgen ou un humain, le temps et l’énergie passés sur la revue de code ne doit pas varier. Pourquoi passer plus de temps sur une MR généré par une IAgen plutôt qu’un être humain ? La question se pose d’autant plus dans le cadre d’un projet libre où n’importe qui (y compris des individus peu compétents dans tel ou tel langage) peuvent faire des MR ?
1 « J'aime »
4

Bonjour Louis, @virgile-deville te répondrait mieux que moi, mais comme il est en congé, je vais tenter d’apporter quelques éléments:

L’idée d’utiliser l’IA pour la revue plutôt que pour l’écriture circule pas mal en ce moment.

Elle a du sens dans certains cas — détecter des incohérences de style, vérifier la couverture de tests.

Mais déléguer la revue, même partiellement, c’est perdre quelque chose de difficile à récupérer : la revue est aussi le moment où un mainteneur juge si le contributeur comprend ce qu’il propose, et si c’est aligné avec la roadmap du projet à moyen-long terme. Un outil d’IA ne peut pas vérifier ça (pour l’instant).

On a creusé ça pendant l’atelier du 26 mars - le compte rendu est là si tu veux : Compte rendu : atelier "IA et contributions open source : comment concilier innovation et qualité ?" — Portail du numérique ouvert.

Du coup on est en train de réfléchir à quelles nouvelles pratiques mettre en place pour garder des communs où les contributions sont qualis (comme de meilleurs guides de contributions), mais aussi aux avantages et aux limites d’utiliser des outils IA pour la revue de code.

Le contributing.md que propose Virgile justement vise à faire que les gens qui soumettent quand même des PR avec du code IA soient bien compris par leurs auteurs et passent un certain nombre de tests pour que ce soit plus facile à intégrer et maintenir (et éviter le phénomène de centaure inversé que tu évoques).

Je comprends l’intuition derrière ta question, mais le problème ce n’est pas la durée d’une revue individuelle. C’est le rapport entre volume entrant (on peut faire de plus en plus de PRs et plus vite) et capacité de revue disponible des mainteneurs.

Un contributeur humain peu à l’aise dans un langage ouvre une MR et il peut y avoir quelques aller-retour, et il devrait comprendre plus ou moins ce qu’il a voulu coder.

Avec un dev qui pilote un agent et « accélère sa vélocité », c’est potentiellement dix MR par semaine sur le même dépôt qui peuvent paraître propres syntaxiquement, mais on n’a aucune garantie que ces gens aient vraiment lu ce qu’ils ont proposé.

C’est exactement pourquoi avec Virgile on propose une politique dans le CONTRIBUTING.md que d’autres projets open source peuvent réutiliser, plutôt que de laisser chaque mainteneur improviser au cas par cas :wink:

5

Bon, j’en avais un peu marre de passer mes journées à discuter avec des contributeurs qui se cachent trop derrière leur AI, et à review des issues et PRs qui sont visiblement pas toujours maîtrisées par les contributeurs, alors j’ai rajouté des templates d’issues et de PRs qui demandent aux contributeurs de certifier que ça obéit aux contributing guidelines :

J’ai mergé sans attendre car j’en avais besoin rapidement.

La formulation se veut très courte et simple. Si vous avez des remarques (ou PRs même), hésitez pas.
Et si la méthode et la formulation peuvent être d’une quelconque inspiration pour d’autres repos, tant mieux.

1 « J'aime »