Si vous avez envie de regarder sous le capot et vous impliquer dans le développement d’une distribution Linux c’est le moment de participer aux tests.
Mageia a publié une première version alpha en décembre 2025, la version bêta est désormais disponible et une version candidate est envisagée pour mars/avril 2026 pour publication de Mageia 10 « quand ce sera prêt », l’occasion de revenir sur les différentes étapes et l’implication possible.

Pour l’apparence de la distribution, un concours artistique a été lancé du 29 janvier au 25 février 2026, la participation des plus graphistes d’entre vous est la bienvenue ! Le choix pour la Mageia 10 va bientôt être fait, il reste toujours quelques points à améliorer par la suite ;-)

Bref, une version 10 de Mageia qui s’inscrit dans la continuité de la stabilité de Mageia 9 : le cycle de publication est là pour l’avérer, il y aura des pleurs, des cris et de grandes joies à réussir à faire fonctionner au mieux vos logiciels de prédilection.

Sommaire

• Cycle alpha : reprise de publication
• Cycle bêta : consolidation des tests et des choix pour la version à publier
• Cycle version candidate : finalisation
• Version finale
• Différences de fonctionnement entre version stable et le cycle de publication.
• S’impliquer pour Mageia 10
• Exemples d’utilisations

Pour cette dépêche, le parti pris est de privilégier les annonces en français. Pour autant, le suivi effectif est à faire en anglais (ensuite décliné au besoin en français).

• Blog Mageia en anglais
• Notes de version Mageia 10 en anglais
• Errata pour Mageia 10 en anglais à consolider au fur et à mesure des évolutions, les corrections effectuées seront archivées à publication de la version

Quelques sujets pris en compte pour Mageia 10 :

• choix du noyau Linux 6.18.x qui est une version LTS
• live ISO 64 bits en 3 versions : KDE, GNOME et XFCE
• conservation d’une version 32 bits (i686 et non plus i586), nécessitant des tests et une définition du périmètre, un live ISO basé sur XFCE
• Wayland par défaut pour GNOME, éventuellement (à tester) pour Plasma KDE et autres environnements le proposant, marquant la résorption de Xorg lorsque possible ; plusieurs compositeurs Wayland pour LXQt sont intégrés (Labwc, niri, hyprland, sway)
• bon fonctionnement de l’infrastructure de mise à jour via URPMI, basé sur RPM ou DNF
• Peaufinement de l’intégration des pilotes libres de GPU pour Intel et AMD ; pour les pilotes nVidia ça va être plus compliqué :/
• des mises à jour de vos logiciels préférés (n’hésitez pas à les préciser en commentaire)

Voici les différents cycles et les choix envisageables restant à chaque étape.

Cycle alpha : reprise de publication

Objectif : stabilisation du périmètre envisagé, identification des montées de version de logiciels restant à faire lors du cycle de publication.

Cela permet d’avoir des premiers ISO installables, et de revoir les plannings respectifs de ce qui est à intégrer : des langages (Rust, Ruby…), des logiciels (FreeCAD 1.1 en février donc plutôt lors de la bêta…).

Premières personnes à tester généralement issues de Cauldron—la version de développement en rolling-release—dont l’installation a pour objectif d’avérer la cohérence de l’installation et d'identifier sur le bugzilla les bogues bloquants ce qui en permet le suivi lors de chacun des cycles. Une version plus jolie des bogues bloquants est disponible, même s’ils restent à corriger ;-)

Les arborescences de dépôt 10 sont créées sur les miroirs, pour permettre de gérer l’ajout de nouveaux miroirs au fur et à mesure. Pendant tout le cycle de publication, le fonctionnement est similaire à ce qui se passe en cauldron : l’arborescence release/ reçoit les mises à jour de paquets, rien dans updates/.
Le changement des dépôts de cauldron à 10 est nécessaire pour ne pas rester avec la version de développement une fois Mageia 10 officiellement publiée ; une réinstallation reste préconisée pour ne pas avoir de reliquat des bogues corrigés lors du cycle de publication (même si enlever les différentes versions de noyaux et de bibliothèques permet de faire un 1^er ménage, il peut y avoir des reliquats de configuration intermédiaire qui perdurent).

