Tout a commencé avec une question apparemment simple : comment générer des débats audio de qualité à partir de mes articles, entièrement en local, sans dépendre du cloud ?
Ce qui devait être un déploiement rapide s'est transformé en une exploration de plusieurs semaines des modèles de synthèse vocale open source. Voici le récit honnête de ce parcours — avec les problèmes rencontrés, les solutions trouvées, et les compromis acceptés.
Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.
Le contexte : débats audio générés par IA
Depuis quelque temps, je génère des débats audio à partir de mes articles de blog. Le principe est simple : prendre un article technique, le faire transformer en script de débat par un LLM (en l'occurrence qwen3:4b-nothink, un modèle que j'ai découvert et qui excelle pour ce type de tâche), puis synthétiser ce script avec des voix distinctes pour deux personnages.
Le résultat est un contenu audio engageant, facile à consommer, qui donne une deuxième vie aux articles. Mais pour que ça fonctionne vraiment, la qualité vocale doit être au rendez-vous. Et c'est là que les choses se sont compliquées.
Edge-tts : un bon début, mais avec des limites bloquantes
Le choix initial
Edge-tts (le service de synthèse vocale de Microsoft Azure, accessible gratuitement via une bibliothèque Python) était ma solution de départ. Sur le papier, tout semblait parfait : ~400 voix disponibles, multilingue natif, gratuit, simple à intégrer.
En pratique, deux limitations ont vite rendu la solution insatisfaisante pour mon usage.
Limitation 1 : le choix cornélien des voix françaises
En français, edge-tts propose deux catégories de voix :
- Les voix françaises "standard" (comme fr-FR-HenriNeural) : bonne qualité de locution française, accent naturel, mais limitées au français. Dès qu'un texte contient un mot anglais, un acronyme, ou une expression étrangère — ce qui est inévitable dans les articles tech — la prononciation devient approximative.
- Les voix "Multilingual" (comme fr-FR-RemyMultilingualNeural) : qualité de synthèse nettement supérieure, capables de prononcer correctement l'anglais, mais... elles décident seules quand switcher de langue.
Limitation 2 : le basculement de langue incontrôlable
C'est ce deuxième point qui a été le plus frustrant. Avec les voix multilingues, la synthèse bascule automatiquement vers l'anglais — ou parfois une autre langue — sur certains mots ou expressions, sans que je puisse contrôler ce comportement.
Un terme comme "Docker", "API gateway", ou simplement une phrase avec structure anglaise, et soudain la voix se met à parler anglais au milieu d'un débat en français. J'ai tout essayé : balisage SSML, nettoyage du texte, phonétisation forcée. Rien n'a résolu le problème de façon fiable.
À cela s'ajoutaient des erreurs 503 fréquentes (service Microsoft temporairement indisponible) qui interrompaient la génération à mi-parcours, nécessitant des relances manuelles.
Il fallait passer au 100 % local.
XTTS v2 : la promesse du local, les réalités de l'autorégressif
La découverte
XTTS v2 est le modèle de synthèse vocale de Coqui AI, disponible en open source. Ses atouts sur le papier : 17 langues supportées dont le français et le japonais, clonage de voix à partir d'un échantillon de 6 secondes, déploiement Docker avec GPU.
J'ai installé le serveur via l'image daswer123/xtts-api-server, connecté ma RTX 3050 6GB, et enregistré des échantillons de voix pour mes deux personnages — Mathieu et Vivienne — à partir de segments edge-tts de bonne qualité. L'API REST intégrée rendait l'intégration dans ma pipeline simple.
Les premiers résultats : prometteurs
La qualité de la locution française était au rendez-vous. Le modèle prononçait correctement les mots, gérait bien les liaisons, et le clonage de voix donnait une identité sonore cohérente aux personnages. Les débats commençaient à ressembler à quelque chose.
Le problème structurel : les artefacts
Mais très vite, un problème est apparu et s'est révélé impossible à éradiquer complètement : les artefacts audio.
XTTS v2 utilise une architecture autorégressive (basée sur un GPT). Cette approche génère l'audio segment par segment, et aux jointures entre segments, on entend régulièrement :
- Des clicks et pops (bruits parasites aux transitions)
- Des hums (bourdonnements basse fréquence)
- Des sons aigus désagréables (chirps haute fréquence, parfois jusqu'à 20-30 % des segments)
J'ai implémenté un post-processing agressif : filtre spectral (noisereduce), fade-in/fade-out sur chaque segment, normalisation RMS, concaténation ffmpeg. Les artefacts les plus sévères étaient atténués, mais jamais complètement absents. C'était une course sans fin entre la qualité désirée et les contraintes structurelles du modèle.
Un autre facteur aggravant : Coqui AI a fermé ses portes en décembre 2025. XTTS v2 n'est plus maintenu. Les bugs identifiés ne seront jamais corrigés.
CosyVoice2 : une architecture différente, des compromis différents
La découverte du flow matching
C'est en cherchant une alternative que j'ai découvert CosyVoice2-EU (Luka512/CosyVoice2-0.5B-EU), un modèle entraîné spécifiquement sur des langues européennes dont le français.
La différence architecturale est fondamentale. CosyVoice2 utilise le flow matching — une technique qui génère l'audio en une seule passe, sans découpage en segments. Résultat immédiat : zéro artefacts de jointure. Les clicks, pops et hums ont disparu.
L'installation : moins évidente sur Windows
L'installation sur Windows a demandé quelques ajustements. Le package WeTextProcessing (normalisation chinoise) ne compile pas sans les outils C++ de développement, et phonemizer en dépend. J'ai dû patcher frontend.py pour ajouter des fallbacks no-op — sans aucun impact sur la qualité française puisque le normalizer chinois n'est simplement pas nécessaire.
Une image Docker Linux est en cours de construction pour avoir un environnement propre et reproductible.
Les métriques de qualité
Les tests sur ma RTX 3050 6GB ont donné des résultats solides :
| Métrique | XTTS v2 | CosyVoice2-EU |
|---|---|---|
| Artefacts | Oui (structurels) | Aucun observé |
| Prosodie française | Plate, robotique | Naturelle |
| VRAM | ~3.2 GB | ~3.5 GB |
| Facteur temps réel (RTF) | ~0.3 | ~0.8–1.5 |
| Licence | Coqui non-commercial | Apache 2.0 |
| Maintenance | Abandonné (déc. 2025) | Actif (2025) |
Les limitations actuelles
La migration n'est pas sans compromis. CosyVoice2 présente ses propres défis :
1. La phonétique Le modèle a des difficultés avec certains acronymes et mots techniques. Des sigles comme "SQL", "RAG", ou "API" peuvent être mal prononcés ou lus lettre par lettre de façon peu naturelle. J'ai dû construire un dictionnaire de phonétisation spécifique pour corriger ces cas.
2. Les hallucinations occasionnelles Sur des textes complexes ou des structures de phrases inhabituelles, le modèle peut parfois générer des segments avec des syllabes répétées ou des sonorités parasites. Rien d'aussi systématique que les artefacts XTTS, mais à surveiller.
3. Le timbre des voix C'est la limitation la plus subjective. Les voix générées par CosyVoice2, surtout en dehors des voix de référence directes, peuvent prendre un timbre un peu... étrange. "Voix de sorcière" est l'expression qui m'est venue. Ce n'est pas une critique du modèle — c'est inhérent aux voix de référence utilisées et au processus de clonage.
La bonne nouvelle : contrairement aux artefacts XTTS qui sont structurels et irrattrapables, les problèmes de timbre et de phonétique sont corrigeables. En travaillant sur la qualité des voix de référence et le pré-traitement du texte, on peut progressivement améliorer le résultat.
4. La vitesse Le RTF de 0.8 à 1.5 sur RTX 3050 signifie qu'un débat de 5 minutes prend 4 à 7 minutes à générer (contre ~2 minutes avec XTTS). Acceptable pour une génération asynchrone nocturne, mais ça change le tempo de travail.
Ce que ce parcours m'a appris
Sur le choix des modèles TTS
Il n'existe pas encore de modèle TTS local "parfait" pour le français en 2026. Chaque solution implique des compromis :
- Edge-tts : excellent pour la qualité pure, mais dépendance cloud et basculement de langue incontrôlable sur les voix multilingues.
- XTTS v2 : bon locuteur français, mais artefacts structurels et modèle abandonné.
- CosyVoice2 : meilleure architecture, zéro artefacts, mais plus lent et timbre perfectible.
Sur les architectures
L'expérience confirme une tendance forte : les architectures autorégressives (GPT-like) génèrent des artefacts aux jointures par nature. Les architectures flow matching ou diffusion éliminent ce problème structurellement. Pour la qualité audio, c'est un critère de sélection de plus en plus important.
Sur l'amélioration incrémentale
Le dernier enseignement est peut-être le plus important pour une approche craft : mieux vaut un modèle avec des problèmes corrigeables qu'un modèle avec des problèmes structurels. CosyVoice2 a des limitations — mais elles sont du côté "données et paramétrage", pas du côté "architecture fondamentale". La progression est possible.
La suite
Les prochaines étapes sur ce chantier :
- Finaliser le Docker Linux pour CosyVoice2, qui permettra d'avoir WeTextProcessing et phonemizer disponibles nativement.
- Enrichir le dictionnaire de phonétique pour les termes techniques fréquents dans mes articles.
- Tester de nouvelles voix de référence pour améliorer le timbre.
- Surveiller Kokoro et Piper — deux alternatives légères qui progressent rapidement et pourraient offrir un meilleur compromis qualité/vitesse sur CPU.
La génération audio locale en est encore à ses débuts. Mais la trajectoire est claire : dans quelques mois, la qualité sera comparable au cloud, sans aucune dépendance externe.
Retrouvez les rapports techniques détaillés sur les tests XTTS v2, OuteTTS et CosyVoice2 dans les ressources du projet.
Ressources
- CosyVoice2-0.5B-EU — HuggingFace
- XTTS-v2 — HuggingFace (Coqui)
- daswer123/xtts-api-server — GitHub
- Kokoro-82M — HuggingFace
- Piper TTS — GitHub
Qui suis je ?
Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.
J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.
Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.
L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.
La technologie, les méthodes, le management sont le cœur de mes compétences.
Vous pouvez me faire confiance sur ces points là.
Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr
Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100% IA.
De edge-tts à CosyVoice2 : mon parcours pour générer des débats audio en local