Claude a-t-il augmenté le nombre de bugs de rsync ?

• Les versions avec assistance de Claude ne sont qu’au nombre de deux, rsync v3.4.2 et v3.4.3, et rien n’indique qu’elles comportent anormalement plus de bugs que les versions passées selon le critère des bugs pondérés par gravité pour 10 commits
• sev/10c est l’indicateur central : il normalise le score de gravité des bugs sur une échelle de 0 à 1, additionne ces valeurs par version, puis divise par le nombre de commits avant de ramener le résultat à 10 commits
• v3.4.2 compte 50 commits, 9 commits Claude, 0 bug et 0.00 sev/10c ; v3.4.3 compte 34 commits, 28 commits Claude, 17 bugs et 3.29 sev/10c, les deux encadrant l’IQR sans qu’aucune ne soit une valeur aberrante
• La p-valeur du test exact par permutation est de 46 %, celle du test exact de Fisher de 74 %, avec un odds ratio de 1.06 : il y a donc très peu d’indices que les versions Claude soient pires que deux versions aléatoires ou aient davantage de chances de dépasser la médiane
• v3.4.1 est une version antérieure à l’introduction de Claude, mais c’était déjà la pire de tout l’ensemble de données avec 59 bugs, 9 commits et 39.39 sev/10c ; le cœur de la controverse autour de rsync vient du fait qu’une régression isolée a été liée à Claude sans tenir compte de la distribution historique

---

Contexte et question

• Fin mai 2026, la controverse autour de rsync a commencé avec un post Mastodon reliant la régression de v3.4.3 et les commits Claude de cette version ; elle s’est ensuite propagée à Hacker News et à l’issue GitHub "Please Do Not Vibe Fuck Up This Software", qui a accumulé plus de 300 commentaires
• La thèse centrale répétée était que le développement assisté par Claude avait introduit des bugs dans un outil jusque-là stable ; la question de données est donc de savoir si les versions assistées par Claude ont anormalement plus de bugs que les versions historiques
• Sur Lobsters, certains ont demandé un graphique temporel du nombre de régressions par version, et l’analyse se concentre sur une seule question : « Les versions assistées par Claude ont-elles inhabituellement beaucoup de bugs ? »

Périmètre des données et reproductibilité

• Les données couvrent 36 versions de RsyncProject/rsync, de v2.4.6 à v3.4.3, pour lesquelles des données de bugs existent ; seules deux versions contiennent des commits Claude : v3.4.2 et v3.4.3
• Le choix des métriques, de la méthodologie et des sources de données a été fait manuellement, avec l’appui des conseils d’une conjointe titulaire d’un master en statistiques
• La collecte des données, le chargement dans DuckDB, la création de vues et les scripts d’analyse statistique ont été produits par GLM 5.1, mais tous les chiffres, statistiques, tableaux et graphiques ont été insérés automatiquement par le script Python qui exécute l’analyse statistique
• Le dépôt de reproduction alexispurslane/rsync-analysis permet d’exécuter toute la chaîne de traitement de bout en bout

Métrique et attribution des bugs

• La métrique clé est le nombre de bugs pondérés par gravité pour 10 commits, sev/10c, calculé ainsi : sev/10c = (Σ severity/100 ÷ total_commits) × 10
• Les commits sont triés selon la date de commit sur la branche principale, et chaque intervalle de version va du tag précédent jusqu’au tag courant ; les tags pre et rc sont exclus des bornes et absorbés dans la version finale
• Les bugs proviennent de trois sources : les issues GitHub, le Bugzilla de rsync et la mailing list rsync ; les bugs issus des issues GitHub et de la mailing list sont attribués à la dernière version publiée juste avant leur signalement
• Pour Bugzilla, le champ « Version » indique explicitement la version dans laquelle le bug a été signalé, et le bug lui est donc attribué
• L’analyse au niveau des versions a été retenue parce que la critique elle-même prend la forme « les versions contenant des commits Claude sont globalement devenues plus boguées », et parce que la plupart des bugs ne précisent pas de quel commit exact ils proviennent

