Guide · 3 septembre 2026 · 10 min de lecture

Un assistant qui répond avant votre équipe

Sur un serveur qui reçoit du support, la même poignée de questions représente l'essentiel des tickets. Y répondre à la main, dix fois par semaine, use une équipe bénévole plus sûrement qu'un incident grave.

Ce qu'un assistant peut vraiment absorber

Regardez vos trente derniers tickets. Sur un serveur communautaire, la répartition est presque toujours la même : une moitié de questions répétitives — « j'ai payé et je n'ai rien reçu », « comment contester une sanction », « comment postuler » — et une moitié de cas particuliers qui demandent un humain.

C'est la première moitié que l'automatisation traite bien. Pas parce qu'elle est simple, mais parce qu'elle est identique d'une fois sur l'autre : la réponse est déjà écrite quelque part, souvent dans un salon d'annonces que personne ne relit.

L'objectif n'est donc pas de remplacer l'équipe. C'est de lui rendre les tickets qui méritent son attention, en réglant les autres avant qu'elle ne les ouvre.

Ce qui décide de tout : le moment où il se tait

Un assistant qui répond trop est pire qu'un assistant absent. Trois règles de retrait valent plus que toute la finesse de compréhension.

• À l'ouverture, il ne mentionne personne. Pinger l'équipe avant même de savoir de quoi il s'agit, c'est exactement ce qu'on cherche à supprimer. Le bot se présente, invite à exposer la demande, et attend.
• Dès qu'un humain écrit, il disparaît. Définitivement, y compris s'il pense avoir la réponse. Deux voix qui répondent à la même personne, dont l'une contredit l'autre en public, coûtent plus cher que tous les tickets qu'il aurait pu absorber.
• Il n'insiste pas. Deux échecs, et il appelle l'équipe. Un bouton permet de court-circuiter à tout moment : quelqu'un qui veut un humain doit l'obtenir sans négocier avec un robot.

Ne partez pas de la page blanche

Le conseil qui suit — écrivez vos fiches, soignez les reformulations — est juste, et il a longtemps été le seul. Il a aussi un défaut : il suppose qu'on sache d'avance ce que les membres vont demander, et qu'on le formule comme eux. Personne ne fait ça. On écrit trois fiches, on allume, et on découvre trois semaines plus tard que le bot renvoie tout le monde vers l'équipe.

Or la matière existe déjà, et elle est meilleure que tout ce que vous écririez de tête : vos tickets fermés. À chaque fermeture, Orius y retrouve la vraie question — celle d'un vrai membre, avec ses fautes et ses mots à lui — et la vraie réponse de votre modérateur, celle qui a réglé le problème. Elle atterrit dans la file « À valider » de votre panneau, en proposition. Vous relisez, vous corrigez deux mots, vous validez.

Trois sources alimentent cette file. Les tickets fermés, donc. Les questions restées sans réponse, groupées par sujet : douze personnes ayant demandé la même chose formaient douze lignes dans une liste que plus personne ne lisait, elles n'en forment plus qu'une, marquée « 12 personnes concernées ». Et les fiches qui répondent mal, signalées avec les formulations exactes sur lesquelles elles échouent — la réponse est déjà bonne, il ne manque que les mots par lesquels on la cherche.

La file est triée par nombre de personnes concernées, parce que c'est la seule question qu'on se pose devant une base à écrire : par où commencer.

Écrire la base de connaissance

Une fiche, c'est une question et une réponse. La tentation est d'écrire la question comme un titre de documentation ; l'erreur est là.

Écrivez la question comme un membre la poserait. « Mon grade n'apparaît pas après l'achat » vaut mieux que « Procédure de synchronisation des rôles ». Personne ne tape le second.

Puis ajoutez des reformulations, une par ligne. C'est le champ le plus utile de tous, et celui qu'on remplit le moins. Deux usages distincts :

1. Le vocabulaire de votre serveur. Si vos membres disent « mon rank » ou « mon VIP », aucun lexique générique ne le devinera.
2. Les autres langues. Une reformulation en anglais ou en espagnol dans une fiche écrite en français permet de couvrir un serveur international sans tenir quatre bases séparées.

Comment le bot comprend une question mal écrite

Un membre n'écrit jamais la question telle qu'elle a été saisie. Il tape « slt jai payé mais jai tjr pa recu mon grade » là où l'admin avait écrit « Comment récupérer mon grade après un achat ? ». Pas un mot en commun sous sa forme écrite.

La comparaison directe échoue donc toujours. Ce qui fonctionne, c'est de reformuler d'abord : retirer les accents et l'écriture en chiffres, développer les abréviations, ramener les mots à leur racine — « payé », « paiement » et « payer » deviennent la même chose. Puis élargir avec un lexique d'intentions : ce qui relève de l'achat, de la sanction, du délai, quelle que soit la langue.

C'est ce dernier point qui fait qu'un « no me llegó mi compra » atteint une fiche rédigée en français. Sur OriusBot, tout ce calcul se fait sur l'infrastructure d'Orius : aucun message de ticket n'est transmis à un fournisseur d'IA extérieur, et il n'y a aucune clé d'API à fournir.

