Talent Marketplace — documentation technique

Architecture et périmètre

Le parcours RH/manager est rendu par le module legacy Company/EmployeeBookBundle. Nextgen-back expose des métadonnées de champs et les écrans de gestion des accès sont des dépendances transverses. La présence de ces API ne signifie pas que la recherche marketplace est implémentée dans nextgen-front.

Navigateur → Contrôleur legacy → filtres et profils autorisés
                         └→ Client AI Hub → propositions de filtres
                               └→ Mapper → formulaire navigateur

Le préremplissage IA ne constitue pas un classement ni une recherche de profils. Les capacités de suggestion d'opportunités d'AI Hub constituent un autre parcours et ne doivent pas être confondues avec cet endpoint.

Composants et données

Composant	Responsabilité
Company/EmployeeBookBundle/Controller/DefaultController.php	Vue d'annuaire, validation IA et détail collaborateur.
Service/AI/TalentMarketplace/TalentMarketplaceFilterClient.php	Appel HTTP AI Hub et conversion des erreurs.
Service/AI/TalentMarketplace/TalentMarketplaceFilterMapper.php	Liste blanche de filtres affichés et adaptation de la réponse.
TMKPFiltersType	Formulaire de filtres personnalisés du contexte tmkp_bo.
Nextgen-back : Domain/V1/Field/DTO/AbstractFieldDTO.php	Propriétés de visibilité des champs.

Les données de détail reposent notamment sur User, Customer, CompanyEntity et leurs valeurs utilisateur/emploi. Le Setting identifie le client. Les champs personnalisés visibles sont ordonnés par leur position.

Routes et contrôle d'accès

Route legacy	Usage
/company/annuaire/	Page marketplace RH/manager.
POST /company/annuaire/ai-filters	Préremplissage, requête XMLHttpRequest.
/company/annuaire/{id}	Détail en contexte RH/manager.
/plateforme/annuaire/	Annuaire collaborateur (EMPLOYEE_BOOK_FO_ACCESS).
/plateforme/annuaire/{employee}	Détail en contexte collaborateur.

Le préremplissage exige un utilisateur disposant d'une école, le droit EMPLOYEE_BOOK_BO_ACCESS, l'option tmkp_ai_search et un jeton CSRF valide pour cette option. La requête est nettoyée par trim puis contrôlée : 1 à 4 000 caractères.

Le détail vérifie le droit sur le collaborateur ciblé et l'égalité du Setting. Si collaborator_can_change_visibility est activé, getNoProfileVisibility() bloque le profil masqué. Les échecs de consultation conduisent à une redirection.

Carte du code pour les deux personas

Les chemins sont relatifs à la racine du dépôt indiqué. Les correspondances ci-dessous sont Vérifié dans le code — vérifiées dans le code local ; la parité déployée est Non vérifié — non vérifiée.

Responsabilité	Dépôt, chemin et symbole
Montage des deux annuaires	legacy : config/routes.yaml, company_employee_book et customer_employee_book
Page, profil et IA RH/manager	legacy : src/Company/EmployeeBookBundle/Controller/DefaultController.php, indexAction, detailAction, aiFiltersAction
Page et profil collaborateur	legacy : src/Customer/EmployeeBookBundle/Controller/DefaultController.php, indexAction, detailAction
Modules, rôles et tenant	legacy : src/Company/EmployeeBookBundle/Security/EmployeeBookVoter.php, voteOnAttribute, canAccessFo, canAccessBo
Formulaire de filtres partagé	legacy : src/Form/Type/TMKPFiltersType.php, buildForm
Sélection des champs selon le contexte	legacy : src/Company/SwpBundle/Form/Type/SearchCompanyEntityType.php, buildForm
Éditeur historique de champs	legacy : src/Form/Type/CompanyEntityForm.php et src/Company/SwpBundle/Resources/views/List/Forms/form.html.twig
Routes refondues rôles/visibilité	nextgen-front : src/router/private-routes.ts, AppRoute.ROLES et AppRoute.VISIBILITY_GROUPS
Correspondance des métadonnées	nextgen-back : src/Domain/V1/Field/DTO/AbstractFieldDTO.php, annotations MappingProperty
Disponibilité du matching	legacy : src/Service/UserCustomJobMatching/UserCustomJobMatchingService.php, areScoresBySettingAvailable, getActiveSettings

