Le coût d'un système qui ne peut pas partir

Le coût d'un système qui ne peut pas partir

The door that exists only on paper

A contract can contain an exit clause and still be a one-way door. The clause may say that an organisation can export its data, move to another provider and receive reasonable assistance. It may even use the comforting word portability. Then somebody asks the practical question: what would we actually take with us on Monday morning?

The answer is rarely a folder of files. It is a working service, a set of identities, a collection of permissions, a history of decisions, a web of dependencies, a group of people who know how to operate it and an institution that has promised somebody else that the service will keep working. The data is part of the system. It is not the whole system. A neatly formatted export can leave the building while the meaning, timing and authority that made it useful remain behind.

This is why switching costs are not a finance problem that arrives after architecture. They are an architecture problem with a finance invoice attached. If an organisation cannot move a workload without losing semantics, continuity, security or the ability to make decisions, it does not own an exit route. It owns a dependency and has written a polite paragraph about it.

The European Data Act treats switching between data processing services as a matter of competition, interoperability and continuity. Its Chapter VI asks providers to remove technical, commercial, contractual and organisational obstacles. The European Commission explains the same ambition in plainer language: cloud and edge customers should be able to switch without losing data or application functionality. That is a useful floor. It is not a magic spell. The difference between a legal right and a usable exit is the work this article is about.

Portability has four meanings

People often use portability to mean that bytes can cross a boundary. A database dump exists. An object store can be copied. A virtual machine image can be downloaded. The export button is visible, and someone has taken a screenshot of it. That is one kind of portability, and it matters. It is also the easiest kind to overstate.

Portable bytes are useful only when the receiving system can interpret them. A record with an identifier, timestamp and status may look complete while its relationships, time zone, ordering rule, retention meaning and permission history live in a service that will not travel. An event can be exported while the policy that gave it significance stays in the old platform. A model can be exported while the tokenizer, prompt version, feature pipeline and evaluation set remain proprietary or undocumented. The file has left. The system has not.

There is semantic portability: the receiving service can understand what the exported objects mean. There is operational portability: people can run, secure, monitor, repair and restore the service in the new environment. There is institutional portability: the organisation can continue to meet its legal, contractual and public obligations while the change happens. These meanings overlap, but none can be substituted for another.

Consider a public archive that can export every document and still cannot reconstruct the access decisions that controlled who could see each document. Consider a hospital platform that can move patient records but cannot reproduce the alert path used by a clinical team. Consider an energy operator that can copy measurements but cannot preserve the time alignment between meters, forecasts and dispatch decisions. These are hypothetical examples, deliberately so. They describe classes of dependency, not incidents at named organisations.

Un plan de sortie sérieux précise quel type de portabilité est requis pour chaque partie du service. Il ne qualifie pas un système de portable parce qu’un ingénieur commercial peut produire un lien de téléchargement. La question est toujours : portable pour quel objectif, sous quelle exigence de continuité, avec quelles preuves et par qui.

Le Data Act fixe un plancher, pas une équipe de secours

Le chapitre VI du règlement (UE) 2023/2854 commence par une instruction d’un pragmatisme peu courant. Les fournisseurs de services de traitement de données doivent supprimer les obstacles précommerciaux, commerciaux, techniques, contractuels et organisationnels qui entravent le changement de fournisseur, le portage des données exportables et des actifs numériques, l’atteinte de l’équivalence fonctionnelle lorsque le règlement l’exige, ou l’utilisation simultanée de plusieurs fournisseurs. Cette liste est utile car elle refuse de prétendre qu’un format de fichier constitue l’unique obstacle.

L’article 25 exige que les droits de changement de fournisseur et les obligations des fournisseurs soient définis dans un contrat écrit que le client peut conserver et reproduire. La structure habituelle comprend un délai de préavis maximal de deux mois, une période transitoire obligatoire de 30 jours calendaires au plus après ce préavis, une assistance du fournisseur d’origine, la continuité des fonctions contractuelles et un niveau de sécurité élevé tout au long de la transition et de la période de récupération. Il exige également une spécification exhaustive des données exportables et des actifs numériques, une période de récupération d’au moins 30 jours calendaires et l’effacement après un changement réussi, sous réserve des conditions de l’article.

Les dates comptent. Pendant la transition allant du 11 janvier 2024 au 12 janvier 2027, les fournisseurs peuvent imposer des frais de changement réduits qui n’excèdent pas leurs coûts directement encourus. À compter du 12 janvier 2027, le règlement dispose que les frais de changement doivent disparaître. C’est un changement important dans l’économie d’une sortie. Cela ne rend pas une application étroitement couplée indépendante, et cela ne fournit pas non plus les ingénieurs, l’environnement de test ou le service de remplacement dont la migration a besoin.

L’article 26 ajoute une obligation d’information. Les clients doivent recevoir les procédures, méthodes, formats, restrictions et limitations techniques connues pour le changement de fournisseur, ainsi qu’une référence à un registre à jour décrivant les structures de données, les formats de données et les normes pertinentes ou les spécifications ouvertes d’interopérabilité. L’article 27 demande à toutes les parties, y compris le fournisseur de destination, de coopérer de bonne foi. Une destination qui ne peut pas recevoir les données n’est pas une destination utile, quelle que soit la raisonnabilité du fournisseur d’origine.

