Standard CNIG PLU, CC, PSMV 2026 : choisir la bonne version pour le dépôt GPU

D'après les retours terrain des bureaux d'études SIG, un dépôt sur trois sur le Géoportail de l'Urbanisme nécessite au moins une correction structurelle avant acceptation — et dans les cas les plus graves, une reprise complète de la numérisation. Avec la généralisation de l'obligation de dépôt dématérialisé issue du décret n° 2019-537 du 29 mai 2019, la conformité aux standards de données géographiques publiés par le CNIG conditionne directement la validité procédurale des documents d'urbanisme. En 2026, les versions de référence sont le standard PLU v2.2, le standard CC v1.4 et le standard PSMV v1.2 : chacune embarque des évolutions qui surprennent encore de nombreux prestataires. Cet article vous donne les clés pour choisir la bonne version, anticiper les erreurs bloquantes et sécuriser votre dépôt GPU dès la première tentative.

Standard CNIG urbanisme : définition, rôle et impact sur la validité du dépôt GPU

Le standard CNIG (Conseil National de l'Information Géographique) est un référentiel technique publié par la Commission des Standards du CNIG qui définit le modèle de données, les règles de nommage des fichiers, les projections géodésiques et les contraintes d'intégrité applicables à la numérisation des documents d'urbanisme réglementaires destinés au dépôt sur le Géoportail de l'Urbanisme (GPU).

Ce que ce référentiel implique concrètement, c'est que le GPU ne valide pas simplement la présence d'un fichier GeoJSON ou d'un shapefile : il vérifie la conformité structurelle du jeu de données au regard d'une version précise du standard. Un dépôt réalisé en version 2.0 d'un standard PLU alors que le GPU attend la version 2.2 génère une erreur bloquante à l'intégration, sans que le document lui-même soit juridiquement incorrect. La distinction entre invalidité technique et invalidité juridique est ici capitale : un PLU peut être légalement approuvé par délibération du conseil municipal et être simultanément refusé par la plateforme de dépôt pour un motif purement structurel, comme un champ mal nommé ou une valeur contrôlée absente.

Le CNIG publie ses standards sous forme de fiches téléchargeables sur cnig.gouv.fr, accompagnées de journaux de modification détaillés. Chaque version porte un numéro à deux ou trois chiffres (ex. : 2.0, 2.1, 2.1.1, 2.2) et une date de publication. Les versions sont parfois rétrocompatibles, mais cette compatibilité n'est jamais garantie d'une version majeure à l'autre. Les principales familles de standards applicables aux documents d'urbanisme sont le standard PLU (PLU simples et PLUi), le standard CC (Cartes Communales), le standard PSMV (Plans de Sauvegarde et de Mise en Valeur) et le standard SCoT, hors périmètre de cet article mais soumis à la même logique de versionnage.

La Commission des Standards actualise ces référentiels à chaque évolution significative du cadre législatif ou réglementaire : loi ALUR, loi ELAN, loi Climat et Résilience, ordonnances de simplification du droit de l'urbanisme. La veille sur les mises à jour du standard est donc une obligation de gestion de projet, pas une option.

Standard CNIG PLU v2.2 (2026) : nouveautés, champs obligatoires et points de blocage GPU

Le standard CNIG PLU v2.2 est le référentiel technique obligatoire en 2026 pour la numérisation des Plans Locaux d'Urbanisme (PLU simples et PLUi) destinés au dépôt sur le Géoportail de l'Urbanisme. Il définit le modèle de données, les objets géographiques obligatoires, les nomenclatures de valeurs contrôlées et les règles de nommage des fichiers — et il succède à la version 2.1 de 2021 ainsi qu'au correctif 2.1.1.

Principales évolutions réglementaires intégrées dans la v2.2

La mise à jour vers la version 2.2 répond à deux évolutions majeures du cadre légal. D'une part, l'intégration des dispositions de la loi Climat et Résilience n° 2021-1104 du 22 août 2021, notamment l'objectif de Zéro Artificialisation Nette (ZAN) et la séquence Éviter-Réduire-Compenser (ERC) dans les documents de planification. D'autre part, la structuration renforcée des données relatives aux Orientations d'Aménagement et de Programmation (OAP) thématiques, dont le contenu s'est considérablement enrichi dans les PLU de nouvelle génération. Les OAP sectorielles et thématiques numériques sont désormais des objets à part entière dans le modèle, avec leurs propres champs de référencement.

Modifications structurelles à maîtriser pour éviter un blocage GPU

Les modifications les plus impactantes pour les équipes SIG sont les suivantes. L'objet ZONE_URBA intègre de nouveaux codes de type de zone pour les secteurs soumis à des règles spécifiques ZAN, avec une contrainte de renseignement obligatoire du champ TYPEZONE selon la nomenclature actualisée de l'article R.151-17 du Code de l'urbanisme. Les objets PRESCRIPTION_LIN et PRESCRIPTION_SURF ont fait l'objet d'une refonte partielle de la table des codes de prescription, alignée sur la circulaire DGALN/DH/QC/2022/113. L'objet DOC_URBA comporte désormais un champ ETAT obligatoire avec une liste de valeurs contrôlées : 'en cours de validité', 'caduc', 'annulé'. Les métadonnées ISO 19115 voient leur exigence renforcée sur le renseignement du point de contact, de la date de révision et de la généalogie du jeu de données — ces métadonnées sont désormais validées de façon bloquante par le GPU.

Erreurs de nommage les plus fréquentes sur les PLU

Un point qui génère régulièrement des erreurs en production concerne le nommage du fichier de métadonnées. Le GPU exige un fichier XML conforme à ISO 19115/19139 nommé exactement selon la convention [IDURBA]_MS.xml. Toute déviation — underscore manquant, majuscule non respectée, extension .XML en majuscules au lieu de .xml — provoque un rejet silencieux difficile à diagnostiquer sans accès aux logs détaillés du validateur. Le champ IDURBA lui-même, qui sert de clé de jointure pour l'ensemble des objets du jeu de données, doit suivre exactement la convention définie par le CNIG : code INSEE de la commune (ou de l'EPCI pour un PLUi) suivi de la nature du document et de la date d'approbation. Depuis la v2.2, ce code comporte 12 caractères, contre 9 dans les versions antérieures, ce qui invalide mécaniquement les jeux de données produits sous la v2.0 ou v2.1 si le champ IDURBA n'est pas mis à jour.

