Le droit de sortir du cloud ne sort pas une PME de l'IA

Le Data Act promet une chose que beaucoup d’acheteurs attendaient depuis longtemps : sortir plus facilement d’un service cloud. Moins de frais abusifs, plus de transparence contractuelle, des exports dans des formats utilisables, des interfaces ouvertes, une pression plus nette contre l’enfermement. Depuis le 12 septembre 2025, ce cadre n’est plus seulement une intention europeenne. Il s’applique.

Pour une PME qui lance un projet IA, la nouvelle est utile. Mais elle peut aussi produire une illusion confortable. Le droit de changer de fournisseur ne signifie pas que l’entreprise sait encore comment reconstruire son usage ailleurs. Il peut exister un chemin juridique de sortie, sans chemin operationnel.

C’est la difference entre la portabilite du cloud et la portabilite du travail.

Un projet IA ne vit pas seulement dans un serveur, un bucket, une base vectorielle ou une API de modele. Il vit dans des documents nettoyes a moitie, des decisions implicites, des prompts ajustes par essais, des exceptions metier, des validations humaines, des connecteurs fragiles, des seuils de confiance et des habitudes d’equipe. Rien de cela ne devient portable par magie parce qu’un contrat cloud prevoit un export.

Le Data Act aide a ouvrir la porte. Il ne range pas la piece.

La sortie cloud n’est pas la sortie du systeme

La Commission europeenne decrit le chapitre VI du Data Act comme un mecanisme pour faciliter le changement entre services de traitement de donnees, notamment cloud et edge. Les fournisseurs doivent retirer des obstacles, permettre certains exports et, pour les plateformes et logiciels en service, rendre les donnees disponibles dans un format courant et lisible par machine.

C’est important. Pendant des annees, beaucoup d’organisations ont decouvert trop tard que le prix d’entree d’un service etait clair, mais que le prix de sortie etait flou. Frais de transit, formats proprietaires, delais, dependances techniques, impossibilite de reproduire un comportement ailleurs : l’enfermement se cachait souvent apres la signature.

Le Data Act corrige une partie de ce desequilibre. Il oblige le fournisseur a parler davantage de sortie. Il donne au client une base pour demander. Il pousse le marche vers plus d’interoperabilite.

Mais une PME qui confond ce droit avec une architecture portable se trompe de niveau. Le fournisseur peut remettre des donnees. Il ne remet pas necessairement la comprehension de ce que l’entreprise en faisait.

Dans l’IA, cette comprehension est souvent le vrai actif.

L’IA ajoute des dependances molles

Les dependances classiques sont visibles. Une base PostgreSQL, un stockage objet, une file de messages, un hebergement web, un annuaire. On peut les lister. On peut discuter la compatibilite, la sauvegarde, la restauration, le temps d’interruption.

Les dependances IA sont plus molles. Elles ne ressemblent pas toujours a de l’infrastructure.

Un prompt qui contient trois annees de compromis metier. Un classement de documents corrige a la main. Une regle de refus ajoutee apres un incident client. Un modele choisi parce qu’il repond “assez bien” dans un cas precis. Une temperature ajustee sans note. Un processus ou le commercial relit, mais seulement quand la reponse lui semble bizarre. Un fichier d’exemples que personne n’a versionne. Une evaluation faite sur vingt cas, puis oubliee.

Ces elements ne sont pas des details. Ce sont eux qui font qu’un systeme tient ou casse.

Le jour ou l’entreprise veut changer de fournisseur, elle peut exporter les donnees et rester bloquee. Elle decouvre que le probleme n’etait pas seulement “recuperer le contenu”, mais “retrouver le comportement acceptable”. Un autre modele reformule differemment. Un autre moteur de recherche renvoie un contexte dans un ordre different. Un autre outil d’orchestration gere les erreurs autrement. Une autre plateforme n’a pas la meme journalisation.

La portabilite IA ne se mesure donc pas seulement en gigaoctets exportes. Elle se mesure en capacite a refaire le meme travail, avec les memes garde-fous, dans un autre environnement.

Le multi-cloud est souvent une diversion

La reponse reflexe consiste a dire : il faut du multi-cloud. Deux fournisseurs, deux regions, deux piles techniques. Sur un schema d’architecture, cela rassure. Dans une PME, cela devient vite une charge de maintenance que personne ne porte vraiment.

Le multi-cloud peut etre justifie pour certaines organisations : exigences fortes de resilience, contraintes reglementaires, volumes importants, equipe technique capable de tester les bascules. Mais comme solution par defaut a l’enfermement IA, il ressemble souvent a une assurance trop chere et mal lue.

Une petite entreprise n’a pas d’abord besoin de dupliquer son architecture. Elle a besoin de savoir ce qui la rendrait prisonniere.

La question utile n’est pas : “pouvons-nous tourner sur deux clouds ?” Elle est plus basse : “si ce fournisseur disparait, augmente ses prix, change ses conditions, degrade son modele ou perd notre confiance, que devons-nous posseder pour continuer ?”

La reponse tient rarement dans un discours de souverainete. Elle tient dans un dossier.

Le dossier de sortie devrait preceder le deploiement

Un dossier de sortie IA n’a pas besoin d’etre long. Il doit etre tenu.

