La règle est claire : utilisez les streams pour les GROS volumes ou les flux continus, et readFile/writeFile pour les petites données ponctuelles — la clé est la question de la MÉMOIRE et de la nature des données. Le problème que les streams résolvent : fs.readFile charge le fichier ENTIER en mémoire (dans une variable) avant que vous ne puissiez le traiter. Pour un petit fichier (quelques Ko, quelques Mo), c'est parfait et simple. Mais pour un GROS fichier (centaines de Mo, Go), c'est problématique : (1) vous consommez énormément de RAM (le fichier entier en mémoire) ; (2) au-delà d'une certaine taille, c'est impossible (vous dépassez la mémoire disponible, le programme plante) ; (3) même si ça passe, c'est du gaspillage (pourquoi charger 2 Go pour les traiter séquentiellement ?). Les streams traitent par MORCEAUX : la mémoire ne contient jamais qu'un petit morceau à la fois, quelle que soit la taille totale. Vous pouvez traiter un fichier de 100 Go avec quelques Mo de RAM. Quand utiliser les STREAMS : (1) Gros fichiers : lire, écrire, copier, transformer des fichiers volumineux (logs, données, médias, exports). (2) Uploads et téléchargements : recevoir un fichier uploadé par un utilisateur ou en envoyer un — on le traite en flux (sinon un gros upload saturerait la mémoire du serveur, une faille de performance et de sécurité). (3) Flux réseau continus : traiter des données qui arrivent en continu (une réponse HTTP volumineuse, un flux de données live). (4) Traitement de données en masse : lire un énorme fichier CSV/JSON ligne par ligne, transformer un gros volume au fil de l'eau. (5) Pipelines de transformation : lire → compresser → chiffrer → écrire, en flux, sans stocker les étapes intermédiaires en mémoire. (6) Servir de gros fichiers : un serveur qui envoie un gros fichier à un client le fait en stream (le client reçoit au fur et à mesure, la mémoire serveur reste faible). Quand readFile/writeFile CLASSIQUE suffit : (1) Petits fichiers : config, petits fichiers de données, fichiers texte courts — les charger entièrement est simple et sans conséquence (quelques Ko en mémoire, aucun problème). (2) Quand vous avez besoin du contenu ENTIER d'un coup : par exemple parser un fichier JSON de config (vous devez avoir tout le JSON pour le parser) — un stream n'aiderait pas et compliquerait. (3) Simplicité : readFile/writeFile sont plus simples à écrire ; pour de petites données, cette simplicité est préférable (ne pas sur-ingénierer). Le critère de décision : (1) La taille : gros ou potentiellement gros (surtout si la taille dépend d'entrées utilisateur — un upload dont vous ne contrôlez pas la taille DOIT être en stream) → streams. Petit et borné → readFile. (2) La nature : flux continu (réseau, live) → streams. Données ponctuelles complètes → readFile. (3) La mémoire : si charger tout risque de saturer la RAM → streams. Attention particulière aux uploads : un piège classique est de recevoir un fichier uploadé en le chargeant entièrement en mémoire — un attaquant (ou un gros fichier légitime) peut alors saturer votre serveur. Les uploads se traitent en STREAM (les bibliothèques d'upload le font). C'est un enjeu de performance ET de sécurité (résistance à la saturation). Le bon réflexe : (1) petites données ponctuelles → readFile/writeFile (simple) ; (2) gros volumes, tailles non bornées, flux continus, pipelines → streams (efficace, scalable). En cas de doute sur des données dont la taille peut être grande ou incontrôlée, privilégiez les streams — c'est le choix scalable. Maîtriser les streams (au moins le principe et .pipe()) vous permet d'écrire des applications qui tiennent la charge sur de gros volumes, là où une approche « tout en mémoire » s'effondrerait. C'est un marqueur de code Node professionnel et performant. Commencez par les cas simples (.pipe() pour copier/servir de gros fichiers) et approfondissez selon vos besoins.

Les streams ont une réputation d'intimidation méritée (le modèle par morceaux, les événements, les types, le backpressure...), mais on peut les apprendre PROGRESSIVEMENT en commençant par les usages simples et concrets, sans tout maîtriser d'un coup. Voici un parcours d'apprentissage graduel. Étape 1 — Comprendre le PRINCIPE (le plus important) : avant toute syntaxe, saisissez l'idée : au lieu de charger tout en mémoire, on traite les données par MORCEAUX qui « s'écoulent ». L'analogie : plutôt que de remplir un seau entier puis de le porter (charger tout), on laisse l'eau couler par un tuyau et on la traite au fil de l'écoulement (stream). Cette intuition (par morceaux, au fil de l'eau, mémoire constante) est l'essentiel — le reste est de la mécanique. Étape 2 — Utiliser .pipe() pour les cas simples : commencez par l'usage le plus courant et le plus simple, le .pipe(). Copier un fichier : fs.createReadStream('source').pipe(fs.createWriteStream('dest')). Vous connectez une source à une destination, et Node fait couler les données automatiquement (y compris la gestion du débit — le « backpressure » — sans que vous ayez à vous en soucier). C'est puissant, concis, et couvre BEAUCOUP de besoins réels (copier, servir, transférer de gros fichiers) sans complexité. Maîtrisez .pipe() d'abord — c'est le 80/20 des streams. Étape 3 — Enchaîner des streams avec pipe : une fois à l'aise avec un pipe simple, enchaînez : lecture.pipe(transformation).pipe(ecriture) — par exemple lire un fichier, le compresser (avec le module zlib), l'écrire. Vous découvrez les streams Transform (qui transforment au passage) et la puissance des pipelines. Node fournit aussi pipeline() (module stream) qui gère mieux les erreurs qu'un chaînage de .pipe() — à connaître pour les pipelines robustes. Étape 4 — Lire un stream avec les événements : quand vous avez besoin de TRAITER les données (pas juste les transférer), apprenez à écouter les événements : .on('data', chunk => ...) (traiter chaque morceau), .on('end', ...) (fin), .on('error', ...) (erreur — toujours la gérer). C'est utile pour, par exemple, traiter un gros fichier ligne par ligne, accumuler ou analyser des données au fil du flux. Étape 5 — Approfondir selon les besoins : les concepts avancés (créer ses propres streams Readable/Writable/Transform, le backpressure en détail, les modes objet, async iterators sur les streams) s'apprennent QUAND un besoin concret se présente — pas d'un coup, pas « au cas où ». Beaucoup de développeurs utilisent surtout .pipe() et l'écoute d'événements, et n'ont que rarement besoin de créer des streams custom. Conseils pour progresser sans se décourager : (1) Commencez par le PRINCIPE et .pipe() — ne vous jetez pas sur la théorie complète. Un pipe simple qui marche vous donne une victoire concrète et la compréhension de base. (2) Apprenez par des cas réels : copier un gros fichier, servir un fichier depuis un serveur, compresser — des besoins concrets qui ancrent la compréhension. (3) Acceptez de ne pas tout comprendre d'emblée : les streams sont un sujet où l'on approfondit par couches, au fil des besoins. Savoir les UTILISER (pipe, écouter les événements) suffit pour l'immense majorité des cas ; les créer/maîtriser en profondeur vient plus tard, si nécessaire. (4) Gérez toujours les erreurs ('error') — un oubli fréquent qui cause des plantages ; prenez le réflexe dès le début. (5) Les bibliothèques abstraient souvent les streams : quand vous utiliserez Express (envoyer un fichier), Multer (uploads), etc., les streams travaillent souvent en coulisses — vous bénéficiez de leur efficacité sans tout gérer à la main. Comprendre le principe vous aide à comprendre ce que ces outils font. En résumé : ne soyez pas intimidé — commencez par le PRINCIPE (traiter par morceaux) et .pipe() (le cas simple et puissant), progressez vers l'écoute d'événements pour traiter des données, et approfondissez au fil des besoins réels. Vous n'avez pas besoin de maîtriser toute la théorie des streams pour en tirer une valeur énorme (traiter efficacement de gros volumes). Les streams récompensent une approche progressive et pratique — un pas après l'autre, en commençant par les usages concrets.