Né en novembre 2025, Clawd, un projet open source IA, a été renommé Moltbot sous la pression juridique de Anthropic (Claude), puis OpenClaw rapidement.

Nous passerons en revue dans cet article la chronologie des faits, les enjeux techniques, juridiques et éthiques, dans un monde open source, projet dont la diffusion a explosé pour bien des raisons…

Sommaire

• Chronologie
  • ClawdBot de novembre 2025 au 27 janvier 2026
  • MoltBot du 27 au 29 janvier 2026
  • OpenClaw depuis 30 janvier 2026
• OpenClaw
  • Description et définition
  • Installation
  • Fonctionnalités
  • Architecture
  • Licence
  • Dépendances
• Succès communautaire et médiatique
  • Dynamiques et amplifications
  • Métriques
• Aspects juridiques et légaux
  • Licences
  • Marques
  • Cadre réglementaire : RGPD et Cloud Act
• Sécurité et vie privée
  • Stockage et fuite
  • Authentification
  • Injection de prompts
  • Contrôle et privilèges
  • Durcissement et mitigation
• Impact et enjeux de l'IA
  • Court terme
  • Moyen terme
  • Long terme
• Prisme du logiciel et IA libre et open source
  • Ouverture
  • Gouvernance
  • Éthique
  • Souveraineté
  • Intelligence collective
  • Au-delà du code
  • Résilience et anti-fragilité
• Liens

Chronologie

ClawdBot de novembre 2025 au 27 janvier 2026

Le projet débute en novembre 2025 sous le nom de Clawdbot, lancé par l'ingénieur autrichien Peter Steinberger, développeur autrichien et fondateur de PSPDFKit. Ce prototype de « WhatsApp Relay » connecte l'IA aux applications de messagerie pour automatiser des tâches système. Le succès est immédiat avec 60 000 étoiles GitHub en seulement trois jours. Le nom fait initialement référence à l'outil Claude d'Anthropic. En outre, le nom et le logo évoquent le homard, symbole repris dans l’identité visuelle du projet.

ClawdBot connaît une adoption rapide dès sa publication sur GitHub. Le projet vise explicitement une alternative locale et contrôlée aux assistants IA centralisés.

MoltBot du 27 au 29 janvier 2026

Le 27 janvier 2026, la firme Anthropic demande un changement de nom pour éviter toute confusion avec sa marque « Claude ». Peter Steinberger rebaptise alors le projet Moltbot, évoquant la mue du crustacé. Ce changement intervient dans un contexte de couverture médiatique maximale. La transition est techniquement précipitée, et elle met en lumière les fragilités organisationnelles liées à une croissance trop rapide. On voit apparaître des clones, des faux dépôts et des tentatives d’escroquerie, par exemple le vol de comptes sociaux par des escrocs et le lancement d'un faux jeton de cryptomonnaie nommé $CLAWD.

OpenClaw depuis 30 janvier 2026

Le 30 janvier 2026, le projet adopte son identité définitive : OpenClaw. Une vérification juridique préalable est effectuée. Les domaines et identités associées sont sécurisés. Ce nouveau nom souligne l'ancrage dans le logiciel libre tout en conservant l'hommage au homard d'origine. La transition est cette fois sécurisée par des recherches de marques et le blocage des noms de domaines. Le projet se stabilise et dépasse rapidement les 124 000 étoiles GitHub.

La phase OpenClaw marque une stabilisation. Plusieurs correctifs de sécurité sont publiés. La gouvernance s’ouvre à de nouveaux mainteneurs issus de la communauté.

OpenClaw

Description et définition

OpenClaw est un assistant IA personnel appartenant à la catégorie des agents autonomes. Il est conçu pour être installé et s'exécuter sur la machine de l'utilisateur (auto-hébergé). Contrairement aux chatbots classiques, il peut prendre des décisions et effectuer des actions concrètes sur un système d'exploitation sans supervision humaine constante. Le logiciel agit comme une couche d’orchestration entre modèles IA et services locaux. Il vise un usage personnel ou organisationnel. L’autonomie fonctionnelle est au cœur de sa proposition de valeur.

Le site web décrit OpenClaw de cette manière :

OpenClaw
The AI that actually does things.
Clears your inbox, sends emails, manages your calendar, checks you in for flights.
All from WhatsApp, Telegram, or any chat app you already use.

Installation

L'installation se passe en ligne de commande : téléchargement, puis lancement de la procédure d'installation, choix du LLM, choix du chat, et voilà.

One-liner

# Works everywhere. Installs everything. You're welcome. 🦞
curl -fsSL https://openclaw.ai/install.sh | bash

npm

# Install OpenClaw
npm i -g openclaw
# Meet your lobster
openclaw onboard

Hackable

# For those who read source code for fun
curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method git

Fonctionnalités

L'agent exécute des commandes shell, lit et écrit des fichiers locaux, ou gère les courriels et agendas. Il peut piloter un navigateur web pour remplir des formulaires ou effectuer des recherches. Le système dispose d'une mémoire persistante lui permettant de conserver le contexte des conversations à long terme (context window). Il peut également initier des interactions de manière proactive via des notifications.

Architecture

Le logiciel repose sur Node.js et TypeScript. Son architecture est divisée en trois couches : une passerelle locale (Gateway), un agent qui gère le raisonnement (découpage et séquencement), et le moteur d'IA (LLM). Il utilise des protocoles WebSocket pour la communication bidirectionnelle entre ses composants. Les interactions s'effectuent via des applications tierces comme WhatsApp, Telegram, Slack ou Discord. Il connecte des modèles IA à des applications tierces. Le système est extensible via plugins. Plus de cinquante intégrations sont disponibles. L’architecture privilégie la modularité plutôt que l’intégration verticale.

Licence

OpenClaw est distribué sous la licence MIT. Cette licence permissive, reconnue par l’Open Source Initiative et la Free Software Foundation, autorise l'utilisation, la modification et la distribution du code, y compris à des fins commerciales. La seule obligation est d'incorporer la notice de licence et de copyright dans toutes les copies.

Dépendances

Le projet combine des briques libres et propriétaires. Les dépendances libres incluent Node.js, Puppeteer et Ollama pour l'exécution locale (inférence d'IA). En revanche, le fonctionnement optimal nécessite souvent des API propriétaires comme celles d'Anthropic (Claude) ou d'OpenAI (GPT). L'utilisation de ces services externes entraîne des coûts d'abonnement pour l'utilisateur, et l'envoi et éparpillement de données sur des clouds étrangers (pouvant être soumis aux lois extra-territoriales).

Succès communautaire et médiatique

Dynamiques et amplifications

Le projet a bénéficié d'un engouement lié au mouvement du « vibe coding » (développement assisté par IA). Des figures influentes comme Andrej Karpathy ont soutenu publiquement l'initiative.

Les réseaux sociaux et médias amplifient le phénomène. Des contributeurs rejoignent le dépôt en masse. Des usages spectaculaires sont massivement partagés. Une véritable sous-culture est née autour de l'achat de serveurs Mac mini dédiés pour faire tourner l'agent 24h/24. La mascotte du « homard spatial » devient un mème.

Métriques

La croissance a été l'une des plus rapides de l'histoire de l'open source:

• Le dépôt GitHub atteint une visibilité exceptionnelle avec plus de 100 000 étoiles GitHub en une semaine.
• Le projet a attiré plus de 2 millions de visiteurs en sept jours.
• La communauté a développé plus de 500 extensions ou « skills » partagées sur Clawhub.

Des milliers d’instances sont déployées en quelques semaines. Un réseau social Motlbook dédié aux agents autonomes sans humains est créé, et plus de 2 100 agents y sont recensés en 48 heures.

La popularité précède largement la maturité technique.

Aspects juridiques et légaux

Licences

La licence MIT ne pose pas de contrainte juridique majeure. Elle ne protège cependant ni le nom ni l’image du projet. L'utilisateur est responsable de l'installation et des conséquences de l'exécution de l'agent.

Cette licence n’encadre pas l’usage des modèles sous-jacents : bien que le code d'OpenClaw soit libre, les modèles d'IA qu'il appelle restent pour la plupart régis par les conditions d'utilisation strictes de leurs éditeurs respectifs. Cela limite l’indépendance réelle du projet. La licence du code ne garantit pas la liberté de l’ensemble de la chaîne.

Marques

La saga démontre la vigilance des entreprises face à la proximité phonétique des noms de projets. Anthropic a exercé son droit de marque pour protéger l'intégrité de son produit Claude. L’absence d’intention commerciale n’est pas déterminante. Peter Steinberger a dû consulter OpenAI avant le renommage final pour éviter de nouveaux conflits. Ce renommage illustre l’asymétrie entre acteurs : les projets libres restent vulnérables aux marques déposées.

Cadre réglementaire : RGPD et Cloud Act

Paradoxalement, l'auto-hébergement de la chaîne entière favorise la conformité au RGPD et la souveraineté, car les données restent sous le contrôle direct de l'utilisateur (responsable du traitement). Cela permet également d'éviter les risques du CLOUD Act américain en évitant le stockage et la transmission de données sur des serveurs étrangers. Toutefois, l'usage possible des services tiers et clouds publics de l'agent peut classer le système comme « à haut risque » selon l'AI Act européen, les données passant par des clouds soumis aux réglementations extra-territoriales.

Sécurité et vie privée

Stockage et fuite

L'architecture initiale stockait les clés d'API et l'historique des conversations en texte clair sur le disque. Des chercheurs ont identifié des milliers d'instances exposées sur Internet, divulguant des données sensibles. La concentration d'informations locales crée un point de défaillance unique (SPOF) en cas de compromission de la machine.

Authentification

Les premières versions ne requéraient pas d'authentification forte par défaut. Des interfaces d'administration étaient accessibles publiquement à cause de proxies/pare-feux mal configurés. Des correctifs récents ont supprimé les modes de connexion sans authentification pour durcir le système.

Injection de prompts

L'injection de prompts est la menace la plus critique et reste un problème non résolu dans l'industrie. Un attaquant peut insérer des instructions malveillantes dans un courriel ou un site web consulté par l'agent. L'IA peut alors exécuter des ordres indésirables, comme l'exfiltration de fichiers, en croyant obéir à son propriétaire.

Contrôle et privilèges

OpenClaw agit comme un super-utilisateur virtuel avec des accès profonds au système : l’agent dispose de privilèges élevés, il peut exécuter des commandes système, et il agit parfois avec des droits excessifs. Il combine l'accès aux données privées, l'exposition à des contenus non vérifiés et la capacité de communication externe. La séparation des privilèges est insuffisante par défaut, l’isolation reste complexe, et le risque augmente avec l’autonomie. Ce mélange de privilèges et autonomie transforme l'assistant en un vecteur d'attaque puissant s'il est détourné.

Durcissement et mitigation

Des correctifs ont été publiés après coup, nombre de commits concernent la sécurité, et la documentation actuelle reconnaît l’absence de configuration parfaite. La communauté recommande donc l'utilisation de conteneurs Docker pour isoler les sessions de l'agent. L'accès à distance doit être sécurisé par des tunnels comme Tailscale ou VPN. L'usage des droits « root » est désormais désactivé par défaut et nécessite une activation explicite (principe du moindre privilège).

Ces pratiques restent encore peu suivies, car difficiles à appliquer pour des non-experts, dans un contexte de déploiement rapide. La sécurité et la vie privée dépendent fortement du niveau technique de l’utilisateur, ne sont pas encore des acquis structurels.

Impact et enjeux de l'IA

Court terme

OpenClaw accélère la productivité en éliminant les tâches de manipulation de données entre applications, en automatisant et en autonomisant les processus via IA et agents. Cependant, il introduit un risque d'IA fantôme (Shadow AI) dans les entreprises où les employés déploient l'outil sans supervision de la direction informatique, ou d'alignement à une charte. La vitesse de diffusion a largement dépassé la maturité des mesures de sécurité initiales.

OpenClaw démocratise les agents autonomes : il rend accessibles rapidement et facilement des capacités jusque-là expérimentales, et il remet en cause d'une certaine manière le monopole des plateformes centralisées. Il expose aussi des utilisateurs non avertis à des risques élevés, la diffusion foudroyante dépasse la capacité de montée de connaissances. Le projet agit comme un révélateur.

Moyen terme

