Voice AI : pourquoi la plupart des POC ne passent jamais en production.

Le problème n’est pas la performance du modèle en démonstration. Le problème est le passage au réel, avec des flux sales, des règles floues et des systèmes déjà en place. Un POC qui ignore cela ne prouve rien. Il montre seulement qu’une idée peut séduire pendant vingt minutes. Dès qu’il faut absorber des appels incomplets, des silences, des accents variés et des contraintes de sécurité, la belle courbe de démo perd sa valeur. La vraie question n’est pas “est-ce que ça marche ?”, mais “est-ce que ça tient quand tout s’enchaîne ?”.

La donnée décide avant le modèle

En Voice AI, la qualité du transcript, la latence et l’accès aux bons contextes font la différence. Un modèle brillant sur un corpus propre se dégrade vite sur des appels réels. Les accents, les chevauchements de parole, le bruit, les silences et les termes métier cassent la promesse. La donnée audio n’est pas un détail d’entrée. Elle fixe le plafond de qualité, puis le modèle ne fait que composer avec ce plafond. Si le signal est instable, la meilleure architecture produit surtout des erreurs cohérentes, donc difficiles à voir au début.

Je regarde d’abord la source audio, le découpage des conversations et la disponibilité des métadonnées. Demandez si l’architecture consomme le flux temps réel ou un fichier différé. Demandez aussi le taux de perte sur les segments courts et les interruptions. Si l’éditeur ne sait pas mesurer cela, il ne sait pas industrialiser. Posez aussi cette question exacte : “Quel est votre taux de reconnaissance sur des appels bruts, sans nettoyage manuel, sur les cinq derniers jours ?”. Exigez un critère vérifiable : même jeu d’essai, mêmes canaux, même codec, mêmes conditions réseau. Le piège classique est le nettoyage manuel caché dans le POC. Tout semble fluide parce qu’une équipe corrige les cas difficiles à la main. En production, ce filet disparaît et le taux d’erreur remonte d’un coup, souvent sur les appels courts, les noms propres et les demandes urgentes.

La gouvernance bloque plus souvent que l’IA

Le vrai sujet est de savoir qui autorise quoi, et à quel moment. En production, une recommandation vocale peut engager un remboursement, une réclamation ou une escalade. Sans règles de validation, le système devient soit trop prudent, soit dangereux. Dans les deux cas, il est rejeté. La gouvernance n’est pas un habillage juridique. C’est le mécanisme qui transforme une réponse probable en action acceptable. Dès qu’une intention touche au client, au risque ou à l’argent, il faut savoir qui tranche, qui bloque et qui assume.

Je demande toujours la chaîne de décision complète. Qui valide les intentions sensibles ? Qui arbitre les réponses ambiguës ? Qui porte le droit de veto métier ? Si la réponse tient en une phrase vague, le POC n’est pas prêt pour un environnement réglementé. Posez cette question en réunion : “À quel moment exact la machine s’arrête-t-elle et qui reprend la main ?”. Demandez un critère contractuel simple : journal d’audit horodaté, version du modèle, version du prompt, règle métier appliquée, et identité de l’opérateur ou du superviseur. Sans cela, aucune équipe de conformité ne signera un passage en production. Le piège est le mode “autonome par défaut” qui n’affiche ses limites qu’après coup. Le symptôme est connu : trop d’escalades inutiles au début, puis trop peu quand le risque augmente.

Un modèle sans gouvernance n’accélère pas l’opérationnel. Il accélère le risque.

Le bon critère est simple. Chaque sortie doit être traçable, rejouable et justifiable. Demandez le journal d’audit, la version du prompt, la version du modèle et la règle métier appliquée. Sans cela, aucune équipe de conformité ne signera un passage en production. Ajoutez une exigence de test : rejouer une décision passée et obtenir le même chemin de validation, avec le même niveau de preuve. Si ce replay échoue, la gouvernance est décorative. Autre point concret : vérifiez la conservation des logs, leur durée, et l’accès aux exports pour audit interne. Un système qui ne sait pas expliquer pourquoi il a répondu “oui” ou “non” finit toujours par être désactivé, même s’il parle bien.

L’intégration vaut plus que la démonstration

