« C'est juste une application web avec quelques champs en plus »
On entend une version de cette phrase à presque chaque premier appel au sujet d'un système financier ou de conformité — une enseigne retail qui veut un vrai grand livre au lieu d'un tableur, une entreprise du BTP qui a besoin de facturation à l'avancement, une clinique qui veut regrouper remboursements et paie, une école qui a besoin d'une comptabilité de subventions et de frais de scolarité capable de survivre à un audit. Le réflexe est de cadrer le projet comme la dernière application CRUD : quelques tables, quelques formulaires, un tableau de bord, livré en quelques sprints.
Ce n'est pas la même construction. Pas parce que l'interface est plus complexe — la plupart des logiciels financiers ont des écrans moins nombreux et plus sobres qu'une application grand public. La différence, c'est que cinq éléments sont non négociables dans un logiciel financier, alors qu'ils restent optionnels partout ailleurs. En ignorer un seul, et le système ne tombe pas en panne bruyamment. Il échoue en silence, des mois plus tard, devant un auditeur ou un client très mécontent.
1. L'argent n'est pas un float
Une application classique peut arrondir un nombre à l'affichage et passer à autre chose. Un grand livre, non. Stockez une devise en virgule flottante, et de petites erreurs d'arrondi s'accumulent sur des milliers de transactions jusqu'à ce que les comptes ne balancent plus — et « les comptes ne balancent plus » n'est pas un ticket de bug, c'est une urgence business.
La solution est ennuyeuse et non négociable : des centimes entiers ou un vrai type décimal, jamais de float JavaScript, et chaque calcul — taxes, remises, répartitions, retenues de garantie — doit passer par la même règle d'arrondi partout dans le code. Chez nous, c'est une règle de linting, pas une remarque de code review.
2. Rien ne se supprime
Les applications classiques font en permanence des suppressions douces ou définitives. Les systèmes financiers, eux, ne suppriment pas — ils corrigent, et conservent l'original. Un grand livre en écriture seule (append-only) signifie que chaque écriture devient immuable une fois validée ; une erreur se corrige par une nouvelle écriture liée, pas en modifiant ou en supprimant l'existante. C'est ce qui rend un système prêt pour l'audit : un auditeur peut retracer l'historique complet de n'importe quel dollar, pas seulement l'état du jour.
Cette seule décision redessine votre modèle de données. Chaque ligne financière a besoin de posted_at, reversed_by et created_by dès le premier jour — ajouter l'immuabilité après coup à un schéma conçu pour autoriser les modifications, ce n'est pas une migration, c'est une reconstruction.
3. Toute action à haut risque exige une double validation
Le modèle de permissions d'une application classique se résume souvent à « ce rôle peut-il voir cette page ». Un logiciel financier a besoin de permissions au niveau de chaque action individuelle, et pour tout ce qui touche à de l'argent réel ou à un risque réel — annuler une facture, approuver un virement, passer outre un rejet de remboursement, renoncer à des pénalités de retard — une deuxième personne doit valider avant exécution. C'est le principe du maker-checker : une personne propose l'action, une autre, avec le bon rôle, la confirme, et le système enregistre les deux.
Ajouter ce mécanisme après coup est douloureux, car ce n'est pas qu'une simple table de permissions — cela change la forme même de votre API. Les actions passent en deux étapes (propose puis approve) au lieu d'une seule, et ce schéma doit être pensé dès le départ, pas plaqué sur un flux existant en « un clic pour valider ».
4. Les nouvelles tentatives créent de l'argent en double si on les laisse faire
Les passerelles de paiement, les fichiers bancaires et les chambres de compensation des assurances relancent tous des tentatives automatiquement. Une application classique relance une requête échouée et rien de grave ne se passe. Un système financier qui relance un appel de paiement sans clé d'idempotence peut débiter un client deux fois, enregistrer une transaction deux fois, ou doubler le versement d'un sous-traitant. Chaque écriture externe a besoin d'une clé d'idempotence unique, et chaque tâche nocturne a besoin d'une étape de réconciliation qui vérifie ce qui s'est réellement passé par rapport à ce que le grand livre croit s'être passé, et qui signale l'écart au lieu de supposer que tout s'est bien déroulé.
C'est une lacune fréquente dans les systèmes qui n'ont pas été conçus avec l'idempotence en tête : l'intégration fonctionne parfaitement en test, et des mois après la mise en production, le règlement d'un fournisseur ne se réconcilie plus et personne ne peut dire pourquoi — parce que rien n'a signalé la nouvelle tentative qui en est à l'origine.
5. Les règles de rétention et de disponibilité ne sont pas les vôtres
Une application classique peut choisir sa propre politique de sauvegarde. Un logiciel financier ou de conformité hérite de règles imposées de l'extérieur : environ sept ans de conservation des documents comptables pour la plupart des administrations fiscales, la règle de rétention de six ans propre à HIPAA pour la documentation de conformité comme les politiques et autorisations (la conservation effective des dossiers médicaux relève du droit de chaque État américain, qui varie et n'est pas remplacé par HIPAA), et les règles de périmètre PCI DSS dès qu'une donnée de carte touche votre système, même en transit. Manquez l'une de ces obligations, et le coût n'est pas un correctif de bug — c'est un constat dans l'audit de l'année suivante, ou une amende.
Les attentes en matière de disponibilité changent aussi. Un site vitrine indisponible pendant une heure, c'est gênant. Une paie qui ne part pas le jour prévu, ou le système de facturation d'un hôpital injoignable pendant l'admission des patients, c'est une tout autre catégorie de problème — et cela change ce que vous devez budgéter pour la supervision, le failover et les astreintes.
À quoi ça ressemble, secteur par secteur
Retail — le point de friction, c'est généralement la réconciliation : les ventes en caisse, les règlements des processeurs de carte et les versements aux fournisseurs doivent concorder, chaque jour, automatiquement, sur des dizaines de points de vente.
BTP — la facturation à l'avancement de type AIA et le suivi des retenues de garantie font que la « facture » n'est définitive qu'une fois un jalon de projet vérifié ; le grand livre doit modéliser un paiement partiel et conditionnel, pas seulement un statut payé/non payé. C'est exactement ce que nous avons construit pour un promoteur résidentiel et commercial — voir l'étude de cas.
Santé — les workflows de remboursement, l'adjudication des assurances et la paie clinique touchent tous à des informations de santé protégées, si bien qu'une gestion conforme à HIPAA (journalisation des accès, accès minimal nécessaire, chiffrement au repos) est une contrainte de conception, pas une case à cocher ajoutée à la fin.
Institutionnel — les grands livres de subventions, les restrictions des donateurs et les budgets par département exigent une comptabilité par fonds : l'argent affecté à un usage ne peut pas silencieusement en couvrir un autre, et chaque dollar a besoin d'une trace remontant jusqu'à sa source.
Ce que ça vous coûte réellement
Rien de tout ça n'est de l'ingénierie exotique — ce sont des patterns disciplinés et bien connus, appliqués avec constance. Mais cela veut dire qu'un module financier prend plus de temps qu'une fonctionnalité CRUD comparable, et coûte plus cher par écran. D'après notre expérience, un module unique et ciblé — calcul des coûts de chantier, prise en charge des remboursements, tableau de bord de réconciliation — prend de 10 à 16 semaines. Une suite financière multi-modules touchant plusieurs de ces points à la fois prend généralement de 5 à 9 mois, avec une première tranche utilisable livrée dans les 12 premières semaines.
Si un prestataire vous chiffre un logiciel financier ou de conformité au même tarif que votre site vitrine, demandez-lui directement comment il gère les pistes d'audit immuables, la double validation et la réconciliation. Si la réponse est vague, c'est ce chiffre-là qui est faux, pas l'effort que vous vous attendiez à payer.
En résumé
Un logiciel financier n'est pas plus difficile parce que ses écrans sont compliqués. Il est plus difficile parce que ses contraintes sont externes — les règles comptables, HIPAA, PCI, vos propres auditeurs — et aucune d'elles ne pardonne les raccourcis pris pour tenir un délai. Intégrez la discipline du grand livre dès le premier schéma, pas après le premier audit. Notre équipe logiciels financiers et d'entreprise cadre exactement ce type de projet — retail, BTP, santé et institutionnel — et peut vous dire, en une semaine, lesquels de ces patterns sont réellement nécessaires à votre système.