On peut amplement anticiper que le succès rapide du projet pourrait influencer la régulation et une standardisation des protocoles avancés d'agents, pour rendre ces assistants interchangeables. Le cadre réglementaire européen (voire mondial ?) obligera probablement à des certifications de sécurité plus strictes. Les grandes entreprises et organisations gouvernementales pourraient publier des versions sécurisées et certifiées du logiciel pour leurs besoins internes.

Ces nouveaux agents autonomes posent des questions inédites et à grande échelle. La sécurité pourrait devenir une obligation normative. Des outils d’audit spécialisés émergent, les pratiques de durcissement se structurent, OpenClaw sert de cas d’école.

Long terme

L'IA agentique pourrait redéfinir la souveraineté numérique en permettant à chacun de posséder son propre assistant local. Les agents autonomes pourraient devenir les principaux utilisateurs des systèmes numériques, rendant obsolètes certaines tâches manuelles de gestion. Cela transforme l’organisation du travail. L'enjeu éthique et social majeur sera l'imputabilité légale en cas de préjudice causé par une décision autonome de l'IA. La dépendance technologique augmente. La gouvernance devient centrale.

Prisme du logiciel et IA libre et open source

Ouverture

Le code source d'OpenClaw est totalement ouvert et auditable, respectant les critères du logiciel libre. Toutefois, l'ouverture est limitée par la dépendance aux modèles propriétaires dont les poids, les données et processus d'entraînement restent secrets et privateurs. Par exemple, le code ne contient à ce jour pas de télémétrie cachée. L’ouverture favorise l’innovation rapide par l'intelligence collective et l’appropriation communautaire, tout en facilitant bien évidemment les usages détournés.

Gouvernance

Le projet est passé d'une initiative solitaire à une gouvernance plus structurée intégrant plusieurs mainteneurs communautaires. Cette gestion collective ouverte renforce la résilience et l'anti-fragilité mais complexifie la coordination technique et sécuritaire. Les décisions critiques sont désormais partagées, et la sécurité est un enjeu majeur : la maturité dépendra de cette gouvernance.

Éthique

L'autonomie de l'IA pose des questions de responsabilité et met en évidence le risque d'erreurs invisibles ou noyées sans supervision humaine en temps réel et prise de décision sans humain. La frontière entre outil et acteur s’estompe. La transparence opérationnelle et l'auditabilité sont essentielles pour prévenir les usages malveillants tout en protégeant les données personnelles. L’éthique ne peut être entièrement déléguée aux modèles, elle dépend des choix d’architecture des développeurs et également dépend aussi des usages des utilisateurs.

Par conséquent, le fantasme d’une IA omniprésente inquiète et interroge sur la dépendance technologique. À long terme, on peut légitimement craindre que cette automatisation et autonomisation de tâches et processus à la complexité croissante prenne de l’ampleur. Ainsi la probabilité s’accroît de voir la remise en cause non seulement l'existence même de certains métiers, mais plus généralement de voir une dépendance de masse.

Souveraineté

L'auto-hébergement complet permet aux utilisateurs de rester maîtres de leur infrastructure et de leurs données. Cela réduit la dépendance envers les géants technologiques et évite le verrouillage propriétaire. Cela est à mettre en perspective avec l'utilisation des clouds publics et services centralisés, par exemple les modèles d'IA et messageries instantanées propriétaires et étrangers.

Intelligence collective

La force du projet réside dans son écosystème de compétences développées par des contributeurs du monde entier. Cette collaboration expérimentale et novatrice permet d'enrichir l'agent et l'écosystème. Nombre de failles ont pu être identifiées publiquement.

Au-delà du code

Une véritable IA open source devrait inclure les poids du modèle, les données d'entraînement et les processus d'apprentissage et de raffinement. OpenClaw est une infrastructure libre, mais n'est pas une « IA open source » au sens strict, en particulier lorsqu'il utilise des modèles fermés et opaques. Cette asymétrie limite l’auditabilité globale réelle. Elle interroge la notion d’IA libre et/ou open source

Résilience et anti-fragilité

Malgré son jeune âge, OpenClaw a déjà survécu à une crise majeure, et le projet s’étant restructuré, la communauté ayant absorbé le choc. Cette résilience dépendra de la capacité à réagir aux risques majeurs et à grande échelle, la sécurité devant précéder le succès. Le logiciel libre n’immunise pas contre les risques. L'architecture ouverte permet par exemple de basculer immédiatement vers d'autres modèles en cas de changement de politique d'un fournisseur d'API. Si le créateur abandonne le projet, la communauté peut forker le code pour assurer la pérennité de l'outil.

La saga OpenClaw renforce le débat sur la nécessité de surveiller et contrôler ces agents et de mettre garde-fous à tous niveaux.

Liens

• CNet : Clawdbot, Moltbot, OpenClaw? The Wild Ride of This Viral AI Agent. An AI tool that can text you and use your apps blew up online. One week and two rebrands later, the question remains: Should you actually use it?
• Cisco : Agents like OpenClaw Are a Security Nightmare
• Wired : Moltbot Is Taking Over Silicon Valley People are letting the viral AI assistant formerly known as Clawdbot run their lives, regardless of the privacy concerns.
• Vectra AI : Attack Surfaces : From Clawdbot to OpenClaw: When Automation Becomes a Digital Backdoor
• Fast Company : Clawdbot/Moltbot/OpenClaw is cool, but it gets pricey fast. Automating a few menial tasks with the viral AI hit would cost me about $30 per month.
• VentureBeat : OpenClaw proves agentic AI works. It also proves your security model doesn't. 180,000 developers just made that your problem.
• OpenClaw : Introducing OpenClaw. Two months ago, I hacked together a weekend project. What started as “WhatsApp Relay” now has over 100,000 GitHub stars and drew 2 millions visitors in a single week. Today, I’m excited to announce our new name: OpenClaw.
• Le Monde Informatique : Le phénomène Moltbot inquiète les experts en cybersécurité. Face à l'engouement de l'agent IA Moltbot auprès des développeurs, la communauté en cybersécurité s'inquiète sur la sécurité des données.
• Forbes : Moltbot Gets Another New Name, OpenClaw, And Triggers Security Fears And Scams
• Hacker News (YCombinator) : Ask HN: Any real OpenClaw (Clawd Bot/Molt Bot) users? What's your experience?.
• Ars Technica : Users flock to open source Moltbot for always-on AI, despite major risks. The open source “Jarvis” chats via WhatsApp but requires access to your files and accounts.
• The Verge : Moltbot, the AI agent that ‘actually does things,’ is tech’s new obsession. But giving an AI agent access to your account credentials and your entire computer system poses some risks, even if it runs on your desktop.

À l’occasion de la sortie de la version 25.10.1 de la suite Radeon Software for Linux du 21 mai 2025, AMD a annoncé que la série 25.10 est la dernière à livrer des composants logiciels propriétaires.

Ces composants propriétaires étaient déjà optionnels depuis bien longtemps, la plupart des utilisateurs de cartes AMD ne s’en servait déjà pas, et le plus grand nombre ignorait peut-être jusqu’à l’existence de certains d’entre eux…

Ce jalon est l’accomplissement de 18 années d’un travail acharné commencé en 2007 avec la publication de documentations des cartes graphiques ATI après le rachat par AMD… Les plus anciens se souviendront de RadeonHD… Et désormais, ce sont les derniers bouts de logiciel propriétaire qui sont poussés vers la sortie.

Nos logiciels libres sont plus sereins lorsqu’ils reposent sur des pilotes libres…

Sommaire

• L’offre complètement libre de pilotes graphiques AMD sous Linux
• RADV officiellement supporté
• Ce que support veut dire
• Le départ des derniers
• Adieu OGLP
• Adieu AMDVLK-Pro
• Adieu AMF
• Souvenir des pilotes AMD abandonnés sur le bord du chemin
• Mais… et les firmwares ?
• Préférer le DisplayPort à l’HDMI pour les très hautes définitions…
• Prochain objectif : l’universalité du calcul et de la virtualisation ?

L’offre complètement libre de pilotes graphiques AMD sous Linux

Voici comment se composera très bientôt l’offre officielle de pilotes graphiques AMD pour Linux :

Noyau	Vulkan	OpenGL	HIP	OpenCL
Linux amdgpu	AMD AMDVLK ou Mesa RADV	Mesa radeonsi	AMD ROCm	AMD ROCm

OpenGL et Vulkan sont des interfaces de programmation (API) graphiques, VA-API est une interface de programmation multimédia, et HIP et OpenCL sont des interfaces de programmation pour le calcul spécialement conçues pour satisfaire aux particularités architecturales des cartes graphiques.

Il est à noter que même si vous n’utilisez pas la suite Radeon Software for Linux, votre distribution vous fournit déjà le pilote Linux et les pilotes Mesa mentionnés.

• Pilote noyau
  • Linux amdgpu pour les cartes GCN1 et suivantes (pilote officiel).
• Pilote graphique Vulkan
  • AMD AMDVLK pour les cartes RDNA1 et suivantes (pilote officiel) ;
  • Mesa RADV, pour les cartes GCN1 et suivantes (pilote officiel).
• Pilote graphique OpenGL
  • Mesa RadeonSI pour les cartes GCN1 et suivantes (pilote officiel).
• Pilote multimédia VA-API
  • Mesa RadeonSI pour les cartes GCN1 et suivantes (pilote officiel).
• Pilote de calcul HIP
  • AMD ROCm pour une sélection de cartes RDNA2 et suivantes (pilote officiel),
    il n’existe pas d’autre implémentation de pilote HIP pour les autres cartes.
• Pilote de calcul OpenCL
  • AMD ROCm pour une sélection de cartes RDNA2 et suivantes (pilote officiel) ;
  • Mesa RustiCL pour les cartes GCN1 et suivantes.

Ces pilotes concernent donc les cartes GCN et RDNA. La famille de cartes GCN pour « Graphics Core Next » sont les cartes sorties à partir de la série HD 7000 en 2012, aussi nommées « Southern Islands » et qui ont inspiré le nom du pilote RadeonSI. La famille RDNA pour « Radeon DNA » (ADN Radeon) est une évolution de cette micro-architecture GCN et les cartes RDNA1 commencent avec les modèles RX 5000 en 2019 et les cartes RDNA2 avec les modèles RX 6000 en 2020.

Le tableau suivant se limite aux générations de cartes graphiques pour lesquelles il existe au moins un pilote fonctionnel faisant partie de la suite officielle Radeon Software for Linux. Il s’agit donc seulement de compatibilité technique. Les générations et modèles officiellement pris en charge par le support commercial d’AMD est évidemment plus restreint, et plus fluctuant, et puis ça dépend de l’API… La compatibilité technique effective intéressera probablement plus le lecteur.

				GCN1	GCN2	GCN3	GCN4	GCN5	RDNA1	RDNA2	RDNA3
Noyau	Linux amdgpu	⭐️	🐧️	✅️	✅️	✅️	✅️	✅️	✅️	✅️	✅️
Vulkan	AMD AMDVLK	⭐️		❌️	❌️	❌️	❌️	❌️	✅️	✅️	✅️
Vulkan	Mesa RADV	⭐️	🐧️	✅️	✅️	✅️	✅️	✅️	✅️	✅️	✅️
OpenGL	Mesa RadeonSI	⭐️	🐧️	✅️	✅️	✅️	✅️	✅️	✅️	✅️	✅️
VA-API	Mesa RadeonSI	⭐️	🐧️	✅️	✅️	✅️	✅️	✅️	✅️	✅️	✅️
HIP	AMD ROCm	⭐️		❌️	❌️	❌️	❌️	❌️	❌️	🧐️	🧐️
OpenCL	AMD ROCm	⭐️		❌️	❌️	❌️	❌️	❌️	❌️	🧐️	🧐️
OpenCL	Mesa RustiCL		🐧️	✅️	✅️	✅️	✅️	✅️	✅️	✅️	✅️

✅️ = Pilote fonctionnel.
🧐️ = Pilote fonctionnel pour une sélection de modèles.
❌️ = Pilote non-fonctionnel.
⭐️ = Pilote faisant partie de la suite officielle Radeon Software for Linux (pour RADV : après les versions 25.10).
🐧️ = Pilote empaqueté en standard dans les distributions Linux usuelles.

La famille de cartes RDNA4 venant tout juste d’être mise sur le marché, conjecturer sa prise en charge est un exercice périlleux. On sait que le pilote ROCm n’est pas encore prêt, par exemple. Il est évident que les prochaines versions de tous ces pilotes les prendront en charge dans un futur proche.

