Programme de services de développement Low-Code : guide de l'acheteur

Un programme de services de développement low-code est un moyen structuré d’acheter la livraison d’applications, regroupant une plate-forme visuelle, des services professionnels et un support continu sur environ quatre modèles d’engagement : augmentation du personnel, livraison de projets à portée fixe, services d’applications gérés et partenariats plateforme et accompagnement. Gartner a inventé le terme « low-code » en 2014, et le marché s’est depuis divisé en catégories de services distinctes qui se comportent très différemment en termes de coût, de contrôle et de verrouillage.

Les programmes de services de développement low-code regroupent trois éléments qui sont généralement vendus séparément dans l’informatique traditionnelle : une plate-forme de développement visuel, les services professionnels pour s’appuyer sur celle-ci et le support continu pour maintenir le fonctionnement des applications résultantes. Les acheteurs qui comprennent ce regroupement peuvent négocier chaque couche indépendamment – ​​et c’est là que la majeure partie de la valeur est gagnée ou perdue.

La couche plate-forme est constituée des outils : générateurs de formulaires par glisser-déposer, concepteurs de modèles de données, moteurs de workflow, connecteurs API et pipelines de déploiement. Les exemples cités incluent Microsoft Power Apps, OutSystems, Mendix, Appian, Retool, Budibase et, pour les équipes déjà investies dans l’écosystème 4D, les propres outils de formulaire, de méthode et de modèle de données de 4D.

La couche services est le travail humain : ateliers de découverte, modélisation des données, intégration, tests et transfert. La couche de support correspond à ce qui se passe après la mise en ligne : surveillance, demandes de modification, mises à niveau de version et formation des utilisateurs.

Un programme de services de développement low-code diffère d’un projet ponctuel sur un point important : il suppose une livraison répétée. Au lieu de commander une seule application, l’acheteur met en place une capacité permanente – un modèle de gouvernance, une bibliothèque de composants réutilisables et une cadence de livraison – de sorte que la deuxième application coûte bien moins cher que la première. Cette économie de réutilisation est la seule justification du cadrage du « programme ».

Comparaison des quatre modèles de services

Les services de développement low-code se présentent sous des formes qui conviennent à des organisations très différentes. Le tableau ci-dessous constitue l’aide à la décision dont la plupart des acheteurs ont besoin avant de parler à un fournisseur.

Connexes : Claris FileMaker Pro — La plateforme de base de données relationnelle de longue date pour les équipes qui ont besoin d'applications personnalisées sur ordinateur, Web et mobile à partir d'un seul fichier..

Modèle	Acheteur type	Contrôle	Profil de coût	Risque principal
Augmentation du personnel	Équipe informatique avec des lacunes en matière de compétences en matière de plate-forme	Haut — vous dirigez le travail	Tarif horaire ou mensuel	Les connaissances partent avec l’entrepreneur
Projet à portée fixe	Département avec une application définie	Faible pendant la construction	Prix ​​fixe par application	Demandes de modification facturées séparément
Services d’applications gérés	Équipe opérationnelle exécutant des applications en direct	Faible à moyen	Rémunération récurrente	Réponse lente aux nouvelles exigences
Partenariat plateforme + accompagnement	Organisation renforçant les capacités internes	Moyen, grandit avec le temps	Mixte : plateforme, formation, développement	Nécessite du temps pour le personnel interne à absorber

L’augmentation du personnel convient aux équipes qui disposent déjà d’une plate-forme standard et d’un retard. Les projets à portée fixe conviennent à un flux de travail unique à grande valeur ajoutée avec des exigences stables.

Les services gérés conviennent aux environnements réglementés où la disponibilité et les pistes d’audit comptent plus que la vitesse. Les partenariats d’accompagnement conviennent aux organisations qui ont l’intention de créer des dizaines d’applications et qui souhaitent disposer de cette fonctionnalité en interne.

Une règle pratique : si l’acheteur ne peut pas nommer la personne qui détiendra l’application dans dix-huit mois, le programme est acheté pour une mauvaise raison. Les programmes de services de développement low-code échouent le plus souvent, non pas parce que la plate-forme était erronée, mais parce qu’aucun propriétaire interne n’a jamais été attribué.

