La knowledge base, document pivot de tout projet IA

Résumé de l'article

Article méthodologique consacré à la knowledge base comme document pivot de tout projet IA. Il présente la logique conceptuelle, les principes de formatage, la structure type d'une knowledge base client (déclinée en trois blocs : cadre comportemental, identité business, contexte opérationnel), les pro tips issus de la pratique, et l'usage opérationnel dans Claude Projects comme dans ChatGPT Projects. Une ouverture finale élargit la réflexion à d'autres usages possibles (éditorial, métier personnel, équipe, produit, domaine d'expertise).

Articles connexes :

L'article s'inscrit dans la suite de "Auditer un site avec Claude Opus 4.7" et annonce explicitement l'article suivant sur le rôle structurant du Markdow

Pourquoi cet article

Dans l'article précédent consacré à l'audit stratégique avec Claude Opus 4.7, j'ai présenté la knowledge base comme l'un des trois piliers de ma méthode. J'ai promis d'y consacrer un article entier, parce que c'est un sujet à part entière, et parce que c'est probablement le document le plus stratégique de tout projet IA — bien avant les prompts.

J'y reviens donc ici, avec une conviction renforcée par chaque nouveau projet : la qualité d'un travail avec un LLM dépend d'abord de la qualité du référentiel qu'on lui fournit. Pas du modèle. Pas du prompt. Du référentiel.

Étonnamment, la documentation officielle des plateformes — Anthropic comme OpenAI — explique très bien le contenant (où mettre les fichiers, comment fonctionne le RAG, quelles sont les limites de tokens) mais reste largement silencieuse sur le contenu : qu'est-ce qu'on met exactement dans une knowledge base, comment on le structure, comment on le maintient. Cet article vient combler cette pièce manquante, à partir d'un modèle que j'ai éprouvé sur des projets clients réels.

La knowledge base est le document pivot d'un projet IA : elle transforme un LLM générique en collaborateur calibré pour ton contexte.Elle ne se résume pas à un dossier de fichiers : c'est une architecture éditoriale qui suit des règles précises de formatage et de structuration.Une knowledge base client efficace s'organise en trois blocs : cadre comportemental, identité business, contexte opérationnel.Elle est transposable d'un LLM à l'autre (Claude, ChatGPT, Gemini), à condition d'être pensée comme un actif et non comme une livraison ponctuelle.Au-delà des projets clients, la logique s'applique à tout usage récurrent d'un LLM : éditorial, métier, équipe, produit.

Sommaire

1. Pourquoi la knowledge base est un document pivot
2. Ce que disent — et ne disent pas — les outils
3. Les principes de formatage qui changent tout
4. La structure type d'une knowledge base client
5. Les pro tips qui font la différence
6. La vie opérationnelle de la knowledge base
7. Ouverture : la knowledge base est plus qu'un document client
8. Conclusion

1. Pourquoi la knowledge base est un document pivot

Avant de parler structure, il faut comprendre ce que la knowledge base résout. Sans cette compréhension, on construit une bibliothèque de fichiers qui ressemble à une knowledge base mais qui n'en a ni la valeur ni l'efficacité.

Le problème qu'elle résout

Sans knowledge base, chaque conversation avec un LLM démarre à zéro. Tu re-expliques le client, son secteur, son ton, ses contraintes, ses cibles. Tu reconstruis le contexte à chaque échange. Et même quand tu prends le temps de bien briefer, le modèle dérive : il oublie une nuance, il revient à des formulations génériques, il propose des recommandations qui pourraient s'appliquer à n'importe quel acteur du marché.

Ce phénomène a un coût direct sur la qualité du livrable et un coût indirect sur ton temps. Dans la pratique, j'ai constaté qu'un consultant peut passer 20 à 30% de son temps de production à re-contextualiser au lieu de produire. C'est exactement ce que la knowledge base élimine.

Ce qu'elle change concrètement

Avec une knowledge base bien construite, le LLM passe de consultant générique à membre d'équipe briefé. La nuance est énorme. Un consultant générique connaît le SEO, le growth, le CRM. Un membre d'équipe briefé connaît ce client précis : ses produits, ses cibles, son ton, ses zones rouges, ses arbitrages déjà rendus, ses concurrents, ses chiffres clés. Et il garde cette connaissance d'une conversation à l'autre, sans qu'on ait à la lui rappeler.

