Standard CNIG SCoT : guide de choix de version et conformité GPU 2024

Le Standard CNIG pour les Schémas de Cohérence Territoriale (SCoT) structure la dématérialisation des documents d'urbanisme en France depuis 2013. Pourtant, 40% des collectivités rencontrent des problèmes de compatibilité lors de l'intégration dans leurs SIG. Ce guide opérationnel vous permet de : ✓ Identifier en 3 étapes la version standard adaptée à votre calendrier d'approbation ✓ Éviter les 5 erreurs techniques bloquantes lors de la transmission GPU ✓ Garantir la conformité réglementaire de votre SCoT dès la première soumission. Ce guide s'adresse aux syndicats mixtes, bureaux d'études et collectivités qui doivent choisir la version standard adaptée à leur calendrier réglementaire.

Historique du standard CNIG SCoT : quelle version pour votre collectivité ?

Le standard CNIG SCoT est un référentiel technique national qui définit les règles de dématérialisation et de structuration numérique des Schémas de Cohérence Territoriale, documents d'urbanisme supra-communaux définis par les articles L141-1 et suivants du Code de l'urbanisme.

Le Conseil National de l'Information Géolocalisée (CNIG) a publié le premier standard SCoT en mai 2013, sous l'impulsion de la loi n°2010-788 du 12 juillet 2010 (loi Grenelle II) qui encourage la modernisation des documents d'urbanisme. L'obligation de transmission dématérialisée est formellement instaurée par l'ordonnance n°2013-1184 du 19 décembre 2013, qui crée le cadre juridique du Géoportail de l'Urbanisme (GPU).

Évolution des versions standard :

• Version 1.0 (Mai 2013) — Structuration initiale PADD/DOO/Rapport — Statut : Obsolète
• Version 2.0 (Décembre 2016) — Prescriptions décret n°2015-1783 — Statut : Déprécié
• Version 3.0 (Septembre 2019) — Alignement loi ELAN n°2018-1021 — Statut : Toléré jusqu'en 2025
• Version 4.0 (Janvier 2023) — GeoPackage, norme INSPIRE métadonnées — Statut : Obligatoire

La version 4.0 intègre des modifications majeures : géoréférencement renforcé selon le système géodésique légal français RGF93 / Lambert-93 (EPSG:2154, système en vigueur depuis le décret n°2000-1276 du 26 décembre 2000), métadonnées ISO 19115 obligatoires, et structuration XML conforme au profil INSPIRE. Le standard PLU CNIG v2023 partage cette même architecture pour garantir l'interopérabilité entre documents d'urbanisme.

Obligation réglementaire : L'ordonnance n°2013-1184 et le décret n°2015-1783 du 28 décembre 2015 imposent que tous les SCoT approuvés ou révisés soient transmis sous format numérique standardisé dans un délai de 3 mois. Le non-respect expose à un contrôle de légalité renforcé.

Les syndicats mixtes et établissements publics porteurs de SCoT doivent donc identifier quelle version correspond à leur calendrier d'approbation et aux outils SIG déployés.

Comment choisir la version du standard SCoT : critères réglementaires et SIG

La compatibilité SIG désigne la capacité d'un logiciel de géomatique (QGIS, ArcGIS Pro, FME) à importer, traiter et exporter les formats vectoriels et métadonnées imposés par le standard CNIG SCoT version 4.0, notamment le GeoPackage (ISO 32122) et les métadonnées ISO 19115.

Calendrier d'approbation : règle de correspondance

Le choix de la version dépend prioritairement de la date d'approbation ou de révision du document :

• SCoT approuvés avant 2019 : version 2.0 acceptable si aucune révision n'est prévue, mais migration vers v4.0 recommandée avant 2025
• SCoT approuvés entre 2019-2022 : version 3.0 minimum obligatoire
• SCoT approuvés depuis 2023 : version 4.0 impérative pour toute transmission au Géoportail de l'Urbanisme

Point critique : Un SCoT approuvé en version 2.0 mais révisé après janvier 2023 doit obligatoirement basculer en version 4.0 lors de la transmission post-révision. La compatibilité ascendante n'est pas garantie : une reprise complète des données géographiques et prescriptions réglementaires s'impose souvent.

Logiciels SIG et formats supportés

Les outils de géomatique doivent supporter les formats imposés par le standard :

