À 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 fourni par votre distribution, vous profiterez des effets de ces travaux de maintenance d’AMD comme vous en profitez déjà pour RadeonSI.

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

Le départ des derniers

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

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

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

Adieu OGLP

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

OGLP proposait une implémentation OpenGL et OpenGL ES.

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

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

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

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

Adieu AMDVLK-Pro

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

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

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

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

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

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

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

Adieu AMF

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

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

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

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

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

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

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

Mais… et les firmwares ?

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

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

Préférer le DisplayPort à l’HDMI pour les très hautes 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… ?