Petit point sur la DSN

C’est fait ! Une première vague d’entreprises et de tiers déclarants a été obligée de déposer pour la première fois une DSN concernant les salaires versés en avril et déclarables au 5 ou au 15 mai.

Cet article fait écho à celui-ci ou encore celui-là.

Sommaire :
Bref historique du projet
Quelles évolutions techniques pour cette norme ?
Vers une évolution structurelle pour la DSN : le transfert du calcul des cotisations
La DSN est un des outils pour construire le système de demain
La simplification du bulletin de paie : un cache-misère contre-productif

Bref historique du projet

Pour rappel, la déclaration sociale nominative est un dispositif visant à simplifier et harmoniser la collecte des données sociales auprès des employeurs. En projet depuis une quinzaine d’années, son point de départ législatif est la loi Warsmann promulguée en mars 2012 et prévoyant sa généralisation au premier janvier 2016 à tous les employeurs de droit privé (procédures alignées des régimes spéciaux comprises).

Sa construction s’est déroulée en trois étapes permettant une augmentation graduelle de la couverture fonctionnelle en phase avec un processus de normalisation regroupant de très nombreux acteurs de la protection sociale en France. On distingue la DSN de la norme NEODeS qui permet son implémentation technique dans les logiciels de paye. Un premier cahier des charges avait été produit à l’été 2012(que j’avais d’ailleurs implémenté dès novembre 2012 sur Odoo, encore nommé à l’époque OpenERP) puis un second portant les informations des DUCS URSSAF en 2013 et enfin un troisième élargissant le dispositifs aux autres DUCS.

La phase trois portant sur ce dernier cahier des charges sera lancée cet été. Nous sommes donc sur la bonne voie. Quelques points restaient encore à éclaircir lors des rencontres éditeurs en début d’année :

  • une question quant à l’impossibilité de renseigner le montant des exonérations (page 6 du compte rendu)
  • un taux d’erreur important lors de la reconstitution du salaire pour le calcul des IJSS (page 88/89 du support)
  • netEntreprise indique que 3% des déclarations ont rencontré des problèmes lors du dépôt de mai 2015

Soulignons également la complétude de la norme qui va jusqu’à prendre en charge avec souplesse la diversité des instituts de prévoyance tiers.

Quelles évolutions techniques pour cette norme ?

Certaines évolutions à moyen termes sont déjà perceptibles :

  • L’intégration de la DPAE (ex-DUE). Dans son rapport annuel 2013, le Comité de normalisation des données sociales propose d’intégrer la DPAE dans un message signalement d’intention d’embauche au sein de la DSN.
  • La Déclaration d’Accident du Travail : il serait logique que les données jusqu’ici fournies par une norme spécifique à la CNAMTS (ou par formulaire papier) soient reprises dans la DSN alors que la subrogation des IJSS en cas d’arrêt maladie est déjà supportée.
  • La prise en charge des nombreuses spécificités du secteur public sont actuellement étudiées par un groupe dédié de la caisse des dépôts (ici ou ). Un récent projet d’ordonnance semble orienter l’intégration de ces populations à horizon 2020. Les récents échecs des programmes RH Louvois, ONP et l’incertitude du programme SIRHEN ne sont probablement étrangers à ce délais particulièrement important.
  • La suppression des codes type personnel : actuellement la DSN reprend les CTP issus de la DUCS URSSAF. Ces agrégats semblent superflus et pourraient être supprimés dans les années à venir. La cohérence technique des données pouvant être assurée plus simplement.
  • La généralisation de l’usage du NIR pour identifier les salariés. Actuellement la norme spécifie pour chaque OPS si un numéro d’identification supplémentaire doit être porté par la norme (ex : donnée S21.G00.81). Par nature le NIR est destiné à la sphère sociale. C’est le rôle de chaque OPS de gérer une table de trans-codage transitoire si elle lui est techniquement indispensable.
  • L’accession gratuite et simple des entreprises à un dispositif de dématérialisation des fiches de payes. Le « coffre-fort électronique » dont parlent de nombreux tiers de confiance commerciaux pourrait facilement être assuré par l’ACOSS. Il ne s’agit après tout que de stocker des PDF (voire des fichiers XML ré-exploitables) et d’en garantir l’intégrité dans le temps…
  • Le passage au format XML : le cahier des charges de la phase 2 a introduit une notation sémantique des champs, les expressions régulières des contrôles reprennent la syntaxe XMLSchema et les fichiers de contrôles comme la structure de la norme sont eux-même en XML. Cela permettrait aux éditeurs de contrôler les fichiers à envoyer en contrôlant directement le respect du schéma XML dans leur programme plutôt que d’appeler un outil de contrôle externe.