La plupart des POC vivent dans une bulle. Ils écoutent bien, répondent bien, puis s’arrêtent avant le CRM, la téléphonie et la supervision. Or la production commence quand il faut écrire dans le bon dossier, rappeler le bon historique et remonter le bon incident. Une belle interaction vocale ne vaut rien si elle ne déclenche pas l’action attendue dans les outils du quotidien. Le vrai coût se cache dans les passerelles, les identifiants, les délais et les erreurs de synchronisation.

Je veux voir l’intégration bout en bout. Demandez le format des événements sortants. Demandez comment le système s’insère dans le CTI, le CRM et le moteur d’orchestration. Demandez ce qui se passe si l’API tombe. Un POC qui ne gère pas la panne n’a pas de plan d’exploitation. Posez cette question exacte : “Quel est le comportement de secours si le CRM est indisponible pendant dix minutes ?”. Exigez un critère technique : authentification réelle, droits réels, logs réels, et écriture effective dans l’environnement cible. Le piège est l’intégration “sur table” avec des connecteurs théoriques. Cela rassure en démo, puis casse sur les droits, les délais réseau et les versions d’API. Le symptôme est simple : tout passe en test, puis rien ne se synchronise dès qu’on change de tenant, de certificat ou de schéma.

La supervision doit être pensée dès le départ

Un système vocal sans supervision devient vite opaque. En production, il faut suivre les taux d’erreur, les abandons, les escalades et les dérives de réponse. Il faut aussi détecter les régressions après mise à jour. Sans observabilité, le POC devient une boîte noire impossible à opérer. La supervision n’est pas un confort de pilotage. C’est le seul moyen de savoir si la qualité baisse, si le modèle dérive ou si un canal se dégrade avant que les équipes terrain ne le subissent.

Je vérifie trois choses. Les métriques sont-elles accessibles en temps réel ? Les alertes sont-elles paramétrables par métier, pas seulement par technique ? Les incidents peuvent-ils être rejoués sur un cas précis ? Si la réponse est non, l’équipe opérera à l’aveugle. Demandez aussi : “Qui reçoit l’alerte quand le taux d’escalade double sur une plage horaire ?”. Exigez un critère vérifiable : seuils configurables, horodatage des événements, export des traces, et corrélation entre appel, décision et action. Le piège courant est le tableau de bord joli mais muet. Il affiche des courbes, pas des causes. Le symptôme apparaît quand personne ne sait si la baisse vient du modèle, du routage, du CRM ou d’un simple changement de script.

Demandez aussi qui lit les tableaux de bord. Un dashboard sans propriétaire ne sert à rien. Il doit y avoir un responsable métier, un responsable IT et un responsable éditeur. Chacun doit savoir quelle action déclencher quand la qualité baisse. Sans cette répartition, les alertes circulent, mais rien ne change. Une supervision utile déclenche une décision, pas une réunion de plus.

Un POC utile ressemble déjà à une production

Je me méfie des POC qui promettent de “voir plus tard” la sécurité, la charge, les droits et la maintenance. Ce sont justement les sujets qui font tomber les projets. Un bon POC teste la valeur et les contraintes dans le même mouvement. Sinon, il mesure une intention, pas une capacité. La différence est nette : une intention impressionne en comité, une capacité résiste au quotidien. Dès qu’un projet vocal doit passer de la preuve à l’usage, les angles morts reviennent tous en même temps.

Demandez un périmètre minimal mais complet. Un flux réel. Un système cible réel. Des règles de gouvernance écrites. Une supervision activée. Puis imposez un critère simple : ce qui n’est pas prouvé dans les conditions de production ne compte pas. Posez cette question exacte : “Qu’est-ce qui est déjà prêt pour l’exploitation, et qu’est-ce qui reste explicitement hors périmètre ?”. Exigez un document contractuel avec latence admissible, qualité d’entrée, responsabilités de validation, modalités d’intégration et plan de reprise. Le piège est le POC qui réussit parce qu’il est incomplet. Le symptôme est toujours le même : la démo passe, puis l’industrialisation réclame trois mois de rattrapage sur la sécurité, les droits et les interfaces.

Le bon réflexe est de faire signer dès le départ les hypothèses d’industrialisation. Latence admissible. Qualité d’entrée. Responsabilités de validation. Modalités d’intégration. Si l’éditeur refuse de cadrer cela avant la démo, le POC restera une démonstration élégante. Et une démonstration élégante ne suffit pas quand il faut absorber des volumes, des exceptions et des contrôles sans perdre la main.