CorgiBOX voulait seulement ajouter un login. Elle a fini par construire un CIAM.

Pour sortir le produit rapidement, l'équipe choisit une stack moderne et un service d'authentification intégré. Email. Google. Mot de passe oublié. Session. Le besoin est couvert, et c'est probablement la bonne décision. Le problème commence plus tard, lorsque CorgiBOX continue de considérer cette couche comme « le login » alors que son activité, elle, a changé.

La première version repose implicitement sur un modèle très simple : une adresse email correspond à une personne, une personne correspond à un compte, un compte correspond à un espace, et cet utilisateur possède quelques permissions.

Puis CorgiBOX commence à grandir. Une association veut disposer d'un espace partagé. Une clinique vétérinaire veut plusieurs utilisateurs. Une marque veut séparer ses équipes France et Belgique. Un consultant travaille pour plusieurs organisations. Un administrateur doit inviter des collaborateurs sans accéder à leurs données.

La simple table utilisateur ne suffit plus. CorgiBOX ajoute alors des organisations, des memberships, des invitations, des rôles, un tenant actif et quelques règles supplémentaires dans la base. Chaque ajout est logique. Mais l'identité vient déjà de changer de nature.

Alice n'est plus simplement « user_123 ». Alice est une personne, disposant éventuellement de plusieurs moyens de connexion, membre de plusieurs organisations, avec des rôles différents selon le contexte. Désactiver Alice chez un client ne doit donc pas nécessairement supprimer Alice de CorgiBOX. Une organisation n'est pas simplement une colonne organization_id.

Le premier grand compte arrive avec une demande parfaitement normale : « Nous utilisons Microsoft Entra. Nous voulons le SSO. Et lorsqu'un collaborateur quitte l'entreprise, son accès doit être supprimé automatiquement. »

CorgiBOX ajoute une connexion SAML ou OIDC. Puis du provisioning SCIM. Et les questions commencent.

Que faire d'un utilisateur qui existait déjà avec Google avant l'activation du SSO ? Faut-il rapprocher les deux comptes, sur la base de l'adresse email ? Qui crée réellement le membership : l'invitation, le premier login ou SCIM ? Que se passe-t-il lorsqu'un groupe change dans l'annuaire du client ? Comment désactiver uniquement l'appartenance à ce client sans supprimer le compte global ? Que doit pouvoir administrer le responsable IT du client lui-même ?

Puis un deuxième grand compte arrive avec un autre IdP, d'autres groupes et une autre façon de nommer ses attributs. Puis un troisième.

Le SSO n'est plus une fonctionnalité. C'est devenu un processus d'onboarding et d'exploitation client.

Le succès de CorgiBOX entraîne de nouveaux usages, et certaines opérations deviennent sensibles. Changer les informations d'un compte professionnel. Exporter beaucoup de données. Accorder une délégation importante. Modifier les informations de facturation. Récupérer un compte administrateur.

Une authentification correcte ne suffit plus à répondre à la question : « Est-ce raisonnable d'autoriser cette opération maintenant ? »

CorgiBOX ajoute alors progressivement un contrôle de terminal, un score de risque, du MFA, un step-up, un fournisseur de vérification d'identité, une file de revue manuelle et des mécanismes spécifiques de récupération de compte.

L'utilisateur possède maintenant un identifiant chez le fournisseur d'authentification, un identifiant CorgiBOX, un dossier chez le fournisseur de vérification et plusieurs événements dans le moteur de risque. Aucun de ces produits n'est nécessairement le problème. La difficulté est de savoir comment leurs décisions s'enchaînent et à quelle personne, organisation et action elles se rapportent.

Le sujet n'est plus seulement l'authentification. C'est l'orchestration de l'identité.

Jusqu'ici, l'IA de CorgiBOX aidait essentiellement l'utilisateur. Maintenant, elle agit. Un agent classe automatiquement certains contenus. Un autre récupère des informations dans un service externe. Un assistant peut préparer une action que l'utilisateur valide ensuite. Certains traitements s'exécutent en arrière-plan.

Le vieux modèle user_id + session atteint alors une nouvelle limite. Il faut être capable de répondre séparément à quatre questions : qui a demandé l'action ? Qui l'exécute réellement ? Pour quelle organisation ? Avec quelle délégation et pendant combien de temps ?

L'agent doit avoir sa propre identité technique. Mais il ne doit pas devenir un super-utilisateur. Son action doit rester rattachable à un humain, un tenant, une politique, un scope et une durée.

