Plan de carrière — guide technique
Cette référence destinée aux équipes d'implémentation et de support couvre listes/détails salariés, métiers cibles, horizons, coexistence manager et consommateurs aval. Voir les guides fonctionnel et de configuration.
Architecture et responsabilités
Vérifié dans le code : le parcours observé appartient à smartmobility-legacy : contrôleurs Symfony, modèles Twig, formulaires/AJAX et entités Doctrine. Le nouveau menu ne prouve pas une implémentation nextgen native.
Ce schéma représente des appels et dépendances vérifiés, sans garantir un délai d'événement ni une synchronisation AIHub immédiate.
Composant, relatif à smartmobility-legacy/src | Responsabilité |
|---|---|
Customer/InternalJobBundle/Controller/UserPlanController.php | Liste/détail autonome, création/renommage/suppression, cibles et actions. |
Customer/InternalJobBundle/Resources/views/Default/{list.carierplan,career-plan-details}.html.twig et Partials | Cartes, dialogues, nom éditable, états vide/complet, soumissions. |
Company/ProspectBundle/Services/ViewSection/CareerPlanSection.php | Visibilité manager et chargement des plans/scores du salarié. |
Main/ConfigBundle/Controller/UserPlanController.php | Contrôleurs partagés manager/accompagnement, distincts des contrôleurs salariés. |
Company/AccountBundle/Controller/SettingController.php::mycareerAction | Horizons de l'entreprise et certains paramètres d'adéquation. |
Main/ConfigBundle/Entity/UserPlanJob.php | Association métier/horizon et lecture du score. |
EventSubscriber/{JobOfferMatchingV1ScoreSubscriber,PlatformActivitySubscriber}.php | Déclenchements de recalcul et messages d'activité enregistrés. |
Flux de requêtes et données
Vérifié dans le code : la liste charge les plans ordonnés de l'utilisateur authentifié et calcule le prochain type principal/B/C. Le détail contrôle le propriétaire. Les deux redirigent vers l'accueil des métiers si my_career_v2 est désactivé ; le sous-menu vérifie séparément careerplan_fo.
La création contrôle le jeton CSRF de session, l'utilisateur, un nom/type non vide et moins de trois plans. Elle persiste propriétaire et dates, effectue un flush, émet un objet UserPlanCreatedEvent sous le nom d'événement UserPlanChangedEvent::class, puis redirige. UserPlan::setType normalise un type inconnu en type principal ; MAX_PLANS = 3.
L'ajout de cible exige AJAX et CSRF, cherche le plan par identifiant et propriétaire courant, résout métier et horizon, refuse un horizon occupé ou un plan complet, persiste l'association/date du plan et émet UserPlanJobChangedEvent. L'actualisation est asynchrone : vérifier carte et compteur avant de resoumettre.
Observé dans l'application : le compte prescrit a créé un plan B et enregistré Data Manager, puis l'écran actualisé a affiché une cible, 0–0 an et 41 %.
Le plan rouvert présente une cible et la carte Data Manager avec horizon et pourcentage de correspondance. Contrôlez la cible dans le bon scénario avant tout ajout ; le matching n’est pas un taux de réalisation d’actions. Interface anglaise ; le titre du métier est une donnée du référentiel.
Contrats des routes salariées
Vérifié dans le code : préfixe /plateforme/internal-job, défini dans config/routes.yaml et les routes du bundle. Ce sont des routes web avec session, pas une API REST nextgen publiée. Les paramètres décrivent les handlers, sans recommander des appels directs.
| Méthode et chemin relatif | Entrées | Résultat |
|---|---|---|
GET /career-projects | Session | Liste HTML ; déclaration sans restriction de méthode. |
GET /career-projects/{id} | Plan | Détail HTML ; non-propriétaire redirigé vers la liste. |
POST /userplan | name, type, _csrf_token | Redirection détail ou liste avec erreur flash. |
PUT /userplan | AJAX : id, name, _csrf_token | JSON Career plan changed ; 404 absent/étranger, 403 jeton invalide, 400 hors AJAX. |
DELETE /userplan | AJAX : id | JSON Career plan deleted ; 404 si aucun plan du propriétaire courant, 400 hors AJAX. |
POST /userplan/jobtarget | AJAX : id, job, target, _csrf_token | JSON response: success ; certaines erreurs redirigent avec flash ; 403 CSRF, 400 hors AJAX. |
POST /userplan/jobtarget/{id} | job, target | Mise à jour et redirection ; contrôle du propriétaire du plan. |
DELETE /userplan/jobtarget | AJAX : id | JSON succès/404/400 ; supprime aussi les scores de ce métier pour l'utilisateur courant. |
POST /userplan/action | id, description, date | Action non terminée, puis redirection ; propriétaire contrôlé à la création. |
POST /userplan/action/{id} | description, date | Met à jour action et date du plan, puis redirige. |
POST /userplan/complete/action | AJAX : id | Positionne achèvement et date ; le texte de réponse dit à tort Career plan action deleted. |
Exemple logique sans données réelles : id=PLAN_ID&job=JOB_ID&target=HORIZON_ID&_csrf_token=SESSION_TOKEN. Les identifiants proviennent de l'interface autorisée et le jeton de la session. Réponse de succès :
{"response": "success"}
Ne pas supposer que toute réponse est JSON : plusieurs erreurs redirigent. Le libellé d'achèvement ne décrit pas l'opération réelle.
Modèle et cycle de vie
Vérifié dans le code :
| Entité | Relations et état |
|---|---|
UserPlan | Propriétaire, type Principal Plan/Plan B/Plan C, nom, description/objectif optionnels, indicateur manager, dates ; associations cibles/actions en cascade all. |
UserPlanJob | Plan, métier, horizon nullable, indicateur manager et dates. |
UserPlanTarget | Configuration d'entreprise, entiers target_start/target_end, dates. |
UserPlanAction | Plan, nom/description optionnels, échéance, achèvement et date associée, dates techniques. |
Les modèles de création/renommage limitent la saisie à 30 caractères ; la colonne Doctrine accepte 255 et les contrôleurs inspectés ne répètent pas explicitement cette limite de 30. L'unicité d'horizon et la capacité sont contrôlées à l'ajout, sans contrainte de base démontrée ; le handler d'édition ne répète pas ces contrôles.
Les actions lisent une date d/m/Y et fixent l'échéance à 23:59:59 ; la gestion d'une date invalide n'est pas établie comme robuste. Les vues/handlers existent mais un éditeur d'actions visible dans le parcours autonome reste Non vérifié.
Le score affiché appelle getUserPercentageMatching : lecture de UserJobMatching pour propriétaire/métier, arrondi de score * 100, zéro sans enregistrement. Il diffère de l'ancienne méthode séparée getUserPercentage, fondée sur le nombre de compétences. Ce score ne prédit pas une décision de sélection.
Retirer un horizon met à null les références existantes avant suppression ; recréer le même intervalle ne les rétablit pas. Les switches d'adéquation sont traités avant validation/transaction des horizons : un rollback de ces derniers ne démontre pas celui des switches.
Événements et consommateurs
Vérifié dans le code : le contrôleur autonome émet des événements de création/suppression de plan et changement/retrait de cible. JobOfferMatchingV1ScoreSubscriber recalcule par utilisateur sur changement de plan/cible et retrait de cible ; PlatformActivitySubscriber enregistre des événements d'activité. Le renommage inspecté modifie la base sans émettre lui-même UserPlanChangedEvent. Toutes les mutations n'ont donc pas le même comportement événementiel.
notifyManager retourne immédiatement avant le code d'envoi : l'email automatique manager est désactivé dans cette implémentation, malgré les appels et le modèle de notification. Une livraison par un autre système est Non vérifiée.
Vérifié dans le code : dans AIHub, src/entity/user/imports/data_sources/import_users_sm.py joint UserPlan → UserPlanJob → job, conserve les codes métier non nuls, regroupe codes/titres et alimente careerPlanJobReferences. src/entity/user/postgres/{models,repository}.py transporte aussi ces références. Cela établit une consommation de données utilisateur, pas la propriété du CRUD par AIHub. Fréquence d'import, lien événements/import et propagation de la cible de test : Non vérifiés.
Permissions, sécurité et confidentialité
Vérifié dans le code : détail salarié, renommage, suppression de plan et ajout de cible contrôlent le propriétaire ; création/renommage/ajout de cible valident CSRF. La visibilité manager dépend de bo_hide_carriere_tab et careerplan_bo. Les paramètres exigent la structure sans parent de l'utilisateur courant.
Les protections diffèrent selon les méthodes : suppression de cible, édition/achèvement d'actions et handlers manager partagés ne montrent pas les mêmes contrôles de propriétaire/CSRF en leur sein. Firewall, routes et voters n'ont pas fait l'objet d'un audit complet. Ne pas généraliser les protections d'une méthode à toutes les routes ; examiner la chaîne complète avant extension et tester uniquement des objets autorisés.
Les intérêts professionnels et scores liés au salarié sont des données personnelles. Limiter journaux/captures au périmètre autorisé, exclure jetons, détails privés et adresses d'infrastructure. Le parcours est resté sur l'entreprise et le compte de test prescrits.
Coexistence legacy et refonte
Les contrôleurs autonomes, Customer/ProfileBundle/Controller/UserPlanController.php, les handlers de galaxie et Main/ConfigBundle coexistent avec des paramètres/validations différents. Les routes manager /company/accompagnment/userplan sont distinctes des routes salariées.
Vérifié dans le code : nextgen-back src/Infrastructure/Doctrine/DBAL/Type/UserPlanType.php conserve les trois types. Nextgen-front src/modules/SmartTrad/utils/lexico-fallbacks.ts fournit le vocabulaire et les composants de revue/développement contiennent des libellés de rattachement. Un CRUD complet nextgen ou calendrier de migration reste Non vérifié.
Erreurs, observabilité et extension
Examiner les switches/sous-menus pour une entrée absente, my_career_v2 pour une redirection, session/CSRF/propriétaire/métier/horizon/capacité pour un refus et les scores enregistrés pour un pourcentage absent. Les erreurs flash/redirections peuvent être mal interprétées par un client JSON. Examiner les erreurs applicatives, événements et consommateurs dans les outils autorisés ; aucun journal ni trace de file n'a été consulté.
Dépendances : pile Symfony/Twig/Doctrine legacy, données métiers/horizons, session/CSRF, scores enregistrés et consommateurs événementiels activés. AIHub consomme des références importées. Une extension doit couvrir contrôleur/vue, modèle et autres points d'entrée concernés, avec contrôles de propriétaire, doublons d'horizon et échec partiel de configuration. Procédure de déploiement et correspondance source/version déployée : Non vérifiées.
Preuves et limites
Observé dans l'application : PS Testing, compte prescrit, 23 octobre 2026 ; liste/détail, création, recherche/horizon, cible persistée, éditeur de nom, plan complet, espace manager et paramètres interdits. Aucune suppression.
Vérifié dans le code : composants cités ; legacy Main/ConfigBundle/Resources/config/doctrine/UserPlan{,Job,Target,Action}.orm.yml, Main/ConfigBundle/Resources/config/routing/userplan.yml, Main/SitemapBundle/Enum/Customer/InternalJobTabsEnum.php, Service/Configuration/UserPlanTargetDefaultConfigurationService.php, Event/UserPlan*Event.php, config/configuration/default_configuration.yml ; chemins nextgen/AIHub ci-dessus.
Non vérifié : audit complet des autorisations, sauvegarde de configuration, gestion d'actions, suppression, livraison/délai des recalculs, notifications, synchronisation AIHub, mobile et parité production. Aucun dépôt applicatif n'a été modifié.
Sources du guide fonctionnel
Ces références d’implémentation et de produit étayent le guide fonctionnel. Le code local n’établit pas la révision ou les options déployées. Les observations dans l’application restent distinctes du code et des sources documentaires.
- Observé dans l'application : PS Testing et compte prescrit uniquement ; espaces, liste/détail, création B, état vide, recherche et horizon, cible persistée, score, éditeur de nom, refus de capacité et accès interdit aux paramètres. Captures de fenêtre complète.
- Vérifié dans le code : dans
smartmobility-legacy/src,Customer/InternalJobBundle/Controller/UserPlanController.php, vuesDefaultetPartials,Main/ConfigBundle/Entity/{UserPlan,UserPlanJob}.php,Company/ProspectBundle/Services/ViewSection/CareerPlanSection.php. - Non vérifié : suppression, persistance d'un changement de nom/cible, actions, édition manager, sauvegarde de configuration, mobile, délais des recommandations et correspondance entre version déployée et sources. Le plan de documentation et sa cible restent disponibles sur PS Testing.
Vérification des parcours du 26 octobre 2026
Observé dans l’application : PS Testing 2026, Jim Carter. Un plan C isolé 14989 a été créé avec MANAGER LEADER BUSINESS MANAGEMENT ; le contrôle de l’horizon manquant puis la sauvegarde à 0–0 ans ont été suivis d’un rechargement : une cible et 81 % de matching. Le plan principal existant a été conservé. Le 27 octobre 2026, après autorisation explicite de l’utilisateur, le plan B 14965 a été renommé de Documentation walkthrough en Documentation G-04 plan B. Un rechargement complet a conservé ce titre ; DATA MANAGER, son horizon de 0–0 ans et le matching affiché de 41 % sont restés visibles. Le blocage d’approbation précédent est levé pour ce seul renommage. La sauvegarde depuis la galaxie reste distincte et non vérifiée.
Dernière mise à jour : 3 novembre 2026