ATS en SaaS ou on-premise : comment trancher quand on recrute sur plusieurs sites
Les écarts d’équipement numérique à l’intérieur d’un même secteur sont beaucoup plus larges qu’on ne l’imagine. La dernière publication de l’INSEE sur les technologies de l’information dans les entreprises en donne une illustration frappante : dans les transports et l’entreposage, seules 9 % des entreprises déclarent utiliser au moins une technologie d’intelligence artificielle, mais ce taux grimpe à 66 % dès qu’on le pondère par l’emploi. Traduction : les grands groupes du secteur sont outillés, les entreprises de taille intermédiaire beaucoup moins, et ce sont précisément ces dernières qui arbitrent aujourd’hui leur premier vrai projet de système de gestion des candidatures.
Or ce choix se prend rarement dans de bonnes conditions. Le débat SaaS contre on-premise est presque toujours présenté comme une question d’architecture, à trancher entre la DSI et l’éditeur. Dans les faits, il engage trois choses qui dépassent largement le périmètre technique, et il se décide le plus souvent sans que l’utilisateur final soit dans la pièce.
Ce que le choix engage réellement
Le premier enjeu porte sur les données de candidature. Une idée reçue tenace veut que l’hébergement interne protège mécaniquement mieux les candidats. C’est faux sur le plan juridique : dans les deux modèles, l’entreprise reste responsable de traitement au sens du RGPD. Ce qui change, ce n’est pas la responsabilité, c’est la répartition des moyens pour l’assumer. En SaaS, vous déléguez l’exploitation à un sous-traitant dont vous devez vérifier le contrat, la localisation d’hébergement et les engagements de sécurité. En interne, vous conservez la main, mais vous conservez aussi la charge de patcher, de surveiller et de sauvegarder, avec les ressources que vous avez réellement, pas celles que vous aimeriez avoir.
Le deuxième enjeu est le délai de mise en service, rapporté au rythme des recrutements. Un projet qui s’étale sur six mois pendant que douze postes sont ouverts n’est pas une décision neutre : il se paie en candidatures perdues et en process gérés entre-temps sur des tableurs, qu’il faudra ensuite reprendre. Dans les secteurs sous tension, ce coût de transition est rarement chiffré alors qu’il est souvent le plus lourd.
Le troisième enjeu est le coût complet sur cinq ans. Les comparatifs d’éditeurs opposent volontiers un abonnement mensuel à un prix de licence, ce qui ne veut pas dire grand-chose. Le poste systématiquement absent des deux côtés du tableau est le temps interne : celui de la DSI pour l’exploitation, celui des équipes RH pour l’administration fonctionnelle, le paramétrage des workflows et la formation des nouveaux arrivants.
Le point aveugle du comité de décision
Il y a un point commun à la plupart des projets ATS qui déçoivent : l’utilisateur réel de l’outil n’a pas été consulté avant l’arbitrage.
Dans une entreprise mono-site où les recruteurs sont des profils RH assis devant un poste fixe, cette absence se rattrape. Dans un environnement industriel ou logistique multi-sites, elle se paie cash. L’utilisateur quotidien d’un ATS n’y est presque jamais un recruteur à temps plein. C’est un responsable de site qui passe la moitié de sa journée en production et consulte ses candidatures entre deux réunions. C’est un chef d’équipe qui doit valider un profil d’intérimaire depuis un téléphone, debout, au bord d’un quai, avec une connexion qui varie selon l’endroit de l’entrepôt où il se trouve. C’est une équipe qui absorbe soixante-dix embauches en trois semaines à l’approche d’un pic saisonnier, puis retombe à deux par mois.
Ces trois usages ne se testent pas en démonstration commerciale, et ils départagent pourtant les deux modèles bien plus sûrement que la fiche technique.
Le modèle SaaS : ce qu’il apporte, ce qu’il contraint
L’argument décisif du SaaS n’est pas le prix, c’est le temps. Quelques semaines suffisent généralement pour disposer d’un outil opérationnel, sans mobiliser d’infrastructure ni de compétence d’exploitation en interne. Les mises à jour, les correctifs de sécurité et l’évolution fonctionnelle sont pris en charge par l’éditeur, ce qui compte particulièrement pour les entreprises dont la DSI se compte sur les doigts d’une main. L’accès depuis un navigateur mobile est natif, sans travail de sécurisation supplémentaire, et la capacité à absorber un pic de volume est intégrée au service.
Ce confort a des contreparties réelles. La dépendance à la connectivité en est la première, et elle n’est pas théorique sur un site industriel isolé ou dans certaines zones d’entrepôt. La facturation, généralement indexée sur le nombre d’utilisateurs, suit mécaniquement la croissance de vos effectifs recruteurs, ce qui rend le coût moins prévisible à cinq ans qu’il ne paraît la première année. La personnalisation reste bornée par ce que le produit prévoit, et l’intégration à un SI RH ancien peut se heurter à l’absence d’interfaces adaptées. Enfin, la réversibilité s’examine dans le contrat, pas pendant la démonstration : format d’export, délai de restitution, durée de conservation après résiliation.
Ce choix s’inscrit rarement isolément. Les données de l’INSEE citées plus haut montrent que 73 % des entreprises utilisatrices d’intelligence artificielle recourent à des services payants de cloud computing, contre 33 % chez celles qui n’en utilisent pas. Le modèle de déploiement d’un ATS reflète généralement une trajectoire d’architecture déjà engagée ailleurs.
L’on-premise : ce qu’il apporte, ce qu’il contraint
L’hébergement interne garde des arguments solides, et il serait paresseux de le traiter comme une survivance. Il offre une maîtrise complète de la localisation des données, une intégration en profondeur avec un système d’information existant, une personnalisation sans limite fonctionnelle autre que le budget, et un coût récurrent plus prévisible une fois l’investissement initial amorti. Pour une entreprise dont la paie, la GTA et l’ERP sont déjà hébergés en interne, ajouter une brique de plus au même environnement a une cohérence évidente.
Les contraintes sont tout aussi concrètes. La maintenance et l’application des correctifs reposent sur une équipe qui a déjà un plan de charge, l’obsolescence matérielle revient tous les cinq à sept ans, les mises à jour fonctionnelles dépendent de vos propres arbitrages plutôt que du rythme de l’éditeur, et l’accès distant sécurisé pour des utilisateurs mobiles est un chantier à part entière.
Un chiffre mérite d’être médité par les DSI concernées : parmi les entreprises qui n’adoptent pas de technologies d’intelligence artificielle, 38 % invoquent l’incompatibilité avec leurs équipements et systèmes existants, et cette proportion approche la moitié dans les entreprises de 250 salariés ou plus. Le poids de l’existant est un argument en faveur de l’internalisation autant qu’un piège à moyen terme.
Six questions pour trancher
Ces six questions suffisent à orienter la décision dans la grande majorité des cas.
Combien de sites, et quelle est la qualité de connexion du moins bien desservi ? Quelle part de vos recruteurs opérationnels travaille sans poste fixe ? Votre SI RH actuel est-il déjà majoritairement hébergé en interne ? Combien d’équivalents temps plein votre DSI peut-elle réellement consacrer à l’exploitation d’une application métier supplémentaire ? Vos volumes de recrutement sont-ils réguliers ou marqués par des pics saisonniers ? Sur quel horizon amortissez-vous habituellement vos investissements logiciels ?
Une majorité de réponses orientées vers la mobilité, l’irrégularité des volumes et la faiblesse des ressources d’exploitation désigne le SaaS. Une majorité orientée vers l’intégration profonde, la stabilité des volumes et une DSI structurée désigne l’hébergement interne. Ces questions ne dispensent évidemment pas de l’examen détaillé des critères techniques et contractuels : Inasoft a publié un comparatif SaaS vs on-premise pour un ATS qui reprend point par point les éléments à vérifier, notamment sur la réversibilité et l’intégration au système d’information existant.
Trois erreurs qui reviennent
La première consiste à arbitrer sans avoir fait tester les deux options par un recruteur de terrain, dans ses conditions réelles d’utilisation. Une session de trente minutes sur un site de production en dit plus long que trois réunions de cadrage.
La deuxième est de sous-estimer la reprise de l’historique. Les candidatures accumulées depuis des années dans des boîtes mail, des tableurs et parfois un ancien outil constituent un vivier qui a de la valeur, et leur migration est presque toujours plus lourde que ce que l’estimation initiale prévoit.
La troisième est de confondre souveraineté de l’hébergement et conformité réglementaire. Héberger en interne ne dispense d’aucune obligation, ni de la tenue du registre des traitements, ni de la définition des durées de conservation, ni de l’information des candidats.
Choisir d’après sa propre topographie
Le modèle de déploiement d’un ATS ne se décide pas d’après la tendance du marché mais d’après la géographie de votre organisation, la composition réelle de vos équipes de recrutement et la capacité d’exploitation dont vous disposez. Un outil parfaitement adapté à une structure centralisée peut devenir un frein dès qu’il faut couvrir dix sites, et l’inverse est tout aussi vrai.
Chez Amalo, nous travaillons quotidiennement dans les outils de recrutement de nos clients industriels et logistiques, du côté utilisateur. C’est de là que vient ce point de vue, et c’est aussi de là que vient notre conviction principale : un ATS ne compense jamais un processus mal défini. Découvrez notre approche du recrutement en environnement industriel.
