Un QR code par outil : l'application d'atelier d'Affûtage Davin

Création de l'application d'atelier de Davin Affûtage, affûteur d'outils coupants industriels à Avignon depuis 1902.

Chez un affûteur, l'information la plus précieuse n'est pas dans un logiciel : elle est dans la tête des opérateurs et sur les étiquettes collées aux lames. J'ai conçu une application web sur mesure qui donne à chaque outil une fiche unique, ouverte en un scan, et qui trace chaque opération d'atelier.

Un parc d'outils qui ne s'arrête jamais

Davin Affûtage remet en état des outils coupants — lames circulaires carbure, fraises scies — qui appartiennent à ses clients. Chaque outil suit une boucle sans fin : enlevé chez le client lors d'une tournée, réceptionné au magasin, traité à l'atelier, facturé, expédié, puis remis en service. Et ainsi de suite, plusieurs fois par an.

Environ 6 000 outils franchissent ce circuit chaque mois, soit près de 300 par jour ouvré. À cette cadence, une information mal transmise ne coûte pas quelques minutes : elle se répète trois cents fois par jour.

Sur ce circuit, trois métiers manipulent le même outil sans jamais travailler avec la même information. Le magasin a besoin de savoir à qui l'outil appartient et quand il doit repartir. L'atelier a besoin des caractéristiques techniques précises pour le régler sur la bonne machine. La direction a besoin de savoir ce qui a été fait, par qui, et ce qui a posé problème.

L'enjeu n'était donc pas de « digitaliser un process », mais de créer un point de vérité unique par outil, consultable en quelques secondes dans un atelier, gants aux mains.

Un outil, un code, un scan

Chaque outil du parc porte une référence de huit caractères, matérialisée par un QR code sur l'outil lui-même.

L'écran d'accueil ne contient donc qu'une seule chose : un champ de saisie, déjà actif. L'opérateur scanne le QR code à la douchette, le code se saisit tout seul, et la recherche se déclenche automatiquement au huitième caractère — aucun bouton, aucun menu. La fiche s'ouvre directement. Le code reste saisissable à la main quand l'étiquette est abîmée.

Écrans reconstitués à partir du code source et de la feuille de style de l'application. Les données affichées sont fictives.

Deux détails font la différence à l'usage. La recherche est cadrée par le rôle : un opérateur ne trouve que les outils effectivement présents à l'atelier, tandis que le magasin et la gestion accèdent à tout le parc. Le même geste ne renvoie pas le même résultat selon qui scanne.

Et un code inconnu n'est pas une erreur : si l'outil n'existe pas encore en base, le magasin le crée immédiatement depuis le code scanné. Le parc s'est ainsi catalogué au fil de l'eau, outil par outil, sans reprise de données préalable ni chantier de saisie.

Une fiche qui parle le langage de l'atelier

La première lettre de la référence indique le type d'outil. L'application s'en sert pour afficher le bon jeu de caractéristiques, sans que personne n'ait à choisir un modèle dans une liste : diamètre, épaisseur de pastille et de corps de lame, alésage, nombre de dents, trous de centrage, présence de clavette, géométrie de denture — Heller, alternée, libre — pour une circulaire carbure ; pas théorique et géométrie brise-copeaux en plus pour une fraise scie.

Techniquement, ces caractéristiques sont stockées dans un champ structuré libre, et non dans des colonnes figées. Concrètement : ajouter un type d'outil ou une caractéristique ne demande aucune migration de base. C'est ce choix qui a permis d'enrichir les fiches progressivement, au rythme des retours de l'atelier.

Tracer chaque opération sans ralentir le poste

À chaque passage de l'outil, l'opérateur ajoute une opération en trois choix guidés : l'opération réalisée — affûtage, double affûtage, changement de pastilles carbure, rectification de dents, vérification de planage et tensionnage, détalonnage ; la machine utilisée, proposée telle qu'elle est nommée sur le terrain ; et une remarque libre, optionnelle.

L'opérateur et l'horodatage sont enregistrés automatiquement. En quelques secondes, l'outil accumule un historique complet : qui est intervenu, quand, avec quoi, et ce qui a été constaté. Cet historique reste attaché à l'outil pour toute sa vie.

