Une liste de logiciels sur un CV ne dit pas si la personne sait produire un résultat fiable. Évaluez un travail réel dans un contexte outillé, avec un exercice court et une grille commune entre manager et RH.
« Maîtrise d’Excel, de Salesforce ou de HubSpot exigée. » Cette ligne, présente dans beaucoup d’offres, filtre sur des noms de logiciels et ne dit presque rien du travail réel attendu. Pour recruter juste, évaluez un résultat dans un contexte outillé, pas une liste d’outils déclarés. Voici comment construire cette évaluation, du choix des tâches qui comptent jusqu’à la réutilisation du cadre en interne.
On demande souvent une « maîtrise » d’outils sans préciser ce que la personne devra vraiment en faire. On filtre sur des noms de logiciels, puis on découvre en entretien, ou après l’embauche, que le candidat connaît l’interface mais pas le travail attendu.
La bonne approche part des situations de travail qui comptent, les traduit en comportements observables, puis les teste avec un exercice court. Ce n’est pas qu’une intuition : les mises en situation figurent parmi les méthodes de sélection les plus prédictives de la performance, d’après la recherche en psychologie du travail (méta-analyse Schmidt et Hunter, 1998).
Commencez par isoler les 3 à 5 tâches où l’outil change réellement la performance. Pas toute la stack. Seulement les moments où un mauvais usage a un coût concret : reporting faux, pipeline commercial illisible (le suivi des opportunités de vente), données client inexploitables, suivi candidat incomplet, relances oubliées, historique introuvable.
Exemples fréquents selon les postes :
Pour chaque tâche, séparez trois choses. L’usage de l’outil d’abord : naviguer, trouver la bonne vue, modifier un enregistrement, filtrer, importer. Le raisonnement métier ensuite : quelle action est prioritaire, quel statut utiliser, quelle information est utile à l’équipe. La rigueur d’exécution enfin : nommer correctement, éviter les champs vides, respecter la structure, laisser une trace exploitable.
Cette séparation change l’évaluation. Un candidat peut avoir déjà utilisé HubSpot mais mal renseigner les champs et dégrader votre qualité de données. À l’inverse, quelqu’un qui n’a jamais touché votre ATS peut comprendre la logique d’un pipeline et documenter proprement ses actions après une courte prise en main.
L’erreur la plus fréquente en pratique : écarter un bon profil parce qu’il ne connaît pas votre outil exact. La familiarité d’interface s’acquiert en quelques jours. La discipline de données, beaucoup plus lentement.
La bonne question n’est donc pas « connaît-il tel logiciel ? ». Reformulez-la : peut-il produire un résultat observable dans un environnement outillé ? Au lieu d’écrire « maîtrise d’Excel requise », visez « sait nettoyer un export simple, repérer des incohérences évidentes et produire un mini-compte rendu fiable ».
[BANNER type="lead_banner_1" title="Compétences logicielles en recrutement : kit de test 30 minutes" description="Saisissez votre adresse e-mail pour recevoir un guide complet, étape par étape" picture-src="/upload/medialibrary/c0f/04zrwoo0jpzvirn15czqu595pynw0yl9.webp" file-path="/upload/medialibrary/b13/cctpdoq5lh78pbcgpwrnwlkd3j2vnmne.pdf"]Une compétence logicielle n’est pas un bloc unique. Sans découpage, l’évaluation dérive vers l’impression générale : « à l’aise », « pas très digital », « débrouillard ». Ces jugements sont pratiques en débrief, mais faibles pour décider.
Un découpage simple sépare au minimum quatre dimensions : la navigation dans l’interface, l’exécution, la discipline des données et l’autonomie.
La frontière entre familiarité d’interface et discipline de données est souvent mal gérée. La première s’enseigne vite : une personne habituée aux outils structurés retrouve rapidement la logique des menus, des champs, des vues et des filtres.
La seconde relève des habitudes de travail : nommer un champ correctement, ne pas écraser une information existante, comprendre pourquoi un doublon pose problème, saisir une date dans le bon format, laisser un historique exploitable. On ne l’installe pas en une démo de trente minutes.
Pour rendre ces dimensions évaluables, formulez-les en comportements visibles :
Ce niveau de précision aide aussi les RH. Quand un manager dit « je veux quelqu’un de très à l’aise sur les outils », on recadre vers ces critères observables plutôt que vers un concours de vocabulaire logiciel.
Une fois les critères posés, fixez le niveau attendu. Sinon, vous retombez sur des formules creuses : « bonne maîtrise », « aisance », « expérience confirmée ». Tout le monde croit comprendre. Personne ne met la même chose derrière.
Un modèle à trois niveaux suffit pour la plupart des postes. Graduer une compétence n’a rien de nouveau : des référentiels publics comme le cadre européen des compétences numériques structurent déjà la progression en plusieurs niveaux. Pour un poste précis, trois niveaux suffisent.
Voici les trois niveaux et ce qu’ils permettent de confier. Les seuils chiffrés sont des repères illustratifs, à ajuster à votre contexte :
|
Niveau |
Ce que la personne fait |
Ce qu’on peut lui confier (exemple) |
|
Débutant opérationnel |
Réalise les tâches de base avec consignes, check-list ou relecture |
Une tâche cadrée, à faible risque, dans un périmètre défini |
|
Autonome |
Exécute seul les tâches courantes et contrôle son travail |
Des mises à jour sans vérification systématique : tenir un pipeline de 30 opportunités sans perte d’information, ou nettoyer un export de 200 lignes en moins de 20 minutes sans doublon restant |
|
Référent |
Fiabilise les usages, corrige les écarts, structure les process |
Diagnostiquer une dérive, reprendre les règles de saisie, faire monter l’équipe en compétence |
Le niveau attendu dépend du poste. Pour un rôle junior, vous pouvez accepter une familiarité limitée avec l’outil si la discipline de données est solide : la personne apprendra l’interface plus vite que la rigueur.
Pour un poste senior, le seuil change. On attend souvent la capacité à diagnostiquer des usages bancals, à corriger des pratiques d’équipe ou à fiabiliser un reporting devenu instable parce que plusieurs personnes alimentent mal la même base. Là, « j’ai déjà utilisé tel logiciel » ne suffit plus.
Dans une fiche de poste ou une grille d’évaluation (scorecard), remplacez les listes d’outils par des formulations actionnables :
En précisant ce qui se fait seul, avec aide ou pour améliorer l’équipe, vous obtenez une base plus robuste qu’une colonne « Salesforce / Excel / HubSpot » cochée au feeling.
[BANNER type="lead_banner_2" blockquote="\"Le CRM Bitrix24 est un outil qui possède de nombreuses possibilités d’automatisation.\"" user-picture-src='/upload/optimizer/converted/upload/iblock/684/gin5o3pfp0a0n0zcmf0t70cjehj86ttu.png.webp?1745926552452' user-name="Formateur, Lionel Graf" user-description="LGXR Consulting"]Le test doit ressembler au travail, pas à un examen scolaire ni à une démonstration produit. Un format de 15 à 30 minutes suffit souvent, à condition de viser juste.
Choisissez un livrable simple, proche d’un vrai irritant d’équipe :
Ne testez pas tout à la fois. Deux capacités critiques suffisent : qualité des données et logique de priorisation, ou exécution de base et autonomie face à une anomalie simple. Dès que l’exercice s’élargit, vous ne savez plus ce que vous mesurez.
Un bon exercice précise quatre éléments :
Exemple d’exercice court (scénario illustratif) :
Contexte : vous rejoignez l’équipe revenue operations (les opérations qui soutiennent le chiffre d’affaires). Un export CRM de prospects doit être vérifié avant une relance commerciale.
Éléments fournis : un fichier de 20 lignes avec, pour chaque prospect, les champs email, société, statut, dernière activité, propriétaire et date de dernière mise à jour. Il contient quelques doublons, des formats de dates hétérogènes, deux champs critiques vides, un statut incohérent avec la dernière activité, et une règle de nommage simple.
Consigne : en 20 minutes, corrigez ce qui rend le fichier exploitable, signalez ce que vous ne pouvez pas trancher seul, puis proposez les 3 actions prioritaires.
Résultat attendu : un fichier nettoyé et une note courte expliquant les choix.
Vous pouvez fournir un modèle de fichier test prérempli avec ces champs, pour que chaque candidat parte du même point. Un tableur ou un support fictif suffit souvent : pas besoin de recréer votre environnement réel à l’identique.
Peu importe l’outil exact de l’exercice. Dans un vrai poste, ces données vivent souvent dans un CRM : Bitrix24, par exemple, organise prospects et affaires dans des pipelines commerciaux configurables. L’enjeu à l’embauche est de vérifier que le candidat y maintient des données exploitables, pas qu’il connaît chaque menu.
Relisez aussi vos consignes avec quelqu’un d’extérieur au poste. Si la moitié des questions porte sur le brief lui-même, le problème vient du test, pas du candidat.
Avec Bitrix24, structurez tests, grilles et suivis candidats dans un espace collaboratif, du CRM aux connaissances internes.
Essayer gratuitementSans grille, le test perd vite de sa valeur. Chacun retient ce qui l’a marqué : rapidité, présentation, stress apparent, erreur visible ou bonne impression générale. C’est là que les écarts de jugement entre manager et RH deviennent pénibles.
Une grille simple de 4 à 5 critères notés suffit. Vous pouvez l’utiliser telle quelle, puis pondérer selon le poste.
Voici un exemple de grille pondérée pour un poste d’opérations. Les poids sont illustratifs, à adapter à vos priorités :
|
Critère |
Ce qu’il mesure |
Pondération (exemple, profil Ops) |
|
Hygiène des données |
Doublons, champs vides, formats, respect des règles de saisie |
40 % |
|
Exactitude |
Corrections justes, aucune erreur introduite |
25 % |
|
Autonomie |
Gère les cas simples seul, signale ce qu’il ne peut trancher |
20 % |
|
Priorisation |
Choisit les bonnes actions dans le temps imparti |
10 % |
|
Clarté |
Note de synthèse lisible, choix expliqués |
5 % |
Pour un rôle d’opérations, l’hygiène de données pèse davantage que la vitesse. Pour un poste exposé à des outils qui changent souvent, l’autonomie et la rapidité d’appropriation peuvent peser plus lourd. Ajustez les poids, gardez la même grille pour tous les candidats d’un même poste.
L’important n’est pas de construire une matrice parfaite, mais d’éviter les notes implicites. Si deux évaluateurs n’ont pas la même définition d’une réponse « forte », leurs comparaisons ne valent pas grand-chose.
Faites noter le test individuellement avant le débrief commun. Sinon, la première personne qui parle, souvent le manager, influence tout le monde, surtout quand le candidat a été bon à l’oral mais moyen dans l’exercice.
Le test donne des signaux. Encore faut-il les lire correctement. Une mauvaise performance n’a pas toujours la même signification.
Premier tri : ce qui relève de la prise en main d’une interface, et ce qui révèle un problème de méthode. Un candidat peut être lent dans un environnement inconnu, chercher ses repères, hésiter sur l’emplacement d’une fonction. Ce n’est pas forcément grave.
D’autres erreurs sont structurelles : saisies répétées dans un mauvais format, absence de vérification avant import, doublons non détectés, commentaires inutilisables, incapacité à suivre une règle simple malgré une consigne écrite. Là, on ne parle plus d’interface, mais d’habitudes de travail.
Pour décider, classez les écarts en trois catégories :
Les critères rédhibitoires dépendent de la famille de poste. Pour une fonction d’opérations, des doublons récurrents et l’absence de tout contrôle qualité sont souvent éliminatoires. Pour un rôle d’assistanat commercial, ce sera plutôt l’incapacité à suivre une règle de saisie simple. Nommez ces critères avant de tester, pas après.
Les questions de relance portent sur les habitudes concrètes, pas sur l’auto-évaluation :
Cette lecture évite deux erreurs : écarter quelqu’un parce qu’il ne connaît pas votre outil exact alors que sa logique est transférable, ou retenir un candidat brillant en démo mais peu fiable dès qu’il faut structurer des données sans supervision.
Un test court a ses limites. Pour les postes où l’expertise d’un logiciel précis est le cœur du métier (data analyst, développeur, administrateur d’un ERP), 20 minutes ne suffisent pas : prévoyez une évaluation technique plus approfondie. Le format court vaut surtout pour les rôles où l’outil est un moyen, pas la finalité.
Le cadre ne sert pas qu’une fois, au recrutement. Les critères et les niveaux deviennent un référentiel simple pour le développement interne.
Reprenez les mêmes dimensions, navigation, exécution, discipline des données, autonomie, pour diagnostiquer les écarts dans l’équipe. Cela aide à distinguer trois sujets souvent mélangés :
Les réponses diffèrent. Si le problème vient d’un nouvel outil mal pris en main, une session ciblée, une base documentaire ou du shadowing suffisent. Si le problème vient d’une discipline de saisie instable, il faut reprendre les règles, les exemples, les points de contrôle, parfois le process qui pousse les équipes à bâcler.
Formaliser ce référentiel dans un outil partagé évite qu’il vive dans la tête d’une seule personne. Bitrix24 propose par exemple une base de connaissances interne où stocker règles de saisie, exemples et points de contrôle, avec des droits d’accès par équipe.
La même grille sert aussi en entretien de développement. Pas besoin d’un dispositif lourd : positionnez la personne sur quelques tâches réelles. Met-elle à jour correctement les informations partagées ? Repère-t-elle les incohérences ? Sait-elle documenter pour l’équipe ? Corrige-t-elle un cas simple seule ?
Ce cadre clarifie aussi ce qu’on attend selon la séniorité. Dans certaines équipes, le titre « senior » repose surtout sur l’ancienneté, alors que les usages outillés restent fragiles. Formaliser les niveaux remet de la cohérence, notamment pour préparer une mobilité vers des rôles d’ops, de coordination ou de management de process.
Donnez enfin un propriétaire et un rythme au référentiel. Confiez-le à un responsable clair, par exemple un manager Ops ou un HRBP (HR business partner, RH de proximité), et revoyez-le tous les trimestres ou tous les semestres. Quand la stack change, qu’un process est revu ou qu’un irritant récurrent apparaît, l’exercice et les niveaux doivent suivre.
Pas obligatoirement. Ce qui compte, c’est la logique de travail : qualité des données, priorisation, autonomie. Un tableur ou un CRM fictif suffit souvent, sauf pour les postes où l’expertise d’un logiciel précis est le cœur du métier.
15 à 30 minutes dans la plupart des cas. Au-delà, vous testez surtout l’endurance et la disponibilité du candidat. Ciblez deux capacités critiques plutôt que de couvrir toute la stack.
Utilisez une grille de 4 à 5 critères pondérés, définissez ce qu’est une réponse « forte », et faites noter chacun individuellement avant le débrief. Cela évite que la première voix, souvent le manager, aligne tout le monde.
Souvent, oui. La familiarité d’interface s’acquiert en quelques jours, la rigueur de données beaucoup plus lentement. Écarter un profil rigoureux parce qu’il ne connaît pas votre outil exact est une erreur fréquente.
Oui. Les mêmes critères et niveaux servent à diagnostiquer les écarts internes et à construire des plans de montée en compétence. Prévoyez un propriétaire du référentiel et une revue régulière pour qu’il reste à jour.