Article · mai 2026

01 — La frustration d'origine

Ezkey est né d'une frustration très personnelle.

Je viens d'un univers backend. En regardant le paysage moderne de l'authentification forte, je pouvais voir pourquoi les passkeys et les approches apparentées comptent. Elles s'appuient sur des fondations cryptographiques sérieuses et pointent clairement vers un avenir moins dépendant des mots de passe.

Ce qui me posait problème, ce n'était pas la cryptographie. C'était l'écosystème autour : la médiation navigateur, la cérémonie UI, les couches de protocoles et une logique d'intégration qui ne correspondait pas à la manière dont je raisonne naturellement sur les systèmes.

02 — Pourquoi une authentification plus forte comptait quand même

Je ne rejette pas l'authentification cryptographique forte. Je crois qu'elle fait partie des bonnes voies pour réduire la dépendance à long terme aux mots de passe.

Ce que je cherchais, ce n'était pas de reproduire chaque couche d'assurance formelle qu'on trouve ailleurs. Ce que je cherchais, c'était un autre chemin vers un niveau de protection significatif : plus fort que les mots de passe, plus fort que les générateurs TOTP classiques, et plus naturel du point de vue d'un développeur backend.

03 — Pourquoi j'ai cherché une alternative backend-first

De mon point de vue, il semblait y avoir de la place pour un système conçu du backend vers l'extérieur plutôt que du navigateur vers l'intérieur.

Cela voulait dire des APIs de confiance, un état durable côté serveur, une vérification cryptographique explicite et une application mobile qui participe comme acteur sécurisé dans la chaîne. Dans ce modèle, le backend n'est pas un simple récepteur passif d'interactions utilisateur. Il devient un vérificateur actif et la source de vérité durable sur l'ensemble des phases d'inscription et d'authentification.

Cette recherche d'une réponse backend-first, c'est la vraie origine d'Ezkey.

04 — Ce qu'Ezkey essaie de faire

Ezkey est ma tentative d'explorer si une authentification plus forte peut être construite autour d'un autre centre de gravité : contrôle backend, limites de confiance explicites, continuité cryptographique et APIs pratiques que les développeurs peuvent comprendre.

C'est pour cela que le protocole insiste sur des phases liées comme bind / verify et pending / respond. L'objectif n'est pas une simplicité cosmétique. L'objectif est la cohérence : un flux, une chaîne, une histoire de vérification et d'état tenue par le backend.

Une autre manière de décrire le projet est celle-ci : Ezkey cherche une voie du milieu. Le projet ne se satisfait ni des mots de passe ni des flux OTP de commodité, mais il n'essaie pas non plus de reproduire toute la cérémonie, tout le modèle d'assurance et toute la profondeur d'implémentation de l'écosystème WebAuthn.

Pour être précis, je ne prétends pas que cette complexité soit perçue de la même manière par tout le monde. Je décris une complexité qui m'a semblé réelle à moi. Ezkey est ma tentative d'explorer quelque chose qui, à mes yeux, est peut-être plus simple à comprendre et à opérer d'un point de vue backend.

05 — Ce qu'Ezkey ne prétend pas

Ezkey n'est pas une implémentation FIDO2, ni une couche WebAuthn, ni une simple variante de passkey. Le projet ne cherche pas à revendiquer une équivalence de standards par association.

Il faut le comprendre comme une voie parallèle, pas comme un raccourci ni comme une enveloppe de compatibilité. Son ambition est plus étroite et plus opinionated : proposer une alternative cohérente pour des équipes qui veulent une posture d'authentification plus forte avec contrôle direct du backend, limites de confiance claires et visibilité opérationnelle.

Le projet ne prétend pas non plus proposer un modèle de confiance complet et formel. Ezkey ne valide pas des chaînes complètes de certificats comme pourrait le faire une pile de sécurité mature. Le certificate pinning prévu est volontairement simplifié et spécifique au projet, pas une revendication de pinning complet au sens le plus strict. Les signaux côté appareil, comme la disponibilité de StrongBox, peuvent être rapportés et transportés cryptographiquement par le protocole, mais ils ne sont pas élevés au niveau d'une chaîne formelle d'attestation adossée à une autorité de certification.

06 — Où je trace la ligne sur la complexité

