1 Comment

Hyper intéressante, votre analyse ! Pour moi, c'est la petite astuce au début de la newsletter ("Et si vous supprimiez vos vieux projets tests ?") qui est la plus révélatrice du vrai impact du no-code : le no-code, c'est aussi tester plein d'outils, lancer des projets, dupliquer à volonté des apps pour faire des sauvegardes, créer des projets pour tester ou pour le fun... Là où un dév sauvegarde juste les différentes versions de son code, un.e no-codeur/no-codeuse utilisera souvent le seul outil à sa disposition : la duplication. Ce qui fait qu'on n'en est plus seulement à stocker une ancienne version de son code, mais tout un environnement (et sa puissance dédiée côté serveur) pour que l'app soit fonctionnelle côté développeur et côté utilisateur... Tout ça pour rien pour certaines apps n'ayant qu'une vocation de backup ou de bac à sable. Ce sera en particulier le cas sur Bubble, Airtable... Donc même si les outils développés en no-code étaient plus efficients que les outils codés (et j'ai de gros doutes dessus - mais ça dépendra avant tout de la manière dont l'outil codé a été développé), le fait que le no-code incite à démultiplier les outils et les projets (ou du moins ne contraint pas sur leur multiplication) fait que son impact sera globalement plus lourd. En bref :

- Le modèle majoritairement freemium et/ou illimité n'incite pas les utilisateurs à considérer la "pertinence"

- Le fait que l'essentiel des choix techniques soient faits sous le capot, et que la majorité des utilisateurs soit peu technique, donne sensiblement moins de prise à la "frugalité" sur le plan technique (il y a surtout les dév Bubble expérimentés qui s'en soucient, et quelques utilisateurs de grosses bases sur Airtable)

Sur le sujet, j'avais aussi beaucoup aimé cet article : https://www.latitudes.cc/pour-une-tech-plus-sobre

Expand full comment