Est-ce différent du service de migration ?

Oui. Le service de migration déplace un workload de A vers B. La réversibilité conçoit la liberté de repartir (de quitter B) et produit un plan de sortie testé comme livrable. Vous pouvez l’acheter seule pour durcir un fournisseur que vous exploitez déjà, ou comme la moitié « sortie » d’une migration.

La réversibilité impose-t-elle d’éviter tout service managé ?

Non. Refuser tous les services managés a son propre coût. Le but est un verrouillage délibéré : vous savez exactement quelles accroches propriétaires vous avez acceptées, pourquoi, et ce qu’il faudrait pour retirer chacune. La réversibilité est une décision documentée, pas de l’ascèse.

Pourquoi un régulateur s’intéresse-t-il à notre plan de sortie ?

Des règles européennes comme DORA attendent des entreprises qu’elles maîtrisent le risque de concentration sur les tiers informatiques critiques, ce qui inclut de pouvoir quitter ou substituer un fournisseur. Un plan de réversibilité testé est la preuve que le risque est maîtrisé, et pas seulement affirmé.

Nous rendrez-vous réversibles vis-à-vis de SaveOps aussi ?

C’est tout l’objet. Tout est en infrastructure-as-code et runbooks dans vos dépôts, exploitable par votre équipe. Une mission de réversibilité qui vous laisserait dépendants de nous contredirait sa propre thèse.

Réversibilité cloud

Réversibilité cloud : une sortie que vous pouvez réellement exécuter

La réversibilité, c’est la capacité de quitter un fournisseur cloud (celui sur lequel vous êtes aujourd’hui, comme celui vers lequel vous migrez ensuite) sans réécriture et sans négociation sous contrainte. C’est de plus en plus une attente réglementaire, pas seulement une bonne hygiène. SaveOps la construit comme une mission à part entière : un plan de sortie documenté et testé, et une architecture cible conçue pour ne plus jamais vous verrouiller.

Ce que la réversibilité vous apporte vraiment

Un cloud que vous ne pouvez pas quitter est un fournisseur qui a un pouvoir de fixation des prix sur vous. La réversibilité est l’ingénierie qui retire ce levier avant que vous en ayez besoin.

Pouvoir de négociation Un fournisseur que vous pouvez quitter de façon crédible en semaines, pas en années, est un fournisseur avec qui vous pouvez négocier. Le verrouillage est la raison pour laquelle les devis de renouvellement ne font que monter.
Défendabilité réglementaire Les cadres européens attendent de plus en plus une stratégie de sortie documentée pour les dépendances cloud critiques. Un plan de réversibilité est l’artefact qu’un auditeur (ou un examinateur DORA) demande à voir.
Résilience, pas seulement sortie La portabilité qui vous permet de partir vous permet aussi de basculer en secours, de répartir entre fournisseurs ou de survivre à la défaillance d’un prestataire. Réversibilité et résilience sont la même ingénierie.
Affranchi du prochain verrou Quitter AWS pour un fournisseur que vous ne pourrez pas quitter non plus, ce n’est pas de la souveraineté. Nous concevons la cible pour que les accroches propriétaires soient l’exception que vous avez choisie, pas le défaut dont vous héritez.

Comment nous construisons un plan de sortie

La réversibilité est un livrable, produit dans l’ordre. Il vaut que vous quittiez un hyperscaler maintenant ou que vous durcissiez un fournisseur que vous exploitez déjà.

Audit du verrouillage Nous inventorions chaque dépendance qui vous rendrait difficile à déplacer : services managés propriétaires, coût d’egress des données, couplage à l’identité et à l’IAM, logiciels de marketplace sous licence et engagements contractuels. Le résultat est une carte hiérarchisée de ce qui vous retient, et où.
Conception de la portabilité Nous retravaillons le parc vers des fondations portables (formats ouverts, API standard, infrastructure-as-code, workloads conteneurisés) pour que la couche substituable le reste. Là où un service propriétaire mérite sa place, cela devient un choix délibéré et documenté.
Runbook de sortie Nous écrivons et versionnons la procédure de sortie : l’ordre des opérations pour déplacer données et workloads hors du fournisseur, le plan d’egress, les étapes DNS et de bascule, et le chemin de retour arrière. Un plan jamais relu n’est pas un plan.
Répétition Nous testons la sortie sur une tranche réelle (monter le workload chez une alternative, déplacer de vraies données, mesurer le temps et le coût) pour que le runbook reflète ce qui se passe vraiment, et non ce que le schéma suppose.
Transfert du dossier Vous conservez le dossier de réversibilité : la carte du verrouillage, les décisions de portabilité, le runbook de sortie testé et les estimations coût/temps. Il vit dans vos dépôts et vous appartient, y compris pour l’utiliser contre nous.

Ce que contient un artefact de transfert propre

Le dossier de réversibilité que nous remettons est un ensemble documentaire concret, pas une promesse. Il contient :

Un inventaire hiérarchisé de chaque vecteur de verrouillage (service propriétaire, coût d’egress, couplage IAM, engagement contractuel) avec son coût de suppression.
L’infrastructure-as-code de tout le parc, dans vos dépôts, pour que l’environnement soit reproductible sans la console du fournisseur.
Un runbook de sortie versionné et testé : les étapes ordonnées, le plan d’egress des données, la bascule et le chemin de retour arrière.
Des estimations directionnelles de temps et de coût pour une sortie réelle, mesurées sur une tranche répétée plutôt que devinées.
La liste des dépendances propriétaires délibérées que vous avez choisi de garder, pour que la prochaine équipe sache exactement où subsiste la friction.

Questions que posent achats et responsables plateforme

Est-ce différent du service de migration ?: Oui. Le service de migration déplace un workload de A vers B. La réversibilité conçoit la liberté de repartir (de quitter B) et produit un plan de sortie testé comme livrable. Vous pouvez l’acheter seule pour durcir un fournisseur que vous exploitez déjà, ou comme la moitié « sortie » d’une migration.
La réversibilité impose-t-elle d’éviter tout service managé ?: Non. Refuser tous les services managés a son propre coût. Le but est un verrouillage délibéré : vous savez exactement quelles accroches propriétaires vous avez acceptées, pourquoi, et ce qu’il faudrait pour retirer chacune. La réversibilité est une décision documentée, pas de l’ascèse.
Pourquoi un régulateur s’intéresse-t-il à notre plan de sortie ?: Des règles européennes comme DORA attendent des entreprises qu’elles maîtrisent le risque de concentration sur les tiers informatiques critiques, ce qui inclut de pouvoir quitter ou substituer un fournisseur. Un plan de réversibilité testé est la preuve que le risque est maîtrisé, et pas seulement affirmé.
Nous rendrez-vous réversibles vis-à-vis de SaveOps aussi ?: C’est tout l’objet. Tout est en infrastructure-as-code et runbooks dans vos dépôts, exploitable par votre équipe. Une mission de réversibilité qui vous laisserait dépendants de nous contredirait sa propre thèse.