Le vote de Debian sur les contributions par IA arrive sur Hacker News, mais le vrai combat porte sur la responsabilité humaine

Debian a ouvert son premier vote contraignant sur les contributions réalisées avec l’IA, faisant passer un conflit de longue date des listes de diffusion à Hacker News et à un scrutin officiel. Les développeurs doivent classer huit options de politique couvrant le code assisté par LLM, la documentation, les traductions, les rapports de bugs et les communications du projet. Une neuvième option, « None of the above », préserve la possibilité de rejeter toutes les politiques proposées.

Le vote ne se résume pas à un affrontement entre l’adoption de l’IA et son interdiction. Certaines options autoriseraient les outils génératifs tout en attribuant la responsabilité au contributeur humain. D’autres décourageraient ou interdiraient leur utilisation en raison de préoccupations liées aux licences, à la qualité, à l’environnement et à la communauté.

Cette distinction compte au-delà de Debian. Les projets open source évaluent traditionnellement les travaux soumis, et non chacun des outils utilisés pour les produire. L’IA générative met ce modèle sous tension, car elle peut créer davantage de correctifs et de textes que les responsables bénévoles ne peuvent raisonnablement examiner. Debian doit décider si les règles de responsabilité existantes peuvent absorber ce changement.

Le titre sur Hacker News masque un scrutin à neuf options

Debian ne vote pas sur une seule politique concernant l’IA. Le projet classe plusieurs définitions incompatibles de ce qui constitue une contribution acceptable.

Le processus formel a commencé lorsque le secrétaire du projet Debian, Kurt Roeckx, a annoncé une résolution générale le 24 juillet 2026. Une résolution générale permet aux développeurs Debian de prendre une décision à l’échelle du projet conformément à sa constitution. Les discussions ont produit huit options de fond avant l’ouverture du vote en août.

Le bulletin officiel couvre un éventail bien plus large que ne le laisse entendre le titre sur Hacker News. L’option 1 ajouterait à la Social Contract de Debian une interdiction des contributions directement assistées par LLM. Elle couvre l’empaquetage, les logiciels Debian, la documentation, les traductions et les ressources web officielles.

Cette proposition distingue le travail réalisé directement pour Debian des logiciels en amont. Debian pourrait toujours distribuer un paquet en amont contenant du travail assisté par IA au titre de cette proposition. La restriction s’appliquerait aux contributions effectuées directement dans les limites du propre projet Debian.

L’option 1 reconnaît également que son application serait difficile. Ses auteurs présentent l’interdiction comme une déclaration de l’intention de la communauté, soutenue par une conformité de bonne foi. La proposition constitue ainsi en partie une déclaration constitutionnelle sur l’identité de Debian.

L’option 2 adopte une approche presque opposée. Elle autoriserait les contributions partiellement ou entièrement générées lorsque les contributeurs respectent six conditions. Ces conditions couvrent la compatibilité juridique, les licences, l’attribution, la responsabilité, la divulgation, les soumissions en masse et la confidentialité.

Dans le cadre de cette option, les contributeurs doivent comprendre et pouvoir défendre tout ce qu’ils soumettent. Une assistance substantielle de l’IA devrait être signalée au public visé. Un commit pourrait utiliser un trailer lisible par machine tel que Generated-By: ou Assisted-By:.

L’option 3 rejetterait l’utilisation des LLM partout où cela est possible en pratique et interdirait les messages destinés à des humains et assistés par IA. Son périmètre comprend les rapports de bugs, les messages sur les listes de diffusion, les discussions Salsa et les publications de la communauté Debian. Elle traiterait également les violations comme des problèmes de conduite.

L’option 4 accepte les travaux assistés par IA créés spécifiquement pour Debian. Elle attribue l’entière responsabilité à la personne qui les soumet et recommande de signaler le travail assisté à un endroit approprié. Elle interdit aussi l’envoi d’informations sensibles du projet vers des systèmes d’IA dans le cloud.

L’option 5 estime que l’IA générative ne mérite ni approbation ni interdiction spécifique. Elle applique les attentes existantes de Debian en matière de qualité, de maintenabilité et de conformité juridique, quel que soit l’outil de production. La divulgation est encouragée mais non obligatoire.

L’option 6 encourage la paternité humaine et conseille d’éviter l’IA générative lorsque cela est possible en pratique. Elle préserve toutefois la liberté d’appréciation des contributeurs et n’exige pas de divulgation. Les responsables resteraient libres de refuser les soumissions assistées par IA.

