La mauvaise question, c’est “quelle IA choisir”. La bonne, c’est “qui contrôle l’inférence”. Trois familles d’arbitrages, qui n’ont pas les mêmes acteurs au bout, pas les mêmes engagements contractuels, et pas la même exposition réglementaire à dix-huit mois.

L’API propriétaire d’un acteur américain

Vous appelez une API. Vous payez par token. Vous ne vous occupez ni de l’infra, ni de la maintenance du modèle, ni des mises à jour.

En pratique : vous sous-traitez à un acteur américain la couche d’intelligence de vos processus. Vous n’avez aucun contrôle sur les changements de modèle, les changements de prix, la disponibilité, les politiques d’utilisation. Vous avez un SLA contractuel, mais si OpenAI change sa politique de formation des données ou ses tarifs, vous vous adaptez ou vous changez.

Quand c’est adapté : prototypage rapide, usage non critique, données non sensibles, pas de contrainte réglementaire sur la localisation. Budget opex préférable au capex.

Le risque qu’on sous-estime : la dépendance de fournisseur. Migrer d’un modèle à un autre est faisable, mais ça coûte. Le prompt engineering développé pour GPT-4 ne se transfère pas à l’identique sur Claude ou Llama. Il y a une dette de migration réelle.

Une solution verticale achetée à un éditeur tiers

Vous achetez une solution d’un éditeur qui a construit une application IA pour votre secteur : CRM avec IA intégrée, outil de génération juridique, assistant de support client.

En pratique, c’est presque toujours un wrapper d’API (GPT, Claude ou autre) avec une couche applicative. La valeur ajoutée est dans l’interface, le prompt système, éventuellement le fine-tuning sur des données sectorielles.

Quand c’est adapté : pas de ressources techniques en interne, la solution couvre précisément votre cas d’usage, et la dépendance fournisseur est acceptable.

Ce qu’on oublie de regarder : vous avez une dépendance double. Envers l’éditeur de la solution. Envers le modèle sous-jacent. Si l’éditeur disparaît, change de modèle ou change ses prix, votre capacité à migrer est limitée par la réalité des contrats signés.

Le modèle open weights sur votre propre infra

Vous déployez un modèle open weights (Llama 3, Mistral, Mixtral, Qwen…) sur votre infrastructure. Vous contrôlez l’inférence, les données, les versions.

Ce que ça demande : un capex en infrastructure (GPU/APU) ou des coûts cloud GPU, plus des compétences internes en MLOps. La performance est inférieure aux modèles frontière propriétaires sur les tâches génériques, mais souvent comparable sur les tâches spécialisées après fine-tuning.

Quand c’est adapté : données sensibles, contrainte réglementaire (RGPD, secret industriel, secret défense), volumes d’inférence élevés qui rentabilisent le capex, volonté de maîtrise à long terme.

Sur le coût : un serveur avec 2 GPU H100 pour inférer un modèle de 70 milliards de paramètres coûte 50 à 70 000 euros en achat. L’amortissement sur 3 ans peut être inférieur aux coûts API équivalents si le volume est suffisant.

La variable manquante : la souveraineté

La plupart des comparaisons build/buy/api s’arrêtent aux coûts. Elles oublient la question de la souveraineté.

Si votre différenciation concurrentielle repose sur vos données propriétaires, envoyer ces données à une API tierce pour du fine-tuning (même avec garantie contractuelle de non-réutilisation) crée un risque que vous devez évaluer consciemment. Une dépendance critique à une API américaine crée aussi une exposition aux décisions réglementaires (export controls, restrictions sectorielles), aux pannes, et aux changements de politique. Ce risque est faible en probabilité, potentiellement élevé en impact.

Le RGPD, les obligations de l’AI Act, et les réglementations sectorielles (santé, finance) peuvent imposer des contraintes sur la localisation et le traitement des données qui rendent certaines architectures API non conformes.

Le bon arbitrage

Le bon arbitrage n’est pas une réponse, c’est une grille. Sensibilité des données, volume d’inférence, ressources internes, tolérance à la dépendance, exposition réglementaire à 36 mois. Aucune entreprise ne signe sur les cinq dimensions de la même manière. Ce qui est constant : aller à l’API la plus connue parce que c’est celle dont parle votre fournisseur, sans avoir regardé l’option open weights sur votre propre infra, c’est ne pas avoir pris la décision. C’est avoir laissé quelqu’un d’autre la prendre à votre place.