Editorial Archives - Page 2 sur 2

Pourquoi vous avez besoin du low-code

9 juin 2019/0 Commentaires/dans Editorial /par Open Lowcode

Le concept du Low-code existe depuis des décennies, sous différents noms. La vague précédente s’appelait AGL (atelier de génie logiciel), mais n’a pas connu un succès majeur. L’idée du low-code est d’automatiser autant que possible le développement d’une application, et de limiter le développement ‘artisanal’ aux fonctions traitant de vraies particularités métier. Cette idée est une évidence pour qui a vécu des activités de développement, et en particulier la quantité incroyable de tâches à non valeur ajoutée.

Si le low-code reste une niche, les stratégies les plus répandues sont l’achat d’un logiciel sur étagère implémentant déjà les processus métier, ou le développement sur mesure. Récemment, la tendance forte est à la réutilisation par les entreprises des technologies de l’internet grand-public, beaucoup plus avancées.

Ces stratégies ont créé beaucoup de frustrations. Le logiciel sur étagère rend votre entreprise client captif, un fait qui n’a pas échappé aux vendeurs de logiciel. La tentation d’augmenter les prix sur ce marché captif devient difficile à résister, surtout si l’alternative est de remettre en cause l’organisation et la structure de coût pour attaquer de nouveaux marchés qui seront moins lucratifs. En plus des prix, les utilisateurs de logiciels sur étagère sont souvent bloqués par les limites des solutions achetées, qui ne sont pas toujours extensibles : peu de logiciels d’entreprise ont des interfaces propres permettant des extensions.

Le développement sur mesure a l’air plus attractif, surtout si l’on essaie de réutiliser les technologies de l’internet grand-public: la plupart des grandes applications internet sont de très bon niveau. Toutefois, les compétences nécessaires pour développer ces technologies ne sont pas toujours accessible à la direction informatique d’une entreprise, le résultat final peut donc être très différent de ce que vous avez à la maison. Et les technologies grand publics ont souvent un cycle d’obsolescence court, de l’ordre de 5 ans (vous souvenez-vous de Flash ?). C’est souvent ennuyeux, car les applications pour les entreprises ont souvent un cycle de 10 à 40 ans. Quand une application fonctionne en production, et que tout le monde est formé, il est souvent idéal de la laisser tourner le plus longtemps possible, les migrations ayant toujours, si on est honnête, un retour sur investissement négatif.

De plus, l’ergonomie des produits d’internet grand public ne sont probablement pas toujours les plus adaptées pour des systèmes d’entreprise gérant des processus complexes et critiques. La simplicité est l’alpha et l’omega des produits grand publics. Mais dans la vie professionnelle, la capacité pour des utilisateurs experts à traiter de façon efficace des quantités importantes de données (typiquement de quelques centaines à quelques dizaines de millier) semble plus importante qu’un beau design. Une des priorités pour l’entreprise est aussi la productivité des utilisateurs expérimentés (power-users), qui ont des besoins particuliers (par exemple des raccourcis claviers rapides). Pour un utilisateur expérimenté, l’interface parfaite est un cockpit d’avion, l’exemple canonique d’interface efficace pour un professionnel. La difficulté pour un bon produit professionnel est évidemment de combiner une excellente ergonomie pour les utilisateurs confirmés, et un démarrage facile pour les débutants. Ce n’est pas incompatible, et la plupart des jeux-vidéos réussissent à concilier les deux.

Les produits grand-publics s’adressent aujourd’hui d’abord au mobile, alors que la vie des employés de grande organisation se passe toujours devant un écran, avec un clavier et une souris. Commander un taxi ou chercher une adresse est bien pratique sur un téléphone, en fait, c’est même plus pratique que de le faire depuis un ordinateur car la localisation apporte beaucoup. Par contre, essayer de réaliser une opération simple de la vie de bureau, par exemple envoyer un e-mail qui comprend un extrait (copier / coller) de deux e-mails précédents, et l’expérience sera proche d’une petite torture. En revenant sur votre PC, vous ressentirez alors un soulagement intense. Et cet exemple est vraiment parmi les plus simples du travail de bureau quotidien en entreprise.

