Skip to content
← Retour au blogue

L’architecture de confidentialité de Verity — Une analyse technique approfondie

Par Maxime B.-Forget ·

Il est facile de prétendre protéger la vie privée. Une architecture, elle, est beaucoup plus difficile à truquer. Ce billet décrit exactement comment l’audio circule dans Verity — du microphone jusqu’au texte à votre écran — avec assez de précision pour que vous puissiez évaluer la conception vous-même. Pas de vagues assurances, pas de langage marketing. Seulement le pipeline.

La version courte : votre audio n’est jamais écrit sur disque et n’est jamais utilisé pour l’entraînement — il est transcrit sur une infrastructure que nous exploitons nous-mêmes, n’est jamais confié à un fournisseur tiers d’API d’IA, et il est supprimé immédiatement après la transcription. Pour comprendre pourquoi, lisez la suite.

Le pipeline audio, de bout en bout

Voici le flux complet avant de le passer en revue couche par couche :

Microphone → capture locale → détection d’activité vocale sur l’appareil → encodage audio compressé → transport chiffré → STT de Verity → transcription brute → peaufinage par IA → chiffrement AES-256-GCM → stockage chiffré

L’audio n’existe sous forme d’échantillons bruts non compressés qu’aux trois premières étapes, qui s’exécutent toutes localement sur votre machine. Au moment où quoi que ce soit quitte votre appareil, il s’agit déjà d’un flux binaire compressé sur une connexion chiffrée. Il est ensuite transcrit sur une infrastructure exploitée par Verity — jamais par un fournisseur d’IA tiers — puis supprimé immédiatement.

Étape 1 : capture locale et détection d’activité vocale

La capture audio s’adapte au format d’échantillonnage fourni par votre matériel et le rééchantillonne à 16 kHz fixes avant tout autre traitement, pour que le pipeline se comporte de façon identique d’un microphone à l’autre, aussi différents soient-ils.

Avant de quitter votre machine, l’audio passe par la détection d’activité vocale. Le détecteur évalue chaque court segment — quelques dizaines de millisecondes à la fois — pour déterminer s’il contient de la parole, et tout ce qui est sous le seuil est simplement rejeté. Le silence et le bruit de fond ne sont jamais envoyés nulle part.

Le détecteur d’activité vocale est intégré à Verity et s’exécute comme un binaire local. Aucun appel infonuagique, aucune inférence sur un modèle distant et aucune transmission de données à cette étape — tout se fait sur votre processeur.

Les segments contenant de la parole sont ensuite compressés avec un codec choisi pour son faible débit et sa bonne qualité vocale — assez léger pour garder le transport rapide, assez fidèle pour ne pas nuire à la précision de la reconnaissance.

Étape 2 : transmission à l’orchestrateur

Le flux binaire compressé est envoyé à l’orchestrateur de Verity par une connexion chiffrée TLS. L’audio voyage en binaire brut plutôt qu’en base64 ou dans un autre format d’expansion : rien n’est gonflé pendant le transit.

Avant d’envoyer l’audio, le client transmet un court message de configuration qui précise le mode de transcription, les langues actives et d’éventuels indices de vocabulaire, afin que le serveur puisse acheminer la requête correctement.

L’orchestrateur reçoit le flux binaire et le réassemble côté serveur. C’est à ce moment que l’audio existe pour la première fois hors de votre machine. Il n’est conservé que pendant la durée du traitement — jamais écrit dans un stockage permanent, jamais journalisé, jamais conservé une fois la transcription terminée.

Étape 3 : traitement STT

Verity exécute la reconnaissance vocale sur sa propre infrastructure — des modèles que nous hébergeons, sur des ressources de calcul que nous provisionnons. La couche STT utilise plusieurs profils de modèles avec basculement automatique pour assurer la fiabilité. L’audio n’est pas stocké de façon permanente, n’est pas journalisé et n’est pas utilisé pour l’entraînement de modèles.

