La compatibilité API AWS d’Outscale tient-elle vraiment ?

Pour l’IaaS, oui, dans une large mesure : EC2 et S3 exposent des API compatibles, si bien que le provider Terraform AWS, la CLI et les SDK se repointent sur les endpoints Outscale. Testez toutefois les appels de bordure : toutes les fonctions les plus récentes d’AWS n’ont pas d’équivalent, et la couche managée au-dessus de l’IaaS est propre à Outscale.

Pourquoi choisir Outscale plutôt que Scaleway ou OVHcloud ?

Pour la qualification SecNumCloud 3.2 et l’adossement à Dassault Systèmes. Si votre mandat impose SecNumCloud (OIV, secteur régulé, données sensibles de l’État), Outscale est aligné là où les clouds banalisés ne le sont pas. À défaut de cette contrainte, Scaleway ou OVHcloud offrent un catalogue managé plus large.

Que fait-on de la couche données ?

On la prévoit comme un chantier. Sans RDS ni DynamoDB managés, PostgreSQL, le cache et la messagerie s’auto-hébergent sur les VM ou sur OKS, avec les sauvegardes, la HA et les runbooks associés. Un coût d’exploitation à budgéter, pas une ligne de devis.

AWS → Outscale

Migrer d’AWS vers Outscale

3DS Outscale, filiale de Dassault Systèmes, est le cloud de la souveraineté exigeante : ses API EC2 et S3 sont compatibles AWS, et ses régions françaises sont qualifiées SecNumCloud 3.2 par l’ANSSI. Pour un OIV, un acteur régulé ou une charge sensible, c’est la voie de sortie d’AWS la plus alignée sur les mandats de l’État. La contrepartie : au-delà de l’IaaS compatible AWS et de Kubernetes managé, le catalogue de services managés est resserré. La couche données s’auto-héberge. Cette page dit précisément ce qui se repointe et ce qui se reconstruit.

Quels services AWS ont un véritable équivalent Outscale ?

Noté de façon conservatrice. L’atout d’Outscale est la compatibilité API : vos scripts, votre CLI et votre provider Terraform AWS se repointent sur les endpoints Outscale.

Services AWS et leurs équivalents Outscale, chacun assorti d’un verdict de migration.
AWS	Outscale	Verdict
Amazon EC2	Outscale VM API compatible EC2 : les SDK, la CLI et le provider Terraform AWS se repointent sur les endpoints Outscale plutôt que de tout réécrire.	Équivalent
Amazon EBS	Outscale BSU Volumes bloc avec snapshots, compatibles avec les usages EBS. Équivalent direct.	Équivalent
Amazon S3	Outscale Object Storage (OSU) API compatible S3, réutilisable avec les SDK et outils du marché (s3cmd, MinIO, Cyberduck).	Équivalent
Amazon VPC	Outscale Net Réseau privé virtuel aux concepts compatibles VPC (sous-réseaux, tables de routage).	Équivalent
Elastic Load Balancing	Outscale Load Balancer Unit (LBU) Répartiteur de charge managé compatible avec les usages ELB.	Équivalent
Amazon EKS	OUTSCALE Kubernetes as a Service (OKS) Kubernetes managé, mais plus récent et au catalogue plus resserré qu’EKS.	Partiel
Amazon RDS / Aurora	Pas de jumeau managé (PostgreSQL auto-hébergé) Pas de base relationnelle managée de première partie : provisionnement, sauvegardes et bascule vous incombent.	Pas de jumeau managé
Amazon DynamoDB	Pas de jumeau managé (ScyllaDB auto-hébergé) Pas de NoSQL en colonnes serverless managé.	Pas de jumeau managé
AWS Lambda	Pas de jumeau managé Pas de fonctions serverless de première partie ; le code événementiel tourne sur vos VM ou sur OKS.	Pas de jumeau managé
Amazon Redshift	Pas de jumeau managé (ClickHouse auto-hébergé) Pas d’entrepôt serverless souverain ; ClickHouse relève d’un autre modèle d’exploitation.	Pas de jumeau managé

Où les API divergent-elles réellement ?

La compatibilité AWS d’Outscale couvre l’IaaS de bout en bout ; les écarts se concentrent sur la couche managée au-dessus.

La compatibilité API est l’atout : EC2 et S3 exposent des API compatibles AWS, donc les SDK, la CLI et le provider Terraform AWS se repointent sur les endpoints Outscale plutôt que de tout réécrire.
Au-delà de l’IaaS et d’OKS, le catalogue managé est mince : pas de RDS, DynamoDB ni Lambda de première partie : les couches données et serverless s’auto-hébergent.
La messagerie, le streaming et l’entrepôt n’ont pas de jumeau managé : ce sont autant de stacks à opérer soi-même sur les VM.

