À 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 résolutions…
• 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 :

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.

✅️ = 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 fournit 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 était 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 résolutions…

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 résolutions 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 !

🥂🍾

ThierryM : suite à un besoin exprimé par les enseignant⋅es d’une école et la découverte de SQLPage à travers l’application École Inclusive que j’ai découverte via ce site, je me suis lancé dans la réalisation d’une application en ligne permettant de suivre — sur toute leur scolarité dans le 1^er degré — les différentes aides proposées aux élèves rencontrant des difficultés.
Bien que cette application soit encore en cours de développement et de test, je relate ici mon retour d’expérience car SQLPage, qui évolue rapidement, mérite d’être plus largement connue.

Jusqu’à présent je n’avais jamais osé me lancer dans ce genre de développements — principalement à cause de la sécurisation des accès et à la gestion de bases de données — mais SQLPage est arrivé…

Sommaire

• Besoins et cahier des charges
• Début de l’aventure
• Matériel, données techniques et application ASDAEL
• Utilisation locale due au RGPD et à la sécurisation des données
• Captures d’écran
• Perspectives

Besoins et cahier des charges

Le directeur d’une grosse école (13 classes + ULIS) avait besoin de pouvoir suivre pluriannuellement les différentes aides mises en place pour les élèves rencontrant des difficultés, ceci afin que les enseignant⋅es (dont les membres du RASED) disposent d’un historique pour voir ce qui avait déjà été proposé et ainsi décider ce que l’on pourrait mettre en place sans perdre de temps ni redite. Bref, l’idée était de gagner en temps et en efficacité.

Au niveau d’une seule école, un tableur LibreOffice Calc pouvait très bien faire l’affaire et suffire (ce classeur existe d’ailleurs) mais il ne pouvait pas être complété à distance et de façon collaborative facilement :

On aurait pu mettre en place un classeur sur le Nuage-Nextcloud des Apps Éducation proposé par l’Éducation nationale et travailler de façon collaborative en ligne ou en drive (pour profiter des macros). Mais cette solution n’est pas aisée à mettre en place, avec des problèmes de synchronisation et des conflits de version de fichiers (je le sais par expérience, car nous gérons l’absentéisme de cette façon et ça demande un gros accompagnement, chaque classe ayant son propre classeur que l’on doit retravailler par la suite pour faire des synthèses d’école).

L’idée était donc de disposer d’une application Web, en ligne pour que les enseignant⋅es puissent intervenir, compléter les données facilement et directement.
L’avantage de cette solution était aussi de disposer d’une application unique pour étendre par la suite son utilisation aux 4 écoles de la ville (voire d’une circonscription) si le projet est concluant : en effet, les infos des élèves de maternelle suivraient lors du passage à l’école élémentaire.
Seulement voilà, se posent pas mal de contraintes notamment par rapport à la sécurisation des données et au niveau du RGPD, l’outil envisagé contenant des informations sensibles. Il était impossible d’envisager un développement en Html/CSS/Javascript/PHP de zéro (manque de temps et de compétences). Et c’est là, que j’ai découvert l’existence de SQLPage qui paraissait répondre à nos inquiétudes avec des accès sécurisés, tout en étant à la portée de « débutant⋅es », à travers le récit de l’auteur de l’application « École Inclusive ».

Début de l’aventure

