Moteur de règles

Les règles de temps de travail (code du travail, CCN-66) que le moteur évalue automatiquement contre un planning : au-delà de quel seuil une durée quotidienne, une amplitude ou un repos déclenche une alerte, et quel niveau de gravité elle porte. Et les groupes de conflit, qui décident laquelle retenir quand plusieurs règles se déclenchent sur la même occurrence.

Pour qui : un super-utilisateur, ou un compte avec le statut équipe et les permissions Django rules_engine.change_rule / rules_engine.change_hitgroup · Où : section Moteur de règles du menu

Écrans couverts : Règles, Groupes de conflit

Les colonnes, filtres et droits de chacun sont dans la référence des écrans.

Comprendre

• Une règle vérifie un seul type de contrôle (sa famille, par exemple « durée effective quotidienne maximale »). Ce que vérifie chaque famille et ce qu'attend chacun de ses paramètres est décrit en langage clair, famille par famille, dans backend/docs/rules-engine-parametres.md — c'est le document à ouvrir avant de créer ou de modifier une règle.
• La sévérité (information, alerte, alerte forte, bloquant) dit ce qui se passe quand la règle se déclenche. Une alerte forte peut être outrepassée moyennant un motif obligatoire ; un blocage ne peut pas l'être.
• Un groupe de conflit ne sert que quand deux règles peuvent porter sur la même occurrence et qu'une seule doit compter : la politique du groupe décide de garder la plus sévère plutôt que de cumuler les deux.
• « Valider le pack de règles actives », sur la liste des règles, ne modifie rien : c'est un contrôle en lecture qui construit l'ensemble des règles actives et signale ce qu'une règle seule ne peut pas révéler (deux règles qui alimentent le même compteur, un statut jamais produit par aucune règle active...). Une règle enregistrée seule est déjà vérifiée à l'enregistrement.
• Ces règles ne sont pas encore appliquées automatiquement à un planning réel : l'écran de planification qui les déclencherait n'existe pas encore (voir « Not built yet » dans AGENTS.md). Aujourd'hui, seule la commande technique evaluate_shift permet de tester une règle contre un service donné.

Créer une règle

1. Ouvrez Règles et cliquez sur Ajouter règle.

2. Choisissez la famille : le type de contrôle à appliquer. Un encart apparaît sous Paramètres avec les paramètres attendus par cette famille.

3. Renseignez Paramètres au format attendu par la famille choisie — reportez-vous à backend/docs/rules-engine-parametres.md pour le sens de chacun et ses valeurs possibles.

4. Renseignez Population si la règle ne s'applique pas à tout le monde (laissez vide sinon).

5. Choisissez la sévérité (effect) et, si une dérogation est possible, cochez si un motif est requis.

6. Si la règle doit céder la priorité à une autre sur la même occurrence, rattachez-la à un groupe de conflit existant, ou créez-le d'abord dans Groupes de conflit.

7. Renseignez le message utilisateur, l'action requise et la note de traçabilité : c'est ce qui s'affichera à la personne concernée quand la règle se déclenche — le moteur ne les lit jamais lui-même.

8. Enregistrez.

   ✅ Vous devriez voir : la règle apparaît dans la liste, avec sa famille, sa sévérité et son groupe de conflit.

Points d'attention

• Une famille inconnue, un paramètre manquant ou hors bornes, ou une période de validité vide sont refusés à l'enregistrement, avec le message correspondant sur le champ concerné.
• Désactiver une règle (active décoché) la retire du pack évalué sans la supprimer — l'historique et le paramétrage restent visibles.
• Un groupe de conflit qui n'est plus référencé par aucune règle reste dans la liste : rien ne le retire automatiquement.