Migrer vers un cloud IA souverain : guide pratique DSI 2026

Pourquoi migrer : les déclencheurs courants

Déclencheur 1 : Exposition au Cloud Act

La découverte que votre fournisseur IA — ou son infrastructure sous-jacente — est soumis au Cloud Act américain est le déclencheur le plus fréquent. Une startup française qui héberge sur AWS ou Google Cloud est structurellement exposée, même si son siège social est à Paris. Depuis que la CNIL a intensifié ses contrôles sur les transferts de données hors UE et que l'EU AI Act a renforcé les exigences de localisation, de nombreuses DSI ont lancé des migrations préventives.

Déclencheur 2 : Changement de politique du fournisseur

Plusieurs grands fournisseurs SaaS IA ont modifié leurs conditions d'utilisation en 2024-2025 pour s'autoriser à utiliser les données clients dans l'entraînement de leurs modèles. Ces modifications, souvent communiquées par e-mail puis intégrées silencieusement dans les CGV, ont déclenché des migrations urgentes chez les entreprises ayant des données sensibles.

Déclencheur 3 : EU AI Act et non-conformité

L'application progressive de l'EU AI Act force les entreprises à documenter leurs systèmes IA et à démontrer leur conformité. Pour un système déployé sur un fournisseur sans documentation technique, sans auditabilité, ou sans DPA conforme, la mise en conformité nécessite soit une migration, soit des développements importants qui rendent la migration plus attractive.

Cartographie des données à migrer

La première étape de toute migration IA est un inventaire exhaustif de ce qui existe chez votre fournisseur actuel. Cette étape est systématiquement sous-estimée — et sa négligence est la cause principale des migrations qui dépassent budget et délais.

Les 5 catégories de données à cartographier

1. Données sources : documents, textes, données structurées qui ont été chargés dans le système pour alimenter les bases de connaissances (RAG). Volume ? Formats ? Date de dernière mise à jour ? Doublons éventuels avec vos systèmes source ?

2. Bases vectorielles : les embeddings générés à partir de vos documents. C'est un actif souvent ignoré car invisible — mais le recalculer chez le nouveau fournisseur a un coût (temps de calcul GPU, temps de validation de la qualité). Demandez l'export dans un format compatible (vecteurs bruts + métadonnées).

3. Modèles fine-tunés : si vous avez fine-tuné un modèle sur vos données métier, les poids résultants sont votre actif IA le plus précieux. Vérifiez immédiatement leur portabilité (voir section dédiée).

4. Historiques de conversation et logs : les historiques de conversation des utilisateurs, les logs de requêtes, les évaluations de qualité — ces données servent à améliorer votre système et à documenter la conformité. Assurez-vous de les exporter avant migration.

5. Configurations et personnalisations : prompt système, paramètres de modèle, règles métier, intégrations API, configuration des droits d'accès utilisateurs — tout ce qui fait que votre déploiement est spécifique à votre organisation plutôt qu'une instance générique.

Catégorie	Priorité migration	Risque si non migré	Format d'export idéal
Modèles fine-tunés	Critique	Perte de mois de travail d'entraînement	Poids modèle (safetensors, gguf)
Bases vectorielles	Haute	Recalcul coûteux (GPU + temps)	Vecteurs bruts + métadonnées JSON
Documents sources	Haute	Ré-ingestion laborieuse depuis sources	Fichiers originaux + arborescence
Historiques et logs	Moyenne	Perte de traçabilité EU AI Act	JSON structuré horodaté
Configurations	Haute	Reconfiguration manuelle longue	YAML/JSON de configuration

Évaluation du vendor lock-in actuel

Avant de planifier la migration, mesurez votre niveau de dépendance réel. Un score élevé de lock-in ne signifie pas que la migration est impossible — mais il permet de planifier réalistement les efforts et les coûts.

Score de lock-in IA (évaluez chaque axe de 0 à 3)

