Réversibilité : portabilité, coûts de sortie et plan de sortie

La réversibilité est la capacité de reprendre ses données chez un autre fournisseur, dans un délai et pour un coût connus à l'avance. Une sortie qu'on n'a jamais répétée n'est qu'une promesse du contrat. Cette leçon vous apprend à chiffrer une sortie sur une grille tarifaire datée, à copier un jeu de données vers un second stockage objet et à prouver que la copie est identique par des empreintes sha256, puis à écrire le plan qui rend la sortie exécutable. Elle s'adresse à qui évalue ou exploite une plateforme cloud et doit pouvoir répondre à la question : « combien de temps et d'argent pour partir ? ».

Ce que vous allez apprendre

• Distinguer portabilité, coût de sortie et délai de sortie, trois obstacles différents.
• Situer une architecture sur l'échelle de dépendance au fournisseur et choisir une stratégie pour la réduire.
• Chiffrer une sortie : volume, tarif, franchise, durée, double facturation, dispositif de sortie du fournisseur.
• Copier un jeu d'objets entre deux stockages et prouver l'intégrité par sha256sum.
• Rédiger un plan de sortie avec un ordre, un critère d'arrêt et une répétition.

Prérequis : avoir lu la leçon Souveraineté technologique du cloud, dont la grille d'évaluation pose la question de la réversibilité ; connaître la notion d'objet et de bucket (stockage de blocs, fichiers et objets) ; savoir utiliser un terminal Linux. La pratique demande Docker ou Podman et un client de copie compatible S3, ici rclone (version v1.75.2 rejouée), présenté dans Rclone : synchroniser et sauvegarder vos données cloud ; la preuve repose sur sha256sum, présent sur tout système Linux. Aucun compte cloud n'est nécessaire.

Qu'est-ce que la réversibilité, et pourquoi la mesurer ?

La réversibilité se mesure par trois grandeurs : ce que vous pouvez reprendre, ce que cela coûte, et le temps que cela prend. Un fournisseur peut promettre une clause de réversibilité dans sa convention (SecNumCloud en exige une) sans que cette promesse dise rien du coût réel ni de la durée. La mesure, elle, vous appartient : elle se fait avant la décision de partir, pas après.

Chaque grandeur correspond à un obstacle distinct :

Obstacle	Question à poser	Ce qui le crée
Portabilité	Puis-je relire mes données ailleurs, sans le service d'origine ?	formats ou API propriétaires, services managés sans équivalent
Coût de sortie	Combien me facture-t-on pour faire sortir mes données ?	trafic sortant, requêtes, double facturation pendant la bascule
Délai de sortie	En combien de temps le volume sort-il, et que devient le service pendant ce temps ?	volume divisé par le débit réellement utile

Glissez pour voir

Le tableau sert de grille : une sortie est réversible quand les trois réponses sont écrites, chiffrées et vérifiées. Les sections suivantes traitent chaque obstacle, puis le plan qui les assemble.

Que rend un service portable ?

Un service est portable quand ses données sortent dans un format ouvert par une interface que d'autres services comprennent. Pour le stockage d'objets, l'API compatible S3 joue ce rôle : un même client lit et écrit chez Scaleway, Outscale, OVHcloud ou AWS, ce qui rend la copie d'un bucket à l'autre possible avec un seul outil. La portabilité tombe dès que la donnée vit dans un service propriétaire : base managée à moteur maison, fonctions déclenchées par des événements du fournisseur, files de messages sans standard.

Deux réflexes se déduisent de cette observation.

Classez vos données par format de sortie, avant de parler de coût : objets bruts (portables), base relationnelle exportable en dump standard (portable avec effort), données dans un moteur propriétaire (portables seulement par un export applicatif, donc par du code à écrire). Le coût de sortie le plus élevé n'est pas le trafic : c'est la réécriture de ce qui dépendait du service.

Distinguez le chiffrement côté serveur du chiffrement applicatif, et sachez où est la clé maîtresse. Le chiffrement côté serveur, par défaut ou avec une clé du fournisseur, protège les disques mais pas la sortie : l'API déchiffre à la lecture et rend du clair à toute identité qui en a le droit. Chez AWS, par exemple, SSE-S3 est appliqué par défaut à tout nouvel objet depuis le 5 janvier 2023, et un objet chiffré par SSE-KMS se télécharge en clair pour qui détient le droit kms:Decrypt sur la clé. À l'inverse, une donnée chiffrée par l'application avant dépôt, avec une clé maîtresse qui reste dans le service de gestion de clés (KMS) du fournisseur, sort illisible hors de ce fournisseur. Savoir qui détient cette clé, question traitée dans la leçon sur les secrets et les clés, fait donc partie de la portabilité.

