Data Act : le cloud réversible devient un critère vert

Changer d’hébergeur ou de fournisseur cloud a longtemps été plus difficile qu’il n’y paraissait. Au-delà du transfert des fichiers, une migration peut impliquer les bases de données, les configurations réseau, les sauvegardes, les identités utilisateurs, les journaux techniques et les applications elles-mêmes. Cette complexité peut enfermer une organisation dans un environnement trop coûteux, surdimensionné ou peu transparent sur le plan environnemental.

Le Data Act, règlement européen sur les données, modifie progressivement ce cadre. Son chapitre consacré au changement de fournisseur vise à faciliter le passage d’un service de traitement de données à un autre, y compris entre fournisseurs de cloud. Son objectif premier est économique et concurrentiel : réduire les obstacles contractuels, techniques et financiers qui limitent la mobilité des clients. Mais cette évolution a aussi une conséquence pertinente pour le numérique responsable : un cloud réellement réversible permet de choisir, puis de quitter, une infrastructure dont les pratiques ne correspondent plus aux besoins ou aux exigences environnementales d’un projet.

La réversibilité ne rend pas un hébergement vert par elle-même. Elle donne toutefois un levier concret : celui de ne pas subir durablement un fournisseur incapable de documenter ses consommations, ses centres de données, son efficacité énergétique ou la fin de vie de ses équipements. Voici comment intégrer ce nouveau critère dans le choix d’un hébergeur.

Data Act : ce qui change pour la portabilité des services cloud

Le règlement (UE) 2023/2854, communément appelé Data Act, est entré en vigueur le 11 janvier 2024. La plupart de ses dispositions sont applicables depuis le 12 septembre 2025. Il couvre plusieurs sujets relatifs à l’accès et au partage des données ; l’un de ses volets concerne spécifiquement les services de traitement de données.

Dans ce contexte, les services visés comprennent notamment certaines offres de cloud computing. Le texte cherche à faciliter le passage :

d’un fournisseur de services de traitement de données vers un autre fournisseur ;
d’un service vers une infrastructure sur site appartenant au client ;
ou vers plusieurs destinations, selon les besoins de l’utilisateur.

Le règlement ne promet donc pas qu’une application pourra être déplacée en un clic. Il impose plutôt un cadre destiné à réduire les obstacles au changement, souvent désignés sous le terme de vendor lock-in ou dépendance fournisseur.

Un encadrement des clauses et des procédures de changement

Le Data Act prévoit que les fournisseurs suppriment les obstacles commerciaux, techniques, contractuels et organisationnels qui peuvent empêcher un client de changer de service. Les contrats doivent notamment préciser la procédure applicable au changement, les données concernées, les délais, ainsi que les éventuels frais.

Le texte fixe aussi des principes de calendrier. En règle générale, la période de préavis demandée au client ne doit pas excéder deux mois. La période de transition doit normalement être réalisée dans un délai maximal de 30 jours calendaires après la fin du préavis. Dans certains cas techniquement justifiés, ce délai peut être prolongé, dans des limites prévues par le règlement.

Ce point est important : une migration n’est pas seulement un export de données. Le fournisseur doit coopérer dans un processus qui peut inclure le transfert des actifs numériques, des données exportables et, selon le type de service, des informations utiles à la continuité du service.

La baisse progressive des frais de sortie

Les frais de migration et de sortie constituent un obstacle classique au changement de cloud, en particulier lorsque de grands volumes de données doivent être transférés. Le Data Act organise une suppression progressive de certains frais de changement. À compter du 12 janvier 2027, les fournisseurs ne devront plus imposer de frais de changement pour le processus couvert par le règlement.

Cette évolution ne signifie pas que tous les coûts techniques d’une migration disparaissent. Une entreprise peut toujours devoir financer l’accompagnement d’un prestataire, les tests, la refonte d’une architecture applicative ou la montée en compétence de ses équipes. En revanche, la réglementation limite la possibilité d’utiliser des frais de sortie comme mécanisme de captivité commerciale.

Ce que le Data Act ne garantit pas automatiquement

