« Tridge and Claude » : pourquoi la présence de l’IA dans Rsync provoque une crise de confiance dans l’open source

Rsync 3.4.3, publié le 20 mai, devait être une mise à jour de sécurité. À la place, une partie des utilisateurs a vu des sauvegardes incrémentales dérailler après installation, au point de pousser certains à revenir à une version antérieure.

La polémique ne tient pas seulement aux bugs. Elle s’est cristallisée autour d’un signal repéré dans l’historique du projet, des commits signés tridge and claude , associant Andrew Tridgell, figure historique de rsync, et Claude, l’assistant d’Anthropic. Dans l’open source, le mélange patch de sécurité et code assisté par IA a suffi à déclencher une vraie colère.

Rsync 3.4.3: six failles CVE corrigées, et des réglages qui changent la donne

Le point de départ est un correctif de sécurité. D’après Linuxiac, rsync 3.4.3 a été publié comme une mise à jour corrigeant six vulnérabilités listées en CVE, qui affectaient rsync 3.4.2 et les versions antérieures. Le même article précise que trois de ces vulnérabilités exigent des configurations non activées par défaut côté démon, et que deux sont atteignables via un pull normal ou une connexion authentifiée à un démon.

Ce cadre explique une partie de la tension, le patch ne vise pas un usage marginal, il touche aussi des scénarios courants. Linuxiac relie aussi les régressions rapportées à des configurations de démon, avec un focus sur une option qui revient dans les discussions, daemon mode et des configurations impliquant chroot = no. Le site indique que la mise à jour inclut des corrections liées à des démons configurés avec cette valeur, et que ce réglage est devenu central dans certains retours de dysfonctionnement.

Pour les administrateurs, le dilemme est immédiat, installer un patch qui ferme des failles, ou temporiser pour éviter de casser des flux de sauvegarde. Le sujet devient explosif parce que rsync n’est pas un outil isolé, il se retrouve dans des scripts, des jobs récurrents, des procédures d’exploitation. Dans ce type d’écosystème, une régression n’est pas un bug comme un autre, elle peut se traduire par une fenêtre de sauvegarde ratée ou une restauration incertaine.

tridge and claude: le détail qui a transformé un bug en procès de méthode

Le nom sur les commits a servi d’étincelle. Selon Korben, depuis la version 3.4.1, des dizaines de modifications sont signées tridge and claude , ce qui renvoie à Andrew Tridgell et à Claude, l’assistant IA d’Anthropic. Pivot to AI chiffre ce point, en indiquant que depuis 3.4.1 il y a 36 commits par tridge and claude dans le dépôt.

Sur Facebook, nixCraft pousse une lecture plus alarmiste, en affirmant que rsync 3.4.3 inclut des commits générés par Claude AI et que des bugs ont cassé rsync, avec un risque de casser des sauvegardes incrémentales. Le même post affirme qu’un retour à 3.4.1 permet de retrouver un fonctionnement normal, et reprend l’élément des 36 commits tridge and Claude depuis 3.4.1.

Le débat, ici, dépasse la question l’IA écrit-elle du code. Il touche à un contrat implicite entre mainteneurs et utilisateurs, un logiciel d’infrastructure peut évoluer, mais il doit bouger avec une prudence extrême, surtout quand la mise à jour est motivée par la sécurité. L’assistance par IA devient un symbole pratique, parce qu’elle suggère à certains une baisse de contrôle, de revue, ou de test. Même si l’IA n’était qu’un outil parmi d’autres, la signature à deux a rendu le processus visible, donc attaquable.

Pivot to AI formule une critique très politique de l’épisode, l’idée que des mainteneurs se retrouvent noyés sous des rapports de sécurité générés par IA, et que certains répondent par de l’IA, avec le risque de produire du vibe code peu fiable. Le ton est polémique, mais il décrit un mécanisme plausible de dégradation, quand les canaux d’alerte se remplissent de bruit, la qualité de tri et de réponse devient plus difficile à maintenir dans la durée.

Régressions: sauvegardes incrémentales, mode démon et retours en arrière

Les effets concrets, eux, sont au centre de la colère. Korben évoque des sauvegardes incrémentales qui se sont mises à mal fonctionner juste après la mise à jour, ce qui a suffi à déclencher une réaction en chaîne chez des utilisateurs qui dépendent de rsync pour des tâches récurrentes. Linuxiac parle de régressions affectant certains workflows, en particulier des configurations de sauvegarde utilisant daemon mode et des options de transfert incrémental.

Dans le forum Linux Mint, la discussion illustre un autre phénomène classique de l’écosystème Linux, la fragmentation des versions selon les distributions. Un participant affiche un exemple de machine sous Mint Mate indiquant rsync 3.2.7 (protocole version 31), tandis qu’un autre cite un environnement Debian testing avec rsync 3.4.3 (protocole version 32). Dans le même fil, un intervenant avance que Ubuntu 26.04 LTS aurait rsync 3.4.1, ce qui, dans sa logique, rendrait Mint 23 OK.

