Une migration réseau échoue rarement parce que personne ne connaît la commande à taper. Elle échoue plus souvent parce qu’une dépendance n’a pas été identifiée, qu’un état initial n’a pas été capturé ou que le critère de rollback est trop vague.
Avant la fenêtre : établir un état de référence
Capturez les adjacences, routes importantes, états d’interface, compteurs d’erreur, latence, pertes et services critiques. Une baseline ne sert pas seulement à prouver que « tout allait bien » : elle permet de comparer objectivement l’après-migration.
Vérifier les dépendances
Identifiez les équipements amont et aval, les circuits, VLAN, VRF, politiques, DNS, services d’authentification, supervision et dépendances applicatives. Pour chaque dépendance, désignez une méthode de validation. « Ping OK » n’est pas toujours suffisant.
Définir la décision de rollback
Écrivez avant l’intervention les seuils qui déclenchent un retour arrière : absence d’un préfixe critique, perte d’un service, dépassement d’un temps maximal, instabilité persistante, défaut de redondance. Cela évite de débattre sous pression.
Préparer la communication
Un changement technique est aussi un changement coordonné. Les personnes qui valident, décident ou exploitent après la fenêtre doivent savoir quand intervenir et quelles informations fournir.
Après la bascule
Rejouez les mêmes contrôles qu’avant la migration. Comparez, ne vous contentez pas d’observer. Vérifiez aussi la supervision, les sauvegardes de configuration et l’état des chemins de secours.
Une checklist utile doit rester courte, vérifiable et liée à une décision. Si une ligne ne peut pas être validée par une preuve observable, reformulez-la.