Viviers de talents — guide technique

Ce guide aide les équipes d’implémentation et de support à tracer le module refondu Talent Pool, son infrastructure commune de groupes et son intégration People Review. Le guide fonctionnel décrit l’utilisation ; la configuration distingue administration client et prérequis de plateforme.

Les affirmations techniques sont vérifiées dans le code des dépôts locaux examinés le 16 octobre 2026. Elles ne prouvent ni le déploiement, ni la disponibilité à l’exécution, ni les autorisations effectives d’une entreprise. Les chemins sont relatifs aux dépôts indiqués dans la cartographie des sources.

Architecture et responsabilités

Composant	Responsabilité
Définition de navigation historique / extension Twig	Expose la fonctionnalité d’administration lorsque les prérequis sont satisfaits, sans second éditeur de vivier.
TalentPoolModule Vue	Listes/détails, contenu localisé, candidats, permissions et retours utilisateur.
Stores Pinia / composables	Recherche, tri, pagination, candidats sélectionnés et état du vivier.
talentPool.api.ts	Requêtes V2, validation et conversion des réponses.
Routage YAML	Contrôleurs de ressources, permissions, filtres et relations.
TalentPool / TalentPoolUser	Configuration du vivier et membres.
Listener de groupe / service de règles communs	Lecture seule, protection du retrait dynamique, publication et évaluation des règles.
Gestionnaire / listener du vivier	Événements de membres et synchronisation des campagnes liées.

Aucun appel AIHub ni modèle de classement de talents n’a été identifié dans ce parcours. Une recherche du nom dans AIHub ne constitue pas un audit de toutes les intégrations externes. Ce module est distinct des viviers de candidats à des offres dans AIHub.

Navigation et coexistence

Le front définit TALENT_POOL dans src/constants/app-route.ts comme /:space(admin)/modules/talent-pool ; src/router/private-routes.ts associe les routes authentifiées de liste et de détail /:id.

Le fichier historique app/config/neobrain/company/definitions.yml définit smr_talent_pool avec enable_new_neobrain_hybrid_platform, le droit smr_talent_pool_access et le périmètre SMR read-talent-pool. src/Twig/Company/CompanyNavigationExtension.php::getSmrTalentPoolFeature renvoie la destination refondue lorsque l’espace administrateur est affichable. src/Enum/V2/AdminFeaturesEnum.php identifie la même destination.

Une navigation historique et un module nextgen peuvent donc coexister. Les recherches ciblées n’ont identifié aucun contrôleur/entité autonome historique équivalent. Aucune migration, base historique indépendante ou synchronisation de deux bases de viviers n’a été établie.

Contrats API

Le front utilise /api/v2. Les routes sont déclarées dans src/Http/Api/Routing/V2/talent_pool.yaml et talent_pool_user.yaml.

Méthode / chemin	Opération	Permission requise
GET /api/v2/talent-pool	Liste	read-talent-pool
POST /api/v2/talent-pool	Création	create-talent-pool
GET /api/v2/talent-pool/{id}	Détail	read-talent-pool
PUT, PATCH /api/v2/talent-pool/{id}	Modification	update-talent-pool
DELETE /api/v2/talent-pool/{id}	Suppression logique	delete-talent-pool
GET /api/v2/talent-pool/{id}/user	Liste des membres	read-talent-pool
GET /api/v2/talent-pool/{id}/user/{userId}	Détail d’appartenance	read-talent-pool
POST /api/v2/talent-pool/{id}/user	Rattachement	add-user-to-talent-pool
DELETE /api/v2/talent-pool/{id}/user	Détachement	remove-user-from-talent-pool

Les identifiants sont limités aux chiffres par le routage. Les actions de masse addUserToTalentPool / removeUserFromTalentPool résolvent leurs cibles via findUsers. Leurs validateurs étendent DefaultAttachValidator et utilisent MissingUserValidatorTrait. L’examen ne prouve pas tous les statuts de réponse ni le délai d’exécution des actions de masse.

Structures illustratives du client front, avec contenu fictif :

{
  "titles": {"en-US": "Example pool"},
  "descriptions": {"en-US": "Illustrative population for an approved workflow"}
}

