Presque toutes les entreprises que nous rencontrons ont fait une démonstration d’IA générative convaincante. Trois semaines de travail, un assistant qui répond aux questions sur la documentation interne, un comité de direction impressionné. Puis douze mois pendant lesquels rien ne passe en production.
L’écart ne se situe pas dans le modèle. Il se situe dans quatre endroits que la démonstration a soigneusement évités : le choix du cas d’usage, la mesure de la qualité des réponses, le coût unitaire à l’échelle réelle, et les droits d’accès aux documents. Cet article décrit l’ordre dans lequel les traiter.
Commencer par écrire ce que vous ne ferez pas
La première décision utile est une décision de refus. Une IA générative est un système probabiliste : elle produit une réponse plausible, pas une réponse certifiée. Tant que ce point n’est pas admis explicitement par la direction, chaque projet se heurtera au même mur au moment de la mise en service.
Il existe donc une famille de cas d’usage à écarter d’emblée, non par prudence excessive mais parce que le coût de contrôle y dépasse le gain : toute décision produisant un effet juridique ou significatif sur une personne sans relecture humaine — tri de candidatures, évaluation de salariés, décision d’octroi —, tout calcul devant être exact et reproductible, et toute production destinée à être diffusée sans relecture sous la responsabilité de l’entreprise.
Écrire cette liste prend une heure. Elle vaut ensuite d’être affichée : elle protège les équipes des demandes impossibles et elle constitue le premier élément d’une gouvernance défendable.
Trois familles de cas d’usage, trois niveaux de difficulté
Les projets rentables se rangent presque toujours dans l’une de ces trois familles, par difficulté croissante.
La transformation de texte. Résumer un compte rendu, reformuler une réponse, traduire, extraire des champs structurés d’un document non structuré. L’entrée et la sortie sont visibles côte à côte, l’humain valide, le risque est faible. C’est le meilleur point de départ, et c’est aussi celui qui produit le plus de gain de temps immédiat.
La recherche augmentée. Répondre à une question en s’appuyant sur un corpus interne : procédures, contrats, documentation technique, historique de tickets. Le gain est important, la difficulté aussi, parce que la qualité dépend moins du modèle que de la recherche documentaire qui l’alimente.
L’action. Laisser un système déclencher une opération dans un outil métier — créer un ticket, modifier une fiche, envoyer un message. Le gain est réel, mais chaque erreur devient une écriture. Ce niveau se traite après avoir maîtrisé les deux premiers, avec des actions réversibles et journalisées.
Un conseil de séquencement : choisissez un cas d’usage de la première famille pour apprendre, et un seul de la deuxième pour créer de la valeur. Deux projets, pas huit.
Le coût par requête est une décision d’architecture
Une démonstration coûte quelques euros. Un service utilisé par 200 personnes ne coûte pas la même chose, et l’écart n’est pas linéaire : il dépend de choix qui se font au début et se corrigent mal ensuite.
Le calcul de base tient en une ligne : coût d’une requête égale nombre de jetons envoyés multiplié par le prix d’entrée, plus nombre de jetons produits multiplié par le prix de sortie. Les prix des modèles courants se comptent en euros par million de jetons, et ils baissent régulièrement — l’ordre de grandeur compte davantage que le tarif du jour.
Ce qui fait exploser la facture n’est presque jamais la longueur des réponses, c’est le contexte envoyé à chaque appel. Un système de recherche augmentée mal réglé expédie quinze extraits de documents à chaque question quand cinq suffisaient. Trois leviers, à évaluer dans cet ordre : réduire le nombre d’extraits en améliorant leur pertinence, activer la mise en cache de la partie stable de l’invite, et réserver le modèle le plus puissant aux requêtes qui le justifient au lieu de l’appliquer par défaut.
La latence obéit à la même logique. Mesurez le 95ᵉ centile, pas la moyenne : les utilisateurs abandonnent sur les requêtes lentes, et ce sont précisément celles que la moyenne dissimule.
Sans jeu de test, vous ne saurez jamais si le système fonctionne
C’est le point où la majorité des projets déraille, et c’est le moins coûteux à corriger.
Tant que la qualité s’évalue en essayant trois questions au hasard après chaque modification, aucune amélioration n’est démontrable et aucune régression n’est détectable. Il faut donc construire, avant d’optimiser quoi que ce soit, un jeu de test de référence : 50 à 100 questions réelles, prélevées dans les demandes que reçoivent vos équipes, accompagnées de la réponse attendue et des documents qui la fondent.
Ce jeu se constitue avec les métiers, en deux ateliers d’une demi-journée. C’est le seul investissement du projet qui conserve sa valeur quel que soit le modèle retenu ensuite.
Trois mesures suffisent à piloter :
- Le rappel de la recherche : le document contenant la réponse figure-t-il dans les extraits transmis au modèle ? Si la réponse est non, aucun réglage d’invite ne sauvera la requête.
- L’ancrage de la réponse : chaque affirmation produite est-elle soutenue par un extrait fourni ? C’est la mesure qui traite le sujet des réponses inventées.
- L’utilité perçue : la réponse règle-t-elle la question de la personne qui l’a posée ?
L’évaluation automatique par un modèle juge fait gagner un temps considérable, à condition de connaître ses biais — il favorise les réponses longues et les formulations proches des siennes. La règle que nous appliquons : faire noter à la main un échantillon de 30 réponses, mesurer l’accord avec le modèle juge, et n’automatiser que si cet accord est élevé.
Recherche augmentée : le sujet n’est pas le modèle, c’est la recherche
Quand un assistant documentaire répond mal, le réflexe est de changer de modèle. Dans la grande majorité des cas, le modèle n’est pas en cause : les bons extraits ne lui ont jamais été transmis.
Quatre réglages produisent l’essentiel du résultat. Le découpage d’abord : des fragments de quelques centaines de jetons, découpés sur les titres et les sections plutôt que tous les mille caractères, avec un recouvrement léger et le titre du document conservé dans chaque fragment. La recherche hybride ensuite : combiner la recherche lexicale et la recherche vectorielle, parce que la première trouve les références exactes — un numéro de procédure, une référence produit — que la seconde manque systématiquement. Le réordonnancement des candidats par un modèle spécialisé, qui améliore nettement la précision pour un coût modeste. Et enfin la citation obligatoire des sources, qui rend la vérification possible par l’utilisateur et transforme un assistant opaque en outil auditable.
Sur le plan technique, une base relationnelle avec une extension vectorielle suffit largement pour un corpus d’entreprise de quelques centaines de milliers de fragments. L’ajout d’un moteur spécialisé se justifie plus tard, sur des volumes ou des exigences de latence qui le demandent réellement.
Les droits d’accès sont le premier piège juridique
Un système de recherche augmentée hérite des droits du dossier qu’on lui a donné à indexer, pas des droits de la personne qui l’interroge. C’est l’incident le plus fréquent et le plus embarrassant : un assistant interne qui restitue à un salarié le contenu d’un dossier de ressources humaines ou une grille de rémunération, parce que l’indexation a ratissé un partage entier.
La règle est simple et non négociable : les autorisations se contrôlent au moment de la recherche, en filtrant les fragments selon l’identité de la personne qui pose la question, et non au moment de l’indexation. Toute autre approche produit une fuite tôt ou tard.
Deux précautions complètent le dispositif : conserver l’origine exacte de chaque fragment, et instaurer une revue périodique du périmètre indexé, parce que les partages évoluent plus vite que les projets.
AI Act et RGPD : ce qui est déjà exigible
Le règlement européen sur l’intelligence artificielle s’applique par étapes depuis 2025. Deux obligations concernent immédiatement une entreprise utilisatrice.
D’abord les pratiques interdites, applicables depuis février 2025 : notation sociale, exploitation de vulnérabilités, reconnaissance des émotions sur le lieu de travail, entre autres. Ensuite — et c’est la disposition la plus souvent ignorée — l’obligation de littératie : les organisations qui déploient des systèmes d’IA doivent garantir un niveau suffisant de maîtrise du sujet chez les personnes qui les utilisent, en tenant compte de leurs connaissances et du contexte d’usage. La formation n’est pas une bonne pratique dans ce texte, c’est une obligation datée.
Les régimes applicables aux systèmes à haut risque entrent en application plus tard et ont fait l’objet de discussions d’aménagement du calendrier : vérifiez l’état du texte avant d’arrêter un plan de conformité, plutôt que de vous fier à une infographie datée.
Côté RGPD, rien de nouveau mais rien d’optionnel : base légale du traitement, minimisation des données transmises au modèle, information des personnes, durée de conservation des historiques de conversation, encadrement contractuel du fournisseur et localisation du traitement. Une analyse d’impact devient nécessaire dès que l’usage touche des données sensibles ou produit des effets notables sur des personnes.
Une grille de décision en cinq questions
Avant d’engager un projet, cinq réponses écrites suffisent à trancher.
- Quelle décision ou quelle tâche cet outil doit-il améliorer, et pour qui ?
- À quoi ressemble une bonne réponse, et qui l’arbitre en cas de désaccord ?
- Quelles données seront transmises au modèle, et sont-elles autorisées à l’être ?
- Combien coûte une requête à l’échelle prévue, et quel volume mensuel est acceptable ?
- Qui relit, qui est responsable de la sortie, et comment le tracer ?
Un projet qui n’obtient pas ces cinq réponses n’est pas prêt. Ce n’est pas un problème de technologie : c’est un problème de cadrage, et il se règle en deux jours.