← Blog

Un système agentique peut-il remplacer un ERP ?

TCO ERP classique vs stack agentique (LLM + RAG + LangGraph + BDD) pour une PME 15-50 salariés.

TL;DR

  • Un ERP (SAP, Odoo, Sage) vend de la structure. Tables normées, workflows figés, audit trail horodaté. C’est non-négociable en comptabilité, paie, traçabilité réglementaire.
  • Un système agentique (LLM + RAG + orchestrateur + BDD) vend de la souplesse. Saisie en langage naturel, rapprochement flou, drafting de documents, extraction depuis PDF/mail.
  • TCO 3 ans PME 25 salariés : ERP mid-market ≈ 90–180 k€ (licences + intégration + support). Stack agentique équivalente sur périmètre partiel ≈ 25–60 k€ (infra + intégration + API calls).
  • Là où l’agent gagne : saisie libre, reconciliation bancaire/factures, extraction de cahiers des charges, pré-remplissage de devis, résumés de réunion, suivi de mails clients.
  • Là où l’agent perd (et où l’ERP reste indispensable) : plan de comptes, liasse fiscale, gestion des lots et DLC, SLA contractuels, audit SOX/ISO, exigences CNIL/RGPD sur la traçabilité des écritures.
  • Verdict 2026 : hybride. Pas de remplacement. Un ERP pour le cœur normé, un agent pour la périphérie texte. On ne remplace pas le grand livre, on remplace la personne qui recopie les factures fournisseurs dedans.

TCO 3 ans comparé : ERP mid-market vs stack agentique (fourchette médiane, périmètre partiel).

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#F3EADE','primaryBorderColor':'#7DB5A5','primaryTextColor':'#2C3E42','secondaryColor':'#FDFBF8','tertiaryColor':'#E99971','lineColor':'#7DB5A5','nodeBorder':'#7DB5A5','nodeTextColor':'#2C3E42','mainBkg':'#F3EADE','edgeLabelBackground':'#FDFBF8','clusterBkg':'#FDFBF8','clusterBorder':'#F3EADE','fontFamily':'Inter, system-ui, sans-serif','fontSize':'13px'}}}%%
flowchart LR
    mail["📧 Mails<br/>PDFs / scans"]:::input
    form["📝 Formulaires<br/>web / GED"]:::input
    extract["🤖 Agent d'extraction<br/>LLM + RAG"]:::agent
    tampon[("BDD tampon<br/>+ validation humaine")]:::buffer
    erp[("🏛️ ERP<br/>source de vérité")]:::erp
    report["🤖 Agent de synthèse<br/>rapports / drafts"]:::agent
    out["📊 Dashboards<br/>réponses clients"]:::output

    mail --> extract
    form --> extract
    extract --> tampon
    tampon -->|humain valide| erp
    erp --> report
    report --> out

    classDef input fill:#F3EADE,stroke:#7DB5A5,color:#2C3E42
    classDef agent fill:#E99971,stroke:#C97A55,color:#FFFFFF
    classDef buffer fill:#FDFBF8,stroke:#E99971,color:#2C3E42
    classDef erp fill:#2C3E42,stroke:#2C3E42,color:#FDFBF8
    classDef output fill:#7DB5A5,stroke:#7DB5A5,color:#FDFBF8

Architecture hybride : ERP au cœur, agents en périphérie. Les agents ne modifient jamais directement la source de vérité.

Pourquoi la question revient en 2026

Depuis dix-huit mois, sur quasiment chaque mission PME, la même phrase revient : « On est en train de choisir entre Odoo et Sage, mais on se demande si ChatGPT ne pourrait pas faire le même boulot. »

La question n’est pas stupide. Elle est juste mal posée.

Un ERP et un système agentique ne résolvent pas le même problème. L’ERP résout un problème de structure (garder des données cohérentes, tracer qui a fait quoi, produire des états comptables réglementaires). L’agent résout un problème d’interface (lire un mail, comprendre un PDF, rédiger un brouillon, rapprocher deux lignes qui se ressemblent sans être identiques).

