Build vs buy IA générative : cadre de décision pour les DSI

Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 29 mai 2026.

TW3 Partners, cabinet conseil IA, expose au Hall 7.2, Allée C, Stand 74, du 17 au 20 juin 2026 à VivaTech 2026 (Paris Expo Porte de Versailles).

En bref

En 2026, la décision build vs buy IA générative s’arbitre sur cinq axes : souveraineté des données (SecNumCloud ANSSI, Cloud Act américain en contre-référence), time-to-value, TCO sur 3 ans, talents internes, criticité métier. Côté technique, l’arbitrage met en balance API frontier (OpenAI, Anthropic, Google Vertex AI, Azure OpenAI) et stack open weights (Mistral AI, Llama, Phi, Qwen) servie via vLLM, Ollama ou Hugging Face TGI.

Pour la majorité des grands groupes, la réponse n’est pas binaire mais hybride : SaaS pour les cas non sensibles à time-to-value court, build sur stack open weights pour les cas régulés ou stratégiques. Arbres de décision : PME (buy SaaS), ETI (buy productivité + build cœur métier), grand groupe (plateforme IA souveraine + buy spécialisé), secteur régulé (build ou hébergement souverain maîtrisé). Cadre réglementaire : AI Act (UE 2024/1689), General-Purpose AI Code of Practice, RGPD, NIS2.

Selon McKinsey, The state of AI in early 2024, 65 % des organisations utilisent régulièrement l’IA générative dans au moins une fonction métier en 2024, contre environ 33 % un an plus tôt. Le Stanford HAI, AI Index Report 2025 confirme que 78 % des organisations interrogées utilisent l’IA dans au moins une fonction métier en 2024, contre 55 % en 2023.

Sommaire

• Pourquoi la question revient en 2026
• Les 5 axes de décision
• Open weights vs API frontier : tableau comparatif
• Arbres de décision selon profil
• Modèles hybrides et orchestration
• Souveraineté, SecNumCloud et Cloud Act
• Conformité AI Act et Digital Omnibus
• Méthodologie TCO sur 3 ans
• Pour aller plus loin
• FAQ
• Sources

1. Pourquoi la question revient en 2026

Trois mouvements de marché remettent la question build vs buy au centre des arbitrages DSI.

Maturité des LLM open weights. Mistral AI, Llama, Phi et Qwen ont atteint des niveaux de performance qui rendent crédible un build sur stack open weights pour la majorité des cas d’usage non frontaliers. Le delta de qualité avec les modèles frontier propriétaires s’est réduit sur les tâches business standard, sans le supprimer totalement sur les tâches complexes (raisonnement long, agentique avancée, multimodal complexe).

Sensibilité forte des coûts API au profil d’usage. Les premiers déploiements GenAI via API frontier ont mis en évidence une forte sensibilité de la facture au volume de tokens (entrée et sortie), au nombre d’utilisateurs actifs, à la longueur des contextes et aux patterns d’usage (RAG verbeux, agents itératifs, multimodal). Sans monitoring fin de ces dimensions, l’écart entre projection initiale et facture réelle peut être significatif. Les DSI redécouvrent l’intérêt de la maîtrise de l’infrastructure et de la prédictibilité du coût marginal.

Pression réglementaire. L’AI Act (UE 2024/1689), le RGPD et la directive NIS2 poussent à internaliser ou à contractualiser strictement les composants critiques pour pouvoir documenter, tracer et auditer. Le build redevient un levier de conformité, particulièrement lorsque les données sont susceptibles d’être visées par des procédures légales étrangères, notamment via le Cloud Act américain pour les fournisseurs soumis à juridiction américaine.

2. Les 5 axes de décision

2.1 Souveraineté des données

La souveraineté impose un contrôle fort de l’hébergement, des traitements, des accès, des journaux et de la chaîne contractuelle. Cela peut conduire à du build, à du on-premise, ou à du buy sur une offre souveraine qualifiée, selon le périmètre et le niveau de risque. Pour les données publiques ou non sensibles, le buy sur une API frontier reste pertinent. Pour les données sensibles ou réglementées, vérifier que l’offre cible est qualifiée SecNumCloud par l’ANSSI sur le périmètre concerné. La qualification SecNumCloud porte sur une offre commerciale précise et un périmètre déterminé : elle ne s’applique pas automatiquement à l’ensemble des services d’un fournisseur cloud, et doit être vérifiée sur l’offre exacte retenue.

2.2 Time-to-value

Le buy d’une solution SaaS prête à l’emploi délivre une valeur en quelques semaines. Le build sur stack open weights demande typiquement 3 à 9 mois pour un premier cas d’usage en production. Quand le time-to-value est critique, le buy est privilégié, quitte à rebasculer en build ultérieurement.

2.3 Coût TCO sur 3 ans

