Référence d’application. Il s’agit d’une architecture illustrative et d’une liste de contrôle du périmètre, et non d’un projet client vérifié ou d’un déploiement mesuré. Les technologies, le périmètre d’intégration et les éléments livrables sont définis selon le besoin réel.
Scénario et contraintes
Une usine remplace le suivi de production sur tableurs. L’exigence déterminante est la traçabilité bidirectionnelle : à partir d’un numéro de série fini, répertorier chaque lot de matières qui y est entré, et à partir d’un lot de matières défectueux, répertorier chaque unité finie concernée. Cette exigence détermine le modèle de données : elle ne peut pas être ajoutée ultérieurement sans retraiter l’historique.
Architecture
Couches et responsabilités
| Couche | Technologie | Responsabilité |
|---|---|---|
| Web bureautique | Vue 3 + Element Plus | Libération des commandes, gestion de la nomenclature, planification, revue qualité et rapports. |
| Client atelier | Terminal mobile / tablette Android (Kotlin), compatible hors ligne | Saisie pilotée par scan à chaque poste. Conçu pour les mains gantées et les connexions Wi-Fi faibles : grandes zones d’action, peu de pressions, file d’attente locale. |
| API | Go + Gin | Validation des rapports par rapport à la gamme, règles de consommation des matières et requêtes de traçabilité. |
| Stockage | MySQL | Commandes, gammes, enregistrements de rapports et généalogie des lots. |
| Passerelle équipements | Passerelle MQTT ou OPC UA (facultative) | Récupère les comptages ou les mesures des équipements lorsque le fournisseur expose une interface, puis les normalise dans les mêmes tables de rapports. |
| Rapports | Tâches d’agrégation planifiées | Rendement, temps de cycle et charge des postes précalculés, car ces requêtes parcourent trop d’historique pour être exécutées en temps réel à chaque chargement du tableau de bord. |
Modèle de données
Les tables ci-dessous portent les règles dont tout le reste dépend. Les définir incorrectement transforme une démonstration fonctionnelle en un système impossible à étendre.
Entités principales
| Entité | Champs clés, relations et règles |
|---|---|
| item / bom | Nomenclature multiniveau avec dates d’effet et règles de substitution. Les versions de nomenclature sont conservées et non écrasées, afin qu’une commande fabriquée le mois dernier soit toujours résolue selon la nomenclature effectivement utilisée. |
| work_order / routing_step | La commande et sa liste ordonnée d’opérations, chacune rattachée à un centre de charge avec un temps standard et les règles de déclaration applicables à cette étape. |
| production_report | Production par poste : opérateur, heures de début et de fin, quantité conforme, retouche et rebut avec codes de motif. C’est la source dont découlent toutes les métriques ; ses règles de validation sont donc plus importantes que les tableaux de bord. |
| material_lot / lot_consumption | Lots réceptionnés et leur consommation pour une commande de fabrication. lot_consumption est la relation qui rend la généalogie possible ; sans elle, la traçabilité se réduit à des suppositions. |
| serial / genealogy | Unités finies sérialisées liées aux lots consommés, formant le graphe qui permet de répondre aux deux directions de traçabilité. |
| inspection / defect | Points de contrôle, règle d’échantillonnage, codes de défaut et décision (acceptation, retouche, rebut), chacun rattaché au rapport ayant produit l’unité. |
Interfaces clés
Points de terminaison portant les règles métier
| Point de terminaison | Objectif et remarques sur la concurrence |
|---|---|
| POST /api/v1/reports | Déclaration au poste. Vérifie que l’étape précédente de la gamme est terminée, que la quantité déclarée ne dépasse pas la quantité libérée et que la consommation de matières reste dans la tolérance de la nomenclature ; le rejet des données incorrectes à ce stade garantit la fiabilité des données de déclaration. |
| POST /api/v1/reports/batch | Envoi de la file d’attente hors ligne depuis les terminaux mobiles, dédoublonné à partir d’un UUID client et conservant l’heure de capture. |
| GET /api/v1/trace/forward/{lot} | À partir d’un lot de matières, renvoie chaque numéro de série fini concerné ; c’est la requête dont dépend un rappel. |
| GET /api/v1/trace/backward/{serial} | À partir d’un numéro de série fini, renvoie la généalogie complète des lots de matières. |
| POST /api/v1/work-orders/{id}/release | Libère une commande en enregistrant une copie instantanée de la nomenclature et de la version de la gamme, afin que les modifications ultérieures des données de référence ne puissent pas réécrire l’historique. |
Décisions techniques
- Généalogie modélisée dès le départ. Ajouter la traçabilité ultérieurement signifie que les données historiques ne pourront jamais être tracées. Si la traçabilité constitue une exigence potentielle à l’avenir, la relation lot_consumption doit exister dès la première version, même si les rapports arrivent plus tard.
- Nomenclature et gamme copiées au moment de la libération de la commande. Les données de référence évoluent constamment ; les commandes doivent continuer à être résolues selon la version avec laquelle elles ont été libérées, faute de quoi les écarts de coût et de consommation deviennent dépourvus de sens.
- Validation au niveau du point de terminaison de déclaration, et non dans le tableau de bord. Les métriques calculées à partir de données non validées produisent des chiffres erronés présentés avec assurance. Rejeter une déclaration impossible lors de sa saisie coûte moins cher que d’expliquer ultérieurement un mauvais chiffre de rendement.
- File d’attente hors ligne sur le terminal mobile. Le Wi-Fi de l’usine comporte des zones mortes à proximité du métal et des machines. Une déclaration qui échoue dans ces zones ne sera tout simplement pas effectuée, et le jeu de données développera silencieusement des lacunes.
- Coexister avec l’ERP existant plutôt que le remplacer. Comparer une interface limitée pour les commandes et les mouvements de stock avec une migration ERP en s’appuyant sur les dépendances, les coûts et les risques réels ; confirmer le processus financier avant de choisir.
Objectifs de conception hypothétiques
Les chiffres ci-dessous sont des exemples hypothétiques de planification de capacité, et non des résultats client mesurés, une recommandation de dimensionnement validée ou un SLA. Définissez des objectifs d’acceptation propres au projet après avoir précisé la charge, les appareils, les données, le matériel et les dépendances tierces ; vérifiez-les au moyen d’un pilote et de tests de charge avant de vous engager sur un objectif de production.
Objectifs de capacité et de performance
| Objectif | Valeur et hypothèse |
|---|---|
| Scan-vers-confirmation | Objectif hypothétique : retour local inférieur à 1 seconde pour une déclaration et un appareil définis. Conserver les enregistrements en file d’attente et distinguer l’accusé de réception local de l’acceptation par le serveur ; tester les délais et les défaillances réseau. |
| Requête de traçabilité | Les deux directions répondent en quelques secondes pour une profondeur de généalogie habituelle, au moyen de relations indexées sur les lots et les numéros de série ; les assemblages multiniveaux profonds sont validés sur vos données réelles lors de l’acceptation. |
| Tableau de bord des rapports | Alimenté par des agrégats précalculés actualisés selon une fréquence convenue avec les opérations, plutôt que par un parcours des rapports bruts à chaque chargement de page. |
| Tolérance hors ligne | Les rapports d’une équipe complète mis en file d’attente localement et téléversés lors de la reconnexion, avec dédoublonnage sur l’UUID client. |
Contenu de la livraison
- Code source du web bureautique, du backend Go et du client Android d’atelier dans votre dépôt
- Schéma de base de données documenté avec le versionnage des nomenclatures et les tables de généalogie, ainsi que l’historique des migrations
- Documentation de l’API, y compris le contrat de téléversement hors ligne et les règles de validation des rapports
- Spécification de l’interface ERP et format d’échange convenu
- Notes de déploiement, procédure de sauvegarde et de restauration, ainsi que notes de configuration du matériel d’étiquetage ou de numérisation
Planifier cela pour votre entreprise
Les modules ci-dessus constituent un point de départ, et non un ensemble figé. Nous limitons généralement la première version à un flux de travail principal et un flux d’administration, puis nous l’étendons lorsque l’utilisation réelle montre où se situent effectivement la charge et les cas limites. Envoyez un brief délimité et nous le mettrons en correspondance avec cette architecture pour vous indiquer quelles parties ne vous sont pas encore nécessaires.