APP Motors vérifie les tâches de l'atelier toutes les cinq minutes et signale les temps d'arrêt

Le concepteur n'a pas terminé le plan, le monteur attend, le responsable cherche la cause par téléphone. Dans une petite unité de production, une telle chaîne disparaît facilement derrière la consigne urgente suivante. L'auteur d'APP Motors a décrit sur Habr son propre système : les tâches sont créées à la voix depuis un téléphone, reliées par des dépendances, et le programme relance en cas de retard. Pour un développeur, l'intérêt est une manière concrète de séparer l'automatisation classique du travail du modèle de langage.

Selon l'auteur, le développement a demandé environ trois semaines de travail effectif, le soir et le week-end. Le système réunit les tâches, les ordres de fabrication, le stock, l'outillage et les versions des plans. Les employés de la production l'utilisent déjà, mais le document présenté ne contient aucune vérification indépendante des résultats.

De la consigne orale à la tâche

Le scénario commence directement à l'atelier. Le responsable dicte une consigne, le téléphone reconnaît la parole, puis le modèle répartit le texte dans des champs : titre, description, urgence, échéance et exécutant. Avant la création, une personne vérifie le résultat.

Par exemple, la demande d'acheter vingt joints d'étanchéité devient une fiche d'achat. Si les dimensions et le matériau manquent, le système propose de préciser la spécification. Il peut aussi suggérer un lien avec une tâche existante concernant le même produit. Cela raccourcit le chemin entre la question soulevée et la consigne que verra l'exécutant.

Le serveur recherche l'employé dans sa propre base avant de solliciter le modèle. D'après l'auteur, le nom est remplacé par un marqueur technique dans le texte envoyé. Cela réduit la transmission de données personnelles, mais ne prouve pas à lui seul que les autres champs ne contiennent aucune information sensible.

C'est aussi là qu'un bogue révélateur est apparu : la fonction recevait le contexte des projets et des tâches similaires, mais ne l'incluait pas dans la requête au modèle. Les tests passaient, car ils simulaient l'appel à un niveau supérieur. L'auteur a ajouté une vérification de la requête complète assemblée. Pour une équipe qui déploie un LLM, la leçon est très concrète : il faut aussi contrôler les données qui parviennent réellement au modèle.

Qui signale les temps d'arrêt

Toutes les cinq minutes, une tâche de fond parcourt les consignes actives. Les rappels d'échéances, la détection des retards et le choix des destinataires sont définis par des règles dans le code. Si le modèle est indisponible, ce mécanisme continue de fonctionner.

Les tâches peuvent être liées par la relation « nécessaire pour » : le plan est requis pour la pièce, la pièce pour l'assemblage. Le programme cherche une tâche active sans sous-tâches non clôturées et vérifie si elle a progressé récemment. Le seuil est de quatre heures pour une chaîne critique et de deux jours pour une chaîne ordinaire. La priorité est celle de la tâche la plus urgente de la chaîne.

Une fois le seuil dépassé, l'exécutant reçoit un rappel précisant qui l'attend. Ceux qui attendent reçoivent un message de blocage. Après l'acceptation d'une sous-tâche, le système indique que le travail peut reprendre. Les répétitions sont limitées et aucune notification n'est envoyée la nuit.

Le modèle intervient pour préparer des conseils dans la synthèse destinée au responsable. Lors du passage nocturne sur les données de production, le SQL repère d'abord les retards, puis le modèle hiérarchise les priorités et rédige un condensé. Selon l'auteur, le rôle d'agent IA n'a aucun droit d'écriture sur les référentiels de production. Le message proposé au nom du responsable est envoyé par la personne elle-même.

Ce qu'il faut retenir et ce qu'il faut vérifier

La partie utile du cas réside dans des règles de responsabilité explicites. L'exécutant soumet son résultat à validation avec une photo ou un fichier, et l'auteur accepte le travail ou le renvoie avec un commentaire. Les erreurs de stock sont corrigées par écriture inverse, les versions de plans sont conservées dans des enregistrements distincts et les actions importantes sont consignées dans un journal d'audit.

Cela dit, l'article décrit l'architecture du système, non une économie démontrée. Il n'y a pas de comparaison des temps d'arrêt avant et après le déploiement, ni de part de consignes mal interprétées, ni de coût total de maintenance. Le délai de développement ne peut pas non plus être transposé automatiquement à une autre usine aux processus différents.

La métrique choisie soulève aussi une question : un commentaire compte comme un mouvement et remet à zéro le compteur d'arrêt. Cela permet de prendre en compte l'explication d'un retard, mais peut masquer un travail qui n'avance pas réellement. Pour reproduire ce schéma, il vaut mieux distinguer l'activité dans la fiche et la modification du résultat attendu.

Pour démarrer concrètement dans votre équipe, choisissez un seul processus, par exemple le parcours entre la demande de plan et l'acceptation de la pièce. Définissez d'abord les statuts, les dépendances et les destinataires des notifications, puis ajoutez la saisie vocale. Mesurez l'effet par les consignes perdues, le temps d'attente et le nombre de relances manuelles du responsable.