Une clé de KMS ne s'exporte pas. La documentation d'AWS KMS la dit conçue pour ne jamais quitter le module matériel en clair, et celle de Google Cloud KMS indique que le matériel d'une version de clé ne peut jamais être consulté ni exporté. Chez Azure Key Vault (offres Premium et Managed HSM), la clé n'est exportable que si elle a été créée avec l'option exportable et une politique de libération, et la libération exige une attestation de l'environnement d'exécution de confiance qui la demande, au format de jeton Microsoft Azure Attestation. Régénérer une clé produit en principe un nouveau matériau cryptographique, pas une copie de l'ancien : ce que l'ancienne clé a chiffré ne se relit pas avec la nouvelle. Le remède se joue donc avant la bascule : déchiffrer les données puis les rechiffrer avec une clé que vous contrôlez, plutôt que de découvrir à l'arrivée qu'elles sont illisibles.

Quel degré de dépendance, et comment le réduire ?

La dépendance à un fournisseur (vendor lock-in) n'est pas binaire : elle se mesure au temps qu'il faudrait pour partir. Elle vient des services managés propriétaires, très pratiques mais sans équivalent chez les concurrents. Le tableau compare quelques services courants et dit s'il existe un standard ouvert sur lequel s'appuyer pour sortir.

Besoin	Service propriétaire (exemple AWS)	Équivalents Azure, GCP	Standard ouvert
Fonction événementielle	Lambda	Azure Functions, Cloud Run functions	Aucun
Base NoSQL managée	DynamoDB	Azure Cosmos DB, Firestore	Aucun
Orchestration de conteneurs	ECS	Azure Container Apps, Cloud Run	Kubernetes, portable
Base SQL managée	Aurora	Azure Database for PostgreSQL, Cloud SQL	PostgreSQL, portable pour les données, pas pour la configuration
Stockage objet	S3	Azure Blob Storage, Cloud Storage	API S3, standard de fait

Glissez pour voir

Trois niveaux se déduisent du tableau, de la sortie la plus courte à la plus longue. Un lock-in faible n'utilise que des standards : machines décrites en code, Kubernetes, PostgreSQL standard, stockage compatible S3 ; la sortie consiste à rejouer l'infrastructure as code et à restaurer les bases. Un lock-in moyen s'appuie sur des services managés aux interfaces standard (Kubernetes managé, base PostgreSQL managée, Redis managé) : chaque service est à reconfigurer chez le nouveau fournisseur. Un lock-in fort repose sur des services propriétaires (fonctions, DynamoDB, file de messages et passerelle d'API propriétaires) : l'application est à réécrire presque entièrement. Le coût de sortie croît avec le nombre de services propriétaires, et il s'estime application par application, sans règle générale.

Trois stratégies réduisent la dépendance sans la supprimer.

L'abstraction isole l'appel au fournisseur derrière une interface que vous maîtrisez. Le code métier appelle une classe de votre cru, et seule cette classe connaît le service. Si la base change, seule elle est réécrite.

# ❌ Lock-in fort : le code métier appelle directement DynamoDB
import boto3
table = boto3.resource("dynamodb").Table("users")
table.put_item(Item={"id": "123", "name": "Alice"})

# Lock-in faible : le code métier ne connaît que l'interface
class UserRepository:
    def save(self, user):
        ...  # l'implémentation DynamoDB, ou PostgreSQL demain, vit ici

UserRepository().save(user)

Les standards ouverts remplacent un service propriétaire quand un équivalent existe : Kubernetes plutôt qu'un orchestrateur maison du fournisseur, PostgreSQL standard plutôt qu'Aurora Serverless, Redis auto-hébergé plutôt qu'un cache propriétaire, RabbitMQ ou Kafka plutôt qu'une file propriétaire, un stockage compatible S3 plutôt qu'une classe d'archivage propriétaire (voir le comparatif des stockages objet).

Le multi-cloud sélectif place le calcul et les données sur un cloud principal, la reprise sur un second fournisseur en veille, et le DNS ou le CDN chez un service neutre. Il double la complexité d'exploitation : ne l'adoptez que si vos équipes savent opérer deux environnements, comme l'explique la page sur les modèles de déploiement.

Le lock-in n'est pas toujours un problème

