Le piège des "outils intelligents" pré-paramétrés

La plupart des apps de gestion vendent du "matching intelligent". En réalité, c'est :

  • Une liste de patterns hardcodés (URSSAF, DGFIP, Stripe, OVH)
  • Un score de similarité textuelle entre libellés
  • Et c'est tout

Ça marche pour 60-70% de vos transactions. Les 30% restants, vous classifiez à la main chaque mois. Aucun apprentissage.

La différence : règles persistées + confidence évolutive

Chez Freelance Budget, chaque fois que vous validez ou créez une classification, l'app génère ou met à jour une ReconciliationRule :

  • Pattern (substring ou regex) du libellé bancaire
  • Match cible (mission, dépense, salaire, autre revenu)
  • Confidence score : 0-100, monte à chaque validation, descend si vous rejetez

Exemple concret :

  1. Mois 1 : Premier prélèvement OVH SAS. Vous classez en "Hébergement web". Une règle est créée : pattern: "OVH SAS" → expense: "Hébergement OVH", confidence 50.

  2. Mois 2 : Nouveau prélèvement OVH SAS. Le moteur applique la règle automatiquement. Vous validez l'auto-match. Confidence monte à 65.

  3. Mois 3 : Confidence 80. Le moteur l'auto-applique sans même vous demander.

  4. Mois 6 : Confidence 95. Le moteur l'applique en silence. Vous voyez juste "9 transactions auto-matchées" en haut du dashboard.

Le système qui devient plus intelligent au fil du temps

Voici ce qui se passe vraiment chez un freelance actif après 3-6 mois d'usage :

| Mois | Transactions à classer manuellement | Temps passé | |---|---|---| | Mois 1 | 95% du relevé | 1h30 | | Mois 3 | 35% du relevé | 30 min | | Mois 6 | 12% du relevé | 10 min | | Mois 12+ | 5-8% du relevé | 5 min |

Ces 5-8% restants, c'est typiquement :

  • Une transaction unique (achat exceptionnel, virement nouveau client)
  • Une variation inhabituelle (prélèvement habituel mais montant différent)
  • Une suppression de pattern (vous avez résilié un abonnement et un mois plus tard, le pattern est obsolète)

Le mécanisme regex vs substring

Les règles supportent deux modes :

  • Substring (défaut) : match si le libellé contient le pattern. Simple, suffit pour 80% des cas.
  • Regex : pour les cas tordus. Exemple : ^STRIPE.*ACME capture tous les versements Stripe pour le client Acme spécifiquement.

Les regex se gagnent automatiquement quand vous corrigez plusieurs fois un faux match. Si vous rejetez "STRIPE — Acme Consulting" matché à "STRIPE — Autre Client", l'app durcit la règle avec un regex plus spécifique.

La confiance qui descend aussi

Si vous rejetez ou modifiez une classification, la confidence baisse. C'est essentiel — ça évite que l'app s'enferre dans une erreur.

Exemple : vous aviez classé "STRIPE PAYOUT" en "Other income". Mais en réalité, vous avez 2 sources Stripe : votre boutique (revenus) et votre app Pro (refacturations). Quand vous rejetez 3 fois, la règle perd confiance et l'app vous redemande.

Pourquoi peu d'outils SaaS font ça

Construire un moteur d'apprentissage persistant et qui s'adapte au comportement demande :

  • Une table ReconciliationRule avec un schéma riche (confidence, regex flag, applied/confirmed counts)
  • Un moteur de matching qui interroge ces règles avant les patterns hardcodés
  • Une UI qui rend la correction explicite (pas juste un "x" qui efface la suggestion)

C'est de l'ingénierie produit invisible — le freelance lambda ne demande pas explicitement "je veux des règles persistantes avec confidence". Mais après 3 mois, il voit l'effet : son relevé mensuel se classe tout seul.

Le moment où on s'en rend compte

Mois 4 typique : vous uploadez votre relevé d'avril. L'app montre "47 transactions, 44 auto-matchées en utilisant 31 règles apprises, 3 à classer".

Vous classifiez les 3 en 1 minute. C'est fini.

Vous vous souvenez avoir passé 1h30 le mois 1. Vous réalisez que vous venez de gagner 15-20 heures par an rien que sur la réconciliation bancaire.

C'est exactement le genre de bénéfice qu'on ne peut pas voir dans une démo de 5 minutes — mais qui devient évident au bout de 90 jours d'usage régulier.