L’application « École Inclusive », bien que conçue pour le second degré, pouvait être adaptée à nos besoins plus modestes et a donc servi de base de départ : c’est beaucoup plus facile de partir de l’existant que d’une page blanche où il faut tout construire. Il s’est avéré que nous n’avions pas besoin de toutes les fonctionnalités et qu’il a fallu reprendre les logiques de fonctionnement mais la base étant là, c’était très rassurant d’autant que l'auteur de « École Inclusive » et le concepteur de SQLPage, très disponibles, étaient là pour m’éclairer, me conseiller ou rajouter des fonctionnalités au fil de mes demandes via les pages GitHub de leur projet respectif. Il faut rajouter que le site de SQLPage, conçu avec SQLPage ;-), regorge de ressources avec une documentation (en anglais) très claire et facilitante avec des exemples.
Il est vrai que ce concept de programmation est assez déstabilisant au début : ne passer que par des fichiers .sql (ou presque) pour développer un site Web, ça paraît inadapté. Mais, une fois qu’on est rentré dedans, on se rend compte que pour le type d’application qu’on recherchait, c’est tout bonnement bluffant et terriblement efficace.
Ce qui est aussi facilitant, c’est la possibilité d’utiliser des bases sqlite ne nécessitant pas la mise en place d’un serveur de type MySQL ou PostGreSQL rajoutant de la complexité. Mais SQLPage fonctionne aussi avec ces serveurs si on en a l’utilité : ce point est intéressant, car le temps consacré pour se former à SQLPage pourra être réinvesti avec d’autres types de bases de données.

Matériel, données techniques et application ASDAEL

Pour des tests les plus proches du fonctionnement prévu (on verra que ça changera), j’ai utilisé un NAS perso Synology 713+ sous DSM 7.1 avec un accès extérieur. Toutes les infos sont là pour ceux et celles que ça intéresse : https://lofurol.fr/joomla/logiciels-libres/104-bases-de-donnees/349-sqlpage-utilisation-sur-un-nas-synology-avec-docker-et-mysql-postgresql-sqlite.
Toujours dans un souci de partage, les sources de l’application de suivi des aides sont disponibles sur la « Forge des communs numériques éducatifs » ou Forge Éduc, le GitLab mis à disposition par l’Éducation nationale pour favoriser le partage et le développement de ressources numériques pour l’enseignement.
Source du projet: https://forge.apps.education.fr/thierrym/suivi-aides-eleves-ecoles

Utilisation locale due au RGPD et à la sécurisation des données

Cette application n’ayant pas reçu de soutien officiel et vu qu’elle contient des données sensibles sur les élèves (bien que ces données ne soient accessibles qu’aux seul⋅es enseignant⋅es concerné⋅es par le suivi des élèves), il a été décidé de ne pas exposer l’application sur Internet, comme prévu initialement. Elle sera donc installée sur un ordinateur localement sans accès de l’extérieur le temps de la tester. Après, il sera toujours possible d’évoluer vers une utilisation réellement en ligne si les essais sont concluants (et avec un audit sur la sécurité).
Et là, encore une fois, l’application est très bien faite, car elle fait office de serveur web et il suffit de saisir son adresse ip sur le port 8080 pour y accéder à partir d’un autre ordinateur sur le même réseau. On ne peut pas faire plus simple (pas besoin de se monter un serveur Apache/Ngnix) !!!

Pour lancer l’expérimentation, j’ai récupéré un “vieil” ordinateur HP 260 G2 Mini (Intel Pentium 4405U, 4 Go de Ram et HD de 100 Go) sur lequel j’ai installé Ubuntu 24.04 Server (avec accès SSH) avec le bureau Mate et Docker pour faire fonctionner les conteneurs Portainer et Adminer pour éventuellement agir sur la base de données SQLite.
J’ai ensuite installé SQLPage avec mes fichiers dans un dossier « ASDAEL » à la racine de mon home puis configurer un démarrage automatique lançant SQLPage et Firefox pointant vers la page « localhost:8080 ».

Captures d’écran

Structure de la base de données

Page d’accueil :

Page de connexion :

Localisation des écoles :

Liste des élèves suivi⋅es :

Fiche individuelle de suivi :

Vue synthétique du parcours de l’élève :

Page de paramétrage :

Perspectives

