La carte communale concerne aujourd'hui plus de 15 000 communes françaises, soit près de 40 % du territoire national, et pourtant elle reste l'un des documents d'urbanisme les plus souvent rejetés lors du dépôt sur le Géoportail de l'Urbanisme. Conformément à l'arrêté du 17 décembre 2015, tout dépôt doit respecter le standard CNIG 2023 sous peine de rejet automatique — avec les délais et blocages de permis de construire que cela entraîne. Ce guide technique complet vous explique comment structurer votre carte communale pour un dépôt GPU accepté du premier coup.
Carte communale CNIG : définition, cadre réglementaire et obligations numériques
La carte communale est un document d'urbanisme simplifié, prévu par le code de l'urbanisme, dont le dépôt numérique sur le Géoportail de l'Urbanisme (GPU) au format CNIG est obligatoire depuis l'arrêté du 17 décembre 2015, et dont la non-conformité entraîne un rejet automatique bloquant l'opposabilité du document aux tiers.
Définie aux articles L.160-1 à L.161-4 et R.161-1 à R.161-12 du code de l'urbanisme, la carte communale délimite les secteurs constructibles et non constructibles d'une commune ne souhaitant pas élaborer un PLU ou un PLUi. Contrairement au PLU, elle ne comporte pas de règlement écrit ni de zonage détaillé par destination : elle se borne à indiquer où la constructibilité est autorisée, en s'appuyant sur le règlement national d'urbanisme (RNU) pour tout ce qui n'est pas explicitement délimité. Cette simplicité de fond ne doit cependant pas masquer une exigence de forme très précise imposée par le géostandard CNIG 2023.
La conformité au géostandard CNIG 2023 impose notamment les obligations suivantes :
- Un système de projection unique : RGF93/Lambert-93 (code EPSG 2154) pour la métropole — c'est le seul référentiel accepté par le GPU pour les données de France métropolitaine. Pour les DOM, des systèmes locaux s'appliquent : UTM 20N (EPSG 4559) pour les Antilles, UTM 22N (EPSG 2972) pour la Guyane, RGR92 (EPSG 2975) pour La Réunion.
- Une nomenclature de couches précise : les noms de fichiers shapefile ou GeoPackage doivent respecter exactement les intitulés définis dans le géostandard (ex.
ZONE_CC,DOC_URBA). - Des attributs obligatoires et typés : chaque entité géographique doit porter les champs définis dans le modèle de données CNIG, avec leurs types exacts (texte, date, entier).
- Un fichier de métadonnées ISO 19115 accompagnant la livraison, décrivant le contexte de production du document.
- L'absence de géométrie invalide : tout polygone auto-intersectant, trou non fermé ou artefact topologique entraîne un rejet automatique à l'import GPU.
Pour situer rapidement le document dans le paysage des documents d'urbanisme, le tableau ci-dessous compare la carte communale au PLU sur les critères les plus structurants :
| Critère | Carte communale (CC) | PLU / PLUi |
|---|---|---|
| Base légale | Art. L.160-1 à L.161-4 CU | Art. L.151-1 à L.153-60 CU |
| Règlement écrit | Non (RNU s'applique) | Oui, règlement détaillé par zone |
| Zonage | Constructible / Non constructible | U, AU, A, N avec sous-zones |
| Règles de forme urbaine | Non | Oui (hauteur, emprise, recul…) |
| Destinations du sol | Non différenciées | Différenciées par destination |
| OAP possibles | Non | Oui |
| Enquête publique | Oui (sauf révision simplifiée) | Oui |
| Communes concernées | Moins de 2 000 hab. en général | Toutes tailles |
| Couches GPU obligatoires | ZONE_CC, DOC_URBA | ZONE_PLU, DOC_URBA, REGLEMENT… |
| Complexité de production | Faible | Élevée |
| Standard CNIG applicable | Géostandard CC v2023 | Géostandard PLU v2023 |
Le choix entre les deux documents dépend des ambitions de développement de la commune et de la capacité de la collectivité à porter une procédure plus complexe. Pour les communes de moins de 2 000 habitants souhaitant simplement délimiter les secteurs constructibles sans réguler les formes urbaines, la carte communale est la solution la plus adaptée.
Couches ZONE_CC et DOC_URBA : attributs obligatoires et causes de rejet GPU
Le géostandard CNIG impose pour la carte communale un modèle de données composé de couches vecteur aux noms et attributs standardisés, dont l'absence ou le mauvais typage déclenche un rejet automatique lors de l'import GPU, avant même l'examen des données géographiques elles-mêmes.
La couche principale est ZONE_CC, qui contient les polygones de délimitation des secteurs de la carte communale. Chaque polygone doit porter au minimum les attributs suivants : IDZONE (identifiant unique de zone, chaîne de caractères), LIBELLE (libellé de zone, ex. "Secteur constructible"), TYPEZONE (code de type de zone selon la nomenclature CNIG — "ZC" pour zone constructible, "ZNC" pour zone non constructible), DESTDOMI (destination dominante, champ obligatoire même si non différenciée), URBA_OPP (opposition à opération, booléen), et DATAPPRO (date d'approbation au format ISO 8601 strict : AAAA-MM-JJ). Une date saisie au format 31/12/2023 au lieu de 2023-12-31 suffit à bloquer l'intégration.
La couche DOC_URBA est une table de référence sans géométrie contenant les métadonnées du document lui-même : numéro SIREN de la commune, nom de la commune, type de document (CC), état du document (APPROUVE, EN_REVISION, ABRO, etc.) et dates clés. C'est l'absence de cette table qui constitue la première cause de rejet constatée lors des dépôts GPU : de nombreux producteurs livrent uniquement ZONE_CC en pensant que la table de métadonnées est facultative, ce qui est incorrect.
Couches obligatoires et facultatives
Le tableau ci-dessous récapitule l'ensemble des couches attendues dans un lot de données conforme :
| Couche | Type géométrique | Obligatoire | Contenu |
|---|---|---|---|
ZONE_CC | Polygone | Oui | Secteurs constructibles et non constructibles |
DOC_URBA | Aucun (table) | Oui | Métadonnées du document d'urbanisme |
SECTEUR_CC | Polygone | Conditionnel | Sous-secteurs si plusieurs secteurs distincts |
PRESCRIPTION_SURF | Polygone | Non | Servitudes ou prescriptions surfaciques |
PRESCRIPTION_LIN | Ligne | Non | Prescriptions linéaires (alignements, etc.) |
PRESCRIPTION_PCT | Point | Non | Prescriptions ponctuelles |
INFO_SURF | Polygone | Non | Informations surfaciques complémentaires |
HABILLAGE_SURF | Polygone | Non | Éléments graphiques non réglementaires |
Erreurs attributaires les plus fréquentes
Parmi les causes de rejet liées aux attributs, on distingue trois catégories récurrentes. Premièrement, les erreurs de typage : un identifiant IDZONE saisi en entier alors que le modèle CNIG attend une chaîne de caractères, ou un champ booléen URBA_OPP renseigné avec "oui/non" au lieu de "true/false". Deuxièmement, les champs manquants : même si un attribut semble sans objet pour une petite commune (comme DESTDOMI dans un secteur homogène), il doit être présent avec une valeur nulle ou une valeur par défaut conforme. Troisièmement, les valeurs hors nomenclature : le champ TYPEZONE n'accepte que les codes définis dans le géostandard CNIG — toute valeur libre comme "Constructible centre-bourg" provoque une erreur de validation.
Le plugin CNIG Validator pour QGIS permet de détecter automatiquement la majorité de ces erreurs attributaires avant tout dépôt, ce qui en fait un outil indispensable dans le flux de production.
Erreurs topologiques GPU : comment valider la géométrie d'une carte communale
La validité topologique des données géographiques est la première cause de rejet lors du dépôt d'une carte communale sur le GPU, avant même les erreurs attributaires, et elle résulte dans la quasi-totalité des cas d'un nettoyage insuffisant des géométries en sortie de numérisation ou de fusion de couches.
La topologie d'une carte communale conforme au standard CNIG repose sur le principe que les polygones de zones doivent couvrir intégralement le territoire communal sans chevauchement ni lacune, en formant un pavage complet : tout point du ban communal doit appartenir à exactement une zone, qu'elle soit constructible ou non constructible. Les emprises de cours d'eau ou de voiries peuvent être exclues du pavage à condition d'être explicitement documentées dans les métadonnées.
Types d'erreurs topologiques bloquantes
Les erreurs topologiques les plus fréquentes relevées lors des contrôles GPU sont les suivantes. Les micro-chevauchements entre polygones adjacents, souvent générés lors d'opérations de fusion dans des logiciels SIG sans nettoyage topologique préalable : un chevauchement de 0,001 m² suffit à déclencher un rejet. Les lacunes entre polygones, c'est-à-dire des espaces non couverts entre deux zones, fréquents aux intersections de plusieurs entités numérisées indépendamment. Les polygones auto-intersectants, aussi appelés géométries en "nœud papillon", créés lors de digitalisations manuelles imprécises. Les anneaux intérieurs mal fermés, où le contour d'un trou dans un polygone n'est pas correctement refermé. Enfin, les doublons de géométrie, soit deux polygones occupant exactement le même espace, souvent issus d'une importation double depuis un fichier source.
Méthodes de détection et de correction
Pour prévenir ces erreurs, plusieurs approches complémentaires sont recommandées. Dans QGIS, l'outil "Vérifier la validité" de la boîte à outils de traitement permet un contrôle géométrique complet ; l'outil "Corriger les géométries" corrige automatiquement la majorité des polygones invalides. Dans ArcGIS Pro, les règles de topologie de geodatabase permettent de paramétrer des contraintes spécifiques (pas de chevauchement, couverture complète) et de les appliquer en lot. En environnement PostGIS, la fonction ST_IsValid() permet un contrôle systématique en base de données, et ST_MakeValid() assure la correction automatique.
La tolérance géométrique à respecter pour le GPU est de 0,001 m. Il est également impératif que les limites de zones s'appuient sur les contours de la commune issus de la BD CARTO® ou de la BD TOPO® IGN, et non sur des limites redessinées manuellement, pour éviter les décalages avec le fond de référence du GPU.
Arborescence ZIP et fichiers requis pour un dépôt GPU accepté du premier coup
Le lot de données d'une carte communale pour le GPU est une archive ZIP structurée selon une arborescence précise, dont le non-respect entraîne un rejet avant même la validation des données géographiques, indépendamment de la qualité du contenu.
L'archive ZIP doit contenir un dossier racine nommé selon le SIREN de la commune et la date d'approbation (ex. 212300123_CC_20231201), contenant les fichiers de données vecteur, le fichier de métadonnées XML au format ISO 19115, et le cas échéant les documents PDF du rapport de présentation et du règlement graphique. La convention de nommage du dossier racine est strictement contrôlée par le GPU : un dossier nommé librement ou sans le SIREN correct provoque un rejet immédiat.
Pour le format shapefile, chaque couche génère quatre fichiers associés (.shp, .dbf, .shx, .prj) qui doivent tous être présents sans exception. L'absence du fichier .prj déclarant le système de coordonnées est l'une des causes de rejet les plus fréquentes en format shapefile, car le GPU ne peut pas vérifier la cohérence de projection sans ce fichier. Une erreur courante consiste à exporter depuis QGIS en cochant "Ajouter au projet" sans vérifier que le .prj a bien été généré. Pour le format GeoPackage (.gpkg), recommandé par le CNIG, un fichier unique contient l'ensemble des couches, ce qui élimine le risque d'oubli de fichier associé et lève également la contrainte de troncature des noms de champs à 10 caractères imposée par le format shapefile.
Le fichier de métadonnées ISO 19115 doit décrire au minimum : le titre du document, la date de création, la date de mise à jour, l'emprise géographique (bounding box en WGS84), le nom de l'organisme producteur, le point de contact, le système de référence spatial, et la conformité au géostandard CNIG 2023. Le CNIG met à disposition un modèle de fiche de métadonnées pré-rempli pour les cartes communales, qu'il est fortement conseillé d'utiliser comme base pour ne rien omettre.
Avant tout dépôt officiel, l'utilisation de l'outil de validation en ligne du GPU est une étape indispensable : il permet de soumettre le lot de données pour contrôle automatique sans engager la procédure d'intégration définitive, et retourne un rapport listant les erreurs bloquantes (qui empêchent l'import) et les avertissements non bloquants (qui n'empêchent pas l'import mais signalent des anomalies). Corriger les erreurs bloquantes avant soumission officielle est la pratique la plus efficace pour réduire le taux de rejet lors de la soumission au Géoportail de l'Urbanisme.
Réviser une carte communale sur le GPU : procédure, champs ETAT et DATVALID
La révision d'une carte communale sur le GPU est une procédure distincte du dépôt initial, soumise aux articles R.161-8 à R.161-12 du code de l'urbanisme, qui nécessite une mise à jour précise des champs ETAT et DATVALID de la table DOC_URBA pour refléter l'état juridique réel du document à chaque étape de la procédure.
La révision suit en principe la même procédure que l'élaboration, incluant une enquête publique. Toutefois, l'article L.161-3 du code de l'urbanisme prévoit une procédure de révision simplifiée, sans enquête publique, lorsque la révision ne porte pas atteinte à l'économie générale du document et ne réduit pas les espaces naturels, agricoles ou forestiers. Dans ce cas, une simple consultation des personnes publiques associées et une délibération du conseil municipal suffisent.
Concernant le délai de publication post-approbation, le code de l'urbanisme n'impose pas de délai précis entre l'approbation en conseil municipal et le dépôt sur le GPU. Cependant, le document n'est opposable aux tiers — et donc ne peut pas fonder l'instruction des permis de construire — qu'après sa publication sur le GPU et sa transmission au préfet conformément à l'article L.161-4. En pratique, les services de l'État recommandent un dépôt dans les deux mois suivant l'approbation pour ne pas bloquer l'instruction des autorisations d'urbanisme sur la commune.
Les points de vigilance propres aux mises à jour sont les suivants. La continuité des identifiants de zones : si une zone existante est modifiée, son identifiant IDZONE doit être conservé pour assurer la traçabilité ; une nouvelle zone reçoit un nouvel identifiant unique. La date d'approbation dans le champ DATAPPRO doit correspondre à la date de la délibération du conseil municipal approuvant la révision, pas à la date de dépôt sur le GPU. Le champ DATVALID indique la date à partir de laquelle le document est exécutoire, c'est-à-dire après transmission au préfet et, le cas échéant, après le délai d'un mois prévu à l'article L.161-4. Enfin, conserver localement une copie de chaque lot de données déposé avec son rapport de validation est une bonne pratique, car le GPU conserve l'historique des versions mais ne garantit pas la reproductibilité des rapports de validation antérieurs.
Lorsqu'une commune passe d'une carte communale à un PLU suite à l'élaboration d'un nouveau document d'urbanisme, le champ ETAT de la carte communale doit être mis à jour avec le code ABRO (abrogé) dans la table DOC_URBA, avec la date d'abrogation correspondant à l'approbation du PLU. Cette mise à jour est fréquemment oubliée, créant des incohérences dans la base GPU et des informations contradictoires pour les utilisateurs du Géoportail de l'Urbanisme.
FAQ
Points clés à retenir
| Point de contrôle | Détail technique |
|---|---|
| Cadre réglementaire | La carte communale est définie aux articles L.160-1 à L.161-4 et R.161-1 à R.161-12 du code de l'urbanisme ; son dépôt numérique sur le GPU est obligatoire depuis l'arrêté du 17 décembre 2015. |
| Projection obligatoire | Le système RGF93/Lambert-93 (EPSG 2154) est le seul référentiel accepté pour la métropole ; des systèmes locaux s'appliquent dans les DOM. |
| Couches obligatoires | ZONE_CC et DOC_URBA sont les deux seules couches dont l'absence entraîne un rejet automatique et immédiat lors de l'import GPU. |
| Format des attributs | Les dates doivent impérativement être au format ISO 8601 (AAAA-MM-JJ) ; tout autre format bloque l'intégration quelle que soit la qualité des géométries. |
| Topologie | Les micro-chevauchements, lacunes et géométries auto-intersectantes sont contrôlés automatiquement par le GPU et constituent la première cause de rejet. |
| Arborescence ZIP | Le dossier racine doit être nommé selon le SIREN communal ; un fichier .prj manquant dans un shapefile est une cause de rejet fréquente et facilement évitable. |
| Validation préalable | L'outil de validation en ligne du GPU permet de tester le lot de données avant soumission officielle : cette étape réduit significativement le taux de rejet. |
| Révision | Les champs ETAT et DATVALID de DOC_URBA doivent refléter l'état juridique réel du document à chaque étape de la procédure de révision. |
| Délai de publication | Le document n'est opposable aux tiers qu'après publication sur le GPU et transmission au préfet ; un dépôt dans les deux mois post-approbation est recommandé pour ne pas bloquer les permis de construire. |
| Abrogation | Le passage à un PLU impose la mise à jour du champ ETAT de la carte communale avec le code ABRO et la date d'abrogation correspondante dans la base GPU. |
Votre commune ou votre bureau d'études rencontre des difficultés pour structurer une carte communale conforme au standard CNIG ? Les équipes d'IDS France accompagnent les collectivités et les bureaux d'études dans la production, la vérification topologique et le dépôt de documents d'urbanisme sur le GPU. Contactez-nous pour un audit de votre lot de données ou un accompagnement complet de la structuration à l'intégration.
*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.*