Pour les PLUi engagés sous la version 2.0 ou 2.1 et finalisés après 2024, une migration vers la v2.2 est obligatoire avant tout dépôt. Cette migration requiert une vérification manuelle des objets de prescription et une mise à jour complète des nomenclatures de valeurs contrôlées — elle n'est pas automatisable à 100 %.

> Besoin d'une vérification de conformité PLU avant dépôt GPU ? Les équipes d'IDS France réalisent des diagnostics de conformité et des migrations de version pour sécuriser votre dépôt dès la première tentative.

Standard CNIG Carte Communale v1.4 (2026) : modèle allégé, erreurs fréquentes et conformité GPU

Le standard CNIG CC v1.4 est le référentiel de numérisation applicable en 2026 aux Cartes Communales au sens de l'article L.161-1 du Code de l'urbanisme. Il s'agit du format de dépôt GPU requis pour les communes ne disposant pas de PLU et souhaitant délimiter graphiquement leurs secteurs constructibles, sans rédaction d'un règlement écrit propre au territoire.

La Carte Communale est un document d'urbanisme de portée limitée : elle ne crée pas de zone à urbaniser, n'ouvre pas de droits à construire au-delà de ce que permet le Règlement National d'Urbanisme (RNU), et ne comporte pas d'OAP. Ce périmètre fonctionnel réduit se reflète dans la structure du standard CNIG CC, significativement plus légère que celle du PLU, mais dont la rigueur de renseignement est tout aussi exigeante pour la validation GPU.

Le tableau suivant récapitule les évolutions de la version 1.4 par rapport à la version 1.3 :

Les erreurs les plus fréquemment rencontrées lors des dépôts GPU de Cartes Communales concernent deux points précis. Premièrement, la confusion entre le périmètre de la Carte Communale (le territoire couvert par le document) et le périmètre communal administratif : l'objet COMMUNE_CC doit représenter l'intégralité du ban communal, y compris les zones non constructibles. Un dépôt ne comportant que les secteurs U génère une erreur topologique de couverture incomplète. Deuxièmement, le renseignement du champ TYPECC : les valeurs 'CC approuvée' et 'CC en cours d'élaboration' sont des valeurs strictement contrôlées et ne supportent aucune variante orthographique, abréviation ou majuscule non conforme.

