Comment j'ai construit un outil vidéo axé sur la confidentialité en tant que développeur solo

Fin 2023, j'avais besoin de retirer l'audio d'un enregistrement d'écran avant de l'envoyer à un client. L'enregistrement avait capté ma partie d'un appel téléphonique qui se déroulait en arrière-plan, et je devais le supprimer avant que la vidéo ne puisse être partagée.

J'ai cherché une solution rapide et j'ai trouvé des dizaines de sites qui promettaient de supprimer l'audio d'une vidéo. Tous voulaient que j'envoie mon fichier sur leur serveur. Un fichier contenant l'audio d'une conversation téléphonique privée. Vers un serveur inconnu. Géré par une entreprise inconnue. Avec une politique de rétention des données inconnue.

J'ai fermé tous les onglets et j'ai ouvert mon terminal à la place. Une commande FFmpeg plus tard, l'audio avait disparu. Mais l'expérience m'est restée. Tout le monde ne connaît pas FFmpeg. Tout le monde ne l'a pas installé. Et le fait que la solution évidente pour la plupart des gens consistait à envoyer du contenu potentiellement sensible vers des serveurs aléatoires me dérangeait profondément en tant que développeur soucieux de la confidentialité.

"

"Le moment où j'ai compris que la solution 'facile' pour la plupart des gens consistait à envoyer un audio privé vers les serveurs d'inconnus, j'ai su qu'il fallait construire quelque chose de meilleur."

La question technique centrale était simple : pouvais-je faire tourner FFmpeg dans un navigateur ? Si la réponse était oui, alors tout le modèle basé sur l'upload vers un serveur devenait inutile. Les utilisateurs pourraient traiter leurs vidéos localement, et leurs fichiers ne quitteraient jamais leur appareil.

La réponse s'est révélée être oui, grâce à FFmpeg.wasm. C'est un portage WebAssembly de FFmpeg, le même framework multimédia qui alimente pratiquement tous les outils vidéo professionnels existants. Quelqu'un avait accompli l'incroyable travail de compiler cet outil écrit en C pour le faire fonctionner dans le bac à sable d'un navigateur.

La première fois que j'ai réussi à faire tourner FFmpeg.wasm dans un prototype, j'ai regardé l'outil supprimer une piste audio d'un fichier vidéo entièrement dans un onglet de navigateur. Aucune requête réseau. Aucun serveur. Le fichier passait du disque de l'utilisateur à la mémoire du navigateur, était traité par WebAssembly, puis ressortait sous forme de téléchargement. Je me souviens avoir pensé : c'est ainsi que tous les outils vidéo en ligne devraient fonctionner.

Faire fonctionner FFmpeg.wasm dans une démo, c'est une chose. Le faire fonctionner de manière fiable sur tous les navigateurs, appareils et formats de fichier que les gens lui envoient, c'en est une autre. Voici les problèmes qui ont englouti l'essentiel de mon temps de développement.

La gestion mémoire a été le plus gros défi. Les navigateurs allouent une mémoire limitée à chaque onglet, et les navigateurs mobiles sont particulièrement contraints. Quand un utilisateur charge une vidéo de 500 mégaoctets, le navigateur doit conserver en même temps le fichier d'origine, le buffer de traitement et le fichier de sortie. Sur un téléphone avec 3 Go de RAM partagés entre toutes les applications et tous les onglets ouverts, cette équation devient vite serrée.

J'ai passé des semaines à optimiser la manière dont l'outil gère les fichiers en mémoire : lecture par morceaux, traitement incrémental et libération immédiate de la mémoire dès qu'une étape est terminée. Le résultat, c'est que l'outil gère des fichiers bien plus gros qu'une implémentation naïve ne le permettrait, même s'il existe toujours des limites qui dépendent de l'appareil de l'utilisateur.

