{"id":6102,"date":"2026-10-14T18:02:04","date_gmt":"2026-10-14T18:02:04","guid":{"rendered":"http:\/\/french.arabpsychology.com\/statistics\/google-sheets-query-filtrer-par-plage-de-dates\/"},"modified":"2026-10-14T18:02:05","modified_gmt":"2026-10-14T18:02:05","slug":"google-sheets-query-filtrer-par-plage-de-dates","status":"publish","type":"psych_stat","link":"https:\/\/french.arabpsychology.com\/?psych_stat=google-sheets-query-filtrer-par-plage-de-dates","title":{"rendered":"Requ\u00eate Google Sheets : comment filtrer par plage de dates"},"content":{"rendered":"

L’\u00e9cosyst\u00e8me contemporain du traitement de donn\u00e9es au sein des tableurs en ligne a \u00e9t\u00e9 profond\u00e9ment transform\u00e9 par l’int\u00e9gration d’outils analytiques avanc\u00e9s capables d’\u00e9muler la puissance des langages d\u00e9claratifs traditionnels. Parmi ces m\u00e9canismes, la fonction QUERY<\/strong> de Google Sheets<\/a> s’impose comme une pierre angulaire algorithmique incontournable. Elle permet aux analystes d’extraire, d’agr\u00e9ger et d’ordonner des volum\u00e9tries substantielles d’informations sans recourir \u00e0 des scripts proc\u00e9duraux complexes. N\u00e9anmoins, l’interaction entre ce moteur de requ\u00eate relationnelle et les dimensions temporelles repr\u00e9sente l’une des zones d’achoppement les plus ardues pour les praticiens de la manipulation de donn\u00e9es. La gestion des dates ne rel\u00e8ve pas d’une simple comparaison lexicale ou num\u00e9rique \u00e9l\u00e9mentaire ; elle exige une compr\u00e9hension exhaustive des strates d’abstraction sous-jacentes qui articulent l’interface utilisateur, le typage s\u00e9riel des cellules et la compilation de commandes quasi-SQL.<\/p>\n

Le filtrage par plage de dates constitue le paradigme d’interrogation le plus r\u00e9current et critique dans les contextes de production, qu’il s’agisse de mesurer la performance financi\u00e8re p\u00e9riodique, d’analyser le cycle de vie d’utilisateurs ou d’auditer des s\u00e9quences d’\u00e9v\u00e9nements transactionnels. Pourtant, les disparit\u00e9s de repr\u00e9sentations textuelles, les incompatibilit\u00e9s r\u00e9gionales entre les conventions francophones et anglo-saxonnes, ainsi que la nature stricte du compilateur textuel de l’API sous-jacente engendrent fr\u00e9quemment des erreurs d’interpr\u00e9tation silencieuses ou des blocages syntaxiques explicites. Ma\u00eetriser le filtrage temporel dans Google Sheets requiert donc de d\u00e9passer le cadre de l’intuition empirique pour aborder les fondements th\u00e9oriques de l’alg\u00e8bre relationnelle adapt\u00e9e aux tableurs en nuage.<\/p>\n

Ce trait\u00e9 exhaustif a pour ambition d’analyser avec une rigueur absolue l’ensemble des dynamiques gouvernant la s\u00e9lection, la d\u00e9limitation et la manipulation des intervalles temporels au moyen de la clause WHERE<\/code> de la fonction QUERY. De l’architecture bas niveau de l’API Google Visualization jusqu’aux optimisations complexes de calcul matriciel dynamique, chaque aspect sera examin\u00e9 \u00e0 la lumi\u00e8re de cas d’usage industriels, de d\u00e9compositions syntaxiques pas \u00e0 pas et de diagnostics pr\u00e9ventifs d’anomalies. \u00c0 travers ce guide m\u00e9thodologique approfondi, l’utilisateur d\u00e9couvrira comment forger des architectures de classeurs d’une r\u00e9silience irr\u00e9prochable face aux ambigu\u00eft\u00e9s chronologiques.<\/p>\n

1. Fondements conceptuels de la fonction QUERY et gestion temporelle dans Google Sheets<\/h2>\n

1.1 Architecture du moteur de calcul et API Google Visualization<\/h3>\n

L’impl\u00e9mentation de la fonction QUERY au sein de Google Sheets ne repose pas sur le moteur de calcul matriciel standard qui pilote les fonctions arithm\u00e9tiques natives telles que SOMME<\/code> ou RECHERCHEV<\/code>. Elle constitue en r\u00e9alit\u00e9 une passerelle directe vers le langage de requ\u00eate de l’API Google Visualization<\/a>. Cette architecture d\u00e9coupl\u00e9e implique que toute formule invoquant cette fonction transmet une matrice de donn\u00e9es brute ainsi qu’une cha\u00eene de caract\u00e8res repr\u00e9sentant une instruction formalis\u00e9e dans un dialecte sp\u00e9cifique, inspir\u00e9 du standard Structured Query Language (SQL). Le compilateur interne de cette API analyse la cha\u00eene textuelle de fa\u00e7on autonome, s\u00e9par\u00e9ment de la grille de calcul h\u00f4te, ce qui cr\u00e9e une fronti\u00e8re herm\u00e9tique entre les r\u00e8gles d’\u00e9valuation classiques du tableur et celles du processeur de requ\u00eates.<\/p>\n

Cette distinction structurelle engendre des r\u00e9percussions majeures sur le comportement du compilateur face aux valeurs temporelles. Alors qu’un tableur traditionnel interpr\u00e8te une date par r\u00e9f\u00e9rence directe \u00e0 sa cellule m\u00e9moire sous forme d’un nombre \u00e0 virgule flottante, le moteur Visualization exige des litt\u00e9raux d\u00e9claratifs strictement typ\u00e9s lorsqu’une comparaison est formul\u00e9e dans la commande textuelle. L’absence d’\u00e9valuation dynamique au niveau de la cha\u00eene impose au d\u00e9veloppeur de formaliser explicitement le type de donn\u00e9e manipul\u00e9 avant m\u00eame que la requ\u00eate ne soit compil\u00e9e et ex\u00e9cut\u00e9e sur les vecteurs d’entr\u00e9e.<\/p>\n

En outre, la localisation r\u00e9gionale du classeur influe sur la mani\u00e8re dont les arguments de la fonction sont d\u00e9limit\u00e9s (virgules ou points-virgules pour s\u00e9parer la plage source de la clause textuelle), mais elle n’alt\u00e8re en aucun cas la syntaxe interne de la requ\u00eate de visualisation. Ce d\u00e9couplage impose une discipline rigoureuse : l’utilisateur francophone doit composer avec des s\u00e9parateurs de fonctions conformes \u00e0 ses param\u00e8tres r\u00e9gionaux tout en maintenant une syntaxe de requ\u00eate invariante calqu\u00e9e sur des normes universelles anglo-saxonnes, garantissant ainsi l’interop\u00e9rabilit\u00e9 des structures de requ\u00eates \u00e0 travers diff\u00e9rents environnements d’ex\u00e9cution.<\/p>\n

1.2 La typologie interne des donn\u00e9es temporelles dans les feuilles de calcul<\/h3>\n

Pour appr\u00e9hender les subtilit\u00e9s du filtrage chronologique, il est imp\u00e9ratif de diss\u00e9quer la mani\u00e8re dont Google Sheets encode et stocke les entit\u00e9s temporelles au niveau binaire. \u00c0 l’instar des conventions \u00e9tablies par les tableurs historiques, Google Sheets repr\u00e9sente chaque instant sous la forme d’un nombre s\u00e9riel continu dont le point d’origine, ou \u00e9poque z\u00e9ro, est fix\u00e9 au 30 d\u00e9cembre 1899 \u00e0 minuit. Chaque unit\u00e9 enti\u00e8re incr\u00e9ment\u00e9e \u00e0 partir de ce pivot repr\u00e9sente un jour civil complet. Les fractions d\u00e9cimales associ\u00e9es quant \u00e0 elles quantifient l’\u00e9coulement des heures, minutes et secondes au sein de cette journ\u00e9e. Par exemple, la valeur s\u00e9rielle 44927 correspond rigoureusement au 1er janvier 2023, tandis que 44927,5 d\u00e9signe ce m\u00eame jour \u00e0 12h00 pr\u00e9cises.<\/p>\n

Il existe par cons\u00e9quent une divergence ontologique fondamentale entre l’affichage cosm\u00e9tique visible dans une cellule et la valeur scalaire sous-jacente inscrite dans la m\u00e9moire vive du tableur. Une date pr\u00e9sent\u00e9e sous le masque 01\/01\/2023<\/code> ou 1 Janvier 2023<\/code> n’est qu’une projection graphique superficielle r\u00e9gie par un masque de formatage num\u00e9rique. Lorsque ces donn\u00e9es sont transmises \u00e0 la fonction QUERY, le moteur de visualisation examine les valeurs scalaires tout en tentant d’inf\u00e9rer le type s\u00e9mantique dominant de chaque colonne. Cette \u00e9tape d’inf\u00e9rence constitue l’une des vuln\u00e9rabilit\u00e9s les plus critiques du traitement temporel.<\/p>\n

Le compilateur de l’API Visualization applique en effet une r\u00e8gle de majorit\u00e9 stricte : si une colonne contient un m\u00e9lange h\u00e9t\u00e9rog\u00e8ne de dates s\u00e9rielles valides et de cha\u00eenes de caract\u00e8res textuelles repr\u00e9sentant des dates mal saisies, le moteur d\u00e9termine le type exclusif de la colonne sur la base d’un \u00e9chantillonnage statistique majoritaire. Si le type ‘date’ est retenu, toute cellule contenant une cha\u00eene de caract\u00e8res sera impitoyablement convertie en valeur nulle (null) durant l’ex\u00e9cution de la requ\u00eate. R\u00e9ciproquement, si les textes pr\u00e9dominent, les num\u00e9ros de s\u00e9rie de dates seront interpr\u00e9t\u00e9s comme des entit\u00e9s textuelles ou corrompues, annihilant toute possibilit\u00e9 de filtrage chronologique par in\u00e9galit\u00e9 math\u00e9matique.<\/p>\n

1.3 N\u00e9cessit\u00e9 de la standardisation ISO 8601 pour les pr\u00e9dicats<\/h3>\n

D\u00e8s lors qu’une condition de s\u00e9lection temporelle est introduite dans la clause WHERE<\/code> d’une requ\u00eate QUERY, le compilateur de requ\u00eates refuse d’op\u00e9rer sur des formats locaux ambigus. La cha\u00eene de commande requiert l’adoption sans concession de la norme ISO 8601<\/a>, qui prescrit la s\u00e9quence ordonn\u00e9e Ann\u00e9e-Mois-Jour selon le mod\u00e8le yyyy-mm-dd<\/code>. Cette standardisation lexicographique stricte est la seule qui pr\u00e9munisse l’interpr\u00e9teur contre les confusions inh\u00e9rentes aux formats r\u00e9gionaux, \u00e0 l’image de la notation 03\/04\/2024<\/code> qui d\u00e9signe le 3 avril dans les territoires francophones et le 4 mars au sein des juridictions nord-am\u00e9ricaines.<\/p>\n

Dans la grammaire de l’API Google Visualization, l’introduction d’un litt\u00e9ral de date au sein du pr\u00e9dicat d’\u00e9valuation exige la pr\u00e9sence obligatoire du mot-cl\u00e9 date<\/code>, imm\u00e9diatement suivi de la valeur normalis\u00e9e encapsul\u00e9e entre apostrophes simples, respectant la structure formelle : date 'yyyy-mm-dd'<\/code>. Ce pr\u00e9fixe agit comme un op\u00e9rateur de coercition s\u00e9mantique pour l’analyseur syntaxique, lui signifiant que la cha\u00eene de caract\u00e8res subs\u00e9quente ne doit pas \u00eatre trait\u00e9e comme un objet textuel ordinaire, mais instanci\u00e9e en tant qu’objet temporel absolu dans l’espace de comparaison relationnelle.<\/p>\n

L’omission de ce mot-cl\u00e9 d\u00e9claratif ou la transmission d’une date format\u00e9e selon le sch\u00e9ma fran\u00e7ais conventionnel (par exemple WHERE A > '31\/12\/2023'<\/code>) provoque une rupture d’int\u00e9grit\u00e9 imm\u00e9diate du processus de compilation. Dans un tel cas de figure, l’analyseur syntaxique traite l’expression comme une comparaison lexicographique bas\u00e9e sur la table des caract\u00e8res ASCII ou Unicode. Cons\u00e9quemment, la valeur ’01\/01\/2024′ serait paradoxalement \u00e9valu\u00e9e comme inf\u00e9rieure \u00e0 ’31\/12\/2023′ simplement parce que le caract\u00e8re ‘0’ pr\u00e9c\u00e8de num\u00e9riquement le caract\u00e8re ‘3’. L’adh\u00e9sion rigide au format ISO 8601 coupl\u00e9e au mot-cl\u00e9 date<\/code> constitue donc le seul garant d’une \u00e9valuation chronologique valide.<\/p>\n

2. Anatomie de la syntaxe de base pour le filtrage par date<\/h2>\n

2.1 D\u00e9composition de la formule canonique de requ\u00eate temporelle<\/h3>\n

L’invocation d’un filtrage temporel au sein d’une feuille de calcul Google Sheets requiert une ma\u00eetrise formelle de la structure d’appel de la fonction QUERY. La signature canonique de cette fonction s’\u00e9nonce selon le sch\u00e9ma formel =QUERY(donn\u00e9es; requ\u00eate; [en_t\u00eates])<\/code>. Le premier argument d\u00e9finit l’espace matriciel bidimensionnel source, tandis que le second h\u00e9berge la directive de traitement sous forme d’une cha\u00eene textuelle continue. Le troisi\u00e8me param\u00e8tre, optionnel mais hautement recommand\u00e9 pour des imp\u00e9ratifs de d\u00e9terminisme, explicite le nombre de rang\u00e9es constituant l’en-t\u00eate de la table source.<\/p>\n

Pour construire une condition temporelle au sein de la clause WHERE<\/code>, le d\u00e9veloppeur doit op\u00e9rer une imbrication m\u00e9ticuleuse de d\u00e9limiteurs textuels. Au sein de la cha\u00eene de requ\u00eate globale d\u00e9limit\u00e9e par des guillemets doubles standard, le pr\u00e9dicat chronologique s’exprime ainsi :<\/p>\n

=QUERY(A1:D100; \"SELECT * WHERE A >= date '2023-01-01'\"; 1)<\/code><\/p>\n

Dans cette expression fondamentale, le mot-cl\u00e9 date<\/code> ordonne au processeur de cr\u00e9er un objet temporel abstrait. Les apostrophes simples ceinturant la cha\u00eene 2023-01-01<\/code> permettent d’isoler la valeur scalaire de la date sans clore pr\u00e9matur\u00e9ment la cha\u00eene globale d\u00e9limit\u00e9e par les guillemets droits externes. Cette hi\u00e9rarchisation des d\u00e9limiteurs est imp\u00e9rative : toute collision entre des guillemets de m\u00eame niveau sans s\u00e9quences d’\u00e9chappement adapt\u00e9es engendre une exception de type PARSE_ERROR<\/code> d\u00e8s l’\u00e9valuation lexicale initiale.<\/p>\n

\"\"<\/figure>\n

Lorsque la date pivot n’est pas cod\u00e9e en dur sous forme de constante textuelle mais provient d’une \u00e9valuation dynamique ou d’une r\u00e9f\u00e9rence externe, l’op\u00e9rateur de concat\u00e9nation perlu\u00e8te (&<\/code>) intervient pour fragmenter la cha\u00eene de requ\u00eate principale. Le maintien de l’int\u00e9grit\u00e9 de la syntaxe finale exige que les apostrophes simples subsistent de part et d’autre de la valeur inject\u00e9e dynamiquement, ce qui conduit \u00e0 des formulations hautement compartiment\u00e9es de type \"SELECT * WHERE A >= date '\" & [Expression_Date] & \"'\"<\/code>. La pr\u00e9cision du positionnement de chaque caract\u00e8re d’espacement et de d\u00e9limitation conditionne l’acceptation de l’instruction par la grammaire de l’API.<\/p>\n

2.2 R\u00f4le et interaction des fonctions auxiliaires TEXTE et DATEVAL<\/h3>\n

Dans les contextes d’automatisation avanc\u00e9e, les dates servant de bornes de filtrage r\u00e9sident presque invariablement au sein de cellules satellites ou \u00e9mergent du calcul de fonctions tierces. D\u00e8s lors, l’interaction directe entre ces valeurs et la fonction QUERY requiert l’intervention de fonctions de s\u00e9rialisation et de transcodage, principalement les fonctions TEXTE<\/strong> et DATEVAL<\/strong>.<\/p>\n

La fonction DATEVAL<\/code> accomplit la conversion fondamentale d’une repr\u00e9sentation textuelle humaine en une valeur s\u00e9rielle enti\u00e8re propre \u00e0 Google Sheets. Elle neutralise les scories de formatage et assure l’homog\u00e9n\u00e9isation d’une cha\u00eene brute en un point fixe sur l’axe chronologique. R\u00e9ciproquement, la fonction TEXTE<\/code> r\u00e9alise l’op\u00e9ration inverse, absolument fondamentale pour la composition de requ\u00eates QUERY dynamiques : elle saisit une valeur temporelle s\u00e9rielle et force sa projection dans un gabarit textuel universel strictement contr\u00f4l\u00e9 au moyen de son second argument formel.<\/p>\n

Ainsi, l’assemblage TEXTE(F1; \"yyyy-mm-dd\")<\/code> extrait la valeur contenue dans la cellule F1<\/code> et garantit qu’elle sera restitu\u00e9e sous la structure normalis\u00e9e ISO 8601 requise par l’API Visualization, ind\u00e9pendamment de la mani\u00e8re dont la date est affich\u00e9e visuellement dans F1<\/code>. L’utilisation d\u00e9lib\u00e9r\u00e9e des caract\u00e8res de masquage yyyy-mm-dd<\/code> (ou aaaa-mm-jj<\/code> selon les sp\u00e9cificit\u00e9s de la langue du syst\u00e8me d’exploitation) au sein de la fonction TEXTE permet de garantir que les composantes du mois et du jour seront toujours compl\u00e9t\u00e9es par un z\u00e9ro initial (par exemple 05<\/code> au lieu de 5<\/code>), respectant scrupuleusement la longueur de dix caract\u00e8res obligatoire pour le parseur de l’API.<\/p>\n

Dans les environnements configur\u00e9s en langue fran\u00e7aise, le s\u00e9parateur syntaxique des arguments au sein des fonctions est le point-virgule (;<\/code>), tandis que la requ\u00eate interne QUERY conserve une nomenclature universelle. L’imbrication m\u00e9thodique s’articule comme suit :<\/p>\n

=QUERY(A1:E; \"SELECT * WHERE B > date '\" & TEXTE(F1; \"yyyy-mm-dd\") & \"'\"; 1)<\/code><\/p>\n

Ce sch\u00e9ma d’interfa\u00e7age constitue le m\u00e9canisme d’ing\u00e9nierie le plus robuste pour pr\u00e9venir toute distorsion temporelle lors du passage des fronti\u00e8res d’\u00e9valuation logicielle.<\/p>\n

2.3 S\u00e9mantique de l’op\u00e9rateur d’\u00e9valuation WHERE<\/h3>\n

La clause WHERE<\/code> constitue le c\u0153ur logique de restriction au sein de l’alg\u00e8bre relationnelle support\u00e9e par la fonction QUERY. Son r\u00f4le consiste \u00e0 it\u00e9rer virtuellement sur chaque tuple (rang\u00e9e) de la matrice de donn\u00e9es et d’appliquer une fonction d’\u00e9valuation bool\u00e9enne sur la colonne sp\u00e9cifi\u00e9e. Seules les rang\u00e9es pour lesquelles le pr\u00e9dicat s’\u00e9value \u00e0 TRUE<\/code> sont conserv\u00e9es dans le flux de sortie matriciel.<\/p>\n

Lorsque la colonne cible contient des valeurs vides ou non d\u00e9finies (marqu\u00e9es conceptuellement par l’\u00e9tat null<\/code>), le compilateur applique les principes stricts de la logique ternaire propre aux bases de donn\u00e9es relationnelles. Toute comparaison temporelle impliquant une cellule vide \u2014 qu’il s’agisse d’une inf\u00e9riorit\u00e9, d’une sup\u00e9riorit\u00e9 ou m\u00eame d’une \u00e9galit\u00e9 stricte \u2014 renvoie syst\u00e9matiquement la valeur UNKNOWN<\/code>. En vertu des r\u00e8gles d’exclusion de la clause WHERE<\/code>, les rang\u00e9es dont le r\u00e9sultat d’\u00e9valuation n’est pas strictement TRUE<\/code> sont automatiquement rejet\u00e9es. Cela implique que les lignes poss\u00e9dant des cases temporelles vierges ne seront jamais int\u00e9gr\u00e9es dans le r\u00e9sultat, pr\u00e9venant ainsi les contaminations de donn\u00e9es r\u00e9siduelles sans exiger l’ajout syst\u00e9matique d’une condition AND A IS NOT NULL<\/code>, bien que cette derni\u00e8re puisse demeurer utile pour des raisons de documentation explicite de la logique d’affaires.<\/p>\n

L’\u00e9valuation des op\u00e9rateurs logiques dans la clause WHERE<\/code> respecte une hi\u00e9rarchie stricte de pr\u00e9c\u00e9dence op\u00e9ratoire. Les comparaisons scalaires \u00e9l\u00e9mentaires (=<\/code>, <<\/code>, ><\/code>, <=<\/code>, >=<\/code>, !=<\/code>) sont r\u00e9solues en premier lieu, suivies par l’op\u00e9rateur de n\u00e9gation NOT<\/code>, puis par l’op\u00e9rateur de conjonction AND<\/code>, et enfin par la disjonction OR<\/code>. L’incompr\u00e9hension de cette table de priorit\u00e9 peut conduire \u00e0 des catastrophes logiques lors de requ\u00eates temporelles complexes combinant des filtres de dates et des segmentations cat\u00e9gorielles, rendant l’usage des parenth\u00e8ses groupantes non seulement vertueux mais architecturalement indispensable.<\/p>\n

3. Filtrage des enregistrements ant\u00e9rieurs \u00e0 une date d\u00e9finie<\/h2>\n

3.1 Mise en \u0153uvre de l’op\u00e9rateur d’inf\u00e9riorit\u00e9 stricte (<)<\/h3>\n

Le filtrage d’ant\u00e9riorit\u00e9 stricte r\u00e9pond \u00e0 la n\u00e9cessit\u00e9 d’isoler des donn\u00e9es historiques closes, en \u00e9cartant m\u00e9thodiquement tout enregistrement survenu \u00e0 compter du point de d\u00e9marcation temporel s\u00e9lectionn\u00e9. L’op\u00e9rateur math\u00e9matique d\u00e9di\u00e9 \u00e0 cette restriction est le symbole d’inf\u00e9riorit\u00e9 stricte <<\/code>. La formulation syntaxique standard au sein du compilateur s’articule sous la forme :<\/p>\n

WHERE A < date 'yyyy-mm-dd'<\/code><\/p>\n

Cette condition instruit le moteur de calcul de v\u00e9rifier si la valeur s\u00e9rielle inscrite dans la colonne A<\/code> est strictement inf\u00e9rieure au num\u00e9ro de s\u00e9rie \u00e9quivalent \u00e0 minuit (00:00:00.000) au jour sp\u00e9cifi\u00e9. Cette pr\u00e9cision math\u00e9matique sur l’heure implicite est d\u00e9terminante lorsque les donn\u00e9es d’entr\u00e9e comportent des horodatages continus (timestamps) g\u00e9n\u00e9r\u00e9s par des syst\u00e8mes automatis\u00e9s ou des formulaires d’acquisition de donn\u00e9es.<\/p>\n

Consid\u00e9rons un enregistrement dont la date d’acquisition est le 2023-05-15 08:30:00<\/code>. Si le pr\u00e9dicat de la requ\u00eate est formul\u00e9 sous la modalit\u00e9 WHERE A < date '2023-05-15'<\/code>, l’enregistrement sera exclu de mani\u00e8re cat\u00e9gorique du jeu de r\u00e9sultats. Bien que le jour calendaire corresponde formellement au 15 mai 2023, la date sp\u00e9cifi\u00e9e sans pr\u00e9cision horaire correspond canoniquement au 2023-05-15 00:00:00<\/code>. Sur le plan de la droite r\u00e9elle, la valeur s\u00e9rielle de l’\u00e9v\u00e9nement (environ 45061,354) d\u00e9passe strictement la borne d’exclusion (45061,000). Il est donc vital d’int\u00e9grer que l’inf\u00e9riorit\u00e9 stricte \u00e0 une date donn\u00e9e exclut par d\u00e9finition l’int\u00e9gralit\u00e9 de la journ\u00e9e d\u00e9sign\u00e9e par ladite date d\u00e8s le premier milli\u00e8me de seconde qui suit minuit.<\/p>\n

Ce comportement est particuli\u00e8rement adapt\u00e9 pour les sc\u00e9narios de cl\u00f4ture comptable mensuelle ou d’archivage l\u00e9gal, o\u00f9 une partition nette doit \u00eatre op\u00e9r\u00e9e entre les exercices r\u00e9volus et les transactions d’une p\u00e9riode courante d\u00e9butant \u00e0 un jour pr\u00e9cis.<\/p>\n

3.2 Mise en \u0153uvre de l’op\u00e9rateur d’ant\u00e9riorit\u00e9 inclusive (<=)<\/h3>\n

\u00c0 l’inverse de la s\u00e9lection stricte, l’op\u00e9rateur de comparaison d’ant\u00e9riorit\u00e9 inclusive <=<\/code> permet d’englober la borne sup\u00e9rieure au sein de l’\u00e9chantillon extrait. Sa syntaxe g\u00e9n\u00e9rale s’\u00e9tablit comme suit :<\/p>\n

WHERE A <= date 'yyyy-mm-dd'<\/code><\/p>\n

L’usage de ce comparateur au sein des bases de donn\u00e9es de tableur pr\u00e9sente toutefois un risque technique majeur li\u00e9 \u00e0 la nature continue du temps par rapport \u00e0 la granularit\u00e9 discr\u00e8te des calendriers administratifs. Si la colonne examin\u00e9e h\u00e9berge des dates pures (c’est-\u00e0-dire dont la fraction d\u00e9cimale de la valeur s\u00e9rielle est rigoureusement \u00e9gale \u00e0 z\u00e9ro), l’instruction WHERE A <= date '2023-12-31'<\/code> int\u00e9grera sans distorsion l’ensemble des \u00e9v\u00e9nements rattach\u00e9s au 31 d\u00e9cembre.<\/p>\n

Cependant, si la source de donn\u00e9es incorpore des horodatages d\u00e9taill\u00e9s, la comparaison inclusive r\u00e9v\u00e9lera un comportement trompeur pour l’analyste non averti. \u00c9tant donn\u00e9 que le litt\u00e9ral date '2023-12-31'<\/code> s’\u00e9value conceptuellement \u00e0 2023-12-31 00:00:00<\/code>, tout \u00e9v\u00e9nement survenu au cours de cette m\u00eame journ\u00e9e \u2014 par exemple \u00e0 14h15 \u2014 poss\u00e8dera une composante s\u00e9rielle sup\u00e9rieure \u00e0 la borne. L’\u00e9v\u00e9nement sera donc rejet\u00e9, en d\u00e9pit de l’apparence inclusive du comparateur <=<\/code>. Pour capturer v\u00e9ritablement l’int\u00e9gralit\u00e9 d’une journ\u00e9e charni\u00e8re contenant des horodatages continus, la rigueur analytique impose d’ajuster l’\u00e9quation selon deux approches :<\/p>\n