Ajouter le téléversement de fichiers semble simple : l’utilisateur sélectionne un document et l’envoie. Pourtant, ce choix a des conséquences sur l’expérience utilisateur, la sécurité, les coûts opérationnels et la capacité du produit à évoluer. Une image occasionnelle dans un formulaire ne pose pas les mêmes exigences que des centaines de vidéos volumineuses ou des documents à examiner avant leur mise à disposition.
La question essentielle n’est pas de savoir quelle architecture est la plus moderne, mais quels composants doivent recevoir les données et quels contrôles appliquer à chaque fichier avant de le considérer comme valide. Dans de nombreux produits, le choix consiste à faire transiter le fichier par le serveur de l’application ou à permettre au navigateur de le téléverser directement vers un stockage d’objets, avec une autorisation délivrée par le serveur.
Définir le flux avant de choisir l’architecture
Commencez par décrire ce qui se passe entre la sélection d’un fichier par l’utilisateur et le moment où une autre partie du produit peut l’utiliser. Identifiez qui le téléverse, les formats acceptés, la taille maximale raisonnable, la possibilité de téléversements simultanés et ce qui se passe après la réception. Déterminez également si le fichier doit être disponible immédiatement ou attendre un examen, une conversion ou une analyse.
Il est utile de distinguer trois notions souvent confondues : recevoir le fichier, le stocker et l’approuver pour utilisation. La réussite d’un transfert ne prouve ni que le contenu est sûr, ni qu’il appartient à l’utilisateur, ni qu’il respecte les règles du produit. En séparant ces étapes dans le flux, il est plus facile de faire évoluer l’architecture sans modifier les règles métier.
- Si le fichier accompagne seulement une opération simple et de faible ampleur, privilégiez un parcours facile à développer et à exploiter.
- Si la taille, le volume ou la durée des transferts sont importants, étudiez comment éviter de faire passer tout le trafic par l’application.
- Si le fichier doit être examiné, traité ou approuvé, modélisez explicitement cet état au lieu de supposer qu’il est prêt dès la fin du téléversement.
Faire transiter le fichier par le serveur de l’application
Dans ce modèle, le navigateur envoie le fichier à un point d’accès de l’application. Le serveur authentifie la requête, applique les contrôles, puis enregistre le contenu dans le stockage choisi. La logique est souvent facile à comprendre, car le téléversement passe par le même point que les autres opérations du produit.
Cette option convient lorsque les fichiers sont petits ou de taille moyenne, que le volume prévu est limité et qu’il faut valider chaque requête dans le cadre d’un flux métier précis. Elle peut également être pratique pour une première version : il y a moins de composants visibles à coordonner et le serveur peut associer la réception à un compte ou à un enregistrement sans exposer au navigateur un accès direct au stockage.
La limite apparaît lorsque le serveur devient l’intermédiaire de grandes quantités de données. L’application doit maintenir des connexions longues et transférer le contenu, même si sa fonction principale n’est pas de le stocker. Cela peut mobiliser des ressources, concurrencer les requêtes ordinaires et rendre les délais d’attente et les coupures de connexion plus problématiques. Vérifiez les limites de taille et de durée sur l’ensemble du parcours, notamment dans le navigateur, les mandataires, le serveur et le stockage final : ajuster un seul élément ne supprime pas les limites des autres.
Téléversement direct vers un stockage d’objets
Lors d’un téléversement direct, le navigateur transfère le fichier vers le stockage sans faire transiter son contenu par le serveur de l’application. Le serveur reste indispensable : il authentifie l’utilisateur, décide s’il peut téléverser, définit les conditions de l’opération et indique comment terminer le flux. L’application ne doit pas se fier aux données du navigateur pour déterminer seule quel utilisateur est autorisé ou quel emplacement peut être utilisé.
Cette approche peut réduire la charge de transfert sur les serveurs de l’application. Elle est utile en présence de fichiers volumineux, de nombreux téléversements ou de connexions prolongées. En contrepartie, le produit doit coordonner plusieurs étapes : réserver ou identifier un téléversement, autoriser le transfert, en recevoir le résultat et mettre à jour l’état du fichier. En cas d’erreur intermédiaire, le transfert peut être terminé dans le stockage alors que l’enregistrement de l’application n’a pas été mis à jour, ou inversement.
Prévoyez donc des états explicites, par exemple en attente, reçu, en cours d’examen et disponible, et définissez comment les réconcilier. Les autorisations doivent avoir une portée limitée et une durée de validité restreinte. N’exposez pas d’identifiants permanents et ne laissez pas une autorisation temporaire permettre plus d’opérations ou donner accès à davantage d’emplacements que nécessaire. Cette approche ajoute des responsabilités d’intégration et d’exploitation ; elle n’est pas automatiquement plus sûre ni plus simple.
Critères pratiques de décision
Comparez les deux options à partir des données du produit et des contraintes réelles, plutôt que de prévisions optimistes. L’architecture peut évoluer : il est raisonnable de commencer par un parcours simple si le risque est maîtrisé, à condition d’en connaître les limites et de définir un signal clair pour le réévaluer.
- Taille et volume : plus les fichiers sont volumineux et les téléversements simultanés nombreux, plus il importe d’éviter que l’application transporte chaque octet. Concevez les scénarios critiques en fonction des limites maximales du produit, et non de la taille moyenne.
- Connectivité : les coupures, les réseaux lents et la fermeture accidentelle de la page affectent davantage les transferts longs. Évaluez si une reprise depuis le début suffit ou si le produit doit permettre des transferts reprenables ; ne promettez pas cette possibilité si elle n’est pas mise en œuvre de bout en bout.
- Sécurité et règles métier : déterminez si l’autorisation doit dépendre de l’utilisateur, de l’entité ou de l’étape du processus, et si le contenu doit rester inaccessible jusqu’à sa validation.
- Traitement ultérieur : si des informations doivent être extraites, des variantes créées ou le contenu examiné, concevez le traitement comme une étape indépendante et gardez la possibilité d’informer l’utilisateur de son état.
- Exploitation : comparez la complexité que l’équipe peut prendre en charge, notamment les autorisations, les alertes, le nettoyage des objets orphelins et la gestion des défaillances partielles.
Validation et protection des fichiers
Validez la demande avant d’accepter le téléversement, puis effectuez les vérifications nécessaires après réception. Au début du processus, vérifiez l’identité, les autorisations, la taille permise, le nombre de fichiers et leur lien avec l’opération demandée. Sur le serveur ou dans un processus de confiance, examinez le contenu reçu : le nom et le type déclarés par le navigateur ne suffisent pas à confirmer ce qu’il contient.
Limitez les accès afin qu’un fichier privé ne soit pas rendu public par accident. Utilisez des références internes au lieu de transformer un chemin ou un nom fourni par l’utilisateur en autorisation. Si le produit permet de télécharger des fichiers, déterminez qui peut le faire et pendant combien de temps ; les liens temporaires ne doivent pas remplacer la vérification des autorisations dans le flux qui les génère.
Les fichiers non fiables peuvent également mobiliser des ressources ou contenir des éléments inattendus. Limitez les tailles et les formats en fonction des besoins réels, évitez de les traiter avec des privilèges inutiles et gardez-les isolés jusqu’à la fin des vérifications pertinentes. Si l’usage présente des risques particuliers, consultez les recommandations de sécurité applicables au type de fichier et au contexte du produit.
Expérience utilisateur et exploitation au quotidien
Une barre de progression n’est utile que si elle fournit des informations compréhensibles et ne masque pas un blocage. Indiquez l’état de chaque fichier, permettez l’annulation lorsque c’est possible et proposez une action claire en cas d’échec. Définissez les erreurs qui autorisent une nouvelle tentative et évitez qu’elle crée des doublons ou laisse plusieurs versions qui semblent valides. Pour les processus longs, indiquez que le téléversement est terminé et que le fichier reste en cours d’examen, plutôt que de présenter ces deux étapes comme une seule.
En production, surveillez les taux de réussite et d’échec, la durée des téléversements, les abandons et les erreurs de validation. Consignez les identifiants d’opération et les états, mais évitez d’inclure dans les journaux du contenu sensible ou des données inutiles au diagnostic. Définissez une politique pour les téléversements incomplets et les fichiers en attente qui ne sont plus nécessaires : sans nettoyage, ils entraînent du désordre, des coûts et des incertitudes sur la version en vigueur.
Liste de vérification avant la mise en œuvre
- Documentez les tailles, les formats, le volume et les autorisations attendus, y compris les valeurs maximales.
- Choisissez entre un passage par le serveur et un téléversement direct selon la charge de transfert et les capacités opérationnelles de l’équipe.
- Définissez les états du téléversement et les conditions permettant d’utiliser ou de télécharger un fichier.
- Testez les fichiers trop volumineux, les formats non autorisés, les déconnexions, les répétitions de requêtes et les échecs de mise à jour de l’enregistrement.
- Vérifiez qu’un utilisateur ne peut ni lire, ni remplacer, ni associer les fichiers d’une autre personne.
- Préparez des mesures, des alertes et le nettoyage des transferts incomplets.
En résumé, la meilleure architecture est celle qui répond aux exigences de sécurité et d’expérience utilisateur sans introduire une complexité que l’équipe ne peut pas exploiter. Pour de petits téléversements, le passage par l’application peut suffire. Pour des transferts volumineux ou fréquents, le téléversement direct peut la soulager, à condition de bien concevoir l’autorisation, les états et la réconciliation. La décision doit être réévaluée si la taille des fichiers, leur volume ou leur utilisation par le produit évoluent.