Méthode d’évaluation de la gravité

• Tous les rapports de bugs ont été notés sur une échelle de gravité de 0 à 100 par Qwen 3 35B, avec un prompt lui assignant le rôle d’un ingénieur senior en fiabilité évaluant l’impact réel sur les utilisateurs
• Les scores de 90 à 100 correspondent à une corruption silencieuse de données, une perte de données, une exécution de code à distance ou des vulnérabilités de sécurité donnant un accès non autorisé ; les scores de 70 à 89 à des crashs, des blocages, des échecs de sauvegarde ou de build ; les scores de 50 à 69 à des régressions fonctionnelles contournables
• Pour Bugzilla et la mailing list, seul le titre était disponible sans corps de message ; le modèle a donc évalué à partir du seul titre, avec instruction de se rabattre vers la zone médiane 40–60 en cas d’informations insuffisantes
• La sortie utilisait une structured output avec schéma JSON n’autorisant qu’une gravité entière, et la température était fixée à 0 afin qu’une même entrée produise toujours le même score
• Les issues notées 0, comme les demandes de fonctionnalité, le spam, les protestations non techniques liées à l’IA ou les soumissions vides, sont exclues du décompte de base des bugs

Résultats statistiques pour les versions Claude

• v3.4.2 comporte 9 commits Claude sur 50 commits, 0 bug réel, 0.00 sev/10c et se situe au 0e percentile
• v3.4.3 comporte 28 commits Claude sur 34 commits, 17 bugs, 3.29 sev/10c et se situe au 77e percentile
• L’IQR historique va de 0.29 à 2.59 sev/10c ; v3.4.2 est juste en dessous et v3.4.3 juste au-dessus, si bien que les deux versions encadrent la distribution centrale chacune d’un côté
• Le test exact par permutation montre que, parmi les 595 combinaisons possibles de 2 versions, 272 ont une moyenne au moins égale à celle du groupe Claude, soit 1.65 sev/10c, ce qui donne une p-valeur de 46 %
• Le test exact de Fisher vérifie si les versions Claude se retrouvent plus souvent au-dessus de la médiane de 0.74 sev/10c ; il donne une p-valeur de 74 % et un odds ratio de 1.06

Nombre de commits et ampleur des changements

• Les versions Claude comptaient en moyenne 42 commits, contre 185 pour les versions sans Claude ; la probabilité que deux versions prises au hasard aient autant ou plus de commits était de 88 %
• D’après l’API GitHub compare, les versions Claude ont modifié en moyenne 3 756 lignes, contre 696 lignes pour les versions sans Claude ; la probabilité que deux versions aléatoires aient autant ou plus de lignes modifiées était de 5 %
• Le nombre de bugs pondérés par gravité était en moyenne de 5,6 pour les versions Claude, contre 14,9 pour les versions sans Claude ; la probabilité que deux versions aléatoires aient autant ou plus de bugs pondérés par gravité était de 77 %
• En conclusion, les versions Claude ont bien eu beaucoup plus de lignes modifiées, mais pas davantage de commits ni davantage de bugs pondérés par gravité

Système de versions et valeurs aberrantes antérieures

• La moyenne des versions v2.x est de 1.11 sev/10c, contre 4.23 sev/10c pour les versions v3.x, ce qui indique un taux de bugs plus élevé du côté de v3.x
• Même en ne comparant que les v3.x, les versions Claude se situent dans le milieu de classement ou mieux ; pour faire apparaître Claude comme une valeur aberrante, il faut comparer à une époque plus calme et attribuer à Claude un changement qui avait déjà eu lieu avant son introduction
• Le test des suites de Wald–Wolfowitz donne, sur 35 versions sans Claude, 13 suites observées contre 18,5 attendues aléatoirement, avec z=-1.88 et p=0.060 ; ce n’est pas suffisamment fort pour rejeter l’hypothèse d’aléa au seuil de 0.05
• v3.4.1, pourtant antérieure à l’introduction de Claude, enregistre le taux de bugs le plus élevé de tout l’ensemble de données, avec 59 bugs, 9 commits et 39.39 sev/10c
• v3.4.1 était une version hotfix sortie le lendemain de v3.4.0, et affichait le taux de bugs le plus élevé de toutes les versions, avec une avance de plus d’un chiffre sur toutes les autres, à une époque où il n’y avait pas d’IA à blâmer

