Ce que nous construisons
- Fondations cloud. Une organisation multi-comptes (AWS Organizations, dossiers GCP ou management groups Azure) avec SSO, garde-fous et logs centralisés. Pourquoi c’est important dès le premier jour (en anglais).
- Réseau. VPC, sous-réseaux privés, VPN ou Direct Connect vers ce qui reste on-prem, et un trafic sortant qui ne coûte pas une fortune en silence.
- Du compute adapté. Conteneurs managés (ECS, Cloud Run), Kubernetes quand il se justifie, ou de simples VM quand c’est la bonne réponse.
- Données. Bases de données managées, bascule par réplication pour limiter l’interruption à quelques minutes, et des sauvegardes testées avant la mise en production.
- Pipelines. Une CI/CD qui construit une seule fois et promeut le même artefact en staging puis en production.
- Tout dans Terraform. Documenté, revu en pull requests et remis à votre équipe.
Le déroulé d’une migration
- Inventaire. Chaque serveur, base de données, cron job, enregistrement DNS et dépendance externe, avec un responsable en face.
- Architecture cible. Région (Francfort, Milan, ou la nouvelle Local Zone d’Athènes pour les workloads sensibles à la latence), choix du compute, plan pour les données et estimation des coûts.
- Fondations et pipelines. Construits et testés avant que le moindre trafic de production ne bouge.
- Répétition. Une répétition complète de la bascule en staging, chronométrée, avec un plan de rollback.
- Bascule. Données répliquées à l’avance, DNS basculé avec des TTL courts, ancien environnement maintenu à chaud jusqu’à ce que vous soyez serein.
- Les 30 premiers jours. Garde-fous sur les coûts, alertes et right-sizing, une fois que le trafic réel montre ce dont vous avez besoin.
La checklist complète que nous utilisons se trouve dans notre checklist de migration cloud (en anglais).
Pour qui
- Les entreprises sur un VPS, chez un hébergeur local ou sur des serveurs on-prem qui arrivent à leurs limites.
- Les équipes qui quittent les plateformes de type Heroku pour des raisons de coût ou de maîtrise.
- Les startups qui lancent un produit et veulent des fondations solides avant le premier client, pas après le premier incident.
Questions fréquentes
Combien de temps dure une migration cloud ?
Une petite application avec une seule base de données prend en général quelques semaines. Une entreprise avec plusieurs services, environnements et intégrations compte plutôt deux à six mois. L’étape d’inventaire vous donne un calendrier réaliste avant de vous engager.
Aurons-nous une interruption de service ?
Nous visons quelques minutes, pas quelques heures. Les bases de données sont répliquées à l’avance et le DNS basculé avec des TTL courts : la fenêtre de bascule est courte et a été répétée. Certains systèmes legacy nécessitent une fenêtre de maintenance ; nous vous le disons dès le départ.
Vers quel cloud migrer ?
Pour la plupart des startups, AWS est le choix par défaut, mais GCP et Azure l’emportent dans certains cas, comme les produits très orientés données ou les entreprises centrées sur Microsoft. Notre comparatif AWS, GCP et Azure (en anglais) détaille les compromis.
Avons-nous besoin de Kubernetes ?
Souvent, non. Pour une poignée de services, des conteneurs managés comme ECS ou Cloud Run coûtent moins cher et sont plus simples à exploiter. Nous recommandons Kubernetes quand vous avez beaucoup de services, des équipes plateforme ou des besoins multi-cloud. Voir notre conseil Kubernetes.
Nos données resteront-elles dans l’UE ?
Oui. Nous choisissons par défaut des régions européennes et cartographions l’emplacement de chaque donnée et de chaque log, ce qui aide aussi pour le RGPD et NIS2.