Alternative UE-uniquement à DigitalOcean.

DigitalOcean est le cloud américain orienté développeurs - tarification compétitive, UX soignée, et une région Amsterdam qui pousse de nombreuses équipes UE à croire que la question de la résidence des données est réglée. Ce n'est pas le cas : DigitalOcean LLC est une société du Delaware, son datacenter d'Amsterdam est exploité sous contrôle d'entreprise américain, et le CLOUD Act s'applique. La bonne nouvelle, c'est que la migration de DigitalOcean vers une infrastructure de juridiction UE que nous menons pour vous est l'une des plus propres de ce guide - la surface d'API de DigitalOcean est réduite, et la plupart des workloads migrés hors de cette plateforme rapportent des factures plus basses et des performances égales ou meilleures.

États-Unis Stack de remplacement, UE uniquement 12 services cartographiés

Planifier un appel Scannez d'abord votre domaine

Fournisseur: DigitalOcean
Siège: New York, NY
Juridiction: États-Unis
Régime juridique: CLOUD Act, FISA 702

Une "région UE" n'est pas la souveraineté. Quatre questions tranchent.

La résidence des données indique où se trouvent les bits. La souveraineté indique quel système juridique peut en imposer l'accès. La réponse doit tenir sur les quatre points, sinon la stack n'est pas souveraine.

Résidence

Où les données sont-elles physiquement stockées ?

Pas "dans le cloud" : quel centre de données, dans quel pays, sous quelle juridiction.

Sous-traitants

Qui d'autre est dans votre chemin de données ?

Chaque fournisseur qui touche les données : le CDN, le relais e-mail, le tracker d'erreurs, le pipeline analytics.

Juridiction

Quelles lois peuvent contraindre à la divulgation ?

Un fournisseur dont le siège est aux États-Unis relève de la FISA 702 et du CLOUD Act, même si les données se trouvent à Francfort.

Garde des clés

Qui détient réellement les clés de chiffrement ?

Si le fournisseur cloud détient à la fois les données et les clés, il peut les lire, quel que soit le DPA.

Échoue AWS · Azure · GCP · Région UE

Échoue sur la juridiction et la garde des clés.

Bits en UE, maison mère américaine, sous-traitants américains dans le chemin par défaut, clés gérées par le fournisseur.

Réussit Stack géré par Binadit

Réussit sur les quatre.

Hébergé en UE sur une infrastructure au siège européen. Zéro sous-traitant américain dans le chemin par défaut. Clés détenues par le client ou par un KMS européen. Nommés dans votre DPA Article 28.

Pourquoi les équipes partent DigitalOcean

Les sorties de DigitalOcean que nous avons menées viennent presque toujours d'un seul déclencheur : un audit client (B2B SaaS) ou une revue de conformité où "DigitalOcean Amsterdam" a été jugé insuffisant au regard de Schrems II, obligeant le client soit à ajouter des mesures supplémentaires coûteuses (chiffrement BYOK qui annule l'intérêt du service managé), soit à migrer. Migrer est généralement l'option la moins coûteuse. Le travail technique est léger car l'offre de DigitalOcean est volontairement minimale, ce qui rend le mapping EU simple.

DigitalOcean services et leurs équivalents UE-uniquement

Une migration n'est pas "échanger une boîte contre une autre". La cartographie ci-dessous est ce que nous exécutons pour les clients qui quittent DigitalOcean au titre de Schrems II : juridiction UE complète, aucune maison mère américaine dans le chemin des données.

