IA générative pour la doc interne : le bilan après 12 mois et 200 utilisateurs

Douze mois après le déploiement d'un assistant IA sur la base documentaire interne d'un client, une PME industrielle de 200 collaborateurs, on a assez de recul pour dire ce qui a tenu et ce qui s'est effondré. Le projet avait commencé avec un pilote enthousiaste. Il a traversé une crise d'adoption à 3 mois, un moment de plateau à 7 mois, et une stabilisation que personne n'avait vraiment anticipée.

Ce texte ne vend pas de succès. Il documente ce qu'on a observé.

Le contexte du projet

La base documentaire : 4 200 documents (procédures qualité, fiches techniques produits, comptes-rendus de réunion, manuels opérateurs, politiques internes). Format mixte : PDF, Word, quelques Excel, des pages SharePoint.

Les utilisateurs : 200 collaborateurs répartis entre le bureau d'études, la production, le service qualité, et la direction. Niveaux d'aisance numérique très hétérogènes.

L'interface : un chatbot intégré dans Teams, avec une barre de recherche classique en parallèle (on n'a pas retiré l'ancienne recherche).

Les 3 premiers mois : l'enthousiasme et la première déception

Le pilote a démarré avec 40 utilisateurs volontaires. L'engouement a été immédiat. Les retours des premières semaines étaient très positifs, l'outil répondait à des questions qu'une recherche classique ne permettait pas de traiter ("quelle est la procédure à suivre si le capteur X déclenche l'alarme Y dans le contexte Z ?").

La première déception est arrivée à la semaine 6. Plusieurs utilisateurs ont découvert que l'assistant donnait des réponses incorrectes sur des procédures récemment mises à jour, parce que les nouvelles versions de documents n'avaient pas encore été réindexées. La confiance a chuté. Certains ont arrêté d'utiliser l'outil.

C'est là qu'on a compris que la fraîcheur de l'index est une exigence fonctionnelle, pas un détail d'implémentation. On a mis en place un pipeline de réindexation quotidienne automatique. Mais la confiance, une fois perdue sur un cas précis, prend du temps à se reconstruire.

Ce qu'on a mesuré sur 12 mois

Taux d'utilisation actif : au pic (mois 4, après la correction du pipeline), 68 % des 200 utilisateurs avaient utilisé l'assistant au moins une fois dans le mois. À 12 mois, ce taux est stable à 41 %. Ce n'est pas un échec, 82 utilisateurs actifs sur 200 représentent un taux d'adoption substantiel pour un outil interne.

Répartition des usages : 3 cas d'usage concentrent 80 % du volume.

1. Recherche de procédures qualité et sécurité (35 %)
2. Questions sur les caractéristiques techniques produits (28 %)
3. Localisation de documents ("où est le formulaire X ?") (17 %)

Les cas d'usage qu'on avait imaginés, synthèse de comptes-rendus, aide à la rédaction, représentent moins de 10 % du volume. Les utilisateurs ont des usages différents de ceux qu'on avait projetés.

Taux de satisfaction déclaré : 71 % des utilisateurs actifs déclarent l'outil "utile" ou "très utile" dans le questionnaire de 12 mois. 18 % le trouvent "peu fiable", ce qui correspond globalement aux utilisateurs qui ont connu des erreurs et n'ont pas retesté.

Volume de requêtes : environ 1 200 requêtes par mois à 12 mois, stable depuis le mois 8. Coût mensuel d'inférence : ~45 € (GPT-4o-mini, contexte moyen de 2 500 tokens).

Ce qui a vraiment freiné l'adoption

La qualité de la base documentaire

C'est le facteur le plus sous-estimé. L'assistant ne peut répondre qu'à partir de ce qui existe dans les documents. Sur ce projet, 30 % des documents étaient obsolètes (versions antérieures non archivées), 15 % étaient des scans de mauvaise qualité, et un nombre significatif de procédures n'existaient que dans les têtes des experts, pas dans des documents.

L'assistant exposait ces lacunes de façon brutale. Quand un utilisateur posait une question sur une procédure non documentée, il recevait une réponse vague ou un aveu d'ignorance. Avant l'IA, la même question atterrissait dans les mails d'un expert qui répondait de mémoire. L'IA ne cachait plus l'état réel de la base documentaire.

Ça a déclenché un projet parallèle de mise à jour documentaire qu'on n'avait pas prévu, et qui a finalement été bénéfique, mais qui a consommé du temps.

Le syndrome de la première mauvaise réponse

Un utilisateur qui reçoit une mauvaise réponse, surtout dans un domaine où il est expert, ne réessaie souvent pas. Le service qualité, les utilisateurs les plus exigeants sur la précision, a été le groupe le plus difficile à reconquérir après l'incident de la semaine 6.

Ce qu'on aurait dû faire : limiter le périmètre initial à des documents dont la fraîcheur était garantie, et communiquer clairement sur ce que l'assistant ne couvre pas.

L'interface dans Teams

L'intégration dans Teams semblait naturelle, tout le monde l'utilise. En pratique, le contexte d'utilisation dans Teams est le messaging instantané : des messages courts, des réponses rapides. Un chatbot documentaire qui génère des réponses en 3 à 5 secondes avec 3 paragraphes de contenu crée une friction cognitive. Plusieurs utilisateurs nous ont dit qu'ils "attendaient une réponse plus courte".

On a ajouté un mode "réponse courte" (2-3 lignes max + lien vers le document source) qui a amélioré le ressenti sur les requêtes de localisation de documents.

Ce qu'on referait différemment

Commencer par un corpus restreint et maîtrisé. Pas les 4 200 documents dès le départ, les 200 procédures les plus consultées, avec une fraîcheur garantie. L'outil aurait été excellent sur ce périmètre avant d'être étendu.

Investir dans la qualité documentaire en amont. L'IA sert d'amplificateur à la base documentaire existante. Si la base est mauvaise, l'IA produit des réponses mauvaises de façon très visible. Auditer la base avant le déploiement est non négociable.

Prévoir une phase de pilote plus longue avec des cas d'usage définis. Deux semaines de pilote avec des cas d'usage vagues ne permettent pas de détecter les problèmes de fraîcheur et de qualité qui arrivent en conditions réelles.

Garder la recherche classique et ne pas opposer les deux. On avait envisagé de retirer la barre de recherche traditionnelle pour "forcer" l'adoption. On ne l'a pas fait, et c'était la bonne décision. Les deux outils cohabitent, et certains utilisateurs utilisent la recherche pour localiser un document puis l'IA pour interroger son contenu.

Ce qu'on retient pour les déploiements suivants

L'adoption d'un assistant documentaire interne n'est pas un problème technique, c'est un problème de confiance. La confiance se construit sur la fiabilité perçue à chaque interaction, et elle se perd très vite sur une seule erreur dans un domaine où l'utilisateur est expert.

Le critère de succès le plus prédictif qu'on a identifié n'est pas le taux d'utilisation initial. C'est le taux de rétention à 3 mois : les utilisateurs qui reviennent 12 semaines après la première utilisation sont ceux qui ont eu de bonnes expériences dès le début. Optimiser les premières interactions, périmètre réduit, documents frais, réponses fiables, est plus important que l'ambition du périmètre initial.

La question qu'on laisse ouverte : comment mesurer la valeur réelle d'un assistant documentaire interne quand la majorité des requêtes remplace des recherches qui n'auraient pas abouti, plutôt que des recherches qui auraient abouti plus lentement ?