L’intégration de l’IA dans le service desk ne se limite plus à la génération de réponses. Dans de plus en plus de cas, l’agent peut lire des tickets, consulter une base de connaissances, accéder à une CMDB, proposer une résolution, router une demande ou préparer une action dans l’outil ITSM.
Cette évolution crée un nouveau point d’attention : l’IA traite en permanence du texte qu’elle ne maîtrise pas. Tickets utilisateurs, e-mails, commentaires, pièces jointes, liens externes ou articles de connaissance peuvent contenir des instructions malveillantes ou ambiguës. C’est le principe de la prompt injection.
Avant de connecter une IA à un environnement ITSM, il faut donc évaluer son périmètre d’accès, ses capacités d’action et les contrôles nécessaires pour éviter qu’un contenu non fiable ne déclenche une réponse ou une action inappropriée.
Pourquoi le service desk est exposé à la prompt injection
Un service desk reçoit par nature des informations non structurées. Les utilisateurs décrivent leurs problèmes librement, ajoutent des captures d’écran, transfèrent des e-mails ou joignent des documents. Pour un agent IA, tous ces éléments deviennent des sources de contexte.
La prompt injection exploite précisément cette situation. Une instruction peut être dissimulée dans un ticket, un document ou une source consultée par l’agent. Si le modèle n’est pas correctement encadré, il peut traiter cette instruction comme une consigne valide.
Dans un contexte ITSM, le risque augmente lorsque l’IA n’est plus limitée à la suggestion. Un agent capable de consulter des données internes, d’enrichir un ticket, de router une demande ou de préparer une action dispose d’un périmètre opérationnel plus large. Plus ce périmètre est étendu, plus les contrôles doivent être précis.
Les risques à analyser avant le déploiement
Le premier risque est la fuite de données. Un agent IA connecté au service desk peut avoir accès à des historiques de tickets, des informations sur les actifs, des données utilisateurs, des incidents sensibles ou des éléments liés à la sécurité. Sans limitation stricte, il peut exposer des informations qui ne devraient pas sortir de leur contexte.
Le deuxième risque est l’action non autorisée. L’IA peut être utilisée pour accélérer le traitement des demandes : affectation d’un ticket, proposition de résolution, clôture, déclenchement d’un workflow ou préparation d’un accès. Mais une action automatisée mal cadrée peut créer des effets plus graves qu’une simple réponse incorrecte.
Le troisième risque est la dégradation de la base de connaissances. Si l’agent s’appuie sur des contenus obsolètes, non validés ou manipulés, il peut produire des recommandations incorrectes à grande échelle. Dans ce cas, le problème n’est pas ponctuel : il affecte durablement la qualité des réponses et des décisions.
| ✓ Checkpoint — 3 risques à analyser ✓ Fuite de données ✓ Action non autorisée ✓ Dégradation de la base de connaissances |
Définir un modèle de menace adapté à l’ITSM
Avant tout déploiement, chaque cas d’usage doit être analysé selon quatre dimensions : les données consultées, les actions possibles, l’impact d’une erreur et la capacité à revenir en arrière.
Une IA qui suggère une catégorie de ticket présente un risque limité. Une IA capable de préparer un accès, consulter des données sensibles ou déclencher un changement doit être traitée avec un niveau de contrôle plus élevé.
La bonne approche consiste à partir du scénario d’échec : que se passe-t-il si l’agent interprète mal une demande ? Que peut-il divulguer ? Quelle action peut-il déclencher ? Qui peut l’arrêter ? Comment peut-on reconstituer sa décision ?
Ce raisonnement permet de définir le niveau d’autonomie acceptable. L’IA peut être utile en suggestion, en préqualification ou en enrichissement, sans pour autant disposer d’un droit d’action complet sur l’environnement ITSM.
| ✓ Checkpoint — Modèle de menace en 4 dimensions ✓ Données consultées ✓ Actions possibles ✓ Impact d’une erreur ✓ Capacité à revenir en arrière (réversibilité) |
Les contrôles à mettre en place
Le premier contrôle est le moindre privilège. L’agent IA ne doit accéder qu’aux données nécessaires à son cas d’usage. Un accès global aux tickets, aux utilisateurs, aux actifs ou aux catégories augmente inutilement la surface de risque.
Le deuxième contrôle est la séparation entre instructions et données. Les consignes qui définissent le comportement de l’agent doivent être clairement distinguées des contenus utilisateurs, des pièces jointes et des sources externes. Tout texte entrant doit être considéré comme potentiellement non fiable.
Le troisième contrôle est la validation humaine sur les actions sensibles. L’IA peut préparer une réponse, enrichir un ticket ou proposer une affectation. En revanche, les actions liées aux accès, aux changements, aux données sensibles ou à la communication critique doivent rester soumises à validation.
Le quatrième contrôle est la journalisation. Il doit être possible de comprendre ce que l’agent a consulté, ce qu’il a proposé, quelle action a été déclenchée et par qui elle a été validée. Sans piste d’audit, l’organisation ne peut ni expliquer une erreur, ni améliorer le dispositif, ni démontrer sa maîtrise.
Le cinquième contrôle concerne les sources de connaissance. Les procédures validées, les contenus utilisateurs, les documents externes et les articles en brouillon ne doivent pas être traités avec le même niveau de confiance. Une IA de service desk doit s’appuyer sur des contenus maîtrisés, à jour et clairement identifiés.
| ✓ Checkpoint — 5 contrôles à mettre en place ✓ Moindre privilège sur les données et les actions ✓ Séparation entre instructions et données ✓ Validation humaine sur les actions sensibles ✓ Journalisation et piste d’audit complète ✓ Hiérarchie de confiance des sources de connaissance |
Gouvernance ITSM : le socle de contrôle de l’IA
La sécurité d’un agent IA ne dépend pas uniquement de paramètres techniques. Elle dépend aussi de la gouvernance ITSM dans laquelle il s’inscrit.
Qui autorise la connexion de l’IA à un périmètre donné ? Qui valide les cas d’usage ? Qui approuve les actions sensibles ? Qui surveille les erreurs ? Qui peut suspendre l’agent ? Ces responsabilités doivent être définies avant la mise en production.
Une gouvernance ITSM structurée permet d’encadrer les droits, les workflows, les validations et la traçabilité. Elle donne un cadre clair à l’automatisation et réduit le risque de décisions non contrôlées.
L’IA peut apporter de la valeur au service desk, notamment sur la qualification, le routage, la collecte d’informations ou l’aide à la résolution. Mais elle ne doit pas être ajoutée sur un socle fragile. Si les données sont peu fiables, si les droits sont flous ou si les workflows ne sont pas maîtrisés, elle accélère surtout les problèmes existants.
Conclusion
La prompt injection ne doit pas empêcher les équipes IT d’explorer l’IA dans le service desk. Elle impose en revanche une approche structurée.
Avant de connecter un agent IA à l’ITSM, il faut définir ce qu’il peut lire, ce qu’il peut faire, quelles actions restent soumises à validation et comment chaque décision sera tracée.
Une IA fiable n’est pas seulement une IA qui produit de bonnes réponses. C’est une IA dont le périmètre est limité, les données sont contrôlées, les actions sensibles sont validées et les décisions peuvent être expliquées. Dans un environnement ITSM, cette discipline est indispensable pour transformer l’IA en levier opérationnel plutôt qu’en risque difficile à maîtriser.
Article proposé par les consultants de SMC Consulting, spécialistes de l’implémentation et de la gouvernance ITSM (France/Belgique/Luxembourg).