Critères d’évaluation — guide de configuration
Pour les administrateurs des critères entreprise et les responsables des campagnes qui les utilisent. Le parcours quotidien figure dans le guide fonctionnel ; les contrats d’implémentation dans le guide technique.
Prérequis et responsabilités
Utiliser une session administrateur entreprise autorisée. Identifier la génération de la campagne : SMR / nextgen ou SML / legacy. Une navigation legacy peut intégrer un écran SMR ; l’URL entreprise ne prouve pas que le calcul est legacy.
Observé dans l’application : les paramètres des critères affichent quatre critères actifs dans le compte inspecté. Vérifié dans le code : chaque critère possède sa clé et son historique de versions. Les paramètres entreprise définissent les critères réutilisables ; activation et choix des sources de campagne restent des étapes distinctes. Aucun identifiant de rôle ou état d’activation par défaut universel n’a été établi.
SMR — créer ou consulter une configuration
- Ouvrir Performance → Critères d’évaluation dans la navigation observée.
- Choisir le score. Contrôler l’activation, la version sélectionnée et le bandeau de verrouillage.
- Ouvrir Version pour consulter l’historique. Utiliser Create a new version pour faire évoluer une configuration utilisée ou ancienne. Sélectionner une ancienne version la consulte sans l’appliquer aux nouvelles campagnes.
- Dans la langue principale, choisir la méthode, le format et les bornes proposées ; renseigner les libellés obligatoires et les poids éventuels.
- Ajouter ou relire les traductions. Les paramètres de structure sont restreints hors langue principale ; un changement de langue peut déclencher une validation ou une sauvegarde. Lire l’avertissement avant de poursuivre.
- Vérifier Simulated score et Calculation breakdown lorsqu’ils sont proposés, puis utiliser Save the score settings lorsque les paramètres sont complets.
- Contrôler la version enregistrée et configurer explicitement une future campagne. Ne pas supposer qu’une campagne en cours a adopté les nouveaux paramètres.
Le PRD Performance définit des historiques indépendants : chaque modification de configuration entreprise crée une nouvelle version. Les versions historiques sont en lecture seule et les entretiens terminés conservent leur configuration d’origine. Les captures illustrent le menu observé dans Chrome ; aucune version n’a été créée pendant cette session.

Menu Version dans Chrome. Deux versions de Performance et l’action « Create a new version » sont visibles ; la notice distingue consultation et application. Aucune version n’a été créée.
SMR — formats, libellés et portée
| Paramètre | Fonctionnement / preuve | Effet |
|---|---|---|
| Activation | Interrupteurs indépendants observés ; quatre clés vérifiées dans le code. | Rend le critère disponible aux parcours consommateurs ; ne prouve pas son utilisation dans toute campagne. |
| Points | Bornes et libellé par valeur. Le PRD prévoit des bornes dans 1–10. | Affiche une note ordinale sur la plage choisie. |
| Pourcentage | 0–100 %, libellés aux extrémités ; PRD et interface. | Les descriptions des extrémités ne créent pas de tranches intermédiaires. |
| Lettres | Plage de lettres et libellés ; A est la meilleure note dans le PRD. | Ne pas trier les résultats par ordre alphabétique. |
| Langues | Structure définie dans la langue principale ; titres/libellés localisés dans le code. | Compléter les libellés après modification de plage. |
| Aperçu | Panneau de simulation observé. | Illustre l’affichage, sans recalculer les résultats salariés. |
Le client inspecté utilisait Performance 1–5, Potentiel pondéré 1–5, Risque 1–5 et Impact 1–3. Ce sont des exemples observés, pas des valeurs héritées par défaut. Les valeurs initiales des composants peuvent différer des données client chargées ; lire la configuration enregistrée.
SMR — performance
Fonctionnement cible défini par le PRD : choisir une performance standard/manuelle ou avancée/calculée. Le mode standard nécessite son échelle d’affichage. Le mode avancé ajoute les paramètres suivants.
| Contrôle | Choix / contrainte | Rôle |
|---|---|---|
| Compétences incluses | Toutes ou liées au métier. | Restreint la composante compétences. |
| Types de compétences | Hard skills, soft skills ou tous les types. | Restreint les compétences sources. |
| Compétences — Employee vs reviewer Weight | Balance 0–100 %, complément automatique pour un total de 100 %. | Combine les évaluations des compétences. |
| Objectives configuration — Employee vs reviewer Weight | Balance indépendante 0–100 %, total de 100 %. | Combine les évaluations des objectifs ; ne reprend pas le poids des compétences. |
| Overall weight distribution — Skills vs Goals | Balance 0–100 %, total de 100 %. | Combine les deux composantes lorsqu’elles sont utilisées ensemble. |
Observé : compétences salarié/évaluateurs = 20 %/80 %, objectifs salarié/évaluateurs = 20 %/80 %, répartition compétences/objectifs = 80 %/20 %. Ces valeurs appartiennent au client inspecté. Règle PRD : deux évaluateurs partagent à égalité la part évaluateurs, sans réglage individuel ; si le second ne participe pas, cette part revient au principal.

