URL: https://linuxfr.org/news/debian-ia-vibe-coding-rsync-la-croisee-des-chemins Title: Debian, IA, vibe coding & rsync : la croisée des chemins ? Authors: Benoit Sibaud Julien Jorge Date: 2026-10-03T10:08:12+02:00 License: CC By-SA Tags: rsync et debian Score: 10 _rsync_ est un logiciel libre de synchronisation distante de fichiers (_remote synchronisation_), [très utilisé](https://qa.debian.org/popcon.php?package=rsync) et [fréquemment évoqué](https://linuxfr.org/tags/rsync/public) sur LinuxFr.org. Ce logiciel a connu une polémique récente sur l’utilisation de LLM pour son développement et maintenant les versions concernées sont arrivées dans Debian, non seulement les versions futures de la distribution mais également la version courante. Et la suite de la dépêche de s’interroger sur les conséquences ou non de ce (peut-être) notable événement. Et plus largement sur le clivage autour de l’_intelligence artificielle générative_. ---- ---- Le 20 mai 2026, la version 3.4.3 a été publiée, amenant des correctifs sécurité et des corrections de bugs. Et très vite les critiques sont arrivées (par exemple le 29 mai le bug Debian [Consider reverting to pre-LLM version](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1138239) (_considérer un retour à une version pré-LLM_) ou le 30 mai un ticket GitHub [Please Do Not Vibe Fuck Up This Software](https://github.com/RsyncProject/rsync/issues/929) (quelque chose comme _merci de ne pas sIAloper ce logiciel_) attribuant les problèmes à l’intelligence artificielle ; ceci a entraîné une réponse du mainteneur [Andrew Tridgell](https://fr.wikipedia.org/wiki/Andrew_Tridgell) [rsync and outrage](https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0) expliquant s’être aidé de LLM pour réécrire sa suite de tests (du shell au Python). Et les régressions constatées n’étaient pas liées à l’IA au final. Dès le 20 mai, la première version post-polémique [atteignait](https://tracker.debian.org/pkg/rsync) les dépôts Debian de développement (_[2026-05-20] Accepted rsync 3.4.3+ds1-2 (source) into unstable_). Et en août la version 3.5 y est entrée (_[2026-08-17] Accepted rsync 3.5.0+ds1-1 (source) into unstable_). En juillet et août 2026 a eu lieu un scrutin pour les personnes développant la distribution Debian sur l’usage des LLM (voir les annonces, discussions, résultats et conséquences [1](https://linuxfr.org/users/e3ms6vyx/liens/general-resolution-llm-usage-in-debian), [2](https://linuxfr.org/users/misc/liens/results-for-llm-usage-in-debian), [3](https://linuxfr.org/users/vida18-2/liens/debian-autorise-l-ia-dans-son-code-linux-et-une-partie-de-la-communaute-claque-la-porte)). Le choix s’est porté sur un « usage responsable de l’IA générative ». Le 15 septembre, le mainteneur Debian du paquet rsync a annoncé que « pour corriger 33 CVE, [il a] décidé de passer à la version 3.5.0 plutôt que de rétroporter toutes les corrections individuellement » (ce qui entraîne des changements de comportement, est annoncé à la mise à jour du paquet et a amorcé la réflexion qui a donné lieu à cette dépêche). Verra-t-on un basculement majeur vers autre chose que _rsync_ des réfractaires à l’IA ? Est-ce un non-événement ? Est-ce le premier de nombreux cas où des paquets embarquant des modifications faites par un LLM (sont arrivées et) arriveront dans Debian ? D’une part, la fracture sur le sujet est palpable : ainsi le [sondage StackOverflow 2025](https://survey.stackoverflow.co/2025/) rapportait 20% de défavorables à l’IA, 60% de favorables et 20% d’incertains/indifférents, mais avec 33% de confiance dans l’IA et 46% de défiance, et 32% d’utilisateurs de l’IA et 38% de réfractaires à l’idée. Le [sondage State of Devs 2026](https://2026.stateofdevs.com/en-US) donne un 50/50 sur les avis positifs ou négatifs sur l’IA, sur l’effet sur l’état mental de l’IA, et classe en premier comme risques l’impact environnement, la perte d’emploi, la montée de l’_IA slop_, les effets cognitifs et l’usage militaire. Même le [sondage State of IA 2026](https://2026.stateofai.dev/en-US/) est révélateur : les utilisateurs d’IA amplifient leur usage, avec de plus en plus d’agentique, tout en reconnaissant une addiction, une capacité à se faire traire financièrement (pour le dire grossièrement) et une montée des risques. Dit autrement tout en se traitant parfois qui de mormons passéistes rétrogrades qui de moutons suivistes antéchristiques (termes non contractuels), tout le monde reconnaît la complexité et la multiplicité des risques. D’autre part, la capacité à faire autrement est assez réduite : forker une Debian en Devuan pour se passer de Systemd est « relativement » facile, on remplace un seul logiciel et les alternatives pré-existaient. Vouloir éviter d’être teinté par une GPL comme certains projets BSD reste faisable (il suffit d’une alternative à chaque logiciel GPL, et visiblement c’est plus ou moins le cas). Mais vouloir éviter tout logiciel libre ayant eu une contribution LLM est-il encore possible ? Est-on seulement capable de lister les logiciels concernés ? Et existe-t-il encore une alternative non-teintée à chacun d’entre eux ? Ne serait-ce pas aussi dur que par exemple vouloir faire du logiciel propriétaire sans jamais utiliser un seul logiciel libre quand ceux-ci sont omniprésents, en particulier dans le développement logiciel ? Bref, est-on à une croisée des chemins ? Ou déjà bien engagé sur une route (et laquelle) ? La réponse est laissée en exercice au lectorat (moi à la base je voulais juste mettre à jour des Debian).