PD-3 — Infrastructure de files de tâches asynchrones (Redis / BullMQ)¶

Epic : PD-193 INFRA

1. Objectif¶

Définir les exigences contractuelles relatives à la mise à disposition d’une infrastructure de gestion de files de tâches asynchrones destinée à supporter les traitements applicatifs utilisant BullMQ.

La présente spécification vise à garantir la fiabilité, la persistance, la visibilité et l’exploitabilité de ces traitements, en cohérence avec les exigences de robustesse, de continuité de service et de confiance utilisateur du produit ProbatioVault.

2. Périmètre / Hors périmètre¶

Inclus¶

Mise à disposition d’un service de gestion de files de tâches asynchrones supportant BullMQ.
Persistance de l’état des tâches (en attente, en cours, exécutées, en échec).
Tolérance aux incidents affectant un composant isolé du service.
Détection et signalement explicites de toute anomalie affectant l’exécution des tâches.
Supervision opérationnelle du service (état, activité, anomalies).

Exclu¶

Définition de l’architecture applicative consommatrice des files.
Implémentation de la logique métier des tâches.
Choix d’un fournisseur cloud, d’un hébergeur ou d’un mode de déploiement.
Optimisation fine des performances applicatives.

3. Définitions¶

Terme	Définition
Tâche asynchrone	Unité de travail exécutée en dehors du flux synchrone d’une requête utilisateur
File de tâches	Mécanisme permettant l’ordonnancement et l’exécution différée de tâches
Perte de tâche	Situation où une tâche n’est ni exécutée ni identifiable comme non exécutée
Incident	Tout dysfonctionnement affectant l’exécution, l’état ou la visibilité d’une tâche

4. Invariants (non négociables)¶

ID	Règle	Justification
INV-01	Aucune tâche ne doit être perdue silencieusement	Préserver la confiance utilisateur et la complétude des traitements
INV-02	Toute tâche doit avoir un état observable à tout moment	Éviter toute ambiguïté sur l’exécution
INV-03	Toutes les tâches ont un niveau de criticité identique	Exigence uniforme de fiabilité
INV-04	Tout incident est considéré comme bloquant	Absence d’incident tolérable
INV-05	Le rétablissement du fonctionnement nominal doit être automatique	Continuité de service
INV-06	Les garanties sont identiques à court, moyen et long terme	Cohérence des exigences
INV-07	Le service doit rester exploitable sans dépendance à des personnes clés	Robustesse organisationnelle

5. Flux nominaux¶

FN-01 — Traitement nominal d’une tâche¶

Une tâche est enregistrée dans une file.
La tâche est exécutée.
L’état final de la tâche est persistant et observable.

FN-02 — Reprise après interruption¶

Une interruption survient pendant l’exécution.
Le service rétablit automatiquement un fonctionnement nominal.
Les tâches non finalisées restent identifiables et traitables.

6. Cas d’erreur¶

ID	Situation	Comportement attendu
ERR-01	Interruption du service	Aucune perte de tâche, reprise automatique
ERR-02	Échec d’exécution d’une tâche	État explicite et détectable
ERR-03	Perte exceptionnelle liée à un cas de force majeure	Information explicite indiquant une exécution incomplète

7. Critères d’acceptation (testables)¶

ID	Critère	Observable
CA-01	Aucune tâche n’est perdue silencieusement	Audit des états persistés
CA-02	L’état de chaque tâche est consultable	Interface ou métrique observable
CA-03	Toute anomalie est détectable	Signal explicite d’incident
CA-04	Le service se rétablit automatiquement après interruption	Reprise sans action humaine
CA-05	Les procédures manuelles sont documentées et exécutables par un non spécialiste	Documentation vérifiable

8. Scénarios de test (Given / When / Then)¶

TC-01 — Exécution nominale¶

Given une tâche enregistrée
When le service fonctionne normalement
Then la tâche est exécutée et son état final est observable

TC-02 — Interruption et reprise¶

Given une tâche en cours d’exécution
When une interruption survient
Then la tâche reste identifiable et le service se rétablit automatiquement

9. Hypothèses explicites¶

ID	Hypothèse	Impact si faux
H-01	Les traitements applicatifs dépendent d’un mécanisme de files asynchrones	Remise en cause du besoin
H-02	La volumétrie cible est atteignable sans remise en cause structurelle	Refonte nécessaire

10. Points à clarifier¶

Définition précise de la volumétrie cible.
Modalités exactes de restitution de l’information utilisateur.
Liste exhaustive des processus applicatifs consommateurs.

Références¶

Epic : PD-193 INFRA
JIRA : PD-3
Repos concernés : infra / backend