Debian reporte sa décision sur les contributions générées par l’IA

• La communauté Debian a débattu de l’autorisation ou non des contributions de code basées sur l’IA ou les LLM, mais a clos la discussion sans conclusion définitive
• Le projet de texte proposé autorisait ces contributions sous conditions, notamment divulgation explicite de l’usage d’outils d’IA, clarification des responsabilités et interdiction d’utiliser des informations sensibles
• Les développeurs étaient divisés sur l’ambiguïté du terme « IA », le périmètre d’usage des LLM, ainsi que sur les questions de qualité, de droit d’auteur et d’éthique
• Certains ont exprimé leur opposition en invoquant des freins à l’onboarding des nouveaux contributeurs, des pratiques d’entreprise contraires à l’éthique et une incertitude juridique
• Debian maintient pour l’instant une évaluation au cas par cas selon les politiques existantes, tout en laissant ouverte la possibilité de poursuivre la discussion

---

Vue d’ensemble du débat de Debian sur les contributions liées à l’IA

• Debian a mené une discussion interne sur l’acceptation ou non de code généré par l’IA, mais celle-ci s’est terminée sans dépôt de résolution générale (GR)
  • Le débat a commencé lorsque Lucas Nussbaum a présenté un projet visant à clarifier la position à adopter vis-à-vis des contributions assistées par l’IA
  • Après avoir recueilli des retours, il a envisagé une soumission officielle, mais la discussion s’est apaisée et aucune résolution n’a été déposée
• Le projet incluait l’obligation de déclarer le code généré par des outils d’IA, la responsabilité explicite du contributeur, la garantie du respect de la sécurité et des licences, ainsi que l’interdiction d’utiliser des informations non publiques

Débat sur la définition des termes et les distinctions techniques

• Plusieurs développeurs ont souligné le manque de clarté du terme « IA » et insisté sur la nécessité de nommer des technologies précises comme les LLM
  • Russ Allbery a estimé que le terme « IA » est trop large pour servir de base à une politique
  • Sean Whitton a proposé de distinguer les usages des LLM selon leur finalité (revue de code, prototypage, code de production)
  • Andrea Pappacoda a indiqué que des projets comme Claude’s C Compiler ne devraient pas être intégrés à Debian
• À l’inverse, Nussbaum a soutenu que le point central n’est pas le type d’outil, mais l’acte même de génération automatisée de code

Onboarding des nouveaux contributeurs et question des coûts

• Simon Richter s’est inquiété du fait que l’IA puisse remplacer les occasions d’apprentissage pour les nouveaux développeurs
  • Il a souligné que, même guidée, l’IA n’apprend pas, et que les ressources investies dans le projet ne se traduisent donc pas par une transmission durable des connaissances
  • Il a aussi été avancé que l’usage de l’IA pourrait accroître la dépendance à des outils payants, réduisant ainsi l’accessibilité pour les contributeurs
• Nussbaum a reconnu qu’un accès gratuit existe aujourd’hui, tout en admettant que la question du coût pourrait se poser à l’avenir
  • Il a rétorqué que l’IA pourrait au contraire rendre des tâches complexes plus accessibles
• Ted Ts’o s’est opposé à l’exclusion des utilisateurs d’IA, la jugeant contradictoire et potentiellement restrictive pour la diversité des contributeurs

Débat sur l’éthique, le droit d’auteur et la qualité

• Matthew Vernon a soutenu que Debian devrait s’opposer clairement à l’IA en raison de la collecte de données non éthique par certaines entreprises du secteur et de son impact environnemental
  • Il a pointé des effets négatifs comme la violation du droit d’auteur, la génération d’images sans consentement et de faux signalements de sécurité
• Jonathan Dowland a proposé de limiter l’acceptation des productions issues de l’IA tant que l’incertitude juridique n’est pas levée
• Thorsten Glaser a plaidé pour le déplacement des projets contenant du code basé sur des LLM vers la section non-free, mais cette idée n’a pas convaincu en raison du risque d’exclure de grands projets comme le noyau Linux ou Python
• Allbery a estimé que les polémiques sur la qualité du code généré par l’IA sont peu pertinentes, rappelant que les humains aussi écrivent du mauvais code
• Bdale Garbee a insisté sur la nécessité d’observer l’impact à long terme de l’IA, qu’il voit comme une nouvelle étape d’évolution

Débat sur la « forme privilégiée pour la modification »

