UX for Ops : Transformer un Proof of Concept logistique en outil de Change Management

Le coût d'une chaîne qu'on ne peut pas remonter

Entre le moment où j'ai décidé de traiter le sujet en urgence et sa mise en œuvre effective, l'entreprise a fait face à des suspicions de défaut qualité.

Sans traçabilité, aucune de ces suspicions n'était instruisable. Impossible d'identifier un lot, une matière, une série. La seule réponse disponible consistait à réexpédier gratuitement un produit neuf, sans jamais déterminer la cause. La perte est double : on paie le remplacement, et on paie une seconde fois en renonçant à corriger ce qui l'a provoqué.

C'est ce genre de situation qui rend une décision facile à porter. J'ai imposé cette exigence de traçabilité avec l'autorité de ma fonction, dans une entreprise qui n'avait jamais jugé utile de s'en saisir.

Trello rend visible, l'application collecte

Ce projet prolonge une méthode que j'applique depuis Bollé Safety, mais il en change la nature, et l'écart tient à qui doit remplir quoi.

Demander un brief structuré ou une synthèse analytique à un cadre du marketing n'est pas toujours simple, mais cela fait partie des attendus de son rôle. Demander la même chose à un opérateur de production ou à un technicien d'assistance, non. Ce n'est ni une question de compétence ni de bonne volonté, c'est une question d'adéquation entre l'outil et le métier.

Les difficultés d'organisation que j'ai rencontrées tout au long de mon parcours sont toujours multifactorielles : culture d'entreprise, gouvernance et propriété des sujets, organisation individuelle, maîtrise des outils, capacité d'abstraction, temps disponible, motivation. Certains de ces facteurs se font évoluer, d'autres demandent surtout de la résilience.

Choisir le bon outil et le bon paramétrage revient donc à trancher quatre questions : sur qui faire peser la gouvernance, comment rendre l'outil accessible à celui qui doit le remplir, quel niveau de donnée attendre de chacun, et comment l'insérer dans son organisation réelle. Le temps et la motivation, eux, se règlent généralement d'eux-mêmes une fois les trois premières bien posées. La culture, ensuite, évolue peu à peu.

Un tableau Trello enregistre une décision déclarée. Cette application capte la donnée au moment du geste, sans que l'opérateur ait à la produire séparément. C'est la seule façon d'obtenir une donnée fiable de quelqu'un dont le métier n'est pas de la produire.

Concevoir pour l'opérateur avant de concevoir pour l'entreprise

L'application visait initialement trois usages : gestion des stocks, préparation de commande et suivi de production. J'ai choisi de la penser comme une aide aux opérateurs plutôt que comme un dispositif de contrôle.

Elle joue évidemment les deux rôles, et il serait malhonnête de prétendre le contraire. Mais l'ordre dans lequel on les traite change tout. L'outil a été conçu en concertation avec les opérateurs ; certaines fonctions sans valeur pour la donnée d'entreprise ont été priorisées parce qu'elles allégeaient leur charge mentale ; et l'interface, bien que volontairement minimale, a été dessinée pour ne pas être austère.

Le premier niveau d'adhésion se joue en effet sur la perception, avant tout argument : l'outil est-il ressenti comme une contrainte supplémentaire à subir, ou comme une solution accessible qui rend de l'autonomie ?

Cette question était d'autant plus vive qu'un directeur des opérations nouvellement recruté est spontanément perçu comme le bras d'un contrôle descendant. Construire cette application a été le prétexte pour passer du temps sur le terrain, écouter les difficultés réelles, et parfois repérer les œillères que produit la peur de changer ce qu'on a toujours fait ainsi. C'est le meilleur exercice de conduite du changement que j'aie eu à mener.

Ce que le système enregistre

Le périmètre initial, livré comme preuve de concept pour répondre à l'urgence, repose sur trois points de capture.

À la **réception**, les numéros de lot des matières premières, les quantités entrées, l'opérateur et la date. En **production**, les lots de matières réellement consommés, les références des outils utilisés afin de garantir la recette de fabrication, les quantités consommées et produites, l'opérateur et la date. À l'**expédition**, le numéro de commande, le client ou le distributeur, les produits et quantités déclarés, le poids total par colis et donc leur nombre, l'opérateur et la date.

Chaque fin de production déclenche automatiquement la mise à jour des stocks, la création du numéro de lot unique et l'impression des étiquettes de traçabilité.

De ces trois points découle une gestion de stock qui n'a besoin d'aucune saisie propre : matières premières, produits finis et achat-revente s'ajustent à chaque réception, fabrication et expédition, avec un horodatage sur chaque mouvement. La donnée de stock n'est plus déclarée, elle est déduite.

