Sci Simple

New Science Research Articles Everyday

# Informatique # Génie logiciel

Se libérer du verrouillage des fournisseurs de low-code

Apprends à gérer le verrouillage des fournisseurs dans les plateformes low-code.

Iván Alfonso, Aaron Conrardy, Jordi Cabot

― 11 min lire


Échappe-toi du Échappe-toi du verrouillage des fournisseurs maintenant plateformes low-code. Libère-toi des contraintes des
Table des matières

Les plateformes low-code sont des outils qui permettent aux utilisateurs de créer des applications avec peu de code. Elles offrent un moyen visuel de construire et de modifier des logiciels, ce qui peut accélérer le développement et rendre ça plus accessible aux non-programmeurs. Cependant, ces plateformes ont souvent du mal à bien fonctionner ensemble, ce qui crée une expérience frustrante pour les utilisateurs.

Le problème de la dépendance au fournisseur

Un des principaux problèmes que rencontrent les gens en utilisant des plateformes low-code, c'est la dépendance au fournisseur. Ça veut dire qu’une fois que tu as construit ton application sur une plateforme précise, la transférer ailleurs, c'est comme essayer de sortir d'une mauvaise relation : tu dois tout recommencer. Les utilisateurs peuvent se retrouver coincés parce que les différentes plateformes ne communiquent pas ou ne partagent pas les infos facilement. En gros, transférer ton projet sur une autre plateforme, c'est un peu comme essayer de changer de coiffure dans un salon qui ne sait faire que des franges.

Qu'est-ce que l'Interopérabilité ?

L'interopérabilité, c'est la capacité de différentes plateformes à bosser ensemble, même si elles parlent des langages ou suivent des règles différentes. C'est comme essayer de faire discuter des potes de cultures différentes à une soirée. S'ils ne parlent que leur propre langue sans une compréhension commune, ça va être compliqué. Un bon niveau d'interopérabilité signifie que les différentes plateformes peuvent se comprendre et aider les utilisateurs à migrer leurs projets plus facilement.

État actuel des plateformes low-code

Le marché low-code a plusieurs plateformes populaires comme Mendix, OutSystems et Microsoft PowerApps. Ces plateformes sont connues pour leurs capacités robustes mais sont souvent critiquées pour leurs options limitées de transfert de projets d'une à l'autre. C'est comme avoir le meilleur food truck de la ville, mais qui ne sert qu'un seul type de taco. Les clients adorent le taco, mais ils pourraient vouloir un burrito d'un autre camion un jour, sauf qu'ils sont coincés au stand de tacos.

Ces plateformes tendent à offrir des fonctionnalités d'importation et d'exportation limitées, ce qui peut être un gros obstacle. Même si elles utilisent des formats techniques similaires, les schémas et langages sous-jacents diffèrent suffisamment pour créer des barrières dans la migration de données.

Analyser l'interopérabilité

Pour comprendre l'interopérabilité des plateformes low-code, on peut regarder quelles options sont dispo pour importer et exporter des modèles. Pense à ça comme faire l’inventaire dans une cuisine pour voir quels ingrédients sont disponibles pour cuisiner un nouveau plat.

Quand les plateformes offrent seulement des fonctionnalités de base, beaucoup d'utilisateurs se retrouvent avec des recettes incomplètes. Par exemple, certaines plateformes pourraient permettre d'exporter une structure de données, mais pas les relations ou d'autres détails importants nécessaires à une application pour bien tourner. Les utilisateurs deviennent alors des chefs qui doivent bosser avec des ingrédients à moitié cuits, et c'est plutôt dur de préparer un repas complet.

Notre approche de l'interopérabilité

Pour améliorer l'interopérabilité, on propose une approche basée sur les modèles. Ça veut dire qu’au lieu de recommencer à zéro chaque fois qu'un utilisateur veut migrer un projet, il peut partir d'un point standard. C'est un peu comme avoir une télécommande universelle pour différentes marques de télé : il te faut juste un outil pour gérer tout ça.

Cette approche basée sur les modèles peut fonctionner dans deux scénarios principaux :

  1. Méthode d'exportation formelle : Si une plateforme permet d'exporter des modèles dans un format lisible, on peut facilement extraire les infos nécessaires à la préparation de la migration.

  2. Méthode d'exportation alternative : Si une plateforme n'offre pas d'export formel, on peut utiliser des méthodes de reconnaissance visuelle pour analyser des captures d'écran de modèles et générer un nouveau modèle basé sur cette image.

Méthode d'exportation formelle

