Discussion :

[dg78]

@ Marco46

Merci pour votre retour,

Avez-vous lu le blog en entier ? notamment les articles :
22 la DSN, une usine à gaz
51 une solution simple, efficace et facile à mettre en œuvre

Vous pouvez vous aider avec ‘le plan du blog’ dans la partie droite.

[Marco46]

Merci c'est difficile de s'y retrouver quand on ouvre la boite sans connaitre le sujet

Effectivement le format est hallucinant on dirait des vieux fichiers .ini tout pourris :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
S20.50.01.01=10
S20.50.01.02=87
S20.50.01.01=4.2
S20.50.01.02=71.6

J'ai lu pourtant sur une des documentation je sais plus laquelle (j'ai téléchargé DSN_Guide-implementation-API_v4-1_2018-08-16.zip) qu'il y avait des endpoints en POST qui supportent le XML et le json. Il doit donc bien être possible d'utiliser des formats modernes voire même de valider vos données via un schéma ? Ça permet pas de couvrir toutes les règles de gestion mais c'est déjà plus lisible et ça permet de valider les données brutes et certaines cardinalités.

Concernant l'histoire des codes, si j'ai bien compris le problème c'est qu'au lieu de servir de proxy et de masquer la complexité des spécificités de chaque organisme, la DSN ne fait que passe plat et oblige donc chaque éditeur à utiliser les codes de chaque organisme au lieu de convertir lui-même en fonction du cas. Le but me semble assez clair, s'ils avaient du rendre ce service ils auraient du gérer tous les cas d'erreur et donc ils auraient porté une responsabilité. Dans le cadre actuel ils peuvent se rabattre sur les éditeurs en disant que c'est eux qui ont mal implémenté.

Concernant les évolutions annuelles de la spec, un des principes de base de l'interopérabilité c'est d'être strict sur ce qu'on envoie et souple sur ce qu'on accepte. Internet tout entier est fondé sur ce principe c'est expliqué dans je ne sais plus qu'elle RFC. Là on se retrouve avec un système qui est strict à tout point de vue. Dans l'exemple que vous donnez le système ne devrait pas rejeter une paie avec le code 3 mais simplement donner un warning. Là aussi j'imagine que le but est de pouvoir se retourner contre les éditeurs.

Concernant la normalisation des codes des rubriques des paies j'étais persuadé que ça avait été fait comme pour la compta !! Effectivement le plus propre serait de loin de fournir une normalisation à laquelle chaque éditeur s'adapterait et ensuite de fournir au système les données en respectant cette normalisation, charge à lui de redistribuer derrière aux organismes.

Là si je comprends bien pour une rubrique donnée vous devez la fournir en autant d'occurrence que d'organismes qui la demande avec leur code spécifique ?

En bout de ligne on est bien loin de la notion de service public effectivement ! On est plutôt sur un jeu malsain consistant à transférer la responsabilité aux entreprises, et les conséquences aux contribuables

[dg78]

Oui, il existe également une API (webservice) (xml) en plus de l’envoi d’un fichier de type DSN. Tous les éditeurs ne l’utilisent pas (moi le premier) mais c’est toujours du même principe : message / bloc / rubrique.

Je viens de m’apercevoir qu’un article (19 les Informations sur la DSN – les liens utiles ) avait été mis sur le blog mais en non publié. Je viens d’activer la publication. Dans cet article, se trouvent les liens des différents cahiers techniques. Le mieux est d’en ouvrir un, par exemple :

http://www.dsn-info.fr/documentation/dsn_cahier_technique_p3_2018.1.pdf


Vous verrez la notion de messages / blocs / rubriques et les codes (pêle-mêle) de tous les organismes.

En compta, il existe un plan comptable normalisé (PCG), il n’en est rien en paie.

[Marco46]

Ok donc en définitive votre critique sur la DSN c'est de faire porter toute la complexité, le risque et donc la responsabilité aux éditeurs au lieu de fournir un vrai service simple d'accès servant de guichet unique avec un format descriptif des fiches de paies simple sur le modèle du PCG en compta.

[Grogro]

Ok donc en définitive votre critique sur la DSN c'est de faire porter toute la complexité, le risque et donc la responsabilité aux éditeurs au lieu de fournir un vrai service simple d'accès servant de guichet unique avec un format descriptif des fiches de paies simple sur le modèle du PCG en compta.

