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.

Si vous êtes RSSI, DSI ou architecte dans une entité concernée par NIS2, vous avez probablement reçu en 2024 ou 2025 une lettre de votre autorité de supervision vous rappelant poliment — mais fermement — que la cartographie de votre système d'information est désormais une obligation réglementaire. Pas une bonne pratique. Pas une recommandation. Une obligation.

NIS2 (transposée en droit national dans les pays membres de l'UE) impose aux entités essentielles et importantes de mettre en place des mesures de gestion du risque cyber, parmi lesquelles figure explicitement la connaissance et la documentation de son système d'information. L'ANSSI en France, le CSIRT Luxembourg, le BSI en Allemagne — tous y font référence. Sans cartographie, pas de gestion du risque sérieuse, pas d'analyse d'impact, pas de plan de continuité fiable.

C'est précisément le problème que Mercator tente de résoudre depuis plusieurs années, et le projet continue d'évoluer.

Qu'est-ce que Mercator ?

Mercator est un outil Open Source de cartographie du système d'information, sous licence GPL, développé en Laravel/PHP. Il est aligné sur le guide de cartographie de l'ANSSI et couvre sept vues complémentaires du SI : écosystème (fournisseurs, sous-traitants), processus métiers, applications, administration (annuaires, comptes à privilèges), infrastructure logique (réseaux, VLANs, flux), infrastructure physique (serveurs, baies, salles), et registre des traitements RGPD.

Le principe central est la navigation par dépendances : depuis n'importe quel objet de la cartographie, on peut remonter ou descendre la chaîne — d'un processus métier jusqu'aux équipements physiques qui le supportent, en passant par les applications et les réseaux intermédiaires. C'est ce qui transforme un inventaire statique en un outil opérationnel pour l'analyse d'impact, la détection de SPOF, la planification de la continuité d'activité.

Mercator calcule également un score de maturité de la cartographie (complétude et qualité des données), par domaine : gouvernance, protection, défense, résilience — directement exploitable pour les audits NIS2, ISO 27001 ou HDS.

Pourquoi cartographier son SI ?

La question peut sembler rhétorique sur LinuxFr, mais elle revient régulièrement en pratique : on sait à peu près ce qu'on a, on a un CMDB approximatif, ça suffira non ?

Non. Voici ce qu'une cartographie bien tenue permet concrètement :

• Identifier les SPOF avant l'incident, pas pendant
• Évaluer l'impact d'une panne ou d'un changement sur les processus métiers, y compris les dépendances croisées
• Répondre aux auditeurs avec des données structurées et non avec un classeur Excel maintenu à la main par une personne qui a changé de poste il y a dix-huit mois
• Qualifier les actifs critiques pour orienter les investissements en sécurité
• Documenter les flux de données pour la conformité RGPD
• Planifier les migrations en connaissant l'ensemble des dépendances applicatives

En résumé : vous ne pouvez pas protéger ce que vous ne connaissez pas. C'est trivial à énoncer, c'est encore courant comme situation en pratique.

Ce que Mercator n'est pas

Point important, car le marché des outils de cartographie et de GRC est traversé depuis quelques années par une lame de fond de fonctionnalités "IA" — parfois utiles, souvent cosmétiques, presque toujours opaques sur ce qui se passe avec vos données.

Mercator est entièrement gratuit sous licence GPL. Il n'y a ni modules cachés, ni limitations fonctionnelles, ni intelligence artificielle. Le code est sur GitHub, lisible, auditable, forkable. L'assistance communautaire passe par GitHub Issues et Discussions. C'est tout.

Nouveautés récentes

Les évolutions récentes portent notamment sur :

• Module BPMN 2.0 pour connecter les processus métiers à l'infrastructure technique, et répondre à la question "si ce serveur tombe, quels processus métiers sont affectés ?" en quelques secondes.
• Analyse des dépendances analyser les dépendances d'un objet en amont ou en aval et générer automatiquement le graphe de ses dépendances.
• Moteur de requêtes, écrivez vos propres requêtes sur la cartographie et générez un graphe ou une liste.

Quelques chiffres

• 500+ étoiles GitHub, 72 forks, déployé dans plus de 30 pays
• Utilisé dans des hôpitaux, grandes écoles, centres de recherche, administrations
• Meilleur Projet Open Source OW2 2024
• Présenté à SSTIC 2023, Hack.lu 2024, Voxxed Days 2025, FIC Lille, FOSDEM, BSides Luxembourg

Après l’'annonce du projet d’infrastructure commune Euro-3C déjà présenté sur LinuxFR.org, une nouvelle annonce dans le domaine bureautique commun au niveau européen vient d’être faite en cette fin de mois à Berlin.

Une coalition d’entreprises européennes du logiciel libre lance Euro-Office, une suite bureautique souveraine et open source.

NdM : sur la thématique de suites bureautiques, beaucoup d’actualités ces derniers temps
ODF est l’avenir, OOXML le passé, NextCloud et le format ODF : des gros nuages orageux, Allemagne : le format ODF obligatoire dans l’administration, ONLYOFFICE suspend son partenariat avec Nextcloud suite a son fork pour le projet Euro-office, Euro-Office : IONOS, Nextcloud et Proton lancent le fork européen d’ONLYOFFICE qui veut en finir avec Microsoft Office, «Bercy réfléchit bien à trouver une alternative au Microsoft de Windows», etc.

Euro-Office est un outil d’édition bureautique en ligne conçu pour être intégré dans des plateformes existantes comme des solutions de partage de fichiers ou de gestion de projet. Contrairement aux suites complètes, il ne gère pas l’ensemble de l’environnement de travail mais se concentre sur l’ouverture, l’édition et la coédition de documents, avec une interopérabilité affichée avec les formats Microsoft.

Portée par Ionos, Nextcloud, XWiki, OpenProject, Eurostack, Soverin, Proton, Abilian et BTactic, l’initiative publie une préversion technique disponible immédiatement sur GitHub, avec une première version stable annoncée pour l’été.

Le projet s'appuie sur le code d’OnlyOffice, qui a une base Open Source, sous licence AGPL.

Elle intervient au moment précis où Onlyoffice met fin à son offre cloud, contraignant des milliers d’organisations à chercher une alternative.

Maintenant est un logiciel libre de monitoring d'infrastructure, conçu pour les administrateurs et développeurs qui font tourner des conteneurs Docker ou Kubernetes. Il se déploie sous la forme d'un unique conteneur qui auto-découvre et surveille l'ensemble d'une stack sans configuration préalable.

Le projet est publié sous licence AGPL-3.0. Le code source complet est disponible sur GitHub, y compris les fonctionnalités de l'édition Pro.

Le problème

Quand on auto-héberge une vingtaine (ou une quarantaine) de conteneurs sur un VPS, le monitoring finit souvent en une collection d'outils déconnectés : Uptime Kuma pour les checks HTTP, Healthchecks.io pour les tâches cron, un script bash pour les certificats SSL, Portainer ouvert dans un onglet pour voir si les conteneurs tournent, et un docker pull manuel de temps en temps pour vérifier les mises à jour. Cinq outils, zéro communication entre eux, aucune vue d'ensemble.

Maintenant regroupe tout ça dans un seul processus.

Sommaire

• • Ce que ça fait
  • Stack technique
  • Support Kubernetes
  • Modèle économique
    • Déploiement rapide
  • Comparaison avec les outils existants

Ce que ça fait

Le conteneur se branche sur le socket Docker en lecture seule (il ne crée, ne démarre et n'arrête jamais de conteneurs) et découvre automatiquement tout ce qui tourne. À partir de là :

• Suivi des conteneurs : états (running, stopped, restarting), health checks Docker natifs, détection de boucles de redémarrage, groupement automatique par projet Compose
• Métriques de ressources : CPU, mémoire, réseau et I/O disque par conteneur, avec une vue "top consumers" pour identifier rapidement les gourmands
• Monitoring d'endpoints : sondage actif HTTP/TCP avec suivi des temps de réponse, codes de statut, correspondance de mots-clés, seuils configurables
• Monitoring de cron jobs : URLs de heartbeat uniques — votre tâche planifiée envoie un ping, Maintenant vous alerte si le ping n'arrive pas
• Certificats SSL/TLS : détection automatique depuis les endpoints HTTPS, vérification de chaîne complète, alertes avant expiration (30j, 14j, 7j, 3j, 1j)
• Détection des mises à jour : scan des registres OCI (Docker Hub, GHCR, etc.), comparaison de digests et de tags semver, signalement des sauts de version critiques, commandes de mise à jour et rollback intégrées (Compose-aware)
• Analyse de sécurité réseau : détection automatique des configurations dangereuses — ports de bases de données exposés sur 0.0.0.0, conteneurs en mode privileged ou host-network, et pour Kubernetes, NodePort/LoadBalancer sans NetworkPolicy
• Page de statut publique : intégrée, personnalisable, reflète automatiquement l'état des monitors
• Serveur MCP : serveur Model Context Protocol intégré avec authentification OAuth2, pour requêter l'état de l'infrastructure depuis un assistant IA compatible

Stack technique

Le choix technique central est la simplicité de déploiement :

• Binaire unique Go compilé statiquement, avec le frontend Vue 3 + TypeScript + Tailwind embarqué via embed.FS
• SQLite en mode WAL pour le stockage — pas de base de données externe, pas de Redis, pas de file de messages
• SSE (Server-Sent Events) pour les mises à jour temps réel dans le navigateur — plus simple que les WebSockets, fonctionne à travers n'importe quel reverse proxy sans configuration particulière
• Moins de 20 Mo de RAM au repos
• Image multi-architecture : amd64 et arm64
• PWA : installable sur mobile

L'authentification n'est volontairement pas intégrée — Maintenant est conçu pour fonctionner derrière un reverse proxy avec middleware d'authentification (Authelia, Authentik, OAuth2 Proxy…), exactement comme Dozzle ou Prometheus. Les endpoints de heartbeat (/ping/{uuid}) et la page de statut publique sont prévus pour être accessibles sans authentification.

La configuration est possible soit par labels Docker sur les conteneurs, soit par l'interface web :

labels:
  maintenant.endpoint.http: "https://api:3000/health"
  maintenant.endpoint.interval: "15s"
  maintenant.alert.severity: "critical"
  maintenant.group: "production"

Support Kubernetes

Maintenant détecte automatiquement s'il tourne dans un cluster Kubernetes (via le compte de service) ou sur Docker (via le socket). Un ClusterRole read-only (maintenant-reader) suffit. Le monitoring se fait au niveau des workloads (Deployments, DaemonSets, StatefulSets) avec filtrage par namespace.

Modèle économique

Le projet suit un modèle open-core :

L'édition Community est complète et utilisable sans restriction pour un usage solo : monitoring conteneurs, endpoints, heartbeats, certificats, mises à jour, sécurité réseau, page de statut, support Kubernetes, alertes par webhooks et Discord, API REST + SSE.

L'édition Pro (9 €/mois ou 90 €/an) ajoute des canaux d'alerte supplémentaires (Slack, Microsoft Teams, Email/SMTP), la détection de CVE via OSV.dev, un tableau de bord de posture sécurité, la gestion d'incidents, les fenêtres de maintenance et les notifications aux abonnés de la page de statut.

L'intégralité du code source, y compris les fonctionnalités Pro, est visible sur GitHub sous AGPL-3.0. Le tier Pro est déverrouillé au runtime par une clé de licence — même binaire, même image Docker.

Déploiement rapide

services:
  maintenant:
    image: ghcr.io/kolapsis/maintenant:latest
    ports:
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /proc:/host/proc:ro
      - maintenant-data:/data
    environment:
      MAINTENANT_ADDR: "0.0.0.0:8080"
      MAINTENANT_DB: "/data/maintenant.db"
    restart: unless-stopped

volumes:
  maintenant-data:

Trente secondes plus tard, l'interface affiche tous vos conteneurs. Aucune configuration nécessaire.

Comparaison avec les outils existants

	Maintenant	Uptime Kuma	Portainer	Dozzle	Prometheus+Grafana
Auto-découverte conteneurs	Oui	Non	Oui	Oui	Via cAdvisor
Monitoring endpoints HTTP/TCP	Oui	Oui	Non	Non	Via Blackbox
Monitoring cron/heartbeat	Oui	Oui	Non	Non	Non
Certificats SSL	Oui	Oui	Non	Non	Via exporter
Métriques CPU/RAM/réseau	Oui	Non	Limité	Non	Oui
Détection mises à jour images	Oui	Non	Oui	Non	Non
Sécurité réseau	Oui	Non	Non	Non	Non
Page de statut	Oui	Oui	Non	Non	Non
Dépendances externes	Aucune	Node.js	Docker API	Docker API	3+ conteneurs

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.

• [ZDNET] Microsoft et Elon Musk, un partenariat inattendu dans l'IA?
• [Silicon] Redis à nouveau disponible sous licence open source
• [Le Monde Informatique] Un hackathon dédié aux outils collaboratifs open source pour l'Etat
• [actu.fr] Hérault: le Fabrikarium, des idées innovantes pour aider les enfants handicapés

[ZDNET] Microsoft et Elon Musk, un partenariat inattendu dans l'IA?

✍ Kim Mi-jeong, le vendredi 2 mai 2025.

Microsoft explore un partenariat avec xAI, la startup d’Elon Musk, pour héberger le modèle Grok, tout en diversifiant ses solutions IA au-delà d’OpenAI.

[Silicon] Redis à nouveau disponible sous licence open source

✍ Clément Bohic, le vendredi 2 mai 2025.

Redis 8 est distribué sous licence AGPL v3, en complément aux deux options non open source proposées depuis l’an dernier (SSPL v1 et RSAL v2).

[Le Monde Informatique] Un hackathon dédié aux outils collaboratifs open source pour l'Etat

✍ Véronique Arène, le mercredi 30 avril 2025.

Avec la DGNum, la Dinum organise les Hack Days - hackathon IA & digital workspace, une compétition qui a pour but de renforcer les applications bureautiques open source utilisées par les agents de l’Etat au niveau européen. Dans ce but, 300 développeurs, designers ou profils en IA et data sont attendus du 2 au 4 juin à l’ENS de Paris.

[actu.fr] Hérault: le Fabrikarium, des idées innovantes pour aider les enfants handicapés

Le mardi 29 avril 2025.

Hackathon solidaire, le Fabrikarium travaille sur des projets open source, que chacun peut s’approprier.

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.

• [Next] Le CNRS veut que ses logiciels libres génèrent des revenus
• [Le Monde Informatique] Priyanka Sharma (General Manager CNCF): «En France il y a une communauté open source vibrante»
• [Le Temps] Au Tribunal fédéral, l'informatique se passe des géants américains (€)
• [ZDNet France] Canonical fête ses 20 ans: comment Ubuntu a changé le monde de Linux
• [Le Monde.fr] Open data publique: «On voit les limites dès que les données pourraient remettre en cause le pouvoir établi» (€)
• [Next] Orange condamnée à 860 000 euros pour contrefaçon et violation de la licence libre GNU GPL
• [Place Gre'net] Échirolles va accueillir AlpOSS, rendez-vous dédié à l'Open Source

[Next] Le CNRS veut que ses logiciels libres génèrent des revenus

✍ Martin Clavey, le vendredi 8 mars 2024.

Le logiciel libre a une place importante dans l’univers de la recherche publique. De nombreux chercheurs contribuent à des projets du libre ou en créent. Le CNRS veut maintenant aider ses chercheurs à intégrer leurs logiciels dans une «logique de satisfaction d’objectifs économiques viables» avec un programme de financement appelé «OPEN».

[Le Monde Informatique] Priyanka Sharma (General Manager CNCF): «En France il y a une communauté open source vibrante»

✍ Dominique Filippone, le vendredi 8 mars 2024.

Un mois avant la première édition en France de la Kubecon Europe, la directrice exécutive de la Cloud Native Computing Foundation, qui gère Kubernetes, revient sur les projets et ambitions et apporte son regard sur l’évolution de la place de l’open source dans les entreprises.

Et aussi:

• [Le Monde.fr] Comment Opendatasoft est devenue l'acteur incontournable de l'ouverture des données publiques (€)

[Le Temps] Au Tribunal fédéral, l'informatique se passe des géants américains (€)

✍ Grégoire Barbey, le jeudi 7 mars 2024.

La plus haute autorité judiciaire du pays a fait le choix de la souveraineté numérique pour son infrastructure informatique. Une approche qui tranche avec d’autres institutions publiques et privées

[ZDNet France] Canonical fête ses 20 ans: comment Ubuntu a changé le monde de Linux

✍ Steven Vaughan-Nichols, le mercredi 6 mars 2024.

La société mère d’Ubuntu, qui équipe aujourd’hui des millions d’ordinateurs de bureau, de serveurs et d’instances cloud, continue de rechercher l’équilibre entre la fourniture de ‘Linux pour les humains’ et sa responsabilité croissante sur le marché mondial de la technologie.

[Le Monde.fr] Open data publique: «On voit les limites dès que les données pourraient remettre en cause le pouvoir établi» (€)

✍ Raphaëlle Aubert et Léa Sanchez, le mardi 5 mars 2024.

Dans un entretien au «Monde», le sociologue Samuel Goëta dresse un bilan de l’ouverture des données publiques en France.

Et aussi:

• [Le Monde.fr] Comment Opendatasoft est devenue l'acteur incontournable de l'ouverture des données publiques (€)

[Next] Orange condamnée à 860 000 euros pour contrefaçon et violation de la licence libre GNU GPL

Le mardi 5 mars 2024.

Après plus de douze ans de procédure, rapporte l’association April, Orange vient d’être condamnée pour contrefaçon. Elle a violé les termes de la licence GNU GPL v2, et donc le droit d’auteur d’Entr’ouvert, société coopérative autrice de la bibliothèque libre de gestion d’identité LASSO (Liberty Alliance Single Sign On).

Et aussi:

• [Silicon] Orange a violé la licence GPL: exposé des faits

[Place Gre'net] Échirolles va accueillir AlpOSS, rendez-vous dédié à l'Open Source

✍ Florent Mathieu, le lundi 4 mars 2024.

Échirolles accueille AlpOSS le 21 mars 2024, première édition d’un rendez-vous dédié aux solutions numériques Open Source.

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.

• [ZDNet France] Non-respect de la licence GPL: Orange condamné en appel
• [Le Monde.fr] La France enterre son indice de durabilité des smartphones
• [InformatiqueNews.fr] Migration PostgreSQL: le choix de la première base de données
• [Clubic.com] Voilà comment Firefox pourrait revenir dans la course en 2024
• [Numerama] Qui est Marina Ferrari, la nouvelle secrétaire d'État chargée du Numérique?
• [ZDNet France] Règlement pour une Europe interopérable: une avancée pour les logiciels libres, pour la FSFE

[ZDNet France] Non-respect de la licence GPL: Orange condamné en appel

✍ Thierry Noisette, le vendredi 16 février 2024.

La cour d’appel de Paris a condamné Orange à payer 650.000 euros à la société coopérative Entr’Ouvert pour ne pas avoir respecté la licence GNU GPL v2.

N. D. M. : cf lien Orange condamné à 650 000 € pour non-respect de la licence GPL

[Le Monde.fr] La France enterre son indice de durabilité des smartphones

Le jeudi 15 février 2024.

Tout en rappelant que son indice était plus ambitieux que celui prévu à l’heure actuelle par l’Union européenne, le ministère de l’écologie a fini par abandonner son projet, auquel la Commission européenne s’était dite défavorable.

Et aussi:

• [Silicon] Apple sacrifie les web apps progressives sur l'autel du DMA

[InformatiqueNews.fr] Migration PostgreSQL: le choix de la première base de données

✍ Florent Jardin, le mercredi 14 février 2024.

Bien des entreprises choisissent de migrer d’Oracle vers l’open source et PostgreSQL, mais le choix de la première base est essentiel.

[Clubic.com] Voilà comment Firefox pourrait revenir dans la course en 2024

✍ Maxence Glineur, le lundi 12 février 2024.

Le navigateur au panda roux n’est plus aussi populaire qu’auparavant. Ironiquement, sa meilleure arme contre Chrome pourrait être… l’un de ses anciens projets.

[Numerama] Qui est Marina Ferrari, la nouvelle secrétaire d'État chargée du Numérique?

✍ Bogdan Bodnar, le vendredi 9 février 2024.

Marina Ferrari, députée Modem de Savoie, vient d’être nommée secrétaire d’État chargée du numérique. Elle remplace un collègue du MoDem, Jean-Noël Barrot, désormais ministre en charge de l’Europe.

Et aussi:

• [ledauphine.com] Gouvernement. La Savoyarde Marina Ferrari nommée au Numérique: «Un domaine que je connais»
• [Le Monde.fr] Marina Ferrari, l'inconnue du numérique (€)

[ZDNet France] Règlement pour une Europe interopérable: une avancée pour les logiciels libres, pour la FSFE

✍ Thierry Noisette, le vendredi 9 février 2024.

Le texte que viennent de voter les eurodéputés est une «opportunité importante», estime la Free Software Foundation Europe.

Et aussi:

• [Silicon] Apple sacrifie les web apps progressives sur l'autel du DMA