La confusion vient du fait que les deux promettent de “faire gagner du temps”. Mais le temps qu’ils font gagner n’est pas le même. L’ERP fait gagner du temps sur la discipline de saisie (une fois saisi proprement, plus besoin de re-saisir). L’agent fait gagner du temps sur la préparation de la saisie (transformer un bon de commande scanné en lignes ERP utilisables).

En 2024–2025, les LLM sont devenus fiables sur ces tâches de préparation. En 2026, ce sont les orchestrateurs d’agents (LangChain, CrewAI, LangGraph + MCP, Autogen, Claude Code en sub-agents) qui sont devenus déployables en prod. D’où la question légitime : puisqu’on peut faire tourner un agent qui lit, classe, rédige, et appelle des API pour 50 € de tokens par mois, pourquoi payer 200 k€ d’ERP ?

Parce que les deux ne jouent pas au même jeu. Détaillons.


Anatomie du TCO : où part l’argent d’un ERP mid-market

Prenons une PME industrielle de 25 salariés, 5 M€ de CA, multi-site, qui choisit un ERP mid-market (Odoo Enterprise, Sage 100c, Cegid XRP Flex, Divalto). Voici la décomposition typique sur 3 ans, basée sur les chiffres observés chez des PME industrielles comparables (fourchettes réelles, pas théoriques) :

PosteFourchette 3 ans
Licences utilisateurs (20–30 nommés)25 000 – 55 000 €
Intégration initiale (60–150 jours consultants)40 000 – 100 000 €
Paramétrage métier (BPM, états, interfaces)10 000 – 25 000 €
Support et maintenance annuels8 000 – 18 000 €/an
Hébergement cloud ou serveur on-prem4 000 – 12 000 €/an
Formation et conduite du changement5 000 – 15 000 €
Total 3 ans90 000 – 180 000 €

Ce qu’on achète concrètement :

  1. Un schéma de données figé (clients, articles, BL, factures, écritures, stocks, nomenclatures, gammes, etc.) qui a mis vingt ans à se stabiliser.
  2. Des workflows normés (validation de commande, rapprochement bancaire, clôture mensuelle, inventaire tournant, OF, gamme de fabrication).
  3. Un moteur d’états comptables qui sort bilan, compte de résultat, annexes, FEC, DEB/DES, TVA, liasse fiscale — et qui les sort correctement au regard de l’URSSAF et du fisc.
  4. Un audit trail immuable : qui a créé l’écriture, qui l’a modifiée, quand, avec quels droits. Requis pour un contrôle fiscal, une certification ISO 9001, un audit SOC 2.
  5. Un écosystème de modules standards (CRM, GPAO, GED, BI) qui s’interfacent sans développement spécifique.

Le prix est majoritairement humain, pas logiciel. Les licences représentent 25–35 % du TCO. L’intégration et le paramétrage en représentent 50–65 %. Support et infra, le reste. C’est un projet qui coûte cher parce qu’il faut comprendre le métier, pas parce que le code d’Odoo est précieux.


Anatomie d’une stack agentique équivalente — et ses limites

Maintenant, ce que coûte une stack agentique qui prend en charge un sous-ensemble du périmètre ERP (on y reviendra pour le “sous-ensemble”) :

PosteFourchette 3 ans
Infra (PostgreSQL managé, Qdrant/pgvector, stockage)1 500 – 4 000 €/an
Orchestrateur (LangGraph self-hosted, ou Temporal)0 – 1 200 €/an
API LLM (Claude Sonnet, GPT-4o-mini, selon volume)800 – 6 000 €/an
Intégration initiale (connecteurs, prompts, fine-tuning RAG)15 000 – 35 000 €
Maintenance évolutive (8–15 j/an consultants IA)6 000 – 15 000 €/an
Total 3 ans25 000 – 60 000 €

Le gap de prix est réel : 2× à 4× moins cher. Mais ce n’est pas le même produit.

Ce qu’on achète concrètement avec une stack agentique :

  1. Un orchestrateur (LangGraph, Temporal, Claude Code en sub-agents) qui séquence des appels.
  2. Un ou plusieurs LLM pour comprendre du texte libre, en extraire de la structure, ou rédiger des brouillons.
  3. Une base vectorielle (RAG) pour donner au LLM l’accès à l’historique de l’entreprise (anciens devis, fiches produit, procédures, mails).
  4. Une BDD relationnelle pour les données structurées (SQLite, PostgreSQL).
  5. Des connecteurs vers les outils existants (mail, compta, CRM, GED).

