No-code et IA : pourquoi le code va désormais plus vite

J'ai passé dix ans à livrer des produits en no-code, d'abord avec une agence, autour de Bubble, FlutterFlow et Make. Aujourd'hui je code tout avec l'IA et je ne démarre plus un seul projet en no-code. Les outils no-code ne se sont pourtant pas dégradés, ils sont meilleurs qu'il y a trois ans. C'est leur promesse principale qui a bougé. Ils servaient à aller plus vite, et je vais souvent plus vite en code depuis que l'IA écrit une partie du travail à ma place.

Cette vitesse se paie, et pas en euros. Elle se paie en maintenance, en sécurité et en mise en production, c'est-à-dire dans tout ce que Bubble portait à ma place et qui est revenu sur mon dos du jour au lendemain. Je raconte ici le produit qui m'a fait basculer, ce que ce basculement coûte réellement, et la grille que j'utilise maintenant pour trancher entre no-code, hybride et code assisté par IA.

Le seul argument du no-code qui a cassé

La vitesse, et elle seule. En février 2025, je répondais publiquement à une vidéo qui présentait le no-code comme un piège pour les startups. J'avais aligné cinq arguments, point par point, en m'appuyant sur des produits que j'avais vus grossir sérieusement sans une ligne de code écrite à la main. Ces cinq arguments, je ne les renie pas. Quatre d'entre eux tiennent toujours aujourd'hui, et je les défendrais encore dans la même discussion.

Mon argument numéro cinq portait sur le coût récurrent. J'écrivais qu'une application développée en code traditionnel réclame entre 150 et 500 euros de maintenance par mois, parfois 500 à 2 000 euros pour un produit un peu sérieux, et que le no-code évite cette facture. J'ajoutais qu'en code, vous devenez souvent otage de votre prestataire, alors qu'un client sur Bubble ajoute son champ tout seul et change une règle sans appeler personne. Cette autonomie était mon argument central, et en juin 2025 je livrais encore la grande majorité de mes projets clients en no-code.

Ce qui a bougé entre-temps ne vient pas des plateformes no-code, il vient de l'autre camp. Écrire du code est devenu beaucoup moins lent. Le rapport DORA 2025 de Google mesure, auprès de près de 5 000 professionnels de la tech, une adoption de l'IA à 90 % chez les professionnels du développement, en hausse de 14 points sur un an, avec une médiane de deux heures par jour passées à travailler avec ces outils. Deux heures quotidiennes rendues à autre chose que la saisie, c'est assez pour refermer l'écart de délai qui justifiait le no-code. Et le jour où le code va plus vite, la question devient franchement : il reste quoi au no-code ?

Tala : un an sur Bubble, puis une V2 en code

Tala, mon assistant vocal qui répond au téléphone à la place d'une entreprise, a vécu un an sur Bubble avant que j'en reprenne la V2 en code. Le choix de départ était bon, je le referais dans les mêmes conditions : un template SaaS solide, l'authentification, la facturation et les comptes déjà câblés, un vrai gain de temps au démarrage. Le produit restait simple, des comptes, des numéros de téléphone, un formulaire de configuration et un texte à trous pour régler le comportement de l'assistant.

Ce qui a coincé, ce sont les fonctionnalités que je voulais ensuite. Un éditeur de parcours visuel, où l'utilisateur dessine lui-même le déroulé de son appel. Un chat qui construit l'agent à votre place, en conversation. Sur la plateforme, je ne suis pas parvenu à les faire tenir : la liberté produit tombait à zéro et je passais mon temps à tordre le besoin pour le faire rentrer dans l'outil.

En novembre 2025, j'ai attaqué la V2 en code. Pas depuis une page blanche, il faut être exact : je suis parti d'une base open source que j'ai ensuite adaptée en profondeur. La migration des données a eu lieu les 22 et 23 décembre 2025, avec 63 parcours d'appel et 776 appels historiques repris depuis l'ancienne application. L'effort ressenti, sur ces six semaines, a été le même que pour un cycle Bubble équivalent. Le produit livré au bout, lui, était largement plus gros. Aucun des deux chantiers que la plateforme m'interdisait n'a posé de problème une fois en code.

Ce que la vitesse du code assisté me coûte vraiment

Trois postes que Bubble portait à ma place sont revenus chez moi en entier : la maintenance, la sécurité et la mise en production. C'est exactement ce que j'avançais en 2025 pour défendre le no-code, ce qui a le mérite de la cohérence. Le socle technique et ses centaines de briques sont à tenir à jour, avec les compilations, les déploiements et l'audit des dépendances. Une bibliothèque saine aujourd'hui devient une faille dans six mois, et personne ne vous prévient. Bubble patchait, hébergeait et mettait à jour sans que j'y pense une seconde. C'est le seul poste où j'ai vu ma facture de temps augmenter franchement, et c'est mon propre argument numéro cinq qui m'est revenu en pleine figure.

