Tout ce qui a changé
dans LemonVentile.

1.2.0 (14 octobre 2026)

Choisir, c’est enregistrer. Choisir un service ou un compte dans le menu d’une ligne ne suffisait pas : il fallait encore cliquer sur la coche, et un choix qu’on croyait fait se perdait au rechargement. La ligne s’enregistre maintenant dès le choix. La coche reste nécessaire pour ce que remplissent le report en masse et l’IA, qui sont à relire, et pour un service créé depuis la ligne. Un service dont la fiche n’a pas de compte s’enregistre quand on choisit le compte.

L’IA cherche le service avant le compte. Elle reçoit chaque service d’achat avec le compte de sa fiche, et la consigne lui fait chercher d’abord un service, puis un compte seul si aucun ne convient. Avant, elle trouvait souvent le bon service mais justifiait un autre compte (« faute de compte dédié »). Surtout, l’écran jetait son service dès que le compte proposé différait de celui affiché, ce qui arrivait sur toutes les lignes « à vérifier » tirées de la fiche du fournisseur. Sur une ligne sans compte ou à vérifier, le service est désormais posé avec le compte de sa fiche. Sur une ligne réglée par une règle, le désaccord s’affiche sans rien changer, et « Adopter » pose le service et son compte.

Les lignes identiques suivent. Un relevé de frais bancaires répète la même désignation six fois. Appliquer l’une d’elles affecte désormais aussi les autres lignes encore à ventiler de la facture qui portent la même désignation, à la date près, et la même référence fournisseur : même compte, même service. Elles ne comptent pas comme des confirmations de plus de la règle.

L’IA groupée s’occupe aussi des lignes « à vérifier ». Le bouton ne visait que les lignes sans compte. Chez un fournisseur dont la fiche porte un compte par défaut, toutes les lignes en avaient un, et le bouton ne faisait rien, sans le dire. Il interroge maintenant aussi les lignes marquées « à vérifier », et affiche un message quand il n’a aucune ligne à demander.

L’adresse de la facture reste dans la barre du navigateur. Après « Appliquer » ou « Modifier l’affectation », la fiche s’affichait sous l’adresse card.php sans numéro de facture, et F5 renvoyait le formulaire. La fiche est maintenant rechargée à sa propre adresse.

1.1.0 (9 octobre 2026)

L’installation s’explique dès l’ouverture du ZIP. Un fichier INSTALL.txt, en français et en anglais, donne les deux façons d’installer le module (depuis le menu de Dolibarr, sans décompresser, ou par copie dans custom), son activation, où trouver le mode d’emploi, et comment le mettre à jour.

Les modèles qui réfléchissent sont pris en charge. Les modèles Claude de génération 5.5 réfléchissent toujours avant de répondre, et cette réflexion se prélève sur le budget de réponse. Avec 1 500 tokens et 30 secondes d’attente, la proposition pouvait revenir vide, ou expirer alors qu’elle était en route. Trois réglages apparaissent dans la configuration : l’effort (de « faible » à « maximum », ou rien d’envoyé), le budget de réponse (4 000 par défaut, jusqu’à 32 000) et le délai d’attente (90 secondes par défaut, jusqu’à 300). Une réponse coupée par le budget, ou refusée par le modèle, le dit au lieu de s’afficher vide. Un service qui ne connaît pas l’effort le refuse en le nommant : le module le retire et renvoie la question.

Un modèle qui se reprend est compris. Il arrive qu’un modèle donne une première réponse, écrive « Correction : », puis en donne une seconde. Le module lisait les deux d’un bloc et rejetait la ligne comme incompréhensible. C’est désormais la dernière réponse, la correction, qui est retenue.

1.0.0 (6 septembre 2026)

Les dates ne comptent plus dans la comparaison. Une facture récurrente porte sa période dans le libellé — « Remboursement capital - Prêt 000000 - échéance 17/09/2026 ». D’un mois à l’autre, seule la date change, et le module ne reconnaissait donc jamais l’échéance précédente : quatre lignes ventilées en août, zéro proposition en septembre. Les dates sont désormais neutralisées dans la clé de rapprochement. Les autres nombres, non : deux prêts de numéros différents restent deux dépenses distinctes.

Un compte se choisit sur la facture, même sans proposition. Chaque ligne non ventilée porte la liste des comptes de Dolibarr, préremplie quand le module a une idée, vide sinon. On corrige une proposition avant de l’appliquer, et c’est le compte retenu — pas celui proposé — qui devient la règle. Renvoyer vers l’écran de ventilation quand le module ne savait rien proposer faisait quitter la facture qu’on avait sous les yeux.

Le module ventile. Sur une facture fournisseur, les lignes qui n’ont pas encore de compte comptable reçoivent une proposition, avec sa raison à côté : « règle retenue, utilisée 4 fois » ou « 3 fois sur ce fournisseur, toujours ce compte ». Un bouton par ligne, et un bouton pour appliquer d’un coup celles qui ne souffrent aucune contradiction.