L’article 30 distingue les types de services. Les fournisseurs d’infrastructure sont invités à faciliter l’équivalence fonctionnelle pour les fonctions partagées lorsqu’un client passe à un service du même type. Les autres fournisseurs de services de traitement de données doivent mettre des interfaces ouvertes à la disposition des clients et des fournisseurs de destination et soutenir une exportation structurée, couramment utilisée et lisible par machine lorsque les normes pertinentes ne sont pas encore disponibles. Le règlement n’exige pas qu’un fournisseur divulgue des secrets commerciaux, invente une nouvelle technologie ou compromette la sécurité. Cette limite est raisonnable. Elle signifie aussi que le client doit comprendre ce qui est réellement exportable avant de signer.

Il existe des limites et des exceptions. Les services principalement sur mesure et les services de test hors production bénéficient d’un régime spécifique, et les fournisseurs doivent informer les clients potentiels des obligations de changement qui ne s’appliquent pas. Le plancher juridique contient donc son propre avertissement : lisez le champ d’application. Un service sur mesure peut être précisément là où une organisation a placé sa dépendance la plus lourde de conséquences. Une clause qui s’applique à un service de catalogue ne sauve pas automatiquement un arrangement sur mesure.

Le Data Act peut rendre une obligation de sortie visible, testable et plus difficile à entraver. Il ne peut pas décider si une organisation a documenté sa sémantique de domaine, conservé le personnel qui comprend la charge de travail, testé le chemin de restauration ou budgété une exécution en parallèle. La loi peut exiger une ouverture. Quelqu’un doit encore construire une porte de l’autre côté.

Les données sont la cargaison, pas le véhicule

L’explication du Data Act par la Commission identifie les données d’entrée, les données de sortie et les métadonnées générées par l’utilisation d’un service par un client comme étant au cœur de la commutation, sous réserve des limites de la propriété intellectuelle et des secrets commerciaux. C’est une définition utile, car les métadonnées portent souvent le contexte que l’on oublie de demander. Elles peuvent inclure des relations, des configurations, des horodatages, la lignée, l’état de conservation et des identifiants. Elles peuvent aussi être la première chose à disparaître lorsqu’une exportation a été conçue comme une fonctionnalité marketing plutôt que comme un chemin de récupération.

Imaginez exporter un ensemble d’éléments de travail. Le système récepteur possède les titres et les descriptions, mais pas la sémantique de file d’attente, les règles d’escalade, l’historique d’affectation ni les liens vers les preuves. L’exportation est techniquement exacte. L’organisation ne peut toujours pas expliquer pourquoi un dossier attendait, qui était autorisé à intervenir ou quelle règle était active à ce moment-là. Les pièces manquantes ne sont pas des champs décoratifs. Elles constituent le comportement du service.

Les métadonnées méritent la même attention de conception que le contenu principal. Un inventaire de migration devrait demander quels identifiants sont stables, lesquels sont locaux au fournisseur, quelles relations sont implicites, quels horodatages ont une horloge définie, quelles autorisations sont portables, quels artefacts dérivés appartiennent au client et lesquels sont des éléments internes du fournisseur. Il devrait consigner la signification d’une suppression, d’une mise en attente, d’une archive et d’une relecture. Sinon, l’équipe réceptrice reçoit un tas de noms et doit deviner les verbes.

Il y a une complication supplémentaire dans les systèmes d’IA. Une réponse peut dépendre d’un index de récupération, d’un modèle d’intégration, d’une invite, d’une version de politique, d’une autorisation d’outil, d’un cache et d’une décision humaine de publication. Exporter le texte final n’exporte pas les conditions dans lesquelles il a été produit. Un ensemble d’évaluation peut voyager alors que le tokeniseur ou les règles de normalisation ne le font pas. Un événement d’audit peut voyager alors que la clé qui vérifie sa signature est oubliée. Le résultat est un enregistrement qui se souvient de la réponse et a perdu la raison.

Rien de tout cela ne signifie que chaque intermédiaire transitoire doit être conservé pour toujours. La portabilité n’est pas une licence pour accumuler. Cela signifie décider quels artefacts sont nécessaires à l’objectif du déplacement, les préserver avec leur signification et indiquer ce qui ne peut pas être déplacé. Une limite honnête est plus sûre qu’une promesse vague. La pire exportation est celle qui semble complète jusqu’à ce que quelqu’un en dépende.

L’interopérabilité est une conversation

Un format de fichier est une phrase. L’interopérabilité est une conversation dans laquelle les deux systèmes s’accordent sur le sujet, le verbe, le moment et les conséquences. Les interfaces ouvertes aident parce qu’elles permettent à un autre système de parler au service sans deviner un dialecte privé. Elles ne garantissent pas, à elles seules, que les deux systèmes partagent un vocabulaire.

