CORS suffit-il à protéger l'API de mon chatbot ?

Non. CORS est un mécanisme appliqué par le navigateur, qui décide si un script d'une autre origine peut lire la réponse. Un programme hors navigateur peut appeler votre serveur sans en tenir compte : il faut en plus limiter les appels et vérifier les sessions côté serveur.

Où mettre la clé d'API du modèle pour un chatbot de site ?

Sur votre serveur intermédiaire, dans un gestionnaire de secrets, jamais dans le code de la page. Anthropic recommande aussi des clés différentes pour le développement, les tests et la production.

Chatbot sur son site : la partie serveur à prévoir

Un chatbot d'IA sur un site web, ce n'est pas seulement une bulle en bas de l'écran. Derrière le widget (le petit programme affiché dans le navigateur du visiteur) il faut un serveur intermédiaire à vous, ou à votre fournisseur, qui garde la clé d'API du modèle, contrôle qui appelle, limite les abus, va chercher les bonnes informations et journalise les échanges. Le navigateur du visiteur ne doit jamais parler directement à l'API du modèle.

Cette page traite de cette partie serveur. Où coller le script du widget sur WordPress, Shopify ou Wix est expliqué sur Alaisia · Studios web ; le choix d'un chatbot et ses messages, côté métier, sur Collabor-IA · Site web.

Le schéma

Navigateur du visiteur                Votre serveur intermédiaire              Services
┌───────────────────┐   HTTPS   ┌──────────────────────────────────┐
│ Widget (script)   │ ────────► │ 1. Vérifie l'origine et la session│
│ - aucune clé      │           │ 2. Limite le débit par visiteur   │
│ - un jeton de     │ ◄──────── │ 3. Cherche le contexte (RAG, CRM) │ ──► Index documentaire
│   session court   │  réponse  │ 4. Appelle le modèle (clé ici)    │ ──► API du modèle
└───────────────────┘ diffusée  │ 5. Journalise                     │ ──► Journal
                                └──────────────────────────────────┘

1. La clé reste sur le serveur

Tout ce qui est envoyé au navigateur est lisible par le visiteur : une clé d'API placée dans le code de la page peut être copiée et utilisée à vos frais. La clé vit donc sur le serveur intermédiaire. Anthropic recommande de ne jamais l'écrire dans le code ni dans un fichier de configuration, d'utiliser la solution de gestion de secrets de votre hébergeur cloud plutôt qu'un fichier .env, et d'avoir des clés distinctes pour le développement, les tests et la production. Les règles complètes des éditeurs sont sur Cercle IA Tech · API.

Le widget, lui, reçoit au mieux un jeton de session court, émis par votre serveur, qui ne donne accès qu'à votre propre point d'entrée.

2. CORS : utile, mais pas une protection

CORS (Cross-Origin Resource Sharing) est, selon MDN, un mécanisme fondé sur des en-têtes HTTP par lequel un serveur indique au navigateur quelles autres origines peuvent lire ses réponses. Réglez-le correctement :

Access-Control-Allow-Origin avec l'adresse exacte de votre site, plutôt que * ;
si le widget envoie des cookies, le joker * est de toute façon refusé : MDN précise que le serveur doit alors indiquer une origine explicite, sinon le navigateur bloque la réponse ;
les requêtes POST en JSON déclenchent une requête préalable OPTIONS (« preflight ») à laquelle votre serveur doit répondre.

Mais CORS n'empêche pas un script hors navigateur d'appeler directement votre serveur : il règle ce qu'un navigateur expose à une page, pas qui peut envoyer une requête. Les vraies protections sont aux étapes suivantes.

3. Limiter le débit par visiteur

Un chatbot public est une porte ouverte sur votre facture d'API. Prévoyez :

Limite	Pourquoi
Messages par session et par minute	Empêcher un robot de vider votre budget
Longueur maximale d'un message	Un message immense coûte cher en jetons d'entrée
Nombre de tours par conversation	Le contexte grossit à chaque tour
Plafond de dépense chez le fournisseur, s'il en propose un	Filet de sécurité si tout le reste lâche

Côté fournisseur du modèle, consultez régulièrement les pages d'usage et de journaux de vos clés, comme le recommande Anthropic pour sa console.

4. Donner le bon contexte, et seulement lui

Le serveur intermédiaire est aussi l'endroit où l'on choisit ce que le modèle voit : extraits de documents publics (principe du RAG, la génération augmentée par la recherche), éventuellement une donnée lue en direct (le statut d'une commande, après vérification de l'identité du client). Un visiteur anonyme ne doit jamais déclencher la lecture d'une donnée personnelle.

C'est aussi là que se place la défense contre l'injection de prompt : un message de visiteur est une donnée, pas une consigne, et le serveur ne doit jamais donner au modèle un outil qu'un visiteur anonyme n'aurait pas le droit d'utiliser lui-même.

5. Diffuser la réponse

Un modèle met plusieurs secondes à produire une réponse complète. La diffusion au fil de l'eau (streaming) affiche le texte pendant qu'il se génère : le serveur intermédiaire relaie le flux du modèle vers le widget. Prévoyez la coupure propre si le visiteur ferme la fenêtre, pour ne pas payer une réponse que personne ne lira.

6. Journaliser

Pour chaque échange : un identifiant de session, l'heure, la question, les sources utilisées, la réponse, le modèle appelé, le nombre de jetons. Sans ce journal, impossible de corriger une mauvaise réponse ou d'expliquer une hausse de coût. Les données personnelles qu'il contient suivent vos règles de conservation.

Faire ou prendre une plateforme

Monter ce serveur soi-même donne la main sur tout, et la charge de tout. Une plateforme de chatbot fournit le widget et le serveur intermédiaire déjà assemblés : c'est par exemple le modèle d'ALMA, la plateforme IA pour PME d'IArche, dont la page Fonctionnalités annonce un « Widget Intégrable » en « une seule ligne de code ». Dans les deux cas, posez les mêmes questions : où est la clé, quelles limites par visiteur, quel journal, quel contexte donné au modèle.