Limites de taille des uploads d'images et de fichiers pour garder votre application rapide

Pourquoi les règles d'upload importent avant que votre application ne grossisse

Les uploads sont faciles à ignorer au départ. Quelques photos et PDF passent bien, les pages semblent réactives et personne ne se plaint. Puis vous avez de vrais utilisateurs et de vrais contenus, et chaque écran commence à paraître plus lourd qu'il ne devrait.

Les uploads n'occupent pas seulement de l'espace. Ils influencent la rapidité perçue de votre application au quotidien. Si vous ne définissez pas de limites claires tôt, vous finirez par corriger les performances sous pression.

Vitesse d'upload ≠ vitesse de chargement de page

La vitesse d'upload, c'est le temps qu'il faut à un utilisateur pour envoyer un fichier au serveur. La vitesse de chargement de page, c'est le temps que mettent tous les autres à afficher ce fichier ensuite.

Quelqu'un peut attendre 3 secondes pour uploader une photo de 12 Mo et se dire "OK." Mais maintenant, chaque page de profil, chaque fiche produit et chaque flux qui affiche cette photo doit aussi la télécharger. Cette sensation de lenteur se propage dans toute l'app, même pour les utilisateurs qui n'uploadent rien.

Un exemple simple : une marketplace démarre avec 30 vendeurs. Tout le monde télécharge des photos directement depuis l'appareil. L'app tient encore la route. Un mois plus tard, il y a 1 000 annonces, et la page d'accueil charge des dizaines d'images surdimensionnées. Rien n'a « cassé », mais l'app paraît lente.

Les coûts cachés s'accumulent silencieusement

Les uploads volumineux et non planifiés créent des coûts difficiles à repérer jusqu'à ce que vous atteigniez une limite ou receviez la facture :

• Le stockage croît plus vite que prévu, même pour de petites apps.
• Les sauvegardes prennent plus de temps et coûtent plus cher.
• Les magasins de métadonnées gonflent si vous stockez trop par fichier.
• Les coûts CDN et bande passante augmentent parce que les utilisateurs retéléchargent de gros fichiers.
• Le support augmente quand les uploads échouent sur des réseaux mobiles.

L'objectif est simple : décidez une fois vos règles, puis faites-les respecter partout. Cela signifie les mêmes limites dans l'UI, l'API, les jobs en arrière-plan et les outils d'administration.

Si vous avez hérité d'une app générée par l'IA où les uploads ont été ajoutés vite et de façon incohérente, c'est un nettoyage courant. Mettre en place des règles cohérentes rendra toutes les autres corrections de performance plus faciles et plus prévisibles.

Ce que recouvrent les règles d'images et fichiers (en langage simple)

Quand on parle de « règles d'upload », il ne s'agit pas d'un long document technique. Il s'agit de quelques limites claires que tout le monde respecte pour que les uploads restent prévisibles et que les pages ne deviennent pas lourdes.

Les règles d'upload incluent généralement :

