Comment enquêter sur un écart d’inventaire avant d’accuser le système

Il y a plus de vingt ans, j’ai reçu un appel auquel je pense encore. Environ 10 000 dollars manquaient à l’inventaire, les utilisateurs signalaient des erreurs, et le propriétaire avait déjà tiré sa conclusion : le système que nous venions de déployer ne fonctionnait pas.

Je dirigeais à l’époque une agence régionale d’intégration, et nous avions remporté un appel d’offres pour automatiser dix-sept stations-service. Les réclamations ont commencé après la mise en service, et une grosse somme avait disparu. Sa lecture n’avait rien de déraisonnable. L’enchaînement des faits nous désignait directement.

C’était aussi une affaire personnelle, comme les contrats le sont rarement. J’avais négocié le marché moi-même, et les propriétaires avaient lié le projet à ma personne plutôt qu’à l’entreprise derrière moi. À la réunion de clôture, ils m’ont serré la main en me disant, sans détour, qu’ils comptaient sur moi pour répondre de tout argent que le projet leur ferait perdre. Là où je travaillais, une poignée de main de ce genre pesait à peu près autant qu’une clause signée.

Notre première erreur : ne pas regarder la forme des réclamations

Le support enregistrait des incidents depuis des semaines. Personne n’avait posé la question évidente sur ce registre : s’agissait-il d’un seul défaut récurrent, de plusieurs défauts sans lien entre eux, d’un problème d’exploitation local, ou du même événement signalé encore et encore par des personnes différentes ?

C’est un piège classique de tout déploiement. Le système tombe en panne à coup sûr pendant que les gens travaillent, et se comporte parfaitement dès qu’un spécialiste se tient à côté d’eux. Si on le laisse s’installer, cet écart se transforme en méfiance mutuelle : les utilisateurs décident que le logiciel est défaillant, l’équipe d’intégration décide que les utilisateurs sont négligents, et personne ne regarde les faits.

Demandez-vous quelle forme a le problème, pas quelle est sa taille

Avant la réunion avec le propriétaire, j’ai demandé à notre équipe autre chose que le total. Cinq questions, sans rien d’astucieux :

• Où : dans laquelle des dix-sept stations se trouve l’écart, et comment chacune se compare-t-elle aux autres ?
• Quand : sur quelle période s’est-il accumulé, et a-t-il commencé avant ou après la mise en service ?
• Qui : quelles équipes, et quelles personnes y travaillaient ?
• Quoi : quelles catégories de produits, et qu’ont ces produits en commun, physiquement et commercialement ?
• Ailleurs : retrouve-t-on le même schéma sur un autre site qui tourne avec la même version ?

Ce que la ventilation a montré

Tous les signalements d’erreur venaient d’une seule station, sur une seule équipe. Le manquant, environ 10 000 dollars accumulés en un mois, n’était pas non plus réparti uniformément sur l’assortiment. Il se concentrait dans trois catégories : les cigarettes, les spiritueux haut de gamme et le chocolat. Des produits petits, chers, faciles à sortir d’un bâtiment sans que personne ne le remarque.

J’ai apporté les listings imprimés à la réunion, car c’était bien avant qu’on puisse afficher une ventilation sur son téléphone. Jusque-là, le propriétaire et moi regardions le même total et en tirions deux situations différentes. Lui voyait un déploiement raté sur tout son réseau. La répartition montrait que, quoi que ce soit, cela se passait sur un seul site, sur une seule équipe, dans un groupe de produits bien défini.

Le chiffre n’a pas changé pendant cette réunion. Ce qui a changé, c’est la part de l’entreprise qu’il mettait en cause, et donc l’endroit où chercher pendant la semaine suivante.

Une enquête ultérieure a confirmé que les pertes venaient de malversations délibérées et non d’une erreur de calcul. Je tiens à être précis sur ce que les données ont fait et n’ont pas fait. Elles n’ont rien prouvé. La preuve est venue des documents, des comptages de stock et des entretiens, et c’est bien de là qu’elle doit venir. Ce que la ventilation a fait, c’est orienter l’enquête vers un endroit où elle pouvait réellement trouver quelque chose.

