Logiciel de recrutement : construire un cahier des charges utile

Vous assistez à trois démonstrations de logiciels de recrutement. Chacune semble convaincante, mais les écrans, les exemples et les promesses diffèrent. Au moment de choisir, votre équipe compare surtout ses impressions. Un cahier des charges de logiciel de recrutement sert à éviter cette situation : il transforme vos besoins en exigences que vous pourrez vérifier sur le même parcours.

Ce document peut rester court. Son intérêt ne dépend pas du nombre de fonctionnalités demandées, mais de la clarté des problèmes à résoudre, des priorités et des preuves attendues. Un recruteur indépendant peut commencer avec quelques scénarios ; un cabinet, une ESN ou une grande équipe RH ajoutera les contraintes de collaboration et d’intégration qui lui sont propres.

Voici une méthode avec un modèle de grille, un exemple pondéré et un protocole de démonstration. Les entreprises, notes et montants évoqués dans les exemples sont fictifs : ils expliquent une démarche, sans classer les éditeurs ni promettre un gain de productivité.

1. Décrire le travail avant de demander des fonctionnalités

Commencez par trois situations récentes qui ont ralenti un recrutement. Peut-être avez-vous retrouvé plusieurs versions d’un CV, contacté une personne déjà approchée par un collègue ou attendu un retour client sans savoir qui devait relancer. Décrivez le point de départ, l’action réalisée et l’information manquante.

Écrire « nous voulons un CRM intuitif » ne permet pas de tester une solution. Écrire « un collègue doit reprendre une candidature et retrouver le dernier échange, la mission et la prochaine action » donne un objectif observable. Vous pourrez demander au fournisseur de réaliser précisément ce parcours.

Associez les personnes qui utilisent réellement les informations : recruteurs, managers et, selon votre organisation, commerciaux, responsables informatiques ou administrateurs. Une contrainte importante peut se trouver à la frontière de deux équipes. Pour une petite structure, cet échange peut tenir en une réunion courte ; il faut surtout en conserver les décisions.

Avant de formaliser votre périmètre, notre comparatif ATS ou CRM de recrutement aide à distinguer le suivi d’une candidature de la relation avec un profil. Cette distinction évite de choisir uniquement sur un nom de catégorie logicielle.

2. Délimiter le périmètre et les utilisateurs

Décrivez les recrutements concernés : permanents, missions, volumes habituels et périodes de pointe, métiers, sites et acteurs. Un chiffre isolé de CV stockés ne décrit pas la difficulté réelle. Précisez aussi combien de personnes interviennent simultanément et quelles informations elles doivent partager.

Séparez ce qui doit être opérationnel au lancement de ce qui peut venir ensuite. Une intégration hypothétique ne doit pas peser autant qu’un problème quotidien avéré. À l’inverse, un besoin d’export indispensable à votre activité doit être écrit avant la signature, même s’il sera peu utilisé.

Voici un modèle de fiche de cadrage, à copier et à remplir avec vos propres réponses. Il prépare la discussion sans préjuger de la solution technique.

Une fois cette fiche remplie, donnez un responsable à chaque question encore ouverte. « À confirmer » est une information utile lorsqu’une personne et une échéance y sont associées. Sans cela, le point risque de réapparaître tardivement comme une urgence.

3. Transformer chaque besoin en exigence vérifiable

Utilisez une phrase simple : qui doit pouvoir faire quoi, dans quelle situation, et avec quel résultat visible ? Par exemple : « Le recruteur affecté à une mission doit pouvoir retrouver les profils correspondant aux critères validés et consulter les informations qui justifient leur pertinence. »

Ajoutez ensuite un test. Préparez quelques profils fictifs, des expériences différentes, une disponibilité inconnue et un doublon volontaire. Demandez comment la recherche distingue les faits renseignés, les éléments manquants et les rapprochements proposés. Un écran de résultats ne suffit pas si personne ne comprend pourquoi un profil apparaît.

