Derrière chaque programme .NET qui tourne sur votre machine, une mécanique discrète orchestre l’exécution du code — quelle que soit la langue dans laquelle il a été écrit. Cette mécanique, c’est la Common Language Infrastructure, connue sous l’acronyme CLI. Une spécification ouverte, standardisée par l’ECMA (norme ECMA-335), qui rend possible l’interopérabilité entre des langages aussi différents que C#, F# ou VB.NET sur une même plateforme d’exécution.
Beaucoup de développeurs connaissent .NET sans jamais avoir ouvert la spec CLI. Pourtant, comprendre ce standard, c’est comprendre pourquoi vos bibliothèques C# fonctionnent sans friction dans un projet VB, et pourquoi le code compile vers un format intermédiaire plutôt que directement en binaire natif.
Ce que définit la Common Language Infrastructure
Du code source au CIL : le chemin de compilation
Quand vous compile un programme C# ou F#, le compilateur ne produit pas directement du code machine. Il génère du Common Intermediate Language (CIL), parfois appelé MSIL. Ce langage intermédiaire est indépendant du processeur — c’est l’un des points forts de l’architecture CLI.
Le CIL ressemble à de l’assembly, mais pour une machine virtuelle. Chaque instruction CIL décrit une opération élémentaire : charger une valeur sur la pile, appeler une méthode, allouer un objet. Le runtime se charge ensuite de compiler ce code intermédiaire en instructions natives via un compilateur JIT (Just-In-Time).
« Le CIL est à la CLI ce que le bytecode Java est à la JVM — un format pivot qui découple la logique du programme de l’architecture matérielle sous-jacente. »
— ECMA-335, 6e édition
Ce mécanisme allows à n’importe quel langage compatible de produire du CIL, à condition de respecter les règles définies par la Common Language Specification (CLS). La CLS describes un sous-ensemble de types et de fonctionnalités que tous les langages CLI doivent supporter pour garantir l’interopérabilité. Un composant qui respecte la CLS peut être consommé par n’importe quel langage de la plateforme — sans acrobatie.
✅ À retenir
La CLI définit quatre éléments centraux : le système de types commun (CTS), la Common Language Specification (CLS), le format de métadonnées, et le Common Intermediate Language (CIL). Ensemble, ils forment le contrat d’interopérabilité entre langages.
Metadata, runtime et bibliothèques : le triptyque d’exécution
Un assembly CLI n’est pas qu’un tas de bytecode. Il embarque des metadata — des informations structurées qui décrivent les types, les méthodes, les attributs et les dépendances du module. Ces metadata permettent au runtime de charger dynamiquement du code, aux outils de réflexion d’inspecter les types à l’exécution, et aux compilateurs de valider les références croisées entre assemblies.
Le runtime — qu’on appelle aussi CLR (Common Language Runtime) dans l’implémentation Microsoft — reads ces metadata pour gérer la mémoire, appliquer la sécurité et exécuter le code JIT. Sans metadata, pas de ramasse-miettes, pas de gestion d’exceptions unifiée, pas d’interop entre languages.
335
numéro de la norme ECMA qui standardise la Common Language Infrastructure depuis 2001
Les libraries standard de la CLI — regroupées sous le terme Standard Libraries — fournissent les briques de base : collections, entrées/sorties, threading, cryptographie. La specification découpe ces libraries en profils selon les contraintes de la plateforme cible. Un profil Compact pour les systèmes embarqués, un profil Full pour les environnements desktop. Ce découpage explique pourquoi .NET tourne aussi bien sur un serveur que sur un appareil mobile.
💡 Notre conseil
Si vous développez une bibliothèque destinée à être partagée entre plusieurs projets ou langages .NET, annotez-la avec [CLSCompliant(true)]. Le compilateur vérifiera automatiquement que vos types publics respectent la CLS — évitant les mauvaises surprises à vos utilisateurs VB.NET ou F#.
Trois implémentations majeures de la CLI existent aujourd’hui. D’abord le CLR de Microsoft, moteur de .NET 6/7/8. Ensuite Mono, qui a porté la CLI sur Linux et macOS bien avant .NET Core. Enfin CoreCLR, le runtime open-source sur lequel repose .NET moderne. Chacune respecte la norme ECMA-335, ce qui garantit — en théorie — qu’un assembly compilé sur l’une tourne sur les autres.
| Implémentation | Plateforme cible | Statut actuel |
|---|---|---|
| CLR (Microsoft) | Windows principalement | Actif (.NET Framework) |
| CoreCLR | Cross-platform | Actif (.NET 6+) |
| Mono | Linux, macOS, mobile | Intégré à .NET MAUI |
La CLI n’est pas une technologie figée. La norme ECMA-335 a connu six éditions depuis 2001, chacune ajoutant des fonctionnalités comme les génériques (édition 2006) ou les types valeur améliorés. Pour aller plus loin sur l’écosystème .NET et les choix d’architecture côté serveur, voir notre guide sur l’architecture des applications .NET.
⚠️ À garder en tête
La conformité ECMA-335 ne garantit pas une portabilité parfaite à 100 %. Certaines APIs platform-specific (appels Win32, accès au registre Windows) ne font pas partie de la specification CLI et cassent la portabilité. Toujours vérifier la compatibilité via les analyseurs de portabilité .NET avant de migrer un assembly entre runtimes.
Questions fréquentes
Quelle différence entre CLI et CLR ?
La CLI (Common Language Infrastructure) est une spécification ouverte standardisée par l’ECMA. Le CLR (Common Language Runtime) est l’implémentation de cette spécification par Microsoft pour .NET Framework et Windows. En d’autres termes : la CLI définit les règles, le CLR les applique. D’autres implémentations comme CoreCLR ou Mono suivent les mêmes règles CLI sans être le CLR de Microsoft.
Pourquoi compiler vers du CIL plutôt que directement en code natif ?
Le Common Intermediate Language (CIL) permet à un même assembly de s’exécuter sur différentes architectures matérielles sans recompilation. Le runtime JIT traduit le CIL en instructions natives au moment de l’exécution, en tenant compte du processeur disponible. Ce mécanisme facilite aussi les optimisations dynamiques et la gestion automatique de la mémoire par le garbage collector.
Quels langages de programmation sont compatibles avec la CLI ?
La CLI supporte tout langage capable de compiler vers du CIL et de respecter le Common Type System. Les langages officiellement supportés par Microsoft incluent C#, F#, VB.NET et C++/CLI. Des compilateurs tiers existent pour IronPython, IronRuby, ou encore Boo. Le seul prérequis : produire des assemblies conformes à la norme ECMA-335.
À quoi servent les metadata dans un assembly CLI ?
Les metadata embarquées dans un assembly CLI décrivent tous les types, méthodes, propriétés et dépendances du module. Le runtime les utilise pour charger les types dynamiquement, gérer le cycle de vie des objets et valider les appels entre assemblies. Les outils de réflexion (Reflection API) s’appuient aussi sur ces metadata pour inspecter ou générer du code à l’exécution.
La CLI est-elle un standard ouvert ou une technologie propriétaire Microsoft ?
La CLI est un standard ouvert. Elle a été soumise à l’ECMA International en 2000 et standardisée sous le numéro ECMA-335 en 2001, puis adoptée par l’ISO/IEC sous la référence 23271. Microsoft en est l’initiateur, mais n’importe quelle organisation peut implémenter la spécification. C’est ce qui a permis l’émergence de Mono, CoreCLR et d’autres runtimes indépendants.