Contrats IA : la réversibilité vaut plus que le meilleur benchmark

Les achats d’IA sont encore trop souvent décidés comme un concours de démonstrations. Une équipe compare quelques réponses, choisit le modèle qui paraît le plus performant, négocie un prix par utilisateur ou par requête, puis accélère l’intégration. Six mois plus tard, le vrai actif n’est plus le modèle. Ce sont les connecteurs, les instructions, les historiques, les règles de contrôle, les jeux d’évaluation et les habitudes de travail accumulés autour de lui.

C’est là que se crée le verrou.

Le risque n’est pas seulement technique. Il est économique. Si changer de fournisseur oblige à reconstruire les flux, requalifier les résultats, renégocier les droits sur les données et interrompre un processus critique, l’entreprise perd son pouvoir de négociation. Elle finit par accepter une hausse de prix, une baisse de qualité ou un changement de conditions parce que le coût de sortie est devenu supérieur au coût de rester.

La bonne question d’achat n’est donc pas : « Quel fournisseur est le meilleur aujourd’hui ? » Elle est : « Quelle part de notre capacité restera utilisable si ce fournisseur devient moins bon, plus cher ou incompatible avec notre stratégie ? »

Un contrat peut promettre l’export des données tout en laissant l’entreprise captive. La réversibilité réelle doit couvrir cinq couches.

Les données et leur contexte

Exporter des documents ne suffit pas. Il faut pouvoir récupérer les métadonnées, les droits d’accès, les historiques utiles, les annotations, les références et les liens qui donnent leur sens aux données. Un dossier sans sa structure peut être techniquement exporté mais économiquement inutilisable.

Les instructions et les règles métier

La valeur d’un système vient souvent des prompts, des chaînes d’actions, des politiques de validation et des exceptions conçues par les équipes. Si ces éléments restent enfermés dans un format propriétaire, le changement de fournisseur ressemble à un nouveau projet.

Les interfaces et les connecteurs

Un assistant relié au CRM, au support et à la base documentaire devient rapidement un composant du système d’information. Une API documentée n’assure pas à elle seule la portabilité. Il faut identifier les fonctions propriétaires, les dépendances invisibles et le travail nécessaire pour remplacer chaque connexion.

Les preuves de performance

Sans jeu d’évaluation conservé par l’entreprise, impossible de comparer objectivement un fournisseur sortant et un fournisseur entrant. L’organisation devient dépendante du discours commercial de chacun. La réversibilité suppose de posséder ses cas de test, ses critères d’acceptation et l’historique des incidents.

Les conditions de sortie

Le délai, le coût, l’assistance de transition, la continuité de service et la suppression finale des données doivent être décidés avant la signature. Une clause de résiliation sans procédure de migration ne protège pas une activité.

Imaginons une entreprise de services B2B qui déploie un assistant pour préparer les réponses commerciales. Le fournisseur retenu est convaincant. En quelques mois, l’outil apprend à exploiter le CRM, les références clients, les modèles de propositions et les règles de marge. Le taux d’usage augmente. L’équipe avant-vente réduit ses délais.

Puis trois événements surviennent : le prix change, un modèle concurrent devient meilleur sur le français métier et la politique de conservation des données du fournisseur n’est plus alignée avec les exigences d’un grand client.

Sur le papier, l’entreprise peut partir. En pratique, elle découvre que les connecteurs ont été développés dans l’environnement du fournisseur, que les instructions ne sont pas exportables dans un format exploitable et que personne n’a conservé un jeu de tests représentatif. Elle ne sait donc ni chiffrer la migration, ni démontrer que la solution alternative maintiendra la qualité, ni garantir la continuité pendant la transition.

Le problème n’est pas d’avoir choisi un fournisseur. Le problème est d’avoir confondu vitesse d’adoption et réversibilité.

Le Data Act européen s’applique depuis le 12 septembre 2025. Son chapitre VI impose aux fournisseurs de services de traitement de données, notamment cloud et edge, des exigences minimales destinées à faciliter le changement de prestataire et l’interopérabilité. La Commission indique notamment que les fournisseurs de plateformes et de logiciels en tant que service doivent rendre disponibles des interfaces ouvertes et permettre, au minimum, l’export des données dans un format couramment utilisé et lisible par machine.

Le périmètre exact dépend toutefois du service acheté. Toutes les fonctions d’une solution d’IA ne sont pas automatiquement couvertes de la même manière, et les secrets d’affaires ou droits de propriété intellectuelle du fournisseur restent encadrés. Un dirigeant ne doit donc pas transformer une obligation réglementaire générale en assurance de portabilité opérationnelle.

