Plan de carrière — guide de configuration

Préparez l'accès salarié, la visibilité manager, les horizons et les fiches métiers avant activation. Consultez les guides fonctionnel et technique.

Public et accès

L'administrateur d'entreprise ou l'équipe de déploiement maintient les paramètres. Les RH entretiennent le référentiel et les données de profil ; les managers interviennent dans leur périmètre autorisé.

Observé dans l'application : PS Testing, compte prescrit, le 23 octobre 2026. Création d'un plan et ajout d'une cible réussis dans l'espace personnel. L'espace manager était accessible, mais les paramètres du plan ont refusé l'accès. Aucun paramètre du tenant n'a été modifié. Les étapes d'administration ci-dessous sont Vérifiées dans le code, sans sauvegarde administrateur observée.

La page affiche un refus d’autorisation au lieu des paramètres de carrière. Revenez à la navigation normale et demandez un contrôle d’accès à un administrateur habilité ; aucun réglage n’est visible ici. Message d’autorisation capturé en anglais.

Afficher en taille réelle

Activation et dépendances

Paramètre ou donnée	Portée et effet	Preuve
careerplan_fo	Visibilité de l'onglet salarié dans le sous-menu des métiers.	Code : InternalJobTabsEnum, InternalJobSubmenuService.
my_career_v2	Accès à la génération autonome des listes/détails ; sinon redirection vers l'accueil des métiers. Ce n'est pas un indicateur de migration nextgen.	Code : contrôleur salarié.
careerplan_bo	Sous-section plans du profil salarié côté manager.	Code : CareerPlanSection.
bo_hide_carriere_tab	Masque globalement la rubrique carrière manager lorsqu'il est activé.	Code : CareerPlanSection.
Fiches métiers et langue	Alimentent le sélecteur de cibles.	Code : requêtes JobRepository.
Horizons de l'entreprise	Intervalles début/fin ; un emplacement par horizon et par plan dans l'ajout autonome.	Code ; option 0–0 observée.
Adéquation utilisateur/métier enregistrée	Pourcentage affiché ; zéro si aucun enregistrement.	Code : getUserPercentageMatching.
job_matching	Affichage du texte explicatif sur les suggestions d'offres dans la vue inspectée. Ne règle pas le nombre de plans.	Code : vue de détail.

La limite de trois plans est une constante du code, pas un champ trouvé dans l'écran de paramètres. Les valeurs effectives des switches et leurs règles d'héritage sont Non vérifiées ; une entrée visible ne permet pas de les déduire intégralement.

Configurer les horizons

La route définie dans le code est /company/account/setting/mycareer. Le modèle affiche My Career Parameters, Intervalles d'une année cible, Ajouter une année cible, Démarrer, Fin et Enregistrer.

1. Utilisez un compte habilité : le contrôleur exige une structure liée à l'utilisateur courant, sans structure parente. Un manager ordinaire ne suffit pas.
2. Relevez les intervalles actuels et les plans qui les utilisent.
3. Ajoutez une ligne et renseignez les bornes entières de début et fin.
4. Vérifiez début inférieur ou égal à fin, sans paire début/fin strictement identique à une autre.
5. Choisissez Enregistrer.
6. Dans un plan de test salarié, vérifiez les horizons proposés, enregistrez une cible puis rouvrez le plan.

Vérifié dans le code : contrôle de début supérieur à fin et de doublons exacts. Début égal à fin est accepté par cette condition. La boucle ne rejette pas explicitement les intervalles différents qui se chevauchent ni les valeurs négatives ; des intervalles cohérents et non négatifs constituent une recommandation opérationnelle, pas une validation serveur démontrée.

Valeurs initiales, portée et données existantes

Vérifié dans le code : config/configuration/default_configuration.yml prévoit 0–2, 3–4, 5–8 ans. UserPlanTargetDefaultConfigurationService crée les lignes pour une configuration d'entreprise à partir de UserPlanTarget. Ce sont des valeurs d'initialisation, pas une garantie pour un tenant existant. La boucle n'établit pas une réconciliation idempotente.

Observé dans l'application : PS Testing ne proposait que 0–0 an. Cette observation décrit son interface actuelle ; les exemples d'initialisation ne doivent pas la remplacer. Aucun remplacement par salarié n'a été établi : le modèle relie les horizons au paramétrage de l'entreprise.

Vérifié dans le code : une paire inchangée est conservée, une nouvelle paire crée une ligne et une paire retirée entraîne la suppression de son horizon après mise à null des références UserPlanJob. Des métiers existants peuvent donc perdre leur horizon. Recréer l'ancien intervalle ne rétablit pas automatiquement ces associations.

Paramètres d'adéquation associés

Le même écran traite job_proximity_matching_green, job_proximity_matching_orange, job_proximity_matching_red et difference_classification_level, avec des valeurs numériques ou complexes à deux bornes selon le type. Les valeurs actives, plages autorisées complètes, héritages et effets sur ce tenant sont Non vérifiés. Ne copiez pas de seuils d'exemple.

Vérifié dans le code : ces switches sont traités avant la validation des horizons et leur transaction. Une erreur d'intervalle ne prouve donc pas l'annulation des changements de switches. Modifiez séparément horizons et seuils, en conservant un état avant/après.

Déploiement, validation et retour arrière

Validez sur un tenant de test : navigation salarié, visibilité manager, création vide, recherche de métier, chaque horizon, compteur après sauvegarde, score et message de plan complet. Vérifiez aussi le refus d'accès attendu pour un compte non autorisé. Les suggestions d'offres et de formation se valident séparément.

Pour retirer l'entrée, un administrateur restaure les valeurs d'activation antérieures. Masquer l'onglet n'est pas une suppression de données démontrée. Pour restaurer les horizons, rétablissez les paires relevées et faites examiner les associations mises à null ; recréer une paire ne suffit pas. Aucun retour arrière automatique ni délai de recalcul n'a été vérifié.

Problème	Contrôle
Onglet salarié absent	Activation, espace et traductions.
Redirection depuis le détail	my_career_v2 et génération legacy attendue.
Rubrique manager absente	Masquage global, careerplan_bo, droits sur le profil.
Cible supplémentaire refusée	Horizons existants et emplacements occupés.
Erreur à la sauvegarde	Ordre des bornes et doublons exacts.
Cible sans années	Suppression de son horizon lors d'une configuration.
Paramètres interdits	Éligibilité de la structure racine ; ne pas contourner par changement d'identité.

Coexistence, preuves et limites

Vérifié dans le code : paramètres et écrans observés en legacy Symfony/Twig. Le type compatible dans nextgen-back et les libellés dans nextgen-front ne prouvent pas l'existence d'un nouvel écran d'administration complet.

Sources dans smartmobility-legacy : src/Company/AccountBundle/Controller/SettingController.php::mycareerAction, Resources/views/Setting/mycareer.html.twig et Resources/config/routing.yml du même bundle ; config/routes.yaml, config/configuration/default_configuration.yml, src/Service/Configuration/UserPlanTargetDefaultConfigurationService.php, src/Main/ConfigBundle/Resources/config/doctrine/UserPlanTarget.orm.yml, src/Main/SitemapBundle/Enum/Customer/InternalJobTabsEnum.php, src/Company/ProspectBundle/Services/ViewSection/CareerPlanSection.php.

Non vérifié : sauvegarde et restauration administrateur, valeurs/héritages actifs, propagation des recommandations et correspondance des versions. Les identifiants de code servent à l'assistance technique ; aucun secret n'est fourni.