Utilisez une langue réellement prise en charge par l’entreprise, sans supposer en-US activé. Les modifications de membres utilisent ce corps, y compris en DELETE :

{"resources": [101, 102]}

Ces identifiants sont fictifs ; n’envoyez pas ces exemples inchangés en production.

Requêtes de liste et traitement des réponses

Le client utilise par défaut page=1&per_page=50 et filters[title][contain] pour le titre. Le tri convertit pool-name en title, members en number_of_members, Owner en created_by et la date en created_at ; dsc devient desc. Le tri serveur par défaut est title ASC, id ASC.

Le routage autorise aussi title equal/contain/start/end, owner equal, status equal et des comparaisons numériques/de date sur l’effectif et la création. Tous ces filtres ne sont pas exposés dans la liste ; ils ne prouvent pas l’existence d’un panneau avancé.

La recherche de membres utilise filters[username][contain], page/per_page et le tri. Le routage expose aussi prénom/nom et creation_type equality. Tri par défaut : firstname ASC, lastname ASC, created_at ASC. Le front présente Added via comme triable sans conversion explicite de creationType dans l’API ; sa compatibilité à l’exécution reste à vérifier.

getTalentPoolList valide le DTO, le convertit et valide le modèle front. En cas d’échec, il journalise puis tente une conversion sans schéma ; il lève une erreur si celle-ci échoue. Détail/création/modification utilisent mapToTalentPool. Les membres utilisent leur schéma DTO et results, item_count, pages. Le repli de la liste peut masquer une dérive : un tableau affiché ne prouve pas la conformité au contrat.

Modèle et validation

Modèle / propriété	Comportement contrôlé
TalentPool extends Group	Table talent_pool ; hérite entreprise, code, lecture seule, effectif, règles, dates, créateur et suppression logique.
Entreprise	Group pointe sur le Setting courant ; unicité code + entreprise.
Traductions	TalentPoolTranslation et comportement traduisible du groupe ; GroupDTO exige les titres et valide les traductions.
Nom / description	Serveur : titre 255, description 1 000 avec assainissement HTML. Création UI : nom 250, description 500 selon constants/form-rules.ts.
Code	DTO optionnel : unicité, codes réservés, assainissement et longueur 1–255 selon le cas. Absent du formulaire de création contrôlé.
Statut	TalentPoolStatus : ACTIVE=1, ARCHIVED=2 ; état initial Active. Aucun cycle complet de statut vérifié dans l’interface.
Propriétaire	Relation obligatoire attribuée à la création ; identifiant/objet en lecture seule dans le DTO. L’interface utilise createdBy, pas cet objet distinct.
TalentPoolUser	Identité composée vivier + utilisateur dans talent_pool_user ; dates, auteur, origine et type d’appartenance.
Défauts d’appartenance	CreationType::API, MembershipType::Static ; le traitement dynamique fournit le type dynamique.
Association de campagne	PeopleReviewCampaignTalentPool relie viviers et campagnes People Review ; cascade de persistance/suppression et suppression des orphelins.

TalentPool::addUser contrôle les identifiants existants avant l’ajout à sa collection. Cela protège cette méthode contre les doublons, sans établir tous les résultats des actions de masse.

TalentPoolUserRepository::findTalentPoolUsers joint vivier/utilisateur, limite l’identifiant du vivier à l’entreprise courante et ajoute les traductions. La visibilité exacte dépend aussi des autorisations communes et de la résolution des cibles. Elle n’a pas été auditée exhaustivement ; la propriété du vivier ne constitue pas une frontière d’autorisation indépendamment vérifiée.

Cycle des requêtes et des membres

1. La liste charge recherche, pagination et tri éventuel. Une ligne ouvre son détail.
2. Le détail charge séparément le vivier et ses membres. La recherche de membres attend 300 ms et réinitialise page et sélection de retrait.
3. La sélection manuelle utilise la liste utilisateur commune avec recherche, statut et managers. Elle exclut localement les identifiants du store de membres chargé, pas tous les membres de toutes les pages. Les effectifs proviennent de la liste amont.
4. useAddMembersWithRules valide le dialogue, poste les identifiants manuels, puis envoie séparément les règles par PATCH si leur enregistrement est demandé. Après succès, il recharge vivier et membres.
5. TalentPoolListener hérite des protections et publie les changements par le listener commun. Les hooks de rattachement/détachement actualisent les effectifs.

