Plan de succession — guide technique

Référence pour les mainteneurs et administrateurs autorisés. Les guides fonctionnel et configuration décrivent les usages. Les chemins indiqués sont relatifs aux dépôts nommés, sans URL d'infrastructure ni secret.

Architecture et composants

Vérifié dans le code : la succession historique utilise Symfony, Twig, jQuery/AJAX et Doctrine au sein de People Review. Les propositions sont des ReviewSuccessor, distincts des réponses génériques au questionnaire. Le module Vue autonome de la nouvelle interface est séparé et incomplet dans la version examinée.

Composant	Responsabilité
AssessmentBundle historique	Types de questions, titres et bornes ordonnées.
ReviewBundle DefaultController	Campagne, population, évaluateurs, questionnaire.
ReviewAssessmentController	Affichage, recherche, ajout, déplacement, suppression et clôture.
SuccessionQuestion.hml.twig	Modales, période obligatoire, sauvegarde AJAX, carte. Le nom de fichier contient bien hml.
successionCollectiveQuestion.html.twig	Tableau, colonnes, glisser-déposer et suppression.
ReviewPDFController et vues PDF	Rendu de la succession dans les parcours PDF ; résultat non contrôlé en direct.
Nextgen ModuleConfig/SuccessionPlan	Liste fictive, filtres/tri/pagination locaux et formulaire de base.

Flux et contrats

Vérifié dans le code : config/routes.yaml monte ReviewBundle sous /company/review. Les suffixes ci-dessous proviennent de Resources/config/routing.yml. Il s'agit de contrats internes ; l'interface autorisée reste le parcours utilisateur.

Suffixe de route	Traitement, entrée et résultat
/r/assessmentView/{id}	indexAction, ID de ReviewUser, affiche le formulaire individuel et ses propositions.
/r/succession/assessmentfindcollab	findUserAction, POST AJAX search, jusqu'à 15 suggestions id/name dans les écoles du tenant courant ; réponse de forme différente en l'absence de résultat.
/r/succession/saveSuccessor	saveSuccessorAction, POST AJAX collab, period, review, reviewUser ; résolution du successeur par nom d'utilisateur dans le tenant de campagne, création ou mise à jour.
/r/collectivereview/{id}	assessmentcollectiveAction, ID de campagne, affichage collectif.
/actions/succession/moveuser	POST AJAX successor, reviewUser, period ; modifie le collaborateur remplacé et l'horizon. Ici successor est l'ID de proposition.
/actions/succession/deleteuser	POST AJAX successor ; suppression de la proposition Doctrine.
/r/review/saveDone	POST AJAX reviewuser ; active le champ done de la revue individuelle.
/actions/succession/collectiveEnd	POST AJAX review ; marque la revue collective terminée, enregistre la date et le statut terminée.

Exemple neutralisé d'ajout, encodé comme champs de formulaire et non en JSON :

collab=<nom d'utilisateur sélectionné>
period=0-2
review=<id de campagne>
reviewUser=<id de ligne collaborateur>

Le succès renvoie response: "success", un fragment HTML et period. Un nom non résolu renvoie response: "response". Le client ajoute la carte reçue à la colonne correspondante. Ne journalisez pas ces fragments ni les résultats de recherche contenant des données RH.

Observé : l'ajout du compte de test, avec période 0–2, a produit Successor taken into account ; réouverture et vue collective ont retrouvé la proposition. L'auto-sélection était uniquement un test de mécanique, sans évaluation d'éligibilité ni recommandation RH.

Modèle et cycle de vie

Vérifié dans le code : src/Main/ConfigBundle/Resources/config/doctrine/ReviewSuccessor.orm.yml définit :

Élément	Contenu
id	Entier généré de la proposition.
period	Chaîne obligatoire, longueur 255, par exemple 0-2.
review → Review	Campagne.
reviewuser → ReviewUser	Ligne du collaborateur remplacé.
successor → User	Collaborateur proposé.

Le traitement cherche le triplet (review, reviewuser, successor) : s'il existe, sa période est mise à jour, sinon un enregistrement est créé. C'est une réutilisation applicative ; unicité en base et protection contre les créations concurrentes n'ont pas été établies. L'entité n'a pas de lien vers l'ID de question : l'isolation de plusieurs questions individuelles dans un formulaire n'est pas démontrée.

Les bornes sont dans AssessmentQuestion.options.choices, tableau plat ordonné. Twig regroupe les valeurs par deux et les joint par un tiret. Le contrôleur collectif cherche une question succession du même questionnaire ; la question collective est de type succession-collective. Il charge les propositions de la campagne et calcule les comptes par successeur. L'affichage compare les chaînes de période aux colonnes : un changement de libellé n'est pas une migration des propositions.

L'ajout ne termine pas la revue. La clôture individuelle active ReviewUser.done. La clôture collective écrit Review.iscollectivedone, datecollectivedone et status. Le traitement d'ajout ne crée ni affectation de poste, ni offre, ni plan de développement.

Configuration, accès et données personnelles

Vérifié dans le code : le rendu individuel vérifie le contexte School et le tenant, puis les relations, évaluateurs, administrateurs et droits dont review_all et can_review_himself. Le rendu collectif accepte l'administrateur principal, l'administrateur de campagne ou review_all. Le type de questionnaire dépend de module_review_bo ; l'édition de campagne de review_create.