Le schéma décrit responsabilités et dépendances ; il ne prouve ni une topologie réseau ni que toute permission historique soit administrée dans la refonte. Le guide de configuration distingue réglages client et prérequis du cœur de plateforme pour chaque génération.

Implémentation collaborateur et autorisation

Vérifié dans le code : le parcours collaborateur relève de Customer/EmployeeBookBundle, distinct du parcours manager. config/routes.yaml monte ce module sous /plateforme/annuaire. Son fichier de routes définit la page, le détail /{employee} et POST /action/visibility_profile/{user}. Cette dernière action modifie la visibilité du profil et exige XMLHttpRequest ; elle est distincte de la recherche et n'a pas été appelée pendant l'inspection.

Customer/EmployeeBookBundle/Controller/DefaultController::indexAction contrôle EMPLOYEE_BOOK_FO_ACCESS et redirige vers l'accueil personnel en cas de refus. Il construit TMKPFiltersType avec filter_type = tmkp_fo, tenant et langue. Le contrôleur manager utilise tmkp_bo. SearchCompanyEntityType::buildForm sélectionne les définitions selon filterTmkpFo / filterTmkpBo, distincts des réglages généraux filterFo / filterBo.

EmployeeBookVoter::voteOnAttribute contrôle le tenant pour un utilisateur cible. L'accès collaborateur repose sur annuaire. L'accès RH/manager suit la branche haut potentiel ou celle d'annuaire_bo, avec règles d'école principale/manager actif et rôle ; voir canAccessBo, hasHighPotentialAccess, hasEmployeeBookBOAccess. La bascule d'espace ne contourne pas ces contrôles.

Le detailAction collaborateur vérifie EMPLOYEE_BOOK_FO_ACCESS pour la cible, charge les champs non standard avec isVisibleOnTalentMarketplaceDetailedProfile = true, les trie par position puis rend le modèle collaborateur. Le détail manager utilise la propriété BO et les contrôles décrits plus haut. L'autorisation complète des requêtes de résultats, au-delà des contrôleurs et du voter, reste Non vérifié dans cette revue.

Aucune route/action de préremplissage IA n'a été trouvée dans les routes et contrôleur collaborateur inspectés. Le contrat IA manager ci-dessous ne doit pas être présenté comme un endpoint collaborateur.

Données de matching et frontières plateforme

Vérifié dans le code : le matching d'offres manager exige job_matching_bo, celui des collaborateurs job_matching_fo. Les deux vérifient aussi UserCustomJobMatchingService::areScoresBySettingAvailable(). Le contrôleur collaborateur filtre les offres selon leur validité avant de les passer au modèle.

areScoresBySettingAvailable() vérifie la présence du tenant dans getActiveSettings(), qui énumère les tables de matching spécifiques aux tenants. Cette méthode ne vérifie pas la complétude des lignes, la fraîcheur ni la qualité métier des scores. Stockage, production des scores et activation constituent des sujets distincts. Le provisionnement relève de la plateforme ; aucune modification manuelle de base n'est prescrite.

AbstractFieldDTO associe les filtres collaborateur/manager à filterTmkpFo / filterTmkpBo, et les visibilités de détail à isVisibleOnTalentMarketplaceDetailedProfile / isVisibleOnTalentMarketplaceDetailedProfileBo. Les initialisations à false sont celles du DTO ; elles ne prouvent ni les valeurs persistées ni la priorité entre générations.

Échange avec AI Hub

Le serveur envoie une requête à :

POST {AI_HUB_BASE_URL}/api/v1/talent-intelligence/talent-marketplace/filters
Accept: application/json
X-API-Key: <clé serveur>
Content-Type: application/json

Structure illustrative ; les clés disponibles sont calculées à partir des filtres affichés :

{
  "client_id": "123",
  "query": "Je cherche un RH mobile",
  "locale": "fr_FR",
  "filters": [
    {"key": "job"},
    {"key": "internal_mobility"},
    {"key": "company_entity", "company_entity_id": 456}
  ]
}

La locale est optionnelle et doit correspondre au format de langue accepté, par exemple fr ou fr_FR. Le client exige HTTP 200 et un tableau filters. Le mapper conserve les filtres autorisés et les attributs key, company_entity_id, kind, values, value, start, end, selon leur type. Les exemples ne constituent pas une spécification complète de chaque valeur métier.