Le coût d’un SaaS croît avec l’usage (tarification au token, au siège ou à la requête). Le coût d’un build combine investissement initial (architecture, intégration, garde-fous, observabilité) et coût récurrent (GPU on-premise ou cloud souverain, staffing SRE IA, supervision, maintenance, mises à jour modèles). La bascule économique vers le build dépend du profil d’usage spécifique et se mesure par une analyse TCO complète, pas par un seuil universel de volume. Méthodologie détaillée en section 8.

2.4 Talents internes

Le build exige une équipe interne capable de maintenir l’architecture : data engineers, ML engineers, SRE IA, architectes. Sans ces profils, le build crée une dépendance prestataire qui annule son intérêt. Le buy reste pertinent tant que l’équipe interne se construit.

2.5 Criticité métier

Un système IA sur le chemin critique d’une opération (production industrielle, support 24/7, processus régulé) exige un contrôle complet : architecture, modèles, opérations. Le build ou l’hébergement maîtrisé devient prioritaire. Un système IA d’appoint (productivité bureautique, exploration) accepte une dépendance externe maîtrisée.

3. Open weights vs API frontier : tableau comparatif

La conclusion 2026 n’est pas l’exclusion de l’un par l’autre. Les architectures hybrides routent dynamiquement la requête vers le modèle pertinent (open weights local pour tâches standard et sensibles, frontier API pour tâches complexes non sensibles) selon contexte, coût et souveraineté.

4. Arbres de décision selon profil

PME (moins de 250 salariés)

Time-to-value et coût initial sont les contraintes dominantes. Le buy via SaaS IA spécialisé (assistant commercial, support client, marketing) est généralement la meilleure option pour démarrer. Le build sur stack open weights intervient à partir d’un cas d’usage stabilisé à fort volume ou pour une donnée stratégique non publiable.

ETI (250 à 5 000 salariés)

Les ETI ont la capacité de financer un build limité mais doivent prioriser. Recommandation : buy sur productivité et marketing standard, build sur cœur de métier (RAG sur base de connaissances métier, automatisation des processus opérationnels). Une équipe IA dédiée de 3 à 10 personnes permet de soutenir le build.

Grand groupe (plus de 5 000 salariés)

Les grands groupes ont la capacité de financer une plateforme interne. Recommandation : plateforme IA souveraine commune (RAG souverain, hébergement LLM open weights, observabilité, garde-fous) sur laquelle les directions métier déploient leurs cas d’usage. Buy de composants spécialisés pour les besoins de niche. Build complet pour les cas critiques (défense, finance régulée, propriété intellectuelle sensible).

Secteur régulé (défense, banque, santé, énergie)

Pour les traitements sensibles ou critiques, le build ou l’hébergement souverain maîtrisé devient souvent l’option de référence. Le buy reste possible pour les composants périphériques (productivité, formation, marketing externe). Articulation avec une offre qualifiée SecNumCloud par l’ANSSI sur le périmètre cible, et avec la certification HDS pour les données de santé à caractère personnel.

Secteur non régulé

Hybride raisonné : buy pour la majorité des cas (rapidité, accès aux modèles frontier), build progressif sur les cas où la connaissance métier, les volumes d’usage ou la criticité opérationnelle justifient un contrôle plus fin. La part du build augmente avec la maturité IA de l’organisation, l’accumulation de cas critiques et la stabilisation des volumes d’usage.

5. Modèles hybrides et orchestration

Le pattern dominant en 2026 combine RAG souverain et API LLM frontier. La donnée métier reste indexée sur infrastructure souveraine (vector store on-premise ou cloud souverain). Les LLM open weights traitent les requêtes standard. Les requêtes complexes ou nécessitant la qualité maximale sont routées vers une API frontier avec un prompt nettoyé qui ne contient pas la donnée brute mais une formulation dérivée.

Ce pattern préserve la souveraineté de la donnée brute, exploite le meilleur des deux mondes (rapidité frontier, coût et conformité open weights), et offre une migration progressive du buy vers le build à mesure que les modèles open weights progressent.

Côté outillage hébergement open weights, vLLM et Hugging Face TGI servent les besoins production, Ollama reste pertinent pour le edge et le développement. Le Model Context Protocol, standard ouvert émergent introduit par Anthropic et passé sous gouvernance de la Linux Foundation fin 2025, formalise l’interconnexion entre assistants IA et outils. Son adoption progresse dans l’écosystème, avec des niveaux de support variables selon les fournisseurs et frameworks ; il réduit le couplage à un fournisseur sur la couche outillage sans constituer à lui seul une garantie de portabilité totale.

6. Souveraineté, SecNumCloud et Cloud Act

Le débat build vs buy IA générative croise désormais celui de la souveraineté numérique européenne.

