Le point de départ.
Le domaine couvrait sessions d’archivage, types, codes d’organisation, stockage d’entrée et de sortie, paquets sources, paquets produits et cycle de vie du workflow. Les opérateurs avaient besoin d’un parcours pratique pour comprendre le mouvement de ces éléments.
La fonctionnalité devait vivre dans une plateforme single-spa plus large qui fournissait déjà header, footer, navigation et microfrontends réutilisables. Réutiliser ces composants était un objectif principal, pas une finition visuelle tardive.
Une application React autonome aurait dupliqué la shell de la plateforme et créé un second endroit où maintenir navigation et chrome. La bonne frontière était une expérience d’archivage ciblée que la plateforme existante pouvait composer.
Ce que la conception devait résoudre.
La frontière utile se situait entre l’état du processus, l’action de l’opérateur et la plateforme hôte :
- La session, les paquets sources et les sorties devaient rester compréhensibles sur neuf étapes.
- Les actions de l’opérateur devaient correspondre clairement à des transitions valides.
- La nouvelle expérience devait réutiliser header, footer, navigation et conventions des composants existants au lieu de livrer une shell parallèle.
- Le microfrontend React single-spa avait besoin d’un point de montage et d’un contrat d’intégration étroits afin que les règles d’archivage ne se dispersent pas dans l’hôte.
- Les règles backend, l’état Camunda et les actions frontend ne pouvaient pas devenir des interprétations différentes du même workflow.
Le diagnostic.
Camunda pouvait coordonner le processus, mais l’orchestration seule ne constituait pas l’expérience de l’opérateur. Il manquait une frontière applicative cohérente autour du workflow.
La plateforme hôte avait déjà résolu la composition et le chrome. Reconstruire ces parties aurait ajouté du code sans améliorer le workflow d’archivage ; j’ai donc limité le microfrontend à la surface métier manquante.
J’ai séparé les responsabilités : l’hôte conserve navigation et composants partagés ; Spring Boot porte les règles applicatives, les références de stockage compatibles S3 et l’intégration Camunda ; le microfrontend React single-spa présente l’état actuel et les actions valides.
La tranche applicative obtenue.
La shell single-spa existante monte le microfrontend React dans son header, son footer et sa navigation partagés. Le microfrontend fournit uniquement la surface d’archivage. Un service Spring ciblé traduit les actions en opérations de workflow et références de stockage, tandis que Camunda coordonne le processus de la création de session au suivi des sorties.
Pourquoi ces frontières convenaient à la plateforme hôte.
Il ne s’agissait pas de choisir un stack greenfield. La shell, le moteur de workflow et les conventions de stockage appartenaient à une plateforme existante ; l’enjeu était d’ajouter une capacité cohérente sans dupliquer ni contourner ces frontières.
Une frontière applicative ciblée avec Spring Boot
- Pourquoi
- Le service regroupait côté backend la responsabilité des règles applicatives, des actions valides, de l’intégration Camunda et des références de stockage. React pouvait consommer un modèle applicatif sans connaître la mécanique du moteur de processus.
- Ce que j’ai écarté
- Appeler Camunda directement depuis le navigateur ou disperser les règles d’archivage dans des services partagés aurait exposé les détails d’orchestration et créé plusieurs interprétations du comportement valide.
- Ce que cela a coûté
- L’API et la couche de correspondance supplémentaires doivent évoluer avec le processus ; les erreurs à la frontière entre service et moteur demandent un traitement explicite.
Camunda pour le processus en neuf étapes
- Pourquoi
- Camunda coordonnait déjà le workflow. Y conserver les transitions maintenait une seule source de l’avancement, tandis que le service traduisait cet état pour les opérateurs.
- Ce que j’ai écarté
- Une machine à états sur mesure, surtout représentée principalement par l’état de l’interface, aurait dupliqué la logique du processus et mis le navigateur en concurrence avec le moteur pour l’autorité sur le workflow.
- Ce que cela a coûté
- Les définitions du processus et le modèle applicatif doivent rester alignés ; le diagnostic opérationnel traverse à la fois le service et le moteur.
React dans la composition single-spa existante
- Pourquoi
- Un microfrontend borné pouvait réutiliser header, footer, navigation et conventions de la plateforme tout en possédant uniquement la route d’archivage et son modèle d’interaction.
- Ce que j’ai écarté
- Réécrire la shell ou livrer une application React autonome aurait étendu le projet au-delà de la capacité manquante et créé une navigation ainsi qu’un chrome dupliqués.
- Ce que cela a coûté
- Le microfrontend dépend d’un contrat stable de montage et d’intégration ; les évolutions de la plateforme partagée demandent de la coordination plutôt qu’un contrôle entièrement local.
Un stockage compatible S3 pour les paquets d’entrée et de sortie
- Pourquoi
- Le contenu des paquets restait à une frontière de stockage objet, référencée par le service et le workflow, ce qui séparait les enregistrements d’archivage de la responsabilité des contenus binaires.
- Ce que j’ai écarté
- Des blobs en base auraient lié les paquets au cycle de vie des données relationnelles ; des fichiers locaux les auraient liés à une instance précise du service et à son parcours de déploiement.
- Ce que cela a coûté
- Buckets, endpoints, identifiants et cas d’objet manquant deviennent des préoccupations opérationnelles explicites que le service doit représenter avec clarté.
Règles pour un workflow réellement exploitable.
L’architecture fournit une source unique de vérité sur le processus ; ces règles en font une expérience que l’opérateur peut lire, juger fiable et reprendre après un problème.
Montrer l’état avant de proposer une action
La session en cours, ses paquets sources et résultats ainsi que l’étape du processus restent visibles avant que l’opérateur choisisse la suite. Une action privée de ce contexte n’est pas présentée comme un progrès.
Le compromisL’interface doit expliquer les états indisponibles, en attente et en échec au lieu d’optimiser uniquement le parcours idéal.
Dériver les actions valides de l’état du backend
L’interface présente les transitions prises en charge par le modèle applicatif, tandis que le service refuse celles qui ne sont pas valides. L’état local du navigateur ne devient jamais une seconde autorité sur la prochaine étape.
Le compromisLes échanges et le rafraîchissement d’état doivent être explicites, mais un écran périmé ne peut pas inventer une transition valide.
Préserver la continuité entre session et paquets
La session, les paquets sources et les paquets résultats restent liés tout au long du parcours en neuf étapes. La vérification suit le même chemin, de la création et l’association jusqu’au traitement et au suivi des résultats.
Le compromisLe modèle et l’interface portent plus de contexte qu’un écran dédié à une seule tâche, mais l’opérateur peut suivre le lien entre le travail et son résultat.
Rendre l’échec et la reprise visibles
Une étape incomplète, en attente ou en échec reste visible. Si la prochaine action valide permet de réessayer ou de poursuivre, elle apparaît seulement après confirmation du backend.
Le compromisL’interface doit expliquer davantage d’états et de parcours d’erreur, mais distingue attente, échec et reprise au lieu de laisser l’opérateur deviner.
Livraison et vérification.
La vérification suit les neuf étapes : créer la session, associer les paquets sources, démarrer le workflow, observer les transitions valides et suivre les paquets de sortie.
J’ai aussi vérifié la frontière de composition : la nouvelle route devait vivre dans le header, le footer et la navigation existants, sans introduire une seconde shell ni pousser l’état d’archivage dans les composants partagés.
Les autres cas d’échec importants se trouvent aux frontières. Le service doit refuser les transitions invalides, l’UI montrer honnêtement les états incomplets ou en attente, et l’intégration conserver le processus comme source de vérité.
Le résultat qualitatif.
La tranche obtenue couvre la gestion des sessions, le traitement des paquets et le contrôle du workflow, depuis l’interface jusqu’au processus Camunda.
Les opérateurs disposent d’un endroit unique pour comprendre le travail et le faire avancer. La plateforme conserve le header, le footer, la navigation et les conventions visuelles déjà connues.
La plateforme gagne une capacité contenue plutôt qu’une application parallèle : aucune shell dupliquée, aucun second modèle de navigation et aucune règle d’archivage dispersée dans des microfrontends sans rapport.
Organisation, produit, types internes, endpoints, buckets, identifiants et dates de livraison sont omis. Le cycle métier provient du dossier de projet.