Interprétation et limites

• L’interprétation compatible avec les données est la suivante : « les deux versions Claude actuelles ne sont pas statistiquement distinguables des versions historiques »
• v3.4.3, avec 3.29 sev/10c et un 77e percentile, est élevée mais pas extrême ; 8 versions historiques obtiennent un score supérieur
• L’affirmation selon laquelle « Claude a clairement empiré les choses » n’est étayée ni par la distribution des versions, ni par le test par permutation, ni par le test de Fisher
• À l’inverse, on ne peut pas non plus conclure à partir de ces données que « les commits Claude ne rendront généralement pas les choses pires à l’avenir » ; on peut seulement dire que, pour l’instant, ces deux versions restent dans une plage ordinaire
• Cette métrique a pour limite d’être un outil grossier, incapable de contrôler la complexité des commits ou l’intensité du travail lié à la sécurité

Facteurs de confusion discutés

• Un utilisateur de Hacker News estime que les correctifs de sécurité liés aux CVE ont vraisemblablement révélé des erreurs de code présentes depuis 2007
• Un utilisateur de Lobsters propose la chaîne causale suivante : « LLM → augmentation des problèmes de sécurité connus → besoin de plus de changements que d’habitude → plus de régressions que d’habitude »
• Andrew Tridgell explique qu’un déluge de signalements de CVE générés par IA a imposé des changements rapides et étendus dans la surface d’attaque de rsync
• Si l’on tient compte de ces facteurs de confusion, le problème semble moins venir de Claude lui-même que d’une charge de travail sécurité plus importante et, en conséquence, d’un volume de modifications accru

[GN⁺]

Avis sur Lobste.rs

• Je pense que chacun peut décider pour soi s’il veut continuer à utiliser des projets FOSS qui seront désormais développés en vibe coding. En revanche, la colère de la communauté après le passage du mainteneur à des outils de vibe coding a été assez surprenante, et les données empiriques présentées dans l’article permettent au moins de mieux contextualiser l’impact de ce changement de pratique
  Il faudra du temps pour voir si l’adoption de cette façon de coder par le mainteneur permettra de préserver la confiance ou si elle l’érodera davantage

  • Je me demande combien de ceux qui se sont énervés contre cette transition ont réellement contribué de façon significative à rsync ou ont versé de l’argent

• Cette analyse était exactement ce que j’espérais, et même plus. J’ai particulièrement apprécié le passage disant : « J’ai moi-même choisi tous les indicateurs, la méthodologie et les sources de données après en avoir discuté avec ma femme, titulaire d’un master de statistique de Penn State University », et le fait d’avoir impliqué une véritable spécialiste des statistiques ainsi que d’en avoir fait un texte facile à lire est excellent
  Puisqu’un seul indicateur a été utilisé, « le nombre de bugs pour 10 commits », c’est dommage d’avoir raté l’occasion d’utiliser un préfixe SI et d’appeler ça des décibugs par commit

  • D’accord. Ce n’est pas mon article, mais j’ai apprécié que quelqu’un dépasse les réactions excessives pour ou contre et montre avec des données l’impact sur la qualité du code

