Cycle de vie d’une candidature
Traduction
Cette page est une traduction de la version anglaise, qui fait foi.
Ce document définit le cycle de vie d’une Application dans Balyze.
Il décrit les états possibles d’une candidature, les transitions autorisées entre ces états, ainsi que les principes régissant les changements d’état.
Objectif du cycle de vie
Le cycle de vie d’une candidature existe afin de :
- représenter la progression réelle d’une candidature
- imposer des transitions d’état claires
- éviter les états incohérents ou ambigus
- permettre des extensions futures sans casser les règles existantes
Le cycle de vie est explicite, fini et volontairement contraint.
États de la candidature
À ce stade, une Application peut se trouver dans l’un des états suivants :
Draft
État initial d’une candidature.
Caractéristiques :
- la candidature n’a pas encore été soumise
- les informations structurelles peuvent encore être ajustées indirectement
- aucun timestamp de soumission n’est défini
- la candidature n’est pas considérée comme active
Cet état est temporaire et interne à l’utilisateur.
Submitted
La candidature a été formellement soumise.
Caractéristiques :
- le timestamp de soumission (
applied_at) est défini - la candidature devient historiquement pertinente
- les données structurelles sont figées
- les données contextuelles restent éditables
Une fois soumise, la candidature représente une intention à un instant donné.
In progress
La candidature est en cours de traitement.
Cet état peut représenter :
- des échanges en cours
- des entretiens
- des relances
- des périodes d’attente
La candidature reste éditable uniquement dans des limites contextuelles prédéfinies.
Rejected
Le processus de candidature s’est terminé de manière défavorable.
Caractéristiques :
- aucune progression supplémentaire n’est attendue
- la candidature est considérée comme clôturée
- les données historiques doivent rester intactes
Il s’agit d’un état terminal.
Accepted
Le processus de candidature s’est terminé avec succès.
Caractéristiques :
- la candidature est considérée comme finalisée
- aucune transition de cycle de vie supplémentaire n’est attendue
- la candidature reste accessible à des fins de consultation historique
Il s’agit d’un état terminal.
Transitions autorisées
Le cycle de vie suit un graphe de transitions strictement contrôlé :
draft→submittedsubmitted→in_progressin_progress→rejectedin_progress→accepted
Les transitions sont volontairement unidirectionnelles.
Transitions interdites
Les transitions suivantes sont explicitement interdites :
- retour à l’état
draftaprès soumission - passage direct de
draftà un état terminal - modification des données structurelles après soumission
- réouverture d’une candidature rejetée ou acceptée
Ces restrictions permettent de préserver la cohérence historique et de simplifier les règles métier.
Interaction entre éditabilité et cycle de vie
Les transitions du cycle de vie influencent directement les données pouvant être modifiées.
Principes clés :
- les données structurelles sont figées après la soumission
- les données contextuelles restent éditables tout au long du cycle de vie
- les changements d’état sont toujours des actions explicites
Les règles détaillées d’éditabilité sont documentées séparément.
Stratégie d’application des règles
Les règles du cycle de vie sont appliquées au niveau des services métier.
- les contrôleurs n’implémentent aucune logique de cycle de vie
- les modèles n’orchestrent pas les transitions
- les policies gèrent l’autorisation, pas la validité du cycle de vie
Cela garantit une application cohérente des règles, quel que soit le point d’entrée.
Éléments hors périmètre
Les aspects suivants sont volontairement exclus à ce stade :
- transitions automatiques
- changements d’état basés sur le temps
- synchronisation avec des systèmes externes
- extensions du cycle de vie pilotées par l’analytics
Ces sujets pourront être réévalués dans des versions ultérieures.
Justification
Ce cycle de vie privilégie la clarté et la prévisibilité plutôt que la flexibilité.
En limitant les transitions et en figeant rapidement les données structurelles, le système :
- évite les états de candidature ambigus
- préserve l’exactitude historique
- réduit la complexité à long terme
Les évolutions futures pourront s’appuyer sur cette base sans remettre en cause les hypothèses existantes.