Journal d'activité quotidien

A1Architecture : son positionnement dans la plateforme

Journal d'activité quotidien is a first-class module of the Productivité et bien-être des recruteurs suite inside the authenticated Expertini ATS workspace. La plateforme fait délibérément l'objet d'un rendu côté serveur : chaque vue est préparée par le serveur applicatif et transmise sous forme de HTML complet, sans framework côté client, sans scripts CDN tiers et sans pipeline de build entre les données et la page. Ce qui s'affiche correspond exactement à ce que le serveur a calculé — une caractéristique qui rend l'interface pleinement auditable.

L'ensemble de la persistance repose sur un magasin de documents natif pour la recherche unique ; chaque requête intègre l'identifiant de l'organisation comme filtre obligatoire au niveau de requête le plus bas. L'isolation des environnements clients est donc structurelle — propre à la composition même de chaque requête — plutôt qu'une règle dépendant de vérifications dans le code applicatif.

Availability is governed by the platform's tool registry: this tool is registered from the Starter 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 cartographie des dépendances

In production the tool reads and writes ats_planner_logs, job requisitions (ats_jobs), 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 c'est ce journal, et non un système d'analyse parallèle, que la section Rapports agrège. Les chiffres d'utilisation que vous voyez correspondent aux données réellement enregistrées par la plateforme.

Tout ce qui sort du circuit principal de la requête — diffusion des notifications, transmission des webhooks, journalisation des activités, e-mails — s'exécute dans des threads d'arrière-plan asynchrones. Un point de terminaison externe lent ne peut jamais bloquer l'interface, et un effet secondaire défaillant est consigné dans les journaux plutôt que réessayé silencieusement au risque d'incohérences.

A3Considérations opérationnelles

Les paramètres au niveau de l'organisation, les actions irréversibles et les connexions sont réservés aux rôles de propriétaire et d'administrateur ; les recruteurs utilisent l'outil sur les dossiers auxquels ils ont accès. Les modifications de rôle s'appliquent dès la requête suivante — le contrôle s'effectue au niveau de la route, pas du menu.

Les échecs sont mis en évidence et non masqués : la validation côté serveur renvoie le champ exact et la raison, les erreurs des fournisseurs sont citées textuellement lorsque des intégrations sont impliquées, et chaque écriture est soit confirmée, soit signalée. Les exports sont régénérés à la demande plutôt que mis en cache — un rapport que vous téléchargez reflète l'état des données au moment précis de votre demande, et non l'instantané de la veille au soir.

Tout ce qui est enregistré vous appartient : les exports CSV et l'application Data Export couvrent les mêmes données que celles lues par la plateforme. La sortie est aussi libre que l'entrée — par conception, non par concession.

A4Interaction contract

L'interface respecte la convention de recherche et sélection de la plateforme : tout champ désignant un enregistrement réel — un candidat, un client ou une offre — est un sélecteur avec saisie semi-automatique basé sur des données en direct, jamais une chaîne en texte libre, ce qui garantit la fiabilité du suivi d'activité et de la déduplication. Les choix statiques sont des menus combinés filtrables à la saisie plutôt que des listes déroulantes natives, et les changements d'état fournissent un retour explicite : les confirmations du serveur apparaissent sous forme de notifications toast, les erreurs de validation précisent le champ exact, et rien n'est affiché comme terminé tant que le serveur ne l'a pas confirmé.

Le wireframe et le flux ci-dessous décrivent le contrat structurel de l'interface — les volets existants, l'ordre de succession des états et ce qui se produit à chaque étape — plutôt que de simples pixels. La mise en page est structurée à l'aide des modules CSS grid et flexbox natifs et s'adapte d'un affichage grand écran à une colonne unique sans vues mobiles distinctes.