01Agents d'accueil et de diagnostic d'entreprise
Diagnostic conversationnel à état
Architecture
- Backend Node.js / Express ; frontend JavaScript servi en statique.
- Accueil : POST /api/agent → OpenAI Responses → historique par session.
- Diagnostic : /start puis /:id/message — états relus côté serveur à chaque tour, puis sauvegardés avant la réponse.
- Les deux agents n'échangent pas de données : chacun a sa propre persistance et son propre point d'entrée.
Rôle du LLM
- Accueil : un appel OpenAI Responses (gpt-4o-mini) par message, avec l'outil de recherche web proposé au modèle.
- Diagnostic : réponse principale demandée en JSON (json_object), analysée puis validée avant usage.
- Pipeline à appels conditionnels : arbitre de focus, génération de section, extractions ciblées et réparations selon l'état du tour.
- Recherche web contextuelle au format json_schema strict, avec sources, déclenchée quand un besoin est détecté.
Garanti par le code
- Les états d'exploration, l'inventaire des processus et le registre de questions peuvent imposer ou remplacer la question du modèle.
- Une question n'est marquée « posée » que si elle a réellement été livrée.
- Le serveur décide de la complétude (isDiagnosticReadyForPlan) avant d'autoriser le plan ; un plan valide déjà stocké est réutilisé.
- Contrôles d'entrée, propriété de session, limitation de débit et réponses de repli.
Données / mémoire
- Accueil : messages conservés par session ; les 20 derniers sont renvoyés au modèle.
- Diagnostic : historique, sections, focus, progression et états métier persistés côté serveur, chiffrés, écrits par fichier temporaire puis renommage.
- Recherche contextuelle mise en cache par conversation, avec durée de validité.
- Accueil : des cas de processus enregistrés sont injectés dans le prompt comme exemples de référence.
Stack & tests
- JavaScript, Node.js, Express, OpenAI, API REST
- Aussi : node:test, Fichiers JSON chiffrés
- Suite node:test : conversation, recherche, routes, plan.
Limites assumées
- Pas de RAG vectoriel : la recherche est une recherche web, et les cas de l'accueil sont injectés dans le prompt.
- Aucun transfert automatique de l'accueil vers le diagnostic.
- L'agent d'accueil répond en texte libre : sa qualification n'est pas une fiche structurée.
- Le nombre d'appels LLM par tour n'est pas fixe.
Assistant IA de pilotage économique pour atelier de boulangerie
Intentions bornées + moteur de calcul
Architecture
- Interface React, API HTTP Node.js (serveur natif) en TypeScript, base SQLite.
- Le chat passe par POST /api/chat : classification, puis dispatch vers une fonction métier par un switch.
- Classification par règles ou par OpenAI, selon le réglage enregistré.
- Application locale (127.0.0.1) avec contrôle d'hôte, d'origine et d'en-tête sur les requêtes de modification.
Rôle du LLM
- Classification : le modèle reçoit le message et renvoie un JSON intent / entities ; le code vérifie l'intention et ne garde que des champs typés.
- Extraction de factures PDF / image en json_schema strict, ou via un service OCR configurable.
- Suggestion de composition d'un produit, vérifiée en structure et renvoyée comme simple proposition.
- Le modèle ne rédige pas les réponses métier : elles sont construites par le code.
Garanti par le code
- Coûts, marges et impacts calculés par le moteur métier, en arithmétique décimale.
- Liste fermée d'intentions : une sortie inconnue devient UNKNOWN avec explication.
- Validation des champs et des valeurs numériques extraits des factures.
- Alertes (hausses de prix, marges, données manquantes) recalculées à chaque consultation.
Données / mémoire
- SQLite : fournisseurs, ingrédients, recettes, produits, factures, volumes et réglages.
- Journal d'audit métier pour certaines modifications.
- Pas de mémoire conversationnelle : la route ne reçoit que le message courant.
Stack & tests
- TypeScript, Node.js, React, SQLite, OpenAI, API REST, Vitest, Playwright
- Aussi : Vite, fraction.js, Service OCR Python / FastAPI (optionnel), Tests Node
- Tests Node, Vitest (interface) et Playwright (navigateur).
Limites assumées
- Pas d'agent autonome qui orchestre librement des services.
- Pas de RAG ni de mémoire conversationnelle.
- Pas d'authentification ni de multi-entreprise : une instance locale par atelier.
- Les alertes s'affichent à la consultation ; aucune notification n'est envoyée.
SaaS de gestion de formation intégrant plusieurs fonctions IA
SaaS multi-tenant + fonctions IA spécialisées
Architecture
- Node.js / Express, MongoDB / Mongoose, sessions stockées en base.
- Multi-tenant : chaque centre est un tenant ; utilisateurs et entreprises clientes y sont rattachés ; middlewares de rôle et de tenant.
- Contrôleurs métier qui appellent un service LLM commun, puis un parsing et des contrôles propres à chaque usage.
- Tâches planifiées (node-cron) : emails de prospection programmés, sauvegardes.
Rôle du LLM
- Fournisseur et modèle choisis par configuration : OpenAI, Anthropic ou API compatible.
- Assistant pédagogique : réponse en JSON (texte, document à ouvrir, action), à partir des modules, ressources et texte des PDF de la formation, cités avec leur page quand elle est connue.
- Mode vocal : question transcrite par Whisper, réponse lue par synthèse vocale.
- Quiz et questions de positionnement demandés en JSON, puis analysés et normalisés.
- Missions : le modèle propose une liste d'actions ; il ne les exécute pas.
- Recherche web Tavily dans une mission, distincte des propositions d'actions du modèle.
- Fiche commerciale en JSON : résumé, problèmes, opportunités, offre et priorité.
Garanti par le code
- Missions : 5 types d'action autorisés, 20 actions maximum par exécution, tout autre type rejeté avant la revue.
- Après validation humaine, certains types d'action modifient les données de prospection ; les autres sont seulement marqués approuvés. Une action non traitée expire.
- Assistant pédagogique : une vidéo demandée par le modèle n'est lancée que si elle existe dans la formation ; une réponse non JSON est rattrapée par un repli.
- Le contexte de l'assistant est limité à la formation du stagiaire, dans son centre.
- Audit technique du site d'un prospect par règles HTML et HTTP, sans IA.
Données / mémoire
- MongoDB : tenants, utilisateurs, entreprises, stagiaires et progression, formations, sessions, positionnements, prospects, missions et actions en attente.
- Les données métier et le texte des supports sont injectés directement dans les prompts.
- Actions de mission conservées avec statut et historique de décision.
- Sauvegardes locales et vers un stockage compatible S3, planifiées.
Stack & tests
- JavaScript, Node.js, Express, MongoDB, OpenAI, Anthropic, Tavily, API REST, Jest
- Aussi : Mongoose, OpenAI Whisper / TTS, pdf-parse, node-cron, Socket.IO, Supertest, Stripe, SMTP / SMS
- Jest et Supertest : unitaires et intégration.
Limites assumées
- Pas de RAG vectoriel : les supports et les données sont injectés directement dans les prompts.
- Pas d'orchestration multi-agents.
- La validation du JSON est partielle selon les usages (schéma complet non vérifié pour la fiche commerciale et le positionnement).
- Seuls certains types d'action approuvée sont exécutés automatiquement.
- Le refus des questions hors formation est une consigne donnée au modèle, pas un contrôle serveur.
Assistant conversationnel multi-hôtel avec RAG hybride
RAG hybride + workflows métier
Architecture
- Next.js 16 et React en TypeScript ; Supabase (PostgreSQL) avec l'extension pgvector.
- Chunking par paragraphes (~800 caractères, recouvrement de 100) puis embeddings OpenAI (text-embedding-3-small, 1536 dimensions).
- Recherche hybride en SQL : union du top-k vectoriel et du top-k lexical (tsvector), chaque passage portant ses deux scores.
- Multi-hôtel : données filtrées par hôtel, avec politiques Row Level Security dans les migrations.
Rôle du LLM
- Deux branches de réponse : « ancrée » quand des passages pertinents sont trouvés, « sans contexte » sinon — le modèle doit alors qualifier sa réponse (answered, fallback, handoff).
- Sortie structurée via responses.parse et un schéma Zod.
- Extraction de la demande de séjour (dates, voyageurs) à partir de l'historique, également en sortie structurée.
- Le modèle signale lui-même un échange abusif ; la conversation est alors marquée pour modération.
Garanti par le code
- Seuils de similarité et règles de sélection des passages fixés dans le code.
- Un hébergement ou un partenaire recommandé par le modèle n'est retenu que s'il figure parmi les candidats proposés par le serveur.
- Le bouton vers le moteur de réservation est décidé par la configuration de l'hôtel (lien ou widget), jamais par le modèle.
- La demande de rappel humain est détectée par des règles explicites — le modèle ne la classe jamais. Ce workflow ne fait aucun appel LLM.
- Le numéro de téléphone du client n'est jamais transmis au modèle.
Données / mémoire
- Sources de connaissances et passages vectorisés par hôtel, avec suivi de fraîcheur.
- Informations temporaires (événements avec date de fin) injectées dans le contexte tant qu'elles sont actives.
- Conversations persistées par hôtel ; seule une partie récente de l'historique est renvoyée au modèle.
Stack & tests
- TypeScript, Next.js, React, Supabase, PostgreSQL, pgvector, OpenAI, Zod, Vitest, API REST
- Aussi : Row Level Security, Twilio (SMS), Tests SQL
- Tests Vitest et contrôles SQL (RLS, recherche hybride).
Limites assumées
- L'assistant ne réserve pas de chambre : il prépare la demande et dirige vers le moteur de réservation de l'hôtel.
- Aucune vérification de disponibilité en temps réel n'est branchée.
- Le spa a son propre workflow de réservation, distinct du parcours chambre.