Il serait trompeur de présenter le Data Act comme une garantie de portabilité universelle. La réversibilité dépend toujours du type de service utilisé, de l’architecture technique et du niveau de dépendance construit au fil du temps.

Un site WordPress hébergé sur une offre mutualisée peut généralement être migré avec ses fichiers, sa base de données et ses paramètres DNS. À l’inverse, une application conçue autour de services propriétaires de base de données, de messagerie, d’intelligence artificielle ou d’analyse de données peut nécessiter une adaptation profonde avant d’être exécutée ailleurs.

Le règlement distingue notamment les services dont les fonctionnalités sont comparables. Pour certaines catégories, dont les infrastructures, plateformes et logiciels proposés comme services, il prévoit des obligations relatives à l’équivalence fonctionnelle lors du changement. Mais l’équivalence fonctionnelle ne veut pas dire identité parfaite : un nouveau fournisseur n’est pas tenu de reproduire à l’identique toutes les technologies propriétaires ou tous les comportements spécifiques d’une offre précédente.

La bonne question n’est donc pas seulement « Puis-je récupérer mes données ? », mais aussi « Puis-je refaire fonctionner mon service avec un niveau de sécurité, de performance et de continuité acceptable chez un autre fournisseur ? »

Cette nuance est centrale pour une démarche écologique. Exporter plusieurs téraoctets de données sans pouvoir les exploiter utilement ailleurs ne constitue pas une réversibilité opérationnelle. De même, une organisation peut récupérer ses données tout en restant prisonnière d’API, de formats, de mécanismes d’automatisation ou d’outils de supervision exclusifs.

Pourquoi la dépendance à un fournisseur peut alourdir l’empreinte numérique

La dépendance à un fournisseur n’a pas automatiquement une conséquence environnementale négative. Certains grands acteurs du cloud publient des informations détaillées sur leurs engagements climatiques et disposent d’importantes capacités d’optimisation. Mais l’absence de possibilité crédible de sortie peut empêcher un client de corriger des choix techniques devenus inefficients.

Lorsqu’une migration paraît trop risquée ou trop chère, une organisation peut conserver plus longtemps que nécessaire :

des instances de calcul surdimensionnées ;
des environnements de test ou de préproduction oubliés ;
des copies de sauvegarde redondantes et insuffisamment gouvernées ;
des données peu ou jamais consultées sur des niveaux de stockage coûteux en ressources ;
des architectures multipliant les transferts entre services ;
des applications difficiles à faire évoluer sans recourir à davantage de puissance de calcul.

Le problème n’est pas propre au cloud. Il concerne aussi les infrastructures sur site. Cependant, les modèles de consommation à la demande peuvent masquer l’accumulation progressive des ressources : une machine virtuelle créée pour un test, un stockage objet associé à un ancien projet ou une réplication de base de données peuvent continuer à mobiliser des capacités tant qu’aucune gouvernance ne les identifie.

Un hébergeur transparent permet au client de mieux comprendre son environnement. Mais si ce client ne peut pas changer de prestataire dans des conditions réalistes, cette transparence reste sans véritable pouvoir de négociation. La possibilité de sortir renforce donc la capacité à exiger des informations sur l’énergie, l’eau, les équipements, le taux d’utilisation ou les émissions associées à un service.

Pour aller plus loin sur l’évaluation des fournisseurs, consultez notre guide sur les critères à vérifier pour un hébergement web écologique et notre dossier consacré à l’importance du scope 3 chez les hébergeurs.

Réversibilité, interopérabilité et sobriété : le lien concret

La sobriété numérique consiste notamment à ajuster les ressources aux usages réels, à allonger la durée de vie des équipements et à éviter les traitements ou stockages inutiles. La réversibilité ne réduit pas directement la consommation électrique d’un serveur. Son impact est indirect, mais tangible : elle rend possibles des arbitrages que la captivité technique décourage.

Redimensionner ou consolider une infrastructure

