> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2026/w16-nocode-rapid-iteration-and-new-engineering-constraints.md).

# W16-NoCode, itérations rapides et nouvelles contraintes d'ingénierie

La semaine dernière, les RH ont lancé une opération de vlogs pour les dix ans des services financiers. Luo Huayu, un stagiaire de notre équipe, a réalisé tout le projet avec nocode. J'ai examiné le code et fait quelques découvertes intéressantes.

Premièrement, un gain de productivité de plusieurs fois, voire de plusieurs dizaines de fois, sur ce type de projet ne m'étonnerait pas. Ce qui m'a surpris, c'est que le projet ait produit 268 versions au total. Nous savons que l'IA continuera d'accélérer la livraison logicielle et que les projets en production évolueront probablement plusieurs fois plus vite qu'aujourd'hui. Mais que se passe-t-il quand la vitesse augmente ? Ce projet en donne un bon exemple.

Il y a quelques années, pour une opération de tirage au sort comparable, on mobilisait généralement un développeur frontend et un développeur backend pendant un peu plus de deux semaines. Après une bonne semaine de travail intense, ils livraient un MVP. Le client formulait ses remarques, les développeurs reprenaient le projet, puis le lui montraient deux jours plus tard. Souvent, il n'était toujours pas satisfait et une nouvelle itération suivait. À la fin, faute de temps, il disait souvent : « On va s'en tenir là. » Il n'avait réellement vu que trois ou quatre versions. La réserve d'itérations s'épuisait vite.

Nocode raccourcit fortement la distance entre le besoin et sa réalisation. Le client reçoit plus vite des retours et trouve donc plus vite de nouvelles idées. Sur les mêmes deux semaines, le projet a parcouru plus de 200 versions. Des itérations auparavant impossibles deviennent réalisables. C'est un point essentiel : une productivité supérieure ne réduit pas nécessairement beaucoup le temps ni les ressources. Le résultat peut plutôt suivre le paradoxe de Jevons. Quand la réalisation devient plus facile, les idées et les itérations se multiplient ; la demande peut tendre vers l'infini. Le volume de travail ne disparaît pas forcément. On libère surtout des itérations qui n'auraient pas pu avoir lieu.

Deuxièmement, ce code m'a fortement donné l'impression qu'un humain l'aurait rarement écrit spontanément ainsi. Ce service Web complet n'a pas de serveur indépendant : le frontend accède directement à la base de données, avec seize procédures stockées. C'est une architecture typique Frontend-only + BaaS. Le frontend utilise React + Vite pour une SPA. Aucun service backend distinct : toutes les opérations sur les données passent par supabase-js dans le navigateur, qui appelle directement le Supabase déployé en privé chez Meituan, sur une base PostgreSQL.

La logique métier se partage en deux. Les validations simples et les limites de fréquence sont gérées dans worksApi.js côté frontend. La logique centrale liée à la sécurité concurrente et à la cohérence des données, comme les votes, les mentions « J'aime » et les suppressions, est encapsulée dans des fonctions stockées PostgreSQL appelées par supabase.rpc(). Le contrôle des droits repose principalement sur les politiques RLS de la base. Cette solution permet de développer vite et évite la maintenance d'un serveur séparé, mais ses problèmes sont évidents. La logique métier est dispersée entre JavaScript côté frontend et PL/pgSQL dans la base. La maintenabilité est moyenne, et certaines informations sensibles, comme la liste des administrateurs, doivent être codées en dur dans le client.

L'intérêt du projet dépasse donc la création plus rapide d'une page événementielle avec nocode. Il montre concrètement une nouvelle normalité de la livraison logicielle à l'ère de l'IA. Les versions se multiplient, les retours arrivent plus vite et l'architecture tend à suivre le chemin de réalisation le plus court. Pour les équipes, les possibilités de gains de productivité sont réelles, mais de nouvelles contraintes d'ingénierie apparaissent. Ce qui deviendra rare ne sera peut-être plus de produire une première fonctionnalité, mais de préserver les frontières architecturales, la maintenabilité et la capacité d'évolution à long terme au milieu d'itérations extrêmement rapides.