Analyse des lacunes de connaissances du support : comment trouver ce qui manque à votre centre d'aide

Qu'est-ce qu'une analyse des lacunes de connaissances du support ?

Une analyse des lacunes de connaissances du support compare deux listes : ce que les clients demandent réellement à votre équipe de support et ce que votre base de connaissances répond réellement. L'écart, c'est votre liste de lacunes. Bien menée, elle aboutit à un backlog court et hiérarchisé d'articles à rédiger ou à corriger, pas à un tableur de 300 lignes que personne n'ouvre.

Je conçois des agents IA chez eesel, et ce travail a changé ma façon de penser les lacunes. Un agent IA lit votre centre d'aide plus attentivement que n'importe quel client, donc la première chose qu'il fait remonter n'est pas une réponse brillante. C'est chaque sujet pour lequel vos documents n'avaient rien, ou avaient la mauvaise information. C'est utile, car une lacune ressemble rarement à une page vide. Elle prend généralement l'une de ces trois formes.

• Manquante. Aucun article ne couvre le sujet. Ce sont les plus faciles à repérer et à corriger.
• Obsolète ou contradictoire. Un article existe, mais il indique l'ancien délai de remboursement, ou deux articles se contredisent. Gorgias en fait même un type distinct, "Resolve knowledge conflict", dans son flux Opportunities.
• Rédigée pour le mauvais lecteur. L'article est exact, mais il répond à la question de quelqu'un d'autre. Une responsable du support venue chez eesel depuis un service de suivi de bus, avec 200 à 250 tickets Zendesk par mois, a constaté que toute sa base de connaissances était écrite pour des administrateurs, alors que les tickets venaient de voyageurs. Toutes les réponses étaient là sur le papier, et aucune n'aidait.

Le troisième type est celui qu'un rapport de recherche ne vous montrera jamais, car la recherche du client renvoie bien un résultat. Simplement, ce n'est pas le bon. C'est pourquoi une analyse des lacunes doit regarder les tickets, pas seulement les recherches. J'ai traité l'approche par les seules recherches dans mon guide sur la correspondance entre requêtes de recherche et lacunes, et c'est un bon début. Ce n'est pas le tableau complet.

Pourquoi les recherches infructueuses sous-estiment vos lacunes

Les recherches infructueuses sont le signal classique des lacunes, et tous les guides commencent par là. Le problème, c'est qui elles comptent. Une recherche infructueuse n'existe que lorsqu'un client ouvre votre centre d'aide, tape une requête et n'obtient rien. Le client qui va directement au formulaire de contact, répond à un e-mail de commande ou ouvre le chat n'apparaît jamais dans ce rapport.

Help Scout est franc sur un autre angle mort. Son rapport Docs exclut les recherches faites depuis la barre de recherche Docs de l'éditeur de réponse et celles passant par l'API, si bien que les recherches infructueuses de vos propres agents ne comptent pas non plus. Des agents qui cherchent dans le centre d'aide en pleine résolution d'un ticket et ne trouvent rien, c'est l'un des signaux de lacune les plus forts que vous ayez, et il est invisible dans le rapport standard.

Les tickets racontent une histoire plus large. Dans l'exemple de rapport de la page d'aide sur le potentiel d'automatisation de Zendesk, le compte a analysé 5 791 conversations et en a signalé 719 comme lacunes de connaissances, soit plus que les 592 déjà couvertes par ses articles existants. C'est un compte de démonstration, pas une référence, mais le profil correspond à ce que je vois : la file de tickets contient plus de sujets sans réponse que le journal de recherche.

Les recherches infructueuses restent donc dans l'analyse. Elles deviennent simplement l'une des quatre entrées, chacune avec son propre angle mort.

Les quatre signaux à extraire

Chaque signal ci-dessous indique ce qu'il détecte, ce qu'il manque et où le trouver. Vous n'avez pas besoin des quatre dès le premier jour. Deux suffisent pour une première passe, à condition que l'un vienne des tickets.

1. Recherches sans résultat