Avec l’arrivée du Livret de Parcours Inclusif (LPI) peut-être que ce genre d’applications ne sera plus utile… d’autant qu’elles n’ont aucun soutien institutionnel et qu’en l’état actuel elles ne peuvent être utilisées que localement, ce qui réduit pas mal leur intérêt.
Mais l’idée de ASDAEL est d’obtenir rapidement une vision synthétique des différentes aides mises en place pour l’ensemble des élèves tout au long des années en facilitant leurs saisies, ce que ne permettra certainement pas le LPI.
À suivre… ?

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

Grâce à la diversité des profils, cela permet de voir le fonctionnement du projet Fedora sous différents angles pour voir le projet au-delà de la distribution mais aussi comment il est organisé et conçu. Notons que sur certains points, certaines remarques restent d’application pour 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 de la chance d’avoir suffisamment de contributeurs et des contributrices de qualité pour permettre d’avoir 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 Kévin Raymond (pseudo shaiton), ancien contributeur de Fedora et de Fedora-fr.org.

Sommaire

• Conclusion

Bonjour Kévin, peux-tu présenter brièvement ton parcours ?

Perso ? Au sein de la communauté ? C’est un peu trop large pour être bref… Curieux et créatif, j’ai découvert l’informatique, l’électronique et la programmation au Lycée. J’ai eu la chance que mon père fasse le choix de Linux pour moi et s’occupe de mes premières installations… Voire configuration matérielle. Au début il fallait Internet pour configurer Internet (recompilation de pilotes de périphériques) c’était un beau casse-tête sans personne pour vous aiguiller. Bon OK si on remet dans l’ordre au tout début il n’y avait pas la problématique du Wi-Fi. J’ai poursuivi mes études par un DUT GEII (Génie Électrique et Informatique Industrielle) en poursuivant sur une licence puis une école d’ingénieur électronique/informatique en alternance. Plus les années passaient, plus j’avais de projets informatiques ou électroniques perso ou professionnels à réaliser et plus je m’éloignais du monde Windows, plus je me sentais chez moi sous Linux.

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

Initialement traducteur francophone, j’en suis arrivé à être le coordinateur principal de l’équipe francophone. J’ai également contribué à l’internationalisation des sites internet du projet Fedora. Ce qui m’a amené à en être un des mainteneurs principaux pendant quelque temps et de m’occuper du déploiement des nouvelles versions à chaque nouvelle sortie de version de Fedora. De là j’ai intégré l’équipe infrastructure afin de pouvoir suivre ou déclencher les mises à jour des sites. Étant un des traducteurs principaux, j’ai rejoint l’équipe documentation pour la même raison que l’équipe site internet : améliorer le déploiement des traductions. Et c’est également pour les traductions que je suis devenu coordinateur Transifex, une des plateformes de traduction utilisée un temps par le projet. Il a fallu accompagner les développeurs pour la migration et assurer le suivi du déploiement. Le problème principal étant qu’un développeur ne se rend pas compte qu’une traduction est disponible ou même qu’elle n’est pas inclue dans sa dernière version. Ayant un pied dans pas mal de portes, j’en suis venu à aider la coordination de chaque sortie de versions de Fedora. Ça c’est pour la partie productivité, mais il y a la partie sociabilité qui est une part importante de la vie d’un contributeur. Je suis devenu ambassadeur du projet Fedora jusqu’à en devenir un mentor. J’ai également intégré le bureau de l’association Fedora-Fr, devenue Borsalinux-Fr lors de mon mandat. J’ai dirigé quelque temps la production de goodies pour l’équipe FR, les réunions hebdomadaires et co-organisé une rencontre internationale à Paris − le FUDCON − après en avoir été plusieurs fois un participant actif (aux États-Unis, Italie, Suisse).

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

Pour le produit, c’était « Fedora Core » à l’époque : pour la nouveauté. Les distributions GNU/Linux étaient en plein développement, beaucoup de nouveautés arrivaient chez l’un avant l’autre. J’en ai essayé plusieurs et j’ai beaucoup aimé les choix proposés sous Fedora Core, j’y suis resté depuis 2005 (au moins en perso, si l’entreprise ne me laissait pas le choix).

