Il y a encore quelques années, la feuille de route d’un technicien réseau ambitieux tenait sur un Post-it : 1️⃣ décrocher la CCNA, 2️⃣ accumuler un peu d’expérience, 3️⃣ viser les étoiles (CCNP, CCIE, ou un poste d’architecte). Puis le Cloud est arrivé comme un ouragan. En l’espace d’un café (ou deux confinements), toutes les diapos RH ont commencé à clignoter “AWS”, “Azure”, “GCP”. Les offres d’emploi ont troqué leurs sempiternelles listes VLAN-OSPF-BGP pour un florilège de services managés aux acronymes ésotériques : VPC, Lambda, EKS, Cloud NAT…
Du jour au lendemain, même les plus chevronnés des networkers se sont retrouvés à pianoter nerveusement sur leurs claviers : “Et si la prochaine réorg virait notre bon vieux datacenter ? Et si la certification CCNA devenait… rétro Cette angoisse n’est pas qu’un fantasme de tech addict. Elle se lit entre les lignes de LinkedIn, dans les forums, dans les conversations Slack où l’on voit fleurir des questions comme :

« Faut-il encore investir 300 € et cent heures de labo pour un examen CCNA alors que tout le monde déploie ses applis sur le Cloud ? »

« Le réseau local va-t-il finir muséifié, enterré sous une pile de YAML ? »

Mais avant de brûler votre rack Cisco (ou votre simulateur GNS3), un rappel s’impose : le Cloud n’est pas une entité éthérée suspendue dans le ciel. Derrière chaque Lambda qui s’exécute “serverless”, il y a… un serveur. Derrière chaque bucket S3, un réseau physique. Et derrière chaque réseau physique, des ingénieurs qui parlent BGP, STP et QoS – qu’ils portent un hoodie “DevOps” ou un polo “Network”.

Autrement dit, le Cloud ne remplace pas le réseau ; il le réorchestre. L’enjeu, pour vous, n’est donc pas de choisir un camp mais de comprendre comment ces deux mondes s’imbriquent – et comment votre carrière peut surfer sur cette vague sans se noyer.

Dans cet article, on va :

• décortiquer ce que la CCNA valide vraiment (indice : bien plus que « savoir câbler une patte verte sur une patte orange »),

• dévoiler les dessous réseau du Cloud que les marketeux préfèrent garder volontairement flous,

• analyser les attentes réelles des recruteurs en 2025 (spoiler : le combo Réseau + Cloud fait encore plus briller votre CV).

Ce que la CCNA prouve (et ce qu’elle ne prouve pas)

Dans l’imaginaire collectif, la CCNA (Cisco Certified Network Associate) continue de flotter comme une sorte de Graal : un ticket d’entrée vers le « vrai » monde réseau, une validation officielle que “tu maîtrises l’OSI sur le bout des doigts, tu configures OSPF les yeux fermés, tu sniffes des trames Ethernet comme d’autres leurs cafés du matin”.
Mais à force de l’encenser – ou de la dénigrer – on a fini par brouiller le message. Alors, remettons d’abord les pendules à l’heure : qu’est-ce que la CCNA certifie réellement ?

1. Un socle théorique solide (et pas si poussiéreux)

Oui, la CCNA reste un condensé de classiques : modèles OSI et TCP/IP, VLAN, routage statique/dynamique, ACL, NAT…
Ces bases semblent parfois ringardes à l’ère du Cloud natif, pourtant elles tiennent encore debout — comme les fondations d’une maison : invisibles quand on admire la façade, mais indispensables pour qu’elle ne s’écroule pas au premier coup de vent (ou de failover).

• Pourquoi c’est précieux ?
  Quand vous basculez un micro-service d’une zone de disponibilité à l’autre, vous jonglez toujours (sans le dire) avec des tables de routage, des MTU, des redirections ICMP. Comprendre ces mécanismes avant qu’ils soient masqués par un panneau « managed service » fait toute la différence lorsque la production flambe le dimanche soir.

2. Une grammaire commune : parler BGP sans Google Trad

Le Cloud a ses dialectes (VPC, VNet, VCN…) mais le langage cœur reste le protocole réseau. La CCNA vous force à articuler clairement des concepts :
Paquet, segment, trame. OSPF, EIGRP, BGP. Subnetting, summarization, route selection.
Autrement dit : elle vous apprend à penser “réseau”, pas à copier-coller des blocs Terraform sans comprendre pourquoi ça marche (ou pas).

3. Un examen de méthode plus que de mémorisation

