Authentification unique (SSO) illimitée. Même facture. Même code.

Ce qui est absent de ce tableau est absent du produit aujourd'hui. S'il manque une capacité dont vous avez besoin, demandez-nous. La réponse pourrait être une date.

Quand la décision vient du propre fournisseur d'identité de votre client plutôt que de votre application, c'est le parcours géré par l'entreprise →

Une application iPhone pour approuver les actions des agents avec Face ID est en développement.

De votre côté, l'intégration est une URL de base. Le client reste le paquet better-auth standard que vous utilisez déjà : il pointe vers votre instance Signet au lieu de votre fournisseur actuel, et les appels que vous avez écrits continuent de fonctionner. Cela vaut pour une instance que nous hébergeons comme pour une instance sur vos propres serveurs sous licence d'entreprise : les requêtes de votre application restent les mêmes, même quand le moteur change d'adresse.

import { createAuthClient } from "better-auth/client";

// Votre client better-auth actuel : pointez baseURL
// vers votre instance Signet. Le protocole est le contrat.
export const authClient = createAuthClient({
  baseURL: "https://auth.example.com/api/auth",
});

// Les mêmes appels que vous écrivez déjà. Ils fonctionnent.
await authClient.signIn.email({ email, password });

• L'instance se vérifie avant de servir. Sa configuration est validée sans aucun réseau, puis validée de nouveau avec l'URL en service; les deux vérifications sont dans le moteur, sans outil externe à installer ni auquel faire confiance.
• Vous pouvez fournir le secret de signature et l'URL de la base de données séparément au processus : le fichier de configuration que vous versionnez ne contient alors aucun secret. Le schéma s'applique au premier démarrage.
• Vous pointez votre client better-auth vers /api/auth. C'est tout le changement de votre côté : une URL. Elle se lit de la même façon en hébergement ou sur vos propres serveurs.

Vous utilisez un cadriciel? Le guide de démarrage propose cinq parcours concrets : Next.js, React Router v7, Node/Express, Vue 3 et Svelte, ainsi que les bases pour React et le client standard.

Chaque utilisateur, session et secret réside dans une base de données qui vous appartient : PostgreSQL à partir de Team, SQLite chiffré sur Hobby. Une API /admin que vous contrôlez se trouve devant elle. Signet est la même version, que nous l'exécutions ou que vous le fassiez. Commencez sur une instance gérée. Le jour où il le faut, transférez-la sur votre propre matériel sous licence d'entreprise, sans changer une ligne de code client. Le protocole ne change pas.

Sur PostgreSQL, partir se fait avec pg_dump, pg_restore, puis un démarrage. Le SQLite chiffré de Hobby demande une étape de plus, décrite dans le guide d'export (en anglais). Sur votre propre matériel, vous le faites vous-même et partir ne demande l'aide de personne. Avec le service hébergé, nous exploitons la base : vous demandez et nous vous remettons le fichier d'export. Une licence d'entreprise met le moteur entre vos mains : si nous disparaissions demain, votre authentification continuerait de fonctionner et les requêtes ne changeraient jamais.

La propriété s'étend aussi à la configuration : chaque paramètre réside dans signet.toml, dans votre propre dépôt, pas dans une console hébergée. La configuration est le tableau de bord →

La série de tests de conformité différentielle est de 280 / 280 : chaque vérification du profil public de compatibilité s'exécute sur l'implémentation de référence et sur Signet, puis les résultats sont comparés. Le profil ne compte que les vérifications que l'implémentation de référence réussit elle-même; Signet n'est pas évalué sur celles auxquelles la référence échoue. L'écart de compatibilité (une vérification que la référence réussit et à laquelle Signet échoue) est de 0.

Séparément, l'acceptation de bout en bout est de 14 / 14 : le client non modifié de better-auth exécute de vrais parcours d'inscription, de session, d'organisation et de deux facteurs. Les deux exécutions ont été consignées le 2026-07-22. L'attestation de compatibilité est une référence datée à ces exécutions, pas une attestation cryptographique sous-entendue, et chaque instance sert sa propre copie pour que vous puissiez la vérifier vous-même.

L'inscription crée l'instance automatiquement. Le processus se termine par une attestation : une vérification /health en service, plus un test sommaire de bout en bout d'inscription, de connexion et de récupération de session sur l'URL en service. Démontré à partir de zéro le 2026-07-21 : health 200, test sommaire 3/3.