• Portabilité des données (0-3) : 0 = export complet garanti et testé ; 3 = pas de procédure d'export documentée
• Portabilité des modèles (0-3) : 0 = modèles fine-tunés exportables ; 3 = modèles propriétaires non exportables
• Dépendance API propriétaire (0-3) : 0 = API standard OpenAI compatible ; 3 = API propriétaire unique sans équivalent
• Intégrations SI (0-3) : 0 = connecteurs standards ; 3 = connecteurs propriétaires profonds dans le SI
• Volume de données propriétaires (0-3) : 0 = données facilement exportables ; 3 = volumes massifs dans des formats propriétaires
• Coûts de sortie contractuels (0-3) : 0 = sortie gratuite garantie ; 3 = coûts de sortie élevés et contraintes contractuelles

Score 0-6 : migration facile (3-6 semaines) | Score 7-12 : migration complexe (2-4 mois) | Score 13-18 : migration critique (4-8 mois, coût élevé)

Plan de migration en 6 phases

Phase 1 — Audit et cartographie (semaines 1-3)

Inventaire complet des données et configurations à migrer, scoring du lock-in actuel, identification des dépendances cachées (intégrations, webhooks, APIs tierces qui transitent par le fournisseur actuel). Livrable : cartographie documentée et plan de migration validé par la DSI et le DPO.

Phase 2 — Sélection et contractualisation (semaines 3-6)

Évaluation des fournisseurs cibles (grille d'audit fournisseur), POC technique sur le fournisseur souverain cible pour valider la compatibilité, contractualisation avec clauses de portabilité et d'auditabilité. Ne signez pas sans avoir validé techniquement que vos données peuvent être importées correctement.

Phase 3 — POC et validation technique (semaines 6-10)

Déploiement de l'environnement cible en parallèle de l'environnement existant, migration d'un sous-ensemble représentatif de données, test de performance comparative sur vos cas d'usage réels. Cette phase valide que la qualité de service de la solution cible est équivalente ou supérieure avant de commencer la migration complète.

Phase 4 — Migration progressive (semaines 10-18)

Migration des données par lots (priorité : modèles fine-tunés, bases vectorielles, documents sources), reconfiguration des intégrations SI, formation des utilisateurs sur les éventuelles différences d'interface. Le principe clé : migrer par cas d'usage, pas par type de données. D'abord le cas d'usage le moins critique, puis progressivement les plus critiques.

Phase 5 — Double-run et validation (semaines 18-22)

Les deux systèmes (ancien et nouveau) fonctionnent en parallèle. Les utilisateurs basculent progressivement sur le nouveau système, avec la possibilité de revenir sur l'ancien en cas de problème. Les outputs des deux systèmes sur des requêtes identiques sont comparés et validés par les équipes métier. Cette phase est clé pour la confiance des utilisateurs.

Phase 6 — Coupure et fermeture (semaines 22-26)

Bascule complète vers le nouveau système, demande d'export final et de certification de destruction des données chez l'ancien fournisseur, résiliation du contrat (en respectant les préavis contractuels), mise à jour du registre des traitements et des AIPD. Livrable final : checklist de validation post-migration complète.

Migration des modèles fine-tunés : le sujet le plus technique

Si votre organisation a fine-tuné un modèle sur ses données métier, c'est l'actif à protéger en priorité. Les enjeux sont différents selon les scénarios :

Scénario 1 : Modèle fine-tuné sur votre infrastructure (on-premise ou cloud dédié)

C'est le cas le plus simple. Vous possédez les poids du modèle et pouvez les migrer directement. Le défi technique est la compatibilité : le modèle a été entraîné avec un framework spécifique (PyTorch, JAX) et peut nécessiter des adaptations pour fonctionner sur la nouvelle infrastructure. Prévoyez 2 à 4 semaines de travail technique pour la migration et la validation.

Scénario 2 : Fine-tuning réalisé via API du fournisseur (OpenAI fine-tuning, Azure OpenAI fine-tuning)

C'est le cas le plus verrouillant. Les modèles fine-tunés via l'API d'OpenAI restent sur l'infrastructure d'OpenAI — vous n'avez pas accès aux poids. La "migration" consiste à recréer le fine-tuning sur le nouveau fournisseur avec le même jeu de données d'entraînement (que vous devez posséder). Prévoyez les coûts de GPU pour le nouvel entraînement et 3 à 6 semaines pour l'entraînement et la validation.

Scénario 3 : Pas de fine-tuning, uniquement des configurations RAG

C'est le cas le plus courant et le plus simple à migrer. Les bases de connaissances (documents source) sont exportées, les embeddings sont recalculés sur le nouveau fournisseur (coût GPU modéré), et les configurations (prompts système, paramètres) sont reproduites. La qualité des réponses peut varier légèrement selon les différences entre les modèles de base des deux fournisseurs — prévoir une phase de validation et d'ajustement.

Garantir la continuité de service pendant la migration

Le risque principal d'une migration IA est l'interruption de service pour les utilisateurs. Voici comment le mitiger :

• Double-run obligatoire : ne coupez jamais l'ancien système avant que le nouveau soit validé en production par des utilisateurs réels sur des cas d'usage réels
• Migration par rôle utilisateur : commencez par les super-utilisateurs et power users (plus tolérants aux imperfections), puis déployez progressivement aux utilisateurs standards
• Rollback plan documenté : définissez en amont les critères de déclenchement d'un rollback (taux d'erreur supérieur à X%, NPS utilisateurs en baisse de Y points) et la procédure d'exécution du rollback
• Support renforcé pendant la transition : doublez le support utilisateur pendant les 4 semaines suivant la bascule — c'est quand les questions et les irritants apparaissent
• Communication proactive : informez les utilisateurs de la migration bien à l'avance, expliquez les raisons (souveraineté, conformité), et présentez les bénéfices attendus. Une migration non expliquée génère de la résistance même quand la solution est meilleure

