Objectif : Transformer une donnée non structurée (conversation naturelle) en donnée structurée (commande Odoo).

C'est  l'un des cas d'usage les plus pertinents pour l'IA générative aujourd'hui : transformer une donnée non structurée (conversation naturelle) en donnée structurée (commande Odoo).

L'utilisation de Supabase comme base vectorielle pour le RAG est un très bon choix technique.

Voici l'architecture technique recommandée pour réaliser ce système "Auto Fill" intelligent.

Le flux se décompose en 3 briques principales :

1. La Synchronisation (Knowledge Base) : Odoo vers Supabase.> là c'est exporté deja TOUT les contacts de ODOO CONTACT TYPé SYNERGIA > cela permet d'avoir dans le RAG des données vectorisables  ( celles qui changent pas tout le temps ) > c'est un batch à faire toutes les heures ou jour . 
2. Le Traitement (Processing) : Conversation vers Extraction JSON. > Là c'est après la reconnaissance de la parole , c'est de faire le parsing dans le RAG<>LLM, pour voir si une nouvelle personne est mentionné et si c'est le cas alors faire le push vers le User dans SCREEN pour lui demander de valider l'orthographe du prénom, nom et aussi valider numéro de téléphone et profession si c'est présent dans le texte de la reconnaissance + et .... si .... le nom de la personne est DEJA dans le RAG avec juste faire un push "visuel" pour demander validation que c'est bien cette personne. 
3. L'Exécution (Action) : JSON vers Odoo.

L'IA doit connaître vos produits parfaitement pour ne pas halluciner des références.

1. Extraction Odoo : Via l'API d'Odoo (XML-RPC ou REST), vous exportez périodiquement votre liste de nom (Nom, prénom, adresse, titre, ...) 
2. Vectorisation (Embeddings) : Vous passez ces descriptions produits dans un modèle d'embedding (ex: OpenAI text-embedding-3-small ou un modèle open source via HuggingFace).
3. Stockage Supabase : Vous stockez ces vecteurs et les métadonnées (ID Odoo contact , Nom, SKU) dans une table Supabase avec l'extension pgvector.

Pourquoi ? Cela permet à l'IA de comprendre que si le client dit "je dsicute avec Madame Lauret et sa nièce Madame Laurence Vassor et Monsieur alexandre Bompart qui est Kiné   ", cela correspond a la ficher contact existante dans ODOO module CONTACT   grâce à la recherche sémantique ( et RAG ) . Et si ce nom n'existe pas alors ... création et PUT dans ODOO Contact étendu du JSON des professions possibles ( ici kiné, ect ... )

.

C'est le cœur du réacteur. Voici le workflow lorsqu'une conversation est terminée :

1. Input : Récupération de la transcription de la conversation (texte).
2. Recherche RAG (Retrieval) :
   • Le système analyse la conversation pour repérer les intentions d'achat.
   • Il interroge Supabase : "Quelles sont les personnes de notre base ODOO contact qui ressemblent le plus aux noms prénom dans ce texte ?"
   • Supabase renvoie les 10-20 produits les plus probables avec leurs vrais ID Odoo.
3. Extraction LLM (Generation) :
   • Vous envoyez au LLM (GPT-4o ou Claude 3.5 Sonnet ou openAI 4àmini ) un prompt contenant :
     • La conversation brute.
     • La liste des produits candidats trouvés par Supabase (Context).
     • Une instruction stricte : "Extrais les informations du client et mappe les demandes produits uniquement avec les IDs de la liste fournie."
4. Output JSON : Le LLM génère un JSON propre.

Exemple de structure JSON attendue :

JSON

{
  "client": {
    "name": "Jean Dupont",
    "email": "jean.dupont@email.com",
    "phone": "+33600000000"
"Profession": "Gériatres"

  ]
}

Une fois le JSON validé, un script backend (Python ou une Edge Function Supabase) prend le relais :

1. Vérification Client : Interrogation de Odoo. Le client existe-t-il (email/tel) ?
   • Oui : On récupère son ID.
   • Non : On crée la fiche contact (res.partner) et on récupère le nouvel ID.
2. Création du Devis : Appel API Odoo pour créer un sale.order.
3. Injection des lignes : Boucle sur le JSON pour créer les sale.order.line avec les bons Product IDs récupérés via le RAG.

Pour être efficace et robuste, voici la stack idéale :