Assistant support interne : répondre avec les bonnes sources et un budget maîtrisé

Un assistant de support interne peut retrouver une procédure, expliquer une règle ou orienter une demande. Mais une réponse rapide ne vaut rien si elle s'appuie sur un document auquel la personne n'a pas accès, masque une incertitude ou coûte plus cher à chaque relance. L'objectif n'est pas de « répondre à tout », mais de résoudre davantage de demandes admissibles avec des sources autorisées et un coût vérifiable.

Prenons un scénario illustratif, ni client réel ni résultat mesuré : une entreprise veut aider ses salariés sur les outils, les achats et les congés. Les demandes arrivent par portail et messagerie ; les réponses sont dans plusieurs espaces documentaires, soumis à des droits différents. Le pilote doit réduire les recherches répétitives sans remplacer les personnes qui interprètent les exceptions.

Concevez ensemble le périmètre documentaire, l'accès, la décision de répondre ou d'escalader et la mesure économique. Comme dans les patterns de RAG enterprise, la valeur se mesure ici à la demande résolue, pas au chunk retrouvé ni au message généré.

Commencer par les demandes, pas par le modèle

Avant de connecter un corpus, échantillonnez des demandes récentes et anonymisez-les selon les règles internes. Regroupez-les par intention — retrouver une information, comparer, diagnostiquer, demander une décision ou signaler une situation individuelle — puis faites valider les catégories par les équipes support. Une question peut cacher un accès manquant, une exception ou une action.

Choisissez quelques intentions fréquentes, couvertes par une source maintenue et dont l'erreur est réversible. Exemple : questions de niveau 1 sur un outil interne, en heures ouvrées, en lecture seule pour les salariés authentifiés ; transfert au support si une procédure manque. Excluez les décisions individuelles RH, conseils juridiques, changements d'accès, urgences et écritures non approuvées.

Écrivez des critères d'entrée et de sortie applicables par le métier. Une demande est « admissible » si son intention est au catalogue, l'utilisateur authentifié et une source approuvée disponible. Elle est « résolue » seulement si l'utilisateur confirme la réponse ou si un résultat métier est vérifié, par exemple le bon ticket créé. Une réponse affichée n'est pas une résolution.

Définissez aussi population, langues, canaux, horaires, propriétaires des sources, conservation des traces et responsable du service. Ce contrat empêche d'étendre silencieusement le pilote à des sujets plus risqués parce que le modèle « sait répondre ».

Une réponse n'est pas une résolution

Comptez une demande close avec confirmation ou résultat métier vérifié, pas un message généré ni une citation affichée.

Sources et droits : ne pas créer un corpus parallèle

L'assistant n'a pas besoin d'indexer toutes les connaissances internes. Il lui faut des sources gouvernées : propriétaire identifié, statut, date de révision, audience autorisée et mécanisme de retrait. Une FAQ en vigueur vaut mieux qu'une archive aux versions contradictoires.

Reliez chaque source à son système de référence et à ses règles d'accès. Établissez l'identité et les groupes de l'utilisateur, puis appliquez les autorisations avant d'envoyer des extraits au modèle. Un prompt « ne révèle pas les informations confidentielles » ne fait pas respecter les ACL. Retirez du retrieval les documents expirés ou dont les droits ne sont plus synchronisés ; vérifiez cette synchronisation et traitez ses erreurs explicitement.

La réponse doit citer un passage précis et lier la source originale. Distinguez les affirmations sourcées des reformulations. En cas de conflit, d'obsolescence ou de couverture trop générale, dites-le et routez vers une personne. Un score de similarité ne prouve pas la justesse : vérifiez les extraits et les réponses sur des demandes représentatives.

Les recommandations de la CNIL sur les systèmes d'IA invitent à intégrer la protection des données dès le projet. Examinez finalités et base juridique avec le DPO ; minimisez les données des requêtes et logs, informez les salariés, restreignez l'accès aux traces, fixez leur conservation et prévoyez l'exercice des droits. Une demande peut contenir des données personnelles : ne les envoyez pas automatiquement à chaque composant.

