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/

JemaOS est un projet de système d’exploitation français, développé à Sophia Antipolis, qui propose une réponse concrète aux enjeux de souveraineté et de numérique responsable.

Le contexte est marqué par l’arrêt imminent du support de Windows 10, une transition qui menace de mettre au rebut près de 400 millions de PC encore fonctionnels à travers le monde. Face à cette obsolescence matérielle massive, JemaOS permet de réhabiliter ces parcs informatiques (machines de 2010 à 2025) en offrant une alternative fluide et sécurisée.

Architecture Open-Core et Optimisation Cible

Sous le capot, JemaOS s’appuie sur un modèle Open-Core combinant des briques de Gentoo Linux, Arch Linux et Chromium. Pour garantir des performances maximales sur du matériel ancien, le système mise sur une optimisation par compilation pour l’architecture cible. Cette approche permet de tirer le meilleur parti de chaque processeur, là où des distributions génériques peuvent accuser des lenteurs.

Sécurité par immuabilité et sandboxing

La sécurité du système repose sur deux piliers majeurs :

• L’immuabilité : Le système de fichiers racine est verrouillé en lecture seule, protégeant le cœur de l’OS contre les corruptions accidentelles ou les écritures malveillantes.
• Le sandboxing : Toutes les applications et processus sont isolés nativement dans des « bacs à sable ». Cette isolation stricte empêche une faille dans une application de compromettre l’intégralité du système, rendant l’usage d’antivirus tiers obsolète.

Pour l’interface, le choix s’est porté sur Aura Shell (Ash) afin d’offrir une expérience utilisateur réactive et épurée.

Le « dispositif Jema » : le Plug & Play pour s’affranchir des configurations complexes pour les non-initiés

L’aspect le plus original de JemaOS est son mode de déploiement via le dispositif Jema (NdM (rectifiée le 22 mars suite à mise à jour de la doc du projet): qui est au format clé USB mais est « un véritable système embarqué complet. Faisant l'objet d'un brevet, (…) Intégrant son propre processeur, sa mémoire vive (RAM) et son espace de stockage interne). » L’idée est de supprimer toute la complexité habituelle : plus besoin de créer des clés USB bootables, de partitionner des disques ou de modifier des réglages BIOS/UEFI complexes.

On branche le dispositif, et le système démarre. Grâce à un chargeur d’amorçage compatible Secure Boot (via « Enroll MOK »), JemaOS tourne en isolation complète. Il exploite les ressources (CPU/RAM) de la machine hôte sans jamais toucher aux données du disque dur interne.

Écosystème applicatif : PWA et P2P

Pour rester léger, le système déporte la partie logicielle vers des Progressive Web Apps (PWA), dont beaucoup fonctionnent en Peer-to-Peer (P2P) pour garantir la confidentialité :

• Anima & Nephtys : Messagerie et visioconférence en P2P.
• JemaNote : Prise de notes avec assistance IA (Mistral).
• OsiVibe : Un éditeur vidéo 4K multi-pistes qui s’exécute directement dans le navigateur.

Gestion de parc et souveraineté

Le modèle économique semble s’appuyer sur une offre SaaS pour les entreprises, permettant une gestion centralisée assez complète :

• Pilotage de parc : Suivi des machines, sauvegardes et gestion des droits d’accès.
• Administration : Gestion des dispositifs Jema et support technique.
• Souveraineté : L’infrastructure Cloud est hébergée en France, ce qui permet de rester sous protection du RGPD et d’échapper au Cloud Act américain.

Une initiative française intéressante à suivre pour ceux qui s’intéressent au numérique responsable.

