Aller au contenu
SkillCort

7 min · 7 stepsTutoriel de diffusion

Comment prévisualiser et contrôler votre évaluation avant sa mise en ligne

Le bug d'évaluation le plus coûteux est celui qu'un candidat découvre. Un corrigé erroné, une page qui déborde ou un support illisible sur téléphone vous coûtent tous un signal que vous ne pourrez pas récupérer. Ce tutoriel propose une routine de contrôle qualité reproductible qui attrape ces problèmes avant l'envoi de la première invitation.

What you'll need

  • Un projet d'évaluation assemblé dans le builder (sections, pages, blocs)
  • Des grilles ou des corrigés attachés à chaque tâche notée
  • Un téléphone ou une fenêtre de navigateur étroite pour la passe mobile
  • 1–2 collègues disponibles pour un court pilote

Step 1: Ouvrez l'aperçu candidat depuis l'en-tête du builder

Commencez chaque passe de contrôle qualité par "Preview as candidate" dans l'en-tête du builder. L'aperçu affiche l'évaluation exactement telle qu'un candidat la verra — mêmes pages, mêmes blocs, mêmes consignes, mêmes minuteurs — de sorte que tout ce que vous attrapez ici est un vrai problème corrigé avant qu'il ne vous coûte une réponse.

Résistez à l'envie de survoler votre propre contenu. C'est vous qui avez écrit ces tâches, donc votre cerveau comblera des lacunes qu'un candidat ne peut pas combler. Lisez chaque consigne comme si vous ne connaissiez pas le poste, et répondez honnêtement à chaque question au lieu de cliquer pour avancer. Le but est de vivre l'évaluation, pas d'en faire le tour.

Step 2: Parcourez chaque page sur ordinateur, en répondant pour de vrai

Allez page par page et accomplissez réellement chaque tâche : tapez les réponses en texte, remplissez les saisies en tableau, téléversez un fichier, enregistrez l'audio ou la vidéo si l'évaluation le demande. Les types d'items interactifs échouent de façons qu'un survol visuel ne révèle jamais — un dépôt qui refuse le format de fichier évident, une tâche de code au point de départ déroutant, un bloc d'enregistrement qu'un candidat pourrait manquer.

Faites particulièrement attention aux mises en page à support juxtaposé. Vérifiez que le support et la question sont visibles ensemble, que les longs documents défilent indépendamment, et que rien n'oblige le candidat à mémoriser le support avant de répondre. Un problème de mise en page ici change discrètement ce que la tâche mesure — de la compétence que vous visiez vers la mémoire de travail et la patience.

  • Chaque consigne est sans ambiguïté pour quelqu'un d'extérieur à votre équipe
  • Les dépôts, les enregistrements et les blocs de code acceptent une réponse réaliste
  • Le support et la question sont lisibles ensemble sur un même écran
  • Les champs obligatoires et la navigation se comportent comme prévu sur chaque page

Step 3: Refaites le parcours sur un téléphone

Relancez le même aperçu sur un téléphone ou dans une fenêtre de navigateur étroite. Les candidats ne sont pas toujours assis à un bureau, et des mises en page qui paraissent correctes sur un large écran peuvent enterrer un support, tronquer un tableau ou pousser le bouton d'envoi sous un défilement interminable sur petit écran.

Si une tâche exige réellement un ordinateur — un environnement de code, une longue revue de document juxtaposé — dites-le explicitement dans les consignes de l'évaluation plutôt que de laisser les candidats le découvrir en cours de tentative. Une phrase qui pose les attentes d'entrée coûte bien moins cher qu'une réponse frustrée et à moitié terminée.

Step 4: Chronométrez un passage à blanc réaliste par rapport à vos limites

Terminez l'évaluation à un rythme de travail réaliste et comparez votre temps écoulé aux limites totale et par page fixées dans le builder. Ajoutez ensuite de la marge : vous connaissez déjà le contenu, et un candidat qui découvre tout sera nettement plus lent que vous ne l'avez été.

Vérifiez les limites par page individuellement, pas seulement le total. Une seule page sous-estimée — en général celle qui porte la mise en situation la plus riche — peut ruiner une évaluation par ailleurs bien minutée, car la pression du temps sur une tâche unique pénalise surtout les candidats appliqués. Si une page vous a paru précipitée même à vous, allongez-la avant que quiconque d'autre ne la voie.

Step 5: Vérifiez chaque grille et chaque corrigé par rapport à sa tâche

Ouvrez chaque tâche notée et confirmez que sa configuration de notation correspond à la tâche telle qu'elle est réellement rédigée — pas telle que vous l'aviez rédigée trois modifications plus tôt. Pour les items notés automatiquement, vérifiez que le corrigé marque les bonnes options et que les barèmes sont ceux que vous voulez. Rappelez-vous qu'une tâche sans corrigé reçoit une note automatique null, c'est-à-dire aucune note, et attend une notation manuelle ; elle n'est pas silencieusement notée zéro, mais elle restera non notée jusqu'à ce que quelqu'un s'en occupe.

