Guide
Changer de solution IA sans tout perdre
Ce qui se récupère, ce qui se perd vraiment, les clauses à exiger du prochain fournisseur, et l'architecture qui rend le changement suivant indolore.
Publié le 20 juillet 2026
La décision de changer d'outil d'IA arrive souvent longtemps après le constat d'échec, retenue par une crainte : tout perdre et tout recommencer. La réalité d'une migration est plus favorable : l'essentiel se récupère, ce qui se perd compte moins qu'on ne le croit, et le véritable enjeu est ailleurs : ne pas reproduire chez le prochain fournisseur la dépendance qui vous coûte aujourd'hui.
Ce qui se récupère
Vos documents, d'abord : ils n'ont jamais appartenu à l'outil. La GED, les dossiers, les modèles de courriers restent à vous, et le tri effectué pour le premier projet - quels documents comptent, lesquels sont à jour - reste acquis.
La connaissance des cas d'usage, ensuite. Le premier outil a révélé où l'IA rend service et où elle échoue, quelles questions reviennent, quels processus valent l'investissement. Ce cahier des charges vécu vaut plus que n'importe quel atelier de cadrage.
Les équipes, enfin. Elles ont appris à formuler des demandes, à se méfier des réponses sans source, à repérer ce qui marche. La déception a formé leur exigence : c'est un actif, pas une cicatrice.
Ce qui se perd, et pourquoi c'est acceptable
L'index de vos documents se perd, et se reconstruit : c'est un produit dérivé de vos pièces, pas un capital. L'historique des conversations se perd le plus souvent aussi ; sa valeur réelle est faible, car les réponses utiles ont déjà été utilisées là où elles servaient. La configuration propriétaire, elle, ne se transfère pas, et c'est précisément le signe qu'elle n'aurait jamais dû enfermer vos processus.
Une exception mérite l'attention : si des équipes ont bâti des habitudes sur l'outil, la migration se planifie avec elles, processus par processus, sans coupure sèche.
Les clauses à exiger avant de re-signer
La dépendance ne se combat pas au moment de partir ; elle se refuse au moment de signer. Avant tout nouvel engagement, exigez par écrit :
- l'export de vos données dans des formats standards, avec délai et assistance ;
- la localisation des traitements et la juridiction de l'opérateur, noir sur blanc ;
- un journal d'audit consultable, qui reste accessible en fin de contrat ;
- l'identité de l'opérateur du système et ses engagements de service ;
- une clause de réversibilité complète : ce qui vous est remis, sous quel format, en combien de temps.
Un fournisseur qui négocie mal ces clauses vous renseigne utilement, avant qu'il ne soit trop tard. Cette grille rejoint les sept questions d'un audit : ce qu'un auditeur exigera demain, exigez-le au contrat aujourd'hui.
L'architecture qui rend le prochain changement indolore
La leçon durable dépasse le choix d'un fournisseur. Une architecture saine sépare trois choses : vos données, l'outil qui les exploite, et le modèle qui raisonne. Quand ces trois couches sont distinctes, remplacer le modèle devient une décision technique révisable - le paysage des modèles bouge tous les six mois - sans toucher aux données ni refaire les processus.
C'est le principe du Workspace : votre instance, vos données en France, des modèles remplaçables par conception, choisis par tâche plutôt qu'imposés par l'éditeur. La sortie du premier outil est l'occasion de poser cette séparation une fois pour toutes.
Questions fréquentes
La migration va-t-elle interrompre les équipes ?
Non, si elle est menée processus par processus : l'ancien outil reste consultable pendant que le premier processus bascule, et chaque équipe change quand son flux est prêt. La coupure sèche est un choix, jamais une fatalité.
Notre prestataire refuse de fournir un export. Que faire ?
Pour les données personnelles, le RGPD vous donne un droit opposable ; une mise en demeure suffit généralement. Pour le reste, tout dépend du contrat signé, et c'est la leçon à retenir : vos documents source, que vous détenez par ailleurs, permettent de reconstruire l'essentiel même sans coopération de l'éditeur.
Comment éviter de revivre la même déception ?
En inversant l'ordre des questions : l'architecture d'abord (citations, bon modèle par tâche, connexion aux outils réels, opérateur responsable - les cinq causes du premier échec, prises à l'envers), la démonstration ensuite, sur vos documents réels. Si vous préparez cette deuxième décision, parlons-en.