NdM: les offres Pro/Ultime/Premium sont orientées entreprises avec un paiement mensuel par utilisateur. Les mises à jour OTA majeures sont payantes. Il est possible d'utiliser JemaOS sans payer (cf la documentation) en désactivant les mises à jour automatiques et installant manuellement les nouvelles versions.
Sur les 14 dépôts publics : la licence varie suivant les dépôts (MIT, AGPLv3, BSD avec clause publicitaire (dont une concernant Google (sic), un dépôt avec le logiciel WidevineCdm propriétaire de Google). La plupart des dépôts n'ont qu'un seul contributeur johnkryptochain, visiblement intéressé par les cryptomonnaies, Telegram et les NFT ; l'autre contributeur a deux commits sur un unique dépôt. L'entreprise qui porte le projet a 10 salariés d'après le site.

En ce mardi 10 mars, la communauté du Projet Fedora sera ravie d’apprendre la disponibilité de la version Beta de Fedora Linux 44.

Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora Linux 44 et réduisant du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.

La version finale est pour le moment fixée pour le 14 ou le 21 avril.

Sommaire

• Expérience utilisateur
• Gestion du matériel
• Internationalisation
• Administration système
• Développement
• Projet Fedora
• Tester

Expérience utilisateur

• L’environnement de bureau GNOME est proposé dans sa version 50 ;
• Les variantes de Fedora reposant sur l’environnement KDE Plasma utiliseront le configurateur Plasma Setup pour la post-installation de manière analogue à GNOME avec GNOME init setup ;
• De même ces variantes utiliseront Plasma Login Manager (PLM) comme gestionnaire de connexions au lieu de SDDM ;
• L’environnement de bureau Budgie passe à la version 10.10 et tourne avec Wayland au lieu de X11 ;
• La variante Games Lab est remaniée pour passer de Xfce à KDE Plasma et ainsi utiliser Wayland pour avoir une couche graphique plus moderne ;
• Le spin MiracleWM remplace l’environnement nwg-shell avec Dank Material Shell (qui est basé sur QuickShell) ;
• Le gestionnaire de paquets universel PackageKit, utilisé par GNOME Logiciels entre autres, exploite dorénavant dnf5 au lieu de la version précédente ;
• L’installateur Anaconda ne fournira plus de configuration réseau par défaut pour les interfaces filaires mais uniquement pour les installations n’utilisant pas une image Live ;
• La suite TeXLive nouveau millésime 2025 est proposée ;
• Le paquet d’intégration avec la bibliothèque Qt5 pour LibreOffice est supprimé, les environnements de bureaux utilisant Qt6 maintenant.

Gestion du matériel

• Pour les systèmes Aarch64 avec un EFI, la sélection du device tree sera automatique au démarrage en particulier pour les ordinateurs portables Windows ARM ;
• Le module noyau NTSYNC est activé quand les paquets Steam ou WINE sont installés pour améliorer les performances et la compatibilité des applications Windows et en particulier les jeux ;
• mkosi-initrd est proposé comme alternative à dracut pour générer des fichiers initrd pour être évalué avant un éventuel remplacement.

Internationalisation

• L’outil d’aide à la saisie IBus évolue à la version 1.5.34 ;
• Le module Ibus pour la transcription vocale est mis à jour à la version 0.7.0 qui propose un module pour utiliser le modèle Whisper d’OpenAI en plus du modèle Vosk déjà employé.

Administration système

• Les images Fedora Cloud n’ont plus une partition /boot dédiée mais utilisent un sous-volume btrfs à la place ;
• L’émulateur QEMU n’aura plus de paquets compatibles avec l’architecture 32 bits i686, car cette architecture n’est plus maintenue par le projet officiel. Mais exécuter un système 32 bits reste évidemment toujours possible avec cet utilitaire ;
• Le gestionnaire de paquets nix est introduit dans Fedora Linux ;
• Le gestionnaire de paquets Kubernetes Helm utilise la version 4 dorénavant tandis que la version 3 reste disponible avec le paquet helm3 ;
• Le gestionnaire de bases de données passe par défaut de la version 10.11 à la version 11.8 ;
• L’outil Ansible est mis à jour à sa 13ᵉ version ;
• Les paquets pour le gestionnaire de bases de données MySQL avec le nom community-mysql sont supprimés.

Développement

• La chaine de compilation GNU progresse avec GCC 16.1, binutils 2.46, glibc 2.43 et gdb 17.1.
• La chaine de compilation LLVM version 22 est proposée ;
• L’outil de configuration de l’environnement de compilation CMake passe à la version 4.2. Cela entraine une rupture de compatibilité pour les projets ayant besoin de la version 3.5 ou inférieure ;
• Par ailleurs CMake utilisera le générateur ninja au lieu de make par défaut pour compiler un projet ;
• La bibliothèque C++ Boost passe à la vitesse supérieure avec la version 1.90 ;
• Le langage de programmation Ruby prend de la valeur avec sa version 4.0 carats ;
• Le paquet ruby-build est d’ailleurs scindé en plusieurs sous paquets pour rendre son utilisation plus modulaire ;
• Le langage Go saute vers sa version 1.26 ;
• Le langage PHP passe à la version 8.5 ;
• Le langage Haskell devient plus fonctionnel avec son compilateur GHC version 9.10 et sa suite de paquets Stackage 24 ;
• La boîte à outils web pour Python nommé Django serpente à la version 6 ;
• Des paquets nodejsXX-bin et nodejsXX-npm-bin sont fournis pour créer les fichiers des binaires /usr/bin/node et /usr/bin/npm sans nom de versions qui pointent vers la version de référence voulue pour simplifier la vie des utilisateurs ;
• La bibliothèque rust-bindgen pour lier du code Rust avec du code C ou C++ est empaquetée à la version 0.72 ;
• De même pour les bibliothèques rust-coreutils et rust-nu qui vont respectivement de la version 0.0.27 à 0.5.x et de la version 0.99.1 à 0.109.2 ;
• La bibliothèque d’édition des métadonnées des fichiers audio taglib passe à la version 2.0 ;
• Le parseur et moteur de rendu de CommonMark cmark progresse vers la version 0.31 ;
• La machine virtuelle Java OpenJDK 21 n’est plus proposée dans les dépôts ;
• Le paquet python-mock a été supprimé des dépôts.

Projet Fedora

• Les paquets avec des fichiers identiques utilisent des liens physiques par défaut ;
• Les systèmes atomiques ne fournissent plus de bibliothèques et de binaires FUSE 2 ;
• Ces systèmes atomiques ne prennent plus en charge les règles dépréciées pkla polkit ;
• Packit remplace Fedora CI et Zuul pour démarrer les instances d’intégration continue pour compiler et exécuter les tests des paquets après un pull request ;
• L’outil d’intégration continue Konflux peut être utilisé pour générer des images reposant sur bootc ;
• D’ailleurs Konflux est aussi utilisé en lieu et place de Jenkins pour construire les images Fedora CoreOS ;
• Koji ne prend plus en charge le service distant RedHat Image Builder Service, uniquement les instances locales peuvent être utilisées ;
• Les labels des images pour conteneurs passent à org.opencontainers.image.title et org.opencontainers.image.licenses pour suivre la spécification OpenContainers ;
• Les paquets autour du langage R ont de nouvelles macros et une meilleure uniformisation des bonnes pratiques pour simplifier leur maintenance.

Tester

Durant le développement d’une nouvelle version de Fedora Linux, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est de tester pendant une journée une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, l’internationalisation, etc. L’équipe d’assurance qualité élabore et propose une série de tests en général simples à exécuter. Suffit de les suivre et indiquer si le résultat est celui attendu. Dans le cas contraire, un rapport de bogue devra être ouvert pour permettre l’élaboration d’un correctif.

C’est très simple à suivre et requiert souvent peu de temps (15 minutes à une heure maximum) si vous avez une Beta exploitable sous la main.

Les tests à effectuer et les rapports sont à faire via la page suivante. J’annonce régulièrement sur mon blog quand une journée de tests est planifiée.

Si l’aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.

Si vous avez déjà Fedora Linux 43 ou 42 sur votre machine, vous pouvez faire une mise à niveau vers la Beta. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.

Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.

En cas de bogue, n’oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Weblate. N’oubliez pas de consulter les bogues déjà connus pour Fedora 44.

Bons tests à tous !

Le collectif Emmabuntüs annonce deux publications récentes mettant fortement l’accent sur l’accessibilité numérique, fruit d’un travail mené en grande partie avec et par des bénévoles non-voyants et malvoyants, directement impliqués dans la conception, les tests et les améliorations ergonomiques de la distribution.

La version Emmabuntüs Debian Édition 6 1.00, basée sur Debian 13 (Trixie) avec les environnements Xfce et LXQt, introduit de nombreuses améliorations destinées aux personnes malvoyantes ou non-voyantes : interface dédiée à l’accessibilité, synthèse vocale améliorée (espeak, MBROLA, Piper), profils Orca, support d’embosseuses Braille, intégration de LIOS (OCR), ainsi que divers scripts simplifiant la prise en main. Cette version est notamment destinée à des déploiements au Togo, en partenariat avec les associations françaises A.S.I YOVOTOGO, Mutualistes Sans Frontières et la FETAPH (Fédération Togolaise des Associations de Personnes Handicapées).

En parallèle, la version Emmabuntüs Debian Édition 5 1.05, basée sur Debian 12 (Bookworm) et disponible en 32 et 64 bits, bénéficie des mêmes avancées en matière d’accessibilité. Elle permet ainsi de poursuivre le reconditionnement d’ordinateurs plus anciens, tout en offrant une expérience utilisateur inclusive.

Ces deux versions illustrent l’engagement d’Emmabuntüs en faveur de l’inclusion numérique, du logiciel libre, du réemploi de matériel informatique, ainsi que la place centrale offerte à l’expertise d’usage apportée par ses bénévoles concernés par le handicap visuel.

Le projet reste ouvert aux contributions, notamment pour les tests d’accessibilité, la documentation et l’amélioration des outils destinés aux utilisateurs malvoyants ou non-voyants.

Fin mars, nous publierons une nouvelle version d’Emmabuntüs Debian Édition 6 1.01, plus légère et plus modulable, afin de permettre à chacun de choisir les logiciels dont il a réellement besoin. Nous recherchons des bénévoles pour participer aux tests de cette version.