Chatbot interne entreprise : ce qu’il faut verrouiller avant de lancer le vôtre

« Chatbot interne entreprise » revient de plus en plus dans les recherches des directions RH et IT : la promesse est simple — un assistant conversationnel qui répond aux salariés depuis la base de connaissances de l’entreprise (convention collective, procédures IT, politique de notes de frais) plutôt qu’un email de plus qui s’empile dans une boîte contact@ ou support@ partagée. Le réflexe le plus courant est de s’abonner à une plateforme du marché facturée par utilisateur. C’est souvent le bon point de départ — mais avant de multiplier les licences, il faut vérifier ce que cet assistant doit réellement savoir, et qui a le droit de le lui demander.

Chatbot scripté, agent conversationnel, ou les deux ?

La question que pose un chatbot interne n’est pas différente de celle que pose un chatbot client : un arbre de décision à quelques branches ne demande pas la même architecture qu’un assistant qui doit croiser plusieurs documents et reformuler une réponse en langage naturel. Nous avons détaillé ailleurs sur ce blog comment trancher ce choix pour un chatbot client ; la même grille s’applique en interne, avec une nuance — un salarié pardonne beaucoup moins vite une réponse fausse sur son solde de congés qu’un visiteur anonyme une réponse approximative sur un produit.

Le socle technique : une base de connaissances, pas un scénario figé

Nous avons construit exactement ce socle pour un chatbot éducatif : une base de connaissances alimentée par les documents existants, une classification qui oriente chaque question vers le bon sous-workflow, et un harnais de test qui vérifie les réponses avant leur mise en production. Pour un usage interne — RH, IT, support salarié — la seule vraie différence est la source : conventions collectives et procédures internes plutôt que contenus pédagogiques. La couche conversationnelle elle-même repose souvent sur des modèles comme Claude, capables de reformuler une réponse plutôt que de réciter un document mot pour mot.

Des données RH sensibles : ce qu’il faut verrouiller dès la conception

• →Hébergement en UE et accès restreint aux échanges, exactement comme pour tout traitement de données RH au sens du RGPD — un assistant interne qui lit des documents RH manipule des données personnelles, pas seulement du texte statique.
• →Une durée de conservation définie pour l’historique des conversations, pas un historique illimité par défaut.
• →Une frontière claire entre ce que le chatbot peut consulter (procédures, documentation partagée) et ce qu’il ne doit jamais restituer — le dossier individuel d’un collègue, des données de paie, un dossier disciplinaire.
• →Le coût suit la même logique que celle détaillée ailleurs sur ce blog pour un diagnostic IA RH sur mesure : un premier périmètre utilisable démarre le plus souvent dans le même ordre de grandeur, largement sous le cumul d’abonnements par utilisateur une fois l’adoption étendue à plusieurs dizaines de salariés.

Comment démarrer sans tout reconstruire

Démarrez étroit : une seule équipe, une seule source de vérité (la politique de congés, ou l’onboarding IT, pas les deux à la fois), et un moyen visible pour un salarié de signaler une réponse fausse. Mesurez combien de questions l’assistant résout réellement sans escalade avant d’étendre son périmètre à une deuxième équipe ou un deuxième jeu de documents. Un chatbot interne qui essaie de tout couvrir dès le premier jour est la façon la plus courante dont ce type de projet s’enlise — ceux qui tiennent démarrent sur une seule question à fort volume, bien documentée, exactement comme les cas d’usage client de notre catalogue de projets.