Le problème IGN/Géoportail apparaît quand une carte officielle, une adresse BAN, une parcelle, un itinéraire, une isochrone ou une altitude devient une décision métier sans que le SI conserve la source, la date, la limite et la preuve.
Le vrai enjeu consiste à traiter les services de la Géoplateforme comme des contrats de production: WMS, WMTS, WFS, TMS, géocodage, autocomplétion, itinéraire, isochrone, isodistance, altimétrie, recherche, validation et statistiques ne portent pas le même risque.
Vous allez comprendre comment relier l'héritage Géoportail, les services actuels de cartes.gouv.fr, les référentiels IGN, les clés d'accès, les limites de requêtes, les données BAN, BD TOPO, Parcellaire Express, RGE ALTI et BD ALTI au run d'un système métier.
Contrairement à ce que laisse croire une simple couche cartographique, le risque est de confondre affichage public et preuve opérationnelle. Le signal faible apparaît quand les équipes corrigent des cartes, exports ou adresses sans savoir quel service a vraiment fait foi.
Pour cadrer cette architecture, notre accompagnement en intégration API aide à relier IGN/Géoplateforme, SIG, back-office, datawarehouse, outils terrain, support et monitoring. Le sujet se rattache aussi au guide API cartographie et géolocalisation, à la landing API cartographie et géolocalisation et à la page intégrateur IGN Géoportail.
Pour qui IGN/Géoportail mérite un connecteur
Identifier les usages dépendants du territoire français
IGN/Géoportail mérite un connecteur pour les collectivités, réseaux d'infrastructure, acteurs énergie, immobilier, assurances, mobilité locale, environnement, tourisme, secours, gestion patrimoniale et applications qui doivent exploiter des données géographiques françaises de référence.
Dans ces contextes, la carte n'est pas seulement une interface. Elle porte une parcelle, une adresse, un accès terrain, une zone de compétence, une altimétrie, un itinéraire ou une couche réglementaire qui peut changer une décision.
Le signal de priorité apparaît quand un écart géographique modifie une autorisation, une intervention, un devis, une tournée ou une donnée publique. Si le seuil de 2 % d'objets contestés sur 30 jours est dépassé, alors le connecteur doit être industrialisé.
Par exemple, un gestionnaire de réseau qui localise des équipements sensibles doit pouvoir distinguer l'affichage d'une couche, la donnée source utilisée pour l'analyse et la décision qui déclenche une intervention terrain.
Séparer visualisation, calcul et donnée de référence
Une couche WMTS peut suffire à afficher un fond cartographique, mais elle ne prouve pas la même chose qu'une réponse WFS, un géocodage, un calcul altimétrique ou une route issue d'un graphe routier.
Cette séparation évite de faire porter à l'affichage une responsabilité de décision. Le front peut montrer une carte, tandis que le backend garde la preuve, les identifiants, les paramètres et les règles de rapprochement.
Le bon arbitrage consiste à choisir le service IGN selon l'action: visualiser, interroger, télécharger, géocoder, calculer, contrôler, valider ou mesurer l'usage. Un seul mot "carte" ne suffit pas pour concevoir le run.
1. Clarifier Géoportail, cartes.gouv.fr et Géoplateforme
Nommer correctement le socle utilisé
Beaucoup d'équipes parlent encore d'API Géoportail, alors que les parcours actuels passent de plus en plus par cartes.gouv.fr et les services de la Géoplateforme. Le connecteur doit nommer précisément l'URL, le service et la documentation utilisés.
Cette précision évite les malentendus entre usages historiques, nouvelles clés, documentation d'aide, pages développeur et services encore cités sous des noms différents dans les équipes métier ou SIG.
Le dossier d'architecture doit donc conserver nom du service, domaine appelé, version de documentation, clé, logiciel consommateur, couche ou ressource, date d'activation et propriétaire. Sans cette fiche, la maintenance devient une chasse aux liens.
Distinguer API de diffusion et services de calcul
Les API de diffusion exposent des images tuilées WMTS, tuiles vectorielles TMS, images WMS raster, WMS vecteur ou sélection d'objets WFS. Les services de calcul traitent géocodage, itinéraire, isochrone, altimétrie ou validation.
Le modèle d'intégration doit refléter cette différence. Une tuile affichée peut être mise en cache côté client, alors qu'un calcul d'itinéraire ou une validation d'adresse doit être tracé comme une décision.
Si un écran mélange diffusion et calcul sans journalisation, alors le support ne saura pas dire si l'erreur vient d'une couche absente, d'un résultat de géocodage, d'un service lent ou d'une règle métier.
Par exemple, une collectivité peut afficher un fond WMTS dans un portail citoyen, interroger un objet WFS dans un back-office et lancer un géocodage dans un formulaire interne. Ces trois usages doivent avoir trois preuves différentes.
Conserver les conditions d'usage et limites
Les services de la Géoplateforme documentent des limites d'usage, des niveaux de service, des clés et des évolutions. Ces informations doivent entrer dans le runbook au même titre que les endpoints et les paramètres.
La règle est simple: aucune dépendance critique à un service public externe ne doit être ouverte sans seuil de requêtes, stratégie de cache, scénario dégradé et contact interne responsable de la surveillance.
Si un service est appelé par plusieurs applications internes, alors la limite ne doit pas être lue application par application. Elle doit être consolidée par adresse IP, clé, parcours et priorité métier.
2. Exploiter diffusion WMS, WMTS, WFS et TMS
Choisir le bon protocole cartographique
WMTS sert souvent les images tuilées, TMS les tuiles vectorielles, WMS l'affichage d'images raster ou vectorielles, et WFS la sélection d'objets géographiques. Ces protocoles ne transportent pas la même responsabilité.
Une application métier doit savoir si elle affiche un fond, superpose une couche, interroge des objets ou alimente une base interne. Le choix du protocole change cache, latence, poids, droits et capacité de reprise.
Si une couche WMS est utilisée pour décider une intervention terrain, alors la date de la couche, le style, l'emprise et la source doivent être affichables. Le screenshot seul ne vaut pas preuve.
Le connecteur doit aussi documenter le payload attendu par le client cartographique: paramètres de couche, projection, bbox, style, format d'image, format de réponse et erreur lisible. Cette précision évite les diagnostics flous entre front, SIG et middleware.
Gouverner couches, styles et emprises
Les couches IGN peuvent couvrir des besoins très différents: fond topographique, photographie, parcellaire, réseau, limites, données historiques ou référentiels métier. Chaque couche doit être documentée comme une dépendance.
Le connecteur doit garder identifiant de couche, style, projection, niveau de zoom, emprise, politique de cache, droits d'usage et applications consommatrices. Une couche changée en silence peut casser des parcours terrain.
Si plus de 5 tickets support sur 30 jours concernent une couche mal comprise, alors le problème n'est pas seulement cartographique. La légende, la documentation et le statut métier doivent être revus.
Préparer l'intégration SIG et web
Les services de diffusion peuvent être consommés par QGIS, ArcGIS, FME, OGR, Maputnik, une application web, un back-office ou un portail public. Le même service n'a pas le même contexte de sécurité partout.
Le dossier technique doit séparer usages humains, traitements automatisés et affichage grand public. Cette séparation aide à fixer cache, limites, clés, tests de rendu et responsabilité de support.
Si une couche est utilisée dans un SIG et dans une application web, alors les deux parcours doivent être testés séparément. Une couche correcte en QGIS peut rester trop lourde, trop lente ou trop complexe côté navigateur.
Les tests doivent aussi vérifier les projections attendues par chaque outil. Une différence entre EPSG:4326, EPSG:3857 et une projection métier peut créer un décalage discret qui ne se voit qu'au moment du rapprochement terrain.
3. Cadrer géocodage, autocomplétion et adresses
Traiter BAN, BD TOPO et parcelles comme des sources distinctes
Le service de géocodage de la Géoplateforme peut fournir des coordonnées à partir d'une adresse ou d'une parcelle, et retourner le localisant le plus proche à partir de coordonnées en géocodage inverse.
Le cadrage doit distinguer adresses issues de la BAN, lieux nommés et POI issus de la BD TOPO, ainsi que données de parcelles provenant du Parcellaire Express. Ces sources ne portent pas le même rythme de mise à jour.
Si un résultat modifie une adresse client, une parcelle, un accès terrain ou une zone fiscale, alors le connecteur doit conserver source, score, géométrie, date, type d'objet et règle d'acceptation.
Le getCapabilities du géocodage doit être intégré au dossier technique, avec les opérations `search`, `reverse`, batch et batch asynchrone réellement utilisées. Cette lecture limite les surprises quand une équipe ajoute un nouveau cas sans revoir le contrat.
Séparer saisie assistée et validation métier
L'autocomplétion facilite la saisie dans un formulaire, mais elle ne doit pas être confondue avec une validation métier. Une suggestion choisie peut rester incomplète, ambiguë ou inadéquate pour la décision aval.
Le backend doit valider les usages sensibles: intervention, facturation, livraison, zonage, rattachement de parcelle ou génération d'un document. L'interface peut accélérer la saisie, mais elle ne doit pas porter seule la preuve.
Cette validation doit produire un statut simple: confirmé, ambigu, introuvable ou à revoir. Le statut rend la décision lisible pour le support, sans obliger chaque opérateur à comprendre les détails du service de géocodage.
Si le seuil de 3 % d'adresses corrigées après validation est dépassé sur 14 jours, alors l'équipe doit revoir pays, type de recherche, champs obligatoires, messages UX et règles de contrôle.
Exploiter batch synchrone ou asynchrone avec prudence
Le géocodage par lot peut être synchrone ou asynchrone selon le besoin. Il est utile pour reprendre un référentiel historique, qualifier des points terrain ou préparer une migration de données.
Le batch doit produire un rapport métier, pas seulement un fichier enrichi. Il doit distinguer résultats acceptés, résultats ambigus, rejets, lignes inchangées, coût support et actions à reprendre.
Si un batch modifie plus de 2 % des coordonnées utilisées par des dossiers ouverts, alors la synchronisation aval doit être validée par un owner métier. La correction technique peut sinon devenir un incident opérationnel.
Par exemple, un bailleur peut reprendre 40 000 adresses de patrimoine avant migration. Le rapport doit isoler adresses confirmées, parcelles rapprochées, localisants ambigus et dossiers à revoir avant d'alimenter CRM, ERP ou outil terrain.
4. Utiliser itinéraire, isochrone et isodistance
Cadrer le calcul d'itinéraire
Le service de calcul d'itinéraire de la Géoplateforme permet d'obtenir un parcours entre deux points selon un profil particulier. Il peut être interrogé en GET ou POST selon les paramètres et le contexte.
Le connecteur doit conserver ressource, méthode de calcul, profil piéton ou voiture, contraintes d'exclusion, étapes intermédiaires, date, paramètres et éventuelle version de ressource. Sans cette trace, une route devient difficile à expliquer.
Si un itinéraire modifie une intervention de plus de 15 minutes, alors la décision doit garder les paramètres et le graphe utilisés. Le support ne doit pas recalculer après coup avec un contexte différent.
Les endpoints REST de navigation doivent être testés en GET et POST quand les paramètres deviennent longs. Une collection Postman ou Insomnia peut aider la recette, mais le run dépend surtout des logs, du timeout et du versioning applicatif.
Comprendre les ressources BD TOPO et moteurs de calcul
Les données de navigation s'appuient sur la BD TOPO, le réseau routier et les tables de non communications. Selon les ressources, le calcul peut s'appuyer sur OSRM, Valhalla ou pgRouting avec des compromis différents.
Cette nuance doit être documentée dans le SI. OSRM peut être privilégié pour la performance, tandis que pgRouting peut répondre à des besoins plus fins de contraintes ou d'attributs, avec une performance moindre.
Si le métier demande des contraintes spécifiques, alors le choix de ressource doit être justifié. Le connecteur doit éviter de choisir le moteur le plus rapide quand la décision exige des attributs plus détaillés.
Le champ de version de ressource doit être conservé dans les résultats sensibles. Si une mise à jour BD TOPO change un temps de parcours, l'équipe peut alors distinguer évolution référentielle, bug de mapping et changement de règle métier.
Utiliser isochrone et isodistance comme outils de décision
Les services isochrone et isodistance servent à représenter une zone atteignable selon un temps ou une distance. Ils sont utiles pour couverture de service, intervention, mobilité, planification et analyse territoriale.
Une isochrone doit conserver point de départ, profil, seuil, contraintes, date et service utilisé. Sans ces paramètres, deux cartes de couverture peuvent raconter des réalités différentes.
Si une isochrone ouvre une zone de plus de 10 000 habitants ou modifie une priorité d'intervention, alors elle doit être vérifiée avec des données métier et un seuil de service avant publication.
5. Industrialiser altimétrie, recherche et validation
Relier altimétrie et précision attendue
Le service de calcul altimétrique permet d'obtenir l'altitude d'un ou plusieurs points et un profil altimétrique le long d'une courbe. Les résultats peuvent varier selon les ressources altimétriques sollicitées.
Le connecteur doit conserver ressource, coordonnées, profil, unité, précision attendue, date et usage métier. Une altitude destinée à l'affichage n'a pas la même exigence qu'une décision d'aménagement ou de risque.
Si une différence d'altitude modifie un coût de chantier ou une qualification de risque, alors l'équipe doit vérifier RGE ALTI, BD ALTI, résolution, arrondi et seuil de tolérance avant automatisation.
Les appels REST d'altimétrie doivent conserver courbe, point, ressource, méthode GET ou POST, profil retourné et tolérance. Cette preuve est indispensable quand un calcul devient une pièce d'un dossier technique ou réglementaire.
Encadrer recherche, métadonnées et téléchargement
Le service de recherche de la Géoplateforme, la découverte des métadonnées CSW et l'API de téléchargement peuvent aider à trouver, qualifier et récupérer des données pour des traitements métier.
Ces services doivent rester reliés à une gouvernance data: source, licence, date, emprise, format, version, propriétaire interne et usage autorisé. Télécharger une donnée ne suffit pas à la rendre exploitable.
Si une donnée téléchargée alimente plus de 3 tableaux de bord ou applications, alors elle doit entrer dans un catalogue interne. Le support doit connaître sa provenance et sa fréquence de rafraîchissement.
Le catalogue interne doit référencer schéma, format, projection, licence, emprise, fréquence et owner. Une donnée peut être ouverte et rester mal gouvernée si son format ou sa date devient incompréhensible pour les applications aval.
Utiliser validation et statistiques d'usage
Les services de validation et de statistiques d'utilisation ne doivent pas rester secondaires. Ils aident à vérifier les configurations, comprendre les consommations et détecter les usages qui dérivent.
Le run doit suivre appels, erreurs, limites atteintes, services les plus consommés, clés utilisées, applications consommatrices et incidents support. Une carte qui fonctionne peut déjà masquer une dépendance trop coûteuse.
Les statistiques doivent être reliées aux owners, pas seulement aux volumes. Un pic WMS, un lot de géocodage et un calcul d'itinéraire n'appellent pas la même correction, même s'ils partagent une clé ou une adresse IP.
Si les statistiques montrent une hausse de 30 % des appels sans hausse de valeur métier, alors l'équipe doit revoir cache, rafraîchissement, usages automatisés et priorités d'accès.
6. Gouverner clés, limites et niveaux de service
Traiter les clés cartes.gouv.fr comme des actifs
Les clés d'accès doivent être créées, documentées et rattachées à des usages précis. Une clé partagée entre SIG, portail web, batch et tests rend le diagnostic de consommation presque impossible.
Le modèle doit séparer environnement, service, logiciel consommateur, propriétaire, restrictions, date de rotation et criticité. Cette discipline facilite les audits, les changements et les incidents de sécurité.
Si une clé est utilisée par plus de 2 applications critiques, alors elle doit être découpée ou surveillée avec un seuil dédié. Un incident sur une seule application ne doit pas bloquer tout le dispositif.
Les tests doivent être rejouables avec des collections outillées, mais la sécurité ne doit pas dépendre d'un export local. Les secrets, URL, paramètres et droits doivent être portés par le middleware et par les variables d'environnement.
Respecter les limites d'usage documentées
Les limites documentées varient selon les services. Le géocodage indique un ordre de 50 requêtes par seconde depuis une même adresse IP, tandis que l'itinéraire et l'altimétrie indiquent des limites plus basses.
Ces chiffres doivent devenir des règles d'architecture: cache, file, backoff, priorisation, traitement différé et scénario dégradé. La limite ne doit pas être découverte pendant une démonstration ou un pic terrain.
Si un flux dépasse 80 % de sa limite pendant plus de 10 minutes, alors l'application doit réduire le débit ou passer en mode différé. Cette règle protège le service public et la continuité métier.
Le rate limit doit être traité avec queue, backoff, circuit breaker et priorité métier. Un batch de nettoyage ne doit pas consommer la même fenêtre qu'un parcours utilisateur ou qu'une intervention terrain urgente.
Prévoir changements et évolutions de la Géoplateforme
La documentation cartes.gouv.fr expose aussi des changements et évolutions de la Géoplateforme. Le connecteur doit donc prévoir veille, tests de non-régression et procédure de mise à jour des endpoints.
Le risque est de figer une URL ou une couche comme si elle ne changerait jamais. En réalité, un socle public évolue, et l'intégration doit absorber les changements sans casser les outils métier.
Si une évolution modifie un service critique, alors un test de recette doit rejouer les parcours principaux avant mise en production. La veille documentaire doit déclencher une action, pas seulement une lecture.
7. Brancher les référentiels IGN au SI
Relier chaque réponse à un objet interne
Une intégration IGN solide rapproche les réponses avec les objets internes: adresse, parcelle, équipement, bâtiment, zone, intervention, dossier, client, collectivité, ressource terrain ou couche métier.
Le modèle doit conserver identifiant interne, source IGN, couche ou service, coordonnées, géométrie, statut, décision, date, version de mapping et trace de corrélation. Cette preuve rend les reprises lisibles.
Si un résultat ne peut pas être relié à un objet interne, il doit rester en observation ou dans un entrepôt data, pas piloter directement une décision opérationnelle.
Construire un pipeline spatial observable
Le pipeline doit séparer collecte, validation, transformation, reprojection éventuelle, rapprochement, stockage, exposition cartographique et alerte. Une erreur peut venir du service, de la couche, du format ou du mapping.
Les entrées doivent garder paramètres, emprise, projection, clé logique et contexte d'appel. Les sorties doivent distinguer donnée brute, donnée normalisée, statut de confiance, coût opérationnel et décision aval.
Cette instrumentation donne un owner au monitoring, au rollback et au support. Elle évite les situations où le SIG, le produit et les opérations regardent trois versions d'une même réalité géographique.
Les payloads doivent être validés par schema avant transformation quand le service renvoie des formats structurés. Cette validation détecte plus tôt les champs manquants, changements de type et erreurs de projection qui casseraient l'aval.
Prévoir reprises et historisation
Une reprise IGN doit pouvoir rejouer un géocodage, une couche, une zone, une altitude, une isochrone ou un téléchargement sans écraser silencieusement les décisions déjà publiées.
Le connecteur doit stocker version de source, paramètres, date logique, résultat précédent, résultat nouveau, motif de changement et action autorisée. Cette chronologie protège les équipes support et data.
Si une reprise modifie plus de 4 % des objets actifs, alors la synchronisation aval doit passer en validation métier. Cette règle évite de transformer une mise à jour référentielle en incident commercial.
8. Plan d'action IGN Géoportail
Prioriser le premier usage public ou terrain
D'abord, il faut choisir un usage court: afficher une couche de référence, valider des adresses, rapprocher des parcelles, calculer un itinéraire, produire une isochrone ou qualifier une altitude.
La fiche de cadrage doit lister service Géoplateforme, protocole, entrée, sortie, source, limite, cache, owner, fallback et preuve support. Si cette fiche manque, le projet démarre avec une dette de gouvernance.
En priorité, l'équipe doit refuser les usages qui mélangent visualisation, calcul et donnée de référence sans décision claire. Un premier lot étroit mais traçable vaut mieux qu'un portail large impossible à maintenir.
Prototyper sur les vrais territoires
Ensuite, le prototype doit utiliser les vrais territoires, projections, couches, parcelles, adresses, contraintes routières et volumes approximatifs. Un test sur une commune simple ne révèle pas toujours les difficultés de production.
Le prototype doit comparer au moins 3 contextes: centre urbain, zone rurale et territoire avec contrainte particulière. Cette comparaison montre si le mapping sait gérer précision, absence de donnée et charge.
Si le prototype ne produit pas une décision d'acceptation, de rejet ou de reprise, alors il reste une démonstration cartographique. La sortie attendue doit être une règle exploitable.
Développer le connecteur avec limites et repli
Puis, le connecteur doit intégrer timeout, cache, backoff, journalisation, clé par environnement, monitoring, seuils d'usage, erreurs lisibles et repli quand un service Géoplateforme répond trop tard.
Le passage serveur doit être privilégié pour les décisions sensibles. L'interface peut afficher une carte, mais le backend doit valider les décisions qui touchent dossier, intervention, facturation, zonage ou engagement public.
Le scénario dégradé doit être écrit comme un comportement normal: afficher un cache daté, différer un batch, masquer une couche secondaire, proposer une saisie manuelle ou escalader au support.
Fixer des seuils de go-live
Le go-live doit exiger des seuils mesurables: 100 % des appels critiques traçables, aucune clé partagée sans justification, cache documenté par service et moins de 2 % d'objets actifs sans décision claire.
Si le taux d'erreurs dépasse 1 % sur 24 heures pour un parcours critique, alors le flux doit repasser en mode contrôlé. Le seuil protège support, délai terrain et confiance métier.
La recette doit aussi vérifier latence, limite d'usage, qualité des données, fraîcheur des couches, cohérence des projections et action support. Un affichage correct ne valide pas la décision métier.
Le tableau de sortie doit être compréhensible par une personne hors équipe technique: parcours validé, seuil respecté, source utilisée, risque restant, décision de lancement et owner du suivi après mise en production.
Organiser les 30 premiers jours
Plus tard seulement, l'équipe peut élargir couches, territoires ou volumes. Les 30 premiers jours doivent mesurer appels, erreurs, cache hit, limites approchées, corrections manuelles, tickets support et décisions refusées.
Le rituel de suivi doit produire des décisions: réduire une fréquence de rafraîchissement, corriger une projection, documenter une couche, déplacer un calcul côté batch ou reporter une fonctionnalité trop fragile.
Cette cadence évite de transformer IGN/Géoplateforme en boîte noire cartographique. Le connecteur reste un actif de run, avec une valeur mesurée, des limites connues et une trajectoire d'amélioration.
9. Erreurs fréquentes IGN Géoportail
Les pièges qui fragilisent vite la production
- Parler encore seulement d'API Géoportail sans identifier le service cartes.gouv.fr, la Géoplateforme, l'URL et la documentation réellement utilisés.
- Utiliser une couche cartographique comme preuve métier, alors que l'affichage ne conserve ni source, ni paramètres, ni règle de décision.
- Mélanger WMS, WMTS, WFS et TMS dans un même contrat, puis découvrir trop tard que les usages de cache et de reprise sont différents.
- Ignorer les limites de requêtes par service, alors que géocodage, itinéraire et altimétrie n'ont pas la même tolérance de charge.
- Corriger une donnée IGN dans le SI sans historiser la source, la date et le motif, ce qui crée une double vérité difficile à expliquer.
Ces erreurs ne se voient pas toujours pendant le prototype, parce qu'une carte s'affiche et qu'un appel répond. Elles deviennent visibles quand un service public, une équipe terrain ou un dossier client demande une preuve.
Le signal faible le plus utile se voit quand les équipes gardent des exports différents pour la même zone. À ce moment, le connecteur ne porte plus la source de vérité et doit être repris.
Le bon arbitrage consiste à refuser une nouvelle couche ou un nouveau calcul tant que source, limite, owner, cache, repli et preuve ne sont pas écrits. Le socle reste alors maîtrisé.
Éviter les mélanges entre référence et enrichissement
Une erreur plus discrète consiste à mélanger donnée de référence, enrichissement interne, correction terrain et affichage cartographique dans un seul modèle. Le support ne sait alors plus quelle donnée fait foi.
Cette confusion crée des interfaces rassurantes mais difficiles à défendre. Une parcelle, une adresse, une altitude et une zone métier doivent garder provenance, date et niveau de validation.
Si une règle métier ne peut pas dire quelle source tranche entre IGN, SI interne et retour terrain, alors le connecteur doit être relu avant extension. La clarté de source conditionne la qualité du run.
La documentation doit aussi montrer où saisir une correction et où ne pas la saisir. Une observation terrain peut devenir une exception interne, une demande de contribution ou une simple note support, mais elle ne doit pas écraser automatiquement un référentiel sans décision, surtout quand plusieurs équipes réutilisent la même couche dans des portails, tableaux de bord et exports réglementaires pendant plusieurs années, avec des partenaires externes critiques et des obligations de traçabilité publique sur la durée.
10. Recette, rollback et support IGN
Tester les familles de services avant ouverture
La recette doit couvrir les familles utiles: couche WMTS, couche WMS, sélection WFS, géocodage direct, géocodage inverse, autocomplétion, itinéraire, isochrone, altimétrie, cache expiré, limite approchée et clé invalide.
Chaque cas doit produire une preuve: URL, service, paramètres, couche ou ressource, statut HTTP, durée, résultat retenu, résultat rejeté, seuil qualité, action support et objet interne lié.
Un seuil de sortie protège le lancement: 100 % des appels critiques traçables, aucune clé partagée entre environnements sans justification, moins de 2 % de résultats ambigus non classés et fallback documenté.
Préparer un rollback par service
Le rollback ne doit pas couper toute la plateforme si un service dérive. Il peut désactiver une couche, revenir à un cache précédent, repasser un batch en manuel ou réduire les calculs d'itinéraire.
Si 3 incidents critiques touchent le même service en 24 heures, si une limite est atteinte en continu, ou si plus de 5 % des objets publiés changent après reprise, alors le mode contrôlé doit s'activer.
Cette approche garde les usages fiables ouverts. Elle évite le faux choix entre débrancher toute la cartographie et laisser un parcours critique se dégrader sans preuve.
Le rollback doit être répétable par une personne de permanence. Une procédure qui dépend d'un développeur précis, d'un export local ou d'une requête improvisée n'est pas un vrai scénario de production.
Donner au support une lecture actionnable
La fiche support doit traduire les résultats IGN en statuts lisibles: couche indisponible, géocodage ambigu, parcelle introuvable, itinéraire recalculé, altitude à vérifier, cache utilisé ou limite atteinte.
Le support doit pouvoir répondre à quatre questions: quelle donnée a été envoyée, quel service a répondu, pourquoi le résultat a été accepté, et quelle action est autorisée quand l'utilisateur conteste.
Si une personne qui n'a pas participé au projet ne peut pas expliquer un cas simple en moins de 15 minutes, alors l'intégration fonctionne techniquement mais n'est pas encore prête pour un run autonome.
Mesurer la stabilité après mise en production
Les 30 premiers jours doivent suivre par service: appels, latence, erreurs, cache hit, limites approchées, résultats utiles, refus métier, corrections manuelles, tickets support et régressions de délai.
Cette mesure décide les extensions. Un service stable peut être élargi, tandis qu'un service ambigu doit être limité, corrigé ou déplacé vers un traitement différé avant de toucher plus d'utilisateurs.
La revue post-prod doit aussi vérifier la documentation vivante: captures, exemples REST, consignes SIG, procédures de cache et seuils de reprise. Une intégration territoriale vieillit mal quand seul le code reste à jour.
Le bon résultat n'est pas seulement une carte qui s'affiche ou une adresse qui se complète. Le bon résultat est une décision géographique traçable, conforme à sa source et compréhensible par l'équipe qui porte le service.
Questions fréquentes IGN Géoportail
Quels services IGN faut-il cadrer autour de la Géoplateforme ? Il faut cadrer la diffusion WMS, WMTS, WFS et TMS, le téléchargement, la recherche CSW, le géocodage, l'autocomplétion, l'itinéraire, l'isochrone, l'isodistance, l'altimétrie, la validation et les statistiques d'usage.
Pourquoi distinguer Géoportail, cartes.gouv.fr et Géoplateforme ? Le vocabulaire doit rester clair: Géoportail désigne encore beaucoup d'usages historiques, tandis que cartes.gouv.fr et la Géoplateforme portent les services API actuels, les clés, la documentation et les évolutions.
Dawap peut-il accompagner une intégration IGN Géoportail ? Oui. Dawap accompagne le cadrage, le développement et l'industrialisation de flux IGN/Géoplateforme pour cartes, géocodage, itinéraires, isochrones, altimétrie, couches métier, limites d'usage et support.
Guides complémentaires après IGN
La ressource API Geoapify complète IGN/Géoportail quand l'équipe compare services publics français, géocodage, routing, places, coûts par usage, clés et cache dans une architecture cartographique plus large.
La ressource API Overpass OpenStreetMap apporte un angle utile pour interroger les données OSM par tags, zones et objets lorsque le besoin porte sur open data communautaire plutôt que référentiels IGN.
La ressource API Google Maps Platform aide à comparer les exigences de cartes, places, geocoding, directions, matrix et clés avec un fournisseur privé plus orienté produit grand public.
La landing API cartographie et géolocalisation relie ce sujet aux offres de cadrage géographique, tandis que la page intégrateur IGN Géoportail précise comment transformer les services Géoplateforme en connecteur maintenable.
Conclusion opérationnelle IGN
Une intégration IGN/Géoportail réussie ne se juge pas à une couche qui s'affiche. Elle se juge à la capacité de relier service, source, limite, cache, date et décision métier dans un run explicable.
Le bon ordre reste stable: nommer le service actuel, choisir le protocole, cadrer les sources, protéger les clés, respecter les limites, tester les cas ambigus et donner au support une lecture actionnable.
Cette discipline garde la Géoplateforme à sa bonne place: un socle public de référence puissant, mais toujours relié à des seuils, des propriétaires, des règles de production et des preuves visibles.
Si vous voulez brancher IGN/Géoplateforme dans un SI sans laisser les cartes et référentiels dériver, notre accompagnement Integration API peut cadrer les services, les clés, les caches, l'observabilité, les reprises et les limites de production.
