Projet démo : agent IA de support client connecté au ticketing

Ce projet démonstratif montre comment nous construisons un agent IA de support de niveau 1 : il ne s'agit pas d'un déploiement client, mais d'un système complet que nous maintenons pour illustrer nos choix d'architecture et nos garde-fous.

Le cas modélisé est celui d'un éditeur de logiciel dont l'équipe support reçoit des demandes répétitives (configuration, facturation, erreurs courantes) dont les réponses figurent déjà dans la documentation et les articles d'aide.

L'agent répond aux demandes simples en s'appuyant exclusivement sur cette documentation, crée ou met à jour les tickets dans l'outil de ticketing, et transmet à un agent humain dès qu'il sort de son périmètre.

Un assistant fondé sur un modèle de langage générique invente des réponses, ne connaît pas le produit et n'a aucune idée du contexte du client. Sans garde-fous, il crée plus de travail pour le support qu'il n'en retire.

Il faut donc ancrer les réponses dans la documentation, borner ce que l'agent a le droit de faire, mesurer la qualité des réponses et contrôler les coûts d'appel au modèle.

Un service Python (FastAPI) reçoit les messages depuis le widget de discussion ou depuis les tickets entrants de l'outil de ticketing via webhook.

Un pipeline d'ingestion découpe la documentation (pages d'aide, notes de version, FAQ) en fragments, calcule leurs représentations vectorielles et les stocke dans PostgreSQL avec l'extension pgvector, avec les métadonnées de version et de source.

À chaque question, le service recherche les fragments les plus pertinents (recherche vectorielle combinée à une recherche par mots-clés), construit un prompt contraint et appelle l'API du modèle de langage.

Une couche de garde-fous valide l'entrée (détection de données sensibles, hors sujet) et la sortie (présence de sources, absence d'engagements interdits) avant tout envoi à l'utilisateur.

L'agent dispose d'outils limités : lire le ticket, y ajouter une réponse ou une note interne, changer son statut et le transférer à un humain. Redis gère l'état des conversations et les plafonds de coût.

Chaque appel est tracé (OpenTelemetry) avec le nombre de jetons, la latence et le coût, et un jeu d'évaluation est rejoué automatiquement dans le pipeline d'intégration continue.

Le cœur de la démarche est la génération augmentée par récupération (RAG) : l'agent ne répond qu'à partir des fragments de documentation retrouvés et cite les pages correspondantes. Si la recherche ne renvoie rien de pertinent ou si la confiance est faible, l'agent l'indique clairement et propose le transfert plutôt que de deviner.

Les garde-fous sont implémentés comme des étapes distinctes, testables indépendamment du modèle : filtrage des demandes hors périmètre, masquage des données personnelles dans les journaux, liste explicite des actions autorisées et vérification de la réponse avant envoi. Une réponse qui échoue à ces contrôles est remplacée par un transfert.

Le transfert humain est un cas normal, pas un échec : l'agent résume la demande, joint la conversation et les sources consultées au ticket, et le place dans la file adéquate. L'agent humain voit exactement ce qui a été dit et pourquoi le transfert a eu lieu.

La qualité et les coûts sont mesurés en continu. Un jeu d'évaluation de questions représentatives avec réponses attendues est rejoué à chaque changement ; les régressions bloquent le déploiement. Les coûts par conversation sont suivis et un plafond suspend l'agent au profit des humains si le budget est dépassé.