Logiciel sur mesure ou standard ? Guide de décision B2B

Première distinction : standard ou votre avantage ?

Comptabilité, e-mail, paie — processus standards. Des milliers d'entreprises les réalisent de la même façon. Les solutions standards (SAP, QuickBooks, Workday) sont matures, sûres et bon marché. Développer du sur-mesure ici est généralement un gâchis.

Mais votre "avantage concurrentiel" — un algorithme de tarification propre, une intégration propre à un client, un flux opérationnel particulier — devient générique dès que vous le fourrez dans un outil standard. Les 20 % de l'activité qui créent vraiment de la valeur tombent à 0 %. Ici, le sur-mesure n'est pas négociable : si vous utilisez les mêmes outils que votre concurrent, vous produisez le même résultat.

Quatre questions pratiques

Avant de trancher, répondez à ces quatre :

1) Le processus est-il un standard du secteur ou propre à l'entreprise ? 2) Le modèle de données évolue-t-il avec le monde extérieur (facturation, intégrations) ? Si oui, un logiciel standard ou un SaaS à API ouverte convient. 3) Votre modèle d'affaires autour de ce processus va-t-il changer dans les 24 prochains mois ? Si oui, le plafond de configuration d'un paquet vous bridera. 4) Votre avantage concurrentiel se cache-t-il dans le processus ? Si vous le citez en expliquant "pourquoi les clients nous choisissent", le sur-mesure est obligatoire.

Deux réponses "distinctives" ou plus (unique, avantage caché) pointent vers le sur-mesure. Sinon, commencez avec un paquet et migrez au plafond — c'est la stratégie la moins chère.

L'approche hybride : le choix le plus pragmatique

Dans la vraie vie, la plupart des décisions B2B ne sont ni "tout sur mesure" ni "tout standard" — elles sont la combinaison intelligente des deux. Le schéma : faire tourner la couche standard (comptabilité, RH, colonne vertébrale CRM, e-mail) sur le meilleur logiciel standard du marché ; construire la couche différenciante (moteur de tarification, portail client, flux opérationnel, transformation de données) en sur-mesure intégré aux paquets par API.

Cela apporte trois choses : (1) sécurité fournisseur et TCO faible sur la couche commodité, (2) contrôle complet et itération rapide sur le différenciateur, (3) chaque couche évolue à son rythme. En pratique, cela se traduit par "SaaS + API + une fine couche applicative sur mesure". En grandissant, la couche sur-mesure s'élargit ; les couches standardisées restent stables. Chez Setviva, environ 70 % des clients commencent en hybride — ceux qui demandent un développement 100 % sur mesure choisissent souvent, une fois les flux cartographiés, de déplacer aussi les processus standards vers des outils standards.

Estimer correctement le coût de migration

L'erreur la plus fréquente des décideurs B2B : ne comparer que le prix de la licence ou du projet. Le vrai coût est sous la ligne de flottaison. En passant au logiciel standard, ajoutez : migration et nettoyage des données, formation, perte de productivité pendant la transition, développement d'intégrations, personnalisation du reporting, redesign des processus. Cela totalise le plus souvent 3 à 5 fois le prix de la licence. En passant au sur-mesure, ajoutez : design et discovery, développement, tests, formation, maintenance et itération continue, infrastructure (serveurs, monitoring, sauvegardes), risque de propriété (qui l'opère si l'équipe part). Cela totalise le plus souvent 1,5 à 2 fois le prix de construction.

Pour une comparaison honnête, écrivez le coût total de possession (TCO) sur 24–36 mois et comparez les deux options au même niveau. Dans chaque proposition Setviva, nous présentons ce TCO détaillé dès le départ pour que la décision repose sur "réellement bon marché" et non sur "qui a l'air bon marché". Bien calculer le coût de migration peut compter plus que le choix lui-même.

Le risque de dépendance : une lame à double tranchant

Tout décideur demande « combien cela coûte-t-il aujourd'hui », mais presque personne ne demande « qui détiendra le rapport de force sur moi dans trois ans ». Avec le SaaS, c'est l'éditeur qui écrit la feuille de route, pas vous. Les contrats se renouvellent avec des hausses de prix qui peuvent devenir sévères une fois que l'outil est ancré dans vos opérations quotidiennes ; des fonctionnalités sont dépréciées ou reléguées dans une offre supérieure ; l'éditeur peut être racheté et le produit abandonné selon un calendrier que vous n'avez pas choisi. Rien de tout cela n'est hypothétique — c'est le cycle de vie ordinaire des éditeurs de logiciels — et plus un outil s'enracine dans vos opérations, plus il devient coûteux de le quitter, même si son prix triple. Ce n'est pas une raison d'éviter le SaaS — pour des processus standards, c'est généralement encore le bon choix — mais cela signifie que la comparaison des « frais mensuels » masque la vraie question : combien de rapport de force cédez-vous à une partie dont les intérêts ne sont pas les vôtres ?

Le logiciel sur mesure retourne le problème du rapport de force vers l'intérieur. Le risque n'est plus la feuille de route d'un éditeur, mais le facteur bus de votre propre équipe. Si les développeurs qui ont conçu le système partent et que les décisions qui le sous-tendent n'ont jamais été documentées, le système devient discrètement une boîte noire que personne ne veut toucher. Livré à lui-même, sans maintenance, il voit ses dépendances vieillir, les correctifs de sécurité cesser d'arriver, et le « sur mesure » finit par devenir exactement ce que vous vouliez éviter — un système fragile et obsolète. Le verrouillage, ici, n'est pas une clause contractuelle, c'est un savoir concentré, mais l'effet est identique : vous ne pouvez pas partir sans en payer le prix fort.

La solution consiste à traiter le coût de sortie comme un critère de décision dès le premier jour, des deux côtés. Pour le SaaS, avant de signer, vérifiez quelles données vous pouvez exporter et sous quel format, si le contrat plafonne les hausses de prix, et à quel point partir serait réellement pénible en pratique. Pour le sur mesure, exigez que la propriété du code source, l'accès à l'infrastructure et une documentation à jour soient des livrables contractuels, pas des faveurs — et choisissez un partenaire qui code pour celui qui héritera du système demain, pas seulement pour la démonstration. Quelle que soit la voie choisie, posez la question de la sortie avant celle de l'achat. L'option dont vous pouvez sortir vaut plus que celle qui paraît la moins chère aujourd'hui.