À retenir
- L’IA prendra en charge une grande partie de ce que les utilisateurs voient dans un ERP : les menus, les rapports standard, les requêtes courantes. Elle ne prendra pas en charge la couche qui enregistre qu’une vente a eu lieu, qu’un stock a bougé ou qu’une facture a été comptabilisée, car un système d’enregistrement exige cohérence, droits d’accès et piste d’audit, et l’IA est probabiliste par nature.
- Le bon test d’un système opérationnel n’est pas de savoir s’il montre un écart, mais s’il suit une décision jusqu’à son résultat : observation, hypothèse, action, preuve. La plupart des logiciels s’arrêtent à la première étape.
- Dès que les données pilotent des actions et non plus des rapports, les erreurs coûtent plus cher et se voient moins : l’explication d’un agent reste cohérente, mais cohérente à propos d’une mauvaise version de l’entreprise.
Ces vingt dernières années, j’ai travaillé sur des déploiements d’ERP, sur des données opérationnelles et dans des entreprises de commerce à des stades de maturité très différents. Un schéma s’est montré remarquablement tenace : une entreprise peut investir lourdement dans un ERP et continuer à préparer le rapport hebdomadaire du propriétaire en assemblant à la main plusieurs fichiers Excel.
Le problème est rarement l’absence de logiciel. Le plus souvent, différents systèmes contiennent des définitions, des processus et des versions différentes de la même réalité. Quelqu’un doit les rassembler, décider à quels chiffres se fier et expliquer le résultat à la direction. En chemin, des informations se perdent ou sont réinterprétées, les mêmes personnes refont le même travail chaque mois, et remonter un chiffre douteux jusqu’à sa source devient difficile. J’ai écrit séparément sur ce que cela coûte à une entreprise au quotidien.
Dans beaucoup d’entreprises du commerce et de la restauration, ce problème de reporting de base n’est toujours pas réglé. Les attentes, elles, sont allées bien au-delà du reporting. Les entreprises veulent désormais un système qui remarque un écart significatif, propose une explication, lance une réponse, puis finit par dire si cette réponse a produit un résultat mesurable.
Quand l’analyse devient action
Imaginez que la marge d’une catégorie commence à glisser dans plusieurs magasins. Un outil de BI classique affiche la variation sur un tableau de bord. Il faut encore que quelqu’un la remarque, cherche la cause, décide quoi faire, communique la décision et revienne plus tard voir si cela a fonctionné.
Un système plus capable examinerait la structure de la baisse : la part des produits à faible marge a-t-elle augmenté, une promotion s’est-elle comportée autrement que prévu, les prix d’achat ont-ils bougé, des produits clés ont-ils manqué, le mix des ventes a-t-il changé. Il pourrait ensuite proposer une action (vérifier l’implantation, déplacer du stock entre magasins, ajuster la prochaine commande, modifier une promotion, confier la tâche au bon responsable) puis, une semaine ou un mois plus tard, réexaminer cette décision au regard du chiffre d’affaires, de la marge, de la rotation des stocks, de la casse et de la trésorerie.
Observation, hypothèse, action, preuve du résultat. La plupart des logiciels de gestion savent assez bien montrer ce qui s’est passé. Bien peu savent suivre une décision jusqu’à son effet économique.
J’appelle cette séquence une boucle de preuve ; le nom compte moins que la dernière étape. Dès qu’elle existe, le reporting cesse d’être seulement un moyen d’observer l’entreprise et devient une partie de la façon dont l’entreprise réagit. C’est le basculement que je défendais dans de la comptabilité à la navigation, et la raison pour laquelle marql tient un Impact Ledger de ce que chaque recommandation suivie a produit sur les chiffres.
Il existe plusieurs niveaux de réponse possibles, et ils ne sont pas interchangeables. Un système peut placer une recommandation devant un responsable et s’arrêter là. Il peut créer une tâche et suivre son exécution. Pour un processus étroit et répétitif, il peut agir seul dans des limites convenues à l’avance. Il peut préparer un transfert de stock entre sites mais exiger l’accord d’un directeur des opérations ; il peut passer une commande dans une fourchette convenue mais faire remonter un achat plus important. Les décisions qui touchent aux prix, à des engagements d’achat importants ou à une grande part du stock demandent un autre niveau de contrôle que les ajustements de routine.
L’objectif n’est pas de déléguer le plus de décisions possible. Le travail difficile consiste à décider quelles actions sont réversibles, quelles limites peuvent être fixées à l’avance, et où le coût d’une erreur justifie encore une validation humaine.
Il en va de même pour l’idée en vogue de converser avec son entreprise. Une interface conversationnelle est réellement utile, mais pas parce que les propriétaires attendaient une nouvelle façon de demander un rapport. Ils veulent savoir quel écart compte, ce qui a pu le causer, qui doit réagir, et si la décision a porté ses fruits. Le langage naturel rend ce processus plus accessible. Il ne rend pas plus fiables les informations qui se trouvent dessous.
La partie de l’ERP que l’IA ne peut pas remplacer
La question de savoir si l’IA remplacera l’ERP a tendance à confondre deux fonctions bien différentes.
La première, c’est tout ce que voient les utilisateurs : menus, formulaires, rapports standard, écrans de validation, flux d’analyse intégrés. Une grande partie de tout cela va changer. Les gens passeront moins de temps à chercher un rapport précis ou à cliquer à travers une longue suite d’écrans, et des agents prendront en charge beaucoup de requêtes, de contrôles et d’étapes de processus courants.
La seconde est moins visible. Les systèmes d’ERP, de caisse, de comptabilité et d’entrepôt enregistrent des événements de gestion. Ils établissent qu’une vente a eu lieu, qu’une marchandise a été réceptionnée, qu’un produit a été sorti du stock, que des articles ont circulé entre sites, qu’un prix a changé, qu’une facture a été comptabilisée. Ces événements ne naissent pas dans la couche d’IA. Il faut toujours les saisir, les relier et les conserver selon des règles définies.
Un système comptable ne peut pas conclure qu’une transaction a probablement eu lieu. Il doit enregistrer ce qui s’est passé, conserver les pièces justificatives et garder un historique que quelqu’un pourra examiner plus tard. Un commerçant doit connaître non seulement le solde de stock actuel, mais aussi quelles réceptions, ventes, transferts, retours et sorties de stock l’ont produit. L’IA est probabiliste par nature, ce qui est utile quand une tâche suppose de l’interprétation, des informations incomplètes ou un éventail de réponses plausibles. Un système d’enregistrement a une autre responsabilité : cohérence, reproductibilité, droits d’accès, piste d’audit. Ajouter de l’IA ne fait pas disparaître ces exigences.
La frontière n’est pas absolue pour autant. L’IA peut nettement améliorer la saisie et le contrôle dans l’ERP sans devenir elle-même le système d’enregistrement. Un agent ciblé peut lire une facture, un bon de commande ou un bon de livraison et préparer les champs pour vérification, rapprocher un fournisseur ou une référence des données de base existantes, repérer une information manquante et signaler une erreur probable avant que la transaction soit comptabilisée. D’autres agents peuvent surveiller ce qui a déjà été enregistré, à la recherche de doublons, d’enregistrements manquants, de valeurs inhabituelles, de classifications de produits incohérentes ou de transactions qui ne se rapprochent pas des opérations liées. Au lieu de surgir à la clôture du mois, ces problèmes peuvent être traités au plus près du moment où ils se produisent.
Toutes ces capacités ne relèvent pas du mot IA. Si un champ obligatoire est vide ou qu’une valeur sort d’une plage connue, une règle classique le détecte de façon plus fiable et moins coûteuse. Les méthodes statistiques et l’apprentissage automatique traditionnel savent bien trouver des schémas inhabituels dans de gros volumes de transactions. L’IA générative et les agents trouvent leur place là où le système doit lire un document non structuré, interpréter un contexte, expliquer une anomalie ou proposer la suite. Une architecture pragmatique utilise les trois, et choisit selon la nature du problème. Le marché fonctionne souvent dans l’ordre inverse : tout est d’abord présenté comme de l’IA, et le problème est défini ensuite.
Les mauvaises données coûtent plus cher
Quand les données ne servent qu’au reporting, une erreur abîme un rapport. Dès que ces mêmes données commencent à piloter des recommandations et des actions, les conséquences changent. Un solde de stock erroné entraîne un achat inutile. Une référence en double fausse la performance d’une catégorie. Des classifications incohérentes pèsent sur les décisions d’assortiment, et des écritures tardives font réagir le système à une situation qui n’existe plus. Les mêmes problèmes sapent toute tentative ultérieure de calculer ce qu’une décision a rapporté.
L’IA peut rendre ce risque moins visible, parce que ce qu’elle produit sonne juste. Un agent peut répondre avec assurance à la question d’un propriétaire, identifier un schéma plausible et recommander une démarche raisonnable. Si les données sources sont incomplètes ou incohérentes, l’explication restera cohérente. Elle sera simplement cohérente à propos d’une mauvaise version de l’entreprise.
Une Porsche 911 peut avoir une ingénierie d’une sophistication exceptionnelle, rien de tout cela ne la dispense de carburant. Dans un système de gestion piloté par l’IA, ce carburant, ce sont des données exactes, structurées et à jour.
C’est aussi pourquoi je ne suis pas convaincu que l’IA rendra automatiquement les projets ERP moins chers. Elle réduira le coût de certaines tâches : traitement des documents, rapprochement des données de base, détection d’anomalies, documentation des intégrations, premier diagnostic. Mais dans le même temps, les entreprises demandent davantage à leurs données : plus de détail, disponible plus tôt, cohérent sur un nombre croissant de systèmes. La nature du travail change ; le travail ne disparaît pas. Dans certains cas, le projet devient plus exigeant, parce que le résultat n’est plus destiné seulement à un rapport de direction. Un analyste humain peut regarder un chiffre inhabituel et décider que quelque chose cloche probablement. Un processus automatisé a besoin que cette incertitude soit détectée avant qu’il ajuste une commande ou réaffecte du stock. C’est l’argument pour traiter le reporting comme quelque chose que l’on fait tourner en continu plutôt qu’un projet que l’on termine.
Un point de départ pragmatique
Pour un propriétaire, le point de départ raisonnable n’est ni le produit d’IA le plus impressionnant ni une tentative de remplacer tout l’environnement comptable. C’est une décision de gestion récurrente où une réponse meilleure et plus rapide créerait une valeur mesurable : marge par catégorie, casse, ruptures, répartition des stocks, achats.
Une fois le scénario défini, vous pouvez vous demander de quelles données il a besoin, d’où elles viennent, à quel point elles sont fiables, ce que le système doit être autorisé à faire, et comment le résultat sera mesuré. Cela révèle généralement assez vite l’état réel de l’infrastructure, et cela évite que le projet devienne une initiative IA générale sans responsable opérationnel ni résultat économique.
Pour la plupart des chaînes de magasins et des groupes de restauration bien établis, remplacer la caisse, l’ERP ou la plateforme comptable n’est pas la première étape. La voie la plus pragmatique consiste à travailler avec les systèmes déjà en place. La caisse fournit généralement les données de base ; l’ERP, la comptabilité et les systèmes d’entrepôt ajoutent les achats, les coûts, les stocks et les informations financières. Les connecter n’est qu’un début : produits, catégories, sites, transactions, prix et soldes doivent encore être rapprochés dans un modèle unique qui reste comparable entre magasins, systèmes et périodes.
C’est la partie de marql qui attire le moins l’attention et qui décide le plus. marql lit les systèmes qu’une chaîne utilise déjà, sans les remplacer, avec un hébergement dans l’UE, les normalise dans un modèle unique, et répond à la deuxième question sur un chiffre dans la même conversation que la première. Une partie du rapprochement est automatisée ; les exceptions demandent toujours des personnes qui comprennent l’activité. Les tarifs commencent à 200 € par mois.
Je ne m’attends pas à ce que l’IA fasse disparaître les ERP et les systèmes comptables dans un avenir prévisible. Elle rendra leurs interfaces moins centrales, prendra en charge le travail d’analyse courant, simplifiera la saisie et renforcera les contrôles de données. La responsabilité d’enregistrer correctement les événements de gestion reste là où elle est. Au fil des années, j’ai vu à maintes reprises de nouveaux outils d’analyse mettre au jour les faiblesses de la comptabilité opérationnelle plutôt que d’en supprimer le besoin. L’IA les mettra au jour plus vite, et dans certains cas agira sur l’information avant qu’une personne l’ait examinée.
SujetsIA et ERP, Système d’enregistrement, Qualité des données, Automatisation par agents
