Acheter une capacité d'IA à un fournisseur ressemble, en apparence, à l'achat de tout autre logiciel: une démonstration, un pilote, un contrat, un déploiement. Mais l'actif sous-jacent diffère de manières que la plupart des processus d'achat ne sont pas conçus pour détecter. Le modèle, les prompts, les données d'affinage et l'historique d'évaluation accumulent de la valeur au fil du temps, et si rien de tout cela ne vous appartient contractuellement, vous n'achetez pas une capacité, vous en louez une indéfiniment à un prix que le fournisseur fixera plus tard.
Les organisations qui se brûlent ne sont pas naïves. Ce sont des acheteurs prudents qui ont mené une évaluation approfondie du produit et qui n'ont simplement jamais posé la question de la sortie, car au moment de la signature, la sortie semblait la clause la moins pertinente du document. Cela rarement le reste.
Ce que vous achetez réellement
Séparez, dès le stade contractuel, ce qui appartient réellement en propre au fournisseur de ce qui est généré par votre utilisation de son produit. Les poids du modèle de base appartiennent au fournisseur; c'est normal et rarement négociable. Mais vos prompts, vos données d'affinage, vos jeux d'évaluation et les résultats générés pour votre entreprise relèvent d'une autre catégorie, et les fournisseurs laisseront volontiers un langage ambigu leur en attribuer plus qu'il ne le devrait.
Lisez la clause sur les droits relatifs aux données comme si vous prévoyiez de partir dans dix-huit mois, car c'est exactement le scénario qu'elle doit pouvoir supporter. Si le texte n'affirme pas clairement que vos données d'entrée, vos données dérivées et vos historiques d'évaluation sont extractibles sur demande dans un format exploitable, supposez que ce n'est pas le cas.
Si le contrat ne dit pas comment vous partez, supposez que le fournisseur a déjà décidé que vous ne partirez pas.
La portabilité est une exigence technique, pas seulement juridique
Une clause contractuelle promettant la portabilité des données vaut peu si le format d'export réel est propriétaire, non documenté ou livré si lentement qu'il est inutilisable pour une migration active. Avant de signer, demandez au fournisseur de démontrer un export, pas de le décrire, et faites tenter à votre propre équipe technique de le charger dans un format neutre.
Le même principe s'applique aux modèles affinés et aux configurations personnalisées. Si le processus d'affinage du fournisseur ne fonctionne que sur sa plateforme et ne produit aucun artefact exportable, vous avez intégré une dépendance dans votre propre feuille de route produit. Exigez de savoir, avant d'engager un budget d'affinage, ce qu'il advient de cet investissement si vous partez.
- ·Exiger un chemin d'export documenté et testé pour les prompts, les jeux d'évaluation et les données d'affinage avant de signer
- ·Demander quelle part de votre investissement en personnalisation est portable par rapport à ce qui est spécifique au fournisseur
- ·Négocier des droits d'évaluation permettant de comparer le fournisseur à des alternatives en continu, pas seulement lors de l'achat
- ·Fixer des préavis contractuels assez longs pour réellement achever une migration, pas seulement pour l'annoncer
Les droits d'évaluation protègent contre la dérive
Les produits d'IA évoluent sous leurs contrats plus que les logiciels traditionnels: les modèles sont mis à jour, réentraînés, retirés, et le résultat évalué à la signature peut ne plus ressembler à celui obtenu dix-huit mois plus tard. Les contrats qui ne vous donnent pas un droit permanent de réévaluer la performance par rapport à des repères convenus vous empêchent de prouver contractuellement que le produit s'est dégradé, même quand vos utilisateurs le ressentent.
Intégrez au contrat des fenêtres de réévaluation à intervalles fixes, avec des repères clairement définis et un véritable recours, pas seulement une conversation, si le fournisseur ne les atteint pas. C'est la clause que les fournisseurs résistent le plus à accepter, ce qui indique à quel point elle vaut la peine d'être obtenue.
Le plan de sortie appartient au contrat, pas à une crise
Toute relation avec un fournisseur d'IA devrait comporter un plan de sortie écrit, convenu avant la mise en service: quelles données partent, sous quel format, sur quel délai et à quel coût. Considérez l'absence de ce plan comme un signal d'alerte, quelle que soit la qualité de la démonstration du produit, car un bon produit aujourd'hui ne dit rien des conditions de départ demain.
Cela n'a rien d'hostile. Un fournisseur confiant dans son produit devrait accepter sans difficulté des conditions de sortie, car il parie sur le fait d'être assez bon pour que vous ne les utilisiez jamais. Ceux qui résistent vous disent quelque chose d'important sur la façon dont ils comptent conserver votre activité.
Rien de tout cela ne plaide contre l'achat d'IA auprès de fournisseurs plutôt que sa construction en interne; pour la plupart des organisations, l'achat reste le bon choix. Cela plaide pour négocier le contrat avec la même rigueur que toute dépendance stratégique, plutôt que de le traiter comme un simple achat logiciel parce que la conversation commerciale semblait familière.
Le coût d'une erreur ici apparaît rarement à la signature. Il apparaît deux ans plus tard, quand le dossier d'affaires pour changer de fournisseur est solide et que le contrat rend discrètement ce changement impossible.