Alternative UE-uniquement à Heroku (Salesforce).

Heroku est le PaaS pionnier orienté développeur, racheté par Salesforce en 2010 et désormais partie de Salesforce.com Inc. Salesforce est une entreprise américaine, la région par défaut de Heroku est aux États-Unis, et le « Common Runtime » européen se trouve sur AWS Irlande - ce qui signifie que votre application Heroku est sur une infrastructure AWS avec Salesforce comme sous-traitant contractuel. Les deux couches sont sous juridiction américaine. L'alternative souveraine est simple : un PaaS auto-hébergé comme Coolify ou Dokku sur une infrastructure européenne, ou un équivalent entièrement managé opéré par un partenaire européen.

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

Planifier un appel Scannez d'abord votre domaine

Fournisseur: Heroku (Salesforce)
Siège: San Francisco, CA (Salesforce)
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 Heroku (Salesforce)

Les sorties de Heroku que nous avons menées proviennent de trois déclencheurs : un audit client (SaaS B2B) signalant que le chemin de données AWS-Irlande via Heroku est exposé au regard de Schrems II, l'arrêt des dynos gratuits en 2022 forçant une réévaluation des coûts, ou une décision stratégique de supprimer la double chaîne de fournisseurs (Salesforce → AWS) qui complique la gestion des DPA. La valeur de Heroku réside dans l'expérience développeur ; des alternatives open source comme Coolify, Dokku et Caprover reproduisent la majeure partie de cette expérience sur une infrastructure européenne.

Heroku (Salesforce) 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 Heroku (Salesforce) au titre de Schrems II : juridiction UE complète, aucune maison mère américaine dans le chemin des données.

Heroku (Salesforce) service	Ce que nous utilisons à la place	Note d'ingénierie
Dynos (web/worker)	Binadit Managed Cloud Platform. Images Docker construites dans GitLab CI et déployées sur Kubernetes, avec environnements de review par branche.	Coolify offre une DX quasi identique à Heroku (déploiements par git push, apps en un clic) sur une infrastructure UE. Facturation généralement 60 à 80 % inférieure à Heroku pour une puissance de calcul équivalente.
Heroku Postgres	Binadit Managed Cloud Platform. PostgreSQL ou MySQL avec Patroni pour le failover et pgBackRest pour la restauration point-in-time.	La réplication logique permet une bascule sans interruption. Les sauvegardes Heroku Postgres peuvent être téléchargées au format pg_dump standard et restaurées n'importe où.
Heroku Redis	Binadit Managed Cloud Platform. Redis ou Valkey, avec Sentinel pour le failover.	API Redis standard ; migration via SLAVEOF ou transfert RDB.
Heroku Connect (Salesforce sync)	Binadit DevOps & Support. Des workers d'intégration exécutés sur votre propre infrastructure, communiquant directement avec l'API du fournisseur.	Pour les équipes qui conservent Salesforce CRM, la couche de synchronisation est reconstruite ; pour celles qui remplacent Salesforce, cette préoccupation disparaît.
Add-ons marketplace	Binadit DevOps & Support. Les composants que vous utilisez réellement, déployés et exploités dans le cadre de votre stack.	La commodité des add-ons de Heroku est la plus grande perte en termes de DX ; la gestion directe des fournisseurs est le compromis à faire pour la souveraineté.
Pipelines (review apps, CI/CD)	Binadit DevOps & Support. Des environnements de review par branche sur Kubernetes, créés et détruits par GitLab CI.	Coolify prend en charge les environnements de prévisualisation par branche.
Heroku Buildpacks	Binadit DevOps & Support. Dockerfiles ou Cloud Native Buildpacks, construits dans GitLab CI.	La plupart des applications Heroku se déploient sans modification via Cloud Native Buildpacks sur Coolify.
Logplex / Logging	Binadit Managed Cloud Platform. Loki pour l'agrégation, avec Grafana pour les requêtes et des politiques de rétention par stream.	Loki est le pattern standard ; il agrège les logs de tous les containers.
Heroku CI	Binadit DevOps & Support. GitLab CI avec des runners sur votre propre infrastructure.	GitLab CI sur un runner auto-hébergé dans l'UE est le remplacement de niveau production.
Heroku Private Spaces	Binadit Private Infrastructure. Environnement entièrement isolé, matériel dédié, architecture réseau sur mesure.	Le concept de « Private Spaces » n'est rien d'autre qu'un VPC ; le réseau EU standard le gère nativement.
SSL / domains	Binadit Managed Cloud Platform. cert-manager avec Let's Encrypt, avec renouvellement automatique.	Le transfert de domaine est un changement de registrar ; le SSL est automatisé par toutes les alternatives PaaS modernes.

