Le module commandes de ton logiciel n'a pas été conçu pour commander

Le module commandes de ton logiciel n'a pas été conçu pour commander

En bref

• Un module commandes inclus dans un logiciel de caisse, de salle ou de stock optimise le flux pour lequel ce logiciel a été dessiné : la commande au fournisseur est arrivée après, et ça se sent quand tu t'en sers.
• La vraie contrainte, ce n'est pas le nombre de références que tu commandes, ce sont les règles que chaque fournisseur amène avec lui — fenêtre de commande, format de la mercuriale, cadence de livraison.
• WhatsApp n'est pas le désordre : c'est la compensation manuelle d'un travail qu'aucun outil ne tient à ta place.
• Un outil né pour les commandes part du fournisseur et du calendrier, pas du référentiel articles.
• Changer d'outil n'améliore pas tes relations fournisseurs et ne fait pas baisser les prix tout seul : ça déplace le travail de la mémoire des gens vers le système.

Pourquoi le module commandes « inclus » te semble toujours à moitié fini

Le module commandes d'un logiciel de gestion généraliste a été dessiné autour d'un autre flux : encaisser, faire tourner les tables, tenir les réservations, sortir le stock. La commande au fournisseur est arrivée ensuite, comme une conséquence du stock — quand le stock passe sous un seuil, quelqu'un doit acheter — et cette généalogie se voit dans la façon dont le logiciel est fait à l'intérieur.

Le signe le plus clair, c'est la place du fournisseur dans les données. Dans un logiciel né pour le stock, le fournisseur est un attribut de l'article : un champ « fournisseur par défaut » dans la fiche produit. Ça marche tant que chaque article a un seul fournisseur. Puis arrive la semaine où tu prends les pommes de terre chez le deuxième primeur parce que le premier est en rupture, et tu t'aperçois que ce champ n'a pas été pensé pour contenir un choix, mais un référentiel.

Les logiciels de procurement que tu trouves aujourd'hui en cherchant ce sujet — Procurify, Order.co et compagnie — n'ont pas ce problème, parce qu'ils viennent des achats. Ils en ont un autre : ils viennent des achats d'une entreprise quelconque, où l'on commande des fournitures de bureau et des licences logicielles, pas des caisses de poisson qui doivent être en cuisine avant sept heures. Un restaurant n'a besoin ni d'un module commandes générique ni d'un procurement générique : il a besoin d'un outil qui connaisse la forme de ses commandes.

Le jeudi soir sur WhatsApp — le flux que tu remplaces vraiment

Le flux réel d'un restaurant qui commande à la main n'est pas désordonné : il est éparpillé. WhatsApp pour le frais, un appel au boucher qui ne décroche qu'avant onze heures, un PDF par mail pour les boissons, et aucun des trois canaux ne sait ce que les deux autres ont fait. Prenons une scène type, annoncée pour ce qu'elle est — un exemple, pas une étude de cas : jeudi soir, fermeture, et le second envoie trois messages vocaux à trois fournisseurs différents pendant qu'il éteint les friteuses.

Ce que ce flux tient ensemble, ce ne sont pas les messages, c'est la mémoire des gens. Quelqu'un sait que le primeur clôture les commandes à 18 h et qu'il ne livre pas le lundi. Quelqu'un sait que la mercuriale du poissonnier, c'est celle envoyée dans la conversation il y a quinze jours, pas celle imprimée et punaisée en réserve. Quelqu'un se souvient que le prix du beurre avait été négocié autrement que ce qui figure sur le bon de livraison. Tant que cette personne est là, le système tient.

Le coût ne se voit pas sur une commande ratée, il se voit à la réception et en fin de mois. Le bon de livraison arrive, quelqu'un le signe vite parce que le chauffeur attend, et le rapprochement avec le prix convenu — s'il a lieu — a lieu des semaines plus tard, sur la facture, quand la marchandise est déjà passée en cuisine. WhatsApp n'est la cause de rien : c'est la prothèse que ce travail s'est fabriquée tout seul.

Fenêtre de commande, mercuriale, cadence : les trois contraintes que ton logiciel ne modélise pas

Chaque fournisseur amène trois règles à lui, et ce sont elles — pas le nombre de références — qui donnent aux commandes une forme que le stock n'a pas. La première est la fenêtre de commande : l'intervalle pendant lequel la commande est encore acceptée pour la livraison suivante. Ce n'est pas un horaire écrit quelque part, c'est un état qui change au fil de la journée : à 17 h cette commande part demain, à 19 h elle part après-demain, et la différence, c'est le service du soir qui la paie.

