La plupart des gens considèrent les chatbots comme une seule et même chose. Ce n’est pas le cas. Ce terme couvre en réalité deux systèmes construits différemment, qui échouent différemment et coûtent des montants différents à exploiter. Cette différence est importante lorsque vous devez choisir quoi construire, ou essayer de comprendre pourquoi un système déjà mis en place continue de poser problème.
Ce guide va plus loin que la plupart des comparatifs habituels. Il couvre la manière dont chaque système traite réellement un message, les situations dans lesquelles il échoue avec de vrais utilisateurs, ce qu’il coûte à grande échelle, et comment combiner les deux lorsque aucun ne suffit seul.

La Différence Fondamentale

Un chatbot traditionnel est un système entièrement conçu à l’avance. Vous décidez de tout ce qu’un utilisateur peut dire, vous créez un chemin pour chaque possibilité, et le bot suit ces chemins. Tout ce qui sort de ce que vous avez conçu échoue.
Un chatbot GPT est un système que vous guidez par des instructions. Vous rédigez un prompt décrivant comment le bot doit se comporter, et le modèle détermine quoi répondre à partir de l’ensemble de la conversation. Il a été entraîné sur une énorme quantité de texte, ce qui lui permet de gérer des entrées que vous n’aviez jamais prévues.
Le résultat : les chatbots traditionnels ne sont performants qu’à hauteur de leur couverture. Les chatbots GPT ne sont performants qu’à hauteur de votre capacité à contrôler leurs réponses. Les deux ont une limite. Ils atteignent simplement cette limite à des endroits différents.

Comment Fonctionnent les Chatbots Traditionnels

Ce qui arrive à un message

Lorsqu’un utilisateur envoie un message, le système le fait passer par plusieurs étapes. D’abord, il nettoie et découpe le texte. Ensuite, il essaie d’associer le message à l’une des intentions définies pendant la configuration, essentiellement des catégories comme « vérifier le statut d’une commande » ou « réinitialiser un mot de passe ». Cette correspondance est effectuée par un classificateur entraîné ou des règles de correspondance, mais il ne peut faire correspondre le message qu’à des catégories qui existent déjà.
En parallèle, il recherche des valeurs spécifiques nécessaires pour compléter la réponse : un numéro de commande, une date, un identifiant de compte. Ces valeurs sont appelées des slots. Si un slot requis manque, le bot le demande avant de continuer.
Une fois l’intention et les slots identifiés, un gestionnaire de dialogue fait avancer la conversation vers l’étape suivante. Il s’agit généralement d’une machine à états, ce qui signifie que le bot ne peut avancer que sur des chemins explicitement construits.

Où cela casse

Le système ne fonctionne qu’à l’intérieur de ce que vous avez conçu. Cela semble acceptable jusqu’à ce que de vrais utilisateurs commencent à l’utiliser.
Les utilisateurs ne formulent pas les choses comme les concepteurs l’attendent. Ils combinent deux questions dans un seul message. Ils sautent une étape que le bot supposait obligatoire. Ils utilisent des mots légèrement différents et le classificateur choisit soit la mauvaise intention, soit abandonne et renvoie un message de fallback.
Les fallbacks sont le signe visible des lacunes de couverture. Chaque « désolé, je n’ai pas compris » correspond à quelque chose qui n’a pas été conçu. Le problème s’aggrave avec le temps, car les utilisateurs qui rencontrent un fallback essaient souvent de reformuler leur demande, ce qui les éloigne encore davantage des intentions connues par le bot.
Les nouveaux produits, les changements de politique et les cas particuliers qui apparaissent en production nécessitent tous de nouvelles intentions, de nouveaux chemins et de nouveaux tests. Les grands déploiements de chatbots traditionnels passent souvent autant de temps à étendre leur couverture qu’à construire le système initial.

Où cela fonctionne réellement

Lorsque toute la conversation peut être cartographiée à l’avance, les chatbots traditionnels sont le bon choix. Réinitialisation de mot de passe, suivi de commande, prise de rendez-vous, formulaires de déclaration : ces cas ont des structures connues, un nombre limité de chemins et des actions backend liées à des étapes précises. Ils sont aussi faciles à auditer, car chaque réponse est liée à une règle.

Comment Fonctionnent les Chatbots GPT

Ce qui arrive à un message