C'est le client qui vous dit, avec ses propres mots, ce qu'il s'attendait à trouver. C'est excellent pour le vocabulaire : les clients cherchent "annuler" alors que votre article s'intitule "Gérer votre abonnement". Le guide de Help Scout pour corriger les recherches infructueuses suggère exactement cette correction : ajouter des mots alternatifs au champ Keywords d'un article ou rédiger un nouvel article lorsque le sujet n'est pas couvert.

Où le trouver :

• Zendesk : le tableau de bord Search préconfiguré a un KPI "Searches with no results" et un graphique du top 5, avec jusqu'à 390 jours de données, d'après son guide des résultats de recherche. Il exige un plan Suite, ou Support avec Knowledge Professional ou Enterprise.
• Help Scout : Reports, puis Docs, puis le tableau Failed searches. Les plans Standard conservent 2 ans de données ; Plus et Pro les conservent pendant toute la vie du compte.
• HubSpot : les analyses de la base de connaissances affichent "Search terms with no results" dans Service Hub Professional et Enterprise, selon le guide d'analyse de la base de connaissances de HubSpot.
• Gorgias : le rapport du Help Center a un KPI "No-result searches", et filtrer le tableau Search terms par "Has results is false" vous donne un backlog. Gorgias note aussi qu'un grand nombre de recherches sans résultat dans une langue signifie généralement que les articles n'ont jamais été traduits.
• Zoho Desk et Front : le tableau de bord de la base de connaissances de Zoho sépare les mots-clés en Popular et Failed. Le rapport de la base de connaissances de Front n'a pas d'étiquette "failed" : cherchez les mots-clés avec beaucoup de recherches et un nombre moyen de résultats faible.

Freshdesk fait exception. Je n'ai trouvé aucun rapport sur les recherches infructueuses dans les analyses de sa base de connaissances. Sur Freshdesk, ce signal implique donc d'ajouter vos propres analyses au centre d'aide ou de vous appuyer davantage sur les trois autres. Mon article sur les exemples de bases de connaissances Freshdesk couvre ce que ses rapports affichent réellement.

2. Sujets de tickets sans article

C'est le plus gros signal et celui que la plupart des équipes sautent, car cela voulait dire exporter les tickets et les étiqueter à la main. Si votre équipe utilise déjà de façon cohérente l'étiquetage des tickets, vous pouvez encore procéder ainsi : regroupez les tickets du dernier trimestre par étiquette, puis vérifiez si chaque étiquette principale a un article. Les étiquettes dérivent toutefois, donc je considérerais un rapport d'étiquettes monté à la main comme un point de départ. Mon guide sur le travail avec les étiquettes de tickets explique comment les nettoyer d'abord.

Les helpdesks ont rattrapé leur retard sur ce point. Le rapport de potentiel d'automatisation de Zendesk, lancé le 30 avril 2026, lit chaque semaine les 90 derniers jours de tickets résolus et les trie en "Covered by knowledge" et "Knowledge gaps", chaque sujet étant marqué à impact élevé, moyen ou faible. Survolez une lacune et cliquez sur Generate article draft. Il est inclus dans tous les plans Suite et Support, réservé aux administrateurs.

L'agent de base de connaissances de HubSpot, en bêta sur Service Hub Professional et Enterprise, analyse les tickets clos et suggère des brouillons "Create article" et "Update article". Il exige au moins cinq tickets clos et coûte 200 HubSpot Credits par article généré, ce qui compte quand Professional inclut 3 000 crédits par mois. Gorgias a une version plus lente appelée AI Library, qui suggère des articles tous les 3 à 6 mois selon le volume de tickets, en anglais uniquement. Zia Ticket to Article de Zoho transforme 1 à 10 conversations d'un seul ticket en brouillon, ce qui relève de la capture et non de la détection.

