Produit interne
Plateforme de support
Ce que je cherchais n’existait pas, alors je l’ai construit
Une plateforme de support auto-hébergée dont l’assistant IA répond uniquement depuis sa base de connaissances, et dont la base grandit avec les questions restées sans réponse.
Réservée aux clients de Nolorem, il n’y a donc pas de visite publique. Les écrans de cette page la montrent avec des données de démonstration.
Ce que vous y trouvez
Des réponses avec la source
L’assistant répond uniquement depuis la base de connaissances et renvoie à l’article utilisé. Quand rien ne couvre la question, il le dit au lieu de deviner.
Il connaît le compte
Il voit l’abonnement du client et ses tickets ouverts, et rédige un ticket quand il le faut. Rien n’arrive dans la file tant que le client n’a pas confirmé.
Des tickets qui arrivent avec leur contexte
Un ticket porte le contexte des articles que le client a déjà lus, et personne ne se voit demander s’il a consulté le manuel.
Chaque conversation est conservée
Chaque échange avec l’assistant est gardé avec son issue et la note du client. Je vois où il aide et où il passe la main.
Les lacunes remontent d’elles-mêmes
Les questions restées sans réponse sont regroupées et comptées, et chaque groupe devient un brouillon d’article en un clic.
Sur mes propres serveurs
Captures d’écran, détails de compte, description de ce qui a cassé : tout reste sur une infrastructure que je gère, pas chez un éditeur de helpdesk.
Pourquoi elle existe
Toute personne qui paie pour Nolorem mérite une aide correcte au moment où quelque chose casse. Aucune des options habituelles ne me convenait. Un helpdesk hébergé facture par agent et par mois et garde vos conversations clients sur les serveurs d'un tiers, ce qui est un message étrange venant d'une plateforme qui prend la confidentialité comme point de départ. Un site de documentation statique répond aux questions d'hier et ne sait pas prendre un ticket.
Ce que je voulais vraiment n'existait pas sous une forme qui me plaisait : une base de connaissances qui intercepte la question avant qu'elle ne devienne un ticket, avec un assistant qui répond uniquement depuis ma propre documentation. Je l'ai donc construite moi-même, sur la même infrastructure et les mêmes principes que Nolorem.
Un assistant qui dit qu'il ne sait pas rend plus service qu'un assistant qui a toujours une réponse.
Le parcours d’une question
Un client qui a un problème commence par l'assistant, pas par un formulaire. L'assistant cherche dans la base de connaissances, répond à partir de l'article trouvé et y renvoie, pour que le client puisse lire l'article entier plutôt que de se fier à un résumé. Quand la base ne contient rien sur le sujet, l'assistant le dit tel quel et propose d'ouvrir un ticket. Il n'en crée jamais un de lui-même : le client confirme d'abord, ce qui évite les escalades accidentelles dans la file.
Le ticket qui finit par être ouvert porte le contexte des articles que le client a déjà parcourus. De mon côté, il arrive dans une boîte de réception filtrable par statut, priorité et catégorie, et sur un tableau qui montre où en est chaque ticket, du tri jusqu'à l'attente d'une réponse du client. Je pars donc de ce que le client a déjà essayé, et chacun s'épargne un tour de questions.
Comment la base de connaissances grandit
Les tickets ne sont pas seulement du travail, ce sont aussi des signaux. Une question que l'assistant a dû transmettre est une question à laquelle la base n'a pas su répondre, et quand la même revient sans cesse, cela doit ressortir plutôt que disparaître dans une archive. La plateforme regroupe ces questions et les compte, si bien que la lacune qui coûte le plus de tickets arrive en tête de liste.
Depuis une lacune, un clic ouvre un nouvel article dont le titre est déjà la question. J'écris la réponse, je la publie, et le client suivant qui pose la même question l'obtient aussitôt de l'assistant, sans ticket. C'est cette boucle qui améliore le système avec le temps, et c'est pour cela que l'aide progresse exactement là où elle faisait défaut, et non là où quelqu'un a supposé qu'elle le ferait.
Les échanges de support contiennent le matériel le plus sensible qu'un client envoie jamais : captures d'écran, détails de compte, description de ce qui a cassé. Tout cela reste sur une infrastructure que je maîtrise. Ce n'est pas une option facturée, c'est le réglage par défaut.
Ce sur quoi j’ai buté
La qualité de la recherche décide de tout. Une base de connaissances que personne ne sait interroger est une base que personne n'utilise, et l'on ouvre un ticket à la place, exactement ce que le système existe pour éviter. Faire correspondre la recherche à l'intention plutôt qu'à la formulation exacte a fait la différence entre un outil utile et une décoration.
Un assistant outillé a besoin de limites. Dès qu'un modèle peut consulter et créer des tickets, l'injection d'invite devient un risque réel et non plus théorique. Les données venues de l'extérieur sont transmises délimitées, l'invite système reste courte, et les actions à conséquence demandent la confirmation de l'utilisateur.
Écrire de bons articles est plus dur que bâtir la plateforme. Le logiciel était la plus petite moitié. Un article qui répond vraiment à une question, au lieu de paraphraser l'interface, demande un effort réel, qu'aucune ingénierie ne remplace.
Pourquoi cette page existe
C'est une petite plateforme qui règle un problème peu glorieux, et à ce titre une illustration honnête du type de travail dont les entreprises ont le plus souvent réellement besoin : pas une conquête spatiale, mais la chose qui supprime discrètement un coût récurrent. Elle montre aussi que je prends mes propres clients au sérieux : la voie économique était un abonnement, avec les conversations hébergées ailleurs.