• Taille maximale de fichier (par fichier, et parfois par action d'upload)
• Dimensions maximales d'image (largeur et hauteur en pixels)
• Formats autorisés (types acceptés)
• Limites de nombre de fichiers (par élément, par message, par utilisateur)
• Où les fichiers sont stockés et comment ils sont restitués aux utilisateurs

Tous les fichiers ne se comportent pas de la même façon, donc les limites ne doivent pas être identiques.

Les images s'affichent dans votre app, elles affectent donc le temps de chargement et le défilement. Les documents (PDF, tableurs) sont souvent téléchargés et ouverts ailleurs, ils peuvent donc être plus volumineux sans ralentir chaque page. La vidéo est une catégorie à part : elle peut plomber les forfaits mobiles et durer sur de mauvaises connexions. Beaucoup d'apps traitent la vidéo séparément ou l'évitent au début.

"Original" vs "display" vs "thumbnail"

Ces termes paraissent sophistiqués mais sont simples :

• Original : le fichier que l'utilisateur envoie. Vous pouvez le conserver pour sauvegarde ou retouches futures.
• Version d'affichage : une copie allégée et redimensionnée que votre app montre réellement à l'écran.
• Vignette : un aperçu petit utilisé dans des listes, grilles et résultats de recherche.

Si vous ne stockez et ne servez que l'original, votre app finit par pousser de gros fichiers à chaque utilisateur, même quand il ne faut qu'un petit aperçu.

La douleur apparaît généralement d'abord pour les utilisateurs mobiles. Une photo « normale » de 6 Mo peut sembler instantanée sur du Wi‑Fi domestique, mais elle peut bloquer une page produit sur du cellulaire, vider la batterie et donner l'impression que l'app est cassée.

Étape par étape : choisissez les limites et formats dès le départ

La façon la plus rapide de définir des règles d'upload est de partir de l'action de l'utilisateur. « Uploader » n'est pas une chose unique. Un avatar, une photo produit et un reçu PDF ont des besoins différents. Si vous les traitez de la même façon, vous finissez souvent par permettre de gros fichiers partout.

Notez les actions d'upload que votre app supporte (ou supportera bientôt). Pour chacune, décidez de ce qui est « suffisant » à l'écran. La plupart des images sont affichées plus petites que ce que les gens pensent.

Une méthode simple en 5 étapes

1. Définissez le cas d'usage et où il apparaît (profil, carte d'annonce, galerie, admin uniquement, téléchargement uniquement).
2. Fixez une taille maximale de fichier qui correspond au comportement réel (ce que les utilisateurs uploadent réellement, pas ce qu'ils pourraient uploader).
3. Définissez des dimensions maximales en pixels pour les images (ça évite qu'un original 6000 x 4000 passe).
4. Choisissez un format par défaut et un petit ensemble de formats autorisés.
5. Ajoutez des limites pour prévenir les abus (nombre de fichiers par élément et stockage total par utilisateur).

Transformez ensuite ces choix en nombres précis. Gardez-les simples à comprendre et faciles à appliquer. Vous pouvez autoriser des limites plus strictes pour les images publiques et des limites plus larges pour les documents de preuve qui sont rarement chargés dans les flux.

Points de départ concrets que vous pouvez ajuster :

• Avatars : max 1 à 2 Mo, max 512 à 1024 px, sortie en WebP ou JPEG
• Photos produit : max 3 à 5 Mo, max 1600 à 2400 px, sortie en WebP (conserver JPEG comme option)
• Reçus (images) : max 5 à 10 Mo, max 2500 à 3500 px, sortie en JPEG ou WebP
• PDFs : max 10 à 20 Mo, conserver en PDF (ne pas convertir)
• Autres documents : max 10 à 20 Mo, autoriser uniquement ce dont vous avez vraiment besoin

Les formats sont le sujet où les équipes se compliquent trop la vie. Un défaut pratique : WebP pour les photos, JPEG en fallback, PNG seulement si vous avez besoin de transparence ou de graphiques UI nets.

Enfin, ajoutez des limites de « combien ». Exemple : jusqu'à 10 photos par produit, jusqu'à 50 pièces jointes par projet, plus un plafond total par utilisateur. Ces plafonds protègent la vitesse et les coûts, et réduisent le risque que votre stockage devienne une décharge.

Choisir des formats sans trop réfléchir

Vous n'avez pas besoin d'une stratégie parfaite. Il vous faut des valeurs par défaut qui gardent les pages légères et prévisibles, plus une ou deux exceptions.

Pour les photos, choisissez un défaut moderne. WebP est généralement le meilleur gain car il conserve un bon rendu pour des fichiers plus petits. Si WebP n'est pas possible pour un outil ou flux de travail précis, retombez sur JPEG. Réservez PNG aux cas où la transparence est nécessaire.

"PNG pour tout" est une erreur courante car PNG sert les bords nets et la transparence, pas les photos d'appareil. Une photo PNG peut être plusieurs fois plus lourde qu'une version WebP ou JPEG sans bénéfice visible. Ce poids supplémentaire se traduit par des flux plus lents, des pages produit plus lentes et des coûts de bande passante plus élevés.

SVG est différent. Il est excellent pour les icônes et logos simples car il reste net à n'importe quelle taille. Mais SVG est aussi un format document qui peut contenir des scripts et du contenu inattendu. Pour les uploads utilisateurs, autorisez SVG seulement si vous le nettoyez ou le convertissez en format sûr d'abord. Sinon, traitez SVG comme « ressources internes », pas comme « tout le monde peut uploader. »

Une cartographie simple à inclure dans votre spec :

• Avatars : WebP (ou JPEG), crop carré, pas de PNG sauf pour transparence
• Galerie ou photos produit : WebP d'abord, JPEG en secours, éviter PNG
• Captures d'écran : WebP pour la plupart, PNG seulement si le texte petit devient flou après compression
• Logos et icônes : SVG pour vos propres fichiers, PNG en secours quand SVG n'est pas possible
• Documents : PDF pour le partage, et bloquer par défaut les formats exécutables

Restez simple : un défaut pour les photos (WebP), un fallback (JPEG) et une exception (PNG pour transparence). Tout le reste est un cas spécial à décider volontairement.

Redimensionner et compresser pour que les pages restent rapides

Le moyen le plus rapide de ralentir une app est d'accepter de gros uploads puis de les servir partout. Une photo de téléphone peut faire 3 à 10 Mo. Si vous l'affichez dans une vue liste à 200 px de large, le navigateur téléchargera quand même le fichier complet à moins que vous ne créiez de plus petites versions.

Une approche pratique : redimensionner à l'upload et générer quelques tailles standard. Conservez l'original seulement si vous en avez vraiment besoin (édition, impression, téléchargement haute-résolution). Sinon, ne garder que « l'original géant » fait payer chaque page.

Un jeu de tailles simple

Choisissez des tailles qui correspondent à votre UI :

• Vignette (listes) : 200 à 300 px de large
• Image carte (grilles) : 600 à 800 px de large
• Image détail (pages produit) : 1200 à 1600 px de large
• Optionnel : original conservé seulement pour l'admin ou le téléchargement

Faites ensuite en sorte que votre app utilise les vignettes dans les listes et la taille détail sur les pages détaillées. Cette décision donne souvent le plus grand gain en temps de chargement.

Paramètres de qualité, en clair

La compression est un compromis : fichier plus petit vs image plus nette. La plupart des gens ne voient pas la différence entre « haut » et « très haut » sur un écran standard, mais ils ressentent une page plus lente.

Visez le fichier le plus petit qui reste correct à la taille affichée. Si une photo produit à 1200 px est satisfaisante à 250–400 Ko, il y a rarement une raison de l'envoyer à 2 Mo.

La compression côté client peut aider parce que les utilisateurs uploadent moins et attendent moins. Mais ce n'est pas suffisant. Vous avez toujours besoin de contrôles et de traitements côté serveur car des utilisateurs peuvent contourner le navigateur, uploader depuis des scripts, ou envoyer des fichiers qui ne correspondent pas à ce qu'ils prétendent.

Exemple : une marketplace affiche 30 éléments sur la page d'accueil. Si chaque "vignette" est en réalité un original de 4 Mo, cette page peut devenir silencieusement 120 Mo. Si vous générez de vraies vignettes à l'upload, la même page peut tomber à quelques mégaoctets et paraître instantanée.

Faire respecter les règles aux bons endroits

Si vous n'appliquez les règles que dans un seul endroit, les utilisateurs trouveront un contournement. Appliquez les mêmes limites à trois niveaux : l'UI, le serveur et les paramètres de stockage/livraison.

1) Dans l'UI (utile, mais non fiable)

Les contrôles côté client évitent de faire perdre du temps à quelqu'un qui s'apprête à envoyer un fichier qui sera rejeté. Affichez les règles avant le choix du fichier et validez immédiatement après sélection.

Contrôles UI utiles :

• Type de fichier (basé sur l'extension et ce que le navigateur rapporte)
• Taille du fichier
• Dimensions de l'image
• Nombre de fichiers
• Aperçu clair de ce qui sera uploadé

Considérez les contrôles UI comme une aide à l'utilisateur. N'importe qui peut les contourner avec des requêtes personnalisées.

2) Côté serveur (le vrai gardien)

La validation serveur est incontournable. Vérifiez tout à nouveau, même si le client a déjà vérifié.

Au minimum, validez :

• Le type en inspectant le contenu réel du fichier (magic bytes), pas seulement le nom de fichier
• Les limites de taille (rejeter clairement les uploads trop volumineux)
• Les dimensions d'image (rejeter les tailles de pixels énormes qui peuvent faire monter la mémoire lors du traitement)
• Le nombre par requête (pour éviter les abus et ralentissements)
• La sécurité des noms de fichiers (générez vos propres noms et supprimez les caractères risqués)

Bloquez aussi les types risqués dont vous n'avez pas besoin. Une bonne règle : n'autorisez que ce que votre produit supporte réellement.

3) Dans les paramètres de stockage et de livraison (éviter les erreurs coûteuses)

