Le code d’examen reste 200-301, mais les domaines et le niveau attendu évoluent. Le dernier jour de passage de la v1.1 est le 2 février 2027 ; la v2.0 démarre le 3 février 2027. Calendrier officiel Cisco.
Retrouvez les programmes complets en français dans la fiche CCNA v1.1 et la fiche CCNA v2.0. Cette page sert à comparer les deux versions, d’abord dans leurs grandes lignes, puis objectif par objectif.
CCNA v1.1 vs v2.0 : comparaison de synthèse
Sur un petit écran, faites défiler les tableaux horizontalement pour lire les colonnes côte à côte.
| Thème | CCNA v1.1 | CCNA v2.0 |
|---|---|---|
| Passage de l’examen | Jusqu’au 2 février 2027 inclus. | À partir du 3 février 2027. Code 200-301 conservé. |
| Organisation | 6 domaines : 20 / 20 / 25 / 10 / 15 / 10 %. | 5 domaines : 25 / 25 / 20 / 20 / 10 %. Les regroupements changent. |
| Infrastructure et adressage | Comparer, décrire, configurer et vérifier les bases physiques et IP. | Diagnostiquer interfaces/câbles ; dépanner IPv4/IPv6 et clients. Virtualisation et principes Wi-Fi restent présents. |
| Commutation et accès | Accès réseau : 20 %. VLAN, trunks, LACP, Rapid PVST+ et WLAN. | Commutation et accès : 25 %. Raccordement des équipements, SVI, LACP et configuration Rapid PVST+. La GUI WLAN n’est plus explicitée séparément. |
| Routage | Connectivité IP : 25 %. Routage statique, OSPFv2 et concepts de redondance. | Routage IP : 20 %. Dépannage statique ; OSPFv2 et OSPFv3 mono-zone ; interprétation HSRP/VRRP. |
| Services et sécurité | Services IP 10 % et sécurité 15 %, dans deux domaines. | Services réseau et sécurité : 20 %. AAA, SFTP/SCP, NAT/PAT, DNS, IPsec, ACL IPv4 et sécurité L2. |
| Automatisation, IA et supervision | Automatisation/programmabilité : 10 %. IA générative/prédictive, ML, REST, Ansible/Terraform et JSON. SNMP/syslog dans les services IP. | IA, exploitation et gestion : 10 %. IA agentique, prompts, approches de gestion, commandes Ansible, SNMP et lecture syslog. |
| Préparation pratique | Configuration/vérification et connaissance des concepts. | Davantage de diagnostic et d’interprétation. Les bases conservées doivent être utilisables dans une panne réelle. |
Comparaison détaillée des objectifs
Comment lire le tableau : la colonne de gauche reprend les 53 objectifs principaux de la v1.1 et leurs sous-points. La colonne de droite indique les références v2.0 concernées et explique le changement de compétence. Une correspondance peut être partielle ou concerner plusieurs objectifs.
« Non repris séparément » signifie que le thème n’est plus explicitement formulé comme objectif autonome dans le programme publié. Cela ne signifie pas que ses bases deviennent inutiles. Les pondérations des domaines ne se comparent pas mécaniquement, car leur périmètre est réorganisé.
| Objectifs CCNA v1.1 | Correspondance v2.0 et évolution à préparer |
|---|---|
| 1.1 Expliquer le rôle et la fonction des composants réseau • 1.1.a Routeurs • 1.1.b Commutateurs de couche 2 et couche 3 • 1.1.c Pare-feu nouvelle génération et IPS • 1.1.d Points d’accès • 1.1.e Contrôleurs • 1.1.f Points terminaux • 1.1.g Serveurs • 1.1.h PoE (Power over Ethernet) | Regroupé Objectif v2.0 2.2 ; Objectif v2.0 1.2 La liste des rôles des composants n’est plus un objectif autonome. Le raccordement des terminaux et la virtualisation donnent un contexte pratique à une partie de ces connaissances. Le PoE est explicitement repris dans les attributs des ports. |
| 1.2 Décrire les caractéristiques des architectures de topologie réseau • 1.2.a Deux niveaux • 1.2.b Trois niveaux • 1.2.c Spine-leaf • 1.2.d WAN • 1.2.e Bureau à domicile/petit bureau (SOHO) • 1.2.f Sur site et cloud | Non repris séparément Objectif v2.0 2.1 ; Objectif v2.0 5.3 Les architectures deux/trois niveaux, spine-leaf, WAN et SOHO ne sont plus énumérées comme dans la v1.1. Les nouvelles approches de gestion ne constituent pas un remplacement terme à terme des topologies. |
| 1.3 Comparer les types d’interfaces physiques et de câblage • 1.3.a Fibre monomode, fibre multimode, cuivre • 1.3.b Connexions (média partagé Ethernet et point-à-point) | Renforcé Objectif v2.0 1.1 Comparer les supports devient diagnostiquer leurs défauts. Le périmètre explicite s’étend à la distance, aux niveaux du signal, au brochage et au choix du câble ou de l’interface. Il faut relier les symptômes au support physique. |
| 1.4 Identifier les problèmes d’interface et de câble (collisions, erreurs, duplex non correspondant, et/ou vitesse) | Renforcé Objectif v2.0 1.1 Le diagnostic reste centré sur collisions, erreurs, duplex et débit, mais demande aussi d’exploiter des indices physiques. Préparer des scénarios de mauvais câblage et d’incompatibilité d’interface, pas seulement une liste de symptômes. |
| 1.5 Comparer TCP à UDP | Non repris séparément Aucun équivalent autonome nommé. La comparaison TCP/UDP n’est plus nommée comme objectif autonome. Ces bases restent utiles pour comprendre le fonctionnement de services comme DNS et DHCP ; cette utilité pédagogique ne constitue pas un nouvel objectif Cisco. |
| 1.6 Configurer et vérifier l’adressage IPv4 et le sous-réseau | Dépannage Objectif v2.0 1.3 La v1.1 demande de configurer et vérifier ; la v2.0 demande de dépanner. Il faut retrouver une erreur d’adresse, de masque ou d’attribution et choisir une correction, pour les adresses publiques comme privées. |
| 1.7 Décrire l’adressage IPv4 privé | Intégré Objectif v2.0 1.3 L’adressage privé rejoint le dépannage IPv4 avec l’adressage public. La distinction reste à maîtriser, mais elle est appliquée à une situation de connectivité plutôt qu’isolée dans un objectif descriptif. |
| 1.8 Configurer et vérifier l’adressage IPv6 et le préfixe | Dépannage Objectif v2.0 1.4 Le changement porte sur la configuration erronée, l’attribution et la longueur du préfixe IPv6. Le programme cite explicitement unicast et EUI-64 modifié. S’entraîner à interpréter la configuration et les symptômes d’un préfixe incorrect. |
| 1.9 Décrire les types d’adresses IPv6 • 1.9.a Unicast (globale, locale unique, et locale de lien) • 1.9.b Anycast • 1.9.c Multicast • 1.9.d EUI 64 modifié | Périmètre reformulé Objectif v2.0 1.4 Unicast et EUI-64 modifié restent explicites. Anycast et multicast ne sont plus détaillés en tant que sous-objectifs dans ce libellé. Éviter d’assimiler cette absence à une interdiction de mobiliser ces notions. |
| 1.10 Vérifier les paramètres IP pour les OS clients (Windows, Mac OS, Linux) | Renforcé Objectif v2.0 1.6 La simple vérification IP d’un poste évolue vers le dépannage de clients filaires et sans fil. Aux paramètres IP s’ajoutent la joignabilité et la sécurité Wi-Fi, sous Windows, macOS et Linux. |
| 1.11 Décrire les principes sans fil • 1.11.a Canaux Wi-Fi non chevauchants • 1.11.b SSID • 1.11.c RF (Radiofréquence) • 1.11.d Chiffrement | Recentré Objectif v2.0 1.5 La v2.0 organise les principes Wi-Fi autour du choix bandes/canaux, des caractéristiques RF, des protocoles de sécurité et des causes d’interférences. Le SSID n’est plus un sous-objectif nommé séparément. |
| 1.12 Expliquer les fondamentaux de virtualisation (virtualisation serveur, conteneurs, et VRF) | Reformulé Objectif v2.0 1.2 Le nouveau libellé met en avant hyperviseurs, machines virtuelles et conteneurs. Les VRF, citées dans la v1.1, ne figurent plus dans cet objectif de virtualisation ; ne pas les confondre avec les machines virtuelles. |
| 1.13 Décrire les concepts de commutation • 1.13.a Apprentissage et vieillissement MAC • 1.13.b Commutation de trames • 1.13.c Inondation de trames • 1.13.d Table d’adresses MAC | Mise en pratique Objectif v2.0 2.1 ; Objectif v2.0 2.2 ; Objectif v2.0 2.4 Apprentissage MAC, vieillissement, diffusion et table MAC ne sont plus une liste autonome. Leur compréhension sert au raccordement et au diagnostic L2/L3. Travailler l’analyse d’une panne de commutation plutôt que la seule définition des mécanismes. |
| 2.1 Configurer et vérifier les VLAN (plage normale) s’étendant sur plusieurs commutateurs • 2.1.a Ports d’accès (données et voix) • 2.1.b VLAN par défaut • 2.1.c Connectivité InterVLAN | Réorganisé Objectif v2.0 2.1 ; Objectif v2.0 2.2 Les compétences VLAN sont réparties entre liaisons d’infrastructure et ports des terminaux. Le nouveau périmètre explicite interfaces L2/L3, SVI et attributs VLAN/PoE/LACP. Les terminaux couvrent postes, imprimantes/IoT, AP, téléphones, hôtes virtualisés et appliances. |
| 2.2 Configurer et vérifier la connectivité inter-commutateurs • 2.2.a Ports trunk • 2.2.b 802.1Q • 2.2.c VLAN natif | Conservé et regroupé Objectif v2.0 2.1 Les trunks 802.1Q rejoignent les liaisons entre commutateurs et vers les routeurs. Le VLAN natif n’est plus un sous-point nommé séparément, mais les trunks restent explicitement à configurer. |
| 2.3 Configurer et vérifier les protocoles de découverte de couche 2 (Cisco Discovery Protocol et LLDP) | Changement d’usage Objectif v2.0 2.3 Configurer et vérifier CDP/LLDP devient utiliser ces protocoles pour valider l’exactitude d’une documentation réseau. Il faut confronter voisins et ports observés à un schéma ou un inventaire. |
| 2.4 Configurer et vérifier EtherChannel (couche 2/couche 3) (LACP) | Conservé et élargi Objectif v2.0 2.1 ; Objectif v2.0 2.2 EtherChannel/port-channel LACP L2 et L3 reste explicite. Il apparaît aussi parmi les attributs des ports pour les hôtes ; la préparation doit distinguer le rôle de l’agrégation côté infrastructure et côté terminal. |
| 2.5 Interpréter les opérations de base du protocole Rapid PVST+ Spanning Tree • 2.5.a Port racine, pont racine (primaire/secondaire), et autres noms de ports • 2.5.b États et rôles des ports • 2.5.c PortFast • 2.5.d Root guard, loop guard, filtre BPDU, et garde BPDU | Configuration renforcée Objectif v2.0 2.5 La v1.1 dit interpréter, la v2.0 dit configurer Rapid PVST+. Pont primaire/secondaire, ports/rôles, PortFast et les guards restent explicites. BPDU filter n’est plus nommé dans la nouvelle liste, contrairement à BPDU guard. |
| 2.6 Décrire les architectures sans fil Cisco et les modes AP | Recentré Objectif v2.0 1.5 ; Objectif v2.0 2.2 Les AP autonomes et gérés par contrôleur restent cités pour leur raccordement. En revanche, l’architecture détaillée des contrôleurs et les modes AP ne sont plus présentés comme un objectif autonome. Le Wi-Fi n’a donc pas disparu. |
| 2.7 Décrire les connexions d’infrastructure physique des composants WLAN (AP, WLC, ports d’accès/trunk, et LAG) | Regroupé Objectif v2.0 2.1 ; Objectif v2.0 2.2 La connectivité physique des AP rejoint les ports d’accès et les liaisons d’infrastructure. Les trunks et LACP demeurent explicites. Le WLC n’est plus détaillé comme composant d’une liste de connexions WLAN distincte. |
| 2.8 Décrire l’accès de gestion des équipements réseau (Telnet, SSH, HTTP, HTTPS, console, TACACS+/RADIUS, et gestion cloud) | Réorienté Objectif v2.0 4.1 ; Objectif v2.0 5.3 Le nouveau programme met l’accent sur les comptes locaux, les clients AAA TACACS+/RADIUS et les approches de gestion. L’ancienne énumération Telnet/SSH/HTTP/HTTPS/console n’est plus un objectif indépendant. |
| 2.9 Interpréter la configuration GUI du WLAN sans fil pour la connectivité client (création WLAN, paramètres de sécurité, profils QoS, et paramètres avancés) | GUI non reprise explicitement Objectif v2.0 1.5 ; Objectif v2.0 1.6 La création de WLAN, les profils QoS et les paramètres avancés dans une GUI de contrôleur ne sont plus détaillés. Les principes radio et la connectivité/sécurité des clients Wi-Fi restent dans le périmètre. |
| 3.1 Interpréter les composants de la table de routage • 3.1.a Code de protocole de routage • 3.1.b Préfixe • 3.1.c Masque réseau • 3.1.d Prochain saut • 3.1.e Distance administrative • 3.1.f Métrique • 3.1.g Passerelle de dernier recours | Plus opérationnel Objectif v2.0 3.1 La table de routage doit servir à déterminer le prochain saut d’un paquet. Protocole, préfixe/masque, distance administrative, métrique et route par défaut restent à interpréter ensemble. |
| 3.2 Déterminer comment un routeur prend une décision de transfert par défaut • 3.2.a Correspondance de préfixe le plus long • 3.2.b Distance administrative • 3.2.c Métrique du protocole de routage | Intégré Objectif v2.0 3.1 Les critères de choix ne sont plus isolés dans une seconde liste. Ils restent nécessaires pour justifier un prochain saut à partir de la table. Préparer des lectures de tables avec plusieurs routes candidates. |
| 3.3 Configurer et vérifier le routage statique IPv4 et IPv6 • 3.3.a Route par défaut • 3.3.b Route réseau • 3.3.c Route hôte • 3.3.d Statique flottante | Dépannage Objectif v2.0 3.2 Les quatre types de routes sont conservés : par défaut, réseau, hôte et flottante. L’attendu passe de configurer/vérifier à identifier puis corriger les pannes de routage statique IPv4 et IPv6. |
| 3.4 Configurer et vérifier OSPFv2 zone unique • 3.4.a Adjacences de voisins • 3.4.b Point-à-point • 3.4.c Diffusion (sélection DR/BDR) • 3.4.d ID du routeur | Ajout OSPFv3 Objectif v2.0 3.3 À OSPFv2 pour IPv4 s’ajoute explicitement OSPFv3 pour IPv6. Le cadre reste mono-zone, avec voisinages, point à point, élection DR/BDR et Router ID. L’authentification est exclue du sous-objectif consacré aux adjacences. |
| 3.5 Décrire l’objectif, les fonctions et concepts des protocoles de redondance de premier saut | Interprétation opérationnelle Objectif v2.0 3.4 HSRP et VRRP sont désormais nommés. La préparation doit permettre de lire leur état et d’en déduire le fonctionnement de la redondance de premier saut, au-delà de la description générale de son utilité. |
| 4.1 Configurer et vérifier le NAT de source interne avec des traductions statiques et des pools | PAT explicite Objectif v2.0 4.3 La v1.1 vise le NAT de source interne avec traductions statiques et pools. La v2.0 nomme NAT/PAT sur IOS XE. Pour la pratique, distinguer traduction statique, utilisation d’un pool et surcharge PAT, puis choisir la configuration adaptée au besoin. |
| 4.2 Configurer et vérifier NTP fonctionnant en mode client et serveur | Non repris séparément Aucun équivalent autonome nommé. NTP client/serveur n’apparaît plus comme objectif autonome. Cela ne transforme pas la synchronisation horaire en mauvaise pratique ; cela décrit uniquement le niveau de détail du programme publié. |
| 4.3 Expliquer le rôle de DHCP et DNS dans le réseau | Deux diagnostics distincts Objectif v2.0 1.7 ; Objectif v2.0 4.4 DHCP devient un objectif de dépannage client/serveur/relais sur IOS. DNS passe à l’analyse des enregistrements A, AAAA, CNAME, MX, NS et PTR selon l’usage : hôte, application web ou messagerie. |
| 4.4 Expliquer la fonction de SNMP dans les opérations réseau | Déplacé Objectif v2.0 5.4 SNMP rejoint le domaine IA, exploitation et gestion du réseau. Son rôle reste descriptif ; le déplacement du numéro de domaine ne signifie pas qu’il s’agit d’une nouvelle technologie à apprendre. |
| 4.5 Décrire l’utilisation des fonctionnalités syslog (y compris les facilités et niveaux de gravité) | Interprétation renforcée Objectif v2.0 5.6 Il faut interpréter des messages, leurs niveaux de gravité et leurs facilities. L’exercice utile est de lire un journal et d’en tirer une information de diagnostic, pas seulement de réciter les niveaux. |
| 4.6 Configurer et vérifier le client et relais DHCP | Serveur et dépannage Objectif v2.0 1.7 Le client et le relais sont conservés ; le serveur DHCPv4 est maintenant explicitement cité. Le niveau attendu porte sur la recherche de panne sur les équipements IOS. |
| 4.7 Expliquer le comportement de transfert par saut (PHB) pour QoS • Classification • Marquage • Mise en file d’attente • Congestion • Policing • Shaping | Non repris séparément Aucun équivalent autonome nommé. La liste PHB de QoS — classification, marquage, files, congestion, policing et shaping — n’est plus explicitée comme objectif autonome de la v2.0. Le changement concerne ici le découpage du programme publié. |
| 4.8 Configurer les équipements réseau pour l’accès distant utilisant SSH | Administration reformulée Objectif v2.0 4.1 Le nouvel objectif nomme comptes locaux et client AAA, sans reproduire l’ancien objectif SSH séparé. La configuration d’un accès d’administration et les notions d’authentification doivent rester cohérentes. |
| 4.9 Décrire les capacités et fonctions de TFTP/FTP dans le réseau | Transferts sécurisés Objectif v2.0 4.2 Décrire FTP/TFTP laisse place à la gestion effective des fichiers de configuration et logiciels avec SFTP/SCP. Il faut préparer les opérations de transfert et leur usage, pas seulement définir des protocoles. |
| 5.1 Définir les concepts clés de sécurité • Menaces • Vulnérabilités • Exploits • Techniques d’atténuation | Concepts non isolés Objectif v2.0 4.5 ; Objectif v2.0 4.6 ; Objectif v2.0 4.7 Menaces, vulnérabilités, exploits et atténuation ne sont plus une liste d’objectifs distincte. Les tâches VPN, ACL et sécurité L2 demandent toujours une compréhension du problème de sécurité traité. |
| 5.2 Décrire les éléments du programme de sécurité • Sensibilisation des utilisateurs • Formation • Contrôle d’accès physique | Non repris séparément Aucun équivalent autonome nommé. Sensibilisation, formation et contrôle d’accès physique ne sont plus énumérés comme éléments d’un programme de sécurité dans ce blueprint. Ces pratiques organisationnelles ne sont pas remplacées par un objectif technique équivalent. |
| 5.3 Configurer et vérifier le contrôle d’accès aux équipements utilisant des mots de passe locaux | AAA mis en pratique Objectif v2.0 4.1 Aux mots de passe locaux succèdent les comptes locaux et la configuration d’un client AAA TACACS+/RADIUS pour l’administration. La relation entre équipement, serveur AAA et identification de l’utilisateur devient centrale. |
| 5.4 Décrire les éléments de politique de mot de passe de sécurité • Gestion • Complexité • Alternatives de mot de passe: • Authentification multifacteur • Certificats • Biométrie | Non repris séparément Aucun équivalent autonome nommé. La politique de mots de passe, MFA, certificats et biométrie ne sont plus détaillés en tant qu’objectif autonome. Aucun nouveau libellé ne reprend cette liste point par point. |
| 5.5 Décrire les VPN d’accès distant et site-à-site IPsec | Périmètre précisé Objectif v2.0 4.5 Les VPN d’accès distant et site à site restent présents. Les protocoles et les modes de transport sont explicitement mentionnés dans la v2.0 ; le niveau demandé reste descriptif. |
| 5.6 Configurer et vérifier les listes de contrôle d’accès | IPv4 précisé Objectif v2.0 4.6 Le nouveau libellé cite ACL standard/étendues et numérotées/nommées, dans le périmètre IPv4. Distinguer ces catégories et préparer la syntaxe de configuration adaptée à chaque usage. |
| 5.7 Configurer et vérifier les fonctionnalités de sécurité de couche 2 • DHCP snooping • Inspection ARP dynamique • Sécurité des ports | Protections ajoutées Objectif v2.0 4.7 DHCP snooping, inspection ARP dynamique et port security restent présents. Deux protections sont ajoutées explicitement à la liste : storm control et RA guard. Les exercices doivent permettre de distinguer leurs menaces et leurs usages. |
| 5.8 Comparer les concepts d’authentification, d’autorisation et de comptabilisation AAA | De la comparaison à la configuration Objectif v2.0 4.1 L’authentification, l’autorisation et la comptabilisation AAA passent d’une comparaison conceptuelle à la configuration d’un équipement client. Les notions restent une base pour comprendre les échanges avec TACACS+ ou RADIUS. |
| 5.9 Décrire les protocoles de sécurité sans fil (WPA, WPA2, et WPA3) | Reformulé Objectif v2.0 1.5 ; Objectif v2.0 1.6 Les protocoles de sécurité Wi-Fi et les paramètres des clients sont maintenus. WPA/WPA2/WPA3 ne sont plus énumérés séparément dans le nouveau sous-objectif ; la sécurité sans fil reste présente dans les compétences à travailler. |
| 5.10 Configurer et vérifier WLAN dans l’interface graphique utilisant WPA2 PSK | GUI non reprise explicitement Objectif v2.0 1.6 La configuration WLAN WPA2-PSK dans la GUI n’a plus d’objectif dédié. Le nouveau point de comparaison est le dépannage de la connectivité et des paramètres de sécurité côté client, et non la création du WLAN dans le contrôleur. |
| 6.1 Expliquer comment l’automatisation impacte la gestion réseau | Plus appliqué Objectif v2.0 5.3 ; Objectif v2.0 5.5 L’impact général de l’automatisation est replacé parmi les approches de gestion et l’exécution de commandes avec Ansible. La pratique attendue dépasse l’identification de ses seuls bénéfices. |
| 6.2 Comparer les réseaux traditionnels avec les réseaux basés sur contrôleur | Approches élargies Objectif v2.0 5.3 Le nouveau texte cite gestion par équipement, cloud, contrôleur, automatisation et IaC. La comparaison traditionnelle/contrôleur devient donc une partie d’une classification plus large. |
| 6.3 Décrire l’architecture définie par logiciel basée sur contrôleur (overlay, underlay, et fabric) • 6.3.a Séparation du plan de contrôle et du plan de données • 6.3.b API Northbound et Southbound | Architecture moins détaillée Objectif v2.0 5.3 Les approches à contrôleur restent citées, mais overlay/underlay/fabric, séparation des plans et API northbound/southbound ne sont plus sous-détaillés. Cette correspondance est partielle, pas une équivalence complète du contenu SDN. |
| 6.4 Expliquer l’IA (générative et prédictive) et l’apprentissage automatique dans les opérations réseau | IA agentique et prompts Objectif v2.0 5.1 ; Objectif v2.0 5.2 L’IA générative/prédictive et le machine learning étaient déjà présents en v1.1. La nouveauté tient au rôle de l’IA agentique et au choix d’un prompt : classification des données, format de sortie, rôle/persona et consignes. Ces compétences prolongent le thème IA déjà introduit dans la v1.1. |
| 6.5 Décrire les caractéristiques des API basées sur REST • Types d’authentification • CRUD • Verbes HTTP • Encodage des données | Non repris séparément Aucun équivalent autonome nommé. Authentification REST, CRUD, verbes HTTP et encodage ne sont plus un objectif autonome. Les autres objectifs d’automatisation ne reprennent pas cette ancienne liste détaillée. |
| 6.6 Reconnaître les capacités des mécanismes de gestion de configuration (Ansible et Terraform) | Ansible renforcé, Terraform non nommé Objectif v2.0 5.3 ; Objectif v2.0 5.5 Ansible doit servir à exécuter des commandes. L’IaC reste citée comme approche de gestion, sans que Terraform soit nommé. La préparation doit donc distinguer la connaissance des approches de gestion et l’utilisation pratique d’Ansible. |
| 6.7 Reconnaître les composants des données encodées en JSON | Non repris séparément Aucun équivalent autonome nommé. La reconnaissance des composants JSON n’apparaît plus comme objectif autonome. Un format de sortie d’IA ou un outil pouvant utiliser JSON n’est pas une preuve que cet ancien objectif est repris sans changement. |
| Pas d’objectif transversal autonome équivalent en v1.1 Les outils de diagnostic étaient mobilisés dans plusieurs compétences techniques. | Objectif transversal explicite Objectif v2.0 2.4 La v2.0 réunit show (dont les journaux), ping, extended ping, traceroute et les résultats de captures. Préparer une démarche : observer, formuler une hypothèse, choisir le test, interpréter le résultat puis vérifier la correction. Ce nouvel objectif couvre le fonctionnement des équipements et la connectivité L2/L3. |
Quelle version préparer ?
Le choix dépend de votre date de passage. Pour un examen au plus tard le 2 février 2027, travaillez le programme v1.1. À compter du 3 février 2027, utilisez le programme v2.0 et prévoyez du temps pour les compétences de diagnostic et les ajouts identifiés dans le tableau.
Si votre préparation v1.1 est déjà avancée, identifiez d’abord les compétences acquises qui restent utiles. Pour basculer vers la v2.0, faites ensuite un bilan ciblé : OSPFv3, serveur DHCPv4, diagnostic DNS, transferts sécurisés, nouvelles protections L2 et usage de l’IA. Le tableau détaillé permet de transformer ce bilan en liste d’exercices.