L’option 7 place l’identité de Debian en tant que projet créé par des humains au centre. Elle couvre l’empaquetage Debian, l’infrastructure, la communication, la documentation et les plateformes du projet, tout en excluant le travail en amont. Elle autorise l’IA pour l’exploration ou la critique tant que le contenu généré ne devient pas la contribution elle-même.

L’option 8 considère le coût environnemental des LLM comme l’enjeu décisif. Elle demande aux contributeurs d’éviter leur utilisation et présente l’impact climatique comme incompatible avec les responsabilités de Debian. « None of the above » complète le bulletin.

Seule la première option modifie la Social Contract de Debian ; elle doit donc obtenir une majorité de trois voix contre une. Les autres propositions nécessitent une majorité simple. Ce seuil plus élevé reflète l’importance constitutionnelle d’une réécriture d’un document fondamental du projet.

Debian utilise un vote préférentiel plutôt que de demander aux développeurs de cocher une seule case. Les votants peuvent classer les options selon leurs préférences, et le processus compare les options jusqu’à identifier un vainqueur atteignant la majorité requise. Un compromis peut donc l’emporter sur une proposition polarisante sans être le premier choix de chacun.

Cette structure change le récit. La question centrale n’est pas de savoir si Debian apprécie l’IA. Le projet décide où commence la responsabilité, quels usages exigent une divulgation et si certains outils entrent en conflit avec les valeurs de Debian avant même le début de la revue.

Debian choisit entre des règles sur les outils et des règles sur les résultats

Le conflit principal oppose les restrictions sur les outils d’IA à la responsabilité concernant le travail produit par ces outils.

La revue open source traditionnelle se concentre sur les artefacts. Un responsable inspecte un correctif, vérifie sa licence, exécute des tests, évalue sa maintenance future et décide s’il améliore le projet. L’auteur reste responsable des défauts, quel que soit l’éditeur ou le compilateur utilisé.

L’IA générative complique cet arrangement, car elle modifie l’économie de la soumission. Produire un correctif plausible peut prendre quelques minutes, tandis que comprendre et examiner ce correctif peut prendre des heures. Le contributeur gagne en rapidité, mais le réviseur hérite de l’incertitude.

Une politique centrée sur les outils tente d’arrêter ce déséquilibre avant qu’il n’entre dans la file d’attente. Une interdiction affirme que certaines méthodes de production créent des risques inacceptables, même lorsque le résultat semble utilisable. La divulgation obligatoire donne aux responsables des informations qu’ils peuvent exploiter pour adapter le niveau d’examen.

Une politique centrée sur les résultats conserve le modèle existant. Elle demande si le correctif est correct, maintenable, légal et utile. Si un humain le signe et le soumet, cette personne en accepte la responsabilité, quelle que soit l’ampleur de l’assistance reçue au préalable.

L’option 2 tente de combiner les deux approches. Elle autorise l’assistance par IA, mais exige que le contributeur comprenne le travail et vérifie son statut juridique. Elle demande également une divulgation lorsqu’une part importante provient d’un outil génératif.

Ce compromis soulève ses propres questions. L’assistance « importante » ne possède pas de définition mécanique. Un contributeur peut divulguer une fonction générée, tandis qu’un autre peut considérer l’auto-complétion répétée de code comme de l’édition ordinaire.

L’option 4 reconnaît ouvertement cette ambiguïté. Son texte note que les contributeurs peuvent ne pas savoir qu’un outil léger de complétion s’appuie sur des modèles génératifs. Elle fait donc confiance aux personnes qui soumettent les contributions pour juger quand l’étiquetage s’applique et recommande la divulgation en cas de doute.

L’option 5 pousse plus loin encore la gouvernance fondée sur les résultats. Elle affirme que le travail assisté par IA doit respecter les mêmes normes que tout le reste. Téléverser aveuglément du contenu généré demeure inacceptable parce que cela enfreint les attentes établies en matière de revue, et non parce qu’il existe une catégorie spéciale d’IA.

Le différend porte donc sur l’endroit où Debian doit introduire de la friction. Une règle sur les outils en ajoute avant la soumission. Une règle sur les résultats en ajoute pendant la revue et l’application des règles. Les deux voies reposent toujours sur le jugement humain.