On sous-estime souvent la compétence cachée que la CCNA développe : le raisonnement structuré.
Pendant vos labs, vous apprenez à :

1. Poser l’hypothèse : « Pourquoi ce ping tombe-t-il à l’eau ? »

2. Isoler la couche : physique ? liaison ? réseau ?

3. Tester, valider, documenter.

Ce processus de troubleshooting – presque ritualisé – devient un super-pouvoir quand vous affrontez des architectures Cloud éclatées : il n’y a plus de console bleue Cisco, mais des dashboards, des logs, des métriques. Le “muscle” logique, lui, reste le même.

4. Ses limites assumées

La CCNA, en revanche, ne fait pas de vous :

• Un expert Kubernetes ou Terraform.

• Un spécialiste de la facturation AWS (et de ses pièges).

• Un gourou de l’observabilité distribuée.

Elle n’enseigne ni le Infrastructure-as-Code, ni le serverless, ni la sécurisation des API Gateway. Elle ne parle pas de cloud-native firewalls, de WAF managés ou de contrôles IAM granulaires. Autant de domaines stratégiques que le marché attend d’un(e) ingénieur Cloud.

Conclusion intermédiaire : La CCNA n’est ni obsolète ni suffisante.
C’est un socle ; or un socle, par définition, demande qu’on construise quelque chose au-dessus.

Dans les coulisses : le réseau (très) physique du Cloud

On imagine volontiers le Cloud comme une brume de calculateurs sans câbles ni baies, un royaume abstrait où les paquets se téléportent par magie. Pourtant, sous chaque console AWS ou Azure, vous retrouvez exactement ce que la CCNA vous a enseigné : des commutateurs, des routeurs, des liens fibre longue distance, des protocoles de routage… simplement industrialisés à une échelle que peu de datacenters classiques peuvent se permettre.

La topologie qu’on ne montre pas sur les slides marketing

• Des cœurs BGP redondés : quand vous créez un VPC, une table BGP quelque part apprend vos CIDR privés et annonce des routes vers l’extérieur.

• Du MPLS en coulisse : les grands fournisseurs agglutinent des milliers de VRF pour isoler les locataires entre eux – c’est le VLAN 802.1Q poussé au stéroïdes.

• Des CDN et des Edge locations qui répliquent les vieux principes de cache L4/L7 ; la « latence sous les 50 ms » se paie en kilomètres de fibre, pas en buzzwords.

En clair, le Cloud est un réseau géant, décoré d’une API. Tout ce qui semblait “câblage” dans votre rack on-prem est désormais abstrait par du JSON : CreateVpc, AttachInternetGateway, UpdateRoute. La logique reste pourtant la même : pour qu’un paquet rejoigne un Pod Kubernetes, il traverse toujours des ACL, des NAT, parfois un tunnel GRE ou IPSec.

Pourquoi ce rappel est crucial

1. Quand un incident survient, la frontière entre “ops réseau” et “ops cloud” s’effondre. Un subnet mal résumé, un MTU tronqué, et votre micro-service s’étouffe — exactement comme sur un réseau campus.

2. Le dépannage reste old-school : traceroute, capture de paquets, comparaison des tables de routage… Mais vous le faites via des logs VPC Flow ou des outils CloudWatch au lieu d’un SPAN Cisco. Ceux qui lisent déjà un show ip route comprennent plus vite un vpcRouteTable.

3. La performance : savoir qu’un ALB opère en L7 et que sa limite RPS dépend du handshake TCP devient critique pour dimensionner une appli. Ce sont des réflexes acquis à coups de labs CCNA – simplement transposés dans un portail web.

Au final, le Cloud ne tue pas le réseau ; il l’embarque dans une capsule plus vaste. Les fondations CCNA ne deviennent donc ni optionnelles ni désuètes : elles se muent en atouts stratégiques pour comprendre l’infrastructure invisible que les providers s’emploient à simplifier – parfois un peu trop.

Certifications Cloud vs. CCNA : deux pièces d’un même puzzle

On pourrait croire qu’il existe une ligne de démarcation nette : à gauche, la CCNA pour les “cable guys” ; à droite, les badges AWS/Azure/GCP pour les “cloud ninjas”. En réalité, 2025 nous montre une cartographie bien plus nuancée : la frontière ressemble à un Venn diagram où les deux cercles se chevauchent largement.

Ce que les certifications Cloud apportent que la CCNA n’aborde pas

Les cursus AWS SAA, Azure Administrator, Google ACE et consorts sont pensés pour un objectif précis : déployer, sécuriser, scaler des workloads sur une plateforme donnée. Autrement dit, ils abordent des couches que la CCNA ignore presque totalement :