Cycle bêta : consolidation des tests et des choix pour la version à publier

Objectif : stabilisation des versions de logiciels envisagées, identification des correctifs à l’installeur.

Lancement du concours de visuels pour fonds d’écrans de Mageia 10, icônes et économiseurs : du 30 janvier 2026 au 25 février 2026. C’est la bêta2 qui vous fera découvrir la nouvelle apparence retenue pour Mageia 10.

Les pilotes nvidia posant des problèmes récurrents, il est envisagé de ne pas proposer leur intégration aux ISO (ils seraient à installer par la suite). Les tests sont les bienvenus. La version nvidia470 peut encore être configurée après installation initiale : elle est conservée pour les anciennes cartes graphiques—même si elle n’est plus maintenue tandis que la version 390 est obsolète et ne fonctionne plus avec les nouveaux noyaux Linux—et les versions nvidia580 et nvidia590 sont proposées (paquets nvidia-current_all et nvidia-newfeature-all permettant l’ajout des modules dkms), ainsi que le pilote ne fonctionnant qu’à partir des versions de cartes RTX. C’est le pilote nouveau qui est utilisé par défaut lors de l’installation initiale.

Les pilotes graphiques libres de AMD et Intel ont bien sûr aussi été mis à jour, ils sont disponibles directement dans les ISO live d’installation.

Les tests pour Plasma KDE avec la gestion par Wayland permettront d’identifier l’opportunité de proposer Wayland par défaut, le choix alternatif de Xorg restant disponible.

L’utilisation de clé USB persistante (fonctionnalité apparue avec Mageia 7) pourrait permettre d’avoir sur soi une clé d’installation live à jour et bénéficiant des derniers correctifs : démarrage avec clé USB live sur PC à installer, premiers diagnostics de bon fonctionnement du matériel sans installation—utilisation de la partition persistante pour prendre des notes—  afin de lancer l’installation dans les meilleures conditions, bénéficiant des correctifs de l’installeur notamment.

Par exemple, selon la date de publication de FreeCAD 1.1—prévue initialement courant février 2026—il pourrait être disponible dans les dépôts de paquet de Mageia 10 (pas sur les ISO, il n’y a déjà plus beaucoup de place :D).

Cycle version candidate : finalisation

Objectif : pré-version de la version finale, à publier « quand c’est prêt »

C’est l’occasion de finaliser les différentes documentations de Mageia 10.
Les errata ne conservent que ce qui n’a pas pu être corrigé avant publication et nécessitant une intervention manuelle, ils seront tenus à jour après publication pour les cas spécifiques découverts après coup lors d’une utilisation plus large de la distribution.
Les Notes de version ne vont plus évoluer beaucoup, permettant de stabiliser les traductions dans d’autres langues que l’anglais qui reste la référence.

Version finale

Les miroirs pour les paquets peuvent être mis à jour avec la version 10 : l’arborescence release/ ne va plus évoluer et les mises à jour de paquets arrivent dans updates/.

Peaufinement des visuels retenus pour la version 10.

La notification pour proposer de monter automatiquement de version de distribution à partir de Mageia 9 interviendra un peu de temps après la sortie de la version finale : le temps de finir de les mises à jour pour clore les bogues non encore corrigés pour la version finale.

Différences de fonctionnement entre version stable et le cycle de publication.

Le cycle de publication s’appuie sur Cauldron, la version en développement continu ou rolling-release :

• il n’y a pas d’updates/ : les paquets sont directement remplacés dans release/
• un corollaire est que lors d’une mise à jour d’un ensemble de paquets (correction), les miroirs ne seront pas forcément complètement à jour, ce qui peut demander une relance de urpmi --auto-update pour mise à jour complète : en cas d’échec temporaire, une relance plus tard est nécessaire
• ce genre de désynchronisation arrive peu souvent en version stable, un peu plus souvent en Cauldron—ce qui est normal (cela se fait particulièrement sentir lors d’une reconstruction en masse) ;-)

S’impliquer pour Mageia 10

