QGIS soumet à un vote l'interdiction de toutes les contributions assistées par IA, du moins pour l'instant

Une proposition pour fermer complètement la porte

Le 5 octobre, une proposition visant à interdire les contributions assistées par IA à QGIS, le logiciel de cartographie open source, a terminé sa période de discussion et est passée au vote. Cette proposition, QEP428, a été ouverte le 24 septembre par le contributeur Nyall Dawson. Elle remplace formellement l'ancienne politique IA du projet, fondée sur le principe du « human in the loop » (humain dans la boucle), par une règle stricte « NOT ALLOWED » (interdit). La source n'indique pas le résultat du vote ; ce qui suit décrit donc une proposition, et non une politique arrêtée.

Comment fonctionnait l'ancienne politique, et pourquoi elle n'a pas fonctionné

Les propositions d'amélioration de QGIS (QEP) sont la voie formelle par laquelle le projet modifie son fonctionnement : une proposition écrite, une période de discussion, puis un vote. L'ancienne politique autorisait l'aide de l'IA tant qu'un humain restait responsable du résultat. Elle reposait sur des étiquettes, notamment une étiquette « AI Assisted » pour les pull requests (modifications de code proposées) et une étiquette « extractive » qui, selon le contributeur uclaros, n'a en réalité jamais été créée.

Le bilan cité par uclaros : environ 50 pull requests ont été étiquetées AI Assisted, et environ 40 d'entre elles ont été fermées sans être fusionnées. D'autres ont été fermées sans jamais avoir été étiquetées. Dawson a qualifié l'ancienne approche de politique qui « n'a clairement pas fonctionné » et a déclaré que le projet avait déjà perdu, de ce fait, au moins un contributeur de très grande valeur.

L'argument : la capacité de relecture, pas la qualité du code

Le reproche central porte sur le volume. Le membre haubourg a écrit que le flux généré par l'IA est bien supérieur à ce que la relecture humaine peut traiter sérieusement, ce qui produit soit une pile croissante de pull requests non relues, soit du code qui n'est pas entièrement relu. Il a aussi soutenu que QGIS inspire confiance parce que les organisations peuvent y contribuer en retour et embaucher des contributeurs, et que c'est ce réseau humain qu'il faut protéger. Il a ajouté que tous les avis de sécurité soumis depuis la mise en place de ce système ont été rédigés avec l'IA, même si la plupart concernaient les sites web du projet et non le cœur de QGIS.

Un contributeur, Amalvir, qui avait soumis deux correctifs de régression assistés par IA, a soutenu l'interdiction. Il a décrit un contrat de confiance rompu, celui qui suppose que toute personne contribuant à un projet aussi complexe sait ce qu'elle fait, et a affirmé que les contributeurs qui s'appuient sur l'IA apprennent peu et ne deviennent jamais relecteurs.

L'objection : qu'est-ce qui est exactement interdit ?

Les critiques se sont concentrées sur la formulation. Le contributeur kannes a fait valoir que les mots « assisted » (assisté) et « used » (utilisé) sont assez larges pour interdire l'usage de LLM pour la relecture de code, l'audit et la sécurité, et a décrit son usage d'un LLM comme relecteur simulé avant d'envoyer une PR à ses collègues. Un autre contributeur, 02JanDal, a dressé la liste des cas ambigus : l'autocomplétion basée sur un LLM, les anciens classements par apprentissage automatique dans les complétions d'IDE, la réflexion sur une conception avec un chatbot, la lecture accidentelle d'une réponse IA d'un moteur de recherche, ou la traduction d'un terme avec Google Translate. Il a suggéré de restreindre le texte au code écrit par des LLM ou des agents IA dans le dépôt qgis principal, en soulignant que la clarté est essentielle puisqu'une sanction y est attachée.

Les partisans ont répondu qu'il s'agit d'une mesure provisoire. Dawson l'a décrite comme une porte fermée qui pourra ensuite être rouverte de façon sélective, au cas par cas, pour des usages comme l'autocomplétion ou la traduction. Le contributeur rouault-on-strike a concédé que la politique risque de jeter le bébé avec l'eau du bain. Le membre 3nids a donné un +0 et a dit qu'il ouvrirait une QEP distincte pour poursuivre la discussion ; elpaso a voté +1, en insistant sur le fait que l'interdiction est initiale, et non permanente.

Les questions à vous poser

• Si votre projet ou votre fournisseur s'appuie sur des logiciels open source, quelle est la capacité de relecture déclarée des mainteneurs, et le volume généré par l'IA la menace-t-il ?
• Comment une telle interdiction serait-elle appliquée, alors que le code ne contient aucun marqueur fiable d'assistance par IA et que l'ancien processus d'étiquetage n'a jamais été pleinement mis en œuvre ?
• Le texte final distingue-t-il le code écrit par l'IA de l'IA utilisée pour la relecture, la recherche ou la traduction, ou laisse-t-il les contributeurs deviner les sanctions ?
• Que deviendra le signalement des failles de sécurité si les avis rédigés par l'IA, qui selon haubourg représentent toutes les soumissions à ce jour, sont couverts par l'interdiction ?
• Qui décide quand et comment la porte se rouvre, et quelles preuves accepterait-il ?

Ce qu'il faut surveiller ensuite

Surveillez le résultat du vote et les éventuels amendements de la formulation, en particulier la question de savoir si le texte est restreint comme l'a proposé 02JanDal. Surveillez ensuite la QEP de suivi que 3nids a dit vouloir ouvrir, ainsi que la discussion que haubourg a prévue à la conférence des utilisateurs sur l'IA pour la relecture, l'audit et la sécurité. Ces éléments montreront si cette interdiction reste absolue ou devient une politique assortie d'exceptions définies.