L'IA a tué le no-code. Parce qu'elle est devenue le no-code.

L'IA a-t-elle tué le no-code ?

Toute technologie est un passif.

Une ligne de code coûte de l'argent. Une licence no-code aussi. Des jetons d'IA aussi. Rien de tout ça ne crée de la valeur en soi : c'est une dépense qu'on accepte parce qu'on parie sur ce que le système va rapporter ensuite, en opérations réglées et en données enfin structurées.

Aucune boîte n'est valorisée parce qu'elle a de la tech. Elle est valorisée parce que son métier tourne. Plus il y a de technologie, plus il y a de dette à porter, et la seule chose qui justifie cette dette, c'est le retour qu'elle produit sur le métier.

Ça change la question de départ. Ce n'est pas « quelle techno est la meilleure ». C'est « qu'est-ce que j'accepte de payer, et contre quoi ».

La seule question qui vaut : à quel horizon ?

Si on commence à construire aujourd'hui, trois questions décident. Elles n'ont rien à voir avec le langage, et elles auraient dû piloter le choix depuis toujours.

Il y en a une quatrième, qu'on oublie systématiquement : où est la limite de ce que je peux construire là-dedans ? Elle existe dans tous les cas, code compris. Le sujet, c'est de savoir si vous allez la rencontrer.

Deux courbes, et elles ne vont pas dans le même sens.

Ce qui sépare vraiment les familles, ce n'est pas ce qu'elles permettent. C'est la forme de la courbe.

Le code a toujours coûté cher à l'entrée. Monter la bonne infrastructure, poser les conventions, écrire les premières lignes : c'est lent et c'est cher. Mais une bonne base de code accélère ensuite, parce que ce qui est déjà écrit se réutilise.

Le déterminant compte, et il n'est pas décoratif : bonne. Pour exactement le même prix, on a vu des équipes coder comme des cochons et laisser derrière elles un existant qui ne tenait pas. La courbe qui monte n'est jamais garantie par le simple fait de coder.

Le no-code partait à l'inverse. Les briques étaient déjà faites, on ne réinventait rien, on montait en deux semaines un écosystème qui tenait la route. Et plus on empilait, moins on allait vite. Dépendances entre outils, licences, ponts, changements de modèle chez les éditeurs, versions d'API qui bougent sous vous.

Une nuance à garder en tête : un ingénieur est censé construire de la même manière des deux côtés. Back, front, logique d'architecture, c'est la même réflexion. Ce qui change, c'est ce qu'on peut faire une fois la réflexion faite.

On sait de quoi on parle, on a vendu les deux.

En 2023, on a construit le système de HSLS, une marque de dépannage qui travaille avec des indépendants sur le terrain. Airtable, Make, Glide, ClickSend, MailChimp, Teamleader comme CRM. Que du no-code.

Avant, 67 % du chiffre d'affaires partait dans les opérations, dont 37 % en administratif. 10 % des factures restaient impayées chaque mois. Le premier prototype fonctionnel a demandé deux semaines, pour 7 500 euros.

Six mois après la mise en route : plus de 80 % des interventions automatisées, le taux d'erreur passé de 20 % à 1 %, environ 15 000 euros par mois qui cessent de partir, 50 000 euros récupérés sur 450 000 de chiffre d'affaires, 50 heures par mois rendues au dirigeant, et la facturation devenue instantanée au lieu de quinze jours.

Ces chiffres sont ceux annoncés en octobre 2023, sur le périmètre d'alors. Ils décrivent un système no-code, pas ce qu'on construit aujourd'hui.

Le no-code, c'était la bonne façon de faire quand on le faisait. Et le même soir, sur la même scène, on nommait déjà le mur.

Trop d'outils, trop de licences, trop de ponts. C'était dans les questions du public, à une conférence consacrée au no-code, organisée par dualoop et PandaPanda, dite par quelqu'un qui en vivait. La captation est publique.