Attribuez à chaque exigence un niveau : indispensable, importante ou optionnelle. Réservez le premier niveau aux conditions réellement bloquantes. Si tout est indispensable, la liste n’aide plus à arbitrer. Pour chaque désaccord, revenez au scénario métier et à la conséquence d’une absence de couverture.

Ne confondez pas « disponible », « configurable », « intégrable » et « prévu ». Ces réponses impliquent des efforts, des délais et des coûts différents. Demandez ce qui existe dans la version proposée et ce qui dépend d’une intervention supplémentaire. Une évolution annoncée doit rester identifiée comme telle dans votre comparaison.

4. Prévoir les données, les accès et la sortie du logiciel

La qualité d’une migration dépend autant des données de départ que de l’outil d’arrivée. Faites l’inventaire des champs, des pièces jointes et des liens entre profils et missions. Définissez ce qui doit être conservé, corrigé ou exclu. Un import réussi techniquement peut rester inutilisable si les statuts perdent leur sens.

La CNIL rappelle notamment l’importance de limiter la collecte aux données utiles, d’informer les candidats et de prévoir une sécurité adaptée. Traduisez ces points en questions concrètes sur les accès, la conservation, la gestion des demandes et les responsabilités. Associez votre DPO si vous en avez un ; une grille commerciale ne remplace pas cette analyse.

Testez également la sortie. Quels éléments sont exportables ? Dans quel format ? Les relations entre une personne et ses candidatures sont-elles compréhensibles après export ? Quels fichiers et historiques sont inclus ? Demandez une description écrite du périmètre, des éventuels frais et des délais applicables.

Pour les intégrations, partez d’un échange précis : envoyer une information, recevoir un événement ou synchroniser une modification. Notez la direction de l’échange et la manière de traiter les erreurs. Le mot « connecté » ne dit pas, à lui seul, ce qui circule effectivement entre deux outils.

5. Comparer avec une grille pondérée sans fabriquer une fausse précision

Les conditions bloquantes se vérifient d’abord. Une bonne moyenne ne compense pas l’absence d’une exigence indispensable. Pour les solutions qui passent ce premier filtre, une pondération peut rendre votre arbitrage plus explicite. Fixez les poids avant les démonstrations, puis conservez la même méthode pour tous.

Dans le cas fictif ci-dessous, une équipe choisit une note de 0 à 3 : 0 signifie non démontré, 1 signifie partiellement couvert, 2 signifie couvert avec adaptation, 3 signifie réalisé dans le scénario testé. Les poids totalisent 100. Ce barème est une proposition à adapter, pas une norme du recrutement.

Le calcul est : poids multiplié par la note, puis divisé par 3. Le total arrondi de cet exemple est 71,7 sur 100. Cette valeur n’a de sens qu’avec les observations associées. « Adaptation nécessaire » doit préciser qui intervient, à quel coût et avec quelle dépendance.

Conservez une colonne de commentaires dans votre propre fichier. Une preuve manquante mérite parfois un second test, plutôt qu’une note définitive. Si vous changez une priorité après avoir compris une contrainte, documentez la raison et réévaluez toutes les solutions avec la même grille.

6. Organiser une démonstration fondée sur vos scénarios

Transmettez un scénario commun : créer une mission, retrouver un profil, actualiser une information, ouvrir une candidature, attribuer la prochaine action et récupérer les données du test. Utilisez des données fictives pour ne pas diffuser de vrais dossiers candidats pendant une simple comparaison.

Demandez ensuite à une personne de votre équipe d’exécuter les étapes essentielles. Une démonstration menée par un spécialiste montre ce que l’outil peut faire ; une prise en main encadrée révèle les explications dont vos utilisateurs auront besoin. Notez les difficultés sans transformer un premier essai en jugement définitif.