Vos paramètres de stockage doivent renforcer vos règles. Assurez-vous que les uploads ne sont pas écrits publiquement, et garantissez que votre app sert les bonnes versions (par exemple les images redimensionnées) au lieu de l'original. Si vous stockez des originaux, séparez-les de ce que vous affichez sur les pages.

Rendez les messages d'erreur spécifiques. "Upload failed" génère des tickets support. "JPEG, PNG ou WebP seulement, jusqu'à 5 Mo, max 3000 x 3000" indique à l'utilisateur quoi corriger.

Erreurs courantes qui ralentissent et exposent au risque

La plupart des problèmes d'upload viennent du fait que la première version fonctionne, donc personne ne la retouche. Des mois plus tard, les pages sont lourdes, les coûts de stockage grimpent et vous découvrez des failles de sécurité dans la chaîne d'upload.

Les erreurs qui causent le plus de dégâts :

• Autoriser "n'importe quel fichier" pour débloquer la fonctionnalité. Si les utilisateurs peuvent tout uploader, vous finirez par tout supporter.
• Faire confiance à ce que le navigateur dit du fichier. Extensions et MIME types côté client sont faciles à falsifier.
• Ne vérifier que la taille en octets, pas les dimensions. Une image de 1–2 Mo peut faire 8000 x 8000 pixels.
• Servir les uploads originaux directement dans l'UI. L'original est rarement la bonne chose à montrer dans les listes, grilles et pages détaillées.
• Mettre les uploads dans votre base de données principale. Les bases sont idéales pour les métadonnées, pas pour les blobs binaires volumineux.

