Dans une fonction finance, l’IA a du sens là où il faut lire, classer ou rédiger à partir de données variables : factures reçues, libellés bancaires ambigus, premiers commentaires d’écarts. Tout ce qui est calcul, rapprochement sur des clés connues ou contrôle de cohérence relève d’abord du code, parce qu’on attend du chiffre qu’il soit juste et reproductible. Enfin, chaque fois qu’une écriture, un paiement ou un message à la direction engage l’entreprise, la décision reste humaine. La bonne question n’est donc pas « l’IA peut-elle faire notre clôture ? », mais « quelle étape de notre clôture relève de quoi ? ».
Pourquoi la finance est un bon terrain pour trier
On ne considère pas la finance comme un domaine à part. Les mêmes problèmes se retrouvent en ADV, aux achats ou au service client : du travail qui se fait entre les outils, dans des fichiers Excel, avec des règles que deux ou trois personnes connaissent vraiment. Mais la finance rend le tri particulièrement visible, pour deux raisons.
D’abord, ses processus sont nombreux, répétitifs et déjà en partie écrits : un calendrier de clôture, des procédures de contrôle, un plan de comptes. On part rarement de rien. Ensuite, l’erreur y coûte cher et se voit : un chiffre faux dans un reporting ou un paiement en double ne passe pas inaperçu longtemps. Cette exigence oblige à faire ce qu’on devrait faire partout : décider, étape par étape, ce qui doit être déterministe, ce qui peut être probabiliste et ce qui doit rester sous la responsabilité d’une personne.
Notre grille générale est détaillée dans la ressource sur le choix entre code, IA ou validation humaine. En résumé :
- Code : la règle peut s’écrire et doit donner le même résultat à chaque exécution (calculs, rapprochements sur référence, contrôles de seuils, contrôles de complétude).
- IA : l’entrée varie trop pour être codée proprement (documents hétérogènes, texte libre, libellés imprécis) ou la sortie est un texte à rédiger.
- Humain : la décision engage l’entreprise, demande un jugement ou tranche une exception que la règle ne couvre pas.
Processus par processus : ce qui s’automatise et ce qui reste humain
Le tableau ci-dessous est une grille de départ. Il décrit des cas typiques de PME et d’ETI ; votre propre répartition dépendra de vos outils, de vos volumes et de vos exceptions.
| Processus | Ce que le code fait bien | Ce que l’IA peut apporter | Ce qui reste humain |
|---|---|---|---|
| Rapprochement bancaire | Lettrage sur montant, date et référence ; règles de tolérance ; liste des suspens | Proposer un rapprochement quand le libellé est imprécis ou le paiement groupé | Valider les propositions incertaines, traiter les suspens anciens |
| Traitement des factures fournisseurs | Contrôle de doublons, rapprochement commande / réception / facture, calcul de TVA | Lire les factures non structurées, extraire les champs, proposer une imputation | Valider les écarts, les nouveaux fournisseurs, le bon à payer |
| Contrôles de cohérence | Balances, variations au-delà d’un seuil, comptes d’attente non soldés | Regrouper et expliquer les anomalies dans un langage lisible | Décider si une anomalie est une erreur ou une réalité économique |
| Clôture mensuelle | Suivi des tâches, calcul des provisions à partir de règles, écritures récurrentes | Préparer des brouillons de justification, relancer les contributeurs avec le bon contexte | Estimations, cut-off discutables, validation des écritures d’inventaire |
| Reporting | Extraction, consolidation, calcul des indicateurs, mise en forme | Rédiger une première version des faits marquants | Choisir ce que l’on dit à la direction et comment on le dit |
| Commentaires d’écarts | Calculer les écarts et identifier ceux qui dépassent un seuil | Proposer une explication à partir des données sous-jacentes et des commentaires passés | Confirmer la cause réelle, qui se trouve souvent hors des données |
| Prévision de trésorerie | Intégrer échéances clients et fournisseurs, paie, fiscalité, emprunts | Signaler les dérives de délais de paiement, préparer des scénarios | Hypothèses d’activité, arbitrages de financement, décisions de paiement |
Trois observations ressortent quand on lit ce tableau en ligne.
Le code porte la plus grande partie du travail. Dans la plupart des processus finance, l’essentiel de ce qui prend du temps n’a rien d’intelligent : extraire, recopier, recouper, vérifier un seuil. Un script bien écrit le fait sans variation, et on peut l’auditer. Recourir à un modèle d’IA pour additionner des colonnes ou lettrer des montants identiques, c’est introduire de l’incertitude là où il n’y en avait pas.
L’IA intervient aux frontières. Elle est utile à l’entrée du processus, quand les documents arrivent dans des formats variés, et à la sortie, quand il faut rédiger. Au milieu, elle peut proposer, mais ses propositions doivent être contrôlées par des règles ou par une personne.
La part humaine ne disparaît pas, elle change de nature. Le contrôleur de gestion passe moins de temps à produire l’écart et plus de temps à le comprendre. C’est souvent là qu’est le vrai gain, bien plus que dans le temps économisé.
Deux exemples de découpage
Prenons un exemple illustratif : le traitement des factures fournisseurs dans une entreprise qui reçoit encore beaucoup de PDF par e-mail. Un découpage raisonnable ressemble à ceci :
- Réception (code) : les pièces jointes sont récupérées dans une boîte dédiée et enregistrées avec leur date de réception.
- Lecture (IA) : un modèle extrait fournisseur, numéro, dates, montants et lignes. Il signale les champs qu’il n’a pas pu lire avec certitude.
- Contrôles (code) : le fournisseur existe-t-il ? La facture est-elle un doublon ? Les montants HT, TVA et TTC sont-ils cohérents ? Correspond-elle à une commande et à une réception ?
- Proposition d’imputation (IA, sous règles) : à partir de l’historique du fournisseur, le système propose un compte et un axe analytique ; une règle bloque toute proposition hors des comptes autorisés.
- Validation (humain) : les factures conformes passent en validation groupée ; les autres arrivent dans une file d’exceptions avec la raison du blocage.
- Paiement (humain) : le bon à payer reste une décision humaine, dans le respect des délégations existantes.
Ce type de flux est détaillé dans notre ressource sur la dématérialisation des factures, qui aborde aussi le lien avec la réforme de la facturation électronique.
Second exemple illustratif : les commentaires d’écarts du reporting mensuel. Le code calcule les écarts par rapport au budget et au mois précédent, puis ne retient que ceux qui dépassent un seuil défini par le contrôle de gestion. L’IA reçoit, pour chaque écart retenu, le détail des écritures et les commentaires des mois passés, et propose une explication rédigée en indiquant sur quelles données elle s’appuie. Le contrôleur corrige, complète avec ce qu’il sait et que les données ignorent (un client perdu, un retard de chantier), puis valide. Le texte final est le sien.
Les risques propres à la finance
Ces risques ne sont pas une raison de renoncer. Ils définissent ce qu’un système doit garantir.
La fiabilité du chiffre
Un modèle de langage produit une réponse plausible, pas une réponse garantie. Il peut inventer un montant, mal additionner ou citer une ligne qui n’existe pas. En finance, la règle qui en découle est simple : aucun chiffre ne doit être produit par l’IA elle-même. Les chiffres viennent des systèmes sources et des calculs codés ; l’IA peut les lire, les commenter ou les classer, et chaque chiffre qu’elle cite doit pouvoir être rapproché automatiquement de sa source.
La piste d’audit
Il faut pouvoir reconstituer, pour chaque écriture ou chaque commentaire : d’où viennent les données, quelle règle ou quelle proposition de l’IA a été appliquée, qui a validé et quand. Un traitement qui se passe dans une conversation ChatGPT puis un copier-coller dans Excel ne laisse aucune de ces traces.
La séparation des tâches
L’automatisation ne doit pas contourner les principes de contrôle interne. Si la même personne pouvait déjà créer un fournisseur et payer ses factures, l’automatisation n’arrangera rien ; mais un système mal conçu peut aussi créer ce problème, par exemple en donnant à un même compte technique le droit de saisir et de valider. Les droits du système doivent être pensés comme ceux d’un collaborateur.
Les données sensibles
Salaires, coordonnées bancaires, marges par client, prévisions non publiées : la finance manipule une grande partie des données les plus sensibles de l’entreprise, dont certaines sont des données personnelles soumises au RGPD. Avant de les faire passer par un service d’IA, il faut savoir où elles sont traitées, si elles sont conservées et qui peut y accéder. Notre approche est décrite dans la page sur la sécurité et les données.
L’usage non encadré d’outils grand public
C’est souvent le risque le plus présent, et le moins visible. Des collaborateurs utilisent déjà des assistants conversationnels grand public pour reformuler un commentaire, analyser un export ou écrire une formule. L’intention est bonne, mais le résultat échappe à tout contrôle : données copiées dans un outil dont on ne connaît pas les conditions, réponses non vérifiées reprises dans un document officiel, aucune trace de ce qui a été fait. Interdire ne suffit généralement pas. Il vaut mieux fixer des règles simples (quelles données ne sortent jamais, quels usages sont admis, quel outil est fourni) et construire des outils encadrés pour les usages récurrents.
Ce qu’il faut exiger avant de confier un chiffre à un système
Avant de mettre en production un traitement qui touche à un chiffre, voici les questions que nous posons nous-mêmes. Si l’une d’elles reste sans réponse claire, le système n’est pas prêt.
- Origine : chaque chiffre affiché vient-il d’un système source identifié, et non d’une génération par l’IA ?
- Reproductibilité : relancer le traitement sur les mêmes données donne-t-il le même résultat pour tout ce qui est calcul ?
- Seuils de confiance : que se passe-t-il quand l’IA n’est pas sûre ? La pièce part-elle en exception ou passe-t-elle silencieusement ?
- Traçabilité : peut-on retrouver, pour une écriture donnée, les données d’entrée, la règle appliquée, la proposition de l’IA et le nom du valideur ?
- Droits : le système peut-il seulement proposer, ou peut-il aussi valider ? Ses droits respectent-ils la séparation des tâches ?
- Tests : a-t-il été testé sur des cas réels, y compris les exceptions connues (avoirs, acomptes, paiements groupés, devises) ?
- Surveillance : qui regarde les erreurs après la mise en service, et à quelle fréquence ?
- Retour arrière : si le système s’arrête, l’équipe sait-elle reprendre le traitement à la main ?
Où commencer, et quand ce n’est pas le bon moment
Le meilleur point de départ est rarement le plus spectaculaire. Un processus fréquent, avec des règles assez stables et un coût en temps bien identifié (rapprochements, contrôles de clôture, traitement des factures) apprend davantage qu’un projet de prévision sophistiqué.
Il y a aussi des situations où il vaut mieux attendre ou choisir autre chose :
- si un module de votre ERP ou un logiciel spécialisé fait déjà correctement le travail et qu’il suffit de le paramétrer, c’est souvent la voie la plus simple ;
- si le processus change en profondeur (changement d’ERP, réorganisation), automatiser l’ancien fonctionnement a peu de sens ;
- si les données de base sont peu fiables (plan de comptes instable, référentiel fournisseurs en désordre), le premier chantier est de les remettre en ordre ;
- si le volume est faible, quelques heures par mois, le gain ne justifiera pas toujours la construction et le suivi d’un système.
Pour aller plus loin
Si vous voulez appliquer cette grille à un processus précis, la ressource sur la clôture comptable la décline étape par étape, et celle sur le tableau de bord financier montre comment fiabiliser le reporting en amont. Si votre processus mêle plusieurs outils, beaucoup d’exceptions et un savoir que peu de personnes détiennent, la cartographie de processus sert précisément à décider ce qui relève du code, de l’IA ou d’une validation humaine avant de construire.