Pour les petites communes rurales qui instruisent leur CC avec l'appui d'un bureau d'études externe, il est fortement recommandé de passer par le validateur CNIG local avant tout dépôt sur le GPU, afin d'identifier en amont les non-conformités structurelles. Par ailleurs, les communes soumises uniquement au RNU, sans aucun document local approuvé, n'ont pas d'obligation de dépôt GPU : l'obligation issue du décret n° 2019-537 ne s'applique qu'aux collectivités disposant d'un PLU, d'une CC ou d'un PSMV approuvé.

Standard CNIG PSMV v1.2 (2026) : précision parcellaire, double tutelle ABF et dépôt GPU

Le standard CNIG PSMV v1.2 est le référentiel de numérisation en vigueur en 2026 pour les Plans de Sauvegarde et de Mise en Valeur, documents d'urbanisme spéciaux applicables dans les Sites Patrimoniaux Remarquables (SPR). C'est le plus exigeant des trois standards traités ici, avec une précision géométrique obligatoire inférieure à 0,10 mètre et une gestion obligatoire de la traçabilité des modifications.

Le PSMV a été créé par la loi Malraux du 4 août 1962 et est codifié aux articles L.313-1 et suivants du Code du patrimoine. Il se substitue au PLU sur le périmètre d'un SPR et définit des règles précises de conservation, de restauration et de mise en valeur du bâti et des espaces. Sa double tutelle — élaboration conjointe par la collectivité, l'architecte des Bâtiments de France (ABF) et la DRAC — introduit une complexité de gouvernance qui se répercute directement sur la gestion de la donnée géographique et les délais de validation.

Exigences spécifiques du modèle PSMV v1.2

La granularité parcellaire est obligatoire : contrairement au PLU qui peut s'appuyer sur des zonages de grande emprise, le PSMV exige une saisie à la parcelle cadastrale, voire à l'îlot bâti. Une tolérance géométrique inférieure à 0,10 mètre est attendue pour les objets de type BATIMENT_PSMV — toute géométrie présentant des écarts supérieurs à cette valeur est rejetée par le validateur topologique du GPU.

L'objet IMMEUBLE_PROTEGE, propre au standard PSMV, référence les immeubles classés, inscrits ou repérés selon les catégories définies à l'article L.621-1 du Code du patrimoine. Le champ TYPEPROTEC accepte uniquement les valeurs de la nomenclature ABF officielle : toute saisie libre ou valeur non listée génère une erreur bloquante.

La gestion des superpositions est une contrainte topologique spécifique au PSMV : le standard impose une cohérence stricte entre les périmètres SPR et les zonages PSMV, vérifiée automatiquement par le validateur GPU. En cas d'incohérence entre la géométrie du périmètre SPR et les objets de zonage, l'ensemble du dépôt est rejeté.

La traçabilité des modifications est obligatoire : chaque mise à jour d'un PSMV (modification simplifiée ou modification de droit commun) doit être tracée dans l'historique du jeu de données via les champs DATMOD et TYPEMOD, avec référence explicite à la délibération ou à l'arrêté préfectoral correspondant. Les PSMV numérisés sous des standards antérieurs à la v1.2 doivent faire l'objet d'une re-numérisation complète lors de tout nouveau dépôt ou modification procédurale.

> Un PSMV à migrer vers la v1.2 ou à déposer pour la première fois sur le GPU ? IDS France accompagne les collectivités et les DRAC dans la production et la validation de leurs jeux de données PSMV à haute précision géométrique. Contactez-nous pour un diagnostic.

Comparatif PLU, CC, PSMV : quel standard CNIG choisir selon votre document d'urbanisme ?

Le choix entre le standard CNIG PLU v2.2, CC v1.4 et PSMV v1.2 dépend de trois critères séquentiels : la nature juridique du document d'urbanisme, la présence d'un Site Patrimonial Remarquable sur le territoire, et l'existence d'un règlement écrit. Le tableau et l'arbre de décision ci-dessous permettent de qualifier le standard applicable en moins de trois questions.

