Calculer le temps entre deux dates paraît simple jusqu’au moment où le résultat affiché ne correspond pas à la réalité. Un jour en trop, un mois compté à tort, une année bissextile oubliée : ces micro-erreurs se glissent dans les tableurs, les logiciels RH et même les outils de gestion de projet sans déclencher la moindre alerte. Le problème ne vient presque jamais de l’outil lui-même, mais de la façon dont la question est posée à l’outil.
Jours calendaires ou jours ouvrés : la confusion qui fausse tout
La première source d’erreur, documentée dans les formations Excel récentes, tient à la distinction entre jours calendaires et jours ouvrés. Un délai contractuel de 30 jours ne couvre pas la même période selon qu’on compte les samedis, dimanches et jours fériés ou non. La différence peut représenter plus d’une semaine sur un trimestre.
A découvrir également : Partylite My Business : se connecter au business center
Sur Excel, la fonction NB.JOURS.OUVRES (ou NETWORKDAYS en version anglophone) exclut automatiquement les week-ends. En revanche, une simple soustraction entre deux cellules de dates renvoie des jours calendaires. Mélanger les deux dans un même tableau, sans l’indiquer, produit des incohérences que personne ne détecte tant que le fichier n’est pas audité.
Les plateformes collaboratives comme Monday.com proposent désormais une fonction WORKDAYS() qui permet de paramétrer le week-end selon le calendrier local (lundi-vendredi ou dimanche-jeudi). Ce type de fonction réduit le risque d’erreur pour les équipes internationales, mais il faut d’abord savoir qu’elle existe, puis la configurer correctement.
A lire également : Gta6 date : à quoi s'attendre pour les éditions spéciales en 2026
Erreur de calcul entre deux dates : le piège de l’inversion et du format
Une erreur classique consiste à inverser la date de début et la date de fin. Sur une soustraction brute dans Excel, le résultat sera négatif. La fonction JOURS(), elle, renvoie un entier négatif si la date de fin précède la date de début, ce qui peut passer inaperçu dans un reporting automatisé.
La fonction DATEDIF, héritée des premières versions d’Excel, va plus loin : elle ne signale aucune erreur si les dates sont inversées dans certaines configurations. Elle renvoie simplement un résultat incohérent. Comme elle n’apparaît plus dans les suggestions du ruban ni dans l’aide contextuelle, les utilisateurs qui la découvrent via un tutoriel ne connaissent pas toujours cette limite.
Formats de date régionaux
Un fichier créé aux États-Unis interprète « 03/07/2025 » comme le 7 mars. En France, c’est le 3 juillet. Quand deux collaborateurs travaillent sur le même tableur avec des paramètres régionaux différents, les calculs de durée entre deux dates divergent sans message d’alerte.
La parade la plus fiable reste de stocker les dates au format ISO 8601 (AAAA-MM-JJ) ou de forcer un format non ambigu dans les cellules. Peu d’équipes prennent cette précaution, et c’est souvent après une erreur de facturation ou de paie qu’elle est mise en place.
Années bissextiles et calcul de durée en mois : deux angles morts
Le calcul entre le 28 février et le 1er mars ne donne pas le même résultat selon que l’année est bissextile ou non. En 2000 (bissextile), il y a deux jours entre ces deux dates. En 2001, un seul. Ce décalage d’un jour semble anodin, mais il se cumule dans les calculs d’ancienneté, de contrats ou d’intérêts financiers.
Le calcul de durée en mois pose un problème plus structurel. Un « mois » n’a pas de durée fixe : il varie de 28 à 31 jours. La fonction DATEDIF avec l’unité « M » renvoie le nombre de mois entiers écoulés, en ignorant les jours restants. Deux périodes de longueur identique en jours peuvent donc afficher un nombre de mois différent selon leur position dans le calendrier.
- Du 1er janvier au 1er mars : DATEDIF renvoie 2 mois, que l’année soit bissextile (60 jours) ou non (59 jours).
- Du 31 janvier au 31 mars : 2 mois affichés, mais 59 ou 60 jours réels selon l’année.
- Du 31 janvier au 28 février : DATEDIF renvoie 0 mois, alors que la quasi-totalité de février est écoulée.
Ce comportement est documenté mais rarement anticipé. Les gestionnaires RH qui calculent des périodes d’essai ou des anciennetés en mois se retrouvent avec des résultats juridiquement contestables si la méthode de calcul n’est pas précisée dans le contrat.
TODAY() et les dates dynamiques : le faux confort de l’automatisation
Utiliser TODAY() dans un tableur pour calculer automatiquement le temps écoulé depuis une date fixe semble une bonne pratique. Le résultat se met à jour chaque jour sans intervention. Le piège apparaît quand le fichier est imprimé, exporté en PDF ou partagé par email : la date de référence change à chaque ouverture du fichier, ce qui rend le document impossible à auditer rétrospectivement.
Un reporting généré le 15 juin et rouvert le 20 juin affichera des durées différentes sans qu’aucune modification n’ait été enregistrée. Pour les documents à valeur probante (paie, facturation, suivi contractuel), figer la date de calcul dans une cellule distincte reste la seule méthode fiable.
Monday.com propose une approche similaire avec sa fonction TODAY(), pensée pour les tableaux de bord dynamiques. Elle fonctionne bien pour du suivi en temps réel, mais elle ne remplace pas un horodatage figé pour les documents archivés.
Vérification croisée : tester ses formules avec des cas limites
La majorité des erreurs de calcul de temps entre deux dates surviennent sur des cas limites que personne ne teste. Avant de déployer une formule dans un fichier partagé ou un outil de gestion, trois vérifications prennent moins d’une minute :
- Tester avec une année bissextile (ex. 29 février 2024 vers 1er mars 2024) pour vérifier que le résultat intègre le jour supplémentaire.
- Inverser volontairement les deux dates pour observer si la formule renvoie une erreur, un nombre négatif ou un résultat silencieusement faux.
- Comparer le résultat en jours calendaires et en jours ouvrés sur la même période pour confirmer que la bonne fonction est utilisée.
- Changer les paramètres régionaux du fichier (passer de FR à US) et vérifier que les dates ne sont pas réinterprétées.
Ces tests ne garantissent pas l’absence totale d’erreur, mais ils couvrent les scénarios qui génèrent le plus de litiges dans les contextes professionnels. Un tableur dont les formules de dates n’ont jamais été confrontées à un 29 février ou à un changement de fuseau est un tableur qui attend son premier bug.