Si une fonction serverless vous fait gagner six mois de développement et que vous n'avez aucune raison objective de quitter le fournisseur à l'horizon de votre plan, l'utiliser est un choix défendable. Le critère est le risque de devoir partir. Une startup en croissance rapide accepte la dépendance pour gagner du temps. Une entreprise réglementée la limite, parce qu'un changement législatif peut l'obliger à partir. Une grande organisation n'ajoute un second cloud que si ses équipes sont mûres pour l'opérer.

Combien coûte et combien dure une sortie ?

Le coût d'une sortie se calcule en six lignes : le volume, la franchise, le tarif, les requêtes, la double facturation, puis le dispositif de sortie du fournisseur, qui peut en déduire une partie. Chacune se renseigne avec une valeur datée prise sur la grille du fournisseur, jamais avec un chiffre mémorisé : les tarifs de sortie changent et les franchises encore plus vite. La page sur le coût du transfert sortant relève des grilles de référence au 9 octobre 2026 ; reprenez-les comme point de départ, puis revérifiez sur la page du fournisseur.

Ligne	Ce qu'elle contient	Exemple de formule
Volume sortant	taille totale à copier, en Go	5 To = 5 000 Go
Franchise	volume gratuit par mois, s'il existe	à lire sur la grille
Tarif	prix du Go sortant au-delà de la franchise	à lire sur la grille
Requêtes	nombre de lectures facturées à l'objet	nombre d'objets × prix de la lecture
Double facturation	coût des deux plateformes pendant la bascule	durée de bascule × coût mensuel / 30
Dispositif de sortie du fournisseur / Data Act	crédit ou gratuité du trafic sortant, accordé sur demande à qui quitte le fournisseur	à demander, avec ses conditions (tableau ci-dessous) ; à déduire seulement une fois accordé

Glissez pour voir

Un exemple chiffré montre la mécanique. Pour sortir 5 To (5 000 Go) d'un hyperscaler dont le premier palier de sortie est à 0,09 USD par Go (valeur relevée dans la page sur le transfert sortant, grille AWS du 1er octobre 2026), le calcul donne environ 5 000 × 0,09 = 450 USD, avant déduction d'une éventuelle franchise et avant les requêtes. Chez un fournisseur dont la sortie est incluse dans le prix, la ligne « tarif » vaut zéro, mais les lignes « durée » et « double facturation » restent à remplir.

Le règlement européen Data Act encadre depuis 2024 les frais de changement de fournisseur : la page sur le transfert sortant, qui cite l'article 29, indique que ces frais ne sont plus permis à partir du 12 janvier 2027 ; jusque-là, ils sont plafonnés aux coûts directement liés au changement. Ce n'est pas une raison d'attendre : l'egress courant d'un service en production reste facturé selon la grille, et la sortie doit être chiffrée avec les valeurs en vigueur au jour où vous la décidez.

Les trois grands fournisseurs proposent aussi un dispositif de sortie, qui se demande et ne s'applique jamais seul. Ces programmes sont des gestes commerciaux conditionnels, pas un droit : le droit, c'est le Data Act, qui plafonne les frais jusqu'au 12 janvier 2027 puis les supprime. Chaque programme exige une démarche auprès du fournisseur et ne vaut que pour une sortie complète du service. Leurs conditions changent : AWS a modifié les siennes le 30 septembre 2025 et le 8 octobre 2026. Relevé au 12 octobre 2026 sur les pages des fournisseurs, à revérifier avant de compter dessus.

Fournisseur	Démarche	Délai et conditions	Ce qui est exclu ou à retenir
AWS	demande au support, soumise à approbation ; une fois approuvée, des crédits couvrent les données migrées	tout transférer hors d'AWS depuis tous les comptes éligibles, ou hors d'un service donné ; hors UE, 180 jours pour terminer ; en UE, procédure de l'addendum Data Act (section 2.3)	fermeture du compte non exigée ; le seuil de 100 Go par mois n'est plus une condition depuis le 30 septembre 2025
Google Cloud	formulaire « Exit Notice » ; un agent est assigné sous 14 jours	30 jours pour démarrer, puis au moins 30 jours de migration ; résiliation du contrat du service concerné au moins 30 jours après la « Completion Notice », en fin de mois	crédit sur la dernière facture ; transferts par Internet seulement ; uniquement les produits listés sur la page de portabilité des données
Azure	demande de support (identifiant d'abonnement, date de début, volume estimé)	60 jours à partir de la date de début annoncée (180 jours pour une facturation au Royaume-Uni depuis des datacenters britanniques) ; annulation de tous les abonnements du compte après la sortie	crédit demandé au niveau de la facture ; exclus : ExpressRoute, VPN, Front Door, CDN ; Microsoft peut refuser le crédit si la procédure n'est pas suivie et peut modifier la politique

Glissez pour voir

Le tableau se lit comme une condition de sortie : chez Google Cloud, le geste commercial suppose de résilier le contrat du service quitté (les autres services du même contrat continuent) ; chez Azure, il suppose d'annuler tous les abonnements du compte après la sortie (hors Royaume-Uni, où l'on peut viser des services isolés). Une migration partielle et progressive d'un service n'y trouve donc pas son compte. Dans votre chiffrage, comptez le tarif plein et notez le crédit comme hypothèse favorable, à confirmer par écrit avant la décision.

