Décider
La comparaison honnête entre un abonnement SaaS et un outil sur mesure : seuils de bascule, coûts complets, risques des deux côtés.
Avertissement d'emblée : ce guide est édité par Visigol, une agence qui développe des logiciels sur mesure. Nous avons donc un intérêt commercial direct à ce que la réponse soit « développer ». Ce chapitre est écrit en connaissance de cause, et il commence par les cas où le sur-mesure est une mauvaise décision — parce que ce sont les plus nombreux. Lisez-le avec ce biais en tête, et vérifiez nos chiffres.
Dans la grande majorité des situations, un abonnement SaaS est le bon choix. Les raisons sont structurelles, pas conjoncturelles :
Un développement sur mesure n'est justifié que si un élément précis casse ce raisonnement. Il y en a trois, et il faut qu'au moins un soit vrai, franchement, pas approximativement.
Si votre manière d'évaluer les candidats est ce qui vous distingue, un outil générique vous force dans son modèle. Le cas typique : un cabinet qui a construit une méthodologie d'évaluation propre, ou une entreprise dont le recrutement repose sur une mécanique inhabituelle — cooptation structurée, évaluation en plusieurs tours avec pondérations spécifiques, sélection sur des critères métier qu'aucun ATS ne modélise.
Le test : listez les cinq choses que fait votre processus et qu'un ATS standard ne sait pas faire. Si vous n'en trouvez pas cinq, ou si les cinq sont des préférences d'affichage, ce seuil n'est pas franchi.
Un abonnement par utilisateur devient coûteux quand beaucoup de gens doivent y accéder. À 40 € par utilisateur et par mois, cinquante utilisateurs représentent 24 000 € par an, soit 72 000 € sur trois ans. À ce niveau, un développement spécifique entre dans la comparaison.
Attention au calcul honnête : il faut ajouter au coût du développement la maintenance annuelle — comptez entre quinze et vingt-cinq pour cent du coût initial par an — et le fait que vous devrez financer vous-même chaque évolution future. Un outil sur mesure n'est pas un actif gratuit une fois livré.
Ce seuil est réellement franchi moins souvent qu'on ne le croit, parce que beaucoup d'éditeurs proposent des rôles à tarif réduit pour les utilisateurs occasionnels. Demandez-les avant de conclure.
Si la valeur attendue vient surtout du raccordement à votre ERP, votre paie ou un outil métier maison, et qu'aucun éditeur ne propose ce connecteur, vous allez payer un développement de toute façon. La question devient : développer un connecteur vers un outil que vous ne contrôlez pas, ou développer l'outil.
Le connecteur reste souvent le bon choix, parce qu'il est beaucoup moins cher. Il devient le mauvais choix quand l'éditeur ne fournit pas d'API exploitable, ce qui vous oblige à des contournements fragiles.
Nous développons des logiciels sur mesure, et voici quand nous déconseillons de nous en commander un.
Vous recrutez moins de vingt fois par an. Le volume ne justifie jamais l'investissement. Un ATS d'entrée ou de milieu de gamme fera mieux pour un prix sans commune mesure.
Votre processus n'est pas stabilisé. Développer fige des décisions. Si votre organisation RH a changé deux fois en dix-huit mois, ou si vous n'avez pas encore de processus écrit, vous allez payer pour coder une version intermédiaire de quelque chose qui va encore bouger. Prenez un SaaS, stabilisez, et reposez la question dans deux ans.
Vous cherchez d'abord à économiser. Un développement sur mesure coûte plus cher les trois premières années dans presque tous les cas. Il peut devenir moins cher ensuite, si et seulement si le seuil 2 est franchi. Si l'argument d'achat est « ça reviendra moins cher », c'est presque toujours faux à l'horizon où la décision se juge.
Personne en interne ne portera le projet. Un développement spécifique exige un interlocuteur côté client qui décide, arbitre et teste. Sans cette personne, le projet dérive ou livre à côté. C'est la première cause d'échec, avant la technique.
Vous voulez « la même chose, mais à nous ». Reproduire un ATS existant sans besoin distinctif produit une version moins aboutie, plus chère, et sans l'écosystème d'intégrations. Si le besoin est standard, achetez du standard.
| Abonnement SaaS | Développement sur mesure | |
|---|---|---|
| Mise en route | Jours | Plusieurs mois |
| Coût année 1 | Abonnement + mise en service | Investissement initial complet |
| Coût années suivantes | Abonnement, qui augmente | Maintenance, entre 15 et 25 % de l'initial |
| Évolutions | Arrivent seules, mais pas celles que vous voulez | À votre main, mais à votre charge |
| Dépendance | Forte : prix, pérennité, feuille de route de l'éditeur | Faible si le code vous appartient, forte s'il appartient au prestataire |
| Risque d'échec | Quasi nul, testable avant achat | Réel |
| Conformité RGPD | Traitée par l'éditeur, à vérifier | À votre charge intégralement |
Entre les deux existe une option que les deux camps commerciaux ont intérêt à ne pas mentionner : garder le SaaS et développer uniquement ce qui manque.
Concrètement, vous conservez l'ATS du marché pour le pipeline, la conformité et les mises à jour, et vous faites développer la brique spécifique — un connecteur vers votre paie, un module d'évaluation métier, un tableau de bord qui agrège vos données. Le budget est d'un ordre de grandeur inférieur à celui d'un outil complet, et vous gardez la maintenance mutualisée sur le cœur.
Cette approche demande une seule chose à l'ATS : une API exploitable. C'est le critère à vérifier en priorité si vous envisagez cette voie, et le chapitre sur les intégrations explique comment évaluer la qualité réelle d'une API avant de signer.
C'est aussi, honnêtement, le type de projet que nous menons le plus souvent chez Visigol : pas le remplacement d'un outil du marché, mais la pièce manquante autour de lui.
Le volume de recrutement n'est pas le bon indicateur : c'est le nombre d'utilisateurs et la spécificité du processus qui font basculer. Une entreprise qui recrute cent fois par an de façon standard a tout intérêt à acheter ; un cabinet de quinze consultants avec une méthodologie propre peut justifier un développement à volume bien moindre.
Trop de paramètres pour un chiffre unique, mais l'ordre de grandeur utile est celui-ci : un outil de suivi de candidatures réellement exploitable, avec site carrière, pipeline configurable, gestion des droits et un connecteur, représente plusieurs dizaines de milliers d'euros. Toute proposition très inférieure décrit un périmètre plus restreint que ce que vous imaginez — demandez ce qui est exclu.
Oui, et c'est une option sérieuse qui réduit le coût initial. Elle ne supprime pas les coûts : hébergement, mises à jour de sécurité, montée de version et développement des adaptations restent à votre charge. C'est un sur-mesure avec une base de départ, pas un SaaS gratuit.
Rien, si vous possédez le code, s'il est déposé sur un dépôt qui vous appartient, et s'il est documenté et construit avec des technologies courantes. Tout, si ces trois conditions ne sont pas réunies. C'est le point à sécuriser contractuellement avant de commencer, pas au moment où le problème se pose.
Ni l'un ni l'autre par nature. Un SaaS vous fait bénéficier du travail de conformité de l'éditeur, mais vous rend dépendant de ses choix de sous-traitance et d'hébergement. Un développement sur mesure vous laisse maîtriser l'hébergement et les durées de conservation, mais la charge de conformité est intégralement la vôtre. Voir le chapitre RGPD.
Les modèles de tarification, les fourchettes réellement pratiquées et les coûts que les grilles publiques ne montrent pas.
Les quatre intégrations qui font gagner du temps, celles qui n'en font pas gagner, et comment évaluer la qualité d'une API avant de signer.
Ce qu'est réellement un logiciel de recrutement, les quatre familles d'outils, les budgets constatés et la méthode pour choisir.