Les derniers pilotes graphiques AMD propriétaires qui subsistaient encore étaient donc les pilotes OGLP, AMDVLK-Pro, et AMF.

Maintenant que tout est libre, ce qu’on attend désormais d’AMD est de faire fonctionner leur pilote de calcul HIP et leur pilote de virtualisation graphique GIM sur plus de matériel…

RADV officiellement supporté

La phrase est explicite, à partir de la sortie de la suite Radeon Software for Linux en version 25.20, « The Mesa Vulkan driver will be officially supported ». Autrement dit, le pilote Vulkan de Mesa sera officiellement supporté par AMD.

Le pilote Mesa pour les cartes AMD est RADV, initié originellement par Valve alors qu’AMDVLK était encore propriétaire.

Cette formulation n’exclut pas le pilote Vulkan libre AMDVLK d’AMD. AMDVLK sera donc très certainement encore supporté comme il l’est déjà.

Ce qui va changer pour Vulkan concerne AMDVLK-Pro, c’est ce que signifie la phrase « The AMD proprietary OpenGL and Vulkan drivers will no longer be included in the release », qui signifie aussi que le pilote OGLP pour OpenGL est également poussé vers la sortie.

Ce que support veut dire

Ce terme de support couvre les paquets de pilotes qu’AMD propose eux-mêmes, par exemple pour Ubuntu, Red Hat Linux Entreprise ou SUSE Linux Enreprise, ce sont les paquets dans le dépôt repo.radeon.com.

Mais AMD participe déjà activement au développement de pilotes Mesa comme le pilote OpenGL RadeonSI. Apprendre qu’AMD ne fera pas que redistribuer mais supportera officiellement le pilote Mesa RADV dans sa suite de pilotes permet d’espérer une contribution similaire à RADV. En d’autres termes, si un bug affecte RADV, ils pourront considérer qu’il est de leur responsabilité de le corriger dans RADV directement.

De plus, cela encourage désormais AMD à implémenter la prise en charge des futures cartes directement dans RADV avant que les cartes elles-mêmes ne soient mises sur le marché, ce qui était le principal argument en faveur d’AMDVLK-Pro et AMDVLK comparé à RADV.

Ainsi, si vous utilisez une carte AMD et quand bien même vous utiliseriez le pilote RADV fourni par votre distribution, vous profiterez des effets de ces travaux de maintenance d’AMD comme vous en profitez déjà pour RadeonSI.

C’est une très bonne nouvelle pour tout le monde car RADV est le pilote Vulkan installé par défaut (car faisant partie de la suite Mesa) par toutes les distributions Linux… et ce pilote devrait désormais profiter directement des efforts d’AMD.

Le départ des derniers

Il est important de noter que parce que ces pilotes en espace utilisateur sont écrits pour fonctionner par-dessus le pilote noyau amdgpu, il reste toujours possible d’utiliser ces pilotes désormais abandonnés, que ce soit OGLP, AMF et AMDVLK-Pro qui nous quittent désormais, ou les plus anciens PAL et ORCA, pour ceux qui recherchent un environnement spécifique tout en utilisant une distribution très récente. Et ce sera probablement encore vrai pendant des années, à condition de conserver votre ancien matériel compatible avec ces pilotes désormais obsolètes.

En réalité ça fait longtemps qu’il n’est plus nécessaire d’employer un logiciel propriétaire pour utiliser ses cartes graphiques AMD sous Linux. Toutes les API supportées par AMD avaient déjà des implémentations libres depuis longtemps.

Ce qu’AMD est en train de faire est de se débarrasser définitivement des rares alternatives propriétaires qui survivaient encore…

Adieu OGLP

OGLP était jusqu’à maintenant le pilote OpenGL propriétaire d’AMD sous Linux. AMD recommande le pilote libre Mesa RadeonSI pour OpenGL sous Linux depuis très longtemps. Le pilote libre Mesa RadeonSI lui est très supérieur, que ce soit en termes de fonctionnalité, de performance, et de qualité, et AMD contribue directement à ce pilote RadeonSI. Il est très probable que la majorité d’entre vous n’ait même pas connaissance que le pilote OGLP existait, ni même connaissait son nom.

OGLP proposait une implémentation OpenGL et OpenGL ES.

Mon expérience dans l’évaluation de pilotes graphiques pour le jeu Unvanquished m’a fait constater que le pilote OGLP présentait les mêmes bugs que le pilote propriétaire AMD pour Windows, Adrenalin. Il est donc extrêmement probable que c’était une simple recompilation du même pilote, mais pour Linux, comme à l’époque de Catalyst et fglrx.

En effet déjà à l’époque de fglrx pour ATI, et encore aujourd’hui pour Nvidia, les pilotes propriétaires graphiques de ces concepteurs de cartes graphiques sont généralement exactement le même pilote quel que soit le système, avec une couche de compatibilité pour le système, ce qui est logique dans une optique de réduction des coûts de développement.

OGLP était donc très certainement le pilote OpenGL de la suite fglrx, le pendant Linux du pilote Windows Adrenalin, mais porté pour le pilote noyau libre amdgpu au lieu du pilote fglrx abandonné il y a déjà des années.

On pourra s’étendre en conjectures sur pourquoi AMD maintenait encore le pilote OGLP jusqu’en 2025, il est probable que celui-ci répondait à des exigences contractuelles professionnelles. Sur le plan technique pendant longtemps le pilote Mesa s’était limité à implémenter seulement le « core profile » d’OpenGL et pas le « compatibility profile » qui pouvait être requis par certaines applications industrielles, et cela justifiait alors l’existence d’un pilote propriétaire pour satisfaire la clientèle. Mais Mesa a depuis implémenté ce « compatibility profile » et ce depuis longtemps désormais, il est donc possible que ne subsistait plus que des exigences contractuelles — peut-être même pas techniques — pour justifier la fourniture de ce pilote OGLP.

Adieu AMDVLK-Pro

Le pilote AMDVLK-Pro était en fait le pilote libre AMDVLK amalgamé de composants propriétaires.

Le pilote AMDVLK est un pilote libre qui implémente l’API graphique Vulkan.

Contrairement au pilote OpenGL officiel RadeonSI qui est développé en collaboration avec Mesa, le pilote Vulkan AMDVLK est développé exclusivement par AMD, mais c’est tout de même un pilote libre.

Au tout début AMDVLK était aussi un pilote propriétaire mais conçu dès le départ pour devenir un pilote libre plus tard, avec la promesse qu’il soit libéré un jour. Le pilote AMDVLK, alors qu’il était encore propriétaire, avait permis à beaucoup d’utilisateurs de Linux de profiter des fonctionnalités Vulkan de leurs cartes graphiques AMD sans avoir à attendre un pilote libre, que ce soit AMDVLK lui-même une fois libéré, ou le pilote RADV développé par Mesa.

Le pilote AMDVLK-Pro était donc en quelque sorte la continuité de ce pilote qui distribuait au plus tôt les fonctionnalités aux utilisateurs, en remettant à plus tard la libération de ces fonctionnalités. Quand AMDVLK avait été libéré, AMDVLK-Pro en était donc devenu la variante propriétaire qui implémentait et distribuait les dernières nouveautés.

Là encore, il est pertinent de supposer que le pilote AMDVLK est construit sur la même base de code que le pilote Windows. Quand bien même existe désormais le pilote Mesa RADV pour Linux, il est peu probable que le pilote libre AMDVLK disparaisse de l’écosystème Linux de si tôt.

Peut-être un jour AMDVLK, bien que libre, suivra le sort d’OGLP si un jour AMDVLK n’apportera rien de plus que RADV et ce depuis un temps certain ? L’avenir nous le dira.

Adieu AMF

AMF (Advanced Multimedia Framework) s’en ira également, c’est une bibliothèque d’accélération matérielle pour le décodage et l’encodage de formats vidéo. AMD recommande d’utiliser à la place l’implémentation VA-API de Mesa.

Souvenir des pilotes AMD abandonnés sur le bord du chemin

Parmi les pilotes AMD propriétaires conçus pour tourner sur le pilote noyau amdgpu, AMD a déjà abandonné ORCA et PAL. C’était des pilotes de calcul OpenCL (conçus pour les cartes GCN 2 à 4 pour ORCA, et GCN 5 pour PAL) qui ont été remplacés par ROCm.

On peut aussi supposer que PAL et ORCA étaient des portages du pilote OpenCL de Windows mais conçus pour tourner sur le pilote noyau amdgpu à la manière d’OGLP et d’AMDVLK.

Pour les plus pointilleux, PAL (Platform Abstraction Library) était en fait le nom de la bibliothèque d’abstraction entre le code propriétaire commun et le système Linux, et par métonymie on appelait PAL le pilote OpenCL qui utilise PAL comme interface. Dans la même veine, certains parlent parfois de ROCr OpenCL pour l’implémentation actuelle de OpenCL de la suite ROCm, ROCr étant le ROCm Runtime. Le nom ORCA n’échappe probablement pas à cette règle d’usage, mais je n’ai jamais trouvé d’explication de ce nom (je ne suis même pas sûr que ce soit un acronyme), la chaîne orca était simplement utilisée dans le nom du paquet (par exemple : opencl-orca-amdgpu-pro-icd).

PAL et ORCA ont longtemps été regrettés, car ils prenaient en charge la totalité des cartes de leurs générations, contrairement à ROCm. On peut lire à ce sujet sur LinuxFr.org l’article de 2022 « OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx ». Heureusement, Mesa fournit désormais RustiCL qui leur est désormais supérieur sur bien des points. Cela pourrait faire l’objet d’une dépêche à venir… 😉

Et avant cela, il y a bien longtemps avant de s’embarquer dans son aventure amdgpu, AMD fournissait la suite Catalyst entièrement propriétaire, qui exécutait au-dessus du pilote noyau propriétaire fglrx des pilotes propriétaires OpenGL et OpenCL pour le graphisme et le calcul.

Mais… et les firmwares ?

Les micrologiciels (firmwares) des cartes graphiques ne sont toujours pas libres, mais ceux-ci ne s’exécutent pas avec le système d’exploitation de votre ordinateur dans le processeur principal de votre machine, ils s’exécutent dans la carte graphique directement, c’est donc un tout autre sujet.

Certains réclament aussi la libération de ces micrologiciels, mais d’ici à ce que ce rêve devienne un jour réalité, si ce jour vient un jour, vous savez déjà que votre Linux, lui, il peut déjà prendre en charge toutes les fonctionnalités de votre carte avec des logiciels libres sous Linux.

Préférer le DisplayPort à l’HDMI pour les très hautes définitions…

Un petit couac cependant… Les pilotes AMD sous Linux ne peuvent légalement pas implémenter la version 2.1 du protocole HDMI, donc si vous avez besoin d’utiliser des définitions telles que le 4K à 120 Hz ou le 5K à 240 Hz, il faut privilégier le DisplayPort. Ce n’est pas la faute d’AMD : AMD avait en fait implémenté cette prise en charge mais n’a légalement pas le droit de la publier dans un pilote libre. Le HDMI Forum a restreint l'accès public aux spécifications en 2021, et publier cette partie du code du pilote serait contraire à ces nouvelles conditions. Ce code de prise en charge HDMI 2.1 est censé être implémenté dans le pilote noyau amdgpu, et AMD n’a aucune intention d’abandonner son pilote libre, alors que sa stratégie est précisément de tout libérer !

Prochain objectif : l’universalité du calcul et de la virtualisation ?

Enfin, je dis que « Linux peut déjà prendre en charge toutes les fonctionnalités de votre carte avec des logiciels libres » mais si vous souhaitez profiter de ROCm et GIM ce n’est vrai qu’à condition de bien choisir votre carte. 😬

AMD a la volonté d’améliorer la situation de ROCm, tel qu’en témoigne un sondage il y a quelque mois invitant les utilisateurs à exprimer leurs souhaits dans le cadre de l’effort d’AMD d’étendre la prise en charge. Mais ça prend du temps ! Et si, se faire attendre, c’est se faire désirer, il ne faudrait pas trop attendre pour AMD au risque que le désir se détourne vers d’autres propositions.

Et du côté de la virtualisation de carte graphique (GPU-IOV), le pilote GIM est libre aussi mais la situation est encore pire : il ne prend en charge que deux accélérateurs (ces produits n’ont pas de sortie vidéo)… Certains diront que c’est un progrès car la version précédente ne prenait en charge qu’un seul accélérateur… Il a été annoncé qu’une prise en charge matérielle plus large serait « sur la feuille de route » mais si ça prend le même temps que ROCm ou plus, il faudra se montrer très patient. 😄

