Un assistant IA qui qualifie une demande entrante à ma place

Le problème

Un visiteur qui a une question précise n'écrit pas dans un formulaire : il part. Et les demandes qui arrivent quand même arrivent floues — « j'aimerais automatiser des trucs » — ce qui impose deux ou trois allers-retours avant de savoir s'il y a un projet. Le formulaire de contact déplace le travail de qualification sur le destinataire, au moment le plus coûteux : après la perte de l'attention du visiteur.

Ce que j'ai construit

• Un chat en streaming token par token : la réponse s'écrit sous les yeux du visiteur, sans attente d'un bloc complet. Le flux est parsé à la main, sans dépendance.
• Une base de connaissances versionnée dans le code (parcours, savoir-faire, réponses fréquentes), injectée dans le prompt système. Corriger une réponse de l'assistant est une modification de texte, pas un réentraînement.
• Deux moteurs interchangeables derrière une seule interface — Groq (Llama 3.3 70B) ou Claude — sélectionnés par variable d'environnement. Changer de fournisseur ne touche pas au reste de l'application.
• Une capture de brief à la fin de la conversation : le visiteur laisse un moyen de contact, l'historique de l'échange part avec la demande — donc le contexte est déjà là.
• Une double notification volontairement redondante : le contenu du brief par e-mail (Resend), et une alerte Telegram qui signale l'arrivée sans transporter aucune donnée personnelle. Si un canal tombe, la demande n'est pas perdue.
• Une pastille d'état en façade : un ping léger sur l'API du modèle, mis en cache 60 secondes, qui vérifie que la clé est valide sans consommer un seul token.

Les garde-fous (c'est là que tout se joue)

• Repli scripté : si aucun moteur n'est configuré ou joignable, l'assistant sert des réponses écrites à l'avance au lieu d'afficher une erreur. Le site ne tombe jamais en panne d'IA — il dégrade.
• Vérification d'origine sur chaque route : une requête qui ne vient pas du site est refusée. L'assistant ne peut pas servir de proxy gratuit vers un modèle payant.
• Limitation de débit par adresse IP, en mémoire vive, sur une fenêtre d'une minute — l'IP n'est écrite dans aucune base ni aucun journal.
• Champ leurre (honeypot) sur le formulaire de brief : les robots le remplissent, les humains ne le voient pas.
• Aucune clé d'API exposée au navigateur : tous les appels aux modèles partent du serveur. Aucune variable publique dans le bundle.

Ce que j'ai accepté de perdre

• La limitation de débit vit en mémoire vive, donc par instance serveur : sur plusieurs instances, un attaquant déterminé obtient un multiple de la limite. Accepté en connaissance de cause — la parade complète demande un magasin partagé (Redis), soit une dépendance et un coût permanents pour un site vitrine. Le jour où l'abus devient réel, c'est le premier chantier.
• La pastille d'état a jusqu'à 60 secondes de retard : le statut est mis en cache pour ne pas interroger le fournisseur à chaque visite. Un incident très bref peut donc passer inaperçu.

Ce que ça donne chez vous

• Support de niveau 1 : répondre aux questions récurrentes sur vos produits et vos process depuis votre documentation, et n'escalader que ce qui le mérite.
• Pré-qualification commerciale : un assistant qui pose les bonnes questions avant de mobiliser un commercial, et transmet une fiche déjà remplie.
• Assistant interne : interroger en langage naturel des procédures, une convention collective, un référentiel technique — au lieu de fouiller un intranet.