Comment l'algorithme calcule les ponts optimaux

Nous utilisons l'algorithme Anonymous Gregorian (parfois nommé algorithme de Gauss), qui produit la date du dimanche de Pâques pour toute année grégorienne. Il est implémenté en quelques lignes d'arithmétique pure, sans aucune table. Pour 2026, il renvoie le dimanche 5 avril ; pour 2030, le dimanche 21 avril. Le Lundi de Pâques en découle (Pâques + 1), ainsi que le Jeudi de l'Ascension (Pâques + 39) et le Lundi de Pentecôte (Pâques + 50). En Alsace-Moselle, le Vendredi saint correspond à Pâques moins 2 jours.

L'article L.3133-2 du Code du travail français stipule qu'un jour férié tombant un dimanche n'est ni reporté au lundi, ni compensé. Sauf convention collective ou accord d'entreprise plus favorable (hors scope de cet outil), le salarié perd simplement le jour. Notre calculateur marque ces fériés comme « tombe un dimanche (perdu) » dans la liste annuelle, mais ne les supprime pas (la date reste un jour férié au sens légal — elle est juste sans effet pratique).

Métropole (Code du travail L3133-1) : 1er janvier, Lundi de Pâques, 1er mai (seul férié obligatoirement chômé), 8 mai, Jeudi de l'Ascension, Lundi de Pentecôte, 14 juillet, 15 août (Assomption), 1er novembre (Toussaint), 11 novembre, 25 décembre. Alsace-Moselle (droits locaux Bas-Rhin / Haut-Rhin / Moselle, maintenus depuis 1918) : la liste métropole + Vendredi saint + 26 décembre (Saint-Étienne, dit aussi 2ème jour de Noël). Les DOM-TOM ont leurs propres dates (commémoration de l'abolition de l'esclavage à dates variables) — non couvertes par le MVP.

Un pont est une fenêtre de jours non-travaillés consécutifs obtenue en combinant week-ends, jours fériés et un éventuel petit nombre de jours CP/RTT posés. On distingue : (a) les fériés naturels — un férié qui tombe un vendredi ou un lundi crée un week-end de 3 jours sans rien poser, ratio infini ; (b) les ponts à activer — un férié en milieu de semaine (mardi, mercredi, jeudi) que l'on prolonge en posant 1 ou 2 jours pour obtenir un bloc de 4-5 jours off.

Le ratio est jours_off_consécutifs / max(jours_posés, 1). Un ratio élevé signifie « peu de jours posés pour beaucoup de jours off ». Exemple emblématique : Ascension 2026 (jeudi 14 mai), poser le vendredi 15 mai = 4 jours off (jeu férié + ven posé + sam + dim) pour 1 jour posé, ratio 4. Le tri principal est ratio décroissant, avec en tie-break le startDate ascendant (le pont le plus tôt dans l'année gagne en cas d'égalité). Cette règle est documentée dans nos notes d'implémentation.

Le Bloc A liste les fériés naturels (vendredi ou lundi), où vous obtenez un week-end de 3 jours sans poser. C'est une information : « voici ce que tu as gratuit cette année ». Le Bloc B liste les ponts à activer, où vous devez poser au moins un jour. C'est une décision : « voici comment optimiser ton budget ». Les regrouper aurait écrasé le Bloc B avec des ratios infinis (les naturels sont automatiquement en tête), masquant l'info utile.

Pour 2026-2030 et un budget ≤ 5 jours, l'énumération des ponts candidats donne ≤ 55 candidats. Un glouton sur le ratio retient toujours le pont le plus efficace en premier puis élimine les ponts qui chevauchent ou dépassent le budget. Sur les 5 années simulées, le glouton produit le même résultat qu'un knapsack DP de référence (D-08). Si une année future donnait un écart > 10%, nous bascuerions sur DP — mais ce n'est pas le cas du MVP. La décision est tracée dans D-08 du dossier décisions.

La sortie de notre module `holidays.ts` est comparée à un snapshot statique extrait de l'API officielle calendrier.api.gouv.fr (Etalab) pour les 5 années 2026-2030 × 2 régions (metropole, alsace-moselle). Tous les tests Vitest passent. La discipline « aucune borne arbitraire » est appliquée : les seuils numériques inscrits dans le contrat d'acceptation (ex: « Bloc A 2026 métropole = exactement 5 fériés naturels ») dérivent d'une simulation calendaire vérifiée préalablement, pas d'une intuition.

Le fichier .ics suit la RFC 5545. Il contient un VEVENT all-day par jour férié (UID préfixé `férié-`, summary = nom du férié) et un VEVENT par jour CP/RTT à poser dans le plan optimisé (UID préfixé `pose-`). Chaque VEVENT contient un DTSTAMP (requis par la RFC, sinon Apple Calendar et Outlook rejettent le fichier), un DTSTART;VALUE=DATE et un DTEND;VALUE=DATE (lendemain, exclusif).

Aucune. Le calculateur tourne 100% côté client (JavaScript dans votre navigateur). Aucune donnée ne quitte votre appareil. Aucun cookie n'est posé. Si Cloudflare Web Analytics est activé par l'éditeur, le compteur de fréquentation est cookieless et conforme à la position CNIL sur les exemptés de consentement. Pas de Google Analytics, pas de Facebook Pixel, pas d'AdSense. URL params suffisent à la persistance entre visites — bookmarkez l'URL pour retrouver vos paramètres.