Ce que l’agent fait bien

  • Saisie libre → structure. Un fournisseur envoie sa facture PDF avec un mise en page différente à chaque trimestre ? L’agent lit, extrait les lignes, mappe sur le plan de comptes, pré-remplit l’écriture. Taux de bon-du-premier-coup observé : 85–95 % sur factures fournisseurs, 70–85 % sur BL scannés.
  • Reconciliation bancaire floue. L’intitulé de virement dit “VIR CB MARTIN 04/26” et on a un client “Martin Industries SA” avec une facture de 12 400 € ce mois-ci. Un ERP classique rapproche si le libellé exact est reconnu ou si le montant tombe juste. L’agent rapproche sur le sens.
  • Drafting de documents. Le commercial reçoit un cahier des charges de 40 pages. L’agent en extrait les contraintes techniques, les confronte à l’historique de devis similaires, et pré-remplit un devis cohérent. Le commercial n’a plus qu’à valider les prix. Gain typique : 2–4 h par devis.
  • Suivi de relation client. L’agent lit les mails reçus, détecte les demandes récurrentes, priorise les litiges, résume les historiques clients quand le commercial prépare un rendez-vous.
  • Réponses internes sur procédure. “Quelle est la procédure de retour client pour un lot contesté ?” L’agent cherche dans la GED, ressort la procédure, cite ses sources.

Ce que l’agent fait mal (et qui bloque le remplacement)

  • Audit trail. Quand un agent modifie une écriture comptable, qui est le responsable légal ? Un LLM n’est pas auditeur. Le commissaire aux comptes exigera une trace humaine nominative. La CNIL aussi sur les données clients.
  • Workflows figés et normés. La clôture mensuelle, la DEB, la liasse fiscale, le FEC — ce sont des procédures où toute improvisation est une sanction fiscale. L’ERP suit le texte à la lettre ; l’agent fabulera une fois sur cent, ce qui est une fois de trop.
  • SLA et disponibilité. Un LLM hébergé cloud a un SLA variable (99,5 % chez OpenAI, 99,9 % chez Anthropic), et des fenêtres de panne documentées. Une clôture comptable le 31 à 23h58 ne tolère pas “model overloaded, retry later”.
  • Cohérence à long terme. Un ERP maintient les règles de gestion à travers les années. Un agent, même avec RAG, peut dériver si les prompts évoluent sans tests de non-régression.
  • Coût à l’échelle. 1 000 factures/mois × 3 appels LLM × 0,02 € = 60 €/mois, acceptable. 50 000 factures/mois × 3 × 0,02 € = 3 000 €/mois : l’économie d’échelle s’érode.
  • Sécurité et confidentialité. Envoyer des factures clients à un LLM cloud pose question RGPD. Self-hosté avec un Llama 3 ou Mistral local, c’est possible mais la qualité baisse, et le coût infra remonte.

L’architecture qui fonctionne vraiment : ERP + agents satellites

Ce qu’on déploie en 2026 chez nos clients PME, c’est l’ERP comme cœur (grand livre, stocks, paie, achats) et des agents comme satellites pour absorber le texte non structuré en entrée et en sortie.

Schéma type :

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#F3EADE','primaryBorderColor':'#7DB5A5','primaryTextColor':'#2C3E42','secondaryColor':'#FDFBF8','tertiaryColor':'#E99971','lineColor':'#7DB5A5','nodeBorder':'#7DB5A5','nodeTextColor':'#2C3E42','mainBkg':'#F3EADE','edgeLabelBackground':'#FDFBF8','clusterBkg':'#FDFBF8','clusterBorder':'#F3EADE','fontFamily':'Inter, system-ui, sans-serif','fontSize':'13px'}}}%%
flowchart TB
    subgraph ERP["ERP mid-market — médiane 135 k€ / 3 ans"]
        direction LR
        L1["Licences utilisateurs<br/>40 k€"]:::erp
        L2["Intégration initiale<br/>70 k€"]:::erp
        L3["Support & infra<br/>15 k€"]:::erp
        L4["Formation<br/>10 k€"]:::erp
    end
    subgraph AG["Stack agentique satellite — médiane 42 k€ / 3 ans"]
        direction LR
        A1["Infra + API LLM<br/>12 k€"]:::agent
        A2["Intégration<br/>22 k€"]:::agent
        A3["Maintenance<br/>8 k€"]:::agent
    end

    classDef erp fill:#E99971,stroke:#C97A55,color:#FFFFFF
    classDef agent fill:#7DB5A5,stroke:#7DB5A5,color:#FDFBF8