La politique cloud de la Commission européenne associe le passage à des normes ouvertes, des services cloud et de périphérie interopérables et un environnement européen commun des données. Sa description des orientations prévues sur les marchés publics de services de traitement de données est révélatrice : ces orientations devraient proposer des recommandations et des critères essentiels pour les appels d’offres. Autrement dit, l’acheteur public est invité à préciser les conditions dans lesquelles une sortie peut être exercée, et non à espérer que le marché s’en souvienne à sa place.

Les contrats sémantiques sont le point où l’interopérabilité devient concrète. Une organisation doit savoir si une valeur vide signifie inconnu, non applicable ou volontairement omis. Elle doit savoir si un horodatage enregistre l’occurrence, l’ingestion ou la publication. Elle doit savoir si une décision politique est définitive, provisoire ou en attente d’appel. Elle doit savoir si un identifiant survit à un déménagement ou n’est qu’une adresse dans l’ancienne base de données du fournisseur. Ces questions ne sont pas glamour. Elles font la différence entre une migration et un exercice de ressaisie.

L’équivalence fonctionnelle demande aussi de l’attention. La loi sur les données utilise cette notion pour les services d’infrastructure couvrant le même type de service et des fonctionnalités communes. Elle ne promet pas que deux fournisseurs auront des consoles, des modèles de tarification ou des architectures internes identiques. Une charge de travail peut produire des résultats matériellement comparables pour les fonctionnalités concernées tout en nécessitant une conception opérationnelle différente. C’est un objectif plus honnête que de prétendre que chaque cloud est une photocopieuse de tous les autres.

L’interopérabilité peut être testée avec un petit vocabulaire avant qu’une organisation ne s’engage dans une dépendance importante. Prenez un enregistrement représentatif, un changement d’autorisation, une erreur, une tâche planifiée et une correction. Faites-les passer par l’interface proposée. Demandez si la destination peut les valider, les interroger, les mettre à jour, les auditer et les supprimer sans réunion privée avec le fournisseur source. Si la réponse dépend d’une présentation, l’interface n’est pas encore un chemin. C’est une promesse avec une belle typographie.

Le verrouillage d’exécution se cache derrière l’exportation

De nombreuses migrations commencent par un mauvais inventaire. L’équipe liste les bases de données, les fichiers et les machines virtuelles. Elle oublie la file d’attente gérée qui contrôle les nouvelles tentatives, le fournisseur d’identité qui délivre les identifiants de service, la plateforme d’observabilité qui contient le seul contexte d’incident utile, le service de secrets qui signe les déploiements, la politique réseau spécifique au fournisseur, le registre d’images, le planificateur, le format de sauvegarde et le parcours d’escalade du support. Chaque dépendance peut être raisonnable. Ensemble, elles forment un environnement d’exécution difficile à reproduire.

Les services gérés créent de la valeur en supprimant du travail. Ce travail ne disparaît pas lorsque le contrat prend fin. Il se déplace dans le plan de sortie. Quelqu’un doit choisir une file d’attente de remplacement, traduire la sémantique de livraison, reconstruire les alertes, faire pivoter les clés, rétablir la fédération d’identité, récupérer les métriques historiques, retester l’intégrité des sauvegardes et décider quel comportement spécifique au fournisseur faisait partie des hypothèses de l’application. Le service était pratique parce qu’il prenait ces décisions pour vous. Partir signifie les reprendre.

Ce n’est pas un argument contre les services gérés. C’est un argument pour documenter la frontière. Une équipe peut accepter délibérément une dépendance à une base de données gérée si elle connaît le format d’exportation, le chemin de restauration, les limites de compatibilité et les compétences nécessaires pour exploiter l’alternative. Elle peut aussi décider qu’une file d’attente ou un service d’identité particulier est trop central pour rester implicite. Le choix architectural n’est pas fournisseur ou pas de fournisseur. C’est une dépendance visible ou une dépendance non tarifée.

L’infrastructure en tant que code peut aider, mais seulement lorsqu’elle décrit plus que les noms de ressources du fournisseur d’origine. Un script qui recrée un objet réseau propriétaire sur la même plateforme relève de l’automatisation, pas de la portabilité. Une description de sortie utile capture l’intention, les politiques, les contrats de données, les hypothèses de sécurité et les tests. Elle peut ensuite mapper ces éléments vers une nouvelle implémentation. Cette distinction mérite d’être protégée, car un script parfait pour la mauvaise plateforme est un moyen très efficace de rester là où l’on est.

Les sauvegardes révèlent le même problème. Une sauvegarde qui ne peut être restaurée que par le service qui l’a créée est un mécanisme de résilience au sein de la dépendance, pas une voie de sortie. Cela peut être le bon choix pour une charge de travail à faible risque. Ce n’est pas la bonne description. Les personnes doivent savoir si une sauvegarde est une copie de récupération à court terme, une archive à long terme, un artefact de migration ou les trois à la fois. Les étiquettes coûtent moins cher que les surprises.

