Les demandes de congés traitées manuellement prennent 3+ jours et créent des erreurs de paie — chaque mois, la finance lance des régularisations parce qu'un solde de congés était faux ou une déduction mal saisie. Sans workflow structuré, les demandes arrivent par email ou chat, le manager vérifie les conflits sur un tableur partagé, RH contrôle le solde dans le SIRH, et la paie est notifiée par un énième email.

L'angle conformité est réel aussi : autorisations de congés manquantes, absences non documentées et reports expirés créent une exposition juridique lors d'une inspection du travail.

La demande de congé est soumise via le portail self-service avec champs exacts : employee_id (lookup, auto-rempli), leave_type (select : Paid-leave/RTT/Unpaid/Sick/Family/Overtime-recovery), start_date (date), end_date (date), half_day_start (booléen), half_day_end (booléen), comment (textarea), attachment (upload fichier, ex. arrêt maladie), requested_days (nombre, auto-calculé depuis les dates).

Le workflow est structuré en arbre de décision avec 3 branches (rejet-solde, signalement-conflit, fast-track) après l'Étape 2, et 6 étapes de bout en bout. Chaque action est ajoutée à la sous-table d'audit timeline_leave.

• Étape 1 (Start — employé) : l'employé soumet la demande via le portail self-service avec leave_type, start_date, end_date et comment.

• Étape 2 (sql-query — vérification solde) : le module sql-query lit le solde de congés de l'employé depuis la base SIRH et compare requested_days au solde restant pour leave_type. Sous-branche A (rejet-solde) : si requested_days dépasse le solde restant, le workflow rejette automatiquement et envoie un email à l'employé avec le détail du solde. Sous-branche B (signalement-conflit) : le copilote IA scanne le calendrier d'équipe pour les absences chevauchantes (même équipe, mêmes dates, risque de quorum) et les signale au manager. Sous-branche C (fast-track) : si leave_type est Sick et qu'un arrêt maladie est attaché, la demande contourne la validation manager et route directement vers la notification paie.

• Étape 3 (email — validation manager) : pour les branches B et C-non-sick, le workflow envoie un email au manager avec la demande, le statut du solde et les conflits calendrier équipe ; le manager approuve, rejette ou demande une modification depuis le lien email. Escalade : si aucune décision sous 48h, le workflow envoie un email au manager de niveau supérieur.

• Étape 4 (email — notification paie) : à l'approbation, le workflow envoie un email à la paie avec leave_type, dates et déduction pour que le prochain bulletin soit exact.

• Étape 5 (usePDF — autorisation de congé) : le congé approuvé est généré en PDF d'autorisation de congé signé via usePDF avec nom employé, leave_type, dates, requested_days et chaîne de validation.

• Étape 6 (Mise à jour calendrier) : le workflow met à jour le calendrier d'équipe et le message d'absence du bureau de l'employé.

Les équipes qui déploient la gestion des congés Utilyx réduisent le temps demande-décision de 3+ jours à moins de 4 heures, éliminent les régularisations de paie sur les soldes, et atteignent 100% de conformité documentaire pour les inspections du travail.

Le vocabulaire RHSD (solde de congés, RTT, calendrier d'équipe, quorum, autorisation de congé, usePDF, useArchive) est natif sur la plateforme, le copilote IA propose donc le bon schéma directement — et le designer visuel no-code permet à tout analyste RH d'ajuster les seuils d'approbation et les règles d'escalade sans coder.