En attendant, on peut célébrer cette victoire : La pile graphique d’AMD sous Linux est désormais complètement libre !

🥂🍾

Not so Common Desktop Environment reproduit fidèlement Common Desktop Environment dit CDE, classique des Unix des années 90. Mais pourquoi puisque CDE est libre ? Eh bien pour faire mieux ! NsCDE est plus léger, plus complet, plus souple.

NsCDE est sorti en version 2.3 le 20 juin 2023. C'est un petit projet qui s'appuie sur un thème pour FVWM et quelques utilitaires de son cru. Le reste, c'est un thème pour les applications GTK et Qt. Poussant le mimétisme jusqu'à reproduire le script shell du premier démarrage, NsCDE vous demande quels doivent être votre terminal, votre gestionnaire de fichier, votre éditeur, etc. Ce n'est pas mal de pouvoir choisir ! Comme c'est assez abouti il n'y a pas eu de nouveaux développements depuis.

Impressions après quelques jours d'utilisation

J'ai trouvé l'ensemble agréable et cohérent, certes un peu brutal visuellement, mais on n'est pas devant un thème, c'est un paradigme de fonctionnement différent. Avec un peu d'habitude on peut bosser sans surprises.

Un exemple sur la gestion des fenêtres, différente du monde Win/Mac qui est le paradigme habituel sur la plupart des bureaux Linux :

Elles se déplacent encore par la barre de titre, mais pour le reste les trois clics de souris sont utilisés. 
Le bouton de gauche est trois choses à la fois : un menu déroulé par un clic gauche, un menu étendu déroulé par un clic droit et une boite de dialogue affichée par un clic centre ; la fenêtre se ferme avec un deuxième-clic rapproché dans le temps (clic gauche ou droit) ou un double clic aussi.
À droite, un bouton agrandit la fenêtre avec beaucoup de possibilités selon le clic gauche, centre ou droit et selon la séquence de clics ; un deuxième bouton réduit la fenêtre : clic gauche pour l'icônifier, clic droit pour l'enrouler. Icônifiée, un clic droit l'agrandit, les clics gauche et centre ouvrent des menus.

NsCDE ne propose qu'un minimum d'utilitaires, il ne s'agit pas de tout intégrer façon KDE ou Gnome, mais plutôt de fournir un environnement de travail pour interagir avec vos programmes préférés. Testez-le pour découvrir autre chose que le fonctionnement habituel. Le libre vous permet de choisir, sortez des sentiers battus.

En tout cas ne l'installez pas pour sa légèreté, Liam Proven l'utilisant avec des composants XFCE l'a trouvé plus léger que les autres, mais il est plus lourd que KDE 3.

L'influence de CDE à travers des anecdotes

C'est moche, hein ? Et pourtant le design de CDE a influencé d'autres environnements de bureau :

• Le présentation manager d'OS/2 a influencé l'aspect de Win 3 et CDE, mais réciproquement le LaunchPad d'OS/2 v3 reproduit le lanceur CDE.
• XFCE 3 reproduisait le lanceur CDE :
• Et même KDE, dont le nom serait un jeu de mots avec Kool Desktop Environment (personne ne s'en souvient vraiment, on trouve d'autres explications).
• À la même époque, Silicon Graphics avait pris un chemin différent avec IRIX Interactive Desktop. D'après mon cousin, qui passait de la PAO sur Mac à la 3D sous Irix, c'était très ergonomique et ça valait bien le Mac. Il n'a jamais eu besoin d'ouvrir un terminal.

Installation

NsCDE propose quelques paquets tout prêt pour Fedora, Suse, Ubuntu, Debian et Slackware ainsi qu'un gros Tarball à décompresser dans /opt.

Je vous recommande de l'utiliser sous un compte de test, sinon NsCDE va pourrir votre bureau habituel avec ses boites de dialogue et ses thèmes Firefox, LibreOffice, etc. En plus, NsCDE n'a pas de script de désinstallation, il sauvegarde vos paramètres Gtk et Qt, mais seulement jusqu'aux versions 4 et 5.

Évitez d'y lancer des applications Gnome à cause des menus et fenêtres, sauf si vous installez gtk3-nocsd (no client side decoration). Préférer les applications légères et simples de LXDE/LXQt, Mate, XFCE, … Ou encore les applis Motifs/X11, le thème NsCDE leur ira comme un gant.

Tester CDE

Si vous tenez à essayer le vrai CDE pour voir comment c'était, il y a un CD Live sous Debian.

Dans le cadre des 20 ans de Fedora-fr et du Projet Fedora en lui-même, Nicolas Berrehouc alias Nicosss et moi-même (Charles-Antoine Couret alias Renault) avons souhaité poser des questions à des contributeurs francophones du Projet Fedora et de Fedora-fr.

La diversité des profils permet de voir le fonctionnement du projet Fedora sous différents angles, au-delà de la distribution, mais aussi comment il est organisé et conçu. Certains points s’appliquent d’ailleurs à d’autres distributions.

N’oublions pas que le Projet Fedora reste un projet mondial et un travail d’équipe, ce que ces entretiens ne permettent pas forcément de refléter. Mais la communauté francophone a la chance d’avoir suffisamment de contributeurs et de contributrices de qualité pour permettre de donner un aperçu de beaucoup de sous-projets de la distribution.

Chaque semaine un nouvel entretien sera publié sur le forum Fedora-fr.org, LinuxFr.org et le blog de Renault.

L’entretien du jour concerne Timothée Ravier, contributeur au Projet Fedora en particulier aux systèmes dits immuables et à l’environnement KDE Plasma.

Sommaire

• Conclusion

Bonjour Timothée, peux-tu présenter brièvement ton parcours ?

J’ai commencé à m’intéresser aux logiciels open source autour de 2004 lorsque j’ai découvert Firefox (version 1.0 à l’époque) par l’intermédiaire d’un ami qui l’a téléchargé pour moi sur un CD ré-inscriptible, car je n’avais pas encore l’ADSL à l’époque. J’ai ensuite découvert Linux avec Ubuntu 6.06. Après mes études d’ingénieur en sécurité informatique, j’ai travaillé à l’ANSSI pendant cinq ans sur le projet CLIP OS et je travaille désormais pour Red Hat où je co-dirige l’équipe CoreOS, qui est responsable de la maintenance de Fedora CoreOS et de Red Hat Enterprise Linux CoreOS pour OpenShift.

Peux-tu présenter brièvement tes contributions au Projet Fedora ?

Mes contributions à Fedora sont liées à mon intérêt pour les systèmes orientés conteneurs, parfois dénommés immuables (immutable). Je fais ainsi partie de l’équipe qui maintient Fedora CoreOS, je suis un mainteneur des Fedora Atomic Desktops (principalement Silverblue et Kinoite) et je suis membre du KDE Special Interest Group (SIG).

Qu’est-ce qui fait que tu es venu sur Fedora et que tu y es resté ?

Je suis passé par plusieurs distributions Linux (Ubuntu, Gentoo, Arch Linux) mais je suis désormais sur Fedora.

Je pense que les « Four Foundations » de Fedora représentent bien mon parcours :

• Freedom : Je suis là parce que je suis intéressé par les logiciels libres, car ils permettent un partage, une mise en commun au bénéfice de tous.
• Features, First : C’est la force de la communauté Fedora d’un point de vue technologique. Je développe ce point dans les questions suivantes.
• Friends : Je me suis fait des amis dans la communauté Fedora et cela contribue à la bonne ambiance et la motivation pour continuer à contribuer.

Pourquoi contribuer à Fedora en particulier ?

Je préfère être proche des projets upstream et des dernières évolutions. C’est pour cela que j’étais pendant un long moment sous Arch Linux.

Mais le processus pour pousser des changements dans Arch Linux était plutôt flou. Il est important de noter que cela a peut-être changé désormais. Mon expérience date de plus de 6 ans et je crois qu’ils ont un processus de RFC maintenant. Le fonctionnement d’Arch Linux impose aussi des mises à jour régulières et une certaine discipline lors des mises à jour liée au modèle de développement sans version fixe.

Je commençais alors à m’intéresser de plus en plus aux systèmes à base d’images (CoreOS Container Linux et Fedora Atomic Host à l’époque) et je suis donc allé voir Fedora Atomic Workstation (ancien nom de Silverblue) pour créer une version à base de l’environnement KDE Plasma, qui est devenue Fedora Kinoite.

Le processus pour pousser des changements dans Fedora est ce qui fait la force de la distribution. Il permet d’obtenir des discussions et des décisions sur les évolutions à apporter à la distribution pour la prochaine version.

Contribues-tu à d’autres Logiciels Libres ? Si oui, lesquels et comment ?

En dehors de Fedora, je contribue principalement au développement des projets KDE. Je fais partie de l’équipe qui maintient les applications KDE empaquetées avec Flatpak et publiées sur Flathub.

Je contribue aussi occasionnellement à différents projets open source en fonction des besoins.

Utilises-tu Fedora dans un contexte professionnel ? Et pourquoi ?

Oui, mes ordinateurs professionnels et personnels tournent sous Fedora Kinoite et mes serveurs personnels utilisent Fedora CoreOS. Une partie des serveurs que nous utilisons pour développer et produire les versions de Fedora CoreOS sont aussi sous Fedora CoreOS. D’autres sont sous Red Hat Enterprise Linux CoreOS, car ils font partie d’un cluster OpenShift.

En gros, nous sommes aussi des utilisateurs directs des logiciels que nous développons.

Est-ce que tes contributions dans Fedora se font entièrement dans le cadre de ton travail ? Si non, pourquoi ?

Une grosse partie de mes contributions se font dans le cadre de mon travail, mais toute la partie liée à KDE et aux Fedora Atomic Desktops est faite sur mon temps personnel.

Est-ce que être employé Red Hat te donne d’autres droits ou opportunités au sein du Projet Fedora ?

Je n’ai pas plus de droits dans Fedora parce que je travaille pour Red Hat. Je dois suivre tous les processus de Fedora comme n’importe quel contributeur. J’ai d’ailleurs commencé à contribuer à Fedora avant d’avoir été employé par Red Hat.

En revanche, il est indéniable que cela m’aide pour contribuer, car j’ai régulièrement l’occasion de discuter avec d’autres contributeurs Fedora dans le cadre de mon travail.

Tu as débuté une carrière dans la sécurité pour finalement travailler pour Red Hat en tant que mainteneur de CoreOS, Silverblue, Kinoite et contributeur à KDE, pourquoi ne pas avoir continué dans la sécurité pour cet écosystème ?

Quelque part je continue à faire de la sécurité mais sous un autre angle. La sécurité que je faisais avant ne bénéficiait qu’à un petit nombre de personnes qui avait accès aux systèmes que l’on développait. La nouvelle version open source de CLIP OS devait rendre le système plus accessible mais le projet était complexe et je crois qu’il est désormais archivé.

Je travaille désormais à améliorer la sécurité de Fedora CoreOS et des Fedora Atomic Desktops sans compromettre leur utilisabilité. L’objectif est de fournir une distribution Linux avec des mises à jour robustes qui soit utilisable par des non développeurs.

Tu participes à CoreOS pour RHEL, CentOS Stream et Fedora. Peux-tu expliquer le but de CoreOS et ses principales caractéristiques ? Quelles sont les différences entre RHEL, CentOS Stream et Fedora à ce sujet ?

L’objectif pour les systèmes CoreOS est de faire tourner au mieux des applications dans des conteneurs. Pour Fedora CoreOS, c’est un système minimal, avec des mises à jour automatiques, proposant à la fois podman et moby-engine (Docker) installés par défaut, prêt à faire tourner des conteneurs sur un seul nœud ou dans le cadre d’un cluster Kubernetes.

Pour Red Hat Enterprise Linux CoreOS (et CentOS Stream CoreOS), ce sont des systèmes qui forment le socle d’OpenShift (et d’OKD), une plateforme qui intègre plein de projets open source dont Kubernetes.

Bien qu’il n’y ait pas une correspondance exacte un pour un dans la liste des logiciels inclus, Fedora CoreOS est l’upstream de CentOS Stream CoreOS et Red Hat Enterprise Linux CoreOS, de la même façon que Fedora est l’upstream de CentOS Stream, qui l’est de Red Hat Enterprise Linux.

