Cinq agents IA qui lisent l'ERP et disent où regarder.
Les analyses existaient. Rien ne les déclenchait.
Ils n'étaient pas démunis. Un outil d'analyse était branché sur leurs données, et ce qu'il répondait était juste. Mais on ne l'interrogeait qu'après avoir constaté quelque chose : un mois inhabituel, une remarque, un doute.
On refaisait alors un export, on repassait par un tableur, et on regardait en arrière. La vision arrivait après coup, par morceaux, et jamais sur l'ensemble de l'activité en même temps.
Nous avons posé une autre question : de quelles informations avez-vous besoin pour piloter ? Non pas ce que vous aimeriez analyser, mais ce dont vous voulez être prévenu.
La réponse a dessiné six domaines, les ventes, les clients, le recouvrement, les achats, le stock et la marge, qui étaient ses préoccupations réelles. Le problème n'était donc pas la capacité d'analyse, qui existait déjà. C'était que rien ne la déclenchait.
Les données étaient justes. Les questions n'étaient pas posées.
Leurs données sont justes. Elles sont dans l'ERP, à jour, exactes. Le problème n'était pas là.
Il était qu'il faut savoir quoi y chercher, et quand. Un client qui espace ses commandes ne prévient pas. Une marge qui s'érode se voit un an plus tard.
Un stock qui dort ne fait pas de bruit. Rien de tout cela ne remonte, parce que rien de tout cela ne déclenche d'alerte dans un système conçu pour enregistrer.
Concrètement, on analysait quand on avait constaté. Un export, un tableur, quelqu'un qui sait faire, et une réponse qui décrivait une période déjà passée. Entre deux analyses, personne ne regardait. Non par négligence : parce que rien n'indiquait qu'il fallait regarder.
Un outil répond à la question qu'on a pensé à lui poser.
L'ERP faisait correctement son travail. Il enregistre, il calcule, il édite. Ce n'est pas un mauvais outil, et il n'était pas question de le remplacer : toute l'activité passe par lui, et ses données sont fiables.
L'outil d'analyse faisait le sien. Branché sur les bonnes données, il répondait juste à ce qu'on lui demandait.
Ce qui coinçait tient à la nature des deux. Un ERP enregistre, il ne surveille pas. Un outil d'analyse répond, il ne demande rien. L'un et l'autre attendent qu'une personne arrive avec une question, et cette personne ne peut poser que les questions auxquelles elle a déjà pensé.
Dès qu'il faut croiser deux notions, tenir compte d'une règle propre à la maison ou regarder une période inhabituelle, on retombe sur l'export, le tableur, et la personne qui sait faire.
Le processus d'abord. L'outil ensuite.
Nous avons conservé l'ERP, entièrement. Il reste la source unique des chiffres, les agents n'y écrivent jamais rien, et l'entreprise continue d'y travailler exactement comme avant. Ce n'est pas un outil de plus : ce sont des informations en plus, poussées vers ceux qui pilotent.
Nous avons conservé aussi l'endroit où vivent les données. Les agents travaillent là où elles sont, sans déménagement préalable, et les modèles qui les interprètent sont des modèles ouverts hébergés en France et en Europe. Rien n'est confié au service d'un éditeur d'intelligence artificielle.
Ce que nous avons challengé, c'est l'idée qu'un logiciel doive décider à la place de l'entreprise de ce qui est anormal. Un retard de paiement devient-il préoccupant à sept jours ou à trente ? Une marge est-elle faible cinq points sous la moyenne de son groupe de clients, ou dix ?
Une référence dort-elle après trois mois de silence, ou après six ? Il n'existe pas de bonne réponse universelle, et deux entreprises du même métier n'y répondent pas pareil. Nous avons donc refusé d'y répondre à leur place.
Nous avons challengé, enfin, le moteur de règles. Un seuil franchi produit une ligne dans une liste ; ce dont l'entreprise a besoin, c'est d'une phrase qui dit ce qu'il faudrait en faire.
Les agents sont donc reliés à des modèles de langage qui interprètent les données dans le cadre qu'elle a défini, et proposent l'action qui en découle. La décision, elle, reste à l'entreprise.
Les agents apportent la question. L'entreprise apporte la borne.
Cinq agents lisent l'ERP et surveillent chacun un domaine : les marges, le recouvrement, les clients, les ventes, les achats et le stock. Ils lisent, ils n'écrivent jamais rien. Chacun est juge de son domaine et d'aucun autre : quand l'un a besoin d'un fait qui appartient à un autre, il le lui demande au lieu de le recalculer. Un même fait n'a qu'un seul propriétaire, donc une seule vérité.
C'est l'entreprise qui pose les bornes. Pour chaque critère, elle règle trois choses : à partir de quand cela mérite un simple constat, à partir de quand cela mérite une alerte, et en dessous de quel montant on ne dérange personne. Tant qu'une borne n'est pas posée, l'agent mesure, affiche ce qu'il voit, et n'alerte pas. Il ne rassure pas non plus : il dit qu'aucune borne n'a été posée.
L'analyse ne suit pas le calendrier comptable. Elle tourne une fois par jour sur l'ensemble de l'activité, et c'est un réglage : deux fois, davantage, selon le rythme de l'entreprise. Ce qu'elle trouve remonte sans attendre la fin du mois, du trimestre ou de l'année. Les écrans lisent un résultat déjà calculé : ils s'affichent immédiatement, même sur un catalogue de plus de cent mille références, et ils portent l'heure de l'analyse.
Cinq domaines. Cinq façons de regarder.
Les marges se raisonnent sur le prix réellement facturé
Elles cherchent les produits vendus sans gagner d'argent : la marge théorique et la marge encaissée divergent dès qu'il existe des accords ou des remises, et c'est la seconde qui décide.
Le recouvrement lit l'exigibilité pièce par pièce
L'échéance réelle de chaque facture, le délai accordé, le comportement de paiement passé, plutôt qu'un retard moyen qui ne désigne personne.
Les clients sont comparés à leur propre rythme
Ce qu'un client rapporte, ce qu'il coûte en marge et ce qu'il coûte à encaisser, mis en regard de sa façon d'acheter : un client qui commande chaque semaine et un client qui commande deux fois par an ne s'éteignent pas au même moment.
Les ventes suivent les devis qui dorment
Ceux qui n'ont jamais été envoyés, ceux qui vont périmer, ceux restés sans réponse au-delà du délai habituel de signature de l'entreprise.
Les achats et le stock donnent un état à chaque référence
Vivante, dormante, éteinte, jamais sortie, et le geste qui va avec.
Une fiche rassemble enfin ce que les cinq savent d'un même client
Rien n'est fusionné ni classé : si deux agents ne disent pas la même chose, cela se voit, et c'est l'entreprise qui tranche.
Une solution adaptée ne change pas seulement l'outil. Elle change le quotidien.
Les effets de ce type de solution se mesurent en mois, pas en semaines. Un délai de règlement qui se réduit, une marge qui s'érode moins : ces mouvements dépendent aussi de beaucoup d'autres choses. Aucun chiffre ne sera publié avant d'être mesuré et attribuable.
- Du stock dormant découvert en grande quantité, sur un sujet que personne n'analysait
- Des relances écrites dès que le retard est identifié, et envoyées si l'entreprise le décide
- Des marges comparées entre clients comparables, et non en moyenne
- Une information qui arrive sans attendre la fin du mois
- Un ERP inchangé, et des données en plus poussées vers ceux qui pilotent
Mais l'essentiel n'est pas là. En posant ses propres bornes, l'entreprise a dû répondre à une question qu'elle n'avait jamais eu à formuler : qu'est-ce qu'une bonne marge, qu'est-ce qu'une mauvaise, et pourquoi. On n'est plus dans le constat, on est dans le pilotage.
On ne lance pas la production en espérant que ce soit bon.
Un chiffre non mesurable n'est jamais remplacé par zéro
Un produit sans prix d'achat n'a pas une marge nulle, il a une marge inconnue, et l'écran le dit.
Toute réserve est annoncée
Si l'historique est trop court pour établir une tendance, elle n'est pas calculée, et la raison est écrite à côté du chiffre.
Les modèles employés sont des modèles ouverts
Les données comme les modèles sont hébergés en France et en Europe. Les données de l'entreprise ne sont jamais confiées au service d'un éditeur d'intelligence artificielle, et aucune ne sert à entraîner quoi que ce soit.
Les données ne changent pas de place
Les agents travaillent là où elles sont, y compris chez l'entreprise si c'est là qu'elles vivent : il n'y a donc pas de déménagement à décider avant de commencer. Le modèle étant ouvert, elle peut de la même façon l'héberger ailleurs, à condition d'en avoir les machines.
Chaque société possède sa propre clé d'accès
L'entreprise est déduite de cette clé côté serveur : aucune requête, même formée à la main, ne peut désigner une autre entreprise que la sienne.
Née ici. Devenue un point de départ.
Ce projet ne s'est appuyé sur aucune brique existante. Il n'y en avait pas. Ce que nous avions, c'était une connaissance des ERP et une pratique de la construction d'agents : une façon de produire, pas un produit.
Ce qui en sort est une brique qui n'existait pas. Les critères de déclenchement sont nombreux et entièrement paramétrables par l'entreprise, ce qui rend l'ensemble transposable à d'autres activités.
Ce qui change d'une maison à l'autre, c'est la structure de la base, le nom des tables et des champs, les statuts que portent les documents, et surtout les règles de gestion propres au métier.
La vraie condition est ailleurs : il faut que l'ERP en face accepte qu'on vienne lire chez lui.
Le fond du problème, lui, se ressemble.
Vous n'avez peut-être ni le même ERP ni le même métier. Mais si vos données sont justes et que les questions ne sont posées qu'une fois le problème constaté, le fond est le même. Voir comment nous l'abordons, ou parlez-nous directement de votre situation.
Parler de ma situation →