Vous avez une page web que vous ouvrez régulièrement pour vérifier si quelque chose a changé ? Une inscription qui doit ouvrir, un mot-clé qui doit apparaître, ou une annonce que vous attendez ? À force, on finit par actualiser la page plus souvent que nécessaire.

Avec webpagecheck, l’idée est simple : laisser un outil surveiller ces pages et vous prévenir par email lorsqu’une condition est détectée. Vous pouvez suivre un changement de texte, la présence d’un mot-clé ou décrire une condition en langage naturel pour une évaluation par IA. Le tableau de bord permet aussi de lancer une analyse ponctuelle et de consulter la dernière capture de la page.

Pourquoi un outil comme celui-ci ?

Des services de surveillance de pages existent déjà. Mais ils tournent chez un tiers, avec leurs limites d’abonnement, et voient passer vos URL comme vos adresses email. webpagecheck s’installe dans votre propre subscription Azure : vous gardez la main sur les données, les identités et le coût.

Quelques exemples d’usage :

• L’ouverture des inscriptions à un événement, une certification ou une formation.
• Le retour en stock d’un produit ou un changement de prix.
• La publication d’une offre d’emploi ou d’un appel à candidatures.
• La mise à jour de conditions générales, d’une documentation ou d’une page de statut.
• Une annonce attendue sur un blog ou une page produit.

Ce que fait l’application

Le tableau de bord regroupe les pages surveillées, leur mode, leur état, la dernière capture et la dernière alerte :

• Trois modes de détection : un changement de contenu, l’apparition ou la disparition d’un mot-clé, ou une condition en langage naturel évaluée par Azure OpenAI avec un score et un seuil réglable.
• La lecture de la page rendue : les modes mot-clé et IA lisent la page après exécution du JavaScript dans Chromium, comme le ferait votre navigateur.
• Une capture à chaque contrôle : visible dans le tableau de bord et jointe à l’email d’alerte.
• Des alertes email via Azure Communication Services, marquées URGENT et en priorité haute, avec des destinataires supplémentaires possibles par page.
• Scan et Check now : analyser une page sans rien envoyer, ou forcer un vrai contrôle. Chaque surveillance peut aussi être mise en pause, modifiée ou supprimée.
• Un mode test : les alertes sont simulées et consultables dans Alerts, sans envoyer d’email.
• Une sécurité de base : identité managée pour ACR et Azure OpenAI (aucune clé à gérer), mot de passe sur l’interface, URL publiques uniquement et données conservées dans Azure Files.

Dans cet article, on va déployer l’application sur Azure Container Apps à partir du script PowerShell du projet. Puis on configurera les notifications et une première surveillance, jusqu’au test de fonctionnement. L’IA reste optionnelle : les modes changement et mot-clé n’en ont pas besoin.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

• 1. Comprendre les trois modes de surveillance
• 2. Les prérequis et les services Azure utilisés
• 3. Récupérer le projet et préparer le dossier
• 4. Préparer Azure CLI et la bonne subscription
• 5. Lancer le déploiement PowerShell
• 6. Ouvrir l’application et configurer l’accès
• 7. Configurer les notifications email
• 8. Créer et tester une première surveillance
• 9. Aller plus loin avec le mode IA
• 10. Comprendre les captures et le choix de sandbox
• 11. Les pièges à connaître avant de laisser tourner
• 12. Combien ça coûte ?
• 13. Conclusion

1. Comprendre les trois modes de surveillance

Concrètement, ça donne quoi ? Plutôt que de tout faire reposer sur l’IA, l’outil propose trois modes. Le bon choix dépend de ce que vous cherchez à détecter.

Exemple : pour détecter l’ouverture d’inscriptions, un mot-clé très précis peut suffire. Si la formulation varie, le mode IA permet d’exprimer une condition comme « Les inscriptions à cet événement sont ouvertes ». Son score reste une estimation du modèle, pas une garantie que l’événement a réellement eu lieu.