L’architecture atomic a gagné du terrain sur les systèmes pour le bureau avec Silverblue et Kinoite et devient relativement populaire, peux-tu expliquer quel en est l’intérêt d’une telle conception pour ce genre de systèmes ?

Le principal intérêt pour un utilisateur est la robustesse et rapidité des mises à jour. Celles-ci sont préparées en arrière plan alors que le système fonctionne normalement. Il suffit alors de redémarrer pour mettre à jour son système. Il n’y a pas d’attente supplémentaire ni à l’extinction ni au démarrage.

Si une mise à jour échoue, le système reste dans l’état actuel, et il est possible de réessayer plus tard.
Si une mise à jour introduit un problème important empêchant le démarrage du système par exemple, il est possible de redémarrer et de choisir la version précédente dans le menu de démarrage de GRUB.

Les utilisateurs sont aussi poussés à utiliser Flatpak pour installer leurs applications graphiques et toolbox (ou distrobox) pour utiliser les applications en ligne de commandes dans des conteneurs.

Quels sont les défis techniques de proposer cette conception dans ces systèmes par rapport à CoreOS par exemple ?

La principale différence est la présence d’une interface graphique. Les applications graphiques doivent être parfois adaptées pour fonctionner avec Flatpak. C’est désormais le cas de la plupart d’entre elles.

Tu y contribues en tant que membre de Fedora Atomic Desktops SIG, peux-tu expliquer son rôle dans Fedora et ton activité dedans ?

Le rôle du Fedora Atomic Desktops SIG est de regrouper l’ensemble des contributeurs Fedora des différentes variantes Atomic : Silverblue, Kinoite, Sway Atomic et Budgie Atomic. Bien que chacun de ces systèmes propose un environnement de bureau distinct, ils partagent énormément d’éléments, tant au niveau des composants de base du système que de l’infrastructure Fedora. Le SIG permet donc de regrouper les contributeurs pour pouvoir les inclure dans les prises de décisions qui impactent ces systèmes.

Je participe à la maintenance des Fedora Atomic Desktops et plus principalement de Silverblue et Kinoite. Cela peut impliquer des mises à jour de paquets, des corrections de bugs dans des projets upstream ou des rajouts de fonctionnalités pour améliorer l’expérience sur ces systèmes. Je surveille aussi que tous les Atomic Desktops continuent de recevoir des mises à jour régulièrement.

Penses-tu qu’un jour ces systèmes atomic deviendront la référence par défaut ? Si oui à quelle échéance ? Quelles sont les difficultés actuelles à résoudre ?

Je l’espère ! Il est impossible de donner une échéance et cela ne dépend pas vraiment de moi. La difficulté la plus importante est la prise en charge du matériel et les pilotes qui ne sont pas intégrés dans Fedora. C’est un problème que l’on ne peut pas résoudre dans Fedora à cause des contraintes légales et qui sont traitées par le projet Universal Blue, dont la variante Bazzite (https://bazzite.gg/), est très populaire.

Pour la problématique des pilotes, est-ce que l’initiative du noyau unifié (d’avoir une image universelle et signée comprenant le noyau, initrd, la ligne de commande) te semble être une solution à cette problématique ?

Ces deux sujets ne sont pas liés.

Le problème des pilotes externes au noyau Linux upstream est divisé en deux cas principaux :

• Les pilotes propriétaires : Ils ne seront jamais ajoutés directement à Fedora pour des raisons légales et de licence.
• Les pilotes open source mais non inclus dans le noyau Linux upstream : Fedora met à jour le noyau Linux très régulièrement et suit les nouvelles versions stables peu de temps après leur sortie officielle. Il faut donc que ces pilotes soient mis à jour pour suivre les nouvelles versions du noyau et cela demande toujours du temps lorsque ceux-ci ne font pas partie du noyau upstream.

Les images noyau unifiées (Unified Kernel Images ou UKI) incluent le noyau, l’initrd et la ligne de commande du noyau dans un seul fichier. Cela présente des avantages pour mettre en place une chaîne de boot mesurée, notamment à l’aide du TPM, et donc pour offrir de meilleures garanties de sécurité. Leur intégration est encore en cours dans les variantes CoreOS et Atomic Desktops.

Les développeurs et administrateurs systèmes ont souvent besoin d’outils qui à ce jour nécessitent souvent de recourir à rpm-ostree plutôt que Flatpak ou Fedora toolbox dans le cadre d’un système immuable. Penses-tu que ces verrous sont un réel problème et qu’ils seront éventuellement résolus dans le temps ?

L’un des objectifs de la nouvelle initiative conteneurs bootables (« Bootable Containers ») est justement de rendre plus ergonomique la modification du système de base. Le système est distribué sous forme d’une image de conteneur standard (image OCI) et il est possible de la modifier à l’aide d’un Containerfile / Dockerfile et d’outils natifs aux conteneurs. Cela permet aux utilisateurs de ré-utiliser leurs habitudes et outils pour modifier aussi leur système de façon sûre et de partager le résultat à l’aide d’un registre d’image de conteneurs.

Nous allons aussi ajouter à nouveau dnf (version 5) dans ces images de conteneurs pour mettre à disposition des utilisateurs une interface familière et toutes les options de dnf lors de la construction de ces images.

Une autre piste est d’utiliser le concept des extensions systèmes de systemd (systemd system extensions ou sysexts), qui permettent d’ajouter du contenu dynamiquement à un système sans perdre les avantages de la gestion à base d’images. Les sysexts utilisent la même technologie que pour les conteneurs (overlayfs) pour ajouter des éléments (merge) au contenu des dossiers /usr et /opt de l’image de base. Je suis en train d’investiguer cette option pour rendre son usage ergonomique pour ces systèmes : https://github.com/travier/fedora-sysexts.

Il est aussi possible de modifier temporairement le système en utilisant un système de fichier temporaire monté au-dessus des emplacements en lecture seule (overlayfs). Les fichiers de /usr peuvent alors être modifiés et de nouveaux paquets RPM installés à la demande. Les modifications disparaîtront au redémarrage.

Tu participes aussi à l’équipe de KDE SIG, peux-tu expliquer son rôle dans Fedora et ton activité dedans ?

L’objectif du KDE SIG est de proposer la meilleure expérience possible de KDE sur Fedora. Nous suivons et contribuons aussi au développement de KDE upstream.

Je participe au KDE SIG en tant que mainteneur de Kinoite et développeur KDE.

GNOME reste le bureau principal de Fedora à ce jour, cependant la qualité de l’intégration de KDE progresse depuis de nombreuses années maintenant, penses-tu que la qualité entre les deux est aujourd’hui équivalente ? Est-ce que les contributions pour KDE sont freinées de par le statut de GNOME au sein du projet ?

C’est une question très difficile, car elle est très subjective. J’utilise principalement KDE sur mes systèmes, mais j’apprécie énormément le travail de design fait sur GNOME. Pour moi c’est un choix personnel.

D’un point de vue technologique, il est possible de trouver des éléments “meilleurs” dans GNOME que dans KDE et l’inverse.

Il n’y a pas de bénéfice à opposer ces deux projets. C’est au contraire la collaboration qui améliore l’expérience utilisateur.

Je ne pense pas que les contributions à KDE soient freinées par le status de GNOME dans Fedora.

L’équipe KDE SIG a récemment proposé d’améliorer le statut de KDE au sein du projet, quitte à même remplacer GNOME pour Fedora Workstation, peux-tu expliquer cette demande ? Penses-tu qu’un jour KDE remplacera GNOME au sein de Fedora ou de RHEL par exemple ?

L’idée des membres soutenant cette proposition (qui ne vient pas uniquement de personnes faisant partie du KDE SIG) est de remettre en question la place de GNOME « par défaut » dans le projet Fedora (notamment Fedora Workstation). Poser cette question force le projet à clarifier les critères qui font qu’un environnement de bureau est considéré comme majeur et donc autorisé à être représenté par une “édition” comme Fedora Workstation. Tous les environnements de bureau non-GNOME ne sont actuellement pas bien présentés sur le site de Fedora notamment.

Il est important pour un projet communautaire de pouvoir justifier ses choix, que l’on soit d’accord ou non avec les arguments présentés. Si ces choix sont perçus comme arbitraires (« c’est comme ça que cela a toujours été », « c’est un employé de Red Hat qui l’a décidé »), alors le projet Fedora perd en crédibilité. Il faut, par exemple, pouvoir justifier que GNOME est un bon choix à présenter aux utilisateurs découvrant Fedora.

Je ne pense pas que KDE va “remplacer” GNOME dans Fedora et ce n’est pas vraiment l’idée derrière cette proposition qui a été formulée explicitement de la sorte pour forcer la discussion. L’objectif est de rendre KDE plus visible dans Fedora.

Pour ce qui est de remplacer GNOME dans RHEL, c’est peu probable et cela serait une décision de Red Hat.

Penses-tu que Fedora est une distribution de référence pour utiliser KDE aujourd’hui ? Par le passé OpenSUSE, Kubuntu ou Mageia étaient souvent recommandées pour utiliser cet environnement.

Oui ! :) Fedora propose depuis plusieurs années les dernières versions de KDE à des fréquences très proches des sorties upstream. Nous sommes actuellement l’une des premières distributions à proposer le bureau KDE Plasma dans sa version 6. Le KDE SIG suit et participe activement au développement de KDE upstream et certains développeurs KDE recommandent désormais Fedora.

Je travaille avec Fedora Kinoite à rendre le développement de KDE plus abordable, notamment pour le test des versions en cours de développement.

Si tu avais la possibilité de changer quelque chose dans la distribution Fedora ou dans sa manière de fonctionner, qu’est-ce que ce serait ?

Je regrouperai l’intégralité des dépôts Git, codes sources, projets, suivi des bugs, etc. sur une (ou plusieurs) instance GitLab hébergée par le projet Fedora. C’est un projet qui est désormais en cours pour migrer vers Forgejo. Finies les instances Pagure (forge de développement Git), plus de Bugzilla (suivi des bugs). Il faudrait aussi abandonner les listes de diffusion pour utiliser Discourse à la place (transition aussi en cours).

D’un point de vue personnel, la migration du projet KDE vers GitLab fut un facteur déterminant dans ma capacité à contribuer au projet KDE. Le mode de contributions à l’aide de Pull Requests / Merge Requests à travers une interface web est devenu un standard qui réduit significativement la difficulté pour un premier contributeur à participer à un projet.

Je pense que c’est la prochaine étape importante pour rendre le développement de Fedora plus accessible et donc pour attirer plus de contributeurs.

À l’inverse, est-ce qu’il y a quelque chose que tu souhaiterais conserver à tout prix dans la distribution ou le projet en lui-même ?

Le processus pour proposer un changement (Change Process). C’est la clé de ce qui fait de Fedora une distribution à la pointe, qui évolue à chaque nouvelle version et qui pousse l’écosystème en avant.

Que penses-tu de la communauté Fedora-fr que ce soit son évolution et sa situation actuelle ? Qu’est-ce que tu améliorerais si tu en avais la possibilité ?

Malheureusement, je n’ai pas eu beaucoup d’interactions avec la communauté Fedora-fr, donc je n’ai pas grand-chose à dire.

Quelque chose à ajouter ?

Merci pour l’entretien !

Si vous souhaitez en apprendre plus sur ces systèmes, je vous recommande les documentations officielles des projets ou les présentations que j’ai réalisées (une ou deux en français).

Merci Timothée pour ta contribution !

Conclusion

Nous espérons que cet entretien vous a permis d’en découvrir un peu plus sur les systèmes immuables de Fedora et l’environnement KDE Plasma.

Si vous avez des questions ou que vous souhaitez participer au Projet Fedora ou Fedora-fr, ou simplement l’utiliser et l’installer sur votre machine, n’hésitez pas à en discuter avec nous en commentaire ou sur le forum Fedora-fr.

À dans 10 jours pour un entretien avec Thomas Canniot, ancien traducteur de Fedora en français et fondateur de l’association Fedora-fr.

Ces derniers temps, on a beaucoup parlé d’intelligence artificielle sur LinuxFr.org. D’IA propriétaires, et d’IA libres. Mais peut-on vraiment faire une IA libre ? La notion n’est pas sans poser quelques difficultés. Une (pas si) courte discussion du problème.

Sommaire

• On appellera IA un réseau de neurones artificiels
• Pour comprendre le réseau de neurones, il est nécessaire de disposer de bases statistiques
  • Les statistiques reposent sur la modélisation
    • Un exemple : la régression linéaire
