- La fonction QUERY de Google Sheets ressemble à du SQL sans en être : trois différences précises expliquent la quasi-totalité des messages d’erreur.
- Les clauses s’écrivent dans un ordre imposé. Inverser deux d’entre elles produit une erreur, même si chacune est correcte.
- Une colonne qui mélange des nombres et du texte fait disparaître silencieusement les valeurs minoritaires, sans aucun avertissement.
- Les dates et les valeurs prises dans une cellule ont chacune une syntaxe précise, qui ne s’improvise pas et qui n’a pas d’équivalent intuitif.
Ce n’est pas du SQL, et c’est tout le problème
Les présentations de QUERY commencent presque toutes de la même façon : « une fonction qui permet d’interroger un tableau comme une base de données, avec un langage proche du SQL ». La comparaison est juste, et c’est précisément elle qui fait échouer ceux qui connaissent un peu de SQL.
Le langage employé est celui de l’API de visualisation de Google, un sous-ensemble volontairement réduit. Il en reprend les mots, pas le comportement. Trois écarts suffisent à expliquer la plupart des blocages : les colonnes se désignent par leur lettre et non par leur nom, l’ordre des clauses n’est pas libre, et une colonne doit contenir un seul type de données.
Aucun des trois ne produit un message d’erreur explicite. Deux produisent une erreur incompréhensible, le troisième ne produit rien du tout, ce qui est bien pire.
Les clauses, dans un ordre qui n’est pas négociable
Une requête s’écrit en une chaîne de caractères entre guillemets, en deuxième argument de la fonction. Les clauses utilisées doivent s’y succéder dans un ordre fixe.
Une requête complète ressemble donc à ceci, appliquée à une plage qui commence en A1 :
=QUERY(A1:E200; "select B, D where D > 100 order by D desc limit 10"; 1)
Le troisième argument mérite plus d’attention qu’il n’en reçoit : il indique le nombre de lignes d’en-tête. Laissé vide, Google devine, et il devine parfois qu’une ligne de données est un en-tête, ce qui décale tout le résultat. Le renseigner explicitement supprime une catégorie entière de comportements bizarres.
Vos colonnes n’ont pas de nom
Sur un tableau de suivi de projet, où l’on insère des colonnes au fil de l’eau, c’est le premier piège rencontré. C’est l’écart le plus déroutant pour qui vient du SQL. Même si la première ligne du tableau contient des intitulés parfaitement clairs, la requête ne les connaît pas : elle désigne les colonnes par leur lettre dans la feuille, A, B, C, indépendamment du début de la plage interrogée.
Deux conséquences pratiques. D’abord, insérer une colonne au milieu du tableau décale toutes les lettres et casse silencieusement les requêtes existantes, qui continuent de fonctionner en renvoyant les mauvaises données. Ensuite, les intitulés ne servent qu’à l’affichage du résultat, jamais à la sélection.
Un cas particulier revient souvent : quand la plage vient d’une autre feuille via une importation, les colonnes ne s’appellent plus A, B, C mais Col1, Col2, Col3, numérotées à partir du début de la plage importée. La requête doit alors être entièrement réécrite avec cette notation, et c’est la source d’erreur la plus fréquente sur les requêtes qui traversent plusieurs fichiers.
La colonne à types mélangés, le piège qui ne dit rien
Celui-ci ne renvoie aucune erreur, ne colore rien en rouge, et fait perdre des heures. Il repose sur une règle simple : une colonne ne peut avoir qu’un seul type pour QUERY, nombre ou texte, et jamais les deux.
Quand une colonne contient les deux, Google tranche selon la majorité et remplace les valeurs minoritaires par des cases vides. Une colonne de trois cents montants dont douze ont été saisis avec un espace ou une unité perd ces douze lignes, sans le signaler. Le total obtenu est faux, et rien ne l’indique.
Le contrôle est immédiat : sélectionnez la colonne dans la feuille d’origine et regardez l’alignement par défaut des cellules. Les nombres se calent à droite, le texte à gauche. Une colonne censée être numérique où quelques valeurs traînent à gauche annonce exactement ce problème.
La réparation passe par la colonne source, pas par la requête. Retirer les espaces, les unités et les tirets, puis reformater la colonne entière en nombre, résout la situation définitivement. Contourner par une fonction de conversion à l’intérieur de la requête reporte le problème sans le traiter.
Les dates et les valeurs de cellules, deux syntaxes qu’on n’invente pas
Ce sont les deux écritures qu’aucune intuition ne permet de retrouver, et elles reviennent dans presque toutes les requêtes utiles.
Une date se compare en la précédant du mot date et en l’écrivant entre apostrophes, au format année, mois, jour :
=QUERY(A1:E200; "select A, C where B >= date '2026-08-01'"; 1)
Écrite autrement, la comparaison échoue ou ne renvoie rien. Le format français, jour puis mois, n’est jamais accepté à cet endroit, même si la feuille affiche les dates ainsi.
Pour comparer à une valeur saisie dans une cellule, la requête doit être coupée et recollée autour de la référence, puisque le contenu de la chaîne n’est pas interprété :
=QUERY(A1:E200; "select A, C where B = '" & G1 & "'"; 1)
Les apostrophes encadrent la valeur si elle est du texte, et disparaissent si elle est un nombre. C’est la nuance qui coûte le plus de tentatives, et elle se retient mieux en se disant que l’on fabrique une phrase à trous plutôt qu’en cherchant une logique de langage de requête.
Vérifier qu’une requête rend ce que vous croyez
Une requête qui affiche un tableau plausible n’est pas une requête juste. Trois contrôles suffisent à faire la différence, et ils prennent moins de temps que de constater l’erreur trois semaines plus tard.
- Comptez les lignes du résultat et comparez ce nombre à un décompte fait autrement, avec un filtre posé à la main sur les données d’origine. Un écart désigne presque toujours une colonne à types mélangés.
- Retirez temporairement la clause de filtrage et vérifiez que le nombre total correspond bien à la taille de la plage. Cela révèle les lignes d’en-tête mal comptées.
- Modifiez une valeur dans les données source et regardez si le résultat bouge. Une requête qui ne réagit pas pointe sur une plage plus étroite que prévu.
Prenez l’habitude de désigner des plages entières de colonnes plutôt que des plages arrêtées à une ligne précise. Une plage arrêtée à la ligne deux cents ignore la deux cent unième le jour où elle est saisie, en silence, et personne ne remonte jamais à la formule pour vérifier.
Quinze ans de support informatique en entreprise, du helpdesk à l'administration système. J'ai traité des milliers de tickets et constaté que les mêmes problèmes revenaient en boucle. J'écris ici les réponses que je donnais au téléphone.