Traitement intelligent de documents pour la comptabilité des PME

Contexte

Un groupe de petites sociétés produit un flux continu de factures, de reçus et de confirmations de revenus, en français et en anglais, sur papier, en photo ou en pièce jointe — certains en devise étrangère, certains envoyés deux fois, certains regroupés dans un même PDF. Chaque société a son mois d’exercice, ses taux de taxes et ses catégories, et le comptable qui ferme le mois a besoin d’un seul endroit où chaque document a déjà été lu, ventilé en sous-total, TPS et TVQ, converti en CAD et catégorisé. InvoiceFlow est né en juin 2026 comme l’outil de cette tenue de livres, puis est devenu une plateforme multi-sociétés avec rôles, approbation des comptes et adresse de transfert par société. C’est un produit distinct de FinSync, ma plateforme d’intégration ERP vers CCH Tagetik : aucun code commun, un autre problème.

Défi

L’extraction est la partie facile à montrer et la partie difficile à croire. La lecture optique des dates produit des années à cinq chiffres et des jours et mois inversés; un reçu en dollars d’un fournisseur étranger doit être reconnu comme étranger et converti au taux du bon jour; la même facture arrive par courriel et par téléversement; un seul balayage contient trois factures; un PDF de 38 Mo dépasse ce que le serveur accepte. Surtout, personne qui ferme un mois n’acceptera un chiffre deviné par un modèle. La plateforme devait décider, document par document, ce dont elle était sûre et ce qui exigeait une personne — et rendre cette décision visible, traçable et peu coûteuse à renverser.

Mon rôle

Fondateur et architecte : vision produit, spécification fonctionnelle, architecture de la plateforme et direction technique — de la chaîne d’extraction et de la couche déterministe de post-traitement au modèle de données, au système de rôles et aux règles d’accès. J’ai rédigé la spécification initiale — écrans, champs, chaîne de traitement et règles fiscales canadiennes comprises — et arbitré chaque décision produit qui a suivi : quelle passerelle de modèle utiliser, comment traiter les doublons, quand un fichier peut être scindé, ce que chaque rôle peut faire. Bâtie et exploitée avec mon équipe chez SOFT M POWER CANADA, avec une plateforme de développement assistée par l’IA pour l’implantation.

Architecture / approche

Une seule chaîne, deux natures. Un grand modèle multimodal reçoit le document entier et la liste des catégories de la société, et doit répondre dans un schéma JSON contraint sous une règle unique : un fichier est une facture. Tout ce qui suit le modèle est du code déterministe que l’on peut tester : réparation des dates avec avertissements écrits dans un journal de traitement, détection de la devise et conversion au taux de la date de facture à partir de deux sources publiques en cascade, détection des doublons qui ne supprime que lorsque numéro, fournisseur et montant concordent avec un enregistrement plus ancien, et statut de révision déclenché par quatre conditions — confiance sous le seuil, doublon soupçonné, plusieurs factures dans un fichier ou date douteuse. Les fichiers multi-factures sont signalés, jamais séparés sans décision humaine.

Technologie

Application React rendue côté serveur avec fonctions serveur derrière un intergiciel d’authentification; PostgreSQL avec sécurité au niveau des lignes sur les huit tables et sur le stockage de fichiers, limitée à chaque société par propriété ou par appartenance; stockage d’objets à accès restreint organisé par société, année, mois et type; une passerelle IA infonuagique vers un modèle multimodal, appelée uniquement depuis le serveur; deux sources publiques de taux de change avec repli; compression des PDF dans le navigateur — réencodage page par page en cinq passes au plus — pour rester sous la limite serveur de 8 Mo; synchronisation de la boîte courriel à la demande et par un point d’entrée planifié; un scan de doublons à la demande qui n’utilise aucune IA.

Exécution

Quatre-vingt-quinze itérations produit entre juin et septembre 2026, éprouvées sur de vraies factures dès les premières semaines. L’essentiel du travail après la chaîne initiale relevait de ce que seule la production révèle : aperçus PDF bloqués par le navigateur, noms de fichiers accentués refusés par le stockage, dépassements de délai sur les fichiers lourds qui ont mené à la compression côté navigateur, un décalage de fuseau horaire qui déplaçait le premier du mois, filtres et défilement perdus à chaque action, catégories par défaut en anglais dans une interface française, une boîte de réception inondée de liens plutôt que de pièces jointes. Les règles d’accès ont été réécrites trois fois — propriétaire, puis rôles, puis appartenance aux sociétés — et deux passes de durcissement ont verrouillé les fonctions privilégiées de la base et mis à jour des dépendances vulnérables.

Contraintes

Un environnement d’exécution sans serveur, avec une limite de requête de 8 Mo et un temps processeur borné : les fichiers lourds sont compressés avant de quitter le navigateur. Chaque appel au modèle a un coût : deux documents traités à la fois, la synchronisation planifiée traite les sociétés l’une après l’autre, et le scan de doublons sur une sélection est déterministe. Pas de domaine de réception dédié : après deux tentatives d’infrastructure dédiée, la réception s’est fixée sur des adresses dérivées d’une boîte qui existe déjà — zéro configuration. Les documents sont analysés par un fournisseur de modèle infonuagique : le produit ne prétend pas que les documents restent dans son environnement; il conserve la réponse brute du modèle et laisse chaque champ modifiable. Aucune intégration comptable : l’export est en CSV, avec devise, taux et total CAD.

Leçons clés

1. Placer une couche déterministe après le modèle : dates, devises, doublons et décision de révision appartiennent à du code que l’on peut tester, pas à une consigne que l’on peut seulement espérer.
2. Le seuil de confiance est une décision produit, pas un réglage du modèle — envoyer un document à une personne coûte moins cher qu’un mauvais chiffre dans un grand livre.
3. Ne supprimer que lorsqu’on est certain : une règle de doublons qui penche vers la question coûte un clic; une règle qui penche vers la suppression coûte la confiance.
4. La réception sans configuration l’emporte sur l’infrastructure élégante — une adresse sur une boîte qui existe déjà a été mise en service là où deux tentatives de domaine dédié ne l’ont pas été.
5. La production casse sur les choses ennuyeuses — taille des fichiers, noms de fichiers, fuseaux horaires — et c’est là qu’est allée la plus grande part du temps d’ingénierie.