Debian soumet l’usage des LLM dans ses contributions à un vote général à huit options
Depuis le 15 août 2026 et jusqu’au 28 août, les développeurs Debian votent sur une résolution générale encadrant l’usage des LLM dans les contributions du projet, avec huit propositions et un « None of the above ». Le résultat fixera une norme de fait pour la chaîne d’approvisionnement des distributions Linux d’entreprise.
15 août 2026. Debian ouvre le vote sur une résolution générale intitulée LLM usage in Debian. 28 août 2026. Le scrutin se clôt, au terme de treize jours pendant lesquels seuls les Debian Developers peuvent classer huit propositions plus un « None of the above ». Pour un SRE ou un RSSI qui consomme Debian comme socle d’infrastructure, l’enjeu n’est pas folklorique : c’est la première fois qu’une distribution majeure soumet la question « combien d’IA dans le code » à un vote structurant de tout le projet.
Le résultat ne changera pas le binaire que vous téléchargez demain. Il changera la réponse à une question qui, elle, vous concerne directement : quand un mainteneur Debian fusionne un patch, pouvez-vous présumer qu’un humain l’a compris ?
Huit propositions, un spectre complet
Le scrutin porte sur huit propositions (notées A à H sur la page de vote), départagées par le vote par classement habituel de Debian — un système de type Condorcet où chaque électeur ordonne ses préférences. Huit textes, donc, qui ne se contentent pas d’opposer « pour » et « contre » : ils dessinent un spectre complet, de l’interdiction pure à la neutralité assumée.
La proposition A est la plus dure. Elle modifie le Contrat Social Debian pour interdire les contributions assistées par LLM au travail direct du projet — empaquetage, logiciels, documentation, traductions, sites web, communication. Les projets amont développés avec de l’IA ne seraient pas affectés, mais ce qui entre dans Debian devrait être écrit par des humains. Ses partisans invoquent le flou du droit d’auteur et des licences, la fiabilité douteuse du code généré, la charge de relecture supplémentaire pour les mainteneurs, le scraping agressif des ressources du logiciel libre et l’empreinte énergétique des grands modèles.
Les propositions B, D et E autorisent l’IA, mais déplacent la responsabilité. La B impose au contributeur de vérifier la qualité technique, la sécurité, les licences et l’utilité de ce qu’il soumet, d’en comprendre pleinement les changements et de déclarer toute aide majeure d’un LLM — tout en interdisant l’envoi d’informations privées ou sensibles de Debian à des services d’IA externes non fiables. La D accepte le travail assisté s’il respecte les DFSG, s’il est relu et compris par le contributeur, et s’il est marqué comme tel quand c’est nécessaire. La E, la plus neutre, refuse de soutenir ou d’interdire les outils d’IA générative : elle applique les mêmes standards de qualité, de correction, de maintenabilité et de légalité à toutes les contributions, quelle que soit leur origine.
Deux propositions sortent du cadre binaire. La F, intitulée « Debian is created by humans », autorise l’IA pour la recherche, l’analyse, l’exploration ou la critique, mais interdit de soumettre directement la sortie d’un modèle comme travail Debian — patch, paquet, documentation, rapport de bug ou communication. La H, elle, place l’argument environnemental au centre : elle demande d’éviter les LLM autant que possible, au motif que leur consommation de ressources est un problème écologique sérieux, tout en reconnaissant que la détection de l’IA est peu fiable et que Debian ne peut pas contraindre ses projets amont.
Enfin, la G durcit la communication : rapports de bug, messages de liste, discussions Salsa, billets Planet Debian devraient être écrits uniquement par des humains, toute utilisation d’IA dans le travail Debian devrait être déclarée, et les manquements pourraient être traités par le Code de Conduite.
Pourquoi ce vote dépasse Debian
Debian n’est pas le premier projet libre à trancher la question — il est le plus massif à la poser aussi nettement. Le contexte récent est une suite de positions divergentes : Rust a adopté une politique officielle sur les contributions générées par IA, Gentoo a instauré une interdiction, GCC rejette le code généré significatif, Codeberg a banni les projets écrits majoritairement par IA générative, et Fedora a soumis une proposition de politique. Chaque projet tranche seul, sans jurisprudence commune.
Ce qui rend le cas Debian singulier, c’est sa position dans la chaîne d’approvisionnement. Debian n’est pas un langage ni un forgeron : c’est une distribution qui agrège des dizaines de milliers de paquets et sert de base à des dérivées entières — Ubuntu, une large part du cloud et de l’infrastructure d’entreprise. La norme que Debian se donne pour « ce qui peut entrer dans le projet » devient, par capillarité, une norme de fait pour tout ce qui se construit dessus. Un RSSI qui exige de ses fournisseurs une traçabilité des contributions lira la résolution finale comme un précédent.
Il y a aussi une dimension de précédent interne. Debian a déjà voté, par le passé, une résolution sur l’interprétation des DFSG pour les modèles d’IA — retirée depuis. La question « l’IA générative a-t-elle sa place dans le projet » revient donc sous une forme plus opérationnelle, moins philosophique : non plus « un modèle est-il libre », mais « qui répond d’une contribution produite par une machine ».
Le vrai clivage, et ce qu’il faut surveiller
Sous la profusion des huit textes, le clivage réel est plus simple qu’il n’y paraît. D’un côté, la A part du principe qu’une contribution générée est irréparablement suspecte — on ne peut ni en établir la paternité, ni en garantir la licence, ni en prouver la compréhension. De l’autre, les B, D et E partent du principe qu’une contribution vaut ce que l’humain qui la signe en a compris et assumé — l’outil est secondaire, la responsabilité est première.
Entre les deux, la F tente une ligne originale qui pourrait devenir la position de compromis : l’IA assiste le travail de l’humain, mais elle ne produit pas l’artefact qui entre dans Debian. C’est, en creux, la distinction que beaucoup d’équipes d’ingénierie adoptent déjà sans la formaliser — l’IA pour comprendre, l’humain pour décider et signer.
Ce qu’il faut surveiller n’est pas tant le vainqueur que la marge et le quorum. Une résolution qui impose l’interdiction à une courte majorité laissera une partie du projet en désaccord durable, et la question reviendra. Une résolution qui acte la responsabilité du contributeur sans mécanisme de contrôle ne changera presque rien en pratique — elle entérinera le statu quo sous un vocabulaire officiel.
Verdict
Si vous êtes développeur Debian, le vote est votre levier et il se ferme le 28 août 2026 : classez les huit options, et lisez la A et la F en entier avant de trancher — ce sont les deux textes qui définiront la ligne de crête du débat, quel que soit le vainqueur.
Si vous consommez Debian en production, ne traitez pas ce vote comme une affaire interne de communauté. Notez le résultat, puis posez-vous la question de gouvernance qui en découle pour votre propre chaîne : avez-vous une politique écrite sur les contributions assistées par IA dans les paquets que vous assemblez et déployez ? La réponse de Debian va devenir un point de comparaison commode pour vos propres exigences fournisseurs.
Si vous publiez du logiciel, observez la position qui sortira du vote comme un indicateur d’attente du marché : la tendance lourde, chez Rust, GCC et Gentoo comme chez Debian, va vers une responsabilité humaine explicite — la transparence sur l’origine d’une contribution devient une exigence de confiance, pas une option de communication.