On a construit un chatbot interne RAG en 48h (coût: 40€/mois)

Il y a six mois, une PME cliente m’a dit : « On perd un temps fou à chercher nos propres infos. » Trente-cinq pour cent du temps de ses équipes sales, support et onboarding s’évaporait dans Notion, Google Drive et HubSpot. Personne ne savait où était quoi. La réponse aux questions RH changeait selon qui tu demandais. Voilà le vrai problème derrière la question comment construire un agent IA RAG pour son entreprise.

On a décidé de ne pas acheter un SaaS de plus. On a construit. En 48h. Pour 38€/mois en production. Et je vais te montrer exactement comment.

Le contexte : une PME noyée sous sa propre documentation

La structure en question : 28 personnes, secteur services B2B. Trois sources de données — Notion pour la doc interne, Google Drive pour les procédures commerciales et les CR de réunion, HubSpot pour tout ce qui touche aux clients et aux deals.

Le problème n’était pas l’absence de documentation. C’était exactement l’inverse. Trop de docs, trop dispersées, aucun point d’entrée unique. Un commercial qui veut savoir quoi faire pour un deal à 60 000€ passe 20 minutes à fouiller avant de demander à son manager. Une recrue qui arrive le 15 mars ne sait pas combien de RTT elle a. Le support croise trois tickets en désespoir de cause pour comprendre pourquoi le client X se comporte bizarrement sur l’API.

On a posé trois contraintes dès le départ :

• Déployer en moins d’une journée de travail effectif
• Coût mensuel récurrent inférieur à 100€
• Données qui restent hébergées en Europe (pas de transfert US)

Ces contraintes ont directement dicté nos choix techniques. Pas de GPT-4o hébergé sur Azure US, pas de Pinecone avec ses serveurs américains. On a cherché la stack la plus légère possible qui réponde au besoin réel.

L’architecture RAG qu’on a retenue (et pourquoi)

Un agent IA RAG — Retrieval-Augmented Generation — couple un moteur de recherche sémantique à un LLM pour ancrer les réponses dans des sources vérifiables. L’agent ne « sait » pas : il cherche, puis génère. C’est ça qui évite les hallucinations sur ta documentation métier.

Notre architecture tient en quatre briques :

1. Ingestion : connecteurs Notion, Google Drive et HubSpot via leurs API respectives
2. Vector store : Qdrant Cloud (région EU) pour stocker les embeddings
3. Orchestrateur : n8n self-hosted sur un VPS OVH à 4€/mois
4. LLM : Claude Sonnet via API Anthropic pour la génération des réponses

Pourquoi pas LangChain ou LlamaIndex ? On les a évalués. Ils sont excellents, mais surdimensionnés pour un corpus de 8 000 chunks. Tu rajoutes de la complexité de débogage pour un gain marginal. Et surtout : on voulait garder la main sur la supervision sans devoir plonger dans du Python tous les matins.

Pourquoi pas Pinecone ou Weaviate ? Pinecone héberge en US par défaut — éliminé. Weaviate en cloud mutualisé coûte 3x Qdrant pour le même usage. Et les deux ont une courbe d’apprentissage plus longue que nécessaire pour ce cas.

Le point qui change tout : le chunking sémantique. On ne découpe pas bêtement par bloc de 512 tokens. On chevauche 50 tokens entre les chunks et on conserve le titre de la section parente comme métadonnée. Résultat : quand tu cherches « process deal > 50k€ », le vecteur retrouve le bon passage même si ta question ne contient aucun mot du texte original.

Le choix du vector store : Qdrant vs Pinecone vs pgvector

Le tableau ci-dessous résume les critères qui comptent pour une PME :

Notre verdict : si tu as déjà un Postgres et moins de 100 000 chunks, utilise pgvector. C’est gratuit, c’est chez toi, ça marche. Dès que tu dépasses ce seuil ou que tu veux la recherche hybride native, passe à Qdrant.

Méfie-toi du piège classique : « il suffit d’uploader les PDFs ». Non. Un PDF scanné non OCRisé, c’est une image. Un PDF avec des tableaux mal encodés, c’est du bruit. Il faut un vrai pipeline d’extraction et de nettoyage avant même de parler d’embeddings.

Le workflow n8n en 5 nœuds

Voici le workflow agent IA exact, nœud par nœud. Le schéma est reproductible sur n’importe quelle instance n8n en moins de 2h.

