Chatbot IA et grosse documentation : pourquoi la plupart saturent (et comment Causerie a résolu le problème)

Vous voulez mettre un chatbot IA sur votre site. Vous lui donnez vos 50 PDF de documentation produit, vos guides PDF, vos FAQ, vos pages de site. Les premières réponses sont correctes. Puis ça se gâte. Le bot se met à inventer des prix. À mélanger deux produits. À oublier des informations qui sont pourtant noir sur blanc dans vos fichiers.

Vous pensez que c'est le modèle qui n'est pas assez bon. C'est presque jamais ça. Le vrai problème est en amont, dans la manière dont la documentation est passée au modèle. Et il a un nom technique précis : la saturation de la fenêtre de contexte.

Comment la plupart des chatbots IA fonctionnent (et pourquoi ça casse)

Quand un utilisateur pose une question à un chatbot IA classique, voici ce qui se passe dans 95% des outils du marché, y compris des plateformes installées comme Intercom Fin, Tidio Lyro, Chatbase, Botpress ou les solutions maison construites en quelques heures :

1. L'utilisateur tape sa question dans le widget.
2. Le système concatène l'intégralité de votre base de connaissances (tous les PDF, toutes les pages scrapées, tout le texte importé) dans un seul gros prompt.
3. Ce gros prompt est envoyé au modèle de langage (GPT-4o, Claude, Gemini ou autre).
4. Le modèle lit tout, cherche la réponse dans la masse, et génère sa réponse.

Ça marche tant que votre documentation est petite. Ça casse dès qu'elle devient sérieuse.

Le plafond technique : la fenêtre de contexte

Chaque modèle de langage a une fenêtre de contexte. C'est le nombre maximum de tokens (morceaux de mots) qu'il peut lire en une seule fois. Au-delà, le modèle refuse purement et simplement la requête. Voici les plafonds actuels :

• GPT-4o et GPT-4o Mini : 128 000 tokens (~ 200 pages de texte dense)
• Claude Sonnet 4 : 200 000 tokens (~ 350 pages)
• Gemini 2.5 Pro : 1 000 000 tokens (~ 1500 pages, sur papier)

Sur le papier, 1 million de tokens c'est énorme. Sur le papier seulement.

Le piège invisible : "lost in the middle"

Plusieurs études (notamment celle de Stanford Lost in the Middle: How Language Models Use Long Contexts, publiée en 2023 et confirmée par plusieurs travaux depuis) ont montré que la qualité des réponses chute drastiquement bien avant que la fenêtre de contexte soit pleine.

À partir de 60 à 70% de remplissage de la fenêtre de contexte, le modèle commence à oublier les informations situées au milieu du prompt. Il retient le début, retient la fin, et perd le centre.

Concrètement, si vous avez 100 PDF de documentation et que le bot doit chercher une info dans le PDF n°47, il y a de fortes chances qu'il ne la trouve pas. Pas parce que l'info n'y est pas. Parce qu'elle est noyée au milieu d'un océan de texte que le modèle traite mal.

Le RAG : la solution architecturale (pas un patch)

Le RAG (Retrieval-Augmented Generation) est une architecture née en 2020 dans un papier de Facebook AI Research. L'idée est radicalement différente de l'approche "tout-dans-le-prompt" :

Plutôt que de donner toute la documentation au modèle à chaque message, on stocke la doc dans une base externe spécialisée, et on ne remonte au modèle que les extraits réellement pertinents pour la question posée.

C'est exactement ce que fait un humain compétent. Quand on vous pose une question pointue sur la doc d'un produit, vous ne relisez pas les 500 pages du manuel. Vous allez à l'index, vous tournez aux deux ou trois pages utiles, vous lisez, vous répondez. Le RAG fait pareil, en automatique, en quelques millisecondes.

Les 4 étapes d'un RAG natif

1. Chunking. Votre documentation est découpée en petits morceaux cohérents appelés chunks, typiquement entre 300 et 800 tokens chacun, avec un léger chevauchement pour ne pas casser le sens d'une idée à cheval sur deux chunks.
2. Embeddings. Chaque chunk passe dans un modèle d'embeddings (chez Causerie : text-embedding-3-large d'OpenAI). Il en sort un vecteur numérique de 3072 dimensions qui capture le sens sémantique du chunk, pas juste ses mots-clés.
3. Stockage vectoriel. Les vecteurs sont stockés dans une base de données vectorielle spécialisée. Causerie utilise Supabase avec l'extension pgvector, qui permet une recherche par similarité cosinus extrêmement rapide, même sur des millions de chunks.
4. Retrieval. Quand l'utilisateur pose une question, sa question est elle aussi vectorisée, puis la base remonte les 3 à 10 chunks les plus proches sémantiquement. Seuls ces chunks ciblés sont envoyés au modèle pour générer la réponse finale.

Sans RAG vs avec RAG : la comparaison concrète

Comparatif : quels chatbots IA acceptent vraiment une grosse documentation ?

Beaucoup de solutions annoncent "documentation illimitée" en marketing. Dans les faits, les limites sont souvent cachées dans les plans, ou liées à la fenêtre de contexte du modèle utilisé. Voici un état des lieux honnête en mai 2026.

La majorité des solutions grand public utilise encore une approche prompt direct ou RAG très basique. Causerie est l'une des rares solutions en français à proposer un RAG natif sans configuration, et la seule à offrir PDF et URLs réellement illimités sur le plan Business à 99€/mois.

Le RAG natif de Causerie, en détail

Sous le capot, voici exactement ce que fait Causerie quand vous activez un chatbot Business :

Ingestion : du PDF brut au vecteur indexé

Quand vous uploadez un PDF dans le dashboard Causerie :

