1) L’idée générale : faire parler des données, pas seulement un modèle
L’application a été conçue pour répondre à un besoin fréquent : obtenir des réponses en langage naturel qui s’appuient sur des données internes (documents, fichiers, contenus structurés) plutôt que de produire une réponse “générique” uniquement issue des connaissances du modèle. L’objectif n’est pas de “remplacer” une base de données ou un moteur de recherche, mais de mettre une couche conversationnelle au-dessus des informations existantes, en conservant un maximum de traçabilité et de cohérence.
Au cœur de ce fonctionnement se trouve Gemini, qui sert de moteur de génération. Mais Gemini n’est pas utilisé comme une simple boîte noire : l’application organise la requête de l’utilisateur, récupère ou prépare des extraits pertinents, puis demande au modèle de produire une réponse conditionnée par ces extraits. Cette approche est proche de ce qu’on appelle souvent “génération augmentée par récupération” (RAG), même si l’implémentation exacte peut varier.
2) Le parcours d’une question : ce qui se passe à chaque étape
Étape A — Saisie et normalisation de la demande
Tout commence côté interface : l’utilisateur saisit une question en langage naturel. Avant d’envoyer quoi que ce soit au modèle, l’application prépare généralement la requête :
- nettoyage de base (espaces, longueur maximale) ;
- enrichissement éventuel (langue, contexte de la session, historique de conversation) ;
- ajout de consignes (“réponds en français”, “cite tes sources”, “n’invente pas si l’info n’est pas dans les données”).
L’objectif est de transmettre au backend un message structuré, prêt à être traité.
Étape B — Appel au backend conversationnel
L’interface envoie ensuite une requête vers un endpoint “chat” côté serveur (une route API). Cette séparation est importante :
- elle évite d’exposer des secrets (clé API, identifiants) dans le navigateur ;
- elle permet de contrôler la sécurité, les quotas, la validation des entrées ;
- elle rend possible l’accès à des données internes (fichiers, index, base, stockage).
Étape C — Récupération du contexte depuis les données
C’est le point clé : Gemini interagit avec les données indirectement, via le contexte que le serveur lui fournit. L’application ne “branche” pas le modèle directement sur un disque ou une base ; elle met en place un mécanisme où le serveur :
- identifie quelles données sont pertinentes pour la question ;
- extrait des passages utiles ;
- construit un “paquet de contexte” (souvent du texte + métadonnées) ;
- l’injecte dans la requête envoyée à Gemini.
Il existe plusieurs stratégies possibles pour cette étape.
Stratégie 1 — Recherche par mots-clés (simple et robuste)
Dans une approche basique, l’application parcourt des documents (ou un catalogue) et récupère les passages contenant des mots proches de la requête. C’est rapide à implémenter, mais parfois moins performant quand l’utilisateur reformule beaucoup.
Stratégie 2 — Recherche sémantique (embeddings)
Dans une approche plus avancée, l’application calcule des représentations vectorielles (“embeddings”) pour :
- la question utilisateur ;
- des fragments de documents (les “chunks”).
Ensuite, elle cherche les chunks dont le vecteur est le plus proche de celui de la question. Avantage : même si l’utilisateur ne reprend pas les mêmes mots, la similarité sémantique peut retrouver les bons passages.
Stratégie 3 — Hybride (mots-clés + sémantique)
Très utilisée en production : on combine une première passe rapide (filtres, mots-clés, métadonnées), puis on reranke avec la similarité sémantique.
Étape D — Construction du prompt “ancré” (grounded)
Une fois les passages récupérés, le backend construit un message pour Gemini structuré en général comme suit :
- Instruction système : style, contraintes (“si l’information n’est pas présente dans les extraits, dis-le”), format attendu (liste, tableau, étapes).
- Historique (si conversation multi-tours) : pour garder la continuité.
- Contexte : les extraits des données, avec leurs titres, dates, identifiants ou URLs.
- Question : la demande finale de l’utilisateur.
On cherche ici à éviter deux écueils :
- trop peu de contexte → réponses vagues ;
- trop de contexte → dépassement de taille, confusion, coût et latence.
Le choix du nombre de chunks, leur taille, et la manière de les ordonner est une partie importante du développement.
Étape E — Appel à Gemini et génération de la réponse
Le serveur envoie ce paquet à Gemini. Le modèle produit alors une réponse qui :
- reformule et synthétise les informations du contexte ;
- applique les consignes (langue, ton, format) ;
- peut justifier son raisonnement à partir des extraits fournis (selon la politique choisie).
Une bonne pratique consiste à demander explicitement :
- de ne pas inventer ;
- de signaler les zones d’incertitude ;
- de citer les passages (ou au moins les documents) utilisés.
Étape F — Post-traitement et retour à l’interface
Avant renvoi au navigateur, le backend peut :
- filtrer ou tronquer la réponse si elle est trop longue ;
- structurer en JSON (texte + citations + sources + score de confiance) ;
- enregistrer des métriques (latence, token usage) ;
- journaliser sans stocker de données sensibles (selon exigences).
L’interface affiche ensuite la réponse, parfois accompagnée de références, et l’utilisateur peut enchaîner.
3) Comment Gemini “interagit” réellement avec les données
Il est important de clarifier le rôle de Gemini : le modèle ne va pas chercher les données lui-même (dans la plupart des architectures web). Il répond à partir de ce qu’on lui donne. L’interaction est donc médiée par le serveur, qui joue plusieurs rôles :
- Sélection : trouver les bons passages dans le corpus.
- Contexte : formater ces passages pour qu’ils soient exploitables.
- Garde-fou : imposer des consignes anti-hallucinations.
- Conformité : gérer secrets, accès, audit.
Cette médiation est essentielle pour la qualité : quand la réponse est mauvaise, ce n’est pas toujours “la faute du modèle”, c’est souvent :
- une récupération d’extraits insuffisante,
- une mauvaise segmentation,
- un prompt trop permissif,
- ou des données ambiguës.
4) Les choix de développement : ce qui compte vraiment
a) Découpage en “chunks”
Pour que la recherche sémantique fonctionne bien, on ne donne pas un document entier à Gemini. On découpe en fragments (paragraphes, sections). Un bon chunking :
- respecte les frontières de sens (titres, sous-titres) ;
- évite les morceaux trop longs (dilution) ou trop courts (perte de contexte) ;
- conserve des métadonnées (source, page, section).
b) Indexation et mise à jour
Si les données évoluent, il faut :
- réindexer,
- recalculer les embeddings,
- invalidation de cache,
- versionner les corpus.
L’application peut choisir :
- un index statique (simple) ;
- un index mis à jour régulièrement (cron / job) ;
- un index “à la volée” (plus coûteux).
c) Stratégies anti-hallucinations
On ne supprime jamais totalement le risque d’hallucination, mais on le réduit fortement avec :
- “Réponds uniquement avec les informations présentes dans le contexte.”
- “Si la réponse n’est pas dans les extraits, réponds : ‘Je ne peux pas conclure…’”
- demande de citations ou de références ;
- limitation de température (moins de créativité, plus de déterminisme).
d) Sécurité et secrets
Le backend détient les secrets : clés, tokens, credentials. Ces éléments ne doivent pas se retrouver côté client. Le développement typique inclut :
- variables d’environnement locales pour le dev ;
- secrets gérés par la plateforme de déploiement en production ;
- contrôle d’accès si les données sont privées.
e) Observabilité (debugger un chatbot “data-driven”)
Pour améliorer l’application, il faut voir :
- quels chunks ont été récupérés,
- quelle requête a été envoyée,
- combien de tokens ont été consommés,
- la latence par étape (recherche vs génération).
Sans ces logs, on ne sait pas si un problème vient de la recherche, du prompt ou du modèle.
5) Exemple de déroulé concret (illustratif)
- L’utilisateur demande : “Quels sont les points clés du dossier X ?”
- Le serveur transforme la question en requête de recherche.
- Il récupère 5 à 10 extraits pertinents du corpus (sections du dossier X).
Il envoie à Gemini :
- consigne “résume, structure, cite les sections” ;
- extraits (avec titres et identifiants) ;
- question.
- Gemini répond avec une synthèse structurée, en s’appuyant sur les extraits.
- L’application affiche la réponse et éventuellement les sources.
Ce déroulé illustre bien que Gemini est guidé, et que la valeur de l’application réside dans la façon dont elle sélectionne et injecte les bonnes informations.
6) Conclusion : une application de conversation pilotée par les données
Le fonctionnement global repose sur une idée simple : la réponse est générée par Gemini, mais la pertinence dépend de la qualité du contexte fourni. L’application orchestre donc une chaîne : question → recherche dans les données → construction d’un contexte → génération contrôlée.
Ce type d’architecture est efficace car il :
- rend les réponses plus fiables et plus “ancrées” ;
- permet de mettre à jour le savoir sans réentraîner un modèle ;
- donne un cadre pour la sécurité et l’audit.