Commentaires : L'anti-GitHub européen dit non au code écrit par Claude et Codex

Pendant que GitHub continue d’intégrer Copilot à chaque recoin de sa plateforme, son concurrent européen a pris la direction exactement inverse. Le 22 juillet 2026, la communauté de Codeberg a voté à 71 % l’interdiction des dépôts majoritairement générés par IA, avec Claude et OpenAI Codex nommément dans le viseur. Une prise de position qui traduit autant un choix éthique qu’une contrainte économique très concrète.

https://clubic.com//actualite-622627-l-anti-github-europeen-dit-non-au-code-ecrit-par-claude-et-codex.html

J’ai entendu de nom Codeberg que récemment grace au projet libre de cartographie sur navigateur cartes.app mais pas avant. J’ai pu voir des débats notamment quel techno pour implémenter les commentaires
mais avant je ne connaissais pas, cela fait plaisir de voir émerger un peu de concurrence

J’irais plus loin personnellement, présence de tout dossier ou fichier concernant de la configuration d’IA => ban immédiat.

1 « J'aime »

C’est un nom à retenir :slight_smile:

Ils maintiennent un fork de Gitea, Forgejo, qui est vraiment sympa comme serveur Git, c’est léger (ça peut facilement tourner sur des toutes petites machines, contrairement à un GitLab par exemple), ça intègre une CI quasiment compatible avec GitHub Actions… Et avec un fort engagement sur le fait de le maintenir gratuit et open source (à la base, ça a forké de Gitea justement parce que ce dernier a commencé à prendre une orientation commerciale).

C’est ce que j’utilise pour mon home lab et une partie de mon activité pro, ça tient vraiment bien la route, avec vraiment peu de ressources :

À comparer par exemple avec un GitLab (et celui là est quasiment vide, j’ai que 3 repos dessus, je le démarre juste quand j’ai absolument besoin de tester un truc sur GitLab) :
image

Ça c’est quand même sacrément extrême hein… Y a de moins en moins de dev qui travaillent sans IA, et je serai d’ailleurs étonné si ce n’était pas déjà utilisé par certains contributeurs. En tout cas, les contributions assistées par l’IA sont bien acceptées, sous certaines conditions très strictes (notamment, que le code et la documentation n’aient pas été écrits par l’IA, en raison des incertitudes sur le copyright, et en particulier le fait que la législation de l’UE n’est pas claire sur le fait qu’un code produit par une IA soit ou non copyrightable) : https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md

Donc un ban complet des projets ayant utilisé de l’IA sous quelque forme que ce soit ne serait pas envisageable.

La règle s’applique aux projets « majoritairement » générés par IA, sans qu’un seuil technique ait été défini ni qu’une méthode d’enforcement ait été précisée

Quid si la réglementation évolue et va dans le sens où toute création d’IA / LLM est considérée comme libre de droits ou au moins conforme aux licences GPL ?

Bienvenue au royaume de l’hypocrisie…
Entre 85% et 90% des développeurs déclarent utiliser régulièrement l’IA pour coder ou développer des logiciels, selon plusieurs enquêtes récentes. lien

Le problème n’est pas l’usage de l’IA mais la manière dont certains l’utilise…

Et en quoi le fait qu’une large majorité l’utilise rendrait hypocrites ceux qui n’en veulent pas ?

Non, pas sous quelque forme que ce soit. Poser des questions et demander à trouver la cause d’un bug quand on bloque sont des usages légitimes. Par contre l’IA agentique c’est non. On sait que l’IA rend déjà teubbé quel que soit l’usage, alors la laisser directement faire le travail à sa place c’est juste travailler activement à se rendre soi-même inutile dans un futur proche, avec en plus les risques que ça comporte en terme de fiabilité des sources.

Mais bannir dès qu’il y a une configuration pour des outils d’IA, comme tu le proposes, c’est bien la bannir sous quelque forme que ce soit.

Parce que la configuration ne dit pas forcément comment c’est utilisé.

1 « J'aime »

Bah non, la configuration sert uniquement pour l’IA agentique génératrice de code, à quoi veux-tu que ça serve d’autre ? L’IA fonctionne parfaitement juste en copiant-collant des bouts de code, et même pour lui demander d’analyzser la base un fichier d’un config n’est pas nécessaire. À partir du moment où une personne a des fichiers de configuration d’IA dans son repo, c’est qu’elle est dans une démarche de génération automatisée.

