Par Pascal Chevallot, avec l’appui de son harnais d’IA
8 août 2026

Le droit européen facilite désormais le changement de fournisseur cloud. Mais une clause de réversibilité ne garantit pas que la collectivité saura réutiliser ce qu’elle récupère. Avant de signer ou de renouveler, il faut essayer de sortir.

La clause de réversibilité est sans doute l’une des dispositions les plus rassurantes et les moins testées des contrats cloud des collectivités. On la signe, on la range, on la retrouve au moment du renouvellement, et l’on se dit que le jour où il faudra partir, elle sera là.

Le droit a pourtant beaucoup bougé, plutôt en faveur du client qui veut changer de fournisseur. Le règlement (UE) 2023/2854, dit Data Act, s’applique depuis le 12 septembre 2025. Son chapitre VI oblige les fournisseurs de services de traitement de données à supprimer les obstacles commerciaux, techniques, contractuels et organisationnels qui empêchent le changement de fournisseur. Pour les services concernés, il impose notamment des interfaces ouvertes et l’export des données exportables dans un format couramment utilisé et lisible par machine. À compter du 12 janvier 2027, les fournisseurs ne pourront plus facturer de frais de changement au client pour le processus de bascule. Le règlement prévoit toutefois des règles différentes selon la nature du service et certaines exceptions, notamment pour des services largement développés sur mesure.

Pour les marchés qui se réfèrent expressément au CCAG-TIC approuvé par l’arrêté du 30 mars 2021, l’article 38 traite déjà du transfert de connaissances et de la réversibilité. Cette référence ne dispense pas de décrire, dans les documents particuliers du marché, les opérations attendues, leur calendrier, les formats, les responsabilités et les coûts. Un intitulé dans un cahier général n’exécute aucune migration.

Dans un autre registre, la doctrine d’achat numérique présentée par l’État le 6 février 2026 insiste sur la sobriété, le recours prioritaire aux solutions déjà disponibles, la résilience et l’hébergement adapté des données sensibles. Elle vise les administrations de l’État, pas directement les collectivités, et ne crée pas une garantie supplémentaire de réversibilité. Elle rappelle cependant qu’un choix d’hébergement ne peut pas être séparé de la sensibilité des données et de la continuité du service.

Autrement dit, le droit facilite la sortie. Il ne dit pas que la collectivité saura se servir de ce qu’elle récupérera.

C’est là que le bât blesse. Quitter un logiciel hébergé ne se réduit pas à télécharger un fichier. C’est déménager un service : des bases de données, des documents, mais aussi des paramétrages, des automatisations, des métadonnées, des historiques, des droits d’accès, et parfois des dossiers d’usagers dont la collectivité reste responsable. Une clause qui promet une restitution sans définir les formats, la volumétrie, le calendrier ni l’usage futur ne garantit rien d’utilisable. Un export, ce n’est pas encore une sortie. C’est parfois un tas de caisses dans un couloir : tout semble là, rien n’est en place.

La collectivité n’est d’ailleurs pas toujours dans la même position. Parfois elle achète un service, comme un outil de gestion des actes ou un SIRH, et la question est de savoir si elle peut partir. Parfois elle demeure responsable de traitements portant sur des données personnelles et doit articuler la sortie avec le RGPD, les durées de conservation et les règles d’archivage applicables. Parfois elle partage un système mutualisé avec d’autres collectivités ou un syndicat mixte, et la décision se prend à plusieurs, en préservant la continuité du service rendu aux autres membres. Vouloir une seule clause pour ces trois situations, c’est préparer trois déceptions.

L’essai de restitution

Il existe pourtant une discipline simple, que les services techniques connaissent bien : on ne découvre pas l’évacuation d’un bâtiment le jour de l’incendie, on l’exerce. La sortie d’un cloud mérite le même traitement. L’essai de restitution suit six étapes, chacune produisant une trace vérifiable :

1. Inventorier ce qui doit revenir. Bases, fichiers, paramétrages, historiques, archives, métadonnées, droits et documentation utile.
2. Définir les formats et les critères d’acceptation. Des formats documentés, réutilisables et adaptés à la cible, pas seulement un export dont personne ne connaît la structure.
3. Lancer un export réel. Complet ou sur un échantillon représentatif, dans les conditions ordinaires du service et avec un chronométrage.
4. Contrôler la restitution. Complétude, intégrité, cohérence, lisibilité, métadonnées et journal des anomalies.
5. Tenter une réimportation. Dans un autre outil ou un environnement de reprise. C’est là que l’on distingue un fichier livré d’une sortie praticable.
6. Rédiger un procès-verbal contradictoire et décider. Écarts, responsabilités, délais de correction, sanctions éventuelles et conséquence sur le renouvellement.

La preuve attendue n’est donc pas l’existence de la clause, mais un export contrôlé, une reprise tentée et une décision tracée.

Ce protocole a un coût, en temps et en compétence. Il doit être prévu dès le contrat et budgété comme un exercice de sécurité. Certains marchés peuvent prévoir un export périodique et un essai de reprise : la collectivité vérifie alors régulièrement qu’elle pourrait partir, avant qu’un incident, un désaccord ou une urgence ne lui impose de le découvrir.

Cette logique prolonge une question déjà posée à propos des infrastructures locales : une réversibilité contractuelle reste théorique tant que la sortie n’a pas été éprouvée.

Quand la réversibilité n’est pas la réponse

Il faut pourtant résister à la tentation d’en faire une fin en soi. Pour certaines données, la bonne réponse est parfois de ne pas entrer : tout service n’a pas vocation à être externalisé. À l’inverse, lorsque les durées de conservation et les règles d’archivage le permettent, certaines données appellent une destruction maîtrisée plutôt qu’une restitution indéfinie. Pour certains outils, une dépendance bornée peut être assumée si elle est comprise, limitée dans le temps et compensée par un scénario de continuité réaliste.

Le cadre européen lui-même peut encore évoluer. Le paquet « Digital Omnibus » présenté par la Commission le 19 novembre 2025 est une proposition de modification du corpus numérique, pas le droit applicable à lui seul. Une stratégie de sortie ne doit donc reposer ni sur une clause isolée ni sur l’idée qu’un texte réglera toute la difficulté technique.

Avant de signer ou de renouveler, quelques questions se posent, et elles valent pour la DGS, la DSI et le service achats : quelles données et quels actifs numériques quitteront réellement le service, sous quel format, en combien de temps, pour quel coût ? Qui saura vérifier que ce qui est restitué est complet et réutilisable ? Dans quel environnement la reprise sera-t-elle tentée ? Et si l’essai de restitution figurait au contrat, à quelle fréquence serait-il exercé ?

Le droit a donné aux collectivités une occasion nouvelle : tester la sortie avant d’en avoir besoin. Ce serait dommage de la laisser passer au moment du renouvellement, sans avoir jamais essayé de partir.

Sources

• Union européenne, règlement (UE) 2023/2854 du 13 décembre 2023, dit Data Act, notamment chapitre VI et articles 23, 25, 26, 29 et 30.
• Commission européenne, « Data Act explained », chapitre VI sur le changement de fournisseur.
• État français, arrêté du 30 mars 2021 portant approbation du CCAG applicable aux marchés publics de techniques de l’information et de la communication, article 38.
• DINUM, « Achats publics numériques : l’État précise sa doctrine », 6 février 2026. Cette doctrine concerne les administrations de l’État.
• Commission européenne, « Digital Omnibus Regulation Proposal », 19 novembre 2025. Il s’agit d’une proposition.