Vers une évolution structurelle pour la DSN : le transfert du calcul des cotisations

Au delà ces changements techniques, la plus grosse avancée serait de déporter le calcul des cotisations sociales de l’entreprise vers les OPS. Comme l’expliquait Renaud Vatinet dans sont article La DSN : Quand la protection sociale entre dans une nouvelle ère, les informations portées par la DSN permettraient aux organismes de recouvrement de calculer l’ensemble des cotisations dues puis de retourner ces montants à l’entreprise qui pourrait si elle le souhaite vérifier les calculs.

Le régime agricole, au travers de la déclaration trimestrielle des salaires permettait jusqu’ici le pré-calcul des cotisations et leur appel chiffré. La MSA se positionne donc d’une certaine manière en précurseur sur ce sujet. J’avoue cependant ne pas comprendre comment était assurée la cohérence entre les appels trimestriels et les cotisations apparaissant sur les fiches de paie mensuelles des salariés…

Ce calcul déporté est un enjeu majeur pour le bien de notre système social. Une étape intermédiaire est possible : la création d’un répertoire unique et exhaustif des règles de calcul des cotisations et des exonérations. Là où logiciels de paye gèrent la complexité de la paie en ventilant les salariés par profiles de paye, il serait envisageable que les OPS créent et maintiennent un profil unique et un algorithme (abstraits via des fichiers XML et XSLT ?) permettant de calculer l’ensemble des lignes du bulletin de salaire de n’importe quel salarié Français (de droit privé). Les logiciels de paie privés continueraient à effectuer de manière autonome les calculs en exécutant scrupuleusement les règles de cette base. C’est techniquement moins complexe que la répartition des calculs entre tous les OPS mais cela apporte une bonne partie de la valeur attendue et donne une visibilité concrète pour piloter les futures réformes.

Une attention particulière devrait être portée :

  • à la gestion annualisée au fil de l’eau (plus de régulation en janvier n+1) du plafond de la sécurité sociale et autres cumuls du même type le cas échéant
  • à l’enrichissement du répertoire commun des déclarants, du RIE de l’ACOSS et du RNE de la MSA avec les données portant sur les zones géographiques sujettes à exonération de cotisations
  • aux interactions entre les conventions collectives et le calcul des cotisations sociales le cas échéant
  • à la prise en compte au plus tôt de cet objectif dans le développement de Cléa, futur système de recouvrement des URSSAF replaçant le SNV2

Reste à voir s’il est plus simple pour les OPS de supporter la complexité technique de répartition des calculs (chacun dans son coin avec synchronisation en temps très contraint/temps réel) ou bien de se mettre autour d’une table pour créer cette base de règles faisant référence et opposable.

La DSN est un des outils pour construire le système de demain

La DSN peut être vue comme une couche d’abstraction à la complexité historique de notre système de protection social. Un peu comme SESAM-Vitale pour l’assurance maladie, il permet de simplifier la vie des citoyens et des entreprises, de rendre plus efficients les OPS… et de redonner des leviers de réforme aux pouvoirs publics. En normalisant les relations entre les administrations et les tiers, de potentielles fusions ou transferts de compétences sont rendues un peu plus abordables.

Parmi les réformes très politiques envisageables qui tireraient un avantage de la DSN, on peut notamment citer :

  • le recouvrement des cotisations de retraite complémentaires du régime général par l’URSSAF
  • le rapprochement (fusion ou adossement) des régimes maladie préconisé par l’IGAS ou la convergence vers un régime maladie universel
  • la question complexe du prélèvement de l’IR à la source (ce qui suppose une individualisation de l’impôt et une phase transitoire complexe) qui pourrait être traitée en parallèle d’une hypothétique fusion de l’IR et de la CSG
  • la liquidation et le versement unique des pensions de retraite vers lesquels tend la toute nouvelle Union Retraite voire le rapprochement des régimes de retraite
  • la mensualisation des droits à la retraite
  • le rapprochement entre l’ACOSS et la DGFiP qui ont des besoins fonctionnels en partie similaires bien que la séparation entre les sphères fiscale et sociale soient très ancrées dans notre culture. On voit d’ailleurs que la DSN sert déjà de véhicule technique pour des données fiscales (notamment pour l’établissement de la CVAE).
  • l’abrogation de toute spécificité légale ou règlementaire de l’Alsace-Lorraine issue du rattachement à l’Allemagne entre la guerre de 1870 et la première guerre mondiale
  • la soumission des organismes paritaires aux PLFSS
  • le recalcul mensuel des droits sociaux et notamment ceux de la branche famille (même si la non disponibilité de ces données à rythme mensuel pour les indépendants risque de créer une inégalité de traitement inconstitutionnelle)
  • la diminution du non recours avec peut-être un jour la liquidation automatique des prestations sociales et un contrôle a priori de leur bonne répartition… voire même leur entrée dans l’assiette des revenus imposables

