identification pour WebApp et agents

1. Pourquoi l’identification est quasi obligatoire dans votre cas

Avec votre stack actuelle :

• WebApp générée via Agent-3 (formulaire)
• Back-office Odoo qui génère des questions
• Bot / viewer JS qui affiche ces questions dynamiquement

Sans identité fiable et persistante, vous ne pouvez pas, ou très mal :

• Rattacher chaque session à un infirmier / aidant précis
  → mapping stable côté Odoo (res.users / res.partner avec un google_sub_id ou external_id).
• Reprendre une session là où elle s’est arrêtée (wizard multi-écran, questionnaires progressifs).
• Faire du RAG / analytics par personne : historiques de réponses, niveaux de compétence, évolutions.
• Gérer les droits : certains profils peuvent voir/modifier plus ou moins de questions.
• Éviter les collisions de données quand plusieurs personnes utilisent la même machine ou le même lien.

Donc oui :

👉 mettre en place un bloc “Auth + User ID” au centre de l’architecture est la meilleure approche, plutôt que d’essayer de recoller les morceaux avec des cookies anonymes.

3. Briques “classiques” côté WebApp (hors MCP, mais importantes)

Avant même MCP, vous pouvez vous appuyer sur :

• Google Identity Platform / OAuth directe (le plus simple si vos devs sont à l’aise avec OAuth).
• Firebase Auth (si vous voulez un backend géré par Google, facile à brancher sur React/Next).
• Supabase Auth, Clerk, Auth0… tous supportent Google comme provider OIDC standard.

L’important :

👉 choisir un provider qui expose un vrai OIDC avec Google (donc un sub stable) pour pouvoir ensuite plugger MCP par-dessus.

5. Recommandation concrète pour votre contexte

En restant pragmatique avec vos ressources actuelles :

1. Court terme (PoC / V1)
   • Implémenter un “Sign in with Google” classique côté WebApp (Google Identity, Firebase Auth ou Supabase Auth).
   • Stocker sub Google → x_google_sub dans Odoo, et rattacher toutes les réponses du wizard à cet ID.
2. Moyen terme (MCP ready)
   • Mettre devant votre futur MCP server un mcp-auth-proxy configuré avec Google comme IdP. GitHub
   • Faire en sorte que l’agent qui parle à votre MCP server reçoive un token contenant l’ID Google → vous pouvez alors aligner le contexte agent / Odoo / WebApp.
3. Long terme (architecture unifiée d’identité)
   • Si vous vous standardisez sur un IdP (Auth0, Keycloak, etc.) :
     • Déployer @mcpauth/auth ou un serveur MCP custom,
     • Centraliser toutes les autorités d’identité (Google, GitHub, etc.)
     • Et exposer ça via MCP aux différents agents (Replit Agent-3, Claude, ChatGPT, etc.).

1. Un schéma d’architecture logique (en texte, bloc par bloc).
2. Les flux principaux (connexion, questionnaire, bot/agents).
3. Un tableau des champs Odoo à créer (prêts pour Odoo Studio / dev).

1. Architecture globale – version simple et robuste

Imaginez les blocs suivants :

1. [Utilisateur infirmier / aidant]
   ↓
2. [WebApp Next.js (Agent-3)]
   • UI du webformulaire
   • UI du viewer JS du bot / questions dynamiques
   • Auth “Sign in with Google”
     ↓
3. [Service Auth – Google OAuth / OIDC]
   • Vérifie l’identité
   • Retourne un ID Google stable (sub) + email + nom
     ↓
4. [Backend WebApp / API]
   • Vérifie le token Google
   • Enrichit la requête avec : google_sub, email, etc.
   • Appelle Odoo (REST / RPC / webhook n8n)
   • Appelle éventuellement le MCP server / Agent IA via n8n
     ↓
5. [Odoo Online]
   • Modèle res.partner ou modèle custom x_nurse_profile
   • Stocke : identité, réponses, profils de compétences
   • Génère / stocke les questions (back-office)
     ↓
6. [n8n (optionnel mais conseillé)]
   • Orchestration entre WebApp ⇄ Odoo ⇄ IA
   • Logique métier un peu avancée
     ↓