1. Le texte est extrait avec un parser PDF robuste (avec OCR automatique si le PDF est scanné).
2. Le texte est découpé en chunks de ~500 tokens avec 50 tokens de chevauchement entre chunks adjacents. Le découpage respecte les frontières naturelles (paragraphes, titres) plutôt que de couper au milieu d'une phrase.
3. Chaque chunk est envoyé à l'API d'OpenAI Embeddings (modèle text-embedding-3-large) qui retourne un vecteur de 3072 dimensions.
4. Le vecteur, accompagné du chunk de texte original et de métadonnées (nom du PDF, page source, position), est inséré dans une table Postgres avec l'extension pgvector.

Pour 200 PDF de 30 pages chacun, l'ingestion prend en pratique 2 à 5 minutes selon la charge serveur. Vous voyez la progression en direct dans le dashboard.

Retrieval : la mécanique à chaque question

À chaque message utilisateur :

1. La question est vectorisée avec le même modèle d'embeddings.
2. Une requête SQL ORDER BY embedding <=> query_vector retourne les chunks les plus proches en similarité cosinus.
3. Un système de scoring sélectionne les 3 à 10 meilleurs chunks selon un seuil de pertinence dynamique.
4. Ces chunks sont injectés dans le prompt final envoyé au modèle de langage choisi (GPT-4o, Claude Sonnet 4, Gemini 2.5 Pro ou les variantes mini/haiku/flash).
5. Le modèle génère la réponse en citant naturellement les extraits utilisés.

L'ensemble de ce processus prend typiquement 800 ms à 2 secondes selon le modèle final choisi. C'est invisible pour l'utilisateur qui voit juste le bot répondre.

Pourquoi Supabase + pgvector et pas Pinecone ou Weaviate ?

Le choix de Supabase n'est pas anodin. Trois raisons concrètes :

• Hébergement Europe par défaut. Supabase propose des régions UE (Francfort, Paris, Londres) ce qui garantit la conformité RGPD sans configuration spécifique. Vos données ne quittent jamais l'Europe.
• Postgres natif. Pas besoin de gérer deux bases (une relationnelle pour les utilisateurs, une vectorielle pour les embeddings). Tout est dans Postgres, ce qui simplifie radicalement l'architecture et réduit les points de défaillance.
• Coût maîtrisé. À volume comparable, Supabase est 3 à 10 fois moins cher que Pinecone Cloud sur les plans gérés. Ça permet de proposer le plan Business à 99€/mois avec PDF illimités sans saigner les marges.

Limites honnêtes du RAG (parce qu'aucune solution n'est parfaite)

Le RAG n'est pas magique. Il a aussi ses faiblesses et il est honnête de les nommer :

• Le RAG dépend de la qualité du chunking. Si votre documentation est mal structurée (tableaux complexes, mises en page exotiques, schémas que seul un humain comprend), le chunking peut perdre du sens. Causerie applique des heuristiques solides mais ce n'est jamais parfait à 100%.
• Une question très transverse peut nécessiter plus de 10 chunks. Si l'utilisateur demande un résumé global de toute votre doc, le RAG n'est pas l'outil idéal. Il est conçu pour des questions ciblées, pas pour des synthèses larges.
• Le RAG ne raisonne pas, il récupère. Si la réponse exige de combiner des informations dispersées dans 15 documents différents, le retrieval peut en manquer certaines. Les requêtes complexes multi-sauts (multi-hop) restent un domaine de recherche actif.
• L'embedding a un coût. Chaque PDF ingéré coûte quelques centimes à OpenAI Embeddings. Sur le plan Business à 99€/mois, ces coûts sont absorbés par Causerie tant que l'usage reste dans des volumes raisonnables (à ce jour personne n'a dépassé le seuil).

Comment choisir le bon chatbot IA pour beaucoup de PDF (checklist)

Si vous évaluez un chatbot IA pour une grosse base documentaire, posez ces 5 questions au fournisseur :

1. "Utilisez-vous un RAG natif ou injectez-vous tout dans le prompt ?" Si la réponse est floue, c'est probablement du prompt direct.
2. "Quelle base de données vectorielle utilisez-vous et où est-elle hébergée ?" Une réponse sérieuse mentionne pgvector, Pinecone, Weaviate, Qdrant ou équivalent, et précise la région d'hébergement.
3. "Y a-t-il une limite réelle au nombre de PDF importables, et où est-elle dans les CGV ?" Beaucoup d'éditeurs annoncent "illimité" en marketing mais cachent une limite à 50 documents dans les CGV.
4. "Le modèle d'embeddings utilisé est-il modifiable ou figé ?" Cela révèle la maturité technique de l'éditeur.
5. "Comment gérez-vous les PDF scannés ou avec OCR nécessaire ?" Une vraie réponse mentionne un pipeline OCR clair, pas un évitement.

Si vous voulez tester directement, le plan Business de Causerie à 99€/mois inclut tout cela par défaut et vous pouvez l'essayer sans carte bancaire avant de souscrire.

Conclusion : l'architecture compte plus que le modèle

En 2026, choisir un chatbot IA en regardant uniquement le modèle de langage est une erreur. L'architecture qui entoure le modèle compte plus que le modèle lui-même. Un GPT-4o bridé par une mauvaise injection de contexte fera moins bien qu'un GPT-4o Mini orchestré avec un RAG natif solide.

Si votre projet implique une documentation conséquente (au-delà de 30 PDF, soyons concrets), le RAG n'est plus un luxe technique, c'est la base. Sans ça, vous achetez un produit qui va se dégrader le jour où vous lui donnerez vraiment du travail.

Causerie a fait le choix d'un RAG natif dès la conception, pas en option, pas en plan Enterprise à 500€/mois. C'est ce qui permet d'offrir PDF illimités à 99€/mois et de tenir cette promesse techniquement, pas marketing.