Sur mesure ou SaaS ? La grille de décision honnête
Quand faut-il développer son propre outil et quand faut-il acheter un SaaS ? Une grille de décision concrète pour ne pas se tromper.
C'est sans doute la décision IT la plus mal tranchée en PME : faut-il acheter un SaaS existant ou développer un outil sur mesure ?
Les deux extrêmes sont mauvais conseillers. "Tout doit être sur mesure" mène à des projets infinis qui ne livrent rien. "Il y a forcément un SaaS pour ça" mène à un empilement d'outils qui ne se parlent pas et coûtent une fortune.
Voici la grille de décision qu'on utilise réellement.
La règle des 80/20 inversée
Pour un besoin métier donné, posez-vous cette question :
Si je liste tout ce que cet outil doit faire, est-ce qu'au moins 80 % est commun à toutes les entreprises de mon secteur ?
Si oui → SaaS. C'est un terrain où les éditeurs ont déjà investi des dizaines de millions. Vous ne ferez pas mieux pour 30 000 €.
Si non → sur mesure (au moins partiellement). Si plus de 20 % de votre besoin est spécifique, le SaaS va vous frustrer : il manquera toujours la fonctionnalité critique, et les contournements vont s'accumuler.
Exemple :
- Compta → SaaS. Aucune PME ne fait sa compta différemment des autres.
- Outil de relance des factures clients → SaaS suffit dans 80 % des cas.
- Logiciel qui pilote une chaîne de production spécifique → sur mesure. Aucun SaaS ne sait ce que font vos machines.
- CRM → SaaS dans 90 % des cas, sauf si votre processus de vente est vraiment atypique.
Les questions qui changent la réponse
1. Combien d'utilisateurs ? Plus vous avez d'utilisateurs, plus le SaaS coûte cher. À 20 utilisateurs, un SaaS à 30 €/utilisateur/mois = 600 €/mois = 7 200 €/an. Sur 5 ans : 36 000 €. À ce niveau, un développement sur mesure peut s'amortir.
2. Quelle valeur stratégique ? Si l'outil fait votre différence sur le marché, sur mesure. Si c'est un outil de support invisible (compta, paie, RH), SaaS.
3. Quelle vitesse de changement ? Si vos process changent tous les 6 mois, le SaaS deviendra rapidement limitant. Si c'est stable, le SaaS suffit.
4. Quelles intégrations ? Si vous avez besoin de connecter 5+ systèmes ensemble, soyez vigilant sur les SaaS. Beaucoup ont des APIs limitées ou payantes au volume.
Le piège du "low-code / no-code"
Les plateformes no-code (Bubble, Retool, Airtable, etc.) ont leur place, mais elles cumulent les deux risques :
- Elles ne sont pas du SaaS pur — vous y mettez de la logique métier
- Elles ne sont pas du sur mesure — vous êtes limité par la plateforme
Quand le no-code marche : pour un MVP rapide, un outil interne simple, ou un PoC qu'on remplacera plus tard.
Quand ça finit mal : quand l'outil no-code grossit, on découvre qu'on dépend totalement de la plateforme, qu'on ne peut pas exporter proprement, et que les coûts explosent au volume. À 5 utilisateurs, 40 €/mois. À 50 utilisateurs, 2 000 €/mois.
Le vrai coût total du SaaS
Le coût SaaS visible (l'abonnement) cache souvent 3 coûts invisibles :
Verrouillage des données. Vos données sont dans leur format. Sortir proprement, c'est un projet à part entière.
Contournements coûteux. Quand le SaaS ne fait pas exactement ce qu'il faut, les équipes développent des hacks (exports Excel, scripts manuels, processus parallèles). Comptez 2 à 5h/semaine perdues par ces contournements.
Inflation tarifaire. Les éditeurs SaaS augmentent leurs prix régulièrement. Sur 5 ans, l'addition peut doubler.
Le vrai coût total du sur mesure
Symétriquement :
Maintenance. Un outil sur mesure coûte 15 à 25 % de son coût initial par an, en moyenne, pour rester à jour (sécurité, dépendances, petites améliorations).
Documentation et onboarding. Pour qu'un nouvel arrivant puisse prendre la main, il faut documenter. C'est un investissement souvent sous-estimé.
Évolution. À chaque nouveau besoin, il faut le développer.
La solution intermédiaire : SaaS + couche custom
Souvent, la meilleure réponse n'est ni l'un ni l'autre. C'est :
SaaS pour 80 % du besoin (compta, CRM, paie) + développement sur mesure pour les 20 % spécifiques (un module qui automatise vos particularités, connecté aux SaaS via API).
Cette approche cumule les avantages : le SaaS gère le commun, vous investissez là où ça vous différencie.
C'est ce que nous faisons sur la majorité de nos projets : on n'invente pas l'eau chaude. On code uniquement la partie qui n'existe pas, et on connecte au reste.
La grille de décision en pratique
| Critère | Pousse vers SaaS | Pousse vers sur mesure |
|---|---|---|
| Besoin standard du marché | ✅ | ❌ |
| Différenciation stratégique | ❌ | ✅ |
| Faible nombre d'utilisateurs (<20) | ✅ | ❌ |
| Volume élevé (>50 utilisateurs) | ❌ | ✅ |
| Intégrations multiples | ❌ | ✅ |
| Évolution rapide du métier | ❌ | ✅ |
| Budget limité | ✅ | ❌ |
| Souveraineté des données | ❌ | ✅ |
Si vous êtes 4-3 ou 5-3, le débat est sain. Si vous êtes 7-1, la décision est claire dans un sens ou dans l'autre.
Comment démarrer
Avant de signer un SaaS ou de lancer un dev, posez 3 questions à un expert externe :
- "Y a-t-il un SaaS qui fait déjà ce que je veux à 80 % ?"
- "Quel serait le coût d'un développement sur mesure équivalent ?"
- "Sur 5 ans, quel coût total ?"
C'est exactement ce que produit un audit court — en 1 à 2 semaines, vous avez la réponse chiffrée.