Ces erreurs créent aussi des risques de sécurité : formats non sûrs, malwares cachés, ou fuite de données privées via les métadonnées EXIF. Des règles de validation basiques (type, taille, dimensions et traitement sûr) gardent les performances prévisibles et réduisent les mauvaises surprises.

Checklist rapide à copier dans votre spec

Écrivez ces règles maintenant et vous éviterez pages lentes, factures de stockage énormes et erreurs d'upload confuses plus tard. Collez ceci dans votre spec et ajustez les chiffres selon votre app.

Règles de base :

• Limites (par type) : Images max 5 Mo chacune. Documents (PDF, DOCX) max 15 Mo chacun. Total par action d'upload max 25 Mo. Si vous supportez vidéo ou audio, définissez des limites séparées au lieu de "n'importe quoi".
• Images (dimensions + formats) : Max 3000 x 3000 px. Autorisés : JPEG, PNG, WebP. Bloquez HEIC sauf si vous le convertissez côté serveur.
• Livraison (tailles que vous servirez réellement) : Générez toujours (1) une vignette pour les listes (par exemple 300 px de large) et (2) une taille détail pour la vue complète (par exemple 1200 px de large). Ne chargez pas les originaux dans les listes ou grilles.
• Sécurité (ce que vous refusez et ce que vous nettoyez) : Bloquez les uploads exécutables et scriptés (EXE, JS, SH, BAT, MSI). Ne faites jamais confiance aux extensions. Validez le type réel du fichier.
• Expérience utilisateur (ce que voit l'utilisateur) : Affichez une erreur claire avec la limite et la solution.

Un message d'erreur simple qui réduit le support :

"Le fichier fait 9,2 Mo. La limite pour les images est 5 Mo. Essayez d'exporter en WebP ou JPEG à 1200 px de large, puis réessayez."

Exemple : des photos produit qui ralentissent silencieusement toute l'app

Une histoire commune : vous lancez une petite marketplace avec 20 annonces. Chaque vendeur upload quelques photos et tout va bien. Quelques mois plus tard vous avez 5 000 annonces, et soudain les pages d'annonces sont lourdes. Les messages au support se ressemblent : "La page met une éternité", "Ça marche en Wi‑Fi mais pas sur mon téléphone", "L'app freeze quand je fais défiler."

Le coupable est souvent simple : les vendeurs uploadent des photos de 10 à 20 Mo directement depuis leur téléphone. Une annonce peut avoir 6 photos, donc un seul chargement de page peut devenir 60 à 120 Mo d'images si vous n'y prenez pas garde.

Avant : pas de règles (ou des règles dans la tête de quelqu'un)

Les vendeurs uploadent ce qu'ils ont. Certaines photos sont énormes, d'autres mal cadrées, d'autres au mauvais format. Votre app montre des images pleine taille là où il ne faut qu'un petit aperçu. Les pages ralentissent à mesure que l'inventaire grandit, et vous finissez par débattre si "l'app est lente" ou "la connexion utilisateur est lente".

Après : des règles simples qui gardent tout rapide

Il ne faut pas de politiques compliquées, mais quelques garde‑fous :

• Limiter les uploads d'images (ex : 5 Mo par image)
• Convertir les uploads en WebP (conserver JPEG, PNG seulement si nécessaire)
• Générer plusieurs tailles (vignette, carte, plein) et servir la bonne
• Limiter le nombre de photos par annonce (ex : 8 à 12)

Concrètement, cela transforme une photo téléphone de 15 Mo en un WebP plus léger plus une vignette légère. Les pages d'annonces redeviennent réactives car elles chargent de nombreuses petites vignettes plutôt que quelques originaux massifs.

Prochaines étapes : définissez les règles maintenant, puis nettoyez l'existant

Commencez par regarder ce que vous avez vraiment, pas ce que vous pensez avoir. Prenez 20 à 50 uploads récents (mélange d'images et d'autres fichiers) et notez pour chacun : type de fichier, taille, et où il apparaît dans l'app. Ensuite, chargez votre page la plus lente sur une connexion mobile ordinaire et notez le temps jusqu'à ce qu'elle semble utilisable.

Cherchez les fichiers bien plus gros que ce que l'écran nécessite. Une photo produit « simple » peut être un PNG de 6 Mo qui n'est affiché qu'en vignette. Ce fichier peut ajouter silencieusement des secondes à chaque vue de page.

Une fois que vous avez des données réelles, concentrez‑vous sur les quelques règles qui évitent la plupart des problèmes :

• Fixer des limites de taille claires (caps distincts pour images et documents)
• Verrouiller les formats autorisés (seulement ce que vous supportez réellement)
• Ajouter redimensionnement et compression pour les images (automatique à l'upload)
• Durcir la validation (vérifier type, taille et contenu, pas seulement le nom de fichier)
• Définir un fallback (que faire quand un upload est rejeté)

Déployez doucement pour ne pas casser les utilisateurs existants. Appliquez d'abord les nouvelles règles aux uploads nouveaux, et enregistrez ce qui aurait été rejeté pour voir l'impact avant de tout faire respecter. Puis planifiez le nettoyage des anciens fichiers : identifiez les 10 % les plus lourds, générez des versions web‑compatibles et supprimez les doublons inutiles.

Si vous avez hérité d'une base de code générée par l'IA, les problèmes s'accumulent souvent au niveau des uploads : règles incohérentes, contrôles serveur manquants, secrets exposés, et pages qui ralentissent avec la croissance du contenu. FixMyMess (fixmymess.ai) réalise des diagnostics et des réparations de codebase pour les apps créées par IA, y compris le durcissement de la validation d'upload, le redimensionnement et la sécurisation.

Terminez en rédigeant vos règles en phrases simples dans votre spec. Si un nouveau membre peut les suivre sans vous poser de questions, c'est bon.