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

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

L’intelligence artificielle (IA) fait couler de l’encre sur LinuxFr.org (et ailleurs). Plusieurs personnes ont émis grosso-modo l’opinion : « j’essaie de suivre, mais c’est pas facile ».

Je continue donc ma petite revue de presse mensuelle. Disclaimer : presque aucun travail de recherche de ma part, je vais me contenter de faire un travail de sélection et de résumé sur le contenu hebdomadaire de Zvi Mowshowitz (qui est déjà une source secondaire). Tous les mots sont de moi (n’allez pas taper Zvi si je l’ai mal compris !), sauf pour les citations: dans ce cas-là, je me repose sur Claude pour le travail de traduction. Sur les citations, je vous conseille de lire l’anglais si vous pouvez: difficile de traduire correctement du jargon semi-technique. Claude s’en sort mieux que moi (pas très compliqué), mais pas toujours très bien.

Même politique éditoriale que Zvi: je n’essaierai pas d’être neutre et non-orienté dans la façon de tourner mes remarques et observations, mais j’essaie de l’être dans ce que je décide de sélectionner ou non.

Sommaire

• Résumé des épisodes précédents
• OpenAI dévoile Codex et codex-1
• Google I/O 2025
• Anthropic publie Claude 4
• En vrac
• Pour aller plus loin

Résumé des épisodes précédents

Petit glossaire de termes introduits précédemment (en lien: quand ça a été introduit, que vous puissiez faire une recherche dans le contenu pour un contexte plus complet) :

• System Card: une présentation des capacités du modèle, centrée sur les problématiques de sécurité (en biotechnologie, sécurité informatique, désinformation…).
• Jailbreak: un contournement des sécurités mises en place par le créateur d’un modèle. Vous le connaissez sûrement sous la forme "ignore les instructions précédentes et…".

OpenAI dévoile Codex et codex-1

Les modèles actuels commençant à être relativement compétents sur les tâches de programmation, la ruée vers l’or arrive : comment en faire de véritables programmeurs, autonomes ou semi-autonomes ?

La première génération consistait à poser des questions à l’IA sur l’interface de chat, et copier-coller des bouts de code, ainsi que d’assistants à l’auto-complétion.

La seconde génération, Aider (open-source), Cline (également), Cursor, Claude CLI ou Codex CLI consistait à donner un accès direct à votre projet à l’IA, lui permettant de consulter et d’éditer le code ; soit intégré à un IDE, soit en ligne de commande.

La troisième génération revient aux racines de la première, où l’interface entre l’utilisateur et l’IA est à nouveau un simple chat dans le navigateur. Mais cette fois, l’IA clone votre projet dans un environnement de développement virtualisé et travaille dans cet environnement. Vous pouvez la superviser, ou la laisser travailler quelques temps.

C’est en tout cas ce que propose OpenAI avec Codex. L’annonce officielle :

Today we’re launching a research preview of Codex: a cloud-based software engineering agent that can work on many tasks in parallel. Codex can perform tasks for you such as writing features, answering questions about your codebase, fixing bugs, and proposing pull requests for review; each task runs in its own cloud sandbox environment, preloaded with your repository.

Traduction :

Aujourd'hui, nous lançons un aperçu de recherche de Codex : un agent d'ingénierie logicielle basé sur le cloud qui peut travailler sur de nombreuses tâches en parallèle. Codex peut effectuer des tâches pour vous telles que l'écriture de fonctionnalités, répondre à des questions sur votre base de code, corriger des bogues et proposer des demandes de fusion pour révision ; chaque tâche s'exécute dans son propre environnement sandbox cloud, préchargé avec votre dépôt.

OpenAI couple cette sortie avec un modèle spécialisé pour la programmation, codex-1, avec sa System Card (pas très intéressante, mais notons qu’elle a le mérite d’exister).

La force de ce mode de fonctionnement est le parallélisme : vous pouvez demander à l’IA de travailler sur plusieurs choses à la fois, voire lancer plusieurs sessions pour la même tâche et choisir le meilleur résultat.

Les réactions sont mitigées : la fiabilité n’est pas toujours au rendez-vous, mais quand elle l’est, le gain de temps est loin d’être négligeable. Et si vous avez les poches profondes, lancer plusieurs tentatives en parallèle est une bonne manière de pallier au manque de fiabilité.

Google I/O 2025

Google I/O est la conférence annuelle de Google, présentant leurs nouveaux produits. C’est à Google I/O 2008 qu’Android avait été présenté.

Pour cette édition 2025, sans surprise, c’est l’IA qui est sur le devant de la scène.

Sur la création audiovisuelle, tout d’abord :

• Veo 3 est un modèle permettant de générer une vidéo (avec son).
• Veo 2, la version précédente, gagne certaines capacités : en plus d’instructions textuelles, le modèle est maintenant capable de prendre des images ou une vidéo de référence, pour reprendre le style ou les détails d’un personnage (ou d’un objet, ou d’une scène). Un contrôle plus fin de la caméra (zoom/rotation) est également fourni à l’utilisateur.
• La génération d’image du nouveau modèle d’OpenAI avait fait parler d’elle en mars dernier. Google propose sa propre solution avec Imagen 4.
• Lyria 2 est un nouveau modèle de génération de musique (paroles comprises).

Pour lutter contre les nouvelles possibilités de désinformation offertes par ces outils, Google lance également SynthID, un outil pour détecter les contenus multimédia générés par les modèles d’IA de Google (et seulement de Google). Sur invitation uniquement, Google craignant probablement qu’un acteur malicieux puisse juste modifier le contenu jusqu’à ce que SynthID réponde « non-IA » si l’outil est publiquement accessible.