Coût total de possession (TCO) sur 3 ans, PME 25 salariés — médianes observées sur missions terrain.

Les agents ne touchent jamais directement aux écritures ERP. Ils préparent la donnée pour qu’un humain ou une interface ERP la valide. C’est cette règle qui permet de garder l’audit trail propre.

Cas d’usage concret chiffré — PME usinage 18 salariés

Cas réel PME, sous-traitant mécanique, CA 3,8 M€, Odoo Enterprise déjà en place depuis 2022. Problème : la personne en charge de l’ADV passe 12 à 15 heures par semaine à recopier des bons de commande clients (PDF, mail, fax numérisé) dans Odoo.

Stack déployée (3 semaines de travail, 14 k€ HT) :

  • Entrée : boîte mail commandes@ + dépôt GED
  • Agent d’extraction : Claude Sonnet + prompt spécialisé bons de commande métal (repère référence, quantité, délai, prix unitaire, incoterm)
  • RAG : base Qdrant des 8 000 commandes historiques + catalogue articles Odoo (export quotidien)
  • Validation : interface web minimaliste (Streamlit) où l’ADV voit la commande pré-remplie et valide ou corrige
  • Sortie : appel API Odoo /create_sale_order
  • Audit : chaque commande créée porte un tag source: agent_v1.2, validated_by: marie@…, validation_ts: …

Résultats mesurés à 2 mois :

IndicateurAvantAprès
Temps ADV par commande7 min1,5 min
Heures ADV / semaine sur ressaisie13 h3 h
Taux d’erreur ressaisie (référence, qté)2,1 %0,6 %
Coût API LLM / mois38 €
Délai de confirmation commande client4–48 h< 4 h systématique

Ce qu’on n’a PAS fait : remplacer Odoo. On a rajouté une couche qui absorbe le travail de préparation. L’ERP reste la source de vérité, le FEC reste auditable, le CAC reste content.

Ce qui a failli mal tourner : à la semaine 3, l’agent a inventé une référence article qui n’existait pas (hallucination). L’interface de validation l’a rattrapé parce qu’on avait contraint le LLM à ne choisir que dans la liste existante via function calling strict. Leçon retenue : jamais laisser l’agent écrire librement vers la base structurée. Toujours via des outils contraints (schéma JSON, whitelist, enum).


Limites, pièges, et anti-patterns observés

  1. “On va remplacer le CRM par un agent” → mauvaise idée. Un CRM structure des relations sur dix ans. Un agent a une mémoire courte et non auditée.
  2. “On fait tourner le LLM en local pour la confidentialité” → souvent faux calcul. Un Llama 3 70B local demande une A100 dédiée (15–25 k€/an en cloud, 30 k€+ en on-prem), et reste 20–40 % moins précis qu’un Claude Sonnet. Pour une PME 25 salariés, l’économie RGPD via LLM local est rarement rentable avant le seuil de 10 000 appels/jour.
  3. “L’agent va écrire directement dans l’ERP” → non. Toujours via une couche de validation, soit humaine, soit automatique mais contrainte (schéma JSON, vérifications métier, sandbox).
  4. “On va lui laisser gérer l’authentification” → non. Les LLM sont trompables par prompt injection. La couche auth reste un système déterministe (OAuth, JWT, ACL).
  5. “On va le brancher à tous les mails” → commencer par un alias dédié. Un agent qui lit tout le mail reçoit aussi les pièces jointes piégées, les phishings, les demandes RH confidentielles. Périmètre restreint = risque restreint.
  6. Sous-estimer la maintenance. Les prompts dérivent, les API évoluent, les modèles changent (Claude 3.5 → 4.x → 4.7), les formats de factures fournisseurs changent. Compter 8–15 jours/an de maintenance agentique active.
  7. “L’agent a remplacé Marie” → dans les faits, Marie fait maintenant autre chose (qualité fournisseur, suivi litiges, relance paiements). La valeur est dans le déplacement du travail vers des tâches non automatisables, pas dans la suppression du poste. C’est aussi ce qui fait accepter le projet socialement.

