« Le variateur de la salle 3 ne répond plus, il faudrait quelqu’un aujourd’hui. » Cette phrase, prononcée par un technicien de maintenance du service client HelpDima au téléphone avec un assistant vocal interne, aboutit douze secondes plus tard à un ticket HubSpot complet : titre, description, catégorie d’équipement et niveau de priorité, sans qu’aucun champ n’ait été rempli à la main.
Le dispositif ne repose pas sur une prouesse de reconnaissance vocale, un sujet traité par ailleurs et non détaillé ici, mais sur ce qui se passe une fois la phrase transcrite en texte : un modèle de langage l’analyse, en extrait les informations structurantes, puis appelle un outil MCP dédié qui se charge de la création effective du ticket dans HubSpot.
Le découpage des responsabilités
Le pipeline complet distingue nettement trois étapes indépendantes : la transcription de la voix en texte, l’extraction structurée des informations pertinentes par le modèle de langage, et la création du ticket via l’outil MCP. Cette séparation permet de faire évoluer chaque brique séparément, par exemple en changeant de moteur de transcription sans toucher à la logique d’extraction ni à l’outil MCP lui-même.
L’outil MCP create_support_ticket attend un objet structuré en entrée, pas un texte libre : c’est au modèle de langage, en amont de l’appel, de transformer la phrase orale en champs distincts, avant que l’outil ne se contente de les transmettre à l’API HubSpot sans interprétation supplémentaire de sa part.
La déduction de la priorité, volontairement limitée

Le champ priorité ne résulte pas d’une libre appréciation du modèle sur la gravité de la situation décrite, jugée trop risquée à laisser à son interprétation seule : il repose sur une liste fermée de mots-clés associés à chaque niveau (« aujourd’hui », « urgent », « dès que possible » pour une priorité haute ; aucune mention temporelle pour une priorité standard). Cette contrainte réduit la richesse d’interprétation du modèle, mais elle rend le comportement du système prévisible et auditable après coup.
{
"name": "create_support_ticket",
"parameters": {
"type": "object",
"properties": {
"title": { "type": "string" },
"description": { "type": "string" },
"equipment_category": { "type": "string" },
"priority": { "type": "string", "enum": ["standard", "haute"] }
},
"required": ["title", "description", "priority"]
}
}
La confirmation orale avant création définitive
Une fois les champs extraits, l’assistant vocal relit à voix haute un résumé du ticket qu’il s’apprête à créer et attend une confirmation explicite du technicien avant d’appeler réellement l’outil MCP. Cette étape a permis de corriger, lors des premières semaines d’usage, plusieurs erreurs de catégorie d’équipement mal identifiée à partir d’une formulation ambiguë.
- « Confirmez-vous la création d’un ticket priorité haute pour le variateur de la salle 3 ? »
- Une réponse affirmative déclenche l’appel réel à l’outil MCP et la création du ticket.
- Une réponse négative ou une correction relance l’extraction avec la précision apportée par le technicien.
Un champ déduit automatiquement à partir d’un vocabulaire limité et documenté vaut mieux qu’un champ « intelligemment » interprété par un modèle : la prévisibilité compte plus que la finesse d’analyse sur un système qui déclenche une action réelle.
Ce que ce dispositif ne fait pas
La reconnaissance vocale elle-même, sa robustesse face aux accents ou au bruit ambiant d’un atelier, reste hors du périmètre de cet article : le pipeline décrit ici commence une fois la transcription textuelle disponible, quelle que soit la qualité de cette transcription en amont. L’outil ne modifie pas non plus de ticket existant, seule la création initiale étant couverte à ce stade.
En résumé
Douze secondes en moyenne séparent la fin d’une phrase orale de la création d’un ticket structuré, un gain de temps réel pour des techniciens souvent les mains occupées au moment du signalement. La rigueur du dispositif tient moins à la sophistication du modèle qu’à la discipline des contraintes imposées à l’outil MCP : un vocabulaire fermé pour la priorité, une confirmation systématique avant toute création.