• Services managés : bases de données “as-a-service”, functions serverless, PaaS web, filesystems distribués.

• Infrastructure-as-Code : CloudFormation, ARM/Bicep, Deployment Manager – l’art de générer un réseau par template plutôt que par CLI.

• Modèle de facturation : comprendre pourquoi 10 000 requêtes NAT Gateway coûtent plus qu’une demi-journée de café, et comment l’architecture influence la facture.

• Sécurité “cloud-native” : IAM, politiques KMS, Security Groups stateful, segmentation par comptes/projets plutôt que par VLAN.

• Observabilité distribuée : CloudWatch, Azure Monitor, Stackdriver — des dashboards qui consolident logs, traces et métriques à l’échelle planétaire.

Ces briques sont vitales pour garantir disponibilité et conformité dans un environnement où les racks sont hors de portée – et la root cause se cache parfois dans un simple tag mal orthographié.

Ce que la CCNA apporte que les certifs Cloud zappent (parfois dangereusement)

En contre-champ, la CCNA continue de délivrer des réflexes que les cursus Cloud survolent – parfois en supposant qu’ils sont “déjà acquis” :

• Dépannage bas niveau : ARP, MTU, duplex — des sujets éclipsés par un bouton “Enable VPC Flow Logs”, mais qui ressortent quand un site mission-critique subit 30 % de pertes de paquets… et que personne ne comprend pourquoi.

• Compréhension des protocoles : savoir ce qu’un SYN, un ACK ou un TTL signifient vraiment permet de diagnostiquer plus vite qu’un test “curl” infructueux.

• Segmentation physique & logique : STP, EtherChannel, HSRP — toujours là derrière un Cloud privé ou un edge on-prem, surtout quand l’entreprise migre en “hybride” et que les VLAN continuent de transporter la voix et la vidéo dans les bureaux.

• Culture du troubleshoot méthodique : traceroute, ping sélectif, ACL pas à pas — des gestes qui deviennent vitaux quand la console Cloud renvoie simplement “5xx Error” sans autre explication.

Là où les formations Cloud vous disent “utilisez le service X pour faire Y”, la CCNA vous demande : “comment le paquet atteint Y ?” – une curiosité salvatrice quand un service X… tombe.

Pourquoi les recruteurs adorent le combo

Les tableaux Excel des RH racontent tous la même histoire : les profils hybrides dominent le game.

• Un·e ingénieur·e Cloud qui a le réflexe de vérifier un TTL avant de blâmer l’auto-scaling vaut de l’or.

• Un·e networker CCNA qui sait packager son infra dans Terraform évite au client des semaines de refacto.

Résultat : les offres “DevNet/Cloud Network Engineer”, “SRE à forte sensibilité réseau”, “Architecte hybride” explosent. Elles exigent à la fois la lisibilité des diagrammes CCNA et la maîtrise des consoles Cloud.

Faut-il choisir ?

La question “ Cloud ou CCNA ? ” se transforme donc en “Dans quel ordre et avec quel objectif ?”.

• Junior pur réseau ? Commence par la CCNA pour forger tes bases, puis ajoute un badge cloud dès que possible.

• Développeur DevOps qui terraform déjà ? Un détour par la CCNA t’offrira un œil neuf sur tes VPC et ton trafic est-ouest.

• Étudiant·e sans expérience ? Un double cursus CCNA + AWS Cloud Practitioner accélère l’employabilité : tu comprends la théorie et tu parles la langue recruteur.

Moralité : la certification Cloud n’enterre pas la CCNA ; elle la complète. Les deux répondent à des questions différentes, mais complémentaires :
« Comment fonctionne le réseau ? » et « Comment l’orchestrer à grande échelle ? ».

Faut-il vraiment décrocher la CCNA pour devenir ingénieur Cloud ?

La question revient comme un ping flood sur les forums : « Je veux bosser sur AWS ; est-ce que je perds mon temps à réviser les VLAN et l’OSPF ? »
Pour y répondre sans détour, il faut quitter la logique binaire oui / non et raisonner en trajectoire.

Le scénario “je saute la CCNA”

