Reprenez-vous notre infrastructure, ou travaillez-vous avec notre équipe ?

Avec votre équipe. Nos ingénieurs s’intègrent à votre escouade (mêmes dépôts, mêmes points quotidiens) précisément pour que le savoir reste chez vous après notre départ. Une migration que seul SaveOps comprend a échoué au regard de notre propre définition de « terminé ».

Vers quel fournisseur européen allez-vous nous migrer ?

Celui qui convient à vos workloads, pas celui que nous préférons. Nous notons d’abord votre parc face au catalogue managé de la cible : un parc orienté streaming pointe vers OVHcloud, un parc guidé par le coût vers Hetzner, un parc équilibré vers Scaleway. La carte des services est le point de départ de cette comparaison.

Comment évitez-vous de devenir le nouveau verrou ?

En faisant du transfert le livrable. Tout est en infrastructure-as-code dans vos dépôts, documenté en runbooks et exploitable par votre équipe. Nous construisons la réversibilité vis-à-vis de nous avec la même rigueur que vis-à-vis de l’hyperscaler.

Pouvez-vous prouver des migrations passées ?

Nous pouvons les décrire de façon anonymisée (par exemple, une fintech qui a sorti ses workloads d’AWS) et citer les fournisseurs européens précis que nos ingénieurs ont exploités en production. Nous ne publions ni logos clients ni études de cas inventées ; l’honnêteté est le produit.

Service de migration cloud

Des ingénieurs seniors qui vous sortent des hyperscalers, puis s’en vont

SaveOps n’est pas un cabinet de conseil qui livre un support de stratégie et facture une prestation au forfait récurrent. Nous plaçons des ingénieurs seniors dans votre équipe, au TJM, pour mener la migration avec vos ingénieurs. Quand le workload tourne sur une infrastructure souveraine européenne et que votre équipe en est propriétaire, nous transférons et nous partons. Le livrable, c’est un système migré, qui vous appartient, et une sortie propre. Jamais un rapport, jamais une dépendance entretenue.

Comment se déroule la mission

Un seul modèle, volontairement étroit : des heures d’ingénierie en régie avec un transfert défini. Voici ce que cela signifie concrètement.

En régie, pas en conseil Nos ingénieurs rejoignent votre équipe, vos points quotidiens et vos dépôts. Ils écrivent l’infrastructure-as-code, basculent les bases de données et débuggent l’incident de 2 h du matin aux côtés de vos équipes, pas depuis un slide.
Facturé au TJM Vous payez un TJM transparent par ingénieur, pour les jours travaillés, calibré à la taille de votre parc. Pas de licence, pas de forfait récurrent, pas de coût par utilisateur. Quand le travail est fait, la facturation s’arrête.
Connaissance interne de la cible Le vivier comprend d’anciens ingénieurs de fournisseurs cloud européens comme Scaleway : la migration est conçue par des gens qui ont exploité la destination en production, pas seulement l’hyperscaler de départ.
Honnêteté radicale sur les écarts Là où un fournisseur européen accuse un vrai retard (étendue du serverless, ML managé, CDN mondial), nous le disons avant la signature et concevons en conséquence. La carte des services AWS→UE n’adoucit jamais un écart pour emporter le marché.
Nous partons La réussite, c’est votre équipe qui exploite le workload sans nous. Nous ne fabriquons pas de dépendance entretenue ; le transfert (runbooks, infrastructure-as-code, équipe formée) fait partie du livrable, ce n’est pas une option payante.

Les phases d’une migration en régie

Chaque mission est calibrée à votre parc, mais la trame est constante. Ces étapes s’enchaînent dans l’ordre, votre équipe impliquée à chacune pour que le savoir reste en interne.

