SAWL · ce qu’on a appris en livrant notre propre produit IA

Pourquoi on a fait SAWL

On intègre Apidae depuis 2014 pour des offices de tourisme et des collectivités. À force de voir les mêmes questions revenir sur les sites, les widgets et les comptoirs, on a voulu répondre concrètement à une seule interrogation : est-ce qu'un assistant conversationnel peut tenir cette charge sans déraper, en s'appuyant uniquement sur les contenus que la structure a déjà validés ?

SAWL est né de ce besoin. C'est un produit dédié à un métier qu'on connaît, branché sur la base Apidae, sur les contenus du site, sur des PDF, sur des FAQ. Le choix d'en faire un produit, et pas une fonctionnalité d'un projet client, était délibéré : on voulait porter nous-mêmes le coût de l'opération pour voir ce que ça révèle.

C'est aussi notre façon de tenir une phrase qu'on répète en agence : l'IA n'est pas un nouveau métier, c'est une nouvelle couche de valeur sur le métier existant. SAWL nous oblige à l'éprouver chez nous avant de la proposer ailleurs.

Ce qu'on a appris à le sortir

La première leçon tient en peu de mots : un produit se mesure à ce qui se passe le mardi à 14h, quand un visiteur tape une question floue, mal orthographiée, sur un événement qui a changé d'horaire la veille. Une réponse brillante sur trois requêtes choisies ne dit rien de cette charge réelle. Tout le travail s'est concentré sur ce décalage.

On a beaucoup investi dans le périmètre des sources : ce que le modèle voit, ce qu'il ne voit pas, ce qui est prioritaire quand deux sources se contredisent. La qualité d'un assistant tient surtout au cadrage de ce sur quoi il a le droit de répondre, et au moment où il doit dire qu'il ne sait pas.

Sortir un produit ouvert au public change la barre. Une réponse mauvaise est visible, et c'est nous qui la portons. Ça discipline la façon de prioriser les correctifs et ça impose une boucle d'opération courte.

Les arbitrages techniques qu'on assume

On a fait des choix simples pour rester maîtres de la chaîne. Hébergement en Union européenne, données synchronisées depuis Apidae avec un cycle quotidien, contenus complémentaires apportés par l'équipe locale. Sur les modèles, on travaille avec Mistral en priorité quand le sujet le demande, un modèle frontier non européen si la spécificité du cas l'exige, et de l'open source quand le contexte le permet.

On a choisi de contraindre fortement la génération plutôt que de la laisser libre. L'assistant ne répond qu'à partir des sources approuvées par la structure. Ce parti pris coûte sur la variété apparente des réponses, mais il pose un plancher de fiabilité sur lequel on peut tenir une conversation avec un directeur d'office.

Le support multilingue, attendu sur un usage touristique, demande son propre dispositif : un modèle d'embeddings multilingue pour l'indexation, un fallback de génération par langue cible, des règles spécifiques sur les noms propres locaux. On progresse par paliers, marché par marché, plutôt que de promettre la même qualité partout d'un coup.

La chaîne RAG, dans le détail

L'architecture tient en trois étages. À l'ingestion, on segmente chaque source (fiche Apidae, page de site, paragraphe de PDF, entrée de FAQ) en passages de quelques centaines de tokens, avec un recouvrement entre passages voisins pour ne pas casser une phrase au milieu. Chaque passage est encodé sous forme de vecteur dense par un modèle d'embeddings multilingue, puis indexé dans un store vectoriel. Le découpage et le choix du modèle d'embeddings sont les deux paramètres qui pèsent le plus sur la qualité finale.

À la requête, la question du visiteur est encodée par le même modèle d'embeddings, puis on remonte les passages les plus proches par similarité cosinus. On garde un top-k volontairement court, entre cinq et dix passages selon le type de requête. Sur les questions ambiguës, on passe par une étape de reranking pour réordonner ces passages selon leur pertinence relative, avec un second modèle plus lent mais plus discriminant. Cette étape coûte des millisecondes, et elle change beaucoup la justesse perçue.

À la génération, le modèle reçoit le contexte sélectionné, la question, et une instruction stricte de ne répondre qu'à partir de ce contexte. Aucune connaissance hors sources n'est mobilisée : si l'information n'est pas dans les passages remontés, l'assistant le dit. Ce verrou est posé en amont par le prompt et vérifié en sortie par un contrôle léger sur le contenu. Le modèle ne brode pas, et c'est volontaire.

Ce qu'on découvre en l'opérant

Faire vivre un produit IA, c'est faire vivre un dispositif : on monitore les conversations, on repère les questions où l'assistant a fléchi, on réajuste les sources, on documente les cas limites. Cette boucle ressemble plus à de l'opération produit qu'à du réglage de prompt.

On apprend aussi beaucoup des intentions des visiteurs. Les questions réelles ne ressemblent pas à celles qu'on imagine en réunion de cadrage. Ce signal remonte aux équipes des offices qui s'en servent pour faire évoluer leurs contenus, parfois indépendamment du chatbot. C'est un effet de bord qu'on n'avait pas anticipé et qu'on trouve plus intéressant que beaucoup de fonctionnalités prévues au départ.

Côté coûts, l'équation d'un produit IA en production diffère d'une POC. Chaque requête a un coût unitaire, chaque langue ajoute du volume, chaque correctif demande du temps humain. Tenir cette économie a changé notre façon de chiffrer un cas client.

Ce qu'on garde sous contrôle

Le premier niveau de contrôle est le périmètre des sources. On choisit ce qui entre dans l'index et on rejette le reste. Une fiche obsolète, un document non validé par l'équipe, une page provisoire : aucun de ces contenus ne passe le filtre tant qu'il n'a pas été repris. Cette discipline limite le volume de réponses possibles, et elle garantit qu'aucune phrase ne sort d'un brouillon.

Le deuxième niveau, c'est la règle de réponse. Quand l'index ne remonte aucun passage suffisant, l'assistant ne complète pas avec une réponse approximative : il déclare ne pas avoir l'information et propose un autre chemin (renvoi vers le site, vers un conseiller, vers un point d'accueil). On suit le taux de réponses « je ne sais pas » comme un indicateur de couverture, pas comme un défaut à masquer.

Le troisième niveau, c'est la boucle d'opération. La synchronisation Apidae tourne en cycle quotidien, mais l'équipe locale peut forcer une mise à jour ciblée quand un horaire change. Les conversations sont monitorées, les questions où l'assistant a fléchi remontent dans un tableau de suivi, les sources concernées sont reprises ou complétées. C'est ce maillage opérationnel qui rend l'assistant fiable sur la durée, pas un seul gros effort initial.

Ce que SAWL nous a appris pour les projets client

On en revient avec une ligne plus stable : il y a un endroit où l'IA fait gagner du temps, et un endroit où elle ajoute surtout du bruit. SAWL a affiné notre capacité à nommer cette ligne sur un projet client, parce qu'on l'a cherchée chez nous, sur notre propre produit, avec notre propre argent.

On en revient aussi avec une règle : un cas d'usage IA qui ne supporte pas la répétition, la mesure et la maintenance ne tient pas. La méthode qu'on applique chez les clients reprend ce principe. On audite, on intègre, on mesure, on maintient, on augmente.

Sur un sujet IA, on préfère montrer SAWL plutôt que de promettre. C'est le moyen le plus court qu'on ait trouvé pour dire ce qu'une agence digitale fait quand elle pose l'IA en couche du métier, sans en faire un nouveau métier.