Cette diversité de versions est souvent présentée comme un gage de stabilité, mais elle a un revers, elle étale dans le temps l’arrivée des correctifs de sécurité. Quand une version pose problème, certains environnements se retrouvent protégés par leur inertie, et d’autres servent de terrain d’impact. Le fil Linux Mint le montre sans détour, l’utilisateur sous une version plus ancienne se félicite d’être sur une distribution qui priorise la stabilité, pendant qu’un autre réagit avec inquiétude à la présence de 3.4.3.

Sur le terrain, le réflexe le plus simple est le retour en arrière. Linuxiac indique que des utilisateurs reviennent à des versions plus anciennes. NixCraft va plus loin en recommandant explicitement de revenir à 3.4.1. Cette stratégie réduit le risque opérationnel immédiat, mais elle réintroduit mécaniquement la question de la sécurité, puisque Linuxiac rappelle que 3.4.3 corrige des vulnérabilités affectant 3.4.2 et antérieures. Ce n’est pas un choix confortable, c’est un arbitrage.

Andrew Tridgell face au contrecoup: trop de rapports IA, et une 3.4.4 ou une 3.5 en ligne de mire

Linuxiac rapporte qu’Andrew Tridgell a répondu à la controverse dans un post intitulé rsync and outrage. Il y évoque un problème très actuel pour les mainteneurs open source, un volume important de rapports de sécurité, dont beaucoup seraient générés par IA. Le point est important, il déplace la focale, l’IA n’est pas seulement dans le code, elle est aussi dans le flux d’alertes, d’audits et de tickets qui arrivent sur les projets.

Sur la suite, Linuxiac indique que Tridgell dit travailler à corriger les régressions. Il envisage soit une version 3.4.4 pour traiter une partie des problèmes, soit de poursuivre vers la version 3.5, décrite comme devant inclure des changements de sécurité plus étendus. Dit autrement, le projet se retrouve avec deux impératifs concurrents, stabiliser vite pour restaurer la confiance dans les usages de sauvegarde, ou avancer vers une étape plus structurante sur le plan sécurité.

Pivot to AI ajoute un élément de contexte personnel, en indiquant que Tridgell est retraité mais se sentirait obligé de continuer rsync. Ce détail n’excuse rien du point de vue des utilisateurs touchés, mais il éclaire une réalité du logiciel libre, des briques critiques reposent parfois sur des personnes, leur temps, leur énergie, et des arbitrages difficiles entre maintenance, sécurité et changements techniques.

La nuance à garder, c’est que l’épisode ne se résume pas à IA égale bug. Linuxiac insiste, la controverse dépasse l’implication de l’IA, parce que des changements motivés par la sécurité ont affecté des workflows standard. Dans un outil de sauvegarde, c’est la pire combinaison, un patch urgent, une régression, et une incertitude sur la marche à suivre. L’IA, ici, sert de catalyseur de défiance, parce qu’elle rend visible une méthode qui inquiète une partie de la communauté.

Quand la confiance se casse: distributions prudentes, forks évoqués et migrations

La colère se lit aussi dans les réactions communautaires. Sur le forum Linux Mint, un message résume l’état d’esprit, les dernières versions seraient devenues buggy and dangerous dans un environnement professionnel, et l’auteur estime qu’il faudrait surveiller le sujet parce que rsync est un outil fondamental qui pourrait devoir être forké. Ce n’est pas une décision, mais l’évocation du fork est un marqueur fort, elle apparaît quand la confiance dans la gouvernance ou la stabilité se dégrade.

Pivot to AI mentionne également des mainteneurs de distributions qui déclareraient ne plus pouvoir faire confiance à rsync et se tourner vers openrsync. Le point est politiquement lourd, parce qu’il touche à la chaîne de distribution, si des distributions basculent, même partiellement, le logiciel perd son statut de choix par défaut. Dans l’open source, la confiance se mesure aussi à la place dans les dépôts, les scripts d’installation, les documentations. Une fois l’idée de migration installée, la reconquête est lente.

La critique à formuler, au-delà du cas rsync, vise le rythme de l’écosystème. Les rapports de sécurité générés par IA, évoqués par Tridgell selon Linuxiac, peuvent rendre service, mais ils peuvent aussi saturer les projets. Et quand la réponse devient elle-même assistée par IA, le risque est de déplacer le problème, moins de temps pour tester dans des environnements réalistes, plus de changements, plus de surface de régression. Le résultat est connu, les utilisateurs se replient sur des versions anciennes, ou sur des alternatives, et l’effort de sécurité perd une partie de son effet.

Dans l’immédiat, l’épisode rsync 3.4.3 laisse une question simple et tranchante pour les équipes qui font tourner des sauvegardes, quelle version installer quand un correctif CVE et une régression se télescopent, et quand la prochaine sortie pourrait être une 3.4.4 de stabilisation ou une 3.5 plus ambitieuse sur la sécurité.