À l'ère de l'IA, quel logiciel de gestion sera encore là dans cinq ans ?

Je n’ai pas ouvert mon ERP (Odoo) ce matin. Hier non plus, et je crois que la dernière fois remonte à la semaine dernière, pour vérifier une facture. Pourtant toute la gestion de mes sociétés est dedans : les ventes, les achats, les banques, la comptabilité. Quand j’arrive le matin, la trésorerie, le compte de résultat et l’activité de chaque société sont déjà à jour, visibles dans mes propres interfaces, préparés par des agents d’IA avec des rôles et des règles que j’ai définis. Petit à petit, j’ai relégué Odoo au rang de system of record, c’est-à-dire la base où les données s’enregistrent. Une sorte de base de référence.

À l’ère de l’IA, le marché du logiciel de gestion d’entreprise bouge très vite. Des dizaines d’éditeurs lèvent des centaines de millions pour faire le travail de gestion des PME à leur place : Rillet 100 millions de dollars en août, Pennylane 175 millions d’euros en janvier. Les grands de l’IA arrivent aussi, Anthropic en mai avec des agents pour la finance, OpenAI en septembre avec une version de ChatGPT pour les métiers financiers. Tous ne survivront pas. Fin 2024, Bench, qui tenait la comptabilité de milliers de petites entreprises américaines, a fermé sans prévenir, et ses clients ont dû récupérer eux-mêmes leurs données. Un DAF n’a pas le choix d’attendre : il doit investir maintenant, sans savoir qui sera encore là dans cinq ans. Il peut en revanche comprendre ce marché avant d’y mettre de l’argent. Et ce qu’il y a à comprendre, c’est que les éditeurs n’abordent pas tous l’ère de l’IA de la même façon.

L’ERP ne disparaît pas, il passe au second plan

J’ouvre de moins en moins mon ERP, et je pense que ce comportement va se généraliser. La saisie va se faire par des agents, on ne la fera plus nous-mêmes. On posera la question à un agent, qui ira chercher la réponse ou fera le travail à notre place. On n’ouvrira donc plus ces interfaces très complètes, qui demandent des semaines pour savoir où cliquer, alors qu’un agent n’a pas besoin de cliquer. Mais l’ERP ne va pas mourir. Il va continuer à tourner et à enregistrer, et surtout il va faire foi sur tout l’historique (le legacy), c’est-à-dire les années d’écritures, de factures et de contrats que personne ne ressaisira ailleurs.

Prenons mon cas. Le matin, je demande à un agent où en est la trésorerie. Il lit les soldes dans Odoo et dans les banques, compare avec le plan et me signale les gros écarts. Je n’ai ouvert aucun écran, et pourtant tout vient d’Odoo.

Aux États-Unis, Salesforce, Workday et SAP ont bâti un marché de plusieurs milliers de milliards de dollars en devenant la source officielle d’un type de donnée, les clients, les salariés, les opérations. En France, Pennylane joue la même carte avec « la plateforme tout-en-un de gestion financière et comptabilité » des PME. Tous veulent rester l’endroit où la donnée s’enregistre, même si plus personne ne les ouvre.

Ce n’est pas la seule raison qui les fait passer au second plan. Leur deuxième lacune, c’est qu’ils enregistrent la donnée, donc la décision, mais pas sa raison. Quand on accorde une remise à un client, on la crée dans l’ERP, mais on n’enregistre nulle part ce qui l’a déclenchée : une livraison en retard, un geste pour garder le client, une négociation au téléphone. Six mois plus tard, la remise est toujours là et plus personne ne sait pourquoi. Ce qui manque, c’est ce qu’on appelle un graphe de contexte.

Ashu Garg, associé chez Foundation Capital, l’écrit très bien le 26 décembre 2025 : la raison d’une décision n’a jamais été traitée comme une donnée. La règle dit ce qui doit se passer en général, par exemple « dix pour cent de remise au maximum ». La trace dit ce qui s’est passé dans un cas précis et pourquoi on l’a autorisé, par exemple « vingt pour cent pour ce client, parce qu’il a subi trois pannes ce trimestre ». Reliées aux clients et aux personnes, ces traces forment un historique où l’on retrouve les précédents, et j’ai déjà écrit pourquoi je crois qu’il a raison.

