Comment entraîner un modèle d'IA sur vos tickets de support pour de meilleures FAQ

Vous pouvez entraîner un modèle d'IA sur vos tickets de support en les convertissant d'abord en un jeu de données question-réponse propre, puis en affinant un modèle transformer pré-entraîné — comme BERT ou une variante de T5 — à l'aide de ce jeu de données. Le processus fonctionne mieux lorsque vous étiquetez chaque ticket comme une question et une réponse vérifiée, et il ne nécessite généralement pas de code complexe si vous utilisez une plateforme dotée d'une interface d'affinage (fine-tuning). En pratique, la plupart des équipes exportent les tickets, suppriment les données personnelles, créent un fichier JSON de questions-réponses, puis exécutent quelques époques d'entraînement sur un service de modèle hébergé.

Ce dont vous avez besoin avant de commencer

Avant de toucher à vos tickets, rassemblez le matériel brut et choisissez un environnement d'entraînement. Vous aurez besoin de :

• Un export des tickets de support résolus avec les horodatages et les réponses des agents.
• Un accès à un éditeur de texte ou à un script simple pour nettoyer les données.
• Un outil d'étiquetage — les feuilles de calcul fonctionnent très bien pour les petits jeux de données.
• Un compte auprès d'un service d'affinage de modèles (Hugging Face, Azure AI, Google Cloud ou une plateforme dédiée).
• Un petit ensemble de test de tickets que vous n'utiliserez pas pendant l'entraînement.

La condition préalable la plus importante est le volume. Vous voulez au moins quelques centaines de tickets clairement résolus ; des milliers, c'est encore mieux. Si vous en avez moins, un modèle personnalisé risque de ne pas surpasser une page FAQ bien rédigée.

Étape 1 – Exporter et inventorier vos tickets

Récupérez tous les tickets résolus depuis votre logiciel de service client. Recherchez des champs tels que l'objet, la description initiale, le fil de conversation et la note de résolution finale. De nombreux outils permettent d'exporter directement en CSV ou JSON.

Créez une feuille de calcul simple avec les colonnes : ticket_id, customer_question, agent_answer, category et resolution_status. Si un ticket comporte plusieurs échanges, vous devrez isoler la question originale et la réponse finale qui l'a résolue.

Ne vous souciez pas encore de la perfection. L'objectif est d'obtenir une liste brute que vous pourrez filtrer et étiqueter.

Étape 2 – Nettoyer les PII et normaliser le texte

Cette étape n'est pas négociable. Supprimez les noms, adresses e-mail, numéros de téléphone et tout identifiant de compte du texte du ticket. Même si votre modèle est interne, l'entraînement sur des PII (informations personnellement identifiables) crée un risque juridique et peut entraîner une fuite de données sensibles ultérieurement.

Utilisez un script simple pour trouver et remplacer les modèles courants. Ensuite, normalisez l'orthographe et la ponctuation : développez les contractions (« n'est pas » au lieu de « n'est »), corrigez les fautes de frappe et convertissez tout en minuscules si votre modèle l'exige.

Supprimez les tickets en double. Si deux clients ont posé exactement la même question et ont reçu la même réponse, gardez un exemple et notez-le comme une paire à haute confiance.

Étape 3 – Étiqueter les paires question-réponse

Maintenant, transformez les tickets nettoyés en un jeu de données supervisé. Pour chaque ticket, déterminez ce que le client a réellement demandé et quelle devrait être la réponse de l'agent. Parfois, la question originale se trouve dans l'objet ; parfois, vous devez la déduire du fil de discussion.

Créez un fichier CSV ou JSON avec deux champs principaux : question et answer (réponse). Ajoutez éventuellement un champ category pour le filtrage, comme « facturation », « configuration » ou « dépannage ».

Une erreur courante consiste à utiliser l'intégralité de la réponse de l'agent comme réponse. Rédigez plutôt une réponse concise qu'un agent de support utiliserait comme modèle. Si un ticket contient plusieurs questions, divisez-le en entrées distinctes.

Étiquetez suffisamment d'exemples pour couvrir les sujets les plus fréquents dans votre file d'attente de tickets. Visez au moins 200 à 300 paires, et plus si vous avez le temps.

Étape 4 – Choisir un modèle et l'affiner

Vous avez deux voies pratiques. La première consiste à affiner un transformer léger comme BERT ou RoBERTa pour classer une question et récupérer la meilleure réponse de votre jeu de données. La seconde consiste à affiner un modèle génératif comme T5 ou GPT-2 pour produire une réponse directement.

Pour la plupart des tâches de pertinence de FAQ, une approche basée sur la récupération est plus simple et plus prévisible. Vous intégrez (embed) à la fois les questions et les réponses, puis vous entraînez le modèle à classer la bonne réponse plus haut que les mauvaises. Les modèles génératifs sont meilleurs pour les questions ouvertes mais plus difficiles à contrôler.

Si vous utilisez un service hébergé, le flux de travail est généralement le suivant : téléchargez votre fichier JSON, sélectionnez un modèle de base, choisissez le nombre d'époques d'entraînement et lancez le travail. La plateforme gère les calculs. Si vous préférez le code, des bibliothèques comme Hugging Face Transformers vous donnent un contrôle total.

