Créer un agent IA sans code : base de connaissances, multi-tours, actions

Pourquoi la plupart des « agents IA » se limitent à répondre à des questions

Chaque éditeur prétend aujourd’hui vendre un agent IA. En regardant au-delà du marketing, la plupart d’entre eux font une seule chose : récupérer une réponse dans un document et la coller dans une fenêtre de chat. C’est une base de connaissances avec une apparence conversationnelle, pas un agent. Un véritable agent doit se souvenir de ce qui a été dit trois messages plus tôt, décider quand il dispose de suffisamment d’informations pour agir, réellement faire quelque chose dans un système de référence, et savoir quand s’arrêter pour faire intervenir un humain.

Pour les responsables CX, support et RevOps qui évaluent cette catégorie, la distinction a une importance commerciale. Un bot de recherche dans une base de connaissances détourne les tickets qui étaient déjà faciles à traiter. Un agent capable de tenir une conversation multi-tours et d’exécuter une action — émettre un remboursement, réserver un RMA, escalader une réclamation — détourne les tickets qui coûtent réellement cher à traiter manuellement. Cet article détaille ce qu’il faut pour en construire un sans ressources d’ingénierie, en utilisant les briques que la plupart des équipes possèdent déjà ou peuvent mettre en place rapidement.

Les trois couches dont un véritable agent a besoin

Couche 1 : l’ancrage sur une base de connaissances

Un agent qui répond à partir d’un ensemble statique de documents ne vaut que ce que vaut la structure de cet ensemble. L’exigence pratique est une base de connaissances interrogeable, versionnée, et pouvant être restreinte ou publique selon la page — car un article sur la politique de retour doit être visible pour les visiteurs anonymes, mais le statut d’une commande spécifique ne le devrait pas.

C’est exactement ce que vous offre d’emblée un modèle de Portail de support : une section base de connaissances accessible publiquement, coexistant avec des pages nécessitant une connexion comme le suivi des tickets, sur le même domaine. La structure des pages prend en charge les pages dynamiques — un slug préfixé par deux-points comme articles/:articleId affiche la bonne entrée de la base de connaissances à partir d’une Liste de données, ce qui signifie que votre contenu de base de connaissances réside dans une entité de données structurée plutôt que dans des PDF dispersés. C’est cette structure dont un agent a réellement besoin pour effectuer des recherches fiables.

Couche 2 : un contexte multi-tours qui ne se réinitialise pas

La plupart des générateurs de bots traitent chaque message comme une nouvelle requête. Cela fonctionne pour « quels sont vos horaires d’ouverture » mais s’effondre dès qu’un client dit « en fait c’est l’article 2, pas l’article 1 ». Un agent viable a besoin d’un fil persistant qui accumule le contexte au fil des échanges et qui reste lié à l’enregistrement dont il traite.

La fonctionnalité Threads de SurveyAnalytica est conçue exactement pour cela. Un thread de type Conversation est conçu pour être orienté client — la même construction utilisée pour les dialogues RMA ou les suivis de répondants — et il reste attaché aux entités qu’il concerne : la réponse, le contact, la commande, le workflow qui la traite. Un seul thread peut se lier simultanément à une réponse, à la campagne qui l’a générée, au contact associé, et au workflow traitant la demande, avec une navigation bidirectionnelle entre eux. Cela signifie que lorsqu’un client revient à une conversation deux jours plus tard, l’agent ne repart pas de zéro ; il reprend un fil (littéralement) qui sait déjà qui il est et de quoi il a été question.

Couche 3 : l’exécution d’actions, pas seulement des suggestions

C’est là que la plupart des produits « agent IA » s’arrêtent discrètement. Ils rédigent une réponse, suggèrent une prochaine étape, ou signalent un ticket — mais l’humain doit encore aller l’exécuter dans un autre système. Un agent sans code digne d’un déploiement commercial doit pouvoir déclencher des actions réelles : créer un enregistrement, expédier un colis, publier sur Slack, écrire dans un système comptable.