DigitalOcean service	Ce que nous utilisons à la place	Note d'ingénierie
Droplets	Binadit Managed Cloud Platform. Machines virtuelles KVM sur Debian ou Ubuntu, provisionnées avec Terraform et configurées avec Ansible.	Nous dimensionnons les instances selon votre profil de charge réel plutôt que selon un tier de catalogue, si bien que la plupart des migrations aboutissent à moins de machines, mais mieux utilisées.
Spaces (object storage)	Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatible S3.	Compatible S3 sur toutes les options ; la migration se résume à un changement d'endpoint dans la configuration du SDK.
Managed Databases (PostgreSQL, MySQL, Redis)	Binadit Managed Cloud Platform. PostgreSQL ou MySQL avec Patroni pour le failover et pgBackRest pour la restauration point-in-time.	La réplication en streaming permet de basculer avec quelques secondes d'interruption plutôt qu'une fenêtre de maintenance, et les restaurations sont testées régulièrement plutôt que présumées fonctionnelles.
App Platform (PaaS)	Binadit Managed Cloud Platform. Images Docker construites dans GitLab CI et déployées sur Kubernetes, avec environnements de review par branche.	App Platform n'a pas d'équivalent souverain direct au niveau PaaS. Coolify (open-source, self-hosted) offre une expérience utilisateur proche de Heroku sur une infrastructure européenne.
Kubernetes (DOKS)	Binadit Managed Cloud Platform. Kubernetes sur Debian ou Talos, avec réseau Cilium et cert-manager pour les certificats.	Vos manifests et charts Helm sont repris tels quels. Ce qui change, c'est l'ingress class et la storage class, et nous gérons les deux.
Load Balancers	Binadit Managed Cloud Platform. HAProxy ou Nginx, avec keepalived pour le failover.	Pour la plupart des cas d'usage, le LB managé chez les fournisseurs européens suffit ; pour des règles avancées, HAProxy sur une petite VM est le schéma standard.
Volumes (block storage)	Binadit Managed Cloud Platform. Ceph RBD, ou Longhorn pour des volumes Kubernetes-native.	Stockage bloc NVMe standard sur toutes les options européennes ; performances comparables ou supérieures.
DNS (DigitalOcean DNS)	Binadit Managed Cloud Platform. PowerDNS ou Knot, en autorité, signés DNSSEC.	La migration consiste en un export et une réimportation de zone ; quelques minutes de travail.
Floating IPs	Binadit Managed Cloud Platform. Allocation d'IP statique avec keepalived pour le failover entre les nodes.	Tous les fournisseurs proposent un équivalent du pattern failover-IP.
CDN (DigitalOcean CDN)	Nous mettons en place et exploitons un CDN européen pour vous : Bunny.net ou KeyCDN, avec du caching Nginx et Varnish à votre origine.	Un CDN est l'une des rares couches que nous n'exploitons pas nous-mêmes. Nous choisissons le fournisseur européen, configurons les en-têtes de cache, la stratégie de purge et l'origin shielding, et l'exploitons dans le cadre du service managé.
Monitoring (DO Monitoring)	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki et Tempo, connectés avec OpenTelemetry.	OpenTelemetry rend l'instrumentation portable, et il n'y a pas de pricing par métrique ou par trace à contourner, donc les équipes arrêtent d'échantillonner à l'excès les données dont elles ont besoin.
Container Registry	Binadit DevOps & Support. Harbor ou le registre de conteneurs GitLab, avec scan de vulnérabilités à chaque push.	Harbor est le registry open-source de niveau production ; nous l'opérons pour nos clients.

Droplets

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Machines virtuelles KVM sur Debian ou Ubuntu, provisionnées avec Terraform et configurées avec Ansible.
Note d'ingénierie: Nous dimensionnons les instances selon votre profil de charge réel plutôt que selon un tier de catalogue, si bien que la plupart des migrations aboutissent à moins de machines, mais mieux utilisées.

Spaces (object storage)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatible S3.
Note d'ingénierie: Compatible S3 sur toutes les options ; la migration se résume à un changement d'endpoint dans la configuration du SDK.

Managed Databases (PostgreSQL, MySQL, Redis)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. PostgreSQL ou MySQL avec Patroni pour le failover et pgBackRest pour la restauration point-in-time.
Note d'ingénierie: La réplication en streaming permet de basculer avec quelques secondes d'interruption plutôt qu'une fenêtre de maintenance, et les restaurations sont testées régulièrement plutôt que présumées fonctionnelles.

App Platform (PaaS)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Images Docker construites dans GitLab CI et déployées sur Kubernetes, avec environnements de review par branche.
Note d'ingénierie: App Platform n'a pas d'équivalent souverain direct au niveau PaaS. Coolify (open-source, self-hosted) offre une expérience utilisateur proche de Heroku sur une infrastructure européenne.

Kubernetes (DOKS)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Kubernetes sur Debian ou Talos, avec réseau Cilium et cert-manager pour les certificats.
Note d'ingénierie: Vos manifests et charts Helm sont repris tels quels. Ce qui change, c'est l'ingress class et la storage class, et nous gérons les deux.

Load Balancers

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. HAProxy ou Nginx, avec keepalived pour le failover.
Note d'ingénierie: Pour la plupart des cas d'usage, le LB managé chez les fournisseurs européens suffit ; pour des règles avancées, HAProxy sur une petite VM est le schéma standard.

Volumes (block storage)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Ceph RBD, ou Longhorn pour des volumes Kubernetes-native.
Note d'ingénierie: Stockage bloc NVMe standard sur toutes les options européennes ; performances comparables ou supérieures.

DNS (DigitalOcean DNS)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. PowerDNS ou Knot, en autorité, signés DNSSEC.
Note d'ingénierie: La migration consiste en un export et une réimportation de zone ; quelques minutes de travail.

Floating IPs

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Allocation d'IP statique avec keepalived pour le failover entre les nodes.
Note d'ingénierie: Tous les fournisseurs proposent un équivalent du pattern failover-IP.

CDN (DigitalOcean CDN)

Ce que nous utilisons à la place: Nous mettons en place et exploitons un CDN européen pour vous : Bunny.net ou KeyCDN, avec du caching Nginx et Varnish à votre origine.
Note d'ingénierie: Un CDN est l'une des rares couches que nous n'exploitons pas nous-mêmes. Nous choisissons le fournisseur européen, configurons les en-têtes de cache, la stratégie de purge et l'origin shielding, et l'exploitons dans le cadre du service managé.

