ASIA
ASIA
Assistant Support Informatique Augmenté
Un GPT personnalisé qui prend en charge le premier niveau du support informatique. Prototype fonctionnel, testé sur scénarios.
Le problème
Dans un service support classique, les incidents sont traités par ordre de priorité. C'est rationnel à l'échelle du service, et frustrant à l'échelle de l'utilisateur : celui dont le problème n'est pas critique sait qu'il va attendre. Alors il essaie de se débrouiller seul.
C'est là que se produit ce que personne ne mesure. L'utilisateur qui bricole sans savoir transforme parfois une panne bénigne en incident réel. Le ticket qui arrive au support n'est plus celui qu'il aurait été une heure plus tôt.
Or une large part des incidents de premier niveau se résolvent par quelques vérifications simples — connexions, mises à jour, redémarrages, droits d'accès. C'est un constat courant dans le métier du support, souvent chiffré autour de 80 %. Ces cas-là n'ont pas besoin d'un technicien. Ils ont besoin d'être pris en charge tout de suite.
Ce que j'ai construit
Un agent conversationnel sous forme de GPT personnalisé, qui conduit un diagnostic de premier niveau comme le ferait un technicien N1 : il interroge, élimine, oriente.
La partie qui m'intéressait le plus est celle de l'adaptation. L'agent identifie le niveau technique de son interlocuteur à travers ses premières réponses, puis ajuste son vocabulaire. À un utilisateur qui ne sait pas ce qu'est une adresse IP, il ne demande pas de vérifier sa configuration réseau. C'est exactement le problème que je rencontre depuis vingt ans dans un tout autre contexte : une solution juste, formulée dans un langage que l'interlocuteur ne possède pas, ne sert à rien.
Ce qu'il fait
Il pose les questions de diagnostic dans un ordre cohérent, adapte son registre au niveau détecté, guide vers une résolution quand elle est à portée, et rédige un ticket documenté quand elle ne l'est pas — de sorte que le technicien qui le reçoit n'a pas à tout recommencer.
Essayer ASIA (un compte ChatGPT gratuit suffit) :
Ce qu'il ne fait pas
C'est un prototype, construit pour démontrer que je sais mener ce type de projet de bout en bout. Il n'a jamais tourné en environnement réel.
Il s'appuie sur un contexte d'entreprise fictif, construit pour la démonstration : une PME industrielle avec son parc, ses applications et son organisation du support. Un déploiement réel exigerait le contexte de l'organisation elle-même — sa documentation, son historique de tickets, son inventaire.
L'agent applique fidèlement une méthode, mais résiste aux consignes qui contredisent ses réflexes les plus courants. Exemple constaté : instruit de proposer un partage par lien pour les fichiers trop volumineux, il continue de suggérer de découper l'envoi en plusieurs messages — la réponse la plus répandue, et celle que l'entreprise ne veut pas. Un déploiement réel demanderait de vérifier ce point cas par cas.
Il ne s'intègre à aucun outil de ticketing. Le ticket est rédigé, pas créé.
Et le gain que je décris plus haut — éviter l'escalade des pannes bénignes — est une intention de conception, pas un résultat mesuré. Il faudrait le tester en conditions réelles pour l'affirmer.
Ce que je ferais ensuite
Le connecter à une base documentaire réelle, ce qui est la condition de toute utilité opérationnelle. L'intégrer à un outil de ticketing pour fermer la boucle. Et le mettre entre les mains d'utilisateurs qui ne l'ont pas conçu — c'est le seul test qui compte.