Votre démonstration fonctionne, les premiers clients signent, les usages décollent. Puis un courriel arrive : le modèle qui fait tourner votre produit sera remplacé, son tarif évolue ou certaines utilisations seront désormais encadrées autrement. Pour une start-up, ce message peut transformer une semaine commerciale prometteuse en chantier d’urgence. La dépendance aux plateformes d’IA n’est pas seulement une question d’infrastructure : elle touche la marge, la promesse client et la liberté stratégique. À l’horizon de septembre 2026, les évolutions déjà observées permettent d’identifier les risques — sans prétendre connaître les prochaines décisions des fournisseurs.
Une dépendance plus profonde qu’une simple API
Le phénomène n’a rien d’inédit. Les entrepreneurs connaissent les changements d’algorithme des réseaux sociaux, les commissions des boutiques d’applications et les factures du cloud. Mais l’IA générative ajoute une difficulté : le service acheté n’a pas un comportement parfaitement stable. Deux modèles capables de répondre à la même requête peuvent produire des résultats très différents dans un processus métier.
Changer de fournisseur ne consiste donc pas seulement à modifier une adresse dans le code. Il faut vérifier les réponses, les refus, les formats, les appels d’outils et les performances dans les langues utilisées. Une consigne soigneusement optimisée pour un modèle peut fonctionner médiocrement ailleurs. Le véritable verrouillage se loge souvent dans les tests absents et les réglages accumulés.
Les signaux sont déjà tangibles. Les dépréciations successives de versions d’API chez OpenAI ont installé la migration dans le quotidien des développeurs. La panne majeure de ses services en novembre 2023 a rappelé le risque de concentration. L’arrivée de Claude 3 puis de GPT-4o en 2024 a, elle, illustré la vitesse du renouvellement. Ces événements ne prédisent aucun retrait précis en 2026 ; ils justifient de préparer le suivant.
Le tarif affiché n’est pas votre coût de revient
Pour un fondateur, le prix au million de jetons constitue un repère commode, mais incomplet. Une fonctionnalité peut mobiliser plusieurs appels, un long historique, des documents, des reprises après erreur et un modèle supplémentaire chargé de contrôler la réponse. À cela s’ajoutent éventuellement la recherche documentaire, le stockage et les interventions humaines.
Prenons un assistant qui prépare des réponses pour un service client. Si une nouvelle version exige davantage de contexte ou produit plus de réponses à corriger, son coût réel peut augmenter malgré un tarif unitaire inférieur. À l’inverse, un modèle plus cher peut devenir rentable s’il évite plusieurs tentatives. La bonne unité économique est la tâche réussie, pas le jeton consommé.
Dès les premiers contrats, l’équipe doit suivre le coût par opération utile et par client, puis simuler plusieurs tensions : hausse tarifaire, disparition d’une remise, usage plus intensif, bascule vers un modèle de secours. Un abonnement « illimité » vendu avant cette analyse peut devenir un engagement impossible à tenir. Mieux vaut prévoir des volumes inclus, des alertes et des règles de dépassement lisibles.
Construire une sortie sans bâtir une usine à gaz
La portabilité ne signifie pas maintenir cinq fournisseurs en permanence. Une jeune entreprise doit d’abord livrer un produit utile. En revanche, quelques choix précoces évitent de transformer chaque évolution en réécriture générale.
Séparer le métier du fournisseur
Les règles métier, les droits d’accès et les données clients ne devraient pas être enfouis dans une intégration propriétaire. Une couche interne peut centraliser les appels, les délais d’attente, les reprises et la mesure des coûts. Elle doit aussi rendre visibles les différences entre fournisseurs : une interface commune ne garantit pas des capacités identiques.
Les consignes, schémas de sortie et configurations doivent être versionnés hors des consoles du prestataire. Lorsque le produit utilise une recherche documentaire, conserver les documents sources et leurs métadonnées facilite une reconstruction de l’index. Changer de modèle d’embeddings peut imposer de recalculer les représentations vectorielles : cette opération demande du temps et mérite un budget.
Tester une vraie solution de repli
Une seconde clé API rangée dans un coffre ne constitue pas un plan de continuité. Le modèle alternatif doit être évalué sur des situations représentatives : dossiers difficiles, français imparfait, documents longs, tentatives de manipulation et sorties structurées. Les données de test doivent être anonymisées ou utilisées dans un cadre autorisé.
- Qualité : la réponse reste-t-elle exploitable pour le métier ?
- Fiabilité : les formats attendus et les garde-fous tiennent-ils ?
- Exploitation : les délais, quotas et coûts restent-ils acceptables ?
- Conformité : le traitement respecte-t-il les engagements pris envers le client ?
Cette qualification doit déboucher sur une décision simple : quelles fonctions peuvent basculer, lesquelles passent en mode dégradé, lesquelles doivent s’arrêter ? Pour une opération sensible, mieux vaut suspendre une réponse que fournir silencieusement un résultat moins sûr.
Le contrat est une composante du produit
Aux débuts, beaucoup de start-up acceptent des conditions standard avec une carte bancaire. C’est rapide, mais ce cadre n’offre pas nécessairement les garanties attendues par leurs propres clients. Avant de promettre une disponibilité élevée ou une localisation stricte des données, il faut vérifier ce que le fournisseur garantit réellement, pour l’offre effectivement souscrite.
La négociation doit viser les points qui peuvent interrompre l’activité : préavis de retrait d’un modèle, notification des changements tarifaires, quotas, assistance et modalités de suspension. Un engagement de disponibilité peut prévoir des avoirs plutôt qu’une indemnisation des pertes commerciales. Il faut donc lire les exclusions, les plafonds de responsabilité et les recours, pas seulement le pourcentage mis en avant.
Sur les données, les questions sont tout aussi concrètes : les entrées et sorties servent-elles à l’entraînement ? Combien de temps sont-elles conservées ? Quels sous-traitants interviennent, dans quelles régions, et comment obtenir leur suppression ? Une option commerciale de confidentialité ne remplace pas l’examen du contrat de traitement des données. Dans un contexte européen, les engagements doivent notamment être cohérents avec les obligations applicables au titre du RGPD.
Enfin, le contrat client doit refléter cette réalité. Il peut encadrer le recours à des sous-traitants et leur remplacement, préciser les fonctions disponibles en mode dégradé et organiser l’information du client. Attention à ne pas promettre une substitution automatique si elle change les lieux de traitement ou les garanties convenues.
Faire de la réversibilité un exercice régulier
Le meilleur indicateur n’est pas le nombre de fournisseurs intégrés, mais le temps nécessaire pour retrouver un service acceptable. Un exercice de bascule sur un périmètre limité révèle les dépendances cachées : quotas insuffisants, fonctionnalités propriétaires, coûts inattendus. L’hébergement d’un modèle à poids ouverts peut aussi être étudié, sans être présenté comme une indépendance gratuite : calcul, maintenance et compétences restent à financer.
Et maintenant ? Si le marché poursuit son renouvellement rapide, les start-up capables de comparer et de changer leurs composants devraient mieux absorber les ruptures. L’objectif n’est pas de quitter son fournisseur préféré, mais de pouvoir rester par choix. Dès les premiers clients, une base de tests, un scénario de repli et des engagements contractuels réalistes constituent une assurance stratégique bien plus crédible qu’une promesse de migration « en quelques jours ».
