Vous pensiez peut-être faire des économies en contractualisant autour d'une solution d'IA ? Même si l'IA est la réponse à votre problème, ce qui n'est pas garanti, les pièges classiques de l'enfermement contractuel et de la dépendance technologique continuent de s'appliquer.
La signature d'un contrat avec un prestataire d'intelligence artificielle est rarement perçue pour ce qu'elle est, à savoir un transfert partiel et souvent irréversible de contrôle sur vos données, vos processus et votre capacité d'arbitrage futur.
L'attention première de l'acheteur se porte sur le prix d'acquisition, les fonctionnalités promises, les délais de déploiement. Ce que le contrat fait réellement, à savoir la dépendance qu'il installe, les coûts qu'il décale, les droits qu'il vous retire, reste dans l'ombre jusqu'au moment où en sortir devient trop coûteux.
Ce moment arrive plus vite qu'on ne le pense. Voici pourquoi nous évoquons ces sujets aujourd'hui.
Le mécanisme de la dépendance
La dépendance vis-à-vis d'un fournisseur technologique n'est pas un accident : c'est un modèle économique. Une étude de Bain & Company citée par Monetizely estime qu'un taux de rétention de 5% suffit à lui seul à faire progresser la marge des éditeurs Saas de 25% à 95%.
Les fournisseurs de solutions tech, IA ou non, ont structurellement intérêt à ce que le coût de migration de leurs clients soit élevé. Plus vous utilisez leurs outils, plus vos données, vos processus et vos équipes s'y adaptent. Chaque mois d'utilisation augmente les coûts irrécupérables : formation des équipes, adaptation des processus internes, intégration des données dans le format propriétaire du système.
Pour les solutions d'IA spécifiquement, le verrouillage est structurellement plus fort que pour le cloud traditionnel. Les outils d'IA apprennent de vos données, de vos requêtes, de vos interactions. Ces apprentissages deviennent inhérents au modèle et ne peuvent pas être transférés à un autre fournisseur. Changer de solution ne signifie pas migrer des données, cela signifie recommencer à zéro un processus d'apprentissage qui a duré des mois ou des années.
Et encore, votre intérêt aurait pu être de ne pas entraîner des services extérieurs sur vos données, y compris dans une perspective de visibilité par les IA.
Ce que le contrat ne dit pas clairement
Quatre dimensions de la dépendance peuvent coexister au sein de votre contrat, et peuvent se renforcer mutuellement.
Quatre dimensions de la dépendance coexistent rarement dans le même article du contrat, et se renforcent mutuellement.
La première est la dépendance aux données. Lorsque vos données sont stockées dans un format propriétaire ou que leur extraction déclenche des frais de sortie, changer de fournisseur cesse d'être une décision pour devenir un projet à part entière. Le rapport Flexera 2026 State of the Cloud documente ce mécanisme concrètement : après cinq années consécutives de baisse, les dépenses cloud gaspillées ont remonté à 29 % en 2026. La cause explicite identifiée par le rapport est la complexité croissante introduite par l'IA et les nouveaux services PaaS. Autrement dit, plus les organisations intègrent profondément les outils de leurs fournisseurs, plus le coût de la maîtrise augmente, même sans changer de prestataire.
La seconde est la dépendance à la plateforme. Les fonctionnalités spécifiques au fournisseur (formats d'API propriétaires, modules d'intégration exclusifs, architectures non portables) créent une dépendance technique qui s'approfondit à mesure que l'adoption s'élargit. Le rapport Flexera documente ce phénomène sous l'angle de la gouvernance : seules 49 % des PME disposent d'un CCOE (Cloud Center of Excellence) contre 76 % des grandes entreprises. Cette asymétrie de pilotage signifie que les PME adoptent les outils de leurs fournisseurs sans disposer des structures internes pour en mesurer la dépendance réelle ni en négocier les conditions de sortie.
La troisième est la dépendance contractuelle. Les clauses de renouvellement automatique, les pénalités de résiliation anticipée et les regroupements forcés de fonctionnalités créent une pression économique qui rend le statu quo systématiquement moins coûteux que la sortie. Le rapport Flexera 2026 révèle que moins de la moitié des organisations utilisent les remises d'engagement proposées par leurs fournisseurs cloud, non par manque d'intérêt pour les économies, mais parce que ces engagements sont perçus comme des restrictions à la flexibilité future. Ce refus d'engagement sur les remises reflète précisément la conscience du lock-in : les organisations préfèrent payer plus cher à la demande plutôt que de se lier contractuellement. C'est le signal inverse de la confiance, et se traduit donc dans le ROI du projet numérique.
La quatrième est la dépendance organisationnelle. Les équipes sont formées sur l'outil du fournisseur. Les processus métier se réorganisent autour de ses capacités. Le rapport Flexera 2026 documente cette tendance de fond : l'usage extensif de la GenAI est passé de 36 % à 45 % des organisations en un an, et 100 % des répondants déclarent désormais l'utiliser sous une forme ou une autre. Cette adoption universelle en douze mois crée une dépendance organisationnelle de fait, les équipes ont modifié leurs pratiques autour des outils, avant même que les contrats et les architectures ne soient stabilisés. Or le même rapport indique que 53 % des organisations citent les risques de sécurité et de conformité liés à l'IA cloud comme leur premier défi. L'adoption a précédé la gouvernance. C'est précisément dans cet écart, entre l'intégration opérationnelle et le contrôle contractuel, que la dépendance s'installe sans être négociée.
Ces quatre niveaux s'additionnent. Une organisation qui a migré ses données dans un format propriétaire, intégré ses processus dans l'écosystème du fournisseur, formé ses équipes sur ses outils et différé l'engagement contractuel par souci de flexibilité se retrouve dans une situation paradoxale : elle a maximisé sa dépendance de fait tout en évitant de la formaliser. Ce n'est pas une stratégie d'indépendance, mais une exposition non documentée.
La dimension réglementaire : ce que l'AI Act change à l'équation
L'entrée en vigueur de l'AI Act (Règlement UE 2024/1689) a introduit une couche supplémentaire de complexité contractuelle que la majorité des contrats signés avant 2025 n'anticipaient pas.
L'AI Act distingue deux rôles : le fournisseur, qui développe et met sur le marché le système d'IA, et le déployeur, c'est-à-dire vous, qui l'utilise dans un contexte professionnel. Cette distinction a des conséquences directes sur la répartition des responsabilités.
Pour les systèmes à haut risque, qui couvrent notamment les outils de recrutement, d'évaluation des performances et de gestion de la relation client (Annexe III, Règlement UE 2024/1689), les obligations du déployeur sont concrètes et vérifiables depuis le 2 août 2026 : supervision humaine effective des décisions automatisées, conservation des logs (traces d'usage informatique), information des personnes concernées, utilisation conforme aux instructions du fournisseur.
Ce dernier point crée une dépendance réglementaire nouvelle. Si votre fournisseur n'est pas conforme, vous ne pouvez pas démontrer votre propre conformité. Les fournisseurs de systèmes à haut risque ont l'obligation de fournir une documentation technique complète à leurs clients déployeurs (AI Act, art. 16, 25, 26). En l'absence de cette documentation, la PME déployeuse est exposée à une responsabilité en cascade qu'elle ne peut pas déléguer contractuellement à son prestataire.
La question à poser à votre fournisseur avant de signer : votre système est-il classé à haut risque au titre de l'AI Act ? Disposez-vous d'une documentation technique conforme à l'Annexe IV ? Un fournisseur qui ne peut pas répondre à ces questions est un risque de conformité pour votre organisation, et ce risque doit être anticipé avant la contractualisation.
La souveraineté des données : un actif sous condition
La transmission de vos données stratégiques vers une infrastructure tierce n'est pas seulement un enjeu de conformité. C'est un enjeu de souveraineté économique.
En Europe, deux régimes juridiques se superposent et créent une tension non résolue. Le RGPD encadre les transferts de données hors de l'Union européenne et impose des garanties spécifiques. Le Cloud Act américain, à l'inverse, permet aux autorités américaines d'accéder aux données hébergées par des opérateurs américains, quel que soit le lieu de stockage physique. Ces deux régimes s'appliquent simultanément, et peuvent se contredire, si votre fournisseur d'IA est une entreprise soumise au droit américain.
La CNIL a explicitement critiqué le projet de certification européenne pour les services cloud (EUCS) pour l'absence de critères d'immunité aux lois extra-européennes, jugeant que cette lacune pose problème sur le plan juridique, économique, technologique et industriel. En France, la certification SecNumCloud maintient des exigences de souveraineté que l'EUCS n'intègre pas dans sa dernière version. Un écart que les contrats avec des prestataires non qualifiés SecNumCloud ne compensent pas spontanément.
Ce que vous signez lorsque vous choisissez un prestataire non souverain, c'est une exposition résiduelle à des régimes juridiques étrangers sur vos données d'entreprise. La portée exacte de cette exposition dépend de la nature de vos données, de votre secteur et de vos obligations contractuelles avec vos propres clients, autant d'éléments que votre contrat avec le prestataire IA ne clarifiera pas toujours à votre place.
Ce qui se négocie avant la signature
L'indépendance technologique, qui préserve aux marges de manœuvre, ne s'improvise pas après déploiement. Elle se contractualise avant. Plusieurs clauses permettent de limiter structurellement la dépendance sans nécessairement changer de fournisseur.
- La portabilité des données doit être explicitement garantie : format d'export standardisé, absence de frais d'égression, délai d'extraction garanti.
- L'accès à la documentation technique du système est une obligation réglementaire pour les systèmes à haut risque, elle doit figurer dans le contrat comme condition de signature, pas comme négociation ultérieure.
- Les conditions de résiliation : préavis, pénalités, obligations du fournisseur en cas de sortie, méritent une attention au moins égale aux conditions d'entrée.
- Le droit d'audit sur les données traitées et les modèles utilisés doit être prévu contractuellement, particulièrement pour les systèmes qui traitent des données personnelles ou qui prennent des décisions impactant des tiers.
D'autant que certaines de ces conditions exposent votre responsabilité en propre, et pas toujours celle de votre prestataire.
Ce que vous signez quand vous signez avec un prestataire IA, c'est un arbitrage sur votre liberté de mouvement future. La plupart des organisations font cet arbitrage implicitement, sans en mesurer les termes. Le coût réel d'un contrat IA n'est pas sa licence annuelle : c'est la somme des coûts de transfert que vous acceptez tacitement, des obligations réglementaires que vous endossez comme déployeur, et de la souveraineté que vous cédez sur vos données stratégiques.
Lire un contrat IA à travers une triple lecture, juridique, économique, technique, n'est pas un luxe de juriste. C'est la condition minimale pour que la signature soit un choix, pas un renoncement.