Divulgation obligatoire en cas de contribution avec des outils d’IA

• Lors d’une discussion sur une PR du projet open source Ghostty, l’idée a été avancée qu’il fallait divulguer explicitement l’usage d’outils d’IA
• Son auteur souligne que l’IA produit encore souvent du code de faible qualité, en particulier lorsque des utilisateurs peu expérimentés le soumettent sans relecture
• L’objectif de cette divulgation est de permettre aux mainteneurs d’évaluer la fiabilité d’une PR et de fournir un retour pédagogique aux contributeurs humains, tout en évitant des efforts inutiles face à de simples productions générées par l’IA
• Un autre participant propose d’ajouter, via le modèle de PR, une checklist incluant l’usage ou non de l’IA
• En parallèle, l’idée a aussi été avancée que les outils d’IA pourraient automatiquement standardiser une byline spéciale dans les messages de commit GitHub, afin de garantir à la fois la transparence et la visibilité de l’outil

---

Nécessité de divulguer l’usage de l’IA

• Mitchellh explique qu’il apprécie les outils d’IA et les utilise lui-même, mais estime qu’à l’heure actuelle ils ne garantissent pas une qualité équivalente ou supérieure
  • Le problème est particulièrement marqué quand des débutants qui ne savent pas bien relire publient directement du code généré par l’IA dans une PR
  • Il critique cette situation comme une forme de « tromperie », dans la mesure où elle fait perdre du temps aux mainteneurs en relecture et en retours inutiles
• Divulguer explicitement l’usage de l’IA permettrait donc aux mainteneurs de juger du niveau d’attention à accorder à la relecture

Proposition d’introduire un modèle de PR

• Yawaramin propose d’utiliser la fonctionnalité de modèle de PR de GitHub pour y inclure la mention d’un éventuel usage de l’IA
  • On pourrait y ajouter en même temps une checklist comme le Developer Certificate of Origin (DCO)
• Cela permettrait à tous les contributeurs de signaler de manière cohérente leur recours à l’IA

Idée de standardisation côté GitHub

• Tobi propose qu’au niveau de GitHub, un standard de byline dédié à l’IA soit créé
  • Chaque utilisation d’un outil d’IA serait enregistrée dans le fichier de staging .git et ajoutée automatiquement au message de commit
  • GitHub pourrait ensuite les lister et fournir un lien vers l’outil → les mainteneurs pourraient ainsi vérifier la provenance
  • En parallèle, les outils d’IA n’auraient plus besoin d’abuser des co-authors comme d’un spam, comme aujourd’hui
• Cette approche est présentée comme une solution qui répond à la fois aux enjeux de transparence, de visibilité des outils et d’efficacité pour les mainteneurs

[GN⁺]

Avis Hacker News

• Souligne que l’usage de l’« IA » entraîne aussi des problèmes de contamination de propriété intellectuelle, et que nous faisons semblant de l’ignorer. Si quelqu’un pouvait mémoriser le code de tous les projets open source et le recracher tel quel à la demande, il serait évidemment interdit dans notre entreprise. Pourtant, dans le cas de l’IA, on nie ce fait à coups de rationalisations et de prétextes. En pratique, cela revient à blanchir de façon assez lâche du code varié, y compris sous GPL, ce qui implique un risque potentiellement fatal pour les entreprises fondées sur la propriété intellectuelle (IP).
  • Les tribunaux américains ont déjà jugé que l’usage des données d’entraînement relevait d’un usage transformateur. Il reste beaucoup de détails à ajuster, mais le changement est désormais irréversible. Si l’on veut que la création de propriété intellectuelle reste une activité économiquement durable, il faudra aussi faire évoluer le cadre juridique.
  • En suivant cette logique, il faudrait aussi interdire StackOverflow ou les manuels de presque tous les domaines. Dans la réalité, les programmeurs finissent inévitablement par voir le code des autres.
  • En pratique, j’ai l’impression que, hors des personnes financièrement concernées, presque personne ne prend vraiment au sérieux les questions juridiques liées à l’IA. Heureusement, dans la plupart des cas, ce sujet est ignoré, et le système juridique fonctionne correctement tant qu’il n’entrave pas le progrès.
• J’ai trouvé très marquant le passage de mitchellh sur le fait de « guider les nouveaux contributeurs jusqu’au bout et les aider à faire merger leur PR ». Faire progresser un développeur débutant grâce à des retours, c’est vraiment précieux. Mais si l’auteur de la PR balance immédiatement ces retours à une IA et n’apprend rien lui-même, alors c’est une perte de temps.
  • Les développeurs débutants vont désormais évoluer dans un monde où travailler sans IA n’existe plus vraiment.
