Critères d’évaluation — guide technique

Pour les équipes d’implémentation, de support et d’intégration. SMR = frontend/backend nextgen ; SML = application Symfony legacy. Pour la performance SMR, le PRD définit le fonctionnement cible. Les références aux dépôts identifient les composants d’implémentation concernés. Les parcours et paramètres figurent dans les guides fonctionnel et de configuration.

Architecture et responsabilités

Vérifié dans le code : CriteriaConfiguration.vue affiche les quatre critères SMR. API, store et mapper CompanySettings chargent configuration, questions et historique. La configuration de campagne résout les sources Performance ; OPRGenerator calcule la note d’entretien. People Review possède des calculateurs distincts pour les réponses échelle, pondérées et Performance. Ces chemins ne forment pas un algorithme unique interchangeable.

Observé dans l’application : /company/space/admin/settings/criteria intègre l’écran SMR dans la navigation entreprise. Les chemins SML restent distincts ; aucune passerelle ou migration automatique n’a été établie. Une recherche ciblée dans aihub/src n’a pas établi de dépendance IA pour ces quatre critères ; ce constat de recherche ne prouve pas une absence dans tout le système.

Modèle et configuration SMR

Clé de configuration	Type de question référencée attendu
PERFORMANCE_ASSESSMENT	CompanyPerformanceQuestion
POTENTIAL_ASSESSMENT	CompanyScaleQuestion ou CompanyWeightedQuestions
RISK_OF_LOSS_ASSESSMENT	CompanyScaleQuestion
IMPACT_OF_LOSS_ASSESSMENT	CompanyScaleQuestion

Vérifié dans le code : les valeurs référencent des questions entreprise par identifiant. AbstractQuestionConfigurationValidator vérifie qu’une référence entière existe, correspond au type attendu et n’est pas déjà affectée à une autre clé de critère incompatible. Ces validations ne remplacent pas le contrôle d’accès.

Les questions portent échelles/options et traductions. L’entité Performance contient les filtres de compétences/types, employeeVsEvaluatorSkillWeight, employeeVsEvaluatorObjectiveWeight, weightDistribution et computeOverScaleOption ; le DTO expose le choix manuel/avancé via useCustomScore. ReviewOverallPerformanceRating conserve composantes, détail et score/justification de l’évaluateur. ReviewUserScore SML est une autre entité : participant, question de section et note numérique.

Flux et contrats SMR

Vérifié aux sites d’appel frontend ; aucune écriture API exécutée. Les chemins sont des contrats d’application, sans identifiants client ni secrets.

Méthode / chemin	Rôle
GET /api/v1/company	Métadonnées entreprise et niveau maximal des compétences.
GET /api/v2/company/configuration/public	Liste ; le client demande la page 1, 25 entrées et des groupes imbriqués.
GET /api/v2/company/configuration/{slug}/history	Historique ; le client charge aussi les pages suivantes.
GET /api/v2/company/question/{id}	Question référencée et traductions.
POST /api/v2/company/question/{type}	Création ; type = scale, weighted ou performance.
PUT /api/v2/company/question/{type}/{id}	Mise à jour de la question de ce type.
PUT /api/v2/company/configuration/{slug}	Association de la valeur au critère.
POST /api/v2/company/question/{id}/translate	Traduction de source_locale vers target_locale.
GET /api/v2/review/{userReviewId}/overall-performance-rating	Lecture du résultat existant, utilisée pour un entretien verrouillé.
POST /api/v2/review/{userReviewId}/overall-performance-rating	Génération/récupération du calcul pour un entretien non verrouillé.
POST /api/v2/review/{userReviewId}/overall-performance-rating/evaluator-score	Enregistrement du score évaluateur et de la justification.

La fonction frontend nomme le paramètre de route userReviewId ; ne pas le remplacer par un identifiant salarié arbitraire. La forme d’association est {"value": <identifiant de question>}. La forme du score évaluateur est {"raw_score": <nombre ou null>, "justification": <texte ou null>}. Ces formes décrivent les contrats, pas des commandes de production ni les schémas complets d’autorisation/validation.