Quelle durée prévoir ?

La durée d'une copie est le volume divisé par le débit réellement utile, et non par le débit nominal du lien. Un lien de 1 Gbit/s offre au mieux 125 Mo/s, soit environ 450 Go par heure : 5 To prennent au minimum un peu plus de 11 heures (5 000 ÷ 450). En pratique, le débit utile est inférieur (nombre d'objets, latence, limites du fournisseur) ; mesurez-le sur un échantillon, puis extrapolez avec une marge. Comptez aussi le temps de vérification, qui relit les deux côtés.

Cette durée décide de la méthode. Une copie qui tient dans un week-end se fait à froid, en coupant les écritures. Une copie de plusieurs semaines impose une synchronisation incrémentale : une première copie complète, puis des passes qui ne recopient que les différences, jusqu'à une dernière passe courte pendant une coupure.

Comment exécuter et prouver une sortie de données ?

Une sortie est exécutée quand une copie existe sur le second stockage et qu'une vérification indépendante prouve qu'elle est identique à l'original. L'exercice se joue sans compte cloud : deux stockages d'objets compatibles S3 sur votre machine jouent le fournisseur d'origine et le fournisseur d'arrivée. Vous utilisez RustFS, le banc de test que la page rclone met déjà en œuvre : réservez-le à cet exercice local. L'exercice a été rejoué avec RustFS 1.0.1 sous Docker 29.1.3 et rclone v1.75.2 (rclone version affiche la vôtre) ; il demande Docker ou Podman, les ports locaux 9000 et 9001 libres (ss -ltn pour le vérifier), et rclone installé.

1. Lancez deux stockages, sur deux ports locaux, avec l'image épinglée par son condensat :

   export AWS_ACCESS_KEY_ID=demo-local-access
   export AWS_SECRET_ACCESS_KEY=demo-local-secret-key
   IMG=rustfs/rustfs:1.0.1@sha256:1803faef57627e2d9c2e7d89d655d712ddded5389040054987163043fecb6a3c
   docker run -d --name rustfs-source -p 127.0.0.1:9000:9000 \
     -e RUSTFS_ACCESS_KEY="$AWS_ACCESS_KEY_ID" \
     -e RUSTFS_SECRET_KEY="$AWS_SECRET_ACCESS_KEY" \
     -e RUSTFS_VOLUMES=/data "$IMG"
   docker run -d --name rustfs-cible -p 127.0.0.1:9001:9000 \
     -e RUSTFS_ACCESS_KEY="$AWS_ACCESS_KEY_ID" \
     -e RUSTFS_SECRET_KEY="$AWS_SECRET_ACCESS_KEY" \
     -e RUSTFS_VOLUMES=/data "$IMG"

   Les valeurs demo-local-* sont des valeurs de démonstration liées à 127.0.0.1 : ne les réutilisez jamais sur un vrai stockage. Si vous préférez Podman, remplacez docker par podman.

2. Déclarez deux remotes rclone, source et cible, dans ~/.config/rclone/rclone.conf. Comme dans la page rclone, env_auth = true fait lire les clés dans les variables d'environnement, donc aucune clé n'est écrite dans le fichier :

   [source]
   type = s3
   provider = Other
   env_auth = true
   endpoint = http://127.0.0.1:9000
   
   [cible]
   type = s3
   provider = Other
   env_auth = true
   endpoint = http://127.0.0.1:9001

3. Créez un jeu de données de trois fichiers, puis déposez-le dans le stockage d'origine :

   mkdir -p jeu
   for i in 1 2 3; do head -c 200000 /dev/urandom > "jeu/fichier-$i.bin"; done
   rclone mkdir source:donnees
   rclone mkdir cible:donnees
   rclone copy jeu source:donnees