Le verrouillage opérationnel est un problème d’effectifs

La dépendance la plus difficile à exporter est souvent le savoir d’une personne. La console d’un fournisseur a appris à une équipe où cliquer, quels messages d’erreur comptent, quelle fenêtre de maintenance est sûre et quelle file d’assistance répond avant une échéance. Ce savoir peut être réel et précieux. Il peut aussi être invisible dans le contrat. Lorsque le service change ou que l’organisation déménage, ce savoir devient une file de questions.

Le cadre de souveraineté cloud de la Commission inclut la souveraineté opérationnelle comme la capacité des acteurs européens à exécuter, soutenir et faire évoluer la technologie indépendamment du contrôle étranger. Ses critères font référence à la continuité, aux compétences et à la résilience face aux dépendances externes. C’est une correction utile à l’idée que la souveraineté se décide par l’emplacement imprimé sur une facture. Un système ne peut pas être opérationnellement indépendant si personne au sein de l’organisation ne peut le restaurer, le diagnostiquer ou approuver un changement.

Les compétences ne signifient pas que chaque organisation doit employer un remplaçant complet pour chaque fournisseur. Elles signifient que l’organisation conserve suffisamment de compréhension pour prendre une décision éclairée, superviser un fournisseur, vérifier une restauration et contester une réponse. Elle doit savoir quel savoir est documenté, lequel est détenu par un fournisseur, lequel est détenu par une seule personne et lequel peut être exercé par un test. Une carte des dépendances qui omet les personnes est une fiction flatteuse.

Les runbooks devraient donc inclure un chemin de sortie, pas seulement un chemin d’état stable. Le runbook n’a pas besoin de décrire chaque commande pour chaque destination. Il doit nommer les invariants, les propriétaires, les conditions préalables, les preuves et les conditions de rollback. Il doit expliquer ce qui doit rester vrai pendant que le service est en transit. Cela le rend utile pour une migration et pour un incident grave, ce qui est un bon retour sur l’effort investi.

La portabilité opérationnelle inclut aussi le calendrier sans glamour. Qui est disponible pendant la bascule ? Qui peut approuver une décision de risque ? Quel fournisseur doit répondre à une question ? Quel régulateur, délégué à la protection des données ou propriétaire de service doit être notifié ? Quelles fenêtres de maintenance sont interdites parce qu’un service public, un processus hospitalier ou une boucle de contrôle industriel en dépend ? Un système ne part pas dans l’abstrait. Il part un mardi, avec des personnes, des équipes et des obligations.

Une clause n’est pas une répétition

Il existe un moyen fiable de savoir si une clause de sortie fonctionne : l’essayer avant que ce soit urgent. Cela ne signifie pas déplacer le service de production pour le sport. Cela signifie exercer la voie sur un échantillon représentatif, un locataire de test, une copie de restauration ou un environnement parallèle. La répétition doit être assez grande pour exposer les sémantiques manquantes et assez petite pour que l’organisation puisse apprendre sans mettre le service en danger.

Prenons l’exemple d’un service régional d’archivage hypothétique. Son contrat liste les documents exportables, autorise un changement de prestataire et promet une assistance. Lors d’une répétition, l’équipe découvre que l’export comprend les fichiers et les identifiants clients, mais pas les durées de conservation, les affectations de rôles ni l’ordre dans lequel les approbations ont été enregistrées. Le prestataire source a respecté la spécification d’export à la lettre. Le service destinataire a reçu la cargaison. L’organisation n’a pas reçu son système d’archivage.

La leçon n’est pas que le prestataire a nécessairement violé le contrat. La leçon est que le contrat ne décrivait pas le véritable besoin de continuité de l’institution. Une répétition transforme un adjectif en question. Portable pour quoi exactement ? Réversible pour quelle panne ? Sécurisé pour quelles données ? Rapide pour quelle obligation publique ? Les réponses doivent figurer dans la conception avant la signature du marché, pas dans un litige après l’échéance.

Une répétition doit produire des preuves. L’organisation doit conserver les manifestes, les sommes de contrôle, les versions de schéma, la liste des erreurs, les limites de temps, le registre des approbations, les résultats des tests et les écarts non résolus. Elle doit savoir quels artefacts ont été volontairement exclus et pourquoi. Elle doit consigner les décisions humaines qui ont rendu le transfert sûr. C’est là qu’un exercice de migration ordinaire commence à ressembler à une activité d’assurance. Le circuit du papier devient une chose que l’on peut inspecter.

Les répétitions ont aussi un effet social. Elles rendent acceptable la découverte que la sortie est incomplète. Sans test, la première personne qui dit que le système ne peut pas être déplacé peut sembler obstructive. Avec un test, le manque a un nom, une reproduction et un responsable. C’est une meilleure ingénierie et un peu moins de théâtre, ce qui est une bonne affaire en toute saison.

L’ordre d’une sortie