À vous de décider ce que vous souhaitez faire ;-) En comprenant que c’est une version en évolution—certaines choses ne fonctionneront pas—et certaines pourront être corrigées pour la version finale (ou peu après :D). De quoi se mettre le pied à l’étrier pour la version suivante : nouveaux logiciels à (faire) empaqueter, nouvelles versions à prendre en compte…
C’est l’occasion de s’astreindre à lancer certaines applications à partir d’un terminal pour récupérer le maximum de logs possibles, ou d’apprendre à diagnostiquer une configuration spécifique causant des soucis—idéalement pour travailler en amont (upstream) pour faire prendre en compte des correctifs et améliorations.

Vous pouvez vous coordonner en français auprès de nos collègues de MLO pour effectuer au mieux vos remontées d’information.

Rien que les tests permettent de bénéficier de versions actualisées par rapport à Mageia 9 et remonter des bugs restant dans l’intégration de vos logiciels de prédilection à l’environnement de bureau de votre choix. Il y a aussi beaucoup de traductions à effectuer.

C’est l’opportunité de (re-)lire les documentations et les actualiser, notamment les nouvelles fonctionnalités.

Exemples d’utilisations

Je vous laisse ajouter des cas d’utilisation qui vous seraient spécifiques en commentaires.
J’ai la chance de participer à un fablab qui me donne accès à divers matériels pour tester :

• EeePC ne fonctionnant pas en x86_64 (donc i686 maintenant), netbooks hybrides (tablette tactile + clavier détachable) limités à 2 Go de RAM et un UEFI 32 bits exotique même quand le processeur gère le x86_64
• (très) vieux portables et ordis—pour la plupart des gens, vieux = plus de 5 ans—là, c’est plutôt (l’ami de Mickey<) de la période 2008-2014 : des MacBook Pro, des iMac, plein de core2duo / Athlon (ça c’est du x86_64 au moins) ou cartes nvidia déclarées obsolètes (des quadro à l’époque réputées de qualité professionnelle, on voit ce que ça veut dire pour nvidia… :/)
• (très) vieux périphériques : gamepad Sidewinder, volant MT Logic wheel pour supertuxkart avec connectique broche DA-15 jaune (si vous avez d’autres périphériques—préférentiellement en USB—je suis preneur _o/ et, oui, c’est pas loin de Paris…)
• quelques Raspberry Pi et assimilés—donc architecture ARM—mais ce n’est pas l’axe principalement retenu pour Mageia 10 :/ et pour le coup, Debian reste une valeur sûre pour la diversité des logiciels disponibles, même si des travaux communs avec le projet Fedora permettent de se tenir à niveau ;-)

Et bien sûr, des logiciels classiques dans un fablab qui fonctionnent bien (plutôt en flatpak) : Cura et Bambustudio pour l’impression 3D, IDE Scratch pour robots Thymio… et Inkscape / FreeCAD / KiCAD sur du matériel un peu plus récent et moins contraint en ressources ;-)

Si vous utilisez des window managers spécifiques, cela m’intéresse d’avoir des retours aussi (enlightenment, LXQt, WindowMaker… autres ?), Mageia proposant des installations cohérentes (intégration environnement, logiciels…) via les méta-paquets task- qui permettent d’installer un ensemble de dépendances automatiquement.

Bons tests _o/

Je sais que le mot "IA" sur LinuxFr, c'est un peu comme prononcer "systemd" en 2015 ; ça ne laisse personne indifférent. Et je comprends. La merdification est réelle, la bulle est réelle, les externalités sont réelles. Je n'ai aucune envie d'en rajouter une couche. Mais voilà, les lignes sont devenues floues, et j'ai pris le virage du coding assisté. D'abord avec curiosité et prudence, et maintenant les deux pieds dans le plat : ça ne remplace pas ma façon de penser, mais ça m'a ouvert des portes : des concepts que je ne maîtrisais pas, des langages que je n'aurais pas pris le temps de toucher avant ; l'assistant me permet d'explorer, de comprendre, et de construire des outils qui m'aident. Et j'espère qu'ils aident d'autres personnes aussi.

