Les chatbots alimentés par modèles génératifs : de la FAQ scriptée aux agents qui agissent

Note refondue le 25 mai 2026. Article initialement publié en mars 2026 — refonte intégrale.

Le terme chatbot est devenu un mot-valise qui recouvre des systèmes structurellement différents. Un système d'arbres de décision scriptés des années 2015, un système RAG ancré dans une base de connaissances métier, et un agent capable d'exécuter des actions dans des systèmes existants n'ont pratiquement rien en commun sur le plan opérationnel, alors qu'ils partagent une interface conversationnelle apparente. Cette confusion produit des arbitrages coûteux pour les organisations qui en restent à une lecture indifférenciée.

Cette note expose la distinction entre ces générations successives, qualifie ce que chaque catégorie permet réellement, et identifie les contraintes spécifiques au cadre suisse qui structurent un déploiement durable.

Trois générations qui n'ont rien en commun

La conversation publique sur les chatbots mélange régulièrement trois familles de systèmes qui méritent d'être distinguées explicitement.

Les chatbots scriptés d'abord, qui constituent la génération antérieure et restent largement déployés. Leur fonctionnement repose sur des arbres de décision prédéfinis : l'utilisateur clique sur un bouton ou choisit dans une liste, le système suit le chemin programmé, et propose des réponses préformulées. Dès que la question sort du périmètre prévu, la réponse est invariablement « Je n'ai pas compris, pouvez-vous reformuler ? ». Cette génération couvre correctement les questions fréquentes et stables — horaires, tarifs publics, suivi de commande — mais échoue face aux demandes nuancées ou contextuelles. Sa principale qualité tient à sa prévisibilité opérationnelle ; sa principale limite tient à son incapacité à traiter ce qui n'a pas été prévu.

Les chatbots ancrés par RAG ensuite, qui constituent la génération actuelle dominante pour les projets d'entreprise sérieux. Ces systèmes combinent un modèle de langage avec un mécanisme de recherche sémantique dans une base de connaissances spécifique à l'organisation. Ils comprennent l'intention derrière une question formulée en langage naturel, ils retiennent le contexte de la conversation en cours, et ils produisent des réponses ancrées dans les documents propres à l'entreprise. La différence opérationnelle avec la génération antérieure est substantielle : le système ne suit pas un script, il raisonne sur la base d'informations vérifiées.

Les agents capables d'agir complètent la liste, et constituent la génération la plus récente. Un agent ne se contente pas de répondre à une question ; il combine un modèle de langage avec des outils — accès à un système de gestion existant, planification d'un rendez-vous, création d'un ticket de support, déclenchement d'un workflow d'approbation — pour exécuter une tâche concrète qui dépasse la simple conversation. Cette capacité d'action transforme la nature du système, qui devient un intermédiaire opérationnel et non seulement un canal d'information.

Comprendre dans quelle catégorie se situe un projet donné est la décision la plus structurante du cadrage initial. Chaque catégorie correspond à un effort de mise en œuvre différent, à un coût d'exploitation différent, et à un profil de risque différent.

La mécanique du RAG : ce qu'elle permet et ce qu'elle ne supprime pas

Le pattern RAG mérite d'être compris dans sa mécanique, parce que ses forces et ses limites sont structurelles plutôt qu'anecdotiques.

Sa mécanique repose sur quatre étapes successives. Les documents de l'entreprise — manuels, fiches produits, procédures, base de connaissances — sont d'abord découpés en segments et transformés en représentations vectorielles qui capturent leur sens sémantique. Quand un utilisateur pose une question, le système la transforme à son tour en représentation vectorielle et recherche les segments les plus proches sémantiquement. Les segments pertinents sont injectés dans le prompt envoyé au modèle de langage, avec la question initiale. Le modèle produit alors une réponse ancrée dans ces segments, avec la capacité de citer ses sources.

Cette mécanique répond au défi central des modèles de langage utilisés seuls : les hallucinations. En ancrant chaque réponse dans des documents vérifiés, le système reste factuel sur les questions couvertes par la base de connaissances. Et quand la base ne contient pas la réponse à une question, le système peut le dire explicitement plutôt que d'inventer une réponse plausible mais incorrecte.

La mécanique ne supprime cependant pas complètement les hallucinations. Le modèle peut encore extrapoler au-delà du contenu fourni, particulièrement quand les segments retournés par la recherche sont partiellement pertinents mais incomplets. Cette limite résiduelle appelle un monitoring des réponses et un système de retour utilisateur qui détecte les dérives.

