Comment fonctionne RoundCut

La réponse courte

RoundCut exécute chaque outil dans votre navigateur grâce à deux API natives du browser : la Canvas API HTML5 pour les opérations au niveau du pixel, et WebAssembly pour les tâches plus lourdes — encodage/décodage de formats d’image et inférence IA. Rien n’est téléversé. Rien n’est traité sur nos serveurs, car nous n’avons pas de serveurs qui touchent à vos fichiers.

Vous pouvez le vérifier en 30 secondes : ouvrez les DevTools de votre navigateur, allez dans l’onglet Network, effacez le journal et utilisez n’importe quel outil. Les seules requêtes réseau que vous verrez concernent les assets statiques du site — HTML, CSS, JavaScript, polices et les modules WebAssembly. Votre image ne quitte jamais la page.

Pourquoi côté client

La plupart des outils d’image en ligne fonctionnent à l’envers : vous téléversez, un serveur traite, vous téléchargez le résultat. Ce modèle présente quelques inconvénients bien connus — votre fichier réside sur la machine de quelqu’un d’autre, vous attendez deux allers-retours, et l’opérateur paie au CPU-seconde, ce qui explique pourquoi ces services tendent à ajouter des comptes, des filigranes ou des formules payantes.

Les navigateurs sont capables d’effectuer la plupart de ce travail nativement depuis des années. L’élément <canvas> gère le recadrage, la rotation, le redimensionnement et le réencodage ; WebAssembly nous permet d’exécuter les mêmes bibliothèques C/Rust MozJPEG, libwebp, libavif et Oxipng qu’utilise Squoosh, à une vitesse quasi-native. Au moment où nous avons lancé la reconstruction 2026, le navigateur avait effectivement rattrapé la suite d’outils d’édition d’images pour bureau. Il n’y avait plus aucune raison d’impliquer un serveur.

Le résultat est une stack avec trois propriétés qui se renforcent mutuellement : confidentialité (votre fichier ne quitte jamais votre appareil), vitesse (pas de téléversement, pas de file d’attente, pas d’aller-retour serveur) et coût (nous servons des assets statiques depuis un CDN pour quelques centimes par mois, quel que soit le nombre de personnes utilisant les outils).

Le pipeline, étape par étape

1. Vous sélectionnez un fichier

Quand vous choisissez une image — via le sélecteur de fichiers, le glisser-déposer ou le collage — le navigateur remet à JavaScript un objet File. JavaScript lit les octets via l’API FileReader ou Blob.arrayBuffer(). À aucun moment de cette étape le fichier n’est envoyé sur le réseau.

2. Le navigateur décode l’image

Les navigateurs modernes peuvent décoder nativement les formats JPG, PNG, WebP, GIF, AVIF et (sur Safari et Chromium récent) HEIC. Nous utilisons createImageBitmap() pour convertir les octets bruts en un bitmap avec lequel le GPU peut travailler, hors du thread principal. Pour le format HEIC sur les navigateurs qui ne le décodent pas nativement, nous recourons à un décodeur WebAssembly qui s’exécute localement dans votre navigateur.

3. L’outil fait son travail

Ce qui se passe ensuite dépend de l’outil. RoundCut en propose actuellement trois :

• Circle Crop — une transformation de pixels Canvas 2D avec un tracé de recadrage circulaire. Le bitmap est dessiné dans un <canvas> à la rotation et au zoom choisis, le recadrage circulaire est appliqué, et l’intérieur du cercle est relu en tant qu’ImageData. Cropper.js gère l’interaction du cadre de recadrage.
• Compress — réencode les formats JPG, PNG, WebP ou AVIF via les modules WebAssembly jSquash (MozJPEG, libwebp, libavif, Oxipng). Ce sont les mêmes codecs upstream qu’utilise Squoosh. Ils s’exécutent dans un Web Worker pour que l’interface reste réactive pendant l’encodage d’une photo de plusieurs mégapixels, et un aperçu côte à côte vous permet de voir le compromis avant de valider.
• Remove Background — un petit modèle d’IA au format ONNX (quelques Mo, téléchargé une fois et mis en cache) s’exécute dans votre navigateur via ONNX Runtime Web, avec WebAssembly comme backend d’exécution. Le premier lancement télécharge le modèle ; chaque lancement suivant est local et instantané.

4. Vous téléchargez le résultat

Le bitmap de sortie est encodé dans un Blob, encapsulé dans une object URL et proposé à la boîte de dialogue standard d’enregistrement de fichier de votre navigateur. Là où elle est prise en charge, nous utilisons la File System Access API pour que vous puissiez choisir directement le dossier de destination. Le fichier apparaît sur votre disque ; rien ne transite par un serveur.

