Comment fonctionne Araluma

La réponse courte

Araluma 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 via notre propre infrastructure quand le navigateur ne peut égaler la qualité, toujours avec une voie 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, pas exhaustif (le catalogue ne cesse de grandir). Il montre un exemple de chaque type de voie :

Outil exemple	Où le travail a lieu
Recadrage en cercle (navigateur uniquement)	100 % dans votre navigateur, API Canvas. 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 de compression (touche au serveur)	Un aller-retour vers notre service sur api.araluma.com (sharp plus libvips sur un VPS en Allemagne), avec une voie de repli dans le navigateur.
Supprimer l’arrière-plan (touche au serveur)	Un aller-retour vers un Cloudflare Worker exécutant BiRefNet sur des GPU de périphérie, avec une voie de repli WebAssembly dans votre navigateur.

Les outils de recadrage, de redimensionnement, de PDF et de conversion de format (hormis la voie de sortie AVIF) se trouvent du côté navigateur uniquement. Le téléchargement de compression, la suppression d’arrière-plan, l’agrandissement par IA et les conversions à sortie AVIF se trouvent du côté qui touche au serveur, chacun avec une voie de repli locale.

Vous pouvez vérifier les affirmations sur le navigateur uniquement en une trentaine de secondes : ouvrez les DevTools, allez dans l’onglet Réseau, videz le journal, puis utilisez n’importe quel outil navigateur uniquement. 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 les points de terminaison nommés ci-dessus.

Pourquoi l’hybride

