Faire valider un logiciel de dictée par la DSI

Si la DSI de votre entreprise (le service informatique) a bloqué Otter.ai, Fireflies.ai ou Read AI, vous n'imaginez pas une réaction excessive. Plusieurs universités et au moins un service technologique d'État, aux États-Unis, ont publié des politiques quasi identiques au cours de la dernière année, et un recours collectif fédéral contre Otter.ai teste désormais, devant un tribunal américain, si cette prudence était justifiée. La raison n'est pas la qualité de transcription. C'est que la transcription est la partie facile — ce qui arrive à l'enregistrement une fois qu'il a quitté votre microphone, voilà ce qu'une revue de sécurité ne peut pas valider les yeux fermés. Un outil de dictée cloud ou de prise de notes de réunion envoie l'audio vers les serveurs d'un éditeur, puis de là vers les sous-traitants que cet éditeur utilise pour faire tourner ses modèles : une chaîne de traçabilité qui doit être cartographiée, contractualisée et auditée avant que quiconque, dans une organisation régulée ou soucieuse de sécurité, puisse l'approuver.

Le type d'outil qui passe cette revue le plus vite est celui qui n'a rien à faire examiner dans ce flux de données : un logiciel qui traite l'audio entièrement sur l'appareil où il a été prononcé, sans rien envoyer nulle part. C'est une affirmation plus étroite que « passe la DSI » — mais c'est celle qui tient réellement la route, et il vaut la peine de comprendre précisément ce qu'elle retire, et ne retire pas, de la checklist ci-dessous.

En bref : la revue DSI d'un logiciel de dictée pose surtout cinq questions — où va l'audio, qui d'autre y touche, combien de temps il est conservé, quel compte l'outil exige, et à quoi il accède une fois installé. Le traitement local répond aux trois premières en retirant complètement l'éditeur de ce chemin. Il ne répond pas aux deux dernières à lui seul — le logiciel lui-même a toujours besoin d'être passé en revue.

Précision pour un lecteur français : les universités et le procès cités plus bas sont américains — les politiques mentionnées (Microsoft Teams Premium, Zoom AI Companion, un recours collectif fédéral) sont propres au système américain. Le raisonnement sur le flux de données et la revue de sécurité reste transposable en France, où le service qui mène cette revue s'appelle la DSI ; et si vous cherchez le cadre réglementaire propre à une entreprise française plutôt qu'une revue interne, notre article sur dictée vocale et RGPD couvre le volet légal.

Des universités américaines bannissent déjà Otter.ai et Fireflies.ai — officiellement

Le cas le plus clairement documenté est celui de l'Office of Artificial Intelligence de l'University of Utah, aux États-Unis, qui a publié un guide intitulé « Using Meeting Transcription and Summarization Tools? Be Sure to Choose Approved Software. » (utilisez-vous des outils de transcription et de résumé de réunion ? assurez-vous de choisir un logiciel approuvé). Le document cite des noms : il désigne directement Otter.ai et Fireflies.ai comme exemples d'outils non approuvés et oriente le personnel vers Microsoft Teams Premium et Zoom AI Companion à la place, en invoquant « significant risks related to data privacy, compliance, and institutional liability » (des risques importants liés à la confidentialité des données, à la conformité et à la responsabilité institutionnelle). Le guide s'articule en trois sections — les principales préoccupations liées aux outils non approuvés, les avantages des alternatives approuvées par l'université, et les actions recommandées pour le personnel — une structure qui devient un modèle dans tout l'enseignement supérieur américain.

Utah n'est pas un cas isolé, et le phénomène est assez récent pour se lire comme une tendance plutôt que la préférence d'un seul établissement :