La simplification du bulletin de paie : un cache-misère contre-productif

Si la création de la DSN est le premier pas d’une démarche salvatrice pour le symbole de notre solidarité nationale, d’autres initiatives soit disant simplificatrices me semblent particulièrement contre-productives. La plus médiatique concerne la pseudo simplification du bulletin de paye.

Le gouvernement envisage en effet de regrouper les lignes de cotisation ayant trait au même domaine de protection sociale (maladie, retraite, chômage, famille) sur les bulletins de salaire.

Regrouper ces lignes est un cache misère grossier :

  • les entreprises devront continuer à calculer le détail de ce quelles doivent au titre des différentes cotisations et aux multiples OPS mais elles devront en plus calculer l’agrégat imprimé sur la fiche de paie
  • le regroupement de ces lignes complexifie la vérification des calculs par le salarié, ce qui est sensé être le fondement du bulletin de salaire
  • le regroupement des cotisations versées à des opérateurs publics et des assureurs privés à but lucratif (part complémentaire) encourage au désengagement de l’État
  • chaque cotisation représente un devoir, pendant d’un droit social acquis au cours des cinquante dernières années.
  • pour ce qui est de l’argument écologique : mieux vaudrait laisser aux URSSAF la création d’un espace en ligne permettant l’accès gratuit aux bulletins de salaires dématérialisés plutôt que de récréer une usine à gaz imposant aux entreprises de payer un tiers de confiance.
  • faire croire aux citoyens que le système de protection sociale est lisible au lieu de le réformer en profondeur ne serait qu’une magouille politique lamentable. Autant ne rien faire.

D’autre part, ce projet remet en question l’affichage de la part patronale des cotisations sur le bulletin de salaire. En tant que salarié je trouve indispensable de savoir combien je coute à mon employeur. Plutôt que de supprimer des informations, il vaudrait même mieux à terme faire apparaitre sur ce bulletin les réductions d’impôts comme le CICE ou à minima les exonérations (explicitées en DSN) qui pèsent sur nos finances publiques mais visent à améliorer notre compétitivité.

Tout cela pousserait peut-être à rationaliser le système tout en rendant l’information plus lisible pour le salarié et les calculs plus simples pour les entreprises. Les seuls perdants : les intermédiaires faisant leur beurre de la complexité déraisonnable du système ; qui restent malheureusement indispensables aujourd’hui.

Odoo : le leader des ERP libres sur la mauvaise pente