C'est cette stabilité qui transforme la collaboration. Le LLM peut se concentrer sur l'analyse stratégique parce qu'il n'a plus à inférer le contexte. Et toi, tu peux te concentrer sur les arbitrages parce que tu n'as plus à briefer.

Pourquoi c'est un actif, pas un fichier

Une knowledge base n'est pas livrée une fois pour toutes. Elle s'enrichit, se corrige. Elle accumule de la valeur au fil des projets — formulations validées par le client, prompts qui ont bien fonctionné, ajustements stratégiques, retours d'usage. Au bout de quelques mois, elle devient un actif difficilement reproductible, qui résume tout ce que ton équipe et le client ont appris ensemble sur la manière de bien travailler avec l'IA sur ce périmètre précis.

C'est cette dimension cumulative qui distingue une vraie knowledge base d'un simple dossier de fichiers : la structure éditoriale, la maintenance, et la logique d'enrichissement.

2. Ce que disent — et ne disent pas — les outils

Avant d'entrer dans la méthode, un détour utile par ce que proposent les principales plateformes. Cela permet de situer où se trouve la valeur ajoutée d'un travail méthodologique.

Côté Anthropic

Claude Projects fournit des espaces de travail autonomes avec leur propre historique de conversations et leur propre knowledge base. Concrètement, tu peux uploader des documents, du texte, du code, et définir des instructions de projet qui s'appliquent à toutes les conversations dans ce projet. Sur les comptes payants, le système s'appuie sur du RAG (Retrieval Augmented Generation) avec un Contextual Retriever qui ne se contente pas d'aller chercher du contenu, mais qui l'enrichit de contexte avant de le restituer au modèle.

La documentation officielle d'Anthropic décrit très bien le contenant : limites de tokens, formats acceptés, partage en équipe, mécanique de récupération. Elle propose même une analogie utile — imagine a team member who arrives fully trained on your company's style guide — mais ne dit pas comment construire ce style guide ni comment l'organiser pour que le modèle l'utilise efficacement.

Côté OpenAI

ChatGPT propose deux dispositifs proches dans l'esprit, différents dans l'implémentation : les Projects (espaces de travail comparables aux Projects Claude, avec instructions et fichiers de référence) et les Custom GPTs (assistants personnalisables avec instructions et knowledge files, partageables publiquement). Les deux acceptent des fichiers de référence, des instructions personnalisées, et offrent une logique de persistance du contexte.

Les recommandations officielles d'OpenAI sont pragmatiques : préférer les fichiers texte clairs, dater les contenus, séparer les règles (à mettre dans les instructions) des sources (à mettre dans la knowledge). Elles restent à un niveau d'évidence générale.

Le constat partagé

Les deux plateformes fournissent l'infrastructure, pas la méthode. Elles te disent où mettre les choses et comment le système les retrouvera. Elles ne te disent pas quoi y mettre, comment l'écrire, ni comment organiser l'ensemble pour que le modèle navigue dedans avec discernement.

C'est exactement la zone que la suite de cet article vient combler.

3. Les principes de formatage qui changent tout

Avant de présenter la structure, il y a une couche transverse à poser : les principes de formatage qui font qu'un document est réellement exploitable par un LLM. Ces principes sont valables pour toutes les sections de la knowledge base, et ils valent pour Claude comme pour ChatGPT.

Markdown systématique

Tous les documents de la knowledge base sont rédigés en Markdown. Ce n'est pas un détail. Le Markdown offre une lisibilité humaine immédiate (donc un coût de maintenance faible), une compatibilité parfaite avec les LLM (qui sont entraînés sur d'énormes volumes de Markdown et qui en parsent la structure naturellement), et une portabilité totale entre outils. Une knowledge base écrite en Markdown se transfère sans perte de Claude vers ChatGPT vers Gemini, là où des fichiers Word ou PDF imposeraient une conversion à chaque migration.

Le rôle structurant du Markdown dans une production assistée par l'IA mérite un article à part entière, qui suivra celui-ci.

Hiérarchie Hn rigoureuse

Le LLM utilise les niveaux de titres (H1, H2, H3) pour comprendre l'architecture du document et pondérer l'importance des informations. Une hiérarchie cohérente lui permet de naviguer dans la knowledge base et de prioriser les sections selon le besoin. À l'inverse, un document à la mise en forme molle (un seul niveau de titre, ou des titres incohérents) se traduit par une lecture indifférenciée, où tout est mis sur le même plan.