4. Exécutez la sortie : copiez le bucket d'origine vers le bucket d'arrivée.

   rclone copy source:donnees cible:donnees

   La commande ne produit aucune sortie en cas de succès : elle ne prouve rien tant que la vérification n'a pas eu lieu.

Comment vérifier que la copie est identique ?

La preuve se fait sur les octets reçus, pas sur le compte rendu de l'outil de copie. Téléchargez le contenu de chaque stockage dans un répertoire local, calculez une empreinte sha256 par fichier, puis comparez les deux listes. Deux fichiers qui ont la même empreinte ont, à toutes fins pratiques, le même contenu ; une empreinte qui diffère signale une copie corrompue ou incomplète.

mkdir -p dl-source dl-cible
rclone copy source:donnees dl-source
rclone copy cible:donnees dl-cible
(cd dl-source && find . -type f -print0 | sort -z | xargs -0 sha256sum) > source.sha256
(cd dl-cible && find . -type f -print0 | sort -z | xargs -0 sha256sum) > cible.sha256
diff source.sha256 cible.sha256 && echo "COPIE IDENTIQUE"

Le résultat attendu est le message COPIE IDENTIQUE, sans aucune ligne de diff avant lui. Si diff affiche des lignes, ouvrez les deux listes : une ligne présente d'un seul côté désigne un fichier manquant, une empreinte différente un fichier altéré.

rclone check (rclone check source:donnees cible:donnees) compare aussi les deux côtés, par tailles et par empreintes quand le stockage les fournit. Il ne remplace pas la preuve par sha256sum : cette dernière ne dépend ni de rclone ni du service qui a stocké l'objet. La différence a été constatée : avec RustFS 1.0.1, rclone check signale md5 differ (code retour 1) sur un objet dont un octet a été modifié ; avec l'ancienne image 1.0.0-alpha.83, il annonçait 0 differences found sur le même objet altéré, alors que sha256sum voyait l'écart.

Vérifiez que le contrôle sait échouer. Modifiez un octet d'une copie de jeu/fichier-2.bin, déposez-la dans la cible avec rclone copyto, puis supprimez dl-cible et relancez la vérification depuis mkdir -p dl-source dl-cible : diff affiche alors la ligne de fichier-2.bin des deux côtés avec deux empreintes différentes, et le message COPIE IDENTIQUE n'apparaît pas.

cp jeu/fichier-2.bin alteree.bin
printf 'X' | dd of=alteree.bin bs=1 seek=100 conv=notrunc
rclone copyto alteree.bin cible:donnees/fichier-2.bin

Relancer rclone copy source:donnees cible:donnees répare l'objet altéré (rclone compare les empreintes) et la vérification repasse à COPIE IDENTIQUE. Seul sha256sum est indispensable pour la preuve : un autre client S3 peut télécharger les objets (par exemple curl --aws-sigv4), mais il faut bien un client S3 pour copier, et rclone est ici le plus court.

Pour tout supprimer en fin d'exercice, supprimez les deux conteneurs et leurs volumes anonymes avec docker rm -fv rustfs-source rustfs-cible (sans -v, l'image déclare /data comme volume et en laisse un par conteneur), puis les répertoires jeu, dl-source et dl-cible, les fichiers source.sha256, cible.sha256 et alteree.bin, et les deux remotes [source] et [cible] de ~/.config/rclone/rclone.conf.

Quelles erreurs rencontre-t-on à ce stade ?

Les échecs d'une sortie viennent presque toujours de ce que la copie n'a pas vu. Le tableau donne les symptômes de l'exercice et ceux d'une sortie réelle.

Symptôme	Cause probable	Que faire
rclone répond une erreur de connexion	le conteneur n'est pas démarré ou le port est occupé	docker ps pour vérifier, puis changer de port local
Une liste d'empreintes est vide	le répertoire téléchargé est vide : la copie vers le stockage d'origine a échoué	relancer l'étape 3 et lister avec rclone ls source:donnees
diff montre un fichier d'un seul côté	la copie s'est interrompue avant la fin	relancer rclone copy, qui ne recopie que les fichiers manquants
Les tailles diffèrent sur une sortie réelle	versions d'objets ou métadonnées non copiées	lister les versions côté source avant de comparer
La donnée copiée est illisible chez le fournisseur d'arrivée	elle était chiffrée par l'application avec une clé maîtresse restée dans le KMS de l'ancien fournisseur	la clé ne s'exporte pas et une clé régénérée serait une autre clé : déchiffrer puis rechiffrer avant la bascule

