NB : par avance l’utilisation de certains termes barbares, même si j’ai fait de mon mieux pour les clarifier. Malheureusement le dictionnaire de la vulgarisation n’est pas encore complètement à jour.

Pour continuer sur la lancée de  mon  précédent article, je me suis demandé comment affiner la définition du low code. 

Il existe,d’après ma dernière définition (souvenez vous : Tout ce qui démocratise l’informatique.  Tout ce qui réconcilie nos utilisateurs avec l’IT est du low code), une multitude de solutions qui pourraient s’apparenter à du low code.

Pour en étudier la quintessence, il est essentiel de voir ces solutions sous l’angle de ses utilisateurs .

En effet , pour un langage informatique, nous trouvons aisément des comparatifs basés sur des principes de performance, adaptabilité , scalabilité, sécurité.

Je vous propose plutôt de nous y intéresser via le prisme de différents types d’utilisateurs. Car si le Low Code est une solution si innovante, c’est qu’il répond aux attentes de nombreuses « personas », comme je le soutiens…

La DSI

Grâce au low code, les DSI pourront :

  • Lutter contre le « shadow IT ».

Shadow IT : Initiatives menées de bout en bout par les services, les départements, Business Units ou les régions sans coordination avec les DSI. Ce sont parfois de bonnes initiatives lorsqu’elles sont partagées, mais qui créent de la dette technique et fonctionnelle quand elle sont complètement déconnectées des best practices de la DSI.

« Ce fut l’un des déclencheurs de l’introduction du low code chez Euler Hermes »

Toujours maîtriser leurs applications

Ne pas utiliser à proprement parler de langage de programmation permet à l’IT, de naviguer « comme dans un livre »  au cœur des applications.

  • Diminuer les coûts de développement des applications

Le low code permet de diminuer par 6 les coûts de développement, tout en accélérant par 6 le temps de développement Oui ça fait rêver …  Cela fera l’objet d’un article spécifique.

  • Diminuer les coûts de maintenance des applications 

La vérification des bugs au moment de la compilation du code réduit considérablement le nombre de bugs

Le Marketing 

Grâce au low code les équipes Marketing pourront :

  • Créer des maquettes fonctionnelles

Terminés les PowerPoints et les figmas  qui présentent des données figées (même si j’admets qu’il existe des outils plus évolués ), tout s’opère sur un seul outil et un seul environnement, puisque les développeurs peuvent directement travailler à partir de la maquette produite par le marketing. 

  • Normaliser les composants pour une utilisation multicanale

Une fois de plus, j’admets qu’il existe des outils qui font aussi le job, mais sans les mêmes avantages et l’efficacité que j’ai pu tester en Low code. 

  • Collaborer de bout en bout à la conception des applications
  • Utiliser le concept de l’AB testing 

L’utilisation de blocs fonctionnels permet de tester plusieurs dispositions avec les mêmes fonctionnalités et données tests.

Le product Owner

Grâce au low code le product owner pourra :

  • Suivre la réalisation de ses « user stories » en temps réel 

Dans les outils low code l’agilité est l’ADN de l’environnement et les commits (envoi des versions sur le serveur ) sont liés aux user stories 

  • Avoir une vision globale et multicanale du produit

Pour mémoire, le Product Owner est le responsable du respect du produit dans le monde Agile. C’est celui qui garantit que le produit développé correspond bien à la vision du porteur de projet .

Le Pen-testeur et le Pen-testé

Encore des rôles barbares mais essentiels, comme il en existe tant dans l’IT .

Le Pentesteur cherche à tester la sécurité des applications développées, il se met à la place de celui qui vous veut du mal :), il cherche à vérifier que seules les personnes autorisées peuvent accéder aux informations et fonctionnalités auxquelles le product owner lui a donné droit .

Et le pentesté ? Me direz-vous ? …  

Il espère que le Pentesteur ne trouvera pas de failles dans sa réalisation 🙂

Le  Pentesteur pourra

  • Avoir rapidement une vision des scénarii de tests
  • Avoir une réponse normalisée à ses attaques

Le Pentesté pourra

  • Produire rapidement les scenarii de tests 
  • Anticiper les tests de son bourreau 
  • Les outils Low code étant basés sur les rôles et les données des applications, les scénarii de tests sont plus faciles à produire et les trous de sécurité moins fréquents.

L’utilisateur final de l’application

Parce que l’on oublie trop souvent que c’est pour lui que nous travaillons toutes et tous.

Il pourra :

  • Se retrouver dans un univers visuel épuré et normalisé 

L’utilisation des derniers standards « front » ou  technologies utilisées pour obtenir un visuel performant et adapté pour l’utilisateur, comme le « react » par exemple

  • Exploiter la puissance d’interfaces épurées

J’admets que tous ces principes correspondent finalement à la vision idéale d’un produit digital parfait.

Toutefois, je voulais attirer votre attention sur un point.

Toutes les composantes du Low Code tendent à accélérer et garantir à ses utilisateurs d’atteindre leurs objectifs .

Pour ma part, j’utilise chez Euler Hermès une solution Low code, MENDIX et j’en ai testé quelques unes ces derniers mois, et toutes ne cochent pas toutes les cases.

Cela fera l’objet d’un autre article. Restez connectés…

Alors, j’appelle les lecteurs qui utilisent le low code ou une forme de développement spécifique,  à réagir et donner leur avis  dans les commentaires, et nous dire, par exemple, si leur solution cochent ces cases.

A vos claviers ! Merci de votre contribution!

A bientôt…

#CaBougeDanslIT