IA Azure : Convertissez un Word en mp3

Vous utilisez la Lecture à voix haute de Word pour écouter vos lonnnnnnnnnng textes, mais vous aimeriez les emporter ailleurs, dans le train, en voiture ou en balade ? Le problème, c’est que Word lit le document pendant qu’il est ouvert, et c’est tout. Moi, je voulais un vrai fichier MP3, autonome, qu’on peut réécouter n’importe où. Et comme mes documents sont longs (très longs), j’ai automatisé la conversion avec un petit outil maison : WordToMp3.

Au programme : le fonctionnement de l’outil en quelques lignes, puis trois tests concrets, du dry run jusqu’à un document de 183 773 caractères transformé en plus de 3 heures d’audio.

• 1. Dictée, Lecture à voix haute, WordToMp3 : de quoi on parle ?
• 2. Pourquoi un script pour un long document ?
• 3. Comment ça marche ?
• 4. Installation et lancement
• 5. Trois tests concrets
• 6. Le cache et la reprise
• 7. Pièges et vigilance
• 8. Conclusion

1. Dictée, Lecture à voix haute, WordToMp3 : de quoi on parle ?

Premier réflexe à prendre : ne pas confondre les fonctionnalités. Word sait transformer la voix en texte, et le texte en voix. Mais aucune des deux ne correspond exactement à ce que je cherchais.

Mon point de départ, c’est donc la Lecture à voix haute, pas la Dictée. L’idée n’est pas d’enregistrer ce que Word lit :

WordToMp3 extrait le texte du document et demande une narration toute neuve à Azure Speech. La voix ne sera donc pas forcément celle que vous entendez dans Word.

2. Pourquoi un script pour un long document ?

Un script n’est pas la seule solution possible : une appli d’export audio ou un enregistrement de l’écran pourraient aussi faire l’affaire. Mais dès que le document dépasse quelques pages, les questions pratiques arrivent vite :

• comment lire un vieux .doc sans toucher au fichier d’origine ?
• comment éviter une seule requête de synthèse énorme ?
• que se passe-t-il si le réseau coupe à la moitié ?
• comment garder les passages dans le bon ordre ?
• comment obtenir un seul MP3 plutôt qu’une centaine de petits fichiers ?
• comment garder ma clé Azure et mes textes privés hors de GitHub ?

Ce qui m’intéresse ici, c’est d’avoir un traitement reproductible et capable de reprendre là où il s’est arrêté. La répartition des rôles est simple : Python orchestre, Word sert uniquement à extraire le texte, Azure Speech génère la voix et FFmpeg assemble le MP3 final.

3. Comment ça marche ?

WordToMp3 est une application en ligne de commande pour Windows, qu’on lance depuis PowerShell. Pas d’interface graphique, pas de site web : un lanceur convert.ps1 qui appelle le script Python convert.py, et c’est tout :

Concrètement, ça donne quoi ? Le traitement se déroule en cinq temps :

1. Extraction : pour un .doc ou un .docx, le script ouvre une instance Word séparée et invisible, en lecture seule, macros désactivées. Il récupère le corps du texte (tableaux compris), puis les notes de bas de page et de fin. Il referme ensuite sans enregistrer. Les fichiers .txt en UTF-8 sont lus directement, sans Word.
2. Découpage : le texte est nettoyé puis coupé en segments de 2 000 caractères maximum, de préférence à la fin d’un paragraphe, sinon d’une phrase.
3. Synthèse : chaque segment est envoyé à Azure Speech (voix fr-FR-DeniseNeural par défaut), un par un, et revient sous forme de fichier WAV.
4. Cache : chaque WAV est vérifié puis conservé à côté du futur MP3. Si on relance, les segments valides sont réutilisés.
5. Assemblage : FFmpeg encode tous les WAV en une seule passe (MP3 128 kbit/s, 24 kHz, mono), puis relit le MP3 en entier pour vérifier qu’il est lisible avant de le publier.

Pourquoi passer par des WAV plutôt que de coller directement des MP3 ? Parce qu’un WAV non compressé se vérifie et s’ordonne facilement. Et un seul encodage final évite de mettre bout à bout des dizaines de MP3 compressés séparément.

4. Installation et lancement

Côté prérequis, rien d’exotique :

L’installation tient en trois lignes :

python -m venv .venv
.\.venv\Scripts\python.exe -m pip install -r requirements.txt
.\convert.ps1 --help

Ensuite, on renseigne l’endpoint de sa ressource Azure et on lance la conversion :

$env:AZURE_SPEECH_ENDPOINT = "https://your-resource.cognitiveservices.azure.com/"
.\convert.ps1 "C:\Documents\book.docx" -o "C:\Audio\book.mp3"

Si la variable AZURE_SPEECH_KEY n’est pas définie, le script demande la clé avec une saisie masquée :

Quelques options utiles : --voice pour changer de voix, --chunk-size pour la taille des segments (de 100 à 3 000 caractères), --attempts pour le nombre de tentatives par segment, et --overwrite pour remplacer un MP3 existant.

5. Trois tests concrets

Le moment de vérité. Trois tests, du plus prudent au plus costaud.

Test n°1 : le dry run, sans toucher à Azure

Avant de dépenser le moindre centime, on vérifie que l’extraction et le découpage se passent bien. Le mode --dry-run s’arrête juste avant la synthèse : pas de clé demandée, pas d’appel à Azure, pas de fichier audio.

.\convert.ps1 .\docs\article\sample-narration.txt --dry-run

