QGIS introduit l'interdiction des contributions IA : 289 points et 299 commentaires sur HN

Le projet QGIS, le système d'information géographique open source le plus en vue, a mis en discussion une interdiction des contributions produites avec l'aide d'une IA. La proposition prend la forme de la pull request n°387 du dépôt QGIS-Enhancement-Proposals, où l'équipe examine les changements majeurs de ses règles et de son architecture. Au 12 octobre 2026, le lien vers cette PR avait recueilli 289 points et 299 commentaires sur Hacker News. Pour un sujet aussi spécialisé que les SIG, c'est beaucoup.

Une réserve importante : la source ne contient que le lien vers la PR et les métriques de HN, sans le texte de la politique. Les formulations exactes (ce qui compte comme une aide de l'IA, comment la vérifier, quelles sanctions sont prévues) et le statut final de la proposition sont à consulter dans la pull request elle-même. Le titre sur HN parle d'interdiction, mais le processus de décision du dépôt QEP peut inclure un vote et des amendements.

Pourquoi ces décisions apparaissent maintenant

QGIS est hébergé sur GitHub, écrit principalement en C++ et en Python, et distribué sous licence GPL. Le projet repose sur un nombre limité de mainteneurs, qui relisent à la main les patchs de centaines de contributeurs. Tout outil qui réduit le coût de production du code sans réduire celui de sa vérification frappe le point d'étranglement : le temps du relecteur.

Au-delà de la charge de travail, deux problèmes, l'un juridique et l'autre technique, se posent. Le premier est la provenance du code. Les modèles ont été entraînés sur d'énormes volumes de dépôts, et les mainteneurs n'ont aucun moyen de s'assurer qu'un fragment généré ne reprend pas le code d'autrui sous une licence incompatible. Pour un projet GPL, c'est une question de pureté de la licence. Le second est la responsabilité. L'auteur d'un patch doit comprendre ce qu'il soumet et savoir défendre sa solution en revue. S'il n'a pas écrit le code lui-même et ne le maîtrise pas entièrement, l'échange se réduit à un relais de messages entre le relecteur et un chatbot.

Un projet de plus sur cette ligne

QGIS rejoint un groupe déjà notable. Gentoo a interdit en 2024 d'accepter du code écrit avec des modèles génératifs. La même année, NetBSD a déclaré le code produit par LLM potentiellement « contaminé » du point de vue des licences et exigé une approbation préalable. QEMU a lui aussi refusé de tels patchs en 2025, invoquant le droit d'auteur et le certificat d'origine du développeur (DCO). D'autres projets choisissent une voie plus souple : ils autorisent l'aide de l'IA, mais exigent qu'elle soit déclarée et font porter la responsabilité sur l'auteur.

Ce que montrent les métriques

• Objet de la discussion : pull request n°387 dans qgis/QGIS-Enhancement-Proposals.
• Plateforme de discussion : Hacker News, 289 points.
• Activité : 299 commentaires, soit environ un par point. Le sujet est clivant, et le fil ne dégage aucun consensus.
• Licence du projet : GPL, ce qui rend la question de la provenance du code particulièrement sensible.
• Date de publication sur l'agrégateur : 12 octobre 2026.

Conséquences pratiques pour les contributeurs et les équipes

Si vous contribuez à QGIS ou à ses plugins, lisez le texte final de la politique avant d'envoyer votre prochain patch. Vérifiez si l'interdiction s'étend à l'autocomplétion dans l'éditeur, à la génération de tests et de documentation, à la traduction et à la correction de coquilles, ou seulement au code substantiel. Dans ce type de document, la frontière est souvent floue, et il vaut mieux régler les cas litigieux avec les mainteneurs à l'avance.

Le format lui-même peut servir aux mainteneurs d'autres projets open source : la règle passe par un processus de propositions public, et non par une décision à huis clos de l'équipe centrale. Cela réduit le nombre de conflits par la suite. Les équipes qui utilisent QGIS en entreprise et envoient des patchs en amont ont intérêt à se doter d'une règle propre : que peut-on envoyer à l'extérieur, parmi le code interne produit avec l'aide d'une IA ? Le plus simple est de garder ces modifications dans un fork ou un plugin maison.

Le verdict final ne tombera qu'après la discussion dans la PR elle-même. Mais les 299 commentaires sur HN montrent que la question « faut-il laisser entrer le code d'IA dans les projets open source » dépasse depuis longtemps les débats autour d'un seul dépôt.