Les propositions les plus strictes soutiennent que l’examen des seuls résultats passe à côté de préjudices plus larges. Elles citent notamment les données d’entraînement protégées par le droit d’auteur, la paternité incertaine, l’extraction agressive du web, les coûts environnementaux et l’atteinte à la collaboration humaine. Un correctif techniquement correct ne répond pas à ces objections.

Les propositions permissives répliquent que Debian ne peut pas, de manière réaliste, auditer les flux de travail privés. Un contributeur peut copier du code généré sans en divulguer l’origine. Une règle que seuls les contributeurs honnêtes respectent risque de pénaliser les utilisateurs transparents tout en laissant intacte l’utilisation dissimulée.

Ce problème d’application est apparu à plusieurs reprises dans une précédente discussion sur Hacker News. Certains commentateurs ont soutenu que les soumissions peu travaillées constituent le véritable problème et qu’elles devraient faire l’objet d’un meilleur tri. D’autres considéraient le code généré par IA comme fondamentalement incompatible avec les valeurs du logiciel libre.

Ces positions ont davantage de terrain commun que leur rhétorique ne le suggère. Aucun des deux camps ne souhaite que les responsables soient submergés de code que son auteur ne peut expliquer. Aucun ne souhaite que des identifiants, des vulnérabilités sous embargo ou des messages privés soient envoyés à des modèles externes.

Le désaccord commence après ce consensus. Un camp considère que la responsabilité des contributeurs est suffisante lorsqu’elle est correctement appliquée. L’autre estime que les systèmes génératifs introduisent des préjudices que la revue des artefacts ne peut ni détecter ni réparer.

La future politique de Debian indiquera aux contributeurs quelle théorie prévaut. Plus important encore, elle dira aux responsables s’ils peuvent rejeter un travail en raison de son origine, avant même d’avoir démontré un défaut dans son résultat.

Les responsables bénévoles supportent le coût de l’échelle générée par IA

Le vote compte parce que l’IA peut accroître le volume des soumissions plus vite que Debian ne peut accroître la qualité de sa revue humaine.

Debian est construit par des bénévoles et maintenu grâce à une confiance distribuée. Les responsables de paquets évaluent régulièrement les rapports de bugs, les correctifs, les transitions de versions, les mises à jour de sécurité et les changements en amont. Leur attention disponible est limitée.

Les outils génératifs affaiblissent l’ancienne relation entre l’effort de l’auteur et celui du réviseur. Une personne peut produire un correctif volumineux sans comprendre chaque branche ou dépendance. Le correctif peut sembler cohérent tout en cachant des hypothèses qui n’apparaissent que dans des configurations inhabituelles.

Cela ne signifie pas que chaque correctif assisté par IA est défectueux. Cela signifie qu’une présentation soignée ne signale plus la quantité d’investigation effectuée. Les responsables doivent établir la compréhension par la discussion, les tests et la capacité du contributeur à expliquer ses décisions.

Plusieurs options du bulletin réagissent en rendant la responsabilité explicite. Les contributeurs doivent garantir la valeur technique, la sécurité, les licences et l’utilité de leurs soumissions. Ils doivent également comprendre suffisamment les changements proposés pour pouvoir les justifier.

Cette exigence ressemble au contrat social existant entre un auteur et un réviseur. Un correctif n’est pas simplement du texte placé dans une file d’attente. C’est l’affirmation que le changement a sa place dans un système maintenu et que quelqu’un répondra aux questions à son sujet.

L’automatisation en masse soulève une version plus aiguë du problème. L’option 2 exige une discussion préalable avant des soumissions de masse automatisées ou autonomes. Elle compare ce processus aux attentes existantes de Debian pour le dépôt massif de rapports de bugs.

Cette garantie cible l’échelle plutôt que l’identité du modèle. Un correctif généré peut faire l’objet d’une revue ordinaire. Des centaines de correctifs générés peuvent monopoliser l’attention du projet avant que les responsables ne déterminent si le flux de travail est fiable.

Le même problème s’étend au-delà du code. L’IA peut générer des rapports de bugs, des modifications de documentation, des traductions et de longs arguments sur les listes de diffusion. Chaque élément peut exiger une réponse humaine, même lorsque son auteur a passé peu de temps à le préparer.

Le choix 3 répond en réservant la communication destinée aux humains aux auteurs humains. Ses auteurs estiment que les gens ne devraient pas consacrer bénévolement du temps à lire une prose qu’une autre personne n’a pas écrite. La politique considère l’authenticité conversationnelle comme une ressource communautaire.