Imaginez Claire : elle sort d’un bootcamp DevOps, enchaîne les labs AWS, passe son Associate, maîtrise Terraform ; six mois plus tard, elle décroche un poste “Cloud Engineer Junior”. Mission accomplie ? Oui… à court terme.
Mais le premier incident réseau sérieux — latence inexpliquée entre deux AZ, perte de paquets après un Transit Gateway mal paramétré — la propulse hors de sa zone de confort. Elle découvre alors que les docs AWS n’expliquent pas pourquoi un TTL qui tombe à 1 coupe tout trafic, ni comment une mauvaise asymétrie de routage ruine la connectivité. Le jour où l’escalade atteint le NOC, elle se heurte à des concepts que la CCNA aurait gravés dans sa mémoire.

Le scénario “je prends le détour CCNA”

Prenez Malik : il attaque la CCNA, passe des soirées sur Packet Tracer à configurer du STP, du HSRP, à debugger des ACL tordues. Deux-trois mois plus tard, il bascule sur le Cloud Practitioner, puis sur l’AWS SAA. Quand il arrive en entreprise, ses réflexes réseau sont déjà ancrés.
Lorsqu’un micro-service refuse de joindre une base RDS privée, il raisonne instinctivement en couches, isole la route, identifie la MTU, propose un fix — et gagne ses galons plus vite qu’un sprint CI/CD. Sur le papier, son parcours a pris quelques semaines de plus ; dans la réalité, il a gagné des années de crédibilité.

Moralité : tout dépend de votre horizon

• Si vous visez la ramp-up la plus courte possible pour un job d’opérateur Cloud “bouton-poussoir”, la CCNA peut sembler un luxe.

• Si vous visez une carrière où vous signerez des architectures hybrides, rédigerez des RCA post-mortem, conseillerez des migrations on-prem → Cloud, la CCNA devient un multiplicateur.

L’erreur n’est pas de faire l’impasse ; c’est de croire qu’il n’y aura jamais de facture technique à payer. Dans l’IT, la dette finit toujours par se présenter — intérêts composés inclus.

Construire son plan de bataille : marier Cloud & CCNA sans se brûler les ailes

On pourrait croire qu’ajouter des certifs, c’est comme empiler des Lego : un badge puis un autre. Sauf qu’en réalité, c’est un rubik’s cube ; les faces tournent, les couleurs s’entrelacent. Voici un canevas (à adapter, pas à recopier) :

1. Mois 0 – 1 : cartographiez vos lacunes.
   Listez ce qui vous manque côté réseau (subnetting, protocoles) et côté Cloud (services, IAM).

2. Mois 1 – 3 : fondez les bases.

   • Lab CCNA : Packet Tracer ou Eve-NG, 2 heures par soir.

   • Lab Cloud : Free tier AWS/Azure, déployez un VPC et un site statique.

3. Mois 3 – 6 : croisez les flux.
   Montez un VPN site-à-site entre votre lab GNS3 et un VPC ; injectez des routes BGP. Vous transformez la théorie en muscle mémoire.

4. Mois 6 – 9 : certifiez l’un, puis l’autre.
   Passez la CCNA, célébrez, enchaînez sur le badge Cloud. La double réussite choque positivement les recruteurs.

5. Mois 9 + : portefolio public.
   Automatisez votre topologie hybride via Terraform, publiez le repo, rédigez un post-mortem d’incident simulé. Votre GitHub devient votre CV le plus persuasif.

Astuce mindset : considérez chaque chapitre CCNA comme un prétexte à créer un PaaS équivalent. Vous révisez le STP ? Déployez ensuite un stack Kubernetes multi-AZ et comparez les mécanismes de reprise. Le cerveau adore les ponts conceptuels.

Conclusion : le duel qui n’en est pas un

Le Cloud ne “remplacera” pas la CCNA, pas plus que les voitures n’ont tué le permis de conduire ; elles en ont simplement redéfini le code.
En 2025 — et a fortiori en 2030 — les ingénieurs qui compteront ne seront ni 100 % câbles, ni 100 % YAML, mais 100 % adaptables. Leur super-pouvoir ? Savoir quand lever la tête pour voir le service managé, et quand descendre d’un étage pour lire la trame.

La vraie question n’est donc plus « Cloud ou CCNA ? » mais :

« Quelle valeur puis-je créer en combinant les deux, ici et maintenant ? »

Si cet article vous a aidé à clarifier votre feuille de route, ne vous arrêtez pas là !
👉 Lisez notre décryptage “Diplômes RNCP vs Certifications IT : la vérité que personne ne vous dit” pour choisir vos prochains jalons sans tomber dans les pièges marketing.

Et souvenez-vous :

“Le réseau est la scène, le Cloud est le décor. Sans acteurs solides, aucun spectacle ne tient la route.”

À vous de monter le meilleur show.