Une migration est plus facile à raisonner lorsque son ordre est explicite. Commencez par la frontière du service, pas par la brochure du prestataire. Nommez la capacité visible par l’utilisateur, les documents qu’elle crée, les décisions qu’elle soutient, les systèmes externes qu’elle appelle et les obligations qu’elle doit continuer à remplir. Identifiez ensuite les données et les actifs numériques qui portent ces fonctions, y compris les métadonnées et les relations dont un destinataire a besoin.

Décrivez ensuite les invariants. Quels identifiants doivent rester stables ? Quels états ne doivent pas être sautés ? Quels horodatages doivent préserver l’ordre ? Quelles autorisations doivent être équivalentes, et lesquelles peuvent être redessinées ? Quels résultats peuvent être recalculés et lesquels doivent être préservés exactement ? Quelles preuves d’audit doivent rester vérifiables ? Un invariant est une promesse sur le sens. Il donne à la migration quelque chose de plus solide qu’un simple comptage de fichiers à viser.

Cartographiez ensuite les dépendances. Incluez les services, les interfaces, les identifiants, les clés, les réseaux, les bibliothèques d’exécution, les fonctionnalités propres au fournisseur, les personnes, les contrats, les accords de support et les notifications réglementaires. Distinguez une dépendance qui peut être remplacée de celle qui ne peut qu’être contournée. La carte doit inclure la source et la destination, car un service de destination peut introduire une nouvelle dépendance tout en en supprimant une ancienne. Un changement de fournisseur n’est pas automatiquement une réduction de dépendance.

Vient ensuite le chemin parallèle. Exportez une tranche contrôlée. Chargez-la dans la destination. Exécutez les mêmes questions métier, autorisations, tâches, alertes et tests de récupération. Comparez les résultats et expliquez les différences. Gardez la source disponible pendant que la comparaison s’exécute. Le but n’est pas de rendre deux systèmes identiques. Le but est de comprendre où ils diffèrent et si ces différences sont acceptables pour l’objectif du service.

Le cutover est une décision, pas un horodatage. Quelqu’un doit avoir l’autorité de l’approuver, et les preuves doivent être lisibles par des personnes qui n’étaient pas dans la salle de migration. Définissez une condition de rollback avant le passage. Définissez ce que le rollback peut et ne peut pas annuler. Décidez comment les nouvelles écritures sont gérées, comment les utilisateurs sont informés, comment la source est protégée et comment la destination devient l’autorité de référence. Si l’équipe ne peut pas décrire une voie de retour, elle n’est pas prête à qualifier le changement de réversible.

Enfin, fermez l’ancienne voie délibérément. Récupérez ce que le contrat exige. Vérifiez la destination. Conciliez les événements en suspens. Révoquez les identifiants. Gérez les sauvegardes, les caches et les copies dérivées. Demandez l’effacement le cas échéant et conservez les preuves nécessaires pour montrer que l’ancien service ne détient plus d’actifs clients exportables. Quitter un fournisseur n’est pas terminé lorsque la nouvelle connexion fonctionne. C’est terminé lorsque l’ancienne autorité a pris fin et que l’organisation peut le prouver.

La sécurité doit voyager avec la charge de travail

Le Data Act maintient expressément un niveau de sécurité élevé tout au long du processus de bascule. Cela semble évident jusqu’à ce qu’une migration soit traitée comme une exception aux contrôles normaux. Des identifiants temporaires sont copiés dans un carnet. Un bucket de transfert est rendu public pendant une heure. Des clés de chiffrement sont échangées via le canal disponible. D’anciens comptes restent actifs au cas où quelqu’un aurait besoin de vérifier une dernière chose. La voie de sortie est devenue la surface d’attaque la plus intéressante de l’architecture.

Une migration sécurisée a son propre modèle de menace. Qui peut demander une exportation ? Qui peut l’autoriser ? Quelle destination est légitime ? Comment le manifeste est-il signé ? Comment les transferts incomplets sont-ils détectés ? Comment le service récepteur prouve-t-il qu’un enregistrement n’a pas été modifié en transit ? Quels journaux sont conservés, et lesquels contiennent des contenus sensibles nécessitant un traitement distinct ? Comment les clés sont-elles renouvelées à la frontière ? Ce sont des questions de sécurité ordinaires avec un calendrier inhabituel.

La sécurité inclut aussi la continuité. Une organisation peut avoir besoin que la source et la destination fonctionnent ensemble pendant que les enregistrements sont conciliés. Cela crée une période pendant laquelle les données circulent, les identités franchissent les frontières et deux systèmes peuvent changer d’état. La conception de la migration doit rendre cette période finie et observable. Si la double exploitation devient indéfinie, l’organisation a créé un pont permanent entre deux dépendances et l’a nommé transition.

Le secteur de la santé illustre ce point sans nécessiter une histoire dramatique. Les orientations de l’ENISA pour les services cloud dans le domaine de la santé traitent la gestion des incidents, le chiffrement, la portabilité et l’interopérabilité comme des éléments de la planification d’un déménagement sécurisé. Un service destiné aux patients ne peut pas traiter la sécurité et la continuité comme des décorations concurrentes. Un enregistrement qui arrive en toute sécurité après que le service est devenu indisponible n’est pas une migration réussie pour la personne qui avait besoin de soins.

