Concevoir une plateforme de modélisation adaptée à son métier

Cette page a été traduite automatiquement depuis la version anglaise.

Une plateforme de modélisation n’est pas un simple éditeur de diagrammes. C’est la fondation technique et expérientielle sur laquelle une organisation capture la connaissance de son domaine, guide les utilisateurs dans une méthode, présente plusieurs vues de la même information, applique des règles et connecte les modèles au reste du système d’ingénierie.

Cette distinction change la première question à poser. La décision se résume rarement à : « Devons-nous construire ou acheter un outil ? » Une question plus utile serait : quelles parties de notre pratique de modélisation sont standard, lesquelles sont propres à notre domaine et lesquelles créent un véritable avantage ?

Pour certaines organisations, un produit existant est la bonne réponse. D’autres doivent configurer une plateforme autour d’un langage et d’un workflow dédiés. Un plus petit nombre dispose d’exigences qui justifient de construire elles-mêmes la technologie centrale. Les coûts et les risques sont très différents dans chaque cas.

Cette page propose un cadre pour prendre cette décision et concevoir une plateforme de modélisation web lorsqu’une configuration ou un développement sur mesure se justifie.

Qu’est-ce qu’une plateforme de modélisation ?

Un outil de modélisation permet aux utilisateurs de manipuler des modèles. Une plateforme de modélisation fournit des capacités réutilisables pour créer un ou plusieurs de ces outils.

La plateforme comprend généralement plusieurs couches :

• une fondation sémantique pour définir et stocker les concepts du domaine et leurs relations ;
• des commandes et des règles qui contrôlent la manière dont le modèle peut évoluer ;
• des représentations telles que diagrammes, arbres, tables, formulaires, matrices, tableaux de bord ou documents ;
• une navigation et un guidage qui aident chaque rôle à trouver la bonne information et à accomplir la bonne tâche ;
• des services de collaboration et de persistance pour partager, réviser, versionner et gouverner les modèles ;
• des frontières d’intégration avec les exigences, le PLM, l’ALM, la simulation, la data science, le reporting, l’automatisation et l’IA ;
• des capacités opérationnelles pour les identités, permissions, déploiements, supervision, sauvegardes, mises à jour et support.

Un produit peut regrouper toutes ces préoccupations pour un langage ou une méthode particulière. Une plateforme en expose suffisamment pour permettre à une équipe de construire une expérience adaptée à son propre domaine.

C’est pourquoi une plateforme ne doit pas être évaluée uniquement sur la qualité de son composant de diagrammes. Les diagrammes sont visibles et importants, mais la cohérence des modèles, l’extensibilité, l’exploitation et l’intégration déterminent si le résultat peut devenir une infrastructure durable.

Partir de la pratique, pas de l’éditeur

Les équipes commencent souvent une initiative de modélisation en dressant la liste des formes, menus et propriétés. C’est compréhensible : ce sont les éléments que tout le monde peut voir. C’est aussi une façon très efficace de reproduire un outil existant sans remettre en question le travail qu’il est censé soutenir.

Commencez plutôt par les décisions et les interactions que la plateforme doit améliorer :

• À quelles questions le modèle doit-il répondre ?
• Qui crée, révise, approuve et consomme chaque type d’information ?
• Quels concepts doivent partager un sens précis ?
• Quelles vues aident chaque rôle sans lui exposer tout le modèle ?
• Quelles règles doivent empêcher un changement invalide et lesquelles doivent seulement avertir ?
• D’où vient l’information et quel système en reste la source d’autorité ?
• Quels livrables, analyses ou actions en aval le modèle doit-il produire ?
• Qu’est-ce qui devra encore être compréhensible et maintenable dans dix ans ?

Ces questions définissent le modèle sémantique, les workflows et les frontières d’intégration. L’éditeur en découle.

Un bon outil métier ne se contente pas d’offrir moins de boutons qu’un outil générique. Il emploie le vocabulaire de ses utilisateurs, rend les parcours utiles évidents et incarne suffisamment la pratique pour aider chacun à prendre des décisions cohérentes.

Acheter, configurer ou construire ?

Il existe trois grandes stratégies. La plupart des projets réels les combinent, mais l’une d’elles doit rester dominante.

