---
title: "Éditeurs dans le navigateur ou cloud : où vont vos fichiers ?"
description: "Deux éditeurs peuvent afficher la même interface sans traiter le fichier au même endroit : reconnaître un traitement local, et les phrases qui ne prouvent rien."
canonical: "https://freeaigeneration.com/fr/guides/editeurs-dans-le-navigateur-ou-cloud-ou-vont-vos-fichiers/"
robots: "noindex"
lang: "fr"
---

# Éditeurs dans le navigateur ou cloud : où vont vos fichiers ?

Deux éditeurs peuvent afficher la même interface, proposer les mêmes menus et ne pas traiter votre fichier au même endroit. La différence ne se voit pas à l’écran : elle se voit dans ce que la page demande au réseau, et dans ce qu’elle est capable de faire quand le réseau est coupé.

La question des éditeurs dans le navigateur ou cloud est donc une question de trajet, pas de fonctionnalités.

## Deux modèles, et un mélange fréquent

Le premier modèle est le traitement local. La page lit le fichier avec l’API File du navigateur, le garde en mémoire dans l’onglet, et le travail s’effectue là. L’enregistrement ou l’export remet un fichier au gestionnaire de téléchargement.

Le second est le traitement serveur. L’éditeur doit recevoir les octets pour travailler, parce que le calcul se fait sur une machine distante. La question n’est plus de savoir si le fichier part, mais ce qu’il devient après : durée de conservation, accès, sauvegardes, suppression, liens de partage.

La plupart des services mélangent les deux. Un éditeur peut traiter l’image dans le navigateur et synchroniser le projet sur un compte. Le modèle se vérifie opération par opération, pas sur la page d’accueil.

## Ce qu’un fichier devient dans chaque cas

En local, le fichier devient un objet en mémoire dans l’onglet. Il n’existe pas de copie ailleurs, sauf si le site en fabrique une, et le téléchargement est votre seule copie.

En serveur, le fichier devient un objet stocké. Il survit à la fermeture de l’onglet, parfois à votre compte, parfois à une sauvegarde dont vous ignorez l’existence. La vraie question devient la politique de conservation, et elle ne se lit pas dans l’interface.

## Comment reconnaître un traitement local

Quatre indices se vérifient sans outil spécial. Le premier est la destination de l’enregistrement : un téléchargement vers votre disque et un message « enregistré dans votre espace » ne décrivent pas le même modèle. Le deuxième est l’exigence de compte, car un outil qui demande une inscription avant d’ouvrir un fichier a presque toujours besoin d’identifier le déposant.

Le troisième est le comportement hors ligne. Une page dont le moteur a été mis en cache continue de fonctionner réseau coupé ; une page qui exige un appel serveur à chaque opération s’arrête.

Le quatrième est le volume et le moment du transfert. Un fichier de 50 Mo sur une ligne à 10 Mbit/s représente 50 × 8 = 400 Mbit, donc 40 secondes avant que le traitement puisse commencer. Si l’outil devient utilisable aussitôt sur un gros fichier sans envoi visible dans l’onglet réseau, le calcul se fait probablement sur place.

## Le temps que le trajet coûte

Le calcul précédent devient parlant sur une bibliothèque. Cinq cents fichiers bruts de 42 Mo représentent 21 000 Mo, soit 21 Go environ, ou 19,6 GiB. À 100 Mbit/s, l’envoi demande 21 000 × 8 = 168 000 Mbit, soit 1 680 secondes, près de 28 minutes.

Ce temps ne se perd pas de la même façon. En local, il correspond à la lecture du disque et au décodage. En serveur, il correspond à un envoi qui consomme de la bande passante montante, et qui recommence à chaque session si le service ne conserve rien.

## Les quatre phrases qui ne prouvent rien

« Tout se passe dans le navigateur » décrit un lieu d’exécution, pas une politique de données. Une page peut traiter une image localement et envoyer télémétrie, polices ou vérification de mise à jour.

« C’est du WebAssembly » ne dit rien non plus. Le WebAssembly s’exécute dans le bac à sable de la page et n’appelle que ce que l’hôte lui fournit : c’est une cible de compilation, pas une propriété de confidentialité.

« Aucun envoi » ne signifie pas « aucun réseau ». La politique de même origine empêche un site de lire le stockage d’un autre, elle ne l’empêche pas d’émettre des requêtes. Et CORS encadre la lecture des réponses, pas l’envoi.

« Sans inscription » ne veut pas dire « sans compte ». Cookies, mesure d’audience et journaux de CDN existent sans formulaire.

## Ce que ce site fait, et les exceptions documentées

Les sept moteurs sont servis depuis la même origine que le site, dans un dossier par moteur et par version, et lancés dans une iframe après un clic. Il n’y a ni compte ni stockage de document chez FreeAIGeneration : enregistrer ou exporter remet le fichier au gestionnaire de téléchargement du navigateur. La phrase exacte affichée par le site est « Fonctionne dans votre navigateur. Aucun compte FreeAIGeneration requis. »

Les exceptions sont nommées, et c’est ce qui rend la description utilisable. Le démarrage de l’éditeur PDF n’émet aucune requête tierce, mais une vérification manuelle de mise à jour peut contacter GitHub. L’éditeur d’animation n’en émet aucune. L’éditeur vidéo propose en option des téléchargements de modèles hébergés chez Hugging Face, après une boîte de confirmation.

Le traitement local reste une propriété de conception, pas une garantie réseau. [Les éditeurs photo, vidéo et PDF en ligne sont-ils confidentiels ?](/fr/guides/les-editeurs-photo-video-et-pdf-en-ligne-sont-ils-confidentiels/) transforme cette distinction en liste de vérifications, et [Éditeurs créatifs dans le navigateur ou logiciels de bureau](/fr/guides/editeurs-creatifs-dans-le-navigateur-ou-logiciels-de-bureau-que-choisir/) traite le versant outil.

Pour appliquer tout cela à un fichier précis, [les outils créatifs](/fr/outils/) se testent sans compte, et [les guides](/fr/guides/) reviennent sur chaque point de méthode.