Dynos (web/worker)

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: Coolify offre une DX quasi identique à Heroku (déploiements par git push, apps en un clic) sur une infrastructure UE. Facturation généralement 60 à 80 % inférieure à Heroku pour une puissance de calcul équivalente.

Heroku Postgres

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 logique permet une bascule sans interruption. Les sauvegardes Heroku Postgres peuvent être téléchargées au format pg_dump standard et restaurées n'importe où.

Heroku Redis

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Redis ou Valkey, avec Sentinel pour le failover.
Note d'ingénierie: API Redis standard ; migration via SLAVEOF ou transfert RDB.

Heroku Connect (Salesforce sync)

Ce que nous utilisons à la place: Binadit DevOps & Support. Des workers d'intégration exécutés sur votre propre infrastructure, communiquant directement avec l'API du fournisseur.
Note d'ingénierie: Pour les équipes qui conservent Salesforce CRM, la couche de synchronisation est reconstruite ; pour celles qui remplacent Salesforce, cette préoccupation disparaît.

Add-ons marketplace

Ce que nous utilisons à la place: Binadit DevOps & Support. Les composants que vous utilisez réellement, déployés et exploités dans le cadre de votre stack.
Note d'ingénierie: La commodité des add-ons de Heroku est la plus grande perte en termes de DX ; la gestion directe des fournisseurs est le compromis à faire pour la souveraineté.

Pipelines (review apps, CI/CD)

Ce que nous utilisons à la place: Binadit DevOps & Support. Des environnements de review par branche sur Kubernetes, créés et détruits par GitLab CI.
Note d'ingénierie: Coolify prend en charge les environnements de prévisualisation par branche.

Heroku Buildpacks

Ce que nous utilisons à la place: Binadit DevOps & Support. Dockerfiles ou Cloud Native Buildpacks, construits dans GitLab CI.
Note d'ingénierie: La plupart des applications Heroku se déploient sans modification via Cloud Native Buildpacks sur Coolify.

Logplex / Logging

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Loki pour l'agrégation, avec Grafana pour les requêtes et des politiques de rétention par stream.
Note d'ingénierie: Loki est le pattern standard ; il agrège les logs de tous les containers.

Heroku CI

Ce que nous utilisons à la place: Binadit DevOps & Support. GitLab CI avec des runners sur votre propre infrastructure.
Note d'ingénierie: GitLab CI sur un runner auto-hébergé dans l'UE est le remplacement de niveau production.

Heroku Private Spaces

Ce que nous utilisons à la place: Binadit Private Infrastructure. Environnement entièrement isolé, matériel dédié, architecture réseau sur mesure.
Note d'ingénierie: Le concept de « Private Spaces » n'est rien d'autre qu'un VPC ; le réseau EU standard le gère nativement.

SSL / domains

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. cert-manager avec Let's Encrypt, avec renouvellement automatique.
Note d'ingénierie: Le transfert de domaine est un changement de registrar ; le SSL est automatisé par toutes les alternatives PaaS modernes.

Comment nous migrons depuis Heroku (Salesforce)

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

Choix du PaaS + cartographie des dépendances

