Créer une application de demandes d’absence pour une petite équipe

Un exemple de six collègues pour préparer les demandes, les décisions et les annulations après accord. Le guide porte sur le parcours de validation, sans calculer les droits à congés.

Une collègue a envoyé ses dates par message. Son responsable lui a répondu oralement, puis les dates ont changé. Le calendrier commun affiche encore la première période et personne ne sait quelle décision fait foi. Une application de demandes d’absence sert d’abord à conserver une demande précise et la réponse qui lui correspond.

L’équipe fictive de Studio Traverse compte six personnes : Ana, Bilal, Chloé, David, Emma et Farid. Leurs situations sont inventées. Ce guide décrit le parcours de demande, de décision et de modification. Il ne définit ni droits à congés, ni soldes, ni règles de paie, ni obligations propres à un statut professionnel.

Limiter le premier besoin à une décision retrouvable

Commencez par ce que chacun doit pouvoir comprendre : quelle période a été demandée, qui doit répondre et quelle est la dernière décision. Cette base peut déjà remplacer des échanges difficiles à reconstituer, sans construire tout un outil de ressources humaines.

Dans l’exemple, Ana veut demander une absence du 12 au 14 octobre 2026. Elle choisit les dates, vérifie le résumé et soumet la demande. Chloé reçoit le dossier dans sa liste de décisions à prendre. Tant qu’elle n’a pas répondu, Ana voit « en attente », et non une absence confirmée.

Le support pédagogique sur une application de gestion de congés avec Bonita illustre notamment la création et le suivi de demandes par l’utilisateur connecté. Il comporte des éléments techniques et ne constitue pas un modèle juridique. Notre guide en retient la question de parcours, avec des règles fictives à adapter.

Écrivez dès le départ les sujets exclus : calcul des droits, alimentation de la paie, justificatifs sensibles et gestion de situations particulières. Une première version peut rester utile sans ces fonctions. Si votre besoin les impose, leur conception demande un travail distinct avec les personnes compétentes dans votre organisation.

Décrire les six rôles et les remplacements

Un rôle correspond à une action, pas seulement à un intitulé de poste. Dans Studio Traverse, Ana, Bilal, David et Emma déposent leurs demandes. Chloé répond aux demandes de leur groupe. Farid est son remplaçant désigné et la personne qui décide pour les propres demandes de Chloé.

La demande de Farid ne doit pas rester sans décideur. L’exemple prévoit Chloé pour ce cas, selon une règle explicite. Le but n’est pas de recommander cette organisation, mais de montrer que tous les comptes doivent avoir un parcours complet, y compris ceux des responsables.

• Demandeur : créer, relire, soumettre et suivre ses demandes.
• Décideur : répondre sur les demandes qui lui sont attribuées.
• Remplaçant : intervenir pendant une période et sur un périmètre définis.
• Gestionnaire de l’outil : gérer les comptes et corriger une erreur selon une procédure.
• Collègue : consulter uniquement les informations de planning autorisées.

Une même personne peut tenir plusieurs rôles. Cela ne signifie pas qu’elle peut prendre toutes les décisions. Décrivez en particulier l’auto-approbation, le remplacement d’un responsable absent et le traitement d’une demande sans affectation. Un accès d’administration ne doit pas se transformer automatiquement en pouvoir de validation métier.

Pour comprendre · illustration du guide

Faire choisir une période sans ambiguïté

Une date seule ne dit pas toujours si la journée entière est concernée. Si votre organisation distingue matin et après-midi, donnez ces choix au début et à la fin de la période. Dans notre exemple, les journées et demi-journées sont des unités d’affichage du planning, sans calcul de droits.

Le résumé peut indiquer « du lundi 12 octobre au mercredi 14 octobre inclus, journées entières ». Ana vérifie ainsi le périmètre avant l’envoi. Si le formulaire affiche seulement deux nombres, une confusion entre fin comprise et fin exclue peut passer inaperçue jusqu’au jour concerné.

