Le 7 octobre 2026, la proposition QEP 428, intitulée « No AI contributions permitted », a été approuvée puis fusionnée dans le dépôt des propositions d'évolution de QGIS, via la pull request #387. Le logiciel, installé dans des agences publiques, des bureaux d'études et des universités, abandonne sa politique « human in the loop », où un humain supervise ce que produit l'IA. À la place : aucune contribution assistée par IA ou agent n'est admise.
Le calendrier est serré pour un projet qui prend d'ordinaire son temps : discussion ouverte en juin 2026 sur la liste qgis-developer, dépôt le 24 septembre, vote le 5 octobre, fusion le 7. Côté chiffres, environ 50 pull requests étiquetées « AI Assisted » ont été déposées, une quarantaine fermées sans fusion. Le tag « extractive », annoncé pour les trier, n'a jamais vu le jour.
Cinquante pull requests, une quarantaine de refus
L'ancienne politique demandait aux relecteurs de jauger la part d'IA dans chaque patch. Autrement dit, de faire un travail de plus, bénévolement. Or un patch se génère en quelques secondes et se relit en heures. QGIS n'est pas seul : le bureau COSMIC (System76) a banni le code IA, OpenJDK a posé sa politique en août 2026, et GCC a encadré en juillet le code « juridiquement significatif » produit par un modèle de langage. Les projets diffèrent, la lassitude des relecteurs est la même.
Avec QEP 428, le contributeur n'a plus qu'une question à affronter : « as-tu écrit ce code ? ». Le projet ne prétend pas pouvoir le vérifier. Tim Sutton, membre du comité de pilotage, le dit sans détour dans la discussion préparatoire :
« Nous savons que c'est difficile à faire respecter, mais si nous découvrons par la suite que vous avez utilisé un LLM pour votre contribution, vous risquez la réversion du code et des sanctions sur vos droits de contributeur. »
C'est une règle qui repose sur la parole donnée. Elle dissuadera les honnêtes, et laissera passer ceux qui mentent, tant qu'un patch généré reste indiscernable d'un patch écrit à la main. OpenJDK a fait le même choix, faute de détecteur fiable. QGIS envisage de brancher une attestation sur son flux de contribution, pour que chaque pull request porte une déclaration explicite. Cela donne un motif de sanction après coup, pas une preuve.
Autocomplétion, traduction, revue : où s'arrête l'interdit ?
Le texte vise les contributions au dépôt de code. Il ne dit rien des issues, des descriptions de pull requests, de la documentation, ni du dépôt des propositions d'évolution. Reste le cas le plus embarrassant : l'autocomplétion d'IDE, les outils de traduction, la revue assistée, que des mainteneurs utilisent eux-mêmes. Une complétion de ligne n'est pas un agent qui écrit le patch, mais le texte ne place la ligne nulle part. Pour des bénévoles débordés, bannir aussi ce qui les soulage serait un drôle de service.
Nyall Dawson, auteur de la proposition et l'un des contributeurs les plus actifs du projet, assume : QEP 428 est une position de départ, restrictive, à assouplir au cas par cas. Une proposition sœur, QEP 429, prévoit une exception pour les contributeurs de confiance. Elle n'est pas tranchée à ce jour.
« +1 », par l'un de ceux que la règle vise
Dans la discussion, un contributeur, Amalvir, a laissé un commentaire qui vaut mieux que bien des arguments de principe. Il a déposé deux correctifs de régressions assistés par IA. Puis il a écrit ceci :
« Je suis directement concerné par cette nouvelle politique, et c'est aussi un +1 pour moi. Quand j'ai créé mes deux pull requests de correction de régressions assistées par IA […] je n'ai pas réalisé le mal que cela pouvait causer à la communauté de relecteurs de QGIS, déjà fragile. Je ne suis clairement pas encore assez compétent pour corriger des bugs dans un projet aussi complexe que QGIS, mais les LLM donnent l'illusion que c'est possible. »
Il voulait aider, il a trouvé des bugs, les outils étaient là. Ses correctifs avaient l'air plausibles ; il ne pouvait pas savoir s'ils l'étaient. C'est la faille de la politique « human in the loop » : elle suppose un humain capable de juger ce que la machine lui tend. Dans une base de code de cette taille, peu le sont. L'interdit tranche là où la consigne laissait chacun s'évaluer lui-même.
La discussion a aussi fait surgir une idée plus étrange : un « proof of life » pour tout nouveau contributeur, soit une micro-contribution financière, soit une rencontre avec un contributeur existant, avant d'accepter sa première contribution. Le but : écarter les bots et les « karma farmers ». L'objection est venue vite : contribuer à QGIS demande déjà du matériel coûteux et des années de formation, et un péage ajoute une barrière. L'idée n'a pas été retenue dans le QEP.
Les studios sont-ils concernés ?
Pas aujourd'hui : aucun texte, à notre connaissance, n'oblige un freelance à certifier l'origine de ses lignes de code. Aucun marché public, aucune clause contractuelle n'a été identifié ici qui reprenne la logique de QGIS. L'hypothèse, et ce n'en est qu'une, est que des clients exigeants finissent par poser la question « qui a écrit ça, avec quels outils ? » quand ils mettent deux prestataires en concurrence. Dans ce cas, un historique Git lisible et des commits explicites vaudraient mieux que des promesses. Mais ce scénario reste à vérifier.
Prochaine étape : QEP 429 et la clause de révision
Le logiciel libre aime les décisions collectives ; le reste du marché, nettement moins, et rien ne dit que d'autres projets suivront. Pour QGIS, la suite est concrète : QEP 429 et l'exception pour les contributeurs de confiance devront être tranchées, et QEP 428 lui-même est présenté comme révisable. C'est à ce moment qu'on saura si l'interdit tient, ou s'il n'était qu'un coup d'arrêt le temps de souffler.