Les réseaux télécoms traversent une mutation profonde depuis plusieurs années. Les fonctions réseau, autrefois exécutées sur du matériel propriétaire, ont d'abord été virtualisées sous forme de VNF, puis reconçues nativement pour le cloud sous forme de CNF. Comprendre la différence entre ces deux approches n'est pas un exercice théorique : c'est un choix d'architecture qui conditionne la performance, les coûts et la capacité d'évolution d'un réseau pour les cinq à dix prochaines années. Si vous êtes architecte réseau, responsable infrastructure ou simplement curieux de savoir pourquoi votre opérateur parle autant de conteneurs et de Kubernetes, ce qui suit devrait clarifier les choses. On va comparer VNF et CNF sur des critères concrets : architecture, performance, coûts, agilité opérationnelle, et pertinence stratégique.
Évolution de la virtualisation : des VNF aux CNF
Le passage des équipements réseau physiques aux fonctions logicielles ne s'est pas fait en un seul bond. Il y a eu deux grandes étapes, chacune portée par des technologies et des philosophies différentes. Comprendre cette trajectoire est indispensable pour saisir pourquoi les CNF ne sont pas simplement des VNF "améliorées", mais bien un changement de paradigme dans la façon de concevoir et d'exploiter les fonctions réseau.
Définition et architecture des VNF (Virtual Network Functions)
Les VNF, ou fonctions réseau virtualisées, sont apparues dans le sillage du mouvement NFV (Network Functions Virtualization) lancé par l'ETSI en 2012. L'idée centrale était simple : prendre les fonctions réseau qui tournaient sur des appliances physiques dédiées (routeurs, pare-feu, load balancers, etc.) et les exécuter sous forme de logiciel dans des machines virtuelles, sur du matériel standard x86.
Concrètement, une VNF est une application monolithique ou faiblement modulaire qui tourne à l'intérieur d'une machine virtuelle (VM). Chaque VM embarque son propre système d'exploitation invité, ses bibliothèques, ses dépendances. Un hyperviseur (VMware ESXi, KVM, ou autre) gère l'allocation des ressources matérielles entre les différentes VM hébergées sur un même serveur physique.
L'architecture type d'un déploiement VNF repose sur trois couches : l'infrastructure NFVI (serveurs, stockage, réseau), la couche de virtualisation (hyperviseur), et les VNF elles-mêmes. Un orchestrateur, souvent conforme au framework MANO de l'ETSI, coordonne le provisionnement et la gestion du cycle de vie. Cette approche a permis aux opérateurs de réduire leur dépendance au matériel propriétaire et de gagner en flexibilité par rapport aux appliances physiques. Mais elle conserve une lourdeur structurelle : chaque VM consomme des ressources significatives rien que pour faire tourner son OS, et le temps de démarrage se compte en minutes, pas en secondes.
L'émergence des CNF (Cloud-native Network Functions)
Les CNF représentent l'étape suivante. Plutôt que de simplement virtualiser une fonction réseau existante en la plaçant dans une VM, l'approche cloud-native consiste à reconcevoir la fonction réseau sous forme de microservices conteneurisés, conçus dès le départ pour tourner dans un environnement d'orchestration comme Kubernetes.
Un conteneur, contrairement à une VM, ne transporte pas son propre système d'exploitation. Il partage le noyau de l'hôte et n'embarque que l'application et ses dépendances directes. Le résultat : une empreinte mémoire et CPU nettement plus faible, un temps de démarrage qui se mesure en secondes, et une densité de déploiement bien supérieure sur un même serveur.
Mais la conteneurisation seule ne fait pas une CNF. Ce qui distingue réellement une CNF, c'est son architecture cloud-native : décomposition en microservices indépendants, communication via des API, capacité à être mise à l'échelle composant par composant, résilience intégrée, et gestion déclarative de la configuration. Une CNF de qualité suit les principes des "Twelve-Factor Apps" adaptés au contexte télécom. Les principaux équipementiers (Ericsson, Nokia, Samsung) proposent leurs cœurs de réseau 5G sous forme de CNF, et la plupart des grands opérateurs européens, dont Orange et Deutsche Telekom, ont engagé la migration de leurs fonctions réseau critiques vers des architectures conteneurisées.
Comparaison technique : Machines Virtuelles vs Conteneurs
Au-delà des définitions, ce sont les différences techniques concrètes qui déterminent le choix entre VNF et CNF. Cette section entre dans le détail de ce qui se passe réellement sous le capot.
Gestion des ressources et hyperviseurs
Dans un environnement VNF, l'hyperviseur joue un rôle central. C'est lui qui crée et gère les machines virtuelles, alloue les vCPU, la mémoire et les interfaces réseau virtuelles. Chaque VM reçoit une allocation fixe de ressources, souvent surdimensionnée pour absorber les pics de charge. Cette approche garantit une isolation forte, mais au prix d'un gaspillage structurel. Un serveur physique avec 512 Go de RAM et 64 cœurs peut héberger une dizaine de VNF gourmandes, dont chacune réserve 20 à 40 Go de RAM pour son OS invité et ses bibliothèques, avant même de faire tourner la moindre fonction réseau utile.
Les conteneurs changent radicalement cette équation. Sans couche d'OS invité, un conteneur typique consomme entre 50 Mo et quelques centaines de Mo de mémoire. Sur le même serveur physique, on peut déployer des dizaines, voire des centaines de conteneurs. Kubernetes, l'orchestrateur standard des CNF, gère l'allocation dynamique des ressources : un conteneur qui n'est pas sollicité consomme très peu, et les ressources libérées sont immédiatement disponibles pour d'autres charges de travail.
Cette différence a un impact direct sur le dimensionnement des datacenters. Les opérateurs qui migrent vers des CNF constatent typiquement une réduction de 30 à 50 % du nombre de serveurs nécessaires pour une même capacité réseau. C'est un chiffre qui pèse lourd quand on gère des milliers de nœuds.
Performance, isolation et sécurité
La question de la performance brute est souvent mal comprise. Les VNF, grâce à des technologies comme SR-IOV (Single Root I/O Virtualization) et DPDK (Data Plane Development Kit), peuvent atteindre des performances réseau proches du matériel natif pour le traitement de paquets. L'hyperviseur ajoute une couche de latence, mais elle est devenue très fine avec les hyperviseurs modernes.
Les conteneurs, eux, tournent directement sur le noyau de l'hôte. Pour les opérations CPU et mémoire, ils offrent des performances quasi-natives sans surcoût de virtualisation. En revanche, le partage du noyau pose une question légitime d'isolation. Si un conteneur exploite une vulnérabilité du noyau Linux, il peut potentiellement accéder aux ressources d'autres conteneurs sur le même hôte. Les VM, avec leur hyperviseur, offrent une frontière de sécurité plus épaisse.
En 2026, cet écart s'est considérablement réduit. Les technologies comme gVisor, Kata Containers (qui combinent conteneurs et micro-VM) et les politiques de sécurité Kubernetes (Pod Security Standards, network policies, service mesh avec mTLS) permettent d'atteindre un niveau de sécurité satisfaisant pour la plupart des cas d'usage télécoms. Certains opérateurs adoptent d'ailleurs une approche hybride : conteneurs pour le plan de contrôle, VM pour les fonctions du plan de données les plus sensibles en termes de performance et d'isolation.
Agilité et cycle de vie opérationnel
C'est probablement sur le terrain de l'agilité opérationnelle que la différence entre VNF et CNF se fait le plus sentir au quotidien. Les équipes qui gèrent des infrastructures réseau passent l'essentiel de leur temps à déployer, mettre à jour, surveiller et faire évoluer les fonctions réseau. La façon dont ces opérations se déroulent change radicalement selon l'approche choisie.
Déploiement et orchestration avec Kubernetes
Déployer une VNF reste un processus relativement lourd. Il faut provisionner la VM, installer l'OS invité, configurer le réseau virtuel, déployer l'application, puis la connecter aux autres composants. Même avec des outils d'automatisation comme Ansible ou Terraform, et un orchestrateur MANO, le déploiement complet d'une nouvelle fonction réseau prend typiquement entre 15 et 45 minutes. Les descripteurs VNF (VNFD) sont souvent complexes et spécifiques à chaque vendeur.
Avec les CNF et Kubernetes, le déploiement repose sur des manifestes YAML déclaratifs. On décrit l'état souhaité, et Kubernetes se charge de le réaliser. Un déploiement complet prend quelques secondes à quelques minutes. Les Helm charts permettent de packager des déploiements complexes de manière reproductible. Un opérateur peut déployer une instance complète d'un cœur de réseau 5G en quelques minutes, contre plusieurs heures dans un environnement VNF traditionnel.
Kubernetes apporte aussi la notion de "self-healing" : si un conteneur tombe, il est automatiquement redémarré. Si un nœud physique tombe, les conteneurs sont redéployés sur d'autres nœuds. Cette résilience native réduit drastiquement le temps d'intervention humaine en cas d'incident. Les opérateurs français qui ont déployé des CNF en production rapportent une réduction de 60 à 70 % du temps consacré aux opérations de déploiement et de remédiation.
Mises à jour, scalabilité et microservices
Les mises à jour sont le talon d'Achille des VNF. Comme une VNF est souvent monolithique, la mettre à jour signifie arrêter l'ensemble de la fonction, appliquer le patch ou la nouvelle version, puis la redémarrer. Même avec des mécanismes de redondance active/passive, ces opérations impliquent des fenêtres de maintenance et un risque de disruption. Les opérateurs planifient ces mises à jour des semaines à l'avance.
Les CNF, grâce à leur architecture en microservices, permettent des mises à jour granulaires. On peut mettre à jour un seul composant (par exemple, le module de gestion de sessions) sans toucher aux autres. Kubernetes supporte nativement les rolling updates : les nouvelles versions sont déployées progressivement, pod par pod, sans interruption de service. Si la nouvelle version pose problème, un rollback automatique ramène à la version précédente en quelques secondes.
La scalabilité suit la même logique. Avec une VNF, monter en charge signifie déployer une nouvelle VM complète, ce qui prend du temps et consomme beaucoup de ressources. Avec une CNF, Kubernetes peut ajouter des répliques d'un microservice spécifique en quelques secondes, en fonction de la charge réelle. L'Horizontal Pod Autoscaler ajuste automatiquement le nombre de pods selon des métriques comme l'utilisation CPU ou le nombre de sessions actives. En période de pointe (un événement sportif majeur, par exemple), le réseau s'adapte en temps réel sans intervention manuelle.
Avantages stratégiques pour les opérateurs télécoms
Au-delà des considérations techniques, le choix entre VNF et CNF a des implications directes sur la stratégie business des opérateurs. Les gains ne se mesurent pas uniquement en millisecondes de latence ou en pourcentage de CPU économisé.
Réduction des coûts opérationnels (OPEX)
Les coûts d'exploitation représentent la part la plus importante du budget réseau d'un opérateur, bien davantage que les investissements initiaux (CAPEX). C'est sur l'OPEX que les CNF font la plus grande différence.
Prenons des chiffres concrets. Un grand opérateur européen qui a migré son cœur de réseau 5G de VNF vers CNF entre 2023 et 2025 a publié les résultats suivants :
- Réduction de 40 % du nombre de serveurs physiques nécessaires grâce à la densité des conteneurs
- Baisse de 35 % des coûts énergétiques associés (moins de serveurs, donc moins de refroidissement)
- Diminution de 50 % du temps passé par les équipes sur les opérations de maintenance courante
- Passage de fenêtres de maintenance mensuelles de 4 heures à des mises à jour continues sans interruption
L'automatisation native de Kubernetes réduit aussi le besoin en personnel spécialisé pour les opérations de routine. Les équipes peuvent se concentrer sur des tâches à plus forte valeur ajoutée : développement de nouveaux services, analyse de performance, innovation. Cela ne signifie pas moins d'emplois, mais des emplois différents, orientés vers le développement et l'ingénierie plutôt que vers l'exploitation manuelle.
Les licences logicielles évoluent aussi. Plusieurs éditeurs de fonctions réseau proposent désormais des modèles de tarification basés sur la consommation réelle (nombre de sessions, volume de trafic traité) plutôt que sur le nombre de VM déployées. Ce modèle est naturellement adapté aux CNF, dont la granularité permet un suivi précis de la consommation.
Interopérabilité et écosystèmes multi-cloud
L'un des problèmes récurrents avec les VNF est le verrouillage fournisseur. Chaque éditeur de VNF a ses propres formats de descripteurs, ses propres exigences en matière d'hyperviseur, ses propres outils de gestion. Migrer une VNF d'un environnement VMware vers un environnement OpenStack, par exemple, peut nécessiter des semaines de travail d'adaptation.
Les CNF, construites sur des standards ouverts (OCI pour les images de conteneurs, Kubernetes pour l'orchestration, Helm pour le packaging), offrent une portabilité bien supérieure. Une CNF qui tourne sur un cluster Kubernetes on-premise peut, en théorie et souvent en pratique, tourner sur un cluster Kubernetes managé chez AWS, Azure, GCP ou OVHcloud sans modification majeure.
Cette portabilité ouvre la porte aux architectures multi-cloud et hybrides. Un opérateur peut exécuter ses fonctions réseau critiques dans ses propres datacenters tout en utilisant le cloud public pour absorber les pics de charge ou pour déployer des fonctions edge computing au plus près des utilisateurs. En 2026, plusieurs opérateurs français exploitent des architectures hybrides de ce type, combinant infrastructure privée et cloud public selon les besoins de chaque fonction réseau.
L'écosystème cloud-native bénéficie aussi d'une communauté open source massive. Des projets comme Istio (service mesh), Prometheus (monitoring), Argo CD (déploiement continu) et Cilium (réseau et sécurité) apportent des capacités qui auraient coûté des millions à développer en interne. Les opérateurs qui adoptent les CNF accèdent à cet écosystème et à son rythme d'innovation.
Choisir la bonne approche pour la modernisation du réseau
La question "VNF ou CNF" n'appelle pas une réponse binaire. La réalité de 2026, c'est que la plupart des opérateurs gèrent un environnement mixte, avec des VNF héritées qui cohabitent avec des CNF de nouvelle génération. La migration complète prend du temps : entre trois et cinq ans pour un opérateur de taille moyenne, davantage pour les très grands réseaux.
Le critère déterminant n'est pas la technologie elle-même, mais la maturité de l'organisation. Adopter des CNF sans avoir les compétences Kubernetes en interne, sans pipeline CI/CD, sans culture DevOps, c'est s'exposer à des échecs coûteux. Plusieurs opérateurs ont tenté des migrations accélérées et se sont retrouvés avec des environnements hybrides mal maîtrisés, plus complexes à gérer que l'infrastructure d'origine.
La recommandation pragmatique est la suivante : commencer par les nouvelles fonctions réseau (5G SA, edge computing, network slicing) en CNF, et migrer progressivement les VNF existantes en commençant par celles dont le contrat de support arrive à échéance. Investir massivement dans la formation des équipes à Kubernetes et aux pratiques cloud-native. Et surtout, ne pas sous-estimer le volet organisationnel : les CNF fonctionnent mieux avec des équipes structurées en mode produit, pas en silos traditionnels "réseau" et "IT".
La différence fondamentale entre VNF et CNF dépasse la simple question technique du conteneur contre la machine virtuelle. C'est un changement dans la façon de concevoir, déployer et exploiter un réseau. Les VNF ont permis de quitter le matériel propriétaire. Les CNF permettent de penser le réseau comme un logiciel, avec tout ce que cela implique en termes de vitesse d'innovation, de résilience et d'efficacité économique. Les opérateurs qui réussiront cette transition seront ceux qui auront compris que la technologie n'est que la moitié du chemin : l'autre moitié, c'est la transformation des compétences et des processus.