Sur les modèles plus classiques :

• Gemini 2.5 Flash, une version plus légère, rapide, moins chère, et moins puissante de Gemini 2.5 Pro.
• Jailbreaké immédiatement, ce que je ne prendrai pas la peine de noter s’il n’y avait l’ironie que ce jailbreak arrive le même jour que la présentation de Google DeepMind nommée « Advancing Gemini’s security safeguards ».
• Gemma 3, le modèle open-weights, gagne plusieurs variantes pour des tâches plus spécialisées : Gemma 3n, pour tourner sur des smartphone ; MedGemma spécialisé dans la médecine ; SignGemma pour le langage des signes et… DolphinGemma pour communiquer avec les dauphins ?
• L’annonce également d’un nouveau mode pour Gemini 2.5 Pro, Deep Think, consistant apparemment à lancer plusieurs chaînes de pensée en parallèle. Apparemment une bonne avancée sur les problèmes mathématiques, moins impressionnant sur d’autres tâches. Accessible sur invitation uniquement également.

Sur les IA « agentiques », capables d’utiliser des outils pour réaliser des tâches variées :

• Google répond à OpenAI Codex avec son propre IA-programmeur, Jules.
• Project Mariner est un prototype explorant l’interaction entre un utilisateur et une IA agentique.
• Un mode « agent » dans l’application Gemini.
• Project Astra, un assistant vous permettant de contrôler votre smartphone via l’audio et la vidéo (caméra/microphone).

Également proposés : plus d’intégration de l’IA dans les services classiques de Google (Search, Mail, Chrome…). Un usage notable : traduction en temps réel dans Google Meet.

Présenté quelques avant Google I/O, AlphaEvolve est un système pour découvrir de nouveaux algorithmes, utilisant Gemini en tant que sous-composant. L’utilisateur fournit une description textuelle du problème avec une solution naïve et une méthode pour évaluer un solution, et le système se charge de trouver de meilleurs algorithmes pour résoudre le même problème.

Ce système a trouvé de meilleures solutions relativement à l’état de l’art sur plusieurs problèmes évalués, par exemple en découvrant un moyen de multiplier deux matrices 4x4 à l’aide de 48 multiplications scalaires au lieu de 49.

Dans la catégorie innovations, Gemini Diffusion explore un paradigme entièrement différent pour les modèles de langage. Les modèles de langage actuels sont basés sur des transformeurs, suivant la méthode maintenant célèbre de « prédire le prochain token à partir des précédents ». Dans la génération d’image, c’est un paradigme complètement différent qui est suivi, celui de diffusion (qui a donné le nom au modèle StableDiffusion), où le modèle est essentiellement un modèle de « dé-bruitage » qui transforme une image bruitée en une image plus claire, et qui commence par du simple bruit blanc. Gemini Diffusion est une tentative d’adapter ce paradigme de « diffusion » à la génération de texte : un texte complet est présenté au modèle, et sa tâche est de l’« affiner » incrémentalement (où le texte initial est complètement aléatoire). Les premiers résultats sont encourageants, ce premier prototype arrivant au même niveau de capacités que Gemini 2.0 Flash.

Anthropic publie Claude 4

L’annonce officielle :

Today, we’re introducing the next generation of Claude models: Claude Opus 4 and Claude Sonnet 4, setting new standards for coding, advanced reasoning, and AI agents.

Claude Opus 4 is the world’s best coding model, with sustained performance on complex, long-running tasks and agent workflows. Claude Sonnet 4 is a significant upgrade to Claude Sonnet 3.7, delivering superior coding and reasoning while responding more precisely to your instructions.

Traduction :

Aujourd'hui, nous présentons la prochaine génération de modèles Claude : Claude Opus 4 et Claude Sonnet 4, établissant de nouveaux standards pour le codage, le raisonnement avancé et les agents IA.

Claude Opus 4 est le meilleur modèle de codage au monde, avec des performances soutenues sur des tâches complexes et de longue durée ainsi que des flux de travail d'agents. Claude Sonnet 4 est une amélioration significative par rapport à Claude Sonnet 3.7, offrant un codage et un raisonnement supérieurs tout en répondant de manière plus précise à vos instructions.

Tout comme Google et OpenAI, Anthropic se focalise sur la course aux agents, souligné par le choix des benchmarks présentés par Anthropic pour vendre leur modèle : « Agentic coding » (SWE-bench-verified), « Agentic terminal coding » (terminal-bench), « Agentic tool use » (TAU-bench). Claude Opus 4 donne un nouveau état de l’art sur tous ces benchmarks, tout en restant au niveau de l’état de l’art (OpenAI o3 / Gemini 2.5 Pro) sur les tâches plus classiques. Ne vous attendez pas à un gros bond en avant, il s’agit là d’une amélioration incrémentale, contrairement à ce que pourrait laisser penser la numérotation de version.

À noter un benchmark sur lequel Claude 4 montre un gros progrès : LoCoDiff, qui cherche à mesurer la capacité des modèles à maintenir de bonnes performances sur un long contexte.

Une bonne nouvelle : OpenAI o3 avait cassé la tendance « les modèles plus avancés hallucinent moins », où o3 hallucinait plus que ses prédécesseurs. Anthropic a réussi à éviter cet écueil, avec un taux d’hallucinations en baisse. En baisse également (sans pour autant disparaître), la tendance des modèles à « tricher ».

