Tout pipeline de traitement de fichiers commence par un dessin.
Quelqu’un le griffonne au tableau : une boîte pour l’upload, une flèche vers l’antivirus, un embranchement pour les images et les PDF, deux flèches vers le stockage. Tout le monde acquiesce. Puis le tableau est effacé, et les trois semaines suivantes passent à traduire ce dessin en workers de file d’attente, en handlers Lambda et en logique de retry éparpillée dans six fichiers. Six mois plus tard, plus personne ne sait répondre à « que se passe-t-il exactement quand un utilisateur envoie un PDF ? » sans relire le code.
Le constructeur de flux visuel d’Uploadista Cloud supprime cet écart. Le dessin est le pipeline.
Le canvas
Ouvrez un flux dans le tableau de bord et vous obtenez un canvas avec une bibliothèque de nœuds sur la gauche. Glissez un nœud sur le canvas, déposez-le où vous voulez, tirez une connexion depuis la sortie d’un nœud vers l’entrée du suivant. Voilà tout le modèle d’interaction.
La bibliothèque est organisée par ce que les nœuds font réellement :
- Input — le point d’entrée des fichiers, sous forme de flux depuis un client ou depuis une URL.
- Traitement média — regroupé en Image (redimensionner, transformer, optimiser, supprimer l’arrière-plan, décrire), Vidéo (transcoder, redimensionner, découper, générer une miniature, décrire) et Document (OCR, extraction de texte, découper un PDF, fusionner des PDF, décrire, convertir en Markdown).
- Contrôle de flux — multiplex pour dupliquer un fichier vers plusieurs branches, merge pour les réunir, un routeur conditionnel pour envoyer les fichiers sur des chemins différents, et passthrough quand un fichier doit continuer sans transformation.
- Archive — compresser des fichiers dans une archive zip.
- Sécurité — analyse antivirus et anti-malware avec ClamAV.
Les nœuds qui font appel à l’IA — suppression d’arrière-plan, description d’images et de vidéos, OCR — côtoient directement les nœuds déterministes. Du point de vue du canvas, il n’y a aucune différence : un nœud prend des fichiers en entrée et produit des fichiers en sortie.
Un vrai pipeline, en deux minutes
Voici un flux que j’ai construit en écrivant cet article. Un utilisateur joint un document ou une photo à un ticket de support :
- Input reçoit le fichier.
- Scan Virus l’analyse. Rien ne s’exécute en aval sur un fichier infecté.
- Routeur conditionnel examine le type du fichier. Les images partent d’un côté, les PDF de l’autre.
- Sur la branche image, un nœud Multiplex copie le fichier sur deux chemins : Resize pour une miniature 400×400 façon avatar, et Optimize pour une version web en WebP à qualité 80.
- Sur la branche PDF, OCR extrait le texte, puis Convert to Markdown produit un contenu indexable.
Cinq minutes de glisser-déposer, et le pipeline n’est pas seulement documenté : il tourne.
Le routeur conditionnel mérite un arrêt, car c’est là que vit l’essentiel de la logique d’aiguillage. Vous choisissez un champ (type, taille, largeur, hauteur ou extension), un opérateur (=, ≠, >, <, contient, commence par) et une valeur. « Type = Images » envoie tout fichier image/* sur la branche vraie. Aucun langage d’expression à apprendre, aucune regex à rater à 2 h du matin.
Configurer les nœuds sans ouvrir la documentation
Cliquez sur un nœud et un panneau de configuration s’ouvre à côté du canvas. Chaque type de nœud a son panneau dédié : le nœud resize demande des dimensions et un mode d’ajustement, le nœud transcode demande un format et un codec, le nœud split PDF demande des plages de pages. Ce sont exactement les options exposées par le SDK — simplement présentées sous forme de champs plutôt que d’un objet dont il faut se rappeler la forme.
Deux options reviennent sur la plupart des nœuds et méritent d’être comprises :
Nommage des fichiers. Le mode auto ajoute un suffixe propre au nœud : photo.jpg devient photo-800x600.jpg après un redimensionnement. Ou vous reprenez la main et définissez votre propre modèle.
Keep output. Désactivé par défaut : la sortie du nœud est stockée mais pas renvoyée dans le résultat du flux, ce qui limite la consommation mémoire. Activez-le quand vous voulez récupérer les octets — pour les chaîner, ou simplement pour les inspecter.
Une convention évite beaucoup de câblage : tout nœud sans connexion sortante est un sink, et sa sortie est automatiquement persistée vers votre stockage cible. Inutile de glisser un nœud de stockage au bout de chaque branche. Laissez une branche ouverte et son résultat est enregistré. Prolongez-la et le traitement continue.
Tester avant de déployer
Un pipeline qu’on peut voir, c’est utile. Un pipeline qu’on peut exécuter avant de le déployer, c’est tout l’intérêt.
Le constructeur intègre un panneau de test. Déposez un vrai fichier dans le nœud d’entrée et le flux s’exécute pour de bon — même moteur, mêmes nœuds, même stockage. La progression remonte en temps réel via WebSockets : la barre d’upload se remplit, puis chaque nœud s’allume au moment où il devient l’étape active, et vous suivez le fichier traverser le graphe. À la fin, vous obtenez les sorties, avec des aperçus pour les images, le texte OCR et les descriptions générées par IA.
En cas d’échec, l’erreur apparaît sur un nœud précis, sous vos yeux, rattachée à ce nœud — pas enfouie dans les logs d’une fonction qu’il faut d’abord retrouver.
Du canvas à la production
Quand le flux fait ce que vous voulez, enregistrez-le et activez-le. Il reçoit un identifiant de flux, et cet identifiant constitue toute la surface d’intégration :
import { Flow } from "@uploadista/react";
function TicketAttachment() {
return (
<Flow
flowId="support-attachment"
storageId="your-storage-id"
onSuccess={(outputs) => attachToTicket(outputs)}
>
<Flow.DropZone accept="image/*,application/pdf">
{({ isDragging, getRootProps, getInputProps }) => (
<div {...getRootProps()}>
<input {...getInputProps()} />
{isDragging ? "Déposez votre fichier" : "Cliquez ou glissez pour envoyer"}
</div>
)}
</Flow.DropZone>
<Flow.Status>
{({ status, currentNodeName }) => (
<p>{status === "processing" ? `Traitement : ${currentNodeName}` : status}</p>
)}
</Flow.Status>
</Flow>
);
}Remarquez currentNodeName. Les noms de nœuds que vous avez saisis sur le canvas reviennent dans votre interface à l’exécution : « Analyse antivirus » et « Extraction du texte » deviennent des chaînes affichables, plutôt qu’un spinner générique.
Modifier le pipeline plus tard ne touche pas à ce code. Ajoutez un nœud, retestez, enregistrez — l’identifiant du flux reste stable et votre application continue d’appeler la même chose.
Le visuel et le code sont le même graphe
C’est le point qui me tient le plus à cœur, et celui qui fait du constructeur autre chose qu’un gadget.
Le canvas ne génère pas une boîte noire. Un flux est un graphe orienté de nœuds typés et d’arêtes — exactement ce que produit createFlow dans le SDK open source :
export const resizeFlow = createFlow({
flowId: "resize-image",
name: "Resize Image",
nodes: {
input: createInputNode("input"),
resize: createResizeNode("resize", { width: 800, height: 600, fit: "cover" }),
optimize: createOptimizeNode("optimize", { quality: 85 }),
},
edges: [
{ source: "input", target: "resize" },
{ source: "resize", target: "optimize" },
],
});Des nœuds, des arêtes, de la configuration. Les trois mêmes choses que vous déplacez sur le canvas. Le constructeur est un autre éditeur pour le même modèle, pas un autre système.
Vous n’avez donc pas à choisir un camp. Prototypez visuellement parce qu’on pense plus vite comme ça, puis gardez le flux dans le tableau de bord où une personne non développeuse peut le lire. Ou définissez vos flux en TypeScript, versionnez-les dans git et bénéficiez d’une validation à la compilation sur chaque définition de pipeline. Les équipes à qui j’en ai parlé finissent par faire les deux : le constructeur visuel pour explorer et pour les pipelines qui changent souvent, le code pour ceux qui sont critiques et doivent passer par la revue.
Quelle que soit la méthode, le runtime est le même — le moteur de flux gère l’orchestration, les retries par nœud, le streaming pour les gros fichiers et les événements de progression. Quand l’étape 3 sur 5 échoue, c’est l’étape 3 qui est rejouée.
Ce que « sans code » veut vraiment dire
Je veux être précis ici, parce que le « no-code » est une promesse galvaudée.
Vous écrivez toujours du code pour déclencher un flux. Vous écrivez toujours du code pour exploiter les résultats. Ce que le constructeur supprime, c’est la couche d’orchestration — la plomberie des files d’attente, le séquencement des étapes, la comptabilité des retries, l’archéologie du « quel service possède cette transformation ». C’est là que se concentre l’essentiel de la complexité du traitement de fichiers, et c’est la couche qui n’a presque rien à voir avec votre produit.
Le pipeline devient une chose qu’on regarde. Un designer peut l’ouvrir et le comprendre. Un ingénieur support peut vérifier ce qui arrive à un PDF sans solliciter un développeur backend. Et la réponse à « que se passe-t-il quand un utilisateur envoie un fichier ? » est une image forcément exacte, puisque c’est elle qui s’exécute.
Essayez-le
Le constructeur visuel est disponible dès aujourd’hui dans Uploadista Cloud. Créez un compte — sans carte bancaire —, connectez un bucket de stockage et construisez votre premier flux. La documentation détaille chaque nœud et ses options, et le moteur sous-jacent est sous licence MIT et disponible sur GitHub si vous préférez définir vos flux en TypeScript.
Si vous construisez quelque chose d’intéressant sur le canvas, montrez-le-moi. La bibliothèque de nœuds s’enrichit en fonction de ce que les gens essaient d’en faire.