No-code : l'Excel des temps modernes
![No-code : l'Excel des temps modernes](/content/images/size/w1200/2023/01/RE4r1u3.webp)
N'y voyez rien de péjoratif, au contraire.
Excel nous accompagne depuis 1987 pour le meilleur et pour le pire :
-
Le meilleur : Excel permet de prototyper une idée en quelques heures. Commencer à structurer l'information et la répartir en plusieurs onglets ou fichiers (différents bounded contexts ?). Cela permet de démarrer rapidement quand on n'est pas sûr de savoir ce dont on a besoin, d'apprendre, de répondre à nos propres questionnements etc. En gros, faire un POC, voir si ça nous aide et, à la longue, si ça suffit ou s'il faut créer une vraie application.
-
Le pire : la loi de l'instrument. Si le seul outil dont vous disposez est un marteau, vous aurez tendance à ne voir que des clous… quand bien même vous avez affaire à une vis. Faire tout avec Excel parce qu'on ne connaît que ça et qu'on maîtrise l'outil sur le bout des doigts. Donc en faire trop, inexorablement : une bonne grosse dose de VBA, rapidement inmaintenable et source de nombreuses failles de sécurité. Cela devient du développement, mais du développement fait par des gens dont ça n'est pas le métier. Et à la fin, c'est le département informatique qui récupère le sac de nœuds après que le crash a eu lieu.
Les outils de no-code/low-code (Retool, Bubble, SAP Build et Airtable pour ne citer que les plus connus) présentent à mes yeux le même intérêt que ce bon vieux Excel :
-
Ils favorisent l'autonomie des équipes métier, donc l'innovation.
-
Ils déchargent l'IT des sujets à moindre valeur ajoutée : workflows de validation, tâches d'administration technique, back-offices ou même front-offices simples (disons CRUD).
-
Au final, ils permettent de répondre vite et bien à la demande, donc de gagner en agilité à l'échelle de l'entreprise.
En tant que développeur ou CTO, il est facile de ricaner et regarder cela de haut. Pourtant, nous serions bien inspirés de considérer ces outils de près.
Le tout reste de savoir encadrer la pratique : que le métier prenne les devants est une bonne chose, mais il convient d'accompagner le mouvement.
Il y a 15 ans, j'ai travaillé en stage chez un grand énergéticien français, qui est à présent en passe d'être nationalisé (on voit pas du tout de qui il s'agit). Une équipe de 3 ou 4 développeurs travaillait à proximité des traders pour faire ça proprement et éviter que ça parte dans tous les sens. Ils appelaient ça les DR (Développements Rapides) et ça marchait très bien.
Voici justement quelques suggestions :
-
Préconiser un outil, afin de mutualiser le savoir-faire et les coûts à l'échelle de l'entreprise (parce que bon, c'est pas donné non plus).
-
Faire connaître les bonnes pratiques de manière à limiter la dette technique. Même avec du no-code, on a besoin de systématisme quand l'application prend de l'ampleur.
-
Se réinterroger sans cesse sur la dépendance à la plateforme, puisque ces dernières sont libres de changer les termes du contrat du jour au lendemain, voire de cesser leur activité.
Quoi qu'il en soit, le recours au low-code/no-code prend totalement son sens dans le cadre d'une approche DDD (Domain-driven design). La question du "make or buy", qui se pose pour chaque contexte, bénéficie à présent d'un nouvel entre-deux.
Moins dichotomique, en somme.