Pourquoi contribuer à Fedora en particulier ?

Quant au projet et bien c’est parce que le produit me plaisait que tout naturellement c’est là que j’ai participé. Autant contribuer à ce dont on se sert tous les jours. Bon je dois quand même dire que c’est le programme d’ambassadeur qui m’a permis d’être inclus. Les forums d’entraide je voyais plutôt ça comme un mal nécessaire. En arrivant sur Paris, j’ai eu la chance de pouvoir rencontrer physiquement des passionnés prêts à vous écouter et vous aiguiller sur vos aspirations. Merci à Mathieu Bridon (dit « bochecha ») sans qui je serai resté de l’autre côté de la fenêtre.

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

Très et trop peu. Je maintiens la traduction du logiciel GNU Make. D’ailleurs il me faut la rafraichir depuis la dernière mise à jour. J’en suis devenu le mainteneur parce que le précédent ne répondait plus et que la traduction actuelle ne me convenait pas. Si quelqu’un veut le reprendre je m’en sépare bien volontiers ! Ensuite j’ai des contributions ponctuelles sur mes interactions professionnelles. Principalement pour du correctif je n’ai pas une part active malgré mon envie. J’essaye autant que possible de tester les nouvelles versions de Fedora dès la version Alpha. Grâce à ma connaissance de Fedora, j’ai intégré le projet OLPC France où j’ai pu apporter mon expertise « Fedora » pour les outils de sauvegarde et mise à jour des XO (nom des ordinateurs portable du projet OLPC basés sur la distribution GNU/Linux Fedora). Et je suis même allé à Madagascar gérer le déploiement d’une mise à jour distribution de l’ensemble d’un parc. Expérience très enrichissante.

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

Oui autant que possible. C’est mon univers, je maîtrise l’environnement et je n’ai pas besoin de chercher comment faire telle ou telle actions ce qui est bien plus rapide. J’apprécie aussi énormément les choix proposés par défaut. GNOME et son mode non intrusif me permet de rester concentré sur le principal (en espérant que la proposition du choix par défaut KDE ne sera pas acceptée…) Mais c’est aussi parce que Fedora fait partie de moi, je me suis construit avec le produit, avec le projet et avec la communauté. C’est comme quitter son pays natal, on peut le faire, mais on n’est plus chez nous. Je me sens très bien sous Fedora et si je veux aider, corriger ou contribuer, je sais déjà comment m’y remettre.

Est-ce que tes contributions à Fedora sont un atout direct ou indirect dans ta vie professionnelle ? Si oui, de quelle façon ?

C’est un atout direct bien évidemment. Étant ingénieur en systèmes embarqués Linux, autant maîtriser l’environnement qui permet de répondre au besoin de l’entreprise. Dans l’entreprise on doit répondre à un besoin. Et pour ça l’humain invente des outils. S’il ne maîtrise pas ses outils il est moins productif et perd une part de ses capacités pour s’adapter à son environnement. D’un autre côté, j’aime le produit Fedora (peut-être maintenant surtout pour la Communauté) et travailler sous Fedora c’est vouloir se lever le matin et être accueilli par quelque chose qui nous fait plaisir. C’est devenu important pour mon bien être.

Tu as été actif sur de nombreux projets de Fedora durant quelques années tout en étant non employé de Red Hat, est-ce que cela a été un frein dans ta participation d’une quelconque façon ?

Absolument pas. J’étais assez pris par toutes mes contributions pour ne pas chercher à vouloir faire de la politique. Il y avait déjà assez de Gourous dans l’équipe française pour que je ne m’y colle pas. Au travers de Red Hat j’ai trouvé du soutien, des conseils et du professionnalisme. Mais également des amis.

Qu’est-ce que tu as fait plus exactement pour l’infrastructure et les sites web du projet Fedora ?