Les ajouts manuels et le PATCH des règles sont des requêtes indépendantes successives. Si le PATCH échoue après un ajout réussi, l’interface affiche une erreur sans compensation dans ce composable. Actualisez avant de réessayer.

Règles dynamiques

TalentPoolAddMembers.vue expose l’onglet dynamique avec la permission de modification, transmet context="talent_pool" et suit sa visite. useAddMembersWithRules utilise shouldSaveRules : visiter l’onglet peut entraîner un enregistrement des règles même après retour au manuel. Le composant réinitialise les règles au démontage ainsi qu’à l’ouverture/fermeture du dialogue.

Le chemin actif utilise useSimpleRulesConverter, pas l’ancien convertisseur du même fichier. Il émet {rules: [...]}, conserve les groupes typés, convertit les entiers/valeurs d’existence et retire les valeurs vides. GroupDTO documente des expressions racines AND et applique le validateur de domaine USER. N’importez pas une affirmation générale « sections en OR » depuis d’autres groupes.

AbstractGroupListener::postUpdate compare les règles et publie leurs changements. GroupRuleChangedConsumerCommand::execute restaure le contexte utilisateur et appelle GroupRuleService::ruleGroupChanged. Le service résout le gestionnaire, évalue les correspondances et actualise les membres issus des règles. Des règles vides retirent ces liens ; sinon les correspondances sont ajoutées et les liens issus des règles ne correspondant plus sont retirés. updateGroups(User) réévalue aussi l’utilisateur dans les viviers avec règles.

Le traitement spécial des règles vides transmet zéro à updateNumberOfMembers. Son rapport avec les membres manuels conservés doit être vérifié à l’exécution ; aucun recomptage complet après effacement ne peut être supposé.

Campagnes People Review liées

TalentPoolManager::addUsersToGroup et les méthodes de retrait émettent des événements. TalentPoolListener::onTalentPoolUsersAdded/Removed appelle CampaignTalentPoolSyncService::syncUsersWithCampaigns, qui trouve les campagnes liées et publie les messages de rattachement/détachement avec la source TALENT_POOL. D’autres consommateurs traitent le rattachement/détachement d’un vivier entier.

La route People Review admin est /admin/modules/people-review. L’étape Review assignment d’une campagne propose les sources Manual, Groups et Talent Pool. Le tableau Talent Pool affiche nom du vivier et nombre de membres ; la sélection reste dans l’état d’affectation jusqu’à l’enregistrement de la campagne. useSaveReviewees envoie les identifiants sélectionnés à /api/v2/people-review-campaign/{campaignId}/talent-pool ; la réouverture charge séparément les viviers liés. Les changements de membres se synchronisent de façon asynchrone avec les campagnes liées ; les responsables de campagne doivent relire les participants après une modification du vivier.

Le chemin événementiel est asynchrone. Délais de propagation et effets selon la phase dépendent des consommateurs déployés et de l’état de la campagne.

Permissions, confidentialité et erreurs

Le front contrôle séparément lecture/création/modification/suppression/ajout/retrait ; le routage impose les permissions d’opération. AbstractGroupListener refuse modification/suppression et rattachement/détachement des groupes en lecture seule. preDeleteUsers refuse le retrait direct des membres dynamiques. Masquer une action complète donc les contrôles serveur ; une sélection de masse contenant un membre dynamique peut échouer.

Les listes exposent l’identité et des populations de gestion des talents. Limitez les accès par des rôles approuvés et contrôlez la visibilité avec des comptes représentatifs. Un vivier n’est ni un groupe de visibilité ni une attribution de rôle. Ne diffusez pas corps de requête, exports ou captures dans des diagnostics publics.