• Je suis très content que la première page de HN aujourd’hui soit remplie de bons contenus fondés sur l’expérience concrète. Il y a beaucoup de récits francs, sans peur inutile ni exagération. Sur mon ordinateur personnel, je désactive l’assistance IA, et au travail aussi je ne l’utilise que de façon très limitée, uniquement quand c’est réellement nécessaire. L’assistance IA est très forte pour le travail atomique, mais nulle pour le travail composé. Au final, tout dépend de la manière dont les humains l’utilisent ; l’intelligence humaine reste essentielle.
  • Je suis de plus en plus d’accord avec l’idée que « l’IA n’est intelligente qu’à la hauteur de la personne qui la pilote ». Je ne comprenais pas comment on pouvait obtenir des résultats totalement différents avec la même IA, mais je ressens désormais concrètement qu’elle n’a rien de magique. Je pense avoir été naïf en m’attendant à ce que des gens incapables d’expliquer les choses entre eux puissent tirer de la valeur de l’IA. Au contraire, l’IA risque surtout d’élargir encore l’écart entre les ingénieurs moyens et les excellents. Je suis encore partagé, mais je comprends mieux pourquoi certains peuvent trouver l’IA inutile.
  • Cite la conclusion de Frederik P. Brooks dans « No Silver Bullets, Refired » : le développement logiciel est intrinsèquement complexe, et au lieu d’attendre une solution révolutionnaire, il faut viser des gains de productivité progressifs. Cette vision paraît à la fois réaliste et porteuse d’espoir.
  • Je trouve intéressante la formule « l’IA n’est intelligente qu’à la hauteur de la personne qui la pilote ». En fin de compte, les auteurs des posts du type « j’ai créé une bibliothèque cool en un jour avec l’IA » étaient dès le départ de très bons développeurs.
  • Je suis aussi d’accord. Dans mon entreprise, c’est la semaine du hack et nous testons les outils d’IA à l’échelle de toute l’organisation ; les bons résultats viennent surtout d’approches analytiques, de garde-fous, de grounded generation, etc. Ces derniers temps, on a l’impression que la mode des chatbots inutiles est passée et que le paradigme revient à l’essence du machine learning.
  • Je pense que les décisions clés doivent être prises par les humains, puis que l’IA relie le reste. Ce qui constitue une décision clé, et ce qui relève simplement du fait de relier des points, varie selon le domaine, mais en pratique, la majorité du code (environ 80 à 90 %) consiste en tâches répétitives et d’assemblage. Si on garde bien cette frontière, le gain de productivité est énorme. À l’inverse, confier les décisions clés à l’IA cause davantage de pertes ; il vaut mieux jeter et recommencer. Parmi ces décisions clés : la conception de la base de données, la définition des types, les dépendances, l’architecture système/infrastructure/interface, le choix des cas de test, l’organisation du code, etc. En revanche, l’IA peut bien gérer le CRUD, les handlers d’API, les transformations simples de structures de données, les scripts de déploiement, l’implémentation de tests, le code de composants UI, le styling, le nettoyage de données temporaires, etc. Elle aide aussi pour la recherche, l’exploration d’idées et l’étude d’alternatives, mais les conclusions et l’implémentation réelle doivent rester sous responsabilité humaine.
• Je ne suis pas quelqu’un de particulièrement passionné par l’IA ; je la vois simplement comme un outil parmi d’autres. Peu m’importe la façon dont quelqu’un a préparé une PR si le résultat est bon. En revanche, si un mainteneur demande quelque chose avant la soumission de la PR, je pense qu’il est normal de s’y conformer.
  • L’origine d’une PR et la manière dont elle a été produite comptent. Les reviewers aussi font des erreurs et ont leurs limites ; la confiance devient donc essentielle. Sans confiance, il ne faut même pas l’accepter dans le processus de review. C’est pour cette raison que l’équipe du noyau Linux a bloqué l’université du Minnesota à cause de ses expérimentations.
  • J’ai l’impression que cela ne répond pas vraiment à l’argument central du texte : « le but est d’aider un nouveau contributeur à progresser, mais si l’interlocuteur est une IA, ce n’est qu’une perte de temps ».
  • On peut produire 1 000 PR par jour avec l’IA. On semble ne penser qu’aux PR bien faites grâce à l’IA, alors qu’en réalité on peut aussi rendre la vie des mainteneurs extrêmement difficile avec elle.
  • Selon le Copyright Office américain, les contenus générés par l’IA ne sont pas protégeables par le droit d’auteur. Pour cette raison, la divulgation de l’usage de l’IA est nécessaire, ne serait-ce que pour des questions de licence. En cas de non-respect, on peut perdre le droit d’auteur sur l’ensemble de l’œuvre. Voir le rapport et la page principale.
  • Si j’ai utilisé l’IA et qu’on me le demande, je le dirai toujours. En revanche, si on ne me le demande pas explicitement, je ne le signalerai pas d’avance « par politesse ». Je pense que la plupart des gens considèrent l’usage de l’IA comme normal, ou n’y prêtent pas attention ; cela me semble plutôt être une mention mineure qui détourne l’attention. Même avec des alertes de type dependabot, l’intérêt réel ne suit pas.