Matrice de décision : ERP, agent, ou les deux ?

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#F3EADE','primaryBorderColor':'#7DB5A5','primaryTextColor':'#2C3E42','secondaryColor':'#FDFBF8','tertiaryColor':'#E99971','lineColor':'#7DB5A5','nodeBorder':'#7DB5A5','nodeTextColor':'#2C3E42','mainBkg':'#F3EADE','edgeLabelBackground':'#FDFBF8','clusterBkg':'#FDFBF8','clusterBorder':'#F3EADE','fontFamily':'Inter, system-ui, sans-serif','fontSize':'13px'}}}%%
flowchart TD
    Q{{"Tâche à automatiser ?"}} --> T1{Audit trail<br/>réglementaire requis ?}
    T1 -- oui --> ERP["🏛️ ERP<br/>source de vérité"]:::erp
    T1 -- non --> T2{Données en<br/>langage naturel ?}
    T2 -- oui --> T3{Validation humaine<br/>tolérable ?}
    T3 -- oui --> AG["🤖 Agent satellite"]:::agent
    T3 -- non --> MIX["🔀 Agent + schéma<br/>contraint (JSON)"]:::mix
    T2 -- non --> T4{Volume & <br/>structure stable ?}
    T4 -- oui --> ERP
    T4 -- non --> MIX

    classDef erp fill:#2C3E42,stroke:#2C3E42,color:#FDFBF8
    classDef agent fill:#E99971,stroke:#C97A55,color:#FFFFFF
    classDef mix fill:#7DB5A5,stroke:#7DB5A5,color:#FDFBF8

Règle de décision : ERP sur le cœur normé, agent sur la périphérie texte. L’inverse échoue.


Verdict

En 2026, un système agentique ne remplace pas un ERP pour une PME industrielle. Il le complète, en absorbant la couche texte non structuré en amont et en aval.

Le choix pertinent pour une PME 15–50 salariés qui n’a pas encore d’ERP :

  • Cœur normé (compta, stocks, achats, paie) : un ERP mid-market éprouvé (Odoo, Sage, Cegid). Budget 40–80 k€ en déploiement, 15–25 k€/an en run.
  • Couche agentique satellite pour l’extraction/drafting : 15–25 k€ en déploiement, 1–5 k€/an en run, ROI typiquement 6–12 mois sur une charge ADV ou compta fournisseurs.
  • Règle d’or : les agents ne modifient jamais directement les données normées. Ils préparent, résument, rédigent. Un humain valide, l’ERP enregistre.

Le jour où un LLM aura un audit trail certifié par la DGFiP et un SLA à 99,99 % sur les heures ouvrées, on reparlera du remplacement. Ce jour n’est pas 2026.


Sources


On peut en parler

BCUB3 accompagne les PME et ETI industrielles sur ces sujets : diagnostic ERP existant, cadrage d’un projet d’agents satellites, choix de stack (cloud vs local, Claude vs GPT, LangGraph vs code custom), POC sur un cas d’usage ADV ou compta fournisseurs avant tout engagement long.

Pas d’éditeur maison à placer. Pas de package ERP à vendre. On regarde ce qui existe chez vous, on mesure ce qui se recopie à la main, et on dit honnêtement si un agent a du sens — ou pas.

Prendre 30 minutes pour en parler →

Et si vous voulez suivre sans vous engager : la newsletter BCUB3 publie un article de ce niveau chaque semaine, sans hype, sur l’IA et les systèmes agentiques en contexte industriel.

S’abonner à la newsletter →

Cet article vous a été utile ?

BCUB3 est une petite structure. Si vous pensez à un collègue ou un partenaire qui pourrait en tirer quelque chose, la meilleure manière de nous aider est de partager le lien. Et si vous avez un cas concret à discuter, parlons-en directement.

Prendre un RDV de cadrage