Accueil › Vérification

Comment nous vérifions que nos fichiers s’importent

La plupart des convertisseurs vérifient leurs fichiers avec leur propre code. C’est-à-dire qu’ils ne les vérifient pas : un fichier peut passer tous leurs contrôles et être refusé par le premier logiciel de comptabilité venu.

Nous faisons l’inverse. Chaque fichier produit par RelevéPro est donné à relire à des bibliothèques libres écrites par d’autres, qui n’ont jamais vu ce projet. Ce qu’elles en ressortent est comparé ligne à ligne à une vérité terrain écrite à la main avant que les relevés d’épreuve existent. Voici le résultat, et ce qu’il ne dit pas.

Mesuré le 27 août 2026 par la commande npm run import sur 68 relevés d’épreuve et 6 formats : OFX, QIF, CFONB, FEC, XLSX, CSV. 3 fichiers ne sont pas comptés parce que le convertisseur refuse lui-même de les fabriquer — le CFONB 120 exige deux soldes, et un relevé de carte n’en imprime aucun. Un refus explicite vaut mieux qu’un fichier qui a l’air bon.

La méthode, en trois temps

Elle tient dans une idée : un juge se vérifie avant d’être cru. Une bibliothèque qui approuve nos fichiers ne prouve rien tant qu’on n’a pas montré qu’elle sait lire, et qu’elle sait dire non.

1. Elle relit d’abord un fichier qui n’est pas le nôtre. Un fichier de référence pris dans le dépôt d’un autre projet, dont le contenu exact est écrit à côté. Une bibliothèque qui s’y trompe est écartée — voir plus bas.
2. Elle doit refuser un fichier abîmé. On casse volontairement un de nos fichiers de 6 façons différentes — archive tronquée, zone obligatoire effacée, montant remplacé par du texte — et on vérifie qu’elle s’en aperçoit. Une bibliothèque qui avale n’importe quoi ne prouve rien quand elle dit « oui ». 44 avaries sur 48 sont vues.
3. Alors seulement, elle juge nos fichiers. 68 relevés d’épreuve, chacun exporté dans tous les formats, chaque ligne comparée à la vérité terrain : date, libellé, débit, crédit.

Les 8 juges

Aucune de ces bibliothèques n’est embarquée dans le site : elles servent à l’atelier, pas au visiteur. Le convertisseur que vous utilisez ne télécharge rien et n’envoie rien — et cela se vérifie en trente secondes.

Les 2 lecteurs que nous avons écartés, et pourquoi

Une page qui ne montre que ce qui marche se lit comme une publicité. Celles-ci ont échoué à la première étape — sur un fichier de référence qui n’est pas le nôtre. Elles ne peuvent donc juger personne, et elles ne comptent pas dans les chiffres ci-dessus.

• ofx-data-extractor 1.5.0 — relit reference-ofx.ofx sans erreur mais s’y trompe. Elle rend zéro opération sur un vrai relevé, et lève une exception dès qu’une balise standard est écrite sur une seule ligne — ce que font les banques.
• qif-ts 1.0.0 — relit reference-qif.qif sans erreur mais s’y trompe. Elle divise par mille tout montant portant un séparateur de milliers, sans erreur ni avertissement. Le plus intéressant : elle aurait relu nos fichiers correctement, parce que nous n’écrivons jamais de séparateur de milliers. Son accord aurait donc été un faux témoignage — et il aurait compté dans le total.

Ce que la méthode a trouvé chez nous

La méthode en a trouvé 5, tous invisibles de l’intérieur : les montants, les dates et les libellés étaient justes dans chaque cas. C’étaient des erreurs de structure, sur des zones qu’aucun de nos contrôles ne regardait — parce que c’est nous qui les avions écrites. Chacun est corrigé, et chacun est remis dans le code à chaque passage pour vérifier que la bibliothèque tierce le refuse à nouveau : un correctif qu’on ne sait pas faire échouer n’est pas un correctif prouvé.

• OFX Une seule opération sans libellé — un virement que la banque n’a pas nommé — rendait le fichier OFX entièrement illisible. Les douze autres opérations partaient avec.
• CFONB Une zone obligatoire du CFONB 120 était laissée en blanc, par prudence. Résultat : 46 fichiers sur 46 rejetés par un module de rapprochement bancaire, avant qu’un seul montant soit lu.
• CFONB Même chose pour le numéro de compte : onze blancs dans une zone obligatoire, et le fichier était jeté sans être ouvert. Le convertisseur refuse désormais de le produire et dit quoi saisir.
• CFONB Un libellé long — une référence de mandat SEPA, par exemple — était coupé à 70 caractères sans un mot. La fin disparaissait du fichier, et rien ne le signalait.
• XLSX La colonne « Date » du fichier Excel était écrite en texte et non en date. Le classeur s’ouvrait, les montants étaient justes — mais un tri par date rendait l’ordre alphabétique, et une soustraction de deux dates rendait une erreur. C’est le fichier que tout le monde télécharge.

Ce que ces chiffres ne disent pas

C’est la partie que nous ne voulons pas laisser à votre charge.

• Une bibliothèque libre n’est pas Sage, EBP ou Cegid. Elle prouve que le fichier est lisible par un tiers qui n’a jamais vu ce projet. Elle ne prouve pas qu’un logiciel commercial l’acceptera : celui-ci peut refuser un fichier parfait pour un plan de comptes inconnu, un journal non déclaré ou un exercice fermé. À ce jour, aucun logiciel comptable commercial n’a ouvert un de nos fichiers — c’est le trou le plus large de cette page, et c’est vous qui pouvez le combler en cinq minutes, gratuitement.
• Sur le FEC, nous avons publié une affirmation fausse, et voici sa correction. Cette page a longtemps dit : « le FEC n’a pas de juge extérieur, aucune bibliothèque libre ne le lit ». Le périmètre de cette recherche était deux registres — npm et PyPI — pour un format français qui vit ailleurs, et c’était le défaut. Un lecteur de FEC libre existe ; il relit désormais nos FEC à chaque passage du banc, et vous le voyez dans le tableau ci-dessus. Ce qui reste vrai en dessous : nos 17 contrôles de structure transcrits de l’outil officiel de la DGFiP restent, eux, notre code relisant notre code — c’est le juge extérieur, et lui seul, qui ne l’est pas.
• Les juges ont leurs angles morts, et les voici. « le CompteNum vidé (champ NOT NULL de la DGFiP) », « la feuille retirée du manifeste [Content_Types].xml », « la marque d’ordre des octets (BOM) retirée » : sur ces points-là, la bibliothèque ne remarque rien. Nous le mesurons et nous l’écrivons plutôt que de compter ces avaries comme vues.
• Les relevés d’épreuve sont fabriqués. 68 mises en page écrites pour casser le moteur, dont on connaît la réponse exacte avant de le lancer. C’est beaucoup plus dur qu’un corpus ordinaire — mais un relevé réel reste un relevé réel, et nous n’en avons qu’un petit nombre.

← Convertir un relevé · Pourquoi votre relevé ne part nulle part