Notre sélection : Airtable — Une interface simple sous forme de feuille de calcul reposant sur une véritable base de données relationnelle, avec des automatisations, des vues et des interfaces partageables..

Comment les services Low-Code et No-Code diffèrent dans la pratique

Les services de développement low-code et no-code sont souvent commercialisés comme une seule catégorie, mais les deux moitiés imposent des contraintes différentes sur un engagement de services. Les outils no-code ciblent les utilisateurs professionnels qui configurent des applications sans écrire de logique ; Les outils low-code supposent qu’un développeur étendra la plateforme avec du code lorsque les capacités du constructeur visuel seront atteintes.

Cette distinction modifie le contrat de services. Un engagement no-code concerne principalement la configuration, la formation et la gouvernance : le travail du fournisseur consiste à maintenir les développeurs citoyens dans des limites sûres. Un engagement low-code ajoute une ingénierie d’intégration, des composants personnalisés, un réglage des performances et une configuration CI/CD, car les applications sont censées toucher les systèmes de production et évoluer.

La plupart des programmes d’entreprise finissent par être hybrides. Un niveau no-code gère les suivis départementaux, les flux d’approbation et la collecte de données. Un niveau de programme de services de développement low-code gère tout ce qui écrit sur un système principal, applique des règles métier complexes ou nécessite une piste d’audit. Les fournisseurs qui ne vendent qu’un seul niveau repousseront toutes les exigences dans ce niveau, ce qui mérite d’être surveillé lors de la détermination de la portée.

À quoi ressemble un véritable engagement, phase par phase

La fourniture de services de développement low-code suit un arc reconnaissable, et connaître les phases permet à un acheteur de repérer un fournisseur qui évite les plus coûteux.

Découverte et modélisation des données. Le fournisseur cartographie le processus métier, identifie les entités et les relations, et décide de ce qui se trouve dans la plateforme low-code par rapport à ce qui reste dans le système d’enregistrement. La modélisation des données est à l’origine de la plupart des retouches ; un formulaire construit sur un mauvais modèle d’entité est reconstruit et non corrigé.

Prototype et validation. Un prototype fonctionnel sera présenté à de vrais utilisateurs dans les premières semaines. Les plates-formes low-code rendent cela rentable, et un fournisseur qui ne peut pas créer rapidement un prototype cliquable ne profite pas du principal avantage de la plate-forme.

Connexes : Knack — Un générateur de base de données sans code destiné aux portails, aux annuaires et aux outils internes, avec une tarification forfaitaire au lieu de frais par utilisateur..

Création et intégration. Les écrans, les flux de travail, les listes de valeurs et les connexions API sont assemblés. L’intégration est généralement l’élément le plus important de toute estimation honnête, car l’authentification, la gestion des erreurs et la synchronisation des données ne sont jamais aussi simples que le suggère la démo.

Tests et renforcement. L’accès basé sur les rôles, la validation des entrées, le comportement de concurrence et les performances sous des volumes de données réalistes sont vérifiés. Les plates-formes low-code cachent la complexité, ce qui signifie que les problèmes de performances apparaissent souvent tardivement.

Déploiement et transfert. L’application passe à la production et, surtout, la documentation, la formation des administrateurs et le transfert du processus de demande de modification à l’équipe interne.

Coup de cœur des lecteurs : Microsoft Power Apps — Développement d'applications low-code de niveau entreprise connecté à Microsoft 365, Dataverse et Power Automate..

Exploiter et itérer. Le programme de services de développement low-code se poursuit avec un backlog, une cadence de publication et des mises à niveau périodiques de la plateforme. Les fournisseurs de plates-formes publient les nouvelles versions selon leur propre calendrier, et quelqu’un doit absorber ces changements.

Critères de sélection qui prédisent réellement le succès

L’évaluation des fournisseurs de services de développement low-code sur la seule base de la reconnaissance de la marque produit des erreurs coûteuses. Les critères ci-dessous sont ceux qui correspondent aux programmes de services de développement low-code qui survivent à leur deuxième année.