• La question « et mon autocomplétion, j’en fais quoi ? » est revenue plusieurs fois, mais la politique prévoit explicitement une exception pour les mots-clés ou courtes expressions de type tab-autocomplete ; pas besoin de les divulguer. Il est recommandé de lire correctement le document (ou la PR).
• Cette politique me paraît convaincante parce qu’elle apporte un contexte supplémentaire. Beaucoup d’autres politiques liées à l’IA que j’avais vues auparavant ressemblaient davantage à des déclarations idéologiques ; ici, on explique pourquoi ces exigences existent et dans quelle direction on veut aller, ce qui paraît beaucoup plus concret. J’aimerais voir plus d’approches de ce type.
• On peut craindre que cette politique ne rende finalement l’usage de l’IA plus difficile pour les gens honnêtes. Si dire qu’on a utilisé l’IA rend la PR moins visible, est-ce que tout le monde ne va pas simplement le cacher ?
  • Je ne pense pas que ce soit si simple. La personne à l’origine de cette politique (mitchellh) utilise elle-même des LLM ; si quelqu’un peut expliquer qu’il a utilisé l’IA comme outil de commodité tout en comprenant suffisamment son propre travail, cela ne devrait pas trop nuire à la confiance.
  • Cette inquiétude peut devenir réelle. Comme l’IA produit en masse du code « qui semble à peu près correct mais qui est en réalité bancal », si une méfiance s’installe envers le code généré par IA, ce sera un problème de l’IA, pas des personnes. Il faut de meilleurs outils de codage basés sur l’IA.
  • Si on dit « j’ai utilisé ChatGPT », on est immédiatement ignoré, alors qu’en ne disant rien et en faisant comme si on maîtrisait le sujet, on reçoit des compliments. Tout le monde évolue déjà vers une dissimulation de l’usage de l’IA.
  • Je ne pense pas qu’il y ait grand intérêt à considérer cela comme un problème.
  • L’idée n’est pas de dire « n’utilisez pas l’IA », mais plutôt : si vous l’avez utilisée, indiquez-le honnêtement dans la PR.
• Je me demande pourquoi on demanderait aussi une divulgation détaillée du type « j’ai utilisé ChatGPT pour m’aider à comprendre la codebase, mais j’ai écrit le code moi-même ».
  • Si ce type d’explication est laissé, cela permet au reviewer de se concentrer sur un point de review possible : les malentendus ou erreurs liés à la « compréhension de la codebase ».
  • Je ne suis pas développeur, mais grâce à ce genre d’assistants IA, le temps nécessaire pour explorer le code a nettement diminué. Personnellement, l’IA m’a vraiment beaucoup aidé.
• Je trouve pertinent le modèle consistant à inclure chaque prompt utilisé pour générer la PR. Les LLM ne sont pas des outils entièrement déterministes, mais il est utile de conserver le contexte sur les étapes et prompts qui ont mené au résultat.
  • En pratique, c’est très peu réaliste. Même pour créer une seule PR basée sur l’IA, il faut souvent mêler 10 à 20 prompts, des tests, des ajustements manuels de contexte, du code écrit à la main, etc. Une capture vidéo d’écran serait presque préférable.
  • Pour ma part, j’utilise une combinaison du plugin vscode (specsytory) et de cursor pour conserver en Markdown le journal de toutes les interactions avec les LLM, puis je le joins à la Pull Request pour faciliter la code review.
• Dans mes projets personnels, j’ai même mis en place une règle demandant de divulguer jusqu’à l’usage de l’autocomplétion de l’éditeur.
  • La manière de transmettre l’intention est intéressante, mais l’IA actuelle est totalement différente de l’autocomplétion traditionnelle. On peut l’utiliser comme une autocomplétion, mais ce qu’elle peut faire est bien plus varié et profond. Réduire l’IA à une simple forme d’autocomplétion n’est qu’un point de vue personnel ; beaucoup de gens ne l’utilisent pas ainsi.
  • La tab-autocompletion est explicitement reconnue comme exception dans la politique.
  • L’autocomplétion n’est le plus souvent qu’un outil syntaxique, alors que l’IA tente aussi de guider le sens et la structure du code.