Guide de mise à jour RouterOS MikroTik

Résumé Mettre à jour RouterOS MikroTik sur un parc ISP est un processus contrôlé, pas une action en un clic. Choisissez un canal de version adapté à vos SLA, sauvegardez chaque appareil, validez sur un pilote, puis déployez par vagues tenant compte de la topologie, avec un chemin de rollback clair. En 2026, cela compte plus que jamais : une faille RouterOS exploitable publiquement (CVE-2026-7668) et une nouvelle version stable (7.23.1) signifient que les routeurs de bordure non patchés constituent un risque actif.

Qu’est-ce que le Patch de RouterOS pour un Parc ISP ?

Le patch de RouterOS est le processus discipliné consistant à faire passer une population d’appareils MikroTik d’une version de RouterOS à une plus récente afin de corriger des failles de sécurité, des bugs de stabilité et des régressions de comportement — sans casser les services qui tournent par-dessus. Sur un seul routeur domestique, c’est une tâche de deux minutes. Sur des centaines ou des milliers de CPE et de routeurs de bordure, cela devient un programme opérationnel : il vous faut une politique de canal de version, un standard de sauvegarde, une étape de staging, un déploiement par vagues et un plan de rollback. L’objectif est simple à énoncer et difficile à tenir à l’échelle — chaque appareil finit patché, et aucun ne tombe hors ligne dans le processus.

Cela mérite un vrai flux de travail car une mise à jour touche la seule chose que vous ne pouvez pas facilement réatteindre en cas d’échec : un routeur à la bordure du client, souvent derrière du CGNAT. Une mauvaise poussée qui perd l’accès de gestion devient une intervention sur site. C’est pourquoi le flux ci-dessous optimise d’abord la sécurité et l’accessibilité, et la vitesse ensuite.

Pourquoi Patcher Maintenant : le Tableau de Sécurité 2026

La cadence de patch reste une tâche de fond silencieuse jusqu’à ce qu’une vulnérabilité force la main, et 2026 donne des raisons concrètes de la resserrer. CVE-2026-7668 est une lecture hors limites dans le point d’accès SCEP de RouterOS, notée CVSS 7.3 (Élevée) ; elle peut être déclenchée à distance et un exploit public existe. Des avis distincts de ce cycle couvrent un problème de contrôle d’accès inapproprié dans la validation de l’IP source VXLAN (corrigé dans RouterOS 7.20 et ultérieur) et une faille de corruption mémoire dans le service SMB qu’un attaquant non authentifié peut déclencher avec des paquets forgés.

La consigne de MikroTik est constante : gardez RouterOS à jour et derrière un pare-feu qui bloque les réseaux non fiables. La branche stable actuelle, RouterOS 7.23.1 (publiée le 2 juin 2026), corrige aussi une fuite mémoire BGP et un problème de stabilité du DHCPv4-snooping. C’est la raison ordinaire pour laquelle les parcs ont besoin d’un processus de patch reproductible plutôt que de mises à jour improvisées.

Étape 1 — Choisir le Bon Canal de Version

RouterOS propose plus d’une branche, et le choix est une décision de politique, pas une préférence. Les versions stable sortent tous les quelques mois avec des fonctionnalités et des correctifs testés ; les versions long-term ne reçoivent que des correctifs critiques et de sécurité, changeant bien moins d’une version à l’autre. Pour les parcs de bordure et de CPE d’ISP qui privilégient la prévisibilité, la branche long-term est souvent le bon choix par défaut, stable étant réservé au matériel ou aux fonctionnalités qui l’exigent. Quel que soit votre choix, n’exécutez jamais de builds testing ou development en production. Documentez la branche par classe d’appareil afin que la décision soit reproductible dans toute l’équipe.

Étape 2 — Sauvegarder et Exporter d’Abord

Ne mettez jamais à jour sans point de récupération. Créez à la fois une sauvegarde binaire (/system backup save) et un export de configuration lisible par l’humain (/export file=), car l’export survit aux changements de version et permet de reconstruire même si une sauvegarde binaire ne se restaure pas sur un autre build. Sortez les deux de l’appareil vers votre système de gestion. Confirmez qu’il y a assez d’espace de stockage libre pour les nouveaux paquets avant de commencer, et privilégiez une connexion filaire ou console — mettre à jour par Wi-Fi ou sur une liaison instable, c’est ainsi que les routeurs se font briquer en pleine écriture. Pour les appareils où l’accès de récupération est la vraie inquiétude, notre guide de récupération Netinstall est le repli quand une mise à jour tourne mal.

