Make vs Buy vs Platform IA 2026 : comment décider pour votre ETI

#Pourquoi la décision Make/Buy/Platform est différente pour l'IA

La question Build vs Buy est ancienne en informatique d'entreprise. Elle a structuré les arbitrages ERP, CRM, SIRH depuis les années 1990. Pour l'IA, elle revient avec une acuité nouvelle — et avec un troisième terme qui change la donne : le modèle Platform.

Trois raisons expliquent pourquoi la décision est fondamentalement différente pour l'IA.

Première raison : les fondations technologiques évoluent à une vitesse sans précédent. Un ERP SAP déployé en 2005 fonctionnait encore en 2025. Un choix de modèle LLM fait en 2023 est déjà caduc en 2026 sur les critères de performance et de coût. Cette vélocité change le calcul du TCO et la pertinence du vendor lock-in : s'engager sur 5 ans avec un fournisseur IA vertical, c'est parier que son modèle propriétaire restera compétitif face aux modèles fondamentaux open source qui progressent tous les 6 mois.

Deuxième raison : l'IA est un levier de différenciation, pas seulement d'efficacité. Selon le guide décision IA pour les DSI, les entreprises qui obtiennent le meilleur ROI de l'IA sont celles qui l'utilisent pour créer un avantage compétitif difficilement réplicable — et non pour reproduire ce que tous leurs concurrents font avec le même SaaS. Si vous utilisez HubSpot IA pour scorer vos leads, votre concurrent direct utilise exactement le même algorithme. La différenciation par l'IA exige de la propriété intellectuelle sur les modèles et les données.

Troisième raison : la souveraineté des données est une contrainte réglementaire, pas un choix. Le RGPD, l'AI Act européen (en application progressive depuis 2024), et les exigences de confidentialité des données clients dans les secteurs réglementés (finance, santé, juridique) créent des contraintes sur où les données peuvent être traitées. Le choix entre Make, Buy et Platform est donc aussi un choix d'architecture de conformité.

Cette tribune structure la décision autour d'un framework opérationnel que nous appliquons chez Nehos dans nos missions d'accompagnement des ETI.

#Modèle Make : développement sur mesure, quand c'est justifié

Le modèle Make consiste à construire sa propre solution IA : développement d'un agent IA sur mesure, pipeline de traitement documentaire propriétaire, modèle fine-tuné sur les données internes. L'entreprise conserve la maîtrise totale du code, des données et de l'évolution fonctionnelle.

Le Make est justifié dans quatre situations.

Processus différenciant à fort avantage concurrentiel. Si votre processus de souscription, de pricing ou de service client constitue un avantage compétitif documenté, automatiser ce processus avec un SaaS générique revient à le standardiser — et donc à l'aligner sur vos concurrents. La personnalisation profonde exige le Make.

Données hautement sensibles ou réglementées. Données de santé (RGPD, HDS), données financières confidentielles, secrets industriels, informations couvertes par le secret professionnel : certaines données ne peuvent pas transiter par les infrastructures d'un éditeur SaaS tiers, même avec les meilleures clauses contractuelles. Le Make permet l'hébergement on-premise ou sur cloud souverain.

Volumétrie élevée qui rend le SaaS non économique. À partir d'un certain seuil de volume de traitement, le coût du SaaS (facturé par siège, par requête ou par document) dépasse structurellement le coût d'une infrastructure propriétaire. Pour une ETI qui traite 50 000 documents par mois, le calcul TCO bascule généralement en faveur du Make entre 18 et 30 mois.

Intégration profonde avec les systèmes legacy. Quand la valeur du projet IA repose sur l'intégration fine avec un ERP propriétaire, un SGBD maison ou un système de gestion métier non standard, le Make est souvent le seul chemin réaliste — les connecteurs SaaS standards ne couvrent pas ces cas.