Lesquels de vos services migrent proprement ?

Réduit aux briques d’infrastructure qu’Outscale opère en managé et à l’API compatible AWS ; la couche données, vous l’apportez.

Filtrer les capacités

3 capacités

Stockage objet

Hyperscaler Amazon S3 Azure Blob Storage Google Cloud Storage

Voie souveraine européenne Scaleway Object StorageOVHcloud Object Storage

Verdict Mature

API compatible S3. Cible directe pour la plupart des SDK, sauvegardes et assets statiques.
Stockage bloc

Hyperscaler Amazon EBS Azure Managed Disks Persistent Disk / Hyperdisk

Voie souveraine européenne Scaleway Block StorageOVHcloud Block Storage

Verdict Mature

Volumes bloc réseau avec snapshots. Brique standard, bien couverte.
Machines virtuelles

Hyperscaler Amazon EC2 Azure Virtual Machines Google Compute Engine

Voie souveraine européenne Scaleway InstancesOVHcloud Public CloudHetzner Cloud

Verdict Mature

Les instances généralistes et dédiées sont un problème résolu en Europe.

Les verdicts sont prudents et reflètent les offres managées de juridiction européenne à jour en 2026. Les catalogues évoluent vite, nous les revérifions donc à chaque mission.

Combien de jours-ingénieur cela représente-t-il ?

30 à 80 jours-ingénieur

Le socle IaaS compatible AWS se déplace vite ; l’amplitude vient de la couche données à auto-héberger et des exigences de qualification SecNumCloud.

Un parc de taille moyenne : ~20 à 40 VM, du stockage objet, un réseau VPC et éventuellement un cluster OKS.
Le bas de la fourchette suppose un socle IaaS compatible AWS que le provider Terraform repointe presque tel quel.
Le haut suppose d’auto-héberger PostgreSQL, une file de messages et l’observabilité, plus la mise en conformité SecNumCloud.
Hors réécritures applicatives, egress depuis AWS et montée en compétence des équipes.

Où Outscale opère-t-il réellement ?

Des régions françaises qualifiées SecNumCloud 3.2 par l’ANSSI, plus des régions publiques standard. Épinglez les charges sensibles sur les régions qualifiées.

cloudgouv-eu-west-1 (France)Région qualifiée SecNumCloud 3.2 (ANSSI), pour les données sensibles et les OIV.
Seconde région SecNumCloud (France)Ouverte pour la résilience et la réversibilité des charges qualifiées.
eu-west-2 (Paris)Région publique standard pour les charges non soumises à SecNumCloud.

Quelles sont les limites, dites honnêtement ?

Un catalogue managé resserré Hors IaaS compatible AWS et OKS, pas de PostgreSQL, DynamoDB ni Lambda managés de première partie : le stateful et le serverless s’auto-hébergent, ce qui déplace l’effort vers l’exploitation.
Le prix de la souveraineté SecNumCloud La qualification a un coût : moins de régions, un TJM d’exploitation et des tarifs unitaires supérieurs aux clouds banalisés, et un écosystème plus petit que les hyperscalers.

Qu’un DSI demande-t-il d’autre avant de s’engager ?

La compatibilité API AWS d’Outscale tient-elle vraiment ?: Pour l’IaaS, oui, dans une large mesure : EC2 et S3 exposent des API compatibles, si bien que le provider Terraform AWS, la CLI et les SDK se repointent sur les endpoints Outscale. Testez toutefois les appels de bordure : toutes les fonctions les plus récentes d’AWS n’ont pas d’équivalent, et la couche managée au-dessus de l’IaaS est propre à Outscale.
Pourquoi choisir Outscale plutôt que Scaleway ou OVHcloud ?: Pour la qualification SecNumCloud 3.2 et l’adossement à Dassault Systèmes. Si votre mandat impose SecNumCloud (OIV, secteur régulé, données sensibles de l’État), Outscale est aligné là où les clouds banalisés ne le sont pas. À défaut de cette contrainte, Scaleway ou OVHcloud offrent un catalogue managé plus large.
Que fait-on de la couche données ?: On la prévoit comme un chantier. Sans RDS ni DynamoDB managés, PostgreSQL, le cache et la messagerie s’auto-hébergent sur les VM ou sur OKS, avec les sauvegardes, la HA et les runbooks associés. Un coût d’exploitation à budgéter, pas une ligne de devis.