Trois ans avant cet article. Le diagnostic n'a pas bougé d'un mot, ce sont les outils qui ont changé. Et le même soir, on posait deux critères pour dire si un outil est vraiment du no-code : la programmation est visuelle, et l'outil laisse sortir les données par une API ouverte. Le second, c'est la réversibilité. Il n'a pas pris une ride.

Ce que l'IA a changé : les briques, sans les dépendances.

Le seul vrai avantage du no-code, ça n'a jamais été l'absence de code. C'était les briques déjà faites, donc la vitesse d'accès à quelque chose qui marche.

L'IA produit ces briques à la demande. Dans le langage qu'on veut, sans dépendance à un éditeur, sur ses propres dépôts et ses propres serveurs. On récupère la vitesse du no-code, et on garde ce que le code donne : du vrai sur mesure, et un système qu'on peut maintenir.

C'est ça, la bascule, et c'est pour ça que la question « code ou no-code » est devenue sans objet. L'IA n'a pas battu le no-code sur son terrain. Elle a pris sa place.

Conséquence directe pour une boîte de vingt personnes : ce qui demandait des grosses roadmaps et des équipes pluridisciplinaires devient atteignable. Pas gratuit, atteignable. La nuance tient dans la section suivante.

Mal posée, l'IA fait pire que le no-code.

Il y a une condition, et elle est entière : la structure posée en amont, puis tenue dans le temps. L'infrastructure, les conventions, la vision produit et métier.

Mal posée, l'IA donne le pire des deux mondes : le plafond du no-code avec les coûts de maintenance du code. Vous payez les deux factures et vous n'avez ni l'un ni l'autre des avantages.

Bien posée, elle fait mieux que le meilleur dépôt de code de l'époque, justement parce qu'elle s'appuie dessus. L'écriture du code devient une commodité, à condition que les conventions soient bonnes.

C'est pour ça qu'on n'encadre nos sprints qu'avec des ingénieurs de gestion et des architectes seniors. Ce n'est pas une précaution de confort, c'est ce qui décide de quel côté du plafond vous tombez. La méthode, posée noir sur blanc →

Le garde-fou a disparu.

Avant, les dérives venaient de profils non techniques qui s'improvisaient techniques en no-code et en low-code. Ça produisait des montages immaintenables, qui défiaient les règles les plus simples de la conception logicielle.

Aujourd'hui ce sont les mêmes, en beaucoup plus nombreux, avec l'IA. Et beaucoup plus durs à repérer pour une boîte non technique, parce qu'en surface tout a l'air de fonctionner.

La nuance qui compte, et elle est rarement dite : Airtable reposait au moins sur une base SQL structurée, maintenue par une société qui avait levé des centaines de millions. Il y avait des rambardes autour des cow-boys. Aujourd'hui, le seul garde-fou c'est l'IA elle-même, et sans conventions, l'IA amplifie le brouillon au lieu de le corriger.

Un exemple chez nous, sur un projet interne. L'IA a poussé une implémentation en fonctions serverless, parce que c'était le chemin le plus court dans le périmètre qu'elle connaissait. Ça a très bien marché jusqu'au jour où un traitement a dépassé la limite de temps de la plateforme, et tout a cassé d'un coup. Personne n'avait rien vu venir : en surface, ça fonctionnait.

Le troc vitesse contre durée n'existe plus.

Le no-code s'adressait à un profil de boîte précis, et le choix était rationnel. Une société qui ne pouvait pas se poser la question de savoir où elle serait dans trois ans, parce qu'elle ne savait pas si elle existerait. Investir long terme n'avait aucun sens. On troquait l'évolutivité contre le retour immédiat, et on avait raison de le faire.

Ce troc n'existe plus. On peut aujourd'hui construire pour la durée avec un retour rapide. C'est ce qui sort le no-code du spectre des solutions pour les boîtes qu'on accompagne, et ce n'était pas vrai il y a dix-huit mois.