Il relève quatre cas où la raison reste hors du logiciel, et les quatre existent chez moi. La raison restée dans ma tête : j’accorde une remise en une minute, et l’ERP reçoit un pourcentage sans aucune case pour « parce que la livraison a eu trois semaines de retard ». Le cas déjà vu : il y a deux ans, j’ai accepté un paiement en quatre fois pour un autre client dans la même situation, et rien dans l’ERP ne relie ces deux factures. L’information éclatée dans plusieurs logiciels : avant de trancher, j’ai regardé l’historique des paiements, ma messagerie et le plan de trésorerie, puis j’ai saisi le résultat dans un seul logiciel, l’ERP. Le oui donné hors du logiciel : le client a demandé la remise en visio, mon associé a dit oui sur WhatsApp, et quelqu’un a tapé le chiffre le lendemain. Le logiciel ne saura jamais qui a dit oui, ni pourquoi.

Est-ce que l’éditeur de l’ERP peut rattraper ça en ajoutant de l’IA à son logiciel ?

À mon avis non. Son logiciel reçoit le chiffre final, après coup. Le moment où la décision se prend, avec les trois écrans, la visio et le message, se passe avant la saisie et en dehors de lui. Un assistant posé sur l’ERP ne verra jamais que ce que l’ERP contient, c’est-à-dire le résultat.

Mais alors, quel type de logiciel va mettre la main sur ce « pourquoi » si stratégique ?

Première approche : les agents qui font le travail, les systems of agents

Qu’est-ce qu’un système d’agents ?

Un agent fait le travail d’un métier à la place de quelqu’un, posé sur le logiciel de référence sans le remplacer. Il lit le contrat, émet la facture, relance le client, rapproche l’encaissement. Il est donc là au moment où l’exception se décide, et il peut la garder, ce que Garg appelle un system of agents. Ses exemples sont dans le portefeuille de son fonds, il faut le lire en le sachant.

Deux Américains. Hyphenate, à New York, pose des agents de clôture, de trésorerie et de facturation au-dessus de NetSuite ou de SAP, sans migration. Elle a levé 9 millions de dollars en septembre 2025 et publie ses propres chiffres, une clôture passée de trois semaines à cinq jours chez un client. Sierra, à San Francisco, fait pareil pour le service client : ses agents prennent l’appel ou le mail et règlent le dossier jusqu’au paiement, avec plus de 150 millions de dollars de revenu récurrent déclarés en février 2026.

Deux Européens. Legora, à Stockholm, fait exécuter le travail juridique par ses agents chez Linklaters, et vaut 8,8 milliards de dollars depuis le 21 octobre 2026. Light, à Copenhague, vend six agents de finance qui codent les factures, rapprochent la banque et passent les régularisations de fin de mois, avec une réserve : ils tournent sur son propre grand livre, donc Light remplace l’ERP au lieu de se poser dessus.

En France, la plus connue des patrons de PME que je croise est Limova, une startup niçoise lancée en décembre 2024, dont le logo est sur le maillot de l’OGC Nice depuis cette saison. Ses agents répondent au téléphone, rédigent les e-mails et publient sur les réseaux, et son fondateur résume toute l’approche en une phrase : « On ne vend pas une IA qui parle. On vend une IA qui fait. » C’est le système d’agents sous sa forme la plus simple, l’automatisation d’un geste, sans logiciel de gestion derrière.

Pourquoi l’éditeur de l’ERP ne lance-t-il pas lui-même un système d’agents convaincant ? Odoo a des agents depuis sa version 19, sortie en septembre 2025 : ils répondent à partir des documents de l’entreprise, remplissent des champs et font des actions. Ce qui vaut pour Odoo vaut pour SAP et Salesforce, et ce n’est pas une question de talent, c’est une question de place. Un agent posé dans l’ERP voit ce que l’ERP contient, et il arrive après la saisie. Le moment de la décision, avec ses trois écrans, sa visio et son message, se passe en dehors de lui.

Reste à savoir si un système d’agents peut garder le « pourquoi ». Reprenons la remise. Quand c’est un agent qui l’accorde, il a sous les yeux, au moment de décider, tout ce que j’avais regardé moi-même avant de saisir : le contrat du client, ses trois incidents du trimestre, la remise accordée à un client comparable il y a deux ans, et la règle qui dit dix pour cent au maximum sauf problème de service. Rien ne l’empêche d’écrire tout ça à côté du chiffre : voilà ce que j’ai regardé, voilà la règle que j’ai appliquée, voilà qui a donné son accord. C’est la trace dont parle Garg, et quand les traces s’accumulent et se relient entre elles, par client, par règle et par date, on obtient la mémoire des décisions, le graphe de contexte. C’est pour ça qu’il dit que cette approche est la mieux placée : elle est là quand on décide, et l’ERP ne l’est pas.