Si c'est cela, est-ce qu'il y a des blocages administratifs, politiques, ou réglementaires, qui expliquent cette difficulté ?

[dg78]

Ok donc en définitive votre critique sur la DSN c'est de faire porter toute la complexité, le risque et donc la responsabilité aux éditeurs au lieu de fournir un vrai service simple d'accès servant de guichet unique avec un format descriptif des fiches de paies simple sur le modèle du PCG en compta.

Oui mais les gros éditeurs (et les gros cabinets d’expertise comptable) sont complices de cette complexité (lire les différents articles du blog).
Ceux qui pâtissent de cette situation : les TPE, certains organismes, les petits éditeurs et au final les salariés.

Je ne désespère pas qu’un jour cette simplification arrive, contrainte et forcée. Le GIP-MDS commence à en prendre conscience. Pour tout dire, j’ai été invité à co-animer (un bien grand mot) un atelier intitulé ‘Plan de paie harmonisé’, fin juin au premier club qualité organisé par le GIP-MDS, atelier proposé suite à une de mes interventions en réunion (lire anecdote 3 sur le blog). J’en parlerais dans un prochain article sur mon blog.

Si c'est cela, est-ce qu'il y a des blocages administratifs, politiques, ou réglementaires, qui expliquent cette difficulté ?

Non, il suffit simplement de redescendre sur terre et de vouloir simplifier mais ce n’est pas l’intérêt des lobbies (gros éditeurs / experts-comptables) car il y a énormément d'argent en jeu. Par exemple, un DRH d'un gros groupe (18 000 salariés) m'a indiqué que, rien qu'en modifications de logiciels (sans tenir compte de la formation et tout autour) lui avait coûté 500 K€.

[François DORIN]

Bonjour,

Pour ma part, je vais me faire l'avocat du diable (car j'aime bien ce rôle, c'est intéressant et stimulant intellectuellement de défendre une position que l'on n'a pas ).

Rappelons l'objectif du DSN. Avant, les entreprises devaient déclarer auprès de nombreux organismes des informations concernant leurs employés (URSAFF, CPAM, AGIRC, ARCCO, etc). L'objectif était d'arrêter de faire 36 déclarations, et de n'en faire qu'une. A la charge ensuite au collecteur de faire le dispatch entre les différents organismes.