• Coût de sortie de la plateforme. Demandez ce qui arrive à l’application si l’engagement prend fin. Les données peuvent-elles être exportées dans un format utilisable ? La logique peut-elle être lue par quelqu’un d’autre ? La logique visuelle propriétaire constitue le risque de verrouillage le plus important sur ce marché.
• Antécédents d’intégration. Demandez deux références impliquant la même classe de système que vous devez connecter : un ERP, un CRM, une base de données existante ou un annuaire sur site.
• Équipe nommée, pas un ensemble de capacités. Demandez qui fera réellement le travail et si ces personnes sont des employés ou des sous-traitants.
• Artefacts de gouvernance. Un programme sérieux produit une stratégie d’environnement, un modèle de contrôle d’accès et une convention de dénomination. Les vendeurs qui les considèrent comme facultatifs créent une dette d’entretien future.
• Engagement de transfert. Le contrat doit spécifier la documentation, la formation administrative et une période définie de support post-lancement.
• Transparence des prix. Des tarifs par application, par utilisateur, par heure et par forfait existent tous. Le modèle importe moins que de savoir si le fournisseur vous montrera comment le numéro a été construit.

Pour la diligence raisonnable au niveau de la plateforme, les recherches d’analystes publiées par des sociétés telles que Gartner et Forrester constituent un point de départ raisonnable, et l’entrée Wikipédia sur les plateformes de développement low-code donne un aperçu neutre de l’historique et des définitions de la catégorie. Les acheteurs des secteurs réglementés doivent également vérifier la position du fournisseur par rapport au NIST Cybersecurity Framework, que de nombreuses équipes d’approvisionnement d’entreprise utilisent désormais comme vocabulaire commun pour les questions de sécurité.

Là où les programmes Low-Code sont vraiment rentables – et là où ils ne le sont pas

Les programmes de services de développement low-code offrent les meilleurs retours sur les applications nombreuses, similaires et de courte durée. Les formulaires de demande internes, les flux de travail d’approbation, les listes de contrôle d’inspection, les suivis d’inventaire et les tableaux de bord départementaux correspondent à ce modèle : chacun est petit, chacun partage des composants avec ses frères et sœurs, et chacun resterait autrement dans un retard informatique pendant des mois.

Les programmes peinent lorsque l’application est véritablement complexe. Les systèmes transactionnels à grand volume, les applications avec des exigences de concurrence complexes et tout ce qui nécessite des calculs lourds en temps réel sont généralement mieux servis par le développement conventionnel – ou par un hybride où la couche low-code gère l’interface et un service conventionnel gère la logique de base.

Un deuxième modèle d’échec est celui du pilote abandonné. Les organisations réalisent souvent une preuve de concept réussie, puis stagnent parce que personne n’a financé la couche de gouvernance. Le pilote prouve que la plateforme fonctionne ; cela ne prouve pas que le programme fonctionne. La budgétisation des parties ennuyeuses (gestion de l’environnement, examen de la sécurité, formation et support) est ce qui transforme un projet pilote en programme.

Un troisième modèle est la prolifération du Shadow IT. Lorsque les développeurs citoyens créent librement sans bibliothèque de composants ni processus de révision, une organisation peut se retrouver avec des centaines d’applications quasi-dupliquées et aucun inventaire de ce qui existe. Un programme de services doit inclure un registre d’applications dès le premier jour.

Build versus Buy : quand un programme interne bat un programme externe

Les organisations disposant d’une capacité de développement existante se demandent parfois si elles ont besoin de services de développement externes low-code. La réponse honnête dépend de trois variables : le nombre d’applications prévues, le caractère inhabituel des exigences d’intégration et la standardisation ou non de la plateforme.

Un programme interne a du sens lorsque l’organisation s’est engagée sur une seule plate-forme, planifie plus d’une poignée d’applications et peut consacrer au moins un développeur expérimenté à la propriété de la plate-forme. Le rôle du fournisseur externe se réduit alors à un accompagnement initial et à un travail spécialisé occasionnel.