Glissez pour voir

Que contient un plan de sortie ?

Un plan de sortie est un document court qui rend la sortie répétable : qui fait quoi, dans quel ordre, avec quel critère pour s'arrêter. Sans lui, la grille et la copie restent des exercices ; avec lui, la sortie devient une procédure qu'une autre personne que vous peut exécuter. Il tient en une page et répond à sept questions.

Rubrique	Question à laquelle elle répond
Périmètre	Quelles données et quels services sortent, lesquels restent ?
Cible	Où arrivent-ils, dans quel format, avec quelles clés ?
Ordre	Qu'est-ce qui bascule en premier : données froides, puis applications, puis données vives ?
Coût et durée	Quelles valeurs de la grille chiffrée, avec quelles hypothèses datées ?
Preuve	Quelle empreinte, quel comptage, quelle vérification fonctionnelle valident chaque étape ?
Critère d'arrêt	À partir de quel écart revient-on en arrière, et comment ?
Fin de vie	Comment prouve-t-on que les données sont effacées chez l'ancien fournisseur ?

Glissez pour voir

Répétez le plan sur un échantillon au moins une fois par an. Un plan jamais joué périme : les tarifs changent, un service propriétaire s'ajoute, la personne qui connaissait la procédure est partie. La répétition sur un échantillon coûte presque rien, et c'est la seule façon de faire apparaître l'écart entre le plan et le réel avant d'en avoir besoin.

Fixez le critère d'arrêt avant de commencer. Une sortie en cours, avec deux plateformes qui facturent, pousse à continuer même quand elle dérape. Écrire à l'avance « au-delà de tel écart d'empreintes ou de tel dépassement de durée, on stoppe et on revient en arrière » retire cette décision de la pression du moment.

Comment vérifier que vous savez le faire seul ?

Vous maîtrisez la leçon quand vous remplissez la grille pour deux fournisseurs et que vous prouvez une copie sans relire le pas-à-pas. Faites l'exercice suivant sans retourner aux étapes ci-dessus.

1. Choisissez deux fournisseurs et un jeu de 2 To de données fictives.
2. Pour chacun, relevez sur sa page tarifaire, avec la date, le tarif de sortie, la franchise, l'existence d'un dispositif de sortie et ses conditions, et la durée minimale à 1 Gbit/s ; écrivez le coût de sortie et la durée.
3. Rejouez sur votre poste une copie d'un jeu de cinq fichiers de taille différente vers un second stockage local, et prouvez par sha256sum que la copie est identique.
4. Écrivez en une page le plan de sortie du fournisseur le plus coûteux, avec ordre, critère d'arrêt et preuve de fin de vie.

Le critère de réussite est simple : un collègue exécute votre plan sans vous poser de question, et la dernière commande de la vérification affiche COPIE IDENTIQUE.

À retenir

• La réversibilité se mesure : ce que vous pouvez reprendre (portabilité), ce que cela coûte, le temps que cela prend.
• L'API compatible S3 rend un bucket portable ; un service propriétaire ne l'est que par du code d'export à écrire.
• La dépendance se réduit par l'abstraction, les standards ouverts et un multi-cloud sélectif, sans jamais disparaître ; elle se pèse contre le gain de temps qu'apporte un service propriétaire.
• Le coût d'une sortie se calcule en six lignes (volume, franchise, tarif, requêtes, double facturation, dispositif de sortie du fournisseur), toujours avec des valeurs datées relevées sur la grille du fournisseur. Le dispositif de sortie est un geste conditionnel qui se demande : le droit est le Data Act.
• La durée est le volume divisé par le débit utile, mesuré sur un échantillon, jamais par le débit nominal.
• La preuve d'une copie est une comparaison d'empreintes sha256 sur les octets téléchargés des deux côtés, pas le compte rendu de l'outil de copie.
• Le chiffrement côté serveur rend du clair à qui a les droits ; seule une donnée chiffrée par l'application, dont la clé maîtresse reste dans le KMS, sort illisible. Une clé de KMS ne s'exporte pas en clair (AWS, Google ; Azure : clé exportable avec attestation) : déchiffrer et rechiffrer avant la bascule.
• Un plan de sortie fixe l'ordre, la preuve et le critère d'arrêt, et se répète chaque année sur un échantillon.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →