Debian discute une résolution pour interdire les contributions générées par IA

Le 24 juillet 2026, le projet Debian a ouvert la période de discussion d'une résolution générale intitulée « LLM usage in Debian ». Le texte, déposé par le développeur Matthias Geiger et soumis au vote de l'ensemble des Debian Developers, propose d'interdire purement et simplement toute contribution rédigée avec l'aide d'un LLM ou d'un autre outil d'IA générative au sein du projet.

Ce n'est pas un simple billet de blog ou une charte informelle. Une résolution générale (General Resolution, ou GR) est le mécanisme constitutionnel le plus lourd dont dispose Debian : c'est l'outil qui a par le passé tranché des sujets aussi sensibles que le choix du système d'initialisation ou l'inclusion de firmwares non libres dans l'archive. Que l'un des plus anciens projets du logiciel libre choisisse ce niveau d'instance pour statuer sur l'IA générative en dit long sur l'ampleur du sujet pour la communauté.

Proposal A : une des quatre propositions soumises au vote

Le texte que nous décryptons ici, identifié Proposal A, n'est qu'une des quatre propositions déposées pour ce vote : les intitulés Proposal A, B, C et D figurent tous au calendrier officiel de la consultation. Proposal A est cependant la plus radicale et la mieux argumentée : elle a été secondée par huit autres développeurs Debian, parmi lesquels Ian Jackson, David Bremner ou Simon Richter, des noms connus des habitués des discussions internes du projet. Au moment de la rédaction de cet article, la période de discussion vient tout juste de s'ouvrir : le texte n'est pas encore adopté, et le résultat du vote reste ouvert.

Ce que Proposal A interdirait exactement

Le périmètre visé par le texte est précis. Selon son auteur, l'interdiction couvrirait, de façon non exhaustive :

• les paquets sources Debian ;
• les logiciels officiels du projet, comme lintian ;
• les ressources web de Debian ;
• la documentation et les traductions ajoutées par les contributeurs ;
• la communication officielle du projet.

Le texte prend en revanche soin d'exclure explicitement trois cas : les projets amont (upstream) qui utilisent l'IA pour leur propre développement, les logiciels liés à l'IA en tant que tels, et les correctifs ou correctifs de sécurité fournis directement par l'amont. Autrement dit, Debian ne prétend pas dicter comment les projets tiers développent leur code : la règle ne s'appliquerait qu'au travail produit directement au nom du projet Debian.

Quatre arguments derrière l'interdiction

La rationale qui accompagne le texte détaille quatre familles de préoccupations.

• Copyright. Le statut légal des sorties de LLM reste flou : elles peuvent être protégeables par le droit d'auteur ou non, et peuvent être affectées par l'ensemble des licences présentes dans les données d'entraînement. La Debian Policy et les DFSG exigent une clarté absolue sur les licences et le copyright ; un contenu au statut incertain n'a jamais été toléré dans Debian, qu'il vienne d'un humain ou d'un modèle.
• Qualité. Un LLM ne peut jamais « savoir » si sa sortie est correcte, puisqu'il produit des combinaisons statistiquement probables à partir de ses données d'entraînement. Chaque paquet source Debian étant unique, un paquet généré par IA mêlerait des pratiques de packaging obsolètes et récentes, avec des fichiers watch non fonctionnels, des overrides hors contexte ou des mentions de copyright inventées.
• Communauté. Debian se construit aussi par le mentorat des nouveaux contributeurs. Faire relire du code produit par IA à un mainteneur bénévole alourdit sa charge de revue et favorise l'épuisement, tandis qu'un nouveau contributeur dépendant d'un LLM n'apprend jamais réellement le fonctionnement du projet, et ne pourra donc jamais prendre la relève d'un mainteneur qui se retire.
• Éthique. Le texte pointe aussi le comportement des entreprises d'IA elles-mêmes : l'aspiration massive du web pour entraîner les modèles, sans respect des licences ni des fichiers robots.txt, a mis à mal l'infrastructure publique de Debian, au point de forcer la mise en place de vérifications JavaScript pour protéger certains services.

Un vote encore ouvert, pas une décision actée

Il faut le dire clairement : au moment de la publication de cet article, rien n'est encore tranché. La période de discussion a débuté le 24 juillet 2026, et Debian tranche traditionnellement ses résolutions générales par un scrutin à méthode Condorcet, tel que défini dans sa Constitution. Les propositions B, C et D pourraient offrir des variantes plus souples, ou des périmètres différents ; leur contenu n'a pas été publié dans l'extrait consulté pour cet article. Ce que l'on sait avec certitude, c'est qu'un noyau de développeurs expérimentés pousse pour une interdiction nette, et que le sujet est désormais officiellement sur la table de l'un des projets les plus structurants du logiciel libre.

Ce qui changerait concrètement si le texte est adopté

Si Proposal A l'emporte, voici ce qui basculerait dans le quotidien d'un mainteneur ou d'un contributeur Debian :

• un changelog, un fichier debian/control ou un correctif de packaging rédigé ou corrigé avec l'aide d'un LLM ne pourrait plus être uploadé ;
• un patch soumis à un outil officiel comme lintian et produit avec assistance IA serait refusé en revue ;
• une traduction de documentation faite via traduction automatique ou LLM ne serait plus acceptée : la traduction humaine resterait la norme ;
• en revanche, un correctif de sécurité produit en amont avec l'aide de l'IA par l'éditeur du logiciel resterait intégrable tel quel dans Debian, puisque le texte exempte explicitement les patchs upstream.

Notre lecture chez CZSyn

Nous suivons ce dossier avec attention, parce qu'il pose une question que tout mainteneur de projet open source va devoir trancher tôt ou tard : où placer le curseur entre l'usage légitime de l'IA comme assistant de productivité, et la contribution brute, non relue, produite par un modèle. Debian choisit une réponse tranchée, cohérente avec son identité : la stabilité et la traçabilité du code priment sur la vitesse. Ce n'est pas un hasard si le texte insiste autant sur le copyright et la charge de revue : ce sont exactement les deux points sur lesquels une entreprise qui contribue à de l'open source, ou qui maintient ses propres dépôts internes, peut se faire piéger.

Pour une PME française qui publie des paquets, des modules ou des extensions en logiciel libre, la leçon à retenir dès aujourd'hui, sans attendre l'issue du vote Debian, est simple : documentez votre politique d'usage de l'IA dans votre fichier de contribution, distinguez clairement l'assistance (autocomplétion, revue, débogage) de la génération brute non relue, et gardez une revue humaine systématique sur tout ce qui touche à la licence et au copyright d'un fichier. Que Debian adopte finalement Proposal A, une variante plus souple, ou aucune des quatre propositions, le débat qu'il ouvre dépasse largement le projet lui-même et pourrait bien inspirer d'autres distributions et projets communautaires dans les prochains mois.

Sources primaires

• Debian, « General Resolution: LLM usage in Debian », page de vote officielle, 2026.
• Debian, page officielle sur les résolutions générales et le processus de vote.
• Debian, Contrat social Debian, cité dans la rationale de Proposal A.