Construire, acheter ou assembler une application ne se décide pas une fois pour toutes : la bonne réponse change d’un processus à l’autre. Achetez les fonctions standard, celles où vous pouvez adapter vos pratiques à l’outil sans rien perdre. Construisez ce qui vous distingue de vos concurrents ou ce qu’aucune solution ne couvre sans contorsions. Et dans la plupart des PME et ETI, assemblez : des solutions du marché pour le socle, des développements sur mesure pour la différence, et des intégrations solides pour relier le tout.
Voici la grille que nous utilisons pour trancher, avec ses critères, ses pièges et un exemple.
Que recouvrent exactement les trois options ?
- Acheter (buy) : souscrire une solution du marché, le plus souvent en SaaS (abonnement, hébergement par l’éditeur), et la paramétrer. Vous bénéficiez des évolutions de l’éditeur, mais vous suivez sa feuille de route.
- Construire (build) : faire développer une application spécifique, dont vous possédez le code. Elle épouse vos règles métier, mais vous en assumez la maintenance et les évolutions.
- Assembler (compose) : combiner plusieurs briques, achetées ou développées, qui échangent des données par API. Une architecture composable est une organisation du système d’information en briques autonomes et remplaçables, chacune responsable d’une capacité métier.
Ces options ne s’excluent pas. Une même entreprise peut acheter sa comptabilité, louer un CRM du marché et faire développer son outil de chiffrage, le tout relié par des flux automatisés.
Quelle question poser en premier ?
La question décisive n’est pas technique : ce processus vous distingue-t-il de vos concurrents ?
Martin Fowler formule cette distinction dans un texte devenu classique, Utility vs Strategic Dichotomy. Une fonction « utilitaire » (la paie en est l’exemple type) doit simplement fonctionner de façon fiable ; une fonction « stratégique » est celle où votre manière de faire crée un avantage. Pour les fonctions utilitaires, sa position est nette : acheter la solution et adapter vos processus à l’outil. Il ajoute que les projets réellement stratégiques sont peu nombreux, et que la règle des 80/20 ressemble plutôt, ici, à du 95/5.
La cartographie de Wardley apporte une lecture complémentaire. Elle classe chaque composant selon son stade d’évolution, du plus nouveau au plus banalisé, d’après le glossaire Wardley Maps, qui recommande d’investir dans les deux premiers stades et d’envisager l’externalisation pour les deux derniers. La colonne de droite traduit cette logique en options concrètes :
| Stade | Caractéristiques | Option généralement adaptée |
|---|---|---|
| Genèse | Nouveau, incertain, en changement permanent | Construire, en expérimentant |
| Sur mesure | Mieux défini, mais rare et propre à chaque organisation | Construire ou assembler |
| Produit | Stable, bien défini, proposé par plusieurs fournisseurs | Acheter et paramétrer |
| Commodité | Omniprésent, standardisé, quasi utilitaire | Louer ou externaliser |
Un même besoin glisse avec le temps vers la droite du tableau : ce qui exigeait un développement il y a dix ans (signature électronique, visioconférence) s’achète aujourd’hui sur étagère.
La grille de décision en sept critères
Pour chaque processus étudié, notez chaque critère et regardez de quel côté penche la balance.
| Critère | Penche vers l’achat | Penche vers la construction |
|---|---|---|
| Différenciation | Processus standard de votre secteur | Processus qui fait votre avantage concurrentiel |
| Couverture fonctionnelle | Une solution couvre l’essentiel sans adaptation lourde | Les solutions imposent des contournements (tableurs, ressaisies) |
| Stabilité du besoin | Règles stables, dictées par la réglementation | Règles qui évoluent souvent avec votre offre |
| Intégration | L’outil dialogue nativement avec votre existant | Les flux sont spécifiques et critiques |
| Coût sur plusieurs années | Abonnement raisonnable au regard du nombre d’utilisateurs | Licences par utilisateur élevées, coûts de personnalisation récurrents |
| Délai | Besoin immédiat, standard | Un délai de quelques mois est acceptable |
| Maîtrise et dépendance | Dépendance à l’éditeur acceptable | Besoin de maîtriser le code, la feuille de route et les données |
Quand la majorité des critères penche vers l’achat, achetez sans état d’âme. Quand elle penche vers la construction, développez, mais en limitant le sur-mesure à ce qui le justifie. Quand le résultat est partagé, c’est presque toujours un signal pour assembler.
Quels coûts cachés chaque option comporte-t-elle ?
En achetant
Le prix affiché n’est qu’une partie de l’addition :
- la personnalisation : chaque adaptation hors du standard doit être maintenue, et peut casser à la montée de version suivante ;
- les contournements : ce que l’outil ne fait pas finit dans des tableurs et des ressaisies, un coût diffus mais réel ;
- la tarification par utilisateur, qui croît avec l’entreprise, et les modules complémentaires payants ;
- la sortie : récupérer ses données et son historique dans un format exploitable n’est pas toujours prévu.
Autre point souvent oublié : vous payez pour des fonctions que vous n’utiliserez pas. Le Feature Adoption Report de Pendo estime que 80 % des fonctionnalités d’une application moyenne sont rarement ou jamais utilisées.
Enfin, une solution SaaS qui héberge des données personnelles fait de l’éditeur votre sous-traitant au sens du RGPD. Le guide du sous-traitant de la CNIL rappelle les obligations qui doivent figurer au contrat, dont l’autorisation écrite préalable du client avant tout recours à un autre sous-traitant. Vérifiez ces clauses avant de signer, comme la localisation de l’hébergement.
En construisant
- la maintenance : correctifs, mises à jour de sécurité, adaptation aux systèmes connectés, sur toute la durée de vie ;
- la dépendance au prestataire, si le code, la documentation et les accès ne vous sont pas remis ;
- le temps de vos équipes, indispensable en cadrage et en recette.
Ces coûts se maîtrisent, mais ils doivent être budgétés dès le départ. Notre article sur ce qui fait le coût d’une application sur mesure détaille le coût total de possession.
En assemblant
L’assemblage concentre la difficulté sur les jointures. Chaque flux entre deux briques doit être conçu, surveillé et repris en cas d’erreur. Il faut aussi décider quelle brique fait foi pour chaque donnée (le client, l’article, le tarif), sans quoi les incohérences se multiplient : c’est le rôle des données de référence. Une architecture assemblée sans pilotage des intégrations devient vite un enchevêtrement fragile.
Un exemple : une entreprise de négoce
Prenons une entreprise hypothétique de négoce de matériel technique, 120 salariés, qui veut moderniser son système d’information. Processus par processus, la grille donne :
- Comptabilité et paie : fonctions utilitaires, encadrées par la réglementation. Achat d’une solution du marché, sans personnalisation.
- CRM : le cycle de vente est classique. Achat d’un CRM du marché, par exemple HubSpot, avec un paramétrage léger.
- Chiffrage des offres techniques : c’est son savoir-faire, avec des règles de compatibilité entre produits et des remises négociées par client. Aucune solution ne les couvre sans tableurs annexes. Développement d’un outil de chiffrage sur mesure.
- Portail client : les clients veulent suivre leurs commandes et retrouver leurs documents. Développement d’un portail léger, alimenté par l’ERP.
- Jointures : une couche d’intégration synchronise clients et devis entre le CRM, l’outil de chiffrage et l’ERP, avec un journal des échanges et une reprise automatique des erreurs.
Résultat : l’essentiel du système est acheté, le sur-mesure se concentre sur deux applications à forte valeur, et l’effort d’intégration est explicitement budgété. C’est ce type d’architecture que nous construisons dans nos projets d’applications web et d’intégrations et API.
Les pièges à éviter
- Décider par doctrine (« chez nous, on achète toujours ») plutôt que processus par processus.
- Comparer un abonnement mensuel à un développement ponctuel sans ramener les deux sur la même durée, au moins trois à cinq ans.
- Juger une solution sur une démonstration préparée par l’éditeur plutôt que sur vos cas réels, y compris les exceptions.
- Sous-estimer l’intégration dans l’option assemblée : c’est elle qui fait tenir l’ensemble.
- Construire ce qui existe déjà : authentification, paiement ou envoi d’e-mails s’achètent sous forme de services éprouvés.
Pour le cas particulier de l’ERP, notre comparatif Odoo ou ERP sur mesure applique cette grille à un exemple concret.
Par où commencer ?
Listez vos cinq à dix processus principaux, appliquez la question de la différenciation, puis la grille aux cas qui restent ouverts. Vous obtiendrez une carte claire : ce qui s’achète, ce qui se construit, et les flux à organiser entre les deux.
Si vous voulez confronter votre situation à cette grille, notre diagnostic de projet vous pose les questions essentielles en deux minutes, et nous revenons vers vous avec une recommandation argumentée, y compris quand la bonne réponse est de ne rien développer.