Créer/modifier la question puis associer la configuration sont des appels distincts ; aucune transaction atomique globale n’est affirmée. Après un échec, contrôler contenu et association active. Certaines lectures de configuration renvoient null après erreur, tandis que les mutations propagent l’erreur. Le client Performance valide la réponse et possède un repli GET ciblé pour une erreur de calcul signalant un manque de configuration compétences/objectifs. Ce repli peut récupérer une note manuelle ; il ne prouve pas la réussite du calcul automatique.

SMR — calcul cible de performance des entretiens

Fonctionnement cible défini par le PRD : le score standard est saisi par l’évaluateur principal pendant l’entretien. Le score avancé est calculé à partir des compétences, des objectifs de performance ou des deux, selon les sources activées dans la campagne. Les Smart Questions sources sont obligatoires.

La configuration entreprise définit les compétences incluses (toutes ou liées au métier), les types retenus, une pondération salarié/évaluateurs pour les compétences et une pondération indépendante pour les objectifs. Pour chaque composante, la part évaluateurs est partagée à égalité entre les deux évaluateurs contributeurs ; sans second évaluateur, elle revient au principal. Les réponses partielles disponibles sont utilisées ; les participants sans contribution sont exclus.

Le calcul comporte deux niveaux :

Composante = note salarié × poids salarié
             + note évaluateur(s) × poids évaluateurs
Performance = score compétences × poids compétences
              + score objectifs × poids objectifs

Les composantes utilisent leurs pondérations de participants respectives. Si la campagne ne retient que les compétences ou que les objectifs, la répartition globale entre sources ne s’applique pas. Le résultat normalisé est un entier de 0 à 100, converti ensuite en points, pourcentage ou lettres selon la version de configuration.

Les composants d’implémentation concernés sont OPRGenerator, OprManager, la résolution de configuration de campagne et les réponses compétences/objectifs. Le contrat cible de conservation des résultats et de visibilité figure ci-dessous.

SMR — normalisation des réponses People Review

Vérifié dans le code : CompanyAnswerValueNormalizerTrait normalise selon le format. Les points passent par les bornes et le convertisseur de matrice partagé ; un pourcentage numérique est borné à 0–100 ; A correspond à la borne haute en lettres. Valeurs nulles, vides et non prises en charge retournent zéro.

CompanyScaleAnswerScoreCalculator normalise une réponse échelle ; CompanyPerformanceAnswerScoreCalculator normalise sa valeur Performance stockée sans lancer OPRGenerator. CompanyWeightedAnswerScoreCalculator utilise d’abord le score remplacé s’il existe ; sinon :

score = somme(note normalisée renseignée × poids positif)
        / somme(poids positifs inclus)

Il ignore les poids non positifs, questions sans options et réponses nulles ; il retourne zéro si aucun poids éligible ne subsiste. Il n’impose pas que les poids effectivement inclus totalisent 100 %. Validation à 100 % dans la configuration et dénominateur à l’exécution ont des rôles distincts. Un zéro en matrice peut donc correspondre à une donnée absente/invalide plutôt qu’à une véritable évaluation minimale.

SML — indicateurs et calcul par section

Vérifié dans le code : le préfixe des routes est /company/review. ReviewIndicatorController lit/enregistre les indicateurs de campagne et leurs options, avec des branches choice, select et range. ReviewIndicatorItem porte les options ; ReviewUserIndicator la valeur choisie pour un participant.

DefaultController::performanceAction, sur /company/review/update/performance, lit option, le participant review et indicator, crée ou met à jour un ReviewUserIndicator, persiste l’option et retourne le libellé de l’indicateur. Aucun calcul compétences/objectifs n’a lieu dans cette action. Son nom ne prouve pas une équivalence avec la performance SMR.

