Journal Agents IA dans Telegram : le texte généré ne suffit pas à faire un outil fiable

Je suis Mikhail Turkin, de l'équipe KUZKO. Ce journal expose mon point de vue sur les outils de conversation assistée par IA, avec notre produit comme exemple. Le texte a été adapté avec l'aide d'une IA. Il ne présente ni une mesure de rentabilité ni un classement indépendant.

Ce qui change dans le travail publicitaire

Produire plusieurs variantes d'un dialogue devient accessible avec un modèle génératif. À mon sens, cela déplace une partie du travail : il faut choisir le contexte, contrôler les faits et vérifier l'effet réel de l'exécution. Multiplier les messages ne prouve pas que la communication devient meilleure.

Dans un groupe local, une question sur un dépannage contient déjà une zone, une urgence et un besoin. Une réponse utile peut préciser la couverture d'un service et la manière de prendre rendez-vous. En revanche, une conversation entièrement créée entre agents ne démontre pas l'intérêt de personnes réelles. Les deux doivent rester séparés dans les statistiques.

Lire un outil à travers ses points de contrôle

KUZKO réunit une description d'activité, les profils des agents, la préparation de scénarios et la recherche de groupes dans une interface web et une application iPhone. Les comptes Telegram sont fournis par l'équipe du service. L'utilisateur vérifie les communautés, modifie les répliques et confirme le lancement. Les actions payantes utilisent des unités internes dont le coût apparaît avant confirmation.

Pour examiner ce type de produit, je regarderais d'abord le passage entre un texte modifiable et une version autorisée. Une correction du lien de réservation après approbation doit créer une nouvelle révision à vérifier. Le fait qu'une version antérieure ait été approuvée ne doit pas autoriser n'importe quelle modification ultérieure.

Voici un schéma de conception réutilisable, pas un contrat d'API KUZKO :

brouillon -> vérification -> révision approuvée -> file -> exécution
                                                            |
                                           terminé / arrêté / échec

Le serveur doit vérifier le propriétaire du scénario et la révision approuvée. Une copie figée côté interface aide à éviter les mutations accidentelles, mais ne remplace pas ces contrôles. Il faut aussi conserver le résultat des opérations répétées afin de ne pas exécuter deux fois la même intention.

La recherche ne donne pas une autorisation de publier

Une recommandation de groupes peut être pertinente sur le plan thématique et rester inadaptée à une campagne. Le règlement de la communauté et les conditions de participation doivent être examinés séparément. Un modèle ne peut pas les transformer en permission.

L'interface devrait distinguer une recherche en cours, une erreur et une absence de résultat. Sinon, l'utilisateur ne sait pas s'il doit attendre, recommencer ou revoir sa demande.

Une livraison incertaine doit rester incertaine

Une tâche en file d'attente n'est pas une livraison. Après un délai réseau dépassé, le fournisseur peut avoir exécuté l'opération sans que son accusé soit parvenu au client. Réessayer sans rapprochement peut créer un doublon ; annoncer une réussite serait tout aussi trompeur.

Le bouton Arrêter mérite aussi une définition précise : empêcher le travail encore en attente, en conservant la trace des effets déjà produits. Il ne peut pas garantir qu'un message déjà reçu n'a jamais existé. Ce sont des exigences à tester sur l'exécuteur, pas des garanties que l'on peut déduire d'une capture d'écran.

Un exemple pour examiner le dialogue

Imaginons un café proposant une dégustation le samedi. Une participante fictive demande si les débutants peuvent venir. L'agent se présente comme assistant virtuel du café, répond uniquement à partir des faits fournis et renvoie vers la page de réservation vérifiée lorsqu'on la lui demande.

Cet exemple est inventé. L'agent ne se fait pas passer pour un client satisfait. Pour un essai réel, je distinguerais les échanges entre agents, les questions de vraies personnes, les demandes qualifiées et les réservations. Nous ne fournissons ici aucune mesure de hausse de conversion.

Capture issue des documents produit KUZKO, interface en anglais. Les noms sont des libellés de comptes ; l'image n'est pas un bilan de campagne.

Références pour prolonger le sujet

Le site KUZKO et sa fiche App Store permettent de voir le périmètre du produit. Une courte vidéo en anglais en illustre le concept par un récit fictif. Cette vidéo est promotionnelle, sans valeur de preuve sur les résultats de clients.

La FAQ antispam de Telegram rappelle les limites concernant les messages indésirables. Pour moi, la question d'évaluation reste concrète : l'opérateur peut-il comprendre, autoriser puis vérifier ce que fait l'agent ?