Pour les systèmes à moindre risque, le même principe s’applique de manière plus discrète. Le transfert doit être à privilèges minimaux, journalisé, testé et réversible pendant la période où le rollback reste possible. L’assistance d’un fournisseur ne doit pas être une raison de relâcher la vérification de l’organisation réceptrice. La bonne foi est une attente juridique. Elle ne remplace pas les contrôles cryptographiques ni un opérateur qui sait ce que ces contrôles signifient.

L’effacement fait partie du départ

On décrit souvent une sortie comme le transfert de données d'un fournisseur à un autre. L'ancien fournisseur devient alors une simple note de bas de page. Le Data Act donne une fonction à cette note : après la période de récupération, le contrat doit garantir l'effacement complet des données exportables et des actifs numériques générés directement par le client ou directement liés à celui-ci, une fois le processus de bascule terminé avec succès, sous réserve des conditions énoncées et de toute date ultérieure convenue.

L'effacement est plus difficile lorsque le service a produit des dérivés. Des tables de travail ont pu devenir des index. Des index ont pu devenir des caches. Un document a pu être résumé en ticket, intégré à un état de recherche ou inclus dans une sauvegarde. Certains dérivés sont des actifs du client. D'autres relèvent de l'interne du fournisseur. Certains peuvent être requis pour une période de conservation légale. Le contrat et la conception technique doivent rendre les catégories suffisamment visibles pour qu'une décision puisse être vérifiée.

Un bon inventaire de sortie a donc deux directions. Il trace ce qui doit être déplacé vers la destination, et il trace ce qui doit disparaître de la source. La deuxième direction protège le client d'une rétention silencieuse et le fournisseur d'une promesse impossible. Elle expose aussi une faiblesse courante : les équipes savent peut-être exporter les données qu'elles voient, mais n'ont aucune carte des copies qu'elles ont créées indirectement.

Les preuves d'effacement doivent être proportionnées et significatives. Une déclaration du fournisseur peut être utile. Un enregistrement lisible par machine, une limite de conservation identifiée et un événement d'achèvement vérifiable sont meilleurs. L'organisation doit savoir ce que la preuve démontre et ce qu'elle ne peut pas démontrer. Il n'y a aucun mérite à produire un certificat magnifiquement signé pour un processus de suppression qui n'a jamais eu connaissance du cache.

Partir devrait réduire l'ancienne dépendance, pas simplement déplacer les données vers un second système pendant que le premier en conserve une ombre pour toujours. La frontière a besoin d'un état final. Sinon, l'organisation a payé pour une migration et conservé la responsabilité d'origine comme souvenir.

Le multicloud n'est pas une personnalité

Utiliser plus d'un fournisseur peut réduire la dépendance, mais cela peut aussi multiplier le nombre de choses qu'une organisation doit comprendre. Un second fournisseur peut offrir à l'équipe une voie alternative, ou devenir une seconde dépendance spécialisée reliée par une intégration privée. L'étiquette multicloud indique combien de clouds sont présents. Elle ne dit rien sur le nombre de sorties réellement possibles.

Le Data Act reconnaît l'utilisation parallèle de plusieurs services de traitement de données et la distingue d'une bascule ponctuelle. Le Règlement reconnaît également que le transfert continu de données pour une utilisation parallèle peut bénéficier d'un traitement tarifaire différent pendant la transition. C'est une distinction juridique utile. C'est aussi un avertissement opérationnel. Une conception qui déplace continuellement des données entre fournisseurs nécessite un contrat explicite, un modèle de sécurité, un processus de rapprochement et un budget. Ce n'est pas une répétition gratuite qui se poursuit par hasard indéfiniment.

Le multicloud peut avoir du sens lorsque les frontières sont claires. Une agence publique peut séparer une charge de travail selon la sensibilité ou les exigences de continuité. Un groupe de recherche peut utiliser un second environnement pour la reproductibilité. Un fabricant peut conserver la logique de contrôle près d'une usine tout en utilisant un service distinct pour l'analyse. Ce sont des choix d'architecture, pas des badges d'indépendance. Chacun nécessite une raison, un responsable et un moyen de récupérer lorsqu'une voie est indisponible.

Il y a aussi un coût en compétences. Deux plateformes signifient deux ensembles d'autorisations, de modes de défaillance, de pratiques de déploiement et de voies d'escalade, à moins que l'organisation ne crée une véritable couche d'exploitation commune. Une seconde plateforme que personne ne peut exploiter sous pression n'est pas de la résilience. C'est une clé de secours très coûteuse dans un tiroir que personne n'a jamais ouvert.

The useful question is not whether an organisation has two providers. It is whether it can move a defined service boundary without losing control. Sometimes the answer is a well-designed single-provider deployment with a tested export. Sometimes it is a federated arrangement. Sometimes it is an on-premises route. The architecture should earn its topology.

Sovereignty is the ability to move and stay