L’événement le plus intéressant de cette publication se trouve principalement dans la politique de sécurité des modèles. N’ayant pu déterminer avec confiance que Opus 4 ne possédait pas de capacités dangereuses (telles que « capacité à aider significativement à la création d’armes chimiques/biologiques ») nécessitant des précautions supplémentaires (contrairement à Opus 3 ou Sonnet 4), Anthropic a décidé de mettre en place ces précautions (AI Safety Level 3 ou ASL-3), au moins provisoirement (le temps de déterminer plus précisément les capacités du modèle sur ces points), et pour Opus 4 uniquement. Ce qui signifie principalement : surveillance (automatisée) des requêtes et restrictions supplémentaires sur les requêtes acceptées. Pour plus de détails, je vous renvoie à la System Card et à la politique de sécurité des modèle d’Anthropic.

Ce qui n’a pas empêché Opus 4 d’être jailbreak immédiatement. Pour la défense d’Anthropic, la System Card mentionne explicitement que le but de ces précautions supplémentaires n’est pas de rendre plus difficile le jailbreak sur les requêtes « classiquement » interdites.

En vrac

Chatbot Arena est l’un des benchmarks les plus connus, utilisé notamment comme critère d’arbitrage sur les marchés de prédiction. Sa pertinence est de plus en plus remise en question, où le classement ne semble pas réellement refléter les capacités des modèles, sur d’autres benchmarks ou des évaluations privées/subjectives. Un papier publié sur arXiv, The Leaderboard Illusion, analyse l’impact de certaines pratiques pouvant expliquer ces différences. Les mainteneurs de Chatbot Arena répondent sur Twitter.

Le gouvernement américain ouvre une consultation publique sur la politique à suivre concernant l’IA.

Un chiffre intéressant: Cursor, un assistant de code, produit actuellement 1 milliard de lignes de code par jour.

DeepSeek publie DeepSeek-Prover-V2, un LLM spécialisé dans les preuves mathématiques. Surpasse tous les modèles actuels sur PutmanBench.

Dans la sécurité des modèles, "Scalable Oversight" désigne la technique suivante : utiliser un modèle considéré comme sûr pour évaluer la sécurité d’un modèle plus sophistiqué. Se posent diverses questions comme : "jusqu’à quel point un modèle moins sophistiqué peut juger un modèle plus sophistiqué" ? Ce papier tente de répondre à cette question (et d’autres adjacentes).

Google DeepMind met à jour son modèle le plus avancé, Gemini 2.5 Pro. De meilleures performances sur les tâches de programmation, mais au prix de moins bonnes sur… presque tout le reste ?

Le Copyright Office aux US publie un premier brouillon sur l’utilisation de données publiques pour l’entraînement des IA. Verdict temporaire: c’est un usage transformatif (autrement dit: pas du plagiat), mais ne rentre pas dans la doctrine du « fair use » (ce qui permettrait aux développeurs d’IA de ne pas offrir de compensation). Une victoire préliminaire pour les créateurs de contenu s’estimant lésés. Cependant, le directeur du Copyright Office aurait été limogé peu après la publication de ce rapport.

ARC-AGI-2 est publié. ARC-AGI est un benchmark spécialement conçu pour être dur pour les IA actuelles, se reposant principalement sur des tâches de type raisonnement visuel. Malgré ceci, o3 est arrivé à 75%, dépassant les performances des évaluateurs humains. Cette seconde édition tente un nouveau format mais garde le même objectif, « difficile pour l’IA, facile pour les humains ».

Quelque chose que je n’ai pas couvert jusqu’ici car un point secondaire dans beaucoup d’annonces plus importantes, mais qui mérite sa mention du fait justement d’être aussi commun : MCP (Model Context Protocol) est une tentative d’uniformiser la communication entre un modèle et d’autres systèmes (IDEs, sites internet,…). Développé par Anthropic (les développeurs de Claude), adopté par OpenAI et Google DeepMind, il devient de plus en plus un standard de fait.

Dans la série « l’IA fait de la recherche », des chercheurs font leur propre système, nommé Robin, où l’IA propose des hypothèses et des expériences pour les tester, les chercheurs réalisent les expériences, et l’IA se charge de l’analyse des résultats et des prochaines étapes (plus d’expériences, plus d’hypothèses, ou tirer une conclusion). Premier résultat : un candidat pour traiter la forme atrophique de la dégénérescence maculaire liée à l’âge.

OpenAI o3 découvre une faille de sécurité dans Linux.

Le mois dernier, nous avions brièvement mentionné que OpenAI 4o était flagorneur, au point d’opiner sur des prompts relevant manifestement de l’épisode psychotique. Un utilisateur anonyme explore la même tendance à un moindre niveau Opus 4, et travaille à mesurer ça plus précisément. Il mentionne que ses résultats préliminaires montrent que les modèles plus avancés ont plus tendance à exhiber ce comportement.

Dario Amodei, le patron d’Anthropic, prévient que l’IA pourrait supprimer la moitié des postes « débutants » dans des domaines tels que la technologie, la finance ou le droit d’ici 1 à 5 ans.

Pour aller plus loin

Non couvert ici :

