« Solutions de Paiement Avancées » a lancé un assistant vocal avec IA pour les appels en pilote sans équipe ML

L'entreprise « Solutions de Paiement Avancées » a raconté comment elle a lancé un assistant IA par voix pour les appels en pilote sans sa propre équipe ML. En six mois, 12 développeurs backend ont construit un système qui en temps réel suggère au gestionnaire comment répondre au client et s'inscrit dans un délai d'environ deux secondes.

Comment le MVP a été construit

À l'intérieur de l'entreprise le projet a reçu le nom « Souffleur ». Sa tâche est d'écouter une conversation déjà transcrite, comprendre quel produit est discuté, remarquer les objections du client et immédiatement afficher au gestionnaire une suggestion textuelle. La pile finale a été assemblée en Python, FastAPI et PostgreSQL, tandis que les classificateurs BERT et Qwen 8B local géraient la classification et la génération.

Pour l'entreprise c'est un moyen de réduire la charge sur les mentors et d'amener plus rapidement les nouveaux employés aux KPI, surtout quand l'écosystème compte plus de 35 produits et que le gestionnaire doit retenir trop de scénarios. La contrainte clé était stricte : le système n'a que 1,5–2 secondes pour répondre, sinon la suggestion perd son sens en plein milieu d'un dialogue en direct.

L'équipe a atteint un prototype fonctionnel rapidement. Lors des trois premières semaines les développeurs ont pris des transcriptions textuelles des appels, entraîné deux classificateurs BERT sur environ 1 500 dialogues, assemblé des bases de connaissances simples avec des scripts et connecté le tout via des prompts avec un modèle GPT cloud. L'interface a été faite en une journée avec Django. Cette preuve de concept fonctionnait lentement, avec un délai de 10–15 secondes, mais c'était suffisant pour défendre l'idée auprès de l'entreprise et obtenir le feu vert pour le MVP. Puis a commencé le vrai travail d'ingénierie pour réduire les délais, la stabilisation et les intégrations.

Pourquoi tout a été simplifié

Au départ l'équipe, comme c'est souvent le cas dans les projets IA, a conçu un système trop ambitieux : son propre pipeline audio, plusieurs classificateurs complexes, fine-tuning d'un grand modèle de langage, une base de données vectorielle et même une boucle d'auto-apprentissage. Mais assez vite il est devenu clair qu'un tel chemin étirerait le lancement sur 12–18 mois et augmenterait drastiquement la probabilité d'échec. Au lieu de chercher à construire l'architecture « parfaite » les développeurs ont commencé systématiquement à éliminer tout ce qui pouvait être omis dans la première version.

«

Nous n'avons pas combattu les problèmes, nous avons reprojeté le système pour que ces problèmes ne s'y posent pas. »

• Ont abandonné le fine-tuning en faveur de RAG pour éviter de passer des mois en annotation et réduire le risque d'hallucinations.
• N'ont pas écrit leur propre transcription et ont pris des segments textuels prêts de Voximplant.
• Ont simplifié le classificateur d'objections : au lieu de 15+ classes ils ont conservé un schéma binaire « il y a objection / pas d'objection ».
• N'ont pas tiré une lourde base de données vectorielle pour quelques mégabytes de données et ont chargé des fichiers JSON structurés directement en mémoire.
• Sont passés des API cloud à Qwen 8B local sur un serveur GPU pour tenir le délai et ne pas envoyer les données sensibles hors du périmètre.

Cet ensemble de compromis s'est avéré être clé. Les modèles cloud donnaient une réponse en 7–20 secondes, et Qwen 32B bien que répondant mieux ne passait quand même pas le test de temps. Une Qwen 8B plus compacte s'est avérée suffisamment bonne pour les suggestions au gestionnaire et a stabilisé la latence autour de deux secondes. En parallèle le déploiement local a fermé les questions de sécurité : les transcriptions d'appels n'ont pas besoin d'être envoyées à des services externes, ce qui signifie qu'ils n'ont pas eu à construire une couche séparée de masquage des données personnelles et à payer pour cela avec des délais supplémentaires.

Ce que le pilote a montré

Le problème le plus sous-estimé s'est avéré être non les modèles mais les données. L'équipe a pris 200 appels, les a divisés entre 12 participants et a rapidement heurté le mur de l'annotation manuelle : pour classifier correctement les objections il ne suffit pas de surligner une phrase, il faut comprendre le contexte de la conversation et la logique commerciale. En conséquence les développeurs ont reconstruit la définition même du problème. Au lieu de chercher à « enseigner à l'IA à penser comme un expert » ils se sont concentrés sur un objectif plus étroit : remarquer à temps quand le gestionnaire a besoin d'aide, puis tirer le script nécessaire et générer une suggestion.

À la fin du pilote le système a atteint un délai moyen d'environ deux secondes, ne montant à trois que dans 2–3% des cas. La classification des services a donné une précision supérieure à 70%, et la reconnaissance vocale — de 92% selon la qualité de la connexion. L'équipe écrit que le pilote a déjà donné un effet qualitatif : les premiers signaux sont apparus sur la commodité, la réduction de la charge sur les mentors et l'utilité générale pour les opérateurs. Mais il n'y a pas encore de conclusions statistiquement significatives sur la conversion et les KPI — pour cela le produit a besoin d'une mise à l'échelle et d'une intégration transparente directement dans le CRM.

Ce que cela signifie

Ce cas démontre bien qu'un produit IA interne ne nécessite pas toujours une équipe ML prête dès le départ. Si une entreprise dispose d'ingénieurs backend solides, d'une douleur métier claire et d'un accès aux processus, un MVP peut être assemblé plus rapidement par une simplification stricte de l'architecture et un refus des composants « intelligents » inutiles. La principale leçon ici ne porte pas sur le choix d'un modèle spécifique mais sur la discipline : d'abord résoudre le problème métier, puis vérifier les contraintes de vitesse et de sécurité, et seulement ensuite compliquer la pile.