En bref. Un chatbot helpdesk ne se juge pas à un pourcentage de tickets détournés, mais à une liste : celle des gestes qu’on l’autorise à faire tout seul. Répondre à une question, ouvrir un ticket, en donner l’état : personne n’en discute. Réinitialiser un mot de passe, débloquer un compte, enregistrer un nouveau téléphone d’authentification : c’est là que le support interne devient une porte d’entrée.
Nous avons relevé le texte des dix-neuf résultats naturels de la requête « chatbot helpdesk » sur Google France, le 10 août 2026. Aucun n’écrit « ingénierie sociale », « hameçonnage » ou « usurpation d’identité », et aucun ne cite l’ANSSI. Pourtant l’agence, elle, écrit noir sur blanc que le service informatique se fait usurper. Cet article comble ce trou, avec un barème de preuve d’identité que vous pouvez manipuler plus bas.
Un helpdesk, c’est le guichet interne : la ligne que compose un salarié quand son mot de passe ne passe plus, quand l’imprimante du deuxième refuse de s’appairer, quand il lui faut un accès à un outil qu’il n’a jamais ouvert. Ce guichet croule sous des demandes qui se répètent, et l’idée d’y poser un chatbot est vieille comme le support informatique.
Les pages qui vendent cette idée racontent toutes la même chose : disponible la nuit, jamais fatigué, il absorbe le niveau 1 et rend du temps aux techniciens. C’est vrai. Ce n’est pas faux, c’est incomplet, et l’incomplétude porte un nom précis : rien de tout cela ne dit à qui le bot est en train de parler.
Un chatbot de support client se trompe de réponse et fait perdre deux minutes. Un chatbot de support interne qui se trompe de personne remet un mot de passe à un inconnu. Ce n’est pas une hypothèse d’école : c’est un mode opératoire documenté par l’ANSSI dans son panorama annuel. Cet article prend le problème dans cet ordre : ce que le bot ferme vraiment, à qui il parle, et quelle preuve exiger avant de le laisser agir.
Ce qu’un chatbot helpdesk ferme vraiment
Toutes les demandes qui arrivent à un guichet interne ne se ressemblent pas, et les mélanger est la première erreur de cadrage. Elles se rangent en trois familles, qui n’exigent ni le même travail, ni le même niveau de confiance.
La première famille, ce sont les demandes de savoir : comment se connecter au VPN depuis l’étranger, où trouver la procédure de note de frais, quel modèle de téléphone est éligible au renouvellement. Rien à exécuter, rien à vérifier : il faut une bonne réponse, à jour, et savoir dire qu’on ne sait pas. C’est le terrain naturel d’un bot branché sur une base de connaissances.
La deuxième famille, ce sont les demandes d’enregistrement : signaler une panne, réserver une salle, commander un consommable, demander l’état d’un ticket ouvert la veille. Le bot crée ou lit un objet dans l’outil de ticketing. Il n’ouvre aucun accès, et le pire qu’il puisse faire est de créer un ticket en double.
La troisième famille est d’une autre nature. Ce sont les demandes d’accès : mot de passe oublié, compte verrouillé après cinq essais, nouveau téléphone à enregistrer comme facteur d’authentification, droits à élargir sur une application. Elles sont extrêmement répétitives, donc extrêmement tentantes à automatiser. Elles sont aussi les seules dont l’échec ne coûte pas du temps, mais un accès au système d’information.
| Famille de demande | Ce que le bot fait | Ce qu’il faut brancher derrière | Coût d’une erreur |
|---|---|---|---|
| Savoir | Il répond, ou il avoue qu’il ne sait pas | Une base de connaissances tenue à jour, avec des dates | Une réponse périmée, une procédure suivie pour rien |
| Enregistrer | Il crée, il lit, il met à jour un ticket | L’outil de ticketing, en écriture et en lecture | Un doublon, un ticket mal catégorisé |
| Accéder | Il exécute un geste sur un compte, ou il refuse | L’annuaire, le second facteur, et une trace de qui a décidé | Un accès remis à la mauvaise personne |
Cette troisième ligne est le sujet de tout ce qui suit. Elle explique aussi une bizarrerie : les grands éditeurs, quand ils décrivent leur agent de support informatique, s’arrêtent pile avant elle.
Le scénario publié par Microsoft compte cinq étapes : créer l’agent, répondre aux questions de politique interne, vérifier le statut d’un ticket, passer la main à un humain, mettre à jour la documentation. Sur les 884 mots de la page relevés le 10 août 2026, les mots « identité », « authentification », « mot de passe » et « réinitialiser » n’apparaissent pas une seule fois.
Ce n’est pas un oubli, c’est un choix prudent : le scénario reste dans les familles « savoir » et « enregistrer ». Le problème, c’est que la demande la plus fréquente d’un helpdesk, celle qui justifie à elle seule le projet dans la tête du directeur informatique, appartient à la troisième famille. Personne ne dit comment la traiter, et tout le monde la traite quand même.
Un chatbot helpdesk et un chatbot de support client ne se conçoivent pas de la même façon. Le second parle à des inconnus dont on ne sait presque rien, et on l’accepte. Le premier parle à des personnes que l’entreprise connaît parfaitement, ce qui donne l’illusion réconfortante qu’il sait qui elles sont.
À qui parlez-vous ? La question que les pages classées ne posent jamais
Le guichet interne a une particularité que le support client n’a pas : il détient le pouvoir de rendre un accès. C’est précisément ce pouvoir qui en fait une cible, et l’agence nationale de la sécurité des systèmes d’information le documente depuis plusieurs années.
Dans son Panorama de la cybermenace 2025, publié en mars 2026, l’ANSSI consacre une section entière aux techniques d’ingénierie sociale. Elle y écrit : « En 2025, l’ANSSI a observé l’emploi de techniques d’ingénierie sociale avancées telles que le SIM-Swapping, le MFA Fatigue, l’usurpation d’identité ou l’hameçonnage vocal par des acteurs cybercriminels. » Et, quelques lignes plus loin : « L’ANSSI a ainsi observé plusieurs cas d’arnaques au faux support informatique, incitant des employés à télécharger des solutions de RMM comme vecteur initial de compromission. »
Le passage suivant est le plus utile pour qui construit un helpdesk. L’agence décrit des entreprises françaises compromises, dont des entités du secteur du luxe, et précise : « Dans au moins un des cas, les attaquants auraient usurpé le service informatique pour obtenir les accès d’une application de gestion des relations clients. »
L’usurpation marche dans les deux sens, et c’est ce qui rend le sujet difficile. L’attaquant peut se faire passer pour le support auprès d’un salarié, ce que décrit l’ANSSI. Il peut aussi se faire passer pour un salarié auprès du support, et demander gentiment la réinitialisation d’un mot de passe. Un chatbot placé à ce guichet hérite mécaniquement des deux risques.
Hameçonnage vocal. L’ANSSI le définit comme une « technique malveillante où l’attaquant utilise un appel téléphonique pour encourager la victime à révéler des informations sensibles ou effectuer des actions compromettantes, souvent en imitant une autorité de confiance (service informatique, banque, etc.) ». Transposée au chat écrit, la technique ne change pas : elle change seulement de canal.
Deux évolutions récentes rendent cette usurpation plus facile qu’avant. La première est la banalisation des outils de synthèse. Dans sa synthèse de la menace publiée le 4 février 2026, le CERT-FR note que « de nombreux cybercriminels exploitent pour quelques dizaines de dollars des services de deepfakes à des fins d’usurpation d’identités ». La voix au téléphone n’est plus une preuve, et le style d’écriture non plus.
La seconde est culturelle. Dans son rapport d’activité 2025, Cybermalveillance.gouv.fr classe l’arnaque au faux support technique au quatrième rang des menaces pour les particuliers, avec 5,9 % des demandes d’assistance et 18 000 demandes traitées, en hausse de 39 % sur un an. Autrement dit : vos salariés ont été entraînés, dans leur vie privée, à se méfier de tout ce qui ressemble à une assistance informatique. Ils vont appliquer cette méfiance à votre chatbot, et ils auront raison.
Croire qu’un chatbot d’entreprise est protégé parce qu’il vit derrière l’intranet. Dès qu’on le publie sur WhatsApp, sur un numéro de téléphone ou sur une adresse d’assistance ouverte, il devient joignable par quelqu’un qui n’a aucun compte chez vous. La question n’est pas où le bot est hébergé, c’est ce que le canal prouve au moment de la demande.
Le niveau de preuve doit suivre le coût de l’erreur
L’ANSSI ne propose pas de recette unique, et c’est honnête de sa part. Dans son guide Recommandations relatives à l’authentification multifacteur et aux mots de passe, publié le 8 octobre 2021 et toujours en vigueur, la section consacrée au recouvrement d’un accès énumère les méthodes possibles, puis renonce explicitement à en désigner une.
Le texte cite « la réception d’un mot de passe temporaire autogénéré », « la réception d’un lien temporaire à usage unique de réinitialisation » et « le contact du support informatique », puis pose la limite : ces méthodes « viennent avec leurs problématiques propres : le choix du mode de réception (par courriel, SMS, envoi postal, téléphone, etc), le choix du temps de validité de liens temporaires, la complexité de ces méthodes pour l’utilisateur, l’ajout ou non de vérificateur humain, etc. Cela rend très difficile la recommandation d’une méthode en particulier. »
La recommandation R30 se contente donc d’exiger « une méthode de recouvrement d’accès adaptée au contexte d’utilisation ». Ce n’est pas une dérobade, c’est le vrai énoncé du problème : il n’existe pas de bon niveau de preuve dans l’absolu, il existe un niveau de preuve proportionné à ce qu’on est sur le point de faire. C’est exactement ce que doit encoder un chatbot helpdesk, et c’est ce que l’outil ci-dessous met en chiffres.
Quel niveau de preuve exiger avant que le bot agisse ?
Quatre questions, une note de risque sur 26, et le geste que le chatbot a le droit de faire. Le barème est publié : chaque réponse porte son nombre de points.
Quelle est la demande ?
Comment le demandeur est-il reconnu au moment de la demande ?
Quel compte est concerné ?
Que dit le contexte de la demande ?
Le geste demandé ne donne aucun accès et ne change rien de sensible. Le chatbot répond, ouvre le ticket, réserve la salle. Une trace horodatée suffit, il n’y a rien à vérifier de plus.
Le chatbot peut aller au bout, à condition de redemander une preuve vivante au moment du geste : un second facteur validé sur un appareil déjà enregistré, jamais un code envoyé sur le canal qui vient de servir à demander. Si la preuve échoue, la demande bascule vers un humain, elle ne s’efface pas.
Le chatbot fait tout le travail sans valeur ajoutée humaine : il qualifie, rassemble les éléments, prépare le ticket et la fiche de décision. Mais c’est un technicien identifié qui appuie sur le bouton, après un contrôle hors bande, par exemple un rappel sur le numéro connu du service ou une validation par le responsable hiérarchique.
À ce niveau, l’automatisation devient le maillon faible. Le chatbot n’exécute rien : il prend la demande, il explique la procédure, il ouvre le ticket et il passe la main. Ce refus doit être écrit dans le scénario, pas laissé à l’appréciation du modèle.
Barème indicatif, à recalibrer sur votre propre politique de sécurité. Il traduit une idée simple : le niveau de preuve suit le coût de l’erreur, pas le confort du demandeur.
Trois exemples, calculés par ce barème, montrent à quel point le verdict bouge sans que la demande change.
Le même mot de passe, trois fois
Réinitialisation
Un salarié demande la réinitialisation de son mot de passe depuis sa session ouverte sur son poste de travail géré par l’entreprise. Compte standard, aucun signal particulier. La demande vaut 6 points, la reconnaissance 0, le compte 0, le contexte 0 : 6 points sur 26, le bot traite après une re-authentification forte. C’est le cas nominal, et il est parfaitement automatisable.
Même demande, mais le demandeur n’a aucune session : il déclare simplement qui il est sur un canal ouvert, le compte est celui d’un administrateur, et son facteur d’authentification a été changé il y a cinq jours. On passe à 6 + 7 + 5 + 4, soit 22 points sur 26 : hors périmètre du bot. Le scénario doit refuser, expliquer et transférer.
Un compte verrouillé, un détail qui change tout
Déverrouillage
Déverrouiller un compte bloqué après trop d’essais vaut 4 points, ce qui en fait le geste sensible le moins coûteux. Depuis une session ouverte sur un appareil personnel, sur un compte standard, on est à 6 points : le bot peut le faire après re-authentification.
Ajoutez un seul élément de contexte, « plusieurs échecs d’authentification sur ce compte aujourd’hui », et le total passe à 9 points sur 26. Le verdict change : le bot prépare le dossier, un humain valide. Ce détail est exactement celui qui distingue un salarié étourdi d’une tentative en cours.
La règle qui fait le plus de dégâts quand on l’oublie tient en une phrase : ne jamais envoyer la preuve sur le canal qui vient de servir à demander. Un code envoyé par SMS à un demandeur qui s’est présenté par SMS ne prouve rien du tout, il valide seulement que la personne tient le téléphone qu’elle vient d’utiliser. C’est très exactement ce que contourne le SIM-Swapping cité par l’ANSSI.
Brancher le bot sans ouvrir une porte
Passer du principe à un chatbot qui tourne suppose sept décisions, dans cet ordre. Les trois premières se prennent avant d’écrire la moindre ligne de scénario.
- Compter les demandes réelles, pas les demandes imaginéesSortez douze mois de tickets de l’outil de ticketing et classez-les dans les trois familles. Le classement dit ce que le bot va vraiment absorber, et il contredit souvent les intuitions du comité de pilotage.
- Écrire la liste des gestes autorisésC’est le document fondateur, et il tient sur une page. Pour chaque geste, le score de preuve exigé et la conduite à tenir si la preuve échoue. Tout ce qui n’est pas sur la liste est refusé par défaut.
- Choisir le canal en fonction de ce qu’il prouveUn widget dans l’intranet hérite de la session d’entreprise, donc d’une identité déjà vérifiée. Une messagerie grand public ne prouve que la possession d’un numéro. Les deux sont légitimes, pour des gestes différents.
- Alimenter la base de connaissances, avec des datesLe bot répond ce qu’on lui donne. Une procédure sans date de mise à jour deviendra une réponse fausse, et personne ne saura quand elle a cessé d’être vraie.
- Brancher le ticketing avant l’annuaireCréer et lire des tickets apporte l’essentiel de la valeur pour un risque quasi nul. Connecter l’annuaire et le second facteur vient après, quand la liste des gestes autorisés est stabilisée et que les scénarios ont tourné en production.
- Rendre la sortie vers un humain toujours accessiblePas seulement en cas d’échec du bot : à tout moment, sur demande. Un bot qui retient l’utilisateur en boucle est vécu comme une manœuvre, et il pousse les gens à contourner le guichet officiel, ce qui est le pire résultat possible en matière de sécurité.
- Journaliser la décision, pas seulement la conversationPour chaque geste sensible : le score calculé, la preuve obtenue, la personne ou la règle qui a tranché, l’horodatage. C’est ce qui permet de comprendre après coup, et c’est ce que réclamera l’audit.
Ce que gagne l’entreprise
- Les demandes de savoir et d’enregistrement sortent de la file d’attente
- Les techniciens traitent des incidents, pas des mots de passe
- Chaque geste sensible laisse une trace exploitable
- La politique de sécurité devient exécutable, au lieu d’être un document
Ce que gagne le salarié
- Une réponse immédiate à 22 heures un dimanche
- Un interlocuteur qui ne juge pas la question posée
- Un parcours identique quel que soit le site ou le pays
- Une explication quand le bot refuse, pas un mur
Ce que la loi impose depuis le 2 août 2026
Le règlement européen sur l’intelligence artificielle, le règlement (UE) 2024/1689, est applicable depuis le 2 août 2026. Son article 50, paragraphe 1, concerne directement tout chatbot, y compris interne.
Les fournisseurs veillent à ce que les systèmes d’IA destinés à interagir directement avec des personnes physiques soient conçus et développés de manière que les personnes physiques concernées soient informées qu’elles interagissent avec un système d’IA, sauf si cela ressort clairement du point de vue d’une personne physique normalement informée et raisonnablement attentive et avisée, compte tenu des circonstances et du contexte d’utilisation.
Pour un helpdesk, l’obligation est facile à satisfaire et elle sert le sujet de cet article. Annoncer qu’on parle à une machine, c’est aussi donner au salarié le moyen de reconnaître le guichet officiel et de se méfier de ce qui n’y ressemble pas. Une phrase d’accueil explicite, un nom qui ne prétend pas être un humain, et un rappel de l’adresse ou du numéro par lequel l’entreprise contacte réellement ses collaborateurs.
Deux réflexes complètent le tableau, sans qu’il faille en faire un chantier. Le bot ne demande que ce qu’il utilise vraiment pour traiter la demande, et rien de plus. Et les journaux qui contiennent des identifiants ou des éléments d’authentification ont une durée de conservation décidée à l’avance, pas une durée par défaut.
Par où commencer, et ce que ça coûte
La bonne première brique n’est pas la plus impressionnante : c’est celle qui traite les deux premières familles de demandes, avec une sortie vers un humain qui fonctionne. Elle se met en place vite, elle ne touche à aucun compte, et elle produit la matière dont vous aurez besoin pour la suite, à savoir la liste réelle de ce que les gens demandent.
Sur une plateforme no-code comme Botnation pour le support informatique, cette première brique se construit sans développement : des intentions, des réponses, un connecteur vers l’outil de ticketing, et une règle d’escalade. Le passage à la troisième famille, lui, n’est pas un sujet d’interface : c’est un sujet de politique de sécurité, et il se traite avec l’équipe qui en a la charge.
Côté budget, l’ordre de grandeur d’une plateforme se lit sur la grille publique : une offre gratuite à 0 €, une offre Basic à 39 € par mois, une offre Pro à 59 € par mois, et une offre Entreprise sur mesure. Ce sont les prix de la plateforme, pas d’un projet. Botnation édite une plateforme no-code et réalise des chatbots sur mesure pour ses clients, via l’offre Entreprise et ses experts en création de chatbot ; le chiffrage d’un projet de helpdesk se fait alors sur devis, parce qu’il dépend entièrement du nombre de connecteurs et du périmètre des gestes autorisés.
Une agence tierce reste parfaitement légitime, en particulier si vous avez un intégrateur déjà en place sur votre outil de ticketing, ou un métier très spécifique à modéliser. La différence, quand l’équipe qui construit est aussi celle qui édite la plateforme, tient à l’après : il n’y a pas de développement sur mesure à reprendre, et le compte, les scénarios et la base restent au nom du client, modifiables dans l’éditeur.
Questions fréquentes
Un chatbot helpdesk peut-il réinitialiser un mot de passe ?
Oui, à condition que la preuve d’identité soit apportée au moment du geste et non au moment de la demande. En pratique : une session d’entreprise déjà ouverte, ou une validation sur un second facteur enregistré à l’avance sur un appareil connu. Ce qui ne prouve rien, c’est un code envoyé sur le canal qui vient de servir à écrire, ou une série de questions sur la date de naissance et le nom du manager, deux informations qu’un attaquant obtient en quelques minutes.
Quelle différence entre un chatbot helpdesk et un chatbot de support client ?
Le public et le pouvoir. Le support client parle à des personnes que l’entreprise ne connaît pas, sur des sujets qui engagent rarement la sécurité du système d’information. Le helpdesk parle à des salariés identifiables, mais il peut rendre un accès. C’est ce pouvoir qui impose un barème de preuve, alors que le support client s’en passe la plupart du temps. La mécanique de compréhension, elle, est la même dans les deux cas : elle est décrite en détail dans notre article sur le fonctionnement d’un chatbot.
Faut-il un modèle de langage, ou des règles suffisent-elles ?
Les deux cohabitent très bien, à condition de les placer où il faut. Un moteur génératif branché sur votre documentation est excellent pour la famille « savoir », parce qu’il absorbe les formulations que personne n’avait prévues. Pour la famille « accéder », le chemin doit rester un scénario déterministe : c’est un enchaînement de conditions vérifiables, pas une conversation. On ne délègue pas à un modèle probabiliste la décision de rendre un accès.
Combien de demandes un chatbot helpdesk absorbe-t-il vraiment ?
Aucun chiffre générique ne vaut pour votre entreprise, et se fier à ceux qu’on lit partout revient à acheter une taille de vêtement au hasard. Le seul calcul honnête part de vos propres tickets : classez douze mois d’historique dans les trois familles, et vous obtiendrez votre plafond théorique. Ce qui est atteint dépend ensuite de la qualité de la base de connaissances et de la clarté de la sortie vers un humain.
Le chatbot doit-il annoncer qu’il est une machine ?
Oui. Le règlement européen sur l’intelligence artificielle est applicable depuis le 2 août 2026, et son article 50 impose d’informer les personnes qu’elles interagissent avec un système d’IA, sauf quand cela ressort clairement des circonstances. Sur un helpdesk, c’est de toute façon la bonne pratique : un guichet interne qui s’annonce est un guichet qu’on peut reconnaître, donc dont on peut se méfier quand une copie s’y substitue.
Peut-on ouvrir le helpdesk sur WhatsApp ou par téléphone ?
Oui pour les familles « savoir » et « enregistrer », qui gagnent énormément à être joignables là où les salariés sont déjà, notamment sur les sites industriels et en itinérance. Non, en l’état, pour les gestes qui touchent aux accès : ces canaux ne prouvent que la possession d’un numéro, et le SIM-Swapping cité par l’ANSSI vise exactement cette possession. Le même bot peut servir les deux publics, à condition que la liste des gestes autorisés dépende du canal.
Ce qu’il faut retenir
Un chatbot helpdesk réussi n’est pas un bot qui répond à tout. C’est un bot dont on sait précisément ce qu’il a le droit de faire, et qui refuse le reste de façon prévisible.
Quatre questions à poser avant de lancer le projet, ou à poser au prestataire qui vous le propose.
- Quelle est la liste des gestes autorisés, et qu’arrive-t-il à tout ce qui n’y figure pas ?
- Quelle preuve d’identité est exigée pour chacun, et sur quel canal cette preuve arrive-t-elle ?
- Que se passe-t-il quand la preuve échoue ? Un transfert vers un humain, ou un abandon silencieux qui poussera l’utilisateur à contourner le guichet ?
- Que trouve-t-on dans les journaux six mois plus tard : la conversation seule, ou la décision, la preuve et l’horodatage ?
Un helpdesk interne qui traite aussi les demandes des équipes ressources humaines pose exactement les mêmes questions, avec des données plus sensibles encore : le sujet est développé dans notre page dédiée au chatbot RH, et la mise en place d’un guichet interne complet dans notre article sur le chatbot interne en entreprise.
Construisez la première brique cette semaine
Créez gratuitement un chatbot, branchez-le sur vos procédures internes et regardez ce que vos équipes lui demandent réellement. C’est cette liste, et elle seule, qui dira où placer la frontière des gestes autorisés.
Créer mon chatbot de support informatique
Ou faire chiffrer un projet par nos experts en création de chatbot
Sources : ANSSI, Panorama de la cybermenace 2025, dépôt légal mars 2026, ISSN 2970-8818, page 30 ; ANSSI, Recommandations relatives à l’authentification multifacteur et aux mots de passe, guide ANSSI-PG-078 version 2.0, publié le 8 octobre 2021, section 4.7 et recommandation R30 ; CERT-FR, L’IA générative face aux attaques informatiques : synthèse de la menace en 2025, 4 février 2026, TLP:CLEAR ; Cybermalveillance.gouv.fr, Rapport d’activité 2025, page 52 ; règlement (UE) 2024/1689 du 13 juin 2024, article 50 et article 113, texte français du Journal officiel de l’Union européenne ; bibliothèque de scénarios Microsoft Adoption, fiche « agent d’assistance informatique », consultée le 10 août 2026 ; pages tarifs et support informatique de botnation.ai, consultées le 10 août 2026. Le relevé des dix-neuf résultats naturels de la requête « chatbot helpdesk » a été réalisé le 10 août 2026 sur Google France.