Décidez du traitement des périodes incohérentes : fin antérieure au début, demi-journée de fin placée avant celle du début ou date absente. Expliquez le problème près du champ. Le formulaire doit garder les autres informations saisies afin que la personne ne recommence pas toute sa demande.

N’ajoutez pas un calcul de solde simplement parce qu’une durée est affichée. Le nombre de cases occupées dans le calendrier ne suffit pas à déterminer un droit disponible ou un décompte applicable. Si vous avez besoin de cette fonction, définissez sa source et ses règles dans un périmètre séparé.

Donner un sens stable aux états de demande

La première version retient brouillon, soumise, précision demandée, acceptée, refusée et retirée. Un brouillon peut être modifié par son auteur. Une demande soumise attend une décision. Une précision demandée revient au demandeur avec une question identifiable, sans être traitée comme un refus.

L’acceptation porte sur une version précise. Lorsque Chloé accepte la demande d’Ana du 12 au 14 octobre, l’application conserve cette période et la date de décision. Si Ana change ensuite le 14 en 16, l’accord initial ne s’étend pas automatiquement aux deux journées ajoutées.

La demande refusée conserve la réponse et le contexte nécessaire à son suivi. Le demandeur peut préparer une autre proposition selon vos règles. Évitez de remplacer silencieusement la demande refusée par une nouvelle période, ce qui rendrait incompréhensible la décision précédente.

Montrer les chevauchements sans décider à la place du responsable

Un chevauchement peut correspondre à deux demandes du même collègue ou à plusieurs personnes absentes en même temps. Les conséquences diffèrent. Une demande répétée d’Ana peut être un doublon ; l’absence simultanée de Bilal demande une discussion d’organisation. Ne traitez pas tous les chevauchements comme une interdiction identique.

Dans l’exemple, Ana demande les 12, 13 et 14 octobre, tandis que Bilal demande les 14 et 15. Le 14 est commun. Le responsable doit retrouver cette journée et le statut de chaque demande. Deux propositions encore en attente ne doivent pas apparaître comme deux absences déjà confirmées.

Si votre équipe définit une règle de présence pour une activité, décrivez-la précisément avec les personnes concernées. Une capacité de service peut dépendre des rôles et des horaires, pas seulement du nombre de collègues présents. L’application peut montrer les informations utiles ; la règle de décision doit être convenue en dehors de l’écran.

Essayez les demi-journées. Ana absente le matin et Bilal absent l’après-midi ne produisent pas le même recouvrement qu’une journée entière commune. Le calendrier doit montrer ce détail sans imposer au lecteur d’ouvrir plusieurs fiches. N’en déduisez aucun calcul de droit : il s’agit ici de visibilité opérationnelle.

Annuler après accord avec une étape explicite

Une personne peut vouloir retirer une demande encore en attente. Dans notre exemple, elle la passe à « retirée » avec une trace, et le responsable n’a plus à décider. L’annulation d’une absence déjà acceptée suit un autre parcours, car l’équipe a pu organiser le travail en fonction de cet accord.

Ana demande donc une annulation de son absence acceptée. L’application indique « annulation demandée » tout en conservant l’état confirmé tant que la décision n’est pas prise. Cette règle est celle de notre scénario ; elle doit être discutée dans votre organisation, puis affichée clairement pour éviter deux lectures du calendrier.

Lorsque Chloé accepte l’annulation, le planning est actualisé et l’historique conserve la première demande, l’accord, la demande d’annulation et sa réponse. Si l’annulation n’est pas acceptée dans ce scénario, l’état précédent reste visible, accompagné de la décision et de la suite à donner.

Une réduction ou un déplacement partiel demande la même précision. Ana veut garder le 12 mais reprendre le travail le 13 : la demande modifiée doit montrer ce qui change. Ne supprimez pas les anciens jours avant que le traitement prévu soit terminé, au risque de présenter une disponibilité encore incertaine.