Coûts de sortie : ce que votre fournisseur ne vous dit pas d'emblée

Coût de sortie	Fourchette	Négociable ?	Comment l'anticiper
Frais d'export des données	0 – 15 000€	Oui (si clause portabilité)	Inclure gratuité dans le contrat initial
Frais de transfert de données sortantes	0,05 – 0,20€/Go	Partiellement	Estimer le volume total dès le contrat
Pénalités de résiliation anticipée	0 – 6 mois de factures	Oui	Négocier délai de préavis court et pénalités plafonnées
Recalcul des embeddings (GPU)	500 – 20 000€	Non (coût technique)	Négocier export des embeddings bruts
Réentraînement modèles (si non exportables)	5 000 – 100 000€	Non	Exiger portabilité des modèles dès le contrat
Développement connecteurs SI	10 000 – 80 000€	Non	Utiliser APIs standards dès le départ
Formation équipes sur nouvelle solution	5 000 – 40 000€	Non	Prévoir dans le budget migration

Checklist de validation post-migration

Utilisez cette checklist à J+30 et J+90 après la bascule complète pour valider le succès de la migration :

Technique

• ☐ Toutes les données sources importées et indexées avec succès (vérification par échantillonnage)
• ☐ Qualité des réponses validée sur jeu de test représentatif (score ≥ seuil défini pendant le POC)
• ☐ Toutes les intégrations SI fonctionnelles (tests bout-en-bout sur chaque connecteur)
• ☐ SLA respecté depuis la bascule (vérification des logs de disponibilité)
• ☐ Aucune donnée résiduelle identifiée chez l'ancien fournisseur (attestation de destruction reçue)

Conformité