Sur le texte de démonstration fourni dans le dépôt, résultat : 14820 caractères, un seul segment, aucun appel à Azure :

Attention, le dry run ne vérifie ni la clé, ni les quotas, ni la disponibilité de la voix, ni la qualité audio. Il valide juste la partie locale.

Test n°2 : un document Word de taille raisonnable

Premier vrai passage par Azure Speech avec un .docx : 14 820 caractères, découpés en 8 segments, voix fr-FR-DeniseNeural. Le script affiche l’avancement segment par segment, puis assemble et vérifie le MP3.

Extracting: C:\audio\book.docx
14,820 characters, 8 segment(s), voice fr-FR-DeniseNeural.
Document body and tables included; notes appended at the end. Images excluded.
Azure Speech key (hidden):
[1/8] Synthesizing (1638 characters)...
[2/8] Synthesizing (1957 characters)...
...
[8/8] Synthesizing (1670 characters)...
Assembling and verifying the MP3...
Done: C:\audio\book.mp3
Duration: 14.9 minutes

Et là, magie : un seul fichier MP3 de 14,9 minutes, prêt à être copié sur un téléphone :

Test n°3 : le gros morceau, un vieux .doc de plus de 180 000 caractères

C’est pour ce cas-là que j’ai écrit l’outil. Un ancien document au format .doc, de 183 773 caractères, découpé en 99 segments d’environ 1 850 caractères en moyenne.

Extracting: C:\audio\book2.doc
183,773 characters, 99 segment(s), voice fr-FR-DeniseNeural.
Document body and tables included; notes appended at the end. Images excluded.
Azure Speech key (hidden):
[1/99] Synthesizing (1812 characters)...
[2/99] Synthesizing (1122 characters)...
...
[99/99] Synthesizing (1348 characters)...
Assembling and verifying the MP3...
Done: C:\audio\book2.mp3
Duration: 191.2 minutes

Résultat : 191,2 minutes d’audio, soit un peu plus de 3 heures de narration, produites en environ 2 minutes de traitement chez moi. Au passage, ce test confirme que l’extraction via Word fonctionne aussi sur l’ancien format .doc :

Côté taille, à 128 kbit/s, on peut estimer environ 184 Mo pour ce MP3 (c’est un calcul, pas une mesure). Prévoyez aussi de la place pour le cache WAV, nettement plus gros : de l’ordre de 500 Mo pour la même durée :

6. Le cache et la reprise

Sur un document de 99 segments, une coupure réseau au segment 70 serait rageante. C’est là que le cache entre en jeu. Les WAV sont rangés dans un dossier .speech-cache à côté du MP3, dans un sous-dossier identifié par une empreinte du texte découpé, de la voix et de l’endpoint.

book.mp3
book.speech-cache/
  <empreinte SHA-256>/
    00001.wav
    00002.wav
    ...

Si on relance la même commande, chaque WAV existant est vérifié : les segments valides sont réutilisés, les manquants ou abîmés sont régénérés. Un Ctrl+C en plein traitement affiche d’ailleurs la commande pour reprendre. En cas d’erreur passagère côté Azure (timeout, service indisponible, trop de requêtes), le script fait jusqu’à 4 tentatives par segment avant d’abandonner.

Le piège classique : changer le texte, la voix, l’endpoint ou l’emplacement du MP3 crée un nouveau cache, et donc une nouvelle synthèse complète. Pour reprendre, on relance exactement la même commande.

7. Pièges et vigilance

• Le texte part chez Azure : chaque segment est envoyé à Azure Speech. Le fichier Word lui-même n’est pas envoyé, mais tout son contenu l’est. À éviter pour un document confidentiel sans avoir vérifié les règles de traitement des données.
• Le cache n’est pas chiffré : les WAV et le MP3 contiennent l’intégralité du document, en audio. Supprimez le cache une fois le MP3 validé.
• Tout n’est pas lu : pas d’OCR pour les images et pages scannées, pas d’extraction dédiée des en-têtes, pieds de page et zones de texte flottantes. Les notes sont lues à la fin, pas à leur emplacement d’origine.
• Le coût : il dépend de la voix, de l’offre et de la région. Vérifiez la page de tarification Azure Speech avant de lancer un gros document. Le dry run compte les caractères, mais ne donne pas de devis.
• L’écoute reste indispensable : FFmpeg vérifie que le MP3 est lisible techniquement, pas que les noms propres, les dates ou les tableaux sonnent bien.

8. Conclusion

Voilà, en cinq étapes (extraction, découpage, synthèse, cache, assemblage), un long document Word devient un seul MP3 qu’on emporte partout. Concrètement, ça donne quoi ? Chez moi, un .doc de 183 773 caractères transformé en 3 h 11 d’audio en environ 2 minutes, sans toucher au fichier d’origine.

Les trois pièges à retenir :

1. le contenu du document part chez Azure Speech, et le cache local n’est pas chiffré ;
2. une relance réutilise les segments valides, mais pas si vous changez le texte, la voix, l’endpoint ou l’emplacement du MP3 ;
3. un MP3 lisible n’est pas forcément une bonne narration, écoutez avant de partager.

Côté pistes d’évolution, rien n’est encore livré, mais plusieurs idées sont sur la table : un découpage par chapitre, des réglages de vitesse et de pauses, de l’OCR pour les pages scannées ou un mode pour réassembler le MP3 depuis le cache sans repasser par Azure.

Le code est sur GitHub. Foncez tester, en commençant par un dry run sur un texte non sensible.