Presque un an jour pour jour après avoir clôturé un deuxième tour de table pour Odoo (ex-OpenERP, Anthony Lesuisse et Fabien Pinckears viennent d’annoncer officiellement qu’Odoo rejoindra Compière et OpenBravo au rang des logiciels de gestion ne proposant qu’un nombre limité de composants libres, honeypot permettant de vendre des modules premiums. C’est une des suites logiques du changement de licence annoncé en février (AGPL copyleft vers LGPL non copyleft).

J’avoue être complètement dégoutté. Mes réactions à chaud sur Twitter et la mailling list.

La communauté ne changera pas de licence : une licence non copyleft mettrait en danger des années de travail. Il ne sera donc plus possible d’installer des modules communautaires en AGPL et des modules « premiums » propriétaires sur la même instance. Modules propriétaires qui porteront probablement 90% de la valeur ajouté à partir de la version 10… Peut-être que l’OCA forkera d’ici quelques mois/années, comme Tryton en 2008… et quand bien même. SAP et Microsoft auront gagner : diviser pour mieux régner.

Comme le dit Raphaël Valyi, un vieux de la vieille en ce qui concerne OpenERP, ce énième changement de modèle économique donne bénédiction à tous ceux qui ont violé la licence AGPL depuis des années et n’ont jamais contribué à la communauté. Les parasites d’hier deviennent les modèles d’aujourd’hui alors que les contributeurs les plus actifs sont durement et durablement punis. On avait déjà eu un aperçu du peu de considération d’OpenERP SA envers sa communauté lors du feuilleton accompagnant la release de la v7, l’abandon très rapide du templating mako ou le renommage marketeux vomitif des Odoo Community Days en Odoo Experience… mais là c’est la totale.

On est loin de ce que nous vendait Fabien depuis dix ans : ci-dessous lors d’une présentation en 2011 ou encore dans ce billet datant de 2013. Et à voir le résultat de Compière et OpenBravo… j’ai pas l’impression que ça soit de bonne augure, sauf peut-être pour les détenteurs du capital à vision court-termiste.

Oui une entreprise doit gagner de l’argent… mais les moyens pour y arriver sont nombreux.

MAJ : d’après Fabien, les entités entrée au capital l’an dernier doivent garder leurs parts huit ans, ce qui peut semble à première vue moins court-termiste que je ne pensais

ebicsPy : ma première lib publiée sur Pipy

Je viens de publier sur Pipy une pré-version d’une bibliothèque Python que j’ai commencé il y a un an et demie. C’était ma première fois. Je pense qu’il y a encore pas mal de choses à ajuster dans le packaging et a minima la liste des dépendances.

Hasard du calendrier, je viens de retomber sur le mail d’inscription à QualifEbics,  qui est daté du 30 avril 2011 : presque 5 ans jour pour jour ! Ce serveur de qualification est gracieusement mis à disposition par Valerian (groupe Elcimaï) et je les en remercie.

Que fait-elle ?

Je sais que ce n’est pas très sexy mais ebicsPy permet d’implémenter facilement un client pour le protocole de communication bancaire EBICS. Il permet basiquement de recevoir les fichiers de relevés de comptes et d’envoyer les fichiers de virement.

Pour les plus anciens, c’est EBICS qui remplace ETEBAC3 et ETEBAC5 depuis la fermeture du réseau Transpac par feu France Telecom et la disparition du protocole X25. Désormais le transport de ces fichiers est assuré par le réseau internet (HTTPS/TCP/IP). Leur confidentialité et leur intégrité sont protégés par EBICS qui met en oeuvre une infrastructure de chiffrement et de signature à clés publiques (PKI en abrégé).

Où la trouver ?

Comme indiqué dans le titre, le package est disponible sur Pipy, le dépôt standard des bibliothèques Python. Vous pouvez télécharger l’archive ou utiliser des outils comme pip ou setuptools pour l’installer sur votre machine.

Je ne sais pas si j’aurai le courage de mettre à jour le package à chaque modification du code. Aussi vous pourrez trouver la version la plus à jour sur mon dépôt Launchpad. Là aussi vous pouvez télécharger l’archive ou utiliser Bazar pour cloner la branche. Je pense que je migrerai le dépôt sur Github un jour…

Qu’en faire ?

Comme toute bibliothèque, elle permet au développeur de créer des fonctionnalités le plus simplement possible. En l’espèce, ebicsPy peut aider à développer :

  • un script simple peu user-friendly mais redoutablement efficace
  • une IHM graphique sous semie-graphique
  • un outils appelable en ligne de commande par n’importe quel programme tiers
  • un serveur REST ou XMLRPC appelable par n’importe quel programme distant
  • un module EBICS pour n’importe quel outil de gestion d’entreprise codé en Python

J’ai choisi de concrétiser cette dernière possibilité en développant un module pour l’outil de gestion d’entreprise libre Odoo (ex-OpenERP). Il n’est pas encore packagé sur l’AppStore Odoo mais les sources sont disponibles sur mon dépôt Github.

C’est utilisable mais il y a encore un peu de boulot pour rendre le code plus présentable. Je pense qu’on pourra très bientôt utiliser EBICS directement dans Odoo :-).

Pourquoi avoir passé autant de temps là dessus ?

  • Pour tromper l’ennuie durant mon second semestre en Espagne
  • Pour apporter à Odoo une fonctionnalité sympa
  • Pour devenir (j’ai encore du boulot XD) un point de référence sur un domaine fonctionnel Odoo
  • Pour améliorer ma façon de coder en Python tout en faisant quelque chose d’utile et structuré
  • Peut-être un jour le vendre sur l’AppStore Odoo(double licence AGPL et LGPL ?) et gagner une pièce si ce que j’ai développé est utile. Le risque de la LGPL est de voir mon travail intégré dans un programme propriétaire sans mon accord… C’est ça ou empêcher mes potentiels clients d’utiliser les modules propriétaires sexy présents sur l’AppStore… question très difficile.