2. Les prérequis et les services Azure utilisés

Ce tutoriel utilise un poste Windows avec PowerShell et Azure CLI. Le script de déploiement protège son fichier temporaire de paramètres sensibles avec des ACL Windows : ne le lancez pas tel quel depuis un Cloud Shell Linux ou WSL.

• Une subscription Azure autorisant les services nécessaires et leur facturation.
• Les droits de créer un groupe de ressources, de déployer l’infrastructure et d’attribuer les rôles à l’identité managée.
• Azure CLI installé et un terminal PowerShell autorisant l’exécution du script selon votre politique d’entreprise.
• Si vous activez l’IA, un accès au modèle et un quota suffisants pour le déploiement Azure OpenAI choisi.

L’application repose sur Python et Flask, avec Waitress pour servir l’interface. Playwright et Chromium réalisent les captures. Le script Bicep prépare les composants suivants :

Pas besoin de Docker ni de Python sur le poste pour ce parcours de déploiement : le build se fait dans ACR et l’installation Python se déroule dans l’image. Il faut en revanche récupérer tous les fichiers du projet nécessaires au build.

3. Récupérer le projet et préparer le dossier

Ouvrez Visual Studio Code, puis récupérez la version du projet mise à disposition avec cet article :

https://github.com/jlou07/webpagecheck

Puis clonez le dans un dossier de travail. Dans les exemples, j’utilise C:\Lab\webpagecheck : adaptez ce chemin à votre poste :

À la racine, vous devez notamment retrouver deploy.ps1, Dockerfile, .dockerignore, requirements.txt, les modules Python, le dossier static et infra\main.bicep. Gardez les exemples sans secret : pas de fichier de configuration personnel, de captures privées ni d’identifiants de votre environnement dans le paquet partagé.

Set-Location 'C:\Lab\webpagecheck'
Get-ChildItem

4. Préparer Azure CLI et la bonne subscription

Installez Azure CLI avec la procédure Microsoft adaptée à votre poste, puis ouvrez un nouveau terminal. Une fois l’outil disponible, connectez-vous et sélectionnez explicitement la subscription cible.

az version
az login --use-device-code
az account list --output table

$subscriptionId = Read-Host 'ID de la subscription cible'
az account set --subscription $subscriptionId
az account show --query "{Subscription:name,Id:id}" --output table

az bicep version
az extension add --name containerapp --upgrade

Si Bicep n’est pas encore disponible, la CLI sait l’installer lorsqu’une commande en a besoin. La documentation Microsoft explique également son installation et sa mise à jour. Si votre poste ou votre subscription applique des restrictions, réglez-les avant le lancement plutôt que de contourner les politiques de sécurité.

5. Lancer le déploiement PowerShell

Choisissez un groupe de ressources dédié à ce lab et un préfixe court. Le préfixe doit comporter de trois à huit caractères, en lettres minuscules et chiffres. Les valeurs ci-dessous sont des exemples, pas les identifiants d’une instance existante.

$resourceGroup = 'rg-webpagecheck-demo'
$namePrefix = 'wpcdemo'
$appName = "${namePrefix}-web"

$deployParameters = @{
    ResourceGroup   = $resourceGroup
    NamePrefix      = $namePrefix
    Location        = 'francecentral'
    OpenAiLocation  = 'swedencentral'
    ChromiumSandbox = $false
}