Si l’explication était vraie, à quoi ressembleraient les données ?

Cette question est la partie de cette histoire dont je me suis le plus servi depuis, et pas seulement pour des manquants. Prenez l’explication qui est sur la table, supposez un instant qu’elle soit juste, et demandez-vous quelle trace elle devrait forcément laisser :

• Une erreur de calcul à l’échelle du système devrait apparaître sur tous les sites, toutes les équipes, tous les utilisateurs et toutes les catégories, puisque la même logique tourne partout. Elle se cantonne rarement à un coin du réseau.
• Un problème de formation ou d’utilisation suit généralement certaines personnes ou certaines équipes, et s’estompe sur les sites où la même version tourne avec une équipe expérimentée.
• Une erreur de paramétrage commence en général à la date où quelque chose a été modifié, et s’arrête aux sites où rien n’a été changé.
• Les pertes dues à des malversations se concentrent souvent sur des articles compacts, de valeur et faciles à emporter, et souvent sur une fenêtre de temps étroite.

Les chiffres actuels du commerce de détail vont dans le même sens. Dans la National Retail Security Survey américaine, les distributeurs attribuaient 36 % de leur démarque au vol externe, 29 % à leurs propres salariés et 27 % aux défaillances de processus et de contrôle et aux erreurs¹. Et un comptage qui contredit le système ne signifie pas toujours une perte : quand des chercheurs ont confronté les fiches de stock d’une chaîne alimentaire britannique à un comptage physique, 64,7 % d’entre elles ne correspondaient pas².

Rien de tout cela n’est un verdict. C’est une façon de décider par où une enquête doit commencer, ce qui est vraiment autre chose que de décider ce qui s’est passé. L’intérêt est d’écarter les explications dont on ne retrouve tout simplement pas les empreintes.

Dix réclamations ne font pas dix pannes

La même discipline vaut pour tout ce qu’un système signale. Dix réclamations peuvent être un seul défaut signalé dix fois. Une anomalie générée automatiquement peut être inhabituelle sur le plan statistique et sans importance sur le plan opérationnel, alors qu’un petit écart dans une catégorie sensible mérite de l’attention dès cette semaine. Le volume ne dit pas la gravité, l’écart-type non plus.

C’est là que je suis devenu méfiant envers les systèmes qui déclenchent des alertes sans aider personne à les évaluer. Une alerte qui dit qu’un chiffre a bougé laisse le lecteur exactement là où le propriétaire et moi en étions avant de sortir les listings. L’argument plus large, selon lequel le reporting doit passer de l’enregistrement de ce qui s’est passé à l’orientation de ce qu’il faut faire ensuite, je l’ai développé dans De la comptabilité à la navigation ; ce texte-ci porte sur une question plus étroite et plus pratique : comment lire une anomalie une fois qu’elle apparaît.

Ce que cela signifie pour les alertes de votre propre système

C’est la raison pour laquelle marql a été conçu pour répondre par la ventilation, pas seulement par le total. Quand un écart apparaît dans le stock, la marge ou la trésorerie, l’écran utile suivant est la répartition : quels sites, quelles périodes, quelles équipes, quelles catégories et quels fournisseurs. marql lit les systèmes de caisse, de comptabilité et de stock qu’une chaîne utilise déjà, avec un hébergement dans l’UE, et la question suivante n’est que le message suivant dans la même conversation, pas une nouvelle demande adressée à quelqu’un de la finance. C’est la friction dont j’ai parlé dans le coût caché du reporting manuel.

Les limites méritent d’être énoncées aussi clairement que les capacités. marql n’établit pas l’intention, ne remplace pas un comptage de stock et ne mène pas d’enquête. Ce qu’il fait, c’est mettre entre les mains d’un directeur des opérations ou d’un responsable financier les mêmes listings que ceux que j’apportais à cette réunion, en quelques minutes plutôt qu’après une semaine de relances, avec des tarifs à partir de 200 € par mois.