Quand une entreprise lance un projet d’IA générative, la première question posée est souvent : “Quel modèle faut-il utiliser ?” GPT, Claude, Gemini, Mistral, modèle open-source, API managée, modèle hébergé en interne… Le débat arrive très vite. Il est important, bien sûr. Le choix du modèle peut avoir un impact réel sur la qualité des réponses, les coûts, la sécurité ou encore les contraintes d’hébergement. Mais dans la majorité des projets que nous voyons, ce n’est pas uniquement le choix du modèle qui fait la réussite ou l’échec d’un projet. C’est d’abord la donnée. Pas parce qu’elle manque. Au contraire : les entreprises disposent souvent d’un volume important d’informations. Documents internes, bases de connaissances, tickets support, comptes rendus, historiques projets, contrats, procédures, échanges clients… La matière existe. Le problème, c’est que ces données sont rarement prêtes à être utilisées par un système IA. Elles sont dispersées, hétérogènes, parfois obsolètes, parfois contradictoires. Et quand on branche un LLM dessus trop vite, on ne crée pas de l’intelligence augmentée. On crée une interface très convaincante au-dessus d’un désordre documentaire. Le sujet n’est donc pas d’opposer le modèle et la donnée. Un bon modèle ne compensera pas durablement une donnée mal structurée, mais une bonne donnée doit aussi être servie par une architecture adaptée et un modèle pertinent. Un projet IA fiable repose sur un équilibre : des sources maîtrisées, un modèle adapté, une architecture robuste et des utilisateurs accompagnés dans leurs usages.  

Le fantasme du “chatbot qui sait tout”

Beaucoup de projets IA commencent avec une idée simple : “On va connecter un chatbot à notre documentation interne, et les collaborateurs pourront lui poser toutes leurs questions.” Sur le papier, c’est séduisant. En pratique, c’est rarement aussi simple. Un collaborateur demande : “Quelle est la procédure à suivre pour valider une demande client spécifique ?” Le système récupère trois documents :

• une procédure officielle de 2023 ;
• une note interne plus récente mais jamais validée ;
• un compte rendu de réunion qui évoque une exception.

Le LLM, lui, ne sait pas nécessairement quel document fait foi. Il va produire une réponse cohérente, fluide, probablement utile… mais potentiellement fausse. C’est là que beaucoup d’équipes découvrent une réalité assez brutale : un LLM ne résout pas les problèmes de gouvernance documentaire. Il les expose. Et c’est précisément pour cela que la donnée doit être pensée dès le départ. Non pas comme une simple matière première que l’on connecte à un modèle, mais comme un actif à structurer, qualifier et maintenir. Comme le raconte Hugo, développeur chez Olympp, à partir d’une expérience menée en mission : "Sur un projet d’assistant IA interne, nous avions une base documentaire assez riche, avec beaucoup d’informations utiles pour les équipes. Mais au moment de la mettre à disposition via l’IA, on s’est vite rendu compte que tout ne se valait pas : certains documents étaient à jour, d’autres obsolètes, certains validés officiellement, d’autres issus d’échanges de travail. Le vrai sujet a donc été de comprendre quelles sources pouvaient réellement faire foi, avant même de chercher à optimiser le modèle. Une fois ce socle clarifié, le choix du modèle et de l’architecture a pris tout son sens : il fallait une solution capable de restituer la bonne information, au bon utilisateur, dans un cadre sécurisé.” Ce retour terrain illustre bien une chose : la donnée est le point de départ, mais elle ne vit pas seule. Elle doit être organisée, hiérarchisée et intégrée dans une architecture pensée pour le cas d’usage.  

Le premier chantier : identifier les sources de vérité

Avant même de parler de RAG, d’embeddings ou de vector store, il faut répondre à une question beaucoup plus simple : quelles sont les sources fiables ? Toutes les données ne se valent pas. Une procédure validée par une direction métier n’a pas la même valeur qu’un document de travail. Un contrat signé n’a pas la même valeur qu’un modèle de contrat. Une documentation technique maintenue dans le repository n’a pas la même valeur qu’une page Notion oubliée depuis deux ans. Pour qu’un système IA soit fiable, il faut lui donner une hiérarchie documentaire explicite. Cela peut passer par des métadonnées simples :

