Configuration des modules
Knowledge gaps
Comment Gfacility repère un article manquant : une recherche sans aucun résultat, enregistrée comme un comportement, regroupée par sujet et visible seulement lorsque deux utilisateurs différents butent sur la même chose.
Mis à jour le 14 août 2026
Configuration · Modules · Base de connaissances
La plupart des bases de connaissances échouent en silence. Personne ne crée un ticket disant “votre documentation n’a pas de page sur le mot de passe VPN” : les gens cherchent, ne trouvent rien, et demandent à un collègue. Les knowledge gaps transforment ce moment invisible en moment mesurable. Chaque recherche dans Gfacility qui ne renvoie aucun résultat est enregistrée, et dès que suffisamment de personnes butent sur le même sujet, celui-ci apparaît sur une liste de priorités pour vos rédacteurs.
Le déclencheur est un comportement, pas un jugement. Une lacune apparaît parce qu’une recherche n’a donné aucun résultat, pas parce qu’une IA estime que la réponse n’était pas assez bonne.
Qu’est-ce qui compte comme lacune ?
Zéro résultat, mesurable
Le déclencheur est objectif et reproductible : la recherche n'a rien donné. Aucun modèle ne note la qualité d'une réponse.
Un problème partagé, pas un individu
Au moins deux utilisateurs différents doivent rencontrer le même sujet avant qu'il ne devienne visible comme lacune.
Bruit filtré
La frappe lettre par lettre, les recherches répétées et les fautes de frappe sont fusionnées, pour que la liste montre des sujets et non des frappes clavier.
Une liste, pas un processus
Aucun ticket n'est créé, aucun workflow ne démarre. Vous obtenez un backlog priorisé de sujets à documenter.
Où une recherche infructueuse est enregistrée
Trois endroits dans Gfacility enregistrent un échec, en temps réel :
Barre de recherche de la base
La barre dans laquelle les utilisateurs cherchent eux-mêmes un article.
Panneau de recherche et chat IA
Le champ de recherche du panneau et du chat IA, où les questions sont posées en langage naturel.
"Pas utile"
Un retour explicite sur un article affiché : la réponse existait, mais elle n'a pas aidé.
Le processus en six étapes
| Étape | Ce qui se passe |
|---|---|
| 1. Enregistrement | En temps réel. Une recherche sans résultat, dans la base ou dans le panneau / chat IA, est enregistrée comme un échec, tout comme un retour explicite "pas utile" sur un article. |
| 2. Normalisation | Le texte recherché est nettoyé : ponctuation retirée, mise en minuscules, mots vides supprimés. Ce qui reste sous trois caractères est ignoré. |
| 3. Réduction du bruit | Le même utilisateur qui cherche le même terme dans les dix minutes ne crée pas une deuxième ligne. La saisie progressive (lettre par lettre) est reconnue et fusionnée en une seule recherche. |
| 4. Regroupement | Au moment du rapport, fautes de frappe et variantes d'un même sujet sont fusionnées par correspondance approximative sur la similarité du texte : "reinitialiser mot de passe vpn" et "reinitialiser mot de passe" comptent pour la même lacune. |
| 5. Seuil de confidentialité | Ce n'est qu'à partir de deux utilisateurs différents confrontés au même problème que la lacune devient visible. Un individu qui se trompe de saisie ne compte pas, et les recherches anonymes ne comptent jamais. |
| 6. Résultat | Une liste de priorités : quels sujets manquent clairement de documentation, à quelle fréquence, et quels termes exacts ont été saisis. |
Privacy by design
Le seuil de l’étape 5 est le cœur de la conception, pas un détail technique. Une recherche isolée dit quelque chose sur une personne ; la même recherche par deux personnes différentes dit quelque chose sur votre documentation. Gfacility ne remonte que le second cas.
Minimum deux utilisateurs
Sous le seuil, rien n'est affiché : le rapport ne peut jamais se lire comme l'historique de recherche d'un collègue.
Recherches anonymes exclues
Une recherche sans utilisateur connu ne peut pas compter, car il est impossible d'établir qu'il s'agit de deux personnes différentes.
Ce que reçoivent vos rédacteurs
Le résultat est volontairement minimal : pas de ticket, pas de workflow, pas de chaîne d’approbation. Juste les trois éléments nécessaires pour décider quoi écrire ensuite.
Sujet
Le sujet regroupé que les gens cherchaient sans le trouver.
Fréquence
À quelle fréquence cela arrive, pour écrire d'abord la plus grande lacune plutôt que la demande la plus insistante.
Termes exacts
Les mots réellement saisis, donc les mots que le nouvel article doit reprendre dans son titre et ses tags.
Ces termes sont la partie pratique : un article rédigé avec les formulations de vos collègues sera trouvé par les règles de correspondance décrites dans 4.2 Base de connaissances, et remontera automatiquement la prochaine fois que quelqu’un créera un ticket à ce sujet.
Quelles décisions allez-vous prendre ?
Qui relit la liste, et à quelle fréquence ?
Un moment fixe (chaque mois, ou chaque sprint) vaut mieux qu'un coup d'oeil ponctuel : la fréquence ne devient parlante que sur une période.
Écrire un article ou corriger la trouvabilité ?
Si le contenu existe déjà, ajouter la formulation recherchée comme tag est souvent la solution la plus rapide.
Dans quelle langue cherche-t-on ?
Les termes de recherche le montrent. Dans les équipes internationales, c'est l'argument pour une traduction plutôt qu'un nouvel article.
Quelles lacunes ne comblez-vous pas ?
Certaines recherches pointent vers un tout autre système. Documenter cette frontière une fois est aussi une réponse.