À la fin, séparez les points démontrés, les points restant à vérifier et les engagements écrits. Fixez une prochaine étape pour chaque incertitude importante. N’attribuez pas à un logiciel une capacité qui n’a été observée que dans une présentation d’une autre solution.

Trois fonctionnalités Oxaibo à transformer en tests

Pour appliquer cette méthode à Oxaibo, commencez par l’analyse d’un CV et sa présentation en CV digital. Importez un CV fictif, relisez les informations extraites et la courte synthèse du profil, puis préparez une présentation de shortlist. Vérifiez le résultat obtenu quand vous choisissez d’afficher ou de masquer le résumé dans le CV digital. Le critère de réussite porte sur la fidélité et la lisibilité du dossier, pas simplement sur la présence du mot « IA ».

Deuxième test : ajoutez le même profil à deux viviers du Talent Center. Ouvrez sa fiche depuis chaque sélection et vérifiez que vous travaillez sur la même référence. Troisième test : associez ce profil à une mission, attribuez un responsable et faites évoluer le suivi de candidature. Ces gestes permettent d’examiner concrètement l’articulation entre profils, viviers, présentation et suivi.

Ce parcours couvre des fonctionnalités précises d’Oxaibo ; il ne valide pas à lui seul toutes vos exigences. Conservez des tests distincts pour les accès, les exports, les intégrations et le périmètre de l’offre. Vous pouvez préparer cette démonstration avec Oxaibo en transmettant vos critères de réussite et des données fictives.

7. Préparer le coût complet et la mise en service

Comparez un même périmètre : utilisateurs, modules, volumes, assistance et durée envisagée. Ajoutez les coûts de reprise de données, de paramétrage, de formation et les éventuelles intégrations. Demandez les limites et les conditions d’évolution de l’offre ; un prix affiché ne décrit pas toujours le coût de votre usage.

Le temps interne compte aussi. Qui nettoie les fichiers ? Qui valide les correspondances de champs ? Qui répond aux utilisateurs pendant les premières semaines ? Prévoyez un pilote limité, des critères de réussite et une décision de généralisation. Le déploiement ne s’achève pas au moment où les comptes sont créés.

Une petite équipe peut tester une mission avant d’élargir. Une organisation plus importante peut choisir un périmètre représentatif et associer plusieurs rôles. Dans les deux cas, documentez les écarts entre le fonctionnement attendu et le fonctionnement constaté avant d’ouvrir davantage d’accès.

Passer du document à une décision explicable

Votre cahier des charges final peut réunir une fiche de contexte, quelques scénarios, les exigences classées, la grille de comparaison et les conditions de déploiement. Il doit permettre d’expliquer pourquoi une solution convient à votre manière de recruter, et quelles limites vous acceptez.

Pour préparer un essai d’Oxaibo, partez d’un parcours concret autour des profils, des viviers, des missions et du suivi des candidatures. Vous pouvez nous contacter avec vos scénarios. Votre document donnera un cadre précis à la démonstration et aux questions à vérifier.

Questions fréquentes

Combien de pages faut-il prévoir ?

Il n’existe pas de longueur obligatoire. Gardez le document assez court pour être lu et assez précis pour permettre des tests. Ajoutez des annexes pour les données ou intégrations complexes plutôt que de mélanger tous les détails aux priorités métier.

Faut-il demander exactement le même outil que celui utilisé auparavant ?

Reprenez les besoins utiles, mais réexaminez les habitudes. Un ancien écran peut compenser une limite qui n’existe plus ailleurs. Décrire le résultat attendu permet de comparer plusieurs façons de réaliser le travail.

Peut-on choisir uniquement avec une note globale ?

Non. Examinez les conditions bloquantes, les preuves, le coût complet et les dépendances. La note facilite la discussion ; elle ne remplace ni la validation des engagements ni le jugement de l’équipe.

Modèles et cas conçus pour ce guide. Photographies générées par IA ; schéma original. Aucun résultat client réel n’est présenté.