• Nœud 1 — Trigger : webhook Slack (une question posée dans #assistant-interne) OU cron quotidien pour la re-indexation automatique des sources
• Nœud 2 — Recherche hybride : requête BM25 + dense dans Qdrant, top 5 chunks retournés avec leur score de similarité
• Nœud 3 — Re-ranking : les 5 chunks sont repassés dans un cross-encoder (Cohere Rerank API) pour trier par pertinence réelle plutôt que par distance vectorielle brute
• Nœud 4 — Prompt système : instructions qui forcent Claude à citer ses sources exactes + seuil de confiance (« si le score < 0,65, réponds que tu ne sais pas »)
• Nœud 5 — Réponse + log : la réponse part dans Slack, chaque échange est loggé dans Postgres (question, chunks utilisés, score, réponse, feedback pouce haut/bas)

Le workflow n8n pour orchestrer un agent repose sur le pattern Perception → Raisonnement → Action. L’orchestrateur reçoit la question (perception), sélectionne les chunks pertinents (raisonnement), génère la réponse et la log (action). C’est l’architecture de base de tout agent IA fonctionnel.

Le log dans Postgres n’est pas optionnel. C’est ce qui te permet de mesurer, d’améliorer et de détecter une dérive avant qu’un utilisateur te remonte une réponse problématique.

Les 3 cas d’usage qui ont justifié le projet

La première semaine, l’équipe a posé 143 questions. Voici les trois profils qui ont justifié l’investissement à eux seuls.

Commercial : « Quel est notre process pour un deal > 50k€ ? » → réponse en 4 secondes avec lien vers la procédure Notion exacte. Avant : 20 minutes de recherche + appel au manager.

Onboarding RH : « Combien de jours de RTT si j’arrive le 15 mars ? » → l’agent cite le handbook RH et l’article de la convention collective applicable. Avant : email à la DRH, réponse le lendemain.

Support produit : « Pourquoi le client X a un comportement bizarre sur l’API ? » → l’agent croise 3 tickets HubSpot + 2 CR d’appel Sales et propose une hypothèse sourcée. Avant : 45 minutes de recherche manuelle.

Les 10 premières questions posées la semaine 1 donnent le ton :

1. « Quelle est la procédure d’onboarding pour un nouveau client Enterprise ? »
2. « Qui contacter en cas de bug bloquant un vendredi soir ? »
3. « Quels sont nos délais de paiement standard ? »
4. « Est-ce qu’on a une template de proposition commerciale pour le secteur santé ? »
5. « Comment gérer un litige sur une facture ? »
6. « Quelles sont les clauses de sortie dans notre contrat standard ? »
7. « Combien de jours d’ancienneté pour la semaine de congé supplémentaire ? »
8. « Où est la dernière version du deck investisseur ? »
9. « Quels clients ont un accès à la bêta de la feature X ? »
10. « Quelle est notre politique de remboursement des frais de déplacement ? »

Ce sont exactement les questions que tout le monde pose à tout le monde, et auxquelles personne ne sait jamais répondre avec certitude. Le agent IA RAG les centralise et les documente.

Ce que ça nous a coûté (et ce que ça nous a rapporté)

Voilà les chiffres réels, sans arrondi marketing.

Coût d’intégration initial : 2 jours à 850€/jour = 1 700€ one-shot. C’est le tarif d’une mission de build sur mesure. Pas de frais cachés, pas de licence supplémentaire.

Coût mensuel réel (moyenne sur 4 mois) :

• Claude API (Anthropic) : 22€/mois
• Qdrant Cloud EU : 12€/mois
• Hébergement n8n (VPS OVH) : 4€/mois
• Total : 38€/mois

ROI observé : 6h/semaine économisées par personne × 12 adoptants = 72h/semaine. Au coût horaire moyen de l’équipe, ça représente environ 2 800€/mois de temps salarié dégagé. Le retour sur investissement initial est atteint en moins d’un mois.

Taux d’adoption à 1 mois : 65% de l’équipe utilise l’agent au moins une fois par semaine. Aucune formation formelle, juste une démo de 15 minutes en réunion d’équipe.

Quand est-ce que ce n’est pas rentable ? Trois situations : moins de 5 personnes (le coût de maintenance dépasse le gain), moins de 500 documents dans la base de connaissances (trop peu pour justifier une base vectorielle pour la RAG), ou quand les réponses sont déjà triviales et documentées dans un seul endroit.

Les 5 pièges qu’on a rencontrés (pour que tu ne les reproduises pas)

C’est la section que tu ne trouveras pas chez les concurrents. Ce sont les vrais bugs de production, pas des mises en garde théoriques.

Piège 1 — Les PDFs sales. On a alimenté l’agent avec des PDFs exportés depuis un logiciel métier. Résultat : des caractères corrompus, des tableaux aplatis, des en-têtes répétés dans chaque chunk. L’agent inventait. Solution : extraction propre via des parsers dédiés (Docling, Unstructured), déduplication des documents, métadonnées obligatoires (source, date, auteur).

Piège 2 — Zéro garde-fou contre les hallucinations. Sans seuil de retrieval, l’agent répondait à tout, même quand il n’avait aucun chunk pertinent. Taux d’hallucination mesuré : 12% des questions. Solution : seuil de score de retrieval à 0,65 (en dessous = « je ne sais pas »), température du LLM à 0,1, prompt système explicite « si tu ne trouves pas dans le contexte, dis-le ».

Piège 3 — Pas d’observabilité. La première semaine, on avait aucun moyen de savoir si l’agent dégénérait progressivement. Solution : log de chaque échange (question, chunks utilisés + score, réponse, feedback pouce haut/bas) dans Postgres. C’est le minimum pour piloter la qualité en production.

Piège 4 — Les questions RH et juridiques sensibles. L’agent a répondu à une question sur un licenciement en citant un article qui ne s’appliquait pas au contrat concerné. Légalement dangereux. Solution : deny-list explicite sur les sujets sensibles (licenciement, maladie, procédures disciplinaires), redirection systématique vers un humain identifié, flag DPO sur les données sensibles.

Piège 5 — Pas de re-indexation automatique. Trois mois après le déploiement, les réponses citaient des procédures obsolètes. La doc avait évolué, l’agent non. Solution : cron quotidien à 2h du matin + webhook sur les mises à jour Notion et Drive pour déclencher une re-indexation incrémentale.

Make, Flowise, Cognee ou dev maison : la matrice de décision

La vraie question n’est pas « est-ce que je dois faire un RAG ? » mais « avec quoi ? » Voici la grille qu’on utilise avec nos clients.

Prends Make si tu as moins de 500 documents, pas de développeur, une équipe 100% ops/marketing qui veut un chatbot simple branché sur une FAQ Google Sheets. C’est le Zapier de l’IA : facile à prendre en main, limites rapides.

Prends Flowise pour du prototypage visuel. Drag-and-drop, configuration sans code, bon pour valider l’idée en 2 jours avant de décider si ça vaut un vrai build. Ne va pas en production complexe avec Flowise.

Prends Cognee si tu as plus de 50 000 documents hétérogènes. Cognee ingère plusieurs sources, construit un graphe de connaissances et relie les entités entre elles. C’est plus puissant que du RAG simple pour des corpus denses et interconnectés.

Fais développer sur mesure (notre cas) dès que tu cumules : plus de 5 sources à brancher, des données sensibles à isoler, des équipes différentes avec des droits d’accès distincts, et un SLA interne à tenir.

Pour aller plus loin sur les cadres IA en entreprise et le choix de la stack, je t’ai préparé un comparatif dédié. Pour les cas data plus avancés, jette un œil au chat with data et analytics conversationnel.

La checklist avant de te lancer (à imprimer)

12 questions à te poser honnêtement avant de commander une mission de build :

1. As-tu 500 documents ou plus dans ta base de connaissances ?
2. Y a-t-il au moins 3 personnes qui cherchent les mêmes infos chaque semaine ?
3. As-tu mesuré le temps perdu à chercher (même grossièrement) ?
4. Tes données sont-elles déjà dans un outil numérique (pas des classeurs papier) ?
5. As-tu un propriétaire désigné pour la base de connaissances ?
6. Qui est responsable si l’agent répond mal sur un sujet RH ou juridique ?
7. Tes données RH/juridiques sont-elles anonymisables ou isolables ?
8. As-tu un budget de 1 500€+ pour le setup initial ?
9. Quelqu’un peut-il maintenir la base de connaissances à jour chaque semaine ?
10. L’équipe est-elle prête à donner du feedback sur les réponses (pouce haut/bas) ?
11. As-tu un canal de communication interne (Slack, Teams) où brancher l’agent ?
12. Quelle est ta tolérance à l’erreur sur les premières semaines de déploiement ?

Les 3 red flags qui doivent te dire « n’y va pas » :

• Aucun propriétaire désigné pour la qualité des réponses
• Des données RH non anonymisées dans le même corpus que les docs commerciales
• Tolérance zéro à l’erreur (chirurgie, finance réglementée, juridique critique) sans garde-fous humains

Les 3 green lights qui disent « fonce » :

• Équipe de 10 personnes ou plus avec des questions récurrentes non adressées
• 3 sources de documentation ou plus à croiser
• Frustration réelle mesurée (temps de recherche, interruptions managers)

Ton premier agent n’a pas besoin d’être parfait

L’erreur classique : attendre d’avoir 100% de réponses correctes avant de déployer. En réalité, couvrir les 20 questions les plus fréquentes à 80% de précision représente 80% de la valeur perçue par l’équipe. C’est suffisant pour valider et améliorer en itérant.

Le bon KPI n’est pas le taux d’hallucination — c’est le temps gagné par semaine. Si l’équipe économise 6h chacune, le projet est un succès, même si l’agent se trompe sur 1 question sur 10 dans des cas rares.

Ce qu’on a appris à travers ce build : un agent IA interne n’est pas un produit qu’on installe et qu’on oublie. C’est un service vivant qui demande une maintenance légère, un propriétaire et une culture du feedback. La bonne nouvelle : une fois ces bases posées, l’adoption se fait d’elle-même.

Si tu veux savoir si ton entreprise est prête pour ce type de build — corpus, budget, gouvernance — je propose un audit de 30 minutes gratuit. Mentionne cet article, et on regarde ensemble ce que ça peut donner chez toi.

Si tu veux suivre l’aventure, abonne-toi !