La compatibilité entre navigateurs a été un autre terrier de lapin. WebAssembly est pris en charge par tous les grands navigateurs, mais chaque navigateur l'implémente avec ses propres nuances. Safari sur iOS gère SharedArrayBuffer différemment de Chrome sur Android. Firefox a ses propres étrangetés côté allocation mémoire. J'ai construit une matrice de tests couvrant plus de 30 combinaisons navigateur/appareil et je la faisais tourner à chaque modification.

Le support des formats s'est aussi révélé plus délicat que prévu. FFmpeg supporte presque tout, mais le build WebAssembly n'inclut pas tous les codecs afin de garder une taille de téléchargement raisonnable. J'ai dû trouver le bon équilibre entre la prise en charge des formats courants — MP4 avec H.264, MOV, WebM — et un chargement initial rapide. La plupart des utilisateurs ne rencontrent jamais de format non pris en charge, mais pour ceux à qui cela arrive, l'outil affiche un message clair et ils peuvent me contacter.

Je veux être très clair sur un point : Remove Audio n'est pas privé parce que nous promettons de ne pas regarder vos fichiers. Il est privé parce que vos fichiers ne peuvent tout simplement pas nous atteindre. Il n'existe aucun endpoint serveur qui accepte des uploads vidéo. Aucune API ne reçoit les données des fichiers. Le code de traitement tourne dans le bac à sable de votre navigateur, et les seules requêtes réseau que la page effectue servent à charger l'outil lui-même ainsi que l'analytics et la publicité.

Cette distinction compte beaucoup plus qu'on ne l'imagine. Quand une entreprise vous dit que vos données sont en sécurité sur ses serveurs, vous devez faire confiance à ses pratiques de sécurité, à ses employés, à son infrastructure et à ses décisions futures concernant la rétention des données. Quand vos données ne quittent jamais votre appareil, toutes ces questions de confiance disparaissent.

J'ai choisi délibérément cette architecture même si cela signifie renoncer à certaines fonctions proposées par les outils basés sur serveur. Je ne peux pas traiter des vidéos plus grosses que ce que la mémoire du navigateur autorise. Je ne peux pas proposer un traitement en arrière-plan si l'utilisateur ferme l'onglet. Je ne peux pas fournir une app mobile qui continue à traiter en tâche de fond. Ce sont de vrais compromis, et je pense qu'ils valent la peine d'être faits.

"

"La confidentialité ne devrait pas exiger de la confiance. Si vos fichiers ne quittent jamais votre appareil, il n'y a rien à croire sur parole. C'est cette architecture-là que je voulais."

Construire Remove Audio seul signifie prendre toutes les décisions, depuis la couleur d'un bouton jusqu'aux options de FFmpeg et à la formulation de la politique de confidentialité. Cela a des avantages : l'outil reste concentré, les décisions sont rapides et aucun comité ne vient diluer la mission centrale. Mais cela signifie aussi que chaque rapport de bug, chaque e-mail de support et chaque déploiement tard le soir reposent sur moi.

Le plus difficile dans le développement solo, ce n'est pas le code. C'est le changement de casquette permanent entre développeur, designer, rédacteur technique, support et marketing. Je peux être plongé dans un problème d'optimisation mémoire WebAssembly et recevoir en même temps un message d'un utilisateur dont le téléchargement a échoué sur Safari iOS 16 sur un modèle précis d'iPad. Les deux demandent de l'attention. Aucun ne peut vraiment attendre.

Ce qui me fait continuer, c'est le retour des utilisateurs. Chaque fois que quelqu'un m'écrit pour dire que l'outil lui a évité d'envoyer une vidéo sensible sur un site inconnu, ou qu'il a pu mettre 50 clips en sourdine dans l'après-midi pour son calendrier social media, ou que même un grand-parent a réussi à l'utiliser sans aide, cela me rappelle pourquoi j'ai construit cet outil. Des outils simples, respectueux de la confidentialité et qui marchent vraiment. C'est ça, la mission.

