Réversibilité cloud : tester la sortie avant de signer

La réversibilité cloud est la capacité à quitter un fournisseur, passer à un autre service ou revenir vers une infrastructure interne sans perdre les données utiles ni interrompre durablement l’activité. Une clause qui promet un export ne suffit pas : il faut savoir ce qui sort, dans quel format, qui peut le reconstruire et comment la continuité sera protégée.

Le Data Act européen encadre désormais le changement de services de traitement de données, dont les offres IaaS, PaaS et SaaS. Il impose notamment des obligations contractuelles, d’assistance, d’information et de portabilité. À partir du 12 janvier 2027, les frais directement liés au processus de changement ne pourront plus être imposés au client.

Cette évolution ne rend pourtant aucune migration automatique. Le bon contrôle reste un test de sortie en huit preuves : périmètre, export, compréhension, reconstruction, dépendances, continuité, effacement et coût complet.

Qu’est-ce que la réversibilité cloud ?

La réversibilité ne consiste pas seulement à récupérer une archive. Elle permet à une entreprise de continuer son activité après la fin d’un service externalisé.

Trois familles de cloud doivent être distinguées :

• IaaS, lorsque l’entreprise loue surtout des serveurs, du réseau et des ressources d’infrastructure ;
• PaaS, lorsqu’elle utilise des services gérés pour développer ou exécuter ses applications, comme une base de données ou une plateforme de déploiement ;
• SaaS, lorsqu’elle consomme directement un logiciel géré par le fournisseur, par exemple un CRM, un ERP, un outil RH ou une plateforme documentaire.

Cette distinction change la sortie. Une infrastructure peut parfois être reproduite à partir de configurations, d’images et de données. Un SaaS contient aussi un modèle fonctionnel, des règles, des vues et des automatisations qui ne deviennent pas automatiquement portables parce que les lignes de données le sont.

La page de référence de l’Arcep sur le cloud, mise à jour en juillet 2026, rappelle que le Data Act s’applique depuis le 12 septembre 2025 et couvre ces trois catégories. Le périmètre exact et les exceptions doivent toutefois être vérifiés pour le service et le contrat concernés.

Ce que le Data Act change pour un changement de fournisseur

Le chapitre VI du règlement européen sur les données vise les obstacles commerciaux, contractuels, techniques et organisationnels qui empêchent un client de changer de service de traitement de données.

Le contrat doit notamment préciser :

• les catégories de données et d’actifs numériques exportables ;
• les exclusions liées au fonctionnement interne du fournisseur ;
• les méthodes, formats, restrictions et limites techniques connus ;
• un préavis qui ne dépasse pas deux mois pour lancer le changement ;
• une période transitoire normalement limitée à trente jours calendaires, sauf impossibilité technique motivée ;
• une période minimale de récupération des données après la transition ;
• les conditions d’assistance, de continuité, de sécurité et d’effacement ;
• les frais encore applicables pendant la période transitoire prévue par le règlement.

Le fournisseur d’origine doit extraire les données dans un format lisible par machine. Le client et le fournisseur de destination restent responsables de leur chargement dans le nouvel environnement. Cette répartition explique pourquoi un droit à l’export ne vaut pas preuve de reprise.

Les lignes directrices de l’Arcep du 2 juillet 2026 précisent aussi la différence entre les actions requises pour faciliter le changement et les prestations supplémentaires d’accompagnement à la migration. Ces dernières peuvent rester facturées lorsqu’elles sont demandées par le client et acceptées à l’avance.

Autrement dit, la disparition des frais de changement à partir du 12 janvier 2027 ne signifie ni migration gratuite, ni absence de travail interne, ni équivalence immédiate entre deux logiciels.

Pourquoi un export de données ne suffit pas

Un fichier peut être techniquement ouvert et rester inutilisable.

Imaginez un CRM exporté en CSV. Les contacts et entreprises sont présents, mais les relations entre eux reposent sur des identifiants non documentés. Les pièces jointes se trouvent dans une archive séparée. Les historiques d’activité utilisent un fuseau horaire inconnu. Les consentements, rôles, automatisations et règles de dédoublonnage n’apparaissent pas.

L’entreprise possède des fichiers. Elle n’a pas encore récupéré son service.

Une sortie complète doit distinguer quatre niveaux :

1. les données, comme les enregistrements, fichiers, historiques et métadonnées ;
2. la structure, comme les schémas, relations, identifiants et règles de validation ;
3. le comportement, comme les automatisations, permissions, alertes et intégrations ;
4. l’exploitation, comme les comptes, secrets, journaux, procédures et responsabilités.

