Build or buy ? La règle est simple : achetez un SaaS pour tout ce qui ne vous différencie pas (compta, paie, messagerie), construisez sur mesure tout ce qui constitue votre avantage concurrentiel ou que personne ne vend en standard. Pour une PME ou ETI industrielle, ce dernier point couvre presque toujours la chaîne technique au cœur du métier : configuration produit, passerelle CAO/CFAO, pilotage d'atelier, lecture d'appels d'offres. C'est exactement là qu'aucun éditeur ne propose de solution clef en main.
Ce guide vous donne une grille de décision en 5 critères (spécificité métier, vendor lock-in, coût réel à 3-5 ans, souveraineté des données, conformité AI Act) et tranche, cas par cas, quand acheter et quand construire.
Dans cet article
- 1. Build or buy : un faux débat binaire
- 2. Critère 1 : la spécificité métier
- 3. Critère 2 : le vendor lock-in
- 4. Critère 3 : le coût réel à 3-5 ans (TCO)
- 5. Critère 4 : la souveraineté des données
- 6. Critère 5 : la conformité AI Act
- 7. La grille de décision récapitulative
- 8. L'approche hybride : acheter le socle, construire le cœur
- 9. FAQ
1. Build or buy : un faux débat binaire ?
La question "logiciel sur mesure ou SaaS ?" est mal posée quand on la pose en bloc, pour toute l'entreprise. Une PME industrielle n'a pas un système d'information : elle a une dizaine de fonctions distinctes, chacune avec son propre arbitrage. Acheter un SaaS de paie est évident. Construire son configurateur de prix sur mesure l'est tout autant. Le bon réflexe n'est pas de choisir un camp, mais de découper votre SI fonction par fonction et d'appliquer la même grille à chacune.
La distinction structurante est celle entre les fonctions "context" et les fonctions "core" (formalisée par Geoffrey Moore). Une fonction "context" est nécessaire mais ne vous différencie pas : la comptabilité d'une charpenterie ressemble à celle d'un imprimeur. Une fonction "core" est ce qui fait que vos clients vous choisissent vous : votre méthode de chiffrage, votre passage du bureau d'études à l'atelier, votre délai de réponse à un appel d'offres.
La règle d'or : on achète le context, on construit le core. Standardiser son cœur de métier sur un SaaS générique revient à abandonner volontairement son avantage concurrentiel pour ressembler à tous ses concurrents qui utilisent le même outil.
Chez JAIKIN, nous n'opposons jamais les deux. Nous concevons des logiciels sur mesure qui viennent précisément combler le "core" là où aucun éditeur ne va, tout en s'intégrant proprement aux SaaS que vous gardez pour le reste. La suite de ce guide vous aide à tracer cette frontière.
2. Critère 1 : votre besoin est-il vraiment spécifique ?
Un SaaS couvre par construction le besoin commun à un grand nombre de clients : c'est son modèle économique. Plus votre processus s'éloigne de ce tronc commun, plus l'outil standard vous coûte en contournements (tableurs parallèles, ressaisies, exceptions gérées à la main) jusqu'à devenir un frein plutôt qu'un levier.
Le cas typique de l'industrie : la chaîne CAO ne rentre dans aucune case
Aucun ERP du marché ne lit nativement un fichier BTLx. C'est pourtant le format pivot de l'industrie bois : un XML standardisé et lisible, exporté par les logiciels de CAO/CFAO (type Cadwork) vers les machines à commande numérique (type Hundegger). Ce format est un gisement de données structurées exceptionnel — chaque pièce de charpente y est décrite précisément — mais il faut une couche logicielle dédiée pour le parser, le requêter et le relier à la gestion. C'est exactement le besoin que personne ne vend en boîte.
Pour un industriel du bois alsacien (bureau d'études), nous avons construit cette passerelle sur mesure : les exports BTLx/BVX/STL alimentent l'usinage CNC et remontent vers la gestion (Sage X3) sans aucune double saisie. Côté appels d'offres, une couche IA lit le CCTP pour pré-remplir la DPGF. Aucun SaaS générique ne fait cela, parce que cela n'existe que dans ce métier précis. JAIKIN publie d'ailleurs en open-source un BTLx Parser en Python : la preuve que ce gisement technique se travaille, à condition d'aller le chercher.
Le test de spécificité en 4 questions
- Avez-vous demandé une fonctionnalité à un éditeur qui a répondu "ce n'est pas dans la roadmap" ?
- Maintenez-vous des tableurs parallèles parce que l'outil officiel ne gère pas vos règles de gestion ?
- Manipulez-vous des formats métier (BTLx, IFC, STEP, EDI sectoriel) qu'aucun outil générique ne comprend ?
- Votre manière de chiffrer, planifier ou produire est-elle un argument commercial face à vos concurrents ?
Deux "oui" ou plus : vous êtes sur du "core", le sur-mesure se justifie. Que des "non" : restez sur un SaaS, ne sur-investissez pas.
3. Critère 2 : à quel point êtes-vous prisonnier de l'éditeur ?
Le vendor lock-in (dépendance éditeur) est le coût caché le plus sous-estimé d'un SaaS. Il ne se voit pas à la signature, il se paie à la sortie. Trois formes à surveiller : la dépendance tarifaire (l'éditeur augmente ses prix et vous n'avez pas d'alternative), la dépendance fonctionnelle (votre processus dépend d'une fonction qui disparaît ou change), et la dépendance aux données (récupérer votre historique à la sortie relève du parcours du combattant).
Le révélateur de lock-in est la question : "que se passe-t-il si je veux partir l'an prochain ?" Avec un SaaS, la réponse est souvent "un export CSV incomplet et la perte de toute la logique métier configurée". Avec un logiciel sur mesure dont vous êtes propriétaire du code source, la réponse est : "rien, le code et les données m'appartiennent, un autre prestataire peut reprendre".
À retenir : le sur-mesure transforme une dépendance éditeur en actif d'entreprise. Le code devient un patrimoine inscrit à votre bilan, pas une location dont le bailleur fixe seul les conditions. Exigez systématiquement par contrat la propriété du code, l'accès au dépôt (GitHub/GitLab) et une documentation de reprise.
Attention à la nuance : le sur-mesure n'élimine pas tout lock-in, il le déplace vers le prestataire. D'où l'importance des trois garanties ci-dessus. Un sur-mesure mal contractualisé (code chez le prestataire, pas de doc) peut créer un lock-in pire qu'un SaaS.
4. Critère 3 : combien ça coûte vraiment à 3-5 ans ?
L'erreur classique consiste à comparer un abonnement mensuel ("99 EUR/mois, c'est rien") à un devis de développement ("25 000 EUR, c'est énorme"). Cette comparaison est faussée : il faut raisonner en coût total de possession (TCO) sur 3 à 5 ans, et intégrer les coûts invisibles du SaaS.
Les coûts cachés du SaaS
- Le prix par siège qui grimpe avec vos effectifs : un outil à 30 EUR/utilisateur/mois pour 25 personnes, c'est 9 000 EUR/an, et ça augmente quand vous embauchez
- Les modules premium verrouillant les fonctions réellement utiles derrière des paliers supérieurs
- Le coût des contournements : heures de ressaisie, tableurs parallèles, erreurs corrigées — un coût humain bien réel mais jamais sur la facture
- Les intégrations facturées à part, et la maintenance de connecteurs qui cassent à chaque mise à jour de l'éditeur
Le bon raisonnement : coût, mais surtout ROI
Le sur-mesure a un coût initial (développement) puis un coût récurrent plus faible (maintenance, évolution). Sur 5 ans, pour une fonction "core" intensément utilisée, le sur-mesure est fréquemment moins cher que l'empilement d'abonnements qu'il remplace — sans compter la valeur créée. Pour un industriel du bois, supprimer la double saisie entre bureau d'études et ERP libère du temps d'ingénierie à chaque dossier ; pour une compagnie aérienne accompagnée par JAIKIN, la digitalisation d'un back-office 360 a permis de réallouer environ une dizaine d'ETP vers des tâches à valeur. Ces ordres de grandeur, propres à chaque cas, sont à estimer projet par projet — mais ils ne figurent jamais dans la comparaison "abonnement vs devis".
Méthode TCO : additionnez sur 5 ans tous les coûts SaaS (abonnements + modules + intégrations + heures de contournement) et comparez au sur-mesure (développement + ~15-20 % par an de maintenance). Si l'usage est intensif et le besoin "core", le sur-mesure passe souvent devant. Notre page développement sur mesure détaille les fourchettes par type de projet.
Build ou buy : on tranche votre cas en 30 minutes
Nos experts cartographient vos fonctions "context" et "core", chiffrent le TCO sur 5 ans et vous disent précisément quoi acheter et quoi construire. Diagnostic gratuit, sans engagement.
Demander un diagnostic gratuit5. Critère 4 : où vivent vos données, et qui les contrôle ?
Pour une PME industrielle, les données ne sont pas anodines : plans CAO, nomenclatures, prix d'achat, marges, fichiers clients, savoir-faire de production. Les confier à un SaaS, c'est souvent les héberger sur une infrastructure dont vous ne maîtrisez ni la localisation, ni le cadre juridique. Un éditeur américain reste soumis au Cloud Act, quand bien même ses serveurs seraient en Europe : les autorités US peuvent en théorie y accéder.
La souveraineté des données est un critère de build-or-buy à part entière. Construire sur mesure permet de choisir un hébergement souverain en Union européenne et de garder un contrôle intégral : qui accède à quoi, où sont les sauvegardes, ce qui sort ou non de votre périmètre. C'est un avantage décisif quand vos données touchent à un secret industriel ou à la conception de produit.
C'est le choix que nous faisons systématiquement chez JAIKIN : hébergement UE, conformité RGPD par conception. Pour un préfabricant bois, nous avons livré une plateforme de pilotage de préfabrication avec modèle IFC consultable sur web et mobile et dossier de chantier 4D, le tout sur infrastructure souveraine — parce que confier des modèles de bâtiments complets à un cloud extra-européen n'était pas une option. Le sur-mesure rend cette exigence atteignable ; un SaaS standard la subit.
6. Critère 5 : votre outil sera-t-il conforme à l'AI Act ?
Dès qu'un logiciel embarque de l'IA — lecture de documents, scoring, aide à la décision, génération — il entre dans le périmètre du règlement européen sur l'intelligence artificielle (AI Act), dont les obligations montent en charge en 2026. Selon l'usage, l'outil peut être classé à risque limité ou élevé, ce qui impose transparence, traçabilité, supervision humaine et documentation technique.
Avec un SaaS IA générique, vous héritez des choix de l'éditeur : impossible de garantir qu'un modèle opaque, entraîné ailleurs, répondra à vos obligations de conformité ni d'expliquer ses décisions à un auditeur. Avec un logiciel sur mesure, la conformité est intégrée par conception : journalisation des décisions IA, maintien d'un humain dans la boucle, documentation du fonctionnement, choix de modèles maîtrisés. Vous démontrez la conformité parce que vous contrôlez le système de bout en bout.
Le critère AI Act : si votre fonction "core" doit intégrer de l'IA (lecture de CCTP, classement de pièces, aide au chiffrage), la conformité devient un argument fort pour le sur-mesure. Partenaire du Claude Partner Network d'Anthropic, JAIKIN conçoit des systèmes IA traçables et hébergés en UE, pensés dès le départ pour l'AI Act.
7. La grille de décision : quand acheter, quand construire ?
Voici la synthèse des 5 critères sous forme de grille. Lisez-la fonction par fonction : pour chaque ligne penchant vers "construire", le sur-mesure se renforce.
| Critère | Plutôt ACHETER (SaaS) | Plutôt CONSTRUIRE (sur mesure) |
|---|---|---|
| Spécificité métier | Besoin standard ("context") | Cœur de métier, formats spécifiques (BTLx, IFC) |
| Vendor lock-in | Sortie facile, données portables | Vous voulez posséder le code et les données |
| Coût à 5 ans (TCO) | Peu d'utilisateurs, usage occasionnel | Usage intensif, nombreux sièges, contournements coûteux |
| Souveraineté des données | Données peu sensibles | Secret industriel, hébergement UE exigé |
| Conformité AI Act | Pas d'IA, ou IA non critique | IA décisionnelle, traçabilité et supervision requises |
| Délai de mise en œuvre | Besoin immédiat (jours/semaines) | Vision long terme, projet de 2 à 6 mois acceptable |
Aucun arbitrage n'est universel : il dépend de votre secteur, de votre maturité et de l'intensité d'usage. Mais le motif se répète dans l'industrie : le context se loue, le core se construit.
8. L'approche hybride : acheter le socle, construire le cœur
Les PME industrielles qui réussissent leur transformation ne choisissent pas un camp : elles combinent les deux. Elles gardent leurs SaaS pour la comptabilité, la paie, la messagerie, et construisent sur mesure une couche "hub" qui orchestre le tout et incarne leur cœur de métier. Cette couche centralise, connecte via API et automatise — sans tout reconstruire.
Pour Kappeler Enseignes (PME industrielle nommable), nous avons livré exactement cela : une passerelle entre les logiciels de CAO (CorelDRAW, Illustrator) et l'IA pour générer les plans de façade, l'automatisation administrative, le suivi de production en atelier, et une refonte web qui a porté +450 % de leads et ouvert le marché allemand. L'entreprise a conservé ses outils standards ; le sur-mesure est venu connecter et automatiser ce que personne ne vendait en boîte.
Le séquençage recommandé : commencez par un "quick win" sur le processus le plus douloureux du "core", prouvez la valeur, puis étendez module par module. Cette logique de hub connecté est détaillée dans nos pages dédiées à l'IA industrielle et à l'intégration CRM/ERP, qui évitent de repartir de zéro.
Et la migration d'ERP dans tout ça ?
Le même raisonnement s'applique à l'ERP : on garde l'éditeur (Sage X3, Odoo) comme colonne vertébrale "context", et on construit autour les passerelles "core" qui suppriment les ressaisies — bureau d'études vers ERP, atelier vers gestion. Plutôt que de tout migrer d'un bloc, on connecte intelligemment. Notre approche est décrite sur la page migration ERP pour PME.
FAQ
Build or buy : comment trancher rapidement pour ma PME ?
Découpez votre SI fonction par fonction et posez deux questions à chacune : "est-ce que ça me différencie de mes concurrents ?" et "est-ce qu'un éditeur le vend en standard ?". Si la fonction vous différencie et n'existe pas en boîte (configurateur, passerelle CAO, lecture d'appels d'offres), construisez. Si elle est générique et bien couverte par le marché (compta, paie), achetez. La règle tient en une phrase : on achète le context, on construit le core.
Un SaaS n'est-il pas toujours moins cher qu'un développement sur mesure ?
Non, pas sur la durée. La comparaison "99 EUR/mois vs 25 000 EUR" est trompeuse. En coût total de possession sur 5 ans, il faut ajouter au SaaS : le prix par siège qui grimpe, les modules premium, les intégrations facturées et surtout les heures de contournement (tableurs parallèles, ressaisies). Pour une fonction "core" à usage intensif, le sur-mesure passe fréquemment devant — sans compter la valeur créée (temps libéré, erreurs évitées).
Le sur-mesure crée-t-il une dépendance à mon prestataire ?
Seulement si le contrat est mal ficelé. Exigez trois garanties : la propriété du code source (le code vous appartient), l'accès au dépôt (GitHub/GitLab) et une documentation de reprise permettant à un autre développeur de continuer. Avec ces clauses, le sur-mesure crée moins de lock-in qu'un SaaS, car vous restez propriétaire de votre code et de vos données. Chez JAIKIN, ces trois points sont inclus par défaut.
Pourquoi la souveraineté des données pousse-t-elle vers le sur-mesure ?
Parce qu'un SaaS impose sa localisation et son cadre juridique. Un éditeur américain reste soumis au Cloud Act même avec des serveurs en Europe. Construire sur mesure permet de choisir un hébergement souverain en UE, conforme RGPD par conception, et de garder le contrôle intégral sur des données sensibles (plans, marges, savoir-faire de production). Pour un industriel, c'est souvent décisif.
Sources
- Geoffrey Moore — "Dealing with Darwin" : distinction core vs context (concept de référence build-or-buy)
- Commission européenne — Règlement (UE) 2024/1689 sur l'intelligence artificielle (AI Act), calendrier d'application 2025-2027
- CNIL — Recommandations sur le transfert de données hors UE et le Cloud Act
- JAIKIN — Projets livrés (Kappeler Enseignes, industriel du bois, préfabricant, compagnie aérienne) et outils open-source (BTLx Parser)
