Réalisation : Infrastructure & R&D
Lab de staging réseau
Création from scratch d'un environnement de staging Meraki full-stack isolé de la production, pour valider chaque configuration, firmware et nouvelle fonctionnalité avant de toucher le réseau réel.
Présentation du projet
Avant la création de ce Lab, l'équipe réseau Criteo ne disposait d'aucun environnement de test dédié. Les nouvelles configurations, VLAN, politiques d'accès, firmware, nouvelles fonctionnalités Meraki, étaient validées directement en production, ce qui exposait le réseau à des interruptions de service non planifiées.
J'ai identifié ce risque, proposé l'architecture d'un environnement de staging isolé, et piloté sa mise en service de bout en bout en autonomie. Le Lab est aujourd'hui utilisé par l'ensemble de l'équipe réseau comme référence pour valider les changements avant production.
Points clés
Risque identifié
Aucun environnement de test disponible, VLANs, firmware, politiques d'accès, tout se testait directement en production. Risque d'interruption de service non planifiée à chaque changement.
Lab Meraki full-stack isolé
MX + MS210 + MR46 + segment IoT, rattachés à une org Meraki Dashboard distincte de la prod avec un ISP différent pour une isolation totale.
Évolution : intégration Catalyst
Redesign du Lab pour intégrer un Catalyst C9300-24S en core switch et tester l'interopérabilité Meraki/Catalyst avant déploiement en production.
Objectifs, enjeux et risques
Les objectifs du Lab étaient multiples : disposer d'un environnement de test isolé reproduisant l'infrastructure de production (avec ISP différent pour garantir l'isolation), tester les nouvelles fonctionnalités Meraki avant de les activer en production (Access Manager, Entra ID), et évaluer l'ajout de nouveaux équipements (Catalyst switches, Cisco APs, sensors IoT) avant de les intégrer au parc réel.
L'enjeu principal était la réduction du risque opérationnel : chaque configuration non testée est un pari sur la production. Le Lab transforme ce pari en certitude, ou en apprentissage contrôlé.
Points clés
Isolation totale
ISP différent de la production, aucun risque d'impact croisé entre le Lab et l'infrastructure réelle.
Fidélité à la prod
Topologie reproduisant l'infrastructure réelle : MX (core), MS210 (distribution + access), MR46 (Wi-Fi), segment IoT.
R&D Meraki
Test des nouvelles fonctionnalités Meraki avant déploiement : Access Manager, intégration Entra ID, nouveaux équipements.
Étapes et acteurs
Tout est parti d'un constat que j'ai remonté à mon maître d'apprentissage : on n'avait aucun filet de sécurité. Les nouvelles configurations de VLANs, les mises à jour firmware, les nouvelles politiques d'accès, tout ça se testait directement en production. J'ai proposé de construire un Lab isolé qui reproduit la topologie réelle. Le projet a été validé et j'en ai pris la charge en autonomie complète.
La première phase a été de construire l'architecture Meraki full-stack. Un MX en cœur de réseau pour le routage, le DHCP et le firewall. Des MS210 en distribution et en access, câblés comme en prod. Des APs MR46 avec les mêmes SSIDs et les mêmes politiques d'accès que les étages Criteo. Un segment IoT isolé reproduisant les capteurs MT10 du parc réel. Le tout rattaché à une organisation Meraki Dashboard séparée de la production, avec un ISP différent pour garantir une isolation totale.
Une fois le Lab opérationnel, j'ai documenté l'architecture sur Confluence : topologie complète, plan VLAN, configurations appliquées, procédures de test à suivre. L'objectif était que n'importe quel membre de l'équipe puisse utiliser le Lab correctement sans avoir à me demander.
La deuxième grande phase est arrivée quand Criteo a décidé d'intégrer des switches Cisco Catalyst legacy dans l'infrastructure Meraki existante. J'ai redesigné le Lab pour intégrer un Catalyst C9300-24S en position de core switch, entre le MX et les MS210. Côté configuration CLI : mise en place du port-channel vers les MS210 Meraki, désignation du Catalyst comme root bridge STP pour éviter tout problème de boucle, configuration des trunks VLAN. Ensuite j'ai validé l'interopérabilité : propagation des VLANs, stabilité STP dans les deux sens, routage inter-VLAN correct à travers les deux familles d'équipements.
C'est sur cette phase que le Lab a prouvé sa valeur de la façon la plus concrète : un test d'upgrade de configuration sur les switches a mis en évidence une boucle STP naissante, avec du MAC flapping à la clé. Détectée et corrigée en Lab, elle n'a jamais atteint la production, là où elle aurait provoqué une dégradation visible sur l'étage concerné.
Le Lab a aussi servi de terrain pour tester les nouvelles fonctionnalités Meraki avant de les activer à l'échelle mondiale : Access Manager pour la gestion fine des accès réseau, et l'intégration Entra ID pour l'authentification Wi-Fi. Chaque test réussi en Lab a été une condition préalable à l'activation en prod.
Aujourd'hui le Lab est utilisé quotidiennement par l'équipe réseau, et ponctuellement par l'équipe EUS, soit une dizaine de personnes au total. Protocole en place : tout changement significatif passe d'abord par le Lab. Chaque test mené est consigné sur des pages Confluence dédiées. Je fais aussi une vérification régulière pour m'assurer que la topologie du Lab reste fidèle à celle de la prod, un Lab qui dérive de la réalité donne une fausse confiance, presque pire que de ne pas en avoir.
Points clés
Phase 1 · Constat et proposition
Constat remonté à mon maître d'apprentissage : aucun filet de sécurité, tout se testait directement en prod. Proposition d'un Lab isolé avec ISP différent. Feu vert donné, projet piloté en autonomie complète.
Phase 2 · Architecture Meraki full-stack
MX en cœur (routage, DHCP, firewall), MS210 en distribution + access câblés comme en prod, APs MR46 avec les mêmes SSIDs et politiques d'accès, segment IoT isolé (MT10). Org Meraki Dashboard distincte de la production, ISP différent.
Phase 3 · Documentation initiale
Architecture documentée sur Confluence : topologie complète, plan VLAN, configurations appliquées, procédures de test. Objectif : que n'importe quel membre de l'équipe puisse utiliser le Lab sans me demander.
Phase 4 · Intégration Catalyst C9300-24S
Redesign du Lab avec un Catalyst C9300-24S en core switch entre le MX et les MS210. Config CLI : port-channel vers les MS210, root bridge STP, trunks VLAN. Validation interopérabilité. Un test d'upgrade a mis en évidence une boucle STP naissante avec MAC flapping, détectée et corrigée en Lab, jamais atteint la prod.
Phase 5 · Validation nouvelles fonctionnalités
Validation d'Access Manager et de l'intégration Entra ID pour l'authentification Wi-Fi. Chaque test réussi en Lab = condition préalable à l'activation en prod mondiale.
Phase 6 · Exploitation et maintien en condition
Utilisé quotidiennement par ~10 personnes (équipe réseau + EUS ponctuellement). Protocole : tout changement significatif passe d'abord par le Lab. Tests consignés sur Confluence. Vérification régulière de l'alignement Lab/prod.
Résultats et lendemains
Le Lab est aujourd'hui utilisé quotidiennement par l'équipe réseau, et ponctuellement par l'équipe EUS. Son existence a changé la façon dont l'équipe aborde les changements de configuration : plus aucune modification significative n'est appliquée directement en production sans avoir été validée en Lab au préalable. Il a déjà évité au moins un incident concret, une boucle STP avec MAC flapping interceptée lors d'un test d'upgrade de configuration sur les Catalyst, qui n'a jamais atteint la production.
L'enjeu désormais est de continuer à enrichir le catalogue de tests sur Confluence et de garder le Lab strictement aligné sur la production, condition pour qu'il reste un filet de sécurité fiable dans la durée.
Points clés
Incident concret évité
Boucle STP avec MAC flapping interceptée lors d'un test d'upgrade Catalyst en Lab, jamais atteint la production. C'est la preuve la plus concrète de la valeur du Lab.
Adoption collective (~10 personnes)
Utilisé quotidiennement par l'équipe réseau + EUS ponctuellement. Protocole en place : tout changement significatif validé en Lab avant prod.
Interop Catalyst validée en prod
L'intégration des C9300-24S en production s'est faite avec confiance, grâce aux tests préalables d'interopérabilité Meraki/Catalyst en Lab.
Catalogue de tests Confluence
Historique des validations réutilisable par toute l'équipe, avec les procédures de test et les résultats consignés au fil de l'eau.
Mon regard critique
Ce projet est celui dont je suis le plus fier dans mon parcours à Criteo, précisément parce qu'il n'était pas demandé. J'ai identifié un risque opérationnel, proposé une solution, et construit quelque chose qui a changé la façon dont l'équipe travaille, pas seulement résolu un problème ponctuel.
Sur la durée, j'ai compris que la vraie contrainte n'est pas de monter le Lab, c'est de le maintenir aligné sur la prod. J'ai fait l'erreur une fois de tester une config sur un environnement qui avait légèrement dérivé, le test était bon, la prod a réagi différemment. Depuis, je vérifie régulièrement l'alignement entre les deux, et chaque test mené est consigné sur Confluence pour que l'historique reste exploitable.
Points clés
Initiative non demandée, valeur collective
Projet identifié et piloté en autonomie. Au-delà du déploiement, c'est une pratique d'ingénierie qui a changé durablement la façon de travailler de toute l'équipe.
La boucle STP : preuve concrète
Un Lab n'a de valeur que s'il est utilisé. La boucle STP / MAC flapping interceptée en Lab avant la prod est l'exemple le plus concret de ce que ça évite.
Enseignement clé : maintenance = condition sine qua non
Un Lab qui dérive de la production finit par donner une fausse confiance. La rigueur dans la maintenance est aussi importante que la création.
Compétences mises en œuvre
Points clés
Conception & infrastructure
Architecture full-stack Meraki + Catalyst, topologie, segmentation, interopérabilité.
Gestion d'équipements réseau
Configuration CLI Catalyst, dashboard Meraki, port-channel, STP, segments IoT.
Autonomie
Projet initié, piloté et livré en autonomie complète, de l'identification du besoin à la mise en service.
Documentation technique
DAT complet du Lab, topologie, configurations, procédures de test et runbooks.
Adaptabilité technologique
Intégration Cisco Catalyst CLI dans un environnement Meraki cloud-managed : nouveau paradigme de configuration.