ReviewAssessmentController::getSectionsScoreAction exige une requête AJAX et un participant, un questionnaire et un utilisateur existants. L’action appelle SectionScoreHelper::calculatesScoreOfSections, puis saveCalculatedScoreOfSections, et retourne sectionsScore. Ce parcours de calcul persiste aussi les résultats : ne pas l’appeler pour simplement inspecter les données de production.

Le helper parcourt les questions par position :

1. Une section initialise somme, moyenne et nombre de questions renseignées à zéro, et récupère l’indicateur associé et ses tranches.
2. Une question choice contribue dans une section avec indicateur si choices_scores existe et a une somme positive. Pour une réponse existante, il additionne les extra.score des choix et incrémente le dénominateur une fois par question répondue, pas par choix.
3. Une question range contribue si hints_scores existe avec une somme positive et si la réponse stockée est supérieure à zéro. La note est hints_scores[response − 1], puis le dénominateur augmente.
4. Pour une section avec indicateur et au moins une question éligible renseignée : moyenne = somme / nombre de questions renseignées, formatée à deux décimales. Les réponses absentes n’incrémentent pas le compteur. Les sections vides restent à zéro.
5. Le helper recherche les tranches inclusives (from ≤ moyenne ≤ to). Sans correspondance, le libellé initial est pas d’étiquette. Si les tranches se chevauchent, une correspondance plus tardive peut remplacer la précédente.
6. La sauvegarde crée ou met à jour un ReviewUserScore par participant et question de section, avec cette moyenne.

Exemple illustratif fondé sur le code : une question choice totalise 6 et une question range éligible vaut 4 : (6 + 4) / 2 = 5,00. Une troisième question sans réponse est exclue du dénominateur. Ce calcul diffère de la formule pondérée participants/composantes SMR.

Le mécanisme peut porter des indicateurs métier, mais aucune correspondance universelle avec les quatre scores SMR, aucun historique entreprise indépendant compatible, aucune échelle normalisée commune ni migration automatique n’ont été établis. Ces points restent non vérifiés.

Performance SMR — contrat cible et historique

Le PRD Performance, version 3 du 21 octobre 2026, définit le fonctionnement cible de cette documentation.

Élément	Règle cible
Versions	Chaque modification entreprise crée une nouvelle version ; chaque score possède son historique indépendant. Les anciennes versions sont en lecture seule.
Libellé	Un libellé obligatoire configurable est repris dans l’entretien, le PDF et l’historique.
Valeur normalisée	Le score avancé est représenté par un entier de 0 à 100, indépendamment de son format d’affichage.
Contributions	Utiliser les réponses partielles disponibles et exclure les participants sans contribution. Répartir à égalité la part évaluateurs lorsqu’ils sont deux ; sans second évaluateur, cette part revient au principal.
Lettres	Convertir la valeur normalisée vers la plage de lettres ; les modificateurs +/− indiquent la direction d’arrondi. Conserver la valeur normalisée d’origine.
Remplacement	Conserver les valeurs calculées et finales, la justification, l’auteur et la politique de visibilité utilisée pour la revue.
Visibilité	Après remplacement, résultat calculé, détail et justification sont visibles ensemble au salarié et au second évaluateur selon Always, Never ou Only when overridden score is higher. Comparer les valeurs normalisées ; une égalité ne suffit pas.
PDF	Appliquer les mêmes règles de visibilité que dans l’entretien.
Historique du profil	À la finalisation, conserver résultat affiché et normalisé, commentaires, référence de campagne/revue et version. Une nouvelle version ne recalcule pas les anciennes revues.

La section 44 du PRD réserve aux spécifications techniques détaillées les ancrages exacts de conversion des lettres, la normalisation des agrégats partiels et le schéma complet de l’historique.

Droits, erreurs et exécution

Vérifié dans le code : la route SMR exige une authentification, ce qui ne prouve pas à lui seul un accès serveur réservé à l’administrateur. Le PRD réserve le paramétrage à Admin et la saisie/le remplacement à l’évaluateur principal ; vérifier les droits client effectifs et tous les contrôles serveur avant intégration. Les contrôles AJAX legacy ne constituent pas non plus une preuve d’autorisation. Voir Rôles et permissions.