Les risques du Make à anticiper. Le développement sur mesure exige des compétences IA internes ou un partenaire spécialisé, un pilotage projet rigoureux, et une discipline de documentation. Le risque de dette technique est réel dans un domaine où les frameworks (LangChain, LlamaIndex, LangGraph) évoluent tous les 3 à 6 mois. Le budget d'un projet IA sur mesure varie de19 7 808 € pour un agent simple à plus de 194 000 € pour une plateforme multi-agents.

#Modèle Buy : SaaS IA verticaux — HubSpot IA, Salesforce Einstein, SAP IA

Le modèle Buy repose sur l'acquisition de solutions SaaS IA verticales : des produits packagés qui intègrent des fonctionnalités IA directement dans un outil métier existant. HubSpot IA pour le marketing automation, Salesforce Einstein pour le CRM prédictif, SAP Business AI pour les processus ERP, Microsoft 365 Copilot pour la productivité bureautique, Notion AI pour la gestion de connaissance.

Les atouts réels du Buy.

La mise en production est rapide — quelques semaines au lieu de plusieurs mois. L'éditeur gère les mises à jour du modèle, la sécurité, la scalabilité et la maintenance. Les équipes n'ont pas besoin de compétences IA pour utiliser la solution. Pour des fonctions support (RH, comptabilité, marketing généraliste), le Buy est souvent la décision la plus rationnelle.

La comparaison avec des alternatives maison n'est pas toujours à l'avantage du Make : développer un système de scoring de leads comparable à Salesforce Einstein coûterait à partir de 1 842 € et prendrait 4 à 6 mois pour atteindre une qualité équivalente.

Les limites structurelles du Buy.

Le principal problème du Buy IA est la standardisation : vous utilisez exactement les mêmes algorithmes que vos concurrents. HubSpot IA applique le même modèle de scoring à votre base de contacts qu'à celle de 100 000 autres clients. La différenciation par les données est possible (votre base est unique), mais la logique algorithmique est identique.

Le deuxième problème est la dépendance aux roadmaps éditeurs. Quand Salesforce décide de faire évoluer Einstein, vous n'avez aucune influence sur les priorités fonctionnelles. Si une fonctionnalité critique pour votre métier n'est pas dans la roadmap de l'éditeur, vous attendez — ou vous développez en parallèle, ce qui annule l'économie du Buy.

Le troisième problème est la portabilité des données. Les SaaS IA accumulent des données sur vos processus, vos clients, vos comportements d'usage. En cas de migration, la récupération de ces données et des modèles entraînés sur votre base spécifique est souvent contractuellement limitée.

Enfin, le ROI d'un agent IA dépend beaucoup de la qualité de l'adaptation au contexte métier — et c'est précisément ce que les SaaS verticaux offrent de manière limitée.

#Modèle Platform : Azure OpenAI, OVHcloud AI, AWS Bedrock — ce que c'est vraiment

Le modèle Platform est le plus souvent mal compris. Une plateforme IA cloud — Azure OpenAI Service, AWS Bedrock, OVHcloud AI, Google Vertex AI — n'est pas un produit fini. C'est une infrastructure qui expose des modèles de langage (LLM) et des outils IA via des API, sur une infrastructure cloud managée.

Ce que vous obtenez avec une plateforme IA :

• Accès aux modèles fondamentaux (GPT-4o, Claude 3.5, Llama 3.1, Mistral Large) via API sécurisée
• Infrastructure cloud managée (scaling automatique, haute disponibilité, SLA garantis)
• Outils de développement (SDK, intégrations LangChain/LlamaIndex, monitoring)
• Conformité certifiée (ISO 27001, SOC 2, HDS pour certains fournisseurs) sans que vous ayez à la gérer vous-même
• Dans le cas d'OVHcloud et Scaleway : hébergement en France avec données qui ne sortent pas du territoire de l'UE

Ce que vous ne faites PAS avec une plateforme IA :