La deuxième est le tarif fournisseur — la mercuriale — qui en restauration n'est pas un fichier, c'est une espèce. L'un te l'envoie en PDF, l'autre en Excel, un troisième en photo d'une feuille écrite à la main, le quatrième ne l'envoie pas du tout et te donne ses prix au téléphone. Un module commandes générique présuppose un catalogue stable avec des prix déjà chargés ; ton mareyeur, lui, a des prix qui bougent avec le marché, et le document qui les porte change de format chaque fois que le commercial change.

La troisième est la cadence de livraison : celui qui passe trois fois par semaine, celui qui vient le mardi et le vendredi, celui qui ne livre que sur appel avec deux jours de préavis. Prises une par une, ce sont des évidences que n'importe qui en cuisine gère les yeux fermés. Prises ensemble, multipliées par le nombre de fournisseurs que tu as, elles forment un calendrier que personne n'a jamais écrit et qui vit entièrement dans la tête de deux ou trois personnes. Le module commandes ne le modélise pas parce qu'il ignore qu'il existe : pour lui, il y a un seuil de réapprovisionnement et un fournisseur par défaut.

Ce que fait un outil né pour les commandes

Un outil né pour les commandes part du fournisseur et du calendrier au lieu du référentiel articles, et ça change les décisions produit une par une. Le panier n'est pas unique : il y en a un par fournisseur, parce que l'unité de travail réelle, c'est la commande qui part chez une contrepartie, pas la liste de courses globale. La fenêtre de commande n'est pas un rappel, c'est un état du système : si elle est fermée, tu le vois pendant que tu composes la commande, pas après l'avoir envoyée.

La mercuriale cesse d'être une pièce jointe et devient une donnée vivante, avec une histoire : le prix d'aujourd'hui, celui de ta dernière commande, et l'écart entre les deux, que quelqu'un doit avoir sous les yeux avant de valider et pas en fin de mois. C'est la même raison qui fait que la commande récurrente n'est pas un modèle à remplir de zéro chaque semaine, mais le point de départ : la semaine dernière tu as commandé ça, change ce qui doit changer et envoie.

C'est aussi la raison pour laquelle un outil pareil est obsédé par le téléphone. Les commandes ne se passent pas assis à un bureau à neuf heures du matin : elles se passent debout, à une main, entre deux services. Un module pensé pour le back-office d'un logiciel de gestion peut se permettre d'être dense ; un outil de commandes, non, parce que son vrai concurrent n'est pas un autre logiciel, c'est un vocal WhatsApp qui coûte dix secondes.

Comment savoir si le module que tu as te coûte quelque chose

Les signaux se lisent sur tes documents de cette semaine, pas sur un questionnaire de maturité numérique. Prends les sept derniers jours et vérifie :

• Où est la mercuriale à jour de chacun de tes fournisseurs principaux ? Si la réponse, pour au moins un d'entre eux, est « dans une conversation » ou « c'est Marc qui sait », ce prix n'est dans aucun système.
• Qui connaît les fenêtres de commande par cœur ? Si le nombre de personnes capables de commander sans demander à quelqu'un est de un, tu as une contrainte de personnel déguisée en procédure.
• Combien de bons de livraison de la semaine ont été rapprochés du prix attendu avant d'être signés ?
• Combien de commandes de cette semaine n'existent que sous forme de message envoyé, sans copie dans un endroit où les retrouver dans un mois ?
• À quand remonte la dernière fois où ton module commandes t'a empêché de te tromper — un fournisseur déjà fermé, un prix qui avait bougé, une quantité hors échelle ?

La dernière question compte plus que les autres. Un outil qui enregistre des commandes fait de l'archivage ; un outil qui t'arrête avant l'erreur fait le travail.

Ce qu'un outil dédié ne résout pas

Un outil dédié aux commandes n'améliore pas tes relations avec tes fournisseurs, ne fait pas baisser les prix tout seul et n'enlève la négociation à personne. Si le prix du beurre est haut parce que ton volume est celui qu'il est, il reste haut dans une appli bien faite — avec cette différence, pas mince, que tu le vois maintenant au moment de commander au lieu de le découvrir à la clôture du mois.

Et il a un coût d'entrée réel, qui mérite d'être regardé en face avant de signer : le référentiel articles et les mercuriales doivent être chargés une première fois, puis maintenus quand un fournisseur ou un format change. C'est le travail que tu fais déjà aujourd'hui, mais dispersé en cent gestes minuscules qui n'ont pas l'air d'un travail parce que personne ne les a jamais comptés ensemble. La question à se poser n'est pas de savoir si ce travail existe : c'est de savoir si tu préfères qu'il vive dans un système ou dans la tête de ton second, le jour où ton second est en congés.