Cette restriction peut aussi créer des coûts d’accès. Les contributeurs qui utilisent une aide à la traduction ou à la rédaction peuvent communiquer plus clairement avec un projet international. Une règle générale pourrait rendre la participation plus difficile pour les personnes travaillant en dehors de leur langue la plus maîtrisée.

La proposition répond à cette préoccupation en invitant les contributeurs à écrire dans leur langue maternelle. Les lecteurs pourraient alors utiliser eux-mêmes des outils de traduction. Un résumé en anglais rédigé par un humain serait bienvenu, mais non obligatoire.

Cette solution déplace la frontière entre l’outil et l’humain au lieu d’éliminer la technologie. L’auteur ne peut pas utiliser un LLM pour rédiger le message Debian, mais un lecteur peut recourir à un logiciel de traduction pour le comprendre. La question de savoir si cet arrangement peut s’adapter à un projet multilingue reste incertaine.

L’accessibilité ajoute une autre complication. Certains développeurs utilisent des outils vocaux, des systèmes de complétion ou des agents génératifs parce que la saisie est difficile. Une interdiction fondée sur les méthodes de production peut affecter ces contributeurs différemment des développeurs qui utilisent surtout l’IA pour aller plus vite.

Une politique fondée uniquement sur le résultat évite cette distinction. Toutefois, elle donne aux mainteneurs moins d’indices sur la manière dont le travail a été créé et relu. Le projet doit alors détecter une compréhension insuffisante par la discussion plutôt que par la divulgation.

D’autres communautés open source ont déjà adopté des positions différentes. La politique IA de Gentoo exige que les contributeurs assument la responsabilité des travaux assistés par IA et les met en garde contre la soumission de contenus qu’ils ne comprennent pas. Elle insiste sur la relecture, les licences et les informations sensibles.

GNOME a également connu des restrictions au niveau de projets individuels. La visionneuse d’images Loupe a annoncé qu’elle n’accepterait plus les contributions issues d’IA générative, invoquant les coûts de maintenance et les préoccupations de la communauté. Ce débat GNOME illustre comment des mainteneurs individuels peuvent agir avant qu’une fondation plus large n’adopte une règle commune.

L’ampleur de Debian rend son choix plus lourd de conséquences. Ses paquets atteignent les utilisateurs, les images cloud, les conteneurs, les distributions dérivées et les systèmes d’entreprise. Pourtant, le vote concerne la gouvernance du projet, et non une conclusion selon laquelle les paquets Debian existants contiennent du code généré par IA non sûr.

Cette distinction doit rester claire. Les documents de vote exposent des risques et des principes concurrents. Ils ne fournissent pas de taux de défauts mesurés pour les contributions assistées par IA au sein de Debian. Ils n’établissent pas non plus combien de contributeurs utilisent actuellement ces outils.

La pression immédiate s’exerce donc sur les mainteneurs, pas sur les utilisateurs finaux. Ils ont besoin de règles leur permettant de protéger leur capacité de relecture sans transformer chaque discussion sur un correctif en enquête sur des outils privés.

La divulgation paraît simple jusqu’à ce que Debian doive l’appliquer

Chaque compromis majeur dépend d’informations que Debian ne peut pas observer de manière fiable et indépendante.

La divulgation semble offrir un terrain d’entente praticable. Les contributeurs signalent une assistance substantielle de l’IA, les relecteurs appliquent le niveau d’examen approprié et les mainteneurs peuvent suivre les tendances au fil du temps. Un usage honnête devient visible sans interdire la technologie.

Le problème est la vérification. Le code généré ne possède pas d’empreinte universelle. Les détecteurs de style peuvent produire des faux positifs, notamment sur du code répétitif, une documentation conventionnelle ou des textes rédigés par des personnes non anglophones de naissance.

Une étiquette obligatoire repose donc largement sur l’auto-déclaration. Les contributeurs qui comprennent la règle et respectent la communauté la divulgueront. Un soumetteur négligent ou trompeur peut omettre l’étiquette, laissant aux mainteneurs le soin d’inférer l’origine à partir du comportement.

Cette asymétrie soutient les critiques de la divulgation. Une politique peut accroître le travail administratif des contributeurs responsables sans empêcher les soumissions qui créent la plus lourde charge de relecture. Les litiges de détection pourraient aussi nuire à la confiance entre mainteneurs et nouveaux venus.

