Un agent IA peut transformer un courriel ou un formulaire libre en fiche de demande exploitable. Pour que cette automatisation aide vraiment l’équipe, la fiche doit distinguer ce que le client a écrit, ce qui manque et ce que l’agent propose de faire. Les informations absentes restent à confirmer : l’agent ne doit ni les deviner ni décider seul si le prospect est qualifié.
Ce cas d’usage convient aux petites entreprises qui reçoivent des messages par plusieurs canaux et ressaisissent les mêmes éléments dans un suivi commercial. Il se prête à un pilote limité : préparer une fiche, faire vérifier son contenu, puis choisir si une connexion au CRM est utile. La documentation OpenAI sur les sorties structurées explique comment contraindre la forme d’une réponse selon un schéma. Cela aide à éviter des champs absents ou des valeurs hors format, mais ne prouve pas que les informations extraites sont exactes. La CNIL rappelle que les réponses générées peuvent paraître plausibles tout en étant inexactes : la vérification doit donc porter sur le fond.
Définir la fiche à partir du travail réel
Commencez par regarder les messages que l’équipe traite déjà. Quelles informations faut-il retrouver à chaque fois pour répondre, préparer un devis ou transmettre la demande à la bonne personne ? Conservez uniquement les champs utiles à cette prochaine étape.
Pour une demande de réparation de vélo, une première fiche pourrait contenir :
- le service demandé, avec les mots employés par le client ;
- le modèle ou le type de vélo, si le message le précise ;
- le problème décrit, sans diagnostic ajouté par l’agent ;
- la date ou le délai demandé, recopié tel qu’il apparaît ;
- le moyen de recontact souhaité, s’il est indiqué ;
- les questions auxquelles l’équipe doit encore répondre.
Si le message dit « mon vélo fait un bruit au pédalage, pouvez-vous le voir cette semaine ? », la fiche peut reprendre le symptôme et la demande de délai. Elle ne devrait pas conclure que le pédalier est défectueux, ni promettre une disponibilité. Ces décisions nécessitent une vérification métier et, parfois, une question au client.
Un champ doit avoir un usage clair. Si personne ne consulte une donnée, ne sait pas la corriger ou ne peut pas expliquer pourquoi elle est collectée, retirez-la du premier essai. Une fiche courte est généralement plus facile à contrôler qu’un résumé qui mélange toutes les informations.
Séparer les faits, les absences et les propositions
Le point délicat n’est pas seulement d’extraire des mots, mais de signaler leur statut. Pour chaque information, prévoyez une distinction simple : « présente dans le message », « à confirmer » ou « absente ». Si c’est utile, ajoutez une citation courte du message qui justifie le champ.
Cette séparation évite plusieurs erreurs fréquentes :
- compléter un budget ou une échéance qui n’a pas été mentionné ;
- transformer une hypothèse en besoin confirmé ;
- confondre le service demandé avec une recommandation de l’entreprise ;
- classer automatiquement une demande comme urgente sans règle métier explicite ;
- présenter une reformulation comme une citation du client.
Gardez aussi les données d’origine accessibles à la personne qui contrôle la fiche. Une phrase comme « besoin urgent » est difficile à valider si l’équipe ne peut pas voir les mots qui ont conduit à cette interprétation. Pour un premier pilote, une colonne « extrait du message » ou un lien vers la demande originale peut suffire.
Utiliser un format structuré sans confondre forme et exactitude
Une sortie structurée peut aider à recevoir des champs prévisibles, par exemple un objet contenant service_demande, description_client, delai_demande, informations_manquantes et prochaine_etape_proposee. Les noms doivent être compréhensibles pour les personnes qui relisent la fiche, pas seulement pour le système qui la traite.
Ajoutez des règles métier autour de la réponse :
- une valeur absente reste vide ou porte explicitement la mention « non précisé » ;
- un élément incertain est envoyé en revue plutôt que complété ;
- une recommandation est séparée des faits du message ;
- la fiche conserve un lien vers sa demande d’origine ;
- une valeur inattendue ne déclenche pas d’écriture automatique.
Le schéma contrôle le format, pas la justesse de chaque champ. Dans sa documentation, OpenAI décrit les sorties structurées comme conformes à un schéma donné et signale aussi des cas à traiter, notamment les refus et les réponses incomplètes. La CNIL décrit les risques d’informations inexactes qui semblent pourtant crédibles. Il faut donc tester les cas métier et vérifier les données, même si la réponse est un JSON valide.
Tester les messages incomplets et ambigus
Avant d’utiliser de vrais messages, préparez un petit échantillon représentatif, avec les protections nécessaires pour les données personnelles. Incluez des demandes ordinaires, des champs manquants, des formulations vagues, deux besoins dans le même message, des informations contradictoires et des demandes qui ne relèvent pas de votre activité.
Pour chaque cas, notez ce que l’agent devrait extraire, ce qu’il devrait laisser vide et quand il devrait demander une relecture. Comparez ensuite ces attentes à la fiche produite. Le but n’est pas d’obtenir une réponse élégante à chaque fois, mais de vérifier que les informations incertaines sont visibles et que les erreurs n’entraînent pas une action non souhaitée.
La fiche de test peut être légère :
| Cas à vérifier | Résultat attendu |
|---|---|
| Une date est explicitement demandée | La date est recopiée sans confirmation de disponibilité. |
| Aucun budget n’est mentionné | Le champ reste vide ou « non précisé ». |
| Le message contient deux demandes | Les deux besoins sont signalés pour contrôle. |
| Le client décrit un symptôme | Le symptôme est repris sans diagnostic inventé. |
| Le message est hors périmètre | L’agent propose une transmission, sans réponse métier improvisée. |
Le NIST recommande d’évaluer les capacités des systèmes génératifs par des méthodes empiriques et de documenter leurs limites. Pour une TPE, cela peut se traduire par des exemples de test conservés, une grille de contrôle et une revue des erreurs observées. Une démonstration sur trois messages bien formés ne suffit pas à établir que le traitement convient à des demandes réelles.
Connecter l’agent au CRM par étapes
Commencez sans écriture automatique : l’agent prépare la fiche, une personne la compare au message original, puis la saisit dans le suivi habituel. Cette étape révèle les champs inutiles et les corrections fréquentes, sans créer de doublons ou de dossiers erronés.
Si le format est stable, l’étape suivante peut créer un brouillon ou une tâche qui attend une validation. Définissez alors qui peut corriger, rejeter ou compléter la fiche. Précisez aussi ce qui arrive en cas d’erreur de connexion, de demande déjà traitée ou de champ obligatoire manquant. La fiche doit pouvoir être reprise manuellement si l’intégration est indisponible.
Avant d’autoriser l’agent à créer ou modifier des dossiers sans relecture, mesurez les erreurs et vérifiez que les règles de doublon et de correction sont fiables. L’objectif n’est pas d’automatiser toute la qualification : il peut suffire d’éviter la ressaisie des éléments clairement présents. Le sujet rejoint celui de la circulation des demandes entre un site et un CRM. Si les outils existants ne représentent pas correctement votre processus, un logiciel métier sur mesure peut être étudié avec le reste du système.
Limiter les données et les accès nécessaires
Un message commercial peut contenir des coordonnées, des détails sur une situation personnelle ou des informations confidentielles. Déterminez avant le pilote quels éléments doivent être transmis au système d’IA, qui pourra consulter les fiches et combien de temps les données sont conservées. Écartez du test les informations qui ne servent pas à la mission.
Les recommandations de la CNIL sur l’usage de l’IA générative invitent les organisations à examiner les données fournies, les conditions du fournisseur, la sécurité et la vérification des sorties. Les obligations applicables dépendent du traitement et de la solution retenue ; un article général ne permet pas de conclure à votre place. Faites vérifier votre configuration par la personne compétente dans l’entreprise lorsqu’elle touche à des données personnelles ou sensibles.
Pour un agent connecté à une messagerie ou à un outil métier, donnez uniquement les accès nécessaires à sa mission. Préparez aussi une procédure pour désactiver la connexion et traiter les demandes en attente à la main. La page agents IA et automatisation présente le service associé ; le périmètre d’un projet doit ensuite être adapté aux outils et aux règles de votre activité.
Mesurer le travail économisé et les corrections
Comptez séparément les fiches créées, celles acceptées sans correction, celles reprises et celles qu’il a fallu compléter. Notez également le temps consacré au contrôle. Une fiche générée rapidement peut déplacer le travail vers la correction au lieu de le supprimer.
Comparez une période ou un échantillon où l’équipe traite les messages manuellement avec le pilote, en conservant les mêmes types de demandes lorsque c’est possible. Vous pouvez suivre quelques mesures simples :
- le temps moyen consacré à préparer une fiche ;
- le nombre de champs corrigés ou laissés incomplets ;
- les doublons créés ou repérés ;
- la part des cas correctement envoyés à une personne ;
- les demandes qui ont nécessité une reprise manuelle.
Choisissez à l’avance ce qui justifierait une suite : moins de ressaisie sans hausse des erreurs, meilleure visibilité sur les informations manquantes ou transmission plus régulière au bon interlocuteur. Si les corrections restent nombreuses, réduisez le périmètre ou améliorez le format avant d’ajouter des connexions.
Un agent IA de qualification ne remplace ni la compréhension du besoin ni la décision commerciale. Son rôle peut être plus modeste et plus utile : préparer une fiche fidèle, montrer ses zones d’incertitude et faciliter une vérification rapide. Commencez par les messages et les champs les plus simples, gardez la validation humaine visible, puis décidez à partir des corrections observées si l’automatisation mérite d’être étendue.