Après plus de 10 ans à construire des outils web, je reviens toujours à la même idée : les outils qu'on utilise sont ceux qui s'effacent. Personne n'a envie de passer du temps dans un outil de mise en sourdine vidéo. Les gens veulent couper le son d'une vidéo puis passer à autre chose. Chaque seconde de friction, chaque étape inutile, chaque élément d'interface confus est une raison de fermer l'onglet et de chercher une alternative.

Cette philosophie façonne tout dans Remove Audio. Une page. Une action. Déposer un fichier, cliquer sur un bouton, télécharger le résultat. J'ai résisté à la tentation d'ajouter des fonctionnalités qui compliqueraient l'expérience centrale. Pas d'édition audio. Pas de découpage vidéo. Pas de filtres. Non pas parce que ces fonctions sont mauvaises, mais parce qu'elles détourneraient l'outil de ce pour quoi les gens sont venus.

L'autre leçon, c'est que la confiance se gagne lentement et se perd instantanément. J'ai toujours été transparent sur la façon dont l'outil fonctionne, sur les données collectées par le site — données d'analytics et de publicité, pas contenu vidéo — et sur ses limites. Quand quelque chose casse, je le corrige et je communique honnêtement. Quand un utilisateur a un cas limite que je ne peux pas prendre en charge, je le lui dis au lieu de lui faire perdre du temps.

Construire un outil sur lequel les gens comptent est une responsabilité que je prends très au sérieux. Chaque vidéo traitée via Remove Audio peut contenir des moments privés, des informations sensibles ou un contenu professionnel important. Ce poids maintient la qualité du code à un niveau élevé et rend l'architecture de confidentialité non négociable.

Remove Audio va continuer à être un outil ciblé, axé sur la confidentialité, qui fait une chose et la fait bien. J'ai une liste d'améliorations en cours : de meilleures performances sur les appareils modestes, une prise en charge plus large des formats et de meilleures fonctionnalités d'accessibilité. Mais l'architecture centrale — traitement local sans upload serveur — ne changera pas.

Je compte aussi écrire davantage sur l'aspect technique du traitement vidéo dans le navigateur. Le web est bien plus puissant que beaucoup de développeurs ne l'imaginent, et je pense que nous verrons de plus en plus d'outils capables de traiter des médias sensibles localement au lieu d'exiger un upload. Si cet article vous parle, gardez un œil sur le blog : j'y publierai d'autres analyses techniques plus approfondies.

Et si vous êtes arrivé jusque-là, merci d'avoir lu. Que vous utilisiez Remove Audio régulièrement ou que vous soyez tombé sur cet article par hasard, j'apprécie votre temps. Si vous avez des questions sur l'outil, la technologie ou quoi que ce soit d'autre évoqué ici, contactez-moi via la page de contact. Je lis et je réponds personnellement à chaque message.

Le web a normalisé l'envoi de contenus personnels vers des serveurs distants, même pour les tâches de traitement les plus simples. Je pense qu'il vaut la peine de remettre cette habitude en question, surtout pour les outils qui manipulent de la vidéo et de l'audio. Toutes les tâches n'ont pas besoin d'un serveur. Tous les fichiers n'ont pas besoin de quitter votre appareil.

Remove Audio est ma réponse à cette question : un outil qui prouve qu'on peut offrir une bonne expérience utilisateur sans jamais toucher aux fichiers des utilisateurs. WebAssembly l'a rendu possible. L'obstination l'a rendu réel. Et les retours des utilisateurs qui tiennent à leur confidentialité autant que moi donnent envie de continuer.

Si vous êtes développeur et que vous envisagez une approche similaire pour vos propres outils, je serai ravi de partager ce que j'ai appris. Et si vous êtes simplement un utilisateur qui veut mettre une vidéo en sourdine sans se demander où part son fichier, c'est exactement pour cela que j'ai construit cet outil.