Faire plutôt qu'acheter, et pourquoi

Des ERP et des logiciels de production couvrent ce périmètre. Je ne les ai pas retenus, pour une raison qu'il faut nommer sans détour : il n'existait aucun budget affecté aux process, ni même de visibilité budgétaire, ni cadrage annuel ni trimestriel.

La contradiction mérite d'être posée. Recruter un directeur des opérations suppose qu'un besoin d'amélioration a été identifié ; ne lui donner ni moyens ni horizon revient à attendre le résultat sans financer la cause. Développer était la seule option qui ne dépendait de personne.

Deux raisons délibérées s'y sont ajoutées. J'ai retenu la même stack que celle de Markprint, le logiciel que nous éditons, pour monter en compétence sur les technologies avec lesquelles nous faisons du chiffre d'affaires. Cela a produit un bénéfice que je n'avais pas anticipé à ce point : une compréhension mutuelle bien meilleure avec notre développeur externe, et donc une capacité réelle à dimensionner les projets et à challenger les décisions techniques plutôt qu'à les subir.

La seconde raison est l'assistance par IA, qui a rendu atteignable pour une personne seule ce qui ne l'était pas. Avec des bases en JavaScript, en opérations et en UX, produire un outil interne entièrement sur mesure est devenu réaliste.

Ce que l'IA a changé, concrètement

J'ai commencé avec Bolt en version gratuite pour une première itération, puis essayé Jules. Ces modes d'utilisation m'ont paru contraignants : ils produisent du code, mais laissent l'architecture à la porte.

Le basculement s'est produit avec l'arrivée des agents dans l'environnement de développement. Sous Visual Studio Code, le rythme a changé d'ordre de grandeur, au point que j'ai repris l'application entièrement : réorganisation du serveur pour qu'il puisse tenir la charge, et passage à une structure atomique allégée, atomes, composants, layouts et pages.

Cette reprise complète est le vrai marqueur. Un assistant qui accélère l'écriture fait gagner des heures ; un assistant qui rend une refonte d'architecture envisageable pour une personne seule change la nature de ce qu'elle peut entreprendre.

Le bin-packing, ou le service rendu qui fait adopter

L'algorithme de bin-packing calcule le format d'emballage optimal pour une commande donnée. C'est une fonction réellement implémentée, et son intérêt n'est pas d'abord économique.

Sans elle, un opérateur teste plusieurs cartons, ou choisit systématiquement le plus grand quitte à le bourrer de papier de calage. Avec elle, l'application lui donne la réponse. Le gain matériel existe, mais le gain d'adhésion est supérieur : c'est le type de fonction qui fait passer l'outil du statut de contrainte à celui de service.

Ces petites choses ont coûté peu de temps grâce à l'assistance par IA, et elles portent une part disproportionnée de l'adoption.

Ce qui tourne aujourd'hui

Le périmètre en production dépasse largement la preuve de concept initiale : réceptions, expéditions, productions et gestion des stocks, un module de bon à tirer servant d'interface entre l'infographie et les clients, un module d'assistance qui recueille les tickets du support, et un module de marketing produit qui tient lieu de PIM.

S'y ajoutent les tableaux de bord, qui sont la raison d'être de toute cette collecte. Côté stock : seuils de disponibilité, détection des stagnations, volume d'activité mesuré en références mouvementées. Côté assistance : durée moyenne de traitement, taux de résolution au premier appel, hiérarchisation des problématiques par typologie et par version du produit. Côté logistique : volumes de mouvements entrants et sortants, activité globale et détail par période.

C'est ici que la boucle se referme. Chaque indicateur existe parce qu'un geste métier l'a produit sans effort de saisie supplémentaire, et non parce que quelqu'un a rempli un tableau.

La dépendance, et ce qu'elle dit

Je suis aujourd'hui seul sur ce développement, ce qui constitue la principale fragilité du dispositif et mérite d'être dit franchement.

Deux voies s'ouvrent désormais que le projet est reconnu comme porteur dans l'organisation. La stack étant commune à celle de Markprint, notre développeur peut reprendre l'application pour la professionnaliser. L'autre option consiste à recruter un alternant : la matière existe, l'expertise métier et l'accompagnement en gestion de projet aussi, et le cadre serait à la fois responsabilisant et encadré.

Dans sa version actuelle, l'application est fonctionnelle et en service. Si je partais demain, sa fragilité ne viendrait pas de sa conception mais de l'absence de moyens accordés pour la pérenniser. Développer une preuve de concept qui fonctionne sans budget ni soutien n'est pas une imprudence, c'est ce qu'on attend d'une fonction opérationnelle quand la décision d'investir n'arrive pas.