Recadrer

Recadrer une image Recadrer une image en cercle

Optimiser

Compresser une image Améliorer la qualité d’une image Supprimer le fond d’une image

Modifier

Redimensionner une image

Convertir

Autres

Convertir JPG en PDF

Comment fonctionne RoundCut

Détail technique sur ce que chaque outil fait, où il s'exécute et comment vous pouvez le vérifier vous-même.

La réponse courte

RoundCut repose sur une architecture hybride : la plupart des outils s’exécutent entièrement dans votre navigateur sans aucun téléversement, et une poignée achemine une seule requête réseau à travers notre propre infrastructure quand le navigateur ne peut pas égaler la qualité, toujours avec une solution de repli invisible côté client. Nous vous disons sur quelle voie vous êtes, dans chaque outil et sur cette page.

Le tableau ci-dessous est représentatif, non exhaustif (de nouveaux outils sortent régulièrement). Il montre un exemple de chaque type de voie :

Outil d’exempleOù le travail se fait
Circle Crop (navigateur uniquement)100 % dans votre navigateur, Canvas API. Aucun téléversement, fonctionne hors ligne.
Aperçu de compression (navigateur uniquement)100 % dans votre navigateur, canvas.toBlob. Aucun téléversement. Le curseur reste instantané.
Téléchargement final de compression (touche au serveur)Un aller-retour vers notre service sur api.roundcut.com.br (Fastify + sharp + libvips sur un VPS en Allemagne), avec un repli navigateur.
Suppression d’arrière-plan (touche au serveur)Un aller-retour vers un Cloudflare Worker qui exécute BiRefNet sur les GPU edge de Cloudflare, avec un repli WebAssembly dans votre navigateur quand le cloud est injoignable.

Le recadrage, le redimensionnement, la conversion de format (sauf l’encodage AVIF) et l’aperçu de compression s’exécutent tous entièrement dans votre navigateur. La suppression d’arrière-plan, le téléchargement de compression, l’agrandissement par IA, l’encodage AVIF et le PDF à plusieurs images acheminent chacun une seule requête et reviennent au navigateur quand le cloud est injoignable.

Vous pouvez vérifier les affirmations côté client en une trentaine de secondes : ouvrez DevTools → Réseau, videz le journal, puis utilisez un outil navigateur uniquement comme Circle Crop ou le curseur de l’aperçu de compression, et vous verrez qu’aucune requête transportant les octets de votre image ne quitte la page. Pour les outils qui touchent au serveur, vous verrez exactement un téléversement par opération, vers des points de terminaison nommés.

Pourquoi hybride

La plupart des outils d’image en ligne se placent à un extrême : tout-téléverser-vers-un-serveur (vous attendez les allers-retours et l’exploitant conserve votre fichier) ou tout-dans-le-navigateur (vous payez en qualité et en vitesse sur les étapes d’encodage et d’IA). Aucun extrême ne gagne partout.

Nous avons choisi le côté client là où les navigateurs sont déjà excellents, l’élément <canvas> gère le recadrage, la rotation, le redimensionnement et l’encodage avec perte de l’aperçu en JPG/WebP, et le côté serveur là où le navigateur perd encore de façon mesurable :

  • La compression d’image, au téléchargement final. Côté serveur, sharp + libvips 8.17 produit des fichiers 10 à 15 % plus petits octet pour octet que les encodeurs du navigateur à qualité visuelle égale, et donne accès au réglage fin de la vitesse/du chroma AVIF et à la sortie JPEG XL que le navigateur n’expose pas. Le curseur et l’aperçu s’exécutent toujours dans votre navigateur pour que l’ajustement reste instantané, seul l’appui sur “Télécharger” passe par notre service.
  • La suppression d’arrière-plan par IA et l’agrandissement par IA, sur la voie par défaut. Les modèles (BiRefNet pour la segmentation, super-résolution pour l’agrandissement) ont besoin d’un vrai GPU pour finir en quelques secondes. Les replis dans le navigateur fonctionnent, mais sont plus lents et produisent un résultat visiblement plus grossier sur les cheveux, la fourrure et les bords fins.
  • L’encodage AVIF, à la conversion. L’encodeur AVIF du navigateur est lent sur certains appareils, donc la sortie AVIF achemine une requête vers le Worker de compression, avec un encodage navigateur sur le fil principal comme repli.

Le coût que nous acceptons d’être côté serveur sur ces voies est un aller-retour par opération. Le coût que nous évitons en restant côté client partout ailleurs, c’est les frais d’aller-retour sur les parties du flux qui s’ajustent le plus vite.

Le pipeline, étape par étape

1. Vous sélectionnez un fichier

Via le sélecteur de fichier, le glisser-déposer ou le collage, le navigateur remet à JavaScript un objet File. JavaScript lit les octets avec FileReader ou Blob.arrayBuffer(). À aucun moment de cette étape le fichier n’est envoyé sur le réseau, quel que soit l’outil que vous utilisez.

