Sortie du cloud : anticiper la portabilité
La sortie du cloud n’est plus un sujet technique réservé aux DSI prudentes. Avec le Data Act et les lignes directrices publiées en 2026, la portabilité des données devient une exigence concrète, mesurable et négociable dès le contrat.
Pour une entreprise, l’enjeu dépasse le simple export de fichiers. Il touche la migration cloud, la reprise d’activité, la sécurité des données et la gestion des risques, surtout quand plusieurs services, applications et automatisations se croisent.
A retenir :
- Droit de changer sans verrouillage contractuel
- Export lisible, testable, documenté
- Continuité d’activité à préserver
- Interopérabilité à vérifier avant signature
- Coûts de migration à anticiper
Le cadre juridique de la sortie du cloud en 2026
Le passage d’un fournisseur à un autre s’inscrit désormais dans un cadre plus net, ce qui change la discussion dès l’achat. Selon l’Arcep, le Data Act s’applique depuis septembre 2025 aux services IaaS, PaaS et SaaS, avec des obligations précises sur le changement de service.
Dans la pratique, cela signifie que le contrat doit décrire les données exportables, les délais, les formats, l’assistance et la période transitoire. Selon les lignes directrices de l’Arcep du 2 juillet 2026, les frais liés au processus de changement ne peuvent plus être imposés à partir du 12 janvier 2027.
Cette évolution ne supprime pas l’effort interne, ni la préparation documentaire, ni les tests de reprise. Elle oblige surtout à distinguer ce qui relève du changement de fournisseur et ce qui relève d’une prestation de migration, souvent encore facturable si elle est demandée à part.
Un directeur informatique qui signe sans cartographier ces points découvre souvent trop tard que le contrat protège l’accès, mais pas la reconstruction complète du service. La suite logique consiste donc à vérifier ce que l’on peut réellement récupérer, et sous quelle forme.
IaaS, PaaS et SaaS : trois sorties très différentes
Ce point devient plus lisible quand on sépare les trois familles de services, car la logique de sortie n’est pas la même. Un IaaS restitue surtout des ressources techniques, alors qu’un SaaS embarque des règles métier, des vues, des automatisations et des dépendances plus délicates.
Selon France Num, la préparation dès la contractualisation reste la meilleure défense contre les coûts cachés et les blocages tardifs. Une PME qui remplace un outil RH ne cherche pas seulement des fichiers, mais aussi des historiques, des permissions et des parcours cohérents.
| Type de service | Ce qui compte vraiment | Effort de reprise | Risque principal |
|---|---|---|---|
| IaaS | Machines, réseaux, images, volumes | Reconstitution d’infrastructure | Configuration manquante |
| PaaS | Données, schémas, services gérés | Réécriture partielle | Dépendances propriétaires |
| SaaS | Données, règles, historiques, automatisations | Reparamétrage complet | Perte de contexte métier |
| Service hybride | Mélange d’exports et de fonctions intégrées | Analyse détaillée | Rupture silencieuse |
Une sortie bien préparée commence donc par la catégorie de service, puis par les actifs réels à récupérer. Cette lecture prépare l’étape suivante, beaucoup plus opérationnelle, où l’on mesure ce qu’un export permet vraiment de reconstruire.
Le contrat ne suffit pas sans preuve d’usage
Le cadre juridique pose un droit, mais un droit sans test reste théorique. La question utile est simple : un autre prestataire peut-il reprendre le service sans perdre l’activité, ni bloquer les équipes, ni casser les chaînes de travail ?
Selon l’Arcep, le fournisseur d’origine doit extraire les données dans un format lisible par machine, mais le client et le nouveau prestataire gardent la responsabilité du chargement. Cela explique pourquoi une clause d’export ne prouve jamais, à elle seule, la réussite d’une migration cloud.
Dans un environnement SaaS, un CSV propre peut masquer des relations invisibles, des identifiants mal documentés ou des automatisations critiques absentes. Une équipe qui découvre cela au dernier moment perd souvent plusieurs jours, parfois davantage, sur la reprise d’activité.
La vraie sécurité des données repose alors sur des preuves concrètes, pas sur un engagement vague. C’est précisément ce qui amène au test de sortie en huit preuves, plus exigeant qu’un simple export administratif.
Tester la portabilité des données avant de quitter un fournisseur
Après le droit et les responsabilités, vient le terrain. La portabilité des données ne se juge pas sur une promesse commerciale, mais sur un scénario rejouable, avec des données, des dépendances et un environnement de destination réalistes.
Un responsable IT peut avancer vite s’il choisit un cas représentatif, comme un client, une pièce jointe, une validation et un historique. Ce test révèle souvent l’écart entre un export “possible” et une vraie sortie du cloud.
La matrice des huit preuves
Cette méthode est utile parce qu’elle transforme une notion abstraite en contrôle concret. Selon le guide numérique 2026 de France Num, la réversibilité doit être pensée dès les formats, les coûts et les modalités de migration.
Dans une entreprise fictive, LinaSoft, un export complet du CRM semblait suffisant jusqu’au jour où les automatisations, les règles de dédoublonnage et les pièces jointes ont manqué à l’appel. Le tableau ci-dessous montre ce qu’il faut vérifier avant d’avancer.
| Axe | Ce qu’on vérifie | Preuve attendue | Signe d’alerte |
|---|---|---|---|
| Périmètre | Données, pièces jointes, traces | Inventaire daté | Actif critique oublié |
| Export | Fichier réellement produit | Extraction horodatée | Export manuel ou incertain |
| Compréhension | Lisibilité des champs et relations | Dictionnaire de données | Fichiers incompréhensibles |
| Reconstruction | Reprise dans un autre environnement | Import validé | Service inutilisable |
Ce type de grille évite les mauvaises surprises au moment du basculement. Il prépare aussi le test suivant, centré sur les dépendances invisibles qui rendent une migration cloud plus coûteuse qu’annoncé.
Les dépendances cachées qui bloquent une reprise d’activité
La sortie réelle ne se joue pas seulement sur les enregistrements, mais sur tout ce qui entoure le service. Identités, secrets, API, journaux, licences et automatisations forment souvent le vrai nœud du problème.
Lors d’une mission de reprise d’activité, un export impeccable peut rester inutilisable si le fuseau horaire, les règles d’accès ou les alertes métier n’ont pas été documentés. Selon la Commission européenne, les clauses types pour le cloud peuvent aider, mais elles ne remplacent pas une vérification technique complète.
C’est ici que l’interopérabilité devient un critère de choix, presque au même titre que le prix. Un service ouvert, bien documenté et testable réduit la tension entre optimisation IT et liberté de changement.
Quand une équipe relie ces dépendances à un plan de continuité, elle voit enfin le coût réel d’un verrouillage fournisseur. Le dernier angle consiste alors à arbitrer le bon niveau de contrôle, sans tomber dans le réflexe du tout-sur-mesure.
Construire une stratégie cloud qui protège la liberté de choix
Une fois les dépendances visibles, la décision d’architecture devient plus saine. L’objectif n’est pas de quitter tous les services, mais de garder la capacité de partir sans perte majeure ni délai bloquant.
Cette logique aide aussi les directions métiers, car elle relie la technologie à la continuité de service. Quand la gestion des risques est intégrée dès le départ, la stratégie cloud cesse d’être une dépendance subie.
Open source, sur mesure et logiciel standard : arbitrer sans se tromper
Le débat n’oppose pas un modèle idéal à un autre modèle défaillant. Il s’agit plutôt de savoir où placer les fonctions sensibles, et où accepter une dépendance maîtrisée.
Dans une PME, un logiciel standard peut très bien convenir pour la bureautique ou la visioconférence. En revanche, un cœur métier mal documenté peut justifier des briques open source ou sur mesure, à condition de garder la documentation et les accès sous contrôle.
| Option | Atout principal | Limite fréquente | Intérêt pour la sortie du cloud |
|---|---|---|---|
| Logiciel standard | Déploiement rapide | Moins de maîtrise | Variable selon l’export |
| Open source | Lisibilité technique | Intégration à maintenir | Bonne portabilité |
| Sur mesure | Contrôle fonctionnel | Coût de maintien | Très bon si bien documenté |
| No-code | Vitesse de création | Dépendances cachées | À tester avec prudence |
Cette grille aide à ne pas confondre propriété technique et liberté pratique. La suite logique est d’organiser la sortie comme un projet normal, avec des responsabilités claires et des preuves conservées.
Préparer un plan de continuité sans se raconter d’histoires
Un bon plan de continuité précise qui fait quoi, quand, et avec quels fichiers de référence. C’est le seul moyen d’éviter qu’une migration cloud se transforme en bricolage au fil de l’eau.
Un administrateur qui teste son export sur un cas simple découvre souvent ce qui manque avant la vraie bascule. Il peut alors corriger le contrat, adapter les formats, ou prévoir une phase de synchronisation mieux maîtrisée.
« J’ai compris que l’export ne valait rien sans dictionnaire de données et scénario de reprise. »
Marc L.
À ce stade, la portabilité devient un réflexe de pilotage, pas un sujet défensif. Et c’est souvent là que l’optimisation IT rejoint enfin la liberté de choix, au lieu de la contredire.
Source : Arcep, « L’informatique en nuage et les grandes dates de la régulation », 2026 ; Arcep, « Lignes directrices sur les frais de changement de fournisseur cloud », 2 juillet 2026 ; France Num, « Guide numérique des entreprises », 2026.
Transformer l’analyse en décision
Les meilleures décisions reposent sur un cadre compréhensible, quelques critères vérifiables et une étape suivante clairement définie. Testez la méthode à petite échelle, mesurez le résultat puis ajustez avant de généraliser.
Votre checklist
- Définir le résultat attendu
- Identifier trois critères prioritaires
- Prévoir une mesure de contrôle
- Fixer une date de réévaluation
