Étude de cas · Industrie · Fabrication
Comment nous avons livré un écosystème industriel de trois applications — un client opérateur Kotlin Android, un panneau admin Laravel + React et un tableau de bord contrôleur — déployés au sein d'un réseau d'usine isolé et conçus pour remplacer les journaux papier par un workflow de qualité audit dans les installations aux États-Unis et dans l'Union européenne.
Le client de CheckList exploitait une usine de fabrication où les processus des réacteurs étaient suivis avec des journaux papier : les opérateurs notaient manuellement les minutages des étapes, les superviseurs feuilletaient des registres pour reconstituer les quarts, et il n'y avait aucune visibilité en temps réel sur la disponibilité ou le nombre d'erreurs. L'usine fonctionnait sans internet à l'intérieur de son périmètre — une contrainte absolue, pas une préférence — si bien que tout remplacement numérique devait fonctionner entièrement hors-ligne et se synchroniser lorsque la connectivité LAN était disponible. Nous avons livré un écosystème de trois applications déployé dans le réseau isolé de l'usine : les opérateurs utilisent une application Android Kotlin pour enregistrer les étapes avec horodatages et preuves photographiques ; les administrateurs configurent les équipements, les checklists, les utilisateurs et les autorisations dans un panneau admin Laravel et React ; les contrôleurs surveillent un tableau de bord en direct avec la disponibilité, les comptes d'erreurs et un bouton d'arrêt d'urgence. L'authentification locale et la synchronisation hors-ligne rendent le système utilisable sans accès internet, et un constructeur de réacteurs/procédés permet à l'usine d'ajouter de nouveaux équipements sans modification de code. Le résultat est un workflow de qualité audit qui résiste aux contrôles dans les juridictions américaines et européennes et remplace chaque ligne du registre papier.
Un instantané de ce que le projet CheckList a livré à travers l'application opérateur, le panneau admin et le tableau de bord contrôleur lors de son premier cycle de production en atelier.
Le choix de la pile technologique domine toutes les autres décisions architecturales dans un projet de MES industriel. Nous avons choisi un client opérateur Android Kotlin personnalisé associé à un backend Laravel et une surface web React parce que les compromis s'alignent parfaitement avec un atelier de production qui fonctionne sans internet. L'application Android fonctionne hors-ligne par conception, le backend Laravel se déploie sur un seul serveur sur site dans le LAN de l'usine, et les tableaux de bord admin et contrôleur React partagent l'état de session via WebSockets afin qu'un superviseur voie un compteur d'erreurs s'incrémenter dès qu'un opérateur enregistre un écart.
Les fournisseurs de MES SaaS ont été écartés dès le début : ils supposent une connexion internet fiable, ils extraient les données de l'usine hors du périmètre et facturent par nœud d'une façon qui devient ingérable à mesure que l'usine se développe. Le SCADA standard est très configurable, mais sa surface de workflow — transfert de quart, preuves photographiques, archive de qualité audit — se situe en dehors de sa compétence principale. Un générateur de formulaires générique associé à un outil d'automatisation assemble un pipeline fragile qui cède dès que le LAN de l'usine perd un paquet.
| Dimension | CheckList (Kotlin + Laravel + React) | Fournisseurs MES SaaS | SCADA standard / générateur de formulaires |
|---|---|---|---|
| Comportement hors-ligne | Natif — file SQLite locale, vidée sur LAN | Suppose une connexion internet fiable | SCADA : oui ; formulaires : généralement non |
| Topologie de déploiement | Sur site sur LAN ; peut être isolé du réseau | Cloud mutualisé ; tarification par siège | SCADA : sur site ; formulaires : cloud uniquement |
| Propriété des données | L'usine possède la base de données de bout en bout | Le fournisseur détient les données de production | SCADA : usine ; formulaires : fournisseur + automatisation |
| Adéquation du workflow | Workflow de quart, minutage d'étape, preuves photos natifs | Solide mais lié au modèle | SCADA : orienté procédé ; formulaires : fragile |
| Profondeur de personnalisation | DSL constructeur réacteur / procédé — l'usine ajoute des équipements | Cycles vendeur + limites de configuration | SCADA : profond ; formulaires : superficiel |
| Contrôle d'accès basé sur les rôles | Opérateur / admin / contrôleur intégrés | Solide, mais hérite du modèle RBAC du fournisseur | SCADA : solide ; formulaires : généralement faible |
| Archive de qualité audit | Archive des cycles complétés avec preuves photos | Variable selon le fournisseur ; qualité d'export variable | SCADA : historien ; formulaires : tableur |
Références de la pile : documentation Laravel, guide développeur Android SQLite, documentation React.
Le client Android est écrit en Kotlin et fonctionne sur des tablettes en atelier liées à un identifiant d'appareil unique au premier démarrage. L'authentification locale est requise — sans attente que l'appareil puisse atteindre un fournisseur d'identité cloud — et chaque action de l'opérateur est d'abord écrite dans un magasin SQLite local avant toute tentative de synchronisation. Le workflow de quart guide l'opérateur à travers les étapes avec une minuterie intégrée, capture des preuves photographiques aux points requis par l'audit, et route l'archive des cycles complétés vers le serveur sur site lorsque la connectivité LAN est disponible. L'interface est conçue pour des gants épais, l'éclairage d'atelier et des gestes rapides plutôt que pour un consommateur avec un téléphone en poche.
Un worker de synchronisation en arrière-plan vide la file locale vers le serveur Laravel sur site via WebSockets, avec des opérations idempotentes indexées par un identifiant généré côté client pour que les nouvelles tentatives ne dupliquent jamais le travail. Le transfert automatique de quart transfère un cycle de réacteur en cours d'une tablette d'opérateur à la suivante sans perdre l'état, et les conflits sont résolus côté serveur par le moteur de workflow. La surface opérateur fait partie de notre pratique de développement d'applications mobiles, et le contrat hors-ligne est la pièce maîtresse — si le LAN de l'usine tombe pendant un demi-quart, aucune action opérateur n'est jamais perdue.
La surface web compte deux personnages distincts, chacun avec une vue délimitée par le contrôle d'accès basé sur les rôles. Le panneau admin — construit en React sur un backend Laravel — permet aux superviseurs de configurer les équipements, de modifier les checklists, de gérer les utilisateurs et les autorisations, et de lier les tablettes à des opérateurs spécifiques. Le DSL constructeur de réacteurs / procédés est la pièce maîtresse : une usine ajoute un nouveau réacteur ou étend un flux de procédé existant en modifiant des modèles de checklists dans le panneau admin, sans attendre un cycle d'ingénierie. Les nouveaux équipements, les nouvelles définitions d'étapes, les nouvelles exigences de preuves photographiques arrivent tous par configuration.
Le tableau de bord contrôleur est une surface de surveillance en temps réel qui diffuse l'état de l'usine via WebSockets — disponibilité actuelle des réacteurs, comptages d'erreurs, quarts en cours, croissance de l'archive de cycles complétés — et expose un bouton d'arrêt d'urgence protégé par RBAC pour que seul un utilisateur avec le rôle contrôleur puisse l'actionner. Le tableau de bord fonctionne dans n'importe quel navigateur moderne à l'intérieur du LAN de l'usine, ce qui signifie que le contrôleur peut surveiller depuis un poste fixe, un ordinateur portable de maintenance ou un écran mural au-dessus de la ligne de production. L'ensemble de la surface web est livré dans le cadre de notre pratique de développement logiciel sur mesure et est structuré de sorte que les usines puissent ajouter de nouveaux tableaux de bord (export KPI, vue mobile superviseur) sans restructurer la couche de données.
L'architecture de CheckList a été construite autour de la contrainte que le LAN de l'usine n'a pas d'accès internet sortant. Le backend Laravel et la base de données MariaDB se déploient sur un seul serveur sur site à l'intérieur du périmètre de l'usine, les tableaux de bord admin et contrôleur React sont servis depuis la même machine, et les tablettes Android atteignent le backend via WebSockets sur le LAN de l'usine. Il n'y a pas de courtier tiers, pas de télémétrie exclusivement cloud et pas de tracker analytique fantôme. Les workers en arrière-plan gèrent les écritures dans les journaux d'audit et l'ingestion des preuves photographiques, et l'archive des cycles complétés est conservée indéfiniment avec des politiques de rétention configurables par installation.
Le contrôle d'accès basé sur les rôles protège chaque endpoint d'API et chaque route de tableau de bord — un opérateur ne voit que son quart, un admin voit la configuration et la gestion des utilisateurs, un contrôleur voit la surface de métriques en direct plus le contrôle d'arrêt d'urgence. La liaison d'appareil attache chaque tablette à un identifiant unique pour qu'une tablette perdue ne puisse pas être réutilisée hors de l'atelier. La posture de gestion des données est documentée pour les obligations du RGPD pour les opérations dans l'Union européenne et les obligations du CCPA / CPRA pour les opérations en Californie et aux États-Unis, avec une rétention des journaux d'audit configurable par installation pour correspondre aux fenêtres réglementaires locales. La posture de durcissement est cohérente avec notre hygiène globale en matière de cloud & DevOps.
Posture de conformité : conforme RGPD · prêt ISO 27001 · SOC 2 Type II en cours · compatible HIPAA · CCPA reconnu.
Un développement en cinq phases qui a conduit CheckList des journaux papier à un écosystème industriel de trois applications déployé dans un réseau d'usine isolé.
Entretiens opérateurs et contrôleurs, taxonomie des journaux papier, modélisation du workflow de quart, exigences en matière de preuves photographiques, contraintes de déploiement sur site, cartographie de la posture RGPD + CCPA.
Sélection de la pile Laravel + React + Kotlin, conception du DSL constructeur réacteur / procédé, surface de contrôle d'accès basé sur les rôles, schéma du magasin de journaux d'audit, schéma de liaison d'appareil.
Application opérateur Android Kotlin avec synchronisation hors-ligne, panneau admin Laravel + React, tableau de bord contrôleur avec diffusion WebSocket, contrôle d'arrêt d'urgence.
Durcissement du pipeline de preuves photographiques, politiques de rétention des journaux d'audit, contrôle RBAC, règles de résolution de conflits dans le moteur de workflow, réglage UX en atelier.
Déploiement du serveur sur site, provisionnement des tablettes et liaison des appareils, formation des opérateurs, vérifications de conformité du tableau de bord contrôleur, vérification de l'archive des cycles complétés.
CheckList a été déployé d'abord dans une seule usine, mais l'architecture est conçue pour une expansion multi-installations sans modifier l'application opérateur ni le panneau admin. Chaque installation exploite son propre serveur Laravel sur site et sa propre base de données MariaDB — le LAN de l'usine reste le périmètre de sécurité — et une couche de fédération future peut agréger les archives de cycles complétés, les exports KPI et les flux BI dans un aperçu au niveau de l'entreprise sans rompre le contrat hors-ligne en atelier. Le DSL constructeur réacteur / procédé signifie qu'une nouvelle installation peut configurer sa propre bibliothèque d'équipements, ses checklists et ses workflows de quart sans ticket d'ingénierie ; le schéma de liaison d'appareil signifie que les tablettes peuvent être provisionnées et alternées localement ; la surface de contrôle d'accès basé sur les rôles signifie que les rôles opérateur, admin et contrôleur fonctionnent de manière identique dans toutes les installations même si les équipements sous-jacents varient. La même posture laisse de la place pour un futur chemin d'export BI — les données d'archive de cycles complétés sortent du périmètre de l'usine uniquement lorsque l'opérateur d'usine l'autorise explicitement, avec des fenêtres de rétention configurées par installation pour correspondre au régime réglementaire local. Les usines aux États-Unis et dans l'UE peuvent fonctionner avec la même recette de déploiement et ajuster localement la rétention, les portées RBAC et les règles d'export BI sans bifurquer le code source.
CheckList a été conçu pour un déploiement en atelier aux États-Unis et dans l'Union européenne sans code source distinct par région. L'interface en anglais sert les opérateurs et contrôleurs en Californie, New York, Texas, Floride et Washington aux États-Unis, et les opérateurs et contrôleurs aux Pays-Bas, en Allemagne, en France, en Irlande et en Suède dans l'UE. Les pratiques de gestion des données sont alignées sur le RGPD pour les opérations dans l'Union européenne et sur le patchwork de confidentialité des États américains — CCPA / CPRA (Californie), VCDPA (Virginie), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) et Oregon CPA. Étant donné que le déploiement sur site maintient les données de l'atelier à l'intérieur du périmètre de chaque installation et que la surface de contrôle d'accès basé sur les rôles contrôle chaque lecture et écriture, la conformité régionale se réduit à une divulgation honnête et à la configuration de la rétention des journaux d'audit plutôt qu'à une ségrégation des données par juridiction.
La recette de déploiement sur site est identique dans les installations américaines et européennes — même backend Laravel, même base de données MariaDB, même application opérateur Android Kotlin, mêmes tableaux de bord admin et contrôleur React. Les fenêtres de rétention pour l'archive des cycles complétés sont configurables par installation pour correspondre aux attentes réglementaires locales, et le magasin de journaux d'audit est structuré pour satisfaire les obligations RGPD pour les utilisateurs dans l'Union européenne et les obligations CCPA de Californie pour les installations aux États-Unis. L'équipe d'ingénierie derrière ce projet est basée en CET et travaille selon un planning CET avec un chevauchement avec la côte Est des États-Unis (9 h–13 h ET) pour les stand-ups, la choreographie de déploiement et la réponse aux incidents.
La feuille de route active de développement logiciel sur mesure de CheckList comprend une couche de fédération multi-usine qui agrège les archives de cycles complétés entre les installations, un chemin d'export BI qui achemine les KPI anonymisés vers les data lakes d'entreprise, un pipeline de preuves photographiques hors-ligne qui survit aux longues coupures de LAN sur les sites distants, et une recette de mise à niveau sur site renforcée qui ne nécessite pas la mise hors ligne d'une usine. Un playbook de déploiement centré sur les États-Unis et un autre centré sur l'UE sont prévus, la surface de contrôle d'accès basé sur les rôles étant déjà structurée pour prendre en charge la configuration de rétention locale par installation.
Si vous planifiez un MES industriel, une application hors-ligne pour atelier de production ou tout développement de contrôle de procédés industriels où les données doivent rester à l'intérieur du périmètre de l'usine pour des audiences aux États-Unis et dans l'UE, nous avons livré cette pile de bout en bout et pouvons comprimer significativement le calendrier de développement. L'équipe d'ingénierie derrière ce projet est au sein de YuSMP Group. Nous travaillons à prix fixe pour les MVP bien définis et sur des équipes de développement dédiées pour la livraison continue, avec un planning CET et une fenêtre de chevauchement garantie avec la côte Est des États-Unis (9 h–13 h ET) pour les stand-ups, les démonstrations et la réponse aux incidents.
Un MVP de MES trois applications couvrant un client opérateur Kotlin Android, un panneau admin Laravel + React, un tableau de bord contrôleur, un déploiement sur site et une synchronisation hors-ligne coûte généralement entre 140 000 et 320 000 €. L'ajout d'un DSL de constructeur de réacteurs et de procédés, d'une fédération multi-usine, de pipelines de preuves photographiques, d'un magasin de journaux d'audit renforcé et d'une exportation BI porte un produit industriel complet à 400 000-780 000 €. Les principaux facteurs de coût sont la correction de la synchronisation hors-ligne, le travail de durcissement sur site et la surface de contrôle d'accès basé sur les rôles qui doit résister à un véritable audit d'usine.
Les fournisseurs de MES SaaS supposent que l'usine dispose d'une connexion internet fiable et que les données client quittent le périmètre ; ces deux points sont rédhibitoires pour une installation fonctionnant hors-ligne par conception. Le SCADA standard est configurable, mais la surface de workflow autour du transfert de quart, des preuves photographiques et d'une archive de qualité audit se trouve en dehors de son modèle de base. Un générateur de formulaires générique associé à l'automatisation assemble un pipeline fragile. Un développement personnalisé Kotlin Android plus Laravel et React possède les données, la topologie de déploiement et la surface de workflow de bout en bout.
Chaque action de l'opérateur — démarrage d'étape, événement minuterie, téléversement de photo, transfert de quart — est d'abord écrite dans un magasin SQLite local sur l'appareil sous une identité d'authentification liée à l'appareil. Un worker de synchronisation en arrière-plan vide la file vers le serveur Laravel sur site via WebSockets lorsque le LAN de l'usine est accessible, avec des opérations idempotentes indexées par un identifiant généré côté client pour que les nouvelles tentatives ne dupliquent pas le travail. Les conflits sont résolus côté serveur par le moteur de workflow, et l'interface opérateur affiche le dernier état connu jusqu'à confirmation par le serveur.
Le système collecte uniquement les données opérateur et procédé dont l'usine a réellement besoin — rôle opérateur, quart, calendrier des étapes, preuves photographiques — et les stocke sur le serveur sur site à l'intérieur du périmètre de l'usine. Il n'y a pas de courtier tiers, pas de télémétrie exclusivement cloud et pas de tracker analytique fantôme. Le contrôle d'accès basé sur les rôles détermine qui peut voir quelles photos et quelles archives de quart. La posture de gestion des données est documentée pour le RGPD pour les opérations dans l'Union européenne et le CCPA pour les opérations en Californie, avec une rétention des journaux d'audit configurable par installation.
Un MVP ciblé avec une application opérateur Kotlin Android, un panneau admin Laravel + React, un tableau de bord contrôleur, un déploiement sur site et une synchronisation hors-ligne prend généralement entre 20 et 32 semaines calendaires. L'ajout d'un DSL de constructeur de réacteurs et de procédés, d'une fédération multi-usine, d'une exportation BI et d'un magasin de journaux d'audit renforcé ajoute encore 10 à 16 semaines. Le passage de durcissement sur site — liaison d'appareil, contrôle d'accès basé sur les rôles, rétention des journaux d'audit et choreographie de déploiement dans les ateliers aux États-Unis et dans l'UE — doit être budgété à 4-6 semaines de travail dédié.
Cas associés
Calculateur de fenêtres en ligne et CRM unifiés — multi-locataires sur trois sites de marque, recherche par adresse.
Voir le cas →
Plateforme de taxi trois applications — chauffeur, passager, répartiteur — avec GPS en temps réel et vérification des documents.
Voir le cas →
Marketplace de pièces auto plus CRM vendeur — recherche par VIN, inventaire multi-sites, livraison intégrée.
Voir le cas →
Plateformes d'entreprise axées sur l'architecture avec conformité prête pour l'audit et intégration à SAP, Salesforce, Workday, Okta.
En savoir plus →
Migration Strangler-fig de piles legacy (.NET Framework, Java 8, monolithe) sans risque de refonte totale.
En savoir plus →
Transformation pragmatique qui livre — migration cloud, modernisation legacy, intégration IA, plateforme de données.
En savoir plus →Partagez quelques détails et un consultant senior vous répondra dans un délai d'un jour ouvrable.