C'est une partie importante de l'ADN du projet : je trace une ligne dans le sable sur la complexité.

Certains mécanismes de sécurité apportent une valeur réelle, mais ils apportent aussi un niveau de cérémonie, d'infrastructure de vérification, de dépendance aux plateformes et de poids d'implémentation que je ne choisis pas, pour l'instant, d'absorber dans Ezkey. Cette frontière n'est pas présentée comme une vérité universelle. C'est ma frontière, façonnée par le jugement, les compromis, l'apprentissage et ma propre perception du moment où la complexité cesse de me sembler justifiée.

Dans la pratique, cela veut dire qu'Ezkey est opinionated non seulement sur l'architecture, mais aussi sur la quantité de complexité sécurité qu'il accepte de porter. Certains de ces choix pourront évoluer. D'autres resteront peut-être volontairement plus simples que ce qu'un système maximaliste vis-à-vis des standards ferait.

07 — Ambition sécurité, sans surpromesse

Ezkey reste un projet de sécurité. Il vise à être nettement meilleur que les mots de passe et nettement meilleur que les authenticators TOTP classiques pour certains cas d'usage orientés backend.

Mais il ne faut pas le lire comme une revendication de complétude formelle. C'est une voix médiane pragmatique et expérimentale : plus forte que le bas de gamme, et, à mes yeux, peut-être plus simple que l'extrémité haute à forte cérémonie, tout en pouvant être utile dans certains contextes d'entreprise sans pour autant répondre à toutes les exigences de sécurité ou d'assurance.

Cette nuance est importante, parce qu'aucune étude de marché n'est venue imposer exactement ce positionnement. Ezkey est un projet d'opinion construit à partir d'un besoin perçu, d'une conviction technique et de mon propre jugement sur l'endroit où les compromis deviennent pertinents.

08 — Pourquoi le projet est AI-first

Ezkey est aussi un projet AI-first.

Au début, j'ai exploré rapidement et imparfaitement. Plus tard, j'ai marqué une pause pour reprendre le codebase en main, le restructurer et relever le niveau de qualité avant de poursuivre. Depuis, une grande partie du travail s'est faite par la planification, la revue, la critique, la direction de refactoring et l'itération disciplinée avec l'IA.

Sur environ un an, cela a produit un volume inhabituel de plans de travail, d'ajustements d'architecture et d'améliorations structurées. Le point n'est pas que l'IA aurait remplacé le sérieux. Le point est qu'elle a rendu possible une boucle d'apprentissage et de construction beaucoup plus vaste.

09 — Pourquoi le projet est quand même sérieux

Ezkey est expérimental, mais il n'est pas improvisé.

J'ai investi du temps et de l'attention dans l'architecture, le protocole, les APIs, l'application mobile, les surfaces opérateur et la documentation. Le projet est devenu un espace pour tester avec sérieux des idées sur les limites de confiance, les cycles de vie, la sobriété UI, l'auto-hébergement, la clarté des APIs et l'usage discipliné de l'IA comme levier.

Il est autofinancé, autodirigé et volontairement contraint par les standards que je voulais appliquer à un projet greenfield mené avec soin.

Une partie de ce sérieux consiste aussi à être explicite sur les limites. J'ai une expérience réelle en backend et en systèmes, mais je ne me présente pas comme l'autorité ultime en ingénierie de sécurité. Ezkey reflète des choix informés, pas l'omniscience, et beaucoup de ses compromis sont explicitement teintés par mon propre jugement plutôt que par un consensus ou une validation marché.

10 — Quel genre de projet Ezkey est vraiment

Ezkey est un projet opinionated. Il vient d'une perspective de développeur bien précise. Il repose sur un manque perçu, pas sur une demande de marché massivement validée. Il est expérimental, mais pas désinvolte. Il est AI-first, mais pas indifférent à la qualité.

Dans ce sens, Ezkey est aussi un projet de synthèse. Il m'a offert un espace greenfield pour mettre en pratique des convictions accumulées sur les systèmes backend, la sécurité, les APIs, la clarté opérationnelle et la conception logicielle d'une manière qu'il aurait été difficile de tenter seul à cette profondeur dans une autre époque.

Retour aux articles et notes

Read in English