Un programme externe a du sens lorsque le choix de la plateforme est encore ouvert, lorsque les premières applications impliquent des intégrations inconnues ou lorsque le personnel interne ne peut tout simplement pas être libéré des engagements existants. Dans ce cas, le contrat doit être rédigé avec une rampe de sortie explicite – un point auquel l’équipe interne prend le relais – plutôt qu’un mandat à durée indéterminée.

Les équipes qui construisent sur 4D occupent souvent une position médiane. Le modèle de données, les formulaires et les méthodes sont déjà familiers au développeur interne. Les services externes sont donc particulièrement utiles pour le travail d’intégration, l’architecture de déploiement et la modernisation des anciennes structures binaires. Il s’agit d’un engagement plus restreint qu’un programme complet, et son prix doit être fixé en conséquence.

Sources et lectures complémentaires

• Plateforme de développement low-code — Wikipédia : Une plate-forme de développement low-code (LCDP) fournit un environnement de développement logiciel – généralement une interface utilisateur graphique (GUI) – qui implique peu ou pas d’écriture…

Questions fréquemment posées

Qu’est-ce qu’un programme de services de développement low-code ?

Un programme de services de développement low-code est un accord permanent dans lequel un fournisseur fournit à la fois une plate-forme low-code et les services professionnels nécessaires pour créer, déployer et maintenir des applications sur celle-ci. Il diffère d’un projet unique car il suppose une livraison répétée, des composants partagés et un modèle de gouvernance continu. Les acheteurs choisissent généralement entre l’augmentation du personnel, les projets à portée fixe, les services gérés et les partenariats d’habilitation.

Combien coûtent les services de développement low-code ?

Les prix varient trop considérablement pour un seul chiffre fiable, car ils dépendent de la licence de la plateforme, du modèle d’engagement et de la complexité des intégrations. Les fournisseurs proposent des tarifs horaires, par application, par utilisateur ou sous forme de forfait mensuel, et les licences de plateforme sont généralement facturées séparément des services. La comparaison la plus utile est le coût total par application livrée sur une feuille de route multi-applications, et non le tarif global.

Le développement low-code est-il adapté aux applications d’entreprise ?

Le low-code convient aux applications d’entreprise qui sont nombreuses, basées sur des flux de travail et exigeantes en intégration : systèmes d’approbation, trackers, portails et outils départementaux. Il convient moins bien aux cœurs transactionnels à grand volume, au calcul en temps réel et aux systèmes présentant des exigences de concurrence inhabituelles. De nombreuses entreprises utilisent une méthode hybride : low-code pour l’interface et la couche de flux de travail, code conventionnel pour la logique de base.

Quelle est la différence entre les services de développement low-code et no-code ?

Les services sans code se concentrent sur la configuration et la gouvernance afin que les utilisateurs professionnels puissent créer en toute sécurité sans programmation. Les services low-code ajoutent une ingénierie d’intégration, des composants personnalisés, un réglage des performances et des pipelines de déploiement, car les applications sont censées toucher les systèmes de production. La plupart des programmes d’entreprise exploitent les deux niveaux, acheminant les applications simples vers le no-code et les plus complexes vers le low-code.

Combien de temps faut-il pour livrer une application via un programme de services low-code ?

Un prototype peut souvent être présenté au cours des premières semaines, et une application départementale simple atteint généralement la production en quelques mois plutôt qu’en quelques trimestres. Les délais s’allongent lorsque les intégrations sont complexes, que les examens de sécurité sont lourds ou que les exigences changent en cours de construction. Le réel avantage de rapidité du programme apparaît sur les deuxième et troisième applications, une fois les composants et la gouvernance mis en place.

Que doit inclure un contrat de services low-code ?

Un contrat doit spécifier l’équipe de livraison nommée, les responsabilités en matière de plate-forme et de licence, la portée de l’intégration, la documentation et la formation des administrateurs, une période de support post-lancement définie et les conditions dans lesquelles l’acheteur peut prendre le travail en interne. Les droits d’exportation de données et la lisibilité de la logique personnalisée doivent faire l’objet de clauses explicites, car ils déterminent le coût pour quitter le fournisseur ultérieurement.