L'audit doit pouvoir expliquer qu'Alice a demandé une action, que l'agent CorgiBOX l'a exécutée, pour l'organisation Acme, dans un périmètre donné, avec une autorisation encore valide au moment de l'exécution. Pour une entreprise AI-backed, cette question peut arriver beaucoup plus tôt qu'on ne l'imagine.

À chaque étape, la décision de développer en interne pouvait sembler moins chère. Une table de plus. Un webhook. Un script. Un composant d'administration. Un nouveau contrôle dans l'API. Un fournisseur spécialisé relié en quelques jours. Pris séparément, chacun de ces développements peut sembler raisonnable.

Mais leur coût réel finit par apparaître ailleurs : dans les webhooks qu'il faut rejouer, dans les scripts de réparation de comptes, dans les incidents de session, dans les comptes dupliqués, dans les mappings SSO spécifiques à chaque client, dans les tickets de support, dans les tests de non-régression, dans la sécurité, dans les audits, et surtout dans le temps d'ingénieurs produit qui ne développent plus le produit.

Le build versus buy n'oppose donc pas réellement une licence payante à une solution gratuite. Il oppose souvent une plateforme CIAM industrialisée par un éditeur à une plateforme d'identité propriétaire que l'entreprise n'avait jamais prévu de construire, de maintenir et d'exploiter.

Passer à une plateforme CIAM comme celles de Ping Identity ou d'Auth0/Okta ne signifie pas que le projet devient automatique. Il faut toujours concevoir. Il faut décider où vit la vérité. Définir les personnes, comptes, organisations, memberships, rôles et délégations. Choisir les parcours. Configurer les fédérations. Définir les règles de rapprochement. Préparer la migration. Intégrer les applications et API. Tester. Puis exploiter.

La différence est importante : l'entreprise cesse progressivement de construire elle-même les mécanismes génériques d'une plateforme d'identité et s'appuie sur un produit éditeur conçu pour les industrialiser et les faire évoluer.

Les fournisseurs spécialisés de fraude, de vérification ou d'autorisation ne disparaissent pas nécessairement. Le CIAM peut devenir le point cohérent à partir duquel les parcours, les politiques et les niveaux d'assurance sont orchestrés.

Chez Ariovis, le premier chantier ne serait pas de remplacer immédiatement tout ce que CorgiBOX possède. Il serait de comprendre ce que CorgiBOX a réellement construit : cartographier les identités, organisations, sessions, rôles, événements, délégations, fournisseurs, agents et parcours.

Définir ensuite un modèle canonique. Par exemple : Person, Identity, Account, Organization, Membership, Role, Delegation, Agent, Verification Case, Risk Decision. Puis attribuer une source de vérité à chaque objet ou décision.

Seulement ensuite vient l'architecture cible. Certaines briques existantes peuvent rester. La base métier peut rester la base métier. Un moteur de fraude spécialisé peut continuer de jouer son rôle. Microsoft Entra ou Keycloak peuvent rester pertinents lorsqu'ils répondent déjà à un besoin précis. Le CIAM devient le socle cohérent qui évite que chaque nouvelle application et chaque nouveau parcours réimplémentent les mêmes problèmes.

Sur l'Access Management et le CIAM, Ping Identity est le partenaire technologique de référence d'Ariovis. Notre rôle ne consiste toutefois pas à déposer une licence Ping chez le client. Ariovis cadre, conçoit, configure, intègre, migre, teste et accompagne la mise en production de la plateforme dans son environnement réel.

L'objectif est d'obtenir rapidement un premier périmètre utile et exploitable, puis d'étendre progressivement le dispositif plutôt que de transformer le sujet en programme de remplacement massif. Sur un périmètre suffisamment défini, avec des prérequis et des critères d'acceptation explicites, Ariovis peut s'engager sur le résultat livré plutôt que sur une simple consommation de jours.

L'éditeur maintient et fait évoluer son SaaS. Ariovis fait en sorte que ce SaaS corresponde au produit, aux métiers, aux risques et aux contraintes d'exploitation du client. C'est là que l'économie change réellement : les développeurs de CorgiBOX peuvent recommencer à développer CorgiBOX.

Continuer à développer l'identité morceau par morceau peut coûter beaucoup plus cher que la licence que l'entreprise pensait éviter.

On ne passe pas au CIAM parce qu'on a beaucoup d'utilisateurs. On y passe lorsque l'identité est devenue un produit transverse que l'entreprise doit administrer, auditer, faire évoluer et contractualiser.