Un assistant IA dans l'intranet : ce qu'il résout, où il doit s'arrêter

Sur quelles sources un assistant IA d'entreprise doit répondre, comment poser la frontière des droits, et pourquoi un assistant qui dit « j'ai agi pour vous » est dangereux.

Bien construit, un assistant IA d'entreprise devient le composant le plus utilisé de l'intranet ; mal construit, il se transforme en machine à deviner peu fiable. Trois décisions font la différence : à partir de quelle source il répond, avec les yeux de qui il regarde et ce qu'on l'autorise à faire.

La source : des documents plutôt que des inventions

Un modèle de langage généraliste ne connaît pas votre procédure de congés. S'il répond en croyant la connaître, il produit un texte plausible mais faux — et cela coûte plus cher que l'absence de réponse.

La bonne architecture ancre la réponse dans le contenu de l'organisation : la question est rapprochée sémantiquement des documents chargés, des annonces publiées et des autres contenus internes ; les fragments trouvés sont donnés au modèle comme contexte, et on lui demande de ne répondre qu'à partir de ce contexte. Si l'information n'y est pas, répondre « je n'ai pas cette information » n'est pas un défaut mais le comportement correct.

Cela a une conséquence : la qualité de l'assistant est plafonnée par celle de vos documents. Si vos politiques ne sont pas à jour, l'assistant ne l'est pas non plus. La bonne nouvelle, c'est que ce manque est visible — les questions restées sans réponse écrivent directement votre plan de contenu.

Les droits : avec les yeux de qui regarde-t-il ?

C'est la décision de conception la plus critique. Si l'assistant lit les données avec des droits d'administration, il peut laisser filtrer dans sa réponse une information que l'utilisateur ne verrait pas normalement : une annonce destinée à un autre service, l'évaluation de quelqu'un d'autre, un signalement éthique.

La bonne approche est que toutes les lectures se fassent avec l'identité de la personne qui pose la question. L'assistant ne peut alors accéder à aucune donnée que l'utilisateur ne pourrait pas atteindre lui-même ; l'isolation cesse d'être une liste de contrôle séparée pour devenir la règle que la base de données applique déjà. Nous détaillons ce principe sur notre page sécurité.

La même logique vaut pour les flux qui exigent la confidentialité : les signalements de la ligne éthique, les réponses aux enquêtes de climat et les données de performance ne doivent jamais entrer dans la base de connaissances de l'assistant.

L'action : où s'arrêter ?

« Crée une demande de congé à ma place » est une fonctionnalité séduisante. Mais un assistant qui crée silencieusement des enregistrements produit un problème de confiance difficile à réparer.

Deux modèles sont défendables. Le premier est la carte de confirmation : le modèle propose une action, l'utilisateur la voit et la valide, et seulement alors l'opération a lieu — en s'exécutant avec les droits de l'utilisateur, si bien que l'assistant ne peut rien faire que personne ne pourrait faire. Le second est l'assistant en lecture seule : il n'écrit jamais et oriente vers le bon écran.

Chez nous, les deux coexistent : l'agent d'action à carte de confirmation vit dans « Demander aux RH », tandis que l'assistant WeAI, accessible depuis chaque écran, est délibérément en lecture seule. Plutôt que d'implémenter à moitié la même capacité à deux endroits, nous avons gardé la frontière nette — et l'assistant l'annonce d'emblée à l'utilisateur.

Le troisième modèle, à ne jamais accepter, est celui-ci : un assistant qui dit « je l'ai créé pour vous » sans avoir rien fait.

Citer ses sources

Un bon assistant liste sous sa réponse les documents sur lesquels il s'appuie et permet d'y accéder en un clic. Double bénéfice : l'utilisateur peut vérifier, et la source d'une mauvaise réponse se trouve et se corrige vite. Plutôt qu'un assistant qui dit « fais-moi confiance », un assistant qui peut montrer.

Mesure et coût

Trois choses à suivre : quelles questions sont posées, lesquelles sont restées sans réponse, et le volume d'usage. Les deux premières produisent le plan de contenu ; la troisième rend le coût prévisible, car les appels au modèle sont facturés à l'usage.

Revoir régulièrement les questions sans réponse est la seule pratique qui améliore l'assistant avec le temps — non pas en changeant de modèle, mais en écrivant le document manquant.

L'aide dans le produit

La fonction la moins commentée mais la plus utilisée de l'assistant concerne non pas les données de l'entreprise mais le produit lui-même : « comment envoyer cette annonce à un seul service ? », « où vois-je mon solde de congés ? ». Ces réponses ne sont pas dans les documents mais dans la connaissance du fonctionnement de l'application.

La base de connaissances de l'assistant doit donc contenir aussi ce que font les modules et depuis quel écran chaque tâche s'effectue. Un bénéfice supplémentaire : les modules désactivés doivent être retirés de cette base — décrire à un utilisateur une fonctionnalité qui n'est pas ouverte dans son organisation revient à promettre ce qui n'existe pas.

Par où commencer ?

N'ouvrez pas l'assistant dès le premier jour. Il faut d'abord que le centre documentaire soit ordonné et à jour ; branché sur une base vide, l'assistant perd sa crédibilité dès la troisième question. Cette responsabilité continue relève de la gouvernance décrite dans l'article sur l'exploitation, et l'ordre de déploiement dans le plan à 90 jours.