Quinze ans à modéliser un métier que je connaissais déjà

Posté le lundi 10 août 2026
Quinze ans à modéliser un métier que je connaissais déjà

En avril dernier, j’ai eu l’opportunité de me rendre à Devoxx France 2026. Parmi les conférences que j’ai pu voir, celle de Cyrille Martraire m’a particulièrement marquée, “Explorer en profondeur un domaine en explorant les publications scientifiques”, et je ne savais pas encore que j'allais y découvrir ce qui manquait à GLSR depuis quinze ans. 

Étonnamment, vu l’actualité du monde IT à ce moment-là, notre conférencier ne parle pas d’agent IA, mais de simples recherches dans des publications scientifiques, et autres papiers académiques. 

En tant que Dev, notre travail consiste à apporter des solutions à une problématique d’utilisateur dans un domaine que l’on ne connaît pas. Et c’est là qu'entrent en jeu les papiers académiques que produisent des experts d’un domaine. Je ne vais pas vous refaire la conférence, Cyrille fait cela beaucoup mieux que moi, et il est plutôt drôle à regarder. Le principal à comprendre, c’est qu’il existe des astuces pour avoir accès aux informations sans pour autant lire des pages et des pages de rapports, de graphiques, tout en récupérant les notions qui nous intéressent. 

Papiers académiquesLe secret est avant tout dans les mots-clés à ajouter dans la recherche, qui vont diriger les moteurs. Le premier cité par Cyrille est “citation”, qui va filtrer sur ces publications. Il y a aussi Google “scholar” qui référence les papiers académiques parmi ces outils. Mais comme pour les réponses de vos agents IA préférés, il faut vérifier ce qui ressort de la liste. Ensuite, plus le document paraît ennuyeux, plus il est susceptible de donner les références que l’on cherche. 😉 Une fois le document trouvé, il suffit de lire l’abstract, qui va résumer le tout avec des éléments de langage qui nous intéressent, un peu comme le frontmatter d’un fichier destiné à un agent IA. 

Ce faisant, l’idée m'est venue de tester sur un domaine que je connais bien et en rapport avec mon projet de toujours, la gestion des stocks d’un restaurant (GLSR). Premier constat, je visais trop large pour avoir des résultats corrects. La gestion des stocks d’un restaurant donne beaucoup de choses, mais rien d’exploitable. Comme le précise notre conférencier, la recherche doit partir d’une question simple, pour canaliser le sujet. Je me suis donc cantonné à un point important de cette gestion de stock, à savoir “comment suivre la durée de vie des produits alimentaires ?”. 

La recherche fut plus fructueuse. Aidé de mon ami Claude, parce qu’un dialogue est plus riche que de réfléchir tout seul, le langage s’est découvert au fil de la discussion. Un point relevé dans la conférence, et que j’ai constaté, c’est qu’avec le langage arrivent aussi les intentions qui y sont attachées. Le même élément ne porte pas le même nom, ni les mêmes préoccupations suivant qui en parle. Lors de la réception, le livreur et le chef cuisinier ne parlent pas de la même chose devant le même carton. Ce sont deux mondes qui manipulent la même chose sans la voir pareil. Dans le jargon tech, on appelle ça un contexte délimité (Bounded Context).

Pour mon stock, une distinction s’est démarquée entre la réception d’un article et sa consommation. Un article qui entre dans le stock va porter une quantité, une date limite de consommation (DLC), un prix et le fournisseur de chez lequel il provient. Alors que dans la cuisine, un ingrédient va porter la quantité en stock global, un prix pondéré (une moyenne des prix à chaque livraison) ou en FIFO (déterminé par ordre d’arrivée). 

Un schéma se dessine, et des éléments émergent pour pouvoir passer les points de blocage. Comment déterminer le prix d’un ingrédient sachant que l’article qui entre n’a pas toujours le même prix ? Et c’est très régulier dans l’alimentaire, notamment pour les fruits et légumes. Donc une livraison, qui regroupe plusieurs articles, pourrait être représentée par des `Lot`, et c’est depuis ce `Lot` que l’on va pouvoir déterminer le coût d’un ingrédient. DLCC’est à ce moment-là que tout se démarque de ce que j’avais créé depuis quinze ans.

Au lieu de gérer un `Article` qui portait tous les éléments, son nom, un fournisseur, le packaging, qui regroupe les unités et quantités qui composent le colisage, la catégorie (une famille logistique), son prix, sa quantité totale et son stock minimum, ce gros objet boulimique doit être découpé pour refléter les besoins. Donc une livraison va concerner un `Lot` qui va porter l'`Article` qui devient un objet minimal, une quantité, une DLC, la date de livraison et un `SupplierReference`, qui porte le packaging (répartition du colisage) et le prix unitaire. Le `SupplierReference` permet à un `Article` d’être livré par plusieurs fournisseurs, un besoin qui n’était pas couvert avec l’ancien système. 

Le `Lot` va permettre de suivre la DLC de son article. Un nouveau service surveille les `Lot` dont la DLC approche. Il avertit le cuisinier des articles qu'il faut utiliser en priorité. Le MVP (Minimum Viable Product) est né. 

Mon application de gestion de stock de restaurant (GLSR), que j’ai développée au départ de la configuration pilotée par une section d’administration, qui va créer chaque élément de l'application (`Article`, `Supplier`, `Unit`, `LogisticFamily`…), à laquelle s’est ajouté un module d’inventaire, avait le code designé de la même manière. Donc, mon application devait bouger pour refléter le modèle que je venais de créer. 

Quand on crée un produit, on a très souvent l’idée finie en tête, mais développer ce genre de solution est très long avant d’avoir quelque chose de fonctionnel. Et c’est précisément le cas de GLSR, qui est, dans ma vision finale, un condensé des outils que j’ai utilisés pendant ma carrière en restaurant. Autant le dire, c’est un mastodonte à créer. 

La finalité de cette discussion est un document de travail qui débouche sur une refonte complète du code, et un design d’application, version ERP. Mais cela fera l’objet d’un nouvel article.

Cette discussion m’émerveille en me faisant découvrir comment peut émerger un produit viable, pour commencer, qui pourra évoluer ensuite. En même temps, cela fait maintenant cinq ans que je suis professionnel du développement, alors que GLSR en a quinze. Aujourd’hui, mon travail dirige beaucoup ma façon de créer, contrairement à ma période d’apprentissage en autodidacte où j’avais la connaissance du métier, pour l’avoir vécue. Ce qui me manquait, c’était une méthode pour l’interroger. 

Photo de olga safronova sur Unsplash