Une organisation peut constater que son architecture est durablement surdimensionnée. Elle peut alors envisager une offre plus adaptée : serveur mutualisé plutôt que machine dédiée, capacité de calcul moindre, stockage archivé, consolidation de plusieurs services ou hébergement dans une région plus cohérente avec ses contraintes.

Sans portabilité, ce changement peut être reporté indéfiniment. Avec des exports documentés, des formats ouverts et une assistance de migration clairement définie, il devient plus réaliste de comparer les options et de déplacer le service lorsque cela est pertinent.

Éviter les migrations « tout reconstruire »

Une migration difficile entraîne souvent une stratégie coûteuse : maintenir l’ancien environnement en parallèle du nouveau pendant une longue période, recréer des pipelines, dupliquer des jeux de données et multiplier les tests. Ces opérations sont parfois nécessaires pour préserver la disponibilité, mais une préparation insuffisante augmente leur durée et leur volume.

La réversibilité favorise au contraire une architecture plus lisible : inventaire des données, dépendances connues, procédures d’export testées et séparation entre les composants standards et les briques propriétaires. Ce travail améliore à la fois la résilience, la maîtrise des coûts et la capacité à réduire les ressources inutiles.

Choisir un fournisseur plus transparent

Un client souhaitant intégrer des critères environnementaux doit pouvoir comparer des éléments concrets : localisation des centres de données, politique énergétique, indicateurs publiés, gestion du matériel, refroidissement, reporting et engagements vérifiables. Le Data Act ne crée pas à lui seul une obligation générale de publication environnementale pour tous les hébergeurs. Il réduit néanmoins un frein essentiel : la peur de rester bloqué après avoir choisi un fournisseur peu transparent.

Cette logique complète les autres critères de sélection. Un PUE faible, par exemple, peut être utile, mais il ne suffit pas à décrire l’impact global d’un service. Notre analyse explique pourquoi le PUE ne suffit pas à comparer les hébergeurs.

Les éléments techniques qui rendent un cloud réellement réversible

La conformité réglementaire est indispensable, mais l’expérience de migration se joue dans les détails techniques. Une offre cloud devient réellement réversible lorsque le client peut récupérer ses actifs sans dépendre d’une interprétation opaque du fournisseur.

Avant de souscrire, recherchez notamment les éléments suivants :

Des formats d’export documentés pour les fichiers, bases de données, sauvegardes, journaux et métadonnées.
Des API documentées, avec une politique de versionnement et des mécanismes d’authentification clairs.
Des outils d’export en libre-service, plutôt qu’une procédure limitée à un ticket de support.
Une documentation d’architecture décrivant les composants déployés, les réseaux, les droits et les dépendances.
Une procédure de suppression précisant ce qui est effacé après le départ du client et selon quel calendrier.
Des garanties de récupération en cas de résiliation, d’incident ou de fermeture d’un compte.

Pour un site web classique, les éléments minimaux à pouvoir récupérer sont les fichiers de l’application, la base de données, les certificats ou leur procédure de renouvellement, les configurations essentielles, les boîtes e-mail lorsqu’elles sont incluses, ainsi que les sauvegardes. Pour une infrastructure plus complexe, l’export des configurations sous forme de code peut faire une différence majeure. Des outils comme Terraform ou OpenTofu, lorsqu’ils sont correctement utilisés, aident à décrire une infrastructure de manière reproductible. Ils ne suppriment pas toutes les dépendances, mais facilitent l’inventaire et la reconstruction.

Les questions à poser à un hébergeur avant de souscrire

Les conditions générales sont rarement suffisantes pour évaluer la réversibilité. Il faut demander des réponses précises, idéalement écrites, et vérifier si la documentation publique confirme les engagements commerciaux.

Questions sur l’export et le changement de fournisseur

Quels types de données, métadonnées et configurations puis-je exporter ?
Dans quels formats ces éléments sont-ils fournis ? Ces formats sont-ils documentés ?
Les exports sont-ils accessibles depuis l’interface d’administration ou nécessitent-ils une intervention du support ?
Quel est le délai habituel de mise à disposition d’un export complet ?
Quelle procédure appliquez-vous pour accompagner un changement de fournisseur au titre du Data Act ?
Quels frais peuvent s’appliquer pendant la période transitoire prévue par le règlement ?
Quelle assistance technique est incluse, et quelles prestations sont facturées séparément ?

