Je suis un grand fan de la dématérialisation. J’ai commencé à faire de la vieille technologique depuis mes 15 ans sur le sujet. Je suis persuadé que c’est un élément indispensable pour la modernisation et l’efficacité des fonctions publiques… quand elle est menée correctement.

Le constat

Depuis plusieurs années, les entreprises françaises passant un certain seuil de CA ou d’imposition doivent déclarer et/ou payer tout ou partie de leurs impôts et autres charges sociales de manière dématérialisée. Ce seuil est abaissé chaque année afin de faire entrer progressivement les entreprises plus modestes dans le dispositif. Toutes les entreprises devront déclarer et payer tous leurs impots de manière dématérialisée à partir d’avril 2015. C’est selon moi une très bonne initiative. Là où le bas blesse c’est que ce passage du papier à l’immatériel a un coût qui me parait en partie injustifié.

Globalement trois solutions s’offrent à une entreprise:

• passer par un tiers déclarant, typiquement un expert comptable
• utiliser un logiciel générant un fichier homologué par l’association EDIFICAS puis choisir une entreprise homologuée par la DGFIP (un tiers de télétransmission ou partenaire EDI) pour transmettre le fichier à la DGFIP
• utiliser directement la plateforme web d’un partenaire EDI qui s’occupera alors à lui seul de générer et transmettre le fichier

Si elle souhaite gérer elle-même ses déclarations d’impôts, une entreprise doit débourser beaucoup d’argent. Après avoir étudié quelques exemples, cela coûte entre entre 110 € et 900€ selon le chiffre d’affaire de la société et la solution choisie. Cela ne comprend que la création et la transmission de la liasse fiscale, ce à quoi il faut ajouter la CVAE, la TVA, EDI-REQUETE et les télépaiements.

Afin de ne pas alourdir le corps de l’article, je repousse le détail de ces exemples en fin d’article.

Les problèmes

Un impôt logiciel

Le premier problème est donc l’impôt logiciel générer par l’obligation de la télédéclaration. Si cela peut paraître dérisoire pour un groupe du CAC-40 c’est moins anecdotique pour une petite structure. Celles-ci ont souvent recourt à un expert-comptable (tiers déclarant) certes, mais ça ne justifie pas cet impôt supplémentaire… surtout quand l’administration met en avant la simplification et les gains pécuniers engendrés par la dématérialisation pour les entreprises.

Des partenaires EDI à l’utilité limitée

À quoi servent les partenaires EDI ? Pas grand chose…

Leur rôle à l’origine était de router les flux vers leurs destinataires (DGFIP, Banque de France, OGA) et de vérifier les messages avant qu’ils ne soient transmis à la DGFIP « afin d’éviter d’allonger inutilement les délais de traitement des dépôts selon la procédure EDI-TDFC » (page 196 du volume IV de la norme TDFC 2012).

Je pense qu’en 2013, la DGFIP pourrait aisément assurer ces deux rôles en permettant aux entreprises de déposer leurs déclarations sur leur compte DGFIP, exactement comme elles (ou leurs tiers déclarants) le font déjà pour leurs déclarations sociales sur le portail public et gratuit NetEntreprise. La toute nouvelle déclaration sociale nominative qui sera obligatoire en 2016 reprend exactement ce fonctionnement. Les logiciels tiers pourront même y déposer les fichiers via un process M2M utilisant des protocoles standards et ouverts.

Cette fragmentation des partenaires EDI engendre des difficultés pour les cabinets d’expertise comptable ou les OGA : si l’on veut transmettre sa liasse à un autre partenaire, il semblerait que celui-ci doit adhérer au même portail(au même partenaire EDI).

Une démarche d’homologation lourde

Actuellement étudiant en école d’ingénieur, je suis passionné par le logiciel libre depuis bien longtemps. Je suis également attiré par la gestion d’entreprise et leurs systèmes d’information. J’envisage de travailler pour une société de services en logiciels libres proposant des services autours d’Odoo (anciennement OpenERP) ; un logiciel de gestion libre.

J’ai donc commencé à développer(bidouiller serait plus juste) un outil permettant aux petites entreprises de générer leur liasse fiscale (TDFC) au format EDIFICAS qui serait facilement intégrable dans d’autres logiciels libres de gestion.

Quelle fut ma surprise à la lecture des documents de l’EDIFICAS :

• il n’y a pas moins de 7 normes EDIFICAS, 12 scénarios d’homologation rien que pour la norme TDFC et de nombreuses sous catégories qui en font une norme illisible
• pour faire homologuer un logiciel permettant de générer un fichier vers le portail d’un partenaire EDI cela coûte au moins entre 500 et 1000 euros (plus si l’on demande un agrément pour plusieurs scénarios) plus des frais annuels supplémentaires.

Cette procédure est donc un frein à l’entrée de nouveaux acteurs et une source de technocratie inutile.

Une norme d’un autre âge

La norme attendue par la DGFIP est fondé sur le standard international UN/CEFACT EDIFACT. C’est un format de fichiers plat complexe à manipuler datant des années 1980. La plupart des champs sont fixés par défaut ou inutilisés et les types de données sont inadaptés.