Les événements du cycle de vie d’un thread — thread créé, message publié, thread résolu, archivé, ou fermé — sont des déclencheurs natifs de workflow. Un thread de support résolu peut déclencher automatiquement l’expédition d’une étiquette de livraison. Les actions générées à l’intérieur d’un thread héritent des entités liées à ce thread et apparaissent dans le Centre d’actions avec des dates d’échéance et un suivi des personnes assignées, de sorte que rien de ce que génère l’agent ne disparaît dans un journal de chat — cela devient une tâche traçable avec un propriétaire. Pour les équipes finance et opérations qui utilisent déjà Tally Prime, le connecteur prend en charge des déclencheurs en temps réel ou par lots selon le type de bon, de sorte qu’un retour initié par l’agent peut être directement transformé en avoir sans que personne n’ait à ressaisir quoi que ce soit.

La quatrième couche : le passage de relais à un humain

Un agent qui n’escalade jamais n’est pas confiant — il est imprudent. L’objectif de conception honnête n’est pas l’automatisation totale ; c’est d’automatiser les parties qui ne nécessitent pas de jugement et d’acheminer le reste vers une personne disposant du contexte complet, et non d’un ticket froid. Un thread orienté client resté sans réponse pendant 24 heures peut déclencher automatiquement une notification Slack, et des participants externes (un client, un installateur tiers) peuvent être invités dans un seul thread sans exposition aux données d’un autre espace de travail — l’accès est limité à ce thread et expire à une date obligatoire que vous définissez. C’est le mécanisme qui permet à un humain d’intervenir dans une conversation d’agent en cours sans avoir à tout réexpliquer, et sans ouvrir un accès système plus large pour y parvenir.

Exemple concret : un agent de retours pour une marque e-commerce

Voici comment les quatre couches s’assemblent pour un détaillant de taille intermédiaire gérant les RMA via un portail en libre-service :

• Point d’entrée : Un client visite le Portail de support à l’image de la marque sur returns.yourbrand.com et ouvre la page publique de la base de connaissances consacrée à la politique de retour. Si sa question y trouve réponse, l’interaction s’arrête là — aucun thread requis, aucune charge pour l’agent.
• Escalade vers une conversation : S’il doit réellement lancer un retour, l’agent ouvre un thread de Conversation et demande le numéro de commande, l’article et le motif — un échange multi-tours, pas un simple formulaire à remplir. Comme le client est connecté, le thread est déjà lié à sa fiche contact.
• Capture structurée des détails : Pour une commande à plusieurs articles, l’agent passe le relais à une section répétable du formulaire RMA — une instance par article retourné, chacune étiquetée séquentiellement (« Retours · Article 1 », « Retours · Article 2 ») — de sorte qu’un client retournant trois produits dans une seule commande n’a pas à mener la conversation trois fois séparément.
• Exécution de l’action : Lorsque le thread atteint le statut « résolu » (retour approuvé, éligibilité confirmée), un déclencheur de workflow se déclenche automatiquement : une étiquette d’expédition est générée et envoyée par e-mail, et l’enregistrement RMA met à jour le système de commande via un webhook.
• Passage de relais à un humain : Si le thread reste sans réponse pendant 24 heures — disons que l’agent n’a pas pu confirmer l’éligibilité au retour face à un cas limite de la politique — une notification Slack fait intervenir un représentant du support, qui rejoint le même thread avec tout le contexte déjà visible au lieu de partir d’un ticket vierge.

Chaque champ de texte libre saisi par le client en cours de route — « le chargeur a cessé de fonctionner après deux semaines », « mauvaise couleur livrée » — passe par une extraction de sentiment et d’entités indépendamment pour chaque instance répétable, de sorte qu’un lot de trois réclamations dans une seule soumission produit trois points de signal distincts au lieu d’un flou moyenné. Ce sont des données que vos équipes qualité et produit peuvent exploiter plus tard, générées comme sous-produit d’une interaction de support, et non d’une enquête distincte.