The Commission’s Cloud Sovereignty Framework is valuable here because it does not reduce sovereignty to a server’s postcode. It names strategic, legal and jurisdictional, data and AI, operational, supply-chain, technological, security and compliance, and environmental objectives. Its operational objective asks whether European actors can run, support and evolve a technology independently of foreign control. Its technology objective discusses openness, transparency, interoperability, auditability and avoiding lock-in to foreign proprietary systems.

That framework is an assessment approach for a public procurement context. It is not a universal score, and it does not certify that a provider can be replaced on a deadline. Its usefulness is the shape of the questions. Who can make a change? Who can keep the service alive if support is withdrawn? Which skills and components are exposed to an external dependency? Which legal claims can reach the operator? Which parts of the stack can be inspected and evolved?

Location still matters. Jurisdiction matters. Ownership matters. They answer important questions about access, authority and industrial capacity. They do not answer whether the organisation can restore the service from a portable state, whether the data model is understood or whether a replacement team can operate the workload. Sovereignty without an exit route is a flag over a locked room.

Staying matters too. A provider may be easy to leave but difficult to operate with today. Portability should not be treated as an excuse to choose a poor service or ignore security. The point is to keep the power to make a different choice. A system with a credible exit can choose to remain for good reasons. A system without one remains because the cost of movement has become a veto.

Openness is a design choice, not a licence badge

Open source can reduce dependency, but a licence alone does not make an operational boundary portable. The organisation also needs a format that can be read, a build that can be reproduced, an interface that is documented, a release process that is visible and people who can maintain the path. An abandoned open repository is open in the same way an unlocked shed is available: technically, perhaps; usefully, not always.

Open standards have a similar discipline. A standard can be public while implementations disagree about edge cases, versioning and error handling. A portable boundary needs conformance tests and a way to record which version was used. It should make the meaning of a state inspectable without requiring a private service. The standard is the common language. The test suite is how the speakers prove they understood one another.

At Dweve, this is the narrow reason we describe BitWeave’s boundary in terms of a portable semantic state rather than a hosted search endpoint. The public page describes one on-disk .bwks index format across its in-process, standalone-server and compatible WASM surfaces. That is a small engineering example, not evidence that every workload is portable and not a claim that an open component removes all contractual or operational dependency. The useful principle is simply to make the state and the boundary explicit.

Le point de fond reste valable sans Dweve. Lorsque l’état essentiel d’un système peut être inspecté, déplacé et testé via un contrat documenté, une organisation dispose de plus d’options. Lorsque l’état n’existe qu’à l’intérieur de l’environnement d’exécution d’un fournisseur, l’organisation en a moins. Une licence peut contribuer à créer la première condition. Elle ne peut pas la créer à elle seule.

Ce que les achats devraient demander avant la signature

On demande souvent aux achats de comparer le prix, les fonctionnalités, les certifications de sécurité et les niveaux de service. La sortie devrait faire partie de la même conversation. Elle devrait être suffisamment précise pour qu’un réviseur technique puisse la tester et suffisamment claire pour qu’un responsable juridique ou de service puisse la comprendre. Une question utile est une question à laquelle on peut répondre par un document, un appel d’interface, une répétition ou un responsable. Une promesse vague n’est rien de tout cela.

Demandez ce qui peut partir. Exigez une liste exhaustive de catégories, et non une phrase affirmant que les données clients sont exportables. Demandez quelles métadonnées, relations, configurations, journaux d’audit, artefacts dérivés et actifs numériques sont inclus. Demandez ce qui est exclu comme éléments internes du fournisseur ou secrets commerciaux, et pourquoi cette exclusion n’empêche pas le service d’être reconstruit ou sa fonction d’être poursuivie.

Demandez comment cela part. Exigez des formats, des schémas, des descriptions d’interface, des limites de débit, des règles d’ordonnancement, des contrôles d’intégrité, des dispositions de chiffrement et une exportation de test neutre quant à la destination. Demandez si le fournisseur de destination peut recevoir les données via une interface ouverte et si le fournisseur soutiendra une répétition représentative. La réponse ne devrait pas dépendre d’une exception d’urgence.

Demandez ce qui continue de fonctionner. Définissez la continuité du service, l’équivalence fonctionnelle et les conditions dans lesquelles la source reste responsable. Demandez comment les nouvelles écritures, les nouvelles tentatives, les tâches planifiées, les alertes, les changements d’identité et les demandes de support se comportent pendant la transition. Demandez qui peut approuver le basculement et qui peut l’arrêter. Un contrat qui spécifie les données mais pas l’autorité est incomplet pour un service important.

Demandez qui peut exploiter le remplacement. Nommez les compétences, la documentation, la formation, l’accès aux outils, le support et les preuves nécessaires pour faire fonctionner la destination. Demandez si une certification spécifique au fournisseur est la seule voie pratique vers la compétence. Demandez comment l’organisation se remettra si le fournisseur d’origine devient indisponible pendant le déplacement. Ces questions exposent le verrouillage opérationnel avant qu’il ne devienne une urgence de personnel.