Sur le marché, à ce jour, ce n’est pas ce qui se passe. Parmi les dix acteurs les plus avancés que j’ai regardés, un seul va dans ce sens. Hyphenate fait valider ses propositions par un comptable, et chaque validation devient la règle de la fois suivante : si la personne corrige un rapprochement une fois, l’agent refait le même geste ensuite. C’est un début de mémoire, mais ce n’est pas encore un graphe : la règle apprise ne dit pas quel cas l’a fait naître, ni ce qu’on avait regardé ce jour-là. Light journalise chaque action avec l’agent qui l’a faite, c’est le geste qui est gardé, pas la raison. Les autres gardent l’historique du client ou ses documents, ce qui aide l’agent à répondre, mais ne dit pas pourquoi on a décidé. Et il y a une objection plus profonde, que développe la deuxième approche : l’agent de métier ne voit que son métier, alors que la raison d’une remise traverse le support, la facturation et la messagerie, c’est-à-dire des outils que personne ne lui a donnés.

Deuxième approche : la couche de contexte, le universal context layer

Prukalpa Sankar dirige Atlan, un éditeur américain de gouvernance des données. Le 15 janvier 2026, elle répond à Garg : il a raison sur ce qui se joue et tort sur le gagnant. Son argument tient en une observation. L’exécution est locale, mais le contexte est global. Pour accorder une remise, l’agent de Garg va chercher dans six outils : le CRM, le support, la messagerie, la facturation, les incidents, l’entrepôt de données. Et chaque entreprise a sa propre combinaison. Un agent de métier devrait donc, selon elle, se brancher à cinquante ou cent systèmes pour couvrir les cas courants, et chaque éditeur referait ce travail dans son coin. Sa conclusion : dans un monde où chaque entreprise a ses outils, c’est celui qui relie tout qui gagne, pas l’application. Cette couche, elle l’appelle le universal context layer.

Dans cette approche, l’outil ne fait pas le travail à la place de quelqu’un. Il définit les chiffres, relie les systèmes entre eux, écrit comment l’entreprise décide, et les agents viennent y lire. Sankar distingue deux sortes de contexte, et la distinction est utile. Le contexte de fonctionnement, c’est-à-dire les procédures et le savoir maison, comme ce qu’on fait quand un client appelle pour un mot de passe. Le contexte des chiffres, c’est-à-dire les définitions, comme ce qu’on appelle exactement le chiffre d’affaires ou le coût d’acquisition d’un client. Et elle avance un deuxième argument, de propriété : les entreprises ont déjà payé cher pour avoir confié leurs données à des éditeurs qui les ont enfermées, elles ne confieront pas leur façon de décider en morceaux à une douzaine de jeunes pousses. Le contexte doit appartenir au client, pas au fournisseur de l’agent.

Le grand ancêtre de cette approche, c’est Palantir, avec Foundry et son ontologie. Sa documentation le dit sans détour : l’ontologie représente les décisions de l’entreprise, pas seulement ses données. Des objets, des liens, des actions, et les applications se posent dessus. C’est le vocabulaire que j’utilise moi-même pour décrire mon système. Atlan se place sur la même ligne, à l’étage du catalogue et des définitions. En France, DataGalaxy, créée à Lyon en 2015, fait un catalogue de données qui se présente aujourd’hui comme le moyen d’« aider les équipes et les agents IA à comprendre ce que signifient les données ». Même position : on ne fait rien, on explique aux agents ce que les choses veulent dire.

Ce que ceux qui ont choisi cette approche ignorent, en revanche, c’est la PME. Le texte de Sankar ne parle ni de DAF, ni de comptabilité, ni d’entreprise de cinquante personnes. Cinquante à cent systèmes, c’est un grand groupe. Chez moi, le contexte n’est pas éparpillé dans cinquante outils. Il est dans Odoo, dans trois classeurs, et surtout dans ma tête.

Ce qu’un DAF en fait

