Extrait de l'émission CPU release Ex0228 : lost + found (janvier 2026).
On vous l'a déjà dit, le logiciel libre est faussement gratuit : il demande du temps, il demande de la patience, mais il demande aussi de participer au projet lui-même : par le code, par l'écriture de procédures, la rédaction du manuel, du graphisme, des traductions, les retours de bugs et l'aide à la communauté.
Et pratiquement tout ce qui concerne l'informatique aujourd'hui fonctionne en partie ou en totalité grâce au logiciel libre. Mais ces projets eux-même sont sous-financés, sous-staffés. On a déjà eu plusieurs fois des alertes. Comme pour OpenSSL, qui est la base commune du chiffrement des protocoles et qui a failli disparaître, ne tenant à l'époque que par la volonté d'une seule personne, faute d'un financement suffisant.
Un rapport commandité par Sentry et publié en Novembre 2025 fait ce constat alarmant : l’écosystème Open Source repose largement sur le travail non-rémunéré de développeurs en burn-out. Les raisons ? Responsabilités énormes, difficultés à trouver des financements, contribution de tiers trop peu qualitatives voire malicieuses, tentatives de piratage, communauté ayant parfois un comportement toxique.
Et la gamification introduite par des plateformes comme Github ajoute une énorme pression sociale envers les principaux développeurs de logiciel libre. En clair, une grosse boite s'amuse à ajouter une pression sociale par des badges de mérite sur le nombre de contributions, oubliant que nombre de projets open-source ne tiennent que par des apports de bénévoles.
Parce que oui, hélas, les leçons ne sont toujours pas apprises : le logiciel libre fait tourner énormément de grosses entreprises mais celles-ci oublient de participer en retour.
Ou alors, elles le font mal.
Par exemple, prenez FFMpeg. C'est un outil de décodage/encodage de son et de vidéo vers de multiples formats. Nous même, pour le site de l'émission CPU, nous nous en servons pour encoder dans un format son, le HLS, qui permet aux smartphones de sauter plus vite entre les chapitres des émissions.
FFmpeg est une suite de bibliothèques créées en 2000 par Fabrice Bellard, un dev français archi-prolifique à qui on doit aussi QEMU, un émulateur de sasfépu, une solution logicielle pour émetteur 4G/5G qui tient dans un seul PC, et de multiples outils incroyables. La suite du projet FFmpeg est désormais gérée par Michael Niedermayer.
Sans FFmpeg, on aurait ni VLC, ni MPlayer, ni Bendler, ni Youtube, ni vidéo dans Chrome ou Firefox, ni streaming sur votre télé.
Et pour chapeauter le projet open-source, FFmpeg est soutenu par une fondation dont le budget annuel est loin sous le million d'euros, déplorable quand on connait tout ce qui tourne comme business avec. Car pour utiliser FFmpeg, il vous suffit simplement de le télécharger, et en accord avec la licence utilisateur, de le signaler. Et c'est tout.
Et le problème est que les grandes compagnies ne réfléchissent qu'en termes juridiques ou de qualité de service sans se poser la question de la réciprocité de leur contribution.
Mark Atwood, expert code pour Amazon, a déjà passé une semaine à expliquer à ses patrons qu'il faut absolument qu'ils arrêtent d'embêter FFmpeg pour des histoires d'accord confidentiel. La raison étant des bugs relevés en encodant un fichier vidéo soumis à droit d'auteur, donc impossible à transmettre comme exemple du bug à corriger. L'organisation open-source n'en n'a cure puisqu'ils n'ont rien signé avec Amazon, et que comme les patrons d'Amazon refusent de participer financièrement à FFmpeg, FFMpeg pourrait par agacement d'un coup de commit bloquer le fonctionnement de 3 gros projets d'Amazon (à savoir Amazon Prime, un service de transcodage vidéo d'AWS et Ring [et Twitch.tv]). Il faut dire qu'Amazon pioche dans plein de projets open-source sans jamais contribuer financièrement en retour. C'était d'ailleurs l'objet d'un litige entre Elastic et AWS.
FFMpeg est aussi très très utilisé par Alphabet, alias Google : aussi bien pour le système Android, pour Android TV, mais aussi pour Youtube afin de produire les dizaines de formats utilisés par le site de vidéos trop mignonnes.
Octobre dernier, ça a tourné au vinaigre sur le réseau social X entre FFmpeg et Google. Je dois avouer que je ne vais plus du tout sur X pour d'évidentes raisons d'hygiène, et je remercie Steven Vaughan-Nichols pour son article du The New Stack résumant les points importants du litige.
Google fait partie des géants qui se sont lancés dans la construction de modèles d'IA LLM généralistes, en concurrence avec OpenIA, Anthropic, Microsoft et d'autres. Et Google, comme Microsoft, a décidé de fortement compléter le travail de développeurs avec ses outils agentiques. Parce que l'investissement massif dans l'IA devra forcément rendre has-been les développeurs humains.
Donc l'équipe sécurité de Google a regardé l'immense écosystème logiciel géré par leurs équipes, et leurs dépendances à des projets open-source externes. Ils ont décidé que les IA feraient de la revue de code automatique et ouvriraient automatiquement des tickets de demande de corrections sur les bibliothèques open-source.
L'outil mis en place s'appelle Big Sleep, car souvent, il s'agit de bug non vus, dormants et potentiel nid à failles. Ce que l'on appelle une dette technique.
Plantage !
Ça a été un déluge. Mais littéralement un déluge, de tickets générés automatiquement. Avec beaucoup, mais alors beaucoup trop de fausses alertes, des alarmes levées sur des tournures de code incomprises ou sans aucune compréhension de ce qui est ramené.
Alors, se prendre des audits non-sollicités par des gens qui croient bien faire mais qui comprennent rien à votre travail, ça m'est déjà arrivé : on m'a dit qu'un serveur avait une grave faille de sécurité à cause d'un composant java… sauf que ce composant java n'a jamais été installé, d'ailleurs y'avait pas un gramme de code java sur le serveur, que du PHP. Le robot s'est mépris sur un code HTTP d'erreur retourné sur une portion d'URL. Gros fail.
Moi, j'ai été poli, j'ai recommandé à la personne qui croyait bien faire de retourner à son métier, où il avait du retard.
Mais là, FFmpeg n'a pas du tout apprécié le ticket automatique du bot de Google ouvert sur leur TRAC, leur outil de rapport de bug. Surtout que le bot ne semble pas lire les commentaires, et insiste lourdement pour traiter les tickets.
FFMpeg a rappelé mi Octobre que les rapports de bugs sont considérés avec sérieux par des bénévoles. Et disons qu'ils ont été diplomatiquement agacés dans ce qui a suivi.
Car le bug en question concerne un format vidéo, Smush, qui n'a été utilisé que par une trentaine de jeux sortis vers 1995. Et le bug fait que les dix premières images de l'intro du jeu « Star Wars : Rebel Assault 2 » ne sont pas lues. Oui, ok, soit, compris, mais franchement, on parle de 2 vidéos qui ont été pondues y'a 30 ans, dans un format archi-confidentiel et totalement obsolète. Un humain aurait forcément compris que la priorité de résolution était extrêmement basse, tout fan qu'il puisse être de Star Wars.
Sauf que Google Big Sleep lui a attribué un identifiant CVE temporaire dans la foulée du rapport de bug. Je vous la refais : le bot Big Sleep a ouvert un procédure d'identification auprès de la MITRE corporation pour se voir attribuer la paternité d'un code Common Vulnerabilities and Exposures
, CVE donc, pour un bug mineur concernant un obscur format vidéo que personne n'a utilisé depuis 30nbsp;ans. Se prendre un identifiant CVE sur son code, c'est franchement pas glorieux.
Et ce n'est pas fini : Google a désormais une nouvelle politique sur les bugs découverts dans des projets tiers, ils laissent 90 jours pour corriger le problème avant de l'annoncer publiquement et jeter l'opprobre sur le développeur trop lent à réagir.
L'organisation FFmpeg a réagit sur X en qualifiant l'initiative de CVE slop
, pourrissage d'index de vulnérabilité
.
Je rappelle que Google fait des milliards en bénéfice, mais reverse beaucoup trop peu vers les développeurs des briques du logiciel libre.
Par exemple, Google propose de mettre à disposition des développeurs pour corriger des bugs, mais pas plus de 3 bugs par projet par mois. Tout en ayant rempli des milliers de rapports d'erreurs sur FFmpeg. Il est loin l'époque 2012-2014 où quand deux devs sécurité de chez Google trouvaient un millier de bugs dans FFmpeg, ils poussaient en même temps leurs corrections dans le code source.
L'organisation FFmpeg a été claire : Que Google revoit à la hausse sa participation financière aux projets open-source pour corriger les bugs qu'il rapporte, ou… il sera le dernier servi.
FFmpeg n'est pas seul à exploser devant ces rapports de bugs et la pression sociale autour sans reconnaissance :
Ainsi, tout récemment, Nick Wellnhofer a abandonné sa bibliothèque libxml2, fatigué de demandes insistantes de corrections de bugs mineurs. Sauf que cette libxml2 est énormément utilisée, notamment tous les navigateurs web, les suites bureautiques, et j'en passe, mais n'a donc plus de mainteneurs depuis Décembre.
Après les errances de l'IA avec le vibe-coding de mauvaise qualité, l'hallucination de fonctions d'API qui n'ont jamais existé, voilà que l'IA pourri l'écosystème du logiciel libre par des rapports de bugs tout en faisant pression socialement pour leur correction. On pourrait très bien voir des briques de code primordiaux d'internet et même de l'informatique moderne exploser avec de telles initiatives de multinationales qui financent des moteurs d'IA avec des fortunes d'un côté mais rétribuent trop peu les bases logicielles en retour.
Ce déséquilibre est lui-même un point de singularité.
Textes : Da Scritch
Illustration : Requête Dall-E A sharp symbol and a question mark symbols floatting in a library
, libéré en CC.