Créer une base de connaissances à partir de vos documents (PDF, Word) en quelques minutes

Dans la plupart des entreprises, les réponses existent déjà. Elles dorment dans des PDF, des fichiers Word, des exports Excel ou d’anciennes pages web. Bonne nouvelle : pour créer une base de connaissances à partir de ces documents, plus besoin de lancer un chantier de wiki interne, d’organiser des ateliers d’arborescence ou de mobiliser un développeur. Grâce au RAG (génération augmentée par la recherche), vous déposez vos fichiers, le texte est indexé, et une IA répond aux questions en citant précisément les passages sur lesquels elle s’appuie. Ce guide détaille toute la démarche, du choix des documents aux tests, avec les pièges à éviter.

Une base de connaissances documentaire, c’est quoi au juste ?

Une base de connaissances classique, c’est un ensemble d’articles rédigés et mis à jour à la main : une FAQ, un centre d’aide, un intranet. La base de connaissances documentaire fonctionne à l’inverse. Vos documents existants restent la référence, et un outil les rend interrogeables en langage naturel.

Techniquement, c’est ce qu’on appelle le RAG. Quand quelqu’un pose une question, le système commence par retrouver les passages les plus pertinents dans vos documents, puis demande à un modèle de langage de rédiger une réponse à partir de ces seuls passages, avec des citations. Pour aller plus loin, lisez notre guide de référence Qu’est-ce que le RAG ?. En résumé : l’IA n’a pas besoin d’avoir « appris » vos contenus, elle les lit au moment de répondre.

Pourquoi partir des documents que vous avez déjà ?

Parce que c’est là que se trouve l’effet de levier. Rédiger de la documentation coûte cher ; la réutiliser ne coûte presque rien. Une bibliothèque de modèles de contrats, des procédures internes, une notice produit ou des années de notes de conseil représentent un savoir considérable, aujourd’hui accessible uniquement à ceux qui savent où chercher.

• Des réponses plus rapides : on pose une question au lieu d’ouvrir dix fichiers et de chercher avec Ctrl+F.
• Des réponses cohérentes : tout le monde obtient une réponse fondée sur les mêmes documents de référence.
• Des réponses vérifiables : chaque affirmation renvoie à un passage, que le lecteur peut contrôler.
• Une base exploitable par des agents IA : exposée via une API ou le protocole MCP, elle peut être consultée par des assistants et agents IA (Claude, Cursor, ChatGPT ou le vôtre), pas seulement par des humains.
• Une expertise à partager : si vos documents renferment une vraie expertise, vous pouvez ajouter la base à une bibliothèque que d’autres interrogent, et être rémunéré quand ils l’utilisent (voir comment partager votre expertise sous forme de base de connaissances).

Étape 1 : sélectionner les bons documents

La qualité des réponses dépend presque entièrement de ce que vous y mettez. Avant de déposer quoi que ce soit, définissez le périmètre de la base en une phrase, par exemple : « Tout ce dont le service client a besoin pour répondre aux questions de facturation » ou « Le droit du travail applicable aux petits établissements de la restauration, convention collective HCR comprise ». Une base ciblée répond mieux qu’un fourre-tout.

• Gardez les documents à jour et qui font foi. Écartez les brouillons, les versions remplacées et les doublons, sinon l’IA risque de citer une règle périmée.
• Privilégiez les documents contenant du vrai texte. Un PDF exporté depuis Word ou une page web a une couche texte ; une photocopie scannée, souvent non.
• Misez sur les documents de référence (procédures, guides, politiques internes, FAQ) plutôt que sur le bruit conversationnel (fils d’e-mails, comptes rendus informels).
• Vérifiez que vous avez le droit d’utiliser et de diffuser chaque document, surtout si la base est publique. Pensez aussi au RGPD si des données personnelles y figurent.

Étape 2 : nettoyer et structurer vos fichiers