• SecNumCloud par l’ANSSI : référentiel français de cybersécurité du cloud. La qualification porte sur une offre commerciale précise et un périmètre déterminé : elle doit être vérifiée sur l’offre exacte retenue, pas sur le nom du fournisseur. Le référentiel intègre des exigences de protection contre les législations étrangères extraterritoriales.
• Cloud Act américain : loi américaine qui prévoit des procédures permettant aux autorités américaines de requérir, sous conditions, des données détenues par les fournisseurs soumis à juridiction américaine, y compris lorsque ces données sont stockées hors du territoire des États-Unis. À traiter dans l’analyse de risque comme une exposition juridique à intégrer pour les traitements de données sensibles.
• L’arbitrage build vs buy en secteur régulé européen privilégie une stack open weights hébergée sur cloud souverain qualifié ou on-premise pour les traitements de données les plus sensibles.

7. Conformité AI Act et Digital Omnibus

L’AI Act (UE 2024/1689) instaure une approche par les risques. Les pratiques interdites et l’obligation de littératie IA s’appliquent depuis le 2 février 2025. Les obligations applicables aux fournisseurs de modèles GPAI s’appliquent depuis le 2 août 2025, avec des modalités de conformité précisées par le General-Purpose AI Code of Practice publié par la Commission européenne.

Un accord provisoire du 7 mai 2026 sur le Digital Omnibus entre le Conseil de l’Union européenne et le Parlement européen prévoit un report des obligations applicables aux systèmes à haut risque : au 2 décembre 2027 pour les systèmes relevant de l’Annexe III et au 2 août 2028 pour les systèmes relevant de l’Annexe I. L’entrée en vigueur effective dépend de l’adoption formelle du texte par les co-législateurs.

Sanctions prévues à l’article 99 du règlement : jusqu’à 35 millions d’euros ou 7 % du chiffre d’affaires mondial pour les pratiques interdites, jusqu’à 15 millions d’euros ou 3 % pour les autres obligations applicables aux opérateurs, jusqu’à 7,5 millions d’euros ou 1 % pour les informations incorrectes, incomplètes ou trompeuses fournies aux autorités. Pour les PME et start-up, c’est le moindre des deux montants qui s’applique.

Pour la gouvernance, la norme ISO/IEC 42001:2023 (système de management de l’IA) et le NIST AI Risk Management Framework 1.0, complété par le Generative AI Profile (NIST AI 600-1), constituent les cadres de référence transverses.

8. Méthodologie TCO sur 3 ans

Le calcul TCO build vs buy doit intégrer huit catégories de coûts sur un horizon de 3 ans, mesurées sur le profil d’usage réel du cas d’usage cible, pas sur des seuils théoriques génériques.

Côté buy (API frontier ou SaaS IA) :

• Coût variable d’usage : tokens facturés (input et output), requêtes ou sièges selon la grille tarifaire. À projeter sur le volume mensuel attendu, avec une marge de tolérance sur la croissance.
• Coût d’intégration et garde-fous : connexion API, filtres entrée/sortie, journalisation, garde-fous OWASP LLM, observabilité.
• Coût contractuel et conformité : DPA, addendum souveraineté, audits fournisseur, documentation pour l’AI Act.

Côté build (open weights sur infrastructure maîtrisée) :

• Investissement initial : architecture, intégration, garde-fous, observabilité, golden dataset.
• Coût infrastructure récurrent : GPU on-premise ou cloud souverain, stockage, réseau, sauvegardes. Dépend du taux d’utilisation effectif des GPU (un GPU sous-utilisé alourdit le TCO).
• Coût staffing : SRE IA, MLOps, supervision, astreintes. Souvent le poste dominant à moyen terme.
• Coût maintenance et évolution : mises à jour modèles, ré-indexations, migrations entre versions de modèles, re-tuning.
• Coût sécurité et conformité : revues RSSI, tests d’intrusion ciblés, documentation AI Act et NIS2, journaux d’audit.

La bascule économique dépend du croisement entre le volume d’usage projeté, le mix de tâches (standard ou frontière), la criticité, la disponibilité de l’équipe interne et la sensibilité des données. Un benchmark sur 3 mois avec mesure réelle des coûts effectifs des deux options est recommandé avant arbitrage long terme.

9. Pour aller plus loin

• Choisir un cabinet de conseil IA en 2026 : guide de sélection
• Méthodologie d’audit IA en entreprise
• Mettre en place un RAG souverain : architecture, stack technique et conformité AI Act
• Déployer une IA agentique en entreprise
• TW3 Partners à VivaTech 2026 : informations stand

10. FAQ

À partir de quel volume le build devient-il plus rentable que le buy ?
Il n’existe pas de seuil universel. La bascule économique dépend du volume effectif, du mix de tâches (standard ou frontière), du taux d’utilisation des GPU, du staffing interne et de la sensibilité des données. La méthode robuste est un calcul TCO sur 3 ans selon les huit catégories décrites en section 8, comparé sur le profil d’usage réel.

