Cartes.gouv.fr vs Google Maps : quand et comment tester sur votre site

Préparation : éléments à vérifier et configuration du prototype WordPress

Vérifications obligatoires côté portail

Avant tout test, consultez la documentation officielle du portail pour confirmer cinq éléments : la licence et ses restrictions d’usage (redistribution, usage commercial, obligations d’attribution), le mode d’authentification et les quotas (clé API, restrictions de referer ou d’IP), les spécifications techniques (formats de tuiles pris en charge comme XYZ/TileJSON, projection - vérifiez la compatibilité EPSG:3857 pour le web - et endpoints pour tuiles, géocodage et routage), la localisation et la tenue des logs (hébergement des serveurs, politique de conservation) et enfin l’existence éventuelle d’un contrat pro/SLA ou d’un support dédié pour usages professionnels.

Choix techniques pour WordPress

Pour un prototype, privilégiez une intégration minimale et contrôlée : utiliser Leaflet comme bibliothèque front (léger, compatible avec les tuiles XYZ/TileJSON) et l’enregistrer via enqueue dans le thème ou via un shortcode. Préparez un site de staging cloné avec des pages représentatives du site de production qui chargent des cartes et des marqueurs. Configurez un cache HTTP pour les tuiles (headers Cache‑Control) et planifiez un reverse cache si nécessaire, tout en vérifiant la politique du portail sur le caching. Sécurisez les échanges (HTTPS obligatoire), restreignez la clé API au referer ou à l’IP et documentez précisément quelles données utilisateur sont transmises aux APIs (adresses saisies, IPs). Enfin, réunissez les outils de mesure : Chrome DevTools, Lighthouse pour l’expérience et des scripts d’automatisation comme sitespeed ou k6 pour la charge.

Plan de test initial

Créez une clé de test isolée du prod, intégrez une carte Leaflet pointant vers l’URL de tuiles du portail, testez géocodage et routage via appels séparés et capturez les formats (JSON/GeoJSON). Notez tout comportement CORS, erreurs 4xx/5xx et limites observées. Ce prototype doit rester simple : une page qui reproduit le flux réel (chargement initial, affichage de marqueurs, requête de géocodage) et des scripts qui automatisent 10-30 répétitions des mêmes parcours pour obtenir des métriques comparables avec Google Maps.

Agrandir

Checklist rapide et prioritaire pour un test opérationnel

En une heure sur votre staging, priorisez ces contrôles : vérifiez qu’une tuile s’affiche correctement en EPSG:3857 (pas de distorsion), contrôlez l’absence d’erreurs CORS et que toutes les requêtes transitent en HTTPS, validez l’intégration Leaflet minimale (carte + markers), exécutez un géocodage simple et capturez la réponse JSON, vérifiez les en‑têtes Cache‑Control sur les tuiles, simulez des requêtes répétées pour repérer un throttling ou des quotas et mesurez les métriques clés via DevTools (TTFB et nombre de requêtes à la première ouverture). Lisez les conditions d’utilisation pour confirmer l’autorisation d’usage commercial et de mise en cache. Si un de ces points échoue, documentez précisément l’erreur et signalez‑la au client : pour des flux critiques, il peut être plus prudent de maintenir Google Maps ou un autre fournisseur jusqu’à résolution.

Scénarios de test détaillés et comparaison métier avec Google Maps

Scénarios fonctionnels à couvrir

• Affichage cartographique : carte zoomable, couches multiples, tuiles raster et vectorielles si disponibles, rendu des markers et clusters et comportement responsive.
• Requêtes d’API : géocodage (adresse → coordonnées), reverse geocoding, itinéraire simple (A→B) et recherche de lieux/POI si l’API le propose.
• Édition et export : capacité à récupérer et réutiliser GeoJSON pour stockage local et réaffichage côté client.
• Modes dégradés : affichage depuis cache en cas d’absence d’accès à l’API et messages utilisateurs en cas d’erreur.

Métriques techniques et critères d’acceptation

Pour chaque scénario, mesurez la performance (temps jusqu’au premier tile visible, temps de rendu des marqueurs et time to interactive), la résilience (taux d’erreurs HTTP sur un jeu de 1 000 requêtes, comportement à l’atteinte des quotas et latence sous charge via k6 ou locust) et la prévisibilité des coûts en se fondant uniquement sur les modèles tarifaires publiés par les deux fournisseurs. Évaluez aussi la conformité et la confidentialité selon la documentation officielle : localisation des données, politique de logs, durée de conservation et accords de sous‑traitance, afin d’estimer la compatibilité RGPD pour les traitements d’adresses et d’IP. Enfin, notez l’intégration opérationnelle : qualité de la documentation, existence d’exemples et support pro/SLA.

Méthode de comparaison pratique

Exécutez chaque scénario dans le même environnement réseau et navigateur, répétez 10 à 30 fois pour lisser la variabilité, consignez les HAR et captures réseau, et alimentez un tableau de bord simple où chaque fonctionnalité est associée à un script de test, aux résultats pour Cartes.gouv.fr et à ceux pour Google Maps, plus une colonne « risque/impact ». Décision métier : retenez Cartes.gouv.fr si la parité fonctionnelle est atteinte, les coûts sont maîtrisables d’après les tarifs officiels et la localisation/contrat correspond à l’exigence de souveraineté ; sinon optez pour une stratégie hybride avec fallback vers Google pour les services critiques.

Conclusion : déroulé recommandé et points de décision

Procédez en trois étapes : d’abord un audit documentaire officiel (licence, endpoints, SLA, tarification, hébergement) ; puis un prototype WordPress sur staging (Leaflet + tuiles + géocodage + cache) avec les tests rapides décrits ; enfin une campagne de bench et une comparaison métier documentée (performance, coût estimé selon tarifs publiés, conformité). Si les critères essentiels sont satisfaits, lancez un pilote client limité avec clause de retour arrière et règles de monitoring ; sinon documentez l’écart et retenez une intégration hybride en attendant l’évolution du portail. Formalisez la décision par un rapport listant risques, coûts et plan de migration pour le client.