Inutile de tout réécrire, mais un minimum de préparation change beaucoup de choses. Un système RAG découpe les documents en passages ; chaque passage doit pouvoir se comprendre seul. Des titres clairs, des paragraphes courts et des termes explicites aident la recherche à tomber sur le bon extrait.

1. Donnez à chaque fichier un titre explicite et, idéalement, une date ou un numéro de version dans le document.
2. Utilisez de vrais styles de titres plutôt que des lignes en gras, pour que la structure survive à l’extraction.
3. Remplacez les renvois flous (« voir ci-dessus », « la règle précédente ») par des références explicites quand c’est important.
4. Développez les sigles au moins une fois par document : les utilisateurs ne poseront pas toujours la question avec la même abréviation (CSE, DPAE, TVA…).
5. Simplifiez les tableaux complexes, ou ajoutez une phrase qui résume ce qu’ils montrent.

Nous détaillons tout cela dans comment préparer vos documents pour l’IA, avec des modèles de procédures et de FAQ.

Étape 3 : importer et indexer les documents

C’est l’étape qui exigeait autrefois un développeur et qui prend désormais quelques minutes. Quel que soit l’outil, l’indexation suit la même logique : extraire le texte, le découper en passages, puis construire un index qu’on peut interroger rapidement.

Les approches d’indexation varient. Certains outils transforment les passages en vecteurs (embeddings) et cherchent par similarité sémantique ; d’autres s’appuient sur la recherche plein texte avec racinisation selon la langue ; les systèmes hybrides combinent les deux. Chaque méthode a ses compromis, que nous expliquons dans le fonctionnement d’un pipeline RAG.

Comment Kopik construit la base pour vous

Sur Kopik, la création d’une base est gratuite. Vous lui donnez une thématique et une langue de document, puis vous déposez vos fichiers ou collez du texte : PDF (avec couche texte, 1 500 pages maximum), Word (.docx) et formats texte comme .txt, .md, .csv, .tsv, .json, .html ou .xml, jusqu’à 4 Mo par fichier et 2 millions de caractères par document. Le texte est découpé en passages d’environ 1 200 caractères avec un chevauchement d’environ 200 caractères, en coupant d’abord sur les paragraphes puis sur les phrases, et indexé aussitôt avec la recherche plein texte de PostgreSQL. Une base peut contenir jusqu’à 1 000 documents et 20 millions de caractères, et chaque compte peut créer jusqu’à 20 bases.

La langue du document (français, anglais, allemand, espagnol, italien, portugais, néerlandais, ou Mixte/autre) compte plus qu’il n’y paraît : elle règle la racinisation et les mots vides de la recherche plein texte, pour que « factures » retrouve « facture » et que les mots outils soient ignorés. Choisissez la langue dans laquelle vos documents sont rédigés, ou Mixte/autre s’ils en mélangent plusieurs. Vous pourrez la modifier ensuite : la base est alors réindexée, ce qui est possible quelques fois par heure.

Au moment de la question, un petit modèle de langage enrichit la requête avec des mots-clés et des synonymes dans la langue des documents : une question posée dans une autre langue retrouve donc quand même les bons passages. Les 8 passages les plus pertinents sont récupérés (recherche plein texte, sans base vectorielle), puis un modèle de langage rédige la réponse à partir de ces seuls passages, avec des citations numérotées. Si la base ne contient pas la réponse, elle le dit. Vous pouvez ajouter ou retirer des documents à tout moment.

Étape 4 : tester les réponses avant de partager

Ne publiez jamais une base que vous n’avez pas interrogée vous-même. Dressez une liste de 15 à 30 vraies questions, celles que vos clients ou vos collègues posent réellement, et confrontez chaque réponse aux documents.

• La réponse est-elle juste ? Ouvrez les passages cités et vérifiez.
• Est-elle complète ? S’il manque un détail clé, le passage concerné est peut-être mal rédigé ou mal découpé.
• Sait-elle dire « je ne sais pas » ? Posez une question hors périmètre. Une bonne base indique qu’elle n’a rien trouvé au lieu d’inventer.
• La formulation change-t-elle tout ? Reposez la même question avec d’autres mots, des synonymes ou des sigles.
• D’anciennes versions ressortent-elles ? Si la réponse cite une règle périmée, retirez le fichier en cause.

