IA locale ⚡ Réconciliation : automate sans rappeler le modèle
Découvrez Doze : IA locale pour automatiser la réconciliation des paiements, sans modèle. Vérifiez les écarts avec Gemma (Ollama). Testez le replay hors ligne !
Doze : apprenez une fois, laissez l'IA dormir
Dans beaucoup d'automatisations dites « intelligentes », le modèle est sollicité à chaque étape. Il relit les données, refait des calculs et s'acharne à gérer les exceptions. Ça peut marcher, mais au final, on retombe sur une dépendance totale : pour une tâche récurrente, il faut à nouveau une inférence, avec son coût, son délai et ses risques d'interprétation.
Doze pose une question plus simple : dans votre chaîne de travail, qu'est-ce qui a vraiment besoin d'un modèle, et qu'est-ce qui peut ensuite tourner de façon déterministe ? Le projet applique cette idée à un cas concret : rapprocher l'export d'un prestataire de paiement avec un relevé bancaire. Gemma, exécuté localement avec Ollama, aide à traduire des intitulés de colonnes. Une fois cette correspondance validée, Python fait les contrôles sans remettre le modèle en marche.
Ce prototype ne prouve ni un gain de temps en entreprise, ni une fiabilité « garantie » sur des données réelles. Il propose surtout une architecture à tester : utiliser l'IA pour lever une ambiguïté une fois, enregistrer le résultat, puis confier les opérations répétables à du code prévisible. Voici comment ça marche, ce que ça vérifie, et où s'arrêtent les garanties.
Le problème : un modèle n'a pas besoin de tout refaire
Le rapprochement des paiements est souvent présenté comme une comparaison de montants. Sauf qu'avant même ça, il faut comprendre les exports. Le prestataire peut avoir une colonne intitulée « Groupe de versement », tandis que la banque utilise « Référence de remise ». Dans les deux cas, on parle du même identifiant de règlement.
Ensuite, il y a les montants à distinguer. Le client paie un montant brut ; le prestataire déduit ses frais ; la banque crédite le montant net. Résultat : comparer « somme payée » et « crédit bancaire » peut signaler un écart... alors que tout est correct. À l'inverse, un écart d'un centime peut être un vrai problème et ne doit pas être « noyé » par un arrondi.
Séparer l'interprétation du calcul
Un modèle de langage peut aider à comprendre que deux intitulés différents renvoient à la même notion. Mais ça ne veut pas dire qu'il est adapté pour additionner des montants, repérer des doublons, ou décider qu'un écart est négligeable.
La séparation utile ressemble à ça :
- Interpréter une convention floue : demander au modèle une correspondance entre les noms de colonnes quand ils ne sont pas assez clairs.
- Vérifier une règle connue : laisser du code classique comparer des références, calculer un montant net, et signaler les écarts.
- Prendre la décision opérationnelle : une personne examine les cas non résolus et autorise (ou non) la transmission du résultat.
Avec ça, on limite les endroits où une réponse plausible mais fausse pourrait passer pour une certitude. Et on évite aussi de payer (en temps et en appels au modèle) la même inférence à chaque export, tant que le format reste identique.
La question à poser avant d'ajouter de l'IA
Le bon critère n'est pas « peut-on demander à un modèle ? ». C'est plutôt : quelle incertitude le modèle doit-il résoudre ? Si vos fichiers réutilisent toujours les mêmes colonnes, alors leur correspondance n'est pas une décision à refaire chaque semaine.
C'est l'idée de Doze : demander au modèle une proposition de correspondance une fois, la faire valider, puis réutiliser cet artefact. Le nom résume le principe : une fois l'ambiguïté traitée, le modèle peut dormir. Si vous voulez comparer avec une autre approche, vous pouvez aussi lire cette automatisation fondée sur des règles déterministes.
L'architecture de Doze : enseigner puis exécuter
Doze utilise Gemma en local, via Ollama, pour transformer des explications approuvées en correspondances entre colonnes. Concrètement, le modèle reçoit les en-têtes des deux fichiers, le séparateur décimal choisi, et les explications humaines nécessaires pour lever l'ambiguïté.
Il ne reçoit pas les lignes de transactions pour décider si elles sont « bonnes » ou « acceptables ». Il ne génère pas de logique de rapprochement. Sa sortie est un objet JSON qui propose, par exemple, d'associer « Groupe de versement » (dans l'export paiements) à « Référence de remise » (dans l'export bancaire).
Un artefact lisible plutôt qu'une conversation à rejouer
La correspondance sauvegardée ressemble à une configuration. Elle identifie notamment les références, les identifiants de lignes, le montant brut, les frais, le montant bancaire et la devise. Chaque rôle doit correspondre à une vraie colonne de l'export concerné.
Cette configuration n'est pas une preuve que la correspondance est correcte. C'est une proposition : compréhensible, modifiable, et approuvée par l'utilisateur. On pourrait aussi renseigner ces champs à la main. L'intérêt de l'IA, ici, c'est de transformer une explication en proposition réutilisable - pas de rendre un rapprochement « automatiquement sûr » juste parce qu'un modèle l'a écrit.
Le flux se décompose donc en deux phases :
- Enseigner : fournir les intitulés et les explications approuvées ; demander à Gemma une correspondance structurée (ou un refus).
- Vérifier : examiner la correspondance, la tester sur des exemples connus, puis approuver.
- Réutiliser : charger les nouveaux exports et exécuter les contrôles sans inférence, ni appel au modèle.
- Examiner : traiter les anomalies et valider le rapport avant transmission.
Une inférence locale, sans repli automatique vers le cloud
Le projet utilise Ollama pour exécuter l'inférence en local, et Gemma comme modèle à poids ouverts. Dans le parcours décrit, les en-têtes et l'explication restent envoyés à un service Ollama accessible sur la machine, plutôt qu'à une API d'inférence distante. Doze ne prévoit pas de bascule automatique vers le cloud, et ne télécharge pas de modèle sans que l'utilisateur le demande.
Ça réduit la dépendance à un service distant pour cette étape précise. Mais ça ne remplace pas une analyse RGPD plus globale : la gestion des fichiers, des journaux, des postes et des accès reste à examiner dans le contexte de l'organisation. L'IA locale, ici, apporte surtout une frontière technique plus simple à auditer, pas une conformité automatique.
Le code applicatif est sous licence MIT. Les poids de Gemma ne sont pas fournis avec le projet et conservent leurs propres conditions de licence. Pour une mise en œuvre, il faut donc vérifier séparément les licences du code, du modèle et des composants utilisés - un point particulièrement important en contexte professionnel européen.
Les contrôles qui rendent le résultat vérifiable
Un JSON valide n'est pas une bonne correspondance. On peut très bien produire une structure propre qui associe le montant brut aux frais et rend tous les calculs faux. Doze ne traite donc pas la sortie du modèle comme une validation.
Des exemples de test indépendants de la proposition
Le prototype de démonstration accompagne la correspondance avec des fichiers CSV synthétiques et des résultats attendus définis séparément. Ces exemples couvrent huit cas : remboursements, doublons, virements manquants, plusieurs devises, et un écart d'un centime.
La configuration proposée doit passer ces tests. Elle ne peut pas déclarer elle-même qu'elle est correcte : les « témoins » sont distincts de la sortie du modèle. Dans l'exemple publié, une correspondance plausible passe les huit tests. Si on inverse le montant brut et les frais, elle n'en passe plus qu'un sur huit.
Cette vérification reste toutefois limitée. Les tests portent sur le schéma synthétique connu du projet ; ils ne prouvent pas la compatibilité avec tous les prestataires ou toutes les structures d'exports. Un rapprochement manuel avec une configuration approuvée reste possible, mais il ne bénéficie pas automatiquement de cette suite de tests.
Des calculs déterministes et des exceptions explicites
Une fois le mapping approuvé, le moteur Python fait les calculs avec une arithmétique décimale et s'appuie sur des références de règlement exactes. On n'essaie pas de « trouver une ligne similaire » pour faire disparaître une anomalie.
Les doublons, les transferts ambigus, les devises non prises en charge ou contradictoires, les lignes mal formées, et les changements de schéma sont signalés comme des problèmes. Un centime d'écart reste un écart. Oui, c'est moins « intelligent » qu'une réconciliation qui devinerait et comblerait tout. Mais c'est aussi plus simple à auditer : l'outil expose ce qu'il ne sait pas résoudre.
Et même quand tout se passe bien, il n'y a pas de transmission automatique. L'utilisateur examine le rapport, puis l'approbation est liée au hachage du rapport, aux fichiers utilisés, ainsi qu'à la correspondance retenue. Si un fichier change, l'ancienne approbation ne s'applique plus.
Le paquet de transmission contient notamment un CSV de rapprochement, un journal d'audit JSON, la correspondance, les empreintes des sources et un fichier de lecture. Les exports d'origine ne sont pas modifiés et leur contenu n'est pas copié dans le paquet.
Ce que montre vraiment la démonstration
La démonstration utilise des exports synthétiques et un résultat Gemma enregistré, présenté comme tel. L'inférence locale a bien été réalisée à un moment donné, mais la rejouer ne demande pas de lancer le modèle. Ça permet d'évaluer l'application sans confondre « lecture d'un résultat enregistré » et « nouvel appel à l'IA ».
Sur 52 semaines simulées, le replay sans inférence donne 41 semaines « propres », 11 en revue, et 19 exceptions explicites. Ces catégories peuvent se recouper : on ne doit pas les additionner comme des groupes strictement exclusifs. Le point important, pour l'architecture, c'est qu'aucun appel au modèle n'a lieu pendant ce replay. Ce test ne prétend pas non plus mesurer un bilan annuel d'activité, ni le temps ou l'argent économisés.
Essayer le prototype et comprendre ses limites
Le prototype est utilisable sans compte et sans téléchargement de modèle si vous choisissez le replay du résultat enregistré. Il faut Python 3.11 (ou plus récent) pour ce parcours. Une fois le dépôt récupéré et son répertoire ouvert, lancez :
python -m doze.serverPuis ouvrez http://127.0.0.1:8741 dans votre navigateur. Sélectionnez le replay du résultat Gemma vérifié, regardez la correspondance, et lancez les tests. Ensuite, vous pouvez tomber sur une semaine problématique, inspecter une exception, puis comparer avec une semaine « propre » et le replay des 52 vendredis.
Le parcours de replay n'est pas une nouvelle inférence : il réutilise une sortie enregistrée. Pour tester la partie « enseignement » par le modèle, il faut Ollama et le modèle local correspondant. Cette différence évite de confondre une démo reproductible hors ligne avec la réalité de l'appel au modèle à chaque lancement.
Une voie en ligne de commande
Le rapprochement peut aussi se lancer sans navigateur, sans serveur web, et sans Ollama, via l'interface en ligne de commande :
python -m doze.close_cli --profile workflow.json --payments payments.csv --bank bank.csv --mapping-approvedEnsuite, la création du paquet de transmission exige le hachage exact du rapport précédemment examiné, avec un nouveau nom de fichier de sortie. Le projet indique avoir testé ce parcours dans de nouveaux processus Python où la création de sockets était bloquée. Les contrôles Doze passent, avec notamment des verdicts sur une semaine propre et une semaine problématique, la création d'un ZIP approuvé, le rejet d'une approbation devenue périmée, et la conservation des fichiers de sortie existants.
Le dépôt inclut aussi les sorties du modèle, les tentatives refusées, les jeux de données synthétiques et les scripts de vérification. La suite de tests annoncée compte 120 tests : 119 réussis, et un test de permission de lien symbolique sous Windows ignoré. L'intégration continue couvre Python 3.11 et 3.12 sous Windows et Linux, y compris une vérification hors ligne. Tout ça rend l'implémentation plus facile à inspecter - sans remplacer l'essai avec vos propres exports et vos propres règles comptables.
Les limites à garder en tête
Doze vérifie l'accord entre les exports que vous lui donnez. Il ne peut pas prouver qu'ils sont complets : si une transaction manque des deux fichiers, il ne la détectera pas.
Le prototype ne se connecte pas aux comptes bancaires, ne déplace pas d'argent, ne convertit pas les devises, ne résout pas les virements fractionnés, et ne fournit pas de conseil fiscal.
Il n'y a pas non plus d'essai en conditions client réelles, et aucun gain de temps humain ou d'énergie n'a été mesuré. Les jeux de données de démonstration illustrent le comportement du système sur des cas construits ; ils ne permettent pas de généraliser à toutes les pratiques comptables françaises ou européennes.
Avant de l'adapter à un processus réel, il faudra notamment vérifier les formats d'export, les conventions d'arrondi, les devises, le traitement des remboursements, les responsabilités d'approbation et la conservation des données. Une revue avec les équipes financières et techniques est nécessaire. L'approche reste intéressante parce qu'elle rend les frontières visibles - pas parce qu'elle supprime le besoin de contrôle.