TL;DR — la décision en 60 secondes
La décision enterprise build vs buy n’est pas binaire. Voici le cadre en un coup d’œil :
- Acheter quand la capacité est une commodité, qu’un marché SaaS mature existe et que le flux de travail n’est pas un différenciateur concurrentiel.
- Développer quand la capacité est une source directe de revenus ou d’avantage opérationnel, quand la conformité exige la souveraineté des données, ou quand la dette d’intégration entre plusieurs outils SaaS est devenue inacceptablement élevée.
- Hybride est la réponse pour la plupart des entreprises : acheter les couches génériques (identité, paiements, communications), développer le cœur différenciant et l’orchestration d’intégration.
- TCO sur 5 ans rend presque toujours le développement plus attractif qu’en année 1 seule — en particulier lors de la modélisation des tarifs SaaS par siège à la croissance des effectifs enterprise.
Pourquoi cette décision est différente à l’échelle enterprise
Pour une PME de 50 personnes, un mauvais choix build vs buy est récupérable. On dépense trop de temps ou d’argent, on pivote, on passe à autre chose. Pour une entreprise avec 2 000 sièges, des intégrations ERP profondément enracinées et une exigence de piste d’audit remontant à sept ans, un mauvais choix signifie une remédiation pluriannuelle, une exposition réglementaire et une responsabilité du management.
À l’échelle enterprise, trois facteurs changent entièrement le calcul :
Tarification par siège non linéaire
La plupart des plateformes SaaS facturent par siège ou par MAU. Pour 100 utilisateurs, un outil à 55 €/siège/mois coûte 66 000 €/an — raisonnable. Pour 3 000 utilisateurs, le même outil coûte 1,98 M €/an. Les contrats enterprise peuvent proposer des remises volumiques, mais rarement plus de 20–30 %, et les engagements annuels minimaux vous lient indépendamment de l’utilisation réelle. Les logiciels sur mesure ont une courbe de coût de maintenance plate : une fois construit, ajouter des utilisateurs coûte de l’infrastructure, pas des licences.
La dette d’intégration s’accumule
L’entreprise moyenne utilise 900+ applications SaaS (Okta, 2024). La couche d’intégration entre ces applications — connecteurs API point à point, middleware, pipelines ETL — coûte généralement plus à maintenir que les applications elles-mêmes. Chaque nouvel outil SaaS ajouté est une nouvelle surface d’intégration. La construction d’une plateforme unifiée réduit la dette d’intégration à une seule base de code gérée. Lisez notre article sur la modernisation des systèmes hérités pour le cadre complet de remédiation.
La conformité à l’échelle enterprise est architecturale
Les obligations du responsable de traitement RGPD article 28, les périmètres d’audit SOC 2 Type II, les accords HIPAA Business Associate, les exigences CNIL et les règlements sectoriels (DORA pour les services financiers UE, FedRAMP pour les administrations US) imposent des contraintes architecturales que la plupart des plateformes SaaS multi-locataires ne satisfont que partiellement. Quand votre équipe conformité examine la matrice de responsabilité partagée d’un fournisseur, les lacunes restantes sont votre problème — souvent avec du code personnalisé hors du périmètre de support du fournisseur. Pour les PME évaluant la même question sans contraintes enterprise, lisez notre article logiciel sur mesure vs logiciel standard.
Quand acheter
Acheter est le bon choix par défaut pour toute capacité qui satisfait ces trois critères :
- Le flux de travail n’est pas un différenciateur concurrentiel direct — vos concurrents utilisent la même catégorie d’outil sans en tirer d’avantage.
- Un marché SaaS mature existe avec plusieurs fournisseurs crédibles, des écosystèmes d’intégration établis et une portabilité des données raisonnable.
- Le coût par siège aux effectifs projetés sur 5 ans est inférieur au coût de construction + maintenance sur 5 ans incluant une équipe de 2 ETP.
Capacités génériques : acheter par défaut
RH et paie, CRM de base, voyages d’affaires, gestion des notes de frais, infrastructure e-mail et agenda, vidéoconférence — ce sont des flux de travail génériques. Toutes les entreprises les font de la même façon. Le marché SaaS est mature, la portabilité des données est établie (export CSV, API HRIS standard) et aucune entreprise ne gagne d’avantage concurrentiel grâce à un outil de notes de frais propriétaire. Achetez-les, configurez-les minimalement et résistez à l’envie de les personnaliser au-delà du point de non-retour.
Rapidité de mise en marché pour les capacités non cœur
Quand un nouveau produit ou marché exige une capacité que votre équipe n’a jamais construite — communications temps réel, traitement vidéo, recherche avancée — l’achat d’une couche SaaS éprouvée permet de livrer en semaines plutôt qu’en mois. Le calcul change si et quand cette capacité devient un différenciateur core à grande échelle. Commencez par acheter, surveillez l’usage et le coût, et menez une évaluation build au bout de 18 mois.
SaaS fortement réglementé avec couverture de responsabilité partagée
Quand un fournisseur SaaS propose un modèle de responsabilité partagée certifié qui couvre génuinement votre périmètre de conformité — SOC 2 Type II, ISO 27001, HIPAA BAA, RGPD/CNIL — et que les obligations résiduelles sont minimales, acheter est souvent plus rapide et moins cher. La qualification est « couvre génuinement » : auditez la matrice de responsabilité partagée, pas la page marketing.
Quand développer
Développer est la bonne décision quand une ou plusieurs des conditions suivantes s’appliquent :
La capacité est un différenciateur concurrentiel direct
Votre modèle de souscription propriétaire, votre algorithme de prévision de la demande, votre logique de scoring client — si cette capacité est la raison pour laquelle des clients vous choisissent plutôt qu’un concurrent, vous ne pouvez pas la confier à une plateforme SaaS tierce. Le fournisseur a désormais une visibilité architecturale sur votre IP différenciante, vous opérez selon son calendrier de roadmap, et tout concurrent peut acheter la même plateforme et combler l’écart. Développez le cœur différenciant. Possédez l’IP. Possédez la roadmap.
La dette d’intégration est devenue la principale charge de maintenance
Quand votre équipe passe plus de temps d’ingénierie à maintenir des connecteurs API, des jobs de synchronisation et des transformations de données entre outils SaaS qu’à construire de nouvelles capacités produit, vous avez un signal build. Le coût sur 5 ans d’une plateforme d’intégration et de données dédiée qui remplace 12 connecteurs SaaS point à point est presque toujours inférieur au coût de maintenance continu. Lisez notre article sur l’intégration IA dans les logiciels enterprise pour les modèles architecturaux.
Le risque de dépendance fournisseur (vendor lock-in) est inacceptable
Quand les conditions tarifaires d’un fournisseur, les engagements minimaux contractuels ou les limitations de portabilité des données créent un risque que l’organisation ne peut pas accepter — données d’audit bloquées dans un format propriétaire, engagements minimum de 3 ans avec hausses annuelles de 20 %, absence d’API pour export de données en masse — développer est l’option de réduction du risque. Voir la section dépendance fournisseur (vendor lock-in) ci-dessous.
La souveraineté des données et l’architecture de conformité l’exigent
Les restrictions de transfert de données RGPD articles 44–49, les règlements sectoriels (surveillance des transactions MiFID II, résidence des données NHS, exigences nucléaires AIEA) et les considérations de sécurité nationale dans certains marchés rendent les architectures SaaS multi-locataires multi-régions architecturalement incompatibles. Quand les données doivent rester dans une juridiction spécifique, avec une isolation logique spécifique et une chaîne d’audit spécifique, construire une plateforme conforme n’est pas un choix mais une exigence réglementaire.
Dépendance fournisseur (vendor lock-in) : quantifier le coût de sortie
La dépendance fournisseur n’est pas un risque hypothétique. C’est un passif quantifiable qui appartient à votre bilan. Les entreprises qui sautent cette modélisation le découvrent systématiquement au moment du renouvellement, quand tout le levier a déjà basisculé vers le fournisseur.
Un modèle complet de coût de sortie comprend cinq composantes :
- Extraction et migration des données : heures d’ingénierie pour exporter toutes les données du schéma propriétaire du fournisseur vers un format portable, valider l’intégrité, transformer et importer dans le système de remplacement. Pour une entreprise avec 5 ans de données opérationnelles, c’est généralement 135 000–450 000 €.
- Recâblage des intégrations : remplacer toutes les intégrations en aval qui appellent les API du fournisseur par des appels au système de remplacement. Multipliez le nombre de points d’intégration par 40–120 heures chacun.
- Formation et conduite du changement : pour les plateformes à fort engagement utilisateur (ERP, CRM, ITSM), prévoyez 40–80 heures de conduite du changement par 100 utilisateurs affectés.
- Engagements minimaux contractuels et pénalités de résiliation : lisez chaque contrat. La plupart des accords SaaS enterprise incluent un préavis de résiliation de 90 jours, des clauses d’engagement annuel minimum et parfois des frais explicites de « résiliation pour convenance » de 50–100 % de la valeur contractuelle restante.
- Risque de continuité d’activité : coût de fonctionnement parallèle de l’ancien et du nouveau système, plus la prime de risque pendant la période où aucun n’est pleinement opérationnel.
TCO sur 5 ans à l’échelle enterprise
Le tableau ci-dessous compare une décision de plateforme enterprise représentative : une plateforme d’automatisation des flux de travail et de reporting pour 1 000 utilisateurs en année 1, croissant à 2 500 utilisateurs en année 5. Le coût de construction suppose une équipe d’ingénierie nearshore senior livrant sur 18 mois, plus une équipe interne de 2 ETP pour le développement et la maintenance continus.
| Poste de coût | Acheter (SaaS) 1 000→2 500 sièges |
Développer (sur mesure) maintenance constante |
Hybride acheter bords + développer cœur |
|---|---|---|---|
| Année 1 — implémentation | 435 000 € (licence + configuration) | 680 000 € (développement) | 470 000 € (cœur + SaaS bords) |
| Année 2 — exploitation | 505 000 € | 160 000 € (maintenance + équipe) | 235 000 € |
| Année 3 — exploitation | 635 000 € | 160 000 € | 245 000 € |
| Année 4 — exploitation | 815 000 € | 165 000 € | 265 000 € |
| Année 5 — exploitation | 1 000 000 € | 170 000 € | 280 000 € |
| Total 5 ans (hors sortie) | 3 390 000 € | 1 335 000 € | 1 495 000 € |
| Coût de sortie estimé en cas de migration | 2 000 000–3 175 000 € | 135 000–365 000 € | 365 000–815 000 € |
L’avantage TCO sur 5 ans d’un développement sur mesure dans ce scénario est de 2,05 M € avant coûts de sortie et de 3,2–5,2 M € en incluant les pénalités de migration estimées. L’année de croisement — où la courbe d’achat dépasse la courbe de développement en coût cumulé — est l’année 3 dans ce modèle. Pour les plateformes avec une croissance des effectifs plus rapide, le croisement arrive en année 2.
Ces chiffres sont cohérents avec les benchmarks des cabinets de conseil Gartner et IDC pour les catégories de plateformes incluant l’automatisation des flux de travail, la business intelligence et les plateformes de données opérationnelles.
Le modèle hybride : acheter les bords, développer le cœur
La présentation de « build vs buy » comme un choix binaire est elle-même le piège conceptuel. Le modèle gagnant pour la plupart des entreprises est un hybride structuré : acheter les capacités génériques en périphérie, développer le cœur différenciant et la couche d’intégration qui lie le tout.
Ce qu’il faut acheter dans un modèle hybride
Gestion des identités et accès (Okta, Azure AD), traitement des paiements (Stripe, Adyen), infrastructure de livraison d’e-mail (SendGrid, AWS SES), vidéoconférence (Daily.co, Twilio), signature électronique de documents (DocuSign, Adobe Sign) — ce sont des problèmes résolus avec d’excellents produits SaaS, de fortes API développeur et une portabilité des données établie. Votre équipe peut se concentrer sur le cœur propriétaire plutôt que de réinventer l’infrastructure générique.
Ce qu’il faut développer dans un modèle hybride
Le moteur de flux de travail propriétaire qui encode vos règles métier. Le modèle de données qui représente votre domaine d’une manière qu’aucun produit SaaS générique ne peut. La couche d’orchestration d’intégration qui achemine événements et données entre les services génériques achetés. La couche reporting et analytics qui donne à votre direction une visibilité sur les métriques importantes pour votre activité spécifique — pas le tableau de bord préparamétré livré avec chaque contrat SaaS. De plus en plus, cela inclut des couches d’intégration IA appliquant l’apprentissage automatique à vos données opérationnelles propriétaires.
La frontière d’intégration est la décision de conception clé
Dans un modèle hybride, la décision architecturale la plus importante est de définir où tracer la frontière d’intégration entre les composants achetés et construits. Cette frontière doit être propre, bien documentée et versionnée. Les événements qui la traversent doivent être typés, validés par schéma et idempotents. Les entreprises qui échouent dans l’hybride sont celles qui laissent des produits SaaS achetés s’enraciner profondément dans le cœur construit — recréant exactement la dette d’intégration qu’elles cherchaient à éviter.
Pour les mécanismes de tarification SaaS qui affectent l’économie du modèle hybride, lisez notre article sur les modèles de tarification SaaS en 2026.
Matrice de décision
Utilisez cette matrice pour évaluer chaque plateforme ou capacité que vous évaluez. Notez chaque facteur de 1à5. Un score total supérieur à 20 est un signal fort pour développer ; inférieur à 12 est un signal fort pour acheter ; 12–20 justifie une évaluation hybride.
| Facteur de décision | Signal achat (score 1) | Signal développement (score 5) | Votre score (1–5) |
|---|---|---|---|
| Différenciation concurrentielle | Générique ; concurrents utilisent la même catégorie SaaS | IP cœur ; moteur direct de revenus ou de marge | |
| TCO 5 ans (achat vs développement) | TCO achat clairement inférieur à la croissance projetée | TCO développement inférieur dès l’année 3 ou avant | |
| Coût de sortie dépendance fournisseur | Données portables ; coût de sortie inférieur à 180 000 € | Coût de sortie dépasse 900 000 € ; portabilité des données limitée | |
| Adéquation conformité | Fournisseur certifié ; obligations résiduelles minimales | Souveraineté des données ou exigences d’audit non satisfaisables par SaaS | |
| Complexité d’intégration | Connecteurs standard disponibles ; faible charge d’intégration | Intégration personnalisée profonde requise ; dette existante déjà élevée | |
| Besoin de contrôle de la roadmap | Roadmap fournisseur acceptable ; pas de besoin fonctionnel urgent | La roadmap doit répondre aux besoins métier en semaines, pas en trimestres |
FAQ
Une entreprise doit-elle développer ou acheter son logiciel ?
Cela dépend de si la capacité est un différenciateur concurrentiel ou une commodité. Achetez les flux de travail génériques (RH, paie, CRM de base) où le marché SaaS est mature et le coût de migration acceptable. Développez quand la capacité est un moteur direct de revenus ou de marge, quand la conformité exige la souveraineté des données, ou quand le TCO de développement sur 5 ans est inférieur au TCO SaaS à la croissance des effectifs projetée. La plupart des entreprises font les deux via un modèle hybride structuré.
Qu’est-ce que la dépendance fournisseur (vendor lock-in) et pourquoi est-elle importante à l’échelle enterprise ?
La dépendance fournisseur (vendor lock-in) est l’état où migrer hors d’une plateforme coûte plus que la valeur accumulée de ce changement. À l’échelle enterprise, cela signifie des formats de données propriétaires, des tarifs par siège croissant de façon non linéaire, des engagements contractuels minimaux et des coûts de migration pouvant atteindre 1,8–4,5 M € pour une plateforme enterprise entièrement intégrée. Modélisez le coût de sortie avant de signer un contrat pluriannuel, pas au moment du renouvellement quand tout le levier est passé au fournisseur.
Un logiciel enterprise sur mesure vaut-il le coût ?
Oui, quand appliqué au bon périmètre. Un logiciel sur mesure vaut le coût quand le flux de travail est un moteur de revenus ou de marge, quand les exigences de conformité ne peuvent pas être satisfaites par un SaaS multi-locataires, ou quand le TCO sur mesure sur 5 ans — incluant une équipe interne de 2 ETP — est inférieur au TCO SaaS sur 5 ans à la croissance projetée. Pour la majorité des entreprises avec 1 000+ sièges sur une plateforme qui croît avec les effectifs, le développement sur mesure est rentabilisé dès l’année 3.
Comment modéliser le TCO sur 5 ans d’un logiciel enterprise ?
Construisez quatre colonnes : (1) Acheter : licence année 1 au nombre de sièges actuel + années 2–5 à la croissance projetée + connecteurs d’intégration + personnalisations ; (2) Développer : développement année 1 + années 2–5 maintenance à 18 % du coût de construction + équipe plateforme de 2 ETP ; (3) Hybride : périmètre de construction réduit + SaaS générique edge ; (4) Coût de sortie pour chaque option. Prenez la VAN de chaque colonne à votre taux d’actualisation sur 5 ans. L’option avec la VAN la plus basse incluant le coût de sortie est la bonne décision. N’excluez pas le coût de sortie — c’est la variable la plus sous-estimée dans les achats enterprise.
Peut-on combiner build et buy ?
Oui — c’est le schéma recommandé pour la plupart des entreprises. Achetez les capacités génériques (identité, paiements, communications, analytics) auprès de fournisseurs SaaS matures. Développez le flux de travail différenciant, le modèle de données propriétaire et la couche d’orchestration d’intégration. La décision de conception clé est de tracer une frontière d’intégration propre et bien documentée entre les deux — et de l’appliquer. Laisser des produits SaaS achetés s’infiltrer dans le cœur construit recrée la dette d’intégration que vous cherchiez à éviter.
Dernière mise à jour le 9 juin 2026. Les chiffres TCO reflètent une livraison nearshore senior et des tarifs SaaS enterprise représentatifs pour les plateformes de flux de travail et de données entre 1 000 et 2 500 sièges. Les coûts des projets individuels varient. Chiffres cohérents avec les benchmarks des cabinets Gartner et IDC pour 2025–2026.