Lorsqu’un message arrive, le système construit une fenêtre de contexte. Il s’agit d’un grand bloc de texte qui contient généralement le prompt système, c’est-à-dire les instructions décrivant comment le bot doit se comporter, l’historique de la conversation jusqu’à ce point, tout contenu récupéré depuis une base de connaissances ou des documents, ainsi que le message actuel de l’utilisateur.
Le modèle lit l’ensemble de ce contexte et génère une réponse en prédisant ce qui devrait venir ensuite. Il n’y a pas d’étape de correspondance d’intention. Il n’y a pas de routage vers un chemin prédéfini. La réponse provient directement de l’interprétation du contexte par le modèle.
C’est pour cela que les formulations variées ne posent pas problème. Un utilisateur disant « je n’arrive pas à me connecter », « mon compte est bloqué » ou « la page de connexion ne fonctionne pas » recevra une réponse cohérente sans que vous ayez à créer une gestion séparée pour chaque formulation.

Le Problème de Mémoire

La fenêtre de contexte possède une limite de taille. À mesure qu’une conversation devient plus longue, les anciens messages finissent par sortir du contexte. Le modèle perd alors ce qui a été dit auparavant.
Dans les démonstrations courtes, cela n’apparaît jamais. Dans les longues conversations réelles, si.
Un utilisateur qui a donné les informations de son compte au début peut se voir les redemander plus tard simplement parce que ces informations ne sont plus dans la fenêtre de contexte.
Les systèmes en production gèrent cela grâce à la synthèse des conversations, en ne conservant que les messages les plus importants, ou en extrayant les informations clés pour les réinjecter dans chaque nouveau contexte. Si vous ignorez ce problème, vous obtenez un bot qui fonctionne bien en test mais frustre les utilisateurs en usage réel.

Les Réponses ne Sont pas Cohérentes

Le modèle ne produit pas toujours exactement la même réponse pour une même entrée. C’est volontaire : une certaine variation dans le langage rend les conversations plus naturelles. Mais pour les cas où une sortie exacte et cohérente est essentielle, comme les mentions légales, les informations médicales ou les instructions étape par étape, vous avez besoin de contrôles supplémentaires : prompts stricts, formats de sortie structurés et vérification des réponses avant qu’elles n’atteignent l’utilisateur.

Le Prompt Système est Votre Outil Principal

Le prompt système est l’endroit où vous définissez ce que le bot fait, ce qu’il ne doit pas traiter, comment il doit répondre et quelles contraintes il doit respecter. C’est l’équivalent GPT du design conversationnel.
Ce n’est pas un travail ponctuel. Les prompts système doivent être ajustés en fonction des échecs observés en production, de la même manière que les intentions d’un chatbot traditionnel doivent être enrichies. La différence est qu’une modification de prompt prend effet immédiatement sur toutes les conversations sans nécessiter un nouvel entraînement ni un redéploiement complet.

Ce Qui Fait Réellement Échouer Chaque Système

Les listes de fonctionnalités ne disent pas grand-chose. Ce qui en dit plus, c’est de savoir dans quelles conditions chaque système échoue.
Entrée ambiguë ou mal formulée: les chatbots traditionnels choisissent soit l’intention la plus proche, soit renvoient un fallback. Les chatbots GPT répondent généralement quand même, mais ils peuvent répondre à la mauvaise interprétation. L’un vous donne du silence, l’autre une réponse fausse mais confiante.

• L’utilisateur saute une étape ou change l’ordre prévu: les chatbots traditionnels cassent. Les machines à états attendent une séquence précise et ne savent pas gérer les sauts ou retours arrière. Les chatbots GPT gèrent cela parce qu’ils lisent l’ensemble du message et non une étape positionnelle dans une séquence fixe.
• Même demande formulée de nombreuses façons: les systèmes traditionnels nécessitent une gestion explicite de chaque variation. Les systèmes GPT gèrent cela grâce à leur compréhension du langage sans travail supplémentaire.
• Des données personnelles apparaissent au milieu de la conversation: les chatbots traditionnels gèrent cela avec des règles définies d’extraction et de masquage des données. Les systèmes GPT font passer ces données personnelles dans la fenêtre de contexte, ce qui signifie qu’elles peuvent toucher le modèle et potentiellement être stockées dans les logs ou le contexte récupéré. Cela nécessite un filtrage d’entrée explicite et des règles strictes de journalisation.
• Pic soudain de trafic: les chatbots traditionnels fonctionnent sur une infrastructure basée sur des règles et montent en charge de façon prévisible avec un faible coût de calcul. Les chatbots GPT montent en charge avec le coût d’inférence du modèle, plus élevé par requête et soumis aux limites du fournisseur de modèle. Un pic soudain peut donc provoquer de la latence ou du throttling qu’un système traditionnel ne subirait pas.

Ce Que Cela Coûte Réellement

Chatbots Traditionnels

