J'ai vu une IA de service au volant couper la parole à une personne qui bégaie. Alors j'ai construit autre chose.

Il y a une vidéo qui circule sur Reddit. Une femme à un service au volant d'un Wendy's essaie de commander un Baconator. Elle bégaie — un blocage sur le « b » — et l'IA la coupe en plein mot, en lui suggérant joyeusement un Frosty. Elle réessaie. Le système interprète sa répétition comme une nouvelle commande. Trois tentatives plus tard, elle crie « AGENT » à un haut-parleur qui n'en a que faire.

J'ai dû regarder cette vidéo une trentaine de fois. Pas parce qu'elle est drôle — elle ne l'est pas — mais parce que chaque échec dans cette interaction correspond précisément à une décision d'architecture prise par quelqu'un dans une salle de réunion, probablement en regardant une diapositive qui affichait « taux de réussite de 86 % ».

Ces 14 % restants ? Ce sont de vraies personnes. Et je dirais que l'architecture n'a jamais été conçue pour elles dès le départ.

C'est l'histoire de la raison pour laquelle mon équipe chez Veriprajna a passé la majeure partie de deux ans à rejeter la voie la plus rapide vers le marché dans le domaine de l'IA vocale — et de ce que nous avons construit à la place.

Que signifie réellement « IA vocale de niveau entreprise » ?

La plupart des entreprises de notre secteur font quelque chose de remarquablement simple : elles connectent un microphone à une API. OpenAI, Google, Anthropic — choisissez votre grand modèle de langage préféré, envoyez-y l'audio, récupérez du texte, générez une réponse. Livrez le produit.

J'appelle cela l'approche wrapper d'API, et elle fonctionne à merveille dans une démonstration. Pièce silencieuse, locuteur clair, requête simple. La démo fonctionne toujours.

La démo fonctionne toujours. Le service au volant à 23 h 47 avec un camion diesel qui tourne au ralenti derrière vous et un bambin qui hurle sur la banquette arrière — c'est là que l'architecture compte vraiment.

Le système FreshAI de Wendy's — construit sur Vertex AI de Google Cloud — est probablement l'exemple le plus médiatisé de cette approche à grande échelle. Et les expériences client rapportées vous disent tout ce que vous devez savoir sur ses limites : des clients ayant besoin de trois tentatives ou plus pour de simples commandes, le système coupant la parole aux gens en plein milieu d'une phrase pour suggérer des articles qu'ils n'ont pas demandés, et une expérience qualifiée d'« inutilisable » pour quiconque présente une disfluence de la parole.

Pourtant, Wendy's s'étend à 500-600 établissements. La raison relève d'un simple calcul — le système augmente le montant moyen du panier grâce à la vente incitative, et les chiffres d'efficacité de la main-d'œuvre font bonne figure lors d'une conférence trimestrielle sur les résultats. Si vous optimisez pour la moyenne, l'architecture est un succès. Si vous êtes la personne pour qui elle ne fonctionne pas, l'architecture est défaillante.

J'ai exploré cette tension en profondeur dans la version interactive de notre recherche. Mais l'argument central en est un que je tiens à défendre personnellement, car il a façonné notre façon de tout construire.

La nuit où nous avons compris que le microphone était le mauvais point de départ

Il était environ 21 h, un jeudi de la fin du printemps. Moi, mon cofondateur et deux ingénieurs, debout sur le parking d'un Taco Bell fermé que nous avions eu la permission d'utiliser pour nos tests. Nous avions monté notre prototype sur un poteau — un haut-parleur, un micro, du ruban adhésif pour tout tenir ensemble. Nous l'avions fait tourner en laboratoire pendant des semaines avec une précision d'environ 95 %. Nous nous sentions prêts.

La première voiture à s'être présentée était une femme dans une Honda Civic, sa vitre à moitié baissée. Elle a dit « Je voudrais un menu numéro trois » assez clairement. Le système a entendu « île engourdie recon bol ». J'ai regardé mon cofondateur. Il regardait le sol.

La précision n'était pas seulement mauvaise — elle était inutilisable. Nous sommes restés sur ce parking encore deux heures, à enchaîner test après test, et les chiffres n'ont fait qu'empirer à mesure que le trafic de la soirée s'intensifiait. Je me souviens du moment exact où j'ai cessé de me sentir frustré pour commencer à ressentir quelque chose de plus proche de l'effroi : ce n'était pas un problème de réglage. Toute notre approche était erronée.

Le problème n'était pas le modèle de langage. Le modèle allait bien. Le problème, c'était tout ce qui se passait avant que l'audio n'atteigne le modèle. Le bruit du vent. Le grondement du moteur. Le bourdonnement mécanique d'une unité de CVC à six mètres de là. Un klaxon de voiture trois pâtés de maisons plus loin. Notre système ne pouvait pas faire la différence entre une voix humaine et un moteur diesel parce que, au niveau du signal, personne ne le lui avait appris.

