Lorsque le cloud passe du côté obscur : Pourquoi est-il essentiel de posséder votre infrastructure pour vos services critiques ? 

Le 12 juin 2025, une panne mondiale sur Google Cloud Platform (GCP) a paralysé des infrastructures critiques. Les effets boule de neige ont été immédiats. Les services de Palo Alto Networks et de Cloudflare (qui dépendent tous deux de GCP) ont connu des pannes qui ont duré plusieurs heures. Les entreprises dépendant de ces services n’ont pas été informées et aucune solution alternative ne leur a été proposée. 
 
Ce n’est pas la première fois que ça arrive. Et ce ne sera pas la dernière. Mais ce fut un signal d’alarme. 
 
Lorsque SASE, SSE ou SD-WAN tombent en panne, l’entreprise est à l’arrêt. La productivité stagne. Des failles de sécurité sont exposées. Les risques se multiplient. Pour des services aussi critiques, une haute disponibilité n’est pas un luxe. C’est un impératif. Et cela commence par la propriété de l’architecture : construire sur une infrastructure que vous contrôlez. 

L’illusion de la redondance dans le cloud 

Les hyperscalers comme GCP, AWS et Azure offrent une mise à l’échelle impressionnante et une portée mondiale. Mais ils n’ont pas été conçus pour des services de mise en réseau et de sécurité qui doivent offrir des performances en temps réel et une disponibilité de 99,999 %. Ce sont des clouds destinés à un usage général, conçus pour exécuter des applications, et non pour transporter l’infrastructure critique réseau et sécurité des entreprises. 
 
Les fournisseurs qui construisent leurs services sur des hyperscalers héritent de cette fragilité. Lorsque GCP trébuche, tout ce qui en dépend trébuche en même temps. La redondance au sein d’un seul fournisseur de cloud ne vous sauvera pas d’une défaillance systémique comme celle du 12 juin. Et la résilience inter-cloud ? Cela ne fonctionne que si elle a été conçue et testé dès le départ, et non pas corrigée après coup. 

Les infrastructures critiques exigent un type de cloud différent 

La plateforme Cato SASE Cloud est différente par conception. Nous avons construit notre propre backbone mondial, avec plus de 85 PoP fonctionnant sur une infrastructure bare-metal détenue par Cato dans des centres de données de premier niveau. Nous ne louons pas la résilience : nous la créons. Chaque PoP fonctionne avec une pile entièrement redondante. Notre moteur cloud Single Pass (SPACE) inspecte et applique la politique sur tout le trafic. Lorsqu’un SPACE, un nœud de calcul ou un PoP échoue, le trafic est automatiquement déplacé, sans aucune intervention nécessaire, et sans aucune interruption de service. 
 
Ce n’est pas de la théorie. Nous avons eu l’occasion de le tester à de nombreuses reprises : 
– Lorsque une coupure de fibre a perturbé un grand opérateur, les utilisateurs de Cato ne l’ont pas remarqué, car notre backbone a redirigé le trafic instantanément. 
– Lorsqu’un centre de données au Royaume-Uni est tombé en panne, Cato l’a contourné sans aucun temps d’arrêt. 
– Lorsque des pannes de courant ont frappé l’Espagne et le Portugal, les clients de Cato sont restés connectés et protégés. 
 
Cela n’a rien à voir avec de la chance. Ce sont les résultats d’une conception délibérément résiliente. 

Ce n’est pas seulement une question de posséder l’infrastructure, c’est une question d’architecture 

On n’atteint pas la résilience en ajoutant des appareils. Il s’agit d’éliminer les points de défaillance uniques grâce au calcul, à la connectivité, à l’inspection et au contrôle. 
 
Grâce à son architecture, Cato distribue les tâches d’inspection à travers des milliers de SPACE fonctionnant en parallèle. Chacun d’entre eux peut traiter le trafic chiffré à la vitesse de transfert, avec une application complète de la pile de sécurité. Si l’un d’eux échoue, le trafic passe par un autre SPACE. Si un PoP échoue, les tunnels redirigent automatiquement le trafic vers le PoP sain le plus proche. Aucune reconfiguration ni script de basculement n’est nécessaire, et pas besoin non plus d’attendre la propagation à travers les DNS. 
 
Comparez cela aux architectures basées sur des appareils ou hébergées dans le cloud, où les pare-feu, les bords SD-WAN ou les points d’inspection sont liés à une instance spécifique. Un basculement nécessite de la planification, des tests et une intervention manuelle. Tout cela, souvent en période de crise. 

Le temps de disponibilité du service commence par la propriété du forfait de données 

Lors de la livraison d’infrastructures critiques comme SASE, la disponibilité et la résilience doivent être intégrées dans le plan de données lui-même. Cela signifie qu’il faut viser bien au-delà des indicateurs de disponibilité classiques. Cela nécessite de fournir un véritable SLA de disponibilité de 99,999 % au niveau du plan de données, où les sessions utilisateur sont inspectées, sécurisées et routées. Si ce niveau tombe, l’entreprise est soit hors ligne, soit dangereusement exposée. 

Pour respecter ce SLA, chaque composant participant au plan de données doit être conçu pour assurer la récupération automatique. Toute dépendance (qu’il s’agisse d’appareils physiques, de services tiers ou de fournisseurs de cloud) qui manque de redondance et de mécanismes de basculement rapides devient un point de défaillance unique. 

En pratique, cela signifie une chose : vous devez posséder l’infrastructure. Ce n’est qu’à cette condition que vous pourrez concevoir, contrôler et améliorer continuellement sa résilience. Lorsque vous devez absolument utiliser des services tiers, ceux-ci doivent être conçus comme des composants sans état, facilement remplaçables et surveillés. S’ils devaient faillir, cela ne devrait pas avoir aucun impact. La récupération doit être automatique, pas réactive. 

Si vous ne contrôlez pas l’infrastructure, vous devez au moins contrôler la manière dont elle échoue, et à quelle vitesse elle sera rétablie. 

Ce que les entreprises doivent exiger de leur fournisseur SASE

Si votre fournisseur SASE ne peut pas survivre à une panne de fournisseur cloud, cela signifie qu’il n’a pas construit un cloud SASE. Il en a probablement loué un. Et ce n’est pas suffisant. 
 
Demandez ceci à votre fournisseur : 
– Où est hébergé votre plan de contrôle, et que se passe-t-il s’il est hors service ? 
– Que se passe-t-il si un PoP échoue en cours de session ? 
– Quelle est la rapidité du basculement entre les fournisseurs ou les régions ? 
– Vos moteurs d’inspection sont-ils multi-locataires, auto-réparateurs et équilibrés en charge ? 
 
Et surtout : L’avez-vous prouvé ? 
 
Chez Cato, nous l’avons fait. Pas une seule fois, plusieurs fois.