La sécurisation utilise un système de signature électronique qui oblige toute entreprise voulant elle même transférer ses liasses (et donc elle-même devenir partenaire EDI) à se rendre physiquement auprès de la DGFIP et de suivre une seconde procédure d’homologation auprès de la DGFIP.

Le dictionnaire des « champs » de la DGFIP (ne contenant pas ceux des OGA) est un classeur Excel. Il comporte même des code non-homogènes avec de ceux de l’outil de test ! Il n’y a pas de description des formulaires autre d’un fichier PDF.

La transmission des fichiers se fait via des réseaux privés coûteux et peu courants CFTAxway ou ALTLAS400-TEDECO (norme X400)

Qu’il soit obligé de transmettre de manière dématérialisée ou non, le contribuable doit encore transmettre un formulaire papier à l’administration pour s’inscrire à la dites télé-procédure.

C’est donc une norme lourde à manipuler et à mettre à jour.

Les pistes de solutions proposées

Attention à ne pas jeter le bébé avec l’eau du bain ! Toute cette infrastructure était probablement adaptée aux début de la création de la procédure TDFC ; à l’époque où les entreprises communiquaient leurs données par bande magnétique ou des réseaux « télématiques » tels que les lignes X25 et Numeris (encore mentionnés dans la norme). À l’heure où l’administration fiscale impose à ses contribuables de se moderniser ; il est urgent qu’elle donne l’exemple et se modernise elle-même avant tout. Dix ans après le début du programme Copernic, il ne faudrait pas baisser le rythme. Quelques propositions :

• supprimer le formulaire d’adhésion à la télédéclaration
• permettre aux entreprises de transférer leur fichier TDFC directement depuis leur compte fiscal sur le portail de la DGFIP
  • le mot de passe est sensé assurer l’authentification et la non répudiation
  • le protocole HTTPS standard assure la confidentialité de bout en bout
  • les entreprises économisent le coût du partenaire EDI
  • les tiers déclarants (cabinets d’expertise comptable par exemple) peuvent déclarer pour le compte de leurs client
  • l’administration fiscale effectue tous les contrôles et affiche les compte-rendus en HTML sur le portail (voire aussi par mail en cas de contrôles asynchrones)
  • => exactement comme le fait NetEntreprise depuis plusieurs années

• supprimer la procédure d’homologation
  • l’administration fiscale fournit un outil de pré-validation aux éditeurs de logiciels
  • la DGFIP s’assure au fil de l’eau que les fichiers importés sont conformes
  • => de la même manière à la DADS-U(norme N4DS) et la future DSN(norme NEODeS)

• refondre toutes les normes de déclarations fiscales
  • avoir une seule norme et un seul scénario
  • utiliser un environnement XML : un schema XML clair est bien plus pratique(tant pour l’administration que pour les éditeurs et les entreprises) qu’une norme en 8 volumes de 200 pages chacun : cela facilite la création de l’outil de pré-contrôle et la mise à jour de la norme et des logiciels
  • fournir le schema xsd permettant de vérifier automatiquement la structure du fichier XML et un fichier de transformations XSLT permettant ensuite d’effectuer des contrôles métiers (ex : contrôle de la clé d’un SIRET) et de générer un rapport XML listant les erreurs
  • fournir les templates propres des formulaires DGFIP en HTML avec une balise permettant de repérer les groupes de données répétables (au niveau des tableaux notamment)
  • s’appuyer sur le model de la norme NEODeS (norme de la DSN) pour la structuration des niveaux de contrôle et des blocs d’en-être/en-queue

• permettre le dépôt de fichiers directement directement depuis les logiciels métiers
  • utiliser un protocole standard, sécurisé et largement utilisé sur internet pour le transport des fichiers
  • transmission en HTTPS(WebService REST bien adapté à la nouvelle norme de la DGFIP EDI-Requete) ou au pire en FTPS
  • sécurisation en réutilisant le couple login/mot de passe ou au mieux en demandant à l’entreprise d’importer une paire de clé RSA (certificat autosigné) depuis son compte fiscal vers le logiciel tiers ou inversement

• proposer aux entreprises un mode EFI pour toutes leurs procédures fiscales
  • il est anormal que le passage du papier au numérique induise de la complexité et un coût supplémentaire (installation d’un logiciel)
  • générer une interface HTML permettant aux contribuables de remplir les formulaires dont ils ont besoin. Générer ensuite le XML qui sera transmis au back-end (de manière transparente pour le contribuable) comme n’importe quel fichier issu d’un logiciel tiers de fiscalité
  • cette interface HTML propose deux modes : un mode liste où l’on liste paires (libellés des champs, valeurs) et un mode formulaire où l’on utilise les templates des formulaires (comme si le contribuable remplissait un formulaire papier actuel)
  • bien évidement, cette interface ne proposerait aucune fonction de pré-calcul comptable. Ce type de fonctions reste la prérogative des logiciels tiers

 

 

 

Continuer la lecture de « Oui à la dématérialisation, non à l’impôt logiciel ! »