Un bloc ouvert en coupe révélant un processus avec des stations reliées entre elles, au-dessus quatre étapes numérotées de la loupe au graphique puis à l'engrenage et à la cible, à côté un bloc-notes avec un tableau manuscrit
Retour au blog
Optimisation de processusRéférenceIntégration ERP

Anatomie d'une optimisation de processus : pourquoi personne ne croyait plus son propre logiciel

Sven HennessenProcessus

Les quatre étapes de notre optimisation de processus sonnent toujours bien sur la page de prestations. Nous les parcourons ici honnêtement, sur un projet réel dans le négoce de pièces détachées : du tableur qui constituait en réalité le diagnostic, au cycle de commande récurrent dans quatre sociétés qui sont à la fois fournisseur et client l'une pour l'autre, jusqu'à la question de savoir comment mesurer le succès quand aucun chiffre ne l'exprime. L'erreur la plus coûteuse n'était pas que le logiciel calculait faux, mais que personne ne pouvait retracer pourquoi.

Sur notre page consacrée à l'optimisation de processus figure une question que nous posons tôt ou tard à chaque client : que nous coûte ce processus chaque mois, et que se passerait-il s'il était 20 à 30 pour cent plus efficace ?

Chez un grossiste en pièces détachées d'une soixantaine de collaborateurs et de quatre sociétés dans la région DACH, cette question n'était pas le point de départ. Les coûts étaient connus dans les grandes lignes : trop de capital immobilisé dans des articles dont personne n'avait besoin, et des ruptures sur ceux qui étaient justement demandés. Le véritable problème était ailleurs. Les achats ne croyaient plus leur propre logiciel de planification des commandes.

Cet article parcourt une fois les quatre étapes de cette page sur ce projet. Non pas comme un exposé de méthode, mais tel que cela s'est réellement passé.

Pourquoi le processus le plus coûteux est rarement celui que l'on touche

Presque chaque entreprise sait quel déroulement génère le plus de frictions. Seulement, cette friction est rarement traduite en chiffre, et sans chiffre il n'y a pas de priorité.

Une des raisons se trouve dans les données. Selon l'étude Bitkom sur la digitalisation de l'économie 2026, menée auprès de 604 entreprises de 20 salariés et plus, 61 pour cent n'exploitent guère ou pas du tout le potentiel de leurs données. Seules 5 pour cent en tirent tout. La seconde raison est encore plus banale : 66 pour cent citent le manque de temps en interne comme obstacle à la digitalisation. Qui doit lancer des commandes chaque jour n'analyse pas le processus de commande en parallèle.

C'est exactement pour cela que le cas problématique connu subsiste. Non pas parce que personne ne le voit, mais parce que personne ne le calcule.

Étape 1 : comprendre le processus, c'est trouver le monde parallèle

La première étape s'appelle chez nous « comprendre le processus », et elle ne consiste pas à dessiner une belle cible. Elle consiste à trouver le processus qui tourne réellement.

Les quatre questions correspondantes sont sans éclat : qui est impliqué ? Où naissent les temps d'attente ? Qu'est-ce qui se fait manuellement ? Où les données sont-elles saisies une seconde fois ?

Mais le chemin le plus rapide vers la réponse est un autre, devenu chez nous la question de diagnostic la plus importante : est-ce que quelqu'un tient sa propre liste à côté du système ? Là où un tableur tourne en parallèle du logiciel se trouve le vrai processus. Ce tableur n'est pas une négligence, c'est un diagnostic. Il montre précisément quelle part de son travail une personne ne confie pas au système, et le plus souvent elle sait très exactement pourquoi.

Chez le grossiste, la réponse était sans ambiguïté. Les achats planifiaient leurs commandes dans leurs propres tableaux, alors qu'un logiciel de planification établi tournait et calculait dans la maison. L'objet de l'investigation était ainsi trouvé. Non pas le logiciel, mais l'écart entre le logiciel et la décision.

Étape 2 : identifier les facteurs de coûts

La deuxième étape consiste à rendre visibles les endroits les plus coûteux et à les prioriser. Dans les déroulements riches en documents et en décisions, les mêmes catégories reviennent presque toujours : traitement des devis et des commandes, vérification des factures, reporting, réclamations, validations, stockage et livraison.

Dans le processus de commande, les coûts se situent de deux côtés, et le second est régulièrement oublié.

D'un côté, il y a le capital immobilisé. Chaque article qui se trouve en rayon trop tôt ou en quantité trop importante immobilise de l'argent qui pourrait travailler ailleurs, et génère des coûts de stockage, de manutention et de dépréciation. Ce côté se calcule dès lors que vous connaissez votre valeur de stock moyenne et votre taux d'intérêt calculatoire. Les deux figurent dans votre comptabilité.

