Apple et Google font la promotion de leur technologie de certification de matériel.

Au nom de la sécurité, les deux gros fournisseurs d’OS mobiles sont en train de verrouiller un marché où ils seraient les seuls acteurs mondiaux à décider qui a le droit d’utiliser tel ou tel matériel.

Le principe

Le but de ces technologies est d’interdire aux gens d’utiliser du matériel et du logiciel non approuvé par Google et Apple.

Faussement présenté comme une fonctionnalité de sécurité, les banques et les gouvernements les adoptent avec enthousiasme, car cela leur permet d’imposer l’usage de logiciels privateurs à leurs clients/citoyens, quitte à sacrifier la souveraineté.

Les technologies

API Play Integrity de Google

Cette API Android permet à une application de vérifier :

1. qu’elle n’a pas été modifiée par l’utilisateur ;
2. que l’utilisateur a bien payé pour l’utiliser ;
3. que l’exécution n’a pas lieu sur un émulateur ;
4. que le matériel sur lequel elle s’exécute est certifié par Google.

Quelques fournisseurs d’Android proposent des alternatives à ce service :

• Unified Attestation, créé par Volla ;
• Android hardware attestation, présenté par Graphene OS comme une alternative à Google’s Play Integrity API plus ouverte.

API App Attest d'Apple

https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service

Privacy Pass

Ce protocole a pour but d’authentifier un utilisateur anonyme. Cela peut sembler contradictoire, mais il s’agit de remplacer les solutions pour stopper les vils bots (captcha, anubis…).

Concrètement l’utilisateur doit obtenir un jeton avant d’accéder à un service.

Malheureusement de vils humains d’Apple et Cloudflare ont trouvé opportun d’implémenter ce système en rendant obligatoire l’usage d’un matériel certifié.

reCAPTCHA

Cette solution de Google impose aussi l’usage des services Google pour vérifier un mobile pour pouvoir accéder à certains services, notamment des sites web.

La certification de matériel du point de vue des utilisateurs

Pour le consommateur, la certification du matériel (appliqué aux ordiphones) revient à :

• limiter son choix de matériel neuf ;
• limiter son choix de matériel d’occasion ;
• accélérer l’obsolescence du matériel possédé.

Bref il faudra plus régulièrement « tout racheter ».

Pour le citoyen, c’est :

• l’usage obligatoire de logiciels privateurs ;
• une inscription forcé et donc l’acceptation des contrats de société “agressives” sur la vie privée et les données personnelles.

Pour les États et l’Union Européenne, c’est un nouvel abandon de souveraineté.

Certifier du matériel, c’est privateur. Certifier des gens c’est pire.

Si vous avez un diplôme d’ingénieur, un permis de chasse, un passe sanitaire ou un tatouage mafieux, vous savez que les organisations adorent certifier les personnes, par exemple pour être bien certaine de recruter un bon tireur pour une mission spéciale en pleine pandémie.

Toutefois si vous êtes un braconnier antivax de l’école 42, vous pouvez aussi télétravailler du côté obscur, par exemple comme développeur Android.

Enfin jusqu’ici, car Google demandera bientôt que tout développeur d’applications Android s’inscrive avec des obligations comme fournir une pièce d’identité officielle et lister tous ses identifiants d’applications actuels et futurs…

Une campagne est en cours pour défendre le droit des braconniers antivax de l’école 42gens normaux de continuer à développer librement sur Android : https://keepandroidopen.org/fr/

Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

• [Stratégies] La souveraineté numérique, à quel prix?
• [ICTjournal] Lancement d'Euro-Office, sous le feu des critiques de LibreOffice
• [Silicon.fr] Open source: ce que l'UE vise désormais
• [clubic.com] Les Big Tech contrôlent plus de 70% du cloud européen: l'UE vient d'allouer 2 milliards d'euros à l'open source

[Stratégies] La souveraineté numérique, à quel prix?

✍ Martin Carnot, le jeudi 11 juin 2026.

264 milliards d’euros. C’est ce que les entreprises européennes versent chaque année à des acteurs américains pour leurs logiciels et services cloud, selon l’étude Asterès publiée en avril 2025. Un montant comparable à la facture énergétique du continent, qui en dit long sur l’enjeu de la souveraineté numérique.

[ICTjournal] Lancement d'Euro-Office, sous le feu des critiques de LibreOffice

✍ Yannick Chavanne, le jeudi 11 juin 2026.