La sécurité est le piège le plus vicieux, et il ne vient pas de la qualité du code produit. L'IA écrit du code qui fonctionne, y compris quand il est dangereux. Veracode teste le code généré par les modèles sur des tâches réalistes : dans sa mise à jour de mars 2026, portant sur plus de 150 modèles, 45 % des réponses contiennent une faille connue alors que plus de 95 % sont syntaxiquement correctes, et le taux de réussite stagne au même niveau qu'en 2025 malgré les nouvelles générations de modèles. Sur les injections dans une page web, seules 15 % des réponses passent le test. Vous obtenez donc une démonstration parfaite, et une règle d'accès aux données qui manque parce que vous ne saviez pas qu'il fallait la demander.

C'est la différence entre un débutant et quelqu'un qui a déjà mis des produits en production : savoir quoi exiger. Permissions, séparation des données entre clients, règles d'accès à la base, hébergement agréé quand on touche à de la santé. Rien de tout ça ne se voit dans une démonstration qui tourne. En France, la CNIL a reçu 6 167 notifications de violations de données en 2025, en hausse de 9,5 % sur un an, dont la moitié liées à un piratage. Une base clients qui fuit se remarque rarement le jour même. J'ai développé ce point ailleurs, avec des exemples réels, dans mon retour sur les promesses et les limites du vibe coding en projet réel.

Reste la mise en production, le sujet dont personne ne parle dans les vidéos à une heure. Une application qui tourne sur votre écran n'est pas une application en production. Il faut des tests, de la surveillance, des sauvegardes vérifiées, des alertes qui réveillent quelqu'un. Sur Tala, il faut en plus déployer sans couper un appel en cours et surveiller la latence pendant que quelqu'un parle au téléphone. Tout ça, la plateforme me le cachait.

Pourquoi je continue malgré la facture

Je gagne trois choses que je ne rends plus. La première est la vitesse, avec une nuance que je tiens à poser. Je ne suis pas systématiquement deux fois plus rapide qu'en no-code : sur certains sujets je suis à égalité, sur d'autres l'écart est énorme. Une étude de l'organisme d'évaluation METR a même mesuré l'inverse, chez seize développeurs open source expérimentés sur 246 tâches : 19 % de temps en plus avec les outils IA, alors que ces mêmes développeurs se croyaient 20 % plus rapides. Le contexte explique l'écart : ils travaillaient sur des dépôts matures qu'ils connaissaient par cœur, là où mon gain vient d'un produit neuf dont je définis moi-même le périmètre. Les vidéos qui montrent une application construite en une heure ne mentent pas non plus, à condition d'appeler ça un prototype et pas un produit prêt à encaisser des clients.

La deuxième est le test automatisé. Sur Bubble, je vérifiais à la main, écran par écran, à chaque modification. En code, j'ai des tests unitaires, d'intégration et de bout en bout que l'IA écrit, lance et corrige quand une régression apparaît. Sur Tala, une IA appelle même une autre IA pour vérifier qu'une mise en production ne casse pas la conversation téléphonique. Ce gain-là ne se mesure pas à la livraison, il se mesure sur toute la vie du produit, et c'est celui qui m'a le plus surpris. C'est aussi ce qui sépare un usage sérieux de l'IA d'un usage cosmétique, un sujet que je détaille dans mon article sur ce que le code augmenté par l'IA change dans une équipe.

La troisième est la liberté. Je choisis mes bibliothèques, mon hébergement, ma base de données et mon architecture. Quand un client demande une brique inédite, j'ajoute un composant au lieu de contourner l'outil. L'éditeur de parcours visuel de Tala, le chat qui configure l'agent, la téléphonie en temps réel : trois chantiers que je n'aurais pas pu mener autrement. Cette liberté est la vraie contrepartie de la facture de maintenance, et c'est pour elle que j'accepte de la payer.

Les trois cas où je recommande encore le no-code

Le premier, et de loin le plus fréquent : le client maintiendra vraiment son produit lui-même. Quelqu'un qui connaît déjà Bubble, qui l'utilise au quotidien et qui n'a jamais développé, n'a aucune raison d'en partir. Le ticket d'entrée reste imbattable pour un produit simple, avec un plan Starter à 29 dollars par mois en facturation annuelle pour un usage web, 119 dollars pour le palier Growth et 349 dollars pour le palier Team, tarifs relevés sur la documentation officielle de Bubble le 31 août 2026. Une seule question à se poser avant de signer : combien de vos utilisateurs éditent réellement leur application eux-mêmes ? Chez moi la réponse honnête est « moins que je ne le pensais en 2025 », et c'est ce qui a nuancé mon argument de l'autonomie.