7. [MCP Server + Agents IA]
   • Accès RAG, explication des profils, génération de texte, etc.
   • Informé de l’ID utilisateur (google_sub) pour personnaliser le contexte

2. Flux 1 – Connexion / identification avec Google

Étapes

1. L’utilisateur ouvre la WebApp (URL publique via Vercel).
2. Il clique sur “Se connecter avec Google”.
3. Google gère l’auth → renvoie un ID Token OIDC à la WebApp.
4. La WebApp envoie ce token au backend API (/api/auth/callback par ex.).
5. Le backend :
   • Vérifie la signature du token (librairie OIDC).
   • Extrait les champs essentiels :
     • sub → ID Google stable
     • email
     • name / given_name / family_name
6. Le backend appelle Odoo (ou un webhook n8n → Odoo) avec ces infos :
   • Si x_google_sub existe déjà → on récupère le partenaire / profil.
   • Sinon → on crée un res.partner + éventuellement un x_nurse_profile.

Résultat :

📌 Vous avez une clé d’identité unique (Google sub) partagée par : WebApp, Backend, Odoo, n8n, MCP.

3. Flux 2 – Questionnaire / webformulaire

1. L’utilisateur est connecté → la WebApp possède son google_sub.
2. Il remplit le wizard de typage infirmier (écrans Agent-3).
3. À la fin ou à chaque étape (au choix), la WebApp appelle :
   • POST /api/nurse/answers avec un payload du type :

{
  "google_sub": "11223344556677889900",
  "email": "prenom.nom@domaine.com",
  "wizard_step": "A1",
  "answers": {
    "injections_sc": true,
    "injections_im": true,
    "injections_iv": false,
    "pansements_simples": true
  },
  "client_timestamp": "2025-11-18T10:35:00Z"
}

1. Le backend récupère ça et :
   • Mappe google_sub → res.partner / x_nurse_profile dans Odoo.
   • Sauvegarde les réponses :
     • soit dans des champs structurés du profil
     • soit dans un modèle ligne type x_nurse_answer (plus flexible).

4. Flux 3 – Bot / viewer JS + MCP / RAG

Quand vous affichez le “bot” dans un viewer JS dans la WebApp :

1. Le viewer JS initialise une session en envoyant au backend :

{
  "google_sub": "11223344556677889900",
  "session_id": "xyz-123",
  "mode": "explication_profil",
  "language": "fr"
}

1. Le backend / n8n :
   • Charge les données du profil dans Odoo (compétences, typologie, etc.).
   • Envoie une requête au MCP Server / Agent IA avec :
     • Le contenu (profil, réponses, etc.)
     • L’ID utilisateur (google_sub) pour tracer / personnaliser.
2. L’agent IA renvoie :
   • Une explication en langage naturel, un plan de formation, un résumé, etc.
3. Le backend renvoie cette réponse au viewer JS, qui l’affiche comme un chat.

5. Champs Odoo à créer – version prête pour Odoo Studio

5.1. Sur res.partner (ou res.users si vous préférez)

À minima, je recommande :

👉 x_google_sub doit être indexé et idéalement unique.

5.2. Modèle de profil infirmier – x_nurse_profile

Vous pouvez créer un modèle custom, relié au partenaire :

5.3. Modèle pour les réponses de questionnaire – x_nurse_answer (optionnel mais très propre)

Si vous voulez garder l’historique détaillé des réponses :

Cela vous permet ensuite de :

• Faire des stats,
• Rejouer des profils,
• Alimenter un RAG spécialisé infirmier.

6. Résumé ultra-opérationnel

• ✅ Oui, l’ID Google est le meilleur pivot d’identité pour votre système.
• ✅ L’architecture gagnante :
  WebApp (Agent-3) + Auth Google → Backend → Odoo + n8n → MCP/Agents IA.
• ✅ Dans Odoo, créez au minimum :
  • x_google_sub sur res.partner
  • Un modèle x_nurse_profile qui stocke le profil IA JSON + scores.
  • Optionnel : x_nurse_answer pour l’historique détaillé des réponses.