• Vous n'obtenez pas une application prête à l'emploi
• Vous ne pouvez pas déployer sans compétences en développement
• Vous n'avez pas d'interface utilisateur fournie

Le modèle Platform est en réalité le socle du modèle Make moderne : la quasi-totalité des développements IA sur mesure en 2026 s'appuient sur une ou plusieurs plateformes cloud IA plutôt que sur une infrastructure self-hosted complète. Développer son propre service d'inférence LLM est rarement justifiable pour une ETI.

La différence entre les fournisseurs de plateforme IA est stratégique. Azure OpenAI offre les modèles OpenAI dans l'environnement Microsoft — pertinent pour les entreprises déjà dans l'écosystème Azure. AWS Bedrock propose le plus large catalogue de modèles (Anthropic, Mistral, Meta, Amazon Nova) avec l'intégration native AWS. OVHcloud AI et Scaleway AI sont les choix souverains pour les données sensibles et la conformité RGPD stricte — leur infrastructure est localisée en France ou en Union Européenne.

Pour les ETI françaises, la combinaison OVHcloud AI pour les données métier sensibles + Azure OpenAI ou AWS Bedrock pour les usages moins critiques est une architecture hybride courante qui optimise la conformité et les performances.

#Matrice de décision : 8 critères pondérés

Voici la matrice que Nehos utilise pour scorer chaque cas d'usage IA d'une ETI. Chaque critère est noté de 1 à 5 pour chaque modèle selon le contexte spécifique de l'entreprise. Le modèle avec le score pondéré le plus élevé est le candidat prioritaire.

La souveraineté du modèle Platform dépend du fournisseur choisi : OVHcloud AI = 5 étoiles, Azure/AWS = 3 étoiles pour les données sensibles.

Comment lire cette matrice. Pour un processus de qualification de leads commerciaux dans une ETI de 300 personnes sans équipe data, le Buy (HubSpot IA, Salesforce Einstein) score mieux sur time-to-market, compétences et budget. Pour un processus de souscription d'assurance avec données médicales, le Make + Platform souverain score écrase le Buy sur différenciation et souveraineté.

La matrice n'est pas destinée à donner une réponse universelle — elle est destinée à rendre le débat quantitatif et traçable, en évitant que la décision soit prise sur la base du dernier fournisseur qui a déjeuné avec le COMEX.

Application aux 4 cas types d'une ETI :

• Productivité interne (messagerie, documents, réunions) → Buy systématique (Microsoft 365 Copilot, Notion AI)
• Support client niveau 1 → Platform + Make léger (chatbot RAG sur base de connaissance interne)
• Processus métier cœur différenciant → Make sur Platform souverain
• Analytics et reporting → Buy si BI standardisée, Make si indicateurs propriétaires complexes

Ce cadre s'articule directement avec la gouvernance IA de l'entreprise : chaque décision Make/Buy/Platform doit être documentée, versionnée et révisable annuellement.

#Pièges du vendor lock-in dans les projets IA

Le vendor lock-in dans l'IA est plus pernicieux que dans le logiciel traditionnel, pour trois raisons que les décideurs sous-estiment systématiquement.

Lock-in sur les données entraînées. Quand un SaaS IA apprend de vos données — votre historique de leads, vos tickets de support, vos contrats — il construit un modèle implicite sur votre base. Ce modèle n'est pas exportable. Si vous changez de fournisseur, vous repartez de zéro sur l'apprentissage. La dépendance croît avec le temps d'usage : après 2 ans, migrer d'un SaaS IA coûte 3 à 5× plus cher qu'après 6 mois.

Lock-in sur les APIs propriétaires. Salesforce Einstein, HubSpot IA, SAP Business AI utilisent des APIs et des formats de données propriétaires. Vos développeurs internes ou vos intégrateurs construisent des automatisations et des connecteurs sur ces interfaces. Quand vous migrez, toute cette couche d'intégration est à reconstruire. Le vrai coût de migration n'est pas la licence du nouveau fournisseur — c'est le coût de migration des intégrations, qui représente souvent 3 à 8 mois-homme.