Chapman University (États-Unis) : son département IS&T a publié un avis de sécurité en août 2025 déclarant que « the use of Read AI is prohibited due to security, privacy, and institutional data risks » (l'usage de Read AI est interdit en raison de risques de sécurité, de confidentialité et de risques pour les données institutionnelles), après des signalements de l'outil rejoignant et enregistrant des réunions sans y être invité. L'université recommande Zoom AI Companion à la place, avec le consentement de tous les participants à l'appel.
The University of Washington (États-Unis) a désactivé Read AI à l'échelle de l'établissement, en déclarant que l'outil « is associated with security and privacy risks to institutional data » (est associé à des risques de sécurité et de confidentialité pour les données institutionnelles) et qu'il peut rejoindre, transcrire et résumer des réunions « without the awareness or consent of other attendees » (à l'insu des autres participants et sans leur consentement).
Mississippi State University (États-Unis) a bloqué Read.ai et Otter.ai dans Microsoft Teams, en précisant explicitement que la décision faisait suite à des « engaging with several other higher education institutions » (échanges avec plusieurs autres établissements d'enseignement supérieur) — présentée comme une conclusion partagée, pas comme une décision isolée.

L'exposition juridique n'a rien d'hypothétique non plus. En août 2025, Otter.ai a été visé par un recours collectif fédéral aux États-Unis — Brewer v. Otter.ai, déposé devant le tribunal fédéral du district nord de Californie (affaire 5:25-cv-06911) — rapporté par NPR, qui allègue que le Notetaker d'Otter a enregistré des conversations privées de personnes qui n'étaient même pas utilisatrices d'Otter, et a utilisé ces enregistrements pour entraîner ses modèles de transcription sans leur consentement. C'est précisément le scénario que les DSI et les équipes juridiques essaient d'anticiper en rédigeant des politiques comme celle d'Utah avant un incident, pas après.

Que vérifie vraiment la DSI avant d'approuver un logiciel de dictée ?

Que la demande atterrisse dans une université, un hôpital ou une PME, la revue passe généralement par la même poignée de questions, à peu près dans cet ordre :

Flux de données sortant. Où va l'audio dès que vous arrêtez de parler — directement vers les serveurs d'un éditeur, bufferisé en local d'abord, ou nulle part du tout ?
Sous-traitants et DPA. Chaque saut supplémentaire que fait l'audio (le moteur de reconnaissance vocale, l'hébergeur cloud, tout LLM utilisé pour nettoyer ou résumer la transcription) est un éditeur distinct qui a besoin de son propre Data Processing Agreement. Un seul sous-traitant non vérifié suffit à bloquer l'approbation.
Rétention. L'audio est-il supprimé juste après la transcription, ou stocké — et si stocké, pendant combien de temps, par qui, et peut-il être réutilisé pour entraîner des modèles ? Cette dernière clause est exactement celle en litige dans le procès Otter.ai.
Comptes et SSO. L'outil exige-t-il un compte personnel en dehors du fournisseur d'identité de l'organisation ? Un outil qui ne demande aucune connexion, ou qui fédère via le SSO existant, représente un risque de gestion d'identité plus faible qu'un outil qui fait tourner sa propre base d'utilisateurs séparée.
Surface d'attaque. À quoi l'outil accède-t-il une fois installé — agenda, microphone, écran, données des autres participants ? La capacité de Read AI à rejoindre automatiquement des réunions via l'intégration à l'agenda est exactement ce qui a déclenché les avis de Chapman et de l'UW cités plus haut.

Aucune de ces questions ne porte sur la qualité de la transcription. Elles portent sur ce qu'un éditeur peut voir, garder et réutiliser — ce qui est précisément ce qui change dès qu'il n'y a plus d'éditeur dans la boucle pour cette étape.

Un traitement local signifie-t-il qu'un outil passe automatiquement la revue DSI ?

Non — et il vaut mieux être précis sur ce qui change et ce qui ne change pas, plutôt que de survendre la chose.

Ce qui change : si l'audio et la transcription ne quittent jamais l'appareil, les questions une à trois ci-dessus s'effondrent. Il n'y a pas de flux sortant à cartographier, pas de sous-traitant auprès duquel réclamer un DPA, pas de politique de rétention côté serveur à interroger — parce qu'il n'y a pas de serveur sur ce chemin. C'est un fait architectural, pas un certificat de conformité, et c'est exactement le même raisonnement qui explique pourquoi Inkvox ne revendique pas non plus d'être conforme à HIPAA : le traitement local retire un maillon de la chaîne qu'un examinateur doit vérifier, pas toute la revue. Voir le détail complet sur notre page confidentialité.

Ce qui ne change pas : la DSI doit toujours évaluer le logiciel lui-même — d'où vient l'installeur, s'il est signé numériquement (code-signed), comment les mises à jour sont livrées et vérifiées, et à quelles permissions au niveau du système d'exploitation il demande accès à l'installation. Une app locale venant d'un éditeur peu connu reste un nouveau logiciel qui tourne avec un accès système, et une revue sérieuse le traite comme tel. Les questions quatre et cinq ci-dessus (comptes, surface d'attaque) ne disparaissent pas simplement parce que l'audio reste sur place : un outil local qui « téléphone à la maison » pour des vérifications de licence, ou qui demande des permissions étendues sans rapport avec la dictée, réintroduit exactement le type de surface qu'un examinateur cherche à écarter.

La version honnête n'est donc pas « le logiciel local passe la revue DSI ». C'est plutôt : le traitement local retire la partie la plus difficile de la revue — le flux de données — et laisse un ensemble plus restreint et plus facile à documenter de questions sur le logiciel lui-même.

Une checklist pour faire approuver un logiciel de dictée local

Si c'est vous qui essayez de faire approuver un outil — ou qui rédigez la politique qui en décidera —, voici à peu près la documentation à avoir prête avant de faire la demande :

Faites confirmer l'architecture par écrit, pas par un discours marketing. Demandez comment l'audio est traité, pas seulement où il prétend rester.
Demandez ce qui « téléphone à la maison », tout court. Vérifications de licence, rapports de plantage, télémétrie — et si tout cela peut être désactivé, ou l'est par défaut.
Obtenez la provenance du modèle. Quel modèle de reconnaissance vocale, les poids de qui, téléchargés d'où — et si ce téléchargement est vérifiable (somme de contrôle, release signée).
Vérifiez le mécanisme de mise à jour. Mise à jour automatique depuis un domaine connu en HTTPS, ou installeur manuel uniquement ?
Confirmez les exigences de compte. A-t-il seulement besoin d'une connexion — et si oui, s'intègre-t-il au SSO existant ou crée-t-il un nouveau silo d'identité ? Un outil qui se passe entièrement de compte élimine carrément cette question ; voyez comment cela se joue avec un logiciel de dictée qui ne demande aucun compte.
Demandez un schéma de flux de données. Même une seule page suffit. Les examinateurs avancent plus vite avec quelque chose à valider qu'avec une simple promesse.

Questions fréquentes

Pourquoi les universités bannissent-elles spécifiquement Otter.ai et Fireflies.ai ?

Parce que leur fonction principale — rejoindre les réunions, enregistrer, puis traiter cet audio sur les serveurs de l'éditeur — crée exactement le type de revue que les DSI cherchent à éviter : un flux sortant permanent de conversations potentiellement sensibles vers un tiers. Le guide de l'University of Utah (États-Unis) présente lui-même cela comme un risque de confidentialité des données, de conformité et de responsabilité institutionnelle, pas comme une critique de la qualité de transcription. Otter.ai fait par ailleurs actuellement l'objet d'un recours collectif fédéral (Brewer v. Otter.ai) qui allègue que l'outil a enregistré des conversations sans consentement et les a utilisées pour entraîner ses modèles.

Un outil de dictée local a-t-il quand même besoin d'une validation de la DSI ?

Dans la plupart des organisations, oui — un logiciel installé sur un poste géré passe généralement par une forme de revue, même plus légère que pour un SaaS cloud. Ce qui change, c'est ce que cette revue doit couvrir : pour un outil local, elle porte surtout sur le logiciel lui-même (signature du code, permissions, mécanisme de mise à jour), pas sur l'audit des pratiques de traitement des données d'un éditeur, de ses sous-traitants et de sa politique de rétention.

Inkvox est-il conforme à HIPAA ou certifié SOC 2 ?

Non — Inkvox ne revendique aucune des deux certifications. C'est un produit en bêta privée conçu pour que la transcription ne quitte jamais votre appareil, ce qui retire la question du flux de données d'une revue DSI, mais ne remplace ni le programme de conformité propre à une organisation, ni son analyse de risque, ni le reste de sa pile logicielle.

Si votre équipe a déjà essayé de faire passer Otter.ai ou un outil similaire en revue et s'est heurtée à un mur, la solution n'est généralement pas un meilleur questionnaire fournisseur — c'est un outil qui n'en a pas besoin pour la partie qui compte le plus. Inkvox fait tourner Whisper large-v3-turbo, quantisé, entièrement sur votre propre GPU via Vulkan — NVIDIA, AMD ou Intel, avec un repli sur CPU —, transcrit une phrase en environ 0,3 à 0,4 seconde sur une carte comme une RTX 3070, et n'envoie jamais l'audio : 0 octet, aucun compte requis. Il est actuellement en bêta privée. Rejoignez la liste d'attente et apportez à votre DSI l'architecture plutôt qu'une promesse.