Échec / diagnostic	Code et conséquence
Traduction absente/invalide	Contraintes de GroupDTO, titre requis ; limites UI/API différentes.
Utilisateurs de relation absents	Validation commune des cibles manquantes.
Lecture seule / retrait dynamique	Exception de requête incorrecte avant l’opération dans le listener commun.
Échec lecture/modification	Journaux des helpers et notifications traduites ; catalogue HTTP complet non vérifié.
Dérive du contrat	La liste peut s’afficher via le repli ; examiner journaux de validation et structure.
Échec des règles	CatchEvent CRITICAL et rejet du message sur Throwable ; stratégie broker de reprise/file d’échec non examinée.
Mise à jour partielle	L’ajout manuel peut réussir avant l’échec du PATCH ; aucune atomicité entre requêtes.
État ancien des membres/campagnes	Examiner séparément publication/consommation des règles et messages de campagne.

Les journaux sont potentiellement sensibles : le consommateur de règles inclut le corps du message dans le contexte d’échec. Ce guide omet adresses d’infrastructure, secrets et commandes de production.

Dépendances et extensions

La conception dépend d’un accès HTTP nextgen authentifié, des contrôleurs/routages Symfony, des entités/dépôts Doctrine, de la sérialisation localisée, des règles/requêtes communes et de consommateurs de messages opérationnels. Topologie des files et santé des services relèvent du déploiement.

Pour étendre les informations, suivez ensemble DTO, validation, entités/traductions et schémas front. Pour ajouter des champs de règle, utilisez les définitions USER et le constructeur, sans inventer d’identifiants JSON. Préservez événements, effectifs et synchronisation des campagnes. Toute permission doit correspondre à un contrôle API et à un comportement UI.

Sources et limites

Fichiers d’implémentation principaux :

Dépôt	Sources
nextgen-front	src/constants/app-route.ts, src/router/private-routes.ts, src/constants/form-rules.ts ; API, composants liste/création/détail, permissions, stores et composables de src/modules/ModuleConfig/TalentPoolModule/ ; src/modules/ConditionalRules/conditionalRules.composables.ts et useAddMembersWithRules.ts.
nextgen-back	src/Http/Api/Routing/V2/talent_pool.yaml, talent_pool_user.yaml ; src/Domain/V2/Group/DTO/GroupDTO.php ; src/Domain/V2/TalentPool/DTO/TalentPoolDTO.php, Enum/TalentPoolStatus.php ; src/Infrastructure/Persistence/Entity/Group/Group.php, Entity/TalentPool/TalentPool.php, TalentPoolUser.php ; Repository/TalentPool/TalentPoolUserRepository.php ; Validator/TalentPool/ ; Service/TalentPool/TalentPoolManager.php ; Listener/Group/AbstractGroupListener.php, Listener/TalentPool/TalentPoolListener.php ; src/Infrastructure/Service/Rule/Group/GroupRuleService.php, Service/PeopleReview/CampaignTalentPoolSyncService.php ; src/Command/Consumer/Rule/Group/GroupRuleChangedConsumerCommand.php.
legacy	app/config/neobrain/company/definitions.yml ; src/Twig/Company/CompanyNavigationExtension.php ; src/Enum/V2/AdminFeaturesEnum.php ; recherche ciblée Talent Pool/vivier.
aihub	Aucun lien direct vers une implémentation Python Talent Pool dans la recherche du nom. Aucune conclusion IA tirée d’autres fonctionnalités de viviers de candidats.

Documenté dans Confluence : SmartMobility Redesign playbook, PS, v3, 24 septembre 2026. Ce document décrit l’intention de déploiement et l’affectation aux campagnes ; les affirmations d’implémentation restent fondées sur le code. Les pages PS de méthodologie/intégration fournies ont été lues ; la FAQ pointait vers un dossier. Aucune ne fournissait de contrat API Talent Pool.

Les comportements liés au déploiement comprennent la révision, les règles effectives de visibilité, les combinaisons des filtres, l’état de l’éditeur de règles, les compteurs après effacement, les reprises de messages, les effets selon les phases de campagne et la restauration. Confirmez ces contrats avec l’équipe plateforme avant de vous y fier en exploitation.

Périmètre des guides produit

Le guide fonctionnel décrit recherche, population manuelle et dynamique, modification et affectation People Review. Le guide de configuration couvre rôles, prérequis d’activation et administration des populations. L’administration Talent Pool par les collaborateurs ne fait pas partie de ce module ; les routes refondues du vivier sont dans l’espace admin.