Ce texte ne décrit ni un client précis ni une mise en production réalisée. Il présente un scénario composite, construit à partir de problèmes fréquents dans les entreprises qui préparent des devis après une visite ou une intervention. Les messages, les rôles et les étapes ci-dessous sont illustratifs.
Le besoin est simple à formuler : une personne sur le terrain décrit une demande dans Telegram, puis un système prépare un brouillon dans le logiciel de devis et met à jour le CRM. La difficulté se trouve dans les contrôles intermédiaires. Un agent ne doit ni inventer une référence produit, ni choisir seul une remise, ni envoyer un engagement commercial sans validation.
Le problème que ce scénario cherche à résoudre
Dans une entreprise de menuiserie, de maintenance ou d'installation, les informations nécessaires à un devis peuvent arriver sous plusieurs formes : note vocale, photo, message, document ou appel au bureau. La personne qui saisit le devis doit ensuite retrouver le client, identifier les produits, vérifier les dimensions et demander les éléments manquants.
Une automatisation peut réduire cette ressaisie si les données de départ sont assez fiables. Elle ne corrige pas un catalogue incohérent ni des règles commerciales connues d'une seule personne.
Avant de connecter un modèle d'IA, l'entreprise doit donc répondre à quelques questions :
| Point à cadrer | Décision attendue |
|---|---|
| Catalogue | Quelle source contient les références et les prix valides ? |
| Remises | Qui peut les proposer et qui doit les valider ? |
| Données obligatoires | Quelles informations bloquent la création du brouillon ? |
| CRM | Comment identifier un client existant et éviter les doublons ? |
| Envoi | Quel rôle valide le devis avant sa transmission ? |
| Incident | Que fait l'équipe si une API ou le modèle ne répond plus ? |
Sans ces réponses, l'agent déplacerait les erreurs au lieu de les réduire.
Telegram est un canal possible, pas une obligation
Telegram convient seulement si l'entreprise l'autorise déjà pour cet usage et si sa politique de sécurité accepte les données qui y transitent. Le même flux peut partir d'un formulaire mobile, de Teams, de Slack ou d'une application métier.
Le choix doit suivre les habitudes de l'équipe sans contourner les règles internes. Pour un bot Telegram, il faut au minimum protéger son jeton, limiter les utilisateurs autorisés, définir la durée de conservation des messages et éviter d'y envoyer des données inutiles. Les secrets d'API ne doivent jamais apparaître dans une conversation.
Une note vocale peut faciliter la saisie après un rendez-vous. Elle ajoute aussi une étape de transcription et un risque d'ambiguïté. Si le bruit masque une dimension ou une référence, le système doit demander une confirmation au lieu de compléter la valeur.
Architecture conditionnelle du flux
Un workflow de devis peut suivre les étapes suivantes :
- Le bot vérifie l'identité de l'utilisateur et accepte un message texte ou vocal.
- Le système transcrit la note vocale si cette fonction est activée.
- Le modèle extrait les champs attendus dans une structure définie : client, chantier, produits, dimensions, options, délai souhaité et commentaire interne.
- Des règles déterministes vérifient les champs obligatoires et les formats.
- Le CRM recherche un client existant. Une correspondance incertaine déclenche une demande de confirmation.
- Le logiciel de devis fournit les références et les prix autorisés. Le modèle ne crée pas son propre tarif.
- Le système prépare un brouillon, sans l'envoyer.
- Une personne habilitée contrôle le contenu et décide de l'envoi.
- Le workflow conserve les événements nécessaires à l'audit, selon la politique de conservation de l'entreprise.
Cette architecture peut être orchestrée avec n8n ou un outil comparable. Un agent IA intervient pour comprendre la demande et dialoguer sur les informations manquantes. Les règles de prix, les permissions et l'état du devis restent gérés par les systèmes métier.
Exemple fictif de conversation
Le message suivant sert uniquement à montrer la logique du flux :
Prépare un devis pour deux fenêtres sur mesure. Pose en rénovation. Les dimensions sont dans la fiche de visite. Le client souhaite aussi une option moustiquaire et demande si une remise est possible.
L'agent ne dispose pas encore de tous les éléments. Une réponse prudente pourrait être :
J'ai retrouvé la fiche de visite, mais une dimension n'est pas validée et aucun taux de remise n'est autorisé dans la demande. Peux-tu confirmer la dimension et transmettre la remise à la personne habilitée ?
Une fois ces points confirmés, le système peut générer un brouillon avec les références du catalogue. Il doit afficher la source de chaque donnée importante afin que le validateur distingue les informations fournies, celles lues dans les outils et celles qui restent à vérifier.
Cet exemple ne prouve aucun gain de temps. Il illustre seulement le comportement attendu lorsqu'une demande est incomplète.
Ce que le modèle peut faire, et ce qu'il ne doit pas décider
Le modèle peut classer une intention, extraire des champs, reformuler une note et poser une question ciblée. Il peut aussi proposer une correspondance entre les mots utilisés sur le terrain et les libellés du catalogue.
Les décisions qui créent un engagement doivent rester encadrées :
- l'identité du client et l'adresse de facturation ;
- les dimensions et quantités ;
- la référence produit retenue ;
- le prix issu du catalogue actif ;
- la remise et les conditions commerciales ;
- les mentions contractuelles ;
- le statut final du devis et son envoi.
Une correspondance suggérée par le modèle n'est pas une validation. En cas de doute, le flux doit s'arrêter ou revenir vers une personne.
Les erreurs à prévoir avant le développement
Le scénario paraît linéaire sur un schéma. Les cas limites déterminent pourtant sa fiabilité.
Une demande ambiguë
Un terme utilisé par l'équipe peut correspondre à plusieurs références. Le système doit présenter les options ou demander une précision. Il ne doit pas choisir silencieusement.
Un client en double
Deux fiches peuvent partager un nom proche. Une adresse email, un numéro de téléphone ou un identifiant métier peut aider, mais une correspondance incertaine doit rester en attente.
Un tarif obsolète
Le catalogue doit exposer une version ou une date d'effet. Si le workflow ne peut pas confirmer le tarif actif, il ne doit pas créer un devis présenté comme prêt à envoyer.
Une API indisponible
Le message doit être placé en attente avec un état visible. Rejouer une action sans contrôle d'idempotence pourrait créer plusieurs brouillons pour la même demande.
Une instruction hostile ou hors périmètre
Le contenu reçu ne doit pas pouvoir modifier les règles du système, révéler un secret ou donner des droits supplémentaires. Les permissions sont fixées hors du message et vérifiées à chaque action sensible.
Comment tester sans transformer les équipes en cobayes
Le déploiement peut commencer avec des dossiers anonymisés et des cas connus. L'équipe compare alors les champs extraits avec les données attendues, sans écrire dans les outils de production.
Une phase en mode brouillon permet ensuite de confronter le système à des formulations réelles. Chaque correction doit être classée : transcription, identification du client, référence produit, règle métier ou problème d'intégration. Cette distinction évite de tenter de tout résoudre dans le prompt.
Le passage en production ne devrait intervenir qu'après la définition d'un retour manuel. Si le bot ne fonctionne plus, l'équipe doit pouvoir transmettre la demande par le processus habituel et retrouver les messages en attente.
L'approbation humaine en production reste particulièrement importante pour un devis. Elle protège le client, le commercial et l'entreprise contre une action prise à partir d'une donnée mal comprise.
Mesurer le résultat sans annoncer de chiffre à l'avance
La mesure commence par un état de référence. Avant l'automatisation, l'entreprise peut relever :
- le délai entre la demande et la création du brouillon ;
- le nombre de demandes d'information complémentaires ;
- la part des brouillons corrigés avant envoi ;
- les erreurs de référence, de quantité ou de client ;
- l'usage réel du canal par les personnes concernées ;
- les incidents techniques et les reprises manuelles.
Les mêmes indicateurs sont suivis pendant le pilote. Si le workflow accélère la saisie mais augmente les corrections, il n'est pas prêt. Si les utilisateurs contournent le bot, le canal ou la séquence doit être revu.
Cette méthode vaut aussi pour une automatisation de facturation avec Pennylane et n8n ou un pipeline d'analyse d'appels commerciaux. Le résultat dépend de la qualité des données, des règles et du contrôle humain, pas du seul modèle choisi.
Quand ce scénario est pertinent
Ce type d'agent peut être étudié si le devis suit des règles explicites, si les produits sont identifiables dans une source fiable et si une personne peut valider le brouillon. Il est moins adapté quand chaque offre exige une étude technique non structurée, quand les prix ne sont pas tenus à jour ou quand aucun système ne permet de tracer les validations.
Un objectif raisonnable consiste à préparer un dossier plus complet, à signaler les incertitudes et à laisser la décision commerciale à la personne responsable.
Existe aussi : Lire en anglais