• Le succès d’un projet open source dépend tellement de la perception que certains vont jusqu’à acheter des étoiles GitHub. Malheureusement, ce problème d’image est désormais hors de contrôle et s’est transformé en argument récurrent, et il sera difficile pour n’importe quelle donnée de changer cela
  À l’avenir, « le mainteneur de rsync a utilisé un LLM et a tout cassé » sera brandi par les sceptiques de l’IA aux côtés d’arguments comme « les datacenters gaspillent 50000 gallons d’eau potable par jour » ou « une étude du METR a dit que les LLM faisaient baisser la productivité »
  Je ne suis pas en train de dire si je suis moi-même sceptique vis-à-vis de l’IA ou non ; je veux simplement dire que les débats sur ce sujet prennent généralement cette tournure

  • Pourquoi serait-ce un « argument », ce n’est pas simplement un fait ?
  • Je ne sais pas si l’auteur cherche à convaincre qui que ce soit avec des données. Je vois plutôt cet article comme une tentative d’apporter un contexte chiffré à la polémique virulente autour de l’adoption de ces outils par rsync
    Cela dit, il est vrai que l’article laisse complètement de côté d’autres éléments non quantitatifs, et c’est sans doute volontaire étant donné qu’il y a déjà assez de bruit des deux côtés, évangélistes comme sceptiques

• Le fait que la pire version de toute l’histoire de rsync soit sortie avant l’arrivée de Claude, avec 39,39 bugs pour 10 commits, est une conclusion très importante et prévisible
  Si les processus entre utilisateurs et développeurs, comme les tests et l’assurance qualité, ne garantissent pas l’exactitude du logiciel, alors on finira par livrer des bugs avec ou sans LLM. Les LLM peuvent nuire à ce processus comme ils peuvent l’aider

  • D’accord. Le billet récent sur cURL semble montrer l’exemple inverse
    Grâce à des pratiques de génie logiciel solides et en place depuis des années, la valeur de ce type d’outils d’IA pour trouver des bugs a globalement diminué
  • J’ai quelques inquiétudes quant à l’avenir de rsync. Le principal problème, c’est que rsync était en pratique un projet terminé depuis des années, mais qu’avec l’usage de l’IA, le code de test existant a été arraché et remplacé par une suite de tests Python, sans faire tourner les anciens tests en parallèle pendant une période significative pour valider la justesse
    À mes yeux, c’est irresponsable. D’autant plus que la fonction première de rsync est de déplacer des données précieuses, et que l’intégrité de ces données est absolument essentielle

• J’aimerais qu’on évite des formules comme « comme c’est typique chez les utilisateurs anti-IA, cela a fini par escalader en fantasmes de violence ». Non seulement l’auteur généralise à partir de certaines personnes avec qui il n’est pas d’accord, mais il risque aussi de braquer les lecteurs qui ne partagent pas son avis, si bien que ceux qui devraient le plus lire l’article ne le liront pas
  Par ailleurs, qu’il y ait plus ou moins de bugs que dans les versions précédentes m’importe assez peu. Ce qui compte pour moi, c’est que le logiciel soit développé d’une manière qui ne correspond pas à ma conception du développement logiciel. Si l’on ne comprend pas d’emblée qu’il y a des problèmes au-delà de la seule efficacité, je n’ai guère d’espoir de convaincre qui que ce soit que cette position est raisonnable
  Heureusement, si je n’en veux pas, je ne suis pas obligé d’utiliser cette version de rsync, et je choisirai une alternative issue d’un fork antérieur à l’usage des LLM

  • Cet article était tellement chargé de colère que je n’ai pas réussi à le lire longtemps et j’ai abandonné. Il aurait mieux valu qu’il cherche à être équitable, ou au moins à en donner l’impression
    Le fait de répéter un mème déjà réfuté depuis longtemps, à savoir que le premier bug report était un ticket sur lequel les gens s’étaient rués, n’a pas aidé non plus. Le véritable premier bug report était un autre ticket

