ZAIA : l'authentification sans clé

Presque toutes les authentifications d'aujourd'hui embarquent un secret dans le client — une clé d'API, un jeton statique, une variable d'environnement dans le code JavaScript livré au navigateur. Ce secret peut être extrait, volé, rejoué. Et une fois l'identité prouvée, plus grand-chose ne revérifie que la requête suivante est légitime.

ZAIA — conçu et initié par TAH BOH ROMARIC, développeur autodidacte — prend le problème à l'envers : le client n'a rien à protéger parce qu'il ne détient rien, et le serveur revérifie chaque requête. Cet article décrit la vision et l'architecture ; les paramètres, seuils et séquences cryptographiques exactes ne sont volontairement pas publiés ici.

01 — Le problème

Le secret côté client, et l'angle mort d'après

Dans un schéma classique, le front-end ou l'application mobile porte une clé. On peut la retrouver dans un bundle JavaScript, la décompiler depuis un APK, l'intercepter. Le secret est une cible.

Second angle mort : l'authentification classique répond à « qui es-tu ? » une fois, puis fait confiance. Elle ne se demande pas si cette requête-ci, maintenant, depuis cet endroit, est cohérente. C'est précisément là que ZAIA se place.

02 — La thèse

Zero-Key et Zero Trust

ZAIA repose sur deux principes tenus ensemble.

• Zero-Key — le client « arrive tête vide » : aucune clé, aucun secret, aucune configuration cryptographique. Il n'y a donc rien à extraire de son code. Toute la cryptographie se déroule côté serveur.
• Zero Trust — aucune requête n'est acquise : l'origine déclarée, l'utilisateur, puis le contexte comportemental sont revérifiés à chaque appel.

Autrement dit : ZAIA ne mise pas sur la preuve d'identité fournie par le client, mais sur la validation continue du contexte par le serveur. C'est une couche universelle, indépendante de la pile technique, qui s'ajoute sans modifier le système existant.

03 — L'architecture

Six composants, un seul flux

Une requête traverse ZAIA comme une file de contrôle. Chaque poste a un rôle précis ; le client, lui, ne voit jamais les règles internes.

Ces composants, imaginés et articulés par TAH BOH ROMARIC, forment un flux unique quel que soit le langage ou le framework du projet protégé.

04 — Le Zero-Key Layer

Pourquoi « tête vide » change tout

Le principe est radical : le client reçoit des éléments publics, les renvoie tels quels, et n'a aucun rôle dans le calcul cryptographique. S'il est intercepté, l'attaquant récupère un identifiant de session inexploitable sans un accès au serveur ZAIA.

L'hygiène de session suit la même logique : l'identifiant de session est un « jeton de capacité » (le posséder vaut accès), donc transporté uniquement en HTTPS, jamais journalisé, jamais dans une URL ; il est de courte durée, renouvelé, lié à l'appareil, à usage unique, et révocable instantanément côté serveur.

05 — Le moteur de risque

IA hybride : le modèle local décide, le grand modèle explique

C'est la couche différenciante. Elle évalue chaque requête sur trois dimensions : l'application, l'utilisateur final et le comportement réseau.

• Niveau 1 — modèle local. Un modèle d'apprentissage automatique léger, embarqué, traite 100 % des requêtes en temps réel, sans dépendance externe. C'est lui, et lui seul, qui décide.
• Niveau 2 — grand modèle de langage, optionnel et asynchrone. Hors du chemin critique, il ne décide jamais. Il traduit les décisions en langage clair pour l'équipe, aide à améliorer le modèle local, et résume les alertes pour éviter la fatigue d'alerte.

Point clé : la validité cryptographique est nécessaire mais pas suffisante. Une session parfaitement signée peut être bloquée si le contexte comportemental sort des clous. Selon le niveau de risque, ZAIA autorise, demande une vérification renforcée, refuse, ou met en quarantaine — les bornes exactes restent à la main de l'équipe et ne sont pas publiées ici.

Pour comprendre ce que recouvre cette IA hybride, voir aussi notre dossier Les intelligences artificielles.

06 — S'intégrer

Un observateur-amplificateur, pas un remplaçant

ZAIA ne réécrit rien. Il s'insère devant l'authentification existante et l'observe pour la renforcer.

• Jetons (JWT), OAuth 2.0, liens magiques, passkeys / FIDO2, clés d'API héritées, sessions PHP ou WordPress, services d'authentification tiers : des adaptateurs prêts à l'emploi.
• Après validation, le Context Injector renvoie au serveur les permissions et métadonnées calculées — le client, lui, ne connaît jamais les règles.

L'installation vise la légèreté : quelques lignes, pas une migration.

07 — Un parti pris rare

Conçu pour les 8 milliards, pas les 500 millions

Le modèle de risque est entraîné pour les marchés émergents : adresses IP mobiles instables, connexions hors des heures occidentales, changements fréquents d'opérateur. Ces signaux ne sont pas traités comme des risques par défaut.

C'est un choix de conception assumé par TAH BOH ROMARIC — développeur autodidacte, familier de ces réalités réseau : l'inclusion numérique n'est pas un correctif ajouté après coup, elle est dans le modèle.

08 — Ouverture

Open source, et une trajectoire vers un standard

Le cœur de ZAIA est publié en open source sous licence permissive, pour une adoption la plus large possible, avec une offre hébergée optionnelle (tableau de bord, supervision) pour les organisations qui la veulent.

La feuille de route va d'un socle — filtrage par origine et couche Zero-Key — vers les adaptateurs et le moteur de risque local, puis le tableau de bord et l'IA hybride, avec pour cap d'en faire un standard universel. ZAIA reste distinct de ZCAS, un serveur applicatif WordPress séparé qui peut, lui, s'appuyer sur ZAIA.

09 — Questions fréquentes

Questions fréquentes

ZAIA remplace-t-il mon système d'authentification ?

Non. Il se pose au-dessus, comme un observateur qui amplifie. Vos jetons, OAuth, passkeys ou sessions restent en place ; ZAIA ajoute la vérification continue du contexte.

Que signifie « le client arrive tête vide » ?

Le navigateur ou l'application mobile ne détient aucun secret : ni clé d'API, ni jeton statique. Il n'y a donc rien à extraire d'un bundle JavaScript ou d'un fichier d'application. Toute la cryptographie se fait côté serveur.

En quoi est-ce vraiment du Zero Trust ?

Chaque requête est revérifiée : origine déclarée, utilisateur, puis contexte comportemental. Une session cryptographiquement valide peut être bloquée si le contexte devient anormal.

Qui est derrière ZAIA ?

ZAIA est conçu et initié par TAH BOH ROMARIC, développeur autodidacte. Le cœur est publié en open source sous licence permissive, avec une offre hébergée optionnelle.

10 — Ressources & liens

Où aller, concrètement