Rien n’est écrit sans clic. Une ligne déjà ventilée n’est jamais touchée : le module complète le travail du comptable, il ne le refait pas. Et « appliquer tout » écarte volontairement les lignes dont l’historique hésite — ce sont justement celles qu’il faut regarder.

Une proposition par IA, si vous l’activez — et seulement si. Sur la première facture portant une désignation, l’historique n’a rien à retrouver et se tait. Un bouton « Demander à l’IA » apparaît alors sur ces lignes-là, et sur elles seules. Vous choisissez le service et fournissez votre clé : OpenAI, Anthropic, Google Gemini, ou n’importe quel modèle que vous hébergez vous-même — Ollama, vLLM, LM Studio — auquel cas rien ne quitte votre machine.

Le module fonctionne entièrement sans, la fonction est désactivée par défaut, et aucun appel n’est jamais fait automatiquement : ni à l’ouverture d’une facture, ni en tâche de fond. Un clic, une ligne, une question.

Ce qui part chez le service tient en trois choses : la désignation de la ligne, le nom du fournisseur, et la liste de vos comptes actifs. Aucun montant, aucun numéro de facture, aucune autre ligne, aucune donnée client. Cette liste de comptes n’est pas là pour meubler : une réponse désignant un compte absent de votre plan est refusée. Sans ce contrôle, le modèle rend un numéro vraisemblable qui n’existe pas chez vous, et l’enregistrement échoue plus loin sans que personne comprenne pourquoi.

Le modèle a aussi le droit de répondre qu’il ne sait pas, et la consigne le lui demande plutôt que de deviner. Sa proposition remplit le menu déroulant ; c’est toujours votre clic qui enregistre, et elle n’entre jamais dans le traitement de masse.

Un conseil tiré de la mesure : prenez un modèle ordinaire, pas un modèle de raisonnement. Sur les mêmes six lignes, un modèle courant répond en une seconde et traite les six ; un modèle de raisonnement met sept à neuf secondes et échoue sur deux, ayant dépensé son budget de réponse à réfléchir avant d’écrire.

Une page pour relire ce qui a été retenu. Comptabilité → Règles d’affectation liste les habitudes du module : le fournisseur concerné, ce qui déclenche la règle — référence article ou désignation —, le compte visé et le nombre de fois qu’elle a servi. On y filtre, on y corrige un compte, on y oublie une règle devenue fausse.

La recherche porte sur la valeur normalisée : taper « poulet » retrouve « Poulet aux hormones ». Un compte devenu inactif dans le plan comptable est signalé sur place, sans quoi la règle continuerait de proposer une affectation que l’application refuserait ensuite d’écrire.

Oublier une règle n’annule aucune ventilation déjà passée. C’est une habitude qui disparaît, pas une écriture.

Appliquer une proposition la retient comme règle pour les prochaines factures du même fournisseur. C’est toute la boucle d’apprentissage, et elle ne part jamais d’une devinette : seulement d’un choix confirmé. Changer d’avis sur une règle la réécrit et remet son compteur à un.

Rien n’est écrit à moitié. L’affectation de la ligne et la règle apprise partent dans la même transaction : les deux, ou aucune. Une erreur de base ne laisse plus une ligne ventilée sans règle, ni une règle qui prétend avoir servi. Le module refuse aussi de toucher une facture déjà transférée en comptabilité, ou dont il n’arrive pas à lire l’état comptable — plutôt que d’écrire derrière le transfert.

Ce qui ne devait jamais être accessible ne l’est plus. L’outil de démonstration, qui charge un administrateur et crée des données, refuse désormais tout appel par le web, et il ne fait plus partie du paquet distribué. L’accès aux factures et à l’assistance IA vérifie les droits de l’utilisateur et le jeton de la page, comme le reste de Dolibarr.

Une référence article n’est pas une date. Neutraliser les dates ne devait pas emporter les chiffres qui identifient une dépense : les références numériques et les dimensions décimales sont conservées. Une proposition ne sort que d’un historique cohérent et d’un compte actif du plan ; quand l’historique hésite, le module ne tranche pas à votre place.

On reste où on travaillait. Appliquer une seule ligne faisait perdre les choix commencés sur les autres et renvoyait en haut de la facture. Les menus gardent leur valeur, la page revient sur la ligne traitée, et un bouton ne s’active que lorsque sa ligne est prête. Une réponse de l’IA arrivée en retard n’écrase plus une correction faite entre-temps.

La liste des règles est paginée et l’historique n’est plus interrogé ligne par ligne — sur une facture longue, la page ne se payait pas la même requête dix fois. Recette passée sur Dolibarr 19 à 24 avec MariaDB 10.11. Les services IA réels et PostgreSQL ne sont pas certifiés.

Fondations

Première version. Fondations : descripteur, table des règles, moteur de rapprochement et page de configuration.

Le moteur est testé sans Dolibarr (php tests/unit-tests.php) sur les deux points où une erreur range une dépense dans le mauvais compte sans que personne ne s’en aperçoive : la normalisation des désignations et le choix de la règle quand plusieurs correspondent.

L’écran de ventilation sur la fiche facture fournisseur n’est pas encore livré.