Pourquoi C# n'est pas réservé aux projets d'entreprise ennuyeux ?
\n\nDans le monde de l'IT, un stéréotype persiste : C# serait un langage pour les projets d'entreprise soporifiques, les systèmes bancaires et les portails administratifs. Mais si l'on met de côté les préjugés, on découvre que Stack Overflow, Unity, une partie de Visual Studio et même JetBrains Rider sont écrits en C#. Analysons ensemble des cas concrets d'entreprises qui utilisent C# en production, et explorons le code qui se cache derrière.
\n\nCet article n'est pas une théorie sèche, mais une analyse de projets réels avec des exemples que vous pourrez adapter à vos propres besoins. C'est parti.
\n\nCas n°1 : Stack Overflow – comment C# gère 1 milliard de requêtes par mois
\n\nStack Overflow est sans doute l'exemple le plus célèbre d'utilisation de C# dans un projet à forte charge. Le site traite plus d'un milliard de pages vues par mois, et fonctionne sur ASP.NET MVC (aujourd'hui .NET Core) avec Redis et Elasticsearch.
\n\nArchitecture et pourquoi C# ?
\nL'équipe de Stack Overflow a choisi C# pour ses performances, son typage fort et son excellent support du multithreading. Leur particularité : une utilisation minimale de bibliothèques tierces. Ils ont développé leur propre ORM (Dapper) et leur propre couche de cache.
\n\nExemple de code : un cache haute performance avec Redis
\nL'un des secrets de la rapidité de Stack Overflow est un cache agressif. Voici à quoi ressemble leur approche avec Redis via StackExchange.Redis :
public class CacheService\n{\n private readonly IDatabase _cache;\n private readonly TimeSpan _defaultExpiry = TimeSpan.FromMinutes(10);\n\n public CacheService(IConnectionMultiplexer redis)\n {\n _cache = redis.GetDatabase();\n }\n\n public async Task<T> GetOrSetAsync<T>(string key, Func<Task<T>> factory)\n {\n // Tentative de récupération depuis le cache\n var cached = await _cache.StringGetAsync(key);\n if (cached.HasValue)\n {\n return JsonSerializer.Deserialize<T>(cached);\n }\n\n // Sinon, on appelle la factory et on sauvegarde\n var value = await factory();\n var serialized = JsonSerializer.Serialize(value);\n await _cache.StringSetAsync(key, serialized, _defaultExpiry);\n return value;\n }\n}\n\n\nPourquoi c'est génial ? Ils ne mettent pas tout en cache sans réfléchir : ils utilisent le cache-aside pattern et définissent un TTL (durée de vie) selon le type de données. Par exemple, 30 secondes pour la liste des questions, 5 minutes pour le profil d'un utilisateur.
\n\nCas n°2 : Unity – C# comme langage pour les jeux et la 3D
\n\nUnity est le moteur de jeu incontournable pour les développeurs indépendants et les grands studios. Son noyau est écrit en C++, mais tout le scripting des jeux se fait en C#. Plus de 50% des jeux mobiles dans le monde sont créés avec Unity, et pas seulement « Angry Birds », mais aussi Hearthstone ou Pokémon GO.
\n\nPourquoi C# plutôt que C++ ?
\nUnity a choisi C# pour son équilibre : plus rapide que Python ou JavaScript, mais plus sûr et plus simple que C++. Le garbage collector (GC) peut poser problème, mais dans Unity, ils ont appris à le maîtriser.
\n\nExemple de code : optimisation avec un pool d'objets
\nDans les jeux, les objets (balles, ennemis, particules) sont souvent créés et détruits. Pour éviter les ralentissements dus au GC, on utilise un Object Pool. Voici à quoi cela ressemble en C# :
\n\npublic class BulletPool : MonoBehaviour\n{\n private Queue<Bullet> _pool = new Queue<Bullet>();\n [SerializeField] private Bullet _bulletPrefab;\n\n public Bullet Get()\n {\n if (_pool.Count > 0)\n {\n var bullet = _pool.Dequeue();\n bullet.gameObject.SetActive(true);\n return bullet;\n }\n return Instantiate(_bulletPrefab);\n }\n\n public void Return(Bullet bullet)\n {\n bullet.gameObject.SetActive(fa