À côté de cet historique, la fiche porte un second fil de remarques, volontairement séparé : les remarques pour facturation. Elles remontent ce qui sort du forfait — une pastille remplacée, une reprise non prévue — pour que le constat fait à l'établi arrive jusqu'à la facture sans repasser par un échange verbal.

Trois métiers, trois vues du même outil

L'application distingue trois rôles, et les droits descendent jusqu'au niveau du champ.

Ce découpage n'est pas cosmétique : il évite qu'un outil soit annoncé disponible à la livraison depuis l'atelier, ou qu'une donnée logistique soit modifiée par erreur pendant une opération. Chacun ne voit que ce dont il est responsable — et l'interface reste courte, ce qui est la meilleure garantie qu'elle soit réellement utilisée.

Rebrancher l'outil sur son circuit

Une fiche ne vaut que si elle sait à qui l'outil doit revenir. L'application relie donc chaque outil à son client — identifié par son code CRM, pour rester aligné sur les outils de gestion existants —, chaque client à son commercial, et chaque client à son jour de tournée.

Résultat : sur la fiche d'un outil posé sur un établi, l'atelier lit directement le jour où il doit être reparti. L'état se résume à trois informations lisibles d'un coup d'œil : hors service ou non, disponible atelier ou disponible livraison, et jour de tournée. Le rattachement à un client se fait par recherche au code CRM ou au nom partiel — parce que sur le terrain, on connaît rarement le code par cœur.

De la traçabilité au pilotage

Les remarques laissées par les opérateurs sont la matière première la plus utile du système : ce sont elles qui signalent une lame abîmée, un outil récurrent à problème, un client à rappeler. Une vue réservée à la gestion extrait donc toutes les opérations comportant une remarque sur une période donnée, avec l'outil, l'opérateur et la date.

La même donnée saisie à l'atelier en trois secondes devient un indicateur qualité exploitable.

Sous le capot

L'interface est une application monopage en Vue 3, avec Vuex, Vue Router et Bootstrap 5. L'API est un Strapi 4 en headless, avec authentification JWT et gestion fine des rôles et permissions, adossé à PostgreSQL. L'API et la base sont managées, l'interface servie en statique. Tout tourne dans un navigateur, en responsive, pensé pour la tablette et le smartphone d'atelier.

Deux choix d'architecture méritent d'être expliqués.

Une API headless plutôt qu'un back-office sur mesure. Strapi fournit d'emblée un espace d'administration complet sur les données : la gestion peut corriger une valeur, faire une extraction ou reprendre un import sans passer par moi. L'effort de développement s'est concentré sur ce qui n'existe pas sur étagère — la fiche outil, le scan, les droits fins — et non sur des écrans de saisie génériques.

Une application web plutôt qu'une application native. Pas de magasin d'applications, pas d'installation, pas de mise à jour à déployer sur les terminaux : un poste ou une tablette ouvre une adresse. Pour un usage exclusivement interne et connecté, c'est le choix le plus sobre et le plus rapide à faire évoluer.

Livré par itérations

Le projet a été mené en 2023 : conception et premiers écrans au printemps, mise en service durant l'été, puis évolutions continues jusqu'à la fin de l'année. Chaque lot est parti en production dès qu'il était utilisable, et les ajustements suivants sont venus de l'usage réel — verrouillage de la disponibilité côté opérateur, ajout du nom de client en complément du code CRM, remontée du jour de tournée sur la fiche outil, enrichissement du formulaire d'opération.

C'est le mode de travail que je privilégie sur les applications métier : la première version sert à découvrir les vrais besoins, pas à les deviner.

Ce que j'en retiens

Une application d'atelier se juge au nombre de gestes. Ici, consulter un outil demande un scan et rien d'autre. Sur trois cents outils par jour, c'est cette économie de gestes — plus que la richesse fonctionnelle — qui détermine l'adoption.

Le vocabulaire du client est une spécification. « Détalonnage », « pas théorique », « dispo livraison », les noms exacts des machines : reprendre les termes du métier tels quels supprime la moitié de la formation.

Les droits sont une fonctionnalité, pas un réglage. Découper l'accès par rôle a autant simplifié l'interface qu'il a sécurisé les données.

Un modèle souple prolonge la vie du logiciel. Les caractéristiques techniques stockées librement ont absorbé six mois d'évolutions sans jamais toucher au schéma de base.