Le comité de pilotage de GCC a adopté la recommandation de son groupe de travail sur l'IA, et le résultat tient en une phrase : pour l'instant, GCC refuse toute contribution juridiquement significative qui contient ou dérive de contenu généré par un LLM. Les cas de test font exception, et les petites modifications situées sous le seuil du droit d'auteur restent acceptables si elles sont clairement signalées comme générées. La formulation compte plus que le titre, car juridiquement significatif n'est pas une appréciation floue dans les projets GNU. C'est un seuil existant avec une règle empirique existante, et c'est ce qui transforme cette politique en quelque chose qu'un mainteneur peut appliquer à un correctif.
The short answer
Le 29 juillet 2026, David Edelsohn a annoncé sur la liste de diffusion GCC que le comité de pilotage acceptait la recommandation du groupe de travail sur la politique IA, présidé par Jonathan Wakely. GCC refusera toute contribution juridiquement significative contenant ou dérivant de contenu généré par un LLM. Les cas de test juridiquement significatifs générés en tout ou partie par un LLM sont autorisés, et les contributions générées juridiquement non significatives peuvent être acceptées si elles sont clairement signalées. Le document est en attente de fusion dans Sourceware Forge.
La plupart des politiques de projet sur le code généré finissent par ne rien dire d'applicable, ou par tout dire à la fois. Celle ci est inhabituelle parce qu'elle reprend une ligne qui existait déjà, et donne ainsi aux mainteneurs quelque chose d'utilisable pendant la relecture.
La phrase qui compte
Le texte est bref. Pour l'instant, GCC refuse toute contribution juridiquement significative qui contient du contenu généré par un LLM ou qui en dérive.
Puis deux exceptions. Les contributions juridiquement significatives portant sur des cas de test, générées en tout ou partie par un LLM, sont autorisées. Et les contributions juridiquement non significatives générées par un LLM peuvent être acceptées, dès lors qu'elles remplissent les prérequis habituels et qu'elles sont clairement signalées.
David Edelsohn a publié l'annonce sur la liste gcc dans les premières heures du 29 juillet, au nom du comité de pilotage, qui avait accepté la recommandation d'un groupe de travail présidé par Jonathan Wakely et réunissant Carlos O'Donell, Sudakshina Das, Jason Merrill, Joel Sherrill, Sam James, Robin Dapp et Arthur Cohen. Le document lui même est déposé sous forme de pull request dans Sourceware Forge et n'était pas encore publié sur le site de GCC au moment de notre vérification.
Juridiquement significatif n'est pas une impression
L'expression porte tout le poids. Dans les projets GNU, elle a une histoire précise liée aux formalités de droit d'auteur et non à l'appréciation personnelle. Le document des mainteneurs place la limite autour de quinze lignes : au delà d'environ quinze lignes de code ou de texte, une contribution est juridiquement significative et exige des documents de cession, tandis qu'une modification de moins de quinze lignes environ ne l'est pas.
Deux précisions du même document s'appliquent ici. Une série de modifications répétées, comme renommer un symbole à de nombreux endroits, n'est pas juridiquement significative même si elle touche beaucoup de fichiers. Et les petites contributions d'une même personne s'accumulent, si bien que c'est le total dans le temps qui compte, pas chaque envoi pris isolément. Ce second point ferme l'échappatoire évidente avant que quiconque l'essaie.
En pratique, cela donne une règle qu'un mainteneur peut garder en tête. Un correctif court, généré et déclaré, passe. Une passe d'optimisation générée, non.
Pourquoi les cas de test échappent à la règle
L'exception semble arbitraire jusqu'à ce qu'on regarde ce qu'est un cas de test de compilateur. C'est en général un petit programme écrit pour provoquer un comportement, son contenu expressif est mince, et sa valeur tient à couvrir un cas auquel personne n'avait pensé plutôt qu'à sa formulation. Cette combinaison le place au plus bas de l'exposition au droit d'auteur et au plus haut de l'utilité de la génération, puisque énumérer des entrées tordues fait partie de ce que les modèles réussissent vraiment.
Prendre la productivité là où le risque juridique est le plus faible, et la refuser là où il est le plus fort, est une position plus réfléchie qu'une interdiction générale ou qu'un haussement d'épaules.
Le texte dit pour l'instant, et le pense
Le comité a écrit qu'il s'attend à voir la politique évoluer et qu'il la réexaminera périodiquement, avec une revue annoncée pour début 2027. Ce n'est pas une précaution de style.
La question ouverte n'est pas de savoir si un modèle peut écrire un correctif correct. Il le peut manifestement. C'est de savoir si une contribution dérivée d'un modèle entraîné sur le code d'autrui peut porter une déclaration de provenance propre au regard des règles de droit d'auteur d'un projet. GCC a abandonné la cession obligatoire à la FSF en 2021 au profit du Developer Certificate of Origin, lequel demande au contributeur de certifier d'où vient son travail. Personne ne sait ce que vaut cette certification quand une partie du travail sort d'un modèle, donc le projet a pris la position réversible et fixé une date pour y revenir.
Des projets différents, des réponses différentes
Si vous contribuez à plusieurs bases de code, lisez ceci comme un point de donnée et non comme une tendance à généraliser. Debian traite la même question par résolution générale, ce que nous avons couvert dans Debian revote sur les contributions écrites par un LLM, et l'EFF a publié sa propre politique pour ses projets open source en février. Ces trois textes n'aboutissent pas au même endroit sur la déclaration, le périmètre et l'application.
Le fil commun n'est pas une conclusion partagée. C'est que la provenance devient une chose que l'on attend de vous, plutôt qu'une chose que personne ne demande, et que les projets déjà rigoureux sur les formalités de droit d'auteur sont les premiers à la formaliser.
Sources et pour aller plus loin
- GCC AI Policy Announcement, David Edelsohn, liste gcc, 29 juillet 2026
- Phoronix : GCC refuse les contributions significatives faites via IA ou LLM, sauf les cas de test
- Document des mainteneurs GNU, section sur les modifications juridiquement significatives
- Guide de contribution GCC
- Politique de l'EFF sur les contributions assistées par LLM
Questions fréquentes
Que dit exactement la politique de GCC ?
La phrase opérante indique que, pour l'instant, la politique de la GNU Compiler Collection est de refuser toute contribution juridiquement significative qui contient du contenu généré par un LLM ou qui en dérive. Deux exceptions l'accompagnent. Les contributions juridiquement significatives portant sur des cas de test, générées en tout ou partie par un LLM, sont autorisées, et les contributions juridiquement non significatives générées par un LLM peuvent être acceptées à condition de remplir les prérequis habituels de toute contribution et d'être clairement signalées comme telles. L'annonce a été publiée sur la liste de diffusion GCC par David Edelsohn le 29 juillet 2026, au nom du comité de pilotage.
Qu'est ce qui compte comme juridiquement significatif ?
Ce n'est pas un terme inventé pour cette politique, et c'est la raison pour laquelle elle est applicable. Le document des mainteneurs GNU trace la limite depuis longtemps sur le terrain du droit d'auteur : une contribution de plus d'environ quinze lignes de code ou de texte est considérée comme juridiquement significative et nécessite des documents de cession, tandis qu'une modification de moins de quinze lignes environ n'est pas juridiquement significative au regard du droit d'auteur. Le même document note qu'une série de modifications mécaniques répétées, comme renommer un symbole dans de nombreux fichiers, n'est pas juridiquement significative même si elle touche beaucoup d'endroits, et que les petites contributions d'une même personne s'accumulent dans le temps. En pratique : un correctif d'une ligne suggéré par un modèle passe si vous le dites, une nouvelle passe d'optimisation non.
Pourquoi les cas de test sont ils traités différemment ?
Les cas de test sont la partie d'un arbre de compilateur où l'exposition au droit d'auteur est la plus faible et l'utilité de la génération la plus forte. Un cas de test est généralement un petit programme écrit pour déclencher un comportement précis, son contenu expressif est mince, et sa valeur vient de couvrir un cas auquel personne n'avait pensé plutôt que de la manière dont il est écrit. Or les modèles sont plutôt bons pour énumérer des entrées tordues. Cette exception permet de prendre le gain de productivité là où le risque juridique est le plus faible, sans ouvrir la porte au code généré dans le compilateur lui même. C'est la même logique que derrière le signalement des petites modifications générées plutôt que leur interdiction : l'objectif est une traçabilité vérifiable, pas l'abstinence.
Cette décision est elle définitive ?
Non, et l'annonce le dit clairement. Le texte s'ouvre sur pour l'instant, et le comité a précisé qu'il s'attend à voir la politique évoluer et la réexaminera périodiquement, la presse évoquant une revue début 2027. Cette formulation a un vrai rôle. La question non tranchée n'est pas de savoir si les modèles écrivent des correctifs utiles, c'est de savoir si une contribution dérivée d'un modèle entraîné sur du code écrit par d'autres peut porter une déclaration de provenance propre au regard des règles de droit d'auteur du projet. Personne n'a de réponse arrêtée, donc GCC a choisi la position réversible en attendant que le paysage juridique se précise.
Comment rester conforme si j'utilise un assistant ?
Trois habitudes couvrent l'essentiel. D'abord, savoir de quel côté du seuil des quinze lignes se situe votre modification, et être honnête, car la règle d'accumulation fait que soumettre à répétition de petits morceaux générés n'est pas une échappatoire. Ensuite, signaler explicitement le contenu généré quand vous soumettez une modification juridiquement non significative issue d'un modèle, puisque la politique fait du signalement une condition d'acceptation et non une politesse. Enfin, considérer les cas de test comme l'endroit sûr où s'appuyer sur la génération, et écrire vous même le code du compilateur. Si vous contribuez ailleurs, vérifiez chaque projet séparément : Debian, l'EFF et GCC ont abouti à des positions différentes, et aucune ne se déduit des autres.