Réversibilité, dépendance et plan de sortie

La réversibilité est la capacité d'une organisation à récupérer ses données et ses services pour les confier à un autre fournisseur, ou les ramener chez elle, dans des conditions de délai, de coût et de format prévues à l'avance. Son contraire est l'enfermement propriétaire (vendor lock-in) : une dépendance si forte qu'on ne peut plus partir. Ce chapitre décrit les formes de dépendance, ce que coûte un départ, ce que doit contenir une clause de réversibilité, comment limiter la dépendance dès la conception, et comment écrire puis tester un plan de sortie.

Les formes de dépendance

Toute dépendance n'est pas mauvaise. Une base managée ou un service serverless font gagner un temps considérable ; en échange, on accepte de dépendre du fournisseur. L'important est que la dépendance soit choisie et chiffrée, pas découverte le jour où l'on veut partir.

Ce que coûte un départ

• Le transfert des données : la plupart des fournisseurs facturent les données qui sortent de leur réseau. Pour un changement de fournisseur, la loi SREN limite ces frais aux coûts réels jusqu'au 12 janvier 2027, puis le Data Act interdit les frais de changement de fournisseur à partir de cette date (chapitre 4).
• Le double fonctionnement : pendant la bascule, on paie l'ancien et le nouveau fournisseur.
• Le travail d'adaptation : réécrire ce qui utilisait un service propriétaire, refaire l'automatisation, reconfigurer les droits.
• La formation de l'équipe au nouvel environnement.
• Le risque : une coupure ou une perte de données pendant la migration.

Le Data Act donne aussi des droits pendant le départ : un préavis de deux mois au plus pour lancer le changement, une période de transition de trente jours au plus, pendant laquelle l'ancien fournisseur doit aider au transfert, et l'export des données et des actifs numériques dans un format exploitable.

La clause de réversibilité