Sauf que voilà. Au début, j'étais prudent. Je vérifiais chaque commande, chaque accès. Et puis petit à petit, j'ai lâché prise. J'ai désactivé les confirmations, laissé l'agent tourner sans supervision, accepté les permissions sans lire. On connaît tous ce moment où on clique "Allow" les yeux fermés parce que c'est la quinzième fois qu'il demande. J'ai fait exactement ce qu'on ne devrait jamais faire en sécurité : faire confiance par défaut.

Et un jour, je me suis dit : je n'ai aucune idée de ce que cet agent envoie sur le réseau. Aucune.

Alors j'ai construit un proxy un peu.. particulier.

Sommaire

• Le constat
• Greywall et greyproxy
• Ce que j'ai observé
• Pourquoi ça compte
• Et après : vers un proxy sémantique
• Pour essayer
• La question

Cher journal,

Ça fait un bail que je n'ai pas vraiment contribué à l'open source. Mes derniers vrais projets publics, c'était Kivy et les projets autour… ça remonte à quelques années maintenant, et j'ai pris ma "retraite" sur ces projets.

Mais je n'ai jamais arrêté de coder. J'ai juste réalisé un truc sur moi-même : le code, c'est un peu comme la musique pour moi. J'aime construire des choses. Je m'exprime mieux avec un éditeur et un terminal qu'avec ma voix ou mes mots. C'est probablement pour ça que je suis là à t'écrire un journal au lieu de faire un talk quelque part.

Le constat

On a passé des années à construire des pare-feux, des IDS, du monitoring pour nos serveurs de prod. Sur des entreprises plus grandes, on traque les connexions suspectes… Et puis un agent IA débarque sur notre machine de dev, on lui dit "tiens, refactore-moi ce module", et il fait ce qu'il veut sur le réseau sans qu'on le sache.

C'est quand même un peu absurde, non ?

Le truc, c'est qu'il n'existe pas vraiment d'équivalent à tcpdump ou iptables pour les agents IA sur nos machines. Pas de couche d'observabilité entre l'agent et Internet. Ou on contrôle, on se fait notre liste d'outils qu'on accepte, ou on fait confiance parce que bon, la sécurité, c'est pas si important… vraiment ?

Greywall et greyproxy

Avec l'équipe de Greyhaven, on a construit deux outils open source :

Greywall est un bac à sable deny-by-default pour les agents IA. Pas de Docker, pas de VM. Ça utilise directement les mécanismes du noyau Linux (namespaces, Landlock, Seccomp, eBPF) pour isoler le processus. Sur Linux, l'isolation réseau passe par un device TUN dans un namespace réseau dédié ; le processus sandboxé ne peut structurellement pas contourner le proxy. Sur macOS, c'est un peu moins élégant en utilisant des variables d'environnement pour forcer un proxy socks5h, si l'outil ne le supporte pas, il ne peut quand même pas sortir. Ça fait le job pour la plupart des outils.

Greyproxy est le plan de contrôle réseau. Un proxy SOCKS5/HTTP avec un dashboard web temps réel. Chaque connexion sortante de l'agent apparaît dans le dashboard. Si aucune règle ne matche, la connexion reste en attente et tu peux l'autoriser ou la refuser en direct, sans relancer la session.

Concrètement, ça donne :

greywall -- claude

Et hop, Claude Code tourne dans son bac à sable. Tu ouvres http://localhost:43080 et tu vois en direct chaque domaine qu'il tente de contacter. Tu autorises api.anthropic.com, tu autorises github.com pour les pushes, tu refuses le reste. Tout est interactif, tout est visible.

Ce que j'ai observé

Au début, c'était juste des connexions supplémentaires. Tiens, c'est quoi ces appels à opencode.ai quand je démarre opencode ? Tiens, pourquoi Claude appelle 2x toutes les 4 minutes un domaine chez Google ? Entre de la télémétrie que l'on ne peut pas désactiver, ou des requêtes qui font "office" de regarder si une nouvelle version est disponible… 2x toutes les 4 minutes. Ce n'est pas le meilleur argument, mais contrairement aux autres sandboxes, au moins ici je le vois en temps réel, et je peux dire oui ou non sur ce que peut accéder la commande.

