Réalisation : NetDevOps

Automatisation Backup Réseau

De 4 heures de backup manuel par mois à zéro. Scripts Python et API REST Meraki pour sauvegarder automatiquement les configurations de 50+ réseaux mondiaux.

Présentation du projet

La gestion manuelle des sauvegardes de configuration sur un parc réseau mondial induit des risques réels : oublis, incohérences de version, et en cas de remplacement d'équipement non planifié, la reconfiguration depuis zéro. J'ai développé une solution NetDevOps pour automatiser l'extraction des configurations de l'ensemble des réseaux Criteo via l'API REST Meraki.

Ce projet a été mené en autonomie totale, de l'analyse du besoin au déploiement en production, avec une présentation finale du code et de la documentation à l'équipe Engineering pour validation (code review).

Problème résolu

Sauvegardes manuelles longues, non fiables et non traçables sur un parc de 50+ réseaux mondiaux.

Solution

Script Python exploitant l'API REST Meraki pour extraire et versionner toutes les configurations en JSON.

Impact

4h de travail manuel par mois éliminées, couverture mondiale, zéro risque de perte de configuration.

Objectifs, enjeux et risques

L'objectif principal était d'automatiser la sauvegarde hebdomadaire des configurations de 50+ réseaux mondiaux avec zéro intervention manuelle et une intégrité garantie des données (format JSON versionné). L'enjeu sous-jacent était le Disaster Recovery : en cas de remplacement d'équipement d'urgence, la configuration doit être disponible immédiatement.

Le risque technique principal identifié dès la conception : le dépassement des "Rate Limits" de l'API Meraki, qui peut bloquer d'autres services utilisant la même clé API si les appels ne sont pas correctement cadencés. La gestion des erreurs et le throttling ont donc été intégrés dès le premier prototype.

Disaster Recovery

Garantir la disponibilité des configurations en cas de sinistre ou de remplacement d'équipement non planifié.

Zéro intervention manuelle

Sauvegardes planifiées automatiquement, sans dépendre de la disponibilité d'un ingénieur.

Audit de dérives

Comparaison des snapshots pour détecter toute modification non planifiée sur le parc.

Étapes et acteurs

Le cycle de développement a suivi une approche structurée : analyse du Swagger Meraki pour identifier les endpoints pertinents, prototypage d'un PoC sur un sous-ensemble de réseaux, tests en environnement de staging (Lab réseau isolé), puis mise en production progressive. Le script Python 3.x utilise la librairie Requests pour les appels API REST, avec stockage sécurisé des clés via variables d'environnement.

Le projet a été mené en autonomie complète. La seule interaction externe a été la présentation finale du code et de la documentation technique à l'équipe Engineering pour une code review formelle, un exercice qui m'a obligé à structurer et justifier chaque choix d'implémentation.

Analyse du Swagger Meraki

Exploration de la documentation API officielle pour identifier les endpoints de configuration pertinents.

Prototypage (PoC)

Développement d'un premier script fonctionnel sur un sous-ensemble de réseaux pour valider l'approche.

Tests en staging

Validation en environnement de test isolé avant déploiement sur le parc mondial.

Mise en production

Déploiement sur les 50+ réseaux, mise en place de la planification automatique et du logging.

Résultats et lendemains

Le script est fonctionnel en production et a réduit le temps de backup de 4 heures par mois à zéro, tout en améliorant la fiabilité et la traçabilité. La comparaison des snapshots successifs permet désormais de détecter toute dérive de configuration non planifiée sur le parc.

La perspective directe est l'intégration dans un pipeline CI/CD pour versionner les configurations sur Git, ce qui permettrait de traiter les configurations réseau avec les mêmes pratiques que le code logiciel : historique, revue, rollback. Une trajectoire naturelle vers une approche Network-as-Code.

4h/mois → 0 min

Le temps de backup manuel a été réduit à zéro, le script s'exécute de façon planifiée sans intervention.

50+ réseaux couverts

L'ensemble du parc mondial Criteo est sauvegardé automatiquement en JSON versionné.

Logging précis

Identification automatique des réseaux n'ayant pu être sauvegardés, avec code d'erreur et timestamp.

Mon regard critique

Ce projet a validé ma capacité à lier développement et réseau, ce qu'on appelle aujourd'hui le NetDevOps. Il est né d'une initiative personnelle : j'ai identifié un risque non couvert (perte de configuration en cas de remplacement d'urgence), proposé une solution, et la déployée sans être sollicité. C'est ce type de démarche proactive qui, selon moi, différencie un ingénieur qui exécute d'un ingénieur qui contribue.

L'enseignement le plus durable : le code écrit en urgence sans tests ni logging structuré finit par créer plus de problèmes qu'il n'en résout. La rigueur dans le développement, même pour des scripts "internes", est aussi importante que dans les configurations réseau.

Valeur ajoutée

Première initiative hors périmètre défini, identification autonome du risque, développement et déploiement.

Enseignement clé

L'ingénieur réseau moderne doit savoir coder. Le scripting rend l'infrastructure plus résiliente et l'équipe moins dépendante des interventions manuelles.

Compétences mises en oeuvre

Automatisation & Scripting

Python 3.x, API REST Meraki, gestion des erreurs, throttling, logging structuré.

Gestion d'équipements réseau

Connaissance approfondie de l'API Meraki et de la structure de configuration des équipements.

Autonomie

Projet initié et mené de bout en bout en autonomie complète, hors périmètre initial.