Pour les sites web, j’ai cherché à faire en sorte que mes traductions soient utilisées, déployées. C’est bien beau de passer ses nuits à traduire plutôt que dormir ou réviser, mais si le jour J la traduction n’est pas utilisée, à quoi cela sert-il ? Et si on te répond « arf, si ça avait été publié 12h plus tôt ça aurait apparu, maintenant il faut attendre le prochain déploiement dans 6 j » ça frustre. Et parfois ce n’est pas qu’une question de date c’est aussi un problème de code. Le développeur ne sait pas qu’une traduction est disponible, il ne l’utilise donc pas. J’ai donc pris en charge la synchronisation des équipes de traduction avec la génération des différents sites. J’ai créé des outils et modifié les process de déploiement des sites afin que les traducteurs soient au courant des dates et que l’équipe sites web déploie automatiquement les traductions sans étapes manuelles inutiles. Côté infra j’étais là pour seconder l’équipe sur le déploiement des sites internet. Je pouvais déployer moi-même la version de test du site fedoraproject.org afin que les traducteurs puissent relire leurs traductions et soumettre des problèmes/correctifs avant le déploiement le jour J (pour rappel une nouvelle version tous les 6 mois). En tant que coordinateur principal de l’équipe de traduction francophone, j’étais aux premières loges pour corriger les problèmes et indiquer la procédure de test aux autres équipes.

Tu as aussi géré la traduction quelques années entre Thomas Canniot et Jean-Baptiste Holcroft, qu’est-ce qui t’a attiré dans cette activité et qu’est-ce que tu as fait ?

Ça a été entre mon année d’étude en Écosse ou j’ai beaucoup amélioré mon anglais et ma première année d’école d’ingénieur à Paris. Si j’ose l’annoncer à voix haute, j’ai eu beaucoup de temps perso lors de mes années d’école d’ingénieur c’est grâce à tout ce temps libre que j’ai pu plonger dans le projet Fedora. Et Matthieu, mon mentor m’a correctement accompagné pour trouver là où je serais le plus utile, l’équipe de traduction où Thomas s’est quasiment retrouvé tout seul. Il gérait une équipe d’1,5 personne en se comptant lui-même. Je suis arrivé et à deux on a abattu un travail énorme pour rattraper les dérives. Je traduisais puis lui me corrigeait. Je venais de loin, il a fallu attendre mes 24 ans que je découvre la grammaire française, les règles d’accord COI/COD… Bon ce n’était pas très fun alors je me suis spécialisé sur la syntaxe. À deux nous avons recruté d’autres traducteurs, ensuite il a vu qu’on était une équipe, il m’a laissé la main sur la traduction. J’ai vécu 2 transitions d’outils de gestion des traductions. J’ai donné beaucoup d’effort sur le projet Transifex. Jusqu’à ce que ce projet se tourne vers un modèle commercial et que le projet Fedora change d’outil. Là je me suis dit que je ne voulais pas recommencer, j’avais des projets de refonte de tout l’outil de déploiement des sites internet. L’équipe de traduction n’était plus mon sujet prioritaire. Je ne sais même plus comment Jean-Baptiste a pris la main, mais à un moment donné les projets ont migré sur le nouvel outil, et moi j’ai perdu tout ce que j’avais mis en place. Mes outils ou scripts permettant d’obtenir les dernières traductions, d’obtenir le pourcentage de complétion de traduction de chaque langue sur chaque projet. Je n’ai plus rouvert cette porte j’ai laissé la main et je me suis concentré uniquement sur la relecture et la formation des nouveaux : habitudes de traduction pour la cohérence de l’historique, utilisation de la bonne syntaxe. Jusqu’à ce qu’on ne me voie plus contribuer sur la liste de diffusion. En résumé, j’avais le développement des sites qui était prioritaire, j’avais de moins en moins de temps à accorder, une équipe de jeunes (pas dans l’âge mais dans la date d’arrivée dans l’équipe de traduction francophone) et un changement d’outil et de process qui m’ont tout naturellement écartés de mes responsabilités.

