Presque toutes les PME que nous rencontrons ont déjà vu une démonstration d'assistant IA capable de répondre à partir de leurs propres documents. Presque aucune n'a ce type d'outil réellement en service. L'écart ne vient pas de la technologie, il vient de la façon dont le prototype a été cadré. Voici la méthode que nous appliquons pour transformer une idée d'assistant documentaire en preuve de valeur mesurée, en trois semaines.

Pourquoi tant de démonstrations d'IA documentaire restent des démonstrations

Les chiffres publiés sur le sujet varient selon les méthodologies, mais ils convergent tous dans la même direction. Une étude IDC largement reprise en 2025 et 2026 avance que sur trente-trois prototypes d'IA construits, quatre seulement atteignent la production. D'autres travaux, dont le rapport de tendances de DZone consacré à l'IA générative, situent entre 70 et 95 pour cent la proportion de pilotes qui n'arrivent jamais en service selon les secteurs.

La cause est presque toujours la même, et elle est peu technique. Un prototype est construit pour convaincre une direction, pas pour durer. On le nourrit avec dix documents propres et des questions dont on connaît déjà la réponse. En production, le corpus contient quinze ans de fichiers hétérogènes, les questions sont mal formulées, et personne n'a défini qui répond de la réponse fausse. Un prototype utile cherche donc à échouer tôt, sur des cas réels, plutôt qu'à briller sur des cas choisis.

Étape 1 : choisir une question métier, jamais une technologie

Le pire point de départ est la phrase nous voudrions un assistant sur nos documents. Le bon point de départ est une tâche identifiable, répétitive et coûteuse. Quelques exemples que nous croisons souvent en PME, en association et en collectivité :

  • retrouver la clause de pénalité applicable dans un marché ou un contrat cadre signé il y a trois ans ;
  • répondre à une question de premier niveau du support en s'appuyant sur la documentation produit et les tickets déjà résolus ;
  • préparer une réponse à appel d'offres en réutilisant les mémoires techniques passées ;
  • vérifier qu'une procédure qualité est bien la dernière version applicable avant un audit.

Le critère de sélection tient en une question. Combien de fois par semaine cette tâche est-elle réalisée, par combien de personnes, et combien de minutes prend-elle ? Si le produit de ces trois nombres ne représente pas au moins quelques heures hebdomadaires, le sujet ne financera jamais son industrialisation.

Étape 2 : constituer le corpus et le jeu de questions de référence

C'est la partie la plus ingrate et la plus déterminante. Elle occupe généralement toute la première semaine.

Côté corpus, prenez un échantillon représentatif et non un échantillon flatteur. Incluez volontairement des documents scannés, des versions obsolètes, des tableurs, des fichiers dont le titre ne dit rien du contenu. Notez pour chaque source son format, son volume, son emplacement et surtout qui a le droit de la lire. Cette dernière colonne est celle qui fait dérailler la moitié des projets plus tard : un assistant qui ignore les habilitations n'ira jamais en production dans une organisation sérieuse.

Côté questions, rédigez avec les utilisateurs finaux entre trente et cinquante questions réelles, avec la réponse attendue et le document où elle se trouve. Ce jeu de référence devient votre unité de mesure pour tout le reste du prototype. Rédigez-le avant de choisir le moindre outil, faute de quoi vous ajusterez inconsciemment les questions à ce que le système sait déjà faire.

Étape 3 : assembler la chaîne la plus simple qui puisse fonctionner

Un assistant documentaire repose sur un principe de recherche augmentée : on ne demande pas au modèle de savoir, on lui demande de répondre uniquement à partir d'extraits retrouvés dans vos documents. La chaîne minimale comporte cinq maillons.

  1. Extraction : convertir chaque document en texte exploitable, y compris les PDF scannés qui exigent une reconnaissance optique de caractères.
  2. Découpage : segmenter les textes en passages cohérents. Un découpage aveugle tous les mille caractères coupe les tableaux et les articles en deux, et cause bien plus d'erreurs que le choix du modèle.
  3. Indexation : calculer les représentations vectorielles et les stocker en conservant, pour chaque passage, sa source, sa date et son niveau de confidentialité.
  4. Recherche : retrouver les passages pertinents, idéalement en combinant recherche vectorielle et recherche par mots-clés, puis en réordonnant les résultats.
  5. Génération : demander au modèle une réponse fondée sur ces seuls passages, avec citation systématique des documents utilisés.