Ce fut le moment où j'ai compris quelque chose que, je pense, la plupart des gens dans ce domaine n'ont toujours pas intériorisé : l'IA vocale n'est pas un problème de TAL. C'est d'abord un problème de traitement du signal, ensuite un problème de linguistique, et un problème de TAL en troisième lieu. Si votre première couche est défaillante, rien en aval ne peut vous sauver.

Pourquoi l'IA des services au volant coupe-t-elle sans cesse la parole aux gens ?

Le coupable s'appelle la détection d'activité vocale — VAD (Voice Activity Detection). C'est le système qui décide quand vous avez commencé à parler et quand vous vous êtes arrêté. Dans la plupart des solutions de type wrapper, il s'agit d'un simple seuil d'énergie : le son passe au-dessus d'une ligne, l'enregistrement démarre ; le son descend sous cette ligne, l'enregistrement s'arrête.

Imaginez cela dans un service au volant. Vous marquez une pause d'une demi-seconde pour jeter un œil au panneau du menu. L'énergie chute. La VAD décide que vous avez terminé. Elle envoie un fragment de phrase au modèle, le modèle hallucine une réponse à une question que vous n'avez jamais fini de poser, et vous voilà en train de discuter avec un haut-parleur.

Nous avons reconstruit notre VAD à partir de zéro. Au lieu de seuils d'énergie, nous utilisons des modèles neuronaux — Silero, Cobra — qui produisent un score de probabilité de parole humaine sur diverses fréquences. Au lieu d'un tout ou rien binaire, notre système fournit un niveau de confiance. Et au lieu d'une tolérance de pause statique de 500 millisecondes, nous utilisons une fenêtre dynamique de 600 à 1 000 millisecondes qui s'ajuste en fonction du contexte conversationnel.

L'astuce qui a fait la plus grande différence, cependant, c'est ce que nous appelons la transcription spéculative. Le système commence à traiter l'audio à 250 millisecondes, mais ne s'engage pas sur un point de fin avant 600 millisecondes de silence confirmé. Ce chevauchement réduit la latence perçue de 350 à 600 millisecondes tout en éliminant les coupures prématurées.

Mon cofondateur a soutenu pendant des semaines que la fenêtre de pause dynamique était de la sur-ingénierie. Nous étions au bureau tard un soir — café froid, tableaux blancs couverts de diagrammes de latence — et il a repoussé sa chaise en disant : « Nous consacrons trois semaines-ingénieur à une fonctionnalité qui fait gagner une demi-seconde. Personne ne marque une pause d'une seconde entière à un service au volant. C'est un problème de vanité. » J'ai répondu quelque chose comme : « Et si tu as tort, nous aurons construit un système qui coupe la parole à chaque client qui a besoin de réfléchir. » Nous ne nous sommes plus parlé du reste de la nuit. Il est parti vers minuit. Je suis resté et j'ai continué à faire tourner des simulations.

Puis nous l'avons testé avec de vrais clients. Il s'avère que les gens font constamment des pauses — en regardant le menu, en se tournant pour demander à un passager ce qu'il veut, en se demandant s'ils ont vraiment besoin de frites. Une seconde entière de pause naturelle n'est pas du silence. C'est de la réflexion. Mon cofondateur m'a envoyé un message d'une ligne après avoir vu les résultats du test : « Tu avais raison. Désolé pour la chaise. »

Quand vous optimisez pour la vitesse au détriment de la patience, vous construisez un système qui ne fonctionne que pour les gens qui savent déjà ce qu'ils veulent.

80 millions de personnes

Le bégaiement touche plus de 80 millions de personnes dans le monde. Ce chiffre a résonné différemment en moi après l'épisode du parking.

Il se manifeste par des répétitions (« b-b-b-baconator »), des prolongations (« mmmmlait ») et des blocages — des pauses silencieuses au milieu d'un mot où la personne est physiquement incapable de produire un son.

Maintenant, réfléchissez à ce qu'une VAD standard fait d'un blocage. La personne cesse d'émettre un son en plein mot. Le système interprète le silence comme la fin du tour de parole. Il répond à un demi-mot. La personne réessaie. Le système traite la répétition comme une nouvelle commande. En dix secondes, vous vous retrouvez avec une IA désorientée, un humain frustré et une file de voitures qui s'allonge derrière eux.