Dans Chrome, « Objectives configuration » possède son propre poids salarié/évaluateurs, avant « Overall weight distribution ». Pondérer les participants aux objectifs et mélanger compétences/objectifs sont deux réglages distincts.
Dépendances de campagne
Le PRD Performance distingue configuration entreprise et activation de campagne. Activer la performance dans la campagne d’entretiens ; en mode avancé, choisir compétences, objectifs ou les deux. Inclure les Smart Questions correspondantes et imposer leur caractère obligatoire. Valider les sources avant lancement.
Spécification PRD : configurer la visibilité du résultat calculé, du détail et de la justification pour le salarié et le second évaluateur : Always, Never ou Only when overridden score is higher. Ces trois informations forment un groupe ; les commentaires suivent le partage ordinaire. La configuration de campagne et les PDF n’ont pas été testés en direct. Aucune politique de visibilité par défaut n’est affirmée.
Renseigner le libellé de question obligatoire de la performance. Il définit le nom du score repris dans l’entretien, le PDF final et l’historique du profil salarié.
SMR — potentiel
Choisir un score direct/personnalisé ou des questions pondérées (vérifié dans le code). En mode pondéré, définir les titres, descriptions facultatives, libellés de réponses et poids, dont le total doit être 100 %. Vérifier les échelles des sous-questions et l’affichage global. Le compteur observé limite la description à 200 caractères. Une modification de plage peut laisser des traductions vides ; les compléter avant sauvegarde.
Observé : quatre questions à 25 % chacune. Vérifié dans le code : le calculateur People Review normalise les questions renseignées éligibles et divise la somme pondérée par la somme de leurs poids. Il ignore les réponses absentes, questions sans options et poids non positifs ; un calcul entièrement vide retourne zéro. Validation des paramètres et traitement des réponses sont distincts.
Choisir le score direct/personnalisé lorsque l’évaluateur doit sélectionner une valeur globale de potentiel ; choisir les questions pondérées lorsque le résultat doit synthétiser plusieurs dimensions explicites. Dans ce mode, donner à chaque dimension un titre clair, une échelle de réponse cohérente et un poids reflétant son importance relative. Les quatre dimensions observées (apprentissage/progression, initiative/responsabilité, résolution de problèmes, adaptabilité) sont propres au client. Quatre poids de 25 % donnent une influence égale ; cela ne signifie pas que toutes les organisations doivent adopter cette répartition.
SMR — risque de perte et impact de la perte
Configurer séparément format, échelle proposée et libellés dans les langues requises. Le backend attend des questions de type échelle pour ces clés ; le potentiel pondéré n’est pas un type valide pour elles. Les libellés doivent distinguer risque de départ et conséquences métier.
Pour le risque de perte, préciser ce qui distingue chaque niveau selon le contexte de l’entreprise. Pour l’impact de la perte, définir les conséquences organisationnelles représentées par chaque niveau, par exemple la continuité de service ou la perte d’une expertise rare. Ces exemples aident à rédiger des libellés ; ce ne sont pas des dimensions natives SMR. Garder des échelles interprétables séparément et éviter de rendre leurs valeurs numériques directement comparables sans ancres équivalentes choisies par l’entreprise. Aucune pondération vérifiée ne relie ces critères à Performance ou Potentiel.