En 2012, le FUDCon (devenu Flock depuis) s’est tenu à Paris et tu en as été l’un des principaux organisateurs. Peux-tu expliquer le but de ces rencontres et de leur importance ? Quelles ont été les difficultés d’une telle organisation ? Quels souvenirs en retires-tu ?

Le FUDCon était un événement annuel (par région) qui était l’occasion pour les contributeurs de se rencontrer pour mieux se connaître mais aussi pour avancer plus rapidement sur des points particuliers et abolir les fuseaux horaires. C’était également l’occasion de rencontrer les « Redhatters ». C’est également lors de ces événements qu’on rapproche tous les organes de la communauté. Les rencontres physiques sont très importantes. Beaucoup d’échanges dans la communauté se passent en anglais, dont c’est la langue maternelle pour une grande partie. Il est parfois difficile de cerner le ton employé à l’écrit par un individu − oui toutes nos réunions étaient en chat/IRC −, c’est lors de rencontre de ce genre qu’on peut cerner le caractère d’un individu et comprendre quand il est sérieux, ironique ou espiègle. C’est aussi l’occasion d’échanger sur la vie, d’autres sujets qui ne sont pas ceux de tous les jours. Ou ouvre notre horizon. Lors de mon premier FUDCon à Zurich, j’étais tout jeune arrivé dans le projet. Je n’avais pas grand-chose à dire mais beaucoup à apprendre. Et plus je me rapprochais de l’équipe France, plus j’entendais que la communauté rêverait d’un événement en France, à Paris. Alors un jour, un peu poussé, on a monté une petite équipe pour cet événement. Il a fallu choisir une date, trouver un lieu, proposer des logements et réaliser toute la logistique :

• créer des goodies pour faire de petits cadeaux pour que les contributeurs puissent repartir avec un beau souvenir (t-shirt « tour Eiffel » et dessous de verre réutilisables)
• gérer les subventions des contributeurs, s’ils proposaient un sujet (talk) ils pouvaient bénéficier d’une subvention par Red Hat
• trouver un traiteur
• coordonner l’équipe d’orga…

J’ai rencontré pas mal de nouvelles difficultés. C’est la première fois que je gérais (en partie) un budget autre que le mien. Mais c’est également la première fois qu’on comptait sur moi — physiquement — à une si grande échelle. L’équipe d’organisation s’est principalement tournée autour des membres de l’association Borsalinux-Fr, mais on avait bien entendu des personnes en charge côté « Red Hat » sur qui se reposer puisque cet événement était sponsorisé tous les ans sur les différentes régions (Amérique, Asie, EMEA). N’oubliez surtout pas que dans EMEA il y a Europe, mais également Afrique. Ahhhh l’Afrique. C’est loin et dans l’espace et dans la culture. Je me souviens d’un appel le matin de l’événement. « Salut Kévin, j’ai raté mon avion, tu peux me trouver un autre vol » ? Oui, c’était un contributeur dont le billet d’avion était payé complètement sur le budget subvention de l’événement. Et ça paraissait naturel pour lui que je lui paie un nouveau billet pour l’avion qu’il avait raté parce qu’il est arrivé en retard à l’aéroport… Bon il a choisi de prendre lui-même le nouveau billet, il est venu et on a passé de bons moments ! C’était un des contributeurs les plus actifs de sa région à cette époque. Autre problématique plus ennuyante au long terme : j’ai utilisé mon adresse de courriel perso pour réserver le traiteur. Et je ne sais pas ce qu’il a fait, mais il s’est enregistré avec ma propre adresse de courriel sur une liste quelque part, et depuis 12 ans je reçois des courriels en tant que gestionnaire de cette entreprise. J’ai des candidatures spontanées pour des comptables, je reçois des promotions pour acheter des sardines en gros, je reçois des nouvelles de la mairie de Paris… Ça c’est pénible. Mais j’avais à l’époque l’alias de courriel @fedoraproject.org et j’aurai dû écrire avec mon contact « pro » plutôt que perso. On apprend beaucoup en contribuant dans les projets communautaires ! Finalement, avoir organisé cet événement m’a donné de l’expérience pour organiser le même genre d’événement au sein du projet OLPC — One Laptop Per Child.

