Après les critiques, place maintenant aux propositions, pour cela aidons nous des deux points suivants abordés auparavant dans des articles spécifiques :
- le fichier FEC établi par la DGIFP
- le Protocole d’échanges de la MSA
Appelons le fichier proposé TSN (Transmission Sociale Nominative) comme ceci on le distinguera, dans la suite de l’article, du fichier DSN actuel (Déclaration Sociale Nominative).
Là maintenant, c’est une véritable transmission directe des données de la paie et non plus une déclaration.
Plusieurs règles concernant le fichier TSN proposé :
- il doit se faire, comme le fichier FEC, sur la base d’un fichier de type CSV (surtout plus de messages comme dans la DSN)
- comme le Protocole d’échanges de la MSA, il doit comporter plusieurs types d’enregistrements, ceci est indispensable car, à la différence du fichier FEC, qui ne concerne que les écritures comptables, le fichier TSN doit contenir les informations sur le déclarant, l’entreprise, les salariés, les contrats de travail, .. et bien sûr les paies.
A la différence du Protocole d’échanges de la MSA, je propose des catégories de données plutôt qu’un type d’enregistrement placé sur la donnée (ou enregistrement).
1) catégories des données
Chaque catégorie est matérialisée par un mot clé précédé par un (ou plusieurs) caractère(s) particulier(s) (par exemple #). Ceci permet de relire et d’analyser automatiquement le fichier TSN.
Pour plusieurs catégories, le fichier TSN s’inspire et utilise les données (blocs et rubriques) du fichier DSN actuel. Rien ne sert de réinventer la poudre.
En se basant sur les blocs de la DSN actuelle, on pourrait avoir les catégories suivantes, dans l’ordre :
#envoi
#émetteur
#contact émetteur
#déclaration
#entreprise
#établissement
#organismes
#organismes_contrats
#salariés
#salariés_contrats
#paies_détail
#paies_modif
#paies_cumul
#urssaf_ctps
#versements
En dessous de chacun de ces mots clés, se trouve une liste de type CSV.
Règles :
- quand le mot clé est au singulier, il n’y a qu’une seule donnée ou ligne dans la liste
- quand le mot clé est au pluriel, la liste peut contenir un nombre indéterminé de lignes (on retrouve implicitement les cardinalités du fichier DSN actuel mais sans utiliser l’usine à gaz des messages)
- possibilité de lignes vides non prises en compte (;;;;;) pour aérer et permettre une lecture visuelle plus facile car, contrairement au fichier DSN, le fichier TSN doit être lisible et compréhensible directement par le déclarant
- si la TSN doit contenir plusieurs entreprises ou plusieurs établissements, il suffit simplement, à la fin des catégories ci-dessus, de repartir avec une nouvelle catégorie #entreprise ou #établissement suivie par les catégories qui sont en dessous et ceci autant de fois qu’il y a d’entreprises ou établissements à mettre sur la même TSN
On remarquera :
- l’ordre des catégories : le détail avant les cumuls (ce qui est logique mais pas appliqué dans la DSN actuelle)
#paies_détail avant #paies_cumul lui même avant #urssaf_ctps lui même avant #versements
- une catégorie #paies_modif permettant d’indiquer d’éventuelles modifications (rattrapages, corrections) ne figurant pas sur les bulletins de paie. Ainsi ces modifications sont bien isolées des paies (ce qui n’est pas le cas avec la DSN actuelle dans laquelle les modifications hors paies sont noyées dans les données des paies). Bien évidemment #paies_détail comprend uniquement le détail de chaque paie du mois, simple copié-collé les lignes de paie sans aucun traitement ou modification.
- une catégorie #paies_cumul fournissant le détail cumulé de toutes les rubriques de paie utilisées pendant le mois. C’est la paie globale de tous les salariés de l’entreprise, paie détaillée par rubriques.
Ceci n’existe pas dans la DSN actuelle mais ce cumul est très utile. Ces cumuls servent à établir la catégorie #urssaf_ctps. Ils pourraient suffire à eux-mêmes si l’Urssaf faisait l’effort de calculer lui-même les CTP (à partir de #paies_cumul) ou mieux de les abandonner.
2) liste de type CSV dans chaque catégorie
Dans chaque catégorie, se trouve une liste de type CSV composée de lignes et de colonnes.
Dans le cas d’une catégorie au singulier (== il n’y a qu’une seule donnée ou ligne dans la liste), la donnée pourrait apparaitre en lignes plutôt qu’en colonnes sur une seule ligne. On obtient alors une présentation similaire à la DSN actuelle mais en présentation CSV.
Exemple :
#envoi
1 ;logiciel ;F.I. Personnel Paie
2 ;éditeur ;Flandre Informatique
3 ;version ;3.3
..
Règles :
- dans une ligne, chaque donnée est séparée par un caractère séparateur (par exemple ;). Chacune de ces données correspond à une colonne si lecture avec Excel.
- chaque donnée correspond à une rubrique existant dans les blocs correspondants aux catégories (blocs de la DSN actuelle) exceptés pour les catégories #paies. Mais il peut y avoir également d’autres données (relations entre catégories).
- la première ligne de la liste contient les identifiants de chaque donnée (nom des colonnes), ceci n’est pas utile mais facilite la lecture visuelle
Nous allons, dans le fichier TSN, user (et abuser) de relations directes entre les données de certaines catégories ce que le GIP-MDS a découvert uniquement à partir de la phase 3 quand il a commencé à utiliser ce qu’il a appelé ‘identifiants techniques’ Adhésion et Affiliation.
Ces relations sont monnaie courante en gestion de base de données où elles sont appelées ‘clés étrangères’, par exemple :
- les organismes auxquels est affiliée l’entreprise
- les contrats de travail d’un salarié
- la paie d’un salarié
Examinons en détail ce que pourraient contenir une catégorie classique (ex : #salariés) puis la catégorie #paies_detail.
2.1 – détail d’une catégorie classique (ex : #salariés)
Actuellement dans la DSN actuelle, le bloc Individu contient les rubriques suivantes :
Chaque rubrique est identifiée par :
- un code (appelé ‘identifiant officiel), par exemple : S21.G00.30.001
- un nom (appelé ‘identifiant sémantique), par exemple :
Individu.Identifiant pour S21.G00.30.001
Individu.NomFamille pour S21.G00.30.002
Individu.NomUsage pour S21.G00.30.003
Individu.Prenoms pour S21.G00.30.004
…
En utilisant la seconde partie du nom sémantique, la première ligne de la liste des salariés pourrait être :
Identifiant ;NomFamille ;NomUsage ;Prenoms ; ..
Remarques :
- Identifiant est en fait le numéro sécu (ou NIR = Numéro d’inscription au répertoire), il est plus judicieux de l’appeler NIR
- le matricule est une donnée importante dans l’entreprise (actuellement en S21.G00.30.019), il convient de placer cette donnée en début et non au rang 19 (il a surement été mis à ce niveau car il avait probablement été oublié et quand on s’est aperçu de son utilité, on était arrivé au numéro 19).
- pour établir une relation (ex paie d’un salarié), il faut identifier le salarié dans la paie. S’il faut l’identifier par le NIR, ce sera fastidieux et difficile à relire, il vaut mieux un identifiant simple qui pourrait être le matricule du salarié dans l’entreprise (facile dans 95% des entreprises lesquelles ont moins de 10 salariés) ou un numéro libre (ex : numéro d’ordre incrémenté de 1 à chaque salarié).
Utilisons IdSalarié (et pas Identifiant car il y aura aussi un identifiant dans la catégorie #contrats et nous aurons besoin des deux identifiants dans la catégorie #paies_detail).
En tenant compte de ces remarques, la première ligne de la liste des salariés devient :
IdSalarié ;Matricule ;NIR ;NomFamille ;NomUsage ;Prenoms ; ..
Les lignes suivantes de la liste des salariés donnent les renseignements de chaque salarié :
7 ;7 ;170065927027717 ;DUPOND ;;Patrick ..
8 ;8 ;280036217728716 ;MARTIN ;;Vinciane ..
J’ai gardé dans l’exemple la colonne Matricule qui est ici la même que Identifiant.
Cas des modifications :
Dans le cas d’une modification dans le mois de certaines données du salarié, la DSN actuelle demande les anciennes valeurs en plus des nouvelles. (voir §2 dans l’article 23 les inepties de la DSN).
Ceci est à mettre pour les salariés et pour les contrats de travail.
Ce cas est résolu très simplement avec la TSN :
Il suffit d’ajouter sous la ligne du salarié (ligne qui contient les nouvelles valeurs) une ligne qui contient uniquement les anciennes valeurs placées dans la bonne colonne (exit l’incohérence des numéros de rubriques dans les blocs et bonjour la lecture directe des modifications dans le fichier TSN lu en Excel).
Afin de dissocier les deux lignes pour le même salarié, il convient d’ajouter deux nouvelles colonnes, la première que j’appelle CodeLigne et la seconde pour la date de la modification (DateModif).
Le code CodeLigne permet également d’indiquer un nouveau contrat, une fin de contrat, un arrêt maladie, une reprise après arrêt. On solutionne ainsi en plus le cas des signalements (DSN événementielles).
Exemple de CodeLigne :
- rien : le salarié était déjà présent le mois précédent, aucune modification
- Anc : anciennes valeurs (si modification)
- N ou Ent (Entrée) ou Nouv (Nouveau) : nouveau salarié
- F ou Fin : départ du salarié
- Arret : arrêt du salarié (maladie, accident ..)
On obtient alors :
IdSalarié ;Matricule ;CodeLigne ;DateModif ;NIR ;NomFamille ;NomUsage ;Prenoms ; ..
7 ;7 ; ; ;170065927027717 ;DUPOND ; ;Patrick ;..
7 ;7 ;Anc ;20180518 ;170065927027700 ; ; ; ;..
8 ;8 ; ; ;280036217728716 ;MARTIN ;;Vinciane ;..
Ce qui donne en lisant ceci en Excel :
Dans cet exemple, le 18/05/2018, il y a eu modification du NIR pour le salarié numéro 7 DUPOND et aucune modification pour la salariée 8 MARTIN Vinciane.
On voit tout de suite que seul le NIR a changé.
2.2 – détail d’une catégorie paie (ex : #paies_detail)
La TSN est une transmission directe des données de la paie.
Il faut donc reprendre le détail complet des paies.
Utilisons l’exemple mentionné dans l’article ‘41 détail d’une paie’.
Toutes les lignes de la paie seront donc mentionnées dans la liste CSV dans la catégorie #paies_detail.
Il faut également que chaque ligne soit en relation avec le salarié et le contrat de travail, on ajoute donc les colonnes IdSalarie et IdContrat.
On obtient alors :
#paies_detail
IdSalarie ;IdContrat ;Code ;Base ;TauxSal ;MontantSal ;TauxPat ;MontantPat
7 ;11 ;1 ;151.70 ;12 ;1820.40 ; ;
7 ;11 ;21 ;27 ;15 ;405 ; ;
7 ;11 ;900 ; ; ; 2245.40 ; ;
7 ;11 ;1010 ;2225.40 ; ; ; 13 ; -289.30
…
7 ;11 ;8520 ;19 ;8.50 ;161.50 ; ;
; ; ; ; ; ; ;
Remarques :
- ici le salarié possède l’identifiant 7 et son contrat de travail possède l’identifiant 11
- le nom de la rubrique de paie n’est pas transmis
- la colonne MontantSal (montants salariaux) correspond aux deux colonnes de la paie Gain (en plus) et Retenue (en moins)
- la colonne MontantPat (montants patronaux) correspond à la dernière colonne Montant sur la paie (c’est une colonne Retenue donc ici elle apparait en moins)
- la dernière ligne ; ; ; ; ; ; ; caractérise une ligne vide pour séparer deux paies, ce qui facilite la lecture
Gros problème :
Arrivés ici, certains lecteurs diront « il y a un gros problème » (et certains d’entre eux seront très contents). Je l’avais déjà signalé dans l’article ‘41 détail d’une paie’
Rappel :
« Il est à noter qu’il n’existe pas de plan de paie (liste des rubriques de paie) standardisé au niveau national comme peut l’être le Plan Comptable Général utilisé en comptabilité.
Chaque logiciel possède son propre plan de paie mais tous doivent fournir les mêmes données.
Dans un logiciel, le total du brut aura le numéro 900 (comme dans l’exemple), dans un autre ce sera 500 ou T500. »
Et oui !! rien ne sert d’envoyer le code rubrique de paie 1010 (qui veut dire ici dans la paie : Maladie, maternité, invalidité, décès), aucun organisme ne le connait ce qui est normal car il est propre à mon logiciel de paie.
Que faire ?
La solution simple est de créer un plan de paie standard normalisé en relation avec les éditeurs de logiciels (il suffit de faire une synthèse des plans de paie existants) et surtout en fonction des besoins des organismes.
Faut-il imposer ce plan de paie standard normalisé à tous les éditeurs de logiciels (comme c’est le cas avec le Plan Comptable Général en comptabilité) ?
Impossible, ceci prendrait au moins 10 ans avec en prime le risque de problèmes dans les paies.
Il suffit tout simplement que chaque éditeur crée une relation entre son propre plan de paie qu’il gardera et le plan de paie standard normalisé (ne vous avais-je pas dit que nous allions user et abuser de relations ?).
Un plan de paie standard peut facilement et rapidement être créé car toutes les rubriques de paie nécessaires sont connues par tous les organismes.
Par exemple, la rubrique de paie ‘Maladie, maternité, invalidité, décès’ est obligatoire. Elle est connue par le régime général (URSSAF) et par le régime agricole (MSA).
Dans le plan de paie standard, cette rubrique aura peut-être le code 1100.
Il suffira donc simplement que j’indique dans mon logiciel de paie que ma rubrique 1010 est reliée à la rubrique de paie 1100 du plan de paie standard.
Aucune difficulté car les éditeurs de logiciels de paie ont l’habitude d’effectuer des relations dans leur plan de paie, la dernière en date étant celles qu’ils ont dû ajouter pour l’édition de la paie dite clarifiée (pour regrouper certaines rubriques).
Ceci ne changera en rien les paies actuelles. Dans mon logiciel de paie, la rubrique de paie ‘Maladie, maternité, invalidité, décès’ aura toujours le numéro 1010 mais dans la catégorie #paies_detail, j’enverrais en plus le code de la rubrique de paie standard.
Pour cela il suffit d’ajouter une nouvelle colonne « CodeStandard » (en gardant la colonne Code pour lecture et vérification du TSN).
L’exemple précédent devient alors :
#paies_detail
IdSalarie ;IdContrat ;Code ;Base ;TauxSal ;MontantSal ;TauxPat ;MontantPat ;CodeStandard
7 ;11 ;1 ;151.70 ;12 ;1820.40 ; ; ;10
7 ;11 ;21 ;27 ;15 ;405 ; ; ;41
7 ;11 ;900 ; ; ; 2245.40 ; ; ;T500
7 ;11 ;1010 ;2225.40 ; ; ; 13 ; -289.30 ;1100
7 ;11 ;1020 ;2225.40 ; 6.9 ;-153.55 ;8.55 ; -190.27 ;1200
…
7 ;11 ;8520 ;19 ;8.50 ;161.50 ; ; ;9010
; ; ; ; ; ; ;
Dans l’exemple, j’ai associé :
le code standard 1100 à mon code 1010
le code 10 à mon code 1 Salaire de base
le code T500 à mon code 900 Total Brut.
Cette association (ou relation) entre le plan de paie spécifique de l’éditeur et un plan de paie standard connu de tous (donc accessible aux organismes) est possible pour toutes les rubriques de paie. Il est même possible que plusieurs rubriques spécifiques soient en relation avec une seule rubrique standard. Il est aussi possible d’imposer que telle rubrique du plan de paie standard ait une base en heure, en jour ou en euros. Tout est possible, il suffit de le vouloir.
Certains, à ce niveau objecteront que je n’ai pas tenu compte des affectations des salariés dans les organismes complémentaires.
Ils auront raison, c’est un point délicat qui se résout facilement en gérant les catégories #organismes, #organismes_contrats et #salaries_contrats puis en ajoutant des colonnes relations supplémentaires dans l’envoi des paies.
La catégorie #organismes contient les renseignements de tous les organismes dont dépend l’entreprise (Urssaf, MSA, caisses retraites, organismes complémentaires, centre impôts ..)
La catégorie #organismes_contrats contient les renseignements des fiches de paramétrage obtenus auprès des organismes complémentaires.
La catégorie #salaries_contrats indique les affiliations de chaque salarié dans les organismes.
Par exemple, dans une paie, les rubriques concernant les organismes complémentaires sont :
Reprenons notre exemple précédent dans la TSN :
#paies_detail
IdSalarie ;IdContrat ;Code ;Base ;TauxSal ;MontantSal ;TauxPat ;MontantPat ;CodeStandard
7 ;11 ;1 ;151.70 ;12 ;1820.40 ; ; ;10
…
Ajoutons les rubriques ci-dessus :
7 ;11 ;2610 ;2218.60 ;0.28 ; -6.21 ;0.42 ;-9.32 ;3010
7 ;11 ;2612 ;2218.60 ;0.14 ; -3.11 ;0.21 ;-4.66 ;3020
7 ;11 ;2614 ;2218.60 ;1.12 ; -24.85 ;0.68 ;-37.27 ;3020
7 ;11 ;2617 ;1 ; ; -78.35 ; ;-16.90 ;3030
Dans le plan de paie standard, on a par exemple :
- 3010 = Prévoyance
- 3020 = Complémentaire spécial transport
- 3030 = Mutuelle
Il convient d’ajouter dans chaque ligne ci-dessus, l’identifiant de l’organisme et l’identifiant de la ligne de contrat (tout ceci est connu à partir des fiches de paramétrage).
Donc si ceci est simple, possible, facile, pourquoi ceci pourrait ne pas se réaliser ?
Tout simplement parce que ce n’est pas l’intérêt des gros éditeurs qui ont peaufiné, bichonné leurs plans de paie (j’en sais quelque chose ayant dû refaire le mien à l’arrivée de la DSN).
Donc uniformiser à cause d’une TSN n’est pas vraiment leur intérêt.
Car, à terme, des éditeurs pourraient calquer leur plan de paie spécifique sur le plan de paie standard. En fait, ils ne risqueront rien car la paie sera toujours compliquée en elle-même.
Quelle solution :
Il suffit simplement que le GIP-MDS, la SDDS, la AMOA et les organismes se réunissent et définissent ce plan de paie standard en se basant sur les besoins des organismes et sur les plans de paie utilisés par les adhérents du SDDS. Il faut simplement de le vouloir ou alors il faut changer de nom et ne plus dire que l’on veut simplifier les données sociales.
3) les nombreux avantages de la TSN par rapport à la DSN
La TSN (Transmission Sociale Nominative) corrige tous les problèmes de la DSN (Déclaration Sociale Nominative) :
- simplicité d’envoi des données par les entreprises
- simplicité de lecture des données par les organismes
Soyons honnêtes, si les éditeurs se prennent la tête pour créer un fichier DSN actuel, les organismes doivent se la prendre tout autant pour relire le fichier DSN afin d’en exploiter les données.
Le fichier TSN est facile à créer (car le logiciel de paie connait déjà le détail des paies, il l’a même mémorisé, ce qui est indispensable pour l’édition d’un éventuel duplicata d’une paie).
Facile à créer et tout aussi facile à relire car, à partir du plan de paie standard (défini ci-dessus), l’organisme retrouve rapidement les lignes de paie qui l’intéressent.
- lecture visuelle facile et compréhensible du fichier TSN
- séparation des modifications hors paie par rapport aux informations provenant des paies
- la TSN n’est en aucun cas impactée par des modifications ou évolutions demandées par les organismes ou par le législateur.
- La TSN n’est pas tributaire d’une montée en charge. L’entrée des trois fonctions publiques n’impacte en rien la TSN des entreprises privées.
- la TSN pour les trois fonctions publiques se trouve par là même énormément simplifiée (peut-être, voudront-ils entrer en TSN dès le 1er Janvier 2020 ? ;-)) )
- avec le temps, certains éditeurs calqueront leur propre plan de paie sur le plan de paie normalisé
- tout ceci entraine bien évidemment des économies substantielles à tous les niveaux : entreprises, organismes, GIP-MDS avec son AMOA, éditeurs de logiciels et experts-comptables
- et en prime, deux grosses cerises sur le gâteau
La première : le contrôle des paies en temps réel.
En effet, avec la TSN, les organismes reçoivent le détail complet des paies (informations qu’ils n’ont pas avec la DSN actuelle). Ils connaissent par ailleurs (étant donné que ce sont eux qui les établissent) les différents taux ou bases à appliquer dans chaque rubrique qui les concernent dans le plan de paie normalisé.
Chaque organisme peut donc, en temps réel (c'est-à-dire dès l’envoi) indiquer à l’entreprise s’il y a une erreur d’assiette, de taux, de montants. Ceci est impossible à réaliser avec la DSN car les taux ne sont pas transmis de même qu’il n’y a pas le détail des montants salariaux et patronaux (il n’y a que le total de ces deux montants et pas toujours notamment avec les CTP et les montants RETA et RETB pour Arrco-Agirc).
Contrôler la DSN actuelle, c’est bien mais comme la valorisation de la DSN provient des paies, contrôler les paies, c’est encore mieux.
Certes, on me rétorquera que contrôler les paies n'est pas dans le périmètre du GIP-MDS. A ceci je répondrais que les données sociales commencent avec la paie donc rien ne sert de vouloir moderniser les données sociales (= MDS) si la donnée de départ (c'est-à-dire la paie) est erronée. Une paie erronée peut conduire à spolier le salarié ce qui est contraire à l'objectif du GIP-MDS (cf article 14 la vidéo qui explique bien des choses).
En conséquence, avec une véritable transmission directe des données de la paie (TSN), il y a, en prime, un contrôle automatique des paies. Ceci ne pénalise en rien la majorité des entreprises qui ne cherchent pas à frauder et ne veulent pas d’embêtements mais l’erreur est humaine.
Faut-il rappeler, qu’il y a quelques années, il était de notoriété publique qu’environ 40 % des paies étaient erronées ? et maintenant, quel est ce pourcentage ?
La TSN introduit donc une forme d’intelligence artificielle.
La seconde cerise sur le gâteau : mise à jour automatique des taux et assiettes
Tous les ans (ou ponctuellement), les organismes effectuent des modifications de taux, d’assiettes dans des rubriques existantes ou créent de nouvelles rubriques ou en suppriment.
A partir du moment où un plan de paie normalisé circule entre les entreprises et les organismes, il n’est pas farfelu de penser que les organismes pourraient indiquer toutes leurs modifications, via ce plan de paie. Charges ensuite aux éditeurs de logiciels de récupérer ces modifications pour les inclure dans leur propre plan de paie. Une ébauche de ceci est en cours avec DSN-FPOC fourni par les organismes complémentaires pour la mise à jour des fiches de paramétrage dans la DSN actuelle. Il manque par contre la prise en compte des parts salariale et patronale ainsi que des taux à réintégrer ou non dans la CSG et le Net Imposable pour permettre une mise à jour automatique dans la paie.
Avec la TSN, la paie pourrait elle aussi être simplifiée. N'est-ce pas aussi le but d'une modernisation des données sociales ?
4) et maintenant que faut-il faire ?
Tout simplement, créer d’abord un plan de paie normalisé qui servira pour la TSN.
Pour cela, il faut associer tous les organismes (qui indiqueront toutes les rubriques de paie qu’elles ont besoin) ainsi que les tous les éditeurs de logiciels de paie (TOUS et pas seulement les gros éditeurs) sans oublier les services informatiques des grosses entreprises qui gèrent eux-mêmes leurs paies.
Ensuite poursuivre en détail mon analyse sur la TSN afin d’établir un cahier technique détaillé.
Tout ceci représente un travail intéressant de normalisation, oh combien plus simple à réaliser que la DSN actuelle. Les utilisateurs (entreprises et organismes) seront alors satisfaits de la simplicité et de la stabilité de la TSN.
5) en conclusion
La solution proposée fournit les grandes lignes de ce qui pourrait devenir une véritable transmission directe des données de la paie et des données sociales, transmission dans laquelle chaque utilisateur (déclarants et organismes) y trouvent leurs comptes. Ce sont les seuls intérêts à prendre en compte.
Cette solution est bien évidemment une ébauche qui nécessite une analyse détaillée.
Comme toujours en informatique, il y aura des situations particulières qui sortiront des cases prévues. Et comme toujours, il faudra faire preuve d’imagination et faire fonctionner les méninges.
Toujours avec l’optique du bon sens, de la simplicité et de la facilité d’utilisation.
Rien ne sert de faire compliqué quand on peut faire simple. Le tout est de le vouloir (mais ça, ce n’est pas gagné).
Une objection qui va être faite :
la DSN fonctionne depuis au plus quatre ans en mode déclaration, vous ne pensez quand même pas que l'on va passer maintenant en mode de transmission directe ?
A ceci, je réponds : et combien d'années la DSN va fonctionner, quel sera son coût annuel si elle reste dans sa forme actuelle ?
Mieux vaut réfléchir le plus tôt possible à une véritable transmission directe des paies comme préconisé en 2001 (voir article 11 qu'est ce que la DSN).