Pourtant, le fait qu’une norme soit difficile à faire respecter ne la rend pas automatiquement inutile. Les projets open source s’appuient déjà sur des déclarations impossibles à auditer en continu. Les commits signés confirment une identité et une action, mais ne révèlent pas tous les outils utilisés pendant le développement.

Une règle de divulgation établit ce que le projet considère comme une conduite honnête. Lorsqu’un usage non divulgué devient évident grâce à des journaux, des aveux ou des comportements répétés, les mainteneurs disposent d’une base définie pour réagir. La règle peut orienter les comportements sans surveillance parfaite.

Les définitions restent la question la plus difficile. Demander à un modèle d’expliquer une erreur du compilateur compte-t-il comme une assistance ? Qu’en est-il de générer un test, de réécrire un message de commit, de traduire de la documentation ou d’accepter une seule complétion ?

Le choix 7 trace une limite autour de l’artefact soumis. Il autorise l’IA générative pour la recherche, l’analyse et la critique lorsque sa sortie ne fait pas partie de la contribution directe. Cette règle se concentre sur ce qui entre dans Debian plutôt que sur chaque interaction préparatoire.

Le choix 2 utilise un seuil d’importance. Cette approche offre de la flexibilité, mais crée une interprétation incohérente. Différentes équipes pourraient développer des attentes différentes, notamment lorsqu’un mainteneur accepte les outils de complétion et qu’un autre les refuse.

Le choix 5 évite entièrement un mandat de divulgation. Il encourage la transparence tout en considérant que les règles habituelles de qualité et de licence suffisent. Cela réduit les conflits de classification, mais donne aux relecteurs moins de contexte.

L’incertitude juridique résiste également à une simple étiquette. Un contributeur ne peut pas garantir que la sortie d’un modèle ne contient aucune expression protégée simplement parce qu’il divulgue son origine. À l’inverse, du code rédigé par un humain et non étiqueté peut aussi enfreindre des droits d’auteur ou violer une licence.

Les Free Software Guidelines de Debian, communément appelées DFSG, définissent les exigences de la distribution en matière de liberté logicielle. Plusieurs propositions exigent que les travaux assistés par IA respectent ces normes existantes. Elles ne prétendent pas que le vote puisse régler les questions mondiales relatives à la paternité des œuvres par les machines.

Cette retenue est importante. Le traitement du droit d’auteur varie selon les juridictions et dépend des faits entourant la paternité humaine, l’entraînement et les contenus reproduits. Debian peut contrôler ce qu’elle accepte, mais ne peut pas créer une réponse juridique universelle.

La confidentialité présente un domaine d’accord plus concret. Les propositions permissives interdisent ou déconseillent l’envoi d’informations Debian privées à des services cloud non fiables. Parmi les exemples figurent les embargos de sécurité, les identifiants, les clés cryptographiques, les informations personnelles et les communications privées.

Cette règle peut être évaluée au moyen des pratiques de sécurité habituelles. Les contributeurs ne devraient pas coller des données de projet protégées dans un service externe sans autorisation. Le risque existe, que la sortie générée devienne ou non ensuite un correctif.

La conclusion sceptique est qu’aucun choix du scrutin n’élimine le jugement humain. Une interdiction oblige les personnes à définir l’assistance et à enquêter sur les violations présumées. Une acceptation conditionnelle oblige les personnes à interpréter l’importance, la responsabilité et l’adéquation de la relecture.

Une gouvernance fondée sur le résultat exige également du jugement. Les mainteneurs doivent déterminer si un contributeur comprend réellement une modification et si sa provenance juridique est défendable. Les tests peuvent étayer cette évaluation, mais ils ne peuvent pas répondre à toutes les questions de maintenance.

La politique gagnante ne sera donc qu’un point de départ. Les équipes Debian auront encore besoin de conventions pratiques pour les étiquettes de commit, l’escalade des revues, l’aide à la traduction, l’accessibilité et les soumissions répétées de faible qualité.

Trois signaux montreront ce que le vote de Debian sur l’IA change réellement

Le résultat compte, mais sa mise en œuvre révélera si Debian a choisi une règle utilisable ou seulement une position symbolique.

Le premier signal sera le classement final et la coalition qui l’emporte. Une interdiction large montrerait que Debian considère les méthodes de production comme faisant partie de la liberté logicielle. Une victoire de l’acceptation conditionnelle préserverait l’usage de l’IA tout en formalisant la responsabilité humaine.

L’écart compte aussi. Le système de vote de Debian permet aux développeurs de classer les choix plutôt que de sélectionner une position isolée. Les préférences ultérieures peuvent déterminer quel compromis survit aux comparaisons directes.

