Achat d'IA : rédigez la clause de sortie avant de choisir le modèle
Peu importe quel modèle domine le classement ce trimestre. Le contrat d'IA qu'un conseil d'administration français signe en 2026 peut discrètement livrer toute sa pile technique à un fournisseur jusqu'en 2028, sauf à rédiger la clause de sortie en premier.
Imaginez une ETI de services francilienne, un composite des dossiers que nous voyons passer sur ce bureau. L'année dernière, elle a mis en production un assistant documentaire fondé sur un modèle fermé américain, branché directement sur l'API du fournisseur. Cela fonctionne bien. Puis le renouvellement arrive. Le tarif catalogue a bougé, et dans les notes techniques du fournisseur figure une date de retrait pour le modèle exact sur lequel l'assistant a été construit et évalué. Le choix cesse d'être théorique : migrer vers le nouveau modèle du fournisseur et rejouer toute la batterie d'évaluation, retoucher les prompts et refaire la revue de sécurité, ou quitter le fournisseur et reconstruire la couche de recherche documentaire ailleurs. Les deux options coûtent de vraies semaines d'ingénierie. L'entreprise n'avait budgété ni l'une ni l'autre, parce qu'au moment de signer, personne n'avait chiffré la sortie.
C'est la décision d'achat d'IA qui engage réellement un conseil d'administration, et la plupart la prennent à l'envers. Un comité demande quel modèle domine le classement du trimestre, signe un contrat au tarif à l'usage avec le vainqueur, et considère le dossier clos. La capacité du modèle passe pour la question difficile. La vraie question difficile, c'est ce que le contrat signé en 2026 permettra encore de faire en 2028, une fois le modèle retiré, le tarif modifié et vos données installées depuis deux ans sur l'infrastructure de quelqu'un d'autre.
Deux éléments de contexte à emprunter, puis à reposer. Les modèles ouverts chinois comme les familles Qwen et GLM accusent désormais un retard sur la frontière américaine de quelques mois plutôt que d'années selon la lecture du CSIS, un écart assez faible pour que la plupart des acheteurs ne le sentent plus à l'usage sur la classification, l'extraction, la rédaction ou la recherche documentaire. Et les hyperscalers américains ont parié dans l'autre sens : Moody's dénombre près de 969 milliards de dollars d'engagements de location contractés chez ces seuls acteurs, pour l'essentiel sur des baux qui n'ont pas encore pris effet. Ce sont des engagements locatifs, un pari que le monde louera de la puissance de calcul à l'usage plutôt que de posséder son infrastructure, et aucun de ces deux chiffres ne dit à un acheteur français ce qu'il doit écrire dans son contrat. C'est là que se joue l'essentiel.
Que doit contenir une clause d'achat d'IA à deux ans ?
Quatre clauses méritent leur place, chacune répondant à un échec déjà observable. D'abord, la portabilité : le droit d'exporter vos prompts, vos données de fine-tuning et vos jeux d'évaluation dans un format exploitable. Cela compte parce que les modèles fermés sont retirés selon le calendrier du fournisseur. OpenAI tient une liste publique de dépréciations des modèles déjà désactivés, chacun assorti d'une date d'arrêt, et un fine-tuning construit sur un modèle de base meurt quand ce socle est retiré. Si vos données d'entraînement et vos évaluations ne vivent que chez le fournisseur, un retrait de modèle devient une reconstruction.
Ensuite, un préavis plafonné sur les hausses tarifaires. La tarification à l'usage évolue dans les deux sens sur ce marché, et un changement de tarif en cours de contrat sans préavis plafonné livre votre modèle économique au fournisseur. Troisième clause, une sortie définie qui restitue ou supprime vos données et les laisse sur une infrastructure que vous contrôlez. Pour un acheteur soumis au RGPD, ce n'est pas un slogan mais une question de transferts internationaux de données à part entière : vos clauses de traitement doivent préciser où résident les prompts et les données de fine-tuning, et imposer la suppression ou la restitution à la sortie. Quatrième clause, un second modèle qualifié disponible derrière une couche d'abstraction, pour qu'une date de retrait devienne un changement de configuration plutôt qu'un projet. Les entreprises qui anticipent traitent le choix du modèle comme un travail de préparation en amont du développement, et le cadrage de l'architecture qui l'entoure relève d'une question de stratégie technique, pas d'un simple achat.
Pourquoi l'adoption des modèles ouverts s'auto-alimente-t-elle ?
Des poids que n'importe qui peut télécharger ne se contentent pas d'être utilisés, ils servent de base à d'autres constructions. Chaque fine-tuning, quantification, adaptateur ou schéma d'intégration publié sur une famille de modèles réduit le coût du prochain projet bâti sur cette même famille. L'outillage se standardise autour d'elle. Les ingénieurs que vous recrutez l'ont déjà pratiquée, parce que c'était ce qu'ils pouvaient faire tourner sur un ordinateur portable en apprenant leur métier. Une API fermée ne peut pas entrer dans cette boucle, puisque ses poids ne quittent jamais le fournisseur : la gravité de l'écosystème se forme donc autour de ce qui est téléchargeable. Pour un acheteur, cette gravité est ce qui rend un plan de repli réaliste : le second choix derrière votre couche d'abstraction n'est bon marché à atteindre que si un écosystème vivant le prend déjà en charge.
Les modèles d'IA open source chinois sont-ils un risque de sécurité ?
Héberger soi-même un modèle referme un risque et en ouvre d'autres, et un conseil d'administration doit entendre les deux moitiés de la phrase. Un modèle exécuté dans votre propre environnement n'appelle pas le fournisseur à chaque requête comme le fait une API hébergée, ce qui constitue une vraie réduction de l'exposition. Cela ne signifie pas qu'il ne communique plus rien nulle part, et quiconque vous le promet exagère. Les poids restent un artefact à la provenance incertaine : vous ne savez pas complètement sur quoi ils ont été entraînés, des fichiers de modèles ont déjà servi de vecteur de logiciels malveillants avec des points de contrôle piégés déposés sur des dépôts publics, et la pile sur laquelle vous les servez, avec la télémétrie et les paquets que votre outillage d'inférence embarque, constitue une surface de risque pour la chaîne d'approvisionnement à part entière. Les lignes directrices sur le développement sécurisé de systèmes d'IA pointent exactement ces éléments à vérifier, quelle que soit l'origine des poids entraînés. Gardez l'humain et la relecture dans la boucle sur tout ce qui a des conséquences, et sécurisez vous-même les systèmes que vous exploitez comme vous le feriez pour n'importe quelle autre chaîne logicielle.
Rien de tout cela ne rend l'auto-hébergement gratuit. Les poids se téléchargent sans frais, mais les tokens consomment toujours du temps GPU, et vous portez vous-même l'exploitation, l'évaluation et l'assurance sécurité. La comparaison honnête n'oppose pas le gratuit au payant à l'usage, elle oppose un coût interne connu que vous maîtrisez à un coût à l'usage que le fournisseur maîtrise. Un conseil d'administration qui inscrit la portabilité, un plafond sur les hausses tarifaires, une sortie de données propre et un plan de repli opérationnel dans son contrat 2026 a acheté la seule chose qu'un classement de modèles ne peut pas lui offrir : la possibilité de changer d'avis en 2028 sans payer pour tout reconstruire.
Questions fréquentes
Comment les modèles ouverts réduisent-ils réellement le verrouillage fournisseur en IA ?
Parce que le modèle tourne sur votre propre matériel et n'est lié à l'API d'aucune entreprise, vous pouvez passer d'un modèle ouvert concurrent à un autre sans réécrire votre application. Cette portabilité plafonne votre exposition à la tarification, au calendrier de dépréciation et à la feuille de route d'un seul fournisseur, exactement l'exposition qu'une API fermée à l'usage est conçue pour préserver. En pratique, l'astuce consiste à garder un second modèle qualifié derrière une couche d'abstraction, pour que changer reste un simple ajustement de configuration plutôt qu'une reconstruction.
Que doit contenir un contrat d'IA à deux ans pour une entreprise française ?
Quatre clauses méritent leur place : un droit d'exporter les prompts, les données de fine-tuning et les jeux d'évaluation dans un format exploitable ; un préavis plafonné sur les hausses tarifaires ; une sortie définie qui restitue ou supprime vos données et les laisse sur une infrastructure que vous contrôlez ; et une obligation qui permette d'utiliser un modèle de repli sans renégocier tout le contrat. Ensemble, ces clauses chiffrent le verrouillage que vous acceptez plutôt que de prétendre qu'il n'existe pas, et la clause de sortie des données est précisément celle où le RGPD s'applique concrètement.
L'utilisation d'un modèle d'IA open source chinois pose-t-elle un problème RGPD ?
Si vous l'auto-hébergez, les données personnelles restent dans votre environnement, ce qui réduit fortement la question du transfert international. Cela ne dissout pas vos obligations : vous restez responsable de traitement, et vos obligations de sécurité et de redevabilité au titre du RGPD s'appliquent intégralement. Le risque technique bascule alors vers la provenance du modèle et la chaîne d'approvisionnement de la pile sur laquelle vous le servez, ce que les lignes directrices sur le développement sécurisé de l'IA visent précisément à couvrir. Si vous appelez à la place une API hébergée chinoise, vous exportez des données à l'étranger et les règles de transfert du RGPD s'appliquent en plus, comme pour tout sous-traitant situé hors de l'Union.
À lire aussi
- La croissance IA de votre cloud est en partie un aller-retour financier. Passez au crible avant de signer
- Mégadeals de l'IA : l'annonce n'est pas le contrat
- Le chiffre sans repère : les capteurs de glucose transforment les objets connectés fitness en machines à anxiété
- Data & Strategy
Rédigé par un persona éditorial IA du système éditorial propriétaire d'Abyshire et relu par notre équipe.