Les méthodes d'ajout/déplacement/suppression ne répètent pas toutes ces vérifications de rendu dans leur propre corps. La chaîne complète firewall, CSRF et autorisation tenant de chaque écriture n'a pas été établie. Les contrôles d'affichage ne prouvent donc pas des contrôles équivalents sur toutes les écritures. Aucun test entre tenants n'a été réalisé.

Les propositions sont des données de planification RH. Limitez les accès à la population autorisée et évitez les réponses de recherche, HTML, données de profil et secrets dans les diagnostics. Les captures utilisent le jeu d'essai nommé ; aucun mécanisme de partage public n'a été établi.

Coexistence historique et nouvelle génération

Vérifié dans le code : smartmobility-nextgen-front/src/constants/app-route.ts définit SUCCESSION_PLAN à /:space(admin)/modules/succession-plan. router/private-routes.ts charge SuccessionPlanModule.vue avec requiresAuth: true. NavigationModule associe l'entrée à read-succession-plan.

Dans src/modules/ModuleConfig/SuccessionPlan/ :

• components/SuccessionPlanList.vue utilise mockSuccessionPlans. Recherche nom/poste, filtre de statut, tri et pagination sont locaux. L'ouverture affiche un toast, la navigation détaillée étant commentée. La suppression retire un élément du tableau fictif.
• store/successionPlan.store.ts conserve les filtres/pages/tris, sans prouver une persistance serveur.
• store/createSuccessionPlan.store.ts définit une seule étape, nom/description initialement vides.
• createSuccessionPlan.composables.ts refuse un nom vide ou composé d'espaces. handleNext contient TODO: Call API to create succession plan, affiche un succès, réinitialise le formulaire et ferme la modale, sans enregistrer de plan.

Le backend nextgen déclare SUCCESSION_CANDIDATE comme troisième critère de matrice People Review dans Domain/V2/PeopleReviewCampaign/DTO/PeopleReviewCampaignMatrixDTO.php. Cela ne démontre ni API CRUD autonome ni migration de ReviewSuccessor. Aucun pont de persistance, événement, traitement asynchrone ou appel AIHub n'a été trouvé dans le parcours d'ajout/liste tracé. Les recherches ciblées dans les domaines entity/matching d'AIHub n'ont pas trouvé d'intégration directe de succession ; cela n'exclut pas un usage futur des services génériques de matching.

Erreurs et observabilité

Situation	Comportement ou diagnostic
Période absente	Observé : Please select a period to continue. Un autosave générique ne prouve pas l'ajout.
Nom non résolu	Vérifié : réponse non réussie ; contrôler suggestion et appartenance au tenant.
Échec AJAX	Vérifié : message d'erreur traduit ; vérifier résultat et jeton sans journaliser les données RH.
Entité de déplacement/suppression absente	Vérifié : response: "error". Certains traitements renvoient sinon succès sans changement effectif : vérifier l'état stocké.
Bornes incomplètes ou renommées	Dépendance à l'ordre des paires et aux chaînes de période ; migration/validation sémantique non établies.
Clôture collective	Change le statut de campagne ; dépasse la simple sauvegarde d'une proposition.
Toast nextgen	Ne constitue pas une preuve de sauvegarde API.

Dépendances et évolutions

L'historique nécessite session entreprise, contexte tenant, profils/relations, Doctrine, Twig et ressources jQuery/AJAX/sortable. Le PDF possède son propre chemin de rendu. Aucun worker, ordonnanceur ou service IA spécifique à la succession n'a été établi. Nextgen nécessite Vue/Pinia et le contexte d'authentification/navigation ; le déploiement des ressources front ne comble pas l'absence de persistance.

Pour achever le module autonome : définir les contrats et contrôles tenant/permissions, connecter liste/création, puis décider du lien avec les propositions historiques. Documenter migration, unicité, compatibilité des horizons et clôture avant d'annoncer la parité. Il s'agit de pistes d'évolution, pas de capacités déjà livrées.

Preuves et limites

Observé dans l'application : 25 octobre 2026, PS Testing 2026, Jim Carter uniquement. Campagne 3518, formulaire 10061, ligne individuelle 59233. Configuration en cinq étapes, validation, ajout/réouverture, vue collective et clôture individuelle : 1 Reviews validated on 1, 100%, COMPLETED. Après I finish → Yes, I validate, la synthèse de campagne affiche Completed, Terminée, 100% et une revue terminée. Aucune notification n'a été planifiée.

Vérifié dans le code : versions locales historique 9ecdb0db43, front nextgen d14017a5, backend nextgen 00beda02c, AIHub 757dd2678. Ce ne sont pas les versions déployées certifiées. Sources : historique config/routes.yaml, ReviewBundle routes/contrôleurs/vues/PDF, éditeur AssessmentBundle et ReviewSuccessor.orm.yml ; routes, navigation et module SuccessionPlan nextgen.

Non vérifié : glisser-déposer, suppression, PDF, ouverture du plan de développement, réception d'emails, autre compte, chaîne de sécurité complète des écritures, persistance autonome nextgen et migration.

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.

Vérifié dans le code : dépôt smartmobility-legacy, src/Company/ReviewBundle/Controller/ReviewAssessmentController.php, vues assessment/SuccessionQuestion.hml.twig et successionCollectiveQuestion.html.twig ; dépôt smartmobility-nextgen-front, src/modules/ModuleConfig/SuccessionPlan/.