AWS ou Scaleway : retour terrain d'un CTO

« On part sur AWS parce que c'est le standard » est probablement la phrase que j'ai le plus entendue en cadrage d'infrastructure ces cinq dernières années, et c'est probablement aussi la moins bien argumentée. J'ai migré des équipes d'AWS vers Scaleway, d'autres dans le sens inverse, et accompagné plusieurs qui sont restées sur AWS après une comparaison sérieuse. Ce retour terrain compile ce qui, en pratique, fait vraiment pencher la balance d'un côté ou de l'autre — au-delà des arguments de principe.

Le coût : une comparaison qui dépend entièrement de l'usage

Sur le papier, Scaleway affiche des prix unitaires nettement inférieurs à AWS sur le calcul et le stockage brut, souvent 30 à 50 % moins chers sur des instances comparables. Dans les faits, l'écart de facture finale dépend surtout de trois éléments rarement anticipés :

• Le coût de sortie des données (egress), historiquement élevé chez AWS et beaucoup plus contenu chez Scaleway. Pour une architecture qui sert beaucoup de contenu ou d'API à fort trafic sortant, cet écart peut représenter plusieurs milliers d'euros par mois.
• La granularité de la facturation des services managés, où AWS propose davantage d'options mais rend le suivi budgétaire plus complexe, avec un risque réel de dérive silencieuse sans FinOps dédié.
• Le coût caché de la complexité : une architecture AWS bien optimisée par une équipe expérimentée coûte souvent moins cher qu'une architecture Scaleway mal dimensionnée par manque d'habitude des services disponibles.

En clair, comparer deux devis de instances ne suffit jamais. Il faut simuler douze mois de trafic réel, egress compris, avant de trancher.

La maturité des services managés : l'écart se réduit mais reste réel

C'est le point où AWS conserve une avance nette. Le catalogue de services managés — bases de données spécialisées, machine learning, orchestration événementielle, observabilité intégrée — reste plus profond et plus mature chez AWS. Pour une équipe qui a besoin de services de niche ou d'une scalabilité mondiale immédiate, cet écart pèse lourd.

Scaleway a fortement progressé sur les briques essentielles : Kubernetes managé, bases de données PostgreSQL et Redis managées, object storage compatible S3, fonctions serverless. Pour une application SaaS B2B classique avec une stack standard, ces briques suffisent aujourd'hui largement. Le point de bascule se situe sur les besoins spécialisés : si votre produit dépend fortement d'un service IA managé propriétaire ou d'une région géographique qu'AWS est seul à couvrir, la question ne se pose même pas.

Le support : la vraie différence se voit en heure de crise

Sur le support standard, les deux fournisseurs sont comparables en réactivité pour les tickets non critiques. La différence apparaît en heure de crise. AWS, avec un plan de support Business ou Enterprise, offre une réponse quasi immédiate sur les incidents critiques, mais à un coût mensuel qui démarre autour de plusieurs centaines d'euros et grimpe vite avec la facture d'infrastructure. Scaleway, plus petit, offre un support parfois plus direct et personnalisé — j'ai eu des échanges avec des ingénieurs Scaleway en moins d'une heure sur un incident de production, ce qui est plus rare chez AWS en dehors des plans premium.

Pour une PME sans astreinte interne solide, ce paramètre mérite d'être testé avant la migration, pas découvert pendant le premier incident. Je recommande systématiquement d'ouvrir un ticket de test non urgent sur les deux plateformes avant de signer, pour comparer le délai et la qualité de réponse réels.

La migration : le coût le plus sous-estimé du dossier

Le coût technique d'une migration Cloud-to-cloud est presque toujours sous-évalué en amont. Trois postes à chiffrer systématiquement avant de décider :

1. La réécriture des dépendances aux services propriétaires : si l'architecture utilise fortement des services spécifiques comme les files de messages managées ou les fonctions serverless propriétaires, la portabilité n'est jamais automatique.
2. La double exploitation temporaire, période pendant laquelle l'entreprise paie les deux infrastructures en parallèle pour sécuriser la bascule.
3. Le temps d'équipe immobilisé, souvent estimé à quelques jours et qui s'étale en réalité sur plusieurs semaines pour une architecture de taille moyenne, tests de charge et de reprise inclus.

Une migration mal cadrée peut coûter, en temps d'équipe et en double facturation, l'équivalent d'un an d'économies attendues sur l'hébergement. Ce n'est pas un argument contre la migration, c'est un argument pour la chiffrer sérieusement avant de la lancer.

Une grille de décision simple

Pour trancher sans idéologie, trois questions suffisent dans la majorité des cas :

• Votre stack dépend-elle de services managés spécialisés que seul AWS propose à maturité ? Si oui, restez ou migrez vers AWS.
• Votre facture est-elle dominée par le trafic sortant ou le stockage brut, sur une stack standard ? Scaleway devient alors très compétitif.
• Disposez-vous d'une équipe capable d'absorber le coût de migration sans ralentir la roadmap produit pendant deux à trois mois ? Si la réponse est non, le statu quo bien optimisé vaut souvent mieux qu'une migration précipitée.

Sur des dossiers de cette nature, faire appel à un CTO externalisé pour cadrer votre migration permet d'objectiver ces trois questions avec des chiffres réels plutôt qu'avec une préférence de principe, et d'éviter de rejouer le débat tous les six mois.

FAQ

Scaleway est-il fiable pour une application en production critique ?

Oui, pour une architecture standard avec des besoins de disponibilité classiques, Scaleway propose des garanties de disponibilité comparables à AWS sur ses services managés principaux. Le point de vigilance porte surtout sur les besoins de scalabilité mondiale immédiate ou de services très spécialisés, où AWS reste en avance.

Combien de temps prévoir pour migrer une application moyenne d'AWS vers Scaleway ?

Pour une application avec une stack standard (base de données, API, stockage objet), comptez généralement six à dix semaines en incluant les tests de charge et de reprise, à condition que l'architecture ne dépende pas fortement de services propriétaires AWS difficiles à réécrire.