Tu as aussi beaucoup rédigé et géré le magazine francophone Muffin, peux-tu nous expliquer en quoi ça consistait et ce que tu as fait ? Que penses-tu de ce format et du travail réalisé ?

Muffin c’était incroyable. Depuis mes années d’études où je devais rédiger des rapports et présenter du contenu d’une manière très formelle, j’ai appris à rédiger en LaTeX. Je pensais savoir, connaître et comprendre. Quand j’ai vu ce que mettait en place melmorabity (Mohamed El Morabity) pour le rendu, j’étais obligé de rester pour en apprendre plus ! J’ai surtout participé à la rédaction du numéro 3. C’est l’occasion de mettre en avant des nouveautés, d’anticiper sur les demandes qui vont venir dans les forums et de présenter du contenu de qualité à nos utilisateurs. J’étais tous les premiers samedi du mois aux PSL à la Cité des Sciences à Paris. C’était une rencontre mensuelle (peut-être a-t-elle encore lieu ?) où plusieurs contributeurs de plein de communautés différentes venaient à la rencontre de leurs utilisateurs. Ce magazine avait une cible de plus. C’était également quelque chose qu’on était fier de mettre en avant lors des différents salons que nous représentions (FOSDEM, Solution Linux…) Fedora misant sur les nouveautés, il est important qu’on utilise différents moyens pour annoncer les changements aux utilisateurs. C’était un moyen de plus.

Par ailleurs à la même période il y avait je crois un Linux Pratique Essentiel dédié à Fedora 13 sortie vers 2011-2012 qui a impliqué de nombreux rédacteurs de la communauté francophone dont toi. Peux-tu revenir sur cette expérience ? Quelle a été la plus-value de travailler avec un éditeur pour créer ce magazine payant ?

Hum, ça me dit quelque chose, mais je n’en ai plus aucun souvenir. J’ai peut-être très peu contribué dans ce magazine ? Je me souviens plutôt de ma première rencontre avec mon mentor, au 42 de je ne sais plus quelle rue à Paris. C’était pour un live sur Radio Libertaire pour ensuite aller à une rediffusion d’une conférence de RMS dans un lieu plein d’idées nouvelles… Y a pas à dire il se passe plein de chose à Paris !

Tu t’es ensuite mis en retrait de la communauté francophone après 2013, pour quelles raisons ?