• ☐ DPA signé avec le nouveau fournisseur et archivé
• ☐ Registre des traitements RGPD mis à jour (ancien fournisseur supprimé, nouveau ajouté)
• ☐ AIPD mise à jour pour les systèmes à haut risque EU AI Act
• ☐ Localisation des données vérifiée (aucun flux résiduel vers l'ancien fournisseur)
• ☐ Documentation AI Act mise à jour avec le nouveau fournisseur

Adoption et performance

• ☐ Taux d'adoption ≥ au taux pré-migration (utilisateurs actifs hebdomadaires)
• ☐ NPS utilisateurs mesuré et stable ou amélioré
• ☐ Tickets de support en baisse par rapport à la phase de transition
• ☐ KPIs métier (temps de traitement, qualité) maintenu ou amélioré
• ☐ Budget migration final documenté et comparé au budget initial

FAQ : Migration vers un cloud IA souverain

Combien de temps faut-il pour migrer une IA d'entreprise vers un cloud souverain ?

La durée dépend de la complexité de l'existant et du niveau de lock-in du fournisseur actuel. Pour une migration simple (configuration RAG, pas de fine-tuning, intégrations standards), 6 à 10 semaines suffisent. Pour une migration complexe (modèles fine-tunés non portables, intégrations SI profondes, volumes de données massifs), comptez 4 à 8 mois. La phase de cartographie initiale est celle qui permet de calibrer cette estimation avec précision.

Peut-on migrer sans interrompre le service aux utilisateurs ?

Oui, avec une approche de double-run bien menée. La migration ne doit jamais être une coupure nette : le nouveau système monte en charge progressivement pendant que l'ancien reste disponible comme fallback. La coupure finale n'intervient que quand le nouveau système a prouvé sa fiabilité en production réelle sur une période suffisante (généralement 4 à 6 semaines de double-run).

Les modèles fine-tunés sur ChatGPT ou Azure OpenAI sont-ils récupérables ?

Non, pas directement. Les poids des modèles fine-tunés via l'API d'OpenAI restent sur l'infrastructure d'OpenAI et ne sont pas exportables. Vous pouvez récupérer le jeu de données d'entraînement que vous avez fourni (s'il est bien conservé), et ré-entraîner un modèle équivalent chez votre nouveau fournisseur. Ce point illustre l'importance de systématiquement négocier la portabilité des modèles dès le contrat initial, avant tout fine-tuning.

Comment gérer la résistance des utilisateurs habitués à l'ancien outil ?

La résistance au changement est inévitable et se gère par l'implication précoce. Associez des représentants des principaux groupes d'utilisateurs dès la phase de POC (ils participent à la validation du nouveau système), formez les référents métier en priorité pour qu'ils deviennent des ambassadeurs internes, et communiquez clairement sur les bénéfices (sécurité des données, conformité, pérennité) plutôt que seulement sur les fonctionnalités. Un gain fonctionnel visible sur au moins un aspect de l'outil facilite considérablement l'adoption.

Que faire si le fournisseur actuel refuse de coopérer à la migration ?

Si votre contrat contient une clause de portabilité (voir notre article sur les clauses essentielles des contrats SaaS IA), le refus est une violation contractuelle ouvrant droit à des pénalités et à une résiliation aux torts du fournisseur. Si aucune clause n'existe, le RGPD impose au sous-traitant de restituer les données à la fin du contrat (article 28.3g) — ce droit est non négociable. En dernier recours, la CNIL peut être saisie pour forcer la restitution des données personnelles.

La migration vers Intelligence Privée est-elle compatible avec un hébergement on-premise existant ?

Oui. Intelligence Privée propose plusieurs modes de déploiement : cloud souverain managé (hébergement en France sur infrastructure dédiée), on-premise dans vos datacenters (nous déployons et maintenons la solution sur votre infrastructure), ou mode hybride (modèles on-premise, interface cloud souverain). Cette flexibilité permet d'adapter le déploiement à vos contraintes de confidentialité, de budget et de capacités IT internes.