Créer un agent IA RAG avec Make pour sa PME (2026)

Vous avez demandé à ChatGPT ou à Claude quelle est votre politique de remboursement, votre grille tarifaire 2026 ou la procédure pour résilier un contrat client — et l'IA a répondu avec assurance, de façon plausible, et complètement à côté. Elle ne connaît pas vos documents internes. Elle ne peut pas les connaître : elle a été entraînée sur le web public, pas sur le PDF de vos CGV mis à jour en mars dernier ni sur le wiki Notion de votre équipe support.

La réponse technique à ce problème porte un nom depuis quelques années et un statut différent depuis 2026 : le RAG, Retrieval-Augmented Generation. Le principe est simple à énoncer — brancher un modèle de langage sur une recherche dans vos propres documents avant qu'il ne rédige sa réponse — et brutalement plus difficile à exécuter correctement que ne le laissent croire les tutoriels qui s'arrêtent au schéma de principe. Une donnée devrait pourtant faire réfléchir avant de se lancer tête baissée : 80% des projets RAG en entreprise connaissent un échec critique, et 73% de ces échecs viennent de l'étape de récupération de l'information elle-même, pas du modèle de langage.

Cet article documente l'architecture concrète que Make permet de monter — agent IA, recherche sémantique sur une base vectorielle, distribution de la réponse sourcée — ce qu'elle coûte réellement face à une solution clé en main comme Dust, les pièges techniques qui expliquent la majorité des échecs, et ce que le RGPD impose dès que ces documents contiennent des données personnelles.

Pourquoi un agent générique ne suffit pas pour une PME

Ce scénario n'a rien d'hypothétique : c'est la situation par défaut de tout assistant IA branché sur ChatGPT, Claude ou Gemini sans configuration supplémentaire, et c'est exactement ce qui pousse de plus en plus de PME à se poser la question de l'architecture plutôt que de se contenter d'un abonnement grand public. Un grand modèle de langage généraliste répond avec les connaissances qu'il a apprises pendant son entraînement — des connaissances figées à une date donnée, et qui ne contiennent, par construction, rien de spécifique à votre entreprise. Demandez-lui votre politique de remboursement et il improvise une réponse plausible en s'appuyant sur ce que font généralement les entreprises de votre secteur. Le résultat a l'air compétent. Il est faux, et personne ne le voit tant que le client ne pointe pas la contradiction avec les vraies CGV.