Ce que ce signal manque : les réponses qui vivent dans la tête de vos agents seniors. Si un agent expérimenté clôt de mémoire deux fois par semaine la même question délicate, les tickets paraissent résolus et le sujet peut sembler "couvert". Un responsable du support d'une société de services informatiques du secteur public a dit à l'équipe d'eesel qu'ils allaient perdre deux agents seniors cette année-là et voulaient mettre ce savoir par écrit avant leur départ. Aucun rapport de tickets ne l'aurait signalé. J'ai écrit davantage sur ce problème dans le transfert de connaissances du support offshore.

3. Questions auxquelles votre agent IA n'a pas pu répondre

Si un agent IA répond à une partie de votre file, c'est le signal le plus précis dont vous disposez. La recherche d'un client vous dit quels mots il a tapés. Une étiquette de ticket vous dit un sujet. Un agent IA qui a essayé et échoué vous dit la question exacte, les documents qu'il a consultés et qu'aucun ne contenait la réponse.

L'onglet Improve d'AI Agent Studio de Freshdesk en est un bon exemple. Selon son article d'aide, il produit deux types d'enseignements à partir des conversations que l'IA n'a pas résolues : "New content" quand aucun article ne couvre le sujet et "Edit content" quand il en existe un, mais obsolète ou trompeur. Chaque carte indique sur combien de tickets elle repose, pour que vous traitiez d'abord les plus gros. Freshdesk a proposé Improve à tous ses clients jusqu'au 30 septembre 2026 ; sa page de tarifs le range désormais sous Freddy AI Agent, avec les 500 premières sessions incluses puis 49 $ par tranche de 100.

Les autres :

• Gorgias Opportunities (bêta, tous les plans avec AI Agent) déclenche "Fill knowledge gap" quand AI Agent continue de transférer un sujet, avec le nombre de tickets et un export CSV des tickets concernés.
• L'agent client de HubSpot liste des "Coaching opportunities" avec un motif Knowledge et des types comme "Knowledge gap" et "Knowledge conflict", d'après son guide de performance.
• L'agent Support Specialist de Zoho Desk laisse un commentaire privé, "Stepped away from ticket due to lack of available help article", quand il n'en trouve pas, d'après la page des agents numériques de Zoho. Il n'y a pas de rapport, mais vous pouvez rechercher dans les tickets cette phrase exacte.
• Help Scout n'a pas de rapport de lacunes pour AI Answers. Sa page de bonnes pratiques vous renvoie à l'onglet Beacon Sessions et à la répartition d'Insights entre "Contact helped" et "Contact not helped", que vous examinez à la main.

Ce que ce signal manque : les mauvaises réponses données avec assurance. Un agent IA ne signale une lacune que lorsqu'il sait qu'il ne sait pas. Quand un article est vague, il peut répondre quand même. Une équipe de télématique automobile sur Zendesk s'inquiétait précisément de cela : son centre d'aide disait prendre en charge "tous les modèles", si bien qu'un bot confirmerait volontiers des modèles de voiture qu'elle ne prenait pas en charge. C'est une lacune de type obsolète ou erroné, et on l'attrape avec le signal quatre ou avec une simulation sur des tickets passés, pas avec un compteur de "sans réponse". La version plus large de ce risque, c'est l'hallucination de l'IA.

4. Signalements des agents sur les articles erronés ou obsolètes

Vos agents lisent des articles du centre d'aide toute la journée et savent lesquels sont faux. L'astuce est de leur permettre de le dire en un clic. Zendesk permet aux agents d'ouvrir le panneau Knowledge dans un ticket, de surligner un paragraphe et d'ajouter un commentaire, ce qui crée un ticket avec le lien de l'article et le ticket source, d'après son guide de signalement d'articles. Cela exige Suite Growth ou supérieur. Le hub AI replies de Front affiche les sources derrière chaque réponse de l'IA, avec des actions en ligne pour corriger le contenu obsolète ou incorrect réponse par réponse.

