build, buy ou embed : évaluer les fournisseurs d'IA

Un éditeur SaaS de taille moyenne spécialisé dans le support client a passé 14 mois et environ 2 millions de dollars à construire en interne un classificateur de tickets par IA. Au moment de la mise en production, les APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → sur étagère d'OpenAI et d'Anthropic atteignaient la même précision pour une fraction du coût. L'équipe n'avait pas construit un moatmoatUn avantage durable sur les concurrents : une ressource, une capacité ou une position qu'ils ne peuvent pas répliquer facilement, et qui permet à une entreprise de dégager des rendements supérieurs à la moyenne dans la durée.Voir la définition complète →. Elle avait construit une pièce de musée.

Ce scénario se répète chaque trimestre dans le secteur SaaS. La décision n'est pas idéologique (build bien, buy mal). C'est un arbitrage entre coût, contrôle et vitesse, qui change selon ce que la fonctionnalité IA apporte réellement à votre produit.

Les trois voies

Build : développer la capacité IA en interne, généralement en fine-tunant des modèles open-weight (des modèles comme Llama de Meta ou Mistral dont les poids, les paramètres appris, sont téléchargeables publiquement) ou en entraînant des modèles sur mesure à partir de données propriétairesdonnées propriétairesDonnées collectées directement auprès de vos clients et prospects via vos propres canaux : votre source la plus fiable et la plus conforme en matière de privacy.Voir la définition complète →.