• Nussbaum a répondu que l’entrée d’un LLM (prompt) constitue la forme privilégiée pour la modification, mais la question du caractère non déterministe a relancé le débat
  • Certains ont soutenu que les LLM sont non déterministes et donc inadaptés aux builds reproductibles
  • D’autres ont répliqué qu’une reproduction est possible si l’on conserve la même seed de PRNG et le même environnement
  • La discussion s’est élargie à des détails techniques comme le déterminisme, la reproductibilité et l’asynchronisme des calculs sur GPU

Conclusion : Debian diffère sa décision

• Au sein de Debian, il n’existe même pas encore de consensus sur la définition d’une contribution générée par l’IA
• Beaucoup estiment qu’il n’est pas encore temps de voter une résolution et qu’il vaut mieux poursuivre les échanges sur la mailing-list
• Nussbaum a indiqué qu’un compromis consistant à autoriser l’IA avec des garde-fous serait probablement l’option la plus réaliste
• Pour l’instant, l’évaluation au cas par cas selon les règles existantes reste en vigueur, et les critères de traitement des modèles d’IA, du code issu de LLM et des contributions générées par l’IA demeurent indéfinis
• Face à des évolutions techniques complexes et à la diversité des positions, le statu quo est jugé comme le choix le plus pragmatique

[GN⁺]

Avis sur Hacker News

• J’ai codé toute ma vie, mais après une blessure au poignet qui m’a rendu la frappe presque impossible, les LLM, l’autocomplétion IA et le développement basé sur des agents m’ont permis de produire à nouveau du code de haute qualité
  Même les hallucinations de l’IA m’aident à affiner mes prompts et à clarifier mon intention
  Du point de vue de l’accessibilité, l’IA est pour moi un outil indispensable, et je pense que l’important n’est pas tant de savoir si « le bon compense le mauvais » que d’avoir une attitude d’intégration envers l’écosystème

  • Comme tu le dis, certaines personnes utilisent l’IA de manière raisonnable, mais il est dangereux de supposer que tous les utilisateurs font de même
    Certains projets sont envahis de PR de mauvaise qualité, et beaucoup de contributeurs cherchent simplement à remplir leur profil GitHub
    Au final, la vraie question est de savoir si la contribution est faite de bonne foi, et les projets doivent définir clairement où ils placent la limite
  • J’ai une approche similaire. Au lieu de confier des problèmes difficiles à l’IA, je lui fournis la solution technique que j’avais déjà l’intention d’implémenter, puis je lui fais générer le code
    Cela réduit la fatigue liée à la revue et permet de se concentrer uniquement sur les éléments qui diffèrent de ce qui était attendu
  • J’ai aussi des douleurs au poignet, donc j’utilise la combinaison Whisper + LLM pour la saisie vocale et l’organisation. Cela automatise les e-mails, la rédaction de documents et même le tri des reçus, ce qui aide aussi ma santé
    J’en suis arrivé au point où je ne voudrais plus travailler dans une entreprise qui bloque ce type de fonctionnalités
  • J’ai aussi un TMS, et l’autocomplétion IA m’a beaucoup aidé. En revanche, les IA de type agent ne sont pas très utiles dans un environnement C++/Rust en temps réel
    L’aspect accessibilité est très important, mais les questions de copyright et de responsabilité restent complexes
  • Si l’on peut signer le code et engager sa compétence et sa réputation, alors l’IA n’est qu’un outil d’autocomplétion avancé et devrait être considérée comme une exception aux règles « no AI »

• Je pense qu’au final, la revue de PR est une question de confiance. Il s’agit de croire que la personne qui soumet a fait de son mieux
  Plus que l’usage de l’IA, l’essentiel est de savoir si elle est utilisée de manière responsable

  • Bien sûr, il existe aussi des acteurs malveillants. Des menaces persistantes avancées (APT) comme l’attaque XZ sont une réalité dans l’open source
    Plusieurs faux comptes peuvent appartenir à un seul attaquant, et le code généré par un LLM a l’air correct aux yeux d’un LLM, ce qui rend la vérification encore plus difficile
    On se retrouve donc dans une situation où évaluer une PR est devenu plus difficile que la produire
  • Mais je pense malgré tout qu’il faut vérifier tout code comme s’il s’agissait d’un cheval de Troie potentiel
  • Le processus de revue doit être assez robuste pour détecter les erreurs, qu’elles viennent d’un humain ou d’une IA