• Le réseau de neurones
  • Le neurone naturel
  • Le neurone formel
  • La mise en réseau
  • Le réseau de neurones est Turing-complet
  • Le réseau de neurones présente un effet boîte noire important
  • Le réseau de neurones est un modèle statistique
    • Tous les modèles sont faux, certains sont utiles, et c’est vrai aussi pour le réseau de neurones
• Le but du logiciel libre est de rendre le pouvoir à l’utilisateur
  • La première des libertés est celle de savoir ce que je fais
  • Si je sais ce que je fais, je dois pouvoir modifier ce que je fais
• Le réseau de neurones est difficilement compatible avec le libre
  • Personne ne sait vraiment ce que fait un réseau de neurones
  • Disposer de la description complète d’un réseau de neurones ne permet pas de l’améliorer
  • La définition du code source d’un réseau de neurones est ambiguë
  • Cette ambiguïté fait courir un risque juridique sous certaines licences libres
    • Comment les boîtes qui font de l’IA non libre résolvent-elles ce dilemme ? Elles ne le résolvent pas
  • La définition d’une IA open source ressemble furieusement à un constat d’échec
• Conclusion : qu’attendre d’une IA libre ?

On appellera IA un réseau de neurones artificiels

Commençons par définir notre objet d’étude : qu’est-ce qu’une IA ? Par « intelligence artificielle », on pourrait entendre tout dispositif capable de faire réaliser par un ordinateur une opération réputée requérir une tâche cognitive. Dans cette acception, un système expert qui prend des décisions médicales en implémentant les recommandations d’une société savante est une IA. Le pilote automatique d’un avion de ligne est une IA.

Cependant, ce n’est pas la définition la plus couramment employée ces derniers temps. Une IA a battu Lee Sedol au go, mais ça fait des années que des ordinateurs battent les humains aux échecs et personne ne prétend que c’est une IA. Des IA sont employées pour reconnaître des images alors que reconnaître un chien nous semble absolument élémentaire, mais l’algorithme de Youtube qui te suggère des vidéos pouvant te plaire parmi les milliards hébergées fait preuve d’une certaine intelligence et personne ne l’appelle IA. Il semble donc que le terme « IA » s’applique donc à une technique pour effectuer une tâche plus qu’à la tâche en elle-même, ou plutôt à un ensemble de techniques partageant un point commun : le réseau de neurones artificiels.

Dans la suite de cette dépêche, j’utiliserai donc indifféremment les termes d’IA et de réseau de neurones¹.

Pour comprendre le réseau de neurones, il est nécessaire de disposer de bases statistiques

Les statistiques (ou la statistique, on peut dire les deux, comme en Alexandrie), c’est la branche des mathématiques qui s’intéresse aux moyens, à partir de données observées et fondamentalement probabilistes, d’en tirer des conclusions généralisables (et idéalement, de prédire l’avenir à partir du passé).

La data science, c’est la branche de l’informatique qui s’intéresse aux moyens, à partir de données emmagasinées sur lesquelles on ne fait pas d’hypothèse de mode de génération, d’en tirer des conclusions généralisables (et idéalement, de prédire les données futures).

Ça vous semble similaire ? Ça l’est. Les deux champs vont avoir des divergences de vocabulaire, de langages (les stateux préfèreront R, les data scientists Python), de formation (les stateux sont plutôt des universitaires, les data scientists plutôt des informaticiens au niveau licence, mais ils ont les mêmes masters et doctorats), mais fondamentalement, et surtout mathématiquement, c’est la même chose. Les connaissances en inférence statistique (notamment bayésienne, pour ceux à qui ça parle) se généralisent très bien à la data science.

Pour faire court, un statisticien est un data scientist qui se la pète, alors qu’un data scientist est un informaticien qui, n’étant pas assez bon pour survivre à la rude concurrence universitaire, a multiplié son salaire par 10 ou 20 en allant vendre ses compétences statistiques à Facebook.

Les statistiques reposent sur la modélisation

En statistique, la manière la plus courante de répondre à une question est de construire un modèle. Prenons une question simple : je dispose d’un jeu de données où j’ai enregistré, pour 1000 personnes, leur IMC et leur taux de cholestérol. Je souhaite savoir s’il y a un lien entre les deux. On souhaiterait, dans ce cas simple, rechercher une relation monotone, sans faire d’hypothèse sur le type de relation.

Un exemple : la régression linéaire

Une manière de répondre à ma question est d’écrire et de trouver les meilleurs A et B pour que la droite « colle » le mieux possible au nuage de points. On démontre que la meilleure droite est celle qui minimise un certain critère, la somme des carrés des erreurs. Une fois qu’on a la meilleure droite possible, on peut faire plein de choses avec :

• On peut rétro-prédire le taux de cholestérol des personnes déjà observées et voir de combien la prédiction s’écarte du réel, ce qui fournit une erreur moyenne de prédiction ;
• On peut faire de même en prédisant juste le taux de cholestérol moyen pour tous les individus et comparer les erreurs moyennes de prédiction, ce qui permet de voir de combien le modèle améliore la prédiction (et donc de quantifier la quantité d’info apportée par la donnée IMC sur la variable cholestérol) ;
• On peut étudier le signe de A : si A est négatif, prendre du poids fait baisser le cholestérol : si A est positif, prendre du poids augmente le cholestérol : si A est nul, le poids n’apporte pas d’info sur le cholestérol.
• Par contre, on ne peut rien dire de la causalité. Tout ce qu’on a observé, ce sont des personnes qui, au même moment, avaient un IMC et un taux de cholestérol donnés. Impossible de dire s’ils ont ce cholestérol parce qu’ils ont cet IMC, s’ils ont cet IMC parce qu’ils ont ce cholestérol, ou s’ils ont ce cholestérol et cet IMC parce qu’ils ont une troisième exposition.
• On peut enfin faire effectuer de la prédiction à notre modèle : en lui passant une personne dont on ne connaît que l’IMC, on peut estimer son taux de cholestérol et assortir cette prédiction d’un niveau de certitude (ça demande un peu plus de maths, mais c’est l’idée).

On peut vouloir ajouter une troisième variable, mettons le tabagisme. On écrira alors :

Avec la variable tabac codée à 0 (non fumeur) ou 1 (fumeur). Noter que notre modèle est alors passé en dimension 3 : on ne cherche plus à faire passer la meilleure droite par rapport au nuage de points en 2D, mais à faire passer le meilleur plan par rapport au nuage de points en 3D. Noter aussi qu’on peut facilement inclure des variables qualitatives : il suffit de les coder 0 ou 1. On peut d’ailleurs inclure des variables à n modalités : il suffit de les recoder en n-1 sous-variables en 0-1 (la modalité de référence étant celle pour laquelle toutes les sous-variables sont à 0).

Les sont appelés des paramètres : c’est en les faisant varier qu’on ajuste le modèle aux données.

On peut ainsi ajouter un nombre quelconque de variables… Ou peut-être pas. En effet, on va finir par atteindre un seuil où le meilleur hyperplan est tout simplement celui qui passe par tous les points ! Si j’ai 50 individus et 50 paramètres, il est facile de choisir un plan qui passe par tous les individus. C’est ce qu’on appelle le surapprentissage : le modèle a tout simplement appris le jeu de données par cœur ! Le surapprentissage est un écueil des modèles trop complexes et un réseau de neurones est tout à fait capable de surapprendre.

Le réseau de neurones

Le neurone naturel

Les neurones sont les cellules du système nerveux. Elles sont spécialisées dans la transmission d’information.

Comme tu peux le voir sur cette image issue de Wikimedia (source), un neurone comprend un nombre quelconque de dendrites, un corps cellulaire, et un axone. Point crucial : l’axone est unique. Il peut lui-même transmettre de l’information à différents neurones en aval, mais il transmet la même information. Or l’information, dans un neurone, peut entrer par les dendrites et par le corps cellulaire, mais elle ne peut ressortir que par l’axone (on peut faire abstraction de la gaine de myéline et des nœuds de Ranvier, qui ont un rôle central dans la vitesse de conduction de l’information mais qui ne changent rien aux calculs effectués). Autrement dit, un neurone transmet la même information à tous les neurones d’aval, et si ceux-ci en font un usage différent, c’est uniquement lié à leurs propres calculs en interne.

Le neurone formel

On peut modéliser un neurone, par analogie avec le neurone naturel. Notre neurone formel pourra donc prendre un nombre quelconque d’entrées, mais comme un neurone naturel, il ne produira qu’une seule sortie. Notre neurone est donc une fonction de ses entrées :

En pratique (mais ça n’a rien d’obligatoire), on prend souvent une fonction d’une combinaison linéaire des entrées :

Avec une contrainte : la fonction (qu’on appelle fonction d’activation) doit être monotone (idéalement strictement monotone), dérivable presque partout (c’est nécessaire à l’optimisation du réseau, qu’on verra plus tard), définie sur un intervalle suffisamment large pour qu’on soit toujours dedans, et non linéaire (sinon mettre les neurones en réseau n’a aucun intérêt, autant faire directement une unique régression linéaire).

En pratique, on prend donc quelques fonctions classiques :

• La fonction binaire : si , sinon
• La fonction logistique, une amélioration de la fonction binaire : . Avantage : elle est strictement monotone, dérivable partout, et elle prend quand même ses valeurs entre 0 et 1.
• La fonction Rectified Linear Unit (ReLU, qu’on peut prononcer « relou ») : si , sinon. Avantage : elle est très facile (donc rapide) à calculer et à dériver. On peut la rendre strictement monotone en la modifiant à la marge : si , sinon, avec .

La mise en réseau

Tout l’intérêt du neurone formel réside dans sa mise en réseau. Un unique neurone ne fait pas mieux qu’une régression linéaire. On construit donc un réseau de neurones. Pour ce faire, on va donc générer plusieurs neurones, chacun prenant en entrée la sortie de plusieurs neurones et produisant une sortie unique, qui sera à son tour utilisée en entrée par d’autres neurones. On ajoute un ensemble de neurones qu’on pourrait qualifier de « sensitifs », au sens où ils prennent en entrée non pas la sortie d’un neurone antérieur, mais directement l’input de l’utilisateur, ou plutôt une partie de l’input : un pixel, un mot… Enfin, une sortie est ajoutée : elle produit le résultat final.

Étant donné que les neurones sont virtuels et n’ont pas d’emplacement géographique, il est assez logique de les représenter en couches : la couche 0 est constituée des neurones sensitifs, la couche 1 prend en entrée les résultats de la couche 0, et ainsi de suite. Classiquement, tous les neurones de la couche n+1 prennent en entrée les sorties de tous les neurones de la couche n.

Se pose alors la question : combien de neurones par couche, et combien de couches au total ?
On peut considérer deux types de topologies : soit il y a plus de neurones par couche que de couches : le réseau est plus large que long, on parlera de réseau large. Soit il y a plus de couches que de neurones par couche, auquel cas le réseau est plus long que large, mais on ne va pas parler de réseau long parce que ça pourrait se comprendre « réseau lent ». On parlera de réseau profond. C’est de là que viennent les Deep et les Large qu’on voit un peu partout dans le marketing des IA. Un Large Language Model, c’est un modèle, au sens statistique, de langage large, autrement dit un réseau de neurones avec plus de neurones par couche que de couches, entraîné à traiter du langage naturel. On constate empiriquement que certaines topologies de réseau sont plus efficaces pour certaines tâches. Par exemple, à nombre de neurones constant, un modèle large fera mieux pour du langage. À l’inverse, un modèle profond fera mieux pour de la reconnaissance d’images.

Le réseau de neurones est Turing-complet

Un résultat théorique important est que les réseaux de neurones sont Turing-complets. C’est-à-dire que, pour tout programme que l’on peut coder et qui sorte une réponse algorithmique, il existe un réseau de neurones qui donne le même résultat. La réciproque est vraie aussi : ce qui est faisable avec un réseau de neurones est faisable en C ou dans un autre langage, au pire en recodant le réseau dans ce langage.

Le réseau de neurones présente un effet boîte noire important

Prenons maintenant un élément d’information et essayons de suivre son trajet dans le modèle jusqu’à la sortie. Dans une régression linéaire, c’est assez facile : le poids de l’IMC va peser pour dans le résultat final. Dans une forêt aléatoire, on peut toujours isoler les arbres où apparaît une donnée et essayer de regarder combien elle pèse. C’est fastidieux mais ça reste faisable. Dans un réseau de neurones, c’est impossible. Chaque neurone de la couche 1 va passer un résultat agrégé à la couche 2, où chaque donnée de la couche 0 ne compte plus que comme partie d’un tout. De même, chaque neurone de la couche 2 va agréger tous les résultats de la couche 1. Il devient impossible d’individualiser l’effet d’une donnée ou même celui d’un neurone.