• Franchement, je trouve le texte actuel meilleur. Mais le passage « cet indicateur ne contrôle ni la complexité des commits, ni la sensibilité en matière de sécurité, ni la gravité des bugs. C’est un outil grossier qui ne sait pas distinguer une correction de coquille d’une ligne d’un patch de CVE » passe, de mon point de vue plutôt LLM = mauvais, à côté de la critique essentielle.
  La critique que moi et d’autres formulons, c’est que l’IA pousse à déverser des commits plus gros, plus difficiles à comprendre et qui augmentent la complexité. Les partisans des LLM disent souvent quelque chose de similaire, puis déplacent les poteaux depuis la pratique éprouvée depuis des décennies de « lire la PR » vers « le LLM doit pouvoir tout tester ». Mais le problème de la complexité du code comme dette technique ne disparaît pas pour autant.
  Dans ce cas précis, la gravité du bug est très élevée, parce que le workflow de sauvegarde a réellement été cassé. rsync est largement utilisé pour les sauvegardes, et c’est un outil auquel on faisait confiance comme à quelque chose de « battle-tested », au point que les gens n’imaginaient même pas qu’une mise à jour de patch puisse casser leurs scripts de sauvegarde.
  On peut dire que le fait que le LLM ait produit un logiciel bogué était un accident, ou que le mainteneur doit changer son workflow avec LLM et augmenter la couverture de tests. C’est d’ailleurs ce qu’il a dit lui-même. Mais au cœur de la colère, il y a le fait que cet outil a brisé cette confiance.
  Il existe vraiment en ce moment une nouvelle catégorie de programmeurs au LLM qui disent « je ne lis plus le code du tout ». Ils disent que ça prend trop de temps à lire et que c’est plus complexe à appréhender que du code écrit par des programmeurs ordinaires. Lire du code, c’est apprendre le modèle mental de quelqu’un d’autre, et les outils LLM ne fournissent pas un modèle mental cohérent unique.
  À part ça, il faudrait aussi vérifier l’accessibilité du site. J’ai une très bonne vue et je suis encore dans la vingtaine, mais du texte gris clair sur fond crème/jaune clair est vraiment pénible à lire.

  • Le passage cité me perturbe. L’indicateur utilisé dans l’article semble bien appliquer une pondération par gravité au nombre de bugs pour 10 commits ; l’auteur se contredit lui-même ou c’est moi qui ai mal lu ?
  • Pour les gens dont le workflow a été cassé, j’y vois une bonne occasion d’apprendre ce qu’est le logiciel open source et ce que garantit une licence GPL.
    Je ne pense pas que ces gens auraient découvert ce bug eux-mêmes. J’imagine que plus de 90 % des utilisateurs de rsync utilisent une version antérieure qui n’a pas ce bug. J’en fais partie.

    $ uname -a  
    Darwin riemann.local 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:31 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T8103 arm64
    
    $ port info rsync  
    rsync @3.4.1 (net)  
    [...]  
    

    Si ça a attiré l’attention, c’est probablement parce qu’on n’a pas besoin d’être Steven Pinker pour voir qu’une bonne partie de la communauté est en pleine confusion en ce moment. Le fait que les LLM programment mieux que les humains n’est pas quelque chose de facile à accepter.
    Les personnes qui fondaient leur identité et leur estime d’elles-mêmes sur leurs compétences de programmation ou leur métier font face à une double crise : l’incertitude sur leurs moyens de subsistance futurs / leur valeur sur le marché, et une crise d’identité.
    La peur, l’incertitude et le doute sont difficiles à gérer, et les entreprises du LLM font de leur mieux pour amplifier cet effet afin de faire monter leur cours de bourse. Si le marché corrige brutalement après octobre, il est possible que ce mécanisme d’amplification s’affaiblisse aussi.
    Une toute petite proportion des programmeurs dans le monde, à savoir ceux qui voient le code comme une forme d’art, utiliseront probablement les LLM pour s’entraîner et progresser.

• Cet article cite beaucoup de commentaires qui parlent de régressions, mais l’analyse elle-même ne mesure pas des régressions, seulement des rapports de bugs. Elle rattache les bugs à la version où ils ont été signalés, pas à la version où ils ont été introduits, et elle mesure la gravité des versions par le nombre de commits tout en excluant des facteurs évidents comme la durée d’une version ou l’adoption par les distributions.
  Je ne vois pas en quoi cela a du sens.

