La résilience du réseau ne se limite pas à la redondance DNS et à l'utilisation de plusieurs régions et fournisseurs. Elle nécessite également d'étendre la résilience à la configuration du réseau. C'est le défi que relève actuellement ControlMonkey, une start-up spécialisée dans l'automatisation des infrastructures cloud. En 2025, cette jeune pousse avait déjà lancé sa fonctionnalité de reprise de la configuration après sinistre cloud, ciblant les infrastructures AWS, Azure et GCP. Aujourd'hui, l'entreprise étend sa plateforme de reprise de la configuration après sinistre au plan de contrôle réseau, en particulier aux configurations CDN, aux règles de pare-feu, aux enregistrements DNS, aux tables de routage et aux politiques de routage périphérique qui se trouvent en dehors des principaux fournisseurs de cloud, mais qui sont essentielles au temps de fonctionnement de la production. Ce support apporte des capacités de sauvegarde de la configuration pour Cloudflare, Akamai, Fastly et F5. L'objectif est de combler ce qui semble être une lacune dans la résilience et la reprise après sinistre de nombreuses entreprises. « Tout le monde sauvegarde ses données, n'est-ce pas ? Il faudrait être fou pour ne pas le faire », a déclaré Aharon Twizer, CEO et cofondateur de ControlMonkey. « Mais qu'en est-il de la configuration réseau ? Si le réseau est en panne, certes, les données seront là, mais il n’y aura aucun trafic. »

Combler le fossé de la configuration réseau

Cette expansion est le résultat des demandes des clients qui souhaitaient une couverture allant au-delà d'AWS, d'Azure et de Google Cloud Platform. D’après ses propres conversations avec ses clients, M. Twizer rapporte que pour les fournisseurs de réseaux tiers, le fossé est plus important que pour les infrastructures cloud. « Concernant les tiers, environ 90 % des personnes avec lesquelles j’ai échangé ne gèrent pas leur Cloudflare avec Terraform, ne gèrent pas leur Akamai avec Terraform, ne gèrent pas leur F5 avec Terraform », a fait remarquer M. Twizer. « Elles n'ont donc aucune couverture. » ControlMonkey utilise la technologie Terraform Infrastructure-as-Code (IaC) pour définir l'environnement. La plateforme se connecte à chaque fournisseur pris en charge et procède à une ingénierie inverse des configurations en direct dans le code Terraform HCL. Elle crée ensuite quotidiennement des instantanés versionnés.

Le flux de travail comporte trois phases. Tout d'abord, la plateforme effectue un inventaire complet des actifs après s'être connectée à un fournisseur. Ensuite, elle identifie les ressources qui ne sont pas couvertes par le code et les signale à l'opérateur. Enfin, elle active les instantanés de configuration quotidiens afin que les équipes disposent d'un état connu et fiable à partir duquel elles peuvent effectuer une restauration. « La meilleure façon de sauvegarder sa configuration est d'utiliser l'infrastructure en tant que code », a expliqué le CEO. « Nous utilisons spécifiquement Terraform pour cela, et notre technologie de base, notre sauce secret, consiste à prendre les fournisseurs ou les vendeurs d'infrastructure et à procéder à une ingénierie inverse de la configuration existante, la configuration en direct, pour la coder. » La récupération s'effectue en un seul clic. Lorsqu'un incident se produit, la plateforme utilise l'automatisation de Terraform pour provisionner la dernière configuration connue comme étant valide dans un deuxième tenant. Les clients peuvent également utiliser les API ControlMonkey pour créer des playbooks de récupération automatisés déclenchés à partir d'outils d'alerte externes comme PagerDuty ou Datadog.

Récupération de la configuration, pas de la disponibilité du fournisseur

Pour être clair, la solution ControlMonkey ne résoudra pas le problème de pannes des fournisseurs. La plateforme traite de la récupération de la configuration, pas de la surveillance de la disponibilité des fournisseurs. Le principal scénario auquel répond ControlMonkey est celui d’une attaque par ransomware qui supprime ou corrompt les configurations réseau plutôt que les données. Dans cette situation, les charges de travail et les données peuvent être intactes, mais le plan de contrôle du réseau a disparu et les applications deviennent inaccessibles. En cas de panne générale du fournisseur, « nous ne pouvons vraiment rien y faire », a insisté M. Twizer. « Nous nous intéressons davantage aux ransomwares, aux cyberattaques, aux agents IA qui commettent des erreurs et aux erreurs honnêtes des employés. » La plateforme ne fournit pas non plus de recommandations de basculement multi-fournisseurs. Elle indique la posture de récupération pour les configurations des fournisseurs existants, et non des conseils de routage vers d'autres fournisseurs.

Tous les services tiers de production visés à terme

L'expansion ne se limitera pas aux équipementiers. Selon M. Twizer, les demandes des clients poussent à étendre la couverture à d'autres catégories de fournisseurs au-delà du cloud et des réseaux, la plateforme visant à terme tous les services tiers sur lesquels les entreprises s'appuient pour leurs opérations de production. La conformité est également un facteur important. Les normes SOC 2 et ISO 27001 traitent toutes deux de la reprise après sinistre et de la planification de la continuité des activités, et ControlMonkey positionne la récupération de la configuration comme faisant partie de ce cycle, au même titre que la protection des données. M. Twizer précise que la réflexion derrière cette expansion résulte d’une lacune évidente dans la façon dont la plupart des entreprises définissent aujourd'hui la résilience. « En 2026, la cyber-résilience concerne les données, l'infrastructure et le plan de contrôle du réseau », a insisté M. Twizer. « Si elle ne dispose pas des trois, une entreprise n’est pas fondamentalement résiliente. »