jules@halfnil:~$ cat ~/blog/codeberg-refuse-depots-generes-ia.md

Codeberg ne bannit pas « l’IA » : il refuse surtout les dépôts fantômes.

Codeberg durcit ses règles contre les projets majoritairement générés par IA. Derrière le débat idéologique, il y a un problème concret de maintenance et de ressources.

25 juillet 2026 · 4 min ·

Le 23 juillet, Codeberg a annoncé qu’il n’accueillerait plus les projets composés majoritairement de code produit par des outils d’IA générative. Présentée rapidement, la décision ressemble à une interdiction générale de l’IA. En lisant les détails, le sujet est plus concret : qui maintient le code, qui paie son hébergement et qui assume les contributions générées ?

## Ce qui a réellement été voté

Deux motions ont été adoptées par les membres de l’association qui gère la forge. La première engage Codeberg à ne pas utiliser les données et dépôts hébergés pour entraîner des modèles génératifs. La seconde modifie ses conditions d’utilisation pour refuser les projets qui « consistent principalement » en code écrit par des outils d’IA générative.

Cette deuxième motion a recueilli 358 voix favorables, 144 défavorables et 14 abstentions, avec environ 50 % de participation. Le terme important est principalement. Un projet humain qui utilise ponctuellement un assistant, accepte une contribution assistée ou génère quelques tests n’est pas automatiquement concerné.

La modification exacte des conditions d’utilisation vise plutôt les dépôts construits et maintenus presque entièrement par des agents, sans véritable supervision humaine.

Il n’y aura pas non plus de purge automatique. Codeberg indique que les projets anciens, les communautés actives et les dépôts utilisant peu de ressources devraient rester tranquilles. La modération sera progressive et humaine, sans scanner chargé de deviner automatiquement l’origine de chaque ligne de code.

## Le vrai problème : produire du code ne crée pas une communauté

Le point intéressant n’est pas de savoir si une IA peut écrire une fonction correcte. Elle le peut souvent. Le problème apparaît après le premier git push.

Un dépôt public implique potentiellement des rapports de bugs, des mises à jour de dépendances, des correctifs de sécurité, des demandes de fonctionnalités et du support. Générer 50 000 lignes en une soirée ne génère pas les heures nécessaires pour les relire et les maintenir pendant trois ans.

Codeberg explique voir apparaître des projets avec un seul utilisateur, mais beaucoup de commits, des pipelines CI/CD fréquents, de grosses releases et davantage de plateformes ciblées que d’utilisateurs réels. Ces « projets fantômes » peuvent consommer autant de stockage et de calcul que des logiciels portés par de vraies communautés.

C’est un changement d’échelle. Avant, écrire du code coûtait suffisamment de temps pour limiter naturellement le nombre de projets créés. Avec un agent, le coût de production chute, mais le coût de revue, d’hébergement et de maintenance reste chez les humains.

## Une règle aussi économique qu’idéologique

Codeberg est une association financée par les dons et exploite sa propre infrastructure. Selon son annonce, un modèle de SSD acheté environ 700 euros il y a quelques années coûte désormais autour de 3 700 euros et reste difficile à obtenir. L’organisation relie cette hausse à la demande matérielle provoquée par le déploiement massif des modèles d’IA, tout en rappelant que l’augmentation de ses propres besoins de stockage lui coûte déjà directement plus cher.

La forge subit aussi les robots qui parcourent les pages de fichiers, les historiques et les variantes de filtres au lieu d’utiliser simplement Git pour cloner les dépôts. Codeberg décrit ces accès comme une source de requêtes coûteuses, de ralentissements et de travail supplémentaire pour ses administrateurs.

Autrement dit, un service communautaire peut se retrouver à payer deux fois : d’abord pour défendre son infrastructure contre la collecte automatisée, puis pour héberger les dépôts générés par les modèles alimentés avec cette collecte.

## Une limite forcément imparfaite

La règle reste floue. Comment mesurer qu’un projet est « principalement » généré ? Le nombre de lignes ne dit rien sur la supervision réelle. Un développeur peut relire sérieusement 80 % de code proposé par un modèle, tandis qu’un autre peut publier sans comprendre dix lignes seulement.

Codeberg assume cette imprécision et fournit surtout des indicateurs : activité communautaire, historique antérieur aux LLM, niveau de maintenance, consommation de ressources et degré d’autonomie des agents. Cette approche ne produira pas une frontière parfaitement objective, mais elle évite de transformer la forge en tribunal automatique du code.

Le débat dépasse d’ailleurs Codeberg. Le projet Debian examine actuellement deux positions opposées : interdire les contributions assistées ou les autoriser sous conditions de responsabilité, de compatibilité juridique, de divulgation et de protection des données sensibles. La proposition permissive demande notamment que l’auteur humain comprenne la modification et en assume entièrement la sécurité et la maintenance.

C’est probablement la question utile pour nos propres projets : non pas « une IA a-t-elle touché ce code ? », mais quel humain est capable de l’expliquer, de le corriger et de le maintenir ? Si la réponse est personne, le dépôt n’est pas vraiment open source. C’est juste une sortie de modèle stockée publiquement.

## Pour aller plus loin

Veille rédigée avec l'aide d'une IA — sources vérifiées et liées ci-dessus.