Peut-on commencer en buy et basculer en build ?
Oui, c’est même le pattern recommandé pour la plupart des entreprises non régulées. Le buy permet de valider le cas d’usage, mesurer la valeur, former les équipes. La bascule en build se déclenche sur les critères de souveraineté, de TCO ou de criticité, généralement entre 12 et 24 mois.

Quels talents internes pour soutenir un build ?
Une équipe minimale comprend un architecte IA, un ML engineer, un data engineer, un SRE IA, un product owner IA, un référent sécurité. Pour un programme multi-cas d’usage, ajouter des ML engineers et data engineers par flux. Compter 8 à 20 ETP pour une plateforme IA interne en grand groupe.

Comment articuler build vs buy avec l’AI Act ?
Le build facilite la production de la documentation technique exigée par l’AI Act (annexe IV) pour les systèmes à haut risque. Le buy reste possible mais impose un contrôle contractuel renforcé sur la documentation fournie par le fournisseur. La classification d’un système au sens de l’AI Act dépend de sa finalité, de son rôle, de son autonomie et de son impact ; elle s’instruit cas par cas.

Quelle est l’exposition au Cloud Act américain ?
Pour les fournisseurs soumis à juridiction américaine, les autorités américaines peuvent, dans le cadre des procédures prévues par le Cloud Act, requérir des données détenues par ces fournisseurs, y compris lorsqu’elles sont stockées hors du territoire des États-Unis. À intégrer dans l’analyse de risque RGPD et dans l’AIPD lorsque le traitement présente un risque élevé. Pour les données les plus sensibles, choisir un fournisseur souverain qualifié sur l’offre cible ou un déploiement on-premise.

Quel rôle pour SecNumCloud ?
La qualification SecNumCloud de l’ANSSI s’applique à des offres et périmètres commerciaux précis. Elle ne s’applique pas automatiquement à l’ensemble des services d’un fournisseur. Vérifier la qualification sur l’offre exacte retenue avant arbitrage souveraineté.

Comment orchestrer plusieurs LLM open weights et frontier ?
Via un routeur multi-LLM (interne ou outil dédié) qui choisit le modèle selon la complexité de la requête, le coût marginal et la sensibilité des données. Les requêtes sont routées vers open weights local par défaut, et vers une API frontier seulement quand la qualité l’exige et que la donnée n’est pas sensible. Le Model Context Protocol standardise la couche outillage et facilite la portabilité entre frameworks, sans constituer à lui seul une garantie de portabilité totale.

Quels modèles open weights privilégier ?
Mistral pour les organisations cherchant un acteur européen et un bon support des usages francophones, Llama pour la richesse de l’écosystème, Phi pour les déploiements edge ou les sous-tâches compactes, Qwen avec une nuance juridictionnelle pour les périmètres régulés sensibles. Tester sur un golden dataset propre avant arbitrage.

Quelle est la place de Hugging Face dans l’écosystème ?
Hugging Face centralise la distribution des modèles open weights, fournit des inference servers (Text Generation Inference) et joue un rôle de standardisation des évaluations.

Comment décider pour un cas d’usage agentique ?
L’agentique impose une observabilité fine et un contrôle complet des chaînes d’outils. Le build sur stack open weights est généralement préférable pour les agents critiques.

Comment discuter build vs buy avec TW3 Partners ?
Au stand Hall 7.2, Allée C, Stand 74 à VivaTech 2026 (17 au 20 juin), ou sur rendez-vous via tw3partners.fr.

Quel financement public pour soutenir un build ?
Plusieurs dispositifs : France 2030, Bpifrance (i-Démo, i-Nov), France Num pour les PME. Vérifier l’éligibilité au cas par cas auprès des organismes.

11. Sources

• McKinsey, The state of AI in early 2024: Gen AI adoption spikes and starts to generate value
• Stanford HAI, Artificial Intelligence Index Report 2025
• Règlement (UE) 2024/1689, AI Act, EUR-Lex
• Conseil de l’Union européenne, communications sur le Digital Omnibus
• Commission européenne, General-Purpose AI Code of Practice
• Règlement (UE) 2016/679, RGPD, EUR-Lex
• Directive (UE) 2022/2555, NIS2, EUR-Lex
• ANSSI, référentiel SecNumCloud et liste des prestataires qualifiés
• U.S. Department of Justice, Cloud Act resources
• ISO/IEC 42001:2023, AI Management System
• NIST AI Risk Management Framework 1.0
• NIST AI 600-1, Generative AI Profile
• vLLM, documentation officielle
• Ollama, documentation officielle
• Hugging Face Text Generation Inference, documentation officielle
• Model Context Protocol, documentation officielle
• Programme officiel VivaTech 2026