Ce que le « sans code » exige réellement de vous

Sans code ne signifie pas sans configuration. Avant qu’un tel agent ne fonctionne de manière fiable, certains éléments doivent être en place, et il vaut mieux être transparent à ce sujet plutôt que de prétendre le contraire :

• Un contenu de base de connaissances structuré. L’agent récupère ce que vous lui fournissez. Une base de connaissances constituée de PDF épars et de pages wiki dispersées produira des réponses incohérentes, quelle que soit la qualité du modèle sous-jacent. Migrer le contenu de la base de connaissances vers une entité de Liste de données structurée est le vrai travail à faire ici, et il vaut la peine d’être fait une fois, correctement.
• Des seuils d’escalade clairs. Décidez à l’avance ce que signifie « non résolu » — 24 heures, trois échanges sans réponse, un score de sentiment client précis — avant d’activer l’automatisation, et non après qu’un client se plaigne d’une boucle de bot.
• La continuité d’identité. Si votre agent a besoin de l’historique des commandes ou du contexte d’achat pour bien répondre, cela nécessite de lier les sessions de navigation anonymes aux contacts connus lors de la connexion — le type de résolution d’identité que gère l’appel identify du suivi de clickstream, en associant le signal comportemental au même identifiant de contact que celui déjà utilisé par l’agent dans son thread de conversation.
• La gouvernance de l’accès externe. Si des clients ou des fournisseurs participent à des threads, les dates d’expiration obligatoires sur les invitations externes ne sont pas des options facultatives — c’est ce qui empêche la portée d’un agent de support de se transformer discrètement en exposition de données.

Comment SurveyAnalytica peut vous aider

SurveyAnalytica ne vend pas un simple widget « agent IA » greffé sur une fenêtre de chat — la plateforme vous fournit les composants dont un véritable agent a besoin, déjà interconnectés : une base de connaissances structurée et à l’image de votre marque via le modèle de Portail de support, des threads de Conversation multi-tours persistants qui restent liés à la fiche client et à toutes les entités associées, ainsi qu’un moteur de workflow qui transforme les événements de thread en actions réelles — étiquettes d’expédition, notifications Slack, mises à jour ERP — au lieu de les laisser à l’état de suggestions dans un journal de chat.

Comme ces composants partagent le même modèle de données que vos enquêtes, portails et connecteurs, une conversation d’agent n’est pas un silo isolé. Le sentiment extrait de la réclamation de retour d’un client alimente la même couche d’analyse que vos enquêtes NPS ; l’action qu’il déclenche apparaît dans le même Centre d’actions que vos workflows d’approbation. C’est la différence entre déployer un chatbot et composer une capacité opérationnelle que vous pouvez réellement gouverner, auditer et améliorer au fil du temps.

Si vous comparez cette offre à une plateforme comme Qualtrics ou à un fournisseur de chatbot autonome, la question pratique n’est pas « est-ce qu’il y a de l’IA » — c’est de savoir si la base de connaissances, la couche de conversation et la couche d’action forment un seul et même système, ou trois systèmes distincts que vous devez assembler vous-même.

Conclusion

Un agent IA sans code digne d’un déploiement commercial ne se définit pas par la fluidité apparente de ses réponses. Il se définit par sa capacité à tenir une conversation sur plusieurs tours sans perdre le contexte, à ancrer ses réponses dans un contenu que vous contrôlez réellement, à exécuter une action réelle dans un système réel lorsqu’il dispose de suffisamment d’informations, et à s’effacer proprement lorsque ce n’est pas le cas. Construisez ces quatre éléments dans le bon ordre — base de connaissances, multi-tours, exécution d’actions, passage de relais à un humain — et vous obtenez un agent qui réduit réellement la charge de travail. Sautez-en un seul et vous avez simplement construit une page de FAQ avec un meilleur marketing.