Depuis plusieurs années, de nombreux débats agitent les échanges entre clients ServiceNow et leurs intégrateurs. Je dois même avouer que ce débat agite aussi les échanges entre intégrateurs (notamment dans les réponses à appel d’offre) ou même au sein des équipes d’un intégrateur.

Je pense que cet article ne changera pas grand chose aux débats, mais je voulais partager ma vision sur le sujet.

No Code / Low Code = 0 développements ?

Si on doit revenir à la racine du No Code / Low Code, il faut se souvenir que l’objectif est de simplifier la vie de l’utilisateur. Au travers de fonctionnalités et d’écrans visuels, on permet à l’utilisateur d’atteindre son besoin sans qu’il n’ait la nécessité de créer du code.

Néanmoins, cette capacité à faciliter la vie du « développeur », conduit à générer énormément de code pour la plateforme. Pour donner quelques éléments (dont vous pouvez trouver de nombreux sources sur internet au travers de l’ADEME ou encore de GreenIT).

L’abstraction : une « surcouche » de code permanente

Pour permettre un utilisateur d’utiliser un simple drag-and-drop pour déplacer un champ, sans avoir à écrire une seule ligne de code, il faut que la plateforme ait anticipé cet auto-codage de façon intégrée. Cette fonctionnalité oh combien pratique nécessite qu’un code générique, appuyé par un moteur d’exécution générique, tourne, anticipant toutes les solutions possibles.

• Le concept d’abstraction consiste à rappeler que les plateformes se comportent comme des traductrices. Derrière l’automatisation, il y a une énorme complexité : la plateforme doit interpréter chaque action en temps réel via un moteur générique, là où un code spécifique serait allé droit au but.
• Le Code Mort : lorsqu’un développeur écrit un script, il vise la fonctionnalité attendue. À l’inverse, une plateforme No-Code active souvent un écosystème complet de fonctions natives, dont beaucoup restent ‘en sommeil’ mais mobilisent des ressources pour rester disponibles.

Optimisation, vous avez dit optimisation ?

L’accès au code de ces plateformes nous étant fermé, on peut néanmoins être d’accord sur leur volonté de Standardisation. Pour répondre à des besoins très divers d’entreprises très différentes, les plateformes embarquent nativement une richesse fonctionnelle qui dépasse largement les besoins et usages réels, ce qui créé un décalage entre la simplicité du clic et la densité du code exécuté.

Pour faire simple, le No Code / Low Code une industrialisation du code, permettant de faciliter la vie des utilisateurs dans le développement mais sans pour autant le supprimer.

Et dans ServiceNow ?

De nombreux outils existent pour faciliter la vie des administrateurs et développeurs ServiceNow. La conséquence est que la majeure partie des besoins spécifiques peuvent être répondus au travers de l’utilisation d’outils visuels ou d’assistants parmi lesquels on pourra retrouver par exemple le Flow Designer ou encore le Table Builder.

Dans la définition ServiceNow, tout cela correspond donc à de la configuration, même si cela peut générer d’un point de vue plateforme énormément de code.

L’exemple de l’ajout d’un champ est intéressant. Un simple clic droit sur un formulaire permet de l’ajouter. L’automatisation nous fait perdre de vue que chaque ‘clic’ instancie une structure complète qui pèse sur la base de données.

• Une colonne dans la base de données,
• Des règles de dictionnaire,
• Des paramètres d’affichage,
• Des droits d’accès (ACL),
• Des index de recherche.

Mais est-ce réellement le sujet ?

Pourquoi parler de tout cela ?

Parce que le sujet qui doit guider la maintenabilité n’est pas forcément le critère de « Développement » ou de « Configuration » mais bien la maintenabilité et l’évolutivité.

Pour prendre un exemple concret, en travaillant sur la partie Source-to-Pay, nous avons détecté qu’un champ financier indispensable en France, n’était pas présent sur la partie Procurement. La question de l’ajouter s’est donc légitimement posée.

De mon côté, je le considérai comme un développement sous le prisme « métier ». A savoir, nous ajoutions une fonctionnalité à ServiceNow qui n’était pas prévue (je ne parle pas du champ mais de son usage). Pourquoi le considérer comme un développement ? Non pas pour l’impact de maintenabilité technique (les montées de version se seraient bien passées) mais parce que ce champ sera très certainement ajouté dans une prochaine version car indispensable au marché français et donc aurait un impact sur la maintenabilité fonctionnelle.

Et les questions à ce poser pour moi sont bien celle-là :

• S’agit-il d’une nouvelle fonctionnalité ou non,
• Est-elle en contradiction avec la philosophie de la plateforme ou non,
• Est-il envisageable qu’elle soit dans une prochaine version ou non ?

Conclusion

le No-Code est une industrialisation du développement. Si cette approche garantit la stabilité des mises à jour, elle masque une dette écologique invisible liée à la multiplication de processus automatisés qui, parce qu’ils sont faciles à créer, finissent par saturer inutilement nos infrastructures.

La vraie question n’est plus de savoir si l’on clique ou si l’on code, mais si la fonctionnalité créée est réellement nécessaire. La sobriété numérique commence par la gouvernance : ne pas configurer ce qui n’apporte pas une valeur critique.