Au cours des prochaines années, presque toutes les entreprises bulgares vont passer par la même épreuve : le SAF-T. Ce fichier comptable standardisé destiné à l’Agence nationale des recettes publiques bulgare (NAP) est introduit par vagues de 2026 à 2030, en vertu du § 17 des dispositions transitoires et finales de la loi bulgare sur le budget de l’État pour 2025 : d’abord les grandes entreprises au-dessus des seuils, puis, d’ici 2030, toutes les autres, y compris les micro-entreprises enregistrées à la TVA. Le rythme est mensuel : le fichier doit être déposé avant la fin du mois suivant le mois de référence, et en cas de rejet il n’y a que 7 jours pour le corriger. Autrement dit, les erreurs coûtent cher et le temps de réaction est court.
C’est dans ce contexte que notre équipe a créé SAFTCheck, un outil gratuit de vérification des fichiers SAF-T doté d’une particularité architecturale inhabituelle : le fichier ne quitte jamais le navigateur de l’utilisateur. Dans cet article, nous racontons franchement (le projet est le nôtre) quelles décisions nous avons prises, pourquoi, et ce que nous avons appris en chemin. Non pas pour nous jeter des fleurs, mais parce que les mêmes principes s’appliquent à tout produit qui traite des données sensibles.
Si vous envisagez un outil similaire pour votre entreprise, voici l’étude de cas que nous aurions aimé lire avant de commencer.
Le défi : gagner la confiance quand on demande des données comptables
Un fichier SAF-T n’est pas un simple XML. Il contient toute la comptabilité de l’entreprise pour le mois : mouvements des comptes, soldes, tiers, pièces. Ce sont des données que les comptables, par habitude (et à juste titre), gardent comme la prunelle de leurs yeux. Le modèle SaaS classique, « envoyez-nous le fichier, nous le vérifierons », part avec un énorme handicap auprès de ce public. Chaque envoi sur un serveur soulève des questions auxquelles il faut répondre : où vont les données, qui y a accès, combien de temps sont-elles conservées, que se passe-t-il en cas de fuite ?
La deuxième particularité du projet, c’était le calendrier. Le SAF-T arrive par vagues et le marché commence à peine à se former : la première vague concerne les grandes entreprises à partir de 2026, mais les questions se posent bien plus tôt. Nous voulions un outil utile dès le moment où le comptable découvre l’obligation, et pas seulement quand il a un fichier prêt à déposer.
Nous avons formulé le projet ainsi : supprimer toutes les barrières entre l’utilisateur et la vérification. Pas d’inscription, pas d’e-mail, pas d’envoi de fichier, pas de prix. Chaque barrière supprimée, c’est une raison de moins de ne pas essayer.
Les trois décisions qui ont défini le projet
La vérification se fait dans le navigateur
La validation s’exécute localement grâce à libxml2 compilée en WebAssembly. Aucun serveur ne reçoit de fichiers, donc rien ne peut fuiter.
Un site statique
Environ 120 Ko au premier chargement, compression brotli, cache immutable. Il s’ouvre instantanément, même sur un portable professionnel via le VPN du bureau.
Uniquement des sources primaires
Tout le contenu du site s’appuie directement sur les documents de la NAP, pas sur des reformulations. Quand un sujet est nouveau, l’exactitude est la seule monnaie qui vaille.
Décision n° 1 : la vérification se fait entièrement dans le navigateur
Nous avons pris la décision d’architecture la plus importante dès le départ : la validation s’exécute localement, dans le navigateur de l’utilisateur, grâce à WebAssembly. Nous avons compilé libxml2, la bibliothèque qui assure depuis des décennies la validation XML dans l’industrie, en un module WASM qui charge le schéma XSD officiel de la NAP (v1.0.2) et vérifie le fichier sur place.
Mais le schéma n’est qu’un début. Le XSD indique si le fichier est structurellement valide, pas s’il a un sens sur le plan comptable. Nous avons donc ajouté par-dessus nos propres contrôles :
- Égalités de soldes par compte et concordance de TotalDebit/TotalCredit
- Références croisées : chaque pièce doit renvoyer à un tiers réellement déclaré
- Encodage UTF-8 et nom de fichier conforme à l’annexe 3
- Chiffre de contrôle de l’EIK (identifiant bulgare des entreprises) : un petit détail qui peut faire échouer un fichier par ailleurs parfait
Le traitement local a un double avantage. Pour l’utilisateur : rien ne peut fuiter, puisque rien n’est envoyé. La promesse de confidentialité n’est pas un paragraphe d’une politique de protection des données, mais une propriété de l’architecture, que chacun peut vérifier dans l’onglet Réseau de son navigateur. Pour nous : aucun serveur ne traite les données comptables d’autrui, et donc aucune des charges opérationnelles et juridiques qui vont avec.
Décision n° 2 : un site statique plutôt qu’une plateforme
Puisque la validation se fait côté client, le serveur n’a rien à calculer. Le site entier est donc statique : le chargement initial pèse environ 120 Ko, tout passe par la compression brotli et les ressources sont mises en cache en immutable. En pratique, l’outil s’ouvre instantanément même sur un portable professionnel via le VPN du bureau, c’est-à-dire exactement l’environnement dans lequel travaille notre public réel.
L’architecture statique nous a aussi permis d’être cohérents jusqu’au bout : le site n’a ni cookies ni traceurs externes, et les statistiques sont internes et anonymes. Il aurait été absurde de promettre que le fichier ne quitte pas le navigateur tout en envoyant le comportement de l’utilisateur à trois plateformes publicitaires.
Décision n° 3 : un contenu issu uniquement de sources primaires
La troisième décision n’est pas technique mais éditoriale : tout le contenu du site s’appuie directement sur les documents de la NAP, pas sur des reformulations. Quand un sujet est nouveau et source de tension, l’exactitude est la seule monnaie qui vaille.
C’est ainsi que toute une couche d’outils d’aide s’est développée autour de la vérification elle-même. Nous avons créé un répertoire des 347 éléments du schéma avec les descriptions officielles de la NAP, ainsi que les nomenclatures et le plan comptable national. Nous avons ajouté un calculateur « Dans quelle vague suis-je ? » pour les échéances 2026-2030, un glossaire des erreurs avec dix pages approfondies et un outil où l’on colle son message d’erreur, « Expliquez-moi l’erreur », ainsi qu’un index des 188 questions-réponses officielles du document de la NAP (version 2, 2026).
La dernière pièce est un convertisseur en bêta : vous fournissez la balance et le journal chronologique en CSV et vous obtenez un SAF-T XML mensuel, là encore entièrement dans le navigateur et gratuitement pendant la bêta. C’est le prolongement logique du même principe : si la vérification peut être locale, pourquoi pas aussi l’élaboration du fichier ? Vous pouvez le voir à l’œuvre dans l’application du convertisseur.
Ce que nous avons appris
La vitesse fait partie de la confiance
Nous avons l’habitude de considérer la vitesse comme une métrique SEO. Ici, elle s’est révélée être bien plus : un outil qui s’ouvre instantanément et fonctionne sans inscription envoie un signal de sérieux. L’inverse est vrai aussi : un site lent avec un formulaire d’e-mail avant le résultat dit « donnez-nous d’abord quelque chose, ensuite nous vous donnerons ».
La confidentialité se prouve, elle ne se déclare pas
La différence entre « nous ne partageons pas vos données » et « vos données ne nous parviennent physiquement pas » est la différence entre une promesse et un fait. La seconde est plus difficile à construire, mais incomparablement plus facile à communiquer : elle s’explique en une phrase et peut être vérifiée par tout utilisateur ayant quelques notions techniques.
Les sources primaires sont un avantage concurrentiel
Produire du contenu tiré directement du schéma et des réponses officielles de la NAP est un travail lent et ennuyeux. C’est justement pour cela que presque personne ne le fait, et justement pour cela qu’il paie. Face à un public professionnel, il n’y a pas d’argument plus fort que de citer la source primaire avec exactitude.
Ce que cela signifie pour vous
Si votre entreprise envisage un outil qui traite des données sensibles (financières, médicales, personnelles), le cas SAFTCheck se résume à trois enseignements transposables :
- Le traitement côté client est désormais une option réaliste. WebAssembly permet des calculs sérieux directement dans le navigateur. Si les données ne doivent pas quitter l’utilisateur, elles n’ont plus besoin de le faire.
- Tout n’a pas besoin d’une plateforme. Un site statique avec un front-end intelligent peut porter un produit à part entière, plus rapide, moins cher et plus sûr que le SaaS équivalent, lorsque les calculs se font en local.
- Supprimez les barrières avant la première utilisation. L’inscription, l’envoi du fichier et le prix sont trois portes que l’utilisateur doit franchir avant de voir la moindre valeur. Chaque porte fermée vous coûte des utilisateurs dont vous ne saurez jamais que vous les avez perdus.
Tous les produits ne peuvent pas (ou ne doivent pas) fonctionner entièrement dans le navigateur. Mais la question « ce traitement peut-il se faire côté client ? » mérite d’être posée au début de tout projet impliquant des données sensibles. Si la réponse est « oui », vous obtenez une architecture où la confiance ne se construit pas avec des mots : elle est intégrée. Et si vous cherchez un partenaire pour se poser cette question avec vous, vous savez où nous trouver.