2. Le navigateur décode l’image

Les navigateurs modernes décodent nativement JPG, PNG, WebP, GIF et AVIF. Nous utilisons createImageBitmap() pour transformer les octets bruts en un bitmap avec lequel le GPU peut travailler, en dehors du fil principal. Pour le HEIC sur les navigateurs qui ne le décodent pas nativement, nous revenons à un décodeur WebAssembly qui s’exécute localement dans votre navigateur.

3. L’outil fait son travail, c’est ici que les voies divergent

  • Outils navigateur uniquement (recadrage, redimensionnement, conversion de format vers PNG/JPEG/WebP, l’aperçu de compression). Une transformation de pixels Canvas 2D ou un codec WebAssembly réencode le bitmap localement. Le résultat est prêt sans aucun téléversement. Cropper.js gère le cadre de recadrage interactif pour les outils de recadrage, et canvas.toBlob gère le réencodage de l’aperçu. Entièrement dans votre navigateur.
  • Compression, téléchargement. Quand vous appuyez sur “Télécharger”, l’image est envoyée une fois à api.roundcut.com.br (un service Fastify sur un VPS en Allemagne exploité par Hostinger, Node 24 + sharp 0.34 + libvips 8.17, les mêmes bibliothèques C que Squoosh utilise sur sa voie serveur). Elle est réencodée avec les mêmes paramètres que vous avez réglés dans l’aperçu, et les octets sont renvoyés en flux vers votre navigateur. Le service garde un cache isolé par locataire et adressé par contenu (un hash des octets d’entrée + paramètres) plafonné à 500 Mo, de sorte que retélécharger la même image avec les mêmes réglages rejoue les octets en cache, le cache n’est pas indexé par vous, IP ou nom de fichier. Si le service est injoignable, l’outil revient au blob d’aperçu du navigateur.
  • Suppression d’arrière-plan, voie cloud par défaut. L’image est téléversée une fois vers un Cloudflare Worker, mise en zone tampon dans un bucket R2 privé, traitée par la transformation cf.image.segment de Cloudflare qui exécute le modèle BiRefNet sur les GPU edge de Cloudflare, et le détourage est renvoyé en flux. L’objet R2 mis en zone tampon est supprimé en moins d’une heure par une règle de cycle de vie R2, quel que soit le résultat. Une photo typique finit en 1 à 3 secondes. Des plafonds quotidiens par IP et une limite de téléversement de 5 Mo maintiennent le palier gratuit soutenable.
  • Autres outils appuyés sur le cloud (agrandissement par IA, encodage AVIF, PDF à plusieurs images) suivent la même forme : une requête vers une infrastructure nommée (une API cloud d’image pour la super-résolution, le Worker de compression pour l’encodage AVIF, notre service VPS pour le PDF à plusieurs images), le résultat renvoyé en flux, et un repli navigateur invisible si cette requête échoue.
  • Repli WebAssembly. Si la voie cloud concernée est injoignable (votre réseau lâche, vous êtes derrière un pare-feu strict, le quota quotidien est plein, ou le fichier dépasse la limite cloud), l’outil bascule sans accroc vers un modèle ou un codec local qui s’exécute dans votre navigateur, par exemple le modèle de suppression d’arrière-plan ISNet via ONNX Runtime Web avec WebAssembly. La première exécution télécharge le modèle et est plus lente, les exécutions suivantes sont plus rapides. Aucun téléversement sur ces voies de repli, vous pouvez le vérifier dans les DevTools.

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

Le bitmap de sortie est encodé en un Blob, enveloppé dans une object URL, et proposé à la boîte de dialogue d’enregistrement de fichier standard de votre navigateur. Le fichier apparaît sur votre disque.

Comment le vérifier vous-même

Choisissez ce que vous préférez :

Méthode 1. Surveiller l’onglet Réseau

  1. Ouvrez RoundCut dans un onglet neuf et ouvrez DevTools → Réseau.
  2. Utilisez un outil navigateur uniquement, Circle Crop ou le curseur de l’aperçu de compression. Vous verrez des requêtes pour HTML/CSS/JS/polices uniquement, plus les modules WebAssembly concernés à la première utilisation. Aucune requête ne transportera les octets de votre image.
  3. Utilisez maintenant un outil qui touche au serveur, Compression → Télécharger ou Suppression d’arrière-plan. Vous verrez exactement un POST transportant votre image, et une réponse revenant avec le résultat. Survolez une requête pour voir la taille et le temps.

La colonne “Initiateur” vous dit quel script a déclenché chaque requête, et la colonne “Type” vous dit ce qui a été envoyé. Nous ne cachons ni l’un ni l’autre.