Paramètres du risque dans Chrome. Le critère possède son activation et sa version propres (V.003 dans ce client), distinctes de Performance et Potential.

Paramètres d’impact dans Chrome. Le critère possède son échelle et sa version ; cet écran ne démontre pas une prédiction automatique des conséquences d’un départ.
SML — configurer la définition réelle de la campagne
Vérifié dans le code ; administration en direct non inspectée : les indicateurs SML sont liés à une campagne legacy. Leur contrôleur enregistre libellés, positions et types, notamment select, choice et range, ainsi que les options. Les indicateurs saisis par participant sont distincts des scores de sections calculés.
Pour un calcul de section, vérifier le questionnaire lié, l’indicateur associé à la section et ses tranches de résultat, puis les barèmes des réponses choice/range. Sans indicateur et options de notation éligibles dont la somme est positive, le helper ne cumule pas les notes des questions de la section. Ne pas copier les pourcentages salarié/évaluateurs SMR : le helper de sections vérifié ne les utilise pas.
Le code inspecté n’établit pas d’écran entreprise universel pour les quatre scores nommés. Faire vérifier par le responsable de campagne quelle section ou quel indicateur correspond à chaque critère métier. La correspondance propre au client, les libellés en direct et les droits restent non vérifiés.
Le tableau de revue legacy contient aussi des valeurs participant pour la performance, le potentiel et le risque, et son contrôle de complétion attend ces trois champs. Cela confirme des champs distincts, sans prouver qu’ils utilisent le calcul des ReviewIndicator ou des scores de section. Le tableau inspecté ne présente pas de champ impact de la perte. Pour chaque campagne, noter si la valeur vient de ce tableau, d’un indicateur choisi manuellement ou d’une section de questionnaire calculée, puis vérifier les options et tranches associées. Cela évite de confondre un libellé sélectionné avec une moyenne numérique de section.
Valider et corriger une configuration
Avant utilisation, relire les libellés dans toutes les langues, totaux des poids, version, activation, questions sources et génération. Vérifier sur une campagne de test autorisée avec des réponses connues : une source, deux sources et visibilité des participants. Cette session n’a modifié aucun paramètre ni créé de donnée de test.
Consulter une ancienne version n’est pas un retour arrière. Pour corriger une configuration utilisée, préparer une nouvelle version et vérifier son utilisation par les futures campagnes. Aucun recalcul automatique des entretiens terminés, changement rétroactif en masse ou retour arrière en un clic n’a été établi.
| Problème | Vérification |
|---|---|
| Sauvegarde indisponible | Verrouillage, absence de modification, libellés requis, langue principale et messages de validation. |
| Potentiel pondéré refusé | Titres/libellés obligatoires, paramètres des questions et total de 100 %. |
| Référence de critère refusée par le serveur | Existence, type attendu et absence d’utilisation du même identifiant par un autre critère. |
| Traduction incomplète | Contenu principal et libellés ajoutés/supprimés après changement de plage ou format. |
| Campagne existante inchangée | Version et sources mémorisées ; une nouvelle version entreprise n’implique pas une application rétroactive. |
| Section legacy inattendue | Réponses éligibles et tranches de l’indicateur ; voir le calcul SML. |
Preuves et limites
Observé dans l’application : quatre onglets, versions utilisées, historique, échelles, poids du potentiel et contrôles compétences/objectifs dans Chrome le 28 octobre 2026. Aucune sauvegarde, traduction ou activation exécutée. Vérifié dans le code : clés, types, verrouillages, appels API et stockage/calcul SML. Spécification PRD : attentes sur les campagnes et l’historique. Non vérifié : valeurs par défaut universelles, administration SML en direct, cycle complet, migration rétroactive et visibilité des sorties. Sources : guide technique.
Dernière mise à jour : 3 novembre 2026