Sur ces sujets compliqués, tout n’est évidemment pas tranché. Pour les petites et moyennes entreprises, acheter un logiciel de comptabilité sur étagère est une évidence. De façon plus générale, chaque fois qu’il existe une norme (la norme comptable dans notre exemple), et que le sujet n’est pas considéré comme un différenciateur majeur, acheter un logiciel sur étagère est une bonne idée, surtout si l’on sait limiter le risque de devenir client captif. Certains services simples, comme la réservation de voyage, la validation des congés, peuvent aussi être développés comme des applications web ou mobiles.

Toutefois, il existe un vaste espace où le développement d’une solution spécifique serait optimal. Cela représente probablement 30% des besoins d’une petite organisation, et jusqu’à 80% dans une organisation plus large. Ce sont tous les cas où une ergonomie très productive est nécessaire, l’implémentation de besoins spécifiques apporte beaucoup de valeur, et un coût de possession bas est significatif.

Un bon outil low-code permet le développement et le déploiement de ces solutions spécifiques au coût le plus réduit possible. Dans les pilotes réalisés avec Open Lowcode, des applications simples qui auraient coûté entre 30 et 60K€ avec un développement traditionnel ont été déployé et 2 jours d’effort. Une application de taille moyenne représentant 300K€ de coût a été déployé en 10 fois moins. Les opérations peuvent aussi être rendues très bon marché en utilisant une infrastructure complètement open-source, dans ce cas Linux et Maria DB). L’effort fait sur les performances veut dire que l’on peut faire tourner l’application avec 10 à 20 fois moins de ressources qu’un logiciel moins optimisé.

Avec Open Lowcode, vous pouvez expérimenter l’approche low-code avec la garantie du logiciel libre, vous n’êtes jamais client captif. Vous pouvez également demander des extensions directement aux auteurs de l’outil pour un coût similaire à un développement local, et un calendrier défini. Ces extensions seront intégrées à l’outil, et donc maintenues sans coût pour vous, vous bénéficiez également des extensions demandées par les autres utilisateurs. Cela vous donne beaucoup plus de garanties de la réussite de votre projet qu’un logiciel commercial. Alors pourquoi ne pas essayer ?

Pourquoi la génération automatique de code

3 juin 2019/0 Commentaires/dans Editorial /par Open Lowcode

La génération automatique de code a souvent une mauvaise réputation. Open Lowcode l’utilise massivement. Cet article explique son intérêt, et comment les effets pervers sont contenus.

Open Lowcode propose à l’utilisateur de définir son modèle de données étendu, le modèle métier: les objets et les propriétés attachées. L’outillage génère ensuite les objets d’accès aux données, les actions et pages standards pour le modèle métier. Tout le contenu spécifique, les pages et les actions définies par les utilisateurs, doivent étendre une classe abstraite qui est aussi générée. Tout le comme est généré en java, le langage de Open Lowcode.

Après plusieurs années d’utilisation, cette technologie de génération de source automatique est clairement un bénéfice, même s’il y a quelques pièges.

Le code généré est probablement légèrement plus rapide qu’une solution utilisant des approches différentes, telles que la réflexion¹. Le code est en tout cas beaucoup plus rapide que l’interprétation d’un langage de script, et une application générée avec Open Lowcode est au moins aussi simple à développer : Elle supprime les portions ennuyeuses du développement dans les langages fortement typés ²tels que java. Une meilleure performance vous permet d’utiliser du matériel moins coûteux, ce qui est d’autant plus visible dans un environnement cloud, et cela réduit l’impact environnemental, pas du tout négligeable, de l’informatique.

L’approche de génération de code apporte une plus-value incontestable dans la maintenance des applications. Quand on réalise un nouveau développement, si le code généré ne compile pas, c’est tout de suite visible, et particulièrement si l’application est la plus typée possible. C’est encore plus vrai quand on change le modèle métier : le code « manuel » à modifier est immédiatement visible par des erreurs de compilation. Dans un nombre très important de situations, on se retrouve dans la situation idéale où « si cela compile, cela marche ».

Quand on rencontre des erreurs sur un serveur en production, le code généré produit un log très précis sur le contexte de l’erreur. Cela rend l’analyse plus facile par un facteur 10 ou 100 comparé à une technologie qui renvoie des informations plus vagues. Comme la complexité du modèle métier est limitée, le code généré est lisible, contrairement, par exemple, au html généré parfois par des outils automatiques.

