Comment fonctionne l’assistant ?

Le prototype associe un modèle de langage à des outils contrôlés par l’application. Le modèle choisit les opérations ; l’application exécute les calculs et affiche leurs résultats.

Architecture générale

Dans le navigateur

Chargement du fichier, moteur DuckDB, requêtes SQL, tableau, graphiques et cartes.

Sur le serveur

Préparation du contexte, appel au modèle, accès aux métadonnées et enregistrement des feedbacks.

Le fichier complet n’est pas envoyé au modèle. L’assistant demande à l’application d’exécuter les opérations nécessaires, puis utilise les résultats obtenus pour répondre.

Quelles données sont échangées ?

Le modèle reçoit la question, l’historique de la conversation, le nom de la ressource, son schéma et les résultats utiles des outils. Ces résultats sont limités afin d’éviter l’envoi de volumes inutiles.

La ressource publique reste traitée localement dans le navigateur. Les secrets nécessaires pour appeler Albert API restent côté serveur.

Un feedback transmet la question, la réponse, l’évaluation et le contexte de la ressource. Le formulaire complémentaire est facultatif.

Quels outils peut utiliser l’assistant ?

Métadonnées
Consulte la fiche publique du jeu de données sur data.gouv.fr : titre, description, producteur, licence, dates et ressources disponibles. Cet outil répond aux questions sur le contexte de publication, sans analyser les valeurs du fichier.
Structure
Inspecte la ressource chargée pour identifier ses colonnes, leurs types, le nombre de lignes et quelques valeurs d’exemple. L’assistant s’en sert pour comprendre les champs disponibles avant de préparer un calcul.
SQL
Prépare puis exécute une requête en lecture seule avec DuckDB dans le navigateur. Le résultat indique les colonnes obtenues, le nombre de lignes, un aperçu des valeurs et les éventuelles limites appliquées.
Vue du tableau
Propose d’utiliser une requête SQL réussie comme nouvelle vue de l’explorateur, par exemple pour filtrer une région ou trier des résultats. L’utilisateur voit la proposition et doit confirmer avant que le tableau change.
Graphique
Transforme un résultat SQL vérifié en graphique à barres, courbe, aire, secteurs ou nuage de points. Le titre, la description, les axes, les séries et la source restent visibles et vérifiables.
Carte
Construit une carte à partir de coordonnées, de géométries ou d’identifiants de régions et départements. L’outil signale les lignes qui ne peuvent pas être placées ou appariées.
Clarification
Suspend la réponse lorsque plusieurs interprétations modifieraient réellement le résultat. Les choix possibles sont alors proposés sous forme de boutons afin que l’utilisateur décide avant la poursuite de l’analyse.

Une requête doit réussir avant d’alimenter une vue, un graphique ou une carte. Chaque visualisation reste ainsi reliée à un résultat calculé et vérifiable.

Quels modèles sont utilisés ?

Les modèles sont accessibles par Albert API. GPT-OSS-120B est sélectionné par défaut et Mistral Medium 3.5 peut être choisi dans l’interface pour réaliser des comparaisons.

Changer de modèle peut modifier la formulation, la vitesse, le choix des outils et la qualité des requêtes. Les calculs restent néanmoins exécutés par les mêmes outils contrôlés par l’application.

Quels garde-fous sont appliqués ?

  • Les requêtes SQL sont limitées à la lecture.
  • Le nombre d’étapes et d’opérations est borné pour éviter les boucles.
  • Un changement de ressource invalide les résultats calculés précédemment.
  • Les métadonnées et valeurs sont traitées comme des données, jamais comme des instructions.
  • Les demandes trop nombreuses sont limitées par session et par empreinte IP quotidienne, sans conserver l’adresse IP brute.
  • Deux réponses peuvent être produites simultanément par session et les compteurs expirent sous 48 heures.
  • Les erreurs distinguent autant que possible le fournisseur IA, la connexion, le SQL, DuckDB et la visualisation.

Limites techniques actuelles

  • Seules les ressources disposant d’une version Parquet compatible peuvent être explorées.
  • Les conversations ne sont pas persistées.
  • Les réponses des modèles restent variables et doivent être évaluées sur des cas réels.
  • Le suivi agrégé des usages, des erreurs, des performances et des coûts reste à compléter.
  • Ce prototype n’est pas encore intégré à cdata ou udata.