Intégrer un chatbot IA sur un site client : la grille de décision que personne ne pose

Une fois par mois, je reçois le même message. Formulations variables, fond identique : « On voudrait ajouter un petit chatbot IA sur le site, c’est faisable ? » Le client a vu passer une démo, il imagine une bulle en bas à droite qui répond aux questions sur ses produits, et il pense raisonnablement que ça doit être un module à cocher quelque part.

Le problème, ce n’est pas la demande. Elle est légitime. Le problème, c’est qu’aucun de ces clients ne veut réellement la même chose, et que leurs sites tournent sur tout et n’importe quoi : du Shopify, du WordPress, du Drupal, parfois un site codé à la main par un prestataire parti depuis longtemps. La question « quel plugin ? » n’a pas de réponse universelle parce que ce n’est pas la bonne question.

Voici donc la grille que j’utilise pour trancher, quel que soit le CMS en face. Elle tient en une idée : un chatbot IA, ce sont deux couches distinctes qu’on confond presque toujours, et c’est cette confusion qui fait prendre les mauvaises décisions.

La mauvaise question (« quel plugin ? ») et la bonne (« qui possède le cerveau ? »)

Un chatbot IA sur un site, ce sont deux choses qui n’ont rien à voir l’une avec l’autre.

Il y a d’abord la couche de livraison : la bulle visible, le widget, le bout de code qui s’affiche dans la page. C’est purement de la plomberie front, et elle dépend entièrement du CMS. Sur Shopify on l’injecte d’une façon, sur WordPress d’une autre, sur un site from scratch on fait ce qu’on veut.

Il y a ensuite la couche cerveau : le modèle de langage qui rédige les réponses, et surtout la base de connaissance qui l’empêche de raconter n’importe quoi sur vos produits. Cette couche, elle, est totalement indifférente au CMS. Le même cerveau peut servir une boutique Shopify, un site WordPress et une appli maison sans changer une ligne.

Quasiment toutes les mauvaises intégrations que j’ai vues viennent de la confusion entre les deux. On choisit un « plugin chatbot » en croyant choisir un outil, alors qu’on choisit en réalité un package qui impose à la fois une couche de livraison verrouillée et un cerveau qu’on ne contrôle pas. La vraie question n’est donc pas « quel plugin », c’est : qui possède le cerveau, vous ou le fournisseur ?

L’échelle de contrôle : du turnkey verrouillé au pipeline que vous possédez

Tout se range sur une échelle, du moins au plus de contrôle. Je la pose toujours telle quelle devant un client, parce qu’elle rend la décision évidente.

Niveau 0, le clé-en-main intégral. Vous donnez des documents bruts à une plateforme, elle découpe, vectorise, stocke, récupère et répond. Vous ne touchez à rien. C’est un Chaterimo sur Shopify : installation en un clic, vous apportez éventuellement votre clé API du modèle, et c’est fini. Zéro effort, zéro contrôle. La base de connaissance est une boîte noire que vous nourrissez sans jamais voir l’intérieur.

Niveau 1, vos propres morceaux. Vous fournissez votre contenu déjà découpé, la plateforme l’indexe. Vous gagnez la main sur la granularité, rien d’autre.

Niveau 2, vos propres vecteurs. Vous calculez vous-même les représentations numériques de votre contenu (donc vous choisissez le modèle qui les produit), la plateforme ne fait plus que stocker et récupérer.

Niveau 3, le pipeline que vous possédez. Découpe, modèle, base vectorielle : tout vous appartient. L’outil branché sur le site ne fait qu’interroger votre index. C’est le maximum de contrôle, et accessoirement le seul niveau qui vous laisse réutiliser la même brique de connaissance sur dix sites clients à la fois.

Le piège, c’est que la quasi-totalité des chatbots clé-en-main sont verrouillés au niveau 0. Aucun ne propose les niveaux 1 à 3 : ce territoire-là, c’est celui du pipeline développeur. Donc dès qu’un besoin réel pousse vers le contrôle, on quitte mécaniquement le monde des plugins magiques.

La couche de livraison, CMS par CMS

Voyons maintenant la plomberie front, parce que c’est là que les clients croient que tout se joue, alors que c’est la partie la plus simple.

Shopify

Contre-intuitivement, Shopify est l’environnement le plus carré. Il existe un mécanisme prévu exactement pour ça : la theme app extension avec un app embed block. En clair, vous déclarez un petit bloc qui injecte votre widget dans toutes les pages, sans toucher au thème, et que le marchand peut activer ou désactiver depuis l’éditeur. La documentation Shopify cite littéralement les bulles de chat comme cas d’usage de référence.