Gardez votre ensemble d'entraînement séparé de votre ensemble de validation. Utilisez 80 % pour l'entraînement et 20 % pour les tests.

Étape 5 – Évaluer la pertinence de la FAQ

Après l'entraînement, testez le modèle sur les 20 % que vous avez mis de côté. Pour chaque question de test, vérifiez si le modèle renvoie la bonne réponse comme suggestion principale. Mesurez la précision à k=1, k=3 et k=5 — la fraction de questions de test où la bonne réponse apparaît dans ces premiers résultats.

Menez une petite étude utilisateur avec vos agents de support. Demandez-leur de noter la pertinence des réponses du modèle sur une échelle de 1 à 5. Un bon modèle devrait obtenir un score moyen supérieur à 4,0.

Si le modèle échoue sur certains sujets, ajoutez plus d'exemples étiquetés pour ces sujets et réentraînez. C'est l'étape que la plupart des équipes sautent, et c'est pourquoi leurs pages FAQ semblent encore génériques.

Étape 6 – Déployer et maintenir à jour

Une fois que le modèle fonctionne bien, intégrez-le à la recherche de votre centre d'aide ou à votre chatbot. Facilitez la tâche aux agents pour copier la réponse suggérée dans une réponse de ticket.

Mettez en place une boucle de rétroaction : laissez les utilisateurs voter pour savoir si la réponse a été utile. Collectez ces votes et ajoutez-les à votre prochain jeu de données d'entraînement. Réentraînez tous les mois ou tous les deux mois, car votre produit et les questions des clients changent.

Mettez également à jour vos pages FAQ avec les paires à haute confiance que le modèle fait ressortir. Cela vous donne le double avantage d'une meilleure IA et d'un meilleur contenu statique pour le SEO.

Limites et cas où ces conseils ne s'appliquent pas

L'entraînement sur des tickets de support n'est pas la solution idéale pour toutes les équipes. Si vous avez moins de 100 paires utilisables, une FAQ organisée manuellement surpassera un modèle affiné. Si vos tickets sont chaotiques, avec de longs fils d'e-mails et aucune résolution claire, le coût de l'étiquetage peut dépasser les avantages.

La méthode suppose également que vos tickets sont dans la langue que vous souhaitez servir. Si vous avez besoin de FAQ multilingues, vous avez besoin soit de données parallèles, soit d'un modèle doté d'une forte capacité interlingue, ce qui est plus difficile à affiner.

Enfin, un modèle entraîné sur des tickets historiques reflétera les problèmes passés, pas les futurs. Il ne sera d'aucune aide pour une toute nouvelle fonctionnalité tant que les clients ne commenceront pas à poser des questions à ce sujet et que vous n'aurez pas ajouté de nouveaux exemples.

Faits clés sur la génération de FAQ par IA

Les faits suivants proviennent des documents publiés par SeaText sur la façon dont l'IA peut améliorer la pertinence des FAQ. Il ne s'agit pas d'affirmations sur vos données spécifiques, mais ils décrivent le problème et une approche courante.

Questions fréquemment posées

Quel type de modèle fonctionne le mieux pour la pertinence des FAQ ?

Pour la plupart des équipes, un modèle basé sur la récupération comme BERT, affiné sur des paires question-réponse, est un bon début. Il renvoie la réponse la plus probable à partir de votre contenu existant, ce qui est facile à vérifier. Les modèles génératifs sont meilleurs lorsque vous devez créer des réponses à partir de zéro, mais ils sont plus difficiles à contrôler.

De quelle quantité de données ai-je besoin ?

Vous avez besoin d'au moins quelques centaines de paires question-réponse propres pour une base de référence fiable. Avec moins de données, vous constaterez un surapprentissage (overfitting). Si vous n'avez qu'une douzaine de tickets, une FAQ manuelle est plus rapide et plus sûre.

Que faire si mes tickets n'ont pas de réponses claires ?

Dans ce cas, l'étape d'étiquetage devient un projet de contenu, pas un projet de données. Vous devrez peut-être réécrire les réponses à partir de vos politiques ou de vos connaissances produit avant de pouvoir entraîner le modèle. Envisagez de n'utiliser que les tickets où le client a explicitement confirmé que la solution a fonctionné.

Puis-je utiliser un service cloud sans écrire de code ?

Oui. De nombreux fournisseurs vous permettent de télécharger un fichier JSON et de commencer l'affinage en quelques clics. Vous devez toujours préparer un jeu de données propre, mais vous n'aurez pas à écrire de scripts d'entraînement.

À quelle fréquence dois-je réentraîner ?

Réentraînez chaque fois que votre produit change de manière significative ou lorsque vous collectez quelques centaines de nouvelles paires étiquetées. Une cadence mensuelle convient à la plupart des équipes. Surveillez la dérive dans la formulation des questions.

Cette méthode fonctionne-t-elle pour les FAQ multilingues ?

Uniquement si vous entraînez sur des données multilingues. Si vos tickets sont en anglais et que vous avez besoin de réponses en français, vous aurez besoin de traductions parallèles. Certains systèmes de récupération basés sur des vecteurs gèrent plusieurs langues sans affinage explicite, mais testez-les.