Buy : acheter une point solution, un produit fournisseur conçu pour une tâche précise (un outil de détection de fraude, un trieur de CV, un moteur de transcription d'appels).

Embed : appeler l'API d'un modèle de fondation (un grand modèle de langage généraliste accessible par internet, comme GPT-4o, Claude ou Gemini) et construire autour votre propre logique produit et votre interface.

En 2026, la plupart des sociétés SaaS utilisent les trois simultanément, pour des fonctionnalités différentes. La compétence consiste à associer la bonne voie au bon cas d'usage.

Noter les arbitrages

Coût total

Le build paraît bon marché sur un slide (juste des salaires d'ingénieurs) mais masque des coûts : labellisation des données, calcul GPU/cloud, réentraînement continu, et le coût d'opportunité de vos meilleurs ingénieurs qui ne livrent pas le produit principal. Une fourchette crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →édible pour un modèle sur mesure avec une fiabilité réelle en production : de plusieurs centaines de milliers à quelques millions de dollars la première année, hors maintenance.

Le buy a un coût visible et prévisible : un abonnement ou une facturation à l'usage. Des fournisseurs comme Intercom (Fin), Zendesk ou des acteurs spécialisés de la détection de fraude (par exemple Sift) facturent au siège ou à la résolution. Facile à budgéter, plus difficile à personnaliser.

Le coût de l'embed évolue avec l'usage. Début 2026, la tarification des API OpenAI et Anthropic se situe entre quelques dollars et quelques dizaines de dollars par million de tokenstokensUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète → selon le niveau de modèle (estimation approximative, publique, qui change fréquemment : consultez la page tarifs d'OpenAI pour les taux en vigueur). Les coûts sont variables mais les frais fixes faibles. Une startup peut prototyper pour moins de 500 $.

Exemple chiffré : un éditeur SaaS ajoute une fonctionnalité de résumé par IA sur 10 000 appels clients par mois, avec en moyenne 1 500 tokens de sortie chacun.

• 10 000 appels × 1 500 tokens = 15 000 000 tokens/mois
• À un tarif illustratif de 10 $ par million de tokens de sortie : 15 × 10 $ = 150 $/mois
• À comparer à une point solution facturée 0,50 $ par appel : 10 000 × 0,50 $ = 5 000 $/mois
• À comparer au build : un ingénieur ML à environ 180 000 $/an en coût complet, plus le compute, dépasse facilement 20 000 $/mois amortis la première année.

L'embed l'emporte ici sur le pur coût, sauf si le volume d'appels est multiplié par 100 : la facture API crocroLe Conversion Rate Optimization (CRO) est la pratique systématique visant à augmenter le pourcentage d'utilisateurs qui réalisent une action souhaitée, en s'appuyant sur la data, les tests et la recherche utilisateur.Voir la définition complète →ît alors linéairement et l'économie du buy ou du build change.

Lock-in

Le lock-in est le degré auquel changer de fournisseur plus tard coûte cher ou prend du temps. Il en existe trois formes :

• Lock-in de données : vos données propriétaires vivent dans le système d'un fournisseur et les extraire ou les réutiliser est difficile.
• Lock-in de workflow : les processus de votre équipe sont construits autour de l'UI et des particularités d'un outil.
• Lock-in de modèle : vos prompts, votre fine-tuningfine-tuningLe fine-tuning adapte un modèle pré-entraîné à une tâche ou un domaine précis en poursuivant son entraînement sur un jeu de données plus petit et ciblé, ce qui améliore la précision et le style pour ce cas d'usage.Voir la définition complète → et votre harnais d'évaluation sont calibrés sur le comportement spécifique d'un modèle.

Acheter une point solution implique généralement le lock-in le plus profond : changer de fournisseur de détection de fraude signifie réintégrer des API, reformer les équipes et souvent perdre le tuning historique du modèle.

Embarquer des modèles de fondation implique un lock-in modéré. Les fournisseurs supportent de plus en plus des formats portables, et les alternatives open-weight (Llama, Mistral, Qwen) permettent de s'auto-héberger si le prix ou la politique d'un fournisseur change. Mais le prompt engineeringprompt engineeringLe prompt engineering consiste à concevoir et affiner des instructions textuelles pour guider les grands modèles de langage vers des réponses justes, pertinentes et fiables.Voir la définition complète → et les pipelines d'évaluation sont rarement totalement portables d'une famille de modèles à l'autre sans retravail.

Le build présente le moins de lock-in fournisseur mais le plus de lock-in interne : les décisions non documentées de votre propre équipe deviennent la dépendance.

Time-to-value

L'embed est le plus rapide. Un prototype fonctionnel avec les API GPT ou Claude peut être livré en quelques jours. C'est pourquoi presque toutes les fonctionnalités IA SaaS annoncées entre 2023 et 2026 ont commencé par un appel d'API embarqué.

Le buy est rapide si le cas d'usage du fournisseur correspond étroitement au vôtre ; lent s'il faut beaucoup de personnalisation (intégration, revue de sécurité, achats peuvent prendre des mois en contexte entreprise).

Le build est presque toujours le plus lent. Même des modèles sur mesure simples exigent collecte de données, labellisation, entraînement, évaluation et tests de sécurité avant la mise en production.

Un framework de décision

Posez trois questions avant de choisir :

1. Cette capacité est-elle au cœur de votre avantage concurrentiel ? Si l'IA *est* votre produit (par exemple un assistant de code IA), le build ou une personnalisation poussée se justifie probablement. Si l'IA est une fonctionnalité greffée sur un outil de workflow existant (par exemple le résumé automatique de tickets dans un CRM), embed ou buy.

1. La tâche sous-jacente est-elle banalisée ? Le résumé de texte, la traduction et la classification basique sont désormais des capacités de commodité chez tous les fournisseurs de modèles de fondation. Le build y est rarement rentable. Des tâches très spécifiques à un domaine (par exemple l'analyse de contrats juridiques de niche avec une taxonomie propriétaire) peuvent justifier un fine-tuning ou une point solution spécialisée.

1. Quel est votre volume d'usage réaliste et votre courbe de croissance ? Un faible volume favorise l'embed (coût fixe quasi nul). Un volume très élevé et stable peut inverser le calcul en faveur du build ou de l'auto-hébergement d'un modèle open-weight, puisque les coûts d'API croissent linéairement à l'infini alors que les coûts d'infrastructure peuvent s'aplatir.

Un test de bon sens utilisé par plusieurs responsables produit SaaS : si vous ne pouvez pas défendre en une phrase pourquoi cette capacité IA doit être propriétaire, choisissez l'embed par défaut.

Checklist d'évaluation pour tout fournisseur ou API

Avant de signer quoi que ce soit, les acheteurs SaaS devraient pousser les fournisseurs sur :

• Des benchmarks sur vos données, pas les leurs. Les benchmarks publics (comme ceux suivis par HELM de Stanford) montrent une capacité générale, pas la performance sur vos documents ou le langage de vos clients.
• Traitement et localisation des données. Où vont vos données ? Sont-elles utilisées pour entraîner davantage le modèle ? Pour des clients européens, le fournisseur répond-il aux exigences du RGPD (Règlement général sur la protection des données) sur les contrats de sous-traitance ?
• SLA de latence et de disponibilité (Service Level Agreements, garanties contractuelles sur le temps de réponse et la disponibilité).
• Plan de sortie. Pouvez-vous exporter vos données de fine-tuning, vos prompts et vos logs si vous partez ?
• Exposition réglementaire. Sous l'AI Act européen (entrée en vigueur par phases de 2025 à 2027), certains cas d'usage IA « à haut risque » (par exemple le scoring de crédit, le tri de candidatures) comportent des obligations de documentation et de transparence qui incombent en partie à l'entreprise qui déploie, pas seulement au fournisseur du modèle. Si vous achetez ou embarquez de l'IA dans un workflow réglementé, demandez qui porte la conformité.

Une brève illustration technique

Voici à quoi ressemble concrètement l'« embed » : quelques lignes appelant l'API d'un modèle de fondation pour classer des tickets de support.

from openai import OpenAI
client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "Classify ticket urgency: low, medium, high."},
        {"role": "user", "content": ticket_text}
    ]
)
print(response.choices[0].message.content)

C'est là toute la « fonctionnalité IA » de beaucoup de produits SaaS dans leur première version livrée. La décision de build ne devient pertinente que plus tard, si la précision, le coût à l'échelle ou les exigences de confidentialité des données imposent de passer au fine-tuning ou à l'auto-hébergement.

À retenir

• Associez la voie au cas d'usage, pas à la tendance. Les tâches de commodité (résumé, classification) favorisent l'embed ; les différenciateurs cœur peuvent justifier le build ; les tâches étroites et réglementées peuvent favoriser une point solution spécialisée.
• Les comparaisons de coûts doivent inclure les coûts cachés. Le build masque le temps d'ingénierie et la maintenance ; le buy masque les limites de personnalisation ; l'embed masque les coûts de montée en charge sur le long terme.
• Le lock-in n'est pas binaire. Notez-le séparément sur les dimensions données, workflow et modèle avant de signer un contrat.
• La vitesse favorise presque toujours l'embed. Utilisez-le pour valider la demande avant d'engager un investissement plus lourd en build ou en buy.
• Les obligations de conformité (AI Act européen, RGPD) restent souvent à la charge de l'entreprise SaaS qui déploie, quelle que soit la voie choisie : les contrats fournisseurs doivent donc préciser qui porte quelle documentation.