Le Data Act protège les données exportables et certains actifs numériques. Il n’oblige pas un fournisseur à transférer ses secrets d’affaires, sa propriété intellectuelle ou une copie autonome de son produit. Pour un SaaS, la reprise fonctionnelle dépend donc souvent d’un travail de configuration, de transformation et de recette chez le service de destination.

Le guide numérique 2026 de France Num recommande d’anticiper formats, coûts, applications et modalités de migration dès la contractualisation. La décision ne porte pas sur l’absence de dépendance. Elle porte sur une dépendance connue, proportionnée et testable.

La matrice de réversibilité en huit preuves

Cette matrice transforme le mot « réversibilité » en résultat observable. Une réponse écrite sans fichier témoin ou scénario rejouable reste une hypothèse.

Axe	Question à trancher	Preuve minimale	Échec révélateur
Périmètre	Quelles données, pièces jointes, configurations et traces doivent sortir ?	inventaire daté et catégories contractuelles	un actif critique n’a pas de propriétaire
Export	L’export peut-il être produit sans intervention exceptionnelle ?	fichier témoin complet et horodaté	l’export dépend d’un devis ou d’un compte inconnu
Compréhension	Une autre équipe peut-elle interpréter les champs et relations ?	schéma, dictionnaire et règles d’identification	les fichiers s’ouvrent mais restent ambigus
Reconstruction	Un échantillon peut-il être importé ou restauré ailleurs ?	compte rendu de reprise sur un environnement neutre	données présentes, service inutilisable
Dépendances	Quelles fonctions reposent encore sur le fournisseur ?	carte des API, identités, secrets, automatisations et licences	un connecteur invisible bloque le parcours
Continuité	Comment traiter les nouvelles opérations pendant la bascule ?	scénario de gel, synchronisation ou double fonctionnement	perte ou duplication entre deux dates
Fin de service	Quand les accès et copies sont-ils supprimés ?	procédure, délai, confirmation et conservation justifiée	données encore accessibles sans responsable
Coût et délai	Qui fait quoi, quand et à quel prix ?	chronologie, responsabilités et budget séparant changement et migration	« sortie incluse » sans charge ni échéance

Une seule ligne rouge peut suffire à modifier le choix. Si les pièces jointes et historiques sont nécessaires à une obligation métier, leur absence ne peut pas être compensée par un export parfait des seules fiches principales.

Consignez ces critères dans le modèle de cahier des charges Zence avant de comparer les offres. Le livrable attendu devient alors un fichier, une procédure ou un résultat de recette, pas le mot « réversible » dans une case.

Comment réaliser un test de sortie avant de signer

Le test n’a pas besoin de migrer toute l’entreprise. Il doit produire une preuve assez complète pour révéler les dépendances coûteuses.

1. Choisir un parcours représentatif

Sélectionnez une action qui traverse plusieurs couches du service : créer un client, joindre un document, déclencher une validation, conserver l’historique et transmettre le résultat à un autre outil.

Évitez le cas idéal composé d’une seule fiche sans relation. Il sous-estime précisément les éléments qui deviennent difficiles à reprendre.

2. Demander un export réel

Utilisez le mécanisme disponible pour un client normal. Notez le rôle requis, le délai, les formats, la taille, les catégories absentes et toute intervention manuelle du fournisseur.

Un exemple de documentation n’est pas une preuve. Le fichier doit provenir du service que vous évaluez, avec des données fictives ou correctement protégées.

3. Ouvrir et cartographier les fichiers

Reliez chaque colonne, identifiant et dossier à une information métier. Vérifiez les encodages, dates, relations, pièces jointes, versions, suppressions logiques, consentements et journaux nécessaires.

Une personne qui n’a pas configuré le service doit pouvoir comprendre la carte. Si tout repose sur la mémoire de l’administrateur actuel, documentez cette dépendance.

4. Reconstruire un échantillon

Importez quelques objets liés dans un environnement neutre, un tableur structuré ou la solution candidate. Rejouez l’action de départ et comparez le résultat.

L’objectif n’est pas de démontrer que deux outils sont identiques. Il est de savoir quelles transformations, pertes acceptables et configurations devront être financées.

5. Simuler la période de transition

Décidez ce qui arrive aux nouvelles données entre l’export initial et la bascule : gel des saisies, second export différentiel, double fonctionnement ou synchronisation temporaire.

Puis attribuez les erreurs possibles : doublon, pièce jointe manquante, identifiant changé, opération validée dans l’ancien outil après la coupure. La continuité se protège avant le jour de sortie.

