À horizon 1er janvier 2027, le paysage déclaratif français connaîtra son inflexion la plus structurante depuis la généralisation obligatoire de la DSN au 1er janvier 2017. La fiche n°3300 du GIP-MDS, mise à jour le 16 octobre 2025, confirme l’intégration de la DPAE en DSN via la norme P26V01 — coexistant initialement avec l’API DPAE actuelle (normes ACOSS NAT/5491 et NAT/5492, version d’octobre 2021). Pour les DSI d’ETI, les éditeurs SIRH et les grands comptes traitant plus de 100 embauches par mois, l’enjeu n’est pas théorique : il commande la roadmap des systèmes RH pour les 18 prochains mois.
Pourquoi l’API DPAE devient stratégique en 2026-2027
Trois facteurs convergent.
- Le volume. Le décret n°2014-628 a abaissé à 50 DPAE/an le seuil de dématérialisation obligatoire, mais en pratique tout employeur dépassant 200 embauches annuelles bascule en mode programmatique pour des raisons opérationnelles.
- La probation. L’AR généré par l’API est horodaté et structuré, et constitue la preuve formelle exigée par l’URSSAF en cas de contrôle.
- La convergence DSN-DPAE. Le maintien d’un double canal pendant la transition 2027 impose un middleware capable de router intelligemment.
L’API DPAE URSSAF actuelle (NAT/5491 et NAT/5492)
Architecture en deux étapes
L’API DPAE est un service REST/HTTPS en mode « machine to machine », documenté par deux normes ACOSS d’octobre 2021 :
- NAT/5491 — principes de fonctionnement (rôle des acteurs, contrôles, retours métier)
- NAT/5492 — guide d’implémentation (endpoints, format des messages, authentification)
L’architecture comporte deux étapes : authentification (récupération d’un jeton JWT) puis dépôt du flux XML.
Endpoints validés (NAT/5492)
| Service | URL |
|---|---|
| Authentification | https://mon.urssaf.fr/authentifier_dpae |
| Dépôt | https://depot.dpae-edi.urssaf.fr (port 8443 concentrateur) — ressource POST /deposer-dsn/1.0/ |
| Consultation des retours | https://consultation.dpae-edi.urssaf.fr |
| Téléchargement des retours | https://telechargement.dpae-edi.urssaf.fr |
La NAT/5492 indique explicitement : « Le nom de la ressource est bien
/deposer-dsn, même dans le contexte DPAE ». Cette incohérence piège
régulièrement les développeurs en intégration initiale.
Format technique
- Encodage XML :
<?xml version="1.0" encoding="ISO-8859-1" ?>(pas UTF-8 — source fréquente d’erreursB1-105-xx) - Compression :
Content-Encoding: gzip(corps gzippé envoyé en mode binaire) - Content-Type :
text/plain(oui, même pour du XML — spécification ACOSS) - Authentification :
Authorization: DSNLogin jeton=<token>(pour un concentrateur, ajouter,declarant=Siret;Nom;PRENOM) - Formats acceptés : XML structuré (schéma NEODeS) ou format à plat 990 caractères par DPAE
- Modes : TST (test) ou PRD (production), pilotés par la balise
<FR_DUE_Upload.Test.Indicator>(valeur120= production)
Codes erreur et retours métier
Les codes d’erreur sont stratifiés en blocs.
Bloc 1 — Pré-contrôles archives et fichiers :
| Code | Libellé | Déclencheur typique |
|---|---|---|
B1-104-02 |
Archive trop volumineuse | Zip > 90 Mo |
B1-104-06 |
Fichier de taille nulle | Body vide, erreur Content-Length |
B1-104-07 |
Fichier trop volumineux | Dépassement seuil |
B1-105-10 à 15 |
Format du fichier non reconnu | Type MIME ou extension non conforme |
Bloc 2 — Contrôles SIRET et statut :
| Code | Libellé | Action |
|---|---|---|
B1-201-01 |
SIRET inconnu | Vérifier référentiel INSEE |
B1-208-01 |
SIRET radié au JJ/MM/AAAA | Réouverture ou nouveau SIRET |
Codes retour métier (NAT/5491) :
- Code 00 — « Le traitement du message est correct » : DPAE acceptée, une référence dossier est renvoyée dans le champ
R_DOSSIER. - Code 98 — Doublon détecté : « Si un doublon de DPAE est détecté, le message code 98 est produit et la DPAE est rejetée ». La DPAE initiale est conservée, aucune action requise.
- Code 99 — Acceptation avec anomalies non bloquantes : la DPAE a été prise en compte mais elle contenait des erreurs sur un ou plusieurs champs facultatifs.
Retours mis à disposition
| Retour | Format | TST | PRD | Mise à disposition |
|---|---|---|---|---|
| AEE (Accusé d’Enregistrement Électronique) | XML structuré | ✅ | ✅ | Immédiat |
| AR (Accusé de Réception métier) | Format 120 (TXT/XML) | ✅ | ✅ | Sous 5 jours ouvrables |
| BIS (Bilan d’Identification du Salarié) | Doc v1.3 | ❌ | ✅ | J+1 de la date d’embauche |
| CR 11 (Bilan d’anomalies) | XML | ✅ | ✅ | Sous 5 jours |
| CR 41 (Certificat de conformité) | XML | ❌ | ✅ | Sous 5 jours |
Le BIS n’est généré que si une anomalie d’identification est détectée (NIR erroné, identité non reconnue par le SNGI). La NAT/5491 précise : « Ce document n’est pas un accusé de réception de DPAE et, en aucun cas, vous ne devez effectuer une nouvelle DPAE pour ces salariés pour corriger les DPAE déjà enregistrées ». Piège classique des intégrations naïves.
Période de rétention : 13 mois pour la consultation, 3 mois pour le téléchargement.
Le signalement DPAE en DSN au 1er janvier 2027
Le report d’un an annoncé par le GIP-MDS (fiche 3300, 16 octobre 2025) a deux conséquences :
- 2026 est une année de pré-configuration — le Cahier Technique DSN 2026 décrit déjà entièrement la mécanique mais le service n’est pas activé.
- 2027 lance la coexistence — API DPAE et signalement DSN coexisteront, les employeurs gardant le choix.
Caractéristiques du signalement
- Norme :
P26V01, signalement « 10 – Signalement Déclaration préalable à l’embauche » - Périmètre initial : régime général, CDI et CDD uniquement (intérim et MSA exclus)
- Canal : EDI, API ou EFI via net-entreprises.fr
- Champs clés : NIR ou numéro technique, SIRET, date prévisible d’embauche (
S21.G00.40.001), heure prévisible (S21.G00.40.083, format HHMM), nombre de jours de période d’essai (obligatoire CDI et CDD > 6 mois), identifiant SPST référencé parsst_dpae - Règle : 1 signalement = 1 individu = 1 contrat (pas de DPAE groupée), interruption de contrat = 2 signalements distincts
- Correction : un signalement « annule et remplace » génère une nouvelle DPAE
Comptes rendus métiers
- CRM 126 (DPAE) — équivalent de l’AR actuel, format XML, sur tableau de bord DSN ou dans le logiciel de paie. Inclut les codes 00 / 98 / 99 connus.
- CRM 121 (Identité) — remplace le BIS, fiabilise l’état civil et le NIR. Couplé au signalement SADV (Amorçage des Données Variables) pour le PAS.
Stratégies d’intégration selon votre architecture
Trois patterns d’architecture émergent selon la maturité SI.
Pattern 1 — TPE et PME (< 200 embauches / an)
Rester sur EFI net-entreprises.fr, basculer vers DSN signalement en 2027 via le logiciel de paie (PayFit, Silae, malibou). Coût d’intégration nul.
Pattern 2 — ETI (200 à 2 000 embauches / an)
API DPAE intégrée au SIRH, avec couche d’orchestration capable de basculer vers le signalement DSN dès 2027. C’est ici que les solutions spécialisées comme dpae.io apportent le ROI le plus net (élimination du double canal, monitoring centralisé, conformité prouvable).
Pattern 3 — Grands comptes / éditeurs (> 2 000 embauches / an)
Statut de concentrateur (charte GIP-MDS), API en mode multi-volumes (un flux contenant plusieurs SIRETs), retours en webhook vers un data lake RH. Inscription concentrateur à api-dpae@acoss.fr requise.
Garder l’API DPAE comme canal principal en 2026 → intégrer la P26V01 en mode test au Q4 2026 → basculer progressivement en 2027 selon les contrats (CDI/CDD via DSN, intérim et MSA via API).
Sécurité, RGPD et probation
L’API DPAE manipule des données personnelles sensibles (NIR, date de naissance). Trois exigences structurent l’intégration :
- Hébergement — les données doivent être traitées dans l’UE. Les serveurs URSSAF sont français.
- Chiffrement — HTTPS/TLS obligatoire, jamais de transmission en clair.
- Conservation — les AR doivent être archivés au minimum 5 ans, dans un coffre-fort numérique horodaté garantissant l’opposabilité (NF Z42-013 ou équivalent).
FAQ technique
Faut-il s’inscrire pour utiliser l’API DPAE ?
Oui en pratique : un abonné inscrit au service en ligne URSSAF est requis pour alimenter le flux d’authentification. Pour le statut de concentrateur, demande spécifique à api-dpae@acoss.fr.
Pourquoi l’erreur 422 Unprocessable Entity ?
Généralement Content-Encoding: gzip mais corps non gzippé, ou inversement. Ou Content-Type incorrect (doit rester text/plain selon NAT/5492).
Le signalement DSN remplacera-t-il l’API DPAE ?
Pas en 2027. Coexistence prévue, les employeurs choisissent leur canal. À moyen terme (2028+), la convergence est probable mais non décidée.
Comment gérer le passage 2026 → 2027 ?
Garder l’API DPAE comme canal principal en 2026, intégrer la P26V01 en mode test au Q4 2026, basculer progressivement en 2027 selon les contrats (CDI/CDD via DSN, intérim via API).
Les CTT (intérim) sont-ils éligibles à la DSN-DPAE ?
Non en 2027. Les entreprises de travail temporaire conservent l’API DPAE classique (ou EFI) pour leurs intérimaires.
Quel SLA garantit l’URSSAF ?
Pas de SLA formel public. En pratique : AEE quasi-immédiat, AR sous 5 jours ouvrables, BIS à J+1 de la date d’embauche.
Conclusion
L’API DPAE et le futur signalement DSN ne sont pas des sujets purement techniques : ils définissent la capacité d’une entreprise à industrialiser son onboarding tout en restant probante face à l’URSSAF. dpae.io propose une couche d’abstraction unifiée qui masque la complexité de l’API NAT/5492 et anticipe nativement la P26V01, permettant aux DSI d’éliminer le double canal sans surcharger leurs équipes.
Pour aller plus loin :