De ce point de vue, c'est plutôt une réussite. Il est simple, pour une entreprise de faire le DSN. Une seule démarche, et c'est finie (notons que pour l'instant, je n'aborde pas la technique, qui n'est que le moyen pas la fin).



Regardons un peu maintenant le côté technique, puisque c'est surtout celui-ci dont il est question ici. J'ai largement envie de dire que l'avis donné ici est fortement biaisé. Nous n'avons en effet que l'avis d'un éditeur. Or, il n'y a pas que les éditeurs à prendre en compte, mais aussi les organismes destinataires.

Je me mets à la place d'un organisme. Contrairement à ce qui est sous-entendu, parser un fichier de ce type pour n'en extraire que les informations nécessaires pour un organisme précis est extrêmement simple. Chaque organisme connait ses codes, et peut donc récupérer ses informations. Comme chaque information est présente sur une ligne, si une ligne ne nous concerne pas, on l'ignore. Point barre.

La simplification voulue initialement n'était pas d'uniformiser les informations utilisées par chaque organisme, mais de ne faire qu'une seule déclaration.

Sur le format une ligne = une donnée, que j'opposerais au format CSV puisqu'il en est question dans la discussion. Si on lit les documents, on se rend compte d'une chose : le format sera évolutif. Ou plutôt, les codes utilisés seront évolutifs. Le format en lui même ne changera pas. L'avantage du format retenu par DSN, c'est qu'une évolution est intrinsèquement pris en compte. Si un organisme abandonne un code, il lui suffit de l'ignorer. Si une nouvelle information apparait, il suffit de lui ajouter un nouveau code. Et le tour est joué.

Si on utilise un format CSV, une évolution signifie ajouter des colonnes, potentiellement en supprimer, et donc modifier drastiquement la signification des colonnes. Le CSV peut être très bien pour représenter le format à un instant T, mais pas pour gérer les évolutions futures.

Il reste qu'il est dommage qu'il n'y ait pas eu simplification via uniformisation. Mais cela peut se comprendre. Uniformisation, cela signifie aussi modification des données reçues par les différentes organismes, avec les conséquences d'erreur possible dans les mappings, changement d'unité, etc...

Ici, rappelons le, l'objectif était de simplifier les choses en permettant aux entreprises de ne faire qu'une seule déclaration, pas de remettre à plat les systèmes. Je suis prêt à parier que ce qui s'est fait, c'est juste pour chaque organisme, un connecteur qui extrait les informations du DSN pour en retirer les informations et les transformer dans le format qu'elles utilisaient avant. Ce genre de connecteur est rapide à développer puisqu'il n'y a pas de modification/traduction/conversion de données à faire.

Résultat des courses, la complexité du système est porté par les éditeurs. Du coup, se sont les éditeurs, et indirectement les entreprises, qui paient pour la mise en place du DSN, pour un impact faible pour les organismes en question.

Maintenant, en lisant certains des documents, on voit que l'évolution est au coeur du format, et je devine que derrière, il y a la perspective de l'uniformisation.

Faut-il se plaindre que l'uniformisation n'ait pas eu lieu en même temps que la mise en place du DSN ? Il est déjà complexe de mettre en place un système de déclaration unique. Si de plus, il fallait coordonner les 36 organismes pour qu'ils uniformisent leurs données ensemble le même jour... Donc, pour ma part, je trouve que non. Le fait de séparer les deux est une bonne chose. Ainsi, chaque organisme pourra s'uniformiser à son rythme dès lors qu'un référentiel commun aura été établi.

Maintenant, j'entends que les grands éditeurs sont complices. Dans un sens, je pense que cela est vrai, mais pas forcément pour les raisons que l'on croit. Ils sont complices non pas parce qu'ils ont organisé cela (à mon avis, ils n'avaient même pas grand chose à dire la dessus), mais par leur coopération avec ce nouveau système. Un tel changement, c'était la mort assurer pour de nombreux "petits" éditeurs qui ne pourraient pas suivre, et donc des parts de marché supplémentaires. Et vu que c'est une obligation légale, il était facile pour eux de reporter le coût sur leurs clients.

[Marco46]

Faut-il se plaindre que l'uniformisation n'ait pas eu lieu en même temps que la mise en place du DSN ? Il est déjà complexe de mettre en place un système de déclaration unique. Si de plus, il fallait coordonner les 36 organismes pour qu'ils uniformisent leurs données ensemble le même jour... Donc, pour ma part, je trouve que non. Le fait de séparer les deux est une bonne chose. Ainsi, chaque organisme pourra s'uniformiser à son rythme dès lors qu'un référentiel commun aura été établi.