Plus j’en faisais au sein de la communauté Fedora, plus j’étais en capacité d’en faire plus. Je n’arrêtais pas d’interagir avec les différentes équipes pour améliorer la productivité, réduire les freins rencontrés par différents contributeurs, améliorer la collaboration. Sauf qu’au bout d’un moment, on entend les oiseaux chanter par la fenêtre et on se dit « mince, c’est déjà le matin ? » aller il faut aller chercher une ou deux heures de sommeil avant d’attaquer le boulot. Celui pour lequel on est payé. J’ai passé des semaines à plus de 30h de contribution sur les projets libres. Avec le boulot à plein temps à côté. Je n’étais pas le seul, mais si en plus on se disperse dans trop de sujets on ne peut pas tous les suivre complètement. Et si en plus on est à Madagascar avec une connexion internet limité, que ça coïncide avec le déploiement d’une nouvelle version et que c’est habituellement toi qui appuies sur le bouton ? Et bien tu trouves un « jeune » tout fou que tu formes et qui passe autant de temps avec toi sur internet qu’avec sa famille, tu lui confies la tâche d’appuyer sur le bouton et d’utiliser en prod tout le process de déploiement que tu viens de changer et activer après 2 mois de refonte complète. Tu te rends compte que ça se passe bien sans toi, que ça tourne, qu’il est fiable. Tu es rassuré et tu te dis « je me suis libéré d’une charge, qu’elle est ma prochaine priorité ? » Merci à Robert Mayr (robyduck) pour cette belle succession ! À ce moment j’ai également quitté Paris pour revenir dans mes montagnes (Haute-Savoie). J’ai intégré un nouveau travail dans lequel j’ai mis tout mon temps et même plus. Je n’ai plus eu l’occasion de rencontrer les collaborateurs du projet Fedora aussi souvent et j’ai décroché. Oui j’ai trop donné pour mon entreprise à l’époque pour ce qu’elle me rendait, mais ayant relâché les rennes de la traduction FR et des sites internet, je me suis redirigé vers le loisir en montagne ce qui m’a permis de passer moins de temps sur l’ordinateur. Je n’avais plus non plus de contacts réguliers avec des gurus de l’informatique : ceux qui vous tirent vers le haut. J’avais beaucoup de connaissances sur la collaboration que j’ai acquises au sein du projet à mettre en place dans mon entreprise. Finalement, j’ai continué mes « contributions libres » mais en tant que bénévole, je suis maintenant formateur en alpinisme. Je passe beaucoup de mon temps libre dans une autre association qui n’a plus de lien avec Fedora si ce n’est le bénévolat.

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 ne suis plus au fait des axes politiques Fedora/Red Hat, je ne sais pas à quel point le rachat de Red Hat a influé sur le projet Fedora même si j’ai vu passer quelques messages sur ce contexte. Je trouve que certains aspects sont trop éparpillés. J’ai vécu (à côté sans être contributeur) le développement de la forge Pagure (hello pingou !) mais également le choix de certains projets de partir sur GitLab ou GitHub. Il y a des avantages et des inconvénients. Personnellement, j’ai découvert Gerrit et tout ce que ça permet. Je l’ai moi-même mis en place dans mon nouvel emploi en 2014. Dès cet instant je n’ai plus réussi à contribuer au projet Fedora. Les outils utilisés étaient un frein pour moi je ne pouvais plus suivre les développements aussi facilement. Donc si je devais changer quelque chose dans le projet, on passerait tout sous Gerrit. Ok je n’ai pas répondu à la vraie question qui concernait le produit… Wayland, systemd ? Non non la politique ce n’est pas pour moi, j’aime avancer et ma première et dernière modification si ce n’est la traduction c’est l’activation de la console en 256 couleurs par défaut. Ça me suffit je vis très bien avec !

À 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 ?

J’aime me dire que c’est un produit qui évolue avec sa communauté et non pas avec une entreprise. Ce que je souhaite conserver, c’est les quatre fondations : Freedom, Friends, Features, First. Les nouvelles fonctionnalités étant ce que j’apprécie beaucoup. Je suis du genre à désactiver les mises à jour auto et aimer déclencher moi-même les mises à jour afin de surveiller tout ce qui arrive.

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’en fais plus partie, j’aimerais. Mais je n’arriverai pas à retrouver le même sentiment en restant à distance, le contact physique ou régulier avec les contributeurs me manque. Mais de la même manière que la plongée ou le parapente me manquent. On n’a qu’une vie et elle est remplie de choix.

Quelque chose à ajouter ?

Merci beaucoup à vous d’être encore actif, aux nouveaux d’avoir pris la relève et à tout le monde de continuer à contribuer pour ce produit. C’est tous les jours que je pense aux milliers de contributeurs Fedora et aux centaines de contributeurs que j’ai connus personnellement.

Merci Kévin pour ta contribution !

Conclusion

Nous espérons que cet entretien vous a permis d’en découvrir un peu plus sur le projet Fedora et Fedora-fr.

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 Aurélien Bompard, développeur au sein du projet Fedora et employé Red Hat affecté au projet Fedora en particulier dans l’équipe infrastructure.