• OpenAI Preparedness Framework 2.0: analyse de la nouvelle politique de sécurité des modèles d’OpenAI.
• GPT-4o Sycophancy Post Mortem: le mois précédent, une mise à jour de GPT-4o l’a rendu bien trop flatteur. Retour sur les raisons de l’incident en question.
• Zuckerberg's Dystopian AI Vision: Mark Zuckerberg a donné plusieurs interviews sur sa vision de l’utilisation de l’IA, en particuliers sur les réseaux sociaux. Résumé de cette vision.
• OpenAI Claims Nonprofit Will Retain Nominal Control: OpenAI annonce abandonner sa tentative de casse du siècle (même si certains doutent de l’honnêteté de cette annonce).
• Cheaters Gonna Cheat Cheat Cheat Cheat Cheat: témoignages et anecdotes sur l’utilisation de l’IA par les étudiants.
• A Live Look at the Senate AI Hearing: résumé des auditions que le sénat US a tenues sur le sujet de l’approche à prendre sur la régulation de l’IA. Pour faire court : « — il ne faut pas nous réguler pour que l’on continue à devancer la Chine — d’accord ».
• Fighting Obvious Nonsense About AI Diffusion: continuation de l’article précédent, où Zvi donne son point de vue sur la politique que devrait suivre le gouvernement US pour rester compétitif.
• Regarding South Africa: Grok, l’IA de xAI, s’est mise à répondre « le Génocide Blanc en Afrique du Sud est réel », sur des sujets complètement sans rapport. L’explication officielle est « une modification non-autorisée du message système ». Tout le monde se pose évidemment la question : qui donc a bien pu faire une telle modification ⸮
• America Makes AI Chip Diffusion Deal with UAE and KSA: analyse et critique de la décision du gouvernement US d’autoriser (et encourager) la vente de GPUs pour la création de datacenters dédiés à l’IA en Arabie Saoudite et aux Émirats arabes unis.
• Fun With Veo 3 and Media Generation: quelques exemples d’utilisation de Veo 3.

En audio/video :

• Une fois n’est pas coutume, une vidéo sur l’IA fait parler d’elle dans la sphère francophone: Maxime Fournes défend la thèse "Il est urgent de mettre l’IA en pause" chez Le Futurologue.
• Yoshua Bengio, que l’on a plus à présenter, donne une courte présentation destinée au grand public à TED (en anglais) sur le même sujet.

Cette dépêche va présenter une méthode pour afficher sur un site personnel les traces, récits et photographies de balades (pédestres, cyclistes par exemple).

Comme le contenu à afficher est diversifié (texte, photographies, cartes), la solution retenue sera un blog. Dans un soucis de sobriété numérique, le site sera sans base de données.

Pour l'aspect esthétique, la barre de navigation et les cartes seront situées dans la partie gauche des pages et surtout, la carte ne bougera pas avec la navigation dans la page.

Sommaire

• 1 - Préparation de pelican
  • a) Le moteur
  • b) Installation du thème graphique
  • c) Écriture du premier billet
  • d) Génération de notre site
• 2 - Peaufinage de base
• 3 - Gestion cartographique
  • a) Gestion des cartes
  • b) Gestion des fichiers de trace (gpx)
  • c) Modification des gabarits
• 4 - Gestion des photographies associées à notre cartographie
  • a) Fichier des billets
  • b) Modification des gabarits
  • c) Gestion des photographies
• 5) Dernières modifications
  • a) Modifier les gabarits
  • b) Ajuster les feuilles de style
• 6) Conclusion

N'ayant pas trouvé d'alternative libre à Polarstep, la solution retenue se base sur les briques logicielles libres suivantes :

• un moteur de blog static : pelican (AGPL v3.0)
• des thèmes pour le blog
• des bibliothèques cartographiques : leaflet (BSD 2)

1 - Préparation de pelican

Pelican propose d'écrire chaque billet de blogs dans un fichier texte indépendant (au format markdown ou reStructuredText).

Pelican les convertit en html et l'organisation du site ainsi généré (catégories, mots-clefs, archivage) se fait par le biais de gabarits (qui sont dans un sous-répertoire templates)

a) Le moteur

L'installation ne sera pas développée ici, pelican étant disponible dans de nombreuses distributions.

Il faut créer la structure de travail (dans le répertoire personnel de notre choix) :

pelican-quickstart

b) Installation du thème graphique

En allant sur le dépôt des thèmes de pelican, il est possible de trouver le style graphique qui nous convient le mieux.

Nous allons utiliser le thème pelican-blue (sous licence MIT 2.0), qui a l'avantage d'être simple, et commençons son installation :

• création du répertoire theme dans notre structure de travail
• décompression de l'archive du thème dans le répertoire « theme »
• modification du fichier pelicanconf.py pour configurer notre site. Il faut adapter quelques variables :

SITENAME = 'Mon blog'
SITEDESCRIPTION = 'Mes souvenirs de vacances'
THEME = "./theme/pelican-blue"
STATIC_PATHS = ['images', 'gpx']

• modifications propres au thème. Souvent l'auteur d'un thème propose de le personnaliser à partir de variables déclarées dans le fichier de configuration.

c) Écriture du premier billet

On va créer notre premier billet

Title: Première sortie
Date: 2025-05-01
Modified: 2025-05-01
Category: Lieux
Slug: depart
Tags: bonjour, balade

Bonjour tout le monde ! Quelle chouette sortie j'ai faite.

d) Génération de notre site

On lance la première compilation :

make clean
make html

On peut voir le résultat :

• soit en ouvrant directement le fichier index.html (présent dans le répertoire output)
• soit en lançant un mini serveur web (make serve) et lancer son navigateur web à l'adresse http://localhost:8000/

Pour plus de renseignements sur pelican, je vous invite à vous rendre sur la documentation du projet.

2 - Peaufinage de base

On va maintenant nettoyer le code des gabarits, en supprimant les choses que l'on trouve inutiles ou qui nous déplaisent. Tout se passe dans le répertoire templates de notre thème.

• il y a les fichiers analytics.html et disqus.html
• une recherche par mot nous informe des éventuelles références à Google, Twitter, Facebook

On supprime les parties qui ne nous conviennent pas.

3 - Gestion cartographique

Nous attaquons désormais notre objectif : rendre visibles sur des cartes des fichiers de trace.

a) Gestion des cartes

On va maintenant configurer la gestion des cartes, par l'intermédiaire de leaflet. Comme l'indique sa page wikipédia, leaflet est très largement utilisé et très pratique.

