L’IA peut rendre une demande de support plus rapide à comprendre : résumer le besoin, repérer les informations manquantes et préparer des indications pertinentes et autorisées. Le bénéfice apparaît lorsque cela produit un état d’avancement facile à vérifier. Envoyer une réponse ou exécuter une modification relève d’une décision distincte.
Un périmètre limité convient pour commencer. Par exemple, l’assistant prépare des brouillons de tickets internes sans envoyer lui-même de messages ni modifier de systèmes. La qualité et les reprises peuvent ainsi être évaluées dans le processus réel.
Ce qu’une proposition utile devrait contenir
Un bref résumé indique l’incident observé, les outils de travail concernés et le déroulement jusqu’ici. Les hypothèses et les questions encore ouvertes sont présentées séparément. Si un horaire, un message d’erreur ou l’étendue de la perturbation manque, cela est rendu visible.
Un brouillon de réponse devrait expliquer les informations encore nécessaires ou l’étape approuvée qui paraît pertinente. Une solution proposée doit reposer sur une base traçable. Un ancien ticket au libellé similaire ne suffit pas comme preuve si l’environnement ou la cause diffère.
Exemple : « L’application est lente »
L’assistant prépare des questions sur le moment, les utilisateurs concernés, la fonction précise et les messages d’erreur. Il peut réunir les informations déjà présentes dans le ticket et renvoyer vers une section pertinente et approuvée de la documentation.
Il ne prétend pas qu’un contrôle du serveur a déjà été effectué ni qu’une cause est confirmée. Une mesure technique n’est proposée que si les constats disponibles la justifient. Il s’agit d’un exemple de processus possible, pas d’une référence client.
Les droits sur les tickets et les documents restent déterminants
Un assistant de support n’a pas automatiquement besoin d’accéder à tous les tickets et à toute la documentation. La recherche est limitée à l’utilisateur concerné, au périmètre convenu et aux objets appropriés. Cela vaut aussi pour les pièces jointes, les notes internes et les informations d’autres clients.
Dans une recherche documentaire avec RAG ces droits doivent être pris en compte dès la sélection des résultats. Les contenus non autorisés ne doivent pas non plus entrer dans un contexte de modèle qui sera ensuite rejeté. La réalisation technique de l’accès documentaire varie selon la source ; Microsoft décrit par exemple différentes approches des droits documentaires dans Azure AI Search (lien externe). Un filtre simple n’est efficace que si l’identité et les valeurs du filtre sont établies de façon fiable.
Lorsque plusieurs environnements clients sont pris en charge, leur séparation et les flux de données autorisés font partie de la conception de l’intégration. Les journaux et contenus conservés sont définis selon la finalité et les besoins d’exploitation. Conserver l’historique complet de prompts le plus volumineux possible n’est pas une fin en soi.
Les contenus entrants sont des données, pas des instructions
Un ticket peut contenir du texte demandant à l’assistant d’effectuer une action interdite. Il en va de même pour les documents, les emails et les pièces jointes. Ces contenus ne doivent ni modifier les règles système ni débloquer des outils ou des accès supplémentaires.
L’application limite donc côté serveur les sources pouvant être lues et les fonctions pouvant être appelées. Une proposition du modèle ne suffit pas à annuler ces limites. Des fonctions définies peuvent être intégrées avec des outils MCP contrôlés et des API existantes ; la documentation sur la sécurité MCP (lien externe) décrit des domaines précis d’attaque et de protection.
Validation et exécution en deux étapes distinctes
La personne chargée du ticket voit ensemble le résumé, les sources et le brouillon de réponse. Elle peut corriger les informations, poser des questions ou rejeter la proposition. Un bouton d’envoi doit indiquer clairement quel message sera envoyé à quel destinataire. L’envoi passe par l’application autorisée à le faire.
Une séparation supplémentaire est utile pour les modifications techniques : une proposition de diagnostic ne devient pas un ordre d’administration simplement parce qu’elle paraît plausible. La finalité, le système cible, le périmètre autorisé et les validations requises sont vérifiés séparément. Les cas incertains ou risqués sont confiés au spécialiste responsable.
Un pilote demande plus qu’une bonne démonstration
- Cas ordinaires : Le besoin et les questions complémentaires nécessaires sont-ils correctement identifiés ?
- Base insuffisante : L’assistant reconnaît-il qu’une réponse étayée n’est pas encore possible ?
- Source erronée ou ancienne : La version et le lien réel avec le ticket sont-ils vérifiés ?
- Changement de droits : Les contenus disparaissent-ils de la recherche et du contexte après un retrait d’accès ?
- Entrées manipulées : Les limites des outils et les validations restent-elles en place ?
- Indisponibilité du service : Le ticket peut-il toujours être traité normalement ?
L’évaluation devrait aussi compter le temps de lecture, de correction et de vérification. Un long brouillon peut créer du travail supplémentaire. Un état d’avancement court et bien étayé peut au contraire soulager la charge, même si la décision finale appartient toujours à une personne.
Du brouillon individuel à une intégration maintenable
DAXS définit le point de départ adapté avec votre support et votre équipe informatique, connecte les sources approuvées et réalise un pilote limité. Le système de tickets existant, les identités et la documentation sont considérés ensemble. Le périmètre et son extension suivent le bénéfice démontré.
Vue d’ensemble des usages de l’IA · Introduction et règles d’utilisation · L’informatique au quotidien