La génération automatique de code permet aussi d’avoir des interfaces très agréables, pour rendre l’écriture de logique métier spécifique aussi intuitive que possible. Cela permet à des développeurs débutants, ou des experts métiers pratiquant la programmation comme un hobby, de développer sur la technologie.

Cela a un avantage particulier en java, où le code généré permet de contourner les limitations des génériques, une fonction avancée de java permettant de définir des types complexes. Cette fonction est très utile, mais supporte mal certains cas. Leur gestion est supportée par le code généré automatiquement. On pourrait rétorquer que c’est juste contourner les limites de java, et qu’il serait préférable de changer de langage. Open Lowcode utilise java car c’est une technologie robuste et mature sur laquelle il est adapté de construire des applications qui auront de 5 à 20 ans de durée de vie, et il n’y a pas vraiment d’alternative.

Il y a des inconvénients à la génération de source. Le développement est un processus en plusieurs phases où l’on définit le modèle, génère et compile les classes automatiques ,et, ensuite, on peut créer ou mettre à jour les développements spécifiques, compiler le tout, et, enfin, le déployer. Ce n’est pas aussi simple qu’un éditeur visuel de type « WISIWIG ». Mais les bénéfices de cette approche compensent largement cette lourdeur. La séparation en différentes phases peut aider aussi à mieux structurer le travail en différentes phases (architecture, développement, déploiement).

Un autre inconvénient est le nombre de classes générées, typiquement quelques centaines pour une application de taille moyenne. Ce n’est pas vraiment beau, mais pas un problème majeur.

Le défaut majeur rencontré est la tendance à devenir paresseux avec la qualité du code généré. Il est facile de générer du code long et sale qui fonctionne, alors qu’il aurait été possible de mieux modulariser le développement, et de développer des fonctions d’aide plus génériques. Ce défaut n’est pas mortel, puisqu’il est très facile de refactoriser le code généré, et de l’améliorer même après l’entrée en service.

Pourquoi l’open-source ?

31 mai 2019/0 Commentaires/dans Editorial /par Open Lowcode

La solution Open Lowcode est le résultat de centaines de jours d’effort. J’ai décidé de le publier en open-source total (pas de freemium ou de doubles licences) et voici pourquoi.

Je ne suis pas un partisan naturel de l’économie collaborative. J’ai eu l’occasion de vérifier dans de nombreuses situations que l’argent est un meilleur arbitre que les alternatives telles que la politiques, les réseaux personnels, ou même la morale. Si je fais quelque chose qui a de la valeur pour quelqu’un, cette personne me paie, et je fais ce que je veux avec l’argent: c’est équilibré, honnête et pratique. Plus généralement, je pense que l’on ne réfléchis pas assez aux problèmes en termes économiques. Nous ferions mieux d’étudier l’histoire d’un point de vue économique que de gloser sur les maitresses des rois.

Pourquoi alors choisir l’open-source ? Certaines raisons sont liées à ma situation personnelle. J’ai développé l’outil “Open Lowcode” sur mon temps personnel en étant employé d’une grande enterprise, et j’ai utilisé ce logiciel à mon travail, ce qui m’a permis de le valider. Rendre “Open Lowcode” open-source était la solution la plus élégante de sortir de la zone grise légale dans laquelle je me trouvais sans que personne (ni mon employeur, ni moi) n’ait quoi que ce soit à payer. Cela me permet aussi de publier le logiciel sans quitter pour l’instant mon emploi.

Open Lowcode est une initiative modeste. Etre complètement libre est un différenciateur facile à mettre en place, et dans de nombreuses situations, cela peut faire la différence pour faciliter l’adoption. C’est d’autant plus le cas que l’on peut maintenant avoir une solution complètement open-source à l’exception de la couche applicative, qui représente souvent la majorité des coûts. OS et bases de données ont maintenant des solutions de référence.

