Questionnaire de sécurité pour un outil audio : les questions à poser, et nos réponses, y compris les non

Un outil qui met vos articles en audio n'est pas un simple widget. Il reçoit vos textes avant publication, il dépose un script sur vos pages, il détient une clé qui lui permet d'agir au nom de votre compte, et il va parfois chercher lui-même des adresses que vous lui donnez. Pour un responsable de la sécurité, un délégué à la protection des données ou un service achats, ce sont quatre portes à examiner avant de signer.

La question des données (où part le texte, chez qui, combien de temps) a déjà son article : le trajet exact d'un texte envoyé à un outil vocal. Celui-ci traite l'autre moitié du questionnaire : les accès, les clés, ce que l'outil peut faire de travers, et ce qu'il ne sait pas encore vous montrer. Pour chaque question, notre réponse, telle qu'elle est écrite dans le code et sur notre page sécurité.

1. Qui voit la clé, et que se passe-t-il si elle fuit ?

C'est la première question à poser, parce que c'est la plus fréquente source d'incident réel : une clé collée dans un courriel, un ticket, un fil de discussion, puis oubliée là.

Notre réponse tient en trois points. Le module WordPress n'affiche jamais la clé : il échange un code valable deux minutes, à usage unique, contre sa propre clé, de serveur à serveur. Personne dans l'équipe n'a donc l'occasion de la recopier. Chaque site a ensuite sa clé à lui, rattachée à lui : révoquer celle d'une préproduction n'interrompt pas la production. Enfin, les clés sont stockées hachées. Nous ne pouvons pas vous les relire, seulement les remplacer, et la révocation se fait depuis l'espace client, sans passer par le support.

Si l'installation elle-même est votre sujet, la page module WordPress détaille ce que le module écrit sur votre site et ce qu'il ne touche pas.

2. Le site doit-il être joignable de l'extérieur ?

Beaucoup d'outils demandent d'ouvrir une porte : un rappel entrant, une adresse que leur serveur viendra interroger. C'est une exception de pare-feu de plus à justifier.

Avec l'extension WordPress ou l'API, la connexion part de votre serveur vers le nôtre, jamais l'inverse. Une préproduction fermée ou un intranet fonctionnent donc sans aucune ouverture. La découverte par flux RSS fait évidemment le chemin contraire, puisqu'elle lit un flux public : c'est le seul mode qui suppose un site joignable. Autre exception, si vous la demandez : la notification « audio prêt », envoyée vers une adresse que vous choisissez, et signée pour que votre serveur puisse vérifier qu'elle vient bien de nous (le détail de la signature).

3. L'outil va-t-il chercher des adresses fournies par un utilisateur ?

C'est la question que les questionnaires oublient, et elle est sérieuse. Dès qu'un service accepte une adresse web (un article à estimer, un flux à suivre, un jingle, une adresse de notification), il devient capable d'aller la chercher depuis ses propres serveurs. Mal gardé, il peut être promené vers des adresses internes qu'aucun utilisateur ne devrait atteindre.

Notre réponse : toute adresse fournie par un client doit être en https, les adresses locales et privées sont refusées, et un nom qui se résout vers une de ces familles l'est aussi. Le point qui compte le plus est le suivant : les redirections ne sont plus suivies aveuglément. Chaque saut est revalidé par le même filtre, avec un nombre de sauts plafonné. Ce durcissement date d'août 2026, après qu'un contournement par simple redirection a été trouvé chez nous. Nous le disons parce qu'un fournisseur qui affirme n'avoir jamais eu de faille n'a souvent simplement jamais cherché.

4. Qui, dans l'équipe, peut faire quoi ?

Trois rôles : propriétaire, administrateur, membre. Un secrétaire de rédaction n'a pas besoin de voir la facturation, et le refus est appliqué par le serveur, pas seulement masqué à l'écran. Un rôle masqué sans contrôle côté serveur se contourne avec un simple appel direct : c'est la question de suivi à poser à tout fournisseur qui vous montre un écran de rôles. Le fonctionnement par rôle est décrit dans l'article sur le travail en équipe.

5. Que dépose le lecteur chez vos lecteurs ?

Aucun cookie, aucun identifiant d'auditeur, aucune empreinte de navigateur. Deux valeurs sont tout de même écrites dans le navigateur de l'auditeur, et il faut les nommer : sa position de lecture (pour reprendre où il s'était arrêté) et ses réglages d'accessibilité. Aucune des deux ne nous est transmise. L'adresse IP sert une minute, en mémoire vive, à limiter le débit pour qu'on ne puisse pas gonfler un compteur d'écoutes, puis disparaît sans avoir touché la base.

6. Ce que nous n'avons pas, dit avant qu'on nous le demande

Un questionnaire de sécurité honnête se juge autant à ses non qu'à ses oui. Voici les nôtres.

• Pas de certification ISO 27001. Si votre service achats l'exige comme condition d'entrée, nous ne passerons pas la grille. Nous répondons en revanche par écrit à un questionnaire aussi détaillé que nécessaire, et acceptons les clauses contractuelles correspondantes.
• Pas de journal des accès visible par le client. Nous journalisons nos propres actions d'administration, mais vous ne pouvez pas consulter vos connexions ni les gestes de vos équipes depuis l'espace client. Sur un compte partagé par une rédaction, c'est un manque réel.
• Pas d'engagement de disponibilité assorti de pénalités dans l'abonnement en ligne, et pas de taux de disponibilité publié, faute d'une sonde externe historisée pour le mesurer. La page statut dit ce qui est réellement interrogé et tient un registre daté des incidents. Un engagement de service se négocie dans un contrat sur devis.
• Pas de programme de récompense pour la recherche de vulnérabilités, ni de page de divulgation coordonnée. Un signalement de sécurité envoyé directement passe devant le reste.
• Pas de chaîne européenne de bout en bout. Le stockage et la préparation du texte sont européens, la synthèse vocale ne l'est pas encore. Tant que ce maillon manque, l'option correspondante reste grisée dans l'espace client : c'est le code qui en décide, pas une page commerciale.
• Pas d'hébergement des fichiers audio sur votre propre infrastructure. Cette option a été annoncée sur notre site, elle n'existait pas, et la mention a été retirée en août 2026.

Comment se servir de cette grille

Ces six questions valent pour n'importe quel fournisseur, nous compris. Posez-les par écrit, et regardez moins la réponse que sa précision : « nous prenons la sécurité très au sérieux » ne répond à aucune d'elles, alors que « le code expire en deux minutes et ne sert qu'une fois » se vérifie. Si vous préparez un marché public, ces points se rangent naturellement dans un cahier des charges de synthèse vocale, à côté de l'accessibilité du lecteur et de la réversibilité.

Un dernier conseil : demandez au fournisseur la dernière faille qu'il a corrigée, et quand. Une réponse précise et datée vaut mieux qu'une page de certifications, parce qu'elle prouve qu'on cherche.

À lire aussi

• Noms bretons, basques, corses, alsaciens : pourquoi la synthèse vocale les écorche, et comment on les corrige
• Voix de femme ou d'homme pour une citation : ce que la phrase française dit de qui parle
• Certificat de provenance : prouver ce qui a fabriqué la version audio d'un article