Le no-code est mort : vive l’IA !
Le no-code est mort : vive l’IA !
Le no-code devait nous éviter d’apprendre à coder. Il nous a surtout appris à assembler ses blocs. Un éditeur, ses règles, ses limites : pour créer son outil, il fallait d’abord apprendre à penser comme la plateforme. L’IA rend ce détour facultatif. Une TPE peut désormais décrire son besoin, tester un prototype récupérable, puis le confier à un développeur augmenté par l’IA pour en faire un produit fiable. Voilà ce qui meurt : le no-code comme passage obligé. Pas le travail de conception ni le développement.
Voix de synthèse en français. Sous-titres français disponibles.
Voix de synthèse en français. Sous-titres français disponibles.
Dirigeants de TPE : créer l’outil qui manque, sans devenir spécialistes d’un éditeur
Prenons une petite entreprise de maintenance. Les demandes arrivent par courriel, le planning vit dans un tableur et les comptes rendus se dispersent. Son besoin n’est pas de maîtriser un constructeur d’applications. C’est de savoir quelles interventions restent à attribuer, qui intervient et si le client a reçu son compte rendu.
Elle peut désormais commencer par une demande précise : « Crée un suivi des interventions avec un client, une adresse, un technicien, un statut et une pièce jointe. Le responsable attribue les missions ; chaque technicien ne voit que les siennes. » Ce scénario est illustratif, pas un résultat client. Mais le bénéfice visé est concret : moins de ressaisies, moins de recherches dans les messages et une information commune pour l’équipe.
Dans un éditeur visuel, il faudrait traduire cette demande en composants, données et workflows. Avec une interface de création par IA, on peut obtenir une première version, la regarder et préciser : « Il manque la date de passage » ou « Le compte rendu doit être validé avant envoi ». La conversation raccourcit la distance entre le métier et une proposition utilisable. Elle ne décide pas à la place du dirigeant de ce qui doit réellement se passer.
Pourquoi consacrer les premières semaines à maîtriser un éditeur si l’on peut commencer par montrer ce qui manque ? Le dirigeant n’a pas besoin de devenir développeur : il doit pouvoir essayer le parcours, expliquer ce qui ne va pas et décider ce qui compte. Le prototype sert à cela. Il rend le besoin testable ; il ne rend pas automatiquement le logiciel exploitable. La suite se prépare dès ce premier essai : qui pourra récupérer le projet, le faire tourner et le transformer ?
Google AI Studio, Lovable, Claude Code : trois rôles, pas trois noms interchangeables
Le mode Build de Google AI Studio permet de créer une application à partir d’une consigne, puis d’itérer avec un aperçu et de récupérer le code. Il sert ici à matérialiser rapidement une idée et à explorer son fonctionnement. Il s’agit bien de Google AI Studio Build, pas de Google Apps Script, qui répond à d’autres usages d’automatisation.
Lovable propose un environnement de création d’applications par conversation. Sa documentation GitHub décrit la synchronisation du code du projet avec un dépôt. Cette continuité compte : une application née dans une conversation peut entrer dans un travail de développement versionné. Synchroniser un dépôt ne prouve toutefois pas, à lui seul, que quelqu’un saura reprendre l’application.
Claude Code est un outil de développement agentique : il travaille sur le code, modifie des fichiers et peut exécuter des commandes. Ce n’est pas un éditeur visuel. Son intérêt pour une équipe produit est de contribuer à l’implémentation, aux corrections et aux tests dans un projet réel. Notre article sur ce qu’une TPE peut confier à Claude Code détaille cette délégation et les décisions à garder.
Le bon choix découle donc du travail à faire, pas d’un concours de marques. Et si le besoin se limite à transférer des données entre des outils existants, une nouvelle application n’est pas forcément nécessaire : le choix entre Google Apps Script et Make pour automatiser une PME pose une question plus pertinente. Décrire le résultat aide aussi à éviter de construire ce dont on n’a pas besoin.
Du code exportable à un prototype vraiment récupérable
Récupérer les fichiers est nécessaire, pas suffisant. Un dépôt peut contenir du code difficile à démarrer, des données mal structurées ou des dépendances propres à la plateforme. Code exportable ne veut pas dire produit réutilisable en l’état. La bonne question est : qu’est-ce qu’un développeur peut reprendre, vérifier et faire évoluer sans repartir à l’aveugle ?
Avant de passer le relais, réunissez un dossier court, avec des données fictives ou anonymisées :
- Les sources et les accès au code : dépôt versionné ou export complet, propriétaire identifié, droits accordés au développeur et procédure pour lancer le projet.
- Le modèle de données : clients, interventions, utilisateurs, relations entre ces éléments et règles d’accès attendues.
- Les dépendances et l’environnement : services externes, versions, hébergement envisagé, noms des variables de configuration et contraintes connues.
- Les scénarios d’usage : ce qu’un responsable et un technicien doivent pouvoir faire, avec un résultat attendu pour chaque parcours important.
- Les bugs observés et les prochaines priorités : étapes pour reproduire un problème, fonctionnalités testées, zones non vérifiées et prochain module utile.
Pas de mots de passe, de clés API ni de données clients dans ce dossier ou dans le dépôt. Les accès nécessaires se transmettent séparément par un canal sécurisé, avec les droits minimaux. Ce dossier ne certifie pas la qualité du prototype : il permet à l’équipe de l’évaluer et d’estimer honnêtement ce qu’elle peut conserver. Parfois, le meilleur acquis sera un module testé ; parfois, ce seront surtout les parcours validés avec le dirigeant, et le code devra être largement restructuré.
Le vrai contre-argument : le visuel reste un excellent moyen de garder la main
Une responsable marketing qui ajuste ses pages sans solliciter un développeur conserve une bonne raison d’utiliser un éditeur visuel. Une équipe qui sait lire et modifier ses workflows Bubble possède également un acquis utile. L’IA ne rend pas cette autonomie caduque ; elle peut même l’élargir.
Bubble défend explicitement ce point de vue dans « Why JavaScript Is the Wrong Language for Vibe Coding ». Son cofondateur Josh Haas y soutient qu’un code généré reste difficile à maîtriser pour une personne qui ne le comprend pas, et défend une représentation visuelle plus proche des concepts métier. Il résume le problème ainsi : « You’re reading a summary of your app, not the app itself » — vous lisez un résumé de votre application, pas l’application elle-même. C’est le point de vue d’un éditeur qui vend sa plateforme, pas une conclusion indépendante. L’objection mérite néanmoins d’être prise au sérieux : pouvoir demander une modification ne suffit pas toujours à pouvoir la comprendre.
Webflow illustre une autre réponse : son AI site builder associe génération de site et poursuite du travail dans son environnement visuel. La plateforme présente cette approche comme une manière de créer une structure puis de la faire évoluer. Là encore, c’est la proposition du fournisseur. Mais elle montre que le marché ne se résume pas à choisir entre des blocs et une conversation : les deux se combinent.
Le visuel garde donc sa place lorsqu’il facilite les modifications quotidiennes et que l’équipe le maîtrise. Ce qui perd sa place, c’est le passage obligé. Pour une entreprise qui part d’un besoin neuf, apprendre toute une plateforme avant de voir son outil fonctionner n’est plus une évidence.
La nouvelle valeur : une équipe produit assistée par l’IA, pas seulement un générateur
Une agence dont la principale valeur est de maîtriser un éditeur doit revoir sa copie. Cette compétence peut rester utile ; elle ne suffit plus à justifier tout un projet. L’IA ne tue pas les équipes produit. Elle les oblige à démontrer leur valeur : transformer un prototype en un outil cohérent, module par module. Chez SAY Digital, c’est le rôle d’une équipe produit assistée par l’IA, guidée par un architecte de solutions IA. Elle peut intervenir dès le cadrage ou reprendre un prototype pour construire la suite.
Reprenons notre entreprise de maintenance. Le dirigeant a testé l’attribution des interventions et la validation des comptes rendus. Un développeur augmenté par l’IA reprend ensuite le projet : il examine le code, vérifie ce qui fonctionne et choisit ce qui mérite d’être conservé. L’architecte clarifie les responsabilités : qui attribue une intervention ? Quel outil détient la bonne adresse client ? Que signifie « terminée » ? Ces réponses orientent l’architecture, le modèle de données et les règles d’accès, pas seulement la prochaine consigne à donner à l’IA.
L’équipe travaille aussi l’UX — un technicien peut-il terminer sa mission sur téléphone ? — et l’UI : statuts lisibles, erreurs compréhensibles, actions sans ambiguïté. Elle vérifie la sécurité côté serveur, pas seulement les boutons masqués, et prépare la montée en charge selon les usages attendus. Un prototype fluide avec deux comptes ne démontre ni l’isolation des données entre clients ni le comportement du service avec des demandes simultanées.
Le développement avance alors par modules utilisables : enregistrer et attribuer une demande ; produire et valider un compte rendu ; connecter la facturation si elle sert réellement le processus. On conserve un module utile après l’avoir testé ; on restructure ou on remplace ce qui fragilise l’ensemble. Ajouter cinq écrans n’est pas une livraison si personne ne peut terminer une intervention.
Le critère d’acceptation devient observable. Une mission attribuée apparaît chez le bon technicien et pas chez un autre. Un compte rendu incomplet ne part pas au client. Une erreur de connexion laisse une action à reprendre plutôt qu’une intervention déclarée terminée à tort. L’équipe vérifie ces comportements avec des scénarios de test, y compris les exceptions du métier.
La qualité se prépare aussi pour la suite : code versionné, choix techniques documentés, sauvegardes dont la restauration est vérifiée, procédure de retour à une version précédente et conditions de maintenance explicites. Ce ne sont pas des freins ajoutés après la création. Ce sont les moyens de modifier rapidement un module sans déstabiliser les autres, et de permettre sa reprise par une équipe identifiée.
Voilà ce que l’entreprise doit acheter : non pas une quantité de code ni une démonstration séduisante, mais une progression maîtrisée vers des modules utiles, testés et maintenables. Le périmètre, les intégrations et les critères d’acceptation déterminent le travail ; aucun outil ne justifie une promesse universelle de délai ou de résultat.
Ne formez pas votre entreprise à assembler des blocs : donnez-lui les moyens de construire
Le no-code a ouvert une porte. L’IA permet de commencer par le besoin, sans apprentissage préalable de l’éditeur. Les plateformes visuelles restent un choix utile pour certains usages ; elles ne sont plus le ticket d’entrée obligatoire. Pour une TPE non technique, le premier objectif peut être plus simple : rendre son besoin visible dans un prototype que quelqu’un pourra reprendre.
La suite n’est pas « exporter, donc livrer ». C’est choisir une équipe capable de reprendre ce qui vaut la peine de l’être, de repenser le reste et de livrer un produit cohérent. Architecture, UX, UI, sécurité, montée en charge : c’est là que le développement doit prouver son utilité. Moins d’apprentissage d’outils pour le dirigeant ; plus de responsabilité produit pour ceux qui construisent.
Vous avez un processus à simplifier, une idée d’outil métier ou déjà un prototype ? Échangeons sur votre besoin d’IA et d’automatisation pour examiner ce qui peut être repris, choisir le premier module utile et définir comment le construire, le vérifier et le faire évoluer.
Pour prolonger cette lecture : notre premier éclairage sur l’IA et la fin du no-code.