Même si je n’étais pas un enthousiaste du logiciel libre, après plus de 20 ans en direction informatique, je suis maintenant convaincu que c’est la bonne solution dans la plupart des cas. D’abord, le logiciel ne coûtant rien à copier et distribuer, un utilisateur supplémentaire ne coûte rien. Si le logiciel est gratuit, un utilisateur supplémentaire qui se débrouille tout seul est complétement transparent. C’est différent d’une boulangerie qui offrirait des croissants gratuits aux étudiants, et qui pourrait se mettre en difficulté à cause de cela. Il y a de plus de nombreux inconvénients à rendre un logiciel commercial. Le coût des ventes est énorme, souvent beaucoup plus important que les investissements dans le produit. Au contraire, le logiciel libre se diffuse par le bouche à oreille. Et je ne suis pas sûr qu’il soit possible, pour un vendeur de logiciel, de gérer correctement la situation où ils bénéficient d’une rente de clients captifs. Presque toujours, cela veut dire, à des degrés divers, un produit limité et des coûts de license astronomiques.

Le logiciel libre est de meilleur qualité, et souvent de façon vraiment significative par rapport aux alternatives commerciales. C’est d’abord grâce à l’ouverture des sourrces: elle permet aux utilisateurs de trouver, et souvent de corriger eux-mêmes, les défauts. Une autre raison de cette qualité est le processus de décision. Un éditeur de logiciel n’est pas le meilleur endroit pour prendre des décisions de long-terme sur le produit: celles-ci seront affectées par des considérations politiques et marketing, parfois de court-terme. Le processus de décision sera presque toujours meilleur que l’instinct du développeur de l’application, surtout s’il a l’occasion de discuter directement avec ses utilisateurs.

L’open-source a aussi ses dangers: sans le modèle économique évident de la vente de licenses, il n’est pas facile de mettre en place une communauté durable pour maintenir l’outil dans le temps, c’est à dire une communauté où tous les contributeurs y trouvent leur compte. Le plaisir et l’égo peuvent parfois suffire, mais c’est improbable pour un logiciel d’entreprise qui a aussi ses composants nécessaires et ennuyeux. Il est évidemment possible de contribuer à l’outil sur son temps de travail, ce qui est fréquent. On peut en général développer une fonction manquante ou corriger une erreur en moins de temps qu’il n’en faudrait pour contacter le support d’un logiciel commercial.

Avant de commencer

19 mai 2019/0 Commentaires/dans Editorial /par Open Lowcode

Nous sommes au début d’une aventure de “low-code”, ou “atelier de génie logiciel” en bon français, une idée des années 90 qui mérite une seconde change. Après 20 ans d’informatique d’entreprise, j’ai développé et déployé des solutions logicielles ces 20 dernières années. La grande constante de ces années en DSI est un gâchis épique. Cela commence par des développeurs qui passent la majeure partie de leur temps à des tâches désagréables d’assemblages de composants mal finis, tâches n’apportant aucune valeur métier. A la fin de la chaîne, une egonomie rugueuse et des performances médiocres font perdre le sourire et beaucoup de temps à nos victimes. Et vous n’êtes pas à l’abris de lenteurs même si vous avez investi dans un serveur luxueux, qui, il y a 20 ans, aurait fait tourner sans problème la sécurité sociale d’un grand pays. Le coût arbitraire des licences logicielles, et les perturbations des mises à jour imposées sur un système qui pourtant tourne parfaitement, méritent aussi d’être mentionné. Et tout n’a pas été mentionné, c’est un puit sans fond.

La grande constante de ces années en DSI est un gâchis épique

Après quelques années à souffrir, l’idée que l’on pouvait faire mieux devint une évidence. j’ai commencé à expérimenter il y a 10 ans, et la solution s’est construite progressivement. Il y a 4 ans, j’ai présenté à mes collègues la solution, et j’ai pu la tester sur certains de nos cas métiers. Les premiers déploiement ne furent pas sans histoire, mais les problèmes ont été rapidement résolus, et ont confirmé le choix clé de la simplicité: les corrections en sont d’autant plus faciles.

La solution Open Lowcode sera déployée progressivement dans les semaines à venir. Elle sera complètement open-source. Tous les services professionnels que vous pourriez souhaiter seront également offerts. Cela devrait permettre d’offrir le meilleur des deux mondes: la qualité sans contraintes de l’open-source, et le confort des services offerts autour des solutions commerciales.

Archive pour la catégorie : Editorial