Verity prend en charge 20 langues. Les modèles sous-jacents en reconnaissent bien davantage, mais 20 est l’ensemble que nous testons et auquel nous nous engageons; c’est donc ce que nous annonçons. Si votre langue figure sur la liste, elle a été évaluée, et pas seulement acceptée par un modèle qui tentera n’importe quoi.

Les requêtes sont acheminées selon la langue détectée, et la couche d’acheminement bascule d’elle-même : si un chemin commence à produire des erreurs ou à expirer, le trafic passe à un chemin sain sans que votre session s’en aperçoive. Cet état de basculement réside uniquement en mémoire — aucun audio n’est jamais mis en mémoire tampon ni mis de côté pendant qu’un composant se rétablit, car conserver de l’audio pour réessayer briserait la garantie de rétention zéro que toute cette conception vise à respecter.

Une fois la transcription terminée, l’audio est supprimé. Il n’est pas conservé pour une nouvelle tentative, ni gardé pour le débogage, ni archivé.

Étape 4 : peaufinage par LLM

Le texte de la transcription brute (et non l’audio) passe par une étape de peaufinage par LLM. Celle-ci corrige la ponctuation, adapte le registre au persona actif (resserrer la prose pour le mode formel, retirer seulement les mots de remplissage pour le mode minimal, etc.) et nettoie les artefacts de la reconnaissance vocale.

L’étape LLM est une opération texte à texte — elle ne reçoit que le texte de la transcription brute, et non votre audio, les métadonnées de session ou les informations de votre compte. Le modèle de peaufinage s’exécute sur l’infrastructure exploitée par Verity, aux côtés du STT.

Étape 5 : chiffrement et stockage

La transcription peaufinée est chiffrée avant d’atteindre notre base de données. Le chiffrement utilise AES-256-GCM avec une clé propre à chaque utilisateur, dérivée par HKDF-SHA256 à partir d’un matériel de clé maître. Les transcriptions de chaque utilisateur sont chiffrées avec une clé qui lui est unique — nous ne pouvons pas lire vos transcriptions sans votre clé, et la compromission de la clé d’un utilisateur n’affecte aucun autre utilisateur.

Le texte chiffré et un identifiant reliant la transcription à sa session sont écrits dans notre base de données. Le texte en clair n’est jamais journalisé, jamais écrit dans des fichiers temporaires, et n’est pas accessible aux ingénieurs de Verity sans une clé qui n’est pas stockée avec les données.

Ce qui n’est jamais collecté

Pour être explicites sur ce que nous ne faisons pas :

  • Aucun enregistrement audio. Nous ne sauvegardons pas votre audio. Nous n’avons pas d’archive audio. Il n’existe aucun compartiment de stockage d’objets contenant votre voix.
  • Aucune empreinte vocale ni aucun modèle de locuteur. Nous ne construisons pas de modèle de votre façon de parler. Chaque transcription est traitée de façon indépendante, sans mémoire des sessions précédentes.
  • Aucune extraction de données d’entraînement. Votre audio et vos transcriptions ne servent pas à entraîner ni à affiner quelque modèle que ce soit.
  • Aucun profil comportemental tiré de la dictée. Nous n’analysons pas vos habitudes de vocabulaire, la répartition de vos sujets ni votre style d’élocution d’une session à l’autre pour dresser un profil de vos intérêts ou de votre identité.
  • Rétention audio zéro. L’audio est traité sur des serveurs exploités par Verity et supprimé immédiatement après la transcription — jamais stocké, jamais envoyé à un fournisseur d’IA tiers, jamais utilisé pour l’entraînement de modèles.

Traitement transparent et responsabilité

Quand une politique de confidentialité indique « nous pouvons partager des données avec des fournisseurs de services tiers », il est presque impossible d’évaluer le risque réel. Le flou est justement le problème.

