Je suis agriculteur en Creuse et je code sur mon temps libre. J'ai commencé à m'intéresser à la question de la récupération de compte en développant ARC PVE Hub, un site destiné à fédérer une communauté de joueurs. Je n'ai jamais compris pourquoi il fallait transmettre son email pour régénérer un mot de passe — ça déplace la sécurité du compte vers un fournisseur SMTP tiers, qui n'est pas contrôlé par l'utilisateur.

J'ai donc imaginé un protocole de récupération sans email, sans SMS et sans tiers. Le travail s'est étoffé en partenariat avec un assistant IA (Claude), comme outil de réflexion et de mise en forme — j'y reviens en fin de dépêche dans une note de transparence.

L'incident de sécurité ANTS du 15 avril 2026 a publiquement illustré le problème. J'en ai eu connaissance après avoir développé SelfRecover, ce qui m'a confirmé la pertinence d'un protocole sans dépendance à l'email. SelfRecover est publié sous AGPL-3.0-or-later sur GitHub.

Cette dépêche présente le protocole, ses choix de conception, ses limites assumées, et la comparaison avec les approches existantes (Keycloak Recovery Codes en particulier, qui m'a été suggéré en relecture). Audit communautaire bienvenu.

Sommaire

• • Le contexte
  • Le protocole en deux phrases
  • Deux modes d'adoption
    • Mode Full — Sans email
    • Mode Lite — Avec email + mot mémorisé
    • Synthèse
  • SelfRecover vs Keycloak Recovery Codes
  • Que se passe-t-il si l'utilisateur perd son secret ?
    • Niveau 1 — Passphrase oubliée
    • Niveau 2 — Passphrase perdue, mais identifiant + mot de récupération retenus
    • Niveau 3 — Accès complètement perdu
    • Chat administrateur humain en mode restreint — état actuel
    • Évolution prévue (en réflexion) : pré-traitement optionnel par chatbot LLM local
    • Démo standalone vs implémentation de référence
    • Pourquoi assumer cette friction
    • Pour quel public
  • Modèle de menace assumé
  • Démos en ligne
  • Code et image Docker
  • Licence et philosophie
  • Note de transparence
    • Conception en partenariat avec un assistant IA
    • Plan d'audit
    • Statut du projet
    • Engagement communauté LinuxFr et culture du libre
  • Pour aller plus loin

Le contexte

Depuis l'essor du web, la réponse standard à « l'utilisateur a oublié son mot de passe » est « on lui envoie un lien de réinitialisation par email ». C'est devenu si universel qu'on oublie ce que ça implique :

• La sécurité du compte est déléguée au fournisseur de la boîte mail (Gmail, Outlook, ProtonMail). Si la boîte mail tombe, le compte aussi.
• Le canal email est régulièrement exploité par phishing : campagnes imitant des mails de réinitialisation légitimes pour capturer les mots de passe.
• Les bases de données qui stockent les emails des utilisateurs deviennent une cible massive : leur fuite expose à la fois l'identité et les vecteurs de récupération.

L'incident de sécurité ANTS illustre une autre facette du problème de gestion des données d'authentification dans les services en ligne. Détecté le 15 avril 2026 et rendu public le 20 avril, il a touché 11,7 millions de comptes selon les communiqués officiels. La cause technique identifiée est une faille d'énumération de type IDOR (Insecure Direct Object Reference) : il était possible d'accéder aux données d'un autre compte en modifiant un identifiant dans une URL. La fuite ne concerne ni les mots de passe, ni les pièces justificatives, mais les données personnelles associées aux demandes de titres.

Devant ces limites structurelles autour de l'authentification web, SelfRecover propose une inversion : conserver le secret de récupération chez l'utilisateur, et utiliser le navigateur pour faire les calculs cryptographiques nécessaires à la vérification. Le serveur ne détient plus que des dérivés, jamais les secrets bruts.

Le protocole en deux phrases

Côté navigateur, on calcule HMAC-SHA256(secret, domaine) : une fonction cryptographique standard qui combine le secret de l'utilisateur avec le nom de domaine du site, et produit une empreinte impossible à inverser. Côté serveur, on ne stocke que cette empreinte, en plus protégée par un hash adaptatif et memory-hard : Argon2id, qui est le standard moderne recommandé contre les attaques par brute force.

Deux propriétés découlent de cette construction :

• Le secret brut ne quitte jamais le poste de l'utilisateur.
• Un secret capturé sur un site A (par exemple via phishing) est mathématiquement inutilisable sur un site B : la dérivation HMAC produit des empreintes différentes pour des domaines différents. C'est de l'anti-phishing par construction, pas par convention.

Note conceptuelle : l'inspiration vient des machines à rotors historiques type Enigma. Le principe partagé est qu'une même configuration secrète, présente des deux côtés (émetteur et récepteur), permet de produire et vérifier un message dérivé. La cryptographie moderne (HMAC-SHA256 ici) repose sur des fondations mathématiques différentes, mais ce principe de dérivation contrôlée par un secret commun est resté.

Deux modes d'adoption

SelfRecover propose deux modes selon le contexte de déploiement.

Mode Full — Sans email

L'application abandonne entièrement le flow de réinitialisation par email. L'utilisateur génère une passphrase diceware à l'inscription (liste EFF de 7 776 mots, 4 à 7 mots par défaut), qu'il mémorise ou stocke dans son gestionnaire de mots de passe. Cette passphrase, combinée au nom de domaine du site via HMAC-SHA256, permet de réinitialiser le mot de passe sans aucune dépendance externe.

Pour qui : nouveaux projets qui veulent s'affranchir de SMTP dès la conception, ou services qui adoptent un modèle de menace post-fuite (l'email n'est plus considéré comme un canal de confiance).

Mode Lite — Avec email + mot mémorisé

L'application conserve le flow de réinitialisation par email habituel, mais y ajoute une étape supplémentaire : l'utilisateur saisit un mot mémorisé (choisi à l'inscription) qui est dérivé HMAC-SHA256 côté navigateur. Le mot brut n'est jamais transmis au serveur. La validation combine donc deux facteurs :

1. La possession de la boîte mail (lien reset reçu)
2. La connaissance du mot mémorisé (dérivé HMAC côté client)

Pour qui : applications existantes qui ne peuvent abandonner SMTP du jour au lendemain, mais veulent durcir progressivement leur flow de récupération. Conséquence : un email intercepté seul ne suffit plus à compromettre un compte — il faut aussi connaître le mot mémorisé.

Synthèse

Mode	Canal email	Crypto utilisateur	Cible
Full	Aucun	Passphrase diceware EFF + HMAC	Nouveaux projets
Lite	Conservé	Mot mémorisé + HMAC	Applications existantes

SelfRecover vs Keycloak Recovery Codes

Lors de la relecture de cette dépêche, devnewton a soulevé une question importante : quelle est la différence avec les Recovery Codes de Keycloak ?

Keycloak est l'IAM (Identity and Access Management) open-source de référence, maintenu par Red Hat sous licence Apache 2.0, déployé dans de nombreuses organisations depuis plus d'une décennie. Son mécanisme de Recovery Codes est un fallback d'authentification à deux facteurs : si l'utilisateur perd son téléphone TOTP, il peut saisir un code de secours préalablement généré côté serveur.

Note importante de positionnement : les Recovery Codes Keycloak adressent le cas « j'ai perdu mon 2FA mais je connais toujours mon mot de passe principal ». Le password reset principal de Keycloak utilise, lui, le canal email standard (configuration SMTP dans l'onglet Email de l'admin console).

SelfRecover s'attaque à un cas différent : « j'ai oublié mon mot de passe principal et je ne veux pas dépendre de l'email pour le récupérer ». Concrètement :

Aspect	Keycloak Recovery Codes	SelfRecover
Cible	Fallback 2FA	Password recovery sans email
Architecture	Serveur IAM standalone (Java + BDD + admin)	Bibliothèque à intégrer dans le code de l'application
Source du secret	Serveur génère, utilisateur sauvegarde	Utilisateur génère/mémorise (diceware ou mot mémorisé)
Stockage utilisateur	Codes à sauvegarder physiquement	Passphrase mémorisable (mode Full) ou mot mémorisé (mode Lite)
Email reset principal	Reste nécessaire (SMTP configuré dans l'admin)	Aucun (mode Full) ou en complément (mode Lite)
Anti-phishing crypto	Pas spécifique au mécanisme	Dérivation HMAC par domaine : un secret capturé sur un site est mathématiquement inutilisable ailleurs
Licence	Apache 2.0	AGPL-3.0-or-later
Maturité	10+ ans, audité, déployé largement	Récent, audit communautaire bienvenu

Pour la majorité des projets qui acceptent l'email comme canal de récupération, Keycloak (et son écosystème) reste le bon choix. SelfRecover s'adresse aux applications qui veulent réduire ou supprimer leur dépendance à SMTP, et qui n'ont pas besoin de la richesse d'un IAM complet (multi-realm, OIDC/SAML, fédération d'identité, etc.).

Que se passe-t-il si l'utilisateur perd son secret ?

C'est la question critique d'un protocole de récupération. SelfRecover y répond par escalade progressive sur trois niveaux, complétée par un système de litiges et un chat administrateur pour les cas extrêmes.

Niveau 1 — Passphrase oubliée

L'utilisateur saisit son username + sa passphrase diceware (match exact). Sur succès, un nouveau mot de passe est généré et affiché une seule fois. Anti-brute force : 3 tentatives par 15 minutes, 3 blocages successifs → éjection vers L2.

Niveau 2 — Passphrase perdue, mais identifiant + mot de récupération retenus

L'utilisateur saisit son identifiant public (numéro client, identifiant métier — fourni par le site) et son mot de récupération dérivé HMAC-SHA256 côté navigateur. 3 tentatives maximum avec compteur visible. Sur 3 échecs → redirection vers L3. Un litige est automatiquement créé (LIT-XXXX), tracé en base, admin notifié. Les litiges auto-résolus sont purgés après 24 heures.

Niveau 3 — Accès complètement perdu

Entrée par un lien discret « accès perdu » sur la page de connexion. L'utilisateur saisit son identifiant public en premier (anti-timing : délai forcé de 2 à 3 secondes), puis remplit un formulaire de scoring multi-facteur :

Catégorie	Champs	Points
Identifiant public	4	20
Mot de récupération (dérivé HMAC)	5	25
Username	3	30
Passphrase (fragments)	3	25

Bonus passifs : IP connue (+5), fingerprint connu (+5).

• Score ≥ 60/100 → compte récupéré, nouveau mot de passe généré
• Score < 60/100 après 3 tentatives → le compte passe en mode restreint : l'utilisateur n'a plus accès qu'au chat administrateur, le compte n'est ni utilisable ni écrasable tant que l'admin n'a pas validé
• Cooldown : 1 heure entre tentatives

Chat administrateur humain en mode restreint — état actuel

Dans l'implémentation actuelle (déployée en production sur ARC PVE Hub), le chat L3 est un canal direct entre l'utilisateur en mode restreint et un administrateur humain du site. Pas d'intermédiaire automatisé, pas de bot.

Le canal de chat est bidirectionnel et fonctionne en polling (pas WebSocket temps réel, pour rester simple). L'admin vérifie l'identité par l'échange et décide manuellement :

Accorder la récupération : mot de passe régénéré, compteurs réinitialisés, litige clôturé, mode restreint levé.

Refuser la récupération : ban temporaire de 24 heures, pas de nouveau litige possible pendant cette fenêtre, compteur de refus incrémenté (1/3, 2/3, 3/3). À chaque clic, l'interface admin rappelle explicitement les conséquences via une modale de confirmation (ban 24h aux refus 1 et 2, suppression définitive au 3e refus).

Au 3e refus, le compte est définitivement supprimé : décision exclusivement humaine, prise en pleine connaissance de cause par l'admin via la modale d'avertissement explicite. La suppression libère l'identifiant public pour une nouvelle inscription.

Principe de design MySelf : aucune destruction de données utilisateur n'est déclenchée sans validation humaine consciente. L'interface admin explicite systématiquement les conséquences avant chaque action irréversible. Une IA peut se tromper ou être manipulée ; lui déléguer la décision de supprimer un compte créerait une surface d'attaque.

Ce mécanisme empêche un attaquant de spammer les litiges indéfiniment : chaque refus lui coûte 24 h, et trois échecs effacent toute trace. Un propriétaire légitime bloqué par erreur peut retenter après chaque fenêtre de ban, ou se réinscrire depuis zéro si totalement verrouillé.

Évolution prévue (en réflexion) : pré-traitement optionnel par chatbot LLM local

En complément du chat admin humain (qui resterait toujours disponible), une couche de pré-traitement par un agent conversationnel local (Ollama auto-hébergé) est en cours de design. Le chatbot poserait les questions initiales de vérification d'identité et estimerait si la demande est légitime. Sur estimation positive, le mot de passe serait régénéré directement ; sur doute, l'admin humain reprendrait la main.

Cette option serait configurable par site qui déploie (activable ou non), et le chatbot ne se substituerait jamais à l'admin pour les décisions destructives (suppression de compte) — ces décisions resteraient exclusivement humaines, conformément au principe MySelf énoncé plus haut.

L'enjeu principal en cours de réflexion : calibrer le seuil de confiance du chatbot pour ne pas créer un nouveau vecteur d'attaque par social engineering (un attaquant pourrait essayer de manipuler le LLM par prompts).

Démo standalone vs implémentation de référence

La démo publique (bi-self.my-self.fr/selfrecover/) ne couvre que les niveaux L1 et L2, car L3 nécessite une interface admin, un système de disputes et un dashboard — trop pour une démo à page unique.

L'implémentation de référence en production se trouve sur ARC PVE Hub, un site communautaire de joueurs ARC RAIDERS qui sert de terrain de test à l'écosystème MySelf. L1 + L2 + L3 + mode restreint + chat admin + dispute system y sont fonctionnels.

Pourquoi assumer cette friction

Dans la vie réelle, si l'on perd sa carte bancaire, son code, sa pièce d'identité, son adresse et sa date de naissance, on ne récupère pas son compte bancaire par email. On passe en agence avec preuve d'identité.

SelfRecover applique la même logique en ligne : la sécurité réelle nécessite parfois un passage par l'humain ou un processus d'identification rigoureux. Cette friction est assumée comme un trade-off conscient, pas comme une limitation à compenser.

Pour quel public

Adapté :
- Applications avec un administrateur actif et disponible pour traiter les litiges (forum communautaire, association, e-commerce indépendant, boutique en ligne militante)
- Sites où la sécurité prime sur la fluidité de récupération (services manipulant des données sensibles)
- Communautés à taille humaine (du forum de 50 membres au service de quelques milliers d'utilisateurs)

Non adapté :
- Plateformes à très grande échelle sans admin individuel (réseaux sociaux massifs, services publics avec millions d'utilisateurs) — le volume de litiges dépasse les capacités d'un humain réactif
- Services où une friction de récupération est inacceptable (gaming compétitif, services temps-réel)
- Projets sans maintenance active (l'admin doit pouvoir répondre aux litiges dans des délais raisonnables)

Pour ces cas, un IAM mature comme Keycloak avec ses mécanismes éprouvés reste plus adapté.

Modèle de menace assumé

Pour la transparence, voici les classes d'adversaires explicitement hors périmètre du protocole :

• Compromission du poste utilisateur (logiciels malveillants, RAT, keyloggers) — un attaquant qui contrôle le poste peut capturer la passphrase à la saisie, indépendamment du protocole.
• Compromission du navigateur (extensions malveillantes, exploits 0-day) — même cause, même effet : si le moteur JS qui calcule HMAC est compromis, la sortie l'est aussi.
• Coercition physique — SelfRecover n'offre pas de plausible deniability (pas de second compte caché ou décoy).
• Cryptanalyse théorique de SHA-256 / HMAC / Argon2id — un cassage mathématique de ces primitives mettrait à mal la quasi-totalité des systèmes cryptographiques modernes, pas seulement SelfRecover.

Ces limitations sont le périmètre normal d'un protocole côté navigateur. Pour les usages à plus haute exigence (cérémonies cryptographiques sensibles, génération initiale de clé maître), MySelf-Live est annoncé dans la roadmap V0.2 : une distribution Linux Live USB minimale, RAM-only, signée GPG, qui isolerait les opérations sensibles du système hôte. Pour les usages courants à fort enjeu, Tails ou Qubes OS offrent déjà ce niveau d'isolation et sont recommandés.

Démos en ligne

• Mode Full (sans email) : https://bi-self.my-self.fr/selfrecover/
• Mode Lite (email + mot mémorisé) : https://bi-self.my-self.fr/selfrecover/lite.html
• Comparatif sécurité 8 adversaires × 3 modèles : https://bi-self.my-self.fr/selfrecover/comparison.html

Aucune inscription préalable n'est requise. Les données sont éphémères côté serveur.

Code et image Docker

• Repo : https://github.com/Pierroons/my-self/tree/main/bi-self/selfrecover
• Whitepaper FR : https://github.com/Pierroons/my-self/blob/main/bi-self/selfrecover/docs/whitepaper-fr.md
• Threat model : https://github.com/Pierroons/my-self/blob/main/bi-self/selfrecover/docs/threat-model.md
• Image Docker multi-arch (amd64 + arm64) :

docker run -p 8080:8080 ghcr.io/pierroons/selfrecover:v0.1.1

La démo de référence tourne sur PHP 8.0+ et SQLite (~600 lignes auditables, zéro dépendance externe). Tag GPG-signé v0.1.1, release datée du 5 mai 2026.

Licence et philosophie

AGPL-3.0-or-later. Toute version déployée publiquement doit publier ses modifications sous la même licence. Pas de capture SaaS possible.

SelfRecover est une brique du méta-projet MySelf, un écosystème de modules auto-hébergés qui couvre l'identité, la modération communautaire, le droit, et l'agriculture.

Un module complémentaire répond de manière directe à la problématique illustrée par l'incident ANTS : SelfDataGuard chiffre les données utilisateur côté client de telle sorte qu'une fuite de base de données ne livre que des blobs inexploitables. Le code est public, AGPL, en v0.1.0-beta — une dépêche dédiée pourra suivre quand le module aura plus de maturité (audit communautaire, retours d'intégration).

Note de transparence

Conception en partenariat avec un assistant IA

Ce protocole a été conçu et codé en partenariat avec un assistant IA (Claude), comme outil de réflexion, de revue critique, et d'écriture de code.

Pour être totalement transparent : je ne suis pas développeur de formation. Mon expérience technique vient du dev web amateur (ARC PVE Hub, un site destiné à fédérer une communauté de joueurs ; un outil de gestion de stock pour mon entreprise ; quelques sites perso). Pour SelfRecover, l'écriture des primitives cryptographiques et la mise en œuvre du protocole ont été largement assistées par l'IA, sur la base de mes choix architecturaux et de ma vision.

Ce qui vient de moi (humain) :
- La vision (souveraineté numérique, refus du SMTP comme canal de récupération)
- Les choix philosophiques (AGPL-3.0-or-later, fallback humain assumé, aucune destruction de données sans validation humaine consciente)
- Le contexte initial (besoin né en développant ARC PVE Hub)
- Chaque décision de trade-off d'architecture
- La responsabilité juridique et morale du code publié sous mon nom et signé GPG

Ce qui vient de l'IA :
- L'écriture des primitives cryptographiques (HMAC, dérivations, vérifications)
- L'agencement du code, la structure des fichiers
- La formalisation des paragraphes du whitepaper et de cette dépêche
- La génération de tests unitaires
- La vérification de cohérence interne

Plan d'audit

• Auto-audit interne : en cours et continu (chaque modification est relue critiquement)
• Audit communautaire : ouvert dès maintenant, je réponds aux remarques techniques avec sérieux (cette dépêche en est l'illustration directe)
• Audit tiers certifié : envisagé à moyen terme via un cabinet agréé CESTI ANSSI (Synacktiv, Quarkslab, Wavestone, ou équivalent), sous réserve de financement

Statut du projet

SelfRecover en est à la version 0.1.1, taguée GPG et signée. C'est un état PoC fonctionnel + déployé en production sur un site réel (ARC PVE Hub), mais pas encore mature pour une adoption massive dans des contextes à fort enjeu. La roadmap V0.2 (MySelf-Live, finalisation du chatbot L3, audit tiers) précisera ce périmètre.

Engagement communauté LinuxFr et culture du libre

Mon compte LinuxFr est récent, mais mon ancrage dans la culture du libre ne l'est pas : utilisateur exclusif de distributions Linux depuis quinze ans (principalement Debian), j'ai aidé plusieurs proches à migrer des PC anciens vers Debian pour leur donner une seconde vie au lieu de la déchèterie. J'arrive sur LinuxFr depuis le monde agricole/permaculture et le jeu vidéo (ARC PVE Hub), pas du milieu dev historique.

Je suis salarié couvreur dans une PME et installé en agriculture à temps partiel — mon temps libre pour le développement et la participation communautaire est compté. Je m'engage à répondre aux retours techniques sur cette dépêche et à suivre les disputes sur l'état du projet. Pour le reste (commentaires réguliers, dépêches futures sur d'autres modules MySelf — en particulier SelfDataGuard quand il sera plus mature), ce sera au gré du temps disponible, sans promesse.

Toute critique technique constructive est bienvenue. Pour les critiques sur la légitimité du projet ou la nature humain/IA de la collaboration, j'invite à juger sur les choix concrets, le code public, et la qualité des réponses à vos questions.

Pour aller plus loin

SelfRecover est un module de l'écosystème MySelf, expérimentation citoyenne sur la souveraineté numérique sous licence AGPL-3.0-or-later.

Les retours techniques, audits communautaires, propositions d'intégration et questions de fond sont les bienvenus — en commentaire de cette dépêche ou en issue sur le repo GitHub.

Si une administration ou une organisation souhaite tester le protocole en environnement isolé, l'image Docker et le Dockerfile sont à disposition. Aucune démarche commerciale n'est associée à cette publication.

Merci aux modérateurs et contributeurs de LinuxFr — Pierre Jarillon, devnewton, Florent Zara, bobble bubble — dont les retours pendant la phase de rédaction ont substantiellement amélioré cette dépêche.

276e émission « Libre à vous ! » de l’April. Podcast et programme :

• sujet principal : Migrer de Windows vers un système libre sur le poste de travail avec Magali Garnero, présidente de l’April, membre de Framasoft ; Zoé Pélegry, porte-parole des mouvements Alternatiba et ANV-COP21 ; David Frissard de l’association Désobsolescence
• chronique de Gee sur « Pourquoi je fais de l’art libre »
• chronique de Benjamin Bellamy sur « La nouvelle série à la mode dont tout le monde parle sur les réseaux sociaux »
• Quoi de Libre ? Actualités et annonces concernant l’April et le monde du libre
  

Rendez‐vous en direct chaque mardi de 15 h 30 à 17 h sur 93,1 MHz en Île‐de‐France. L’émission est diffusée simultanément sur le site Web de la radio Cause Commune. Vous pouvez nous laisser un message sur le répondeur de la radio : pour réagir à l’un des sujets de l’émission, pour partager un témoignage, vos idées, vos suggestions, vos encouragements ou pour nous poser une question. Le numéro du répondeur : +33 9 72 51 55 46. La prochaine émission sera diffusée mardi 2 juin à 15h30 (puis en podcast). Nos invitées seront la LDH et Amnesty International France. Pour avoir le regard d'assocations dont l'objet premier n'est pas "le numérique", mais qui pour autant ont développé une analyse de ces enjeux à l'aune de leur propre combat. Et plus particulièrement, des associations de défense des droits humains.

Le collectif Linux Quimper vient d'envoyer un courriel à madame la présidente de la Communauté d'agglomération de Quimper Bretagne Occidentale (QBO) pour lui proposer d'engager une étude sur les dépendances numériques extra-européennes qui pourraient exister dans les services de QBO afin de trouver des solutions européennes de remplacement comme l'a demandé l'État français à ses ministères lors du séminaire interministériel du 8 avril 2026

Courriel adressé à madame la présidente de la communauté d'agglomération de Quimper Bretagne Occidentale (QBO) par Linux Quimper, collectif quimpérois de défense et de promotion des logiciels libres

Objet : Proposition d’étude sur les dépendances numériques extra-européennes

Madame la Présidente de QBO,

À la suite du séminaire interministériel (1) du mercredi 8 avril 2026, consacré notamment à la réduction des dépendances numériques extra-européennes, nous souhaitons attirer votre attention sur l’intérêt qu’une telle démarche pourrait également présenter à l’échelle de notre agglomération.

Notre collectif qui participe depuis 2006 à la promotion des logiciels libres et de Linux en particulier, sur Quimper et ses environs, suit avec attention les enjeux liés à la souveraineté numérique, à la maîtrise des coûts et à la pérennité des systèmes d’exploitation et des logiciels. Dans un contexte de fortes évolutions technologiques et de dépendances parfois peu visibles, il nous paraît utile qu’une collectivité puisse disposer d’une vision claire et partagée de ses propres dépendances numériques.

Dans cet esprit, nous nous permettons de suggérer que Quimper Bretagne Occidentale puisse engager une étude portant sur les dépendances numériques extra-européennes de ses services comme précisées dans le compte-rendu du séminaire interministériel : poste de travail, outils collaboratifs, antivirus, intelligence artificielle, bases de données, virtualisation et équipements réseau. Une telle démarche permettrait de dresser un état des lieux objectif, d’identifier les points de vulnérabilité éventuels et de dégager des pistes d’évolution adaptées aux besoins de la collectivité.

Cette réflexion pourrait, à terme, permettre de définir un objectif chiffré de réduction de ces dépendances, accompagné d’un calendrier progressif et réaliste. Elle offrirait également l’occasion de valoriser les solutions ouvertes, interopérables et maîtrisées, dans une logique de continuité de service et d’efficacité budgétaire.

Dans un esprit de transparence et de dialogue, nous vous serions reconnaissants de veiller à ce que l’évolution de cette réflexion fasse l’objet d’une information accessible aux citoyennes et citoyens.

Nous restons à votre disposition pour, si nécessaire, vous apporter des explications complémentaires.

Nous vous prions d’agréer, Madame la Présidente de QBO, l’expression de notre considération distinguée.

pour Linux Quimper, collectif Quimpérois de défense et de promotion des Logiciels Libres,
https://linuxquimper.org/
contact at linuxquimper.org

Orbitiny est un bureau Linux portable qui se lance comme une appli et qui ne joue pas dans la même catégorie.

Un bureau qui tourne au-dessus d’un autre, et ce n’est pas une blague

Dans l’écosystème des environnements de bureau Linux, on connaît les approches classiques, un gestionnaire de fenêtres, un compositeur, un panel, un menu, des services de session. Orbitiny arrive avec une idée qui semble contre nature, un bureau complet qui se lance comme une simple application, au-dessus de votre environnement actuel, sans remplacer quoi que ce soit, sans ouvrir une nouvelle session, sans toucher à votre configuration.

On clique, et un deuxième bureau apparaît, avec son propre panel, son propre menu, son propre gestionnaire de fichiers, comme une couche graphique autonome qui s’empile sur la première. C’est inhabituel, mais ça fonctionne.

Comment ça marche réellement, sous le capot

Orbitiny n’utilise pas KWin, Mutter ou Openbox. Il embarque son propre mini gestionnaire de fenêtres, écrit en Qt et C++, qui ne prend pas le contrôle de la session. Le système hôte continue de gérer les vraies fenêtres, les notifications, les entrées clavier et souris. Orbitiny ne gère que ce qu’il crée lui-même.

Techniquement, Orbitiny est une application Qt géante, un conteneur qui simule un bureau, un panel, un menu, un gestionnaire de fichiers et des services internes. Cela lui permet de tourner au-dessus de KDE, GNOME, Xfce ou n’importe quoi d’autre, sans conflit de compositeur, sans guerre de raccourcis clavier, sans écraser les paramètres de session.

C’est cette encapsulation qui rend possible le mode portable et l’exécution parallèle.

Qu’est-ce que ça apporte que les autres bureaux n’apportent pas

Orbitiny ne cherche pas à remplacer KDE ou GNOME. Il propose autre chose, un bureau autonome, portable, encapsulé, qui peut être lancé n’importe où, sans installation, sans dépendances lourdes, sans interaction profonde avec le système.

Ce que cela change concrètement :

1. un bureau que l’on transporte réellement sur une clé USB, avec ses réglages et ses plugins
2. un environnement isolé pour tester des applications sans polluer son bureau principal
3. un espace de travail temporaire pour les techniciens, les formateurs, les utilisateurs nomades
4. une solution pour les distributions live qui veulent proposer un bureau complet sans l’intégrer au système
5. une manière de contourner les limitations d’un bureau hôte sans le modifier

Orbitiny n’est pas un remplaçant, c’est un bureau parallèle, un bac-à-sable/sandbox graphique.

Des fonctionnalités déjà bien avancées

Le gestionnaire de fichiers maison, Qutiny, propose des fonctions rarement vues ailleurs, fusion de fichiers texte par glisser déposer, fusion d’images verticalement, recherche par nom et par contenu, double panneau, gestion des opérations avec emblèmes visuels. Ce sont des fonctions immédiatement utiles, sans installer d’outils externes.

Le bureau gère les gestes souris, jusqu’à douze par bouton, gauche ou droit. On peut dessiner un cercle pour ouvrir un terminal, une ligne pour lancer un navigateur, un zigzag pour fermer une fenêtre interne. C’est rapide, efficace, et entièrement configurable.

Chaque écran physique peut avoir son propre fond d’écran, ses propres raccourcis, ses propres applets. Chaque bureau virtuel peut également avoir sa propre configuration. Cela permet de créer des espaces de travail réellement indépendants.

Orbitiny détecte automatiquement WINE et DOSBox. On peut lancer un .exe Windows ou un programme DOS directement depuis le bureau ou le gestionnaire de fichiers, sans créer de fichier .desktop ou de configuration manuelle.

Le mode portable, la vraie différence

L’archive fait environ 185 Mo. On la décompresse sur une clé USB, on lance start-orbitiny, et tout fonctionne immédiatement. Tous les réglages sont stockés dans le dossier d’extraction. On peut donc transporter son bureau complet, ses préférences, ses plugins, et les retrouver sur n’importe quelle machine Linux.

Pour les techniciens, c’est un bureau de secours.
Pour les utilisateurs avancés, c’est un environnement jetable.
Pour les curieux, c’est un terrain d’expérimentation sans risque.
Pour les distributions live, c’est un bureau plug and play.

Informations concrètes

Orbitiny est sous licence GPLv3. Le code source et les binaires sont disponibles sur SourceForge. Le projet est développé par Sasko Usinov. Les premières versions datent de 2023, la version actuelle est la 0.3.0.

Orbitiny utilise Qt 5 et Qt 6 selon les modules, du C++ moderne, et une architecture modulaire composée de 48 composants isolés. Si un composant plante, le reste du bureau continue de fonctionner. C’est un choix technique rare dans les environnements de bureau.

Le développement est actif, et les prochaines étapes annoncées concernent l’amélioration du système de plugins, un thème sombre complet et la stabilisation du mode portable.

Premières impressions, un projet jeune mais déjà solide

Orbitiny tourne vite, tourne bien, tourne même très bien pour un bureau qui s’empile sur un autre. Le gestionnaire de fichiers accède directement au système hôte, le panneau de configuration est déjà complet, l’ensemble est fluide et cohérent.

On est loin du prototype bricolé un dimanche soir. Orbitiny ressemble à un projet avec une vision claire, et surtout avec une approche technique différente de ce que l’on voit habituellement.

Un concept étrange mais une idée qui mérite d’exister

Orbitiny ne remplacera pas KDE ou GNOME, mais ce n’est pas son but. Il propose une approche différente, un bureau autonome, portable, encapsulé, qui peut cohabiter avec n’importe quel environnement existant. Rien que pour ça, il mérite d’être essayé.

L’obligation croissante d’utiliser une application mobile bancaire pour valider des opérations sensibles devient un problème bien réel pour une partie des usagers : personnes sans smartphone, téléphones trop anciens, appareils non compatibles, ou encore systèmes alternatifs et dégooglisés.

Le sujet n’est pas seulement bancaire. Il touche aussi aux logiciels libres, à la liberté de choix technique, et plus largement à l’exclusion numérique. Lorsqu’une opération essentielle ne peut plus être validée que depuis une application propriétaire distribuée dans les écosystèmes de Google ou d’Apple, l’accès au service dépend alors d’un canal technique unique.

Le cas de BoursoBank a récemment relancé la discussion sur LinuxFr. Dans mon cas, lors d’opérations sécurisées, l’interface web m’a renvoyé vers l’application mobile comme unique moyen de validation. Certaines pages d’aide de la banque évoquent pourtant des solutions alternatives ou de secours, mais le service client m’a indiqué aujourd’hui qu’il n’existait en pratique pas d’autre moyen de valider ces opérations sans l’application mobile.

C’est précisément ce décalage entre la communication affichée, l’expérience réelle et la réponse du support qui pose problème. Il laisse l’usager dans une situation d’incertitude, y compris lorsqu’il cherche à quitter ce modèle pour une autre banque, sans garantie de ne pas retrouver la même contrainte quelques mois plus tard.

Cette évolution interroge : pourquoi ne pas proposer systématiquement des alternatives robustes, comme un second facteur indépendant de l’application mobile ?

Dans ce contexte, une pétition a été lancée pour demander que les banques opérant en France proposent au moins une méthode de validation forte utilisable sans application mobile imposée. Elle met en avant un principe simple : une banque peut être sécurisée sans réserver de fait ses services aux smartphones Google ou Apple.

Un nouvel outil de maintenance système attire l’attention : Kudu. Présenté comme une suite open source (sous licence MIT), le logiciel propose un ensemble de fonctions destinées à nettoyer, surveiller et optimiser un ordinateur, avec une compatibilité annoncée avec Windows, MacOS et Linux.

L’idée n’est pas totalement nouvelle, mais Kudu tente de se démarquer par une approche plus large que celle des utilitaires classiques. Le logiciel regroupe des outils de nettoyage, de gestion du démarrage, d’analyse de doublons, de surveillance des performances et plusieurs fonctions de maintenance avancée dans une interface unique.

Une alternative à des outils bien connus

Kudu est souvent présenté comme une alternative à CCleaner, un positionnement qui parle immédiatement aux utilisateurs habitués à ce type d’outils. Là où le projet cherche à marquer des points, c’est sur son statut open source, sa disponibilité multi-plateforme et l’intégration de fonctions qui vont au-delà du simple ménage système.

Le logiciel met aussi en avant des fonctions liées à la sécurité et à la confidentialité. On y trouve notamment des options de contrôle sur certains composants du système, des réglages de durcissement et des mécanismes de nettoyage plus poussés, avec une logique d’utilisation pensée pour rester simple.

Une approche tout-en-un

La documentation du projet insiste sur une organisation en plusieurs blocs : sécurité, maintenance et outils. Cette structure permet de retrouver rapidement les fonctions les plus courantes, tout en gardant à portée de main des actions plus techniques pour les utilisateurs qui veulent aller plus loin. L’un des points mis en avant est aussi la possibilité d’utiliser le logiciel sans compte obligatoire, avec une partie cloud présentée comme facultative.

Un projet à observer

Kudu arrive sur un terrain déjà bien occupé, mais il bénéficie d’un positionnement intéressant : open source, multiplateforme et orienté maintenance complète. Ce trio peut lui permettre de trouver sa place auprès des utilisateurs qui cherchent une alternative plus ouverte aux outils propriétaires habituels.

Reste maintenant à voir comment le projet évoluera dans la durée. Comme souvent pour ce type d’utilitaire, la différence se fera sur la qualité réelle des fonctions, la stabilité, la fréquence des mises à jour et la confiance que le logiciel inspirera au quotidien.

273e émission « Libre à vous ! » de l’April. Podcast et programme :

• sujet principal : Au café libre, débat autour de l’actualité du logiciel libre et des libertés informatiques avec Isabelle Carrère, Pierre Beyssac et Vincent Calame
• chronique « Que libérer d’autre que du logiciel » avec Antanak
• chronique de Vincent Calame sur « Le numérique est l’affaire de toutes d’Isabelle Collet »
• Quoi de Libre ? Actualités et annonces concernant l’April et le monde du Libre

Rendez‐vous en direct chaque mardi de 15 h 30 à 17 h sur 93,1 MHz en Île‐de‐France. L’émission est diffusée simultanément sur le site Web de la radio Cause Commune. Vous pouvez nous laisser un message sur le répondeur de la radio : pour réagir à l’un des sujets de l’émission, pour partager un témoignage, vos idées, vos suggestions, vos encouragements ou pour nous poser une question. Le numéro du répondeur : +33 9 72 51 55 46.

LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l’équipe de modération avant publication. C’est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

Ce que l’on sait moins, c’est que LinuxFr.org vous propose également de publier directement vos propres articles, sans validation a priori de lʼéquipe de modération. Ceux-ci s’appellent des journaux. Voici un florilège d’une dizaine de ces journaux parmi les mieux notés par les utilisateurs et les utilisatrices… qui notent. Lumière sur ceux du mois de mars passé.

• « Je hais les thèmes sombres, et je peux l'expliquer » par jben ;
• « Wine 11 : NTSYNC débarque en production et ça envoie du lourd » par pas_pey ;
• « Le Web moderne m'a tuer : plaidoyer pour une informatique sobre et déconnectée » par shingo ;
• « quihebergelesmails et nos journalistes » par skeespin ;
• « NextCloud et le format ODF : des gros nuages orageux » par Ysabeau 🧶 ;
• « Découverte de rust pour l'embarqué » par uneTanche ;
• « Migration sous SailfishOS » par Siltaär ;
• « De développeur à orchestrateur, comment l'IA a changé ma vie » par small_duck ;
• « Radio France supprime les liens RSS des ses émissions » par Micromy ;
• « ZRAM et ZSWAP et les mythes associés » par Mjules.

À partir du 20 mai 2026, Amazon mettra fin au support de huit modèles de liseuses Kindle et de certaines tablettes Kindle Fire commercialisées entre 2007 et 2012.

C'est l'occasion de réviser et partager entre nous toutes les solutions FOSS en 2026 pour lire, stocker et partager des ouvrages électroniques multimédias sans se faire piéger par les solutions propriétaires. À vos claviers pour les commentaires !

Ces appareils ne pourront plus accéder à la boutique Kindle pour acheter, emprunter ou télécharger de nouveaux livres ou contenus. Amazon justifie cette décision par l’évolution technologique et le fait que ces modèles ont été pris en charge pendant au moins 14 ans, voire 18 ans pour certains.

Modèles concernés : Les liseuses Kindle et tablettes Kindle Fire de 2012 ou antérieures. Après cette date, il sera impossible d’ajouter de nouveaux livres sur ces appareils, et en cas de réinitialisation ou de déconnexion du compte Amazon, ils ne pourront plus être réenregistrés. Amazon annonce qu'une réduction de 20 % sur l’achat d’un nouveau modèle sera proposée aux utilisateurs concernés, ainsi qu’un crédit pour l’achat de livres électroniques.

L’ancien sudo (écrit en C) a été récréé en Rust (sudo-rs), par une autre équipe, pour des raisons de sécurité mémoire notamment. Plusieurs distributions intègrent cette nouvelle implémentation dans leurs paquets et, en particulier, Ubuntu 25.10 l’utilise par défaut.

Pour mémoire (source) : Cette commande permet à un administrateur système d’accorder à certains utilisateurs (ou groupes d’utilisateurs) la possibilité de lancer une commande en tant qu’administrateur, ou en tant qu’autre utilisateur, tout en conservant une trace des commandes saisies et des arguments.

Le récent changement est que, par défaut, la saisie du mot de passe sudo affiche désormais des astérisques via sudo-rs, à l’inverse du comportement antérieur.

Le débat porte principalement sur l’utilisabilité en opposition à la tradition de sécurité Unix de ne rien afficher du tout.

Les arguments du choix portent notamment sur les aspects sécurité, utilisabilité, et tradition. Là où les pro-astérisques estiment la fuite de longueur tolérable, qu’elle confirme l’entrée fonctionnelle, et qu’il s’agit d’une amélioration moderne, les anti-astérisques considèrent que cela expose la longueur aux observateurs, que c’est inutile pour les experts, et que cela casse l’héritage Unix.

Du côté des arguments pour les astérisques, la rétroaction visuelle confirme que les frappes s’enregistrent, ce qui aide les nouveaux utilisateurs ou ceux avec des claviers défaillants et réduit les erreurs de saisie.

Les partisans notent que les risques d’épaulement (voir les caractères réels) sont faibles aujourd’hui avec l’accès distant courant, et que les indices de longueur sont mineurs comparés aux gains d’utilisabilité.

Du côté des arguments contre les astérisques, la conception Unix traditionnelle cache la longueur du mot de passe pour contrer les attaquants observant de loin, préservant une norme de sécurité de 46 ans même si imparfaite.

Les admins vétérans y voient un risque inutile dans les environnements partagés ou physiques, avec des solutions faciles comme pwfeedback pour revenir en arrière.

Vous savez peut-être comment configurer votre choix, notamment en écrivant dans /etc/sudoers soit Defaults pwfeedback (ce qui sera de toutes façons le comportement par défaut avec astérisques), soit Defaults !pwfeedback (avec le point d’exclamation en préfixe).

Si ce paramètre vous rappelle quelque chose, c’est normal. Les plus préoccupés d’entre nous par la sécurité se rappellent de l’incident de sécurité (CVE-2019-18634) lié à ce paramètre il y a quelques années : le paramètre pwfeedback introduit, en version 1.7.1 de sudo, avait hélas introduit un bug qui n’avait été corrigé que bien après.

Un peu de politique FOSS (un tout petit peu hors sujet ;-) )

Je profite de cette dépêche pour faire un appel, car ce débat et l’ancien bug lié à pwfeedback nous rappellent les risques qui pèsent sur les composants FOSS parfois vitaux et répandus comme XZ Utils, qui manquent de main d’œuvre et de moyens.
La récente attaque (CVE-2024-3094) contre OpenSSH en 2024 via sa dépendance logistique à XZ Utils, par un pirate qui avait exploité de l’ingénierie sociale sur Lasse Collin, le mainteneur fatigué et esseulé deXZ Utils, a failli compromettre un grand nombre d’ordinateurs utilisantOpenSSH`.
C’est un tiers, Andres Freund, employé de Microsoft, qui a contré le piratage en détectant puis identifiant l’erreur.

De même, vous avez su que Todd, C. Miller, l’unique mainteneur de sudo depuis 30 ans, appelait au secours et aux financements en début d’année 2026. Certes, ce point particulier a peut-être été réglé par la ré-écriture en Rust (sudo-rs) avec l’aide de Miller, mais le sujet est global pour le FOSS.

Mon souhait : donnons plus de notre personne ou de notre poche aux projets et personnes du FOSS.

Les informations que vous n’avez pas demandées (ou Too much information you didn't ask for)

Rust veut dire « rouille » en anglais, mais l’auteur de Rust faisait apparemment référence aux « rouilles » biologiques, qui sont les maladies dues à des champignons, les Pucciniales, qui donnent ainsi un aspect rouillé aux plantes parasitées, comme la rouille grillagée du poirier. Graydon Hoare a choisi ce terme, pour s’inspirer de ces champignons qui sont extrêmement sophistiqués dans leur capacité à survivre, comme on pourrait le vouloir pour nos programmes.