TyreFlow — De l'inspection à l'offre client approuvée

En bref

TyreFlow a été construit pour le Casablanca AI Lab de DaiL lors de l'Octopus day, sous une contrainte de six heures et à partir d'une session de découverte client plutôt que d'un cahier des charges. Un atelier inspecte des roues qu'il a déjà en stockage ; l'observation utile — ces pneus sont usés — doit devenir une conversation client avant le prochain rendez-vous de ce client, et ne le devient souvent pas.

Le projet a terminé 2ᵉ. Ce que je défendrais le plus fort n'est pas une fonctionnalité que le logiciel ajoute : c'est une chose qu'il refuse de faire.

Le problème

Le brief posait que les techniciens inspectent des roues stockées et que l'information n'atteint pas le coordinateur à temps. La découverte a corrigé deux points.

D'abord, la douleur n'était ni l'inspection ni l'offre : c'était le passage de relais. La note reste quelque part où le coordinateur ne la voit pas avant qu'il soit trop tard.

Ensuite, et c'est plus utile : le cas principal est asynchrone. J'avais supposé un client debout dans l'atelier ; la réponse du client était que les roues sont en stockage et que le client n'est pas là. Il n'y a pas de moment de retrait pour l'attraper — la seule vraie échéance est son prochain rendez-vous. Cette seule correction a changé la forme du produit, et elle n'est apparue que parce que la session était une conversation et non une liste d'exigences.

Le troisième point, sans ambiguïté : une personne nommée approuve chaque offre, y compris les cas propres. Pas de « suffisamment fiable pour un envoi automatique ».

Architecture

Tout chemin d'une inspection vers un client passe par le verrou de stock et une approbation humaine. Il n'y a pas de contournement.

Une file de travail pour le coordinateur, et une règle en dessous : aucune offre n'est jamais envoyée pour un pneu que l'atelier ne peut pas fournir.

Classification. Chaque train de roues devient exactement l'un de projet d'offre, tâche à vérifier ou aucune action — jamais plusieurs — classé par urgence à partir du nombre de jours avant le rendez-vous, pondéré à la hausse pour les dossiers incomplets et les stocks non confirmés. Une tâche à vérifier liste toutes les raisons applicables d'un coup au lieu de les réduire à une seule étiquette, parce que « taille inconnue » et « contact injoignable » sont deux travaux différents.
Les preuves avant la proposition. La fiche affiche toujours ce que le technicien a réellement enregistré avant d'afficher le moindre projet d'offre. L'approbation n'est jamais une supposition.
Le verrou de stock. Tant que le stock n'est pas confirmé, Approuver est désactivé. Le coordinateur signale la taille au tableau des stocks ; confirmer cette taille débloque le contact automatiquement et fait remonter tous les dossiers rejetés pour exactement cette raison.
Approbation humaine, toujours. Approuver, approuver en masse et réactiver un dossier rejeté sont tous des clics explicites.
Brouillons en 3 langues × 4 canaux — français, darija et anglais sur WhatsApp, SMS, e-mail et appel, depuis des modèles éditables avec un prix vivant.

Tout fonctionne sur des données synthétiques, et chaque envoi simulé est étiqueté « simulé — non envoyé » dans l'interface elle-même, pas seulement dans le README.

Décisions & compromis

Le verrou de stock est devenu un blocage dur, pas un avertissement

L'exigence initiale autorisait l'envoi d'une offre à stock non confirmé avec une formulation prudente. Quand le client a dit « assurez-vous qu'on ne puisse pas contacter les clients si le stock n'est pas disponible », j'ai supprimé le chemin entièrement plutôt que de rendre l'avertissement plus visible.

C'est la décision que je défendrais en premier. Un avertissement délègue la règle à celui qui est fatigué à 17 h ; un bouton désactivé l'applique. Le coût est réel — un coordinateur certain que le stock existe ne peut quand même pas continuer — et c'est le chemin de récupération qui rend cela acceptable : signaler la taille au tableau des stocks prend un clic, et la confirmer débloque tout ce qui l'attendait, y compris les dossiers déjà rejetés pour cette raison. La formulation prudente ne couvre plus que le cas réellement ambigu : stock confirmé, mais nombre d'unités insuffisant.

Rejeter un dossier a cessé d'être une impasse

Au début, un rejet faisait disparaître le problème de la vue — ce qui va très bien jusqu'à ce que la raison du blocage disparaisse et que plus personne ne pense à regarder. La corbeille des rejets n'efface jamais, et elle est reliée au rappel qui se déclenche quand la taille de stock bloquante est confirmée. Elle referme la boucle que le verrou ouvre ; sans elle, le verrou ne serait qu'une façon de perdre du travail en silence.

Un bouton de démo « injecter un événement » a été supprimé

Le brief prévenait qu'une animation scriptée n'est pas la preuve qu'un agent a effectué une action, et mon premier prototype contenait exactement cela : un bouton qui simulait l'arrivée d'une information. Je l'ai remplacé par une reclassification déclenchée par des actions qui font partie du vrai flux de travail — confirmer un stock, enregistrer une inspection. La démo est moins fluide et prouve nettement plus. Chaque changement d'état du prototype est calculé à partir de l'état réel des composants ; les seules animations sont des transitions qui suivent un changement d'état au lieu de s'y substituer.

Un 80/20 explicite sur quoi construire en six heures

En six heures, le nombre de fonctionnalités est la mauvaise fonction objectif. J'ai estimé que le délai de passage de relais causait l'essentiel des occasions manquées : les 20 % porteurs — preuves visibles, verrou de stock, étape d'approbation incontournable — ont donc eu le temps de développement. Le changement de langue, les modèles éditables et le canal téléphonique sont venus après, pas avant. C'est cet ordre qui a permis à la démo de résister aux questions au lieu de ne survivre qu'au chemin idéal.

Ce qui a été difficile

Distinguer, en direct et sous chronomètre, ce que le client disait vouloir de ce que la situation exigeait réellement. Le cas « le client est dans l'atelier » semblait évident et était faux — c'est leur cas secondaire, et le construire en premier aurait produit un outil pour un moment qui, la plupart du temps, n'arrive pas. Il est toujours là, avec une alerte urgente au ton distinct, mais comme le bonus qu'il est.

Le reste a été du débogage honnête sous pression. Les tests ont fait apparaître deux vrais bugs dans les alertes : le son se déclenchait pour le technicien au lieu du coordinateur, et changer de rôle détruisait précisément les données dont l'alerte parlait. Les deux sont corrigés au niveau du store. Je préfère les nommer que présenter six heures de travail comme s'étant déroulées sans accroc.

Résultat

2ᵉ place, et un prototype déployé — pas un jeu de diapositives — au bout de six heures. Livré avec un état de départ reproductible (une réinitialisation qui restaure exactement les données de départ, sans dérive ni aléatoire), une documentation séparant le réel du simulé, et un dossier de passation couvrant la prochaine intégration, les accès, le responsable et le risque non résolu.

Ce que j'en retiens : la découverte est un travail d'ingénierie. La chose la plus utile que j'aie construite ce jour-là est un bouton désactivé, et le brief écrit ne me l'aurait jamais fait deviner.

La suite

La vraie prochaine étape n'est pas une fonctionnalité, c'est un test de validation : mettre la file devant un vrai coordinateur pendant une semaine et mesurer si les inspections deviennent effectivement des conversations avant le rendez-vous suivant. Tout le reste — intégrations de messagerie réelles, backend persistant au lieu d'un état initialisé, authentification digne de ce nom — est simple une fois que ce chiffre existe et confirme que le mécanisme fonctionne.