Vous l'avez peut-être remarqué si vous utilisez Brave, Vivaldi ou Edge sur votre mobile... Google a décidé encore une fois de serrer la vis. La fête du slip semble toucher à sa fin pour la lecture en arrière-plan de YouTube via les navigateurs tiers. C'est donc la douche froide pour ceux qui profitaient de cette petite faille pour écouter de la musique écran éteint sans passer à la caisse.
En gros,
Google a durci ses contrôles
pour bloquer cette fonctionnalité sur les navigateurs mobiles tiers. L'objectif, selon eux, est d'assurer une expérience "cohérente" (et surtout de vous pousser vers l'abonnement YouTube Premium). Ça s'inscrit dans cette
guerre sans fin contre les bloqueurs de pubs
qui dure depuis 2023. C'est de bonne guerre, diront certains, mais c'est surtout très agaçant quand on a l'habitude de bidouiller.
Heureusement, comme toujours sur le Web, quand une porte se ferme, une fenêtre s'ouvre (ou on casse le mur, c'est selon). Voici le point complet sur ce qui marche encore... et ce qui ne marche plus.
Mise à jour : Suite à vos nombreux retours par mail (merci !), j'ai complété cet article avec plusieurs astuces supplémentaires, notamment pour Brave, iOS, ReVanced et une extension Firefox bien pratique.
Brave, Vivaldi, Edge... c'est plié
Autant le dire tout de suite, cette méthode est quasiment MORTE. La majorité des tests récents montrent que la lecture s'arrête net quand vous verrouillez l'écran ou quand l'app passe en arrière-plan. Y'a bien quelques retours isolés qui parlent d'un fonctionnement occasionnel sur Brave, mais c'est devenu tellement aléatoire que c'est pas la peine de compter dessus. Cette porte-là, Google l'a bien refermée.
Cela dit, un lecteur m'a filé une astuce intéressante pour Brave. En allant dans Confidentialité > Filtrage de contenu > Filtres personnalisés, vous pouvez ajouter la ligne suivante :
youtube.com##+js(brave-video-bg-play)
Ça injecte un script qui force la lecture en arrière-plan. J'ai pas encore assez de recul pour dire si ça tient dans le temps, mais ça vaut clairement le coup d'essayer si vous êtes fidèles à Brave.
La méthode Firefox (fragile)
Si vous êtes sur Android, Firefox reste votre meilleur allié... mais plus pour très longtemps peut-être. Avec l'extension Video Background Play Fix dispo pour Firefox Android, vous pouvez encore faire croire à YouTube que vous êtes toujours actif sur l'onglet même quand l'écran est verrouillé. Ça marche quelques jours, parfois quelques semaines, jusqu'à ce que YouTube patche le truc.
Pour les plus témérraires, il y a toujours la technique du caméléon : changer votre User-Agent avec l'extension
User-Agent Switcher
pour vous faire passer pour un PC de bureau. Sauf que YouTube ne se fie plus uniquement au user-agent pour ses vérifications... Du coup c'est de moins en moins fiable.
D'ailleurs, y'a une autre extension qui vaut le détour : Background Playback Helper. Celle-ci fonctionne à la fois sur Firefox Desktop ET Android (à partir de la version 142), et elle empêche YouTube, YouTube Music et même Vimeo de couper le son quand vous changez d'onglet ou verrouillez l'écran. Le dev a intégré un système keep-alive optionnel qui envoie des signaux d'activité pour éviter les timeouts. Pas mal du tout. La version 0.4.1 gère déjà les derniers blocages de Google et une 0.5.0 est en test avec la gestion automatique du fameux popup "Toujours regarder ?" qui vous gonfle quand vous écoutez en arrière-plan depuis trop longtemps.
Bref, on installe et on croise les doigts. C'est le jeu du chat et de la souris permanent et rien n'est garanti à 100%.
Les clients alternatifs (la vraie solution)
Si vous en avez marre de jouer au chat et à la souris avec Google, la solution radicale c'est de passer sur un client alternatif. C'est aujourd'hui la méthode LA PLUS FIABLE pour écouter YouTube en arrière-plan sans passer à la caisse.
NewPipe reste LA référence open source. Lecture en arrière-plan, téléchargement de vidéos, mode Picture-in-Picture, zéro pub, zéro tracker, pas besoin de compte Google. L'app gère aussi SoundCloud, PeerTube et Bandcamp. Seul hic, YouTube casse régulièrement les API et l'app peut planter du jour au lendemain (y'a eu DEUX hotfixes rien qu'en janvier 2026). Hop, on met à jour via F-Droid et ça repart. Vous lancez la vidéo, vous appuyez sur le bouton "Arrière-plan" et voilà. Votre écran s'éteint, la musique continue. C'est magique !
Mais NewPipe c'est pas la seule option. Tubular est un fork de NewPipe avec
SponsorBlock
intégré (pour skipper automatiquement les segments sponsorisés) et le retour des dislikes. LibreTube passe par un proxy Piped, donc YouTube ne voit même pas votre IP... et l'interface est plus moderne. Et puis y'a Grayjay, le couteau suisse qui regroupe YouTube, Twitch, Dailymotion et PeerTube dans une seule app (pas totalement open source par contre, mais très complet).
Et y'a un truc que BEAUCOUP d'entre vous m'ont signalé par mail et que j'aurais pas dû zapper... ReVanced. Le concept est différent des apps ci-dessus puisque ReVanced ne remplace pas YouTube, il le PATCHE. Vous gardez l'app YouTube officielle avec son interface, mais avec la lecture en arrière-plan, zéro pub et même SponsorBlock en bonus. Il faut installer le ReVanced Manager pour appliquer les patches, plus un service appelé GmsCore qui simule les Google Play Services. C'est maintenu activement et plutôt stable (genre 3 mises à jour par an suffisent). Par contre, faites gaffe aux faux sites qui tentent de surfer sur la réputation du projet... le seul dépôt officiel, c'est sur
GitHub
.
Toutes ces apps (sauf ReVanced) s'installent via
F-Droid
ou en APK. Pas via le Play Store, forcément... Google aime pas trop ce genre de trucs.
Et sur iOS ?
Pour les utilisateurs d'iPhone, c'est toujours plus compliqué qu'Android... mais pas autant que je le pensais ! Plusieurs d'entre vous m'ont envoyé des pistes et y'a des trucs qui marchent vraiment bien.
Tube PiP permet d'avoir le mode Picture-in-Picture sur YouTube, ce qui vous laisse réduire la vidéo et utiliser votre téléphone normalement pendant que ça continue de tourner. C'est dispo directement sur l'App Store, donc pas de bidouilles à faire.
Et puis y'a Video Lite qui gère YouTube mais aussi Twitch, Rumble et même TikTok (bon ça c'est optionnel). Lecture en arrière-plan, pas de pubs... Y'a juste une petite pub au démarrage de l'app elle-même (qui se bypass apparemment en passant par un VPN type ProtonVPN). Un lecteur m'a d'ailleurs précisé qu'il avait créé un compte Google dédié pour l'occasion, par parano... et franchement, il a pas tort.
Bref, sur iOS c'est pas aussi riche qu'Android mais vous avez quand même de quoi faire.
Du coup voilà, que vous soyez sur Android ou iOS, y'a des solutions. Sur Android, passez sur ReVanced si vous voulez garder l'app officielle, sur NewPipe / Tubular si vous préférez un truc 100% indépendant, ou même sur
WeTube pour une expérience sans pub
dispo sur le Play Store. Sur iOS, testez Tube PiP ou Video Lite. Tout le reste (navigateurs tiers), c'est du bricolage temporaire que Google finira par casser.
Une équipe de chercheurs en économie vient de poser des maths sur un truc que pas mal de devs sentaient venir... Le vibe coding serait en train de tuer l'open source. Pas au sens figuré, hein. Au sens "les mainteneurs ne pourront bientôt plus payer leurs factures". J'ai parcouru le papier ce midi, et je pense que ça va vous choquer...
En gros,
le document
modélise ce qui se passe quand des millions de devs arrêtent d'aller sur Stack Overflow et de lire la doc officielle pour plutôt demander à Claude, Copilot, Cursor ou Windsurf de tout faire à leur place. En fait, à cause de ces nouvelles habitudes, les projets open source qui vivaient de la pub sur leur site, des sponsors attirés par le trafic, ou de la visibilité communautaire... perdent tout. Le trafic baisse, les dons baissent, les revenus baissent.
Et les chiffres font mal !
Tailwind CSS, par exemple. J'ai regardé les stats npm de tailwindcss sur npmtrends.com... les téléchargements hebdo dépassent les 44 millions en janvier 2026, c'est du jamais vu. Sauf que les visites sur tailwindcss.com ont plongé d'environ 40%.
Côté revenus, c'est encore pire, puisque ça a chuté d'à peu près 80%. Adam Wathan, le créateur de Tailwind,
en parlait début 2026
et ça avait l'air de bien le déprimer.
Pendant ce temps, Stack Overflow a perdu un quart de son activité depuis fin 2022 avec l'arrivée de ChatGPT. Bah oui, plus besoin de poser des questions quand l'IA vous mâche le travail.
En fait, l'IA utilise MASSIVEMENT l'open source pour générer du code. Elle s'appuie dessus, elle recommande les packages, elle les intègre automatiquement. Mais elle ne renvoie personne vers les sites des projets. C'est un peu comme si Spotify jouait vos morceaux sans jamais afficher le nom de l'artiste... et sans le payer non plus !
D'ailleurs, les auteurs du papier font exactement cette analogie. Ils proposent un modèle "Spotify pour l'open source" où les plateformes d'IA (OpenAI, Anthropic, GitHub) partageraient leurs revenus d'abonnement avec les mainteneurs en fonction de l'utilisation réelle des packages. Leur calcul montre que sociétés d'IA devraient contribuer au minimum à hauteur 84% de ce que les utilisateurs classiques apportent, sinon c'est la spirale de la mort pour les projets.
Perso, ça me rappelle
la fameuse lettre de Bill Gates en 1976
qui gueulait déjà que personne ne voulait payer pour le logiciel. Cinquante ans plus tard, on en est toujours au même point, sauf que maintenant c'est l'IA qui fait le travail de sape. Et comme le disait
Linus Torvalds récemment
, le vibe coding c'est "horrible, horrible" pour la maintenance du code. Pas juste parce que le code généré est souvent bancal, mais parce que ça coupe le lien entre le dev et l'écosystème qui le nourrit.
Après, attention, ça veut pas dire que TOUS les projets open source vont crever du jour au lendemain. Ceux qui ont des contrats enterprise genre Red Hat ou du support payant à la Elastic s'en sortent... pour l'instant. Pareil pour les gros projets type Linux ou Kubernetes qui sont soutenus par des fondations. Le problème, c'est surtout les petits projets maintenus par une ou deux personnes qui vivaient de la visibilité. Vous savez, le mec qui maintient un package npm avec 2 millions de téléchargements hebdo depuis son appart, sans sponsor... ben lui, il est dans la panade. Sauf si le mec a un Patreon bien rempli ou un contrat de consulting à côté, mais ça c'est l'exception, pas la règle.
Et n'allez pas croire que les GitHub Sponsors suffisent... j'ai galéré à trouver ne serait-ce qu'un seul projet avec plus de 500$/mois via ce système.
Le plus flippant dans tout ça, c'est que même si l'IA rend chaque dev individuellement plus productif, le résultat net peut être carrément NÉGATIF pour tout le monde. Moins de projets open source viables, moins de diversité, moins d'innovation à la base. Et ces auteurs le démontrent mathématiquement avec leur modèle à deux canaux (productivité vs diversion de la demande).
Et sachez le, même dans le scénario le plus optimiste où les plateformes d'IA payeraient leur part, si ce ratio tombe en dessous de 84%... c'est foutu. Le modèle diverge et les projets meurent quand même.
Bref, si les plateformes d'IA ne trouvent pas un moyen de rémunérer l'open source qu'elles exploitent, on court droit vers un appauvrissement massif de l'écosystème open source.
À l’heure du codage par IA, il est d’autant plus important de s’assurer que les contributeurs comprennent ce qu’ils proposent.
Un des ateliers de la FOSDEM 2026 a abordé cet aspect. Le contexte : une réflexion au sujet de la charge qui pèse sur les mainteneurs de projets open source.
Référence y est faite dans une discussion sur GitHub. Avec une question : que pourrait faire la plate-forme pour motiver les contributeurs à passer du temps sur les explications (descriptions de problèmes et de features) plutôt que sur la soumission de code ?
Là n’est cependant pas le thème principal de cette discussion. À travers elle, GitHub fait plutôt part de ses perspectives concernant la gestion des PR.
À court terme, il propose aux mainteneurs des options pour les désactiver complètement, les restreindre aux collaborateurs et les supprimer depuis l’UI.
Sur le long terme, GitHub envisage une solution « intermédiaire » permettant de conditionner l’ouverture de PR au respect de critères. Il songe aussi à exploiter l’IA pour évaluer le respect des standards/guidelines des projets.
Pour les guidelines, la source de vérité pourrait être le fichier CONTRIBUTING.md.
GitHub invité à envisager la désactivation automatique de Copilot
Beaucoup de projets veulent partager du code sans créer un entonnoir de contributions publiques, confirme un participant qui approuve les perspectives à court terme. Les mesures de contournement actuelles – des bots qui ferment les PR – ajoutent du bruit et sont peu intuitives, précise-t-il. Et de suggérer, concernant la vision à plus long terme, de pouvoir faire la différence entre contributeurs passagers et contributeurs externes de confiance sans avoir à donner d’accès collaborateur complet.
On suggère aussi à GitHub de quoi restreindre les contributeurs « nouveaux » – par exemple, dont la première interaction remonte à moins de 48 heures – à un seul PR. Ou encore d’obliger la liaison de tout PR à un ticket ou à une discussion.
Sur le volet IA, on suggère à GitHub un système de seuils configurables au niveau du dépôt ou de l’organisation. Et la désactivation automatique de Copilot sur les repos dont la politique interdirait l’usage.
Vous avez déjà remarqué à quel point nos claviers Android sont devenus bavards ? Que ce soit
Gboard
ou
SwiftKey
, ils ont tous la fâcheuse tendance à vouloir "améliorer l'expérience utilisateur" en envoyant vos habitudes de frappe sur des serveurs distants. Forcément, quand on sait que tout ce qu'on tape, des mots de passe aux messages privés, passe par cette petite interface, ça peut vite donner des sueurs froides niveau vie privée.
Alors c'est exactement pour contrer cette tendance qu'un nouveau projet open source vient de pointer le bout de son nez : Urik.
Pas de télémétrie dans ce clavier, et pour les plus paranos, sachez que le dictionnaire personnalisé et l'apprentissage des mots sont également stockés dans une base de données locale chiffrée avec SQLCipher. Vos frappes restent donc chez vous et nulle part ailleurs. On est dans la même philosophie que
FUTO Voice Input
, ce qui prouve qu'on peut avoir des outils intelligents sans pour autant sacrifier sa vie privée.
Côté technique, Urik n'est pas un clavier au rabais. Développé en Kotlin, sous licence GPL-3.0, il propose tout ce qu'on attend d'un outil moderne : la saisie par glissement (swipe), le contrôle du curseur via la barre d'espace et le support de dispositions alternatives comme le Dvorak, le Colemak ou le Workman.
Et pour la correction orthographique, il s'appuie sur l'algorithme SymSpell qui tourne lui aussi intégralement sur le téléphone. L'intelligence du truc permet d'ailleurs d'éviter de corriger bêtement les URLs ou les adresses email, ce qui évite pas mal de frustrations au quotidien.
Petite parenthèse, pour ceux qui ont besoin d'outils de protection supplémentaires sur mobile, n'hésitez pas aussi à jeter un œil à
Oversec
pour chiffrer vos communications.
Urik, de son côté, soigne aussi l'accessibilité avec un support complet de TalkBack et des thèmes à haut contraste conformes aux normes WCAG AA. L'application nécessite au minimum Android 8.0 et bien qu'elle soit encore officiellement en bêta, elle est déjà très stable pour un usage quotidien.
Alors oui, ça demande un petit temps d'adaptation quand on quitte les géants du secteur, mais le gain en sérénité est immédiat. Plus besoin de se demander si votre prochain message va finir dans une base de données publicitaire.
Sachez aussi que le projet est entièrement financé par sa communauté, ce qui garantit une certaine indépendance vis-à-vis des trackers habituels. Bref, si vous cherchez à reprendre le contrôle sur ce que vous saisissez, c'est clairement une alternative à tester d'urgence sur votre smartphone.
Brice, un lecteur de Korben, m'a bel et bien scotché. Il y a quelques semaines, je vous parlais du
Pineapple Pager
et ça a visiblement réveillé une fibre nostalgique chez certains d'entre vous. Donc merci à Brice pour l'info, car il a carrément passé sa soirée à coder un truc énoooOOOooorme (et super utile) qui s'appelle MonitorBox.
Parce qu'on va pas se mentir, on croule tous sous les notifications. Entre Slack, les emails, et les alertes de sécurité, notre cerveau a fini par développer un mécanisme de défense radical : il ignore TOUT !!! C'est ce qu'on appelle la "fatigue de l'alerte". J'avoue que pour un admin sys en astreinte, c'est le début de la fin. Le jour où le serveur de prod tombe vraiment, on swipe la notif comme si c'était une pub pour des croquettes bio... Pas terrible donc pour la continuité de service.
L'interface de MonitorBox - sobre mais efficace (
Source
)
Et c'est là que Brice intervient justement avec son idée de génie : Ressusciter le bon vieux pager des années 90. Au début je pensais que c'était juste pour le fun (un délire de vieux geek quoi), mais en réalité c'est un vrai outil de surveillance pro.
MonitorBox est conçu pour tourner sur un vieux PC recyclé (genre un vieux Dell Optiplex GX270 ou un ThinkPad T60) sous Debian 12 Bookworm et l'idée, c'est de sortir l'alerte critique du flux continu de votre smartphone pour l'envoyer sur un appareil qui ne sert qu'à ça. Ainsi, quand le beeper à votre ceinture se met à gueuler sur la fréquence 466.975 MHz, vous savez que la maison brûle, sans même regarder l'écran.
Et techniquement, c'est hyper propre !!! Le système utilise une vue Terminal (parfaite pour un vieil écran CRT qui traîne) et un dashboard web moderne sous JavaScript pour le suivi. L'arme secrète reste ensuite le support du protocole POCSAG.
Via le port série (type /dev/ttyS0 ou un adaptateur FTDI), MonitorBox pilote un émetteur radio qui se charge de balancer les infos sur les ondes. Et toudoum, voilà comment votre vieux Tatoo ou Tam-Tam reprend du service !
⚠️ Attention quand même, émettre sur des fréquences radio est ultra-réglementé. Vérifiez donc bien la législation avant de jouer les apprentis sorciers, car pas moyen de plaider l'ignorance si les mecs de l'ANFR débarquent chez vous avec leur camionnette de détection Agence Tous Risques...
J'adore perso son approche qui vise le "Zéro faux positif". En effet, le script s'appuie sur Shell, curl et espeak pour la synthèse vocale locale, et intègre une logique de "Retry" comme ça si un service ne répond pas, l'outil vérifie à nouveau avant de vous réveiller en pleine nuit. Ça réduit drastiquement les fausses alertes, contrairement aux outils de
monitoring
habituels qui hurlent parfois au loup pour une micro-latence passagère de rien du tout.
MonitorBox est léger (pas besoin de base de données SQL compliquée, juste un fichier servers.conf), souverain, et permet de redonner vie à du matos qu'on croyait bon pour la déchetterie.
Brice nous propose en gros un mix parfait entre low-tech et haute performance. Et si vous voulez tester le bousin, tout le code est open source (licence MIT) et
disponible sur GitHub
. Seul petit bémol, il vous faudra bel et bien un vrai câble DB9 ou DB25 et un adaptateur qui tient la route, sinon votre VM va juste vous envoyer bouler violemment. Aaaah ces drivers USB chinois, je vous jure...
Bref, merci Brice pour l'inspiration et pour ce beau projet à la fois rétro et moderne !
De quoi des paramètres relèvent-ils juridiquement parlant ? À l’instar des poids, ils ne sont en tout cas ni des logiciels, ni du code source, ni des données.
L’OSI (Open Source Initiative) a étudié cet aspect dans le cadre de ses travaux sur l’intelligence artificielle. Elle avait amorcé un grand tour d’horizon du sujet à l’été 2022. Avec une question centrale : qu’est-ce que l’IA open source ? Ou, sous un autre angle : dans quelle mesure la définition de l’open source (OSD, Open Source Definition) peut-elle s’appliquer à l’IA, tant cette dernière estompe la frontière entre code et données ?
Avec la perspective du règlement européen sur l’intelligence artificielle, la réflexion s’était accélérée. Jusqu’à la publication, le 28 octobre 2024, d’une définition de l’IA open source.
La qualification juridique des paramètres n’y est pas abordée. L’OSI précise toutefois, en annexe, qu’ils peuvent être libres par nature, ou rendus libres par le biais d’une licence ou d’un autre instrument légal.
Trop d’incertitude juridique pour demander d’ouvrir toutes les données
Entre autres débats, il y eut celui sur les données d’entraînement : lesquelles faut-il mettre à disposition pour entrer dans les clous de l’IA open source ?
Certains promeuvent un accès sans contraintes au nom de la reproductibilité, de la transparence et de la sécurité.
L’OSI n’en a pas décidé ainsi. Son argument : une telle approche ferait de l’IA open source une niche, vu l’éventail de cas où le partage de tout le dataset est illégal ou techniquement impossible.
En la matière, l’un des obstacles s’appelle le copyright… dont l’OSI s’est d’ailleurs fixé l’objectif de limiter l’extension. Elle estime qu’il est en tout cas nécessaire de le mettre en balance avec les besoins de la société. Dans cette optique, elle s’est prononcée en faveur, sinon de l’ouverture des données, au moins de la notion d’usage raisonnable. Son président exécutif est allé jusqu’à suggérer de faire sans la notion de copyright pour ce qui est des modèles d’IA. Son postulat : entre vie privée, protection des consommateurs et respect des droits humains, la protection des jeux de données est déjà bien encadrée.
Beaucoup de savoirs autochtones sont protégés par des mécanismes non compatibles avec des cadres ultérieurs régissant l’exclusivité et le partage de droits, ajoute l’OSI. Il existe de surcroît des cas où les conditions d’utilisation de données publiques peuvent apporter à une entité A l’assurance de les exploiter librement, sans pour autant lui permettre de procurer les mêmes garanties à une entité B. Les notions de fair use et de domaine public en sont des illustrations, tant leurs définitions diffèrent entre les pays.
Les éléments à fournir pour être dans les clous de l’IA open source
Dans ce contexte, l’OSI a choisi d’exiger la fourniture d’« informations sur les données ». Impérativement suffisantes pour qu’une personne compétente puisse recréer un système « substantiellement équivalent ».
Les infos en question doivent couvrir :
Le périmètre et les caractéristiques des données d’entraînement
Leur origine (y compris les processus d’obtention et de sélection)
Les procédures d’annotation, de traitement et de filtrage
Des éléments supplémentaires peuvent être exigés en fonction du dataset. En l’occurrence, la liste des données publiques exploitées et/ou de celles obtenues auprès de tierces parties. Avec, dans l’un et l’autre cas, des informations sur la provenance et les conditions d’accès.
Côté code, il faut procurer celui utilisé pour le prétraitement des données, l’entraînement/validation/test et l’inférence. Ainsi que les outils et bibliothèques sous-jacents. On y ajoutera les poids du modèle et autres paramètres de configuration (par exemple, des checkpoints-clés et l’état final de l’optimiseur ; métadonnées de modèle et échantillons de sorties sont facultatifs).
Obligatoire
Facultatif
Données
Informations sur les données
Article de recherche
Rapport technique Data card
Évaluation (+ résultats)
Code
Prétraitement
Entraînement
Validation
Test
Bibliothèques / outils
Inférence lors des benchmarks
Évaluation
Modèle
Architecture
Paramètres
Carte
Outputs
Métadonnées
Le code, plus important que les données ?
D’après l’OSI, cette approche conserve celle de l’OSD. Laquelle n’impose pas une reproductibilité et une transparence totales, mais les permet (builds reproductibles). De plus, on peut toujours formuler davantage d’exigences, comme le Digital Public Goods Standards et les Recommandations GNU pour les distributions systèmes libres le font vis-à-vis de l’OSD.
Au final, l’utilisateur aurait les mêmes possibilités qu’avec des licences permissives. Tout du moins au sens où il pourrait conserver les insights obtenus à partir du code et de la description des données d’entraînement non partageables, puis construire sur cette base en y associant ses propres données non partageables et en rendant disponibles les insights obtenus en continuant l’entraînement.
Plus globalement, nous assure-t-on, le code d’entraînement et de traitement des données apparaît plus important que le dataset dans l’optique d’une modification libre.
En miroir à l’OSD, un système d’IA open source doit garantir quatre libertés :
Utilisation à toutes fins sans avoir à demander d’autorisation
Étude de son fonctionnement et inspection de ses composantes
Modification à toutes fins, y compris des sorties
Redistribution sans restriction d’utilisation
L’OSI recense pour le moment 5 modèles conformes : Amber et CrystalCoder (LLM360), OLMo (AI2), Pythia (EleutherAI) et T5 (Google). D’autres le seraient probablement s’ils modifiaient leurs conditions de licence, ajoute-t-elle. Parmi eux, BLOOM (BigScience), Falcom (TII) et Starcoder2 (BigCode).
Une centaine d’organisations ont adhéré à la définition de l’IA open source. Côté français, il y a l’APELL, le CNLL, Linagora, Probabl.AI, Sopra Steria et code.gouv.fr.
Une alternative open source à NextCloud développée en Go. Pour l'avoir vu fonctionner sur un NAS (relativement costaud tout de même), c'est très fluide.
Ce tutoriel explique comment installer FossFLOW en local (self-hosted) pour créer des diagrammes isométriques 3D directement dans votre navigateur Web.
La Commission européenne a lancé un appel à commentaires pour une nouvelle initiative stratégique intitulée « Vers des écosystèmes numériques ouverts européens », dont l’adoption est prévue au premier trimestre 2026. Motivée par les objectifs essentiels de souveraineté technologique et de cybersécurité, cette initiative vise à réduire la dépendance de l’Union européenne vis-à-vis des infrastructures numériques non européennes en renforçant le secteur open source européen. S’appuyant sur la stratégie 2020-2023 en matière de logiciels open source et complétant la future loi sur le développement du cloud et de l’IA, cette feuille de route vise à identifier les obstacles à l’adoption, à soutenir le développement des communautés et des start-ups open source, et à garantir que les technologies ouvertes dans des secteurs critiques tels que l’IA, le cloud et les applications industrielles soient développées et régies dans un cadre européen sûr, compétitif et transparent.
L’appel à commentaires suscite un certain enthousiasme de la communauté Open Source, avec 334 réponses moins d’une semaine après son ouverture. Cf. ces statistiques.
Continuez la lecture pour le détail des questions posées, quelques éléments de contexte et quelques éléments de réponses possible.
On peut identifier dans l’appel à commentaires une dizaine de questions, divisées en questions explicites (posées spécifiquement aux parties prenantes dans la consultation) et questions implicites (les problèmes sous-jacents que l’initiative cherche à résoudre).
Questions explicites
Ces questions sont répertoriées directement aux pages 3 et 4 afin que les parties prenantes puissent y répondre :
Forces, faiblesses et obstacles : « Quelles sont les forces et les faiblesses du secteur open source de l’UE ? Quels sont les principaux obstacles qui entravent (i) l’adoption et la maintenance d’un open source de haute qualité et sécurisé ; et (ii) les contributions durables aux communautés open source ? »
Valeur ajoutée : « Quelle est la valeur ajoutée de l’open source pour les secteurs public et privé ? Veuillez fournir des exemples concrets, y compris les facteurs (tels que le coût, le risque, la dépendance, la sécurité, l’innovation, entre autres) qui sont les plus importants pour évaluer la valeur ajoutée. »
Mesures concrètes de l’UE : « Quelles mesures et actions concrètes peuvent être prises au niveau de l’UE pour soutenir le développement et la croissance du secteur open source de l’UE et contribuer à la souveraineté technologique et au programme de cybersécurité de l’UE ? »
Priorités : « Quels domaines technologiques devraient être prioritaires et pourquoi ? »
Compétitivité et résilience : « Dans quels secteurs une utilisation accrue de l’open source pourrait-elle conduire à une compétitivité et une cyber-résilience accrues ? »
Questions implicites
Voici les questions fondamentales qui motivent la nécessité de cette initiative pour la Commission, que l’on retrouve tout au long du contexte politique et de la définition du problème (pages 1-2) :
Souveraineté : Comment l’UE peut-elle réduire sa dépendance vis-à-vis des pays tiers en matière d’infrastructures numériques et reprendre le contrôle de sa sphère numérique ?
Passage à l’échelle : Comment l’UE peut-elle aller au-delà du financement de la recherche et de l’innovation pour soutenir réellement le passage à l’échelle, le déploiement industriel et la viabilité commerciale des innovations open source ?
Administration publique : Comment le secteur public (États membres et régions de l’UE) peut-il mieux adopter les solutions open source afin d’éviter la dépendance vis-à-vis d’un fournisseur et d’accroître la transparence ?
Durabilité : Comment l’UE peut-elle garantir que la valeur générée par les projets open source n’est pas uniquement exploitée en dehors de l’UE et que les développeurs européens ont accès au capital et aux infrastructures nécessaires à leur croissance ?
Sécurité : Comment tirer parti des logiciels open source pour améliorer la transparence de la chaîne d’approvisionnement et la gestion des vulnérabilités en matière de cybersécurité ?
Bilan de la Stratégie Open Source 2020-2023 de la Commission européenne
Comme indiqué en intro, cette consultation a pour but (entre autres) de réviser la Stratégie Open Source 2020-2023 de la Commission européenne. Voici une analyse rapide de son bilan.
Cette stratégie se définissait par son slogan "Think Open". Le point clef, qu’on lui a reproché à son époque, est qu’elle était principalement une stratégie de transformation interne et culturelle (comment la Commission gère son informatique), plutôt qu’une stratégie de politique industrielle (comment l’Europe construit sa filière).
1. Forces, faiblesses et barrières
Analyse de la stratégie 2020-2023 : La stratégie identifiait correctement la force de l’Open Source comme levier d’innovation et de co-création.
Limite/Impact : Elle s’est concentrée sur les barrières administratives internes (simplifier la bureaucratie pour permettre aux fonctionnaires de contribuer au code). Elle a largement ignoré les barrières de marché (financement, concurrence déloyale des géants US) qui pèsent sur le secteur privé européen.
Bilan : Elle a réussi à lever des blocages juridiques internes, mais n’a eu que peu d’impact sur la fragmentation du marché européen.
2. Valeur ajoutée pour les secteurs public et privé
Analyse de la stratégie 2020-2023 : Elle a parfaitement théorisé la valeur ajoutée pour le secteur public : « Argent public, Code public », éviter le verrouillage propriétaire (vendor lock-in), et l’interopérabilité.
Limite/Impact : La stratégie visait à « montrer l’exemple » (lead by example). Cependant, l’impact réel sur le secteur privé est resté marginal, car la Commission a continué, paradoxalement, à dépendre massivement de solutions propriétaires (Microsoft 365) durant cette période, affaiblissant la portée de son message sur la valeur ajoutée de l’Open Source.
3. Mesures concrètes au niveau de l’UE
Analyse de la stratégie 2020-2023 : La mesure phare et le grand succès de cette stratégie a été la création du bureau de programme Open Source (OSPO) de la Commission ("OSOR"). Elle a aussi facilité la publication de logiciels comme EUSurvey ou LEOS.
Limite/Impact : Ces mesures étaient centrées sur l’institution (« Inner Source »). Il manquait des mesures de soutien financier direct à l’écosystème (type « Fonds Souverain ») qui sont demandées aujourd’hui.
4. Priorités technologiques
Analyse de la stratégie 2020-2023 : La stratégie mentionnait le Cloud, l’IA et la Blockchain de manière générique.
Limite/Impact : Elle manquait de ciblage stratégique. Elle traitait l’Open Source comme une méthode de travail, et non comme une brique de souveraineté pour des technologies critiques spécifiques (comme le demande aujourd’hui la Feuille de route sur le Cloud/Edge).
5. Compétitivité et résilience
Analyse de la stratégie 2020-2023 : Le document mentionnait la « souveraineté technologique » en introduction, citant Ursula von der Leyen.
Limite/Impact : L’approche est restée très « soft power » (influence par l’exemple). Elle n’a pas suffi à créer une résilience face aux chocs géopolitiques ou à l’extraterritorialité du droit américain (Cloud Act), car elle ne s’accompagnait pas d’une politique industrielle agressive.
6. Souveraineté (réduire la dépendance)
Bilan 2020-2023 : La stratégie posait le principe « Stay in control » (Garder le contrôle).
Réalité : C’est sans doute l’échec principal de la période. Malgré la stratégie, la dépendance de l’Europe aux hyperscalers non-européens s’est accrue (cf Asteres). La stratégie a sous-estimé la difficulté de migrer des infrastructures critiques vers de l’Open Source sans investissement massif dans des alternatives industrielles européennes.
7. Passage à l’échelle (upscaling)
Bilan 2020-2023 : La stratégie encourageait le partage et la réutilisation (Reuse).
Réalité : Le passage à l’échelle a été limité à des outils de niche (sondages, légistique). La stratégie n’a pas fourni les mécanismes pour transformer des projets Open Source européens en géants technologiques capables de rivaliser mondialement.
Réalité : La création de l’OSPO a été un modèle positif suivi par certains États membres (ex: France - avec les limites que l’on sait, Allemagne, Pays-Bas…). Cependant, l’adoption reste très hétérogène. La stratégie manquait de “dents” (obligations contraignantes) pour forcer l’adoption des logiciels libres et des standards ouverts dans les marchés publics des États membres.
9. Durabilité (modèles économiques et maintenance)
Bilan 2020-2023 : La stratégie prévoyait que les développeurs de la Commission puissent contribuer “incidemment” aux projets externes.
Réalité : C’est une réponse insuffisante au problème de la maintenance des infrastructures critiques (le problème de « l’inconnu du Nebraska »). Le bénévolat ou les contributions ponctuelles de fonctionnaires ne remplacent pas un financement structurel des fondations et des mainteneurs, point soulevé par les experts (Doc 3).
10. Sécurité (supply chain)
Bilan 2020-2023 : Point fort de la stratégie via le programme EU-FOSSA (audits de sécurité financés par l’UE).
Réalité : La Commission a bien identifié que « Open Source = transparence = sécurité potentielle ». Cependant, l’approche était réactive (audit de l’existant). La nouvelle période (2024+) doit gérer les effets de bord du Cyber Resilience Act (CRA), qui a créé une insécurité juridique pour les développeurs Open Source que la stratégie 2020-2023 n’avait pas anticipée.
Conclusion de l’analyse
La stratégie 2020-2023 a été une étape culturelle nécessaire mais insuffisante.
Son mérite : Elle a légitimé l’Open Source au cœur de l’administration européenne (création de l’OSPO, changement de mentalité).
Sa limite : Elle est restée une stratégie informatique interne (« Comment la Commission utilise le logiciel libre ») et non une stratégie politique (« Comment l’Europe utilise le logiciel libre pour sa souveraineté »).
Nous appelons donc à ce que la nouvelle initiative (2026) opère ce basculement : passer de l’Open Source comme « bonne pratique administrative » à l’Open Source comme « arme de souveraineté industrielle ».
1. Forces, faiblesses et obstacles du secteur open source de l’UE
Forces :
Engagement politique et financier : l’Europe a démontré son engagement à travers le financement de la recherche (Horizon Europe, Digital Europe) et des cadres politiques (Data Act) qui favorisent la transparence (*p. 16-17).
Écosystème en pleine croissance : on observe une expansion des fournisseurs européens de cloud et d’edge open source proposant des alternatives conformes au RGPD, ainsi que de grands consortiums multipartites (bien qu’ils soient confrontés à des défis) et des collaborations avec des instituts de recherche (p. 18-19).
Cadres spécialisés : L’Europe assiste à l’adoption croissante de cadres open source spécialisés dans l’IoT dans des secteurs tels que l’industrie manufacturière et l’énergie (p. 19).
Faiblesses :
Domination des technologies non européennes : le marché est fortement influencé par les technologies propriétaires et les hyperscalers non européens, en particulier dans les domaines du cloud, de l’edge computing et des technologies de conteneurisation (p. 20).
Fragmentation : Les initiatives nationales sont souvent fragmentées et manquent de coordination au niveau européen (p. 17).
Problèmes de gouvernance : De nombreux projets, même ceux qui bénéficient de contributions européennes, sont gérés par des entités non européennes (par exemple, la Linux Foundation), ce qui peut entraîner un décalage par rapport aux intérêts européens (p. 26).
Principaux obstacles :
(i) À l’adoption et à la maintenance :
Obstacles à l’interopérabilité : Il existe un manque de « normes véritablement ouvertes » universellement adoptées et développées par des entités européennes. Cela entraîne une complexité d’intégration et des frictions entre les outils propriétaires et les outils open source (p. 24).
Sensibilisation du marché et discours : les PME et les entreprises hésitent en raison d’idées fausses sur la complexité et le soutien, souvent alimentées par les discours marketing des fournisseurs dominants non européens (p. 25).
Pénurie de compétences : l’offre de professionnels maîtrisant les technologies open source européennes, l’orchestration du cloud et la cybersécurité est insuffisante (p. 25-26).
(ii) Vers des contributions durables :
Contraintes en matière de ressources et de financement : De nombreux projets essentiels dépendent de contributions bénévoles et de financements sporadiques. Le paysage actuel favorise souvent les grands projets bien établis, laissant les petites initiatives européennes innovantes sous-financées (p. 24-25).
2. Valeur ajoutée pour les secteurs public et privé
Le document identifie la valeur ajoutée dans plusieurs dimensions, en se concentrant principalement sur la souveraineté numérique, la sécurité, la résilience économique et la durabilité.
Exemples concrets et facteurs :
Administration publique :
Souveraineté et contrôle : l’adoption de l’open source européen permet aux institutions de garder le contrôle sur le traitement et le stockage des données, réduisant ainsi leur dépendance vis-à-vis de fournisseurs étrangers soumis à des lois extraterritoriales (par exemple, la section 702 de la loi américaine FISA).
Sécurité et conformité : la transparence totale du code permet un audit rigoureux, garantissant la conformité avec les directives RGPD et NIS.
Coût et transparence : cela réduit les coûts d’approvisionnement/de licence et favorise la confiance du public grâce à des systèmes transparents (p. 50).
Secteur privé (général et PME) :
Innovation : cela réduit les barrières à l’entrée pour les PME, leur permettant d’être compétitives en tirant parti d’une infrastructure abordable et personnalisable. Cela accélère les cycles de développement grâce à l’innovation collaborative (p. 13).
Réduction des risques : cela évite la dépendance vis-à-vis d’un fournisseur associée aux normes propriétaires (p. 11).
Fabrication (industrie 4.0) :
Efficacité opérationnelle : permet une maintenance prédictive et une surveillance en temps réel.
Flexibilité : les normes ouvertes permettent l’intégration transparente de nouvelles technologies dans les systèmes existants, évitant ainsi la dépendance (p. 51).
3. Mesures et actions concrètes au niveau de l’UE
La feuille de route propose des actions (70 au total) réparties en cinq piliers afin de soutenir le secteur et de contribuer à la souveraineté et à la cybersécurité, notamment :
1. Développement technologique :
Normes : définir et imposer une « interopérabilité exécutoire » basée sur des normes véritablement ouvertes pour toutes les infrastructures numériques financées par l’UE (p. 28-29).
Financement : créer un « Fonds européen pour la souveraineté open source » (NB : EOSSF → EU-STF) pour les projets fondamentaux (p. 30).
Architectures de référence : développer des implémentations de référence spécifiques à chaque secteur (par exemple, pour les soins de santé ou l’énergie) (p. 30-31).
2. Développement des compétences :
Formation et certification : Lancer des programmes de certification pour la maîtrise de l’open source européen et financer des ateliers de formation axés sur l’industrie (p. 32-33).
Éducation : Intégrer les principes de l’open source dans les programmes d’études STEM et créer des centres d’excellence dans les universités (p. 34).
3. Pratiques d’approvisionnement :
Politique : Adopter des politiques « Fonds publics, code public, open source d’abord, préférence européenne » (p. 36).
Lignes directrices : Créer des guides d’évaluation pratiques et un répertoire de solutions européennes recommandées à l’intention des responsables des marchés publics (p. 37-38).
4. Croissance et investissement :
Plateforme d’investissement : créer une « plateforme européenne d’investissement dans l’open source » (EOSIP) afin de consolider les informations sur le financement (p. 41).
Image de marque : lancer une initiative de promotion de l’image de marque afin de mettre en avant la sécurité et la souveraineté des projets européens (p. 43).
5. Gouvernance :
Analyse de sécurité : donner la priorité aux évaluations de vulnérabilité pour les projets critiques et collaborer avec les agences de cybersécurité (p. 45).
Comité consultatif : former un comité consultatif européen sur l’open source afin de superviser le financement et l’orientation (p. 47).
4. Domaines technologiques prioritaires
La feuille de route donne explicitement la priorité aux technologies Cloud, Edge et Internet des objets (IoT).
Pourquoi ces technologies sont-elles prioritaires ?
Épine dorsale de l’infrastructure : ces technologies constituent « l’épine dorsale de l’infrastructure numérique moderne » et sont essentielles pour la sécurité nationale et économique (p. 10).
Dépendance actuelle : l’Europe est fortement dépendante des hyperscalers non européens dans ces domaines, ce qui pose des risques en matière de confidentialité des données, de sécurité nationale et de résilience opérationnelle (p. 10).
Tendances émergentes : certains sous-domaines sont mis en avant comme étant essentiels pour la souveraineté future :
Edge Computing : essentiel pour réduire la latence et assurer la souveraineté des données (en gardant le traitement proche de la source) (p. 20).
Conteneurisation/Orchestration : critiques pour l’évolutivité, mais actuellement dominées par des entités non européennes (p. 20).
IA/apprentissage automatique : l’intégration de l’IA dans les appareils périphériques, pour l’IoT industriel et les systèmes autonomes (p. 20).
NB: d’autres domaines prioritaires peuvent également être mis en avant, en dehors de la feuille de route, notamment le collaboratif (bureautique).
5. Secteurs pour une compétitivité et une cyber-résilience accrues
Le document identifie les secteurs suivants dans lesquels l’open source peut stimuler la compétitivité et la résilience (p. 50-53) :
Administration publique : renforce la confiance, la souveraineté des données et réduit les coûts.
Fabrication (industrie 4.0) : améliore l’efficacité de la production, réduit les déchets et empêche la dépendance vis-à-vis d’un fournisseur.
Santé : sécurise les données sensibles des patients, permet l’interopérabilité entre les systèmes (par exemple, les dossiers médicaux électroniques) et accélère la recherche médicale.
Énergie : optimise la gestion de l’énergie (réseaux intelligents), intègre les énergies renouvelables et réduit la consommation énergétique des centres de données.
Autres secteurs : transports, agriculture, finance, éducation, villes intelligentes et industrie spatiale (en particulier l’analyse des données d’observation de la Terre) (p. 53).
Aujourd’hui, je vous propose de découvrir Pimmich, un cadre photo connecté open source basé sur Raspberry Pi, pensé pour afficher vos souvenirs sans cloud ni abonnement, en restant 100% local. Avec les récents changements côté Google Photos, beaucoup d’entre vous ont dû revoir leurs habitudes… et Aurélien a eu le bon réflexe : s’appuyer sur […]
Découvrez comment installer n8n facilement : méthodes d'installation, comparatif des hébergeurs (Hostinger, HostMyServers), configuration et cas d'usage concrets pour automatiser vos workflows.
Découvrez comment installer n8n facilement : méthodes d'installation, comparatif des hébergeurs (Hostinger, HostMyServers), configuration et cas d'usage concrets pour automatiser vos workflows.
À l'occasion du sommet franco-allemand sur la souveraineté numérique européenne, le Conseil National du Logiciel Libre (CNLL), co-signataire, avec plus d'une centaine d'organisations et de personnalités, de la lettre ouverte initiée par son partenaire européen l'APELL, appelle les dirigeants français et allemands à dépasser les déclarations de principe pour adopter une véritable politique industrielle numérique. Face à une vulnérabilité stratégique qui nous coûte plus de 265 milliards d'euros par an et nous expose aux lois extraterritoriales de puissances étrangères, l'heure n'est plus au diagnostic mais à l'action décisive.
Les nouvelles les plus récentes sur LinuxFR concernant PrestaShop remontent à bientôt trois ans, une éternité dans le monde de l’édition de solutions web.
Pour rappel, PrestaShop est un système de gestion de contenu (CMS) libre français de commerce en ligne, développé en PHP et placé sous licence OSL v3.
En cette fin d’année 2025, regardons quelles sont les nouveautés des douze mois écoulés.
(Déclaration d’intérêts : je suis salarié PrestaShop SA)
Après plus de deux ans de développement et de collaboration avec la communauté, cette version majeure apporte son lot de nouveautés, principalement sous le capot. Avec, entre autres, le passage à Symfony 6.4 (version LTS), la compatibilité avec PHP 8.4 ou encore une toute nouvelle API d’administration.
Juillet et août : appel aux contributions externes
Le projet PrestaShop, depuis sa genèse, est open source et ouvert à toute forme de contribution : développement, rapport de bugs, traductions, écriture de documentation, etc.
Au quotidien, ce projet est également soutenu par l’entreprise PrestaShop SA.
Durant cette année, cette dernière a souhaité améliorer le suivi des contributions externes. C’est pourquoi il a été décidé de proposer à la communauté deux thématiques ciblées : les hooks (billet en anglais) et l’API Admin (billet en anglais) .
Il y a quelques semaines, un point d’étape concernant les contributions sur l’API Admin a été publié sur le blog du projet (en anglais).
4 septembre : sortie de PrestaShop 8.2.3
Depuis la publication de PrestaShop 9, la branche 8.2 est en support étendu, ce qui veut dire que seuls des correctifs de sécurité sont traités.
C’est pourquoi début septembre, la version 8.2.3 a vu le jour, suite la découverte d’une faille sur la page de réinitialisation du mot de passe.
L’écosystème PrestaShop, ce sont des dizaines de dépôts, des centaines de contributeurices et des milliers de tickets ouverts.
Il a été proposé de revoir la manière dont sont gérés les tickets, afin d’aider la communauté à mieux s’y retrouver.
C’est pourquoi il est maintenant possible d’ouvrir un ticket (pour déclarer un bug ou demander une nouvelle fonctionnalité) sur certains dépôts directement. Auparavant, tout était centralisé sur le projet PrestaShop directement et il était devenu très compliqué, pour les personnes en charge de traiter les plus de 2 300 tickets d’être efficaces.
Et voila, on ne touche plus à cette version, en cours de développement depuis plusieurs mois, et on entre dans une phase de « feature freeze » : plus aucune nouveauté ne sera ajoutée. C’est une période pour tester cette version importante qui apportera notamment un nouveau thème par défaut (Hummingbird), un système de création de promotions revu et amélioré et aussi la possibilité d’assigner plusieurs transporteurs sur une seule commande.
Vous souhaitez tester cette future version et aider la communauté à stabiliser tout cela, n’hésitez pas à lire cette page publiée récemment.
Et en 2026, quel programme ?
La procédure de livraison de PrestaShop 9.1 continuera son cours, avec la sortie de versions Release Candidate et bien sûr, une version finale. Pas de date à donner, c’est toujours plus sage d’être prudent.
Entamé depuis plusieurs années, le chantier de réécriture du backoffice poursuivra son cours, avec la migration vers Symfony.
En tout cas, l’année 2026 sera importante pour le projet et sa communauté, mais nous aurons le temps d’en reparler dans quelques semaines !
Connexion