• Formats vectoriels obligatoires v4.0 : GeoPackage (.gpkg) recommandé, shapefile (.shp) toléré, MapInfo TAB déprécié, GML 3.2.1 pour exports INSPIRE
• Encodage : UTF-8 obligatoire pour éviter les problèmes d'accents dans les attributs LIBELLE et TYPEPSC
• Géométries : polygones fermés, topologie propre (aucune auto-intersection), système de projection EPSG:2154

Logiciels testés compatibles v4.0 :

• QGIS 3.28+ avec plugin CNIG officiel (téléchargeable sur plugins.qgis.org)
• ArcGIS Pro 3.0+ avec extension Urbanisme (Esri France)
• FME 2023+ (Safe Software) pour conversions de formats massives

Attention aux bloqueurs techniques : Les versions antérieures d'ArcMap (10.x) ne gèrent pas correctement le GeoPackage. Une migration vers ArcGIS Pro ou QGIS devient alors indispensable pour respecter le standard.

Spécificités territoriales et prescriptions thématiques

Les SCoT frontaliers ou littoraux présentent des contraintes supplémentaires dans la structuration des couches :

• Zones littorales : intégration obligatoire de la bande des 100m (loi Littoral - articles L121-1 et suivants, notamment article L121-13) en couche PRESCRIPTION_SURF avec attribut STYPEPSC=07
• Espaces transfrontaliers : compatibilité avec les référentiels européens ETRS89 pour échanges transnationaux
• Zones de montagne : couches spécifiques UTN (Unités Touristiques Nouvelles) avec géométries ponctuelles ou surfaciques selon emprise

La version 4.0 offre une meilleure granularité pour ces prescriptions via des tables attributaires enrichies et une nomenclature TYPEPSC étendue (43 valeurs contre 28 en v3.0).

Éviter les erreurs GPU : optimisation des fichiers SCoT volumineux

Le validateur GPU est un outil en ligne officiel du Géoportail de l'Urbanisme qui vérifie automatiquement la conformité technique d'un SCoT numérisé avant sa transmission réglementaire aux services de l'État. Accessible sur geoportail-urbanisme.gouv.fr, il détecte les erreurs de structure, de nommage et de métadonnées.

Structure des fichiers : arborescence et validation

Le GPU rejette automatiquement les SCoT non conformes. Arborescence standard CNIG v4.0 (disponible sur cnig.gouv.fr/standard-scot-v4) :

• SCoT_[SIREN]/ — Répertoire racine
• PIECES_ECRITES/ — PADD.pdf, DOO.pdf, RAPPORT_PRESENTATION.pdf
• PRESCRIPTION/ — PRESCRIPTION_LIN.gpkg, PRESCRIPTION_PCT.gpkg, PRESCRIPTION_SURF.gpkg
• INFORMATION/ — INFO_SURF.gpkg
• ANNEXES/ — Documents annexes
• metadata.xml — Métadonnées ISO 19139

Contrôles géométriques obligatoires avec QGIS :

• Menu Vecteur > Outils de géométrie > Vérifier la validité
• Recherche des géométries nulles : expression $geometry IS NULL dans le calculateur de champs
• Topologie : aucun trou non intentionnel, aucun chevauchement (tolérance 0,01m)

Métadonnées XML (fichier metadata.xml à la racine) : Profil INSPIRE conforme ISO 19139. Générateurs recommandés : Metadata Wizard (plugin QGIS), ArcGIS Metadata Editor. Champs obligatoires : titre, résumé, organisation responsable, date de référence, emprise géographique, système de référence spatiale.

Optimisation des fichiers volumineux

Problème récurrent : Les SCoT étendus (>500 Mo) provoquent des timeouts lors du téléversement GPU, générant des échecs de transmission.

Solutions techniques éprouvées :

• Compression PDF : utiliser Acrobat DC avec profil "Standard PDF/A-2b" (norme ISO 19005-2 pour archivage pérenne), réduction résolution images à 300 dpi maximum, suppression métadonnées embarquées
• Simplification géométrique : algorithme Douglas-Peucker avec tolérance 1m pour couches surfaciques étendues (communes, zones agricoles), préservation géométries complexes pour périmètres réglementaires stricts
• Découpage thématique : séparer les prescriptions en fichiers distincts (environnement, mobilité, habitat) plutôt qu'une couche PRESCRIPTION_SURF unique de plusieurs milliers d'entités