On va donc

• le télécharger,
• le décompresser dans le répertoire static de notre thème
• modifier les entêtes de nos gabarits (cela se fait le plus souvent dans le fichier base.html) pour y ajouter au niveau <head> les références à leaflet :

    <link rel="stylesheet" href="{{ SITEURL }}/theme/leaflet/leaflet.css"   integrity="sha256-p4NxAoJBhIIN+hmNHrzRCf9tD/miZyoHS5obTRR9BMY="  crossorigin=""/>
    <script src="{{ SITEURL }}/theme/leaflet/leaflet.js"  integrity="sha256-20nQCchB9co0qIjJZRGuk2/Z9VM+kNiyxNV1lvTlZBo="  crossorigin=""></script>

Comme on a récupéré en local les fichiers, on met des chemins propres à notre arborescence (via {{ SITEURL }}/theme/).

b) Gestion des fichiers de trace (gpx)

Elle va se faire par l’intermédiaire d'un module supplémentaire https://github.com/mpetazzoni/leaflet-gpx (BSD 2).

De la même manière qu'on a intégré dans nos entêtes l'intégration de leaflet, nous allons ajouter une ligne pour faire référence à leaflet-gpx (bien vérifier le nom du fichier javascript) :

<script src="{{ SITEURL }}/theme/leaflet-gpx/gpx.js"></script>

Par rapport à la documentation officielle, on retire l'attribut defer (puisque nous utilisons les fichiers locaux et non distants).

Pour tester notre environnement, on va déposer dans notre répertoire gpx un fichier de trace, puis on va ajouter dans notre billet les éléments de cartographie de notre voyage :

<div id="map" style="width: 600px; height: 400px;"></div>
<script>
        var map = L.map('map');
        L.tileLayer('http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
          attribution: 'Carte et données : <a href="http://www.osm.org">OpenStreetMap</a>'
        }).addTo(map);
        var gpx = '/gpx/FICHIER.gpx';
        new L.GPX(gpx, {async: true}).on('loaded', function(e) {
            map.fitBounds(e.target.getBounds());
        }).addTo(map); 
</script>

On regénère notre site web, et on peut visualiser notre billet

Globalement, ça fait le boulot.

Mais on peut améliorer la chose : on peut par exemple cacher les marques de début et de fin d'itinéraire en insérant la ligne suivante après le async: true

markers: {startIcon: null, endIcon: null, }

Mais surtout, nous souhaitons que pelican génère automatiquement la partie consacrée au fichier de trace (alors que dans notre test, nous avons dû l'ajouter nous-même) !

c) Modification des gabarits

Si l'on veut simplement ajouter notre fichier de trace et que notre gabarit le traite, on va ajouter cette information dans les entêtes de notre fichier markdown ! En effet pelican permet de créer des variables qui seront utilisables dans nos gabarits.

Nous allons donc créer et utiliser une variable (qui s'appellerait… Gpx par exemple), qui stockera le nom du fichier gpx à afficher (les chemins sont relatifs à notre site web)

Title: Première sortie
Date: 2025-05-01
Modified: 2025-05-01
Category: Lieux
Gpx: /gpx/monfichier.gpx
Slug: depart
Tags: bonjour, balade

Nous modifions ensuite notre gabarit article.html pour qu'il génère la carte à partir de notre variable.

Pelican est très souple : basé sur Jinja2, il permet les boucles, les conditions et les variables.

Tous les éléments qu'il utilise sont insérés dans des accolades. Le fonctionnement est facilement lisible et compréhensible.

On va donc conditonner (avec if) l'insertion de leaflet.

{% if article.gpx %}
    <div id="map" style="width: 600px; height: 400px;"></div>
<script>
    var map = L.map('map');
    L.tileLayer('http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
      attribution: 'Carte et données : <a href="http://www.osm.org">OpenStreetMap</a>'
    }).addTo(map);

    var gpx = '{{ article.gpx }}';
    new L.GPX(gpx, {async: true,
                       markers: {startIcon: null, endIcon: null, }
      }).on('loaded', function(e) {
         map.fitBounds(e.target.getBounds());
      }).addTo(map); 

</script>
{% endif %}

Bien entendu, nous supprimons ces références du fichier markdown correspondant à notre billet de test.

On regénère notre site web, et on peut visualiser notre billet… qui n'a pas changé : tout fonctionne. Pour chacune de nos sorties, il suffit donc d'indiquer le fichier de trace dans les entêtes pour que la carte soit insérée automatiquement dans notre billet.

Passons maintenant à l'intégration de nos photos.

4 - Gestion des photographies associées à notre cartographie

Nous avons besoin :

• d'une image
• de ses coordonnées géographiques (latitude et longitude)

Pour cela, nous allons procéder de la même manière que pour le fichier trace : nous allons créer et utiliser des variables dans les entêtes des fichiers markdown.

a) Fichier des billets

Nous modifions encore une fois les entêtes en ajoutant autant d'informations (image, latitude et longitude) que de photos à afficher en miniatures.

Title: Première sortie
Date: 2025-05-01
Modified: 2025-05-01
Category: Lieux
Gpx: /gpx/monfichier.gpx
Slug: depart
Img: /images/image1.jpg
Lat: 49.895517
Lon: 2.295983
Img: /images/image2.jpg
Lat: 49.89443
Lon: 2.30137
Tags: bonjour, balade

On remarque ici que l'on a mis plusieurs images avec les mêmes noms de variables.

b) Modification des gabarits

Nous allons ensuite modifier les gabarits de pelican pour qu'ils positionnent des miniatures des photos sur notre trajet.

