Chaque développeur a ce problème qu’il continue de rencontrer — celui qui le suit de projet en projet, d’entreprise en entreprise. Pour moi, c’était l’upload de fichiers.
Pas le genre simple. Pas « choisir un fichier, l’envoyer en POST à un serveur, terminé. » Je parle du genre où les utilisateurs envoient des milliers d’images qui doivent être redimensionnées, des vidéos à transcoder, des documents à analyser — tout en affichant une progression en temps réel sur une application mobile avec une connexion instable.
Après avoir passé près d’une décennie en tant que CTO à construire des applications à forte composante média, je peux affirmer avec certitude : l’état du traitement de fichiers dans l’écosystème JavaScript est cassé depuis longtemps. Uploadista est ma tentative d’y remédier.
Le problème que je résolvais (encore et encore)
Dans ma première startup, nous construisions une marketplace où les vendeurs uploadaient des photos de produits. Assez simple, non ? Nous avons commencé avec un endpoint Express basique et Multer. En quelques semaines, nous avions besoin de redimensionner les images. Puis d’ajouter des filigranes. Puis de convertir les formats pour mobile. Puis d’analyser les virus parce qu’un utilisateur avait uploadé un PDF malveillant.
Chaque nouvelle exigence signifiait greffer une autre bibliothèque, un autre service, un autre point de défaillance. Notre pipeline d’upload est devenu un fouillis inextricable de callbacks et de workers de queue. Quand quelque chose échouait à mi-traitement, nous avions des fichiers orphelins dispersés sur S3, des miniatures à moitié générées, et aucun moyen de relancer uniquement l’étape qui avait échoué.
Alors on réécrivait tout. On réécrivait toujours tout.
Dans l’entreprise suivante, nous avons adopté un CDN d’images populaire. L’API était bonne, les transformations puissantes. Mais une fois passé un certain seuil de volume, les factures sont devenues imprévisibles. Notre équipe financière ne pouvait pas établir de budget — frais de bande passante ici, crédits de transformation là, frais de stockage par-dessus. On passait plus de temps à modéliser les coûts dans des tableurs qu’à développer des fonctionnalités.
Sur un troisième projet — une plateforme sociale mobile-first — nous avions besoin d’expériences d’upload natives sur iOS et Android. Des uploads reprises sur des connexions instables. Des uploads en arrière-plan survivant aux changements d’application. Un suivi de progression vraiment précis. Les bibliothèques JavaScript existantes ? Elles étaient conçues pour le navigateur. Le mobile était une réflexion après coup, si tant est qu’on y ait pensé.
Ce que j’ai essayé (et pourquoi ça n’était pas suffisant)
Je les ai tous utilisés — les uploaders open source populaires pour navigateur, les bibliothèques UI soignées, les services managés TypeScript-first plus récents, les plateformes de traitement en pipeline complet.
Les meilleurs uploaders open source pour navigateur sont vraiment impressionnants : modulaires, bien conçus, avec de riches écosystèmes de plugins pour les intégrations de stockage cloud. Mais quand j’avais besoin de chaîner des étapes de traitement — redimensionner, puis filigrane, puis convertir en WebP, puis router vers plusieurs fournisseurs cloud — je me retrouvais à écrire du code d’orchestration personnalisé. La composition de pipelines n’était pas leur raison d’être.
Les bibliothèques orientées UI sont un plaisir à intégrer. En quelques minutes, vous avez une expérience d’upload soignée. Mais elles s’arrêtent à la frontière du navigateur. Le traitement côté serveur, l’orchestration du pipeline, le routage multi-cloud — tout ça reste votre problème.
Les services managés plus récents ont rendu l’intégration avec les frameworks incroyablement simple, et j’admire sincèrement ce que leurs équipes ont construit pour l’expérience développeur. Mais ils ont tendance à être couplés à leur propre infrastructure d’hébergement. J’avais besoin de pouvoir apporter mon propre stockage — parce que mes clients avaient des exigences de résidence des données dans l’UE, et « vos fichiers vivent sur nos serveurs » n’était pas une option.
Les plateformes de traitement en pipeline plus puissantes offrent une orchestration complète et des tonnes d’intégrations. Mais les modèles de tarification à grande échelle peuvent être difficiles à prévoir, et le support TypeScript donne souvent l’impression d’avoir été ajouté après coup — de simples wrappers sur des API REST, sans validation à la compilation des définitions de pipeline.
Chaque outil résolvait une partie du puzzle, mais aucun ne résolvait l’ensemble.
Le déclic
L’idée d’Uploadista a cristallisé lors d’un sprint particulièrement douloureux. Nous construisions une plateforme de contenu qui devait :
- Accepter des uploads depuis le web, iOS et Android
- Analyser les fichiers pour détecter les malwares
- Extraire les métadonnées
- Générer plusieurs tailles d’images
- Convertir les vidéos en HLS pour le streaming
- Stocker les originaux dans le bucket S3 du client (exigence RGPD)
- Stocker les versions traitées dans notre CDN
- Suivre l’ensemble du pipeline avec une progression en temps réel
Nous avions sept services différents assemblés avec des queues SQS et des fonctions Lambda. Quand l’étape 4 échouait, il fallait déterminer manuellement quels fichiers étaient bloqués, les retraiter, et espérer que les étapes en aval reprendraient là où elles s’étaient arrêtées. Le débogage impliquait de jongler entre les logs CloudWatch de six fonctions différentes.
Je me souviens avoir pensé : pourquoi n’existe-t-il pas un framework où je peux définir l’intégralité de ce pipeline comme un flux typé et composable ? Où chaque étape est une fonction pure qui transforme une entrée en sortie ? Où les nouvelles tentatives, la gestion des erreurs et le suivi de progression sont intégrés ? Où je peux l’exécuter localement pour le développement et le déployer sur n’importe quel cloud pour la production ?
Ce soir-là, j’ai commencé à esquisser ce qui deviendrait l’architecture orientée flux d’Uploadista.
Ce que nous avons construit (et pourquoi c’est différent)
Uploadista est construit autour d’une idée centrale : le traitement de fichiers est un problème de pipeline, pas un problème d’upload.
L’upload lui-même — transférer des octets d’un client vers un serveur — c’est la partie facile. La partie difficile, c’est ce qui se passe ensuite. Et ce « ce qui se passe ensuite » devrait s’exprimer comme un flux typé, composable et observable.
Voici ce à quoi cette philosophie a conduit :
Traitement orienté flux. Au lieu d’écrire du code impératif qui appelle service après service, vous définissez un flux — un graphe orienté d’étapes de traitement. Chaque étape a des entrées et sorties typées. Le framework gère l’orchestration, les nouvelles tentatives et le parallélisme. Si l’étape 3 sur 5 échoue, seule l’étape 3 est relancée lors d’une nouvelle tentative. Pas de fichiers orphelins. Pas de nettoyage manuel.
TypeScript-first, pas TypeScript-compatible. Le SDK est construit avec TypeScript depuis le début, en utilisant Effect-TS pour une gestion robuste des erreurs. Vos définitions de pipeline sont entièrement typées. Si vous passez un fichier vidéo à un processeur d’images, le compilateur le détecte. Si une étape produit une miniature et que l’étape suivante attend une image haute résolution, vous le savez à la compilation, pas à 3h du matin en production.
BYOS — Apportez votre propre stockage. Vos fichiers, vos buckets, vos règles. Connectez votre S3, Google Cloud Storage ou Azure Blob Storage. Nous ne stockons jamais vos données. Pour les entreprises ayant des exigences de résidence des données, ce n’est pas une fonctionnalité — c’est un prérequis.
SDKs mobiles natifs. Pas des wrappers WebView. Des SDKs natifs iOS, Android, Flutter et React Native avec des uploads reprises, le support de transfert en arrière-plan et un suivi de progression précis qui fonctionne sur des connexions mobiles instables. Parce qu’en 2026, le mobile n’est pas une plateforme secondaire — c’est la plateforme principale.
Tarification prévisible. Une seule métrique : les exécutions de flux. Pas de tarification par nœud, pas de surprises de bande passante, pas de crédits de transformation. Vous exécutez un flux, vous payez pour un flux. Votre équipe financière peut enfin établir un budget.
Ce qui nous attend
Uploadista est disponible dès aujourd’hui — vous pouvez vous inscrire et déployer votre premier pipeline maintenant. Les retours de nos premiers utilisateurs sont précis et inestimables, et façonnent activement tout, de la surface d’API aux messages d’erreur.
Le constructeur de flux visuel avance bien. Il permettra de concevoir des pipelines de traitement en glissant-déposant des étapes sur un canevas, avec le code TypeScript généré automatiquement. Pensez-y comme le meilleur des deux mondes : visuel pour le prototypage et la compréhension, code pour le contrôle de version et le CI/CD.
Nous investissons également massivement dans la documentation et l’expérience développeur. Chaque message d’erreur devrait vous dire ce qui s’est passé et comment le corriger. Chaque API devrait avoir des exemples qui fonctionnent vraiment. L’autocomplétion TypeScript devrait vous guider à travers l’ensemble du SDK sans jamais avoir à ouvrir une page de documentation.
Une note sur l’open source
Le SDK Uploadista principal est sous licence MIT et le restera toujours. Je crois que les outils d’infrastructure doivent être transparents. Vous devriez pouvoir lire le code qui gère vos fichiers, auditer le modèle de sécurité et contribuer des améliorations. La plateforme cloud (Uploadista Cloud) est là où nous construisons notre activité — infrastructure gérée, le constructeur visuel, collaboration d’équipe, monitoring. Mais le moteur en dessous est ouvert.
Ce n’est pas de l’altruisme. C’est du pragmatisme. Les meilleurs outils développeurs gagnent la confiance par la transparence. Et la confiance, c’est ce qui pousse un développeur à choisir votre framework pour son prochain système en production.
Essayez par vous-même
Si tout cela vous parle — si vous avez ressenti la même frustration en construisant du traitement de fichiers à grande échelle — je serais ravi que vous testiez Uploadista. Consultez la documentation, parcourez le SDK sur GitHub, ou inscrivez-vous sur Uploadista Cloud — aucune carte bancaire requise.
Et si vous avez des questions, des opinions ou des anecdotes sur les uploads de fichiers, je veux les entendre. Les meilleurs produits se construisent en conversation avec ceux qui les utilisent.
Denis est le fondateur et CEO d’Uploadista. Il a précédemment occupé le poste de CTO dans plusieurs startups développant des applications à forte composante média. Vous pouvez le retrouver sur Twitter/X ou GitHub.