Autoriser avant de chercher

L'identité et les ACL de la source gouvernent le retrieval ; le modèle ne doit jamais être le contrôle d'accès.

Router par tâche et assumer les limites

Toutes les demandes ne nécessitent pas le même modèle ni la même autonomie. Une recherche factuelle courte peut se contenter d'un retrieval ciblé ; une comparaison de procédures exige plusieurs sources et parfois une revue. Une demande d'action — modifier un accès, valider un achat, changer une donnée RH — relève d'un workflow contrôlé, pas d'une simple conversation.

Routez selon l'intention, la sensibilité, les sources disponibles, la confiance et le coût maximal. Limitez tentatives, contexte et outils. N'escaladez pas automatiquement vers un modèle plus cher jusqu'à obtenir une réponse : après une recherche infructueuse ou des sources contradictoires, le support est souvent la meilleure option.

Définissez « confiance insuffisante » : source autorisée absente ou ancienne, citations hors sujet, question hors catalogue, conflit ou résultat invérifiable. Expliquez simplement la prochaine étape plutôt qu'un score abstrait. Sous réserve de confidentialité, préremplir un ticket avec la question et les sources évite de faire répéter l'historique.

Pour l'escalade, nommez une file propriétaire, transmettez le contexte minimal avec son motif (source, exception, risque, panne) et fixez horaires et délais. Prévoyez la reprise d'une conversation et un mode dégradé si un composant tombe. Ne déclarez pas la demande résolue si une personne doit encore statuer.

Le NIST AI Risk Management Framework structure l'identification, la mesure et le traitement des risques. Utilisez-le comme cadre, non comme certification : testez les fuites et erreurs avec des profils différents, assignez les corrections et gardez une option de désactivation.

Organiser un pilote qui apprend sans élargir le risque

Un pilote utile compare le parcours assisté au processus actuel sur des demandes de même catégorie. Avant l'ouverture, établissez une baseline : volume et délai de traitement, transferts, réouvertures et temps moyen du support, avec les limites de cette mesure. Démarrez ensuite en mode « observation » ou lecture seule : l'équipe support voit les réponses proposées, les vérifie et indique si elle les aurait acceptées. Cette étape permet d'examiner les erreurs sans présenter d'abord une réponse non vérifiée comme une consigne officielle.

À mesure que les réponses passent les contrôles, ouvrez un sous-ensemble d'intentions à un petit groupe représentatif. Gardez une voie simple vers un humain et recueillez des retours qualifiés, pas seulement un pouce levé : réponse correcte, source inadaptée, document manquant, question ambiguë, ou réponse correcte mais inutilisable. Chaque catégorie doit avoir une suite assignée. Un document manquant revient à son propriétaire ; une mauvaise ACL à la DSI ; une ambiguïté répétée au métier qui précise le catalogue.

Convenez des seuils de poursuite avant d'observer les résultats : qualité des citations, escalades appropriées, absence de fuite en test, coût maximal et capacité support disponible. Décidez à dates prévues de continuer, corriger, maintenir le périmètre ou arrêter.

Mesurer le coût par demande effectivement résolue

Le coût par demande résolue est une métrique opérationnelle, pas une promesse d'économies. Définissez la formule avec Finance et le support avant de comparer le pilote à la situation de départ :

Coût complet du périmètre sur la période ÷ demandes admissibles résolues sur cette période.

Incluez les coûts imputables : licences ou consommation modèle, recherche, stockage, connecteurs, gateway, observabilité, infrastructure, intégration amortie, maintenance, support et revue humaine. Présentez séparément les coûts communs selon une règle explicite. Évitez le double compte sans traiter l'exploitation comme gratuite.

Comptez les demandes uniques admissibles et résolues, pas les messages. Une demande peut générer plusieurs essais, recherches, outils ou transferts, qui consomment tokens et temps support. Gardez ces événements visibles, dédupliquez les relances du même dossier et fixez une fenêtre de résolution adaptée au processus.