Verity répond à cette préoccupation en publiant des détails précis : la reconnaissance vocale et le peaufinage par IA s’exécutent sur une infrastructure que nous provisionnons et contrôlons, l’audio est supprimé immédiatement après la transcription et aucune API d’IA tierce n’intervient dans le processus. Les ressources de calcul sous-jacentes sont louées à AWS — AWS fournit les serveurs, pas le logiciel, et n’accède pas aux données indépendamment de nous. Nous publions exactement comment l’audio circule dans le pipeline et quelle est notre position de rétention à chaque étape. Aucun service externe ne reçoit d’audio ni de transcription.

Architecture de conformité au RGPD

Le pipeline de Verity est conçu en traitant le principe de minimisation des données du RGPD comme une contrainte, et non comme une réflexion après coup. Concrètement :

  • Minimisation des données. L’audio est traité puis supprimé. Les seules données personnelles conservées sont le texte chiffré des transcriptions, soit le minimum nécessaire au fonctionnement du produit.
  • Traitement sans rétention. L’audio est traité sur une infrastructure exploitée par Verity et supprimé immédiatement après la transcription. Garder l’inférence à l’interne élimine complètement la catégorie des sous-traitants d’IA de la surface de risque.
  • Droit à l’effacement. La suppression d’un compte déclenche la suppression de tous les enregistrements de transcriptions chiffrées et du matériel de clé. Après la suppression, il n’existe aucun moyen de récupérer le contenu des transcriptions — le texte chiffré devient orphelin.
  • Résidence des données. Les serveurs de Verity sont situés aux États-Unis. Les transferts depuis l’UE/EEE et le Royaume-Uni reposent sur les clauses contractuelles types de la Commission européenne, et la liste complète des sous-traitants figure dans notre politique de confidentialité. Nous préférons dire clairement où se trouvent vos données aujourd’hui plutôt que de laisser entendre autre chose.

Où les modèles s’exécutent réellement

La reconnaissance vocale et le peaufinage par IA s’exécutent tous deux sur une infrastructure que Verity provisionne et exploite. Les modèles sont des versions à poids ouverts que nous hébergeons nous-mêmes — nous téléchargeons les poids et les servons à partir de nos propres serveurs d’inférence. La distinction est importante : exécuter un modèle publié par un laboratoire, ce n’est pas la même chose qu’appeler l’API de ce laboratoire.

Les ressources de calcul sous-jacentes sont louées à AWS; c’est la façon honnête de le dire — nous ne possédons pas de centres de données. AWS fournit les serveurs, le stockage et le réseau; AWS n’exécute pas les modèles et n’accède pas à vos données indépendamment de nous. C’est une frontière de confiance très différente de celle qui consiste à confier votre audio à un fournisseur d’IA dont le modèle d’affaires dépend des données.

Sur ordinateur, Verity offre aussi un mode de traitement local — la reconnaissance vocale s’exécute entièrement sur votre machine, sans qu’aucun audio ne quitte votre appareil. Ce mode est facultatif et convient surtout aux utilisateurs qui ont besoin d’un fonctionnement entièrement hors ligne ou qui ont des exigences strictes en matière de résidence des données.

L’évaluer par vous-même

Nous encourageons l’examen minutieux. La page des fonctionnalités de confidentialité détaille nos pratiques en matière de données. La politique de confidentialité est rédigée en langage clair, et non dans un jargon juridique conçu pour brouiller les cartes. Et notre page de confiance décrit l’architecture technique plus en détail.

Si vous êtes ingénieur en sécurité et évaluez Verity pour un environnement réglementé, nous répondrons avec plaisir à vos questions sur notre programme de sécurité ou discuterons de vos exigences de conformité précises. Publier ce niveau de détail sert justement à ouvrir cette conversation, pas à l’éviter. Pour un point de vue propre à chaque plateforme, voyez comment cela se compare à la dictée intégrée sur iPhone et Windows.

Voyez-le en action

La dictée axée sur la confidentialité — essayez-la gratuitement

Télécharger Verity
← Retour au blogue

Commencez à dicter gratuitement.

Traitement sans rétention. Aucune carte de crédit requise. Annulable en tout temps.

Télécharger gratuitement
L’architecture de confidentialité de Verity — Une analyse technique approfondie — Blogue Verity