Si votre helpdesk n'a ni l'un ni l'autre, un canal Slack partagé ou une étiquette de ticket "KB fix" fonctionne très bien. Le format compte moins que l'habitude. La faiblesse de ce signal est que les agents cessent de remarquer les articles qu'ils ont appris à contourner, c'est pourquoi les nouvelles recrues sont vos meilleurs rapporteurs. Mon guide sur l'intégration des agents du support client suggère de faire de "signaler trois articles" une tâche de la première semaine.

Où chaque helpdesk affiche les lacunes de connaissances

Voici la comparaison côte à côte. Les prix des plans sont par agent ou par poste et par mois, facturés annuellement, d'après la page de tarifs de chaque éditeur.

Deux choses ressortent. D'abord, la colonne des signalements IA est nouvelle : presque tout a été lancé en 2026, donc si vous avez consulté les rapports de votre helpdesk pour la dernière fois il y a un an, regardez à nouveau. L'ancienne fonction Content Cues de Zendesk, qui suggérait des articles, a été supprimée le 1er mai 2025, et le rapport de potentiel d'automatisation en est le remplaçant. Ensuite, les fonctions de lacunes suivent l'IA. Freshdesk et Gorgias ne trouvent les lacunes issues des tickets que via leurs agents IA, donc une équipe qui n'en utilise pas obtient beaucoup moins.

Zendesk a aussi un knowledge copilot en accès anticipé sur Suite Professional et supérieur, avec des scores Coverage, Freshness et AI readability. Le score Freshness baisse pour les articles non mis à jour depuis six mois, ce qui est une vérification intégrée pratique pour le contenu obsolète. Si vous êtes précisément sur Zendesk, mes articles sur l'analyse des lacunes de connaissances dans Zendesk et la recherche des articles manquants dans Zendesk vont plus loin.

Comment réaliser une analyse des lacunes de connaissances du support en un après-midi

C'est la version que je mènerais avec une équipe de cinq à cinquante agents. Elle prend environ trois heures la première fois et moins d'une heure chaque mois ensuite.

Étape 1 : extraire 90 jours des quatre signaux

Quatre-vingt-dix jours, c'est assez long pour lisser une mauvaise semaine et assez court pour que les réponses n'aient pas changé. Exportez les recherches infructueuses, vos 30 principales étiquettes ou sujets de tickets, la liste des lacunes ou des questions sans réponse de l'agent IA et tous les signalements des agents. Mettez le tout dans une seule feuille avec une colonne pour la source.

Étape 2 : regrouper par sujet, pas par formulation

"Annuler l'abonnement", "arrêter mon forfait" et "comment je me désinscris" forment une seule lacune. Regroupez les lignes en sujets et additionnez les compteurs entre les sources. Un sujet qui apparaît dans trois des quatre signaux est réel. Un sujet qui n'apparaît que sous la forme de deux recherches infructueuses pour "bitcoin" ne l'est probablement pas. Si vous avez des centaines de lignes, un LLM est efficace pour cette étape de regroupement, à condition de vérifier ses regroupements.

Étape 3 : classer par volume et par fixité de la réponse

C'est là que la plupart des listes de lacunes déraillent. Les équipes classent uniquement par volume, puis rédigent un article pour "où est ma commande", auquel aucun article ne peut répondre, car la réponse est différente pour chaque client.

• Fort volume, même réponse à chaque fois : rédigez l'article en premier. Délais de remboursement, limites de plan, étapes de configuration. Un article ici peut clore des centaines de tickets par trimestre.
• Fort volume, exige des données de compte : ne rédigez pas de document. Le statut d'une commande, les dates de facturation et les modifications de compte demandent une connexion aux données ou une action, pas un article. Le propre guide d'optimisation des connaissances de Gorgias fait la même distinction : une skill quand les acheteurs demandent à l'agent de faire quelque chose, un article quand ils demandent une information.
• Faible volume, même réponse : une macro ou une courte entrée de FAQ suffit. Mon guide sur la création de macros à partir de tickets passés en parle.
• Faible volume, propre à chaque cas : laissez cela aux personnes. Tous les tickets ne doivent pas devenir du contenu.

Étape 4 : écrire pour la personne qui pose la question

