Ce qui change vraiment pour vos livrables GPU
Le sujet n'est plus "faut-il se mettre à jour ?", mais comment migrer proprement vos modèles de données. La page Ressources DDU du CNIG référence les versions récentes PLU v2025-06 et CC v2025-11, et le GPU expose désormais des modèles de validation cnig_PLU_2025 et cnig_CC_2025. Le GPU indique aussi l'ajout d'un contrôle sur certains champs "à valeur vide autorisée", avec une évolution annoncée d'avertissement vers erreur (voir les informations techniques GPU et les manuels GPU).
Ce que cela implique pour une collectivité / un bureau d'études
La migration ne se limite pas à "changer un nom de zip". En pratique, il faut :
- mettre à jour le gabarit de production (champs, présence des colonnes, structures),
- aligner les exports sur le millésime visé par le validateur GPU,
- tester les livrables avant téléversement (données + arborescence + métadonnées).
L'enjeu est double : éviter les rejets aujourd'hui et éviter les blocages quand un avertissement devient une erreur. Le GPU l'annonce explicitement dans ses informations techniques.
La bonne méthode de migration (simple et robuste)
- Choisir un millésime cible (PLU/CC 2025 si votre chaîne est prête).
- Mettre à jour le modèle interne (présence des champs, même si certaines valeurs peuvent rester vides selon standard).
- Contrôler les exports dans un environnement de recette.
- Valider sur le GPU avec le bon modèle.
- Documenter la version utilisée dans vos livrables et votre procédure interne.
Erreur fréquente
Continuer à produire avec un ancien gabarit "qui passait avant" puis corriger à la main après rapport GPU. Cette logique coûte cher (temps, reprises, risque d'oubli). Le plus efficace est de corriger la source (modèle métier), pas seulement l'archive finale. Pour comprendre les enjeux du validateur GPU et choisir la bonne version CNIG, consultez nos guides dédiés.