Phrases auto-portantes

Chaque paragraphe doit pouvoir être extrait isolément et garder son sens. C'est une discipline d'écriture qui change tout : on évite les "comme vu plus haut", "tel que mentionné précédemment", on reformule les références, on assume une légère redondance. Le RAG fonctionne par extraction de fragments — si un fragment ne tient pas tout seul, il devient inutilisable hors contexte.

Encarts de priorité explicites

Les LLM détectent et pondèrent les marqueurs de priorité explicites. Quand tu écris "RÈGLE CRITIQUE :" ou "À LIRE EN PRIORITÉ", le modèle accorde plus de poids à ce qui suit. C'est un levier puissant et largement sous-utilisé. Sur les sections où une règle est non négociable, le marquer explicitement vaut largement mieux que de l'enfouir dans un paragraphe.

Listes structurées avec verbes d'action

Pour les règles comportementales (ce que l'IA doit toujours faire, ne jamais faire), les listes à puces avec des verbes d'action en tête sont nettement plus efficaces que la prose. "Privilégier les formulations positives", "Citer toujours la source", "Refuser de produire X". Le format est plus lisible pour l'humain qui maintient le document, et plus directement actionnable pour le modèle.

Métadonnées de mise à jour

Chaque document de la knowledge base intègre, en en-tête, une date de dernière mise à jour, un numéro de version, et idéalement la nature de la dernière modification. C'est le minimum de gouvernance qui permet à une knowledge base de vivre sans se désynchroniser. Sans ces métadonnées, on ne sait jamais ce qui est encore valide et ce qui a vieilli.

4. La structure type d'une knowledge base client

Voici le cœur de la méthode. Le modèle que je présente ici a été affiné sur plusieurs projets clients et s'organise en trois blocs logiques : le cadre comportemental, l'identité business, et le contexte opérationnel. Cette tripartition n'est pas arbitraire — elle correspond aux trois questions que doit résoudre tout LLM avant de produire un travail utile : qui suis-je dans ce projet ?, pour qui je travaille ?, comment je dois travailler ?

Bloc 1 — Le cadre comportemental (le "qui" de l'IA)

C'est la première section qu'on rédige, et c'est aussi celle qui sera lue en priorité par le modèle. Elle définit le rôle que l'IA doit incarner dans ce projet, ses règles de fonctionnement, et le format attendu de ses réponses.

Une section bien construite ressemble à ceci dans son squelette :

## Qui tu es dans ce projet
[Définition courte du rôle, en 2-3 phrases. "Tu es mon partenaire X
spécialisé dans Y, avec un objectif unique : Z."]

## Ce que tu fais toujours
- Vérifier les sources avant d'affirmer une donnée chiffrée
- Proposer un plan validé avant de rédiger
- Signaler les zones d'incertitude
- ...

## Ce que tu ne fais jamais
- Combler une donnée manquante par une approximation
- Utiliser des emojis sauf demande explicite
- ...

## Format de réponse par défaut
[Précisions sur la structure, la longueur, le ton attendu]

Cette section est dense, courte, et formulée à la deuxième personne ("tu"). Elle conditionne tous les comportements en aval. C'est aussi la section qui s'enrichit le plus dans les premières semaines d'usage : à chaque fois qu'on doit corriger un comportement du modèle, on remonte la règle ici plutôt que de la rappeler dans chaque conversation.

Bloc 2 — L'identité business (le "qui" du client)

Ce bloc rassemble tout ce qu'il faut savoir sur le client pour produire un travail calibré. Il se décline en trois sections principales.

Identité de l'entreprise.

Mission, vision, valeurs, proposition de valeur unique, positionnement. La nuance importante : on n'écrit pas une plaquette marketing, on écrit un brief opérationnel. La différence se mesure à l'extraction : un paragraphe issu d'une plaquette dit "Nous accompagnons nos clients dans leur transformation digitale avec passion et expertise". Un paragraphe issu d'un brief opérationnel dit "L'entreprise vend du conseil en transformation digitale aux ETI industrielles françaises de 200 à 2000 salariés, avec un positionnement premium et un ticket moyen autour de 80 K€". Le second est exploitable par un LLM, le premier non.

Produits et services.

Pour chaque offre, je documente : description courte, cible visée, problème résolu, arguments de vente principaux, objections fréquentes rencontrées en avant-vente, et concurrents directs sur ce périmètre. Cette dernière dimension est sous-exploitée et pourtant cruciale : connaître les concurrents permet au LLM de calibrer ses recommandations dans un paysage réaliste.

Cibles et personas.

Profils types, motivations principales, freins identifiés, vocabulaire qu'ils utilisent vraiment, ce qui ne fonctionne pas avec eux. La règle d'or : chaque persona doit être assez précis pour qu'on puisse "entendre" cette personne parler en lisant la fiche. Si le persona pourrait s'appliquer à n'importe quel acheteur B2B, il n'apporte rien.

Bloc 3 — Le contexte opérationnel (le "comment" du quotidien)

Ce bloc rassemble tout ce qui touche à la production concrète : le ton, les canaux, le contexte business, les apprentissages.

Tone of voice et style éditorial.

C'est probablement la section la plus délicate à écrire. Elle ne se résume pas à "ton professionnel et accessible" — formulation qui ne sert à rien parce qu'elle s'applique à tout le monde. Une section tone of voice efficace contient :

• ce que la marque est (3 à 5 adjectifs incarnés, avec une justification courte) ;
• ce que la marque n'est pas (les écueils à éviter, formulés en négatif explicite) ;
• les règles de rédaction (longueur des phrases, niveau de technicité, usage du "nous" ou du "vous", formulations privilégiées) ;
• les mots à utiliser et les mots à bannir, avec quelques exemples ;
• des exemples de paragraphes validés par le client, pour servir de référence absolue.

Cette dernière dimension — les exemples validés — est ce qui fait la différence entre un tone of voice théorique et un tone of voice opérationnel.

Canaux de communication, contexte opérationnel, chiffres clés, historique stratégique.

Quatre couches qui ancrent l'analyse dans la réalité du client : où la marque s'exprime et avec quel registre par canal, quelles sont les contraintes business du moment, quels sont les chiffres qui structurent les décisions, quels sont les choix stratégiques déjà rendus et qu'il faut respecter. Sans ces couches, le LLM produit des recommandations hors-sol.

Prompts types validés.

C'est la mémoire vive du projet. À chaque fois qu'un prompt produit un résultat exceptionnel (audit, brief, analyse, copywriting), on le capture ici avec sa formulation exacte et un commentaire sur ce qu'il a permis. Cette section ne se construit pas a priori : elle s'enrichit à chaque session de travail. Au bout de quelques mois, c'est probablement la section qui apporte le plus de valeur opérationnelle, parce qu'elle évite de réinventer ce qui a déjà fonctionné.

5. Les pro tips qui font la différence

Au-delà de la structure, quelques principes issus de la pratique qui changent radicalement l'efficacité de la knowledge base.

Écris pour le modèle, pas pour l'humain.

Une knowledge base n'est pas une plaquette de présentation. Elle peut être dense, technique, parfois redondante, voire un peu sèche. Ce n'est pas grave : elle n'est pas faite pour être lue d'une traite, elle est faite pour être consultée par un LLM qui en extraira ce dont il a besoin. La fluidité littéraire passe après la précision opérationnelle.

Hiérarchise explicitement.

Tout n'a pas la même importance dans une knowledge base. Marquer "PRIORITÉ HAUTE" ou "RÈGLE CRITIQUE" sur les éléments non négociables permet au modèle de pondérer correctement. À l'inverse, traiter toutes les sections sur le même plan dilue les règles essentielles dans un océan d'informations secondaires.

Donne des exemples ET des contre-exemples.

"Voici un paragraphe qu'on validerait" / "Voici un paragraphe qu'on ne validerait pas, et pourquoi" — ce format est nettement plus puissant qu'une règle abstraite. Le modèle apprend par contraste, comme un humain. Sur les sections de tone of voice, en particulier, les contre-exemples valent de l'or.

Documente le négatif.

Ce que tu ne veux pas est souvent plus discriminant que ce que tu veux. "Ne jamais utiliser le mot disruption", "Ne jamais conclure par une question rhétorique", "Ne jamais proposer plus de trois options". Ces interdictions explicites éliminent en un coup les patterns par défaut du modèle qui ne correspondent pas au contexte.

La knowledge base doit être mise à jour

Une knowledge base sans gouvernance se désynchronise en quelques semaines. Date de dernière mise à jour visible, numéro de version, journal des modifications en bas de chaque document : c'est le minimum vital pour qu'elle reste fiable dans le temps.

Teste avec un prompt diagnostic.

Une fois la knowledge base en place, je pose systématiquement au LLM une variante de cette question : "Présente-moi qui tu es dans ce projet, pour qui tu travailles, et ce que tu dois faire et ne pas faire." La réponse du modèle révèle ce qui est bien intégré et ce qui passe à côté. C'est un test simple, rapide, et étonnamment révélateur.

Itère après les premiers usages réels.

La première version d'une knowledge base est toujours imparfaite. Ce sont les premières conversations qui font émerger les manques : une nuance non documentée, une règle ambiguë, un cas non prévu. Plutôt que de chercher la version parfaite avant de commencer, pose une v1 raisonnable et enrichis-la au fil des sessions. La meilleure knowledge base est celle qui a vécu.

6. La vie opérationnelle de la knowledge base

Une knowledge base bien construite ne vaut que si elle est correctement intégrée au workflow. Voici comment elle s'inscrit concrètement dans la pratique.

Sa place dans Claude Projects et ChatGPT Projects

Sur Claude, la knowledge base se loge dans l'espace dédié du Project, alimenté soit par upload de fichiers (Markdown, PDF, DOCX), soit par contenu textuel collé directement. La section "instructions" du Project sert à dupliquer, en version condensée, le bloc 1 (cadre comportemental) — ces instructions sont injectées en système à chaque conversation et ont donc un poids particulier.

Sur ChatGPT, la logique est très proche. Les Projects acceptent des fichiers de référence et des instructions personnalisées. Les Custom GPTs offrent un dispositif comparable, avec une limite de 20 fichiers par GPT mais l'avantage d'une personnalisation plus poussée du persona et la possibilité de partager le GPT à des collaborateurs ou à des clients.

Dans les deux cas, la même knowledge base en Markdown peut être déployée à l'identique. C'est le grand avantage du format : tu maintiens un seul corpus, tu le déploies sur plusieurs plateformes.

La routine de mise à jour

Sur un projet client actif, j'enrichis la knowledge base à plusieurs occasions :

• après chaque session de travail significative, si une nouvelle règle ou un nouvel apprentissage a émergé ;
• après chaque validation client, pour capturer les formulations approuvées ;
• en revue mensuelle, pour vérifier qu'aucune section n'a vieilli ;
• en revue trimestrielle, pour une mise à plat plus profonde.

Cette routine prend peu de temps si elle est régulière. Elle devient un chantier lourd si on la laisse traîner.

La maintenance

La knowledge base a un propriétaire identifié — généralement le consultant ou l'expert qui pilote le compte. Sans propriétaire, elle vieillit silencieusement. Les contributions des autres membres de l'équipe passent par lui pour garder la cohérence éditoriale. Cette gouvernance peut paraître lourde, mais elle est ce qui distingue une knowledge base vivante d'un dépotoir de documents.

L'enrichissement par les apprentissages

Au-delà des mises à jour formelles, deux mécaniques d'enrichissement font la différence :

• les prompts validés qu'on capture systématiquement ;
• les corrections récurrentes : dès qu'on doit reprendre le LLM trois fois sur le même point, c'est un signal qu'une règle manque dans la knowledge base. On l'ajoute, et on n'a plus à corriger.

La portabilité entre LLM

Parce qu'elle est en Markdown, la knowledge base se transfère sans dégradation entre Claude, ChatGPT et Gemini. C'est une assurance importante dans un paysage où les modèles évoluent vite. Si demain un autre LLM devient plus adapté à un type de tâche, la migration est triviale : on copie les fichiers, on adapte le logement (Project, Custom GPT, Gem selon la plateforme), et on continue.

7. Ouverture : la knowledge base est plus qu'un document client

Tout ce qui précède décrit la knowledge base dans son usage le plus mature : le projet client. C'est le terrain où la méthode est la plus aboutie, parce que c'est celui où je l'ai le plus pratiquée. Mais la logique est transposable bien au-delà — et c'est sans doute là qu'il y a le plus à explorer dans les mois qui viennent.

Quelques pistes que j'expérimente ou que je vois émerger.

La knowledge base éditoriale.

Pour un blog, une newsletter, ou une production de contenu régulière. Elle contient la ligne éditoriale, le tone of voice, les sources de référence, les sujets déjà traités, les formulations validées. Le blog que tu lis en ce moment en est un exemple direct : derrière chaque article, il y a un Project Claude avec sa propre knowledge base, qui structure le brief éditorial, la charte visuelle, le lexique, le pilotage éditorial et les sources. Cette knowledge base est ce qui garantit la cohérence d'un article à l'autre, sans que je doive re-briefer le modèle à chaque fois.

La knowledge base métier personnelle.

Ta propre référence d'expert : tes méthodes, tes frameworks, tes sources de fond, tes formulations, tes positionnements sur des sujets clivants. C'est probablement l'usage le plus puissant pour un consultant, parce qu'il transforme le LLM en extension de ton cerveau professionnel. J'expérimente actuellement ce format pour mon propre compte, et le gain en vitesse de production sur des sujets récurrents est significatif.

La knowledge base d'équipe.

Pour un service, un département, ou une organisation entière. Elle agrège les processus, les standards de qualité, les références internes, les bonnes pratiques. Elle se prête particulièrement bien aux Projects partagés en équipe (Claude Team, ChatGPT Business), où plusieurs collaborateurs interagissent avec le même référentiel.

La knowledge base produit ou marque.

Pour un SaaS, un produit, une marque en propre. Elle aligne la communication interne et externe sur une base unique : positionnement, messages clés, FAQ, objections, cas d'usage. Elle est particulièrement utile pour les équipes marketing, sales et support qui doivent toutes parler de la même chose avec cohérence.

La knowledge base de domaine d'expertise.

Pour faire monter en compétence un LLM sur un secteur précis : juridique, médical, technique, financier. Elle rassemble la documentation de référence, le vocabulaire spécialisé, les cas d'école, les zones grises. Elle transforme un modèle généraliste en assistant sectoriel sérieux.

Ces usages ne sont pas des cases fermées : ils se croisent, ils se combinent, ils s'enrichissent. La logique commune, c'est que toute activité qui mobilise un LLM régulièrement gagne à avoir sa knowledge base. La méthode décrite dans cet article peut servir de base — chaque usage demandera ensuite ses propres adaptations.

On est probablement aux débuts d'une pratique qui va se professionnaliser dans les années qui viennent. Plus on partagera de retours d'expérience, plus on convergera vers des standards utiles. C'est une exploration en cours, et elle est ouverte.

Conclusion

Ce qui rend une collaboration avec un LLM puissante, ce n'est pas la sophistication du modèle, ni la subtilité du prompt. C'est la qualité du référentiel sur lequel il s'appuie. Une knowledge base bien construite transforme un outil générique en collaborateur calibré, qui connaît ton contexte, parle ton langage, respecte tes règles, et capitalise sur tes apprentissages. C'est la différence entre travailler avec un consultant junior qu'il faut briefer à chaque fois et travailler avec un collègue qui sait.

La méthode présentée ici est une base, pas un dogme. Elle s'adapte à ta pratique, à ton secteur, à tes outils. Elle évoluera avec les plateformes et avec les modèles. Et elle s'enrichira à mesure que la communauté partagera ses propres retours d'expérience.

Le prochain article reviendra sur le format Markdown, qui est la couche technique qui rend possible toute cette méthode. C'est un sujet plus court mais structurant : comprendre pourquoi le Markdown s'impose comme standard de fait pour la production assistée par l'IA, et comment l'intégrer concrètement dans un workflow professionnel.

Si tu pratiques déjà la knowledge base sur tes projets, tes propres adaptations m'intéressent. C'est le genre de méthode qui se renforce par les usages réels — pas par la théorie.

Sources :

• Anthropic — What are projects : https://support.claude.com/en/articles/9517075-what-are-projects
• Anthropic — Collaborate with Claude on Projects : https://www.anthropic.com/news/projects
• OpenAI — Projects in ChatGPT : https://help.openai.com/en/articles/10169521-using-projects-in-chatgpt
• OpenAI — Knowledge in GPTs : https://help.openai.com/en/articles/8843948-knowledge-in-gpts
• Google — Documentation Gemini (en référence ponctuelle si pertinent)