• Personnellement, j’évite les projets qui utilisent des LLM. Pas tellement pour une raison concrète, plutôt parce que ça me met profondément mal à l’aise ; un peu comme quand quelqu’un dit « kek » ou « fren » et que je le prends comme un signal que je n’ai plus envie d’interagir, même sans raison précise.
  Les explications avancées aujourd’hui pour justifier le rejet des LLM me donnent l’impression d’être des rationalisations plaquées après coup. Les inquiétudes actuelles sur l’éthique, la qualité, etc. sont valides, mais même si ces problèmes étaient résolus, je ne pense pas que des gens comme moi, de tendance plutôt anti-IA, changeraient soudain d’avis.
  C’est pour ça que j’évite, sans raison précise, les projets avec des AGENTS.md, des commits coécrits par Claude, etc. Ça me déplaît, ce n’est pas mon goût, et peu importe qu’il y ait des bugs ou non. J’imagine que d’autres ressentent la même chose.

• À l’auteur : premièrement, un fantasme reste du langage. En pratique, cela revient à affirmer que ça s’est arrêté aux mots, ou du moins à ne pas prétendre qu’il y a eu une escalade non verbale.
  Deuxièmement, si on veut défendre ce genre d’affirmation, il faudrait demander à un statisticien proche comment l’étayer. Le fait que quelques personnes aient posté ce type de messages ne permet pas, à lui seul, d’étayer de manière significative l’idée que ce serait « typique ».
  Mon observation anecdotique non étayée statistiquement, c’est que les utilisateurs « anti-IA » sont généralement plus tristes que violemment agressifs face au fait que des LLM s’imposent là où ils ne sont d’aucune aide.

  • Je vois parfois des textes très longs et très détaillés qui cherchent à réfuter une partie des opposants aux LLM, en général ceux qui y réagissent sur un plan émotionnel et social. J’ai du mal à expliquer pourquoi, mais ces textes me paraissent très peu sincères, avec une impression de s’en prendre aux plus faibles.
    C’est tellement détaillé qu’il devient difficile d’y répondre sur le plan émotionnel, et au final ça semble toujours conclure que « le problème, ce n’est pas le LLM ; bien utilisé, c’est un amplificateur. Les anti-IA ne comprennent simplement pas et ont seulement peur d’être laissés derrière ».
    Je n’ai pas non plus envie de réduire le travail des mainteneurs de rsync à une simple controverse, donc je ne sais pas comment formuler une contre-réponse convaincante.
    Les statistiques présentées ici peuvent être intéressantes du point de vue de la maintenance open source, mais les conclusions me semblent bizarrement orientées d’un seul côté, et ça me laisse l’impression que l’open source façon GitHub n’est pas la forme à laquelle j’ai envie de contribuer.
    Cela dit, je trouve tout à fait malsain que des gens soient allés se jeter en meute sur le dépôt rsync pour s’en prendre au mainteneur.
  • Il est juste de dire que les fantasmes publics de violence ne sont pas acceptables. Ce n’est pas le genre de chose auquel une civilisation devrait aspirer. En revanche, le fait que l’auteur qualifie cela de « typique » me gêne, parce que c’est une généralisation.
    Pour ce qui est des observations anecdotiques, cette BD dit des choses justes. J’aime voir des affirmations concrètes et mesurables, en partie parce que j’aime les chiffres, et aussi parce que cela aide les discussions en ligne à se rapprocher un peu plus du monde idéal de la dernière case.

• Merci pour l’analyse, mais je ne suis pas convaincu par la méthodologie. J’aimerais voir des métriques comme le nombre de bugs par unité de diff, obtenu en multipliant pour chaque commit le nombre de lignes modifiées dans le code principal — donc hors tests et documentation —, ainsi qu’une analyse du temps nécessaire après une release pour atteindre un certain nombre de bugs.
  Cela dit, comme cette release a probablement attiré bien plus d’attention que les autres, il est très possible que davantage de bugs aient été signalés, ce qui semble rendre difficile l’élaboration d’un indicateur vraiment convaincant. Une question comme « est-ce typique au bout de quelques semaines après la release ? » pourrait aussi ne pas être très utile.