• Le débat sur la qualité des contributions IA est étrange. La qualité a toujours été la responsabilité de l’auteur de la soumission
  Utiliser l’IA n’accorde aucune immunité, et au contraire, les politiques restrictives sur l’usage de l’IA risquent surtout de nuire aux contributeurs de bonne foi

  • Le problème est que le code produit par un LLM peut sembler bon en apparence alors qu’il s’agit en réalité de code implémenté sans compréhension réelle
  • Ce qui compte, ce n’est pas l’outil, mais la capacité du contributeur à expliquer et défendre son code pendant la revue
    Je maintiens un fork de 300 commits avec l’aide de l’IA, mais je peux relire et expliquer chaque ligne
    Au final, c’est la qualité de l’implication qui compte, pas le type d’outil utilisé
  • La vraie constante immuable, c’est le sens des responsabilités. Si l’on soumet un patch, il faut en assumer la conception comme la maintenance
  • Mais l’IA risque d’encourager les gens à se dérober à cette responsabilité

• À long terme, il semble probable qu’avec les progrès de l’IA, il deviendra difficile de distinguer les productions humaines de celles de l’IA
  Quand cela atteindra un niveau « suffisamment bon », elles ressembleront à des productions humaines, et je me demande alors ce qui se passera

  • On ne pourra pas l’empêcher parfaitement, mais je pense qu’établir une politique vaut mieux que ne rien faire
    Aujourd’hui, la plupart des PR IA sont de mauvaise qualité, mais même si la qualité augmente, on pourra toujours les refuser pour des raisons juridiques ou idéologiques
  • Les contributions IA doivent au final être vues comme une extension de l’individu. Le compte doit appartenir à une vraie personne, et il faut que sa réputation soit en jeu
  • Si une énorme quantité de code apparaît soudainement, on peut soupçonner l’usage de l’IA. L’important n’est pas de savoir si l’IA a été utilisée, mais si le problème est compris
  • L’IA en est encore à de la prédiction au niveau du token, ce qui la distingue d’un code conçu par un humain
    On y voit souvent des abstractions excessivement fragmentées ou des refactorings inutiles
    Qu’un humain utilise l’IA comme outil est acceptable, mais on est encore loin d’un niveau où l’IA remplacerait l’humain
    En revanche, l’abus du vibecoding fait déjà grimper brutalement les coûts de revue et de maintenance
  • Au final, le code produit par quelqu’un qui s’en sert correctement ne se distingue pas du code humain. Le problème n’est pas l’outil, mais la manière de l’utiliser

• Je suis de ceux qui pensent que « si ça marche, ça suffit »
  Si le code respecte les critères de fonctionnalité, documentation, tests et exactitude, peu importe qu’il ait été écrit par une IA ou par un humain
  L’important est de définir clairement ce que signifie « ça marche » et de disposer d’un système de revue compétent

• L’IA peut générer des PR de plusieurs milliers de lignes d’un coup, mais il faut au final les limiter à une taille révisable
  Même si l’IA fait passer les tests, si l’auteur ne comprend pas ce qu’il soumet, cela reste dangereux
  Il faut limiter le périmètre du travail et disposer d’un historique de contributions manuelles antérieures

• La politique de Debian est simple — faire en sorte que personne ne soit lésé. C’est un bon principe

• Quelqu’un a demandé si Debian avait une règle interdisant de soumettre le code de quelqu’un d’autre comme si c’était le sien
  En pratique, comme c’est illégal au titre de la violation du copyright, cette interdiction existe implicitement même si elle n’est pas formulée explicitement
  Un LLM n’est pas une personne, mais le copyright de son code reste malgré tout flou

• Le vibecoding pour des web apps ou des applications mobiles ne me dérange pas, mais utiliser l’IA pour des logiciels d’infrastructure critiques comme les noyaux, compilateurs ou systèmes d’exploitation est dangereux
  Dans ces domaines, il faut des langages à vérification formelle comme Ada/SPARK
  L’idée de monter un jour dans une voiture équipée d’un système de freinage produit par l’IA me fait peur

  • D’accord. Les systèmes critiques exigent une attention minutieuse, et les LLM manquent à la fois de rigueur et présentent des risques de copyright
  • En réalité, j’ai entendu dire que dans l’industrie automobile, il y avait déjà beaucoup de code généré automatiquement avant même l’IA

• Un « envoi de code en mode YOLO » est bien moins acceptable qu’un code où l’on a utilisé l’IA mais que l’on a vérifié au maximum