UK Online Safety Act : pourquoi le local est exempté
Regarder le résumé vidéo
Ofcom a condamné le mois dernier un service de partage de fichiers à 20 000 livres sterling pour ne pas avoir répondu à ses demandes d’information. Deux autres services, 1Fichier et Gofile, ont été contraints d’implémenter le perceptual hash matching dans leurs pipelines de téléversement. De nouvelles réglementations sont entrées en vigueur le 8 janvier 2026, et des orientations sur les technologies agréées arrivent ce printemps.
Si vous gérez une plateforme qui reçoit des téléversements de fichiers, vous avez désormais une obligation de conformité au Royaume-Uni. Vous devez évaluer votre risque, déployer une infrastructure de scan et répondre aux demandes du régulateur, sous peine d’amendes journalières.
VaultTools n’a aucune de ces contraintes. Voici pourquoi.
Ce que le Online Safety Act exige réellement
Les codes de bonnes pratiques du UK Online Safety Act sur les contenus illégaux ciblent les plateformes qui reçoivent des fichiers d’utilisateurs sur leur propre infrastructure. Le déclencheur légal est la réception côté serveur. Un service est dans le champ d’application s’il stocke des fichiers, les rend accessibles à d’autres, ou facilite le partage entre utilisateurs.
Pour les plateformes de partage de fichiers à haut risque, Ofcom recommande le perceptual hash matching : une technique qui génère des empreintes cryptographiques du contenu téléversé et les compare à des bases de données de matériaux illégaux connus. Certaines plateformes l’ont implémenté volontairement. D’autres se l’ont vu imposer. Une a refusé de coopérer et a été sanctionnée.
La pile de conformité est réelle. Il faut :
- Une évaluation du risque lié aux contenus illégaux
- Un système de scan répondant aux standards techniques d’Ofcom
- Un processus de réponse aux demandes d’information légales dans les délais impartis
- Une surveillance et un reporting continus
Cela représente du temps d’ingénierie, une révision juridique, des coûts d’outils tiers et une couche d’infrastructure qui touche chaque fichier téléversé par un utilisateur.
Pourquoi rien de tout cela ne s’applique à VaultTools
VaultTools ne reçoit jamais de fichiers. Quand vous déposez un PDF dans l’outil de fusion, votre navigateur charge le module Wasm depuis notre CDN et l’exécute localement. Les octets de votre fichier vont de votre disque dans la mémoire du navigateur, passent par la fonction Rust compilée en WebAssembly, et reviennent sous forme de téléchargement. Rien ne quitte votre machine.
Nos serveurs servent des ressources statiques : HTML, CSS, JavaScript et fichiers .wasm compilés. Ils n’acceptent pas de téléversements de fichiers. Il n’existe aucun endpoint POST qui reçoit un PDF. Il n’existe aucun bucket S3 stockant vos images. Il n’existe aucune file de traitement gérant vos documents.
L’obligation de scan du Online Safety Act ne peut pas s’attacher à un serveur qui ne voit jamais un fichier. Ofcom ne peut pas nous contraindre à scanner des téléversements que nous ne recevons pas. Il n’y a pas de stockage côté serveur à auditer, parce qu’il n’y a pas de stockage côté serveur.
Ce n’est pas une promesse dans une déclaration de confidentialité. Ce n’est pas une affirmation dans des conditions d’utilisation. C’est un fait architectural que vous pouvez vérifier en ouvrant l’onglet réseau de votre navigateur lorsque vous utilisez n’importe quel outil du site. Vous verrez des requêtes pour des fichiers .wasm et des ressources de page. Vous ne verrez pas votre fichier quitter votre appareil.
L’architecture qui crée cette propriété
Le cœur de chaque outil est une fonction Rust compilée en WebAssembly avec wasm-pack. Par exemple, l’outil de fusion PDF appelle pdf-tools, l’un des cinq crates Rust de la base de code :
// crates/pdf-tools/src/merge.rs (simplifié)
pub fn merge_pdfs(documents: &[Vec<u8>]) -> Result<Vec<u8>, String> {
let mut output = Document::new();
for bytes in documents {
let doc = Document::load_mem(bytes)?;
// fusionner les pages dans output...
}
Ok(output.save_to_bytes()?)
}Cette fonction prend des octets en entrée et retourne des octets. Elle n’a pas accès au réseau. Le bac à sable Wasm l’impose au niveau du moteur d’exécution : un module Wasm ne peut pas ouvrir de socket, ne peut pas écrire dans le système de fichiers, ne peut pas effectuer de requêtes HTTP, sauf si l’hôte lui en fournit explicitement la capacité. Nous ne le faisons pas.
Le JavaScript de la page charge le module Wasm, lui passe les octets de votre fichier, reçoit le résultat et déclenche un téléchargement. L’aller-retour est entièrement local.
La pression réglementaire favorise désormais le traitement local
L’amende infligée à Im.ge compte au-delà des 20 000 livres. Elle a établi que le refus procédural de coopérer (simplement ne pas s’engager avec Ofcom) constitue en soi une infraction sanctionnable. Les plateformes ne peuvent pas ignorer le régulateur. Le taux journalier de 100 livres qui s’ensuit n’est pas menaçant isolément, mais la posture d’application croissante, elle, l’est.
Les orientations du printemps 2026 définiront quelles technologies de scan satisfont à la loi. Une fois publiées, toute plateforme de téléversement de fichiers desservant des utilisateurs britanniques aura un socle technique clairement défini à respecter ou des mesures d’application à affronter. Ce socle coûte de l’argent à mettre en œuvre et à maintenir.
La même tendance réglementaire est visible dans d’autres juridictions. Le Digital Services Act de l’UE a des obligations qui se chevauchent pour les grandes plateformes. La Suède débat d’exigences de surveillance pour les services de messagerie. Plusieurs États américains ont adopté des lois touchant la modération des contenus sur les plateformes. La surface de conformité pour les outils de fichiers basés sur des serveurs ne fait que s’étendre.
Le traitement local ne protège pas seulement la vie privée des utilisateurs. Il retire l’opérateur entièrement du périmètre de conformité. Il n’y a pas de pipeline de téléversement à réguler. Il n’y a pas de contenu à scanner. Il n’y a pas de données à conserver ou à déclarer. L’architecture répond à la réglementation avant même qu’elle ne soit écrite.
Ce que cela signifie en pratique
Si vous utilisez VaultTools pour traiter des documents sensibles, la garantie que vous voulez réellement n’est pas notre parole que nous supprimons les fichiers après une heure. C’est l’impossibilité structurelle pour nous d’avoir vos fichiers en premier lieu.
Pour les avocats traitant des contrats clients, les comptables gérant des documents fiscaux, les designers travaillant sur des ressources de marque non publiées, ou quiconque fait passer des documents dans un outil avant de les partager, la bonne question à poser n’est pas : “Quelle est la politique de conservation de cette plateforme ?” C’est : “Cette plateforme reçoit-elle seulement mon fichier ?”
Chez VaultTools, la réponse est non. Et cette réponse ne change pas, quelles que soient les lois adoptées, les régulateurs impliqués ou ce qui arrive à l’entreprise.
Essayez avec l’onglet réseau ouvert. Déposez un fichier dans n’importe quel outil. Regardez les requêtes. Votre fichier ne quitte jamais l’appareil.