Monitoring (DO Monitoring)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Prometheus, Grafana, Loki et Tempo, connectés avec OpenTelemetry.
Note d'ingénierie: OpenTelemetry rend l'instrumentation portable, et il n'y a pas de pricing par métrique ou par trace à contourner, donc les équipes arrêtent d'échantillonner à l'excès les données dont elles ont besoin.

Container Registry

Ce que nous utilisons à la place: Binadit DevOps & Support. Harbor ou le registre de conteneurs GitLab, avec scan de vulnérabilités à chaque push.
Note d'ingénierie: Harbor est le registry open-source de niveau production ; nous l'opérons pour nos clients.

Comment nous migrons depuis DigitalOcean

Une migration typique de mid-market se déroule en trois phases. Les chiffres ci-dessous supposent une équipe d'ingénierie de 6 à 10 personnes et une stack applicative modérément complexe.

Jours 1-3

Inventaire & dépendances

Lister chaque Droplet, Database, Space et déploiement App Platform. Identifier toute API spécifique à DigitalOcean ou automatisation doctl nécessitant une réécriture. Résultat : plan de migration clair, sans surprises.
Jours 4-10

D'abord les dépendances légères

DNS, Spaces et CDN déplacés en premier. Répliques de base de données pré-provisionnées sur un service managé EU. Registre de conteneurs déplacé vers Harbor. Monitoring sur Prometheus EU.
Semaines 2-5

Bascule Compute & DB

Droplets reprovisionnés sur infrastructure compute Binadit avec les mêmes images. Bascule de base de données avec réplication logique. Workloads App Platform migrés vers Kubernetes sur Binadit. Bascule du Load Balancer avec changement DNS.

TCO sur 5 ans d'une sortie DigitalOcean : généralement 40-60% moins cher, les économies les plus importantes portant sur le compute, où des spécifications équivalentes coûtent généralement environ moitié prix, et sur les bases de données managées. Là où DigitalOcean a un avantage, c'est l'expérience utilisateur d'App Platform, que la stack souveraine européenne remplace par Coolify ou un PaaS auto-géré.

Questions fréquemment posées

Voir toutes les questions fréquemment posées

DigitalOcean a des datacenters à Amsterdam et Francfort - est-ce que cela suffit pour le RGPD ?

Résidence oui, souveraineté non. Le datacenter d'Amsterdam est détenu et exploité par DigitalOcean LLC, une entité sous contrôle américain. Le CLOUD Act permet aux autorités américaines d'exiger la divulgation de données n'importe où dans le monde. Pour les workloads sensibles au Schrems II, cette exposition n'est pas résolue par la localisation du datacenter.

La fiabilité va-t-elle en souffrir si nous quittons DigitalOcean ?

Pas dans notre expérience, mais la réponse honnête est que la fiabilité vient de l'architecture plus que d'un logo. Une instance unique sans failover est fragile partout. Ce que nous construisons à la place, c'est de la redondance aux couches qui comptent : bases de données répliquées avec failover testé, load balancing entre les nœuds, et un monitoring qui nous alerte avant qu'il n'alerte vos clients. C'est cette partie du déménagement qui change votre uptime, pas le choix du datacentre.

Qu'en est-il du remplacement d'App Platform spécifiquement ?

App Platform est réellement utile pour les petites équipes qui ne veulent pas gérer d'infrastructure. Coolify, auto-hébergé et open source, offre une expérience App Platform comparable sur du calcul européen. Pour les équipes qui souhaitent une solution managée, nous gérons la plateforme de conteneurs pour vous.

Pouvons-nous migrer progressivement ou est-ce que cela doit se faire d'un seul coup ?

La transition progressive est la norme. Faire fonctionner les deux fournisseurs en parallèle via une répartition du trafic au niveau DNS, migrer charge de travail par charge de travail, décommissionner DigitalOcean une fois le dernier service déplacé. Délai type : 4 à 8 semaines pour les charges de travail du marché intermédiaire, 2 à 4 semaines pour les petites.

Combien de temps dure une sortie de DigitalOcean ?

Pour une charge de travail typique (5 à 20 Droplets, 1 à 2 bases de données managées, Spaces, DNS) : 3 à 6 semaines. Avec un partenaire d'infrastructure managée aux commandes : 2 à 4 semaines. Le travail technique est léger ; le calendrier est déterminé par les points de validation et la disponibilité de l'équipe.

La migration va-t-elle créer une interruption de service ?

Non, lorsque c'est fait correctement. La migration de base de données utilise la réplication logique de sorte que la bascule se résume à un simple changement de DNS ou de chaîne de connexion. La migration du compute utilise le blue-green au niveau du load balancer ou du DNS. Le stockage d'objets utilise la double écriture pendant la fenêtre de migration. Le zéro downtime est l'attente standard.

Planifiez votre sortie de DigitalOcean.

Appel de cadrage de 30 minutes. Nous cartographions votre stack par rapport aux alternatives UE-uniquement, estimons l'effort de migration et vous disons si c'est le bon choix.

Planifier un appel Comparer un autre fournisseur