Avant de rédiger, ouvrez cinq vrais tickets du sujet et lisez comment les clients le formulent. Utilisez leurs mots dans le titre. Vérifiez ensuite qui pose la question : le voyageur ou l'administrateur, l'utilisateur final ou le propriétaire du compte. L'équipe de suivi de bus citée plus haut n'avait pas besoin de plus d'articles. Elle avait besoin des mêmes réponses réécrites pour un autre lecteur.

L'agent de base de connaissances de HubSpot fait une version de cela automatiquement, en joignant les "Source conversations" derrière chaque suggestion. Quel que soit l'outil qui rédige l'article, gardez les tickets sources à côté du brouillon pendant que vous le modifiez.

Étape 5 : corriger les articles obsolètes et contradictoires dans la même passe

Les nouveaux articles attirent l'attention, mais un article erroné fait plus de dégâts qu'un article manquant, surtout quand un agent IA le lit. Pendant que vous êtes dans la feuille, prenez chaque élément "Edit content" ou "knowledge conflict" et corrigez ou supprimez l'ancienne version. Si deux articles répondent à la même question, fusionnez-les. Mon guide sur la détection du contenu obsolète du centre d'aide propose une checklist pour cela.

Étape 6 : revérifier les mêmes sujets après 30 jours

Bouclez la boucle. Un mois après la publication, vérifiez si le nombre de tickets du sujet, les recherches infructueuses ou les signalements de lacunes de l'IA ont baissé. Si ce n'est pas le cas, l'article existe mais n'est pas trouvé ou ne répond pas à la vraie question. Le rapport de Zendesk se met à jour chaque semaine, et les opportunités de Gorgias ne se mettent pas à jour quand vous modifiez les connaissances, donc comparez des données fraîches plutôt que d'attendre qu'un ancien élément disparaisse tout seul.

Une bonne mesure de résultat ici est votre taux de déflexion sur ce sujet, ou le taux de résolution de l'IA sur celui-ci. Mon guide de la déflexion des tickets explique comment la mesurer sans vous leurrer.

Ce que disent les équipes de support sur la recherche des lacunes

La version la plus rudimentaire de cette analyse reste l'une des meilleures que j'aie vues. Un responsable informatique sur Reddit a ajouté un champ obligatoire à chaque ticket clos et en a fait un rapport hebdomadaire de lacunes :

"I have two fields in my ticket resolutions that I draw from: Self Service Possible? Drop down menu with three options. Mandatory. Yes - KB Exists Yes - KB Needed No ... I run a report every Friday for any tickets that have either of the "Yes" answers selected and use that list to either make documentation tickets or notify Line Managers that their staff are raising tickets for well documented issues. Takes me about 15 minutes all in."

Commenter on r/ITManagers

Ce champ capture les signaux deux et quatre en un clic, et il fonctionne dans tout helpdesk qui prend en charge les champs de ticket personnalisés. L'idée que les analyses de recherche ne suffisent pas est plus ancienne que la plupart des outils actuels. Quelqu'un qui travaillait sur le centre d'aide de Dropbox l'a formulée sur Hacker News dès 2011 :

"Improving it is a bit more complicated than just getting analytics around how many hits on /help end up searching, reading help articles, and maybe filing tickets. There is a lot more needed to understand which areas of the help center aren't getting enough prominence, which topics are just missing..."

ivankirigin, Hacker News

Certaines équipes ont déjà monté elles-mêmes la version IA. Un administrateur Zendesk a créé une automatisation qui tente de répondre à chaque nouveau ticket à partir de la base de connaissances et, quand elle n'y arrive pas, rédige l'article manquant :

"If it can't it drafts me an article that would cover it, as well as tells me why."

u/Mjwild91, r/Zendesk

Et le côté obsolète du problème est souvent le plus difficile. Une équipe sur r/startups a décrit son centre d'aide prenant du retard entre iOS, Android et le web :

"I feel that a big part of the challenge is to track which legacy articles are broken by a new feature."