Nous allons à nouveau modifier notre fichier article.html, en y ajoutant (à la suite de notre précédente modification, dans la condition {% if article.gpx %}) le code suivant :

Nous commençons par indiquer l'icône qui s'affichera sur la carte à chaque photo mise en valeur

var MonIcone = L.icon({
    iconUrl: '/images/app-photo.png',
    iconSize: [36, 36]
});

Puis nous codons l'affichage du marqueur (qui sera géré par leaflet).

{% if article.img %}
  {% if article.img is string %}
     imageTxt = 'Description';
     L.marker([{{ article.lat }}, {{ article.lon }}], {icon: MonIcone}).bindPopup(imageTxt + '<br><img src="{{ article.img }}" width="200px"><a href="#bal5">plus de détail</a>').addTo(map);    
  {% else %}
    {% for n in range(article.img| length) %}
       imageTxt = 'Description';
       L.marker([{{ article.lat[n] }}, {{ article.lon[n] }}], {icon: MonIcone}).bindPopup(imageTxt + '<br><img src="{{ article.img[n] }}" width="200px"><a href="#bal5">plus de détail</a>').addTo(map);
    {% endfor %}    
  {% endif %}

La difficulté réside dans la gestion des éléments répétitifs :

• s'ils sont plusieurs, on peut utiliser les méthodes python des listes.
• s'il n'y en a qu'un seul, cette méthode renvoie toutes les lettres de notre variable ! Il a donc fallu tester si celle-ci est une chaine de caractères ou une liste.

Les choix sont ici purement personnels ou démonstatifs :

• on a laissé une variable imageTxt en dur, elle pourrait être passée dans les entêtes de nos fichiers markdown
• le texte du popup peut être adapté (on pourrait y ajouter un lien direct vers notre image par exemple)
• le lien (ancre) est à créer dans notre fichier markdown
• la taille de l'image du popup est en dur (on peut passer par une feuille de style css)

On regénère notre site web, et on peut visualiser notre billet :

Et lorsqu'on clique sur une icône d'appareil photo, on voit bien notre popup :

c) Gestion des photographies

Comme indiqué plus haut, la taille des miniatures affichées peut se gérer :

• par CSS
• ou créer des miniatures (avec imagemagick) pour diminuer la charge de notre serveur (afficher une photo de 3000 pixels à 200 pixels n'est pas optimal). Dans ce cas, il suffira d'adapter notre gabarit pour lui indiquer où aller chercher les petites images (/images/miniatures/ par exemple)

Par contre, le point le plus compliqué est la gestion des coordonnées des photographies : il faut les rentrer à la main !

• Pour les photographies qui n'intègrent pas les coordonnées dans leurs métadonnées, il n'y a pas d'autre solution que d'aller chercher sur une carte (openstreetmap par exemple) et de trouver le lieu de la prise de vue et de repérer les coordonnées.

• Pour les photographies qui contiennent leurs coordonnées géographiques, on peut utiliser l'outil exiftool pour les récupérer. On peut éventuellement faire un script bash qui affiche les lignes d'entête pour notre billet (on n'a plus qu'à les recopier ou les rediriger vers un fichier texte) :

    for photo in $(ls ./content/images);
    do
        echo ""
        echo "Img: /images/"$photo
        LAT=$(exiftool -n -s3  -gpslatitude ./content/images/$photo)
        echo "Lat: "$LAT
        LONG=$(exiftool -n -s3  -gpslongitude ./content/images/$photo)
        echo "Lon: "$LONG
    done

Nous avons utilisé les options -n qui affichent les valeurs numériques au format décimal (celui utilisé par openstreetmap pour les coordonnées) et -s3 pour avoir la valeur du champ sans le nom de son attribut.

5) Dernières modifications

Nous venons de voir les différentes techniques qui permettent d'avoir le rendu que nous souhaitions. Et le résultat est déjà agréable à regarder.

Nous pourrions nous arrêter ici, mais vous voulons que la carte reste en permanence dans le menu latéral. La solution est de la mettre dans une balise <aside>.

a) Modifier les gabarits

Notre thème comporte déjà une telle balise : elle est dans le fichier base.html… ce qui signifie qu'il ne peut pas voir les informations sur les articles (donc nos entêtes) !

La solution va donc consister à déplacer, à l'intérieur du fichier article.html, tout notre code dans une section (que nous appellerons mamap :

{% block mamap %}
    Mettre ici tout le code sur notre gestion cartographique
{% endblock %}

Et dans le fichier base.html, on va insérer à l'intérieur des balises <aside> son appel (qui ne tient que sur deux lignes) :

{% block mamap %}
{% endblock %}

b) Ajuster les feuilles de style

Il faut surcharger le comportement de la carte gérée par leaflet :

    .leaflet-container {
        width: 400px;
        height: 300px;
        max-width: 100%;
        max-height: 100%;
        margin: auto;
    }

Et vérifier que les largeurs de la carte, et de <aside> soient compatibles.

Le résultat avec nos dernières modifications est désormais le suivant

6) Conclusion

Il est temps de finir cette dépêche, dans laquelle nous avons pu découvrir la souplesse et la richesse des gabarits gérés avec jinja2, ainsi que la facilité d'utilisation de leaflet.

Désormais, dans notre flux de travail, nos répertoires sont organisé ainsi :

content 
    + gpx : les fichiers de trace
    + images : les photos que l'on veut afficher sur notre blog
    fichierXX.md : les billets
output : notre site web (généré par pelican)
theme
    + pelican-blue  : le thème choisi
        + static
            + css
            + leaflet
            + leaflet-gpx
        + templates

Et la rédaction de nos billets consiste à :

