Le prototype fonctionne et votre équipe a chiffré le développement. Avant d’annoncer une date de lancement aux clients, vérifiez ce qui dépend encore d’un fournisseur : l’accès au modèle, les usages autorisés, le financement de l’exploitation ou la possibilité de poursuivre le service autrement.
Une annonce ne garantit pas que votre entreprise pourra utiliser le modèle en production. La propriété d’une réponse générée ne règle pas toutes les conditions de sa réutilisation. Des crédits peuvent financer les essais sans couvrir durablement la fonctionnalité. Ces dépendances méritent une décision avant de devenir un engagement commercial.
Pour un directeur technique, l’objectif est concret : accepter une dépendance connue, réduire le périmètre pour la rendre supportable ou différer l’engagement tant qu’une condition essentielle reste incertaine. Les documents publics éclairent cette décision ; ils ne suffisent pas à établir la situation contractuelle complète de votre entreprise.
L’essentiel en 60 secondes
Avant de promettre une fonctionnalité IA, vérifiez l’accès de l’organisation qui l’exploitera, les usages prévus au regard de l’accord applicable et le budget après les crédits ou tarifs de lancement. Si la continuité repose sur un changement de fournisseur, évaluez le remplaçant sur la tâche réelle et vérifiez que le repli peut fonctionner.
Ces éléments permettent d’arbitrer : accepter la dépendance en précisant ce qui imposerait de la réexaminer, réduire le périmètre à ce qui est établi ou différer lorsqu’une condition incertaine est essentielle à la promesse client.
Dans cet article
- Repérer la dépendance fournisseur qui engage votre produit
- Confirmer l’accès au modèle avant la mise en production
- Vérifier les conditions de l’API et la réutilisation des réponses
- Calculer le coût d’exploitation après les crédits API
- Évaluer la réversibilité avant de changer de fournisseur
- Accepter la dépendance, réduire le périmètre ou différer
1. Repérer la dépendance fournisseur qui engage votre produit
Une dépendance à un fournisseur d’IA apparaît lorsqu’une partie de votre fonctionnalité repose sur des conditions qu’il contrôle : accès à son modèle, usages permis ou tarification, par exemple. Pour un modèle de langage, ou LLM, l’enjeu consiste à relier chaque condition à ce que vous promettez au client.
Ces conditions peuvent changer en quelques jours. Le 3 juin 2025, Varun Mohan, dirigeant de l’outil de code assisté par IA Windsurf, écrivait : « Avec moins de cinq jours de préavis, Anthropic a décidé de couper presque toute notre capacité directe sur tous les modèles Claude 3.x. » Windsurf a dû trouver de la capacité auprès d’autres fournisseurs d’inférence et a prévenu d’indisponibilités possibles à court terme pour les utilisateurs de Claude. Anthropic a indiqué donner la priorité à des « partenariats durables » (TechCrunch).
Prenons un exemple fictif. Un éditeur de logiciels prépare un assistant de support intégré à son produit. Il répond aux questions des clients à partir de l’aide en ligne, cite la page pertinente et transmet les demandes sans réponse établie à une personne. L’équipe envisage aussi d’utiliser, plus tard, les réponses générées puis validées pour entraîner un modèle spécialisé plus petit. Les exemples de fournisseurs ci-dessous servent à examiner différentes hypothèses de ce projet.
Dans notre exemple, cette promesse est une réponse étayée par l’aide à jour, avec un passage au support humain lorsque la documentation ne permet pas de répondre. Elle donne à l’équipe une base d’évaluation : le système retrouve-t-il la bonne page ? Repère-t-il une instruction obsolète ? Que présente-t-il lorsqu’aucune source ne répond à la question ? Que reste-t-il accessible si le modèle est indisponible ?
Séparez ensuite la première version de l’idée d’entraînement ultérieur. Répondre aux clients avec un service existant et réutiliser ses réponses pour entraîner un autre modèle sont deux décisions. Si l’économie du projet suppose déjà ce futur modèle, sa faisabilité et ses autorisations doivent être examinées dès maintenant.
Pour chaque hypothèse qui peut modifier le périmètre, la date ou le budget, conservez les éléments utiles à la décision : modèle précis, mode d’accès, document applicable ou réglage du compte, date de vérification et conséquence d’un changement. Désignez qui doit lever l’incertitude et suivre l’évolution de la condition.
La fin prévue d’un tarif de lancement ou d’un avantage dépendant de l’éligibilité se distingue d’une modification contractuelle ultérieure. Par exemple, la clause M.3 d’Anthropic prévoit que les mises à jour prennent effet 30 jours après leur publication ou la réception d’une autre notification par le client. Celles qui répondent à un changement de loi ou de réglementation s’appliquent immédiatement dès publication ou notification ; les modifications ne sont pas rétroactives.
Dans votre dossier de décision, relevez la clause applicable à votre accord, les canaux où paraissent les mises à jour et les notifications, la personne qui les suit et le changement qui impose de réexaminer l’engagement produit. Vous obtenez ainsi un point de vigilance relié à une décision précise, plutôt qu’une liste de documents sans conséquence sur le projet.
2. Confirmer l’accès au modèle avant la mise en production
L’annonce de Gemini 4 Carbon par Google, le 28 octobre 2026, décrit un déploiement progressif. L’accès commence auprès d’un groupe d’acteurs de la cyberdéfense, puis doit s’étendre à d’autres partenaires de confiance. Une disponibilité plus large pour les développeurs et les entreprises est présentée comme une étape à venir. Cette annonce n’établit donc pas l’accès de votre organisation.
Google annonce aussi un tarif de lancement de 2 USD par million de jetons en entrée et de 10 USD en sortie, puis de 4 et 20 USD après cette période, sans date de fin. L’annonce précise toutefois que Carbon sort au même tarif de lancement qu’Argon, et la page de tarifs de Google affiche ces tarifs pour Argon jusqu’au 30 novembre 2026, puis 4 et 20 USD à partir du 1er décembre. Carbon n’y figurait pas le 6 novembre : sa propre date reste donc ouverte.
Pour l’assistant de support, la question immédiate est de savoir si l’organisation qui exploitera le produit peut appeler le modèle par le canal prévu. Une démonstration réussie sur un autre compte ne répond pas à cette question.
Vérifiez le compte, l’API disponible et la capacité nécessaire à la charge attendue avant de faire de ce modèle une condition du lancement. Si l’accès reste incertain, vous pouvez évaluer une solution disponible, adapter la fonctionnalité à ce qui est accessible ou maintenir une réserve explicite sur la date. Attendre un modèle précis peut se défendre, à condition d’expliquer quelle exigence du produit le rend nécessaire.
La vérification que nous ferions en premier tient en un seul test : faire passer la fonctionnalité par le compte d’entreprise qui l’exploitera, avec vos propres documents, à un volume réaliste et aux tarifs payants. Ce test couvre à la fois l’accès, les quotas, la qualité et le coût.
Chiffrez également l’exploitation au tarif applicable après la période de lancement. Tant que la date de fin du tarif réduit n’est pas établie, gardez sa durée comme une inconnue dans le prévisionnel.
3. Vérifier les conditions de l’API et la réutilisation des réponses
Les conditions commerciales standard d’Anthropic, en vigueur depuis le 17 juin 2025, traitent de la propriété des réponses dans la section B et des usages concurrents dans la section D.4. Celle-ci interdit d’accéder aux services pour construire un produit ou service concurrent, « including to train competing AI models or resell the Services except as expressly approved by Anthropic ». La seule lecture du passage sur la propriété laisserait cette restriction de côté.
La page d’aide française sur l’entraînement à partir des réponses de Claude conserve une ambiguïté. Son introduction évoque largement une autorisation écrite pour l’entraînement et le développement de modèles. Une autre partie permet des modèles spécialisés non concurrents, comme des classificateurs et des outils de résumé. Les exemples interdits incluent les chatbots à usage général, les modèles conçus pour la génération de texte ouverte et les réponses utilisées comme cibles d’entraînement, et un modèle de support entraîné sur des réponses validées pourrait s’en approcher. Ces passages ne permettent pas de trancher chaque usage envisagé.
Revenons à notre assistant. Décrivez précisément l’enchaînement prévu : réponse générée, validation humaine, conservation comme exemple d’entraînement, modèle spécialisé obtenu et utilisateurs visés. Soumettez ce cas concret au fournisseur pour clarification au regard de l’accord applicable. Si nécessaire, faites examiner ce point contractuel avant de fonder la décision sur une permission supposée.
Décidez en parallèle si la première version présente un intérêt sans cet entraînement ultérieur. Si oui, vous pouvez maintenir cette évolution hors du périmètre promis tant que la question reste ouverte. Si la rentabilité supposée repose sur elle, l’incertitude concerne déjà l’approbation du projet.
Cette distinction évite de faire dépendre le lancement d’une évolution encore mal définie. Elle permet aussi de discuter séparément la valeur de l’assistant actuel et les conditions nécessaires à son évolution, sans présenter la validation humaine des réponses comme une autorisation de réutilisation.
4. Calculer le coût d’exploitation après les crédits API
Le guide OpenAI sur les crédits API liés à ChatGPT décrit un avantage pour les abonnements Pro et Business éligibles, associé à une organisation API. Pour l’activer, il faut notamment être propriétaire de l’abonnement ou de l’espace de travail concerné et de l’organisation API, et utiliser la même adresse e-mail pour les comptes ChatGPT et API. Les crédits mensuels expirent à la fin du cycle de facturation et ne sont pas reportés. Pour les espaces Business prépayés à l’année, l’attribution annuelle expire à la fin du cycle annuel. L’avantage reste soumis aux limites de débit de l’API ; les futures attributions dépendent du maintien de l’avantage et de l’éligibilité.
Pour votre assistant, notez quelle organisation reçoit les crédits et qui en maîtrise le financement. Construisez ensuite une estimation sans cet avantage : questions représentatives, quantité de texte transmise et générée, tarifs payants, recherche documentaire et fonctionnement de l’application.
Comparez ce coût d’exploitation au budget ou au prix prévu pour la fonctionnalité. Vous pouvez alors décider si l’offre reste viable après consommation ou expiration des crédits. Si le coût oblige à réduire l’usage, cette limite doit entrer dans le périmètre du produit avant l’engagement commercial.
Précisez aussi comment l’exploitation sera financée ensuite et ce que verra le client si ce financement manque. Selon le guide, lorsqu’il ne reste aucun crédit, les requêtes API échouent avec une erreur HTTP 429 et le code credit_balance_exhausted. Un solde disponible et une capacité suffisante pour traiter les demandes sont deux éléments à vérifier séparément.
Les crédits peuvent faciliter l’expérimentation. Pour engager une fonctionnalité destinée aux clients, leur intérêt doit être rapproché de leurs conditions d’attribution, de renouvellement et d’expiration, puis d’un budget d’exploitation financé au-delà de cet avantage.
5. Évaluer la réversibilité avant de changer de fournisseur
La réversibilité désigne ici la possibilité de remplacer le fournisseur tout en conservant une expérience acceptable pour cette fonctionnalité. Elle s’évalue à travers le travail nécessaire : adaptation de l’intégration, préparation des données, tests et effet du changement sur les clients.
Une couche d’adaptation autour de l’API peut concentrer les changements d’intégration dans une partie du code. Il reste à vérifier ce que produira le remplaçant dans le système complet.
Un remplacement peut aussi arriver sans décision de votre part. Le journal des modifications de Google du 2 novembre 2026 indique qu’à partir du 1er décembre 2026, toutes les requêtes API vers gemini-2.5-pro seront automatiquement redirigées vers gemini-3.8-flash et facturées aux tarifs de ce modèle. Une fonctionnalité bâtie sur l’ancien modèle change ainsi de modèle et de tarifs à une date publiée : la comparaison ci-dessous doit avoir lieu avant.
Pour l’assistant, comparez les solutions sur les mêmes questions et les mêmes sources. Incluez une page périmée, des instructions contradictoires et une question sans réponse documentée. Examinez les sources citées et le passage au support humain. Évaluez aussi les modifications d’instructions, le traitement des réponses, la recherche documentaire, le délai de réponse et le coût d’exploitation.
Fixez les critères d’acceptation à partir des besoins de la fonctionnalité avant d’interpréter les résultats. Si le remplaçant répond avec aisance mais affirme une réponse que la documentation ne permet pas d’établir, vous avez une décision produit à prendre. Vous pourriez modifier le parcours, introduire une relecture ou conserver le fournisseur initial. Le simple succès d’un appel API n’établirait pas que le remplacement convient.
Le conseil que nous contesterions : garder un fournisseur de secours suffit. Une deuxième intégration prouve qu’un appel aboutit, pas que la fonctionnalité tient encore sa promesse. Garder un secours est raisonnable lorsqu’il a été évalué sur la tâche réelle et que l’équipe sait le faire fonctionner. Il met l’équipe en difficulté lorsqu’il n’existe que dans un code que personne n’a testé depuis son écriture.
Notre guide pour construire un assistant, un agent ou une plateforme IA suit ce principe : le choix des modèles découle de tests sur les documents réels, et l’ajout d’un modèle doit résoudre un problème observé dans le traitement. Il ajoute aussi un composant à évaluer et à exploiter.
Dans notre exemple, une solution de repli pourrait consister à préparer des réponses relues par le support lorsque les réponses automatiques sont indisponibles. Ce fonctionnement modifie l’expérience et la charge humaine. Vérifiez que l’équipe peut l’assurer avant de le présenter comme une continuité de service. Le guide pour arrêter un outil IA sans arrêter l’activité approfondit la question de ce qu’un arrêt contrôlé interrompt.
Une alternative mérite donc sa place lorsqu’elle répond à un besoin identifié et que son fonctionnement est établi pour ce besoin. La présence de plusieurs fournisseurs dans le code ne dispense pas de cette évaluation.
6. Accepter la dépendance, réduire le périmètre ou différer
Ramenez les éléments recueillis à la décision de lancement. Le tableau illustre des choix possibles pour l’assistant fictif ; il ne présente aucun résultat d’implémentation ou de mission client.
| Condition déterminante | Éléments à établir | Décision produit possible |
|---|---|---|
| Accès soumis à un déploiement progressif | Accès de l’organisation par le canal prévu pour la production, avec la capacité nécessaire | Garder une réserve sur le lancement ou évaluer une solution disponible |
| Réutilisation des réponses pour l’entraînement encore incertaine | Accord applicable et clarification du processus d’entraînement prévu | Sortir l’entraînement du périmètre promis ; différer s’il conditionne la viabilité |
| Budget fondé sur des crédits ou un tarif de lancement | Éligibilité, expiration, tarifs ultérieurs et estimation d’exploitation financée | Accepter le coût payant, réduire le périmètre ou revoir le modèle économique |
| Continuité dépendante d’une autre solution | Évaluation sur la tâche attendue et fonctionnement du repli | Accepter l’interruption, limiter la promesse ou financer l’alternative nécessaire |
Accepter une dépendance peut être raisonnable. Vous pourriez retenir un fournisseur unique pour une première version limitée parce que l’accès est établi, l’usage prévu clarifié, le coût payant supportable et une interruption définie acceptable. Conservez le raisonnement et l’événement qui impose de le réexaminer.
Réduire le périmètre est utile lorsque la partie intéressante du produit peut fonctionner sans l’hypothèse incertaine. L’assistant pourrait être lancé sans engagement sur l’entraînement futur, ou préparer des réponses à valider avant leur envoi. La feuille de route et la communication client doivent décrire cette expérience réelle.
Différez l’engagement lorsqu’une condition manquante est essentielle. Si la fonctionnalité exige un modèle indisponible ou dépend financièrement d’un entraînement dont les conditions restent à confirmer, poursuivre le développement ne résoudra pas ce point.
Notre propre limite est la suivante. Nous construisons sur un seul fournisseur lorsque l’accès est confirmé sur le compte de production, que l’usage est autorisé et que le coût payant tient dans le budget. Nous ne promettons pas de date sur un modèle auquel vous n’avez pas encore accès, ni « nous pouvons changer à tout moment » tant que le changement n’a pas été testé.
Conclusion : préparer le prochain arbitrage produit
En réunion de travail avec un directeur technique, nous le disons ainsi : « Avant de promettre cette fonctionnalité, listons ce qui doit rester vrai côté fournisseur : l’accès, les conditions et le prix. Ce que nous ne contrôlons pas entre dans le plan comme un risque, avec une date pour le revérifier. »
Pour la prochaine réunion produit, prenez la fonctionnalité en attente d’arbitrage et identifiez son hypothèse non établie la plus lourde de conséquences. Joignez les éléments actuels, désignez qui doit éclaircir le point et écrivez ce que chaque réponse changerait dans le périmètre, la date ou le budget. Vous aurez une décision concrète à prendre.
Examinons votre choix de fournisseur
Si cet arbitrage demande un regard technique extérieur, apportez la promesse client, l’architecture envisagée, le mode d’accès au fournisseur et la condition non résolue à la revue d’architecture et de feuille de route de notre service CTO fractionné. Cette intervention couvre notamment les choix de fournisseurs et débute par un devis fixe pour le périmètre convenu.
Questions fréquentes
La propriété des réponses ne règle pas à elle seule les usages permis du service. Dans l’exemple d’Anthropic, les conditions commerciales restreignent séparément les usages concurrents et la page d’aide laisse des questions ouvertes sur certains processus d’entraînement. Décrivez l’usage envisagé et faites-le clarifier au regard de l’accord applicable avant de compter sur cette réutilisation.
Ils peuvent contribuer au financement tant qu’ils sont disponibles selon leurs conditions. Pour approuver la fonctionnalité, chiffrez l’exploitation aux tarifs payants applicables et précisez qui la financera après consommation ou expiration des crédits. Vérifiez la capacité de l’API séparément du solde.
Ajouter un fournisseur ne suffit pas à établir la réversibilité. Le remplaçant doit répondre aux critères de la fonctionnalité sur des cas représentatifs, et l’équipe doit pouvoir assurer le repli prévu. La décision doit inclure les changements de comportement, le travail d’intégration, le coût et la charge humaine.
Sources et limites
Sources consultées le 6 novembre 2026. Les documents fournisseurs cités étayent les points précis concernant l’accès, les conditions, les tarifs et les crédits. Le cas Windsurf provient de l’article de TechCrunch du 3 juin 2025, qui cite les deux entreprises.
L’assistant de support est fictif : aucun comparatif, migration ou exercice de reprise n’a été réalisé pour cet article. L’accord applicable et la configuration de votre compte doivent être vérifiés avant de vous appuyer sur ces exemples pour décider d’une mise en production. Les positions présentées comme les nôtres sont des recommandations, pas les résultats d’un projet mesuré.