Pour les tâches notées par grille, relisez chaque critère face à l'énoncé de la tâche et confirmez qu'une réponse forte à cet énoncé pourrait réellement démontrer chaque critère. Notez que les grilles se figent en instantané au moment de l'attachement : c'est donc maintenant qu'il faut corriger la formulation — les modifications ultérieures dans votre bibliothèque n'atteindront pas l'évaluation publiée.

Step 6: Videz la liste de vérification de publication

La liste de vérification de publication est le dernier garde-fou de la plateforme : elle bloque Publish tant que la configuration requise n'est pas complète, en signalant par exemple une configuration de notation manquante ou une section incomplète. Traitez chaque point qu'elle soulève au lieu de chercher le chemin le plus rapide vers un bouton vert.

Considérez la liste comme un plancher, pas comme un plafond. Elle vérifie l'exhaustivité structurelle ; elle ne peut pas juger si vos consignes sont claires ou si votre minutage est humain. C'est à cela que servaient les étapes précédentes. Quand la liste est vide et que vos passes manuelles sont faites, vous êtes prêt pour le pilote.

Step 7: Faites un pilote avec une ou deux personnes en interne

Avant qu'un candidat ne voie l'évaluation, faites-la passer de bout en bout à un ou deux collègues en conditions réelles — le vrai lien de diffusion, les vraies limites de temps et les paramètres de sécurité que vous comptez utiliser, pour que l'expérience de consentement et de vérification préalable soit testée elle aussi. Choisissez des personnes qui n'ont pas participé à sa construction ; un regard neuf trouve ce que le vôtre ne peut pas voir.

Débriefez immédiatement, tant que l'expérience est fraîche. Notez ensuite leurs réponses avec vos grilles, comme vérification finale que le langage de la grille fonctionne sur une production réelle et pas seulement en théorie. Corrigez ce que le pilote révèle, relancez l'aperçu sur tout ce que vous avez modifié, et seulement ensuite envoyez les invitations.

  • Où les consignes ont-elles paru ambiguës ou surprenantes ?
  • Quelle page a semblé la plus sous pression temporelle ?
  • La vérification préalable et les messages de sécurité ont-ils paru proportionnés aux enjeux ?
  • Les réponses du pilote ont-elles pu être notées proprement avec la grille ?

Pro tips

  • Contrôlez après chaque modification significative, pas une seule fois — une correction d'une ligne dans une tâche peut invalider un corrigé.
  • Tenez une liste de vérification partagée par évaluation, pour qu'une deuxième personne puisse vérifier la passe au lieu de croire qu'elle a eu lieu.
  • Prévisualisez avec les mêmes paramètres de sécurité que ceux de la diffusion, afin de vivre vous-même l'écran de consentement et de vérification préalable.
  • Calculez le minutage pour un lecteur qui découvre, pas pour l'auteur — vous serez toujours la personne la plus rapide à jamais passer cette évaluation.
  • Si le pilote fait apparaître un problème de formulation dans une grille, corrigez-le avant de publier ; les grilles attachées sont des instantanés figés.

Questions fréquentes

L'aperçu candidat compte-t-il quelque part ou crée-t-il des enregistrements ?
Non. "Preview as candidate" est un outil du builder destiné à vous, pas une diffusion. Il affiche l'évaluation exactement telle que les candidats la vivront, pour que vous puissiez tester librement sans affecter les résultats ni les invitations.
Que se passe-t-il si je publie une tâche sans corrigé ?
Sa note automatique est null, autrement dit absente, ce qui signifie qu'elle exige une notation manuelle — elle n'est pas notée zéro. C'est sans danger, mais si vous attendiez une notation automatique, les réponses non notées vont s'accumuler à l'évaluation. C'est la passe de contrôle sur les corrigés qui attrape cela avant le lancement.
Puis-je corriger une grille après la mise en ligne de l'évaluation ?
Les modifications de la grille dans votre banque ne changeront pas une évaluation en cours — la grille attachée est un instantané figé, ce qui protège la cohérence de notation pour les candidats déjà en vol. C'est exactement pourquoi la vérification des grilles appartient au contrôle qualité avant lancement.
De combien de testeurs pilotes ai-je réellement besoin ?
Un ou deux suffisent s'ils apportent un regard vraiment neuf et passent l'épreuve en conditions réelles. Vous ne mesurez pas leur compétence ; vous testez si les consignes, le minutage, la mécanique des items et le langage des grilles survivent au contact de quelqu'un qui n'a pas construit l'évaluation.
La liste de vérification de publication est verte — ai-je terminé ?
La liste confirme que la configuration requise est structurellement complète, et elle bloque Publish tant qu'elle ne l'est pas. Elle ne peut juger ni la clarté, ni le minutage, ni la qualité des grilles — cela demande les parcours manuels et le pilote décrits dans ce tutoriel.

For hiring teams

Livrez des évaluations que vous pouvez assumer

Découvrez comment l'aperçu candidat, la liste de vérification de publication et les contrôles de diffusion de SkillCort font du contrôle qualité avant lancement une routine plutôt qu'une course. Réservez une démo et parcourez-la en direct.