Décider du PaaS EU (Coolify est notre choix par défaut pour une DX style Heroku ; Dokku pour les minimalistes ; offre managée de Binadit pour les équipes qui délèguent). Inventorier les apps Heroku, dynos et add-ons.
Jours 4-10

Base de données + changement d'add-on

Heroku Postgres répliqué vers PostgreSQL managé UE avec réplication logique. Chaque add-on remplacé par un équivalent UE (un par un pour contrôler le risque). La journalisation migrée vers Loki.
Semaines 2-4

Bascule de l'application

Applications redéployées sur Coolify avec les mêmes buildpacks. Bascule DNS avec une fenêtre TTL basse. Application Heroku archivée après une période de vérification.

TCO sur 5 ans des sorties Heroku : 60-85% moins cher. Le modèle tarifaire de Heroku (par dyno, par add-on, par palier de base de données) s'accumule rapidement ; un PaaS auto-hébergé sur infrastructure européenne remplace une facture Heroku typique de 500-2000 $/mois pour une fraction de ce montant en infrastructure brute, plus nos frais de gestion si vous ne souhaitez pas l'exploiter vous-même.

Questions fréquemment posées

Voir toutes les questions fréquemment posées

La région UE de Heroku est-elle suffisante pour le RGPD ?

Résidence uniquement. La région EU « Common Runtime » de Heroku fonctionne sur AWS Irlande - soit deux couches de processeurs sous contrôle américain (Salesforce comme partie contractante directe, AWS comme infrastructure sous-jacente). L'analyse CLOUD Act s'applique aux deux. Pour les workloads strictement Schrems II, Heroku EU n'est pas suffisant.

Allons-nous perdre la DX de Heroku ?

Coolify reproduit les déploiements git-push, les templates d'applications en un clic, les environnements de prévisualisation par PR, le SSL automatisé, les variables d'environnement et les déploiements par branche. L'expérience développeur est réellement proche. La principale perte est le marketplace d'add-ons ; on la remplace par des relations directes avec les fournisseurs, ce qui est plus gérable que ne le suggère le marketing de Heroku.

Qu'en est-il de Heroku Connect pour la synchronisation avec Salesforce ?

Si vous conservez Salesforce CRM, Heroku Connect doit être reconstruit (API REST/Bulk + file d'attente). Si vous quittez également Salesforce - ce qui est de plus en plus courant dans les sorties motivées par Schrems II - cette préoccupation disparaît.

Pouvons-nous utiliser Coolify nous-mêmes ou avons-nous besoin d'aide ?

De nombreuses équipes hébergent elles-mêmes Coolify avec succès sur une seule VM. Pour les scénarios de production multi-tenant - multi-environnement, blue-green, gestion des secrets - une configuration avec un partenaire managé prend tout son sens. Nous déployons et exploitons des clusters Coolify pour nos clients.

Combien de temps dure une sortie de Heroku ?

Pour une charge de travail réduite (1 à 3 apps, 1 Postgres, quelques add-ons) : 1 à 2 semaines. Pour une configuration Heroku d'entreprise multi-apps avec Private Spaces et Heroku Connect : 6 à 10 semaines. La surface applicative de Heroku est volontairement simple, ce qui fait de la migration essentiellement un exercice de chorégraphie.

Qu'en est-il des nouvelles plateformes de type Heroku ?

Ils reproduisent bien l'expérience développeur, et si c'est tout ce dont vous avez besoin, ils constituent un point d'atterrissage raisonnable. Vérifiez deux choses avant de vous engager : sous quelle juridiction se trouvent la plateforme et sa base de données, et à quoi ressemble la sortie dans deux ans. Une plateforme qui construit à partir de votre Dockerfile sur une infrastructure que vous pourriez exploiter vous-même est une conversation bien plus courte plus tard qu'une plateforme avec un build et un runtime propriétaires.

Planifiez votre sortie de Heroku (Salesforce).

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