Dates des avis Google Maps : pourquoi « il y a un mois » pose problème, et comment le gérer

Si vous avez déjà exporté des avis Google Maps et essayé de les trier par date, vous avez rencontré le problème : les dates ne sont pas des dates. Ce sont des formules comme « il y a un mois », « il y a 2 semaines », « il y a un an ». Un tableur ne peut pas les trier, un graphique ne peut pas les représenter, et un outil naïf va soit les ignorer, soit, pire, en inventer une. C’est un petit problème qui, silencieusement, gâche une bonne partie de l’analyse des avis, et il mérite donc d’être bien compris.

Ce que Google affiche réellement

Google Maps n’affiche pas de date calendaire sur un avis. Il affiche une formule relative et arrondie : depuis combien de temps l’avis a été publié, exprimé dans l’unité la plus pratique. « Hier », « il y a 3 jours », « il y a 2 semaines », « il y a un mois », « il y a un an ».

Google conserve un horodatage précis pour chaque avis en interne. Mais le panneau d’avis public, ce que voit un visiteur et ce que lit une extension de navigateur, n’affiche que la formule arrondie. Tout ce que vous construisez à partir des avis Google Maps hérite de cette contrainte. Vous travaillez avec « il y a un mois », pas avec 2026-06-14.

Pourquoi cela complique l’analyse

Les dates relatives posent problème dès que vous voulez faire quoi que ce soit lié au temps :

• Vous ne pouvez pas les trier. « Il y a un mois » et « il y a 2 semaines » ne se classent pas correctement en tant que texte, et un tableur n’a aucun moyen de savoir qu’il s’agit même de dates.
• Vous ne pouvez pas regrouper par période. « Avis par mois » devient impossible quand chaque date est une formule floue.
• Elles se périment. La formule est relative au moment où elle a été capturée. « Il y a un mois », exporté aujourd’hui, ne signifie pas la même chose que « il y a un mois » exporté le trimestre prochain. Si vous stockez uniquement la formule, vos données se désynchronisent silencieusement.

Ce dernier point est le plus subtil. Une colonne de formules relatives n’est pas seulement difficile à trier, elle devient activement trompeuse avec le temps, parce que son sens dépend d’un « maintenant » qui a changé.

La mauvaise solution : inventer de la précision

La solution tentante consiste à convertir « il y a un mois » en une vraie date et à passer à autre chose. Prendre la date de capture, soustraire un mois, écrire 2026-06-24, et continuer.

C’est pire que de ne rien faire, car cela transforme une estimation grossière en fausse précision. « Il y a un mois » peut correspondre à n’importe quoi entre trois et six semaines. Écrire un jour exact laisse croire que vous savez quelque chose que vous ignorez, et quiconque en aval verra une date calendaire propre et la traitera comme fiable. Quand cette personne mettra plus tard en corrélation les avis avec le lancement d’un produit ou un incident, elle établira une corrélation avec de la fiction. Un outil qui vous montre des dates exactes pour des formules relatives ne vous rend pas service : il vous cache sa propre incertitude.

La solution honnête : deux colonnes

L’approche qui fonctionne réellement conserve les deux informations et indique clairement laquelle est laquelle.

Première colonne : la formule exacte. Conservez « il y a un mois » mot pour mot, ainsi que la date à laquelle vous l’avez capturée. C’est la vérité de base. Elle ne ment jamais, et comme vous avez gardé la date de capture, « il y a un mois » reste interprétable quel que soit le moment où vous relisez le fichier.

Deuxième colonne : une estimation identifiée comme telle. Calculez une date calendaire au mieux à partir de la formule et de la date de capture, et indiquez clairement que la colonne est approximative. Vous pouvez alors trier, regrouper et représenter graphiquement, tandis que quiconque lit le fichier voit d’un coup d’œil qu’il s’agit d’estimations, et non des horodatages de Google.

L’estimation est naturellement plus précise pour les avis récents et plus large pour les anciens. « Il y a trois jours » situe un avis à un jour précis. « Il y a un an » peut correspondre à n’importe quel moment sur une fourchette de quelques mois. Ce dégradé n’est pas un problème, car il correspond au niveau de précision dont on a généralement besoin : les avis récents, ceux qu’on veut réellement placer sur une chronologie, sont justement ceux pour lesquels l’estimation est la plus fiable.

Ce qu’il faut vérifier dans un outil

Quand vous évaluez une extension d’export Google Maps, c’est un test rapide et révélateur. Exportez un établissement et regardez les colonnes de dates.

• Si vous voyez une seule colonne de dates calendaires précises, l’outil invente de la précision. Méfiez-vous alors de tout ce qu’il produit par ailleurs.
• Si la formule relative a complètement disparu, vous avez perdu la vérité de base et vous ne pouvez plus vérifier les estimations.
• Si vous voyez à la fois la formule d’origine et une estimation clairement identifiée, l’outil est honnête avec vous, ce qui est exactement le comportement que vous devriez rechercher partout ailleurs.

L’export Google Maps d’ExportReviews adopte l’approche à deux colonnes : la formulation exacte affichée par Google dans un champ, une estimation identifiée comme telle dans un autre. C’est un détail qui en dit long sur le respect, par un outil, de la différence entre ce qu’il sait et ce qu’il devine.

Ce qu’il faut retenir

Les dates relatives ne sont pas une nuisance à camoufler ; elles sont une limite réelle de ce que Google Maps expose, et la bonne réponse consiste à être honnête sur cette limite plutôt qu’à la dissimuler. Conservez la formule, estimez-la en complément, identifiez clairement l’estimation. Tout outil qui fait autrement échange votre capacité à faire confiance aux données contre le gain cosmétique d’une colonne de dates bien nette. Pour le reste du processus d’export, consultez le guide pas à pas.