Étape 3 — Tester sur un Appareil Pilote

Mettez d’abord à jour un routeur représentatif et observez-le. Choisissez un appareil qui reflète une classe de production — même modèle, même rôle, configuration similaire — et appliquez la version cible pendant une fenêtre de maintenance. Après son redémarrage, vérifiez la version, confirmez que les paquets sont activés et passez en revue le changelog à la recherche de changements de comportement qui touchent votre configuration (sémantique du pare-feu, services par défaut, nommage des interfaces). Ce n’est qu’une fois le pilote propre que vous autorisez le déploiement plus large. Cette seule étape évite le mode de défaillance le plus coûteux : découvrir une régression après qu’elle a déjà été livrée à mille clients.

Étape 4 — Déployer par Vagues Tenant Compte de la Topologie

Le déploiement de masse est une affaire d’ordre et de rythme, pas d’appuyer sur un bouton partout en même temps. Regroupez les appareils par topologie pour que les routeurs chaînés se mettent à jour en séquence — vous ne voulez pas qu’un routeur amont redémarre avant qu’un appareil aval ait récupéré ses paquets. Définissez des vagues avec leurs propres fenêtres de maintenance et suivez chaque appareil dans une liste de réconciliation afin que toute unité posant problème soit remise en file, pas oubliée. Pour réduire la bande passante internet, pointez les appareils vers un routeur central servant de miroir de paquets local ; cela contrôle aussi quelle version le parc peut récupérer.

Un déploiement par vagues ne fonctionne que si vous pouvez réellement atteindre chaque appareil pour confirmer qu’il est revenu. C’est là le piège opérationnel des CPE derrière du CGNAT — et là où la gestion centralisée fait ses preuves.

Étape 5 — Vérifier, Puis Revenir en Arrière si Besoin

Après chaque vague, confirmez le résultat : vérifiez la version remontée, confirmez que le firmware de la routerboard a aussi été mis à jour le cas échéant (/system routerboard upgrade), et validez que les services qui comptent acheminent bien le trafic. Si un appareil dysfonctionne, restaurez la sauvegarde binaire précédente, ou reconstruisez à partir de l’export RSC, ou réinstallez la version précédente avec Netinstall en dernier recours. Un programme de patch n’est pas « terminé » quand la nouvelle version est installée — il l’est quand chaque appareil est vérifié sain et chaque exception suivie jusqu’à sa clôture.

Conseils pour le Patch à l’Échelle d’un Parc

• Standardisez une seule baseline durcie pour que les mises à jour soient prévisibles. Nos bonnes pratiques de sécurité Winbox et le guide des opérations de sécurité device-mode définissent la baseline à laquelle remonte la plupart des problèmes de mise à jour.
• Restreignez l’accès de gestion à un VPN ou à des IP de confiance avant et après les mises à jour, pour qu’un parc à moitié patché ne soit jamais exposé.
• Gardez le plan de gestion atteignable même derrière du CGNAT, afin que la vérification et le rollback ne nécessitent pas de visite sur site.
• Passez en revue les avis de sécurité de MikroTik selon un calendrier plutôt que d’attendre un incident.

FAQ

À quelle fréquence dois-je mettre à jour RouterOS ? Évaluez chaque version au regard de votre politique de branche et patchez hors cycle dès qu’un avis touche des services que vous exposez. Il n’y a pas d’intervalle fixe — seulement une cadence guidée par le risque.

Stable ou long-term pour un parc ISP ? Long-term est le choix par défaut le plus sûr pour la bordure et les CPE ; utilisez stable là où vous avez besoin d’un support matériel ou de fonctionnalités plus récents, après validation en staging.

Et si une mise à jour brique un appareil distant ? Restaurez depuis la sauvegarde ou l’export RSC ; si l’appareil est injoignable, récupérez-le avec Netinstall. C’est pourquoi une sauvegarde testée et un chemin de gestion atteignable sont obligatoires avant toute vague.

Patchez Tout Votre Parc Sans les Interventions sur Site

Le plus difficile dans le patch d’un parc n’est pas la mise à jour — c’est d’atteindre et de vérifier chaque appareil ensuite, surtout les CPE derrière du CGNAT. MKController centralise la visibilité sur tout votre parc MikroTik, et NATCloud vous donne une accessibilité de l’intérieur vers l’extérieur sans redirection de ports, pour que déploiements par vagues, vérification et rollback se fassent tous à distance.

Démarrez votre essai gratuit MKController