Analytique des candidats

A1Architecture : où il se situe dans la plateforme

Analytique des candidats is a first-class module of the Gestion des clients et du pipeline suite inside the authenticated Expertini ATS workspace. La plateforme est délibérément rendue côté serveur : chaque vue est préparée par le serveur d'application et livrée sous forme de code HTML complet, sans cadre côté client, sans scripts de CDN tiers et sans pipeline de compilation entre les données et la page. Ce qui s'affiche est ce que le serveur a calculé — la propriété qui rend l'interface vérifiable.

Toute la persistance repose sur un unique magasin de documents natif de recherche; chaque requête comporte l'identifiant de l'organisation en tant que filtre obligatoire à la couche de requête la plus basse. L'isolation des locataires est par conséquent structurelle — une propriété de la manière dont chaque requête est composée — plutôt qu'une politique qui repose sur le code de l'application se souvenant d'effectuer la vérification.

Availability is governed by the platform's tool registry: this tool is registered from the Growth plan, and access is enforced server-side by the registry gate on every request — never by hiding a button. Plans also carry a monthly distinct-tool quota (3 / 5 / 15 / 30 / 45 across Trial→Business, unlimited on Enterprise), counted at the same chokepoint. The pricing page states both honestly: what is available, and how much of it the month includes.

A2Modèle de données et carte des dépendances

In production the tool reads and writes the candidate database (ats_candidates), pipeline applications (ats_applications). Documents are plain, explicitly-mapped fields — mappings are provisioned ahead of first write, so term filters and aggregations behave deterministically instead of depending on inferred types.

Chaque ouverture distincte est consignée dans le journal d'activité des outils — et ce journal, et non un système d'analyse parallèle, est ce que la section Rapports agrège. Les chiffres d'utilisation que vous voyez sont ceux que la plateforme a réellement enregistrés.

Tout ce qui sort du chemin de la requête — diffusion de notifications, livraison de webhooks, journalisation des activités, courriels — s'exécute dans des threads d'arrière-plan indépendants. Un point de terminaison externe lent ne peut jamais bloquer l'interface, et un effet secondaire échoué est consigné dans les journaux plutôt que d'être relancé silencieusement, ce qui créerait des incohérences.

A3Considérations opérationnelles

Les paramètres au niveau de l'organisation, les actions destructrices et les connexions sont réservés aux rôles de propriétaire et d'administrateur ; les recruteurs exploitent l'outil sur les dossiers qu'ils sont autorisés à voir. Les changements de rôle s'appliquent lors de la requête suivante — l'application des règles s'effectue au niveau de la route, et non dans le menu.

Les échecs sont mis en evidence, et non étouffés : la validation côté serveur renvoie le champ exact et le motif, les erreurs des fournisseurs sont citées textuellement lorsque des intégrations sont impliquées, et chaque écriture confirme l'opération ou en signale l'échec. Les exportations sont régénérées sur demande plutôt que d'être mises en cache — un rapport que vous téléchargez reflète la base de données au moment exact où vous l'avez demandé, et non l'instantané de la veille.

Tout ce que vous écrivez vous appartient : les exportations CSV et l'application d'exportation de données couvrent les mêmes entrepôts que ceux lus par le produit lui-même. La sortie est aussi ouverte que l'entrée — par conception, et non par concession.

A4Interaction contract

L'interface suit la convention de recherche et de sélection de la plateforme : tout champ désignant un enregistrement réel (un candidat, un client ou un emploi) est un sélecteur de type à la recherche portant sur des données en direct, jamais une chaîne saisie librement, ce qui permet de préserver la fiabilité des historiques d'activité et de la déduplication. Les choix statiques sont des listes déroulantes de filtrage à la frappe plutôt que des menus natifs, et les transitions d'état fournissent des commentaires explicites : les confirmations du serveur s'affichent sous forme de bannières éphémères, les erreurs de validation nomment le champ exact, et rien n'est affiché comme étant terminé si le serveur ne l'a pas confirmé.

Le schéma filaire et le flux ci-dessous documentent le contrat structurel de l'interface — les panneaux existants, l'ordre des états et le déroulement à chaque limite — plutôt que les pixels. La mise en page est composée à l'aide de grilles CSS et de boîtes flexibles (flexbox) natives et s'adapte d'un grand écran de bureau à une colonne unique sans vues mobiles distinctes.