Coder pour des comptables : les écueils à éviter

Lorsqu’on développe un logiciel à destination de professions réglementées, on a une responsabilité supplémentaire par rapport à n’importe quel autre logiciel. Chaque erreur peut avoir des conséquences légales et financières importantes pour nos clients.

Il devient donc vital de bien séparer les logiques et les responsabilités de nos algorithmes pour s’assurer que les normes comptables soient bien respectées à chaque étape du traitement automatisé des documents.

L’un des challenges principaux que nous avons rencontré est la séparation claire entre les logiques dites « fonctionnelles » et les logiques « par état ». C’est d’ailleurs l’un des sujets majeurs de la programmation informatique. Est-ce que je code dans le but d’obtenir de changer un état (programmation par état) ou de retourner un résultat (programmation fonctionnelle) ?

Par exemple, lorsqu’on recherche un billet d’avion sur un site de comparatifs en ligne, les prix sont calculés dynamiquement en fonction de l’offre et de la demande. Une négociation invisible s’engage alors, entre les consommateurs et les compagnies aériennes. Cette négociation a lieu en temps réel, et bien que les calculs algorithmiques qui déterminent les prix des billets restent les mêmes, les paramètres (nombre de connexions, tarifications, recherches…) changent constamment, entraînant donc un changement de résultat (le prix du billet d’avion).

Donc, à chaque fois que vous allez sur un site de comparatifs de billets d’avion, et que vous recherchez un billet, votre action a une influence sur le prix, qui change dynamiquement. Donc c’est fonctionnel.

Cependant, lorsqu’on achète le billet d’avion qui nous convient, ces calculs s’arrêtent, et le prix est sauvegardé dans une base de données pour être ensuite débité de notre compte. Donc c’est par état.

Il serait absurde de recalculer le prix à la hausse ou à la baisse à chaque fois que le client qui a acheté le billet d’avion va sur son compte pour le consulter. Ce prix doit être figé et enregistré.

A l’inverse, d’autres informations de votre billet doivent pouvoir être modifiées dynamiquement : par exemple, les horaires du billet. En cas de retard, on souhaite que l’utilisateur puisse avoir en temps réel l’information des horaires de départ et d’arrivée lorsqu’il consulte son compte. Il fait donc du sens de ne pas figer ces horaires une fois que le billet a été acheté, mais de les recalculer plus ou moins dynamiquement lorsque le client consulte son compte. On mélange ici de la logique par état et de la logique fonctionnelle.

C’est évidemment plus compliqué en réalité : la SNCF, par exemple, sauvegarde les horaires des trains sur plusieurs bases de données pour éviter les surcharges de serveur. Parfois, il y a des petits décalages entre l’horaire affiché sur l’application SNCF et l’horaire réel de départ du train. Cela peut être comique lorsqu’on le train a plus d’une heure de retard au départ et que l’application nous affiche « vous êtes en route! ». Evidemment, ces cas sont très rares comme peuvent l’attester les gens qui prennent régulièrement le train.

On le voit, un « état » représente un point de négociation figé à un instant T, une sorte de « contrat » entre deux parties qui se sont mises d’accord sur un échange de données. A l’inverse, une « fonction » est un algorithme qui prend des données en entrée et en renvoie d’autres en sortie de manière dynamique.

En comptabilité, on voit que ce sujet est absolument crucial.

Lorsque les algorithmes de Chaintrust passent sur chaque facture, ils récupèrent des informations venant de trois sources différentes :

– Le FEC N-1 de la société concernée

– Les apprentissages automatiques de nos algorithmes

– Les éventuels paramétrages que nos clients nous demandent entre chaque batch d’écritures

Parmi ces trois sources, seule celle du FEC est constante. Les deux autres peuvent évoluer, ce qui a pour conséquence que des écritures comptables différentes peuvent sortir pour une même facture. Lorsque nous envoyons les écritures comptables à notre client, il devient donc important de les figer afin d’éviter tout problème : en effet, il arrive que les clients nous redemandent les écritures, et donc il faut absolument que les écritures que nous leur envoyons soient les mêmes à chaque téléchargement !

Cependant, nous vérifions ces écritures avant de les envoyer, nous avons donc mis en place un process standardisé de génération / validation d’écritures :

1. Les algorithmes passent sur chaque facture et génèrent une première version d’écritures

2. Puis, une phase de validation d’écritures commence : tous les potentiels problèmes comptables sont traités de manière semi-automatisée : les doublons, les problèmes de cutoff, les arrondis de TVA, la séquentialité, les immobilisations…

3. Lorsque cette phase est terminée, les écritures sortent : un dernier contrôle qualité global est effectué par notre équipe pour s’assurer que des incohérences ne sont pas passées « en dessous du radar »

4. Une fois qu’on est certains de nos écritures, nous les validons : A ce moment, les écritures sont figées, les factures sont tamponnées numériquement, et notre client va pouvoir les télécharger.

5. Si malgré tout certaines erreurs se sont tout de même glissées dans les écritures, nous demandons à nos clients de nous les remonter pour pouvoir les corriger lors des futures sorties : mais cela n’a pas d’impact sur les sorties antérieures, car les écritures ont été figées.

6. Dans le pire des cas, on peut désactiver une sortie d’écriture et recommencer, mais il faut évidemment s’assurer que le client ne les a pas importées dans son logiciel avant !

Cette démarche nous permet de facturer nos clients en tout sérénité. Chaque facture émise correspond à des écritures comptables qui ont été traitées et validées par nos clients, ce qui nous assure que l’on ne facturera pas « en trop » nos clients.

La comptabilité allie à la fois des besoins lourds de logiques fonctionnelle tout en exigeant de figer les données et donc de respecter une logique par état. C’est donc complexe en termes de code, de logique et de traitement. L’atomisation et l’indépendance des objets devient un enjeu critique pour la scalabilité et l’entropie du code.

Envie de voir ce que ça donne : automatisez votre saisie comptable sur www.chaintrust.io/