19 — Connaissance et QA

1. Objectif métier

Fournir une base de vérité exploitable par l’équipe et les automatisations, pour répondre vite et juste aux clients.

Ce module couvre deux piliers complémentaires:

la base de connaissance (sources, traitement, recherche),
les parcours Q&A guidés (modules, thèmes, questions, choix).

Résultat attendu: des réponses plus cohérentes, moins d’escalades inutiles, et une meilleure continuité entre IA et opérateurs.

2. Qui utilise ce module (admin/operator)

admin: construit et gouverne la connaissance, structure les parcours Q&A, active les modules.
operator: exploite la connaissance validée, remonte les manques et les ambiguïtés observées en conversation.

Répartition recommandée:

admin propriétaire du contenu,
opérateur capteur terrain,
boucle d’amélioration hebdomadaire entre les deux.

3. Prérequis

Checklist avant déploiement:

propriétaire de contenu nommé pour chaque domaine,
périmètre prioritaire défini (top 20 questions clients),
politique de mise à jour (fréquence, validation, archivage),
format éditorial des sources harmonisé,
stratégie de relais opérateur en cas de réponse incertaine.

Contraintes métier à respecter:

le nom de source doit être unique par organisation,
le type de source doit correspondre à son contenu,
seules les sources prêtes (ready) alimentent la recherche,
un choix Q&A doit soit mener à une question valide, soit terminer par une réponse finale,
un module Q&A activé doit être entièrement testé avant diffusion large.

4. Procédure pas-à-pas (orientée actions produit)

Définir les usages prioritaires.

FAQ produit/service.
livraison/retour/remboursement.
rendez-vous et disponibilité.
support incidents fréquents.

Créer les sources de connaissance.

Ajouter des sources text pour démarrer rapidement.
Ajouter des sources url pour les pages officielles.
Ajouter des sources pdf pour les référentiels complets.
Ajouter des sources google_sheet pour des contenus vivants partagés.

Lancer le traitement des sources.

Vérifier le passage pending -> processing -> ready.
Corriger immédiatement les sources en failed.

Contrôler la qualité de recherche.

Tester avec des formulations client réelles.
Tester fautes, formulations courtes et formulations longues.
Vérifier que les réponses renvoient les bons contenus.

Ajuster les contenus.

Réécrire les paragraphes trop longs.
Supprimer les informations contradictoires.
Datation explicite des politiques sensibles.

Construire les modules Q&A.

Créer un module par besoin métier majeur.
Créer des thèmes lisibles.
Créer des questions courtes.
Ajouter des choix orientés décision.

Connecter les embranchements Q&A.

Soit vers la question suivante.
Soit vers une réponse finale claire.
Éviter les chemins qui tournent en boucle.

Activer progressivement.

Tester en interne avec 10 cas minimum.
Activer sur un périmètre réduit.
Étendre après validation qualité.

Mettre en place la maintenance continue.

revue hebdomadaire des retours opérateurs,
resynchronisation dès changement de politique métier,
retrait des sources obsolètes,
revue mensuelle de tous les modules Q&A actifs.

5. Scénarios concrets (minimum 2)

Scénario A: mise à jour politique de livraison. Objectif: éviter les réponses contradictoires. Action: mise à jour de la source, resynchronisation, re-test sur 10 questions. Résultat attendu: réponses alignées avec la nouvelle politique en moins de 24h.
Scénario B: arbre Q&A pour demandes de retour. Objectif: orienter le client sans surcharge opérateur. Action: module Retours, thèmes par motif, questions successives, sortie finale adaptée au cas. Résultat attendu: parcours guidé cohérent et réduction du temps de traitement.
Scénario C: recherche insuffisante sur sujet sensible. Objectif: sécuriser la qualité de réponse. Action: escalade vers opérateur + enrichissement de la base + nouveau test. Résultat attendu: amélioration mesurable au cycle de revue suivant.

6. Erreurs fréquentes et résolution

Erreur: source bloquée en échec. Cause fréquente: contenu inaccessible, format inadéquat ou texte inexploitable. Résolution: corriger la source, relancer le traitement, revérifier l’état final.
Erreur: réponses peu pertinentes. Cause fréquente: contenu trop vague ou mal structuré. Résolution: réécrire en blocs courts, concrets, orientés questions client.
Erreur: Q&A bloqué en milieu de parcours. Cause fréquente: choix pointant vers une question invalide. Résolution: corriger le lien de branche et retester tout le parcours.
Erreur: contradictions entre deux sources. Cause fréquente: doublons documentaires non gouvernés. Résolution: définir une source maîtresse et archiver l’ancienne.
Erreur: module activé trop tôt. Cause fréquente: activation sans recette complète. Résolution: retour en supervision opérateur et requalification du module.

7. Bonnes pratiques et limites

Bonnes pratiques:

écrire pour le client final, pas pour l’équipe interne,
privilégier des paragraphes courts et actionnables,
limiter une source à un thème principal,
nommer les modules Q&A avec une intention explicite,
tracer chaque mise à jour de contenu sensible.

Limites à connaître:

le traitement des sources n’est pas instantané,
seules les sources ready sont consultables,
un parcours Q&A trop complexe réduit le taux de complétion,
la qualité dépend fortement de la discipline éditoriale continue.

8. Référence rapide (champs/statuts/modes)

Types de source:

pdf,
url,
text,
google_sheet.

Statuts de traitement:

pending: source créée, en attente.
processing: traitement en cours.
ready: source prête pour la recherche.
failed: traitement en échec.

Objets Q&A:

module: conteneur principal activable.
thème: regroupement par sujet.
question: point de décision.
choix: orientation vers une suite ou réponse finale.

Repères d’exploitation:

toujours tester après une resynchronisation,
toujours prévoir une sortie opérateur sur les cas non couverts.