La plupart des outils d’image en ligne se situent à un extrême : tout-téléverser-vers-un-serveur (vous attendez les allers-retours et l’exploitant garde 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 partout 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 ou WebP, et les navigateurs modernes décodent nativement chaque format courant. Nous avons choisi le côté serveur seulement pour les rares étapes où le navigateur perd encore de façon mesurable :

• La compression, au téléchargement final. sharp plus libvips côté serveur produit des fichiers 10 à 15 % plus petits octet pour octet que les encodeurs de navigateur à qualité visuelle égale, et expose des réglages de vitesse AVIF et de chroma que le navigateur n’a pas. Le curseur et l’aperçu s’exécutent toujours dans votre navigateur pour que l’itération reste instantanée. Seul l’appui sur “Télécharger” passe par notre service.
• La suppression d’arrière-plan par IA, sur la voie par défaut. Le modèle BiRefNet qu’exécute la segmentation d’image de Cloudflare (la même architecture que remove.bg) a besoin d’un vrai GPU pour finir en une ou deux secondes. La voie de repli dans le navigateur (ISNet via ONNX Runtime plus WebAssembly) fonctionne, mais prend bien plus de temps et produit une découpe visiblement plus grossière sur les cheveux, les poils et les contours fins.
• L’agrandissement par IA, sur la voie par défaut. La super-résolution dans le cloud récupère du détail qu’un ré-échantillonnage dans le navigateur ne peut pas, avec une voie de repli dans le navigateur quand le service est injoignable.

Le coût que nous acceptons pour ê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 est ce même frais sur les parties du flux de travail qui itèrent le plus vite.

Le pipeline, étape par étape

1. Vous sélectionnez un fichier

Via le sélecteur de fichiers, 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 une bitmap avec laquelle le GPU peut travailler, en dehors du thread principal. Pour le HEIC sur les navigateurs qui ne le décodent pas nativement, nous nous rabattons sur un décodeur WebAssembly qui s’exécute localement dans votre navigateur.

3. L’outil fait son travail, là où les voies divergent

• Les outils navigateur uniquement (recadrage, redimensionnement, l’aperçu de compression et le curseur, l’assemblage PDF et la plupart des conversions de format). Ceux-ci s’exécutent comme des transformations de pixels Canvas et des réencodages canvas.toBlob directement sur votre machine. Le cadre de recadrage interactif utilise Cropper.js. Rien ne quitte la page.
• Téléchargement de compression. Lorsque vous appuyez sur “Télécharger”, l’image part une fois vers api.araluma.com (un service Fastify sur un VPS Hostinger en Allemagne, Node plus sharp et libvips, les mêmes bibliothèques C que Squoosh utilise sur sa voie serveur). Elle est réencodée avec les paramètres que vous avez réglés dans l’aperçu, et les octets reviennent en flux. Le service garde un cache isolé par locataire et adressé par contenu (un hachage des octets d’entrée plus les paramètres) de sorte que retélécharger la même image avec les mêmes réglages rejoue les octets en cache. Ce cache n’est pas indexé par vous, votre IP ou le nom de fichier. Si le service est injoignable, l’outil se rabat sur la blob d’aperçu dans le 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 attente dans un bucket R2 privé, traitée par la segmentation d’image de Cloudflare avec le modèle BiRefNet sur des GPU de périphérie, et la découpe revient en flux. L’objet en attente est supprimé en moins d’une heure par une règle de cycle de vie R2, quel que soit le résultat. Une photo type se termine en une ou deux secondes. Des limites quotidiennes par IP et par taille de téléversement maintiennent l’offre gratuite viable.
• Suppression d’arrière-plan, voie de repli WebAssembly. Si le Worker est injoignable (votre réseau tombe, un pare-feu strict le bloque, le quota quotidien est plein, ou le fichier dépasse la limite cloud), l’outil bascule en silence vers le modèle ISNet qui s’exécute localement via ONNX Runtime Web et WebAssembly. La première exécution télécharge le modèle et prend plus de temps, les exécutions suivantes sont plus rapides. Aucun téléversement sur cette voie, vérifiable dans les DevTools.
• Agrandissement par IA. La voie par défaut envoie l’image une fois vers un service cloud de super-résolution et renvoie le résultat agrandi en flux, avec une voie de repli dans le navigateur si le service est injoignable.

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

La bitmap de sortie est encodée en un Blob, enveloppée dans une URL d’objet et remise à la boîte de dialogue d’enregistrement standard de votre navigateur. Le fichier atterrit 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 Araluma dans un onglet neuf et ouvrez les DevTools, puis l’onglet Réseau.
2. Utilisez un outil navigateur uniquement comme Recadrage en cercle ou le curseur d’aperçu de compression. Vous ne verrez que des requêtes pour le HTML, le CSS, le JS et les polices, plus les modules WebAssembly concernés au premier usage. Aucune requête ne transporte les octets de votre image.
3. Utilisez maintenant un outil qui touche au serveur comme Téléchargement de compression ou Supprimer l’arrière-plan. Vous verrez exactement un POST transportant votre image vers le point de terminaison nommé, et une réponse revenant avec le résultat. Survolez une requête pour lire sa taille et son timing.

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’une ni l’autre.

Méthode 2. Utiliser les outils hors ligne

1. Chargez n’importe quelle page d’outil Araluma. Lancez Supprimer l’arrière-plan une fois sur une petite image pour que le modèle ISNet dans le navigateur soit mis en cache.
2. Ouvrez les DevTools, allez dans l’onglet Réseau et 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 continuent de fonctionner. Ils n’ont jamais eu besoin du réseau.
   • Téléchargement de compression se rabat sur la blob d’aperçu dans le navigateur (un encodage un peu moins efficace, mais fonctionnel).
   • Supprimer l’arrière-plan se rabat sur le modèle WebAssembly ISNet et fonctionne sans aucune requête sortante.

Si ces outils ont fonctionné hors ligne (certains dégradés, ceux navigateur uniquement identiques), alors par définition aucun serveur n’a vu votre image.

Ce que nous voyons et ce que nous ne voyons pas

Sur les voies navigateur uniquement, nous ne voyons rien de votre image. Il n’y a aucune requête à examiner, aucun cache où la stocker, aucune ligne de journal à parcourir.

Sur les voies qui touchent au serveur :

• Téléchargement de compression 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 sa durée de vie, 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 aucun contenu d’image. Le service d’encodage est partagé avec les mêmes locataires que servait la v1 avant la bascule, avec un CORS par locataire, des limites de débit et des URL canoniques signées par HMAC.
• Supprimer l’arrière-plan voit l’image le temps du téléversement de mise en attente et de l’appel de segmentation (généralement une ou deux secondes), après quoi la copie en attente est supprimée par la règle de cycle de vie R2. Nous ne remettons jamais vos octets à un fournisseur de modèle tiers. Le modèle BiRefNet s’exécute au sein de l’infrastructure propre à Cloudflare, pas sur une API externe de type remove.bg, fal.ai ou Replicate.
• L’agrandissement par IA voit l’image le temps de l’appel de super-résolution, renvoie le résultat et ne conserve rien qui vous soit lié.

Sur chaque voie, notre fournisseur d’analyse (Cloudflare Web Analytics) enregistre des données de pages vues agrégées : URL, pays, famille de navigateur, Core Web Vitals. Aucun cookie, aucun identifiant persistant, rien qui soit lié à une personne.

Pour les outils qui téléchargent un module WebAssembly au premier usage (le décodeur HEIC, le modèle ISNet ONNX), notre hébergeur voit que quelqu’un a récupéré le module, de la même façon qu’il voit qu’un fichier CSS est récupéré. Le module lui-même ne porte 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 progressivement enrichis seulement là où vivent les outils interactifs.
• CSS pur avec propriétés personnalisées, sans Tailwind, sans CSS-in-JS. Tout le système de design tient dans un seul fichier tokens.css.
• canvas.toBlob et <canvas>, l’encodage JPEG, PNG, WebP et AVIF pour les outils et aperçus côté navigateur.
• Cropper.js, la couche d’interaction du rectangle de recadrage.
• ONNX Runtime Web, qui exécute la voie de repli WebAssembly ISNet pour Supprimer l’arrière-plan.
• Cloudflare héberge le build statique et le sert depuis la périphérie, et fait tourner les Workers, R2 et le pipeline de segmentation d’image (BiRefNet) derrière la voie par défaut de Supprimer l’arrière-plan.
• Fastify avec sharp et libvips sur Node, le service de téléchargement de compression sur api.araluma.com, sur un VPS Hostinger en Allemagne.
• Cloudflare Web Analytics, des 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’enrichissement progressif : là où un navigateur prend en charge une API plus récente (par exemple showSaveFilePicker ou OffscreenCanvas), nous l’utilisons, et là où il ne le fait pas, nous nous rabattons sur l’équivalent plus ancien. Il n’y a pas de mur “votre navigateur n’est pas pris en charge”.

Les seules exigences strictes sont JavaScript (pour tout outil) et une connexion réseau (seulement lors de l’usage d’une voie qui touche au serveur, les outils navigateur uniquement s’exécutent entièrement hors ligne après le premier chargement de la page).

Questions

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