Le dashboard de greyproxy rend tout ça visible. Tu vois passer les requêtes DNS, les connexions TCP, les domaines contactés. Tu peux construire progressivement une liste d'autorisations adaptée à ton projet. Il y a même un mode apprentissage qui trace les accès filesystem avec strace et génère automatiquement un profil de sécurité.

Ce n'est pas un outil pour les paranos. C'est un outil pour ceux qui pensent que l'observabilité, c'est un droit, pas un luxe.

Pourquoi ça compte

Je sais que l'enthousiasme pour l'IA est réellement différent en fonction des gens. Les questions sur la qualité du code généré, la consommation énergétique, la centralisation chez les GAFAM ; tout ça est légitime.

Mais justement. Si on utilise ces outils (et beaucoup d'entre nous le font, même ceux qui restent prudents), autant le faire avec les yeux ouverts. Greywall, c'est pas un outil pour promouvoir l'usage des agents IA. C'est un outil pour que, si tu en utilises un, tu gardes le contrôle.

Il y a une phrase qu'on a mise sur le site et qui résume bien l'idée :

"The security layer around your tools should be independent of the company selling you the AI."

La couche de sécurité autour de tes outils ne devrait pas dépendre de la boîte qui te vend l'IA. Claude a son propre sandbox intégré, Codex a le sien. Mais tu fais confiance aux entreprises pour te protéger d'elles-mêmes ? C'est un problème d'indépendance, pas de technologie.

Greywall est agnostique. Ça marche avec Claude Code, Codex, Cursor, Aider, Goose, Gemini CLI, Cline, et une dizaine d'autres. Tu changes d'agent, ta couche de sécurité reste la même.

Et après : vers un proxy sémantique

Le greyproxy actuel travaille au niveau des connexions : il voit les domaines, les ports, les IPs. Il ne déchiffre pas le TLS, il ne lit pas le contenu. C'est déjà très utile pour contrôler les accès réseau.

Mais là où ça devient vraiment intéressant, c'est quand on commence à reconstruire les conversations LLM qui passent par le proxy. Pas en cassant le chiffrement ; en instrumentant le flux côté client. L'idée, c'est de construire un proxy sémantique qui comprend ce que l'agent envoie et reçoit, qui peut faire du remplacement de variables d'environnement à la volée (pour ne jamais exposer tes vrais secrets à l'API du LLM), et qui te donne une vision complète de ce que l'IA fait en ton nom.

On en est au début, mais la direction est claire : remettre l'humain au milieu du système. Pas comme un goulot d'étranglement, mais comme un observateur informé qui peut intervenir quand c'est nécessaire. C'est ce qui manque cruellement à des systèmes comme OpenClaw et à la plupart des outils d'orchestration d'agents.

Pour essayer

Installation rapide :

# Homebrew
brew tap greyhavenhq/tap && brew install greywall

# Ou via curl (pas taper)
curl -fsSL https://raw.githubusercontent.com/GreyhavenHQ/greywall/main/install.sh | sh

Ça tourne sur Linux et macOS. Sur Linux, il te faut bubblewrap et socat comme dépendances. Greyproxy s'installe comme service systemd si tu veux qu'il tourne en permanence.

Si tu veux comprendre les détails techniques de l'architecture (les 5 couches de sécurité, pourquoi on a abandonné Docker, comment fonctionne la capture réseau transparente), on a écrit un article technique détaillé ici : https://greyhaven.co/insights/why-we-built-our-own-sandboxing-sytem

La question

J'ai une vraie question pour la communauté. Ceux d'entre vous qui utilisent des agents IA pour coder (même occasionnellement, même à contrecœur) : comment vous gérez la sécurité ? Vous faites confiance par défaut ? Vous avez mis en place quelque chose ? Ou vous préférez ne pas y penser ?

Et pour ceux qui n'utilisent pas d'agents IA : est-ce que le manque de transparence et de contrôle fait partie des raisons ?

Ça m'intéresse vraiment de savoir :)

Open ModelSphere est un outil de modélisation et de gestion de modèles, qui combine les fonctionnalités de modélisation de processus, de données et UML, tout en offrant un environnement de gestion de modèles des plus flexibles. Il est aussi possible de générer des diagrammes via du code ou base de données.