L’intérêt par rapport au bricolage classique (éditer le thème à la main) : votre code survit aux mises à jour de thème et reste réutilisable d’une boutique à l’autre. C’est précisément ce qui change la donne en agence.

Le seul vrai garde-fou : votre clé API ne descend jamais côté navigateur. Le widget injecté appelle votre backend, et c’est le backend qui détient la clé et parle au modèle. Sinon n’importe quel visiteur lit votre clé dans le code de la page. Retenez-le, c’est l’erreur la plus fréquente et la plus chère.

Et cacher la clé ne suffit pas : votre backend doit aussi vérifier que la requête vient bien du widget légitime, pas d’un script qui tape votre endpoint en direct. Sur Shopify, le mécanisme propre est le proxy d’application, qui signe les requêtes côté Shopify et vous laisse valider la signature côté serveur ; à défaut, un token éphémère par session fait l’affaire. Sans ça, le dev pressé monte une API intermédiaire ouverte sur Render ou Supabase, et quelqu’un siphonne sa facture Anthropic en spammant l’endpoint pendant la nuit.

WordPress

C’est l’extrême « plug-and-play assumé » de l’échelle, et pour une fois sans compromis honteux. La meilleure solution que je connaisse est MXchat, parce qu’elle ne vous enferme pas : choix du modèle, choix du modèle d’embedding, et compatibilité avec des bases vectorielles externes. C’est rare qu’un plugin grand public laisse autant de contrôle.

J’ai d’ailleurs poussé l’expérience jusqu’à le faire tourner sur une base maison plutôt que sur le service vectoriel par défaut : voir MXchat sur DuckDB et MotherDuck, où je remplace l’infrastructure vectorielle lourde par de la recherche en SQL pur. Le point à retenir ici : sur WordPress, vous pouvez rester au niveau 0 pour la facilité tout en gardant une porte ouverte vers le niveau 2 ou 3 le jour où le client grandit.

From scratch et autres CMS (Drupal, etc.)

C’est le degré de liberté maximal, et donc le plus exigeant. Aucun mécanisme prévu, mais aucune contrainte non plus : un widget de chat léger (quelques dizaines de lignes de JavaScript) appelle votre backend, point. Sur Drupal vous le posez via un bloc ou une région de thème, sur un site maison vous l’incluez où vous voulez. La couche de livraison devient triviale, et toute la valeur se déplace vers le cerveau. Ce qui tombe bien, parce que c’est exactement le sujet suivant.

Le cerveau : RAG interne clé-en-main ou pipeline possédé

C’est ici que se joue la qualité réelle du chatbot, et c’est ici que je vous renvoie vers ce que j’ai déjà écrit en détail, pour ne pas réécrire trois mille mots de RAG. Mais voici le minimum pour suivre sans ouvrir quatre onglets.

Un chatbot qui doit répondre sur vos produits a besoin de RAG (Retrieval Augmented Generation). En une phrase : avant de laisser le modèle répondre, on va chercher les bons passages dans votre base, et on les lui glisse sous les yeux, pour qu’il cite vos données au lieu d’inventer. Si vous voulez le mécanisme complet, je l’ai détaillé dans Le RAG expliqué comme personne ne le fait.

Pour aller chercher ces « bons passages », on transforme chaque texte en embedding, c’est-à-dire en coordonnées numériques qui permettent de mesurer ce qui ressemble à quoi. Le détail qui tue : le modèle qui produit ces embeddings n’est presque jamais choisi consciemment, alors qu’il détermine la qualité de tout le reste. C’est tout le propos de Votre RAG a un talon d’Achille. Et c’est exactement là que les outils clé-en-main vous trahissent : leur option « apportez votre clé » couvre le modèle de génération, jamais le modèle d’embedding, qui reste imposé en interne. Vous croyez maîtriser, vous ne maîtrisez que la moitié.

D’où la bascule. Si vous voulez votre propre base vectorielle (Pinecone par exemple) et votre propre modèle d’embedding, vous quittez le clé-en-main pour un pipeline d’orchestration que vous possédez. Concrètement, un outil comme n8n auto-hébergé reçoit la question, l’embedde avec le modèle de votre choix, interroge votre index, puis passe le contexte récupéré au modèle de langage. Il existe même des modèles tout faits côté n8n pour Shopify et WooCommerce.

Petite nuance que beaucoup ratent : tout le monde n’a pas besoin d’une base vectorielle. Si votre connaissance est surtout structurée (un catalogue, des fiches), une récupération en SQL ou en BM25 fait parfois mieux et coûte dix fois moins cher, comme je le montre dans RAG sans base vectorielle. Pensez « quelle est la nature de ma connaissance » avant « quel vector store ». Au passage, si vous comptez aspirer du contenu public dans cette base, lisez d’abord la question piège que tout le monde se pose mal.