Le navigateur reçoit une enveloppe {"filters": [...]} issue du mapper. L'utilisateur confirme ensuite la recherche.

Erreurs et limites

Cas	Réponse du préremplissage
Droit ou activation manquant	403, forbidden.
CSRF invalide	403, invalid_token.
Requête vide/trop longue	400, invalid_query.
Configuration manquante, réseau ou réponse invalide	502, unavailable.
Timeout	504, unavailable.

Le client HTTP fixe max_duration à 20 secondes. Ce délai ne constitue pas un engagement de performance de toute la recherche. Une erreur ne doit pas être assimilée à une absence de profils.

Configuration et exploitation

• AI_HUB_BASE_URL : URL serveur AI Hub.
• AI_HUB_API_KEY : secret transmis dans l'en-tête ; jamais dans le navigateur.
• tmkp_ai_search : activation métier.
• job_matching_bo : pris en compte avec la disponibilité des scores pour proposer le matching par offre.
• Préfixe de journal : [TALENT MARKETPLACE] AI filters prefill - , avec contexte setting_id.

Critères de recette technique

1. Vérifier les refus d'accès, CSRF et bornes de longueur, dont 4 000 et 4 001 caractères.
2. Vérifier la séparation des clients et les profils masqués.
3. Vérifier les indicateurs de visibilité dans chacun des contextes.
4. Vérifier les filtres personnalisés et les suggestions hors liste blanche.
5. Simuler HTTP 200 valide, réponse sans tableau, erreur distante et timeout.
6. Vérifier que le préremplissage n'exécute pas la recherche et que le parcours manuel reste utilisable.

Contraintes et hors périmètre

Le guide couvre les interfaces lues dans le code, pas une garantie d'activation universelle chez chaque client. Les coûts IA, limites de débit et SLA ne sont pas définis par ces composants. Les agents de suggestion d'opportunités et les workflows de candidature sont hors périmètre.

Requête navigateur et cycle des filtres

Vérifié dans le code — vérifié dans le code : le navigateur transmet les paramètres de formulaire query et _token par XMLHttpRequest à la route IA historique. Le contrôleur nettoie la description, valide accès et CSRF, puis détermine les filtres disponibles selon le tenant et le formulaire. Le JSON AI Hub décrit plus haut appartient à l'échange serveur à serveur.

Sans proposition utilisable, les filtres courants sont conservés. Avec des propositions utilisables, ils sont réinitialisés puis remplacés. Le navigateur ne lance pas la recherche de collaborateurs. Des descriptions successives remplacent donc les critères. Le mapper identifie les champs personnalisés par le couple key / company_entity_id, écarte les filtres non demandés et enrichit les compétences avec leurs informations d'affichage propres au tenant.

Dépendances, confidentialité et extensions

Vérifié dans le code : le préremplissage utilise le client HTTP Symfony historique, la configuration du tenant, les services d'autorisation, le formulaire et le script navigateur. aiFiltersAction ne déclenche ni traitement en arrière-plan ni écriture de profil. L'action de consultation du profil est distincte ; cette observation ne décrit pas tous ses effets.

La description, l'identifiant du tenant, la langue éventuelle et les descripteurs des filtres sont transmis à AI Hub. Le serveur construit ce contenu sans y joindre les profils des résultats. Décrire des critères professionnels et éviter les données personnelles ou confidentielles dans la saisie libre. Non vérifié — non vérifié : fournisseur IA déployé, conservation, localisation, quotas et politique de journalisation distante. Ces points restent à valider avant activation client.

Pour ajouter un filtre, examiner ensemble le formulaire/modèle, BO_FILTER_SWITCHES ou le descripteur personnalisé, toFrontPayload et applyFilter dans le navigateur. Confirmer le support distant avant d'étendre le contrat. Les tests disponibles dans tests/Unit/Service/AI/TalentMarketplace/ couvrent le client et le mapper ; ils n'ont pas été exécutés pour cette mise à jour documentaire.

Frontière entre historique, refonte et service distant

Vérifié dans le code : ce parcours relève de Company/EmployeeBookBundle historique. Les métadonnées nextgen-back correspondent aux contrôles de champs historiques ; l'administration de visibilité nextgen-front ne prouve pas un moteur de recherche équivalent. Non vérifié : parcours de recherche refondu complet, migration et compatibilité des versions déployées.