Parce qu’il a été conçu en Java, Open ModelSphere peut être installé sur la plupart des plateformes, soit Windows, Linux et Unix.

Open ModelSphere permet aux utilisateurs de construire leurs modèles plus facilement, à partir de zéro ou via rétro-ingénierie provenant d’une variété de sources (SGBDR ou autres sources non-relationnelles comme Java).

Les utilisateurs peuvent choisir entre plusieurs systèmes cibles SQL, comme Oracle, Informix, SQL Server de Microsoft, Sybase et DB2 UDB. Ensuite, ils peuvent facilement employer le processus de génération pour mettre leurs bases de données à jour.

Open ModelSphere propose également une fonction de génération de rapport en format HTML améliorée, permettant une personnalisation du contenu et du format.

Il offre une documentation API ouverte qui facilite l’intégration de la solution Open ModelSphere dans les environnements de développement existants.

Grace à la notion de plugin, des fonctionnalités peuvent être ajoutées à l’application.

Historique

Au début des années 1990, des professeurs et des étudiants de l’Université Laval ont lancé le développement d’un outil CASE (Génie Logiciel Assisté par Ordinateur) qui allait devenir le produit commercial Silverrun. Ce n’est qu’en 2008 que l’entreprise a pris le virage de l’innovation ouverte en libérant le code source du logiciel. Il est rare qu’un logiciel de cette trempe soit libéré. De la documentation utilisateur et technique existe.

Énormément de patrons de programmation et de concepts sont employés par l’application qui est une vraie mine d’or pour tout développeur.

Pour ces raisons, j’ai décidé de faciliter l’usage de l’application en lui permettant de fonctionner avec Java 11 et Gradle. Si vous avez du temps, il ne faut pas hésiter à y participer.

Physiocab est un logiciel libre de gestion de cabinet de kinésithérapie, développé sous licence Affero GPL 3.0 et hébergé sur Codeberg. Le projet est porté par la société Allium SAS, dans le cadre de la plateforme communautaire Kalinka, dédiée aux kinésithérapeutes francophones.

Le projet vient de passer en beta publique (v0.9) et cherche des testeurs et contributeurs.

Pourquoi un logiciel libre pour les kinés ? Le secteur de la santé libérale souffre d'une offre logicielle dominée par des solutions propriétaires onéreuses, souvent opaques sur le traitement des données de santé. Physiocab propose une alternative : un code auditable, des données stockées localement sous la responsabilité du praticien.

Fonctionnalités

La beta couvre déjà un large périmètre fonctionnel :

• Planning hebdomadaire en drag & drop, avec export PDF et gestion des semaines exceptionnelles, particulièrement orienté vers les kinés intervenant en multi-établissements.
• Bilans Diagnostiques Kinésithérapiques (BDK) avec tests standardisés (TUG, Tinetti, Handgrip, EVA, évaluation du risque de chute…), export de PDF et historique comparatif.
• Suivi des séances avec de multiples exercices structurés (équilibre, force, endurance, mobilisation), chronométrage automatique et calcul de progression.
• Application tablette en PWA : fonctionne hors connexion grâce à un Service Worker, s'installe sans passer par un store, interface optimisée tactile.

Stack technique

Backend : Python 3.10+
Base de données : PostgreSQL 12+
Frontend tablette : PWA (Progressive Web App)

L'application est multi-plateforme côté client (Windows, macOS, Linux, iOS, Android). La communication entre l'appli de bureau et l'appli PWA se fait de manière directe via PeerJs. Cette méthode ne nécessite pas de préparation contraignante comme l'ouverture de ports.

Les données sont stockées localement, ce qui implique que le praticien reste maître de ses sauvegardes et de sa conformité RGPD.

Le logiciel a été testé par un kinésithérapeute en situation réelle plusieurs jours d'affilée.

Modèle économique

L'utilisation est gratuite, sans limite dans le temps et sans frais cachés, la licence Affero GPL 3.0 en étant la garantie. Un support payant sur devis est proposé pour les praticiens souhaitant une installation assistée, une formation à distance, des développements sur mesure ou un audit de sécurité.