Développée à partir d’un fork d’OnlyOffice et soutenue par plusieurs organisations européennes, Euro-Office entend promouvoir une alternative locale aux suites bureautiques dominantes. The Document Foundation, éditeur de LibreOffice, dénonce toutefois un projet en contradiction avec certains principes de souveraineté numérique.

Et aussi:

• [Génération NT] Euro-Office: l'alternative européenne à Microsoft qui démarre avec un frein à main
• [ZDNET] Guerre de l'open source et polémiques, tout ce qu'il faut savoir sur le lancement d'Euro Office par NextCloud

[Silicon.fr] Open source: ce que l'UE vise désormais

✍ Clément Bohic, le mardi 9 juin 2026.

La nouvelle stratégie open source de l’UE ouvre des pistes en matière de gouvernance, de résilience et de commande publique.

[clubic.com] Les Big Tech contrôlent plus de 70% du cloud européen: l'UE vient d'allouer 2 milliards d'euros à l'open source

✍ Guillaume Belfiore, le lundi 8 juin 2026.

La Commission européenne a publié en fin de semaine dernière son paquet de souveraineté technologique. Ce dernier combine un Chips Act 2.0, une législation sur le cloud et l’IA, une feuille de route sur l’énergie et une stratégie open source inédite. Et il était temps. Aujourd’hui, l’UE achète plus de 80% de ses technologies numériques à des fournisseurs non européens.

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.

Portabase est un logiciel libre auto-hébergeable publié sous licence Apache 2.0, conçu pour automatiser la sauvegarde et la restauration de bases de données dans des scénarios de reprise après sinistre et de migration homogène (c’est-à-dire entre bases de données de même type).

Son architecture distribuée le rend particulièrement adapté à des environnements décentralisés, où les bases de données ne sont pas accessibles sur un même réseau. Il permet de piloter les sauvegardes depuis une interface unique, tout en laissant l’exécution effective aux agents déployés au plus près des bases de données.

Sommaire

• Un projet né d’un besoin opérationnel
• Une architecture distribuée : un serveur central et des agents
• Bases de données prises en charge
• Aperçu des fonctionnalités clés
  • Sauvegardes planifiées, déclenchement manuel et rétention
  • Restauration et migration homogène
  • Stockage local ou distant
  • Notifications lors d’évènements spécifiques
  • Organisation et contrôle d’accès
• Installation et déploiement
• Feuille de route et fonctionnalités à venir
• Conclusion

Un projet né d’un besoin opérationnel

Portabase a été créé il y a environ deux ans et demi pour répondre à un besoin interne : remplacer des scripts utilisés pour sauvegarder des bases PostgreSQL par une solution centralisée et facilement maintenable, évitant d’avoir à déployer un script avec une cron sur chaque serveur. N'ayant pas trouvé de logiciels libres répondant à ce besoin, nous avons investi pour créer cette solution et faire un premier pas dans la contribution au monde du libre, après avoir été de simples utilisateurs pendant de nombreuses années.

La construction d’une communauté autour du projet a réellement commencé depuis environ six mois, vers mi-décembre 2025, avec la publication d’une documentation plus détaillée, des articles sur Reddit et la création d’un serveur Discord.

Quelques statistiques à mi-mai 2026 :

• environ 850 étoiles, 90 issues ouvertes et 5 contributeurs sur GitHub
• plus de 10 000 pulls sur Docker Hub
• environ 2 000 visites mensuelles sur la documentation.

Une architecture distribuée : un serveur central et des agents

Le serveur central fournit l’interface graphique et joue le rôle de control-plane : il permet de déclarer les agents, configurer les sauvegardes, lancer des restaurations et connecter des systèmes tiers (stockages, notifications). Il est construit avec Next.js en TypeScript.

L’agent est déployé au plus près des bases de données : il exécute les tâches de sauvegarde et de restauration. Initialement écrit en Python, il a été réécrit en Rust afin d’obtenir un composant plus léger, plus prévisible et plus robuste à l’exécution. Les garanties apportées par le compilateur Rust contribuent à réduire drastiquement les bugs avant même la mise en production.

Le choix architectural est important : le serveur central ne contacte jamais directement les agents. Il n’est donc pas nécessaire d’ouvrir des ports entrants vers les environnements où résident les bases de données. Ce sont les agents qui contactent périodiquement le serveur central. Cette approche réduit la surface d’exposition réseau et limite les conséquences d’une compromission du serveur central.

Bases de données prises en charge

Le projet a démarré avec PostgreSQL, puis s’est étendu rapidement à d’autres moteurs, d’abord dans l’écosystème SQL.