De l'autre côté, il y a la rupture de stock, et celle-ci n'apparaît sur aucun compte. Un article qui manque au moment où un client en a besoin coûte du fret express, des relances au commerce, des commandes reportées et, dans le pire des cas, le client lui-même. Il n'existe aucune écriture pour ces coûts, c'est pourquoi ils n'apparaissent dans aucune analyse. C'est précisément ce qui les rend si chers.

Un chiffre solide n'émerge ici qu'avec vos propres valeurs, pas avec des moyennes sectorielles. Quels indicateurs s'y prêtent et lesquels ne font que rassurer, nous l'avons détaillé dans Optimiser, réinventer ou abandonner ?.

Le problème n'était pas le calcul erroné, mais l'inexplicabilité

C'est là que le projet est devenu intéressant, car la perte de confiance avait une histoire.

Le logiciel standard en place avait, dans le passé, calculé des propositions de commande manifestement fausses. À l'origine, non pas un mauvais logiciel, mais la complexité de son implémentation : beaucoup de paramètres, beaucoup d'hypothèses, beaucoup d'endroits où une configuration ne correspondait pas à la réalité du négoce de pièces détachées. S'y ajoutait que le résultat n'était pas traçable. La proposition était là, mais pas la manière dont elle était née.

Et de là naît la chaîne qui a rendu le processus vraiment coûteux au bout du compte :

  1. Un logiciel standard porte un processus clé dont la logique dépend fortement de l'entreprise.
  2. L'implémentation devient complexe, car chaque particularité doit être traduite en paramètres.
  3. Des propositions erronées apparaissent.
  4. Le résultat n'est pas traçable, donc l'erreur n'est pas imputable.
  5. Comme personne ne trouve la cause, personne ne peut y remédier.
  6. Les achats se construisent un monde parallèle dans lequel ils comprennent eux-mêmes le calcul.

Le point décisif se situe à l'étape quatre. Une proposition erronée à elle seule ne détruit pas la confiance. Une proposition erronée que vous ne pouvez pas expliquer, si. Face à une erreur explicable, vous vérifiez les données de base, corrigez un paramètre et poursuivez. Face à une erreur inexplicable, vous ne savez pas si le paramétrage est en cause, la qualité des données, ou le modèle de calcul lui-même. Vous ne faites donc plus confiance à la proposition suivante non plus, même lorsqu'elle est juste.

Que ce schéma ne soit pas un cas isolé, le regard sur l'automatisation en général le montre. Dans le State of Agentic Orchestration and Automation Report 2026 de Camunda, 71 pour cent des entreprises exploitent des agents IA dans des projets pilotes, mais seulement 11 pour cent en production sur de vraies décisions. 85 pour cent manquent de la maturité de processus nécessaire à ce pas, et 48 pour cent rapportent que leur automatisation tourne isolément à côté du processus réel. Le schéma est le même que chez le grossiste : la puissance de calcul n'a jamais été le goulot d'étranglement. La traçabilité l'était.

Étape 3 : optimiser de façon ciblée, et à la racine

De ce diagnostic a découlé une décision que nous avons prise conjointement avec le client : l'ancienne solution n'a pas été complétée, elle a été remplacée.

La raison est la même que celle pour laquelle le processus ne fonctionnait pas auparavant. On ne peut pas plaquer de la transparence sur un calcul opaque. On peut placer une meilleure interface devant et des analyses supplémentaires à côté, mais la boîte noire reste et se traîne avec. Si la traçabilité est le véritable objectif, elle doit naître dans le calcul lui-même.

Ce qui a donc été construit est une application web avec prévision statistique des besoins et connexion aux deux systèmes ERP, qui décompose les articles de vente sur plusieurs niveaux en leurs composants d'achat, afin que les propositions de commande naissent là où l'on commande effectivement. Quatre éléments ont été déterminants :

  • Chaque proposition de commande expose son fondement. Consommation moyenne, stock de sécurité, délai de réapprovisionnement et stratégie appliquée sont visibles, résultats intermédiaires inclus. Les achats peuvent vérifier chaque proposition, la commenter et l'ajuster avec leur expertise, au lieu d'y croire ou de l'ignorer.
  • Des cycles hebdomadaires coordonnés plutôt que des décisions ad hoc. Les quatre sociétés commandent selon un rythme commun et concerté.
  • Validation par la direction avant le déclenchement. Rien ne part automatiquement. La direction garde le contrôle sans devoir vérifier chaque article individuellement.
  • Connexion en direct aux deux ERP. Les données de stock et de commandes alimentent la prévision en temps réel, et non depuis un export de la semaine dernière.

À l'intérieur de cette troisième étape, le déroulement construit ressemble à ceci, un cycle de cinq stations qui redémarre dans chaque société :

Cycle récurrent par société : import des données ERP du jour, calcul selon les algorithmes choisis, validation par le responsable des achats, négociation du prix avec le fournisseur, proposition de commande dans l'ERP. Les autres sociétés apportent le besoin en tant que client et les conditions en tant que fournisseur.