La stratégie de choix suit une logique de qualification préalable du document en trois questions séquentielles. Le territoire est-il couvert par un SPR ? Si oui, c'est le standard PSMV qui s'impose, indépendamment de l'existence d'un PLU adjacent — les deux documents coexistent, mais chacun doit être déposé sous son propre standard. Si non, la commune dispose-t-elle d'un document approuvé comportant un règlement écrit et des OAP ? Si oui, c'est le standard PLU. Dans tous les autres cas, le standard CC s'applique.

Un écueil fréquent en pratique : les révisions de PLU engagées avant 2021 et finalisées après 2024 peuvent avoir démarré en version 2.0 ou 2.1 du standard et nécessiter une migration vers la version 2.2 avant dépôt. Cette migration n'est pas automatisable intégralement et requiert une vérification manuelle des objets de prescription, des secteurs de plan de masse et des nomenclatures ZAN absentes des versions antérieures. Pour un PLU simple (moins de 15 couches, commune de taille moyenne), une migration encadrée par un prestataire SIG spécialisé prend généralement entre 3 et 10 jours ouvrés. Pour un PLUi multi-communes ou un document comportant des OAP thématiques complexes, la durée peut atteindre 3 à 6 semaines.

Points clés à retenir

• Le versionnage du standard CNIG conditionne directement l'acceptation du dépôt sur le GPU : un écart de version, même mineur entre une version 2.1 et 2.2, peut provoquer un rejet bloquant sans que le document soit juridiquement invalide.

• En 2026, les versions de référence actives sont PLU v2.2, CC v1.4 et PSMV v1.2 ; tout jeu de données produit sous une version antérieure doit faire l'objet d'une vérification de compatibilité — et si nécessaire d'une migration — avant dépôt GPU.

• Le standard PSMV v1.2 est le plus exigeant des trois : il requiert une précision géométrique inférieure à 0,10 mètre, une gestion obligatoire de la traçabilité des modifications et une cohérence topologique stricte avec les périmètres SPR.

• Le champ IDURBA est l'identifiant structurant de tout jeu de données GPU : depuis la v2.2, il comporte 12 caractères (contre 9 précédemment) et toute non-conformité dans sa construction invalide l'ensemble des objets du dépôt.

• Les métadonnées ISO 19115 ne sont plus optionnelles en 2026 pour aucun des trois types de documents : un fichier XML mal nommé, incomplet ou mal encodé entraîne un rejet de l'intégralité du dépôt, y compris pour des jeux de données géométriquement parfaits.

• La loi Climat et Résilience n° 2021-1104 a introduit des champs et objets spécifiques dans le standard PLU v2.2 (secteurs ZAN, séquence ERC) qui sont absents des versions antérieures et ne peuvent pas être produits sans une mise à jour du modèle de données source.

• Pour les Cartes Communales, la première source d'erreur de dépôt est la confusion entre périmètre du document et territoire communal complet : l'objet COMMUNE_CC doit impérativement couvrir la totalité du ban, zones constructibles et non constructibles confondues.

• La veille semestrielle sur cnig.gouv.fr est une bonne pratique de gestion de projet SIG pour tout projet engagé sur plusieurs années : la version applicable est toujours celle en vigueur à la date du dépôt, jamais celle en vigueur à la date de lancement de la procédure.

Vous travaillez sur un PLU, une Carte Communale ou un PSMV et vous souhaitez sécuriser votre dépôt GPU dès la première tentative ? Les équipes d'IDS France accompagnent les collectivités et les bureaux d'études dans la production, la migration et la validation de leurs jeux de données CNIG — du diagnostic de conformité initial jusqu'au dépôt validé sur le Géoportail de l'Urbanisme. Contactez-nous pour un audit de votre projet.

*Cet article est fourni à titre informatif. IDS France est expert en cartographie, SIG et ingénierie géospatiale. Nos équipes n'incluent pas de juristes en urbanisme et ne garantissent pas la conformité juridique de vos documents. Pour toute interprétation juridique, rapprochez-vous d'un professionnel du droit.*