Stratégie	Contexte adapté	Avantage principal	Risque principal
Acheter un produit	Le langage, la méthode et les workflows sont en majorité standard	Chemin le plus rapide vers des capacités établies et du support	Contraindre une pratique spécifique dans un produit incapable de bien l’exprimer
Configurer une plateforme	Le domaine et les vues sont spécifiques, mais les besoins d’infrastructure sont communs	Concentrer l’investissement sur la sémantique et l’expérience utilisateur	Sous-estimer les extensions, l’exploitation et la propriété à long terme
Construire la technologie centrale	La plateforme elle-même est différenciante ou soumise à des contraintes que les fondations existantes ne peuvent satisfaire	Contrôle maximal de l’architecture	Reconstruire des années de travail sur les interactions, la collaboration et la maintenance

Achetez lorsque des produits établis couvrent le langage, la méthode, l’échelle, les intégrations et les contraintes de déploiement avec un niveau d’adaptation acceptable. Une configuration peut rester nécessaire, mais le produit demeure le centre de gravité.

Configurez une plateforme lorsque votre vocabulaire, vos points de vue, vos règles ou vos workflows sont spécifiques, alors que la persistance des modèles, les diagrammes, formulaires, tables, validations, la collaboration et l’infrastructure d’application web ne le sont pas. C’est dans cet espace que les plateformes d’outillage dirigées par les modèles apportent le plus de valeur.

Construisez à partir de zéro uniquement lorsqu’une exigence critique ne peut raisonnablement être satisfaite par un produit, un framework ou une plateforme existante. Une bibliothèque de diagrammes peut donner l’impression que la première démonstration est facile. Les coûts cachés arrivent ensuite : sélection, mise en page, annulation et rétablissement, copier-coller, accessibilité, concurrence, migration, permissions, performances, tests et mises à jour.

La bonne décision minimise la quantité d’infrastructure non différenciante que votre organisation doit posséder et maintenir.

Pourquoi déplacer la modélisation vers le web ?

Mettre un éditeur dans un navigateur ne constitue pas, à lui seul, une stratégie. Le web devient intéressant lorsqu’il transforme l’accès, la collaboration, l’intégration et la livraison.

Une plateforme web peut offrir :

• un accès par URL plutôt que par installation sur chaque poste ;
• des liens vers un projet, une représentation ou un élément de modèle précis ;
• une seule version déployée pour un groupe d’utilisateurs ;
• un contrôle côté serveur de la persistance et des services partagés ;
• une participation plus simple des utilisateurs occasionnels et des personnes chargées des revues ;
• une frontière naturelle pour les API et l’intégration avec d’autres systèmes web ;
• une livraison plus rapide des améliorations à tous les utilisateurs ;
• une collaboration autour du même modèle plutôt qu’un échange de fichiers.

Ces bénéfices ne sont pas automatiques. L’architecture doit gérer la latence, les modifications concurrentes, les calculs longs, le chargement partiel, les permissions, les pannes et le coût opérationnel d’un service partagé. Une application desktop peut dissimuler de nombreuses hypothèses dans un processus et un workspace. Une plateforme web doit les rendre explicites.

La transition est pertinente lorsque l’accès partagé et les workflows connectés comptent davantage que la préservation des habitudes du desktop. La transition web de Sirius et Papyrus présentée à EclipseCon 2023 montre comment ce changement rouvre les décisions d’architecture, d’utilisabilité, de collaboration et d’interopérabilité.

Le modèle et ses vues doivent rester séparés

L’un des choix d’architecture les plus importants consiste à séparer le sens du domaine de ses représentations.

Le modèle sémantique capture les concepts, les relations, les contraintes et les identités. Un diagramme sélectionne et organise une partie de ce modèle dans un but précis. Une table compare un ensemble d’éléments. Un formulaire guide une édition ciblée. Un tableau de bord calcule une vue d’ensemble. Ce sont différentes projections de la même connaissance d’ingénierie.

Lorsqu’une représentation devient le modèle, plusieurs problèmes apparaissent :

• les informations invisibles deviennent difficiles à gérer ;
• le même concept est dupliqué entre plusieurs vues ;
• les intégrations dépendent de détails graphiques ;
• les règles de cohérence se retrouvent liées à un seul éditeur ;
• l’ajout d’une représentation nécessite de modifier les données sous-jacentes.

Une plateforme doit permettre aux concepteurs d’outils de définir les éléments sémantiques qu’une vue expose, leur apparence, les opérations proposées aux utilisateurs et la façon dont ces opérations modifient le modèle. Les mêmes commandes et règles de validation doivent rester utilisables depuis d’autres vues et API.