On est tenté de choisir une approche, l’outil qui fait ou la couche qui explique. À mon avis ce n’est pas la bonne question. Les deux ont raison sur un point et tort sur l’autre. Garg a raison de dire que la décision se voit au moment de l’action, et tort de croire que le pourquoi est là, quelque part, à ramasser. Dans une PME, il n’y a rien à ramasser : la raison n’est écrite nulle part tant que le dirigeant ne l’a pas posée. Sankar a raison de dire que le contexte doit appartenir à l’entreprise, et tort de croire qu’il faut une plateforme de grand groupe pour le tenir.

Je pose donc deux questions à chaque éditeur qui vient me voir, et je crois qu’un DAF peut faire pareil. La première : qui voit la décision se prendre chez vous ? Si l’outil affiche un tableau de bord et attend que je décide ailleurs, il ne verra jamais rien. Hyphenate répond oui à celle-là, puisque ses agents font la clôture. La seconde : si je résilie dans un an, à qui appartient la trace ? Si les règles, les exceptions et les précédents sont écrits dans un format que je peux lire sans l’outil, ils sont à moi. Sinon, c’est l’éditeur qui tient ma mémoire, et je la lui loue tous les mois. À cette question-là, c’est au vendeur de répondre, et pas sur une plaquette.

Chez moi, j’ai répondu aux deux à la main. Chaque fois qu’une exception m’a surpris, un client qui paie toujours en retard, un client au forfait dont aucune facture ne dit le taux journalier, un prospect perdu qu’il fallait sortir du plan, j’ai écrit la règle dans un fichier que mes agents lisent, dans mes mots. Ça prend une demi-heure, pas une mission de conseil. Odoo garde le résultat. Les règles sont à moi, et c’est avec elles que la machine travaille.

Reste la difficulté que ni Garg ni Sankar ne traitent, et que je n’ai pas réglée non plus : une règle écrite une fois doit être tenue ensuite, et pour l’instant c’est moi qui la tiens.

---

Sources

• Ashu Garg, AI’s trillion-dollar opportunity: Context graphs, lettre B2BaCEO, 26 décembre 2025, reprise d’un texte cosigné avec Jaya Gupta chez Foundation Capital le 22 décembre 2025. lien
• Prukalpa Sankar, Context Graphs Are a Trillion-Dollar Opportunity. But Who Actually Captures It?, Atlan, 15 janvier 2026. lien
• Palantir, documentation Foundry, Why create an Ontology?. lien
• Marina Temkin, TechCrunch, How AI accounting startup Rillet raised $100M and became a unicorn in 48 hours, 21 août 2026. lien
• Maddyness, Pennylane : nouvelle levée de fonds de 175 millions d’euros, 20 janvier 2026. lien
• Pennylane, page d’accueil. lien
• Anthropic, Advancing Claude for Financial Services, mai 2026. lien
• OpenAI, Introducing ChatGPT for Financial Services, septembre 2026. lien
• TechCrunch, Bench shuts down, leaving thousands of businesses without access to accounting and tax docs, 27 décembre 2024. lien
• Hyphenate, page d’accueil, chiffres publiés par l’entreprise. lien
• Hyphenate (alors Maximor), annonce de la levée de 9 M$, 29 septembre 2025. lien
• Sovereign Magazine, Hyphenate (ex-Maximor), changement de nom le 1er octobre 2026. lien
• Sierra, blog, Year two in review, 6 février 2026, revenu récurrent déclaré par l’éditeur. lien
• Legora, page News, Legora raises $550 million Series E at $8.8 billion valuation, 21 octobre 2026. lien
• Light, page d’accueil, chiffres publiés par l’entreprise. lien
• Atomico, $30M Series A for Light, 25 septembre 2025. lien
• OGC Nice, Limova.ai, the Nice-based AI start-up, is our new Premium Partner. lien
• Odoo, Odoo 19 Release Notes, septembre 2025 : « Chat with AI agents that can learn from your documents and perform actions ». lien
• Presse-citron, L’IA qui fait : la startup niçoise Limova veut réconcilier les PME et l’intelligence artificielle, 24 janvier 2026. lien
• DataGalaxy, page d’accueil. lien
• Lyon Capitale, DataGalaxy : la start-up lyonnaise qui va simplifier le big data. lien

Mis à jour le 28 octobre 2026

← Tous les articles