Peut-on se fier à ce qu’elle construit ? Tester la reconnaissance vocale en santé

Cet article a d’abord été publié par Quality IT Resourcing sur LinkedIn le 19 octobre 2026, sous le titre Healthcare AI Can’t Afford to Be Almost Right (en anglais).

De « peut-elle le construire ? » à « peut-on s’y fier ? »

L’IA a changé la vitesse à laquelle on fabrique du logiciel. Un travail qui prenait des semaines à une équipe peut aboutir à un prototype fonctionnel en quelques jours. Cette vitesse pose une question plus difficile à toute organisation qui met l’IA au travail : comment savoir si le résultat est fiable ?

J’ai vu les grands modèles de langage passer de la difficulté à écrire du code qui fonctionne à un code qui rivalise avec celui d’ingénieurs expérimentés, en ce qui m’a semblé être un rien de temps. Si l’IA pouvait construire aussi vite, la vraie question n’était plus « peut-elle le construire ? », mais « peut-on se fier à ce qu’elle construit ? »

J’ai étudié l’informatique à l’Université du Manitoba, avec une spécialisation en IA et en apprentissage automatique. Au sein de l’équipe de recherche de Zokforce, je construis des systèmes d’IA agentique avec LangGraph, MCP, la génération augmentée par récupération (RAG), FastAPI et Google Cloud.

Un client fédéral du secteur de la santé

L’un de mes projets consistait à évaluer un système de reconnaissance vocale pour un client fédéral du secteur de la santé. Le système devait transcrire des conversations en anglais et en français, et rester exact malgré la terminologie médicale, les accents, le bruit de fond et les passages d’une langue à l’autre.

Termes médicauxUn seul mot erroné peut changer un dossier

Reconnaissance vocale bilingueDes conversations en anglais et en français

AccentsBeaucoup de locuteurs, beaucoup de façons de parler

Bruit de fondDes sons qui ne viennent pas du locuteur

Changement de langueL’anglais et le français dans une même conversation

En santé, une erreur de transcription n’a rien d’anodin. Elle peut changer le sens d’un dossier.

Le client avait besoin de preuves que le système était fiable avant de l’accepter, pas seulement de la parole d’un fournisseur affirmant qu’il « fonctionnait bien ».

Un audio de test à la réponse connue

D’habitude, on teste un tel système à la main : des personnes lisent des scripts à voix haute, puis quelqu’un vérifie les transcriptions à l’œil. C’est lent, deux testeurs jugent rarement de la même façon, et aucune série ne peut être reproduite à l’identique.

J’ai contribué à concevoir une autre approche. Plutôt que de compter sur des personnes qui lisent des scripts de test à voix haute, nous avons généré l’audio de test par synthèse vocale. Comme nous avions écrit le script, nous savions exactement ce qui devait en sortir.

01Écrire le scriptLe texte qu’on attend en retour

02Générer l’audioLa synthèse vocale lit le script à voix haute

03TranscrireLe système évalué le remet en texte

04NoterTaux d’erreur sur les mots et sur les caractères, par rapport au script

ReproductibleChaque série se relance à l’identique après chaque modification, dans les deux langues

Chaque extrait généré passait par le système de reconnaissance vocale, et chaque transcription était notée par rapport à son script selon deux mesures courantes : le taux d’erreur sur les mots (WER) et le taux d’erreur sur les caractères (CER). Le jeu de tests pouvait s’étendre aux deux langues et aux cas difficiles, et chaque série pouvait être relancée à l’identique après chaque modification. L’équipe d’acceptation du client a obtenu des preuves mesurées et reproductibles du rendement du système, et non des impressions.

Trouver la cause, pas seulement l’erreur

L’automatisation signale vite qu’un résultat est faux. Elle ne dit pas pourquoi. Quand une transcription revenait erronée, le plus difficile n’était pas de repérer l’erreur, mais d’en comprendre la cause. Était-ce l’audio, l’accent, un terme du domaine, le changement de langue ou le système lui-même ?

La repérer est la partie facileUne transcription revient erronée

L’audio

L’accent

Un terme du domaine

Le passage à l’autre langue

Le système lui-même

La partie difficileComprendre pourquoiPuis empêcher que le même échec se reproduise

Cette distinction compte pour quiconque confie à l’IA un travail sensible. Repérer une erreur n’est qu’un début. Un système devient fiable quand on comprend pourquoi il a échoué et qu’on empêche le même échec de se reproduire.

Vérifier aussi vite qu’on construit

Pour moi, les tests font partie de la construction de l’IA ; ce n’est pas une étape qui vient après. Mes propres projets d’agents, bâtis avec des agents LangGraph, des outils MCP et de la récupération d’information, s’accompagnent d’une suite de tests automatisés qui s’exécute à chaque modification.

Le problème que je vois le plus souvent, c’est que les organisations peuvent maintenant construire de l’IA rapidement, mais pas la vérifier rapidement. La plupart évaluent encore l’IA à vue de nez : quelqu’un essaie dix requêtes, les réponses semblent bonnes, et on met en production.

À vue de nezQuelques requêtes et une bonne impression

• Quelqu’un essaie dix requêtes
• Les réponses semblent bonnes
• On met en production

Vérifier aussi vite qu’on construit

Sur preuvesTesté à chaque modification

• Les bonnes réponses définies d’avance
• Les cas difficiles à chaque série
• Des tests automatisés après chaque modification
• Une révision humaine là où les enjeux sont élevés

Quatre réflexes pour les dirigeants

Mes conseils aux dirigeants d’entreprise :

1. Définir l’exactitude en termes d’affaires. Décidez ce qu’est une bonne réponse pour votre travail avant de mesurer quoi que ce soit.
2. Bâtir les jeux d’évaluation autour des cas difficiles. Le cas courant fonctionne en général ; testez les cas qui font le plus de tort quand ils échouent.
3. Tester automatiquement après chaque modification. Un nouveau modèle, une nouvelle requête ou une nouvelle source de données peut briser ce qui fonctionnait hier.
4. Garder l’humain aux commandes là où les enjeux sont élevés. La révision humaine reste partout où une erreur a de réelles conséquences.

Les systèmes fondés sur les grands modèles de langage échouent en silence et de façon inégale. Ils se débrouillent bien dans le cas courant et cèdent sur les cas limites qui comptent le plus.

À mesure que les agents d’IA prennent en charge une plus grande part du travail, l’évaluation déterminera quels systèmes dépassent la démonstration impressionnante pour devenir fiables au quotidien. L’IA peut désormais construire du code et des produits plus vite que jamais, mais le jugement humain ne suit pas ce rythme. Les gens se fatiguent, et c’est à la révision que les erreurs passent. Savoir vérifier la qualité à grande échelle pourrait devenir l’une des capacités les plus précieuses qu’une organisation puisse bâtir.

La même logique guide le travail d’ingénierie de harnais d’IA de Zokforce : des cas de test bâtis avec vos spécialistes autour des cas limites à risque élevé, chaque mise à jour notée automatiquement avant sa mise en production, et chaque réponse vérifiée avant qu’on s’y fie.

Références

• Quality IT Resourcing, « Healthcare AI Can’t Afford to Be Almost Right », LinkedIn, 19 octobre 2026 (en anglais).
• Aiden Mak, ingénieur en IA, équipe de recherche de Zokforce : Aiden Mak sur LinkedIn.