Distinguer appels question/configuration échoués, références incompatibles, libellés incomplets, sources manquantes, entretien signé/finalisé et zéros inattendus. Les erreurs et journaux frontend permettent d’identifier l’opération, mais aucun tableau de supervision dédié, tâche de calcul asynchrone, fréquence de rafraîchissement ou garantie de nouvelle tentative n’a été établi. Employer des diagnostics expurgés ; ne pas inclure d’évaluations nominatives, secrets ou commentaires privés.

Les chemins vérifiés utilisent composants frontend, services backend et entités persistées ; SML utilise contrôleurs Symfony, Twig et Doctrine. Aucun nouveau service à déployer n’est établi pour cette fonction. Les points d’extension sont les métadonnées des critères, types/validateurs de questions, résolution des sources, calculateurs et conversions d’affichage. Un nouveau type doit préserver les validations, références de version et droits participants chez les consommateurs. L’historique cible du profil conserve la version de configuration et les valeurs normalisées pour leur réutilisation ultérieure.

Preuves et limites

Dépôts locaux inspectés le 28 octobre 2026 ; les chemins identifient les sources et ne garantissent pas leur parité avec un commit déployé.

Dépôt	Sources / responsabilités
smartmobility-nextgen-front	src/modules/CompanySettings/CriteriaConfiguration.vue ; BasicConfiguration/criteria.constants.ts ; BasicConfiguration/components/Performance/PerformanceConfigurationStep.vue, EvaluationSkillConfiguration.vue, ObjectivesConfiguration.vue, SkillsGoalsWeightDistribution.vue ; composants de configuration Potential/RiskOfLoss/ImpactOfLoss ; api/company.api.ts ; src/router/private-routes.ts. Les chemins BasicConfiguration sont relatifs à CompanySettings.
smartmobility-nextgen-front	src/modules/ModuleConfig/Campaigns/modules/Reviews/api/review.api.ts ; composants de rendu Performance et paramètres avancés de campagne.
smartmobility-nextgen-back	Validateurs sous src/Infrastructure/Persistence/Validator/Company/Configuration/ ; src/Domain/V2/Company/DTO/Question/Performance/CompanyPerformanceQuestionDTO.php ; entité sous src/Infrastructure/Persistence/Entity/Setting/Question/Performance/.
smartmobility-nextgen-back	src/Infrastructure/Persistence/Service/Review/OPRGenerator.php, OprManager.php ; Service/PeopleReview/CompanyAnswerValueNormalizerTrait.php, CompanyScaleAnswerScoreCalculator.php, CompanyWeightedAnswerScoreCalculator.php, CompanyPerformanceAnswerScoreCalculator.php sous la même racine Persistence.
smartmobility-legacy	src/Company/ReviewBundle/Controller/DefaultController.php, ReviewIndicatorController.php, ReviewAssessmentController.php ; src/Company/AssessmentBundle/Service/SectionScoreHelper.php ; entités ReviewIndicator, ReviewIndicatorItem, ReviewUserIndicator, ReviewUserScore sous src/Main/ConfigBundle/Entity/ ; config/routes.yaml et routes du ReviewBundle.
aihub	Recherche ciblée dans src sur les quatre scores ; aucune dépendance de calcul établie.

Observé dans l’application : huit captures de fenêtre Chrome entière des paramètres SMR, le 28 octobre 2026. Vérifié dans le code : chemins et formules ci-dessus. Spécification PRD : document fourni, dont la section 12 sur les poids des participants aux objectifs. Déduit : sens métier des critères lorsqu’aucun modèle numérique n’est défini. Non vérifié : parcours SML en direct, correspondances client des quatre noms, parité de déploiement, couverture complète des contrôles d’accès, cycle entretien/remplacement/PDF/profil et migration. Aucun code applicatif, paramètre ou base n’a été modifié.