Pourquoi l’Europe.

Une avocate belge ouvre son ordinateur un mardi matin, appuie sur un raccourci et dicte une note sur l’acquisition en cours d’un client. Elle maintient le bouton, parle quarante secondes, relâche. Le texte soigné se pose dans son brouillon d’e-mail. Elle l’envoie.

Elle vient d’exporter des données client confidentielles vers une juridiction étrangère. Elle ne le savait pas. Son cabinet ne l’a pas autorisé. Son ordre des avocats ne l’a pas approuvé. L’outil de dictée qu’elle a utilisé ne l’a pas avertie, parce que de son point de vue, rien ne s’est mal passé.

Voilà le réglage par défaut tu du logiciel d’IA moderne. L’audio est passé par une société constituée aux États-Unis, a été traité sur des infrastructures opérées aux États-Unis, et tombe désormais sous le droit américain. L’intention de l’avocate n’y change rien. La politique de conformité de son cabinet non plus. L’emplacement physique du serveur non plus. Dès que sa voix entre dans le pipeline d’un fournisseur américain, la posture juridique des données de son client a changé.

La plupart de ceux qui construisent ces outils, et la plupart de ceux qui les utilisent, trouvent ce fait suffisamment inconfortable pour préférer ne pas le regarder en face. Alors personne ne le marque. Alors il reste le défaut.

Il existe une loi américaine de 2018 appelée Clarifying Lawful Overseas Use of Data Act, généralement abrégée en CLOUD Act. Elle fait une chose que les utilisateurs européens devraient connaître : elle oblige les sociétés constituées aux États-Unis à remettre des données aux autorités américaines sur réquisition valable, quel que soit l’endroit où ces données sont physiquement stockées.

Relisez cette phrase. Le serveur peut être à Francfort. L’entreprise peut avoir une filiale néerlandaise, un DPO français, un bureau commercial belge. Rien de tout cela ne compte. Si la maison mère est immatriculée au Delaware, les données sont accessibles à l’autorité américaine. Le CLOUD Act inclut aussi des dispositions qui peuvent empêcher le fournisseur d’informer le client que la requête a été faite.

En 2020, la Cour de justice de l’Union européenne a jugé, dans l’affaire usuellement appelée Schrems II, que les transferts de données UE-US sous l’ancien cadre Privacy Shield n’étaient pas adéquats. Le raisonnement de la Cour reposait, en partie, sur le fait que les utilisateurs européens n’avaient aucun recours juridique effectif contre les pouvoirs de surveillance américains. La Cour n’a pas inventé cette préoccupation. Elle a décrit une réalité structurelle que le CLOUD Act avait déjà confirmée dans la loi deux ans plus tôt.

Le RGPD ajoute sa propre pression. L’article 32 impose à tout responsable du traitement d’assurer la sécurité du traitement, y compris contre la divulgation non autorisée. Si vous êtes responsable du traitement et que votre sous-traitant est constitué aux États-Unis, vous avez sur les bras une question qu’aucune conditions générales d’utilisation ne peut pleinement résoudre.

On peut débattre de la gravité de tel ou tel cas. On ne peut pas débattre de l’architecture. La dictée routée par les États-Unis n’est pas un problème de politique qu’un meilleur contrat peut résoudre. C’est un problème juridictionnel qui exige que les données ne franchissent jamais la frontière au départ.

Je code pour vivre et je dicte tout ce que j’écris. Pendant la majeure partie de l’année dernière, j’ai utilisé Wispr Flow. Ça fonctionne très bien. L’équipe derrière est talentueuse et le produit est réellement bon.

Puis un soir, j’ai lu la partie de leur documentation qui explique où l’audio va vraiment. Je l’ai relue. J’ai refermé l’ordinateur. Je suis resté un moment sur le balcon.

Le chemin des données était exactement ce que j’aurais dû anticiper : une société constituée aux États-Unis, un traitement chez un fournisseur de modèles hébergé aux États-Unis, des décisions audio prises par des ingénieurs américains sous droit américain. Rien à reprocher à l’ingénierie. Rien à reprocher à l’équipe. Mais quelque chose n’allait pas dans les défauts, et ces défauts s’appliquaient à moi, et ils s’appliquaient à chaque consultant belge, néerlandais et allemand à qui j’avais déjà transmis le lien.

Je dictais mes e-mails clients là-dedans depuis des mois. Eux aussi.

Je l’ai reconstruit.

Olinra tourne sur des modèles Mistral hébergés en UE. L’API est un serveur Fastify dans un datacentre Hetzner à Nuremberg. L’authentification, c’est Supabase à Francfort. Les octets audio sont envoyés en streaming dans le corps de la requête Voxtral et jetés dès l’arrivée de la réponse. Il n’y a pas de bucket S3, pas de cache chaud, pas de transcript qui vit sur un disque ailleurs que sur votre machine. L’architecture, c’est la marque, et la marque, c’est l’architecture.

Si jamais l’un de ces points cesse d’être vrai, la marque est terminée. Je suis sérieux à ce point.

Olinra, c’est la réponse d’une seule entreprise pour une seule catégorie de produit. La dictée est une surface étroite. Le but de cette page n’est pas d’argumenter que les utilisateurs européens devraient changer d’outil de dictée. Le but, c’est d’argumenter que les utilisateurs européens devraient cesser de traiter le routage par défaut vers les États-Unis comme inévitable, dans chaque catégorie de produit qu’ils touchent.

L’industrie logicielle européenne, pour l’essentiel, n’a pas construit autour de cette hypothèse. L’industrie logicielle américaine, pour des raisons compréhensibles, n’a pas construit autour de cette hypothèse non plus. Alors il faut bien que quelqu’un commence, et le point de départ, ce sont de petits produits utiles qui prennent position et prouvent que la position peut se tenir.

Olinra, c’est le mien. Il y en aura d’autres. Exigez-les des logiciels que vous utilisez.