Limiter les informations du calendrier commun

Le calendrier collectif doit montrer ce qui aide l’équipe à s’organiser. Il peut afficher une personne indisponible et la période concernée, sans exposer le motif détaillé ni les échanges avec le responsable. Décidez ce que chaque rôle peut consulter au lieu de partager automatiquement toute la fiche.

La CNIL recommande de limiter les accès aux seules données nécessaires. Pour ce projet, traduisez ce principe simplement : Ana retrouve ses propres demandes ; Chloé voit celles qu’elle doit traiter ; un collègue consulte la disponibilité autorisée, sans ouvrir les commentaires de décision.

Évitez de recueillir une justification personnelle libre si elle n’est pas nécessaire au parcours retenu. Un champ « commentaire » très ouvert peut contenir des informations que le planning n’a pas besoin de conserver. Si certains cas exigent d’autres documents, prévoyez une procédure adaptée au lieu d’élargir ce formulaire par défaut.

Les messages de notification demandent la même attention. « Une réponse est disponible dans votre espace » peut suffire pour inviter à consulter la décision. Pendant les essais, utilisez uniquement des adresses contrôlées et des situations fictives. Testez les accès aux liens directs, aux exports et aux anciennes notifications.

Essayer les cas qui rendent le planning incohérent

Préparez une demande d’Ana, une de Bilal et une de Chloé. Faites-les parcourir avec les comptes correspondants. Vous vérifierez à la fois la demande ordinaire, le chevauchement et le circuit du responsable. Un parcours qui fonctionne seulement pour les salariés sans rôle particulier reste incomplet.

Essayez la décision simultanée : Chloé et son remplaçant ouvrent la même demande. Une seule décision actuelle doit être retenue selon la règle choisie. L’autre personne reçoit une explication et voit ce qui a déjà été enregistré. Deux écrans ouverts ne doivent pas produire deux réponses contradictoires envoyées au demandeur.

• Demande modifiée après accord : nouvelle décision identifiable.
• Annulation demandée après accord : calendrier conforme à la règle choisie.
• Demande retirée avant réponse : absence de tâche de décision active.
• Deux demandes qui se recouvrent : jours communs correctement visibles.
• Compte d’un collègue : aucun accès aux commentaires réservés.
• Responsable absent : remplaçant actif seulement sur son périmètre.

Ces vérifications restent à exécuter sur votre application. Notez l’attendu, le résultat observé, la date et la version. Après une correction, contrôlez les vues du demandeur, du décideur et du calendrier commun. Une information juste dans un écran peut rester fausse dans un autre si les mises à jour sont mal reliées.

Utiliser le modèle pour un essai limité

Le dossier de demandes d’absence à adapter rassemble les six rôles fictifs, trois demandes, les règles de modification et les essais. Commencez par faire confirmer le circuit de décision. Ne remplacez pas vos règles existantes par celles du document simplement parce qu’elles sont déjà écrites.

Choisissez ensuite une période d’essai et un groupe restreint. Précisez quel système fait foi et comment une erreur est signalée. Pendant une démonstration, toutes les demandes peuvent rester fictives. Un passage à l’usage réel demande notamment de valider les accès, les responsabilités et la continuité du service.

Le guide sur l’application interne d’une petite équipe aide à organiser ce projet. Le dossier peut être utilisé avec un prestataire ou dans un projet dirigé avec Maestro. L’application d’absences décrite ici reste à construire ; elle n’est pas une fonction RH native annoncée de Maestro.

Au bilan, cherchez les moments où deux personnes ont compris différemment l’état d’une demande. Une période modifiée, un remplacement de responsable ou une annulation sont particulièrement révélateurs. Corrigez d’abord ces ambiguïtés : une décision clairement retrouvable est plus utile qu’un calendrier très rempli dont personne ne sait quelle version est valide.

Revenir au sommaire