Étape 5 : choisir qui peut y accéder

Le niveau d’accès dépend du contenu. Une base sur la politique RH interne doit rester privée. Un guide sur une réglementation publique peut être largement diffusé. La plupart des outils proposent une variante de ces trois niveaux.

Kopik propose exactement ces trois options, et chaque base dispose de sa propre page partageable. Une base non listée n’est accessible que par son lien, qui contient un long identifiant aléatoire. Une base privée n’est pas qu’un brouillon : vous pouvez l’interroger vous-même depuis le site, l’API REST ou MCP, gratuitement (usage raisonnable : 200 questions par jour). Les bases publiques apparaissent dans le catalogue des bases de connaissances, classées par thématique (juridique, RH et emploi, fiscalité et comptabilité, santé, immobilier, tech et produit, etc.). Si vos documents contiennent des données personnelles ou confidentielles, gardez la base privée et vérifiez vos règles internes (et le RGPD) avant de la partager.

Étape 6 : mettre la base au travail

Une base de connaissances n’a de valeur que si on l’interroge. Il existe trois façons courantes de la brancher.

• Le chat web : vous partagez le lien, les utilisateurs posent leurs questions dans le navigateur.
• L’API REST : votre application, votre site ou votre outil interne envoie une question et reçoit une réponse sourcée, ou seulement les passages pertinents si vous voulez que votre propre modèle raisonne dessus.
• Le protocole MCP : les assistants et agents IA (Claude, Cursor, ChatGPT ou le vôtre) se connectent à la base et la consultent quand ils en ont besoin. Voir comment connecter une base de connaissances à Claude avec MCP.

Kopik gère ces trois modes. L’API et le serveur MCP utilisent une clé d’API créée depuis votre tableau de bord ; tout est expliqué dans la documentation développeurs. Sur une base privée, tout cela est gratuit pour vous : vos documents deviennent le RAG de vos propres agents, sans aucune infrastructure à gérer. Voir comment utiliser une base de connaissances privée comme RAG pour vos agents IA.

Les erreurs fréquentes quand on crée une base de connaissances

• Tout verser en vrac. Plus de documents ne veut pas dire de meilleures réponses. Des fichiers contradictoires ou obsolètes dégradent la recherche.
• Mélanger des sujets sans rapport. Une base sur la fiscalité et une base sur la prise en main d’un logiciel doivent être deux bases distinctes.
• Négliger la langue. La recherche plein texte repose sur une racinisation propre à chaque langue : réglez la langue de document de la base sur celle de vos fichiers, ou choisissez Mixte/autre s’ils mélangent plusieurs langues.
• Sauter les tests. Le premier vrai utilisateur ne doit pas être celui qui découvre que la base ne sait pas répondre à la question évidente.
• Ne jamais mettre à jour. Programmez une revue des documents à chaque changement de règle, de tarif ou de procédure.
• Attendre de l’IA qu’elle comble les trous. Un bon système RAG répond à partir de vos documents. Si l’information n’y est pas, la bonne réponse est « non trouvé ».

Check-list : votre base de connaissances en 30 minutes

1. Formulez le périmètre de la base en une phrase.
2. Rassemblez les documents à jour et qui font foi ; supprimez doublons et brouillons.
3. Vérifiez que le texte des PDF est sélectionnable ; passez les scans à l’OCR ou remplacez-les.
4. Ajoutez titres, intertitres et numéros de version là où ils manquent.
5. Créez la base, réglez sa langue de document et sa thématique, déposez les fichiers.
6. Posez 15 à 30 vraies questions et contrôlez les passages cités.
7. Corrigez les documents sources là où les réponses pèchent, puis retestez.
8. Choisissez la visibilité : privée, non listée ou publique.
9. Partagez le lien, ou branchez la base via l’API ou MCP.