Le RAG résout ce problème par un détour : au lieu de demander au modèle de « savoir », on lui donne le bon extrait de document au moment de répondre. Concrètement, chaque document interne est découpé en fragments, chaque fragment est transformé en vecteur numérique (l'embedding) qui capture son sens, et ces vecteurs sont stockés dans une base spécialisée. Quand une question arrive, le système cherche les fragments les plus proches sémantiquement, les insère dans le prompt envoyé au modèle, et seulement à ce moment le modèle rédige une réponse — ancrée dans vos documents, pas dans ses souvenirs d'entraînement.

L'intérêt documenté en 2026 est chiffré : une architecture RAG bien gouvernée réduit les erreurs factuelles de 60 à 80% par rapport à une génération non ancrée, et l'écart de précision de récupération entre des données bien gouvernées et des données mal gouvernées atteint 85-92% contre 45-60%. Le RAG n'est donc pas un gadget technique de plus — c'est ce qui sépare un assistant IA utilisable en production d'un générateur de réponses plausibles mais dangereuses à suivre.

Le contexte 2026 ajoute une deuxième raison de s'y intéresser maintenant plutôt que d'attendre : GraphRAG, popularisé par Microsoft Research en 2024, s'est imposé entre-temps comme l'architecture la plus recherchée pour les agents IA en entreprise — mais les praticiens sont unanimes sur un point qui concerne directement une PME : GraphRAG est le plus souvent surdimensionné pour une TPE ou une PME. Le RAG vectoriel classique, plus simple à monter et moins coûteux à faire tourner, couvre à lui seul environ 80% des cas d'usage réels d'une petite structure. Il n'y a donc pas de retard à rattraper sur une architecture plus complexe : le bon niveau de sophistication pour une PME en 2026 reste, dans l'immense majorité des cas, le RAG vectoriel simple décrit dans cet article.

L'architecture à 4 briques : documents, base vectorielle, agent Make, distribution

Il existe deux façons de construire cette architecture : la solution clé en main (Dust, Glean et consorts, qui embarquent tout le pipeline) et la solution assemblée soi-même avec un orchestrateur no-code. Make appartient à la deuxième catégorie, et sa capacité à effectuer une recherche sémantique directement contre une base vectorielle comme Pinecone — confirmée dans la documentation produit de Make AI Agents — en fait une option crédible pour une PME qui veut garder la main sur chaque brique plutôt que de tout confier à une plateforme fermée.

Concrètement, la chaîne se déroule ainsi : un déclencheur Make surveille un dossier Google Drive ou une base Notion, découpe chaque nouveau document en fragments de taille contrôlée (idéalement en respectant les frontières naturelles — un tableau ou une liste ne se coupe jamais au milieu), envoie ces fragments à un modèle d'embedding, stocke le résultat dans Pinecone. Côté requête, l'agent Make reçoit la question d'un utilisateur, la transforme elle aussi en vecteur, interroge Pinecone pour les fragments les plus proches, construit un prompt avec ce contexte et l'envoie au modèle de langage — qui répond en citant la source du fragment utilisé, pas seulement une réponse nue.

Configuration concrète, dans l'ordre

• 1. Créer l'index Pinecone — un index serverless sur le plan Starter gratuit suffit pour démarrer : 100K vecteurs et 2GB de stockage couvrent un corpus de plusieurs centaines de documents PME sans dépenser un centime.
• 2. Construire le scénario d'ingestion dans Make — déclencheur sur le dossier source (Drive, Notion, SharePoint), module de découpage en fragments, module d'embedding, module d'écriture vers Pinecone. Ce scénario tourne en tâche de fond, déclenché à chaque nouveau document ou modification.
• 3. Définir la taille des fragments avant tout test — viser des fragments de 300 à 500 tokens qui respectent les frontières naturelles du document (un paragraphe, un tableau entier, une section) plutôt qu'une coupe mécanique à intervalle fixe.
• 4. Construire l'agent de requête — module Make AI Agent avec l'action de recherche sémantique Pinecone configurée, suivie de l'appel au modèle de langage avec le contexte récupéré injecté dans le prompt.
• 5. Tester sur un jeu de questions réelles avant la mise en production — reprendre les 10-15 questions les plus posées au support ou à l'équipe interne, vérifier que chaque réponse cite bien la bonne source, pas seulement une réponse plausible.

Cas d'usage concret : l'agent support qui répond avec les vraies conditions

Prenons un scénario représentatif : une PME de service qui reçoit chaque semaine des dizaines de questions similaires sur ses conditions de remboursement, ses délais de livraison et sa grille tarifaire — des informations qui changent 2 à 3 fois par an et qui vivent dans un Google Doc partagé, pas dans une base de données structurée. Sans RAG, un chatbot générique invente une réponse plausible basée sur ce que font « généralement » les entreprises du secteur. Avec l'architecture décrite ici, la question du client est vectorisée, comparée aux fragments du Google Doc réellement à jour, et la réponse cite la section exacte des CGV utilisée — avec la date de dernière modification du document source, ce qui permet à l'équipe de repérer immédiatement si la réponse s'appuie sur une version obsolète.

Ce détail — afficher la source et sa date plutôt qu'une réponse nue — n'est pas un raffinement optionnel. C'est ce qui transforme un agent RAG d'un générateur de texte convaincant en un outil que l'équipe support peut réellement vérifier avant de le laisser répondre sans supervision.

Toutes les PME n'ont pas besoin d'un RAG complet

Avant de se lancer dans cette architecture, une question mérite d'être posée honnêtement : votre corpus documentaire tient-il vraiment sur plusieurs centaines de pages qui évoluent régulièrement, ou s'agit-il en réalité d'une vingtaine de questions récurrentes qu'une FAQ bien rédigée et un moteur de recherche plein texte classique (Notion, Algolia, ou même un simple Ctrl+F structuré) suffiraient à couvrir ? Le RAG apporte une vraie valeur à partir du moment où le corpus est trop volumineux ou trop dispersé pour qu'un humain le parcoure rapidement, et où les questions posées varient suffisamment pour qu'une liste de questions-réponses figée ne suffise plus. En dessous de ce seuil, monter une architecture RAG revient à consommer plusieurs jours de configuration pour un gain marginal sur un problème qu'une FAQ bien tenue résolvait déjà à moindre coût.

Combien ça coûte : Make + Pinecone maison vs Dust clé en main

Deux philosophies s'affrontent ici, et le choix dépend moins du budget brut que de ce que vous voulez contrôler. La version « maison » avec Make et Pinecone coûte moins cher à l'usage mais demande du temps de configuration et de maintenance. La version clé en main avec Dust coûte plus cher au siège mais élimine la configuration de la base vectorielle et du chunking.

Cas concret chiffré : une PME de 8 personnes qui interrogent quotidiennement la base de connaissances. Avec Dust Pro à 24$/siège/mois (annuel), le budget mensuel tourne autour de 192$/mois, connecteurs et chunking inclus. Avec Make + Pinecone, en comptant Make Core (~11€/mois) + le coût tokens d'environ 500 requêtes/mois + Pinecone qui reste sur le tier gratuit jusqu'à 100K vecteurs (largement suffisant pour un corpus de quelques centaines de documents), le budget réaliste tombe sous 50€/mois — mais il faut ajouter le temps de configuration initiale du chunking et de la surveillance des embeddings obsolètes, que Dust prend en charge nativement.

Une troisième option mérite d'être mentionnée pour l'équipe technique qui veut réduire encore le coût de la base vectorielle : Supabase, qui intègre l'extension pgvector directement dans sa base Postgres managée. Pour une PME qui utilise déjà Supabase comme backend applicatif, ajouter le stockage vectoriel ne demande pas d'abonnement séparé — l'extension tourne dans la même base de données que le reste de l'application, ce qui simplifie l'infrastructure au prix d'une recherche vectorielle un cran moins optimisée qu'une base spécialisée comme Pinecone sur de très gros volumes. Pour un corpus PME de quelques centaines à quelques milliers de documents, la différence de performance reste marginale ; elle devient sensible seulement à partir de plusieurs millions de vecteurs, un volume que peu de PME atteignent avec leur seule documentation interne.

Les 4 pièges qui expliquent la majorité des échecs RAG

Le RAG n'est pas un problème d'intelligence artificielle, c'est un problème d'ingénierie des données avec une composante IA — une distinction qui explique pourquoi tant de projets échouent malgré un modèle de langage performant. Sur les six modes de défaillance recensés par les praticiens en 2026, quatre reviennent systématiquement, indépendamment de l'architecture choisie (Make, Dust, ou une stack entièrement codée sur-mesure) : le choix des outils ne protège d'aucun d'entre eux si la discipline de données qui va avec n'est pas mise en place en parallèle.

Un réflexe simple limite une bonne partie de ces risques sans complexité technique supplémentaire : désigner, pour chaque catégorie de document ingéré (CGV, grille tarifaire, procédures internes), une seule personne responsable de signaler tout changement à l'équipe qui gère le scénario Make d'ingestion. Sans ce point de contact clair, le pipeline continue de tourner sur des documents qui ont changé de version sans que personne ne déclenche la réingestion — exactement le scénario d'embeddings obsolètes documenté plus haut, mais qui se corrige avec une règle d'organisation plutôt qu'avec un réglage technique.

RGPD : ce qu'il faut verrouiller avant de brancher Make sur vos données

Un point technique que la plupart des tutoriels RAG passent sous silence, et qui concerne directement toute PME française qui envisage cette architecture : les embeddings générés à partir de vos documents ne sont pas un format neutre. S'ils encodent le sens de textes contenant des noms, des emails ou des informations RH, ils constituent eux-mêmes une donnée personnelle au sens du RGPD — au même titre que le document source. Associer des métadonnées temporelles à des embeddings de comportement peut même permettre de réidentifier des individus dans un jeu de données agrégé, un risque documenté explicitement par les praticiens de la protection des données en 2026.

Le cadre est clair sur un point : un système d'IA qui repose sur des données personnelles n'échappe pas au RGPD, y compris à la phase de construction de la base vectorielle elle-même — l'article 5 du RGPD (licéité, loyauté, transparence, minimisation) s'applique à l'ingestion des documents dans Pinecone autant qu'à l'usage final de l'agent. La CNIL a publié en 2026 des recommandations qui se construisent progressivement, avec un programme de travail qui doit encore préciser les conséquences du RGPD pour les modèles d'IA qui ne sont pas anonymes — la doctrine complète n'est pas figée, ce qui impose une prudence renforcée plutôt qu'une attente passive.

En pratique, trois réflexes avant de lancer l'ingestion d'un corpus PME dans une base vectorielle : exclure explicitement les documents RH nominatifs et les échanges clients sensibles du pipeline d'ingestion automatique (les traiter à part, avec un accès restreint) ; documenter la base légale (intérêt légitime documenté pour un usage interne de productivité, jamais un simple consentement implicite) ; et mettre en place, comme le recommandent déjà plusieurs cabinets spécialisés, des filtres robustes au niveau du système qui encapsule le modèle plutôt que de compter uniquement sur la prudence du prompt envoyé au LLM.

Un point pratique pour l'architecture Make + Pinecone spécifiquement : Pinecone étant un service américain, vérifiez les clauses contractuelles types ou le mécanisme de transfert applicable avant d'y stocker des embeddings issus de documents contenant des données personnelles de résidents européens — le sujet dépasse le cadre technique et mérite une vérification avec un DPO ou un conseil juridique avant la mise en production, pas après. Dust, de son côté, publie ses propres engagements de résidence des données dans sa documentation contractuelle — à vérifier au cas par cas selon le plan souscrit, l'information n'étant pas garantie identique sur tous les tiers.

Verdict : construire ou externaliser ?

Le choix entre Make + Pinecone et une solution clé en main comme Dust n'est pas une question de budget seul — c'est une question de qui, dans l'entreprise, va porter la responsabilité de la qualité du corpus documentaire dans la durée. Une PME qui n'a personne pour surveiller les embeddings obsolètes et la dérive du chunking gagnera plus à payer plus cher une plateforme qui l'absorbe pour elle qu'à économiser un abonnement sur un système que personne ne maintient réellement au bout de six mois.

Résumé pour qui n'a pas le temps de tout lire : Make peut orchestrer une architecture RAG complète en s'appuyant sur Pinecone pour la recherche sémantique, à un coût très inférieur à une solution clé en main — mais 73% des échecs RAG viennent de la récupération, pas du modèle, donc le temps économisé sur l'abonnement doit être réinvesti dans le nettoyage du corpus et la stratégie de chunking. Dust reste la meilleure option pour une équipe qui veut éliminer cette charge de configuration, au prix d'une facturation par siège qui grimpe vite au-delà d'une dizaine d'utilisateurs. Dans les deux cas, un audit RGPD du corpus précède le choix technique, pas l'inverse.

Dernier point à ne pas sauter, quel que soit le choix technique retenu : ne mettez jamais un agent RAG en production sans un mécanisme visible qui affiche la source citée et sa date de dernière mise à jour à côté de chaque réponse. C'est ce détail, plus que le modèle de langage ou la base vectorielle choisie, qui permet à une équipe de repérer une dérive avant qu'un client ne le fasse à sa place — et qui transforme un projet RAG d'un pari technique en un outil que l'entreprise peut réellement auditer dans la durée.

Articles liés

• Make AI Agents : quelle autonomie, quels risques (2026) — sur les limites et les points d'arrêt humain à prévoir pour tout agent Make, RAG inclus.
• n8n + OpenAI : agent IA auto-hébergé, le coût réel (2026) — la même architecture d'agent, avec n8n comme orchestrateur auto-hébergé plutôt que Make.
• Dify, n8n ou Flowise : quelle plateforme d'agents IA choisir (2026) ? — pour les équipes techniques qui veulent comparer d'autres orchestrateurs open-source.
• Supabase vs Firebase vs MongoDB Atlas : bases de données 2026 — Supabase intègre pgvector, une alternative auto-hébergée à Pinecone pour la base vectorielle.
• CrewAI, AutoGPT ou AgentGPT : quel agent IA pour leads ? — la même question d'autonomie d'agent appliquée à la génération de leads plutôt qu'à la base de connaissances.