Face à la prolifération de solutions no-code certains de mes clients pensent pouvoir se passer d’un développeur. Oui, mais non.
Dans le retour d’expérience d’aujourd’hui nous allons parler des assets Unity, et particulièrement de la promesse de no code faites par certains. J’en profite pour remercier mon client, W., qui m’a autorisé à parler de ce projet et ainsi faire écho à l’article de la semaine dernière : https://urlr.me/YycFT9
Mais pour commencer, qu’est-ce que le « no code » ? Le no-code est une approche du design et de la production d’application qui ne requiert aucune compétence de code à proprement parler. L’exemple le plus à la mode s’en rapprochant serait le « vibe codding », abordé ici https://urlr.me/9Zzpa3 , où la démarche de décrire son projet à une IA pour la laisser se charger du code.
Cette promesse n’est pas nouvelle, mon premier souvenir étant les logiciels de création de site internet wysiwyg (What You See Is What You Get) des années 200, et elle touche à peu près tous les domaines de l’informatique. Unity n’est donc pas une exception.
L’asset store spécialisé d’Unity (https://assetstore.unity.com/?aid=1011l4ZLaY) permet de mettre en vente et d’acheter une multitude d’asset, sortes de modules préconstruits par d’autres développeurs et prêts à intégrer à nos divers projets. Les plus connus et plus utilisés sont les assets 3D ; concrètement un modélisateur 3D choisit de vendre certains de ces modèles pour permettre aux développeurs n’ayant pas ce genre de compétences de les inclure à leurs jeux. Un autre type serait les modules couvrant là de véritables concepts de programmation : un module de sauvegarde de données, de déplacement de caméra, de boutons et d’interfaces graphiques… Et ceux qui vont nous intéresser aujourd’hui, les modules « no code ».
W. et moi sommes rentrés en contact sur une plateforme de mise en relation de freelance. Il cherchait un freelance pour la mise en place d’un projet s’articulant autour de l’asset « Game Creator 2 » de « Catsoft Work ». De son point de vue, tout l’intérêt de l’utilisation de ce module est de simplifier le plus possible la partie programmation de son projet le rendant, en théorie, plus facilement maintenable et modifiable par lui. La promesse de ces modules est là : soit aller plus vite pour faire la même chose qu’en programmant, soit carrément se passer des développeurs. Et c’est à peu près là que les ennuis commencent.
Car, un peu comme l’IA, ces outils ne font pas de miracles et limitent les possibilités des éventuels développeurs intervenant sur des projets les utilisant. Un peu comme un pochoir qui ne fait qu’un seul dessin mais le fait bien, ces assets sont programmés pour remplir une tâche spécifique. Certains ne la remplissent même pas bien et nous n’en parlerons pas plus ; mais d’autres y arrivent parfaitement. Cela dit, la difficulté vient du fait que même si un pochoir peut très bien faire un dessin de 4x4 il est presque impossible de le détourner pour qu’il se mette à faire à la fois un 4X4 et une voiture de sport.
Dans un premier temps, la première complexité est, paradoxalement, du côté du développeur. Il faut en effet prendre en main l’asset pour faire des choses que nous aurions peut-être faites de manière radicalement différente ; et en comprendre la logique interne.
Et ce n’est que le début d’un vrai travail d'équilibriste, car il est très rare qu’un asset corresponde exactement à la volonté d’un client : il y a toujours des comportements à ajuster, des fonctionnalités non prévues, des modifications à aborder. Il faut alors :
- Prendre en compte les spécificités de l’asset, et ses possibilités ;
- Comprendre en profondeur la vision du client pour discerner ce qui est à mettre en place de ce qui n’est pas nécessaire ;
- Communiquer sur les possibilités de l’asset, et de la complexification du programme en mettant en place des fonctionnalités.
En effet, l’ajout de certaines fonctionnalités non prévues par l’asset force soit à détourner le comportement de certains modules de ces derniers, soit implique une complexité phénoménale dans du code supplémentaire afin de passer par des voies détournées pour réaliser quelque chose bloqué ou empêché pas l’asset et/ou un de ces modules.
Cela peut également poser des problèmes sur du plus ou moins long terme : que se passe-t-il lorsque le développement de l’asset ou sa maintenance s’arrête ? Quand une nouvelle version d’Unity sort, et que la compatibilité n’est pas assurée ?
Avant de choisir la route du « no code », posez-vous toutes ces questions, les avantages sont flagrants, mais quid des inconvénients ? Avec W. il m’aura fallu quelques jours pour prendre en main l’asset, suivi de quelques jours de développement et le projet fut achevé et réussi. Cette architecture centrée sur l’asset lui permet de faire évoluer le projet à son rythme en autonomie.
Si vous voulez discuter de l’intérêt de choisir cette voie du « no code », vous savez où me trouver !