Et parfois, pas de RAG du tout

Le réflexe d’agence le plus utile que j’aie développé, c’est de savoir quand ne pas construire un RAG. Pour un site dont la connaissance est finie et stable (le catalogue d’un importateur automobile, les CGV, la FAQ livraison), monter un Pinecone est de la sur-ingénierie pure. Avec les fenêtres de contexte actuelles, on peut souvent coller toute la connaissance utile directement dans le prompt et se passer entièrement de récupération. C’est le déplacement que je décris dans Du RAG au CAG. Moins de pièces, moins de pannes, moins de latence. La question à se poser n’est pas « comment faire un beau RAG », c’est « ai-je vraiment besoin d’aller chercher quoi que ce soit ».

Les pièges que j’ai payés pour vous

Quelques erreurs que j’ai commises ou vues commettre, et qui coûtent toutes du temps ou de l’argent.

Empiler deux orchestrateurs. Mettre une plateforme conversationnelle comme Botpress en façade et n8n derrière pour faire le même travail. Botpress parle déjà nativement aux modèles et sait appeler une base externe. Soit il fait tout, soit il n’est qu’un widget et n8n est le cerveau, mais pas les deux à se marcher dessus. Choisissez où vit le cerveau, une fois.

Sacrifier le streaming sans le savoir. Faire transiter le modèle derrière un webhook synchrone (le cas typique d’un n8n branché en réponse directe) tue l’effet « la réponse s’écrit en direct ». L’utilisateur attend en silence, puis tout tombe d’un bloc. Sur un chat, c’est perçu comme lent même quand c’est rapide. Récupérer le streaming derrière n8n existe mais impose de passer par des Server-Sent Events ou des Websockets, ce qui change la nature de la plomberie : on n’ajuste plus un workflow, on monte une vraie couche temps réel. D’où l’arbitrage net : soit vous acceptez la réponse en bloc, soit vous changez d’architecture, il n’y a pas de demi-mesure indolore.

Croire ses propres métriques. Un RAG qui « marche en démo » et qui déraille en production, c’est l’histoire de la moitié des projets. Avant de livrer, mesurez vraiment, et méfiez-vous de ce que vous mesurez : vos métriques d’éval sont probablement fausses.

Sous-estimer l’économie réelle. Le « apportez votre clé » est presque toujours plus prévisible que les forfaits au message, mais encore faut-il modéliser l’usage. J’ai démonté le modèle économique de ces offres dans Le mirage de l’IA illimitée, et montré comment diviser la facture dans Prompt caching.

Souveraineté : qui possède la couche de connaissance ?

Au fond, toute cette grille revient à une question que je pose à chaque client, même quand il ne l’avait pas vue venir : à qui appartient la connaissance qui fait tourner le bot ? Au niveau 0, elle vit chez un tiers, dans un format que vous ne voyez pas, sur une infrastructure que vous ne maîtrisez pas, avec les implications RGPD que ça suppose dès qu’il s’agit de données clients. Au niveau 3, elle est à vous, sur votre serveur, réutilisable d’un site à l’autre, exportable le jour où vous changez d’outil.

Pour un client unique avec un besoin simple, le niveau 0 est parfaitement raisonnable et je le recommande sans complexe. Pour une agence qui veut capitaliser une brique de connaissance sur toute une flotte, c’est l’inverse : chaque heure passée à posséder le pipeline est un actif, pas un coût. C’est la même logique qui m’a fait migrer l’intégralité de mon parc de PrestaShop vers WooCommerce : préférer la maîtrise à la facilité, quand l’échelle le justifie.

Ma grille, en une page

Voici comment je tranche en pratique, sans réfléchir trois jours.

Le critère qui domine tous les autres : le besoin de réutilisation. Un seul site, un seul besoin, restez bas sur l’échelle et ne sur-construisez rien. Une flotte, un savoir-faire à capitaliser, montez et possédez.

Et pour finir sur l’horizon, parce que cette grille a une date de péremption : la bulle de chat est une étape, pas une fin. Demain, ce ne sont plus des humains qui interrogeront vos pages, mais des agents, directement. C’est tout l’enjeu de WebMCP et de la bascule que je décris dans Le RAG est mort, vive l’Agent. Le chatbot que vous installez aujourd’hui est, au mieux, le brouillon de l’interface que vos clients exposeront aux machines demain. Autant le construire en sachant à qui appartient le cerveau.