Projet en poste · IAssist · En déploiement
Une IA de support qui a déjà lu plus de 130 000 tickets.
IAssist répond aux personnels à toute heure à partir des bases du support. Quand il ne trouve pas, il transmet la demande à l'équipe, déjà rédigée et classée. Pour les techniciens, il devient un copilote qui analyse chaque nouveau ticket.
130 000+
tickets rendus exploitables
3 500+
pages de documentation
100 000+
personnels : déploiement prévu
Région Académique Occitanie, 2025–2026
Le problème
L'équipe d'assistance reçoit chaque jour des centaines de tickets. Une bonne partie revient sans cesse : accès au compte académique, mot de passe, messagerie, VPN, applications métier comme SIECLE, PRONOTE, AFFELNET ou I-Prof.
Les réponses existent déjà, mais elles sont dispersées : une FAQ, des modèles de réponses rédigés par les techniciens, une documentation Confluence et l'historique des tickets résolus.
La réponse : deux agents, un même socle
Pour les usagers, un premier niveau de support disponible à toute heure, intégré à la plateforme de tickets. Il ne répond qu'à partir des sources destinées au public, et n'invente jamais de procédure.
Pour les techniciens, un copilote qui analyse un nouveau ticket, fouille toutes les sources, y compris la documentation interne et l'historique, puis propose une synthèse avec une recommandation.
Le tout fonctionne avec des modèles à poids ouverts, sur les API de l'État ou hébergés en interne.
Assistant usagers · premier niveau, à toute heure
Question
+ académie, service ou application
→ le bon contexte
Recherche hybride
FAQ · modèles de réponses
→ sources publiques seulement
Réponse sourcée
si une solution existe
→ l'usager est dépanné
Ticket pré-rempli
rédigé et classé, avec son accord
→ dans la bonne file
Copilote des techniciens
Nouveau ticket
analysé par l'agent
→ ce qui est demandé
Recherche hybride
FAQ · modèles · Confluence · tickets résolus
→ les 4 sources
Lecture ciblée
pages Confluence pertinentes lues en entier
→ le détail utile
Synthèse
et recommandation
→ le technicien décide
Ce qui fait la différence
Une recherche qui connaît le vocabulaire du support. Les acronymes, noms d'applications et codes d'erreur échappent souvent à la seule recherche par le sens. Chaque recherche combine donc les mots exacts et le sens, puis un modèle de tri reclasse les candidats et ne transmet que les meilleurs, avec leur source.
Un ticket bien rédigé plutôt qu'une réponse inventée. Sans solution, l'assistant rédige le sujet et la description à partir de la conversation, identifie le service, classe la demande dans la bonne sous-catégorie et prépare un formulaire pré-rempli. L'usager vérifie et valide : rien n'est créé sans son accord, et l'équipe n'a plus à requalifier.
Le bon contexte dès la première question. L'usager indique son académie et, s'il le souhaite, le service ou l'application concernés. Les procédures qui diffèrent d'une académie à l'autre (adresses, contacts, démarches) sont choisies en conséquence.
Une attente qui se comprend. La réponse s'affiche au fil de l'écriture, et l'interface montre ce que fait l'agent : « Recherche dans la base de connaissance… », « Création d'un ticket… ». L'historique est conservé côté serveur pour garder le fil.
Une ligne pour l'intégrer. Un simple script ajoute IAssist à n'importe quelle page, à commencer par la plateforme de tickets, sous la forme d'un bouton qui ouvre le chat.
Mesurer pour améliorer
Chaque échange est tracé dans Langfuse : la question, les outils appelés, les documents retrouvés, la réponse et le modèle utilisé.
Les retours des usagers, pouce levé ou baissé avec un commentaire facultatif, sont rattachés à l'échange concerné. Ils montrent les questions mal couvertes, et donc les sources à enrichir.
Les consignes de l'agent sont versionnées et déployées par étiquette : une nouvelle version passe en production sans redéployer l'application.
Souverain, et indépendant du fournisseur
Le même agent tourne sur Albert, l'API d'IA de l'État, sur Aristote, ou sur des modèles auto-hébergés (llama.cpp, Ollama), au choix par simple configuration. Les modèles sont à poids ouverts, comme Gemma ou Qwen : rien n'oblige les données à quitter une infrastructure souveraine, ni même les serveurs internes.
L'interface suit le Système de Design de l'État (DSFR), avec ses exigences d'accessibilité et ses pages légales.