Lock-in sur les compétences. Les équipes qui utilisent un SaaS IA pendant 18 mois développent des réflexes, des workflows et des paramétrages qui sont spécifiques à ce produit. Migrer, c'est aussi reconfigurer des processus organisationnels et reforEr des équipes — un coût rarement comptabilisé dans le calcul du TCO. Le change management d'un projet IA commence dès le choix de la solution, pas au moment du déploiement.

Stratégies anti-lock-in pour les ETI.

L'abstraction par couche d'orchestration est la stratégie la plus efficace : développer une couche d'orchestration interne (LangChain, LangGraph) qui dialogue avec les APIs LLM via une interface standardisée. Si GPT-4o devient trop cher ou si OpenAI change ses conditions, vous basculez sur Claude 3.5 ou Mistral Large en changeant une ligne de configuration — pas en refactorant l'application.

La contractualisation des SLA et des clauses de portabilité est indispensable. Tout contrat SaaS IA doit inclure une clause d'export des données et des modèles entraînés, un délai de portabilité en cas de résiliation, et une interdiction d'utiliser vos données pour entraîner des modèles generiques. Les SLA et KPIs des agents IA doivent être définis dans le contrat, pas dans le PowerPoint commercial.

La diversification des fournisseurs de modèles réduit le risque de lock-in technique : ne pas tout concentrer sur un seul éditeur LLM. Une architecture multi-modèles (OpenAI pour certains usages, Anthropic ou Mistral pour d'autres) augmente la résilience et la capacité de négociation.

→ Vous évaluez vos options ? Utilisez notre estimateur de budget en ligne pour obtenir une fourchette en 2 minutes, ou consultez nos tarifs détaillés.

#Architecture hybride : quand combiner les 3 modèles

La bonne nouvelle pour les ETI : la décision Make/Buy/Platform n'est pas binaire, et elle ne s'applique pas au niveau de l'entreprise mais au niveau de chaque cas d'usage. Une architecture hybride bien pensée combine les trois modèles en allouant chacun aux processus pour lesquels il est optimal.

Le modèle hybride type pour une ETI de 200-500 salariés en 2026 :

Couche Platform (socle commun) : Azure OpenAI ou OVHcloud AI comme fournisseur de modèles. Base vectorielle partagée (Qdrant self-hosted ou Weaviate Cloud). Infrastructure d'orchestration commune (LangFuse pour le monitoring, Redis pour les sessions, PostgreSQL pour les métadonnées). Ce socle sert tous les projets IA de l'entreprise et est géré par l'équipe IT ou par un partenaire.

Couche Buy (fonctions support) : Microsoft 365 Copilot pour la productivité bureautique. Notion AI ou Confluence AI pour la gestion de connaissance interne. Un outil de BI IA pour le reporting standard (Power BI avec Copilot, Tableau AI). Ces outils sont déployés rapidement, sans développement, et couvrent les besoins des équipes RH, juridique, finance et marketing généraliste.

Couche Make sur Platform (processus différenciants) : les 2 à 5 processus métier qui constituent un avantage concurrentiel réel sont développés sur mesure au-dessus du socle Platform. Agent de qualification des prospects selon les critères propriétaires de l'entreprise. Pipeline de traitement des dossiers clients avec les règles métier spécifiques. Outil de génération de contenu aligné sur la charte éditoriale et les offres de l'entreprise.

Cette architecture hybride a deux avantages complémentaires. Elle réduit le TCO : les économies d'échelle du Platform (infrastructure partagée) financent les développements Make premium. Elle limite le risque : si un fournisseur SaaS disparaît ou augmente ses tarifs, seule la couche Buy est impactée — les processus critiques restent sur la couche Make propriétaire.

La méthode de déploiement en 7 étapes s'applique aux projets Make de cette architecture hybride. Pour les projets Buy, la méthodologie est différente : elle porte sur la sélection fournisseur, la négociation contractuelle et la conduite du changement.

Le rôle du Chief AI Officer (CAIO) dans une ETI est précisément de superviser cette architecture hybride : maintenir la cohérence entre les couches, éviter la prolifération de SaaS IA non gouvernés (IA shadow IT), et piloter l'évolution du socle Platform en fonction des besoins des métiers.

#TCO comparé sur 3 ans : calcul réel pour ETI 200-500 salariés

Voici un calcul de TCO sur 36 mois pour un cas d'usage type : un agent de qualification des leads commerciaux traitant 1 500 leads entrants par mois dans une ETI de 350 salariés.

Hypothèses communes :

• Volume : 1 500 leads/mois traités par l'IA
• Équivalent 1,5 ETP commercial dédié à la qualification manuelle avant le projet
• Coût ETP commercial chargé :51 4 992 €/an

#TCO Modèle Buy — Salesforce Einstein Sales Cloud

Estimation d'une augmentation tarifaire annuelle de 7 % — dans la moyenne de Salesforce historiquement.

#TCO Modèle Make sur Platform — Agent IA sur mesure (Azure OpenAI)

Lecture du TCO comparé. Sur 3 ans, le Make sur Platform est 2× moins cher que le Buy pour ce cas d'usage. Le point de bascule se situe autour de 18 mois : avant, le Buy est moins cher (pas de coût de développement initial) ; après, le Make s'amortit. Ce calcul illustre pourquoi il faut raisonner en TCO 36 mois, pas en coût de démarrage.

Ce calcul ne prend pas en compte les économies opérationnelles générées (réduction de 1,5 ETP de qualification manuelle =97 1 920 € sur 3 ans dans les deux cas). Le ROI des agents IA est positif dans les deux scénarios — la question n'est pas «faut-il faire l'IA ?» mais «quel modèle économique choisir ?».

Pour les budgets et fourchettes détaillés par type de projet IA, le guide budget projet IA entreprise 2026 complète cette analyse TCO avec la décomposition par postes de coût.

La transformation digitale réussie sans gaspiller repose sur ces arbitrages budgétaires précis : la majorité des surcoûts dans les projets IA viennent d'un mauvais choix initial de modèle (Make quand Buy suffit, ou Buy quand Make était nécessaire), pas d'une mauvaise exécution.

#Pièges du vendor lock-in dans les projets IA

Au-delà du calcul TCO, trois risques de lock-in spécifiques à l'IA méritent une attention particulière des ETI.

Le lock-in sur les embeddings et les bases vectorielles. Si vous stockez 500 000 chunks de documents dans une base vectorielle Pinecone avec les embeddings d'OpenAI, migrer vers une autre base vectorielle ou vers d'autres embeddings nécessite de réindexer l'intégralité du corpus. Le coût de réindexation est direct (calcul des embeddings) mais le coût indirect de downtime et de reconfiguration des pipelines est souvent 3 à 5× plus élevé. Stratégie de mitigation : utiliser des embeddings open source (Sentence Transformers, nomic-embed) qui peuvent tourner sur n'importe quelle infrastructure, et une base vectorielle self-hosted (Qdrant, Chroma, Milvus).

Le lock-in sur les orchestrateurs propriétaires. Microsoft Copilot Studio, Google Vertex AI Conversation, Amazon Bedrock Agents — tous proposent des environnements d'orchestration visuels qui simplifient le développement. Mais les agents construits dans ces environnements sont difficilement portables vers un autre fournisseur. À l'inverse, un agent développé avec LangGraph (open source) peut basculer d'Azure OpenAI à AWS Bedrock en changeant la configuration des modèles.

Le lock-in contractuel sur les données d'entraînement. Plusieurs éditeurs SaaS IA (lecture fine des conditions générales) se réservent le droit d'utiliser vos données de feedback pour améliorer leurs modèles globaux. Exiger une clause d'opt-out explicite, vérifier la Data Processing Agreement (DPA) et s'assurer que vos données ne quittent pas l'UE sont des prérequis non négociables pour toute ETI traitant des données clients ou des données B2B sensibles.

#Architecture hybride : quand combiner les 3 modèles

L'architecture hybride n'est pas un compromis — c'est la configuration optimale pour la grande majorité des ETI. Elle consiste à déployer chaque modèle là où il crée le plus de valeur, avec un socle Platform commun qui évite la fragmentation technique.

Le principe du «socle souverain + Make différenciant + Buy pour le reste» structure les projets IA des ETI les plus avancées en 2026 : une plateforme cloud IA (OVHcloud pour la souveraineté, ou Azure pour l'intégration Microsoft) sert de fondation, les 3 à 7 processus différenciants sont développés sur mesure, et les dizaines de fonctionnalités IA génériques passent par du SaaS.

Pour concevoir cette architecture, le rôle d'un partenaire comme Nehos est d'abord analytique : cartographier les processus, scorer chaque processus sur la matrice 8 critères, concevoir l'architecture cible, et dimensionner la feuille de route. Ce travail en amont évite le piège du «projet IA » qui se transforme en empilement incohérent de SaaS IA non gouvernés.

#Framework Nehos : notre méthode d'aide à la décision pour les projets IA

Après avoir accompagné plus d'une cinquantaine d'ETI et de grands groupes dans leurs décisions Make/Buy/Platform, Nehos a formalisé une méthode en 4 phases sur 4 semaines.

Phase 1 — Cartographie des processus cibles (semaines 1-2)

Audit de l'ensemble des processus candidats à l'IA : interview des directeurs métier, identification des tâches répétitives à fort volume, évaluation de la criticité et de la sensibilité des données impliquées. Livrable : une liste de 10 à 30 processus candidats avec un premier scoring sur les 8 critères de la matrice.

Phase 2 — Scoring matriciel et sélection (semaine 2-3)

Application de la matrice de décision sur les processus candidats avec les poids calibrés sur le contexte spécifique de l'ETI. Identification des 3 à 5 processus à traiter en priorité, avec la recommandation Make/Buy/Platform pour chacun. Livrable : matrice de priorisation commentée, présentable au COMEX.

Phase 3 — Architecture cible et TCO (semaine 3-4)

Conception de l'architecture hybride cible : choix des fournisseurs Platform, sélection des SaaS Buy, spécifications des développements Make. Calcul du TCO sur 36 mois pour chaque option retenue. Identification des risques de lock-in et des clauses contractuelles à négocier. Livrable : dossier d'architecture + tableau de TCO comparé.

Phase 4 — Feuille de route et plan de financement

Priorisation des projets IA en vagues de 3 à 6 mois, dimensionnement des budgets par vague, identification des aides publiques applicables (CIR, BPI, France 2030). Définition des indicateurs de suivi et des critères de go/no-go pour chaque projet. Livrable : roadmap IA 24 mois avec jalons, budgets et KPIs.

Ce framework s'inscrit dans une approche de gouvernance IA d'entreprise qui garantit la cohérence des décisions IA dans la durée. Il est complémentaire du guide de décision IA pour les DSI, qui aborde la dimension technique et organisationnelle du même défi décisionnel.

La décision Make/Buy/Platform est peut-être la plus stratégique que vous prendrez sur votre programme IA 2026-2028. Elle mérite une rigueur analytique égale à celle que vous apportez à vos décisions d'investissement industriel ou d'acquisition. Prendre rendez-vous avec l'équipe Nehos pour un cadrage de 45 minutes, c'est obtenir une première lecture de votre situation sur cette matrice — sans engagement.