Un contrat de service cloud (ou d'infogérance, ou de SaaS) doit prévoir la sortie avant d'y entrer (cours CEJM : droit). Points à vérifier :

Récupérer ses données d'un SaaS

Avec un SaaS, la réversibilité porte surtout sur les données : le logiciel reste chez l'éditeur, et tu dois repartir avec tout ce que tu y as mis. Avant de signer, vérifie trois points :

• L'export existe et il est complet : toutes les données, avec les pièces jointes, l'historique, les commentaires, les comptes et leurs droits, et pas seulement un tableau des enregistrements principaux.
• Le format est exploitable : CSV ou JSON documentés, fichiers d'origine pour les documents. Un export PDF se lit, mais ne se réimporte pas.
• L'export est accessible sans l'éditeur : depuis l'interface d'administration ou par une API, sans devoir ouvrir une demande payante.

Limiter la dépendance dès la conception

• Des standards plutôt que des formats maison. Une base MySQL managée reste du MySQL : un mysqldump se relit partout. Une image de conteneur tourne sur Container Apps, sur Kubernetes, sur un hôte Docker du siège (cours Docker).
• Attention au stockage objet. La plupart des fournisseurs (AWS, Google Cloud, OVHcloud, Scaleway) parlent l'API S3. Azure Blob Storage a la sienne : une application écrite pour Blob Storage devra changer de bibliothèque pour partir. Des outils comme AzCopy ou le logiciel libre rclone copient d'un stockage à l'autre.
• De l'infrastructure décrite dans du code. Terraform et OpenTofu décrivent l'infrastructure de plusieurs fournisseurs avec le même langage ; les ressources changent de nom, mais la méthode et l'outillage restent.
• Une couche d'accès dans l'application. Le code métier appelle un module « stockage des documents », qui seul parle à Blob Storage : changer de fournisseur ne touche qu'à ce module (cours MVC).
• Des exports réguliers hors du fournisseur : ils servent à la fois de sauvegarde (chapitre 13) et de répétition de la sortie.
• Une documentation à jour de l'architecture et des flux (cours Documentation technique).

Le plan de sortie

Le plan de sortie est le document qui dit comment quitter le fournisseur : il se rédige au début du projet, se met à jour à chaque évolution et se teste. Pour l'application de suivi des livraisons de Sorbier :

Exercices

Exercice 1 sur 4 Mesurer la dépendance Réussi À revoir

Pour chaque élément, estime la dépendance au fournisseur (faible, moyenne, forte) et justifie.

1. L'API du parc, livrée en image Docker, déployée sur Container Apps.
2. La base MySQL 8.4 managée.
3. 200 Go de bons de livraison dans Blob Storage, lus par l'application avec la bibliothèque @azure/storage-blob.
4. Un traitement écrit pour Azure Functions, déclenché par l'arrivée d'un fichier dans Blob Storage, qui écrit dans Cosmos DB.
5. La réservation de trois ans d'une VM, achetée il y a six mois.

Voir la réponseMasquer la réponse de l'exercice 1

1. Faible : l'image est un standard (OCI) qui tourne sur tout hôte de conteneurs ; seule la configuration de Container Apps est à refaire.
2. Faible : MySQL standard, exportable avec mysqldump et relisible par n'importe quel serveur MySQL.
3. Moyenne : les données se copient facilement (200 Go, rclone, AzCopy), mais le code de l'application utilise l'API de Blob Storage, qui n'est pas l'API S3 : le module d'accès est à adapter.
4. Forte : déclencheurs, modèle de programmation et base de données propriétaires ; le traitement est à réécrire.
5. Forte, mais temporaire : contractuelle, elle dure encore deux ans et demi. Les réservations peuvent parfois être échangées ou annulées sous conditions : lis-les avant de t'engager.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 4 Rédiger les exigences de réversibilité Réussi À revoir

Sorbier va signer avec un éditeur un contrat SaaS de gestion des tournées de livraison. Rédige cinq exigences de réversibilité à faire figurer dans le contrat.

Voir la réponseMasquer la réponse de l'exercice 2

Par exemple :

1. « Le prestataire fournit, à tout moment et sans frais, un export complet des données (tournées, clients, adresses, historiques, pièces jointes) aux formats CSV et JSON, accompagné de la description des champs. »
2. « En fin de contrat, le prestataire assure une phase de réversibilité de trente jours, pendant laquelle le service reste accessible et le prestataire assiste Sorbier et son nouveau prestataire. »
3. « Le préavis de résiliation ne dépasse pas deux mois. »
4. « Après restitution, le prestataire supprime toutes les copies des données, y compris les sauvegardes, dans un délai de trente jours, et fournit une attestation de suppression. »
5. « Le prestataire met à disposition une interface de programmation (API) documentée permettant d'extraire les données, sans surcoût. »

On peut ajouter le lieu d'hébergement, la conservation du service pendant la transition, et le prix des prestations d'assistance au-delà de la période prévue.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 Vrai ou faux Réussi À revoir

1. Un SaaS qui permet d'exporter les données en PDF garantit la réversibilité.
2. Le droit à la portabilité du RGPD permet à Sorbier de récupérer toutes ses données chez un éditeur SaaS.
3. Utiliser une base MySQL managée crée moins de dépendance qu'une base propriétaire du fournisseur.
4. Un plan de sortie se rédige le jour où l'on décide de partir.
5. Toute dépendance à un fournisseur cloud est une erreur de conception.

Voir la réponseMasquer la réponse de l'exercice 3

1. Faux : un PDF se lit, mais ne se réimporte pas dans un autre logiciel. La réversibilité exige des formats exploitables (CSV, JSON documentés, fichiers d'origine) et un export complet.
2. Faux : l'article 20 du RGPD donne ce droit aux personnes sur leurs propres données. Pour l'entreprise cliente, ce sont le contrat, la loi SREN et le Data Act qui organisent la restitution.
3. Vrai : MySQL est un standard ; un mysqldump se relit sur n'importe quel serveur MySQL.
4. Faux : il se rédige au début du projet, se met à jour et se teste. Le jour du départ, il est trop tard pour découvrir qu'un export est incomplet.
5. Faux : une dépendance peut être un bon choix si elle fait gagner du temps ou de la fiabilité, à condition d'être choisie, chiffrée et documentée.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Ordonner la bascule Réussi À revoir

Remets dans l'ordre les étapes de la sortie d'Azure de l'application de suivi des livraisons vers le cluster Proxmox du siège : (a) basculer l'enregistrement DNS vers la nouvelle adresse ; (b) demander à Microsoft la suppression des données et une attestation ; (c) baisser la durée de vie (TTL) de l'enregistrement DNS à 5 minutes ; (d) copier une dernière fois la base et les bons de livraison ; (e) déployer l'image Docker et restaurer une copie récente des données sur la cible, et tester ; (f) mettre l'application Azure en lecture seule (figer les écritures) ; (g) vérifier le fonctionnement sur la cible, garder l'ancien environnement une semaine.

Voir la réponseMasquer la réponse de l'exercice 4

c, e, f, d, a, g, b.

1. (c) Baisser le TTL quelques jours avant : les résolveurs oublieront vite l'ancienne adresse au moment de la bascule.
2. (e) Préparer la cible avec une copie récente et tester sans toucher à la production.
3. (f) Figer les écritures, pour qu'aucune donnée ne soit créée pendant la copie finale.
4. (d) Faire la copie finale, qui est courte puisque la cible a déjà presque tout.
5. (a) Basculer le DNS.
6. (g) Vérifier, et garder l'ancien environnement le temps d'être sûr de ne pas revenir en arrière.
7. (b) Seulement à la fin, demander la suppression des données et l'attestation, puis résilier.

Tu avais trouvé ?

Oui, j'avais bonPas encore