• ajouter le fichier gpx de notre trace dans les entêtes
• ajouter les informations sur chaque photo que l'on veut voir (toujours dans les entêtes)
• écrire notre billet normalement (en y ajoutant éventuellement d'autres photos ou des ancres de navigation)

Cette dépêche démontre qu'il est possible d'avoir, avec les outils actuels, un rendu intéressant pour partager ses sorties. Et totalement utilisable en auto-hébergement.

Les outils utilisés sont très personnalisables et je vous invite à lire leurs documentations ou à parcourir leurs extensions respectives et de vous les approprier selon votre usage.

Malheureusement, la solution présentée ne conviendra qu'à une minorité d'utilisateurs. En effet, elle se base sur des éléments qui sont le plus souvent rendus invisibles (site web, transfert de fichiers, métadonnées) et elle est inutilisable sur téléphone.

« J'étais tranquille j'étais peinard / je réparais ma mobylette » / la nouvelle a surgi le soir / un truc pas vraiment super-chouette… » Eh oui, le couperet est tombé, les utilisateurs de l'agrégateur de flux Web Netvibes.com ont reçu le 15 avril un courriel de Dassault Systèmes leur annonçant que leur agrégateur préféré aller se désagréger définitivement dans l'atmosphère le 2 juin 2025 à midi, avec toutes leurs données, tel un Starship numérique. Si l'on en croit le début du message, cela est lié au développement d'un nouveau service de l'entreprise nommé 3D UNIV+RSES, avec plein d'IA et tout et tout. Le courriel d'avertissement indique certes comment sauvegarder ses données, mais « et maintenant, Papa / C'est quand qu'on va où ? »

Sommaire

• Good vibrations 2.0 ou le cubisme informationnel
• J'ai rencard avec Pétrolette
  • Procédure migratoire
  • Synchronisation ?
  • Nouveaux développements
• Retour d'expérience
  • Points négatifs
  • Points positifs
• Prêts pour l’équipée sauvage ?

Good vibrations 2.0 ou le cubisme informationnel

Netvibes.com, lancé par une start-up en 2005 et racheté par Dassault Systèmes en 2012, était un lecteur en ligne permettant d'afficher les flux RSS ou Atom dans des petits cadres qu'on pouvait regrouper dans des onglets thématiques. Chaque cadre était configurable (longueur, affichage d'images ou non…) et déplaçable facilement. Les flux se mettaient automatiquement et régulièrement à jour. On pouvait aussi ajouter de petites applications (listes de choses à faire, accès courriels, accès à différents réseaux sociaux, etc.). Wikipedia décrit Netvibes.com comme « un portail Web personnalisable. Représentatif de ce qu'on appelle le Web 2.0 ». En tout cas, c'était un très bon outil de veille que j'utilisais tous les jours depuis belle lurette.

Lancé en 1990, donc à peu près en même temps que le World Wide Web, le Courrier international nous permettait d'avoir accès à une pluralité de points de vue issus des journaux du monde entier. Un agrégateur de flux, c'est un peu l'équivalent informatique. Il permet un véritable cubisme informationnel. Avoir un onglet News agrégeant des flux de journaux d'horizons politiques différents et de plusieurs pays, c'est échapper à la bulle informationnelle, à la ségrégation sociale créée par les grands réseaux sociaux commerciaux. Car observer depuis le point de vue d'autrui est un bon exercice, même si ça peut parfois être désagréable comme du poil à gratter. Enfin, avec un agrégateur, l'algorithme c'est vous : votre œil survole l'ensemble des titres et capte au vol ce qui l'intéresse ou le surprend.

J'ai rencard avec Pétrolette

L'outil libre qui se rapproche le plus de Netvibes.com est Pétrolette, « la page d'actus qui ne sait rien de toi », développée par YPhil en JavaScript. Comme son nom l'indique, Pétrolette n'est pas un gros SUV qui fait tout, même le café, mais une application libre qui essaie de faire au mieux une seule chose : afficher des flux Web dans des cadres classés dans des onglets. Donc disons le tout de suite, il faut oublier les éventuelles autres applications que vous utilisiez dans Netvibes. D'après son CHANGELOG, Pétrolette est en version 1.7 depuis l'été 2023. Le GitLab de Pétrolette est indiqué comme étant un miroir de son Framagit mais est en fait plus à jour, la dernière activité remontant à Noël 2024. C'est là que le développement se passe.

D'après le compte Mastodon de Pétrolette, suite à des problèmes d'hébergement, l'instance principale est depuis décembre 2024 https://petrolette.onrender.com/ bien que celle-ci soit considérée comme temporaire. Les plus admin pourront bien sûr héberger leur propre instance, soit en local soit sur le Web, par exemple sur https://place.de.ma.mob/ si le domaine n'est pas déjà réservé.

Procédure migratoire

Par défaut, quand on va sur l'instance principale, qui est une instance partagée, on a un certain nombre d'onglets pré-remplis, avec en tout plus de trois cents flux. On peut les personnaliser (ce sera stocké en local), mais ce qui nous intéresse ici, c'est migrer de Netvibes à Pétrolette. Voici la procédure :

• Dans Netvibes.com, sauvegarder ses données en allant dans « Compte > Sauvegarder vos données », choisir le tableau de bord, cliquer sur Exporter (fichier XML).
• Dans Pétrolette, supprimer tous les onglets par défaut (croix rouges), importer le XML avec « Flux > Ouvrir ».
• Tous les onglets et flux sont récupérés. Le titre d'un flux apparaîtra quand on clique sur son icône pour le déployer.
• Déplier et configurer chaque flux (mais on devrait éventuellement aussi pouvoir travailler à partir du .conf pour réduire ce travail fastidieux).

La configuration est stockée localement sur l'ordinateur et non pas en ligne (on n'a donc pas de compte Pétrolette, donc elle « ne sait rien de toi », elle ne sait pas ce que tu lis). On peut l'exporter dans un fichier .conf au format JSON et l'importer sur un autre PC pour avoir la même configuration.

Synchronisation ?

Mais une telle synchronisation manuelle n'est pas idéale et l'application peut utiliser le protocole remoteStorage pour pouvoir partager la même configuration sur plusieurs PC, et en particulier vers l'application 5apps. D'après l'aide, l'instance principale de Pétrolette ne gère que 5Apps (mais le menu affiche également des icônes pour Dropbox et Google Drive, qu'on devrait donc pouvoir utiliser si on héberge sa propre instance).

On peut s'enregistrer sur 5apps à partir d'un compte GitHub, Bitbucket, GitLab.com ou en se créant un compte (adresse email, identifiant, mot de passe). 5apps vous fournit une « adresse utilisateur » du type login@5apps.com. On peut alors aller dans le menu de Pétrolette, cliquer sur remoteStorage et entrer l'adresse utilisateur pour faire la connexion. Il n'y a plus qu'à autoriser Pétrolette à y accéder et faire de même sur tous vos PC. Pour cela, sur chaque machine, connectez-vous à votre compte 5apps puis dans la liste des « Connected Apps », cliquez sur le lien petrolette.onrender.com, dont l'URL est du type https://5apps.com/rs/oauth/token/123d3215c5484b9a78987e8/launch_app.

Nouveaux développements

Ça c'est la théorie, dans la pratique la synchronisation semble problématique, avec un fonctionnement très capricieux, et après discussion avec l'auteur il pourrait bien s'agir d'un bug où l'application s'emmêlerait les pinceaux entre stockage local et stockage distant. C'est la mauvaise nouvelle. La bonne nouvelle (scoop !) c'est que ça pourrait être résolu dans une future Pétrolette 2 à laquelle réfléchit l'auteur !

Voilà une bonne raison de réfléchir à l'invitation à faire un don au projet Pétrolette dans la fenêtre pop-up qui surgit de temps en temps. Il est en effet possible de faire un don sur Liberapay ou de prendre un abonnement sur Ko-fi : à partir de 1 €/mois le pop-up disparaît. Au-delà, on peut demander à l'auteur de créer un nombre plus ou moins important de flux RSS pour des sites qui n'en proposent normalement pas. Rappelons-nous que dans surveillance://, Tristan Nitot nous avertissait sur notre fâcheuse tendance à aimer la gratuité.

Retour d'expérience

Commençons par les points négatifs, ce qui nous permettra de finir sur le positif !

Points négatifs

• Lenteur pour mettre à jour les flux : quand on affiche sa page Pétrolette, tous les flux sont mis à jour simultanément, c'est-à-dire même dans les onglets qui ne sont pas affichés.
• Pas de mise à jour périodique des flux. On peut certes les mettre à jour individuellement en cliquant sur une icône. Mais malheureusement, recharger la page avec F5 permet certes de mettre à jour tous les flux mais nous remet systématiquement sur le premier onglet. Pétrolette 2 proposera peut-être des fonctionnalités pour faciliter les mises à jour des flux.
• N'affiche pas l'heure de parution des actualités, contrairement à Netvibes. Mais la date et l'heure sont indiquées dans la fenêtre d'aperçu quand on survole un titre.

Points positifs

• Les aperçus du texte qui apparaissent au survol de la souris sont plus longs qu'avec Netvibes, et même parfois très longs, ce qui permet d'avoir un bon aperçu du contenu avant un éventuel clic, voire même de s'en passer.
• La hauteur (en pixels) des cadres peut être réglée plus finement qu'avec Netvibes (où seules trois hauteurs standards étaient disponibles). Cela peut d'ailleurs être utilisé pour augmenter la distance verticale entre deux cadres, ceux-ci étant par défaut collés de façon un peu compacte.
• Les titres longs apparaissent en entier sur plusieurs lignes, alors qu'ils sont coupés dans Netvibes. Cela peut-être un avantage mais parfois aussi un défaut avec certains sites qui proposent des titres à rallonge (du genre trois lignes sur Developpez.com !) que l'oeil a du mal à lire au vol.
• Le menu principal propose de déposer un marque-page dans la barre du navigateur. Il contient un script qui d'un clic ajoutera le site de l'onglet courant dans votre Pétrolette.
• Le champ de recherche permet de chercher un terme dans tous les titres de l'ensemble des onglets. Les zones où il est trouvé apparaissent encadrées en jaune.

Prêts pour l’équipée sauvage ?

« Dès que les vents tourneront nous nous en allerons… » Il le faudra bien, le 2 juin tout s'arrête. Et donc tout recommence. On a maintenant toutes les réponses à la question synthétique et sympathique « c'est quand qu'on va où ? » Quand ? On le sait depuis le début et on l'a répété, c'est le 2 juin ! Où ? On espère y avoir apporter une réponse dans cette dépêche.

Et puis à l'heure où les algorithmes profiteurs des réseaux sociaux commerciaux tendent à enfermer l'utilisateur dans sa bulle informationnelle au seul motif d'optimiser les profits et où les moteurs IA sapent la sérendipité du Web, se balader humblement en mobylette RSS devient une véritable mesure d'hygiène mentale. En plus c'est libre.

Figure 1 - « Quand j’me balade en mobylette / On dirait l’équipée sauvage ». Ouais, ça carbure librement avec « La Pétrolette » (Duncan & Suberbie, 1895 - 1898) [source : Wikimedia, domaine public].