Cas d'usage terrain : Le SCoT du Grand Clermont (171 communes, 560 000 habitants) a réduit son archive de transmission de 1,2 Go à 380 Mo en appliquant ces optimisations, permettant une validation GPU sans échec au premier dépôt.

Procédure de validation avec l'outil CNIG

L'outil officiel validateur GPU vérifie 47 points de contrôle :

• Conformité du nommage des fichiers (PRESCRIPTION_SURF.gpkg, pas de PRESCRIPTION_SURFacique.gpkg)
• Complétude des attributs obligatoires (champs LIBELLE, TYPEPSC, STYPEPSC, LIBELONG pour v4.0)
• Cohérence projection/emprise (EPSG:2154, emprise dans limites métropolitaines)
• Intégrité XML métadonnées (validation XSD du schéma ISO 19139)

Méthodologie recommandée en 4 étapes :

• Validation locale avant mise en production (itérations de correction sans contrainte de délai)
• Génération du rapport d'erreurs (export CSV avec localisation géographique des anomalies)
• Corrections itératives jusqu'à conformité 100% (tolérance zéro sur erreurs bloquantes)
• Archive finale au format ZIP (norme ISO 21320-1) avec checksum MD5 pour intégrité

Astuce technique : Conserver une version de travail non compressée (.gpkg sources + PDF non optimisés) pour faciliter les futures mises à jour réglementaires ou corrections mineures post-transmission.

Maintenance et anticipation des évolutions réglementaires

Documentation et traçabilité des versions

Tenir un registre de versionnement garantit la traçabilité des modifications :

• Version standard CNIG appliquée (1.0 à 4.0)
• Date de création initiale des couches SIG et des PDF
• Auteurs et prestataires intervenus (AMO, bureau d'études, service SIG interne)
• Modifications post-approbation : corrections d'erreurs matérielles, ajustements suite contrôle de légalité

Outil recommandé : Fichier HISTORY.txt à la racine du répertoire SCoT_[SIREN], mis à jour à chaque itération. Format type :

• 2023-03-15 — Création initiale v4.0 — Bureau études URBA+ — Approbation du 2023-02-10
• 2023-06-20 — Correction PRESCRIPTION_LIN attribut TYPEPSC — Service SIG Syndicat — Suite remarque DDT
• 2024-01-10 — Mise à jour métadonnées (contact responsable) — IDS France — Changement président Syndicat

Cette traçabilité simplifie les audits de conformité DDT/DREAL et sécurise juridiquement les archives du SCoT.

Veille réglementaire et migration anticipée

Le standard CNIG évolue tous les 3-4 ans en moyenne. Stratégie d'anticipation recommandée :

• Veille normative active : abonnement newsletter CNIG (cnig.gouv.fr), suivi groupe de travail GPU sur georezo.net
• Tests environnement développement : dès publication version beta (généralement 6 mois avant version finale)
• Migration progressive : planifier 6-9 mois avant obsolescence officielle d'une version pour éviter précipitation

Perspective 2026 : La version 5.0 prévisionnelle devrait intégrer les prescriptions du ZAN (Zéro Artificialisation Nette - loi n°2021-1104 du 22 août 2021, loi Climat et Résilience). Préparer dès maintenant une couche "consommation_espace" avec attributs surfaces_artificialisation facilitera la transition réglementaire.

Points clés à retenir

• Version 4.0 obligatoire pour tous les SCoT approuvés ou révisés depuis janvier 2023, sous peine de rejet GPU et non-conformité réglementaire
• Compatibilité SIG prioritaire : privilégier QGIS 3.28+ ou ArcGIS Pro 3.0+ avec support GeoPackage pour garantir la pérennité et l'interopérabilité
• Validation systématique via l'outil validateur GPU (geoportail-urbanisme.gouv.fr) avant toute transmission officielle pour éviter les rejets chronophages
• Optimisation fichiers indispensable : compression PDF/A-2b, simplification géométrique Douglas-Peucker et découpage thématique pour SCoT >500 Mo
• Traçabilité documentaire : fichier HISTORY.txt et métadonnées ISO 19115 complètes permettent d'anticiper les audits DDT et faciliter les mises à jour réglementaires futures