Portabase prend aujourd’hui en charge neuf bases de données : PostgreSQL, MySQL, MariaDB, MongoDB, SQLite, Redis, Valkey, Firebird et Microsoft SQL Server. La prise en charge Microsoft SQL Server est plus récente, puisqu’elle date d’environ une semaine au moment de la rédaction, et doit donc encore être considérée comme en phase de test.

Aperçu des fonctionnalités clés

Sauvegardes planifiées, déclenchement manuel et rétention

Portabase permet de planifier des sauvegardes selon des intervalles fixes ou à l’aide d’une syntaxe cron. Il reste également possible de déclencher une sauvegarde manuellement ce qui est utile avant une opération de maintenance, une mise à jour applicative, une migration ou toute intervention susceptible de modifier fortement l’état des données.

La gestion de la rétention repose sur trois politiques configurables :

• count-based : conserve un nombre maximal de sauvegardes
• time-based : conserve les sauvegardes pendant une durée maximale
• GFS (Grandfather-Father-Son) : pour un plan plus élaboré, cf. ci-après.

Le GFS permet une granularité avec des sauvegardes journalières, hebdomadaires et mensuelles. L’objectif est de couvrir aussi bien les petites installations auto-hébergées que les besoins d’équipes qui doivent formaliser un plan de conservation.

Restauration et migration homogène

Sauvegarder est nécessaire, mais ce n’est pas suffisant ! L’objectif principal reste de pouvoir restaurer les données le moment venu, en écrasant les données existantes par celles contenues dans la sauvegarde sélectionnée.

Le cas de migration couvert est celui d’une migration homogène : même type de base de données, même version. Portabase permet ainsi de déplacer une base de données de manière contrôlée en passant par l’interface graphique, sans avoir à utiliser des commandes dans un terminal.

Attention : Portabase n’est pas un convertisseur de bases de données. Il ne sert pas à transformer une base PostgreSQL en base MySQL, ni une base MongoDB en base MariaDB.

Stockage local ou distant

Portabase peut stocker les sauvegardes localement, sur l’instance qui héberge le serveur central, ou à distance via des stockages compatibles S3, par exemple AWS S3 ou Garage. Google Drive est également pris en charge. Une même sauvegarde peut être envoyée vers plusieurs destinations simultanément, ce qui permet de créer de la redondance.

Notifications lors d’évènements spécifiques

Le système de notifications couvre les canaux couramment utilisés par les équipes techniques : email, Slack, Discord, Telegram, Ntfy, Gotify et webhooks. Les alertes peuvent être déclenchées sur les succès comme sur les échecs de sauvegarde, avec des politiques personnalisables au niveau des bases de données.

Organisation et contrôle d’accès

Portabase intègre un système d’organisation par espace de travail. Toutes les ressources (agents, canaux de notification, stockage, etc) peuvent être attribuées à des organisations spécifiques, permettant de segmenter les accès. Cette fonctionnalité est principalement utilisée par des équipes qui gèrent plusieurs clients.

Installation et déploiement

L’installation peut se faire avec le CLI, Docker ou sur Kubernetes via Helm Chart. Les images Docker sont disponibles pour les architectures linux/amd64 et linux/arm64.

Pour les personnes qui ne souhaitent pas utiliser la CLI, la documentation propose des configurations prêtes à l’emploi, aussi bien pour le serveur central que pour les agents, permettant de démarrer rapidement.

Feuille de route et fonctionnalités à venir

La feuille de route doit être mise à jour très prochainement. Les prochains développements porteront sur l’amélioration de l’expérience utilisateur, l’intégration dans des écosystèmes auto-hébergés comme Unraid, Proxmox VE Scripts, Dokploy et Coolify, ainsi que le renforcement des tests sur toutes les versions de bases de données prises en charge.

Conclusion

Portabase est né d’un besoin très concret : disposer d’un outil centralisé pour gérer les sauvegardes et restaurations de bases de données, sans maintenir une collection de scripts maison répartis sur chaque serveur.

Le projet couvre déjà plusieurs besoins courants : politiques de rétention, notifications, stockage local ou distant, authentification OIDC/OAuth2, ainsi que des modes de déploiement adaptés à Docker et Kubernetes.

Des retours d’usage, rapports de bugs et contributions sont donc les bienvenus pour continuer à durcir le projet et l’adapter aux cas réels rencontrés sur le terrain. N'hésitez pas à rejoindre le Discord !