Avec un référentiel commun pour gérer les paies (un contrat d'interface commun entre éditeurs de logiciels de paie et DGIFip) les organismes n'auraient pas eu besoin de changer quoi que ce soit. Il "suffisait" (gros guillemets) d'implémenter les adapters du côtés du SI de la DGIFip. Or là ils demandent à chaque éditeur de faire le boulot à leur place.

En terme d'architecture et de simplicité ils ne pouvaient pas faire pire et initialement tout ceci fait quand même partie du fameux "choc de simplification" de Hollande. Il s'agissait de mieux organiser la société dans son ensemble, pas de protéger quelques chefaillons des conséquences d'un échec du système pour leur carrière, car pour moi, connaissant un peu ce genre de milieu, je pense que cet aspect a du avoir un impact très très fort sur la volonté de prendre le moins de risques possibles côté DGIFip, bien plus que du lobbying de la part de gros éditeurs voulant siphonner les clients des petits éditeurs.

Ça manque de balls tout ça si vous me passez l'expression ...

[dg78]

@François Dorin

D’abord, deux remarques de vocabulaire :
- DSN = Déclaration Sociale Nominative, donc on ne dit pas : le DSN, du DSN mais la DSN, de la DSN.
- d’après le Larousse, biaisé, biaisée. Se dit de quelque chose qui est déformé, fallacieux. Non, mon avis n’est pas fortement biaisé, déformé, fallacieux. C’est simplement un avis sincère basé sur l’expérience, c’est mon avis, ma vérité, vous pouvez en avoir une autre.

Ensuite, je vous rejoins sur la première partie de votre réponse (intérêt de la DSN) et sur le dernier paragraphe (Ils sont complices non pas parce qu'ils ont organisé cela … mais par leur coopération avec ce nouveau système).
Je dis la même chose dans deux articles du blog :
- « Au départ, l’idée de la DSN est excellente : concentrer, regrouper et simplifier en partant des paies. »
-« il essaie de faire comprendre aux gros éditeurs et aux experts comptables tout l’intérêt qu’ils ont à porter la DSN, eux qui, jusqu’alors étaient assez réticents » (14 La vidéo qui explique bien des choses).

Avez-vous lu tous les articles du blog ?

La simplification voulue initialement n'était pas d'uniformiser les informations utilisées par chaque organisme, mais de ne faire qu'une seule déclaration.

Je l’ai écrit également : « Sachant qu’il n’y a pas eu d’harmonisation entre les organismes (est-ce possible et souhaitable ?), .. »

En programmation objet, les notions de responsabilité et de cas d’utilisation (Use Case) sont importantes. Il n’est pas de la responsabilité de la classe Entreprise que de s’occuper de codes internes à la classe Organisme, codes spécifiques à chaque objet Organisme, codes pouvant changer (ajout/modif/suppression) inopinément un beau matin. Elle n’a pas non plus à les subir. En plus des codes spécifiques à chaque objet Organisme, le séquencement des blocs dans le message varie suivant les objets organismes.

Comme la DSN est un sous-produit de la paie (dixit, à juste titre, le GIP-MDS), la responsabilité de la classe Entreprise est d’exposer ses données (entreprises, salariés, paies). Si ceci était fait en relation avec un plan de paie standard connu par les organismes (chaque organisme définissant ses rubriques de paie spécifiques), tout le monde serait gagnant (entreprises, organismes, éditeurs). Ceci de la même façon que le fichier FEC avec quelques adaptations.

Du coup, se ce sont les éditeurs, et indirectement les entreprises, qui paient pour la mise en place du de la DSN, pour un impact faible pour les organismes en question.

L’impact n’a pas été faible pour les organismes car nombre d’entre eux ont eu (et ont encore) beaucoup de difficultés. Certains ont commencé très tard avec la DSN et un nombre important de problèmes ont existé (entreprises prélevées deux fois, ou pas du tout ou prélevées pour d’autres ..).
Demandez au personnel des organismes ce qu’il en pense de la DSN

@Marco46

Tout à fait d’accord avec vos remarques.
Il faut juste noter qu’au niveau du prélèvement à la source, la DGIFip est au même niveau que les divers organismes. Elle subit, comme eux, la structure du niveau logique de la DSN.

[François DORIN]

- DSN = Déclaration Sociale Nominative, donc on ne dit pas : le DSN, du DSN mais la DSN, de la DSN.

C'est noté. Merci

- d’après le Larousse, biaisé, biaisée. Se dit de quelque chose qui est déformé, fallacieux. Non, mon avis n’est pas fortement biaisé, déformé, fallacieux. C’est simplement un avis sincère basé sur l’expérience, c’est mon avis, ma vérité, vous pouvez en avoir une autre.

Le Larousse dit aussi : Se dit d'une observation présentant une distorsion systématique, d'un raisonnement fondé sur une telle observation.

Avez-vous lu tous les articles du blog ?

Tous, non. Il y en a énormément (beau travail au passage )

[Grogro]

Oui mais les gros éditeurs (et les gros cabinets d’expertise comptable) sont complices de cette complexité (lire les différents articles du blog).
Ceux qui pâtissent de cette situation : les TPE, certains organismes, les petits éditeurs et au final les salariés.

Je ne désespère pas qu’un jour cette simplification arrive, contrainte et forcée. Le GIP-MDS commence à en prendre conscience. Pour tout dire, j’ai été invité à co-animer (un bien grand mot) un atelier intitulé ‘Plan de paie harmonisé’, fin juin au premier club qualité organisé par le GIP-MDS, atelier proposé suite à une de mes interventions en réunion (lire anecdote 3 sur le blog). J’en parlerais dans un prochain article sur mon blog.

Dans quelle mesure, justement, cette complexité métier n'est pas justement le reflet de l'incroyable complexité législative et réglementaire ?