Le chemin d'endpoint AI Hub est Vérifié dans le code dans le client historique. Aucune implémentation Talent Marketplace correspondante n'a été trouvée dans le répertoire local aihub/src. L'exemple décrit donc le contrat attendu par l'appelant ; les validations distantes, les schémas métier des valeurs retournées et la disponibilité en production restent Non vérifié.

Sources et limites

Revue du 15 octobre 2026 à partir des fichiers locaux, qui peuvent inclure des modifications non commitées.

Preuve	Source relative à la racine du dépôt
Vérifié dans le code : routes et validation	legacy : src/Company/EmployeeBookBundle/Resources/config/routing.yml, src/Company/EmployeeBookBundle/Controller/DefaultController.php
Vérifié dans le code : intégration et filtres autorisés	legacy : src/Service/AI/TalentMarketplace/TalentMarketplaceFilterClient.php et TalentMarketplaceFilterMapper.php dans le même répertoire
Vérifié dans le code : remplacement des critères	legacy : web/assets_profile/tmkp-ai-search.js
Vérifié dans le code : métadonnées des champs	nextgen-back : src/Domain/V1/Field/DTO/AbstractFieldDTO.php
Vérifié dans le code : administration de visibilité	nextgen-front : src/modules/Users/VisibilityGroups/
Vérifié dans le code : routes et accès collaborateur	legacy : config/routes.yaml, src/Customer/EmployeeBookBundle/Resources/config/routing.yml, src/Customer/EmployeeBookBundle/Controller/DefaultController.php, src/Company/EmployeeBookBundle/Security/EmployeeBookVoter.php
Non vérifié : implémentation distante	Aucun fichier correspondant trouvé dans aihub/src local

Observé dans l’application — observé dans l'application : le guide fonctionnel rapporte la recherche/profil manager et la redirection de l'annuaire collaborateur sur smartmobility.io ; ces observations ne prouvent pas la parité du code. Le guide de configuration rapporte les écrans administrateur. Aucune exécution IA de bout en bout n'a été réalisée. Les erreurs documentées correspondent au comportement vérifié de l'appelant. Les critères d'acceptation décrivent des vérifications à réaliser, pas des tests d'exécution réussis. L'activation du tenant et la chaîne complète d'autorisation des résultats restent à valider dans l'application.

Voir la configuration et le guide fonctionnel.

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 : même compte fourni dans les espaces manager et personnel ; contrôles manager, listes contrat/matching, mode haut potentiel, recherche, pagination et profil inspectés. Navigation collaborateur inspectée ; accès direct à l'annuaire redirigé vers l'accueil. Les écrans administrateur de visibilité et le dialogue historique alimentent le guide de configuration.
• Vérifié dans le code : dans legacy, src/Company/EmployeeBookBundle/Controller/DefaultController.php, src/Customer/EmployeeBookBundle/Controller/DefaultController.php, leurs modèles Resources/views/Default/, src/Company/EmployeeBookBundle/Security/EmployeeBookVoter.php, src/Form/Type/TMKPFiltersType.php et web/assets_profile/tmkp-ai-search.js distinguent contextes, contrôles et IA conditionnelle.
• Vérifié dans le code : nextgen-back src/Domain/V1/Field/DTO/AbstractFieldDTO.php et nextgen-front src/modules/Users/VisibilityGroups/ décrivent métadonnées et administration. Les quatre dépôts sont présents ; les fichiers locaux ne prouvent pas la parité du déploiement.
• Inferred — déduit : les scénarios illustratifs proposent un usage des contrôles, sans garantir de profil correspondant.
• Non vérifié : recherche/résultats/profil collaborateur, IA en direct, scores d'offres, logique complète ET/OU et de tri, tous les contrôles optionnels et toutes les branches d'autorisation des résultats. Les captures des contrôles collaborateur ou IA indisponibles sont absentes. Les données identifiantes des fiches de résultats sont masquées ; les profils détaillés complets ne sont pas illustrés pour exclure les informations personnelles.

Vérification des parcours du 26 octobre 2026

Observé dans l’application : PS Testing 2026, Jim Carter. Annuaires est désormais présent dans l’espace personnel. La recherche sur Jim Carter n’a renvoyé aucun résultat ; aucune fiche d’un autre collaborateur ni résultat IA inspecté. L’ancienne absence d’entrée décrit une session historique, pas le menu actuel.