Ainsi, même si je connais l’intégralité du contenu du modèle, il m’est impossible de donner du sens à une partie du modèle, prise isolément. Le modèle se comporte comme un bloc monolithique, et la seule manière d’étudier un nouvel exemple est de lui appliquer tout le modèle et de voir ce qui sort. C’est ce qu’on nomme l’effet boîte noire.

Attention : l’effet boîte noire n’est pas lié au nombre de paramètres du modèle. Si je fais de la génétique, et que j’étudie 2000 mutations génétiques individuelles (des SNP, pour single nucleotide polymorphism), je peux assez facilement ajuster un modèle de régression logistique (qui est une variante de la régression linéaire où on fait prédire non pas une variable quantitative, mais une probabilité) à 2000 paramètres (un pour chaque SNP). Chaque paramètre sera parfaitement compréhensible et il n’y aura pas d’effet boîte noire.

Il n’est pas non plus lié à ta méconnaissance des mathématiques, cher lectorat. Des statisticiens chevronnés se cassent les dents sur l’effet boîte noire. Il est intégralement lié à la structure du modèle. Certains types de modèles en ont, d’autres n’en ont pas. Les réseaux de neurones en ont.

Cet effet a une conséquence perturbante : même si on sait ce que fait un réseau de neurones, il est impossible de savoir comment il le fait ! On pourrait argumenter que ce n’est pas forcément différent de ce que nous faisons : si on montre à un enfant de 3 ans une photo de chien, il saura dire que c’est un chien, mais il ne saura pas dire pourquoi c’est un chien. Cependant, on demande rarement à un programme d’être réflexif, mais on demande toujours à son auteur de savoir comment il tourne. C’est un peu la base de la programmation.

Le réseau de neurones est un modèle statistique

Reprenons : on a un paradigme (le réseau de neurones) capable d’effectuer n’importe quelle tâche pour laquelle il existe une solution algorithmique, à condition de le programmer correctement… Mais on ne sait pas le programmer ! Heureusement, il existe un contournement : on ne va pas le programmer, on va l’ajuster, comme un modèle statistique. Ou l’entraîner, si on préfère le terme de « machine learning ».

Tu t’en souviens, cher lecteur, un réseau de neurones est un ensemble de fonctions dont chacune prend en entrée différentes données avec des coefficients (les fameux ). On va commencer par initialiser l’apprentissage en donnant des valeurs aléatoires à ces coefficients. Ensuite, on va soumettre à notre réseau de neurones des tas et des tas de données correctes, et qu’on va comparer ce qu’il prédit à ce qu’on attend. La différence s’appelle l’erreur. Et à chaque itération, on va identifier les neurones les plus générateurs d’erreur et les pénaliser (réduire leur poids, ou plutôt réduire leur poids dans les neurones où c’est nécessaire), tout en favorisant les meilleurs neurones. Les détails de la technique (qui s’appelle la rétropropagation de l’erreur) dépassent largement le cadre de cette courte introduction, mais l’essentiel est qu’à la fin, on obtient un réseau capable de donner des réponses proches de ce qui existait dans l’ensemble des données correctes qu’on lui a passé et de généraliser quand la demande est différente d’une donnée de l’ensemble d’apprentissage. Avantage : en pratique, un réseau de neurones est capable de prendre en entrée n’importe quel type de structure de données : image, texte, son… Tant que les neurones d’entrée sont adaptés et qu’il existe un ensemble d’apprentissage suffisamment grand, c’est bon.

Tous les modèles sont faux, certains sont utiles, et c’est vrai aussi pour le réseau de neurones

Bien sûr, il y a des limites. La première est la complexité algorithmique. Un réseau de neurones nécessite de réaliser un nombre astronomique d’opérations simples : pour chaque couche, il faut, pour chaque neurone, calculer la somme des produits des coefficients avec toutes les sorties de la couche antérieure, soit multiplications, où n est le nombre de neurones par couche et c le nombre de couches. Par exemple, pour un petit réseau de 10 couches de 20 neurones, plus une couche d’entrée, on réaliserait à chaque itération multiplications en virgule flottante, et encore, c’est ici un tout petit réseau : un réseau comme ChatGPT a des neurones qui se comptent par millions, voire dizaines de millions !

Une autre limite est la précision des réponses. Le réseau de neurones étant un modèle statistique, il n’est capable que d’interpoler, c’est-à-dire trouver une réponse à partir de cas similaires. Cette interpolation est rarement aussi précise que celle que donnerait une réponse formelle si elle existait : si Newton avait eu accès à des réseaux de neurones, nous aurions une prédiction du mouvement des planètes qui ne baserait sur aucune théorie, qui serait à peu près exacte mais insuffisamment précise pour envoyer des sondes sur Mars. Quant à s’interroger sur la précession du périhélie de Mercure, on oublie.

De manière générale, on peut s’interroger sur ce qui amène un réseau de neurones à se planter. On peut diviser les erreurs en plusieurs catégories :

• La question posée n’a aucun rapport avec les données passées en entrée. Par exemple : « Sachant que la dernière personne que j’ai croisée dans la rue avait 42 ans, indique-moi son genre ». Le modèle n’a pas assez d’information pour répondre.
• La question posée n’a aucun rapport avec l’ensemble d’apprentissage. Par exemple, demander à un modèle entraîné à reconnaître des photos de chien de reconnaître une voiture. En général, ce problème est résolu en contraignant le format des questions ; dans cet exemple, il suffirait de ne pas permettre à l’utilisateur de poser une question, juste de poster une photo et de recevoir une réponse. D’ailleurs, on ne voit pas très bien pourquoi entraîner un tel modèle à traiter du langage.
• L’ensemble d’apprentissage est trop restreint/biaisé. L’exemple typique est le modèle qui prétendait reconnaître les délinquants à une simple photo et identifiait en fait tous les noirs : ben oui, ils étaient majoritaires dans les délinquants de l’ensemble d’apprentissage. Noter qu’il existe des problèmes où l’ensemble d’apprentissage sera toujours trop restreint pour un certain niveau de précision exigé. Si on demande à un réseau de dire si un point donné est à l’intérieur ou à l’extérieur d’un flocon de Koch, il va falloir lui passer une infinité de données d’apprentissage pour qu’il apprenne les cas limites juste par interpolation (alors qu’avec un modèle formel, ça serait assez facile).
• Le modèle est parasité par une donnée annexe : c’est une problématique assez spécifique du réseau de neurones. L’exemple le plus classique est celui des images de mains : après tout, le voisin le plus probable d’un doigt, c’est un autre doigt. L’amusant, c’est que ce problème serait résolu assez facilement en demandant au modèle de compter 4 doigts et un pouce. Mais comme on ne peut pas programmer directement un réseau de neurones…
• Enfin, si les motifs précédents ont été écartés, je dois me demander si mon modèle n’est pas inadapté : soit qu’il n’a pas assez de neurones, soit que la topologie n’est pas bonne. Plus de neurones permettent de traiter des données plus complexes et leur disposition permet d’augmenter leur efficacité.

En définitive, on peut voir le réseau de neurones comme un outil qui résout approximativement un problème mal posé. S’il existe une solution formelle, et qu’on sait la coder en un temps acceptable, il faut le faire. Sinon, le réseau de neurones fera un taf acceptable.

Le but du logiciel libre est de rendre le pouvoir à l’utilisateur

On a beaucoup glosé, et on continuera de le faire longtemps, sur la philosophie du Libre. Free Software Foundation d’un côté, Open Source Initiative de l’autre, les sujets de discorde ne manquent pas. Mais il faut au moins créditer l’OSI sur un point : avoir clarifié le fait que le Libre est avant tout un mouvement politique, au sens noble du terme : il vise à peser sur la vie de la cité, alors que l’Open Source vise avant tout à disposer de logiciels de qualité.

La première des libertés est celle de savoir ce que je fais

Ça paraît évident dans la vie de tous les jours : je sais ce que je fais. Si je décide de prendre une pelle et de planter un arbre dans mon jardin, je sais que je suis en train de prendre une pelle et de planter un arbre dans mon jardin. Si je décide de prendre un couteau et de le planter dans le thorax de mon voisin, je sais ce que je fais. C’est une liberté fondamentale, au sens où elle fonde toutes les autres. Si je ne sais pas ce que je fais, je ne peux signer un contrat, par exemple (c’est d’ailleurs le principe qui sous-tend le régime de la tutelle en droit). D’ailleurs, comme toute liberté, elle fonde une responsabilité. Si je ne savais pas ce que je faisais (et que je peux le prouver), je peux plaider l’abolition du discernement et échapper à ma responsabilité pénale, quelle que soit l’infraction commise, même les plus graves²

Dans la vie de tous les jours, donc, il est évident que je sais ce que je fais. Mais avec un ordinateur, c’est beaucoup moins évident. Quand j’exécute Windows, je ne sais pas ce que je fais. Pas seulement parce que je ne connais pas la séquence de boot, mais de façon beaucoup plus fondamentale : parce que n’ayant pas accès au code source, je ne sais pas ce que fait le programme que j’exécute. Ce qui pose un problème majeur de confiance dans le logiciel exécuté :

• Confiance dans le fait que le programme fait bien ce que son programmeur a voulu qu’il fasse (absence de bugs)
• Confiance dans le fait que le programmeur avait bien mon intérêt en tête et pas seulement le sien (sincérité du programmeur, fréquemment prise en défaut dans le logiciel non libre)

Dans le système des 4 libertés du logiciel libre, cette liberté est la liberté 1. Elle passe après la liberté 0 (liberté d’exécuter le programme) et avant la liberté 2 (liberté de redistribuer le programme). On pourrait légitimement discuter de sa priorité par rapport à la liberté 0 (est-il raisonnable d’exécuter un programme dont on ne sait pas ce qu’il fait ?) mais ça dépasserait l’objet de cette dépêche.

Si je sais ce que je fais, je dois pouvoir modifier ce que je fais

Conséquence logique de la liberté précédente : si je n’aime pas ce que fait un programme, je dois pouvoir l’améliorer. Si je ne sais pas le faire moi-même, je dois pouvoir payer quelqu’un pour l’améliorer. Là encore, ça suppose l’accès au code source, ne serait-ce que pour savoir ce que fait le programme. Il s’agit de la liberté 3 du logiciel libre.

Le réseau de neurones est difficilement compatible avec le libre

Personne ne sait vraiment ce que fait un réseau de neurones

On l’a vu, les réseaux de neurones présentent un effet boîte noire important. Déjà, la plupart des IA commerciales ne sont accessibles qu’au travers d’une interface ou une API. Elles n’exposent que rarement les neurones. Mais même pour une personne disposant de tous les neurones, autrement dit de la description complète du réseau, l’effet boîte noire est tel que le fonctionnement du réseau de neurones est inintelligible. D’ailleurs, s’il était intelligible, il serait très vite simplifié !

En effet, on peut recoder tout réseau de neurones dans un langage plus rapide, dès lors qu’on comprend ce qu’il fait (puisqu’il est Turing-complet). Vu la consommation astronomique d’énergie des réseaux de neurones, s’il existait un moyen de comprendre ce que fait un réseau de neurones et de le traduire dans un autre langage, on le ferait très vite. Ce qui fournirait d’ailleurs des réponses à des questions théoriques ouvertes comme : qu’est-ce que comprendre une phrase ? Comment reconnaît-on un chien, un visage, un avion ?

Disposer de la description complète d’un réseau de neurones ne permet pas de l’améliorer

On l’a vu : si je dispose de la totalité des neurones, je dispose de la totalité de la description du réseau de neurones. Mais comme je suis incapable de savoir ce qu’il fait, je ne suis pas plus avancé pour l’améliorer, qu’il s’agisse de retirer un défaut ou d’ajouter une fonctionnalité. Noter d’ailleurs que ceci n’est pas forcément impactant de la même manière pour tous les aspects du réseau de neurones : si je n’ai aucun moyen d’être sûr de l’absence de bugs (c’est même le contraire ! Il y a forcément des bugs, c’est juste que je ne les ai pas trouvés ou qu’ils ne sont pas corrigeables), j’ai en revanche peu d’inquiétude à avoir concernant la sincérité du programmeur : comme lui non plus ne maîtrise pas sa bestiole, pas de risque qu’il soit insincère³.