Découverte et inventaire Nous cartographions votre parc réel (chaque service managé, magasin de données, dépendance réseau et ligne de coût) face à un fournisseur européen cible, et notons chaque workload : migration propre, partielle ou vrai écart. Aucune migration ne démarre au jugé.
Conception de la cible et preuve de concept Nous choisissons le fournisseur souverain (ou le mélange) adapté à vos workloads, puis prouvons d’abord les parties risquées : la bascule de base de données, le repointage du stockage objet, le service sans jumeau managé. Les surprises surgissent ici, pas en production.
Migration incrémentale Les workloads migrent par incréments revus (jamais une bascule « big bang »), avec des chemins de retour arrière et vos ingénieurs aux commandes avec les nôtres. Les déplacements liés à la gravité des données et l’egress sont séquencés pour maîtriser risque et coût.
Transfert Nous laissons l’infrastructure-as-code, les runbooks et une équipe formée pour l’exploiter. Le sens du transfert : vos ingénieurs savent faire tourner, mettre à l’échelle et débugger la plateforme sans nous en ligne.
Sortie propre Nous nous désengageons. Le workload est à vous, sur une infrastructure que vous contrôlez, sans dépendance SaveOps, licence ni verrou laissés derrière. C’est la même réversibilité que nous bâtissons vis-à-vis de l’ancien hyperscaler.

Ce que « terminé » veut dire

Une migration que nous signerions coche chacun de ces points. Sinon, elle n’est pas finie.

Le workload tourne en production sur une infrastructure souveraine européenne, pas dans un environnement de recette ni sur un slide.
Votre équipe en est propriétaire et l’exploite : infrastructure-as-code dans vos dépôts, runbooks écrits, astreinte formée.
L’ancien compte hyperscaler peut être fermé, aucune dépendance silencieuse ne vous y retient.
Aucune dépendance SaveOps entretenue : pas d’outillage propriétaire, pas de licence, pas de « appelez-nous pour changer quoi que ce soit ».
La réversibilité est intacte : vous pourriez repartir, quitter ce fournisseur, sans réécriture. La souveraineté inclut la liberté de nous quitter aussi.

Comment nous facturons : le TJM

Nous facturons un TJM transparent par ingénieur en régie, pour les jours réellement travaillés. Le coût total dépend de deux variables que vous pouvez raisonner : le TJM et le nombre de jours-ingénieur que votre parc exige.

Ce second nombre dépend de la part de votre stack posée sur des lignes propres plutôt que sur de vrais écarts. Un parc sans état, en conteneurs et Postgres, représente une fraction de l’effort d’un parc appuyé sur DynamoDB, Redshift ou un câblage événementiel Lambda poussé. Nos pages de migration par fournisseur donnent des fourchettes de jours-ingénieur pour un parc de taille moyenne, et le calculateur estime la facture d’infrastructure après la migration.

Ce que nous ne faisons pas : vendre une licence, un abonnement à une plateforme, un forfait récurrent ou un support de stratégie. Quand la migration est faite et que votre équipe en est propriétaire, la facturation s’arrête.

Ce qu’un DSI demande avant de s’engager

Reprenez-vous notre infrastructure, ou travaillez-vous avec notre équipe ?: Avec votre équipe. Nos ingénieurs s’intègrent à votre escouade (mêmes dépôts, mêmes points quotidiens) précisément pour que le savoir reste chez vous après notre départ. Une migration que seul SaveOps comprend a échoué au regard de notre propre définition de « terminé ».
Vers quel fournisseur européen allez-vous nous migrer ?: Celui qui convient à vos workloads, pas celui que nous préférons. Nous notons d’abord votre parc face au catalogue managé de la cible : un parc orienté streaming pointe vers OVHcloud, un parc guidé par le coût vers Hetzner, un parc équilibré vers Scaleway. La carte des services est le point de départ de cette comparaison.
Comment évitez-vous de devenir le nouveau verrou ?: En faisant du transfert le livrable. Tout est en infrastructure-as-code dans vos dépôts, documenté en runbooks et exploitable par votre équipe. Nous construisons la réversibilité vis-à-vis de nous avec la même rigueur que vis-à-vis de l’hyperscaler.
Pouvez-vous prouver des migrations passées ?: Nous pouvons les décrire de façon anonymisée (par exemple, une fintech qui a sorti ses workloads d’AWS) et citer les fournisseurs européens précis que nos ingénieurs ont exploités en production. Nous ne publions ni logos clients ni études de cas inventées ; l’honnêteté est le produit.