• statut du document : brouillon, validé, obsolète ;
• propriétaire métier ;
• date de dernière mise à jour ;
• périmètre concerné ;
• niveau de confidentialité ;
• priorité en cas de conflit avec une autre source.

Ce travail n’est pas spectaculaire. Il ne produit pas forcément de démo impressionnante. Mais c’est souvent ce qui sépare un prototype amusant d’un outil réellement utilisable.  

Le deuxième chantier : nettoyer sans tout refaire

La tentation, face à une base documentaire désordonnée, est de vouloir tout nettoyer avant de commencer. C’est rarement réaliste. Les entreprises vivent avec de la dette documentaire, comme elles vivent avec de la dette technique. Vouloir tout corriger avant de lancer un projet IA revient souvent à ne jamais lancer le projet. La bonne approche est plus pragmatique : prioriser. On identifie d’abord les cas d’usage à forte valeur. Par exemple :

• répondre aux questions fréquentes des équipes support ;
• aider les commerciaux à retrouver les bons éléments d’un dossier client ;
• accélérer l’onboarding des nouveaux développeurs sur une codebase ;
• assister les équipes RH ou juridiques dans la recherche documentaire interne.

Puis on nettoie uniquement le corpus nécessaire à ces cas d’usage. C’est une logique d’ingénierie : on ne cherche pas à créer une base parfaite, on cherche à créer un système fiable sur un périmètre maîtrisé. La qualité de la donnée n’est donc pas un objectif abstrait. Elle doit toujours être reliée à un usage concret. Une base documentaire peut être imparfaite dans son ensemble, mais suffisamment fiable sur un périmètre précis pour permettre un premier cas d’usage utile.  

Le troisième chantier : gérer les droits d’accès

C’est l’un des sujets les plus sous-estimés. Dans une entreprise, tout le monde n’a pas accès aux mêmes informations. Un document financier, un contrat client, une donnée RH ou une note stratégique ne doivent pas être restitués à n’importe quel utilisateur sous prétexte qu’un assistant IA y a accès. Le problème est que beaucoup de prototypes IA sont construits comme si l’accès à la donnée était binaire : soit le système connaît le document, soit il ne le connaît pas. En production, ce n’est pas suffisant. Il faut que le système respecte les permissions existantes. Si un utilisateur n’a pas le droit de lire un document dans SharePoint, Google Drive, Notion ou Confluence, il ne doit pas pouvoir en obtenir le contenu via l’IA. Cela suppose une architecture sérieuse :

• authentification de l’utilisateur ;
• filtrage des documents récupérés selon ses droits ;
• logs d’accès ;
• règles de masquage pour les données sensibles ;
• vérification des outputs avant restitution dans les cas critiques.

Un assistant IA interne ne doit jamais devenir un contournement involontaire des règles de sécurité. C’est aussi ici que le choix du modèle et de l’architecture devient déterminant. Selon la sensibilité des données, le niveau de confidentialité attendu ou les contraintes internes de sécurité, une entreprise ne fera pas forcément les mêmes choix : API externe, hébergement privé, modèle open-source, SLM spécialisé, architecture RAG cloisonnée, système d’agents ou filtrage avancé des accès. La donnée est donc bien le point de départ, mais elle doit être rendue exploitable dans un cadre technique sécurisé.  

Le quatrième chantier : traiter l’obsolescence comme un risque produit

Une réponse IA peut être fausse pour deux raisons. La première : le modèle hallucine. La seconde, plus fréquente en entreprise : le modèle s’appuie sur une information qui était vraie hier, mais ne l’est plus aujourd’hui. C’est particulièrement critique pour les procédures internes, les offres commerciales, les règles RH, les politiques de sécurité ou les engagements contractuels. Un bon système doit donc savoir gérer la temporalité :

• privilégier les documents récents ;
• signaler quand une source est ancienne ;
• exclure les documents explicitement obsolètes ;
• afficher les sources utilisées ;
• permettre à un utilisateur de remonter une réponse incorrecte.

Dans certains cas, l’IA ne devrait même pas répondre directement. Elle devrait dire : “J’ai trouvé plusieurs sources contradictoires, voici les documents concernés, une validation humaine est nécessaire.” Ce n’est pas un échec. C’est une fonctionnalité de confiance. Une IA fiable n’est pas seulement une IA qui répond vite. C’est aussi une IA capable de reconnaître les limites de son périmètre, de signaler une incertitude et de ne pas transformer une contradiction documentaire en réponse artificiellement sûre d’elle.  