Il commence par la liste des donnees : sources, proprietaires, formats, frequence de mise a jour, emplacement, droit d’export, donnees derivees. Il continue avec les traitements : nettoyage, indexation, embeddings, enrichissements, filtres, journaux. Il ajoute les prompts et instructions systeme, les exemples, les schemas de reponse, les criteres de rejet.

Il documente aussi les modeles utilises, mais sans leur donner plus d’importance qu’ils n’en ont. Pour chaque modele : pourquoi celui-ci, quelles limites connues, quels tests de reference, quel comportement attendu, quelle alternative plausible. Si l’alternative n’a jamais ete essayee, l’ecrire. Une hypothese non testee est moins dangereuse quand elle porte son nom.

Le dossier doit enfin decrire le controle humain. Qui valide ? A quel moment ? Sur quels cas ? Avec quel droit de blocage ? Beaucoup de projets IA pretendent etre portables alors que leur securite depend d’une personne precise qui “sait quand ca sent mauvais”. Cette competence est utile, mais elle n’est pas une architecture.

Le minimum tient dans un tableau.

Zone	Question de sortie	Preuve utile
Donnees	Que peut-on exporter demain ?	Format, volume, droit, script ou procedure
Prompts	Comment reconstruire le comportement ?	Prompts versionnes, exemples, changelog
Modeles	Quel substitut plausible existe ?	Tests comparatifs sur cas reels
Controle	Qui decide que la sortie est acceptable ?	Checklist de validation et jeux d’essai
Couts	Que facture le depart ?	Egress, migration, temps interne, interruption

Ce tableau n’est pas ambitieux. C’est sa force. Une PME qui sait repondre a ces cinq lignes est souvent plus libre qu’une entreprise qui annonce une strategie multi-cloud sans procedure de reprise.

L’interoperabilite avance, mais lentement

La Commission a publie en fevrier 2026 une etude sur l’interoperabilite des services de traitement de donnees. Le sujet est technique, mais il dit quelque chose de simple : les standards ne tombent pas du ciel. Il faut identifier les specifications ouvertes, combler les manques, publier des references, puis laisser aux fournisseurs le temps de s’adapter.

Autrement dit, la portabilite reglementaire est un chantier, pas un bouton.

C’est une bonne nouvelle si on la lit correctement. L’Europe ne se contente pas de dire “soyez interoperables”. Elle travaille a rendre la demande plus concrete. Mais pour l’acheteur PME, cela ne remplace pas la discipline interne. Meme avec de meilleurs standards, personne ne devinera quelles donnees etaient critiques, quelles transformations etaient indispensables, quels tests definissaient un resultat acceptable.

Le standard peut transporter la valise. Il ne choisit pas ce qu’il faut mettre dedans.

Les frais de sortie ne sont qu’une partie du cout

Le Data Act prevoit aussi la disparition progressive de certains frais de changement, notamment les frais necessaires a la sortie et au transit de donnees a partir de janvier 2027. C’est un signal fort contre un modele ou l’on attire le client par un prix d’usage, puis on le retient par un prix de depart.

Mais le cout reel d’une sortie IA ne se limite pas a la facture du fournisseur.

Il y a le cout de comprehension : retrouver comment le systeme marche. Le cout de verification : comparer les reponses avant et apres. Le cout de correction : adapter prompts, connecteurs, formats et droits. Le cout de formation : expliquer aux equipes ce qui change. Le cout de suspension : decider quels usages doivent etre arretes pendant la migration.

Ces couts ne disparaissent pas par decret. Ils baissent quand l’entreprise a documente son usage avant l’urgence.

C’est la raison pour laquelle le dossier de sortie devrait etre cree au moment du cadrage, pas au moment de la rupture. Au debut, tout est encore lisible. Les choix sont frais. Les compromis peuvent etre notes en trois phrases. Six mois plus tard, ils deviennent des souvenirs.

La vraie souverainete est un exercice de reprise

Le mot souverainete est trop grand pour beaucoup de projets IA de PME. Il invite a parler de pays, de cloud europeen, de modele local, de dependance americaine, de regulation. Ces sujets existent. Mais ils peuvent masquer une souverainete plus ordinaire : etre capable de reprendre son propre travail.

Une PME souveraine n’est pas celle qui utilise le fournisseur le plus patriotique. C’est celle qui peut expliquer ou sont ses donnees, comment elles sont transformees, ce qu’un modele fait vraiment, qui valide, comment sortir et comment verifier que la sortie n’a pas casse le metier.

Le Data Act donne un levier externe. Il rend certaines demandes plus legitimes. Il force les fournisseurs a preparer une partie du terrain. Mais il ne dispense pas l’entreprise de faire sa part la moins spectaculaire : tenir l’inventaire, tester l’export, versionner les instructions, garder des jeux d’essai, nommer les controles.

Ce travail n’a rien d’heroique. Il ressemble a de l’administration technique. C’est precisement pour cela qu’il protege mieux que les grands mots.

Un projet IA devrait pouvoir repondre a une question simple avant son lancement : si nous devions partir dans trente jours, que saurions-nous refaire ?

Si la reponse est vague, le probleme n’est pas encore le cloud. Le probleme est que l’entreprise ne possede pas vraiment son propre systeme.