Questions sur l’interopérabilité

Quels standards, protocoles et API utilisez-vous ?
Quelles fonctionnalités reposent sur des composants propriétaires difficiles à reproduire ailleurs ?
Existe-t-il des limites de débit, de volume ou de fréquence pour extraire les données ?
Les sauvegardes peuvent-elles être restaurées chez un autre prestataire, ou seulement dans votre propre environnement ?
Comment exporte-t-on les règles réseau, les identités, les droits d’accès et les journaux ?

Questions sur l’environnement et la transparence

Publiez-vous des informations sur la localisation des infrastructures utilisées pour mon service ?
Quels indicateurs environnementaux communiquez-vous, et à quel périmètre correspondent-ils ?
Pouvez-vous distinguer les données propres à votre infrastructure de simples certificats d’achat d’énergie renouvelable ?
Disposez-vous d’une politique sur le réemploi, la réparation ou le reconditionnement des serveurs ?
Quels outils fournissez-vous pour identifier les ressources inutilisées ou surdimensionnées ?

Ces questions ne visent pas à obtenir une promesse vague d’« hébergement vert ». Elles permettent d’évaluer deux choses complémentaires : la qualité environnementale des pratiques déclarées et votre capacité réelle à partir si ces pratiques ne sont pas documentées, ne correspondent plus à votre stratégie ou ne répondent pas à vos besoins.

Mettre en place une stratégie de sortie dès le début du projet

La meilleure migration est souvent celle qui a été anticipée avant même la mise en production. Une stratégie de sortie ne signifie pas prévoir un départ immédiat : elle consiste à éviter que les choix initiaux transforment un changement futur en projet de crise.

Quelques pratiques simples améliorent fortement la situation :

tenir un inventaire des services, des bases de données, des domaines et des comptes techniques ;
documenter les dépendances entre applications et services managés ;
séparer les données métiers des formats propriétaires lorsque cela est possible ;
tester périodiquement la restauration des sauvegardes ;
supprimer les environnements et données devenus inutiles ;
prévoir des revues régulières de dimensionnement ;
archiver les contrats, conditions tarifaires et procédures de sortie du fournisseur.

Pour un projet WordPress, un exercice utile consiste à réaliser une migration de test vers un environnement temporaire. Il permet de vérifier que les fichiers, la base de données, les médias, les redirections, les extensions et les sauvegardes sont bien récupérables. Pour une architecture cloud, une revue annuelle peut porter sur les volumes de stockage, les machines inactives, les sauvegardes obsolètes et les services gérés dont l’usage n’est plus justifié.

Cette discipline sert directement la sobriété : on ne peut pas ajuster ni déplacer ce que l’on ne connaît pas. Elle rejoint les recommandations présentées dans notre article sur le choix d’un hébergeur écologique.

Réversibilité : un critère vert à intégrer sans simplifier à l’excès

Le Data Act fait évoluer le rapport entre clients et fournisseurs de cloud en encadrant davantage le changement de prestataire. Cette avancée ne remplace ni une analyse des performances, ni une vérification des engagements climatiques, ni un travail de sobriété applicative. Elle ajoute toutefois un critère décisif : la liberté de sortir d’un environnement qui ne convient plus.

Pour un hébergement plus responsable, la réversibilité doit être envisagée avec la transparence environnementale, l’adéquation des ressources aux usages, la localisation des données, la sécurité et la qualité du support. Un fournisseur qui facilite l’export, documente ses interfaces et annonce clairement ses procédures de départ offre un signal plus crédible qu’une promesse générale d’écologie.

Avant votre prochaine souscription ou renouvellement, prenez le temps de demander le plan de sortie, de tester les mécanismes d’export et de comparer les informations environnementales disponibles. Cette vérification peut vous aider à choisir un hébergement à la fois performant, maîtrisable et plus cohérent avec une démarche de numérique responsable.