La Commission européenne a publié en novembre 2025 des clauses contractuelles types non contraignantes pour le cloud. Elles distinguent explicitement le changement et la sortie, la résiliation, ainsi que la sécurité et la continuité d’activité pendant la transition. Ce découpage est utile : une entreprise peut avoir le droit de résilier sans disposer des moyens techniques de basculer, ou pouvoir exporter des données sans maintenir le service pendant la migration.

Le NIST, dans son AI Risk Management Framework, invite également les organisations à traiter les risques liés aux logiciels, données et autres composantes fournies par des tiers. Pour un comité de direction, la conclusion est simple : le risque fournisseur n’est pas un sujet annexe des achats. Il fait partie de la gouvernance du système d’IA.

1. Définir le paquet de sortie

Le contrat doit lister ce qui sera restitué : données d’entrée et de sortie, métadonnées, configurations, instructions, historiques pertinents, journaux, règles d’accès et documentation des connecteurs. Le format, le délai et le canal de remise doivent être précisés.

2. Séparer ce qui appartient à l’entreprise

Les données, les instructions conçues pour l’entreprise, les jeux d’évaluation et les paramètres métier doivent être identifiés sans ambiguïté. Le fournisseur doit expliquer ce qu’il utilise pour entraîner ou améliorer ses services, selon quelles bases et avec quelles options de refus.

3. Exiger des interfaces documentées

L’architecture doit isoler autant que possible les appels au modèle, les règles métier et les sources de données. Cette séparation ne rend pas le changement gratuit, mais elle évite que toute l’application doive être reconstruite.

4. Conserver une mesure indépendante

L’entreprise doit posséder un échantillon de cas réels, anonymisés si nécessaire, avec des critères d’acceptation : exactitude, citations, délai, coût, escalade humaine et taux d’erreur critique. Ce jeu sert à suivre le fournisseur en place et à tester une alternative.

5. Chiffrer la sortie avant l’entrée

Le fournisseur et l’équipe interne doivent estimer le temps, les compétences et les coûts nécessaires pour migrer. Une estimation imparfaite vaut mieux qu’une sortie invisible. Le budget d’adoption doit inclure une enveloppe de réversibilité.

6. Prévoir la continuité

La période de transition, le maintien des accès, l’assistance technique, la gestion des incidents et la suppression vérifiable des données doivent être écrits. Les responsabilités ne doivent pas être découvertes pendant la crise.

7. Tester réellement la réversibilité

Une fois par an, ou avant une extension critique, l’entreprise devrait exporter un échantillon, rejouer les tests sur une solution alternative et mesurer l’écart. Une clause jamais exercée reste une hypothèse.

La réversibilité a un coût immédiat. Elle peut ralentir la signature, imposer une architecture plus modulaire et demander une discipline de documentation que les équipes préféreraient reporter. Mais ce coût achète trois options stratégiques : changer de technologie, renégocier en connaissance de cause et continuer l’activité si le fournisseur échoue.

Le bon niveau de réversibilité dépend de la criticité. Un outil expérimental utilisé par cinq personnes ne mérite pas le même dispositif qu’un agent qui prépare des prix, répond à des clients ou modifie des données de production. L’erreur consiste à attendre que l’usage soit critique pour découvrir que les dépendances sont déjà installées.

Le comité de direction peut trancher avec trois questions :

1. Quel processus s’arrête si le fournisseur disparaît pendant trente jours ?

1. Quels actifs ne pouvons-nous pas récupérer aujourd’hui dans un format exploitable ?

1. Combien de semaines nous faudrait-il pour atteindre une qualité acceptable chez un autre fournisseur ?

Si personne ne peut répondre, le risque n’est pas maîtrisé.

La première semaine, cartographiez les solutions d’IA déjà utilisées et les processus qu’elles touchent. La deuxième, classez les dépendances selon les cinq couches : données, instructions, interfaces, preuves de performance et sortie. La troisième, choisissez un système critique et exécutez un export réel. La quatrième, soumettez le résultat au comité de direction avec trois décisions : les clauses à renégocier, les composants à modulariser et le test de continuité à financer.

L’objectif n’est pas de rendre l’entreprise indépendante de tout fournisseur. Il est de rendre chaque dépendance visible, mesurable et réversible à un coût décidé.

Atalas aide les dirigeants à transformer ce diagnostic en architecture, règles de gouvernance et trajectoire d’exécution. Le Studio IA permet de prototyper et tester les options techniques ; le coaching IA pour dirigeants structure l’arbitrage au niveau du comité de direction ; le conseil stratégique accompagne les décisions de portefeuille, de fournisseurs et de déploiement.

Pour cadrer votre niveau de dépendance et votre plan de réversibilité : réserver un échange de 30 minutes.