Cette séparation est au coeur d’Eclipse Sirius : une définition de modeleur décrit la projection des données métier dans les représentations et les interactions possibles. Sirius Web transpose ces principes dans une pile web.

La collaboration dépasse l’édition simultanée

La coédition en temps réel est visible et impressionnante, mais elle ne constitue qu’une partie de la collaboration.

Les équipes d’ingénierie doivent aussi savoir :

• qui peut consulter ou modifier chaque périmètre ;
• comment une modification est révisée et expliquée ;
• si deux changements entrent en conflit sur le plan sémantique, et pas seulement technique ;
• comment représenter les baselines, branches ou versions ;
• comment des fournisseurs échangent des parties délimitées d’un modèle ;
• comment les commentaires, décisions et preuves restent reliés aux éléments du modèle ;
• comment les utilisateurs récupèrent après une erreur ou une panne de service ;
• quelles notifications sont utiles sans devenir envahissantes.

Le bon modèle de collaboration dépend de l’organisation. Une petite équipe interne et un programme impliquant plusieurs entreprises n’ont pas les mêmes besoins d’isolation, d’approbation ou de gestion de configuration.

Traitez ces workflows comme des exigences du domaine. N’imaginez pas que l’ajout de WebSockets ou d’une base de données partagée suffise à les résoudre.

L’intégration définit la frontière de la plateforme

Un modèle utile vit rarement seul. Il échange des informations avec des référentiels d’exigences, la gestion de sources, le PLM, l’ALM, la simulation, la gestion des tests, la génération documentaire, les plateformes de données et, de plus en plus, les services assistés par IA.

Pour chaque connexion, déterminez :

1. quel système est propriétaire de l’information ;
2. si l’interaction est synchrone, asynchrone ou basée sur des fichiers ;
3. comment les identités sont préservées entre les systèmes ;
4. quels changements peuvent circuler dans chaque direction ;
5. comment les échecs et mises à jour partielles sont détectés ;
6. ce que les utilisateurs peuvent inspecter lorsqu’une action automatisée modifie le modèle.

Les API sont nécessaires, mais un inventaire d’API n’est pas une architecture d’intégration. Les identifiants stables, transactions, permissions, sémantiques d’événements et traitements d’erreurs comptent tout autant.

Le prototype d’API REST Sirius Web a exploré comment exposer des modèles EMF à des clients et formats familiers. La démonstration Sirius Web et Jupyter illustre l’objectif plus large : relier conception, simulation et analyse sans transformer chaque échange en manipulation manuelle de fichiers.

Les performances sont une question de confiance

Les grands modèles révèlent les problèmes d’architecture, mais leur taille brute n’est pas la seule métrique utile. Une plateforme doit être testée avec des workflows représentatifs :

• ouvrir un projet et sa première vue utile ;
• naviguer d’un résultat de recherche vers un élément du modèle ;
• déplier un arbre profond ou très large ;
• afficher et éditer des diagrammes denses ;
• exécuter une validation ou une analyse d’impact ;
• appliquer un changement affectant plusieurs représentations ;
• servir plusieurs utilisateurs concurrents ;
• importer, exporter ou migrer des données réalistes.

La prévisibilité compte. Une opération qui prend parfois une seconde et parfois trente suscite l’hésitation, même si sa moyenne paraît acceptable. Les utilisateurs ont besoin d’un retour pendant les opérations longues et de la certitude que répéter une commande n’aggravera pas la situation.

Les performances appartiennent donc dès le départ à l’expérience utilisateur, à l’architecture des données et à la stratégie d’observabilité. Elles ne peuvent pas être déléguées à une phase finale d’optimisation.

Migrer un outil desktop exige des décisions de produit

Une migration du desktop vers le web ne doit pas commencer par une réécriture écran par écran.

Inventoriez l’outil existant en quatre groupes :

• actifs du domaine : métamodèles, bibliothèques, règles, transformations, générateurs et requêtes ;
• actifs de la pratique : points de vue, workflows, conventions de revue, modèles de documents et formations ;
• actifs d’intégration : formats de fichiers, API, connecteurs, rapports et automatisations ;
• hypothèses du desktop : mécanismes de workspace, état local, menus, préférences et points d’extension.

Les trois premiers groupes portent souvent une valeur durable. Le quatrième mérite d’être questionné. Certains concepts du desktop restent utiles ; d’autres n’existent qu’à cause de la plateforme sur laquelle l’outil original a été construit.

