Agents IA comptabilité : les 3 limites du RPA résolues
Date de publication :
25.05.2026
Nicolas Marchais est co-fondateur et CEO de Phacet. Après sept ans chez Spendesk, il co-fonde Phacet en 2024 : une couche agentique qui orchestre entre ERP, banque et email. Fiable, auditable, cross-system, ce que Nicolas appelle une Finance Workforce.
La plupart des équipes comptables qui ont adopté du RPA entre 2018 et 2024 se sont prises le même mur autour de la deuxième année. Les scripts marchent brillamment sur les 70 % de factures qui arrivent dans un format propre et prévisible. Ils cassent silencieusement sur les 30 % qui ne le sont pas. Un nom fournisseur avec une faute de frappe. Un libellé de centre de coût qui a dérivé. Un rapprochement bancaire où le champ référence était vide. Chaque exception déclenche une revue manuelle, et au bout d'assez d'exceptions, le contrôleur fait 80 % du travail que le RPA était censé éliminer.
Ce n'est pas un échec d'exécution. Le RPA a été conçu pour une classe de problèmes précise (tâches répétitives déterministes sur inputs structurés) et il résout bien cette classe. La charge comptable qui a cassé le RPA, c'est la partie qui exige de raisonner sur la variabilité, de traverser plusieurs systèmes, ou de produire une piste d'audit défendable par un expert-comptable. Selon l'analyse Informatica sur l'agentic automation, Gartner anticipe que plus de 60 % des projets IA manqueront leurs SLA business d'ici 2026 par manque de pratiques data prêtes pour l'IA. Le chiffre est un symptôme : la plupart des équipes comptables greffent des outils IA sur des pipelines qui n'ont jamais été restructurés pour les utiliser.
Les agents IA pour la comptabilité ne remplacent pas votre RPA. Ils se posent par-dessus, couvrant les trois catégories de travail là où le RPA ne peut structurellement pas atteindre : la variabilité sémantique, l'orchestration cross-systèmes, et la piste d'audit native. La trajectoire plus large de cette transition est documentée dans notre analyse agents IA et automatisation comptable 2026. Cet article cartographie chacun de ces trois gaps, les patterns de travail où ils se manifestent dans une équipe comptable, et la bascule architecturale qui les ferme.
Pourquoi "agents IA" n'est pas juste du RPA avec un moteur plus malin
Une formulation courante dans le marketing des éditeurs positionne les agents IA comme la génération suivante du RPA : même pipeline, cerveau plus intelligent. Cette formulation est trompeuse. Les agents IA changent quel type de travail peut être automatisé, pas seulement à quelle vitesse le même travail tourne.
Un agent IA est une entité logicielle spécialisée avec un objectif défini, la capacité d'agir à travers plusieurs systèmes, et une façon structurée d'exposer son raisonnement. Il ne fait pas juste tourner un script. Il lit le contexte, applique du jugement dans un seuil de confiance, et fait remonter son travail pour revue humaine quand le seuil n'est pas atteint. L'architecture est fondamentalement différente du RPA sur trois aspects qui comptent pour la comptabilité. La distinction compte en pratique : un agent intelligent n'est pas une application SaaS avec des features IA greffées, c'est une catégorie de logiciel différente.
Le RPA exécute des instructions. Les agents exécutent une intention. Un script RPA à qui on dit "récupère le numéro de facture dans la cellule B7 du corps de l'email" plante quand le corps de l'email change de layout. Un agent à qui on dit "trouve le numéro de facture" lit le document, le reconnaît, l'extrait, et continue même si le layout est nouveau.
Le RPA tourne dans un seul système. Les agents agissent à travers les systèmes. Un bot RPA qui traite des factures dans votre outil AP ne vérifie pas si l'attestation URSSAF du fournisseur a expiré dans le master fournisseur, ne valide pas le RIB contre le contrat, ne croise pas le montant contre le bon de commande original. Un agent qui porte le job "valider une facture" fait tout cela en une seule opération.
Le RPA produit des logs. Les agents produisent des pistes d'audit. Un log d'exécution RPA dit "étape 14 réussie à 10h32:17". Une piste d'audit native dit "cette facture a été rapprochée à la commande 2026-0451 avec 94 % de confiance sur la base du nom fournisseur, des lignes et du montant ; les 6 % d'incertitude viennent d'un libellé de ligne qui ne matchait pas exactement ; l'agent l'a flagguée pour revue ; le contrôleur a validé à 10h32." Le premier satisfait un administrateur système. Le second satisfait un commissaire aux comptes.
C'est ce qui distingue une plateforme agentique d'une bibliothèque de scripts. La plateforme rend les agents fiables en production via la donnée partagée, l'observabilité, la piste d'audit, les contrôles humain dans la boucle, et les mécanismes de fallback.
Problème 1 : variabilité sémantique (là où le RPA cale silencieusement)
Le premier gap est le plus visible opérationnellement. Un fournisseur appelé "Acme Logistique SARL" sur l'en-tête de facture, "ACME LOGISTIQUE" sur le relevé bancaire, et "Acme Log." dans l'objet d'email, c'est le même fournisseur pour un comptable humain. Pour un script RPA, ce sont trois chaînes de caractères différentes qui échouent à une condition de match exact.
L'équipe comptable apprend à vivre avec. La routine de rapprochement flag les trois enregistrements comme non-rapprochés. Un junior ouvre chacun, reconnaît le pattern, et unifie manuellement. À la fin du mois, l'équipe a fait des milliers de ces reconnaissances, chacune rapide, chacune banale, et collectivement responsables de la majorité du backlog de rapprochement.
Les agents IA ferment ce gap parce que le matching sémantique, c'est ce que les large language models font nativement. L'agent contrôle de la facturation fournisseur reconnaît que "Acme Logistique SARL" et "ACME LOGISTIQUE" sont le même fournisseur sans qu'on le lui dise explicitement. L'agent rapprochement bancaire rapproche un paiement du relevé bancaire à une facture en attente dans l'ERP même quand les champs de référence ne s'alignent pas exactement. L'agent standardisation et reclassification maintient une codification cohérente sur un portefeuille de clients même quand la donnée source dérive.
Astotel -- 18 hôtels, détection d'écarts ligne à ligne
Les contrôles d'écart de prix ligne à ligne ont récupéré 5 000 euros par an sur un seul fournisseur. L'écart est devenu visible uniquement parce que l'agent pouvait reconnaître le même produit à travers des factures qui utilisaient des libellés légèrement différents. Les erreurs étaient toujours là. Le RPA ne pouvait pas les voir parce que les libellés variaient dans le dataset. L'agent le pouvait.
"Je gagne jusqu'à deux jours par mois, et je repère des erreurs que je n'aurais jamais vues seule." -- Valérie, Directrice Achats
C'est la source la plus large d'amélioration opérationnelle quand une équipe comptable passe au-delà du RPA. Le travail qui exigeait de la reconnaissance de pattern humaine (les 30 % de factures qui cassaient le script) devient du travail que l'agent traite, avec des exceptions qui remontent pour revue humaine.
Problème 2 : orchestration cross-systèmes (là où le RPA s'arrête à la frontière)
Le deuxième gap est architectural. Le travail comptable traverse les systèmes par nature. Une seule validation de facture exige de toucher l'outil AP (la facture), l'ERP (le bon de commande), la banque (le RIB fournisseur), le master fournisseur (les attestations URSSAF et assurances), le dépôt de contrats (les tarifs négociés), et parfois la boîte mail (la communication d'origine du fournisseur). Chaque système détient une partie de la vérité.
L'architecture RPA est intra-système. Un bot vit à l'intérieur d'une seule application et automatise les actions humaines à l'intérieur de cette application. Traverser vers un autre système exige soit une intégration API (qui n'existe pas toujours), soit un deuxième bot dans le deuxième système (qui double la maintenance), soit un screen scraping fragile qui casse quand l'UI change. La plupart des équipes comptables qui ont démarré avec du RPA ont fini avec un portefeuille de bots qui traitent chacun une slice d'un workflow, et un contrôleur qui recoud les slices à la main.
Les agents IA ferment ce gap parce que les agents sont conçus pour agir à travers les systèmes nativement. L'agent Inbox factures fournisseurs lit l'email, extrait la facture, interroge l'ERP pour la commande correspondante, vérifie le contrat pour le tarif négocié, valide le RIB contre le master fournisseur, et route le résultat. Tout en une seule opération. Pas de couture humaine.
La raison architecturale pour laquelle ça compte : les plateformes agentiques se positionnent par-dessus la stack existante, pas à l'intérieur d'un outil. Phacet opère spécifiquement comme une couche qui orchestre entre les systèmes déjà en place (Pennylane, Sage, NetSuite, Cegid, Yooz, Qonto, BNP, etc.) plutôt qu'en remplacement de l'un d'eux. Migrer vers un nouvel ERP coûte plusieurs centaines de milliers d'euros. Une couche d'orchestration ajoutée par-dessus se déploie en quelques semaines.
Le pattern cross-systèmes est aussi ce qui rend les plateformes agentiques réellement différentes d'un assistant IA généraliste comme ChatGPT ou Claude. Les assistants sont intelligents sur une requête unique. Ils ne sont pas connectés à votre stack finance, ne produisent pas de piste d'audit, et la donnée que vous leur fournissez peut être utilisée pour entraîner la version suivante du modèle. Une plateforme agentique adresse les trois.
Problème 3 : piste d'audit native (là où les logs RPA ne suffisent pas)
Le troisième gap, c'est celui dont se soucient les auditeurs et les responsables conformité. Le RPA produit des logs d'exécution : une liste d'étapes, des horodatages, des flags succès ou échec. Les logs sont utiles à un administrateur système qui débugge un script. Ils ne sont pas utiles à un expert-comptable qui défend les comptes face à un commissaire aux comptes, à une équipe d'audit interne qui fait un walkthrough Sapin II, ou à un contrôleur qui répond à la question "pourquoi cette facture a-t-elle été validée ?".
Une piste d'audit défendable capture non seulement ce qui s'est passé mais pourquoi ça s'est passé : les inputs que le système a considérés, la comparaison qu'il a faite tourner, le seuil qu'il a appliqué, le score de confiance qu'il a produit, l'humain qui a revu, l'override (le cas échéant) et sa justification. Ce niveau d'explicabilité est structurellement hors de ce que le RPA produit, parce que le RPA ne raisonne pas. Il exécute.
La piste d'audit native est ce qui rend les plateformes agentiques défendables en contextes régulés. Chaque action d'agent (chaque extraction, chaque rapprochement, chaque flag, chaque décision de routage) est horodatée, stockée et inspectable dans la Vue Détail par enregistrement. Un expert-comptable peut ouvrir n'importe quelle facture et voir la chaîne de raisonnement complète. Un commissaire aux comptes peut faire tourner un échantillon de 50 transactions et vérifier chacune en quelques secondes. Le responsable conformité pour la Loi Sapin II, le RGPD, l'ISO 27001, le PCG, le FEC, ou les normes sectorielles a la trace de preuves dont il a besoin sans reconstruction manuelle. Pour la défense face à un contrôle fiscal, le FEC immédiatement remontable depuis la piste d'audit native est un atout décisif.
Pour une fonction finance sous pression réglementaire, c'est le critère qui fait passer les agents IA de "amélioration intéressante" à "architecture non négociable". C'est aussi ce qui distingue les plateformes purpose-built finance des assistants IA généralistes, qui produisent des réponses remarquables mais aucune piste d'audit.
À quoi ressemble le travail comptable quand les 3 gaps sont fermés
Une vue pratique d'un workflow comptable qui a basculé du RPA à l'exécution agentique :
Ce n'est pas du RPA plus rapide. C'est une architecture de workflow différente, où l'agent fait le travail que le contrôleur faisait, et le contrôleur fait le travail que l'agent ne peut pas (le jugement sur les cas réellement ambigus). Le pattern observé en production chez les clients Phacet : 38 % des projets en production sont des agents de contrôle et de fiabilisation. C'est le moat, et c'est là que le modèle opérationnel bascule. Le tableau complet de cette transition est cartographié dans notre analyse équipe finance autonome.
Comment décider quels processus migrer en premier
Une question fréquente des équipes comptables qui envisagent la bascule : quels processus migrer en premier ? Le framework de décision a trois filtres.
Filtre 1 : variabilité des inputs. Les processus qui traitent des inputs très structurés et stables (un postage de paie mensuel fixe, un paiement de loyer récurrent) tournent bien en RPA et ne bénéficient pas beaucoup de la migration. Les processus à forte variabilité d'inputs (factures fournisseurs, notes de frais, transactions bancaires, portefeuilles multi-clients) sont ceux où les agents IA délivrent une amélioration immédiate. Commencer là.
Filtre 2 : amplitude cross-systèmes. Les processus contenus dans un seul système (une écriture postée depuis un template) sont compatibles RPA. Les processus qui traversent les systèmes (une facture qui exige un matching commande, une validation master fournisseur, et une vérification contrat) sont le territoire des agents. Migrer les processus cross-systèmes en premier.
Filtre 3 : pression d'audit. Les processus que le commissaire aux comptes revoit en détail (reconnaissance du revenu, flux intercompany, provisions de clôture) bénéficient de pistes d'audit natives. Les processus opérationnels et rarement audités peuvent rester en RPA. Migrer les processus à pression d'audit forte en premier parce que la piste d'audit est là où la valeur compose.
En combinant les trois filtres : le traitement des factures fournisseurs, le rapprochement bancaire, la recatégorisation multi-clients, le rapprochement intercompany, et les contrôles de facturation pilotés par contrat sont les premières migrations typiques. Les postages de paie, les loyers récurrents, et les écritures sur template peuvent rester en RPA.
CPA -- Cabinet d'expertise comptable
CPA a déployé la plateforme progressivement sans arracher leur outillage existant. Le cabinet opère désormais avec une nouvelle ligne de revenus construite autour du déploiement et 2 à 4 points de marge gagnés qu'ils communiquent à leurs propres clients. CPA n'a pas remplacé sa stack. Ils ont ajouté une couche d'orchestration là où les gaps étaient.
"C'est comme un tableau Excel dopé à l'IA. On n'est pas dépaysés." -- Romain Joussellin, associé chez CPA
Comment les agents Phacet rendent cette architecture concrète
Phacet opère comme un catalogue de 40+ agents spécialisés pour le travail finance, construits sur 100+ déploiements clients réels. Chaque agent suit la même structure : il structure l'input (extrait et normalise la donnée des emails, ERP, contrats, flux bancaires), contrôle contre une référence (master fournisseur, contrats, périodes antérieures, budgets), et expose son raisonnement avec un score de confiance. Chaque étape est horodatée dans une piste d'audit native. La combinaison rend le travail fiable, contrôlable et auditable par design.
Les agents les plus pertinents pour une équipe qui passe au-delà du RPA :
- L'agent Inbox factures fournisseurs remplace le tri d'email RPA qui échouait systématiquement sur la variation de layout.
- L'agent contrôle de la facturation fournisseur fait le contrôle d'écart de prix ligne à ligne que le RPA ne pouvait pas faire parce que les libellés de ligne variaient.
- L'agent rapprochement bancaire gère le matching sémantique que les règles RPA en match exact ne peuvent pas faire.
- L'agent standardisation et reclassification impose une codification cohérente sur les portefeuilles, là où les scripts RPA devaient être réécrits pour chaque client.
Chaque agent fait remonter ses résultats dans les Tables (une vue tableur où chaque ligne est une transaction avec ses documents source, ses champs extraits, l'indicateur de confiance, et l'historique d'audit). Quand un agent est en dessous du seuil, le composant AI Match fait remonter le rapprochement proposé avec son raisonnement dans la Vue Détail. Les 40+ agents du catalogue ont été construits sur 100+ déploiements clients réels -- ils reflètent les patterns qui cassaient le RPA dans de vraies équipes comptables, pas des features conçues pour une page de produit.
Le premier agent passe en production en moins de deux semaines. La migration complète au-delà du RPA (variabilité sémantique, orchestration cross-systèmes, piste d'audit native) prend typiquement un à trois trimestres selon la stack existante et la propreté de la master data. Phacet n'exige pas de remplacer le RPA. Les deux coexistent : le RPA gère les patterns déterministes pour lesquels il a été conçu, et les agents gèrent les patterns qui le cassaient.
Pourquoi la plupart des projets "IA comptable" sous-livrent encore
L'analyse Informatica citant Gartner rapporte que plus de 60 % des projets IA manqueront leurs SLA business d'ici 2026, et 97 % des adopteurs GenAI peinent à prouver la valeur business. Le pattern est cohérent à travers les enquêtes : l'adoption IA est rapide, la capture de valeur IA est lente.
Trois raisons structurelles expliquent le gap, et les trois sont accentuées en comptabilité :
La donnée n'est pas prête pour l'IA. Le PCG, le master fournisseurs et l'historique de codification d'une équipe comptable sont remplis d'incohérences que l'équipe a contournées manuellement pendant des années. Un agent IA hérite de ces incohérences à moins que la donnée sous-jacente ne soit nettoyée. L'agent standardisation et reclassification adresse cela spécifiquement, mais il doit tourner avant ou en parallèle des autres agents, pas après.
Le workflow n'est pas redessiné. La plupart des équipes déploient l'IA par-dessus le workflow existant. L'agent tourne plus vite mais produit le même pattern de sortie, ce qui veut dire que l'équipe fait toujours les mêmes handoffs et revues. Le gain vient du redesign du workflow autour de l'agent (le contrôleur revoit les exceptions, pas les transactions), pas de l'ajout de l'agent au flow existant.
La piste d'audit est traitée en bout de chaîne. Les équipes découvrent à leur premier audit que leur outil IA ne produit pas de trace défendable. Elles rétro-fittent la piste, ce qui est cher et incomplet. La piste d'audit native dès le jour 1 est ce qui rend le projet pérenne au-delà du pilote.
Les équipes qui passent au-delà du taux d'échec de 60 % résolvent les trois : donnée prête pour l'IA, workflow redessiné, piste d'audit native. C'est le changement de modèle opérationnel qui distingue un déploiement agentique réussi d'un outil supplémentaire ajouté à la stack.
Foire aux questions
Qu'est-ce que les agents IA pour la comptabilité, en une phrase ?
Les agents IA pour la comptabilité, c'est l'usage d'agents IA spécialisés qui agissent à travers les systèmes qu'une équipe comptable utilise déjà (ERP, banque, email, contrats), chacun portant un job défini, exposant son raisonnement, et produisant une piste d'audit native. C'est distinct du RPA (qui exécute des scripts dans un seul système) et des assistants IA généralistes (qui donnent des réponses mais ne se connectent pas aux systèmes finance et ne produisent pas de piste d'audit). Voir notre entrée glossaire sur l'agent IA pour la définition de la brique de base.
Quelle est la différence entre agents IA et RPA dans le travail comptable ?
Le RPA exécute des scripts déterministes sur des inputs structurés dans un seul système. Il marche pour 70 % du travail comptable routinier et casse sur les 30 % qui ont de la variabilité sémantique, de l'amplitude cross-systèmes, ou de la complexité d'audit. Les agents IA gèrent la couche sémantique et contextuelle (matcher quand les libellés varient, raisonner quand le contexte change, orchestrer à travers les systèmes), avec une piste d'audit native que le RPA ne produit pas. Les deux sont complémentaires : le RPA reste pour les processus déterministes, les agents prennent le relais là où le RPA cassait. Notre analyse au-delà du RPA décompose les différences architecturales plus en détail.
Faut-il arracher mon RPA existant pour déployer des agents IA ?
Non. Les agents IA se posent par-dessus la stack existante comme une couche d'orchestration. Phacet opère spécifiquement comme un catalogue d'agents qui s'intègrent aux systèmes déjà en place (Pennylane, Sage, NetSuite, Cegid, Yooz, Qonto, BNP, etc.) plutôt qu'en remplacement. Le RPA continue de gérer les patterns déterministes pour lesquels il a été conçu. Les agents gèrent les patterns sémantiques et cross-systèmes qui cassaient le RPA.
Quels processus comptables migrer en premier ?
Trois filtres guident la décision. Premièrement, les processus à forte variabilité d'inputs (factures fournisseurs, notes de frais, rapprochement bancaire) bénéficient le plus. Deuxièmement, les processus qui traversent plusieurs systèmes (une facture qui exige un contrôle commande, contrat et master fournisseur) sont le territoire des agents. Troisièmement, les processus que le commissaire aux comptes revoit en détail bénéficient de pistes d'audit natives. Les premières migrations typiques : traitement des factures fournisseurs, rapprochement bancaire, recatégorisation multi-clients, rapprochement intercompany.
Combien de temps prend un déploiement agents IA pour une équipe comptable ?
Le premier agent Phacet passe en production en moins de deux semaines. Une couverture significative des trois gaps RPA (sémantique, cross-systèmes, audit) prend typiquement un à trois trimestres, selon la stack existante et la propreté de la donnée sous-jacente. Le rythme n'est pas limité par les agents eux-mêmes mais par le travail amont de qualité de données et de redesign de workflow. Les équipes qui ont investi dans une master data propre déploient plus vite.
Les agents IA sont-ils plus risqués que le RPA côté conformité ?
Bien déployés, ils sont moins risqués. Le RPA produit des logs d'exécution qui ne sont pas de niveau audit. Les agents IA produisent une piste d'audit native avec raisonnement, scores de confiance, et historique de revue humaine. Pour la Loi Sapin II, le RGPD, l'ISO 27001, le PCG, le FEC, et les normes sectorielles, la piste d'audit agentique est ce qui rend le travail automatisé défendable. Pour la supervision de l'Ordre des Experts-Comptables et la doctrine du CSOEC, c'est aussi ce qui rend la production cabinet inspectable. Le profil de risque est plus bas que celui du RPA en contextes régulés, pas plus haut.
La question "agents IA contre RPA" cadre le choix de travers. Le RPA marche toujours pour le travail déterministe mono-système à faible pression d'audit pour lequel il a été conçu. Les agents IA ne le remplacent pas. Ils couvrent les trois catégories de travail que le RPA ne pouvait structurellement pas atteindre : variabilité sémantique, orchestration cross-systèmes, piste d'audit native. Ensemble, ils couvrent toute l'amplitude du travail comptable qu'un contrôleur humain faisait.
Les équipes qui tirent le plus de valeur de cette bascule font trois choses dans l'ordre. Elles identifient les processus où les trois gaps mordent le plus fort (typiquement factures fournisseurs, rapprochement bancaire, portefeuilles multi-clients). Elles déploient des agents sur ces processus en premier, avec le RPA existant qui continue de tourner sur les patterns déterministes. Et elles redessinent le workflow pour que le rôle du contrôleur bascule du traitement de transactions vers la revue d'exceptions et la propriété de la politique.
Phacet opère exactement dans cette couche. Les 40+ agents IA spécialisés couvrent le travail sémantique, cross-systèmes et lié à la piste d'audit qui définit la comptabilité au-delà du RPA. Chacun est en production chez de vrais clients. Le premier agent passe en production en moins de deux semaines. La transition complète à travers les trois gaps prend un à trois trimestres. La vision stratégique derrière cette transition est exposée dans notre analyse révolution agentique de l'automatisation finance.
Au-delà du RPA n'est pas la génération suivante de l'automatisation. C'est le travail que la génération précédente ne pouvait pas atteindre. Les équipes qui y arrivent en premier feront le même travail comptable avec 38 % de leur portefeuille d'agents dédié au contrôle et à la fiabilisation, qui est exactement là où la valeur compose.
Dernières ressources
Débloquez votre potentiel avec l'IA
Exploitez davantage vos ressources existantes grâce à des solutions d'IA personnalisées.