Plus structurellement, la qualité d'un système RAG dépend directement de la qualité des données indexées. Des documents obsolètes produisent des réponses obsolètes ; des documents contradictoires produisent des réponses incohérentes ; des documents mal structurés produisent des recherches imprécises. L'alimentation et la maintenance de la base documentaire constituent un effort continu qui ne se résume pas à l'indexation initiale.

Les agents : quand l'IA passe à l'action

Les agents alimentés par modèles représentent l'évolution la plus récente, et probablement la plus structurante, de la catégorie. Leur intérêt opérationnel tient à leur capacité à exécuter une séquence d'actions pour accomplir une tâche complexe, plutôt qu'à simplement répondre à une question.

Quelques cas d'usage illustrent ce que cette capacité ouvre. Un agent peut vérifier le statut d'une commande dans le système de gestion d'une entreprise et fournir une réponse contextualisée au client. Il peut planifier un rendez-vous dans l'agenda d'un commercial après avoir qualifié le besoin du prospect. Il peut créer un ticket de support dans un système métier après avoir collecté les informations nécessaires. Il peut générer un devis personnalisé sur la base des paramètres extraits de la conversation. Il peut déclencher un workflow d'approbation interne avec la documentation appropriée.

Ce niveau de capacité demande un cadre technique plus sophistiqué que les générations antérieures. Les outils accessibles à l'agent doivent être définis explicitement, leurs permissions doivent être encadrées, les règles de sécurité doivent être posées. L'agent décide quel outil utiliser en fonction de la demande, mais cette décision reste dans un périmètre contrôlé par la conception du système.

Le coût d'exploitation d'un agent est substantiellement plus élevé qu'un chatbot RAG simple. Un agent peut effectuer plusieurs dizaines d'appels au modèle pour traiter une tâche complexe, contre un appel ou deux pour une réponse RAG classique. Cette caractéristique réserve l'usage des agents aux cas d'usage à forte valeur ajoutée où la complexité de la tâche justifie le coût.

Quatre cas d'usage qui structurent le marché suisse

L'observation des déploiements opérationnels dans le marché suisse fait émerger quatre cas d'usage qui constituent la majorité des projets sérieux.

Le support client multilingue continu d'abord. Le caractère multilingue structurel du marché suisse — français, allemand, italien, anglais — rend particulièrement pertinent un système qui maîtrise nativement plusieurs langues sans configuration supplémentaire. Pour une entreprise de services ou un acteur du commerce électronique, cette capacité libère un canal de support de premier niveau disponible en continu, avec une qualité linguistique que l'externalisation classique peine à atteindre dans les quatre langues simultanément.

Le support technique documenté ensuite. Une entreprise industrielle peut alimenter son système avec ses manuels techniques, fiches produits et guides de dépannage. Le système devient alors capable de guider un client dans la résolution d'un problème complexe en s'appuyant sur la documentation précise du produit concerné, plutôt que de proposer des réponses génériques qui obligent le client à chercher l'information par lui-même.

La qualification de prospects complète la liste des usages externes. Un système conversationnel sur le site web d'une entreprise peut poser les bonnes questions pour qualifier l'intention d'un visiteur, identifier précisément son besoin, et orienter vers le bon interlocuteur interne. L'interaction est immédiate et adaptée à la situation, ce que les formulaires de contact classiques ne permettent pas par construction.

L'assistant interne pour les collaborateurs ferme la liste, et constitue souvent le cas d'usage le plus simple à déployer avec le meilleur rendement. Un système alimenté par les procédures internes, les politiques de l'entreprise et la documentation technique permet aux collaborateurs de trouver rapidement l'information sans solliciter les équipes support internes. Cette application réduit la charge sur des équipes saturées, et elle améliore la qualité des décisions opérationnelles en facilitant l'accès à l'information de référence.

L'escalade humaine : conception aussi importante que la technologie

Un chatbot alimenté par modèle, quelle que soit sa génération, doit savoir reconnaître ses limites. Les demandes émotionnelles, les réclamations complexes, les cas atypiques qui sortent du périmètre des données indexées, doivent être transférés à un humain. La conception du parcours d'escalade est aussi importante que la technologie qui sous-tend le système.

Trois caractéristiques distinguent une escalade bien conçue d'une escalade mal pensée.

La détection des signaux d'escalade d'abord. Le système doit identifier — explicitement par des règles, ou implicitement par les caractéristiques de la conversation — les situations qui dépassent ses capacités. Un client visiblement mécontent, une question sortant du périmètre de la base de connaissances, une demande qui touche à un sujet sensible, doivent déclencher un transfert plutôt qu'une réponse forcée.