Planifiez une tranche verticale qui prouve un workflow complet : charger des données représentatives, les parcourir, les éditer dans une vue dédiée, valider le résultat, connecter un service externe et déployer l’ensemble sous des contraintes de sécurité réalistes. Cette approche révèle les lacunes architecturales plus tôt qu’un portage large mais superficiel.

La place de Sirius Web

Eclipse Sirius Web est un framework open source pour construire et déployer des studios de modélisation web. Son dépôt fournit des composants backend Spring Boot et frontend React réutilisables, ainsi qu’une application d’exemple.

Il est pertinent lorsqu’une organisation a besoin d’une expérience de modélisation dédiée plutôt que d’un éditeur généraliste figé. La plateforme fournit des briques pour l’exploration des modèles, les diagrammes, formulaires, tables, vues de détails, validations, opérations d’édition et extensions. Les concepteurs d’outils peuvent ainsi se concentrer sur le modèle du domaine, les vues, les comportements et les intégrations plutôt que de réimplémenter chaque interaction depuis zéro.

Cette approche conserve un enseignement important de Sirius Desktop : définir les expériences de modélisation à un niveau d’abstraction supérieur et raccourcir la boucle de retour entre la définition d’un outil et son utilisation. J’ai décrit ces principes dans Construire des outils de modélisation graphique : approches pour réduire la complexité.

Sirius Web n’est pas une solution terminée pour toutes les organisations. Une plateforme de production exige encore des décisions concernant le packaging, les identités, les permissions, la persistance, le déploiement, la supervision, les mises à jour, la migration, le support et la méthode présentée aux utilisateurs. Selon le projet, ces capacités peuvent provenir d’une application construite sur le framework ou d’une distribution supportée.

Eclipse SysON constitue un exemple concret : il utilise Sirius Web pour fournir un environnement de modélisation SysML v2, puis y ajoute le langage, les bibliothèques, les vues, les règles, les workflows et les préoccupations d’interopérabilité propres à l’ingénierie système.

Une démarche de réalisation pragmatique

Traitez la plateforme comme un produit, même lorsque ses utilisateurs sont internes.

1. Cadrez la pratique. Identifiez les utilisateurs, décisions, concepts, vues et systèmes faisant autorité.
2. Choisissez la stratégie dominante. Acheter, configurer ou construire, avec des raisons explicites pour chaque couche spécifique.
3. Prouvez une tranche verticale. Livrez un workflow utile qui traverse la sémantique, l’interface, la persistance, l’intégration et le déploiement.
4. Testez tôt avec les experts métier. Validez le vocabulaire, la navigation, le guidage et les retours avant d’étendre la couverture du langage.
5. Définissez les frontières d’extension. Séparez configuration, API supportées, code dédié et forks.
6. Concevez l’exploitation avec l’application. Intégrez sécurité, observabilité, sauvegardes, migration et mises à jour dans les critères d’acceptation.
7. Mesurez le travail réel. Suivez l’accomplissement des tâches, les erreurs, le temps de revue, la fiabilité des intégrations et l’effort d’apprentissage, pas seulement le nombre de fonctionnalités.
8. Progressez à partir de preuves. Ajoutez des rôles, vues et domaines après que l’architecture et la pratique ont résisté à un usage réel.

Cette démarche garde une première version réduite sans en faire un prototype jetable. L’objectif n’est pas de démontrer qu’un diagramme peut être dessiné. Il est de démontrer que l’organisation peut posséder et faire évoluer une pratique de modélisation.

L’actif durable est la pratique

Les choix technologiques comptent. Une fondation fragile peut rendre chaque fonctionnalité coûteuse. Mais une plateforme réussit lorsque les personnes peuvent l’utiliser pour partager du sens, prendre des décisions et connecter leur travail.

Le modèle sémantique préserve le domaine. Les vues le rendent compréhensible. Les règles le rendent fiable. Les intégrations le rendent utile au-delà de l’éditeur. L’exploitation le rend disponible. La gouvernance et la formation le rendent durable.

C’est pourquoi l’objectif ne doit pas être de construire un outil de modélisation sur mesure pour lui-même. Il faut créer la plus petite plateforme capable de faire vivre une pratique de modélisation utile, tout en s’appuyant sur des fondations maintenues pour tout ce qui ne différencie pas l’organisation.

---