Quand une plateforme propose une manière d'exporter des modèles au format textuel, le processus devient plus simple. Ça permet d'extraire des infos, comme des classes et des relations, et de les transformer en un modèle qui peut être utilisé sur une nouvelle plateforme. Cette approche offre une transition plus fluide, un peu comme passer d'une chanson à une autre dans une playlist.

Ici, les règles de transformation guident le processus d'exportation. Chaque plateforme a sa façon unique de structurer les données, mais beaucoup d'entre elles utilisent des concepts similaires, ce qui rend plus facile la traduction d'une à l'autre. L'idée, c'est d'identifier les éléments qui peuvent être transformés de la plateforme source à un format que la plateforme cible peut comprendre.

Méthode d'exportation alternative

Dans les cas où une plateforme ne fournit pas de fonctionnalité d'exportation adéquate, on peut se tourner vers des modèles visuels. En analysant une image du modèle, on peut générer une nouvelle représentation. Bien que cette méthode ne capture peut-être pas tous les détails, elle agit comme un plan de secours lorsque le premier plan échoue, un peu comme trouver un snack quand le dîner est retardé.

Un modèle de langage visuel (comme un super outil d'IA) aide à interpréter la capture d'écran et à recréer le modèle. Ce processus implique de donner un peu de contexte sur la plateforme spécifique pour s'assurer que l'IA comprend comment interpréter l'image avec précision.

Importation de modèles

Une fois que le modèle est prêt, c'est le moment de penser à l'importer sur la plateforme cible. Ce processus peut également avoir deux scénarios :

  1. Méthode d'importation formelle : Si la plateforme cible permet l'importation formelle, on peut générer les fichiers nécessaires qui correspondent au format attendu.

  2. Méthode d'importation alternative : Dans les cas où il n'y a pas d'option d'importation directe, beaucoup de plateformes permettent aux utilisateurs de télécharger des données de sources comme Excel ou des fichiers CSV pour créer de nouveaux projets. C'est un peu comme utiliser une boîte à emporter pour ramener des restes d'un restaurant à un autre.

Méthode d'importation formelle

Quand une plateforme supporte les imports formels, on peut créer des fichiers structurés d'une manière que la nouvelle plateforme peut comprendre. Cela implique de mapper les éléments du modèle généré au langage et à la syntaxe de la plateforme cible.

Ce mappage sert de guide de traduction, en s'assurant que tout s'assemble correctement et permet une transition fluide. De plus, des plateformes comme Appian et Oracle Apex permettent d'importer des projets complets, incluant des données, des comportements et des modèles graphiques, via des formats prédéfinis.

Méthode d'importation alternative

Pour les plateformes qui ne supportent pas les imports directes de modèles, beaucoup permettent l'importation de données depuis des fichiers comme Excel ou CSV. Ce n'est pas une méthode standard pour importer un modèle de données mais ça sert d'alternative pour les utilisateurs dans ces situations. Le processus implique de créer des fichiers structurés qui aident à inférer le modèle de données nécessaire à la plateforme cible.

Quand on utilise Excel, chaque feuille génère une nouvelle classe, et les colonnes créent des attributs. Cependant, cette méthode peut ne pas capturer les relations aussi précisément, ce qui mène à des modèles moins complets. Pense à ça comme commander une salade sans vinaigrette ; ça peut être sain mais pas très satisfaisant.

Défis à venir

Malgré les méthodes proposées pour améliorer l'interopérabilité, des défis demeurent. Les utilisateurs doivent être conscients que les plateformes low-code manquent souvent de documentation ou de support robuste pour migrer des projets, ce qui peut mener à une expérience frustrante. L'accent pour beaucoup de plateformes commerciales est mis sur la rétention des clients plutôt que sur l'aide à la migration ailleurs. Les gens se retrouvent coincés avec des produits qui ne facilitent pas les sorties faciles, ce qui peut ressembler à être coincé dans un pitch de vente interminable pour un produit que tu ne voulais même pas acheter.

Construire un modèle d'échange standard

Une solution clé au dilemme de l'interopérabilité est la création d'un modèle d'échange standard pour les plateformes low-code. L'absence de modèle standardisé signifie que chaque plateforme fonctionne dans sa bulle, créant des points de friction pour les utilisateurs qui veulent changer.

Créer un tel modèle permettrait des transferts fluides entre les plateformes, un peu comme des emoji standardisés entre appareils aident les gens à communiquer plus librement, peu importe la marque de téléphone qu'ils possèdent. Avec tout le monde chantant la même chanson, déplacer des modèles entre les plateformes deviendrait un jeu d’enfant, et les utilisateurs pourraient se concentrer davantage sur la construction et moins sur les soucis de compatibilité.

Surmonter les limitations d'importation/exportation

Les limitations dans les fonctionnalités d'import/export peuvent mener à des modèles incomplets, laissant les utilisateurs avec un puzzle qui manque des pièces cruciales. Bien que la complétion manuelle soit une option, il serait bien plus efficace de développer des techniques qui automatisent le processus de récupération des éléments manquants. Pense à ça comme un service de recettes fiable qui te donne les étapes manquantes si tu les as oubliées en cuisinant.

Utiliser l'IA ou des méthodes plus simples basées sur des règles peut améliorer l'expérience de migration, permettant aux utilisateurs de concentrer leurs efforts ailleurs au lieu de jouer les détectives. L'objectif serait de rendre la transition aussi facile que bonjour.

Migration incrémentale

Au-delà de la migration de modèles complets, les plateformes devraient envisager l'idée de migration incrémentale. Ça signifie reconnaître des composants existants et ajouter de nouveaux éléments sans écraser les modifications personnalisées de l'utilisateur. Imagine une plateforme logicielle qui propose de saupoudrer des garnitures fraîches sur ta pizza sans changer tout le reste. C'est une question de donner aux utilisateurs flexibilité et contrôle sur leur travail.

Méthodes basées sur l'IA pour l'import/export

Explorer des techniques avancées d'IA pour les méthodes d'importation et d'exportation alternatives pourrait aussi améliorer le processus. Pour l’exportation, utiliser la reconnaissance d’images multiples ou de vidéos pourrait renforcer la compréhension de l'IA des grands modèles, lui permettant de capturer avec précision chaque détail.

Pour l'importation, former une IA à reproduire un modèle en utilisant l'interface utilisateur de la plateforme cible serait un véritable changement de jeu. Cet assistant intelligent pourrait guider les utilisateurs dans la recréation de leurs modèles, rendant la transition moins intimidante.

La voie à suivre

Bien qu'il existe des défis importants, le paysage low-code évolue, et des améliorations peuvent se produire. S'attaquer au problème de la dépendance aux fournisseurs et améliorer l'interopérabilité peut mener à de meilleures expériences pour tous les utilisateurs. En créant une approche plus unifiée, les utilisateurs bénéficieraient de transitions plus rapides et de moins de maux de tête.

Développer un meilleur soutien d'outils, surtout pour les modèles UI et comportementaux, est crucial. Cela inclut des plans pour créer des interfaces conviviales qui simplifient le processus de migration. Imagine un bon pote dans le monde du logiciel, te guidant étape par étape à travers le processus de déménagement.

Alors que les développeurs et les innovateurs continuent de travailler sur ces solutions, l’espoir est qu'une nouvelle ère de collaboration émerge, permettant aux utilisateurs de tirer pleinement parti des plateformes low-code sans se sentir coincés dans l'écosystème d'un seul fournisseur. L'avenir est prometteur, et il pourrait inclure un monde où les plateformes low-code s'entendent vraiment bien entre elles !

Source originale

Titre: Towards the interoperability of low-code platforms

Résumé: With the promise of accelerating software development, low-code platforms (LCPs) are becoming popular across various industries. Nevertheless, there are still barriers hindering their adoption. Among them, vendor lock-in is a major concern, especially considering the lack of interoperability between these platforms. Typically, after modeling an application in one LCP, migrating to another requires starting from scratch remodeling everything (the data model, the graphical user interface, workflows, etc.), in the new platform. To overcome this situation, this work proposes an approach to improve the interoperability of LCPs by (semi)automatically migrating models specified in one platform to another one. The concrete migration path depends on the capabilities of the source and target tools. We first analyze popular LCPs, characterize their import and export alternatives and define transformations between those data formats when available. This is then complemented with an LLM-based solution, where image recognition features of large language models are employed to migrate models based on a simple image export of the model at hand. The full pipelines are implemented on top of the BESSER modeling framework that acts as a pivot representation between the tools.

Auteurs: Iván Alfonso, Aaron Conrardy, Jordi Cabot

Dernière mise à jour: 2024-12-06 00:00:00

Langue: English

Source URL: https://arxiv.org/abs/2412.05075

Source PDF: https://arxiv.org/pdf/2412.05075

Licence: https://creativecommons.org/licenses/by/4.0/

Changements: Ce résumé a été créé avec l'aide de l'IA et peut contenir des inexactitudes. Pour obtenir des informations précises, veuillez vous référer aux documents sources originaux dont les liens figurent ici.

Merci à arxiv pour l'utilisation de son interopérabilité en libre accès.

Plus d'auteurs

Articles similaires