Au stade du prototype, résistez à l'architecture ambitieuse. Pas d'agent multi-étapes, pas de mémoire longue, pas d'orchestration complexe : ces briques se justifient quand le socle documentaire donne déjà de bons résultats, jamais avant. La question de l'hébergement, en revanche, se tranche immédiatement. Si le corpus contient des données personnelles ou des informations contractuelles sensibles, le choix du fournisseur et de la région d'hébergement fait partie du cadrage, pas des finitions.

Étape 4 : mesurer, arbitrer, décider

La troisième semaine sert à passer le jeu de questions de référence et à produire trois chiffres.

  • Taux de récupération : dans quelle proportion le bon document figure-t-il parmi les extraits retrouvés ? Si ce taux est faible, inutile de changer de modèle de langage, le problème se situe en amont.
  • Taux de réponse exacte : la réponse est-elle juste, complète et correctement sourcée ? Faites relire par un expert métier, pas par l'équipe technique.
  • Taux d'abstention : quand l'information n'existe pas, l'assistant dit-il qu'il ne sait pas ? Un système qui invente est plus dangereux qu'un système qui se tait, en particulier sur des sujets contractuels ou réglementaires.

Ces trois indicateurs permettent une décision honnête en fin de prototype : industrialiser, corriger le corpus et relancer une itération courte, ou renoncer. Renoncer après trois semaines et un budget maîtrisé est un excellent résultat. Renoncer après neuf mois de projet ne l'est pas.

Prévoyez également une estimation du coût à l'usage : nombre de requêtes attendues par mois, coût unitaire observé pendant le prototype, coût de réindexation quand les documents évoluent. Beaucoup de projets franchissent la barrière technique et échouent sur cette arithmétique.

Les cinq erreurs qui coûtent le plus cher

Nous les rencontrons systématiquement, et elles n'ont rien d'exotique.

  1. Traiter les habilitations à la fin. Un assistant qui expose à tous un document réservé à trois personnes est un incident, pas une finition à corriger plus tard.
  2. Mesurer à l'oeil. Sans jeu de questions, la moindre modification devient une croyance et les arbitrages se transforment en débats d'opinion.
  3. Confondre le prototype et le produit. La mise en service ajoute la journalisation, la reprise sur erreur, la mise à jour de l'index, la formation des utilisateurs et un responsable identifié.
  4. Nettoyer le corpus pour la démonstration. Vous testez alors une organisation documentaire idéale qui n'existera jamais dans la vraie vie.
  5. Oublier le retour utilisateur. Un simple bouton pour signaler une réponse insatisfaisante alimente le jeu de tests et constitue la matière première des itérations suivantes.

Questions fréquentes

Combien de temps faut-il pour prototyper un assistant IA documentaire ?

Trois semaines suffisent pour obtenir une preuve de valeur mesurée sur un périmètre unique et bien délimité. Au delà de six semaines sans décision, le prototype devient un projet qui n'ose pas dire son nom.

Faut-il entraîner un modèle sur nos propres données ?

Dans la grande majorité des cas rencontrés en PME, non. La recherche augmentée interroge vos documents au moment de la question, ce qui évite un réentraînement à chaque mise à jour documentaire et permet de citer les sources. Le réglage fin d'un modèle répond à d'autres besoins, comme un format de sortie très particulier.

Nos documents peuvent-ils rester hébergés en France ?

Oui, et c'est un choix d'architecture à poser dès le cadrage. Selon la sensibilité du corpus, on retient un fournisseur proposant un hébergement européen ou un modèle déployé sur une infrastructure maîtrisée, ce qui influe sur le coût et sur le niveau de qualité attendu.

Que faire si le prototype donne de mauvais résultats ?

Regardez d'abord le taux de récupération. Dans la plupart des cas, le problème vient du découpage des documents ou de la qualité de l'extraction, pas du modèle de langage. Un corpus mal préparé ne sera sauvé par aucun modèle, aussi récent soit-il.

Ce prototype peut-il servir de base à l'application finale ?

La chaîne de traitement et le jeu de questions se réutilisent, l'interface et l'exploitation sont à reconstruire. Il est plus sain de considérer le prototype comme un instrument de mesure que comme la première version du produit.

Vous disposez d'un fonds documentaire important et d'une tâche répétitive qui pèse sur vos équipes ? Nous cadrons le périmètre, construisons le prototype et vous remettons les chiffres qui permettent de décider. Parlons de votre projet.