Régler la confiance sans deviner

Chaque correspondance reçoit un score. Sous un seuil, le bot considère qu'il n'a pas compris. Ce seuil est le seul réglage qui compte vraiment, et il se règle dans les deux sens :

• Trop bas : le bot répond à côté. Le membre repart avec une fausse réponse et n'insiste pas — c'est le pire des cas, parce qu'il ne se voit pas.
• Trop haut : il appelle l'équipe pour des questions qu'il aurait su traiter, et ne sert plus à rien.

Autour de 42 % convient à la plupart des serveurs. Mais ne réglez pas à l'aveugle : un banc d'essai permet d'éprouver une question sans toucher à un vrai ticket, et montre la reformulation que le bot a réellement cherchée. C'est cette ligne qui explique un résultat surprenant, bien mieux qu'un pourcentage.

Passer la main proprement

Un assistant se juge autant sur ses échecs que sur ses réussites. Quand il appelle l'équipe, il ne se contente plus d'une mention de rôle : il joint une fiche de passation. La demande d'origine — celle que le membre a formulée librement, avant qu'on lui demande de reformuler —, le point exact où ça a bloqué, ce qui a déjà été répondu, et de quoi juger le ton : ancienneté du compte, arrivée sur le serveur, avertissements actifs.

Redire ce qui vient d'être dit est la façon la plus rapide de perdre quelqu'un. Le membre lit cet encadré, puisqu'il est dans son salon : on n'y écrit donc aucun score, aucun numéro de fiche, rien qu'on ne lui dirait pas en face.

Deux réglages complètent l'escalade. Le délai de réponse habituel est annoncé au membre — mesuré sur vos propres tickets pris en charge, jamais saisi à la main : un délai déclaré est faux dès le lendemain, et il est faux dans le sens qui fâche. Rien n'est annoncé tant qu'il y a moins de cinq mesures sur trente jours. Et vos horaires de permanence, déclarés jour par jour dans le fuseau de votre serveur, permettent au bot de dire que l'équipe n'est pas là et quand elle revient. Un membre qui écrit à 3 h du matin et ne reçoit rien pendant six heures ne conclut pas « ils dorment » : il conclut « ils s'en fichent ».

Le cas des questions jumelles

Un score élevé ne dit pas laquelle des fiches répond. Si le serveur a « Comment acheter le grade VIP ? » et « Comment acheter le grade MVP ? », la demande « comment acheter un grade » correspond aux deux — également.

Trancher au hasard revient à répondre faux une fois sur deux. Le bon comportement est de demander, en proposant les candidates. C'est l'écart entre les deux meilleures fiches qui déclenche cette question, pas le score.

Ce que l'assistant rate, et pourquoi c'est précieux

Il ratera des questions. Toujours. Ce qui compte, c'est de le savoir : chaque question restée sans réponse est journalisée, avec le meilleur score obtenu.

Cette liste est la matière première de votre base. Elle contient les questions réelles de vrais membres, dans leurs mots — la meilleure formulation possible pour une nouvelle fiche, et une que vous n'auriez pas inventée. Un quart d'heure par semaine à la relire fait plus pour la couverture que deux heures à imaginer des questions à l'avance.

Savoir si tout cela sert à quelque chose

Le journal des manques dit ce qui rate. Il ne dit rien de ce qui marche — et c'est pourtant la seule question qui reste après une soirée passée à écrire des fiches. On se souvient des trois fois où le bot a répondu à côté, jamais des soixante fois où il a réglé la question tout seul, et on finit par éteindre un module qui fonctionnait.

Le panneau affiche donc deux chiffres sur trente jours : la part de tickets réglés sans appeler l'équipe, et la part de réponses jugées utiles par les membres eux-mêmes. Sous cinq tickets, aucun pourcentage n'est affiché : un taux calculé sur deux mesures est un chiffre faux qu'on retient quand même.

Questions fréquentes

Le bot peut-il inventer une réponse ?

Non. Il ne rend que des réponses écrites par le serveur, telles quelles. Il choisit laquelle ; il n'en rédige aucune. C'est une limite volontaire — un assistant qui improvise sur les règles d'un serveur crée des litiges au lieu d'en éviter.

Faut-il écrire les fiches dans les quatre langues ?

Non. Une fiche par question, dans la langue du serveur, plus quelques reformulations dans les autres langues si votre communauté est internationale. Le lexique d'intentions rattrape une bonne part du reste.

Que se passe-t-il si aucune fiche n'est écrite ?

L'assistant reste muet, et refuse même de s'activer. Un accueil qui promet une aide impossible à rendre vaut moins que le silence.

Le membre sait-il qu'il parle à un robot ?

Oui, et il doit le savoir. L'assistant se présente comme tel à l'ouverture, et chaque réponse porte la mention qu'elle est automatique. Laisser croire à un humain se retourne toujours contre le serveur.

À lire ensuite : le système de tickets, le planning de l'équipe, le CRM de staff.