Le deuxième cas est encore plus simple : le produit existant tourne. On ne migre pas une application stable par effet de mode. Le coût et le risque d'une réécriture doivent se justifier par un besoin que l'outil actuel bloque, comme dans mon cas avec l'éditeur de parcours. Nos applications no-code livrées, nous continuons de les maintenir, et je déconseille activement la migration à plusieurs clients qui me la demandent. Si le sujet se pose quand même, la vraie décision se prend produit en main, pas sur une tendance.

Le troisième cas, celui qui m'intéresse le plus, est l'hybride, où le visuel et le code cohabitent dans le même projet. FlutterFlow pousse le code Flutter de votre projet vers votre propre dépôt GitHub, et WeWeb permet d'exporter les fichiers de l'application pour l'héberger sur votre propre infrastructure. n8n reste l'outil que j'utilise tous les jours : visuel, extensible avec du code, et auto-hébergeable sur votre propre infrastructure d'après sa documentation officielle. Make rend un service voisin en ligne, sans avoir à administrer de serveur. Ces outils ne sont pas un compromis mou, ils offrent souvent le meilleur rapport entre le temps investi et le résultat obtenu.

Ma grille pour trancher entre les trois familles

Qui maintiendra ce produit dans douze mois, vous ou un prestataire ? C'est la première question que je pose, avant toute autre. Viennent ensuite trois questions dans le même ordre à chaque fois. Le produit a-t-il une fonctionnalité que personne d'autre ne propose, ou reprend-il des mécaniques connues ? Existe-t-il une contrainte réglementaire forte, données de santé, agrément, exigence de localisation ? Et quel budget récurrent pouvez-vous absorber une fois le produit en ligne ? Les réponses tombent presque toujours dans une des trois cases ci-dessous.

Aucune de ces cases n'est un jugement de valeur sur les outils. Le critère décisif reste la personne qui va vivre avec le produit, pas la technologie du moment. Quand la réponse penche vers le no-code, je le dis, et j'affine avec l'arbre de décision que j'utilise pour trancher entre outils no-code quand le choix se joue à l'intérieur de cette famille. Quand elle penche vers le code, c'est du développement sur mesure, avec ce que ça implique de responsabilité derrière.

Le no-code n'est pas mort et je serais mal placé pour l'annoncer. Il est redevenu une option parmi d'autres, alors qu'il était automatiquement la plus rapide pendant plusieurs années. Ce qui a changé, c'est que le code n'est plus réservé à ceux qui écrivent chaque ligne eux-mêmes. La responsabilité, elle, n'a pas bougé de place : elle est juste passée de la plateforme à vous. Si vous démarrez, Softr, Make, n8n ou Bubble restent de très bons choix. Choisissez pour votre produit et pour la personne qui va le maintenir, pas par religion.

Questions fréquentes

Le no-code est-il devenu inutile depuis l'arrivée de l'IA ?

Non. Il a perdu son avantage automatique de vitesse, ce qui est très différent. Un produit simple, porté par quelqu'un qui maîtrise déjà sa plateforme et qui ne veut pas dépendre d'un prestataire, reste mieux servi en no-code aujourd'hui qu'en code. Ce qui a disparu, c'est le réflexe de choisir le no-code uniquement parce que ce serait forcément plus rapide.

Une application développée avec l'IA coûte-t-elle moins cher qu'en no-code ?

Moins cher à construire, souvent. Moins cher à posséder, rarement. La licence no-code inclut l'hébergement, les mises à jour de sécurité et les correctifs de la plateforme. En code, ces postes deviennent votre budget récurrent, celui-là même que j'estimais entre 150 et 500 euros par mois en 2025 pour défendre le no-code. Comptez cette ligne avant de comparer les deux devis.

Peut-on faire confiance au code écrit par une intelligence artificielle ?

Pour la logique métier, il produit un résultat de très bon niveau. Pour la sécurité, il faut relire et savoir quoi demander : dans les tests Veracode de mars 2026, 45 % des réponses générées contiennent une faille connue alors que la quasi-totalité compile sans erreur. Le risque n'est donc pas un plantage visible, mais une règle d'accès manquante que personne ne remarque avant l'incident.

Faut-il migrer une application Bubble qui tourne bien ?

Non, sauf si l'outil vous bloque sur une fonctionnalité que vos clients réclament. La migration a un coût réel, un risque de régression et une période d'instabilité. Dans mon cas, j'ai basculé parce que deux fonctionnalités structurantes étaient hors de portée de la plateforme, pas parce que le code était à la mode. Une application stable qui rend service se garde.

Combien de temps faut-il pour une première version en code assisté ?

Un prototype se monte en quelques heures, et les vidéos qui le montrent sont honnêtes sur ce point précis. Une première version que vous pouvez confier à de vrais utilisateurs demande plutôt quelques semaines, l'essentiel du délai partant dans les tests, l'hébergement, les sauvegardes et les règles d'accès. C'est cette partie que le no-code vous offrait sans le dire.