La particularité se trouve dans l'encadré en marge. Les quatre sociétés sont simultanément fournisseur et client l'une pour l'autre. Ce qui apparaît comme besoin dans l'une devient livraison dans l'autre, et les conditions correspondantes sont négociées en interne. C'est précisément pour cela que la planification des commandes ne fonctionne pas ici comme quatre calculs indépendants. Lorsque les quatre calculent au même moment selon la même méthode, leurs commandes ne s'additionnent plus par hasard mais entrent dans la discussion avec le fournisseur comme une image concertée.

Le dernier point de la liste est celui qui rend la solution viable, et il n'a rien à voir avec le calcul. En matière d'automatisation intelligente des processus, nous procédons de la même manière : le système prépare et propose, la validation critique reste chez l'humain. Qui porte la responsabilité a besoin de contrôle, sinon il n'utilise pas le système.

Étape 4 : mesurer le succès, y compris là où aucun chiffre n'existe

La quatrième étape est la comparaison avant-après. Chez le grossiste, du côté des faits mesurables :

RésultatAvant
Circuit de validation en moins d'une journée, de la proposition à la commande validéeAucun processus de validation en place
Quatre sociétés commandant selon un cycle communQuatre sociétés sans rythme commun
Deux systèmes ERP en direct dans la prévisionMaintenance manuelle des données sur des bases obsolètes

L'indicateur qui nous en dit le plus ne figure toutefois dans aucun tableau : les tableaux parallèles ont disparu. Tant que quelqu'un calcule encore en parallèle, l'optimisation n'est pas arrivée, quoi qu'affirme le tableau de bord. La phrase à laquelle nous mesurons ce projet est venue du responsable des achats : « Nous savons enfin pourquoi le système commande ce qu'il commande. » Toute l'histoire figure dans notre référence Optimisation des commandes avec prévision transparente ; la solution elle-même est désormais disponible sous le nom de Visposition.

L'honnêteté exige aussi l'autre côté. Dans l'enquête Bitkom, 45 pour cent des entreprises utilisant l'IA rapportent des processus internes accélérés, mais 33 pour cent rapportent également des coûts plus élevés que prévu. C'est pourquoi nous mesurons avant le démarrage et pas seulement après. Sans mesure de départ, il n'y a pas de preuve ensuite, seulement des affirmations dans les deux sens.

Le même déroulement, un autre processus

Le schéma n'est pas lié à l'approvisionnement. Dans une entreprise agroalimentaire de taille moyenne, chaque demande de service passait par cinq stations : service client, administration des ventes, technique, ordonnancement et facturation. Tous travaillaient sur le même dossier, mais pas dans le même système. Les transmissions se faisaient par e-mail, tableur et téléphone, à travers trois systèmes ERP hérités du temps.

Là aussi, le facteur de coût n'était pas le traitement individuel, mais la transmission entre les étapes. Et là aussi, les postes les plus importants se situaient en dehors de toute analyse : des recours auprès des fournisseurs qui se perdaient dans le quotidien. Au bout du compte, il s'agissait de pertes annuelles à cinq chiffres qui n'étaient auparavant pas mesurables. Aujourd'hui, les trois systèmes ERP convergent dans un workflow continu, et un ticket est traité en moins d'une journée. À lire dans la référence La gestion des tickets de service repensée de bout en bout.

Deux secteurs, deux processus complètement différents, la même cause : des informations qui n'accompagnent pas le processus, et des résultats que personne ne peut expliquer.

Quatre questions pour votre processus

Si vous voulez transposer cela à un déroulement qui vous est propre, quatre questions suffisent pour commencer :

  1. Est-ce que quelqu'un tient sa propre liste à côté du système ? Si oui, quelle part du travail ne confie-t-il pas au système ?
  2. Quelqu'un peut-il expliquer comment le système arrive à son résultat ? Si non, chaque erreur est une erreur insoluble.
  3. Quels coûts de ce processus n'apparaissent dans aucune écriture ? Fret express, reprises, commandes reportées, commandes perdues.
  4. Quelqu'un sait-il où en est un dossier sans avoir à demander ? Chaque relance nécessaire est un point de mesure.

Qui peut répondre à ces quatre questions pour son processus le plus important n'a plus besoin d'une étude pour savoir où l'argent reste sur la table. Et n'a le plus souvent pas besoin d'un grand projet pour le récupérer.

Sources

Besoin d'aide ?

Vous avez en tête un processus pour lequel vos collaborateurs tiennent encore leurs propres listes à côté du système ? C'est précisément là que nous commençons. Parlez-nous-en et nous regarderons ensemble ce qui se cache derrière : des résultats erronés, un manque de traçabilité, ou simplement un déroulement qui n'a jamais été conçu ainsi.

Nous contacter