Oui, la configuration sert pour l’IA agentique.
Mais non, l’IA agentique ne sert pas qu’à générer du code.

Si par exemple tu demandes à Claude Code de t’analyser ton projet pour y chercher des éventuelles failles de sécurité, tu utilises bien de l’IA agentique, mais tu ne lui fais pas générer du code.

Et dans ce cas, ça se justifie quand même d’avoir une configuration pour ton IA agentique, pour lui dire quels fichiers elle a le droit de lire ou non, les commandes qu’elle a le droit d’exécuter, pour lui donner du contexte (le CLAUDE.md), etc…

Je peux t’assurer que j’ai déjà vu plus d’un projet sur lesquels on a interdiction absolue de générer du code (et cette interdiction est respectée par l’équipe), mais pour lesquels on utilise quand même des agents pour de la recherche de bug, de la review…

Donc tu peux bien avoir des projets à 100% écrits par des humains mais ayant tout de même une configuration pour de l’IA agentique.

À l’inverse, tu peux avoir un projet 100% écrit par de l’IA agentique sans qu’il y ait le moindre fichier de configuration identifiable dans le repo.

Donc non, la présence de fichiers de configuration n’est pas un critère valable.

Quand on paye pour un Claude code c’est qu’il y a déjà un problème. Un petit Gemma 4 tournant en local suffit largement pour des besoins occasionnels. Et pas besoin de lui dire à quoi accéder vu que ce n’est pas envoyé sur le cloud. Et encore, là on présuppose que les agents respectent les règles qu’on leur donnent, chose dont le contraire est régulièrement démontré.

Alors ton petit Gemma 4 tournant en local, il sera bien moins efficace qu’un Claude Code avec un Opus ou un Fable… Même face à Sonnet, ça soutient sans doute pas la comparaison. Et ça sera bien plus lent (et en entreprise, le temps, c’est de l’argent… un abonnement à 20€, si ton dev gagne 30min par mois avec, c’est déjà rentable hein…). Surtout pour des développeurs qui aujourd’hui ont bien souvent un laptop sans GPU…

Et les exclusions sur les fichiers à traiter, ce n’est pas forcément que pour des questions de confidentialité, c’est aussi pour des questions de performances… Quand par exemple tu as un projet sur lequel tu as vendorisé un gros paquet de librairies, t’as pas envie que ton agent perde son temps à aller lire tout ça quand tu veux qu’il t’analyse ton code…

Et une configuration pour une IA agentique ne veut d’ailleurs pas non plus nécessairement dire que tu utilises forcément un modèle cloud. Puisque justement, comme tu le dis toi même, tu peux le faire avec un modèle tournant en local sur ton PC s’il est suffisamment costaud, ou sur les serveurs de l’entreprise (et oui, on peut le faire même avec Claude Code : Claude Code peut utiliser des modèles tournant dans un Ollama par exemple… on le fait dans ma boîte pour des runs de CI, sur lesquels on ne veut pas utiliser des modèles cloud, et on utilise le même serveur dans Claude Code pour certains usages).

Et ? Encore une fois, quand on a besoin de cette puissance, c’est qu’on est dans une démarche d’utilisation génération de code et de délégation de son intelligence à l’IA.

Houla, avec l’abonnement à 20€ par mois tu n’iras pas bien loin, et non ça n’est pas rentable puisque l’employé perd en compétence. À la limite c’est rentable si tu peux virer l’employé un question. Y en a qu’ont essayé, ils ont eu des problèmes commes disait l’autre.

Rappelons que des études ont montré que même pour une bête recherche d’une information, utiliser une IA plutôt que d’aller sur Google et consulter des sources menait à une baisse significative de l’engagement cérébral. Est-ce que les patrons veulent des employés stupides ? Ils risquent d’en revenir assez vite. C’est déjà le cas pour les GAFAM d’ailleurs.

Si l’agent doit analyzer du code qui repose sur des dépendances, il faudra bien qu’il aille les lire. Il ne va pas s’amuser de lui-même à parser des millions de fichiers si ça n’est pas pertinent.

C’est pas comme si je t’avais donné des exemples de cas où on utilise ça sans pour autant générer du code…