Demandez comment l’ancienne voie se ferme. Définissez la récupération, la conservation, la suppression, la gestion des sauvegardes, la révocation des clés, la suppression des accès et les preuves. Demandez comment l’organisation prouvera que l’exportation est terminée et que l’ancienne autorité a pris fin. La dernière question est souvent celle qui transforme un document d’achat agréable en un document sérieux.

Un petit tableau de bord de sortie

Une organisation n’a pas besoin d’un chiffre universel pour comparer les sorties. Elle a besoin d’un court enregistrement qui rend les lacunes importantes difficiles à cacher. Les questions suivantes sont un point de départ, et non un test réglementaire :

• Une nouvelle équipe peut-elle identifier et interpréter chaque actif que le service doit transporter ?
• La destination peut-elle valider l’exportation sans assistance propriétaire ?
• Le service peut-il continuer pendant que la source et la destination sont rapprochées ?
• L’organisation peut-elle reproduire les autorisations, les preuves et l’état des politiques qui comptent ?
• Une personne nommée peut-elle arrêter ou inverser le déplacement dans des conditions définies ?
• Les contrôles de sécurité requis peuvent-ils fonctionner pendant le transfert et la récupération ?
• L’organisation peut-elle exploiter le remplacement avec des compétences qu’elle peut conserver ou obtenir ?
• Peut-elle prouver ce qui a été effacé, conservé ou intentionnellement exclu à la source ?

The value of this list is not the list itself. It is the demand for an answer that can be checked. A provider may answer some questions with contractual terms, some with technical documentation, some with a test and some with a limitation. That is healthy. A limitation that is visible can be managed. A limitation that appears only during an urgent migration owns the timetable.

Exit changes how a system is designed

Once a team treats exit as a real property, design discussions become more precise. State needs an owner and a format. Interfaces need a version and a conformance test. Derived artefacts need a lineage and a deletion rule. Credentials need a rotation path. Provider-specific features need a reason, an alternative or an explicit acceptance of dependency. Operational knowledge needs a home outside one person’s memory.

This discipline can improve the system even when nobody ever switches. A portable state is easier to back up and restore. A documented interface is easier to test. A clear dependency map is useful during an outage. A rehearsal exposes ambiguous permissions before they become a security incident. A named rollback owner makes a release decision less ceremonial. Exit is a resilience practice wearing procurement clothing.

It can also prevent a common strategic error. Organisations sometimes try to buy sovereignty at the end by adding a second provider, a legal addendum or a dashboard that counts cloud regions. These additions may help, but they do not reverse a design that has hidden its semantics, skills and authority inside one service. The cheapest time to make an exit credible is before the dependency becomes the shortest path to every important outcome.

There is no shame in choosing a dependency. Every serious system has them. The shame is in calling a dependency optional because the contract has an export clause. Clarity lets an organisation price the choice, govern it and decide when the trade-off is no longer acceptable. It also gives a provider a fairer relationship with the customer. A service that earns renewal by being useful is stronger than one that earns it by being impossible to leave.

The system should be allowed to leave

The cost of a system that cannot leave is not only the eventual migration bill. It is the authority surrendered before the bill arrives. It is the supplier’s private vocabulary becoming the organisation’s public process. It is a runtime nobody else can operate, a record nobody else can interpret and a decision nobody can reverse without asking permission from the system that made the dependency.

European policy is pushing in the right direction. The Data Act makes switching rights, export information, cooperation, continuity, interoperability and the removal of charges part of the legal landscape. The Commission’s cloud policy puts interoperable infrastructure and procurement criteria beside competitiveness and security. ENISA has been naming lock-in and loss of governance as cloud risks for years, and its healthcare guidance connects portability to the safe continuity of a sensitive service. These sources do not describe an effortless future. They describe the work that an effortless claim tends to hide.

The practical answer is modest and demanding. Design the exit while designing the service. Describe the state before you purchase the runtime. Test the export before you need it. Keep enough operational knowledge to challenge the supplier and run the destination. Treat security, continuity, authority and erasure as part of the move. Record what cannot travel. Rehearse the route with people who will have to sign their names to the outcome.

Un système peut rester chez un même fournisseur pendant des années. C'est tout à fait raisonnable tant que le choix reste délibéré. Le critère est de savoir si l'organisation pourrait choisir à nouveau. Si c'est le cas, la dépendance est maîtrisée. Sinon, c'est la dépendance qui commande. Le logiciel a une manière sèche de révéler les rapports de force. Donnez-lui une voie de sortie et il reste une infrastructure. Retirez cette voie et il devient un propriétaire.

Sources

• Regulation (EU) 2023/2854, Data Act, Chapter VI, EUR-Lex, Publications Office of the European Union.
• Data Act explained, European Commission.
• Cloud computing, European Commission.
• Cloud Sovereignty Framework: implementation guidance, European Commission, Directorate-General for Digital Services.
• Cloud Computing Risk Assessment, European Union Agency for Cybersecurity.
• Securing cloud services for health, European Union Agency for Cybersecurity.
• BitWeave, Dweve.