Article
L’IA en finance d’entreprise : quoi automatiser et quoi ne pas confier au modèle
Après une douzaine de déploiements dans la finance de PME, j’ai une règle simple : le modèle de langage reçoit ce qui consiste à lire ; le code reçoit ce qui consiste à calculer ; l’humain garde ce qui consiste à répondre. Ci-dessous — ce que cela donne en pratique, avec trois exemples et une liste de choses à ne pas faire.
Auteur: Tomasz FordymackiPublié le:
Trois paniers : automatisé, jamais délégué, vérifié par l’humain
| Automatisé (code ou modèle) | Le modèle propose, l’humain vérifie un échantillon | Jamais confié au modèle |
|---|---|---|
| Charger un compte XML du registre et le réconcilier (actif = passif) | Classer les libellés d’écritures en postes de gestion | L’arithmétique — chaque multiplication dans du code, avec un test |
| Règles de contrôle des livres : TVA, délais, registre officiel, cours, soldes | Extraire des champs des contrats et factures (parties, montants, dates) | Retraitements d’EBITDA et pondérations des méthodes d’évaluation |
| Rapport, tableau de bord et présentation générés depuis un modèle | Une première version du commentaire de résultat (« ce qui a changé et pourquoi ») | Hypothèses de prévision et conclusion pour la direction |
| Répartition du temps de travail par client depuis l’export des tickets | Traduction du rapport dans une seconde langue (chiffres vérifiés par règle) | Données personnelles et salaires — restent dans une zone inaccessible au modèle |
Trois exemples de déploiements
- 1Un parseur de comptes du registre — huit sociétés avec une seule méthodeLes fichiers XML ont une structure unique mais trois variantes (petite entité, autre, micro) et des annexes différentes. Un script charge bilan, compte de résultat et flux, les réconcilie et calcule quatorze ratios en cinq modules avec notation. Pas de modèle de langage ici — du code pur, car la structure est connue. Effet : une analyse comparative d’une douzaine de sociétés en une heure au lieu d’une semaine ; mêmes ratios, même méthode, zéro ressaisie.
- 2Un contrôleur des livres pour un cabinet — cent règles au lieu de l’œilL’export du logiciel comptable, le plan de comptes et la politique comptable en entrée ; une centaine de règles (TVA et délais, contreparties contre le registre officiel, facturation électronique, cours de la banque centrale, comptes qui ne doivent jamais porter de solde) et plusieurs centaines de tests. Le modèle de langage n’apparaît qu’à un endroit : pour un libellé ambigu, il propose une classification que la comptable valide. Effet : erreurs visibles avant la clôture, la comptable travaille sur les exceptions, un tableau de bord pour le dirigeant du cabinet montre quelle société a échoué à quoi aujourd’hui.
- 3Un rapport de gestion depuis le modèle — un chiffre dans trois documentsUn script lit le modèle Excel (compte de résultat de gestion, répartition, trésorerie), construit un tableau de bord HTML, un rapport PDF et une présentation — en polonais et en français pour un propriétaire à l’étranger. Les contrôles de bouclage (somme des segments = compte de résultat, bilan équilibré) bloquent la publication si quelque chose ne colle pas. Le modèle de langage rédige la première version du commentaire « ce qui a changé » ; je le corrige et le signe. Effet : clôture du rapport d’une semaine à une heure, fini les trois versions de la même marge.
Pourquoi le modèle ne doit pas calculer
Un modèle de langage prédit le fragment de texte suivant. Pour « 2 × 3 » il prédira « 6 », l’ayant vu un million de fois ; pour « 7,96 + 14,75 actualisés à 11,3 % » il prédira quelque chose qui ressemble à un résultat — et se trompera de quelques pour cent de façon invisible. Dans une évaluation, quelques pour cent font des centaines de milliers. C’est pourquoi, dans mes outils, le modèle ne renvoie jamais un nombre destiné au rapport : il renvoie une classification, une proposition ou du texte, et du code testé fait le calcul. Ce n’est pas de la prudence — c’est la différence entre un outil et un risque.
Liste de contrôle avant déploiement
- Quel rapport unique consomme le plus d’heures ? Commencez par lui — pas par une « stratégie IA ».
- Les données entrent-elles par une seule passerelle avec validation et journal ? Sinon, la passerelle d’abord.
- Où sont les données personnelles et les salaires — et le modèle y accède-t-il ? Il ne doit pas.
- Quels contrôles peuvent s’écrire comme une règle testée ? Tous ceux-là vont dans le code, pas dans le modèle.
- Qui signe le résultat ? Si la réponse est « personne, c’est automatique », le déploiement n’est pas prêt.
- Y a-t-il un registre des pièges et une procédure d’actualisation ? L’outil doit survivre à son auteur.
Questions fréquentes
Quel modèle de langage ?
Pour lire des documents — Claude ; là où les données ne peuvent pas sortir — un modèle exécuté localement (Ollama). Le choix est secondaire par rapport à l’architecture : passerelle, zones, règles avant le modèle, code pour le calcul. Un modèle médiocre dans une bonne architecture fait moins de dégâts que le meilleur modèle dans une mauvaise.
Combien ça coûte et quand est-ce rentable ?
Un premier déploiement (un rapport, un export) représente deux à trois semaines de travail ; le coût des modèles de langage à cette échelle est négligeable — quelques dizaines de złoty par mois. Je compte le retour en heures d’équipe : un rapport d’une semaine à une heure, ce sont 30 à 40 heures par mois, soit un retour dès le premier trimestre. Je ne publie pas de tarifs — périmètre et prix découlent d’un échange.
Est-ce conforme au RGPD ?
Oui, si l’architecture l’est : données personnelles dans une zone inaccessible au modèle, identifiants pour l’analyse, modèle externe ne recevant que du contenu anonymisé, contrat de sous-traitance là où il est exigé. C’est une condition pour que j’accepte le déploiement — pas une option à activer plus tard.
Parlons de votre situation
Écrivez quelques phrases sur la société et le problème. Je réponds sous deux jours ouvrés et le premier échange est gratuit.
M’écrire