Zonage PLU : la réponse pré-faisabilité numéro 1, en 200 ms

Persona : architectes, marchands de biens, proptech, banques, foncières. Temps : 5 min de lecture. Budget : 199 EUR/mois (plan Pro), endpoint réservé aux comptes Pro et plus.

TL;DR : on a branché chaque permis sur le Géoportail de l'Urbanisme. Un appel, le code de zone (UA / UB / AU / A / N), un verdict booléen constructible, et la raison juridique. 200 ms de latence. Plus besoin de naviguer geoportail-urbanisme.gouv.fr commune par commune.

Le problème métier

Un architecte regarde une parcelle. Avant tout : est-ce constructible ?

Le réflexe historique : ouvrir geoportail-urbanisme.gouv.fr, taper l'adresse, attendre que la commune charge, cliquer sur le calque "zonage", lire la légende. 3-5 minutes par parcelle. Multipliez par 10 dossiers par semaine, vous avez perdu 4-8h.

Pire : ~20 % des communes FR n'ont pas digitalisé leur PLU sur Géoportail. Quand vous tombez sur une de ces communes, vous le découvrez après avoir cherché. Frustrant.

Le réflexe API :

curl -H "X-API-Key: pk_..." \
  https://api.permisapi.fr/v1/permits/PC07404021K1/plu

Réponse en 200-500 ms :

{
  "num_pa": "PC07404021K1",
  "lat": 48.8566, "lng": 2.3522,
  "has_plu": true,
  "zonage": {
    "code": "UB",
    "libelle": "Zone urbaine de densité moyenne",
    "type_zone": "U",
    "constructible": true,
    "constructible_reason": "Zone urbaine constructible (zonage commençant par U).",
    "plu_revision_date": "2018-04-12",
    "plu_partition": "DU_PLU_75056_001"
  },
  "other_zones": [],
  "source": "Géoportail de l'Urbanisme via apicarto.ign.fr"
}

Vous avez la réponse, vous savez si la commune a un PLU digitalisé, vous avez la date de la dernière révision, vous avez l'identifiant du document PLU pour pouvoir creuser.

Les 4 zones qui décident tout

Le Code de l'urbanisme français définit 4 grandes catégories de zonage PLU. C'est ce que retourne notre endpoint.

Zone U (urbain). Préfixes UA, UB, UC, UD, UE, UF, UH, UI, UR, UZ. Construite et équipée, constructible directement sous les règles du PLU. C'est le sweet spot pour la plupart des projets.

Zone AU (à urbaniser). Préfixes AU, 1AU, 2AU. Réservée à l'urbanisation future. Constructible mais sous conditions définies par le PLU : ouverture progressive, équipements à réaliser, parfois OAP (Orientations d'Aménagement et de Programmation) à respecter. Sweet spot pour les promoteurs qui anticipent.

Zone A (agricole). Non constructible sauf exceptions strictes : extensions limitées de l'existant, bâtiments d'exploitation agricole. Disqualifiant pour 95 % des projets MDB.

