Aller au contenu

Blog 29 septembre 2026 3 min de lecture

Scaleway, OVHcloud, OUTSCALE : pourquoi les traiter au même niveau qu’AWS

En bref

Couvrir un cloud, ce n’est pas afficher son logo : c’est lire son inventaire par API, écrire des règles pour ses services, copier ses disques et ses bases, lire ses journaux d’activité, et relier tout cela au reste. Ctadel le fait pour Scaleway, OVHcloud et OUTSCALE comme pour AWS, Azure et Google Cloud, dans un seul graphe.

Les équipes françaises que nous rencontrons ont rarement un seul cloud. Un historique chez OVHcloud, de la production chez Scaleway, un contrat qui impose OUTSCALE pour un périmètre qualifié, et AWS ou Azure pour tout ce qui vient d’un rachat ou d’un partenaire. Leur outil de sécurité, lui, en couvre trois sur six. Les trois autres sont des angles morts.

Ce que « couvrir un cloud » veut dire

Afficher le logo d’un cloud sur une page ne coûte rien. Le couvrir demande cinq briques, et chacune manque souvent.

  1. L’inventaire par API. Instances, volumes, réseaux, groupes de sécurité, identités et politiques, bases gérées, clusters, buckets, clés de chiffrement, fonctions, registres, DNS, équilibreurs. Chaque cloud a ses propres API, sa propre pagination, ses propres façons de décrire une adresse privée ou une politique.
  2. Des règles écrites pour ses services. Une règle AWS sur un bucket S3 ne se transpose pas à un bucket Scaleway par un simple renommage : les options de chiffrement, de versionnage, de journalisation et de politique publique n’ont ni les mêmes noms ni les mêmes valeurs par défaut.
  3. La lecture du contenu. Copier un disque ou une base, c’est demander au cloud un instantané, une restauration, une instance éphémère. Les API, les délais et les limites diffèrent partout.
  4. Les journaux d’activité. Qui a créé quoi, désactivé quel journal, ouvert quel port, depuis quelle adresse. La détection sur journaux suppose de lire le format de chaque cloud.
  5. Le code. Les règles Terraform pour les fournisseurs de chacun, pour attraper le problème avant qu’il ne soit déployé.

Sans ces cinq briques, une ressource de ce cloud n’entre pas dans le graphe, et un chemin d’attaque qui la traverse n’existe pas pour l’outil.

Ce que Ctadel lit sur les clouds français

Sur Scaleway, Ctadel lit par API l’ensemble des produits : instances, volumes, réseaux privés et passerelles, groupes de sécurité, IAM, bases gérées, Kapsule, stockage objet, Key Manager, Serverless, registres, DNS, équilibreurs, Audit Trail. Les disques et les bases PostgreSQL sont copiés et lus dans votre projet.

Sur OVHcloud, le Public Cloud, les serveurs dédiés, le Managed Kubernetes Service, le stockage objet et le KMS, avec une consumer key limitée aux lectures et, si vous le souhaitez, un couple d’identifiants S3 pour lire les buckets.

Sur OUTSCALE, les machines virtuelles, volumes, instantanés, images, réseaux, groupes de sécurité, EIM, OKS, le stockage objet, les VPN et les liaisons directes, avec un utilisateur EIM dédié. Les référentiels affichés incluent SecNumCloud, pour les périmètres qui l’exigent.

Pour chacun des trois, les mêmes scanners qu’ailleurs : configuration, identités, données, secrets, Kubernetes, hôtes, vulnérabilités, journaux, code, et les chemins d’attaque qui relient le tout. Les pages Scaleway, OVHcloud et OUTSCALE détaillent ce qui est lu, ce qui est vérifié et l’accès demandé.

Ce que ça change quand on en a plusieurs

La valeur n’est pas dans la couverture de chaque cloud pris à part. Elle est dans le graphe commun.

  • Une même personne, présente dans AWS, dans Azure et dans l’IAM Scaleway sous trois identités, apparaît comme une seule identité avec ses permissions effectives sur les trois.
  • Un chemin d’attaque peut commencer sur une instance OVHcloud et finir sur un bucket Scaleway, si une clé trouvée sur le premier ouvre le second. Un outil qui couvre les deux séparément ne le verra pas.
  • Un même référentiel (ISO 27001, PCI DSS, RGPD, SecNumCloud) se lit sur l’ensemble du périmètre, pas cloud par cloud, avec des règles différentes mais la même exigence en face.
  • Un même panneau de correction propose la console, la ligne de commande et Terraform pour le cloud concerné, et le ticket part dans le même outil.

Et l’hébergement en France

C’est un bonus, pas l’argument. L’instance Ctadel de chaque client tourne chez un hébergeur français ; les détails et les sous-traitants sont dans le centre de confiance. Mais si vous choisissez Ctadel, que ce soit parce qu’il voit vos six clouds dans un seul graphe, pas parce que son hébergeur est français.

Voyez-le sur vos comptes

La démonstration en ligne est ouverte à tous, sur des données fictives. Pour une instance sur vos propres comptes, demandez une démonstration.