Archives par mot-clé : Réflexion

No-Code – Low-Code – Fausse bonne idée ?

A l’heure de l’avènement du « low code » / « no-code », pourquoi il est toujours indispensable d’avoir des Analystes/programmeurs !

No-code - une page de code Json avec par dessus un symbole interdit.

Définition de « no-code »

Le concept de no code renvoie à un mode de développement logiciel qui masque la complexité du code source de l’application. Les outils de développement sans code combinent différentes techniques.

En clair, le no-code permet à des professionnels d’implémenter des processus d’automatisation, des publications, des fonctionnalités sans avoir a connaitre un langage, une technologie.

No-Code / Low-Code

La différence entre le « No Code » et le « Low Code » tient tout simplement dans le fait que le « Low Code » permet d’ajouter des composants en les programmant. Cela ajoute ainsi un ensemble de perspectives d’améliorations des éléments utilisés.

Implications techniques

Dans le concept de « No code » on va venir caché toute la couche technologique des utilisateurs. Alors certes, il va y avoir un gain de temps sur la conception des fonctionnalités « customs ». On va utiliser un ensemble de composants prédéveloppés qui vont s’enchainer les uns après les autres dans un but précis.

De par le fait que chaque composant est prédéveloppés, ils doivent de facto également être extrêmement configurable afin de pouvoir couvrir les multiples besoins fonctionnels. A défaut d’être configurable, ils doivent être d’une forte granularité : un peu comme des briques de constructions.

Dans le premier cas, il y a plusieurs phénomènes qui vont se produire :

  • Le composant va devoir embarquer un nombre non négligeable de connecteurs
  • Comme il embarque de nombreux éléments de connectivité, il va forcément avoir une empreinte de code plus importante.
  • Le composant consommera donc forcément plus de ressources.
  • Le composant consommant plus de ressources, son utilisation aura un impact plus important sur l’infrastructure qui l’accueille.
  • Cet impact va avoir un cout économique supplémentaire, environnementalement plus important.
  • Enfin l’utilisation d’un tel composant va potentiellement générer des problèmes de performance.

En bref, si un composant n’est pas conçu, étudié, optimisé pour remplir un tache très précise, il va être plus lourd, plus gourmand, plus couteux.

Engrenages et horloge

No-code, sur le long terme ?

Sur le long terme, utiliser du no-code est contre-productif. Autant les utilisateurs savent décrire quel est leur besoin, autant ils n’ont aucune notion de gouvernance, de maintenabilité, d’évolutivité et de sécurité. Tout simplement ca n’est pas leur métier !

A l’inverse, un analyste programmeur, un architecte, un développeur ou quelque soit le nom utilisé, si tant est que l’individu soit talentueux, connait, maitrise tous ses sujets. Cela transparait dans son code, dans sa façon de répondre au besoin des utilisateurs.

Un développeur va factoriser son code, va mettre en place des tests unitaires, des stratégies de gestion des erreurs, des sécurités sur ses inputs, ….

Vous allez me dire : « Oui mais les composants sont déjà testés, optimisés, … » et vous avez raison ! MAIS, parce qu’il y en a toujours un, le danger réside plutot dans l’utilisation et les interactions de chacun de ses composants et dans sa capacité à évoluer

Prenons un exemple !

Je souhaite faire un process qui va me calculer la montant de la T.V.A. sur un article. Nous allons faire l’exercice en php. Un générateur no code produira ce type de code:

public function process( $value)
{
return $value*1.2;
}

Un développeur ira plus loin, il testera si le prix du produit est correctement défini :

/**
* Function to calculate T.V.A on a product price
*/
public function calculateTVA($producPrice)
{
if($productPrice!= null && $productPrice>0 )
return $productPrice*1.2;
else
return false;
}

Un développeur qui aura réfléchi au besoin, se dira, oui mais la TVA peut avoir plusieurs valeurs ? que se passe t-il si mon prix n’est pas un nombre ? etc . Son code tiendra compte de ses interrogations :

/**
* function to calculate TVA
* input : float $productPrice, float $VATrate
* output : float  or string (Error message)
*/

public function checkInput($data, $type)
{
if(gettype($data)==$type)
return true;
else 
return false;
}

public function calculateTVA(float $productPrice, float $vatRate)
{
// Check the inputs
if(checkInput($productPrice, "double") && checkInput($vatRate,"double") && $productPrice>0 && $vatRate>0)
return $productPrice*$vatRate;
else
return "One or more parameters have an incorrect value";
}

Alors certes la quantité de code est plus importante, mais les gains en termes de compréhension, d’évolutivité et de maintenabilité sont énormes : Ce code est réutilisable, la vérification des entrées est utilisable pour d’autres modules, données, etc …

Au final ?

Le no-code est une technologie qui est va devenir très utile et va s’étendre de plus en plus dans les années à venir. Pourquoi ? parce qu’il y a un réel besoin que les utilisateurs métiers soient capables d’effectuer des taches qui jusqu’à présent étaient échues aux développeurs. Elle dispose d’avantages non négligeables.

Par contre, s’il s’agit de mettre en place un ensemble de fonctionnalités destinées à perdurer dans le temps et dans les usages, l’intervention d’un analyste-programmeur / développeur reste une nécessité absolue.

Alors, nous autres « techos », soyons rassurés, il y a, et il y aura toujours du travail pour nous !