La continuité du contexte transmis ensuite. Quand l'escalade se déclenche, le collaborateur qui prend le relais doit recevoir l'historique de la conversation et le contexte qualifié de la demande, plutôt que de devoir tout redemander au client. Cette continuité est constitutive d'une expérience client respectueuse ; son absence transforme l'escalade en frustration supplémentaire.

La gestion claire de l'attente complète la liste. Si le transfert vers un humain ne peut pas être immédiat, le système doit le dire honnêtement, indiquer un délai réaliste, proposer un rappel ou un autre canal. Cette transparence préserve la confiance que les promesses irréalistes érodent.

Cette dimension est particulièrement structurante dans le contexte suisse, où la Loi fédérale sur la protection des données^[1] impose une transparence sur les processus automatisés qui affectent les utilisateurs. Lorsque le système produit ou prépare une décision automatisée affectant significativement l'utilisateur, la possibilité d'une revue humaine doit être traitée explicitement dès la conception.

Le cadre suisse de protection des données

Trois dimensions de la conformité à la Loi fédérale sur la protection des données méritent d'être posées explicitement au cadrage d'un projet de chatbot d'entreprise.

La transparence sur la nature du système d'abord. L'utilisateur doit savoir qu'il interagit avec un système automatisé, et non avec un collaborateur humain. Cette transparence n'est pas une formalité ; elle conditionne la confiance et la qualité de l'interaction. Elle se traite généralement par une mention explicite en ouverture de conversation.

Le traitement des données personnelles partagées ensuite. Si un client partage des informations personnelles au cours d'une conversation — coordonnées, identifiants, données de santé, données financières — ces informations entrent dans le périmètre de la Loi fédérale sur la protection des données. Leur traitement doit être conforme aux principes de licéité, de proportionnalité, et de transparence. Cette dimension demande une analyse explicite au cadrage du projet, plutôt qu'un traitement par défaut.

La localisation des traitements complète la liste. Si le système est hébergé sur des infrastructures sous juridiction étrangère, le transfert de données personnelles vers ces infrastructures peut soulever des questions de droit applicable et d'accès extraterritorial aux données. Pour les secteurs sensibles — finance, santé, administration publique — cette question doit être traitée explicitement. Des alternatives existent : hébergement sur infrastructure européenne ou suisse, déploiement de modèles ouverts sur infrastructure contrôlée. Chaque option présente un profil de coût et de complexité différent qui mérite d'être qualifié au cadrage.

La discipline qui distingue le déploiement durable

Le déploiement d'un chatbot d'entreprise alimenté par modèle ne se réduit pas à un choix technologique. Il appelle une discipline opérationnelle dont quelques orientations distinguent les projets qui produisent une valeur durable.

Le démarrage sur un périmètre limité d'abord. Plutôt que de viser un système capable de tout traiter dès le lancement, identifier un cas d'usage précis et mesurable — FAQ support, qualification de prospects, assistant interne sur un sujet documenté — produit des résultats plus rapides et des apprentissages plus utiles pour les extensions ultérieures.

L'investissement dans la base de connaissances ensuite. La qualité d'un système RAG dépend directement de la qualité des données indexées. Structurer, nettoyer et mettre à jour les documents avant de les indexer représente, dans la pratique observée en cabinet sur les projets MCVA, une part substantielle de l'effort total — typiquement entre la moitié et les deux tiers. Cette observation mérite d'être assumée plutôt que minimisée au cadrage.

La conception explicite de l'escalade humaine complète la liste. Les critères de transfert, les parcours de reprise par un collaborateur, la gestion du contexte transmis, méritent d'être pensés au démarrage du projet, pas découverts en exploitation.

La mesure continue et l'itération ferme la séquence. Suivre le taux de résolution, la satisfaction utilisateur, les questions qui n'obtiennent pas de réponse satisfaisante, alimente une amélioration continue qui distingue les systèmes qui consolident leur qualité sur la durée de ceux qui dérivent.

Un chatbot alimenté par modèle bien conçu absorbe une part substantielle des demandes répétitives, libère du temps pour les interactions à plus forte valeur ajoutée, et améliore l'expérience client par sa disponibilité immédiate et sa qualité de réponse. Un chatbot mal conçu produit de la frustration client et accumule une dette technique. La différence ne se joue pas dans le modèle utilisé. Elle se joue dans la rigueur du cadrage initial et dans la discipline du déploiement.

Sources

[1] Loi fédérale sur la protection des données (LPD), révision du 25 septembre 2020, entrée en vigueur le 1ᵉʳ septembre 2023. www.fedlex.admin.ch/eli/cc/2022/491/fr [↩]

Jérôme Deshaie est CEO de MCVA Consulting SA, cabinet suisse de conseil stratégique en intelligence artificielle, basé en Valais.