u/19Vicus90, r/startups

C'est un argument pour faire une brève vérification des lacunes après chaque version, et pas seulement une fois par trimestre.

Erreurs qui gâchent une analyse des lacunes de connaissances

• Traiter les recherches infructueuses comme la liste complète. Elles comptent les chercheurs, pas les clients. Associez-les toujours à un signal issu des tickets.
• Rédiger des articles pour des questions propres au compte. "Où est ma commande" demande une consultation, pas une page. En faire un article ajoute juste une page qui dit "contactez-nous".
• Ajouter sans jamais corriger. Un article obsolète qu'un agent IA cite avec assurance est pire qu'aucun article. Corrigez les conflits dans la même passe.
• Publier des brouillons d'IA sans les relire. Chaque outil du tableau ci-dessus enregistre des brouillons, et aucun ne connaît votre politique mieux que votre équipe. Relisez chaque brouillon face à ses tickets sources avant sa mise en ligne.
• Ne le faire qu'une fois. Les lacunes se rouvrent chaque fois que les tarifs, la politique ou le produit changent. Une vérification mensuelle des dix principaux sujets les détecte tôt.
• Ignorer les connaissances hors du centre d'aide. Les réponses dans Confluence, Google Docs, les fils Slack et les anciennes macros comptent aussi comme des connaissances. Si votre IA ou vos agents ne peuvent pas y accéder, ce sont des lacunes pour le client. Mon guide de la gestion des connaissances par l'IA pour les équipes de support explique comment les connecter.

eesel pour l'analyse des lacunes de connaissances du support

Si vous voulez que la liste de lacunes se construise toute seule, le plus simple est de laisser un coéquipier IA travailler la file et vous dire où il a buté. Le coéquipier IA pour helpdesk d'eesel s'intègre à Zendesk, Freshdesk, Gorgias, Front, Help Scout et les autres, apprend de votre centre d'aide, de vos macros, de vos tickets passés et de vos documents dans Confluence, Notion ou Google Drive, et rédige ou envoie des réponses. Chaque tâche à laquelle il ne peut pas répondre avec vos documents est enregistrée comme une lacune de connaissances.

La page Reports montre à quelle fréquence l'agent manquait de connaissances pour répondre, et comment cela évolue jour après jour. La documentation le dit simplement : "A knowledge gap is your agent telling you something is missing from your documentation." Ouvrez n'importe quelle tâche sur la page Activity et vous voyez ce qu'elle a cherché, ce qu'elle a trouvé et si elle a rencontré une lacune, ce qui vous permet de remonter d'une mauvaise réponse jusqu'au document qui l'a causée.

À partir de là, la skill Update knowledge base (listée comme KB Auto-updater sur la page Skills) trouve les questions auxquelles votre centre d'aide ne répond pas et rédige les articles manquants pour que votre équipe les relise. Elle s'active par espace de travail ; si la tuile indique "Contact us", l'équipe d'eesel l'active pour vous. Vous pouvez aussi lancer une simulation sur vos tickets passés avant la mise en production, qui note chaque réponse par rapport à ce que votre équipe a réellement envoyé et liste les lacunes par thème de ticket.

Une équipe B2B SaaS sur Front, avec environ 200 à 300 tickets par mois en anglais et en français, a demandé à eesel précisément cette association : des réponses tirées de leur guide utilisateur, de Slack, de leur base de connaissances interne et de tickets passés, plus la détection des lacunes et des articles rédigés pour tout ce qui manquait. Pour être clair sur le périmètre : eesel n'est ni un éditeur de centre d'aide ni un outil d'analyse de recherche, gardez donc le rapport de recherches infructueuses de votre helpdesk pour le signal un. Ce qu'il ajoute, c'est le signal trois, sur chaque ticket, sans que personne n'ait à étiqueter quoi que ce soit. Les plans commencent à 299 $ par mois pour 500 crédits sur la page de tarifs, et vous pouvez essayer eesel gratuitement avec 100 crédits sur vos propres tickets.