La définition du code source d’un réseau de neurones est ambiguë

Posons-nous un instant la question : qu’est-ce que le code source d’un réseau de neurones ? Est-ce la liste des neurones ? Comme on l’a vu, ils ne permettent ni de comprendre ce que fait le réseau, ni de le modifier. Ce sont donc de mauvais candidats. La GPL fournit une définition : le code source est la forme de l’œuvre privilégiée pour effectuer des modifications. Dans cette acception, le code source d’un réseau de neurones serait l’algorithme d’entraînement, le réseau de neurones de départ et le corpus sur lequel le réseau a été entraîné.

Cette ambiguïté fait courir un risque juridique sous certaines licences libres

Tu devines alors, cher lecteur, là où je veux en venir… Si le corpus comprend des œuvres non libres, tu n’as tout simplement pas le droit de le diffuser sous une licence libre ! Et si tu t’es limité à des œuvres libres pour entraîner ton modèle, tu risques fort d’avoir un ensemble d’apprentissage trop restreint, donc un réseau de neurones sans intérêt.

Alors il y a quatre moyens de tricher.
Le premier, c’est de t’asseoir sur la GPL et de considérer qu’en distribuant les neurones, tu as fait le taf. La ficelle est grossière. Je viens de passer une dépêche à te démontrer que c’est faux, tu pourrais au moins me montrer un peu plus de respect.

Le deuxième, c’est de distribuer sous une licence non copyleft, genre BSD ou WTFPL. Une licence qui ne nécessite pas de distribuer le code source. Certes, mais en fait tu ne fais pas du Libre.

Le troisième, c’est de considérer le réseau de neurones comme une donnée, pas un exécutable. Donc pas de code source. La partie sous GPL serait alors l’interface graphique, et le réseau, une donnée. C’est assez limite. Une donnée exécutable, ça s’approche dangereusement d’un blob binaire.

Le quatrième, c’est de repenser complètement le paradigme du logiciel libre et de considérer qu’il vise avant tout à rééquilibrer les rapports de pouvoir entre programmeur et utilisateur, et qu’en redistribuant les neurones, tu as fait le job. Sur les rapports de pouvoir, tu n’as pas tort ! Mais d’une part, ça ne tiendra pas la route devant un tribunal. D’autre part, il persiste une asymétrie de pouvoir : tu as accès au corpus, pas l’utilisateur.

Quand bien même on admettrait que le code source est l’ensemble corpus + algorithme d’optimisation + réseau de neurones de départ, l’optimisation d’un réseau de neurones consomme autrement plus de ressources que la compilation d’un programme plus classique, des ressources qui sont loin d’être à la portée du quidam classique. À quoi servirait un code source impossible à compiler ?

Enfin, même cette définition du code source pose problème : elle n’est en fait pas beaucoup plus lisible que le réseau lui-même. Ce n’est pas parce que j’ai accès aux centaines (de milliers) de textes sur lesquels un réseau a été entraîné que je peux prédire comment il va se comporter face à une nouvelle question.

Comment les boîtes qui font de l’IA non libre résolvent-elles ce dilemme ? Elles ne le résolvent pas

C’est presque enfoncer une porte ouverte que dire que l’IA pose de nombreuses questions de droit d’auteur, y compris dans le petit microcosme du non-libre. Cependant, les IA non-libres ont un avantage sur ce point : si le réseau de neurones ne permet pas de remonter au corpus initial (donc en l’absence de surapprentissage), alors elles peuvent tranquillement nier avoir plagié une œuvre donnée. Tu ne me verras pas défendre les pauvres auteurs spoliés, car j’ai toujours considéré que la nature même de l’information est de circuler sans barrières (Information wants to be free, tout ça) et que le droit d’auteur en est une, et particulièrement perverse.

La définition d’une IA open source ressemble furieusement à un constat d’échec

L’OSI a publié une définition d’IA open source. Cette définition mérite qu’on s’y attarde.

Premier point intéressant : après des années à tenter de se démarquer du Libre, notamment via la définition de l’Open Source qui tente de reformuler les 4 libertés sans recopier les 4 libertérs, l’OSI baisse les bras : est open source une IA qui respecte les 4 libertés.

Deuxième point intéressant : est open source une IA qui publie la liste des neurones, le corpus d’entraînement et la méthode d’entraînement. En fait, ça revient à ne pas choisir entre les neurones et leur méthode d’entraînement. Soit, mais ça ne résout pas le problème de l’effet boîte noire. Au mieux, ça revient à admettre qu’il est le même pour le programmeur et l’utilisateur.

Conclusion : qu’attendre d’une IA libre ?

Il ne fait aucun doute que développer des IA libres exigera de nouvelles licences. La GPL, on l’a vu, expose à un risque juridique du fait de l’ambiguïté de la définition du code source.

Il est à noter, d’ailleurs, qu’une IA repose rarement exclusivement sur son réseau de neurones : il y a systématiquement au moins un logiciel classique pour recueillir les inputs de l’utilisateur et les passer au réseau de neurones, et un second en sortie pour présenter les outputs. Ces briques logicielles, elles, peuvent tout à fait suivre le paradigme classique du logiciel libre.

En définitive, cher lecteur qui ne développes pas d’IA, je t’invite surtout à te demander : qu’attends-tu d’une IA ? Qu’entends-tu quand on te parle d’IA libre ? Plus fondamentalement, l’IA serait-elle un des rares domaines où il existe une distinction pratique entre libre et Open Source ?

Il n’y a pas de façon simple de faire une IA libre, il n’y a peut-être pas de façon du tout. Mais le principe du libre, c’est que c’est à l’utilisateur in fine de prendre ses décisions, et les responsabilités qui vont avec. Je n’espère pas t’avoir fait changer d’avis : j’espère modestement t’avoir fourni quelques clés pour enrichir ta réflexion sur le sens à donner au vocable IA open source qu’on voit fleurir ici et là.

Avec la numérisation très rapide des services administratifs français est arrivé le besoin d’authentifier et certifier à distance une personne faisant une démarche avec des outils numériques officiels.

La certification à distance est un problème déjà traité depuis longtemps sur internet. Que ce soit sur LinuxFr.org ou sur un site marchand, « s’enregistrer en ligne » est un acte banal pour beaucoup de monde, effectué machinalement pour certains, ou consciemment et mûrement réfléchi pour d’autres. Lorsqu’il s’agit d’élargir cette certification d’identité à l’ensemble de la population, afin qu’elle puisse accéder à des services auxquels tout à chacun à droit, on peut s’interroger sur les moyens mis en œuvre pour cela.

Puisqu’il s’agit de l’administration publique et non d’un service privé, ils devraient reposer sur des outils ouverts et auditables par la société civile, accessibles à toutes et à tous en termes de moyens et sans dépendances exagérées envers des tierces parties.

Sommaire

• Authentifier une personne vis-à-vis de l’administration publique
• Les problèmes posés
• Les solutions officielles
• Des solutions standard, accessibles et ouvertes !
• Des démarches pour alerter

Authentifier une personne vis-à-vis de l’administration publique

Pour valider certaines démarches le choix a été fait d’utiliser une application mobile : France Connect + à ne pas confondre avec « France Connect ». Le service « France Connect » quant à lui, permet l’authentification basique pour des sites administratifs que ce soit sur application mobile ou sur le web. Cette authentification par « France Connect » permet aux personnes d’accéder à des données sensibles le concernant : imposition, patrimoine, santé, etc.

L’application France Connect + est aujourd’hui obligatoire pour les démarches suivantes :

• CPF : Compte personnel de formation, formation ou certains permis ;
• ANTS : l'Agence Nationale des titres Sécurisé, procuration de vote… ;
• INPI : Institut national de la propriété industrielle, guichet unique… ;
• MaPrim'Renov

et exige d’avoir le dernier modèle de Carte Nationale d’Identité, comportant des données biométriques.

La facilité de mise en œuvre d’une application mobile pour l’authentification forte ne va pas sans contreparties qui n’ont pas toutes été prises en compte.

Les problèmes posés

Une application mobile imposée par l’administration aux usagers, devrait être développée pour tous les OS mobiles existants. Aujourd’hui, seuls les OS majoritaires, Android de Google et iOS d’Apple, parfois exclusivement dans leurs dernières versions, sont prises en compte, pour des raisons de coût et de temps.

Ceci exclut toutes les personnes ayant fait un choix différent, volontairement ou par contrainte personnelle : pas de smartphone, smartphone (système et matériel) spécifique adapté à un handicap, smartphone ancien toujours fonctionnel et pas envie d’y consacrer plus d’argent pour obtenir la dernière version du système, OS alternatif, etc.

Ces deux systèmes d’exploitation mobiles majoritaires étant américains, cela remet donc l’authentification pour des démarches officielles entre les mains et les CGV d’entreprises privées, hors d’Europe.

Entreprises dont vous pouvez vouloir ne pas dépendre parce que leurs conditions d’utilisation ne vous conviennent pas :

• obligation de créer un compte sur leur plateforme ;
• obligation de donner des informations personnelles à associer au compte (numéro de téléphone, e-mail de secours…) ;
• elles ont droit de vie et de mort sur vos données hébergées, sur votre compte qu’elles peuvent supprimer pour toute raison qu’elles estiment valable sans aucun recours possible [8] ;
• elles sont connues pour contourner régulièrement les lois sur la vie privée.

Cela pose aussi des problèmes techniques et de sécurité avec une identité validée qui se promène sur un appareil mobile qui peut être volé, perdu ou simplement hors d’usage.

On retrouve dans cette limitation les mêmes problèmes qu’à l’époque des applications PC liées à du matériel et développées uniquement pour le système commercial le plus connu, Windows. Parfois, pour le deuxième plus connu, MacOS, mais pas les autres ; de même que pour la certification DSP2 des banques qui oblige la double authentification forte ; ces dernières ayant choisi de développer chacune une application mobile privée, souvent indiscrète, au lieu d’utiliser les standards existants.

Ainsi, à ce jour, les applications bancaires ne sont disponibles que sur les deux plateformes mobiles déjà citées et leurs versions les plus récentes, laissant de côté de nombreuses personnes.

Les solutions officielles

Certains dossiers CPF peuvent apparemment être transmis par courrier, avec un délai élevé pour leur prise en compte. [2]

L’INPI suggère d’utiliser les services de sociétés tierces [4], payants et difficiles à utiliser [9], parfois hors Europe et demandant aussi l’utilisation d’un smartphone pour certaines.

Cela ne résout donc rien et les sommes demandées peuvent être importantes pour une signature électronique certifiée eiDAS alors que l’application mobile officielle et son utilisation sont gratuites.

Comme le racontent les journaux en lien certaines démarches proposent des alternatives hors France Connect + mais qui demandent quand même un smartphone Android / iOS !

L’identité numérique de La Poste demande aussi un smartphone dans les mêmes conditions, la validation en bureau de poste ou à domicile se fait avec leur application, encore une fois Android et iOS puis l’application France Connect + ; les agents ne sont pas formés pour répondre à des demandes de solutions alternatives hélas.

Des solutions standard, accessibles et ouvertes !

Comme souvent, tout ce que nous souhaitons c’est la possibilité d’utiliser tous ces services officiels et publics avec nos logiciels de choix, accessibles à toutes et tous ; avec tout autant de sécurité et de praticité que les autres solutions.

Il existe déjà des standards pour la double authentification, pas toujours pris en charge hélas. La même chose devrait pouvoir être faite pour l’authentification forte.

L’idéal serait une plateforme standardisée, publique, auditable, qui permettrait d’utiliser des protocoles standards et sécurisés avec le logiciel/matériel de notre choix.

Des démarches pour alerter

Voici un état des lieux assez rapide pour intéresser au sujet et regrouper les témoignages éventuels, des solutions qui fonctionnent ou ne fonctionnent pas.

L’objectif maintenant, en plus d’avoir pour chacune des personnes concernées une solution qui fonctionne rapidement, d’alerter sur cette fracture numérique créée par des décisions politiques ; ce n’est pas une fracture naturelle liée à une différence de générations : celles nées avec le numérique et celles qui ne le sont pas. Il faut la traiter aussi mais ce n’est pas la même chose.

Si vous avez des suggestions pour attirer l’attention sur ce sujet, n’hésitez pas à vous exprimer :)