Avec un abonnement à 20€ par mois, tu peux déjà faire beaucoup. Et gagner largement plus de 30 min par mois.

Et non, ça n’implique pas forcément une perte de compétence. Tout comme un artisan qui utilise une visseuse plutôt qu’un tournevis ne perd pas forcément de compétence.

L’IA est un outil. Mal utilisé, oui, ça peut faire perdre. Bien utilisé, ça peut être tout le contraire. Perso, j’ai bel et bien appris des trucs grâce à l’IA, sur la sécurité par exemple (la sécurité n’étant pas mon métier, je passe pas forcément beaucoup de temps à me documenter sur le sujet… et je n’aurais pas pensé spontanément par exemple que quand on vérifie un login/mot de passe, si le login n’est pas trouvé en base, il est préférable de quand même « vérifier » le mot de passe en calculant son hash et en le comparant avec un hash quelconque…), et j’applique ça maintenant sur du code que j’écris avec mes petites mains sur mon petit clavier.

Mais c’est sûr que si c’est juste pour lui faire pisser du code et le commiter sans même y jeter un oeil, la le risque de perdre en compétences est grand. Mais pas si on l’utilise comme un assistant, en étudiant ce qu’il fait, en lui demandant d’expliquer des choses, etc…

Tiens du coup, est-ce que utiliser un IDE avec de la colorisation et de l’auto-completion, c’est aussi perdre de la compétence ? Et utiliser un linter/formatter ? Et utiliser des frameworks ? Et Sonar ? Et utiliser un compilateur plutôt que d’écrire directement en assembleur ?

Ben non. Parce que le but est qu’il trouve des failles ou des bugs dans l’application elle même. Pas dans les dépendances.

Et c’est bien plus efficace et fiable et lui indiquer via la configuration qu’il ne doit pas aller dans certains répertoires que de compter sur le fait qu’il comprendra tout seul ou de devoir le lui rappeler à chaque prompt.

Bon c’est bon, quand on en arrive à cet argument je lâche le débat perso. L’IA n’est pas un outil, c’est un prestataire de service. Virtuel certes, mais toujours un prestataire de service qui fait le boulot à la place de celui qui l’utilise. La visseuse ne saute pas le mur toute seule pour installer un truc quand on lui demande.

Effectivement, on va s’arrêter là. Ce n’est pas parce que tu n’es pas capable d’utiliser l’IA intelligemment que personne n’en est capable et que personne ne le fait.

Mdr, l’hypocrisie à l’état pur. C’est aussi pour ça que l’Europe sera toujours en retard.

Je suis développeur depuis plus de 15 ans, bien avant l’arrivée de l’IA, et pourtant aujourd’hui j’avance beaucoup plus vite grâce à elle.

Au lieu de la diaboliser, il vaut mieux apprendre à l’utiliser intelligemment. Comme toutes les technologies, ce n’est qu’un outil : tout dépend de la façon dont on s’en sert. :wink:

Bref, restez dans le déni si vous voulez, moi je préfère m’adapter.

Faudrait aussi lire un peu les explications hein. Ce n’est pas une question de diabolisation de l’IA, les raisons sont juridiques et techniques.

Outre les incertitudes juridiques sur le copyright du code généré (incertitudes qui sont valables aussi aux USA), le fond du problème, c’est que des projets utilisant massivement l’IA induisent pour Codeberg des coûts de fonctionnement élevés (parce que ça consomme bien plus de ressources qu’un projet qui avance à vitesse humaine… forcément quand t’as un mec qui fait 50 commits par jour et mobilise à chaque fois toute la chaîne de CI, et tout ça pour des trucs qui parfois ne sont utilisés par personne d’autre que l’unique mainteneur…). Et comme Codeberg est un projet non commercial, c’est compliqué pour eux de supporter ces coûts, et ils préfèrent privilégier les projets maintenus par une vraie communauté de développeurs open source.

D’ailleurs leurs nouvelles règles ne ciblent pas que le code généré par l’IA, puisque non seulement ils continuent d’en accepter pour les projets qui ont une communauté significative ou pour les petits projets consommant peu de ressources chez eux, tandis qu’à l’inverse ils se réservent le droit de rejeter aussi des projets dont la consommation de ressources serait trop élevée par rapport à la taille de leur communauté.

C’est désolant.