If Linux Hits 10%, Nobody Will Know What Linux Is Source Code Ep. 30

SYNTHÈSE STRUCTURÉE

Les chiffres de StatCounter : une reclassification, pas une migration

L’intervenant analyse le bond supposé de Linux de 5,52 % à 10,65 % en un mois sur le desktop nord-américain. Il souligne qu’une telle variation est physiquement impossible pour des centaines de millions de machines. La catégorie « unknown » de StatCounter, qui représentait 9,24 % du trafic desktop en juin, s’est dégonflée en juillet, et Linux a « miraculeusement » augmenté du même montant. Il cite aussi l’exemple de Windows 7 qui « ressuscite » à 9,61 % en septembre 2025 avant d’être corrigé à 1,62 %. « Nous célébrons un brouillon », conclut-il, rappelant que les données StatCounter restent révisables pendant 45 jours après publication.

Ce que mesure réellement StatCounter : des pages vues, pas des utilisateurs

Le point technique central : StatCounter compte des pages vues, et Cloudflare Radar compte des requêtes HTTP. Or, qui génère des requêtes HTTP automatisées ? Les serveurs, les conteneurs, les pipelines CI/CD, les navigateurs headless, les scrapers et, depuis deux ans, une quantité industrielle d’agents IA. Tout cela tourne massivement sous Linux. « Nous ne mesurons pas des desktop Linux. Nous mesurons l’infrastructure de l’internet qui se présente comme un desktop Linux. » L’intervenant estime que la part réelle du desktop Linux se situe « à peine au-dessus de 2 % », en étant optimiste.

Les données Steam : un bruit statistique, pas une tendance

Les chiffres Steam oscillent entre 3,69 % et 5,33 % en quatre mois. L’intervenant qualifie cette variation de « bruit », pas de part de marché. Il rappelle que l’enquête Steam est un échantillon auto-sélectionné (les utilisateurs doivent accepter de participer) au sein d’une population déjà auto-sélectionnée (les joueurs Steam actifs). Surtout, environ 22 % des systèmes Linux sur Steam sont des SteamOS Holo, c’est-à-dire des Steam Deck et Steam Machines : des consoles où l’utilisateur n’a jamais choisi Linux. « C’est arrivé dans une boîte. »

Les bénéfices réels d’une adoption à 20 %

L’intervenant construit honnêtement le meilleur argument pro-adoption. Quatre bénéfices concrets : les fabricants matériels arrêteraient de nous ignorer (pilotes Wi-Fi à la sortie, webcams fonctionnelles, lecteurs d’empreintes utiles) ; les logiciels professionnels suivraient (suites créatives, CAO, logiciels fiscaux) ; l’accessibilité progresserait enfin (lecteurs d’écran, contrôle vocal, technologies d’assistance) ; et les écoles ainsi que l’administration publique auraient une justification politique pour choisir Linux dans les appels d’offres. Il ajoute le moindre gaspillage électronique et le pouvoir de négociation sur les formats, standards et DRM.

Le Steam Deck : la preuve qu’une expérience grand public est possible

L’intervenant reconnaît que le Steam Deck a prouvé quelque chose qu’il n’aurait pas parié : Linux peut offrir une expérience consommateur soignée sans demander à l’utilisateur de comprendre quoi que ce soit de technique. « C’est un argument sérieux. Il n’est pas stupide. Il n’est pas naïf. » Mais c’est précisément ce point qui ouvre la porte aux dangers qu’il va détailler.

La standardisation inévitable : la question n’est pas « si » mais « qui »

Un produit de masse nécessite une cible unique. Un développeur qui veut atteindre 200 millions d’utilisateurs ne peut pas tester sur 40 distributions, six environnements de bureau, trois systèmes d’init, deux serveurs d’affichage et quatre formats de paquets. « Ce n’est pas de la paresse. C’est de l’arithmétique. » Le coût de support croît avec le produit de la variance, pas avec sa somme. La vraie question devient : qui définit la standardisation, et avec quel mandat ?

systemd : l’expérience qui prouve que le mécanisme fonctionne

L’intervenant cite systemd comme preuve historique : un composant conçu centralement, soutenu par une entreprise avec des ressources, techniquement défendable sur le papier, est passé d’optionnel à inévitable en moins de dix ans dans un écosystème qui se dit décentralisé. Pire : une fois la transition achevée, l’écosystème la rationalise et l’appelle « progrès ». « Celui qui se souvient comment c’était avant devient le nostalgique, le fondamentaliste, celui qui vit dans le passé. » Et tout cela s’est produit à 2 % de part de marché, sans pression commerciale sur le desktop. Que se passera-t-il quand l’enjeu sera 300 millions de machines, des contrats de pré-installation, des accords OEM et des stores avec commissions de 30 % ?

La GPL comme système immunitaire, et le précédent Android

La GPL n’est pas une préférence esthétique : c’est le seul mécanisme juridique qui empêche 30 ans de travail collectif d’être capturé, fermé et revendu comme produit. Le scénario réaliste n’est pas une entreprise maléfique qui rachète Linux et le ferme. C’est une dérive progressive : un composant sous licence permissive (BSD, MIT, Apache), puis un deuxième, puis un troisième. Le cas d’école existe déjà : Android. Noyau Linux sous GPL (obligatoire), espace utilisateur sous Apache 2.0. « Le manuel d’instructions existe déjà. Gardez la GPL là où vous y êtes forcés, construisez tout le reste sous licence permissive, puis fermez les morceaux qui génèrent des revenus. C’est légal. C’est efficace. Ça marche. »

Snap, Flatpak, AppImage : le déplacement de la frontière de confiance

Ces formats résolvent un problème réel : un développeur indépendant ne peut pas empaqueter pour 40 distributions. Mais structurellement, ils déplacent la frontière de confiance. Avant, entre le développeur et votre machine, il y avait un mainteneur de distribution : une personne avec un nom, une communauté, un bug tracker public, une réputation à défendre. « Ils étaient un filtre. Ils étaient un relecteur. Ils étaient en un sens un éditeur. » Maintenant, il y a un store géré par une entreprise avec un backend propriétaire. « Ce n’est pas un relecteur. C’est un réseau de diffusion de contenu. » Et les mises à jour automatiques ferment la boucle : un paquet de 3 Go qui se met à jour tout seul, que vous ne pouvez pas inspecter, ni différer, ni comparer, ni refuser sans lutter contre le système. « Cela n’a rien à voir avec l’open source. Rien. »

Les quatre piliers de l’open source, et la définition de la « connaissabilité »

L’intervenant insiste sur une définition précise : l’open source signifie quatre choses ensemble — accéder, lire, modifier, redistribuer. « Retirez un seul de ces quatre éléments et le mot devient une étiquette marketing. » Un binaire opaque signé qui se met à jour tout seul a techniquement du code source public quelque part, mais pratiquement, c’est une boîte noire. La distinction cruciale n’est pas entre interface graphique et terminal : « La distinction est entre une abstraction qui habilite et une abstraction qui dissimule. » Une abstraction qui habilite vous laisse descendre, voir ce qu’elle fait, soulever le capot. Une abstraction qui dissimule rend la couche sous-jacente inutile à comprendre, et donc après une génération, impossible à comprendre.

L’exemple du fichier de configuration vs la base de données opaque

Un fichier de configuration en texte clair : vous pouvez le lire, le commenter,