Reste que si le raccourci a déjà été pris, la sortie se paie. Une migration qu'on accompagne en ce moment, pour sortir un client de son montage : 92 500 euros hors taxes, 616 heures, trois phases étalées jusqu'en 2027.

Sortir d'un montage, ça se compte en mois, pas en week-ends. La seule règle qui tienne quand on s'y engage : structurer la première phase pour qu'elle soit livrable et utile même si les deux suivantes ne se font jamais.

Là où notre camp perd aussi.

Voici la grille qu'on utilise en cadrage. Elle est volontairement agnostique à la techno : elle s'applique de la même façon à un logiciel fermé du marché, à un empilement d'outils ouverts, et à du sur mesure en code.

Ce que la grille donne quand on la passe famille par famille. Aucune ne gagne partout, la nôtre comprise.

Notre point faible est nommé, et c'est le septième critère. Qui maintient si celui qui a construit disparaît ? Une grille ne répond pas à ça. Un contrat d'entretien, du code qui vous appartient et une documentation lisible par n'importe quelle équipe, oui.

Et une conséquence qu'on assume, parce qu'elle nous coûte du chiffre : sur les briques réglementées, comptabilité et stock notamment, un éditeur est parfaitement légitime et nous n'avons aucun intérêt à recoder ce qu'il fait mieux. Le comparatif complet, avec les cas où il ne faut pas nous choisir →

Notre stack, et pourquoi c'est arbitraire.

On code en React et en TypeScript, avec des bases SQL sur des serveurs européens, et on est assistés par plusieurs IA selon le niveau d'exigence du client.

C'est un choix, pas une religion. On est à l'aise avec, ça fonctionne très bien, et personne ne pourra jamais dire que c'est mauvais. Symétriquement, on ne crachera jamais sur une équipe qui part sur Angular ou qui construit en Python avec Django. Ce sont des langages différents, rien de plus.

Ce qui compte, c'est que la machine traduise ce langage en programmes que de vraies équipes utilisent tous les jours pour faire tourner une boîte. Si un prestataire vous vend sa stack comme un argument, demandez-lui plutôt ce qu'elle règle chez vous.

Ce qui reste ouvert.

Une question qu'on ne sait pas trancher. On préfère l'écrire que faire semblant.

Si les chaînes de développement assistées par IA se banalisent, et que chaque agence, chaque indépendant et chaque client final y accède au même coût, qu'est-ce qui résiste ?

Les deux réponses qu'on se donne aujourd'hui : transformer une intention métier en système qui tourne reste rare, et la connaissance accumulée du contexte d'un client ne se copie pas au rythme où la production technique se banalise. Les deux reposent sur une rareté de profil, pas sur une barrière technique. Et une rareté de profil se comble en cinq ans.

On repose la question dans six mois. Cet article portera sa date de révision.

Ce que ça veut dire pour vous.

Cinq questions, dans cet ordre. Elles ne parlent d'aucune technologie, c'est fait exprès.

• Est-ce que votre outil règle encore un problème, ou est-ce qu'il en crée ?
• Est-ce que vous construisez plus vite qu'il y a un an, ou moins vite ? C'est la question qui départage tout le reste.
• Si votre prestataire s'arrête demain, vous récupérez quoi, et en combien de jours ?
• Combien de licences payez-vous pour faire tenir l'ensemble, et combien de ponts entre outils peuvent casser sans prévenir ?
• Est-ce que quelqu'un chez vous sait dire pourquoi le système est construit comme ça ?

Si la réponse à la deuxième est « moins vite », vous n'avez pas un problème d'outil. Vous avez un problème de structure, et il ne se règle pas en changeant de plateforme. Changer de plateforme sans changer la structure, c'est racheter le même problème plus cher.

Et si votre boîte tourne avec moins d'une vingtaine de personnes sur un besoin bien délimité, un bon indépendant reste probablement votre meilleure option. On a écrit le guide pour le choisir, sans nous →

Ce qu'on nous demande sur le sujet.