Ce n'est pas un cas marginal. C'est un choix de conception. Lorsque vous entraînez un modèle de RAP (reconnaissance automatique de la parole) presque exclusivement sur de l'anglais américain « standard » — bien articulé, avec un minimum de pauses — vous prenez une décision sur les personnes à qui votre système s'adresse. La recherche montre que les modèles de RAP fondés sur Conformer (une architecture neuronale qui combine la convolution avec l'auto-attention pour le traitement audio), l'épine dorsale de la plupart des systèmes modernes, voient leurs performances se dégrader si gravement sur la parole désordonnée que certains renvoient des scores de similarité sémantique négatifs. Pas seulement inexacts — sémantiquement inversés.

Lorsque votre modèle d'IA renvoie des scores sémantiques négatifs sur la parole désordonnée, vous n'avez pas construit un système qui peine sur des cas marginaux. Vous avez construit un système qui n'a jamais été conçu pour entendre une part importante de l'humanité.

Un investisseur m'a dit un jour, sans détour : « Utilise simplement l'API et affine-la plus tard. Tu brûles ta trésorerie sur un problème qui touche un petit pourcentage de clients. » J'ai sorti les chiffres sur mon téléphone — 80 millions de personnes rien que pour le bégaiement, avant même de compter les accents, les locuteurs de l'anglais langue seconde (ESL, English as a Second Language), les clients âgés, quiconque commande dans une voiture bruyante. J'ai vu son visage changer. « Ça, ce n'est pas un petit pourcentage », a-t-il dit. « Non, ai-je répondu. En effet. »

Nous affinons des modèles auto-supervisés sur des jeux de données de parole disfluente ré-annotés. Nous utilisons l'insertion synthétique de disfluences — en prenant des transcriptions fluides, en y ajoutant des blocages et des répétitions, en les synthétisant en audio d'entraînement. C'est un travail minutieux. Ce n'est pas le genre de chose qui apparaît sur un tableau comparatif de fonctionnalités. Mais c'est ce qui fait la différence entre un système qui fonctionne pour tout le monde et un système qui fonctionne pour la moyenne.

Que se passe-t-il quand l'IA vocale s'exécute en périphérie plutôt que dans le cloud ?

Chaque mot prononcé dans le microphone d'un service au volant Wendy's traverse l'internet public jusqu'à un centre de données Google et en revient. Cet aller-retour coûte de 100 à 500 millisecondes avant même que le modèle ne commence à traiter. Dans l'interaction vocale, la référence absolue est un temps de réponse inférieur à 300 millisecondes — au-delà, la conversation cesse de paraître naturelle. À 700-900 millisecondes, on dirait un mauvais appel téléphonique. À deux secondes, les gens commencent à parler par-dessus le système.

Nous avons tout déplacé en périphérie. Traitement local sur du matériel spécialisé sur le site même du restaurant. Notre latence est tombée à 5 à 10 millisecondes.

Mais le véritable enseignement n'était pas seulement la vitesse — c'était la taille du modèle. Un LLM à usage général a besoin de tout savoir sur tout. Un petit modèle de langage spécifique à un domaine a besoin de savoir que « Dave's Single » est un burger, pas un album de musique. Cette focalisation signifie une inférence plus rapide, des réponses plus prévisibles et une fraction du coût de calcul. Nous avons observé des améliorations de vitesse de 3x et des coûts opérationnels inférieurs de 30 à 40 % par rapport aux approches basées sur le cloud.

L'architecture en périphérie a aussi résolu un problème que nous n'avions pas pleinement anticipé : la fiabilité. Quand l'internet tombe en panne — et cela arrivera — un système dépendant du cloud devient un presse-papiers très coûteux. Notre système continue de fonctionner. Pour l'analyse technique complète de notre architecture en périphérie face aux approches cloud, vous pouvez plonger dans l'article de recherche.

Le mur réglementaire dont personne ne parle

La norme CAN-ASC-6.2:2025 a atterri sur mon bureau début 2025, et je me souviens de l'avoir lue avec un mélange de soulagement et de sentiment de justification — voici enfin une norme qui disait ce vers quoi nous avions bâti : les personnes handicapées doivent être impliquées dans la conception, les tests et la gouvernance des systèmes d'IA. Pas après coup. Dès le début. La loi européenne sur l'accessibilité (European Accessibility Act) entre en vigueur en juin 2025 avec de lourdes amendes, et l'ADA est en cours de réinterprétation pour couvrir les obstacles numériques pour les personnes ayant un handicap de la parole. Rénover un système non conforme sur 600 établissements coûte à peu près cinq fois ce qu'il en coûte de bien le construire dès le départ.

« Et si nous étions simplement en train de construire une façon vraiment coûteuse de prendre une commande de burger ? »

Cette pensée m'a frappé vers 2 h du matin, peut-être six mois après le début du développement. J'étais seul au bureau, à fixer le spectrogramme d'un mot bégayé que notre système ne parvenait toujours pas à analyser. Nous y travaillions depuis des mois. Nous avions épuisé la majeure partie de notre financement initial. Et les entreprises de wrapper d'API livraient des produits pendant que nous étions encore en train de déboguer des chaînes de traitement du signal.

J'ai failli tout arrêter. J'ai failli décider de simplement envelopper l'API, de livrer quelque chose et d'itérer plus tard comme tout le monde.

Mais « itérer plus tard » est un mensonge dans l'IA vocale. Une fois que vous avez construit votre architecture autour d'hypothèses de dépendance au cloud, de seuil de VAD et de parole fluide uniquement, chaque interaction client renforce ces hypothèses dans vos données d'entraînement. Vous n'itérez pas vers l'accessibilité. Vous itérez en vous en éloignant.

Construisez d'abord pour le cas marginal, et le cas moyen se règle de lui-même. Construisez pour la moyenne, et le cas marginal n'est jamais corrigé.

Le problème de l'alternance des tours de parole qui m'a fait tout repenser

Il y a une subtilité dans la conversation humaine que nous tenons complètement pour acquise. Quand vous dites « Je voudrais un Baconator et... » — ce « et » en suspens signale que vous n'avez pas fini. Un caissier humain attendrait. La plupart des IA de service au volant ne le font pas.

Nous avons intégré ce que je conçois comme une grammaire conversationnelle dans notre logique de détection de fin de tour. Le système analyse en temps réel des indices linguistiques : les conjonctions qui signalent une continuation, les changements de hauteur tonale qui signalent l'achèvement, l'expression « c'est tout » qui veut dire exactement ce qu'elle dit. Quand un client dit « c'est tout », notre système répond en moins de 200 millisecondes parce que l'intention est sans ambiguïté. Quand il laisse traîner un « et... », le système attend, même à travers une seconde entière de silence.

C'est aussi là que réside notre philosophie de supervision humaine (human-in-the-loop). Nous ne pensons pas que l'IA devrait gérer l'intégralité de la transaction sans supervision. Les requêtes simples et transactionnelles — l'IA s'en charge. Les situations complexes, les clients frustrés, les moments à forte friction — ceux-là sont transférés à un humain avant que l'interaction ne s'effondre, et non après.

L'objectif n'a jamais été de remplacer l'humain au service au volant. C'était de faire en sorte qu'aucun client n'ait jamais à crier « AGENT » à une machine qui n'écoute pas.

Je reviens sans cesse à ce taux de réussite de 86 % rapporté par Wendy's. Dans la plupart des contextes logiciels, 86 % serait un échec. Imaginez une application bancaire qui traite correctement 86 % des transactions. Imaginez un système de navigation qui vous amène à la bonne destination 86 % du temps. Le service au volant a d'une manière ou d'une autre normalisé un taux d'échec qui serait inacceptable dans toute autre interaction avec le consommateur.

C'est un problème d'architecture, pas un problème d'IA

Le schéma que je vois à travers le secteur, ce sont des entreprises qui traitent l'IA vocale comme une couche logicielle — quelque chose que l'on greffe par-dessus une infrastructure existante avec la bonne clé d'API. Et je comprends pourquoi. C'est rapide, c'est bon marché, et les démonstrations sont incroyables.

Mais le service au volant n'est pas une démo. Ce sont des moteurs diesel, du vent, des bambins, des accents, du bégaiement et des gens qui font une pause pour réfléchir. C'est toute la complexité irréductible de la communication humaine se déroulant dans le pire environnement acoustique possible. On ne peut pas s'en sortir avec un wrapper.

Les entreprises qui remporteront ce marché — et je le dis avec le parti pris de quelqu'un qui a misé sa carrière dessus — sont celles qui sont prêtes à aller en profondeur. En profondeur dans le traitement du signal. En profondeur dans la modélisation acoustique. En profondeur dans la linguistique de la façon dont les gens parlent réellement, et non de la façon dont les données d'entraînement de la RAP disent qu'ils devraient parler. En profondeur dans une infrastructure en périphérie qui ne dépend pas d'un centre de données à mille cinq cents kilomètres de là.

Il n'y a pas de raccourcis dans l'IA vocale. Il n'y a que le travail rigoureux, sans gloire et profondément technique de construire des systèmes qui entendent chaque client. Pas 86 % d'entre eux. Chacun d'entre eux.

Voilà ce que signifie « de niveau entreprise ». Et tant que le secteur n'aura pas accepté cette définition, nous continuerons à regarder des vidéos de haut-parleurs de service au volant incapables de comprendre le mot « Baconator ».