Je suis développeur de logiciels depuis toujours, en fait depuis quarante ans. C'est-à-dire que je conçois et crée des logiciels destinés à des utilisateurs pour leur faciliter la vie.
Au début, logiciels en informatique industrielle (bancs d’essais, de test), puis graphique (gammes et rapports de contrôles) et scientifique (simulation, recherche opérationnelle) et ensuite en informatique de gestion.
Développeur de logiciels fournis à des utilisateurs, donc de facto, je suis également éditeur de logiciels.
Concevoir des logiciels, c’est faire l’analyse des besoins des utilisateurs en tenant compte de contraintes : contexte, législation, technologie …
Créer des logiciels, c’est mettre les mains (et le cerveau) dans le code pour transcrire l’analyse en commandes assimilables par le matériel (ordinateur, imprimante et autres périphériques).
Pour moi, l’analyse et le code sont indissociables avec sans cesse des retours de l’un vers l’autre tout comme les allers retours entre le développeur et l’utilisateur afin que le logiciel réponde vraiment aux besoins de l’utilisateur. C’est ce que l’on appelle maintenant l’agilité. Je fais de l’informatique agile depuis longtemps sans le savoir !!
Bien évidemment, en quarante ans, les techniques ont évolué. Je suis de base ingénieur en automatique et informatique. Je me suis sans cesse adapté, formé, auto formé. Je n’ai jamais quitté la technique : MS-DOS, Windows, Web, base de données, programmation objets, applis mobiles, …
Faire de l’informatique de gestion, sans connaitre la gestion, est monnaie courante. C’est, pour moi, inconcevable. C’est pourquoi, j’ai suivi, il y a bien longtemps, un troisième cycle de gestion à l’IAE Paris (à l’époque, cela s’appelait comme cela, maintenant c’est un MBA). Je suis donc titulaire d'un MBA "à l'insu de mon plein gré".
Comme logiciels de gestion, j’ai (entre autres) à mon actif :
- un logiciel de gestion commerciale : suivi de travaux, facturation, encaissements, relances, …
- un logiciel de comptabilité générale et tiers
- un logiciel de planification des travaux et suivi du détail des heures
- un logiciel de gestion du personnel et paie
Ces quatre logiciels sont liés, par exemple, les factures et les paies partent automatiquement dans la comptabilité. Le détail des heures part dans la paie et dans la facturation..
J’affectionne les logiciels simples à utiliser, ergonomiques avec le maximum d’automatismes.
Ces logiciels sont surtout utilisés dans un secteur particulier en agriculture, à savoir la gestion des entreprises de travaux agricoles. Ce sont elles qui, dans nos campagnes, possèdent les grosses machines qui font certains travaux en prestation de services pour les agriculteurs.
Depuis plusieurs années, le logiciel de comptabilité permet d’exporter les données vers les impôts sous la forme d’un fichier appelé FEC : Fichier des Ecritures Comptables.
Depuis 2017, il y a obligation, pour tout logiciel de paie, d’exporter les données vers Net Entreprise (régime général) ou la MSA (régime agricole), lesquels renvoient les données qui les concernent vers tous les organismes sociaux.
Ceci s’appelle DSN : Déclaration Sociale Nominative.
Etant éditeur d’un logiciel de paie, j’ai donc obligation de gérer le fichier DSN (transmis directement ou via une API ou WebService) en respectant le dossier technique émis par le GIP-MDS : http://www.dsn-info.fr/documentation/dsn_cahier_technique_p3_2018.1.pdf (246 pages).
Pas de DSN = abandon du logiciel de paie, donc passage obligé par la case DSN.
En programmant la DSN, et surtout en pestant contre son cahier technique, je me suis posé la question : comment aurais-je fait l’analyse de la DSN si j’avais eu à la faire en me servant de l’expérience acquise avec mon logiciel de paie et d’autres analyses que j’avais pu faire ?
Je me suis alors pris au jeu.
Avant de réfléchir à une analyse, j’ai voulu comprendre les tenants et aboutissants de la DSN actuelle. En un mot, j’ai essayé de comprendre pourquoi l’analyse de la DSN avait été faite de cette façon. Après quelques recherches et regroupements sur internet, mon idée sur la DSN actuelle était faite. J’ai ensuite réfléchi à une solution permettant d’atteindre l’objectif de la DSN (simplifier au maximum) tout en évitant les problèmes de la DSN actuelle.
Le voici donc l’objet de ce blog : détailler la DSN, donner mon état d’âme sur la DSN, dire que la DSN part d’un très bon sentiment, dire qu’elle pourrait être très utile mais qu’elle a été conçue comme une usine à gaz qui tôt ou tard explosera.
Dire également à qui profite cette situation, pourquoi et comment a-t-elle été réalisée de façon si complexe, difficilement maintenable, si difficilement évolutive et non adaptée à des rattrapages, corrections ou modifications dans les paies. De plus, il n’y a aucune visibilité pour les entreprises déclarantes. Sans oublier la difficulté manifeste de relecture des données par les différents organismes.
Pendant que l’administration fiscale fait le fichier FEC de façon simple et efficace, le GIP-MDS et le SDDS construisent le fichier DSN d’une façon jamais égalée en complexité avec des risques énormes.
A ce niveau, certains lecteurs (salariés) vont décrocher en se disant : « les déclarations, c’est le problème de l’employeur, pas le mien ». Détrompez-vous, c’est aussi le vôtre, car c’est vous qui payez une partie des cotisations et l’employeur paie pour vous les cotisations dites cotisations patronales. Il est bien de savoir où et comment elles arrivent et avec quel contrôle.
Etablir une fiche de paie est déjà une chose compliquée et la DSN ajoute encore de la complexité.
Je m’efforcerais d’être, dans ce blog, le moins technique possible.
J’ai bien évidemment conscience d’être un tout petit pot de terre (ou plutôt un minuscule grain de sable) face à de très gros pots de fer. Il me serait bien plus facile de ne rien dire et de faire la politique de l’autruche mais ceci n’est pas dans mon tempérament. J’ai toujours été un électron libre et je resterais un électron libre.
Je suis étonné, voire stupéfait, du peu de réaction face à la DSN actuelle. Tout le monde ronchonne : les déclarants, le personnel des cabinets comptables et de nombreux organismes destinataires de la DSN ainsi que certains éditeurs. On me dit que cela ira mieux demain quand des modifications seront faites et que tout sera bien rodé et pourtant cela fait quatre ans que la DSN a démarré.
J’ai attendu, pensant que certains allaient réagir. Il n’en est rien donc je réagis.
Pendant que le GIP-MDS, avec des budgets de communication très importants, dit que tout va bien, un directeur de la CNAV (Caisse Nationale Assurance Vieillesse) indique, en réunion plénière des éditeurs (en avril 2018), que, pour 2017, il y a eu d’énormes écarts entre la DADSU (Déclaration Annuelle des Salaires) et la DSN. Qu’il se rassure, la DSN sera maintenant toujours bonne car la DADSU est supprimée à partir de janvier 2018. Il n’y aura donc plus de moyen de comparaison.
Dire que quelque chose ne va pas est très facile, trop facile.
Mon objectif, en réalisant ce blog, n’est pas de critiquer pour critiquer mais d’indiquer, à mon modeste niveau (celui d’un développeur de logiciels) une solution (ou des pistes) qu’il conviendrait d’adopter pour faire passer la DSN de son état de bombe à retardement à un état de réussite.
Je pense qu’à un moment donné, il faut avoir le courage de dire « il est temps d’arrêter les conneries ».
Bien évidemment, je ne détiens pas la science infuse aussi vos remarques et critiques seront les bienvenues sur ce blog qui sera modéré a priori.
Je ne refuse pas non plus les encouragements ;-))