Méthode 2. Utiliser les outils hors ligne

  1. Chargez n’importe quelle page d’outil RoundCut. Utilisez Suppression d’arrière-plan une fois sur une petite image pour que le modèle ISNet du navigateur soit mis en cache.
  2. Ouvrez DevTools → Réseau → cochez Hors ligne (ou coupez le Wi-Fi).
  3. Rechargez la page, les ressources statiques sont en cache, donc elle se charge encore.
  4. Essayez les outils :
    • Les outils navigateur uniquement (Circle Crop, redimensionnement, l’aperçu de compression) continuent de fonctionner, ils n’ont jamais eu besoin du réseau.
    • Le téléchargement de compression revient au blob d’aperçu du navigateur (encodage un peu moins efficace, mais fonctionnel).
    • La suppression d’arrière-plan revient au modèle WebAssembly ISNet et fonctionne sans aucune requête sortante.

Si les outils fonctionnaient hors ligne (ceux appuyés sur le cloud légèrement dégradés, ceux navigateur uniquement identiques), par définition aucun serveur n’a vu votre image.

Ce que nous voyons, et ce que nous ne voyons pas

Sur les voies côté client, nous ne voyons rien de votre image. Il n’y a aucune requête à regarder, aucun cache pour la stocker, aucune ligne de journal à parcourir.

Sur les voies côté serveur :

  • Le service de compression et de PDF voit les octets de l’image le temps de l’encodage (en général quelques centaines de millisecondes), garde une entrée de cache adressée par contenu pendant la durée de vie du cache, et c’est tout. Le cache n’est pas indexé par utilisateur, IP, nom de fichier ou tout identifiant que nous pourrions utiliser pour retrouver “vos” images. Nous ne journalisons pas le contenu des images. Le service d’encodage est partagé entre les deux mêmes locataires que la v1 servait avant la bascule, avec un CORS, des limites de débit et des URL canoniques signées en HMAC par locataire.
  • La suppression d’arrière-plan et les autres voies d’IA voient l’image le temps du téléversement en zone tampon et de l’appel au modèle (en général quelques secondes), après quoi la copie en zone tampon est supprimée par une règle de cycle de vie R2. Le modèle BiRefNet s’exécute au sein de l’infrastructure propre de Cloudflare, pas sur une API externe du style remove.bg / fal.ai / Replicate.

Sur chaque voie, notre fournisseur d’analytique (Cloudflare Web Analytics) enregistre des données agrégées de pages vues. URL, pays, famille de navigateur, Core Web Vitals. Pas de cookies, pas d’identifiants persistants, rien de lié à une personne.

Pour les outils qui téléchargent un module WebAssembly à la première utilisation (le décodeur HEIC, le modèle ONNX ISNet), notre hébergeur voit que quelqu’un a récupéré le module, de la même manière qu’il le voit 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 pile technologique

Pour les curieux :

  • Astro, le générateur de sites statiques. Chaque page est livrée en HTML pur avec des “îlots” JavaScript à amélioration progressive, uniquement là où vivent des outils interactifs.
  • CSS vanille avec propriétés personnalisées, pas de Tailwind, pas de CSS-in-JS. Tout le système de design tient dans un seul fichier tokens.css.
  • canvas.toBlob / <canvas>. Encodage JPEG, PNG, WebP, AVIF (pris en charge par le navigateur) dans les outils navigateur uniquement, et tout le travail de recadrage et de redimensionnement.
  • Cropper.js, la couche d’interaction du rectangle de recadrage.
  • ONNX Runtime Web, exécute le repli WebAssembly ISNet pour la Suppression d’arrière-plan.
  • Cloudflare Pages, héberge le build statique, le sert depuis l’edge.
  • Cloudflare Workers + R2 + cf.image.segment (BiRefNet), le pipeline par défaut de la Suppression d’arrière-plan.
  • Fastify + sharp 0.34 + libvips 8.17 sur Node 24, le service de compression et de PDF sur api.roundcut.com.br, sur un VPS Hostinger en Allemagne.
  • Cloudflare Web Analytics, comptages de pages vues agrégés et sans cookie.

Prise en charge des navigateurs

Chaque outil fonctionne sur la version actuelle et la précédente de Chrome, Firefox, Safari et Edge, sur ordinateur et mobile. Le site utilise l’amélioration progressive : là où un navigateur prend en charge une API plus récente (par ex. showSaveFilePicker, OffscreenCanvas), nous l’utilisons, là où il ne le fait pas, nous revenons à l’équivalent plus ancien. Il n’y a aucun mur “votre navigateur n’est pas pris en charge”.

Les seules exigences strictes sont JavaScript (pour tout outil) et une connexion réseau (uniquement lors de l’usage d’un outil appuyé sur le cloud sur sa voie par défaut, les outils navigateur uniquement s’exécutent entièrement hors ligne après le premier chargement de page).

Questions

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