Pourquoi le sujet est autant organisationnel que technique

La donnée n’appartient pas uniquement aux équipes IT. Les métiers savent quels documents font foi. Les équipes sécurité savent quelles informations sont sensibles. Les équipes juridiques savent quelles formulations ne doivent pas être généralisées. Les développeurs savent comment construire le pipeline. Le produit sait quel niveau de réponse est acceptable pour l’utilisateur. Un projet IA sérieux oblige donc l’entreprise à clarifier ses responsabilités. Qui valide les sources ?
Qui maintient la base documentaire ?
Qui décide qu’un document est obsolète ?
Qui arbitre quand deux sources se contredisent ?
Qui est responsable si l’assistant donne une mauvaise réponse ? Ces questions peuvent sembler lourdes. Elles sont pourtant indispensables dès que l’IA sort du cadre de la démonstration. Mais la réussite ne dépend pas uniquement de la stack technique ou de la qualité documentaire. Un assistant IA ne devient pas utile simplement parce qu’il est bien conçu. Il doit aussi être compris, adopté et utilisé correctement par les équipes. Hugo le souligne également à travers son expérience en mission : “Une fois l’outil disponible, on voit vite que la technique ne suffit pas. Les utilisateurs doivent comprendre ce que l’assistant peut faire, mais aussi ce qu’il ne peut pas faire. Il faut leur expliquer comment formuler leurs demandes, comment lire les réponses, quand faire confiance au système et quand garder une validation humaine. Sans accompagnement, même une bonne architecture et une base documentaire propre peuvent être sous-utilisées ou mal utilisées.” La formation et l’accompagnement des équipes sont donc des leviers aussi importants que le choix du modèle, la structuration des données ou l’architecture technique. C’est souvent cette combinaison qui fait la différence entre un prototype intéressant et un outil réellement utilisé au quotidien.  

Notre approche chez Olympp

Chez Olympp, nous abordons les projets IA par le cas d’usage, pas uniquement par le modèle. Avant de choisir une stack technique, nous cherchons à comprendre :

• quelles questions l’utilisateur doit pouvoir poser ;
• quelles sources sont nécessaires pour y répondre ;
• quelles données sont sensibles ;
• quel niveau d’erreur est acceptable ;
• quelles réponses doivent être validées par un humain ;
• quelles traces doivent être conservées ;
• quels utilisateurs doivent être formés ou accompagnés dans l’usage de la solution.

Ensuite seulement viennent les choix d’architecture : RAG, agent, API managée, modèle open-source, SLM spécialisé, stockage vectoriel, observabilité, évaluation continue. La donnée n’est pas une étape préparatoire. C’est le socle du système. Mais ce socle doit être associé à une architecture adaptée, à un modèle pertinent et à une adoption réelle par les équipes. C’est cette combinaison qui permet de passer d’un prototype séduisant à une solution IA fiable, sécurisée et utile dans la durée.  

En synthèse

L’IA générative ne transforme pas automatiquement une base documentaire en connaissance fiable. Elle amplifie ce qui existe déjà. Si vos données sont propres, hiérarchisées, maintenues et gouvernées, l’IA peut devenir un accélérateur puissant. Si elles sont dispersées, obsolètes et contradictoires, l’IA risque surtout de rendre ce désordre plus visible — avec une couche de langage convaincante par-dessus. Mais le vrai sujet n’est pas seulement de choisir le meilleur modèle, ni de considérer que la donnée suffit à elle seule. C’est de construire un environnement complet où la donnée, le modèle, l’architecture et l’accompagnement des équipes fonctionnent ensemble. La donnée reste le socle : sans sources fiables, à jour et correctement gouvernées, aucun modèle ne peut produire durablement des réponses de confiance. Mais pour transformer cette donnée en outil réellement utile, il faut aussi faire les bons choix techniques, sécuriser les accès, maîtriser les coûts, adapter l’architecture au cas d’usage et accompagner les utilisateurs. Olympp accompagne les entreprises dans la conception de systèmes IA fiables, depuis la structuration des cas d’usage jusqu’à l’architecture technique, la mise en production et l’appropriation par les équipes. Notre conviction : une IA utile commence toujours par une donnée maîtrisée, et devient réellement performante lorsqu’elle s’inscrit dans un système cohérent, sécurisé et compris par ses utilisateurs.