Démarrer la gestion des congés payés sur Odoo en cours d'année : le bon réflexe (qui n'est pas celui qu'on croit)
Vous bouclez votre déploiement Odoo et vous arrivez à la question piège : "On démarre Congés en avril, mais la période de référence française court du 1er juin au 31 mai. Comment on s'en sort pour le solde N-1 d'un salarié, son solde N en cours, et l'acquisition à venir ?"
C'est une question que je vois revenir à chaque projet RH. Et la mauvaise réponse — celle qui consiste à créer trois types de congés distincts pour isoler chaque millésime — coûte cher en temps de paramétrage, en confusion utilisateur et en clôtures annuelles douloureuses. Voici la bonne approche, testée sur le terrain.
Le piège : croire qu'il faut "compartimenter" les périodes
Le réflexe initial, quand on découvre Odoo Congés, c'est de vouloir représenter chaque période d'acquisition par un type de congé distinct : CP N-1, CP N, CP N+1. L'intention est louable — on veut tracer proprement ce qui appartient à quelle période, forcer la consommation du plus ancien d'abord, éviter les mélanges.
Le problème, c'est que chaque 31 mai, vous vous retrouvez à devoir faire glisser les soldes d'un type à l'autre : ce qui restait sur CP N devient le nouveau CP N-1, ce qui est en cours d'acquisition bascule en CP N… À multiplier par tous les salariés, c'est laborieux, source d'erreurs et difficile à auditer.
Il existe une approche beaucoup plus simple, qui exploite un comportement natif d'Odoo souvent ignoré.
Le bon modèle : un seul type, plusieurs allocations en parallèle
Dans Odoo, une allocation est un crédit attribué à un salarié pour un type de congé donné, avec une date de début et une date de fin de validité. Et la chose à retenir, c'est qu'un même salarié peut avoir plusieurs allocations actives en parallèle sur le même type de congé. Chacune avec sa propre fenêtre de validité.
Concrètement, pour un salarié qui démarre sur Odoo en milieu de période 2025-2026, on aura trois allocations sur le type unique « Congés payés » :
- CP 2024-2025 (reliquat) — quantité fixe, valable jusqu'au 31/05/2026.
- CP 2025-2026 (déjà acquis) — quantité fixe, valable jusqu'au 31/05/2027.
- CP 2026-2027 (en cours d'acquisition) — alimentée automatiquement à 2,5 jours ouvrables par mois, valable jusqu'au 31/05/2028.
Et c'est tout. Pas de type multiple. Pas de gymnastique annuelle. La consommation se fait naturellement sur l'allocation qui expire le plus tôt (logique FEFO — first expired, first out), donc le reliquat N-1 part en premier.
Le paramétrage en détail
Le type de congé unique
Un seul à créer : « Congés payés ».
- Décompte : jours ouvrables (samedi compté, 30 jours/an de plein droit pour un temps plein)
- Validation : par le responsable hiérarchique / gestionnaire de congés (sans incidence)
- Pièce jointe : facultative
- Mode d'allocation : à l'approbation (le gestionnaire crée les allocations)
- Solde négatif : non autorisé sauf politique d'entreprise
Le plan d'accumulation : « CP — 2,5 j ouvrables / mois »
Un seul également :
- Fréquence : mensuelle, au dernier jour du mois
- Quantité octroyée : 2,5 jours
- Plafond : 30 jours (limite annuelle légale)
- Démarrage : à la date de début de l'allocation qui l'utilise
En image :
Avec le détail de la règle :
Les trois allocations à l'initialisation
Prenons un exemple chiffré pour fixer les idées. Salarié à temps plein, bascule sur Odoo au 1er avril 2026.
| Allocation | Période d'acquisition | Date début | Date fin | Quantité | Mode |
|---|---|---|---|---|---|
| CP 2024-2025 reliquat | 01/06/2024 → 31/05/2025 | 01/04/2026 | 31/05/2026 | 8 j (reliquat constaté) | Régulière (figée) |
| CP 2025-2026 acquis | 01/06/2025 → 31/05/2026 | 01/04/2026 | 31/05/2027 | 25 j (10 mois × 2,5) | Régulière (figée) |
| CP 2026-2027 en acquisition | 01/06/2026 → 31/05/2027 | 31/05/2026 | 31/05/2028 | départ à 0 | Plan d'accumulation |
Les deux premières quantités correspondent aux soldes réellement constatés sur la paie au moment de la bascule. La troisième démarre à zéro et se cumulera automatiquement au fil des mois :
L'opération annuelle : une seule allocation à créer chaque 31 mai
C'est ici que la simplicité du modèle se révèle pleinement. Chaque 31 mai à partir de 2027, vous n'avez qu'une seule chose à faire : créer la nouvelle allocation pour la période d'acquisition qui démarre.
Au 31/05/2027 :
| Nouvelle allocation | Période d'acquisition | Date début | Date fin | Quantité | Mode |
|---|---|---|---|---|---|
| CP 2027-2028 | 01/06/2027 → 31/05/2028 | 31/05/2027 | 31/05/2029 | 0 (cumul auto) | Plan d'accumulation |
Et c'est terminé. Le reste se fait tout seul :
- L'allocation CP 2024-2025 a expiré au 31/05/2026 → Odoo l'a sortie du solde disponible.
- L'allocation CP 2025-2026 expire au 31/05/2027 → le résiduel est perdu (sauf cas légaux : maternité, arrêt maladie, etc.).
- L'allocation CP 2026-2027 a atteint son plafond de 30 jours → elle reste consommable jusqu'au 31/05/2028.
Cette création annuelle est même automatisable via une action planifiée Studio ou un petit module dédié, pour tous les salariés à temps plein en une seule passe.
Le point de vigilance avant déploiement
Un test à faire absolument sur un employé pilote avant généralisation : vérifier que la consommation se fait bien en FEFO automatique quand plusieurs allocations coexistent. Selon les modules HR additionnels installés et la configuration fine de votre instance, il peut arriver que le salarié — ou le valideur — doive choisir explicitement l'allocation à débiter au moment de la demande. Le modèle reste valable, il faut juste compléter par une consigne aux utilisateurs : toujours débiter l'allocation la plus ancienne en premier.
C'est un test de 10 minutes qui évite des surprises 6 mois plus tard.
Ce qu'il faut retenir
- Un seul type de congé (« Congés payés ») suffit, même si vous gérez plusieurs millésimes en parallèle.
- Trois allocations à l'initialisation, avec des dates de fin différenciées : Odoo gère naturellement l'expiration et la priorité.
- Une seule allocation à créer chaque 31 mai pour la nouvelle période en acquisition.
- Pas de glissement annuel manuel : c'est l'erreur classique qui complique tout pour rien.
- Testez le FEFO sur un cas pilote avant de généraliser.
La beauté de cette approche, c'est qu'elle reflète directement la logique métier française des CP — chaque période a sa fenêtre, son plafond, sa date d'expiration — sans imposer à Odoo une représentation artificielle qui le fait travailler contre lui-même.
Cet article fait partie du blog Parcours Odoo. Si vous avez un cas particulier (temps partiel, entrées-sorties en cours d'année, accord d'entreprise spécifique sur le report), n'hésitez pas à me contacter — la méthode s'adapte, mais le principe reste le même.
Si vous avez besoin d'accompagnement, profitez de nos carnets d'heures (à partir d'une heure) pour traiter ensemble vos cas d'usages.