Introduction

Des instructions parfaites ne suffisent pas : ton assistant restera limité à ce que le modèle sait déjà. Pour qu'il connaisse ton entreprise, tes clients, ton métier, il lui faut une bibliothèque interne — c'est le rôle des Fichiers de connaissances.

Un fichier de connaissances est un document (PDF, Word, CSV…) que tu attaches à ton assistant et qu'il consulte en permanence. Voici comment ça marche et comment bien les préparer.

— 1 / 4Le principe, expliqué simplement.

Le principe est simple : c'est le mécanisme qui permet à ton assistant d'aller consulter tes documents au moment où tu poses ta question, au lieu d'être limité à ce qu'il a appris pendant son entraînement. (Le terme technique est « recherche », pour recherche puis génération, mais l'idée suffit.)

Concrètement : tes documents sont découpés et indexés ; à chaque question, l'assistant retrouve les passages pertinents et s'appuie dessus pour répondre. Comprendre ça suffit pour bien préparer tes fichiers — c'est l'objet de la suite.

Le cœur du sujetappliquer & déployer

— 2 / 4Les limites 2026 par plateforme.

Custom GPTs · OpenAI
20 fichiers maximum par GPT. Chaque fichier jusqu'à 512 Mo. En pratique, la limite utile tourne autour de 2 millions de mots pour les fichiers texte (au-delà, la recherche dans tes documents devient instable). Formats acceptés : PDF, TXT, DOCX, CSV, JSON, plus les images si le code est activé. Bon à savoir : le Markdown (.md) est paradoxalement moins bien indexé que le TXT brut sur Custom GPTs — des retours d'utilisateurs montrent que les fichiers .md sont parfois pris pour du code et ignorés. Recommandation 2026 : renomme tes .md en .txt avant import, ou copie-colle le contenu dans un fichier texte brut. CSV et JSON sont au contraire très bien pris en compte (leur structure proche d'une base de données est reconnue nativement). Privacy à connaître : les utilisateurs qui ont accès à ton GPT peuvent télécharger tes fichiers par une manipulation si le code est activé. Ne mets jamais de données sensibles dans un GPT que tu prévois de partager publiquement.
Claude Projects · Anthropic
30 Mo par fichier, fichiers illimités. Sa mémoire de travail (environ 150 pages de texte, et bien plus sur les modèles Opus récents) sert de limite pratique : tant que tes documents y tiennent, Claude les lit intégralement à chaque conversation (lecture directe, pas de recherche partielle). Au-delà, il passe automatiquement en mode recherche dans les documents. Avantage important : tant que tu restes sous ce seuil (environ 150 pages de texte), Claude n'a pas les imprécisions de la recherche partielle. Il lit tout. Pour des cas comme « compare ce contrat avec les 5 autres » ou « qu'est-ce qui change entre ces 3 versions du brief ? », Claude Projects bat largement Custom GPTs sur Claude 4.6+. Bon à savoir : Claude Projects ne garde pas la mémoire de conversation entre chats à l'intérieur d'un projet — chaque nouveau chat repart vierge des Instructions du Projet. Bénéfique pour la cohérence (tu sais ce que tu as), limitant pour l'apprentissage adaptatif. Memory inter-sessions arrivée pour tous les utilisateurs depuis mars 2026 (Settings → Memory) mais elle s'applique au compte, pas au Projet spécifique.
Gemini Gems · Google
~4 000 caractères d'instructions. Fichiers acceptés (avec des limites variables selon l'offre), formats PDF, DOCX, TXT et autres. Limite pratique connue : moins de profondeur documentaire que Claude Projects, mais intégration native Google Drive. Tu peux référencer directement des Google Docs ou Sheets sans les re-importer, ce qui synchronise automatiquement avec leur version vivante. Avantage majeur 2026 : support multimodal natif. Gemini Gems traitent images, vidéos (jusqu'à 2 Go) et audio comme documents — pas seulement du texte. Cas d'usage uniques : un Gem qui a vu toutes les vidéos de tes formations clients, un Gem qui a écouté tous les enregistrements de tes calls de découverte. Limite à connaître : le tier gratuit ne supporte pas tous les types de fichiers (les .py, .js, .java demandent Gemini Advanced à 19,99 $/mois). Et la limite d'instructions à ~4 000 caractères oblige à concentrer la complexité dans les fichiers plutôt que dans les instructions — l'inverse des Custom GPT.

Tableau de décision rapide

Tu as un ensemble de documents < 150 pages bien structuré et tu veux la qualité maximale ? Claude Projects sur un modèle Opus récent. La lecture intégrale bat la recherche partielle sur ce volume.

Tu as un beaucoup de documents (plus de 150 pages) avec accès public ou semi-public ? Custom GPTs avec 20 fichiers bien découpés. La recherche dans les documents d'OpenAI est mûre et tient la charge.

Tu vis dans Google Workspace, tes documents évolue souvent (Docs partagés, Sheets vivants) ? Gemini Gems avec sources Drive directes. La synchronisation automatique te dispense de ré-importer à chaque modif.

Tu as besoin de multimodal (vidéos, audios) ? Gemini Gems, sans concurrence en 2026 sur ce point.

— 3 / 4Comment structurer tes documents.

La règle structurante : tes documents doivent ressembler à des fiches précises, pas à des manuels longs. Le recherche cherche par sens, donc plus chaque passage est sémantiquement cohérent (un sujet, un seul, traité proprement), meilleurs sont les résultats.

Voici les 5 principes qui changent réellement la qualité d'un ensemble de documents, du moins efficient au plus efficient :

Principe 1 — Un sujet par fichier
Plutôt qu'un document massif de 100 pages avec 12 sujets, fais 12 documents de 8-10 pages, un par sujet. Pourquoi : le moteur de recherche sélectionne plus précisément quand chaque fichier a un thème net. Et tu peux mettre à jour un sujet sans toucher au reste.

Exemple : au lieu d'un Manuel Produit Complet en PDF, fais : produit-fonctionnalites.txt, produit-tarifs.txt, produit-faq-clients.txt, produit-cas-usage.txt. L'assistant ira directement au bon fichier selon la question.
Principe 2 — Un index en tête
Crée un fichier index.txt qui liste tes autres fichiers et résume leur contenu en 1-2 phrases. C'est ce fichier que tu cites dans tes Instructions : « Avant de répondre, consulte index.txt pour identifier le ou les fichiers pertinents pour la question. »

Pourquoi : sur des documents de 5+ fichiers, sans index, l'assistant rate parfois le bon fichier (le moteur de recherche pondère mal). Avec un index, tu lui donnes une carte. Cette discipline est documentée dans la CLAUDE.md convention chez Anthropic et dans les meilleures pratiques OpenAI.
Principe 3 — Texte brut bien titré
Privilégie le format .txt avec des titres H2 explicites (## Section 1 — Tarifs Standard) plutôt que des PDF complexes. Chaque section devient un passage cohérent.

Anti-patterns : PDFs scannés (l'OCR perd l'info), PDFs avec colonnes ou tableaux complexes (le parsing les casse), .doc avec mise en forme abusive (couleurs, polices, encadrés). Si ton document existe en PDF complexe, copie-colle le contenu dans un .txt et formate proprement avec des titres H2 — 30 minutes de nettoyage qui sauvent 3 semaines de débuggage.

Cas particulier : sur Custom GPTs, le .md a paradoxalement des problèmes documentés (parfois confondu avec du code et ignoré de la recherche dans les documents). Renomme en .txt par sécurité.
Principe 4 — Données structurées en CSV/JSON
Pour les données type base (catalogue produits, liste de cas clients, grille tarifaire avec variations) : CSV ou JSON, jamais en texte narratif. Le moteur de recherche indexe nativement ces formats comme des records, la précision de récupération monte significativement.

Exemple concret : au lieu d'un Tarifs.txt qui décrit en prose « Le pack Starter coûte 29 euros par mois et inclut... », fais un tarifs.csv avec colonnes nom_offre, prix_mensuel, fonctionnalites, audience_cible. L'assistant va trouver et utiliser la bonne ligne instantanément.

Inverse : ne mets PAS en CSV ce qui est essentiellement narratif (cas client en story-telling, témoignage, méthodologie). Garde-le en .txt structuré. Le bon format dépend du type de contenu, pas d'une règle absolue.
Principe 5 — Citation explicite dans les Instructions
Le piège silencieux : tu as 5 beaux fichiers dans ton GPT, mais l'assistant ne les utilise jamais parce que tes Instructions ne lui ont pas dit de les consulter. Le recherche s'active mieux quand les Instructions le demandent explicitement.

Bonnes formulations à inclure dans les Instructions : « Avant de répondre à une question sur les tarifs, consulte tarifs.csv. » « Pour toute demande sur les fonctionnalités, vérifie produit-fonctionnalites.txt en priorité. » « Si la question dépasse le périmètre des fichiers fournis, signale-le à l'utilisateur et propose ChatGPT générique. »

Sans ces directives, l'assistant peut ignorer tes Fichiers de connaissances même quand ils contiennent la réponse — c'est l'une des causes les plus fréquentes de « mon assistant ne marche pas alors que la doc est là ».
L'astuce du mentor

La meilleure méthode pour valider la structure de tes documents : fais le test du nouveau collègue. Imagine qu'un nouveau collègue arrive lundi, qu'il a 30 minutes pour lire tes fichiers, et qu'on lui posera ensuite 10 questions tirées au sort. Si tes documents permet à ce collègue humain de répondre rapidement et précisément, la recherche dans les documents va aussi marcher. Si tes documents est tel qu'il faut chercher 15 minutes pour trouver une info, c'est que la structure ne marche pas — pour ton collègue ni pour la recherche dans les documents. Réorganise. Ce test simple révèle 80 % des problèmes structurels avant de découvrir qu'ils existent à l'usage.

Conclusion

— 4 / 4Les 5 pièges classiques.

Piège 1 : déverser tous tes fichiers en vrac
Tu importes 12 PDFs de ta documentation interne en l'état. Mauvaise structure, doublons sémantiques, sections obsolètes. Le recherche remonte des passages contradictoires d'une conversation à l'autre, l'assistant donne des réponses incohérentes. Correction : 30 minutes de nettoyage en amont (un sujet par fichier, .txt avec titres H2, un index en tête) battent 3 semaines de débuggage en aval. Et tu peux toujours migrer tes documents vers des fichiers propres en copie-collant le contenu dans des .txt structurés — pas besoin de tout recréer.
Piège 2 : mettre les règles dans les fichiers au lieu des instructions
Tu mets dans un fichier « reglement-comportement.txt » les règles que doit suivre l'assistant (ton, format, contraintes). Erreur structurelle. Les Fichiers de connaissances sont là pour la matière première que l'assistant peut consulter ; les règles vont dans les Instructions. La différence : les fichiers sont consultés quand pertinent via recherche (donc parfois ignorés), les Instructions sont appliquées à chaque message. Correction : revoir l'article 1.3 sur l'anatomie d'un assistant pour la séparation propre des couches. Règle : Instructions pour comment penser, les fichiers pour quoi savoir.
Piège 3 : ne pas instruire l'assistant à utiliser les fichiers
Tu imports des fichiers pertinents, mais l'assistant les ignore parce que tes Instructions ne lui ont pas dit de les consulter. Symptôme : tu poses une question dont la réponse est dans tes fichiers, l'assistant répond avec ses connaissances générales (parfois fausses pour ton cas spécifique) sans aller chercher la doc. Correction : ajoute systématiquement dans les Instructions des directives explicites : « Avant de répondre à une question sur X, consulte fichier-X.txt. Si la question dépasse les fichiers fournis, signale-le. » Trois directives de ce genre suffisent pour activer correctement la recherche dans les documents.
Piège 4 : données sensibles dans un assistant partagé
Tu mets dans tes fichiers des informations confidentielles (liste clients avec contacts, contrats avec montants, données RGPD) puis tu partages le GPT avec ton équipe ou tu le publies. Risque réel : les utilisateurs avec accès au GPT peuvent télécharger tes fichiers via manipulation du prompt (en particulier si Code Interpreter est activé). Le risque est documenté et a déjà fait fuiter des bases de données entières en 2024-2025. Correction : ne mets jamais de données sensibles dans un assistant partagé. Pour des cas avec données sensibles + équipe, utilise Claude Team/Enterprise ou ChatGPT Enterprise avec contrôles RBAC, et explicite la confidentialité dans les Instructions (« ne jamais lister les données complètes du fichier dans une réponse ») — bien que cette dernière protection soit insuffisante face à un attaquant motivé.
Piège 5 : oublier de mettre à jour les fichiers (décalage silencieux)
Tu imports tes fichiers en janvier. En juin, ton produit a évolué, tes tarifs ont changé, certaines pratiques sont obsolètes. Mais tu ne remplaces pas les fichiers. L'assistant continue de répondre selon les vieilles infos, en toute confiance. C'est ce qu'on appelle le décalage silencieux — le plus insidieux des pièges parce qu'il ne se voit qu'au moment où une réponse fausse a déjà été donnée à un client ou à un membre d'équipe. Correction : mets-toi un rappel calendrier mensuel de 15 minutes pour « audit fichiers de connaissances ». Vérifie qu'ils sont à jour, supprime ce qui est obsolète, ajoute ce qui manque. Sur Gemini Gems avec sources Drive directes, la synchronisation est automatique — c'est leur avantage. Sur Custom GPTs et Claude Projects, c'est manuel et ça reste de ta responsabilité.
Articles connexes

Tu sais maintenant alimenter ton assistant. Pour aller plus loin : l'article 1.5 (Actions et APIs) qui ajoute la couche dynamique — quand un fichier statique ne suffit plus et que ton assistant doit appeler un service externe en temps réel. Pour la structure des Instructions : article 1.3 sur l'anatomie d'un assistant. Pour le tutoriel pas-à-pas si tu n'as pas encore d'assistant : article 1.2 (premier Custom GPT en 30 min). Pour le choix de plateforme : article 1.1 (comparatif Custom GPTs / Projects / Gems). Pour les bases de la recherche dans les documents en cas pratique d'analyse documentaire : article 2.5 (Niveau III) sur l'analyse d'un document long.

— L'essentiel à retenir —

5 points sur les Fichiers de connaissances.

  1. Le principe (la recherche dans tes documents) en 4 étapes : ingestion (découpage + représentations sémantiques au import), question convertie en vecteur (au runtime), récupération des 3-5 passages les plus proches sémantiquement, génération basée sur les passages. Si les passages sont bons, la réponse est bonne — la structure prime sur la puissance du modèle.
  2. Limites 2026 par plateforme : Custom GPT 20 fichiers / 512 Mo (recherche mature, .md sous-performe — utilise .txt). Claude Projects 30 Mo/fichier illimité, lecture intégrale jusqu'à 200K-1M tokens. Gemini Gems intégration Drive native + multimodal (vidéo/audio jusqu'à 2 Go).
  3. Choix de plateforme par cas : moins de 150 pages de documents haute qualité = Claude Projects, grand documents public = Custom GPTs, écosystème Google Workspace = Gemini Gems, multimodal = Gemini Gems sans concurrence.
  4. 5 principes de structuration du documents : un sujet par fichier (10 fichiers de 10 pages > 1 fichier de 100 pages), un fichier index.txt en tête comme carte du documents, .txt avec titres H2 (PDFs complexes mal indexés, .md sous-performe sur GPT), CSV/JSON pour les données type-base, citation explicite des fichiers dans les Instructions (« avant de répondre à X, consulte fichier-X »).
  5. 5 pièges à éviter : fourre-tout de docs en l'état, règles dans les fichiers au lieu des instructions (revoir 1.3 anatomie), oublier d'instruire l'assistant à utiliser les fichiers, données sensibles dans assistant partagé (risque exfiltration via manipulation du prompt documenté), oubli de mise à jour qui crée un décalage silencieux. Test du nouveau collègue : si un humain peut répondre vite avec tes documents, la recherche dans les documents marchera aussi.