Le coût est lourd au départ. Concevoir les intentions, construire les chemins conversationnels, connecter les systèmes backend et tester la couverture demande beaucoup de temps avant qu’un seul utilisateur n’utilise le système. Un déploiement gérant 50 intentions avec une complexité raisonnable peut prendre des mois pour être correctement réalisé.
Une fois en production, les coûts d’exploitation sont faibles et prévisibles. Les réponses basées sur des règles nécessitent très peu de calcul. L’infrastructure évolue de façon linéaire avec le volume des requêtes.
Le coût souvent sous-estimé est la maintenance continue. Chaque nouveau produit, chaque changement de politique et chaque cas particulier découvert en production nécessitent une nouvelle intention, un nouveau chemin et une nouvelle phase de tests. Dans les grands déploiements, cela devient un coût d’ingénierie permanent qui grandit avec l’entreprise.

Chatbots GPT

Le coût initial se déplace du design conversationnel vers la configuration du système : rédaction et test du prompt système, mise en place d’un système de récupération documentaire si nécessaire, connexion des outils et ajout de garde-fous. Cela est généralement plus rapide pour couvrir de nombreux cas, mais demande des compétences différentes.
Les coûts d’exploitation sont basés sur l’usage. Vous payez par token, ce qui correspond approximativement au nombre de mots traités. Les prix varient selon le modèle, mais avec les tarifs actuels, un système gérant 100 000 conversations par jour avec des contextes de taille moyenne génère des coûts mensuels significatifs. Les conversations longues et les appels au système de récupération augmentent encore ces coûts.
La maintenance se concentre sur l’ajustement des prompts, la qualité des contenus récupérés et l’adaptation des garde-fous à mesure que de nouveaux cas d’échec apparaissent. Cela n’a pas le même problème de croissance incontrôlée que l’expansion de couverture des chatbots traditionnels, mais cela demande tout de même une attention constante.
La version simple : pour des interactions étroites, stables et à fort volume, les chatbots traditionnels sont plus économiques. Pour des conversations larges, variables ou qui changent fréquemment, les chatbots GPT réduisent suffisamment la charge de conception pour compenser leurs coûts d’exploitation plus élevés.

Sécurité et Conformité

Chatbots Traditionnels

Le risque se situe principalement au niveau des intégrations. Le chatbot lui-même ne génère rien, il n’y a donc pas de risque de sortie imprévisible. Les préoccupations concernent les données collectées, leur destination et les droits d’accès des intégrations backend.
Les audits de conformité sont simples parce que chaque chemin conversationnel est lié à une règle explicite.

Chatbots GPT

Le profil de risque est différent sur plusieurs points précis.
L’injection de prompt est la principale surface d’attaque. Un utilisateur peut écrire un message essayant de contourner le prompt système pour pousser le bot à faire quelque chose qu’il ne devrait pas faire. Un prompt système bien conçu réduit ce risque, mais ne le supprime pas totalement, surtout dans les longues conversations où le modèle doit prendre en compte beaucoup de contexte.
Les fuites de données via le système de récupération documentaire se produisent lorsque celui-ci récupère des documents contenant les données d’un autre utilisateur et que le modèle réutilise ces informations dans sa réponse. Les contrôles d’accès doivent être appliqués au niveau de la récupération documentaire, pas uniquement au niveau applicatif.
Les réponses imprévisibles dans les secteurs réglementés représentent un vrai problème. En finance, en santé ou dans le domaine juridique, une réponse hors des limites prévues peut créer un risque réglementaire. Vous ne pouvez pas supposer que le modèle restera dans les limites par défaut. Cela nécessite une classification des réponses et des mécanismes de revue humaine intégrés dans la conception du système.
La journalisation est plus complexe, car il faut enregistrer toute la fenêtre de contexte, y compris les documents récupérés et l’historique de conversation, afin de pouvoir reproduire et auditer une réponse précise. Cela crée des volumes de logs beaucoup plus importants que dans les chatbots traditionnels.

Systèmes Hybrides : Comment Fonctionnent Réellement la Plupart des Déploiements