Un résultat serré laisserait subsister un désaccord important au sein du projet. Les mainteneurs pourraient appliquer la politique avec prudence ou chercher des règles locales. Un résultat décisif donnerait aux équipes une autorité plus claire pour traiter les contributions contestées.

Le deuxième signal sera les directives de mise en œuvre qui suivront. Il faudra surveiller l’apparition de trailers de commit standardisés, de modèles de contribution, d’avertissements sur la confidentialité ou d’une documentation expliquant ce qui constitue une assistance substantielle.

Des directives claires renforceraient une politique fondée sur la divulgation. Elles réduiraient les incohérences accidentelles et aideraient les contributeurs à comprendre les attentes avant de soumettre leur travail. Le silence transférerait l’interprétation aux mainteneurs individuels.

Les exceptions au niveau des projets méritent également attention. Certaines propositions préservent explicitement la capacité d’un mainteneur à refuser des travaux assistés par IA. Si de nombreuses équipes annoncent des règles plus strictes, Debian pourrait développer une politique fragmentée malgré une résolution à l’échelle du projet.

Ce résultat ne représenterait pas nécessairement un échec. Les équipes de paquets font face à des charges de travail, des risques de sécurité et des relations avec l’amont différents. Toutefois, des règles incohérentes rendraient la participation plus difficile pour les contributeurs travaillant sur plusieurs parties de Debian.

Le troisième signal sera le comportement observable des revues au cours des mois suivants. Les mesures utiles ne sont pas les affirmations sur la productivité. Ce sont les changements dans les soumissions massives rejetées, la fréquence des divulgations, les litiges de relecture et les réactions des contributeurs.

Une hausse des correctifs bien étiquetés et bien expliqués soutiendrait l’approche fondée sur la responsabilité. Des soumissions répétées non divulguées ou de longues querelles sur la détection renforceraient l’argument selon lequel la divulgation ne peut pas protéger l’attention des bénévoles.

À l’inverse, une interdiction qui déclenche des conflits de classification constants révélerait son propre coût de mise en œuvre. Si les mainteneurs ne peuvent pas distinguer la génération interdite de la recherche ou de la complétion autorisées, la limite pourrait devoir être révisée.

Les réactions sur Hacker News continueront d’amplifier les deux extrêmes. Un camp décrira toute restriction comme une résistance à des outils de développement utiles. L’autre considérera l’acceptation conditionnelle comme une capitulation face à une production automatisée de faible qualité.

La décision réelle de Debian est plus précise. Elle concerne la personne qui supporte le coût lorsque générer une contribution devient plus facile que la relire. Chaque proposition répartit ce coût différemment entre les auteurs, les mainteneurs et la communauté au sens large.

Les développeurs extérieurs à Debian devraient suivre cette question, car des conflits similaires se déplacent vers la gouvernance des projets. Les normes informelles fonctionnaient lorsque l’assistance de l’IA était occasionnelle et difficile à étendre. Les agents automatisés rendent visibles les lacunes des politiques en multipliant les soumissions plausibles.

Les utilisateurs en entreprise devraient s’y intéresser pour une autre raison. Ils dépendent des pratiques de maintenance open source, même lorsqu’ils ne contribuent jamais de correctif. Une capacité de relecture durable affecte la réponse aux failles, la qualité des paquets et la continuité des logiciels fondamentaux.

Les travailleurs du savoir sont également confrontés à la même question de responsabilité. Un document généré, soigné en apparence, peut transférer le travail de vérification de son auteur à chaque lecteur. Les équipes doivent décider si la divulgation, les normes de relecture ou des usages restreints contrôlent le mieux ce transfert.

La politique la plus durable sera probablement celle que les mainteneurs peuvent appliquer sans devenir des détectives d’outils. Elle doit rejeter les travaux qui imposent une charge déraisonnable aux relecteurs tout en préservant une assistance utile pour des contributeurs responsables.

Le vote de Debian ne réglera pas la place de l’IA dans l’open source. Il constituera un véritable test de gouvernance au sein de l’un des projets les plus influents du logiciel libre. Suivez le résultat, puis observez les files d’attente de revue, les pratiques de divulgation et les règles appliquées par les mainteneurs locaux. Ces signaux montreront si le débat sur Hacker News a débouché sur une responsabilité concrètement applicable ou simplement sur une nouvelle querelle autour des outils.