• repere.app devient la source de vérité pour les données de base du compte,
• chaque service garde ses données métier,
• et les services ne demandent à repere.app que ce dont ils ont besoin : identité, proches, droits d’accès, souscriptions.

Le vrai bénéfice, ce n’est pas seulement le SSO. C’est surtout :

• éviter la ressaisie,
• garder une identité cohérente entre services,
• simplifier l’ouverture à d’autres apps,
• et séparer proprement les responsabilités.

La limite à garder en tête : il ne faut pas que repere.app devienne un “monolithe universel”. Il doit rester une brique simple : authentification, identité, liens familiaux, abonnements, accès. Pas de logique métier.

Brief de départ — Projet repere.app

1. Vision

repere.app est une plateforme centrale d’identité, d’accès et de souscriptions.

Son rôle est de permettre à un utilisateur de :

• créer un compte unique,
• gérer ses informations de base,
• gérer les membres de sa famille ou ses proches,
• accéder à plusieurs services sans ressaisir ses informations,
• gérer ses souscriptions gratuites, payantes, récurrentes ou ponctuelles.

repere.app n’a pas vocation à porter les données métier de chaque service.
Chaque service reste responsable de sa logique métier et de ses propres données.

2. Positionnement

repere.app est une brique commune qui fournit :

• l’authentification,
• les données de base des utilisateurs,
• les liens familiaux,
• la gestion des accès,
• la gestion des souscriptions.

Les services connectés peuvent être :

• des sous-domaines internes, comme tirage.repere.app ou font.repere.app,
• des plateformes liées, comme Kalenia,
• à terme, des services tiers souhaitant déléguer l’identité et les souscriptions.

L’objectif est d’offrir une expérience simple pour l’utilisateur et de réduire la complexité technique côté services.

3. Principe d’architecture

repere.app

Plateforme centrale qui gère :

• compte utilisateur,
• profil de base,
• adresses et coordonnées,
• proches / famille,
• authentification,
• souscriptions,
• droits d’accès par service.

Services connectés

Chaque service gère :

• ses propres utilisateurs techniques si nécessaire,
• ses données métier,
• ses écrans,
• ses règles métier,
• ses traitements internes.

Les services ne stockent pas comme source principale les données personnelles de base si elles peuvent être récupérées via l’API repere.app.

4. Rôle de l’API

Le fonctionnement cible est orienté API.

Les services doivent pouvoir interroger repere.app pour obtenir :

• identité de l’utilisateur,
• informations de contact,
• informations d’adresse,
• composition familiale,
• liens entre membres,
• statut d’abonnement,
• droits d’accès à un service,
• métadonnées utiles au service.

Exemples d’usage :

• Kalenia récupère les données du praticien connecté et vérifie son abonnement,
• un service famille récupère les proches gérés par le compte principal,
• un futur service externe vérifie si un utilisateur a accès à une offre active.

5. Cas d’usage prioritaire

Le premier cas d’usage prioritaire est Kalenia.

Dans ce cadre :

• repere.app gère l’authentification du praticien,
• repere.app vérifie ses souscriptions et options,
• Kalenia garde la logique métier propre à son activité,
• les données de santé ou données métier sensibles ne remontent jamais dans repere.app.

Cela permet de valider le modèle avec un besoin réel avant d’ouvrir à d’autres services.

6. Valeur pour l’utilisateur

Pour l’utilisateur final, la promesse est simple :

• un seul compte,
• des informations de base saisies une seule fois,
• une gestion centralisée de soi et de ses proches,
• un accès plus fluide à plusieurs services,
• une meilleure lisibilité de ses souscriptions et de ses accès.

7. Valeur pour les services

Pour les services connectés, la plateforme apporte :

• moins de développement sur le login,
• moins de formulaires à maintenir,
• moins de duplication des données de base,
• une gestion centralisée des accès,
• une meilleure cohérence entre plusieurs produits.

À moyen terme, cela peut devenir une offre utile pour des indépendants, formateurs ou créateurs de services ayant besoin de :

• comptes utilisateurs,
• souscriptions,
• accès récurrents ou ponctuels,
• gestion simple de leurs clients.

8. Limites volontaires

repere.app ne doit pas devenir :

• un outil métier,
• un CRM complet,
• un ERP,
• une plateforme de paiement multi-provider complexe dès le départ.

Le périmètre doit rester volontairement limité à :

• identité,
• authentification,
• famille,
• accès,
• souscriptions.

Cette discipline est essentielle pour garder un produit simple, maintenable et réellement utile.

9. Ambition moyen terme

À moyen terme, repere.app peut devenir une brique commercialisable pour d’autres services, en particulier pour des structures simples qui ont besoin de :

• gérer des clients,
• proposer des abonnements,
• vendre des accès ponctuels,
• déléguer l’authentification et une partie de la gestion utilisateur.

Mais cette ouverture ne doit venir qu’après validation du modèle sur les usages internes, en particulier avec Kalenia.

10. Ligne directrice

Construire d’abord une brique simple, robuste et utile pour les usages internes.
Valider le modèle sur Kalenia.
Puis seulement ouvrir progressivement à d’autres services.