Présenter le sujet comme « traditionnel vs GPT » donne l’impression qu’il faut choisir l’un ou l’autre. La plupart des systèmes efficaces en production utilisent les deux, et la vraie question est de savoir où placer la frontière entre eux.
Option 1 : Routeur basé sur des règles, gestion GPT
Un classificateur d’intentions dirige les requêtes structurées, comme la consultation de compte, le traitement des paiements ou le suivi de commande, vers des flux déterministes. Tout le reste est envoyé vers la couche GPT. Les flux structurés gèrent les interactions où la cohérence et l’auditabilité sont essentielles. La couche GPT gère le reste, ce qui produirait autrement des fallbacks.
Cette approche est fréquente dans les plateformes de service client qui doivent gérer à la fois des interactions transactionnelles réglementées et des demandes conversationnelles ouvertes.
Option 2 : GPT interprète, les règles exécutent
Le modèle GPT gère toute la compréhension du langage naturel et génère une réponse, mais avant qu’une action soit effectuée, comme envoyer un formulaire, traiter un paiement ou réserver un rendez-vous, le système passe la main à une étape déterministe avec une logique fixe. Le modèle comprend ce que veut l’utilisateur. Le système basé sur des règles décide si l’action doit être exécutée et comment.
Cela permet de garder le risque lié à la variabilité des réponses du modèle loin des actions critiques tout en conservant la flexibilité conversationnelle au niveau de l’entrée utilisateur.
Option 3 : GPT avec récupération documentaire et escalade
Le modèle GPT répond aux questions en s’appuyant sur une base de connaissances contrôlée. Si la réponse ne peut pas être trouvée dans le contenu récupéré, le système escalade vers un agent humain au lieu de laisser le modèle spéculer. Cela limite le risque d’hallucination en fixant une frontière claire : si ce n’est pas dans la base de connaissances, le bot le dit et transfère la demande.

Comment Choisir

Pouvez-vous cartographier tout l’espace conversationnel à l’avance ? Si oui, et si cet espace reste suffisamment stable pour être maintenu facilement, commencez par un chatbot traditionnel. Si l’espace conversationnel est large, évolue fréquemment ou grandit plus vite que vous ne pouvez le cartographier, vous avez besoin d’une composante GPT.
À quel point la cohérence est-elle importante ? Pour tout ce qui touche à la réglementation, aux transactions financières ou au langage juridique, les chatbots traditionnels ou les architectures hybrides fortement contrôlées sont plus sûrs. Les réponses GPT peuvent être contraintes, mais jamais rendues totalement prévisibles.
Quels sont vos besoins d’audit ? Les chatbots traditionnels sont plus simples à auditer. Chaque réponse est liée à une règle. Les systèmes GPT nécessitent une journalisation et une capture des réponses beaucoup plus rigoureuses pour satisfaire les auditeurs.
Que votre équipe est-elle réellement capable de construire et de maintenir ? Les chatbots traditionnels nécessitent des compétences en design conversationnel et en outils NLU. Les chatbots GPT nécessitent du prompt engineering, la conception de systèmes de récupération documentaire et une compréhension du comportement des modèles dans les cas limites. Ce sont des compétences différentes. Le bon choix dépend en partie de ce que votre équipe peut maintenir dans le temps.
**Quel type d’échec est le plus acceptable ? **Les chatbots traditionnels échouent avec un message de fallback générique. Les chatbots GPT échouent avec une réponse fausse mais crédible. Selon votre contexte, l’un de ces risques peut être plus grave que l’autre.

Avant le Passage en Production

Pour les chatbots traditionnels: définissez un seuil minimal de couverture avant le lancement. Définissez votre politique de fallback : message générique, demande de clarification ou transfert vers un humain. Construisez un jeu de tests basé sur des requêtes réelles ou réalistes et vérifiez la couverture avant chaque mise en production. Journalisez chaque intention non reconnue afin de savoir quoi améliorer ensuite.
Pour les chatbots GPT: versionnez vos prompts système afin de pouvoir revenir en arrière lorsqu’un changement casse quelque chose. Écrivez des cas de test qui explorent les limites de ce que le bot doit ou ne doit pas dire. Ajoutez une classification des réponses pour détecter celles qui sortent des garde-fous avant qu’elles n’atteignent les utilisateurs. Configurez des alertes de coûts afin qu’un pic de trafic ne provoque pas une facture surprise.
Pour les systèmes hybrides: documentez clairement la logique de routage. La frontière entre la couche basée sur des règles et la couche GPT est l’endroit où apparaissent les erreurs les plus difficiles à comprendre, et cette frontière doit être traçable lorsqu’un problème survient.

Conclusion

Le choix entre ces deux architectures dépend de trois éléments : la quantité d’interactions que vous pouvez définir avant le déploiement, le niveau de cohérence des réponses dont vous avez besoin, et ce que votre équipe est réellement capable de construire et de maintenir.
Les chatbots traditionnels échouent lorsque leur couverture s’arrête. Les chatbots GPT échouent lorsque leurs réponses sortent des limites que vous avez définies. Aucun de ces problèmes ne se résout tout seul, et les deux nécessitent un travail continu.
La plupart des systèmes solides en production utilisent les deux, avec une frontière placée là où la cohérence et l’auditabilité sont les plus importantes. Cette frontière constitue la vraie décision d’architecture, bien plus que la technologie utilisée de chaque côté.