Conception d'un système de demandes de congés simplifiée : définissez les politiques, gérez l'acquisition, routage des approbations manager et maintenez des calendriers exacts sans workflows compliqués.
Les gens s'attendent à ce qu'une demande de congé ressemble à la réservation d'une réunion : choisir des dates, voir son solde, obtenir un oui ou un non clair, et que cela apparaisse partout où c'est nécessaire. Quand ce n'est pas le cas, les équipes reviennent au « envoie-moi un message », et le système devient une tâche de tenue de registre plutôt qu'un outil fiable.
Les demandes se bloquent généralement dans les passations : un fil d'e-mails qui n'atteint pas le bon manager, un tableau que personne ne met à jour, ou une approbation par chat impossible à auditer ensuite. L'employé pense être couvert, le manager pense que les RH s'en occupent, et les RH découvrent au moment de la paie que le solde est faux.
Le vrai objectif de la conception d'un système de demandes de congés est ennuyeux mais important : des soldes corrects, des approbations claires et une source unique de vérité. Si votre solde est exact mais que les approbations sont floues, les managers continueront de demander « Ai-je déjà approuvé ceci ? » Si les approbations sont parfaites mais que le calendrier est erroné, les équipes se retrouvent tout de même en double réservation.
Quatre groupes s'appuient sur le même flux, mais pour des raisons différentes :
Un « workflow lisible » signifie que vous pouvez regarder les étapes et les expliquer en langage simple : qu'est-ce qui déclenche la demande, qui approuve, que se passe-t-il en cas de rejet, et qu'est-ce qui est écrit en retour (solde, statut, calendrier). Si vous ne pouvez pas l'expliquer rapidement, les gens le contourneront.
Des outils comme AppMaster peuvent aider en gardant la logique visuelle et centralisée, de sorte que les changements de politique ne se transforment pas en un labyrinthe d'e-mails et d'exceptions.
Un bon outil de congés est surtout un ensemble propre d'enregistrements et quelques relations claires. Si vous maîtrisez l'essentiel, le reste de la conception du système de demandes de congés reste lisible, même lorsque les politiques et approbations se complexifient.
Commencez par un petit ensemble d'objets principaux que vous pouvez expliquer en une minute :
Pour les demandes, les champs qui évitent les douleurs réelles ne sont pas sophistiqués. Ils sont spécifiques. Stockez la date/heure de début et de fin, s'il s'agit d'une demi‑journée, et le fuseau horaire de l'employé au moment de la demande. Ajoutez une courte raison, et autorisez des pièces jointes si votre processus RH nécessite une preuve (par exemple un certificat médical). Gardez les pièces jointes optionnelles pour ne pas bloquer le PTO normal.
Les statuts doivent être peu nombreux et prévisibles : brouillon (sauvé mais pas envoyé), soumis, approuvé, rejeté et annulé. Évitez les statuts supplémentaires comme « en attente RH » à moins d'en avoir vraiment besoin.
Ne sautez pas la piste d'audit. Même un minimal « qui a changé quoi et quand » vous sauve lors des litiges. Au minimum, journalisez la soumission, l'approbation, le rejet, l'annulation et toute modification de dates.
Pour les équipes, emplacements et départements, traitez-les comme des données de référence séparées. Liez les employés à ces groupes, et liez les politiques aux groupes auxquels elles s'appliquent. Ainsi, quand quelqu'un change de bureau, vous mettez à jour un seul enregistrement employé, pas chaque politique.
Si vous construisez cela dans AppMaster, gardez chaque objet simple au départ, puis ajoutez validations et étapes de workflow une fois les données stabilisées.
Les bonnes politiques sont ennuyeuses volontairement. Les gens doivent pouvoir prévoir le résultat avant de cliquer sur Soumettre. Dans la conception d'un système de demandes de congés, la façon la plus rapide de perdre la confiance est lorsqu'une même demande est approuvée une semaine et rejetée la suivante.
Commencez par nommer vos types de congés et rédigez une phrase claire pour chacun. Les congés payés (Vacation ou PTO) sont des temps planifiés. Le congé maladie est un temps non planifié lié à la santé. Le congé sans solde n'a pas de paie. Le congé parental a souvent des dates et documents spécifiques. Le temps compensatoire (comp time) est gagné par des heures supplémentaires et dépensé comme le PTO.
Les règles d'éligibilité doivent se lire comme une checklist, pas un document légal. Soyez explicite : qui peut l'utiliser (temps plein, temps partiel, contractuels), quand cela commence (après la période d'essai, après X jours), et si cela dépend de l'ancienneté. Si une règle a des exceptions, rédigez l'exception comme sa propre règle, pas en note de bas de page.
Les règles de demande sont le point où la confusion commence généralement. Soyez précis sur les délais de préavis, les périodes de restriction (blackout) et la plus petite unité autorisée. Par exemple : « Les demandes de vacances doivent être soumises 5 jours ouvrés à l'avance, sauf urgence approuvée par les RH » est testable. « Soumettre tôt » ne l'est pas.
Les règles de report et d'expiration doivent tenir en une phrase. Exemple : « Jusqu'à 40 heures sont reportées à l'année suivante et expirent le 31 mars. » Si vous avez besoin d'une deuxième phrase, c'est un indice que la politique fait trop de choses.
Voici une façon simple de garder le texte de politique et la logique des règles synchronisés :
Exemple : un employé en période d'essai demande 2 heures de PTO pour demain. Le système doit le bloquer pour deux raisons faciles à lire : « Le PTO commence après 60 jours » et « Le PTO nécessite 5 jours ouvrés de préavis. » Si vous construisez dans AppMaster, gardez ces messages proches des nœuds de règle pour que les mises à jour ne se désynchronisent pas.
L'acquisition est l'endroit où la conception d'un système de congés devient souvent désordonnée, car de petites règles s'additionnent. L'objectif n'est pas des maths sophistiquées, mais des résultats prévisibles qui correspondent à ce que RH et employés attendent en consultant un solde.
Une confusion courante est de mélanger les styles d'acquisition. Certaines entreprises ajoutent des heures à chaque période de paie, d'autres mensuellement, certaines acquièrent par heure travaillée, et d'autres accordent la totalité annuelle à une date fixe. Les problèmes commencent quand vous ne stockez que le « solde » et oubliez « comment il a été acquis ». Gardez un enregistrement clair des événements : attribution, acquisition, ajustement et utilisation.
La proratisation est un autre piège. Un nouveau salarié qui commence en milieu de mois, ou un employé passant de temps partiel à temps plein, ne devrait pas nécessiter une correction manuelle dans un tableur. Décidez d'une règle et tenez‑y‑vous. Par exemple : proratiser par jours calendaires dans la période, ou par heures planifiées. Quelle que soit votre décision, écrivez‑la en termes clairs et encodez‑la de la même façon partout.
Les plafonds et les soldes négatifs causent des tickets « ça a l'air faux ». Si vous autorisez un report jusqu'à un plafond, appliquez ce plafond à un moment précis (fin d'année, fin de période d'acquisition, ou après chaque acquisition). Si les soldes négatifs sont autorisés, définissez la limite et ce qui arrive en cas de fin de contrat.
Les règles d'arrondi créent une dérive silencieuse. Choisissez un niveau d'arrondi (minutes, quarts d'heure, demi‑journées) et appliquez‑le de façon cohérente à l'acquisition et à l'utilisation. Si vous acquérez en minutes mais que les demandes se font en demi‑journées, les employés auront toujours l'impression que le système est faux.
Les demandes rétroactives et les corrections ont besoin d'une piste d'audit. Si quelqu'un soumet une demande pour la semaine dernière, le système doit recalculer depuis la date effective et journaliser le changement.
Une checklist simple qui évite la plupart des litiges :
Dans AppMaster, cela se traduit normalement par une table Transactions plus un petit processus métier qui recalcule les soldes quand une demande est approuvée ou corrigée.
Un workflow d'approbation manager doit répondre à une question : qui peut dire « oui » en toute confiance ? Si vous essayez de modéliser chaque détail d'organigramme, votre système de demandes de congés devient difficile à lire et encore plus difficile à réparer.
Commencez par une règle par défaut : le manager direct de l'employé approuve. Ajoutez ensuite seulement les exceptions qui changent le risque ou la responsabilité. Gardez l'ordre des règles explicite, pour pouvoir expliquer les résultats sans fouiller dans les paramètres.
La plupart des équipes peuvent utiliser une seule étape d'approbation pour le PTO standard. Ajoutez des étapes uniquement lorsque la demande affecte la paie, la conformité ou la couverture entre équipes.
Schémas courants et lisibles :
Les approbations échouent quand l'approbateur est absent. Faites de la délégation une règle de première classe, pas une solution manuelle. Si le manager est marqué en congé, routez vers un délégué ; s'il n'y a pas de délégué, routez vers le manager du manager (ou les RH en dernier recours). Journalisez toujours quelle règle a choisi l'approbateur.
Les rejets et modifications sont là où les systèmes deviennent désordonnés. Restez simple : un rejet clôt la demande avec une raison requise. Si l'employé modifie des dates ou le type de congé, traitez‑le comme une nouvelle soumission et relancez le routage depuis le début. Cela évite les « demi‑demandes approuvées » qui ne correspondent plus à ce qui a été approuvé.
Un exemple pratique : Alex demande 3 jours de congé maladie. Le système le route au manager, mais comme il s'agit d'un type de congé contrôlé par la politique, les RH ont une seconde étape seulement après l'approbation du manager. Si le manager est absent, le délégué approuve, et la piste d'audit montre pourquoi.
Si vous construisez cela dans AppMaster, gardez la logique de routage dans un seul processus visuel avec un petit ensemble de règles dans un ordre clair, pour que n'importe qui puisse le lire et le maintenir plus tard.
Une bonne validation garde la conception du système de demandes de congés lisible car elle empêche les cas particuliers d'envahir les approbations. Visez des règles faciles à expliquer et à tester.
Commencez par les règles de réservation. Les contrôles de chevauchement doivent détecter les conflits avec les congés approuvés et les demandes en attente. Soyez explicite sur les demi‑journées : stockez la date plus une unité simple comme AM, PM ou heures pour que les demi‑journées ne soient pas arrondies par erreur en journées pleines. Décidez aussi quoi faire avec les week‑ends et jours fériés : les bloquer ou les autoriser mais les ignorer dans le calcul des jours.
Les contrôles de solde sont plus délicats qu'ils n'y paraissent. Beaucoup d'équipes valident le solde au moment de la soumission (pour éviter le spam) et revérifient au moment de l'approbation (car les acquisitions et autres approbations peuvent changer le solde). Si vous faites les deux, montrez à l'utilisateur quel point a échoué.
Voici un ensemble clair de validations couvrant la plupart des cas :
Les contrôles de couverture d'équipe peuvent aider, mais évitez les blocages stricts sauf si nécessaire. Un meilleur défaut est un avertissement laissant le manager décider. Exemple : « Deux personnes de votre équipe sont déjà absentes ce jour. Soumettre quand même ? »
Rendez les messages d'erreur justes et réparables. Dites aux utilisateurs ce qui a échoué, où et comment corriger. Par exemple : « Votre demande chevauche un PTO approuvé le 12 mars (PM). Choisissez un autre créneau ou modifiez la demande existante. »
Si vous construisez cela dans AppMaster, gardez les validations proches du formulaire de demande et réutilisez les mêmes contrôles lors de l'étape d'approbation pour éviter la dérive des règles.
Un bon système de demandes de congés est ennuyeux dans le meilleur sens : chaque demande suit le même chemin, et chaque décision a une raison claire. La façon la plus simple de le garder lisible est de séparer les données de politique (quelles sont les règles) de la logique de workflow (ce qui se passe quand quelqu'un clique sur Soumettre).
Voici une séquence qui reste simple même lorsque vous ajoutez des types de congés :
Gardez le workflow lisible en journalisant chaque décision en langage clair (par exemple : « Rejeté : chevauche un congé approuvé existant »). Si vous utilisez un outil visuel comme le Business Process Editor d'AppMaster, étiquetez les étapes comme un humain les lirait.
Avant le lancement, testez avec des scénarios réels : demandes rétroactives, manager en congé, changement de politique en cours d'année, et modification après approbation. Si le résultat surprend les RH, la règle n'est pas encore assez claire.
Un calendrier doit répondre rapidement à une question : qui est absent, et quand. Ne tentez pas de transformer l'événement de calendrier en l'enregistrement complet de la demande. Mettez seulement ce qui aide la planification, et gardez le reste dans votre système RH.
Pour le contenu des événements, restez cohérent. Un bon défaut est un titre court comme « Absence — Alex Kim » plus le type de congé si cela a de l'importance (« PTO », « Maladie »). Gardez les détails minimaux pour la confidentialité. Beaucoup d'équipes préfèrent afficher l'événement comme « Occupé » et stocker raisons, soldes et notes uniquement dans la demande.
Chaque demande a besoin d'un ID interne stable, et chaque événement de calendrier devrait stocker cet ID (par exemple dans un champ personnalisé ou la description). Ainsi, vous pouvez créer, mettre à jour et supprimer en toute sécurité le bon événement lorsque les demandes changent.
Gérer les statuts est là où les systèmes dérivent. Décidez d'avance si les demandes provisoires apparaissent ou non. Si vous les montrez, distinguez‑les visiblement (préfixe « En attente » dans le titre et un état de disponibilité différent). Quand une demande est approuvée, mettez à jour le même événement plutôt que d'en créer un nouveau. Si une demande est annulée ou rejetée après avoir été visible, supprimez l'événement pour que les calendriers ne mentent pas.
Les fuseaux horaires posent le plus de problèmes pour les congés en journée complète et partiels. Stockez début et fin comme des timestamps exacts dans le fuseau horaire local de l'employé, et stockez aussi ce fuseau sur la demande.
Utilisez des événements « toute la journée » seulement pour les congés vraiment sur une journée entière. Pour les demi‑journées, créez des événements horaires (par exemple 13:00–17:00) pour que les collègues dans d'autres fuseaux voient le chevauchement correct.
Si la synchronisation calendrier échoue, ne la cachez pas. Mettez la tâche en file, réessayez avec backoff, et affichez un statut clair « Calendrier non mis à jour » avec une action manuelle « retenter la synchronisation ». Dans des outils comme AppMaster, c'est généralement un simple processus en arrière‑plan plus un écran admin listant les tentatives de sync échouées pour que les RH puissent régler sans éditer les demandes.
La plupart des échecs dans la conception d'un système de demandes de congés surviennent quand les règles s'accroissent silencieusement. Le système « fonctionne », mais personne ne fait confiance aux soldes, et chaque cas étrange devient un ticket de support.
Si l'acquisition est fragmentée en de nombreux cas spéciaux (nouveaux embauchés, reports, congés sans solde, temps partiel), les gens ne peuvent pas prévoir leur solde.
Gardez un modèle d'acquisition clair par type de congé, puis ajoutez les exceptions comme règles nommées et testables. Rédigez quelques employés exemple et soldes attendus pour des dates précises, et revérifiez à chaque changement de politique.
Les approbations qui se multiplient deviennent impossibles à tester, et les managers ignorent pourquoi une demande a été routée ailleurs.
Un modèle plus sûr :
Le texte de politique s'adresse aux humains (ce qui compte, qui est éligible). Les règles mathématiques sont pour le système (taux, plafonds, arrondis, report). Stockez‑les séparément pour pouvoir mettre à jour la formulation sans toucher aux calculs, et tester les calculs sans réécrire le manuel.
Si vous écrasez des demandes, vous perdez le « pourquoi » derrière un changement de solde.
Conservez toujours une piste d'audit : qui a changé quoi, quand, et les valeurs précédentes. Dans AppMaster, c'est simple à modéliser comme une table d'historique des demandes plus des transitions d'état dans un Business Process.
Les congés couvrent des dates, mais les approbations et entrées calendrier utilisent des timestamps. Normalisez sur un « fuseau politique » unique et stockez aussi le fuseau local de l'employé. Décidez aussi tôt si les jours fériés publics réduisent le nombre de jours demandés, et appliquez la règle de façon cohérente.
Avant d'annoncer le système à tous, passez une courte série de vérifications avec un employé réel, un manager et quelqu'un des RH. Vous voulez confirmer que le système paraît évident, pas seulement qu'il fonctionne.
Utilisez cette checklist comme une porte go/no‑go pour votre conception :
Un test pratique : créez une demande, approuvez‑la, modifiez les dates, puis annulez‑la. Si une étape laisse un solde incorrect, un événement calendrier obsolète ou un statut inexpliqué, corrigez‑le avant le lancement.
Si vous construisez avec du no‑code, la visibilité compte autant que les fonctionnalités. Dans AppMaster, gardez le modèle de données (types de congés, soldes, approbations) et le workflow d'approbation dans des éditeurs visuels, afin que les RH et l'opérationnel puissent vérifier ce que le système fait réellement. Vous pouvez aussi exposer des APIs pour la synchro calendrier et régénérer un code source propre au fil de l'évolution des politiques sans empiler des correctifs temporaires.
Quand la première version est stable, étendez une dimension à la fois : plus de politiques, plus de règles de routage, puis plus d'intégrations.
Une nouvelle employée, Maya, commence le 10 mars. Votre système de demandes de congés utilise un accrual mensuel, donc Maya gagne du PTO le premier de chaque mois. Le 12 avril, elle demande une demi‑journée : 3 heures vendredi prochain pour un rendez‑vous médical.
Ce que chacun voit :
Maya soumet la demande. Son manager est en congé, donc le système vérifie la configuration de délégation et la route vers le manager d'intérim. Le manager d'intérim approuve.
À l'approbation, deux choses se produisent : la demande est verrouillée à la version de politique utilisée, et un événement calendrier est créé « Maya — PTO (3h) » à la bonne date et avec la bonne fenêtre horaire. Maya voit immédiatement « Approuvé » et le statut calendrier « Ajouté ».
En juin, les RH mettent à jour la politique en cours d'année (par exemple, l'acquisition augmente après 90 jours). Les soldes doivent être recalculés, mais les demandes approuvées dans le passé ne doivent pas être modifiées silencieusement. Le système recalcule le solde courant de Maya depuis la date d'effet, en conservant une trace avant/après.
Une semaine plus tard, Maya change la date de la demande (le rendez‑vous est déplacé). Comme le congé était déjà approuvé, le changement devient une nouvelle « demande de modification » qui repasse par le manager délégué. Une fois approuvé à nouveau, l'événement calendrier existant est mis à jour (même ID d'événement), pas dupliqué.
Ceci est facile à modéliser dans un outil comme AppMaster en gardant le workflow lisible : un seul chemin d'approbation, une vérification de délégation, une étape unique de création/mise à jour du calendrier, et une action de recalcul séparée que les RH peuvent lancer quand les politiques changent.
La façon la plus sûre de finir la conception d'un système de demandes de congés est de livrer une petite version en laquelle les gens ont confiance, puis d'étendre. Commencez par une politique (par exemple PTO) et un chemin d'approbation (employé -> manager). Quand cela devient ennuyeusement fiable, ajoutez le type de congé suivant, une région ou un cas limite.
Avant d'ajouter plus de règles, décidez où réside la source de vérité. Si votre SIRH est le référentiel maître, votre appli doit surtout valider, router les approbations et synchroniser les résultats. Si votre appli est le maître, vous aurez besoin de journaux d'audit plus clairs et d'un plan pour gérer les changements de données RH (nouveau manager, déplacement de département, dates de fin de contrat).
Un plan de première version pratique :
Rédigez 5 à 10 cas de test réels et rejouez‑les après chaque changement. Utilisez des cas de votre propre équipe, pas des exemples inventés. Par exemple : quelqu'un demande vendredi le jeudi, quelqu'un modifie sa demande après approbation, ou un manager approuve alors que l'employé est dans un fuseau horaire différent.
Si vous construisez sans code, la visibilité importe autant que les fonctionnalités. Dans AppMaster, vous pouvez garder le modèle de données (types de congés, soldes, approbations) et le workflow d'approbation dans des éditeurs visuels, de sorte que les RH et l'opérationnel puissent examiner ce que fait réellement le système. Vous pouvez aussi exposer des APIs pour la synchronisation calendrier et régénérer un code source propre à mesure que les politiques évoluent, sans empiler de correctifs temporaires.
Quand la première version est stable, étendez une dimension à la fois : plus de politiques, plus de règles de routage, puis davantage d'intégrations.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
