Un carton contient encore vingt paires de gants. Le chiffre est juste. Il peut même être parfaitement à jour.

Il manque pourtant une information beaucoup plus utile : est-ce que ces vingt paires vont tenir deux jours ou trois semaines ?

C’est là que la gestion de stock devient bizarre. On pense d’abord à un problème de comptage. On finit avec un problème de temps.

Le nombre immobile

Un inventaire classique produit une photographie.

Il dit qu’il reste 20 boîtes, 8 cartouches, 3 bobines ou 47 pièces. Un tableur peut très bien conserver cette photographie. Une feuille de papier aussi, avec une endurance à la panne de serveur assez humiliante pour l’industrie du SaaS.

La photographie vieillit dès que quelqu’un prend quelque chose.

Ce décalage entre quantité physique et quantité enregistrée est suffisamment fréquent pour avoir son propre champ de recherche. Une étude publiée en 2008 sur près de 370 000 enregistrements de stock dans 37 magasins d’un même distributeur trouvait 65 % d’enregistrements inexacts.2 Le contexte est celui d’une grande chaîne de détail, pas d’un atelier de six personnes. Le chiffre ne se transpose donc pas honnêtement à une petite équipe. Mais le mécanisme est familier : une information de stock ne reste correcte que si les gestes qui la modifient arrivent aussi dans le système.

Faire un grand inventaire tous les mois corrige l’écart. Puis le compteur recommence à dériver.

Le problème de conception devient alors moins spectaculaire : comment enregistrer un mouvement sans transformer chaque paire de gants utilisée en mini-déclaration fiscale ?

Le geste perdu

C’est le point de départ d’Invumi.

L’interface principale n’essaie pas de faire ressembler un petit atelier à un entrepôt de 40 000 m². Elle essaie surtout de rendre le mouvement assez léger pour être noté lorsqu’il se produit : ouvrir le produit, ajouter ou retirer une quantité, repartir.1

Cette idée paraît presque trop simple. Elle conditionne pourtant tout le reste.

Une prévision calculée sur une histoire fausse produit seulement une erreur mieux habillée. Un seuil d’alerte basé sur une quantité que personne ne met à jour attendra poliment pendant que l’étagère se vide. Même un très joli graphique reste un graphique de fiction si son entrée est mauvaise.

Une partie de la recherche récente sur le réapprovisionnement explore justement l’intérêt de données captées au point de consommation lorsque les registres de stock sont imparfaits.3 Les systèmes étudiés sont plus techniques qu’un téléphone posé dans un studio, mais le déplacement est intéressant : mieux vaut rapprocher la mesure du moment où le stock change que demander ensuite à quelqu’un de reconstruire ce qui s’est passé.

Le seuil aveugle

Supposons maintenant que les quantités soient bonnes.

On peut définir un seuil : « préviens-moi lorsqu’il reste dix unités ». C’est déjà utile. C’est aussi aveugle à la vitesse.

Dix unités peuvent être confortables pour un produit utilisé une fois par mois. Elles peuvent être une urgence pour un consommable qui part quinze fois par jour et met une semaine à revenir du fournisseur.

Invumi conserve donc le seuil, mais ajoute une estimation construite à partir de l’historique des mouvements.1 La nuance importante est moins l’algorithme que son droit de se taire. La page publique du produit précise que la prévision n’est affichée que lorsque l’historique est suffisant.1

Ce détail résume assez bien le choix de produit.

Un logiciel qui ne sait pas devrait pouvoir afficher « je ne sais pas ». Sur un écran de suivi, c’est presque une fonction premium tant les interfaces ont pris l’habitude de produire un nombre même lorsqu’elles n’ont rien de sérieux à dire.

La prédiction ne remplace donc pas le seuil. Elle ajoute une deuxième question : à quelle vitesse est-ce qu’on s’en approche ?

Acheter juste assez

L’autre moitié du problème arrive au moment de commander.

Savoir qu’un produit est trop bas ne dit pas encore combien acheter. Le besoin dépend de la quantité actuelle, de la quantité cible et du rythme attendu avant le prochain réassort.

Pour une petite équipe, le système peut rester volontairement banal : une cible par produit, une liste des éléments sous leur seuil, puis une quantité à ramener vers cette cible. Invumi groupe cette information dans la partie achat au lieu de demander de parcourir chaque fiche une par une.1

L’intérêt n’est pas d’automatiser l’achat jusqu’au fournisseur. Pas encore. C’est de réduire le moment absurde où quelqu’un ouvre trois onglets, une feuille Google Sheets, le site du fournisseur et peut-être une photo prise la semaine précédente pour décider s’il faut commander 4 ou 14 boîtes.

Ce petit moment administratif est précisément le genre de friction qui devient coûteuse parce qu’elle est trop petite pour mériter un vrai projet d’organisation.

Savoir s’arrêter

Invumi ne cherche pas à devenir un WMS complet.

Le produit vise les petites équipes. Il suit des produits, leurs mouvements, les seuils, les quantités cibles et une prévision lorsque les données le permettent.1 Des besoins comme les lots complexes, le picking avancé ou l’EDI appartiennent à une autre catégorie d’outils. Les ajouter pour avoir une grille de fonctionnalités plus impressionnante rendrait probablement le produit moins utile à la personne qui veut juste savoir si elle doit recommander des gants aujourd’hui.

C’est aussi la limite de cet article.

Ce retour de conception peut expliquer pourquoi Arthur a construit le produit de cette manière et à quel problème chaque choix répond. Il ne peut pas transformer cette expérience en preuve qu’Invumi convient à toutes les petites entreprises, ni faire comme si une étude menée dans le retail validait directement le comportement d’un studio, d’un fablab ou d’un petit commerce.

Le test intéressant est plus simple : est-ce que l’équipe continue réellement à enregistrer ses mouvements après deux semaines ? Est-ce que les quantités restent assez proches du réel pour que les alertes soient utiles ? Est-ce qu’une commande prend moins de décisions inutiles qu’avant ?

Si ces trois choses ne se produisent pas, le graphique prédictif pourra être très joli. Il décorera simplement une mauvaise base de données.

Le produit ici

C’est pour ce problème précis qu’Arthur a construit Invumi, une gestion de stock prédictive pour petites équipes, qui part du mouvement réel, signale les niveaux faibles et essaie d’estimer la rupture avant qu’elle soit visible sur l’étagère.1

Il y a des fonctions plus faciles à vendre dans une capture d’écran. Je préfère celle-ci : quand les données ne suffisent pas, la prévision n’apparaît pas.

Un bon stock n’a pas besoin de prétendre connaître l’avenir. Il doit simplement éviter de découvrir le passé au moment d’ouvrir le dernier carton.