6. Fermer la boucle

Le test se termine lorsque les comptes sont révoqués, les intégrations arrêtées, les secrets renouvelés, la facturation close et l’effacement confirmé selon le contrat et les règles applicables.

Lorsque des données personnelles sont traitées, la qualification des rôles reste distincte du Data Act. La CNIL rappelle comment qualifier client et fournisseur cloud selon les finalités et moyens réellement décidés. Faites relire les engagements de restitution, conservation et suppression par les personnes compétentes.

SaaS, PaaS et IaaS : le résultat attendu n’est pas le même

Le Data Act prévoit une recherche d’équivalence fonctionnelle pour les services d’infrastructure du même type. Cette notion ne doit pas être étendue par réflexe à chaque SaaS.

Service quitté	Ce que le client doit surtout récupérer	Travail probable à destination
IaaS	machines, volumes, réseaux, configurations, images, journaux et données	adapter l’infrastructure et vérifier une équivalence fonctionnelle raisonnable
PaaS	données, schémas, configurations, code, événements et dépendances gérées	remplacer les services propriétaires et revalider performance, sécurité et exploitation
SaaS	données métier, fichiers, historiques, identités, règles exportables et preuves	reconfigurer les parcours, rôles, automatisations et intégrations dans un autre produit

Cette distinction évite deux promesses fragiles. Le fournisseur ne doit pas annoncer qu’un simple fichier recrée le produit. Le client ne doit pas exiger que chaque fonction propriétaire soit reproduite gratuitement par le service de destination.

Les clauses contractuelles types publiées par la Commission européenne proposent des blocs consacrés au changement et à la sortie, à la résiliation, ainsi qu’à la sécurité et la continuité. Leur usage est volontaire. Elles offrent une base de discussion, pas une validation automatique du contrat ni du scénario technique.

Quand le sur-mesure améliore-t-il vraiment la réversibilité ?

Un développement sur mesure peut donner davantage de contrôle sur le code, le modèle de données et les procédures. Il ne garantit pas la réversibilité si le dépôt, l’infrastructure, les secrets et la documentation restent détenus par une seule personne.

À l’inverse, un SaaS standard peut constituer le meilleur choix pour une fonction courante si l’export, le coût, la continuité et la reprise sont acceptables. Reconstruire un outil de paie, de visioconférence ou de signature uniquement pour « tout posséder » ajouterait une complexité difficile à justifier.

La bonne décision consiste à faire payer son loyer à chaque dépendance. Une brique spécialisée peut accélérer le projet et améliorer le service. Elle doit en retour rendre sa limite, son coût de sortie et son remplacement compréhensibles.

Une dépendance invisible augmente aussi le coût du prochain changement. La documenter ne supprime pas ce coût ; elle permet de le comparer au bénéfice réel de la brique avant de s’engager davantage.

Notre comparaison entre logiciel standard, no-code et sur mesure aide à choisir la trajectoire. Le guide sur la propriété et la réversibilité d’un site web reste propriétaire des domaines, comptes, code, contenus et livrables d’un site. Ici, la question est plus étroite : comment quitter un service cloud et prouver que l’activité peut reprendre ailleurs.

Quelle première action prendre ?

Choisissez aujourd’hui un service qui porte une opération importante : CRM, stockage documentaire, base de données gérée, outil RH ou plateforme métier. Créez un cas fictif avec une relation, une pièce jointe, un historique et une automatisation. Exportez-le, ouvrez les fichiers et tentez de le reconstruire hors du service.

Le premier élément impossible à expliquer devient votre prochain travail : clause à préciser, format à documenter, intégration à découpler, procédure à tester ou coût à chiffrer.

Zence conçoit et fait évoluer des logiciels métier sur mesure en gardant les décisions, les données et le coût du changement visibles. Une stratégie de sortie n’oblige pas à partir. Elle permet de choisir un fournisseur parce qu’il sert le produit, pas parce que la sortie reste inconnue.

Sources principales

• Arcep — L’informatique en nuage et les grandes dates de la régulation, mise à jour en juillet 2026
• Arcep — Lignes directrices sur les frais de changement de fournisseur cloud, 2 juillet 2026
• EUR-Lex — Règlement (UE) 2023/2854 sur les données
• Commission européenne — Clauses contractuelles types pour les contrats cloud, 19 novembre 2025
• CNIL — Qualifications des acteurs du cloud, 28 mai 2026
• France Num — Guide numérique des entreprises 2026