# Redéploiement uniquement : réutiliser le mot de passe existant
if (az containerapp show -g $resourceGroup -n $appName --query name -o tsv 2>$null) {
    $deployParameters.UiPassword = az containerapp secret list -g $resourceGroup -n $appName --show-values `
        --query "[?name=='ui-password'].value | [0]" -o tsv
}

.\deploy.ps1 @deployParameters

Au premier déploiement, l’application n’existe pas encore : le script génère alors un mot de passe initial. Lors d’un redéploiement, le bloc if réutilise le mot de passe existant. Le paramètre ChromiumSandbox = $false est nécessaire pour les captures sur Container Apps : il est expliqué en section 10.

Les ressources Azure commencent à apparaître :

Par défaut, l’email et Azure OpenAI sont activés. Le modèle configuré dans le Bicep du projet est gpt-4.1-mini, version 2025-04-14, en déploiement Global Standard. Vérifiez sa disponibilité, son cycle de vie et votre capacité à le déployer avant de lancer le script. Les régions d’exemple ne constituent pas une garantie de disponibilité pour votre subscription.

Pour commencer sans IA, ajoutez cette ligne avant l’appel du script :

$deployParameters.DeployOpenAi = $false

Cette option conserve les modes changement et mot-clé. L’option DeployEmail = $false existe également, mais elle retire l’envoi d’emails attendu dans ce tutoriel. Choisissez vos options avant l’exécution, ne lancez pas chaque variante à la suite.

Le script déroule quatre opérations :

1. Créer le groupe de ressources.
2. Déployer l’infrastructure avec Bicep, sans l’application dans cette première passe.
3. Construire l’image dans Azure Container Registry.
4. Déployer la Container App avec l’image qui vient d’être construite.

À la fin, le script affiche l’URL de l’interface, l’adresse expéditrice si l’email est activé et l’endpoint OpenAI si l’IA est activée :

Il n’affiche pas automatiquement le mot de passe initial. Vous pouvez le retrouver ici côté portail Azure :

L’URL est aussi disponible juste là:

6. Ouvrir l’application et configurer l’accès

Ouvrez la page de l’application, puis saisissez les identifiants :

Vous voilà dans l’application, rien de plus !

7. Configurer les notifications email

Dans le panneau Configuration, renseignez l’adresse expéditrice indiquée à la fin du déploiement et une adresse de destination que vous contrôlez. Pour le premier test, un seul destinataire suffit :

1. Renseignez Sender address avec l’expéditeur fourni par le domaine Azure Communication Services. Une adresse arbitraire de votre messagerie ne convient pas.
2. Renseignez Recipient addresses. Plusieurs adresses peuvent être séparées par des virgules.
3. Enregistrez les paramètres.
4. Vérifiez que l’envoi est actif et utilisez Send test notification pour recevoir un véritable email.

En mode test, les alertes sont conservées comme simulées dans l’interface, mais aucun email ne part. Le test de notification est lui aussi simulé lorsque l’envoi est désactivé. Un statut simulé ne prouve donc pas que votre messagerie a reçu quelque chose.

Si vous utilisez votre propre domaine, c’est parfaitement possible. Voici un domaine déjà utilisé dans Microsoft 365 :

Et dont la zone DNS est gérée sous Azure :

Depuis le portail Azure, sur les ressources créées, commencez par le vérifier dans le service Email :

Créez si besoin un MailFrom :

Puis liez-le à la ressource Communication Services :

Reconfigurez puis refaites un test d’envoi :

Contrôlez la bonne réception du test :

L’option CustomEmailDomain du script doit être conservée lors de ses prochaines exécutions : sinon, le déploiement revient au seul lien avec le domaine Azure.

8. Créer et tester une première surveillance

On commence avec un cas simple et sans IA. Ajoutez une page avec les valeurs suivantes :

Enregistrez la page, puis attendez quelques secondes le résultat de l’analyse automatique :

Quelques secondes plus tard, le mail d’alerte arrive également :

Modifiez le test existant en remplaçant le mot par un autre qui n’existe pas, sauvegardez :

Quelques secondes plus tard, constatez le résultat de la seconde analyse automatique :

L’icône Scan affiche l’analyse et le contenu de l’email qui serait préparé. Le Scan ne modifie pas l’état de référence de la surveillance et n’envoie pas d’email :

L’icône Check now est différente : elle réalise une vraie vérification, met à jour l’état et peut déclencher une alerte si la condition le justifie :

Le moment de vérité : une fois l’analyse validée, réactivez l’envoi et provoquez une transition contrôlée. Vérifiez la réception de l’email, puis son statut dans Alerts. Une fois ce parcours validé, choisissez un intervalle raisonnable pour vos vraies surveillances.

9. Aller plus loin avec le mode IA

Si Azure OpenAI a été déployé, le badge de l’interface indique que l’IA est active. Vous pouvez créer une surveillance en mode AI, décrire votre condition et fixer le seuil de déclenchement. La valeur par défaut est 70 %.

Sur une page d’inscription publique, une condition utile serait par exemple : « Les inscriptions sont ouvertes et un lien permet de s’inscrire maintenant, pas seulement de consulter la date d’ouverture. » Soyez précis sur ce qui distingue le résultat attendu d’une simple annonce.

Le modèle reçoit la condition et le texte extrait de la page, limité aux 12 000 premiers caractères. Il retourne un score et une explication. L’application utilise son identité managée pour appeler Azure OpenAI dans ce déploiement : vous n’avez pas de clé OpenAI à coller dans le navigateur.

Changez le test pour vérifier le comportement :

L’IA arrive bien à faire la distinction avec ce changement de test :

Et l’email d’alerte arrive bien :

10. Comprendre les captures et le choix de sandbox

Chaque véritable contrôle essaie de prendre une capture, même sans alerte à envoyer. La colonne Last capture donne accès à cette image. Seule la dernière capture de contrôle est conservée par page, dans le stockage persistant. Le Scan dispose de sa propre capture et ne remplace pas celle du dernier contrôle :

Si une capture échoue, l’ancienne image est retirée plutôt que présentée comme récente. La collecte du texte et les alertes peuvent continuer sans image. Consultez les journaux pour distinguer un échec de navigation, un blocage du site et un problème de lancement de Chromium.

La sandbox Chromium est activée par défaut dans le code et dans le Bicep. Sur Azure Container Apps, elle ne peut pas démarrer : le conteneur n’a pas accès aux namespaces utilisateur et Chromium s’arrête avec l’erreur No usable sandbox!. C’est pourquoi le déploiement de la section 5 passe ChromiumSandbox = $false. Il n’existe aucun basculement automatique vers un navigateur sans sandbox.

Si vous avez déployé sans ce paramètre et que les journaux affichent cette erreur, la commande suivante change uniquement cette variable d’environnement et crée une nouvelle révision, sans relancer tout le déploiement :

az containerapp update `
    --resource-group $resourceGroup `
    --name $appName `
    --set-env-vars CHROMIUM_SANDBOX=false `
    --output none

Ce choix ne désactive ni le proxy public uniquement, ni les vérifications TLS, ni l’utilisateur non-root du conteneur. Si vous rejouez plus tard le déploiement complet, l’option PowerShell correspondante est -ChromiumSandbox:$false. Sans cette option, le modèle Bicep réactive la sandbox. Ne réduisez pas l’isolation simplement pour faire disparaître un message d’erreur non diagnostiqué.

11. Les pièges à connaître avant de laisser tourner

Une capture visible n’est pas la preuve que le texte surveillé est complet

Les modes mot-clé et IA lisent le texte de la page rendue par Chromium, après exécution du JavaScript : un texte ajouté dynamiquement, comme les traductions de la page example.com, est donc bien détecté. Si Chromium échoue, l’application se rabat sur le HTML brut de la collecte HTTP, qui peut ne pas contenir ce texte. Le mode changement compare toujours le HTML brut, pour éviter les fausses alertes dues aux éléments dynamiques. Les pages avec authentification, CAPTCHA ou protection anti-bot peuvent également ne pas convenir. Testez votre cible avec le Scan avant de lui faire confiance.

Uniquement des destinations publiques

Les URL privées, locales et de métadonnées cloud sont refusées. Les redirections et les ressources chargées par Chromium passent par un proxy temporaire authentifié qui vérifie les adresses et se connecte à l’adresse IP contrôlée. Ce n’est donc pas un outil pour surveiller votre intranet. Respectez aussi les conditions d’utilisation des sites surveillés et évitez les fréquences agressives.

Une seule réplique pour cette version

La persistance repose sur un fichier JSON et des images dans Azure Files. Le déploiement fixe une réplique minimum et maximum. Ne montez pas simplement le nombre de répliques pour « faire plus robuste » : cette version ne dispose pas d’un ordonnanceur distribué ni d’une coordination multi-instance.

Prévoir une vraie frontière de sécurité

L’interface utilise une authentification Basic sur HTTPS. Cela ne fournit pas, à lui seul, un SSO Entra ID, du MFA ou une gestion multi-utilisateur. Pour une exposition plus large qu’un usage personnel ou de lab, étudiez un contrôle d’accès en amont, des restrictions réseau adaptées et une protection contre les tentatives répétées de connexion.

Les dépendances Python sont verrouillées avec des hachages et l’image s’exécute avec un utilisateur non-root. Des tests couvrent notamment les URL privées, les redirections, le DNS rebinding, la validation TLS et le traitement du mot de passe au déploiement. Ces protections ne constituent pas une certification de sécurité : maintenez aussi l’image de base, les paquets système et Chromium à jour, et réalisez un audit de vulnérabilités avant une exposition sensible.

12. Combien ça coûte ?

Voici une estimation pour un mois complet avec les paramètres par défaut du script : une page ou quelques pages contrôlées toutes les heures, Container Apps en France Central et Azure OpenAI en Sweden Central. Les prix sont les tarifs publics en dollars, relevés en octobre 2026, hors remise et hors taxes.

La facture est dominée par deux postes fixes : la réplique Container Apps qui tourne en permanence et le registre ACR. Les appels IA, le stockage et les emails restent marginaux à cette échelle.

Ce que j’ai réellement payé

Sur mon lab, du 16 au 21 octobre 2026, soit environ 5 jours, Cost Management affiche environ 1,17 € pour le groupe de ressources : 0,72 € pour ACR, 0,30 € pour Container Apps, 0,11 € pour Azure OpenAI, 0,03 € pour le stockage, 0,01 € pour l’email et 0 € pour Log Analytics.

Comment réduire la facture

• Désactivez l’IA si les modes changement et mot-clé suffisent : $deployParameters.DeployOpenAi = $false.
• Choisissez des intervalles raisonnables : chaque contrôle lance Chromium et, en mode IA, un appel au modèle.
• Ne comptez pas sur le scale to zero : le planificateur tourne dans le processus de l’application, la réplique minimum est donc fixée à 1 dans cette version.
• Créez un budget Azure avec une alerte sur le groupe de ressources avant de laisser tourner le lab.
• À la fin du lab, supprimez tout le groupe de ressources : az group delete --name $resourceGroup --yes --no-wait. La ressource Azure OpenAI passe alors en suppression réversible : purgez-la si vous voulez réutiliser le même nom.

Pour votre propre estimation, utilisez la calculatrice de prix Azure et les pages de tarifs de Container Apps, Container Registry et Azure OpenAI. Pour le budget, suivez le tutoriel Créer et gérer des budgets, Microsoft Learn.

13. Conclusion

Voilà, du déploiement PowerShell à la première surveillance, vous avez de quoi automatiser une vérification que vous faisiez jusque-là à la main. Le plus intéressant n’est pas forcément d’ajouter de l’IA partout : un mot-clé bien choisi ou un simple suivi de changement peut déjà répondre au besoin.

Les pièges à retenir : choisir la bonne subscription, distinguer Scan et Check now, surveiller les quotas email et ne pas confondre une capture réussie avec une analyse complète de la page. Pour les captures, le compromis de sandbox doit rester un choix explicite, pas un détail caché.

Foncez tester en lab, avec une page publique et une boîte de réception que vous contrôlez. Validez le parcours complet avant de laisser tourner vos vraies surveillances.

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.