- ▸ Le constat
- ▸ La thèse
- ▸ Argument premier : la réputation, ce filtre qu'on croyait dépassé
- ▸ Argument second : le code lui-même avoue
Souvenez-vous de l’an 2000. Une pièce jointe nommée « I LOVE YOU », et 45 millions d’ordinateurs infectés en vingt-quatre heures. La pièce ne valait rien à expédier. Vous l’avez ouverte parce que vous faisiez confiance. C’est exactement ce qui se rejoue aujourd’hui — pas dans vos boîtes mail, mais dans le code.
Points clés – Le taux d’acceptation des pull requests sur OpenClaw est passé d’environ 48 % avant le pic à moins de 9,3 % après, selon l’étude statistique publiée par Greptile le 8 mai 2026. – Les contributeurs sont désormais filtrés par leur réputation : 8,2 % de merge pour les premiers venus, 10,3 % entre deux et cinq PR, 18,6 % au-delà. – La nature du code soumis trahit le spam : les fonctionnalités passent à 9 %, les refactorisations à 35 %. – Le parallèle avec le spam email des années 2000 n’est pas une figure de style : c’est le même mécanisme économique, le coût de production qui s’effondre.
Le constat
En 2000, le ver ILOVEYOU a contaminé 45 millions de machines en une journée. Pourquoi ? Parce que le coût d’envoi d’un email tendait vers zéro, et parce que les gens faisaient confiance à la plateforme, rappelle l’étude statistique des PR ouvertes sur openclaw/openclaw, publiée par Greptile le 8 mai 2026.
Aujourd’hui, le coût de production d’une pull request tend lui aussi vers zéro. Les assistants de génération de code écrivent une fonctionnalité plausible en quelques secondes. Et le résultat se lit dans les chiffres : avant le pic de soumissions, environ 48 % des PR étaient acceptées sur OpenClaw. Après, moins de 9,3 %, selon les sources disponibles à ce jour.
Lisez bien ce nombre. Un dépôt qui fusionnait près d’une contribution sur deux n’en retient plus qu’une sur dix. Le volume a explosé. La valeur, elle, s’est effondrée. Ce n’est pas un accident. C’est une signature.
La thèse
Je crois que nous ne vivons pas une crise de l’open source. Nous vivons sa version contemporaine du spam email — et nous la traitons avec la même naïveté qu’en 2002. Le problème n’est pas que des machines écrivent du code. Le problème est que le coût de l’envoi s’est effondré pendant que le coût de la lecture, lui, reste humain. Cette asymétrie est le moteur de tout spam. Elle l’a toujours été.
Argument premier : la réputation, ce filtre qu’on croyait dépassé
Observez comment OpenClaw se défend, presque malgré lui. Les contributeurs y sont déjà triés par leur réputation. Un premier venu voit 8,2 % de ses PR fusionnées. Entre deux et cinq contributions, le taux monte à 10,3 %. Au-delà de cinq, il atteint 18,6 %, d’après les données de Greptile.
Que vous dit cette courbe ? Que la confiance ne se déclare plus, elle se gagne. Exactement comme le courrier électronique a dû réinventer la confiance après l’âge d’or du spam : listes de réputation d’expéditeurs, scores d’authentification, historique d’envoi. L’identité a remplacé la présomption de bonne foi.
C’est un basculement silencieux mais profond. Le pacte fondateur du logiciel libre reposait sur une promesse d’ouverture radicale : n’importe qui, partout, peut contribuer. Or ce que montre OpenClaw, c’est qu’à coût de soumission nul, l’ouverture radicale devient un vecteur d’attaque. Le mainteneur ne lit plus le code d’abord. Il lit l’expéditeur d’abord. Et il a raison de le faire, parce que son attention est la seule ressource rare dans toute l’équation.
Argument second : le code lui-même avoue
Il y a plus troublant encore. La nature des contributions trahit le spam. Sur OpenClaw, les fonctionnalités nouvelles affichent un taux de merge de 9 %. Les refactorisations, elles, sont acceptées à 35 %, soit près de quatre fois plus.
Pourquoi cet écart ? Parce qu’une refactorisation suppose une connaissance intime du code existant — on ne réorganise bien que ce qu’on a compris. Une fonctionnalité plausible, en revanche, se génère à la chaîne. « feat(web-search): add SearXNG as a search provider. » « build a memory system. » Ces titres sonnent juste. Ils ressemblent à du travail. Ils en ont la forme sans toujours en avoir la substance.
C’est précisément la définition du spam : un message qui imite parfaitement le légitime pour franchir le filtre. Le ver de 2000 promettait une lettre d’amour. La PR de 2026 promet une fonctionnalité utile. Dans les deux cas, l’emballage est impeccable et le contenu, statistiquement, décevant. Neuf fois sur dix.
L’objection
J’entends la contestation, et elle est sérieuse. Linus Torvalds l’a formulée mieux que personne : « Given enough eyeballs, all bugs are shallow. » Avec assez de regards, tout bug devient trivial. C’est la foi fondatrice de l’open source : le volume est une force, pas une faiblesse. Plus de contributions, c’est plus de chances qu’une pépite émerge du tas. Filtrer trop tôt, ne serait-ce pas trahir cette promesse et fermer la porte au prochain grand contributeur, celui qui n’a encore aucune réputation ?
L’objection serait juste si le volume produisait encore des regards. Mais la loi de Torvalds suppose une symétrie : autant d’yeux que de contributions. Or le spam casse précisément cette symétrie. Les soumissions se multiplient pendant que les relecteurs, eux, restent une poignée d’humains aux journées de vingt-quatre heures. À ce moment-là, le volume ne révèle plus les bugs : il les enterre. Le tas devient si haut que la pépite reste invisible. La loi ne ment pas. Elle a seulement cessé de s’appliquer.
Ce qui est en jeu
Au-delà d’un dépôt de code, il me semble qu’une infrastructure de confiance vacille. Le logiciel libre fait tourner l’essentiel du monde numérique — vos banques, vos hôpitaux, vos administrations s’appuient sur des briques maintenues par des bénévoles. Si l’attention de ces bénévoles est saturée par du bruit plausible, ce n’est pas un dépôt qui souffre, c’est le bien commun numérique tout entier.
Les premières réponses, d’ailleurs, ressemblent à celles de l’email : des listes de blocage pour gérer le volume, des filtres fondés sur la confiance et une infrastructure de réputation pour repérer les mauvais acteurs. Nous reconstruisons, brique par brique, l’arsenal anti-spam des années 2000. La question n’est donc pas technique. Elle est politique : à qui accorde-t-on le droit d’être lu ? Et qui paie le prix de ce tri ?
Conclusion
Revenons à la lettre d’amour de l’an 2000. Si elle a fonctionné, ce n’est pas par génie technique, mais parce qu’elle exploitait notre confiance à un moment où elle ne coûtait rien à trahir. OpenClaw nous renvoie le même miroir, vingt-six ans plus tard. Le coût de produire est tombé à zéro ; le coût de lire reste irréductiblement humain.
Je ne crois pas que la solution soit de fermer les portes. Mais je crois qu’il faut nommer ce que nous vivons. Ce n’est pas une vague de contributions. C’est une vague de spam, et nous avons déjà, une fois, appris à y survivre. La vraie question est de savoir si nous saurons le refaire sans sacrifier ce qui faisait la beauté de l’ouverture. Le débat est ouvert. À nous de ne pas l’ouvrir trop tard.
FAQ
Qu’est-ce qui explique l’explosion du nombre de PR sur OpenClaw ?
Le même mécanisme que le spam email des années 2000, selon l’étude de Greptile : le coût de production d’une contribution a chuté vers zéro grâce à la génération automatique de code. Quand soumettre ne coûte presque rien et que la plateforme inspire confiance, le volume explose mécaniquement.
Comment les contributeurs sont-ils filtrés sur OpenClaw ?
Par leur réputation, mesurée à l’historique de leurs contributions. Les premiers venus obtiennent 8,2 % de merge, ceux ayant deux à cinq PR montent à 10,3 %, et les contributeurs aguerris au-delà de cinq PR atteignent 18,6 %, d’après les données publiées le 8 mai 2026.
Cet article est une tribune et reflète l’opinion de son auteur.
