Tableau d'octets à partir d'un Stream en C# : 5 meilleures pratiques 2025

Transformer un Stream en Byte Array : guide pour développeur C# (édition 2025)

Avez-vous déjà pensé : « Mais pourquoi, C#, ne me permets-tu pas simplement de prendre ce Stream et de le transformer en tableau d'octets en une seule ligne ? ». Si oui, vous n'êtes pas seul. La question « Creating a byte array from a stream » sur Stack Overflow recueille des milliers de vues, et ce n'est pas pour rien. La tâche semble élémentaire, mais le diable se cache dans les détails : performances, mémoire, asynchronisme et versions de .NET.

En 2025, l'écosystème .NET nous offre plusieurs solutions élégantes. Dans cet article, nous allons analyser 5 meilleures pratiques – des classiques aux nouveautés. Vous apprendrez quand utiliser MemoryStream, pourquoi BinaryReader est toujours pertinent, et comment ne pas « faire planter » l'application lors du traitement de flux gigantesques. C'est parti !

1. Le classique : MemoryStream et CopyTo

La méthode la plus populaire et intuitive. Si vous avez un Stream (par exemple, depuis un fichier, un réseau ou la mémoire), vous le « déversez » simplement dans un MemoryStream, puis vous appelez ToArray().

public static byte[] StreamToBytesUsingMemoryStream(Stream inputStream)\n{\n    using (var memoryStream = new MemoryStream())\n    {\n        inputStream.CopyTo(memoryStream);\n        return memoryStream.ToArray();\n    }\n}

Avantages :

\n
• Simplicité et lisibilité.
\n
• Fonctionne dans toutes les versions de .NET (Framework, Core, 5+).
\n
• Prend en charge CopyToAsync pour le travail asynchrone.
\n

Inconvénients :

\n
• Si le flux est énorme (par exemple, 1 Go), vous conservez les données deux fois en mémoire : d'abord dans MemoryStream, puis dans le tableau.
\n
• Ce n'est pas la variante la plus rapide pour les très petits flux (surcharge liée à la création de l'objet).
\n

Quand l'utiliser : Pour les flux de taille moyenne (jusqu'à 100 Mo) et lorsque la lisibilité du code est plus importante que les micro-optimisations.

2. Le héros asynchrone : ReadAsync et Buffer

Dans le développement moderne, l'asynchronisme est la norme. La méthode ReadAsync permet de lire les données par portions, sans bloquer le thread. C'est particulièrement utile dans ASP.NET Core ou les applications GUI.

public static async Task<byte[]> StreamToBytesAsync(Stream inputStream)\n{\n    using (var memoryStream = new MemoryStream())\n    {\n        byte[] buffer = new byte[8192]; // 8 Ko — taille standard\n        int bytesRead;\n        while ((bytesRead = await inputStream.ReadAsync(buffer, 0, buffer.Length)) > 0)\n        {\n            await memoryStream.WriteAsync(buffer, 0, bytesRead);\n        }\n        return memoryStream.ToArray();\n    }\n}

Conseil de professionnel : La taille du tampon peut être modifiée. Pour les flux réseau, 8 Ko est un bon compromis. Pour les disques SSD, vous pouvez l'augmenter jusqu'à 64 Ko.

Avantages :

\n
• Ne bloque pas le thread appelant.
\n
• Permet de traiter les données « à la volée » (par exemple, calculer un hachage).
\n
• Contrôle de la consommation mémoire.
\n

Inconvénients :

\n
• Un peu plus de code.
\n
• Nécessite la compréhension du modèle async/await.
\n

3. BinaryReader : un vieil ami vaut mieux que deux nouveaux

Beaucoup oublient BinaryReader, et c'est dommage. Il sait lire tout le flux en une seule commande — ReadBytes. Mais il y a un détail : il doit connaître la longueur du flux à l'avance.

public static byte[] StreamToBytesUsingBinaryReader(Stream inputStream)\n{\n    if (inputStream.CanSeek)\n    {\n        inputStream.Position = 0; // Réinitialisation de la position si nécessaire\n        using (var reader = new BinaryReader(inputStream, Encoding.UTF8, leaveOpen: true))\n        {\n            return reader.ReadBytes((int)inputStream.Length);\n        }\n    }\n    else\n    {\n        throw new InvalidOperationException("Le Stream ne prend pas en charge la recherche de position");