Comment le vérifier vous-même

L’affirmation « sans téléversement » est vérifiable en deux minutes. Choisissez la méthode que vous préférez :

Méthode 1 — Observez l’onglet Network

1. Ouvrez RoundCut dans un nouvel onglet.
2. Ouvrez les DevTools (F12 ou clic droit → Inspecter) et allez dans l’onglet Network.
3. Cliquez sur le bouton « effacer » dans l’onglet Network pour repartir de zéro.
4. Utilisez n’importe quel outil : chargez une image, modifiez-la, téléchargez le résultat.
5. Regardez le journal Network. Vous verrez des requêtes pour HTML, CSS, JS, polices et (lors du premier usage d’un outil plus lourd) le module WebAssembly concerné. Vous ne verrez aucune requête contenant les octets de votre image.

La colonne « Initiator » vous indique quel script a déclenché chaque requête, et la colonne « Type » indique ce qui a été envoyé. Filtrez par « Fetch/XHR » pour vous concentrer sur les requêtes de données ; vous verrez qu’elles sont toutes petites, toutes vers l’origine statique, et qu’aucune ne contient votre fichier.

Méthode 2 — Utilisez les outils hors ligne

1. Chargez n’importe quelle page d’outil RoundCut. Utilisez-la une fois pour vous assurer que les modules WebAssembly pertinents sont en cache.
2. Ouvrez les DevTools, allez dans l’onglet Network et cochez la case Offline (ou coupez simplement votre Wi-Fi).
3. Rechargez la page. Elle se charge quand même, car le navigateur a mis en cache les assets statiques.
4. Utilisez à nouveau l’outil, de bout en bout. Il fonctionne toujours.

Si l’outil a fonctionné hors ligne, par définition il n’a pas contacté de serveur pendant l’opération. C’est la preuve la plus solide possible — le travail s’est effectué sur votre machine car il n’y avait aucune autre machine accessible.

Ce que nous voyons

Pour être clair sur ce qui est collecté : quand vous chargez une page, notre fournisseur d’analytics (Cloudflare Web Analytics) enregistre qu’un navigateur a chargé cette URL depuis un certain pays. Pas de cookies, pas d’identifiants persistants, rien lié à une personne.

Pour les outils qui téléchargent un module WebAssembly lors du premier usage (codecs jSquash, le modèle ONNX de suppression de fond), notre hébergeur voit que quelqu’un a récupéré le module — de la même façon qu’il voit quelqu’un récupérer le fichier CSS. Le module lui-même ne contient aucune information sur votre image.

L’inventaire complet des données figure dans notre politique de confidentialité.

La stack technologique

Pour les curieux, voici sur quoi RoundCut est construit :

• Astro — le générateur de sites statiques. Chaque page est livrée en HTML brut avec des « islands » JavaScript à amélioration progressive uniquement là où résident les outils interactifs.
• CSS vanilla avec propriétés personnalisées — sans Tailwind, sans CSS-in-JS. L’intégralité du système de design tient dans un seul fichier tokens.css.
• jSquash — bindings WebAssembly pour MozJPEG, libwebp, libavif et Oxipng pour l’encodage d’images.
• Cropper.js — la couche d’interaction du rectangle de recadrage pour les outils de recadrage.
• ONNX Runtime Web — exécute le modèle de suppression de fond dans votre navigateur via WebAssembly.
• Cloudflare Pages — héberge le build statique, le sert depuis l’edge et fournit DNS et protection DDoS.
• Cloudflare Web Analytics — comptages de pages vues agrégés, sans cookies.

Compatibilité des navigateurs

Tous les outils fonctionnent sur la version actuelle et la précédente de Chrome, Firefox, Safari et Edge — bureau et mobile. Le site utilise l’amélioration progressive : là où un navigateur prend en charge une API plus récente (ex. : showSaveFilePicker, OffscreenCanvas), nous l’utilisons ; là où ce n’est pas le cas, nous revenons à l’équivalent plus ancien. Il n’y a pas de barrière « votre navigateur n’est pas pris en charge ».

La seule exigence absolue est JavaScript. Avec JavaScript désactivé, les outils ne peuvent pas s’exécuter — il n’y a pas de fallback côté serveur car il n’y a pas de serveur qui traite les images.

Questions

Quelque chose que nous n’avons pas couvert ? Écrivez-nous à support@araluma.com. Les questions techniques sont les bienvenues.