Suivez admissibilité, résolutions confirmées, transferts, réouvertures, réponses corrigées ou rejetées, qualité des citations, revue humaine, latence et coût modèle. Segmentez par catégorie et équipe : une moyenne peut masquer des exceptions qui absorbent le budget.

Le « temps économisé » est délicat : mesurez le traitement avant et pendant le pilote avec la même définition, et distinguez le temps retiré de celui déplacé vers une revue. L'accès facilité peut aussi augmenter le nombre de questions. Présentez ces effets séparément des dépenses ; une estimation n'est pas une économie réalisée.

Pour rendre le calcul réplicable, gardez un registre par identifiant de demande (pseudonymisé si nécessaire), avec dates d'entrée et de clôture, catégorie, nombre de tentatives, tokens ou unités facturées, minutes de revue, résultat et motif de transfert. Ce registre n'a pas à conserver tout le texte conversationnel : séparez les données nécessaires au support des événements de mesure et appliquez les règles de conservation établies. Finance peut rapprocher les agrégats d'usage avec les factures ; le métier peut vérifier que les demandes marquées résolues le sont réellement. Ainsi, un écart de facture devient investigable sans exposer plus de contenu que nécessaire.

Fixez un budget périodique et un plafond par demande ou catégorie. Alertez avant dépassement, limitez les tentatives et suspendez proprement l'automatisation à la limite. Examinez les cas extrêmes, pas seulement le coût moyen. Le calcul du coût complet des licences et tokens aide à distinguer coûts fixes, variables et retries.

Des responsabilités partagées, avec des décisions nommées

La DSI porte l'intégration, l'identité, les connecteurs, la sécurité et l'observabilité. Elle doit tracer sources, versions et politiques, et pouvoir désactiver une intégration sans arrêter le support.

Finance valide convention de coût, allocations, plafonds et rapprochement télémétrie-facture. Elle distingue mise en place, qualité documentaire et formation des coûts récurrents, et désigne qui reçoit les alertes et autorise les ajustements.

Le métier choisit les intentions admissibles, valide les réponses, définit la résolution et nomme les responsables des sources et escalades. Il examine les erreurs et décide de clarifier ou retirer une source, exclure un cas ou changer une règle. DPO, sécurité et RH contribuent selon les données concernées.

Évaluez des demandes anonymisées, profils d'accès distincts, sources obsolètes, ambiguïtés et cas à refuser ou transférer. Faites valider le jeu par le métier et rejouez-le après les changements d'index, modèle ou règles ; mesurez aussi la qualité des refus et escalades.

Checklist avant d'élargir le pilote

1. Usage — intentions, exclusions et définition testable d'une résolution sont validées.
2. Sources et accès — owners, statut, retrait et tests ACL avant génération sont en place.
3. Réponse et routage — citations vérifiables ; conflits, faible couverture et cas sensibles sont escaladés.
4. Humain — file responsable, contexte minimal, délais, mode dégradé et arrêt d'urgence sont définis.
5. Mesure — baseline comparable, coût complet, retries, revue, réouvertures et résolutions sont suivis.
6. Budget — plafonds et alertes ont des responsables ; aucun dépassement silencieux.
7. Évaluation — tests versionnés couvrent permissions, sources obsolètes et refus.
8. Revue — DSI, Finance et métier décident de continuer, corriger ou arrêter.

Conclusion

Un assistant de support interne utile n'est pas un moteur de réponse universel. C'est un parcours gouverné : des demandes choisies, des sources autorisées, une réponse vérifiable, un transfert lorsque le système atteint ses limites, et une mesure économique au niveau de la demande résolue. Commencez étroit, rendez les reprises et les coûts visibles, puis n'élargissez que lorsque les droits, l'expérience humaine et l'exploitation sont démontrables.

Pour le cadrage de la recherche documentaire, approfondissez les patterns RAG enterprise ; pour les responsabilités d'un workflow plus autonome, voir les agents en entreprise.