Zone N (naturelle). Idem agricole : non constructible sauf STECAL (Secteurs de Taille Et de Capacité d'Accueil Limitées) ou bâtiments existants. Disqualifiant à 95 %.

Notre endpoint classifie automatiquement le code reçu et renvoie un booléen constructible plus une raison textuelle. Pour les zonages exotiques (zones spécifiques d'un PLU local), constructible: null et la raison explique pourquoi on ne sait pas trancher automatiquement.

La source de données

Géoportail de l'Urbanisme (GPU). Plateforme officielle de l'État, alimentée par les communes qui versent leurs documents PLU au format CNIG. Données structurées, mises à jour à chaque révision PLU communale.

Accès : on consomme via apicarto.ign.fr, l'API publique de l'IGN qui wrap Géoportail GPU. Gratuit, pas d'authentification, pas de quota documenté (mais cache poli côté client recommandé).

GET https://apicarto.ign.fr/api/gpu/zone-urba?geom={"type":"Point","coordinates":[lng,lat]}

L'architecture côté PermisAPI

Pas d'ETL, pas de stockage. V0.1 = appel live à chaque requête /plu. Pourquoi ce choix :

Données fraîches : si une commune révise son PLU mardi, vous l'avez mercredi. Pas de recalcul mensuel à attendre.
DB Free tier protégée : on ne stocke pas 36 000 PLU communaux dans Neon (estimé +500 MB de geometry).
Latence acceptable : 200-500 ms en cold, ~150 ms en chaud côté apicarto. Pour un endpoint pré-faisabilité, c'est largement OK.

Le compromis : si apicarto.ign.fr est down (rare mais ça arrive), on retourne has_plu: false avec une raison explicite. Le client peut décider de retenter ou de fallback sur un check manuel.

V0.2 prévu (si traction) : cache Redis 7 jours sur (round(lat, 5), round(lng, 5)). À 1 m de précision, c'est suffisant pour la plupart des cas d'usage.

Les 3 cas particuliers à connaître

1. Communes sans PLU digitalisé. ~20 % des communes FR (essentiellement rurales) n'ont pas encore mis leur PLU sur Géoportail. L'endpoint retourne has_plu: false avec une raison qui suggère de vérifier en mairie. Le client peut soit accepter, soit fallback sur une stratégie (ex : utiliser le RNU = Règlement National d'Urbanisme par défaut, qui est plus restrictif).

2. Plusieurs zones sur le même point. Rare mais possible : un point peut tomber sur plusieurs polygones (zone urbaine + servitude d'utilité publique, par exemple). L'endpoint renvoie le zonage primaire dans zonage et les autres dans other_zones. Au client de décider lequel prime.

3. PLU vs PLUi vs RNU. Géoportail couvre les PLU communaux ET les PLUi (intercommunaux). Le champ plu_partition contient l'identifiant du document, qui commence par DU_PLU_, DU_PLUi_ ou DU_CC_ (carte communale). Pour les communes en RNU pur (sans document local), has_plu: false avec raison explicite.

Cas d'usage concrets

Architecte en phase faisabilité. Avant d'engager 4h de pré-étude, l'API te dit en 1 appel si la parcelle est en U, AU, A ou N. Si A ou N, tu fermes le dossier ou tu pivote vers de l'extension limitée. Si U ou AU, tu continues. Économie : 3 minutes par dossier × 30 dossiers/mois = 90 minutes/mois économisés sur un seul cabinet.

Marchand de biens en sourcing. Tu reçois 50 permis dans ton webhook chaque semaine via /v1/alerts. Pour chacun, tu appelles /plu côté serveur. Tu ne montres au commercial que les permis en zone U ou AU. Les A et N filent direct au "rejected". Économie : 8h/semaine sur le tri manuel.

Proptech avec scoring de constructibilité. Tu enrichis ton produit avec un signal constructible: bool natif. Les utilisateurs filtrent leurs résultats par "zone urbaine uniquement" en 1 click. Plus de UX flexibility sans coder l'ingestion PLU communale (~2 semaines de dev).

Banque en analyse crédit. Pour un crédit immobilier sur du neuf, vérifier que la parcelle visée est bien constructible évite des dossiers qui partent en désastre. 1 appel API en pré-validation, c'est intégré au workflow KYC.

L'utiliser dans votre stack

L'endpoint est documenté sur https://api.permisapi.fr/docs avec try-it-out. Plan Pro à 199 EUR/mois inclut PLU + DVF + Score MDB + SIRENE + Cadastre + France entière + historique complet.

# SDK Python (permisapi-client >= 0.5.0)
from permisapi_client import PermisAPI

client = PermisAPI(api_key="pk_live_...")
plu = client.permits.plu("PC07404021K1")

if not plu["has_plu"]:
    print(f"PLU indisponible : {plu['not_covered_reason']}")
else:
    z = plu["zonage"]
    print(f"Zone {z['code']} ({z['libelle']})")
    print(f"Constructible : {z['constructible']}")
    print(f"Raison : {z['constructible_reason']}")
    print(f"Dernière révision PLU : {z['plu_revision_date']}")

// Vanilla fetch
const resp = await fetch(
  "https://api.permisapi.fr/v1/permits/PC07404021K1/plu",
  { headers: { "X-API-Key": "pk_live_..." } }
);
const { has_plu, zonage } = await resp.json();
if (has_plu && zonage.constructible) {
  // Continuer le workflow
}

Limites V0.1

Pas de cache. Latence 200-500 ms par appel. Si vous bouclez sur 1000 permis, comptez 5-10 minutes au total. V0.2 prévoit un cache Redis 7j qui réduira à <50 ms les hits chauds.
Pas de prescriptions. Pour V1, on ne retourne que le zonage de base. Les prescriptions PLU (servitudes EBC, espaces protégés, marges de recul) sont dans des endpoints apicarto séparés que nous n'agrégeons pas encore. Backlog V0.3.
Pas de version historique du PLU. Si une commune révise son PLU, on retourne la version actuelle. L'historique des révisions n'est pas accessible via apicarto. Pour les gros dossiers, vérifier plu_revision_date et la date du permis.

Pourquoi on l'a construit

PermisAPI est ma boîte solo. La feature DVF cross-ref a déjà transformé la perception du produit ("ah ok, c'est pas qu'un wrapper Sitadel"). PLU est la deuxième brique du même mouvement : transformer un permis en package pré-faisabilité.

Avec PLU + DVF + Score MDB + SIRENE en 5 appels parallèles (Vue 360° dans le dashboard), on est passé d'un wrapper d'API publique à un agrégateur foncier qui justifie son prix. C'est la même approche que Stripe avec leur enrichissement Stripe Atlas, ou Plaid avec leur enrichissement transactionnel.

Et si vous avez des suggestions d'évolution (autres calques apicarto, formats de réponse, granularités), répondez à cet article ou écrivez à evan@permisapi.fr.