« Ça ne tiendra pas la charge. » C'est l'objection numéro un quand j'explique qu'un produit exploité a été construit sans équipe de développement. Elle est presque toujours fausse, et surtout elle détourne l'attention des quatre murs contre lesquels on finit réellement par buter. Je préfère nommer les vrais, parce que ce sont eux qui déterminent quand il faut changer d'approche — et ce moment arrive plus tard que ce qu'on te raconte.
Les objections qu'on entend, et ce qu'elles valent
« Ça ne monte pas en charge. » Pour l'immense majorité des produits, la charge n'est jamais le facteur limitant. Un service B2B avec quelques centaines d'utilisateurs actifs, un outil interne, une place de marché de niche : les plateformes actuelles absorbent ça sans discussion. Le problème de charge, quand il arrive, arrive après que dix autres problèmes se soient posés.
« On ne possède rien. » Selon les plateformes, tu récupères le code, tu héberges où tu veux, tu branches ta propre base. La question de la dépendance est légitime, mais elle se pose en termes de coût de sortie, pas de possession. Vérifie le coût de sortie avant de commencer, pas après.
« Ce n'est pas sécurisé. » Généralisation vide. Les failles que je vois sur ce type de produit sont des failles de conception — un contrôle d'accès mal posé, une donnée exposée dans une réponse qui ne devrait pas la contenir. Ce sont exactement les mêmes failles que sur du code écrit à la main par une équipe pressée. La différence n'est pas l'outil, c'est que personne n'a relu.
« Ce n'est pas maintenable. » Celle-ci est à moitié vraie, et je la traite plus bas — mais pas pour la raison qu'on avance d'habitude.
Les quatre vraies limites
1. La donnée à grande échelle
C'est le premier mur réel, et il n'a rien à voir avec le nombre d'utilisateurs. Il apparaît quand le volume ou la complexité des données dépasse ce que les requêtes générées savent traiter proprement : agrégations sur des historiques longs, jointures multiples, calculs qui doivent tourner en tâche de fond, besoins d'indexation fine.
Le symptôme est reconnaissable : ce n'est pas le site qui ralentit, c'est un écran particulier — le tableau de bord, l'export, la recherche filtrée. Tant que tu manipules des enregistrements par milliers, tout va bien. Par millions avec des calculs dessus, tu es sorti du périmètre confortable.
2. Les intégrations avec l'existant
Se connecter à une API moderne et documentée est un non-problème. Se connecter à un ERP installé en 2009, à un logiciel métier sans interface, à un système qui n'échange que par fichiers déposés sur un serveur à trois heures du matin : là, la difficulté n'est pas dans l'outil de build, elle est dans le travail d'intégration lui-même. Et ce travail-là demande des compétences qu'aucune assistance ne remplace.
En PME, c'est la limite que je rencontre le plus souvent. Le produit est simple, le contexte technique ne l'est pas.
3. Les exigences de conformité et de traçabilité
Dès qu'un secteur impose de prouver qui a vu quoi, quand, et de conserver une trace inaltérable — santé, finance, certains marchés publics —, la charge de preuve devient structurante. Il faut des journaux d'audit, des politiques de rétention, une gestion des droits documentée, parfois des exigences d'hébergement.
Rien de tout ça n'est impossible à construire de cette façon, mais l'effort n'est plus dans le produit : il est dans la documentation et les garanties autour. À ce stade, l'arbitrage se fait avec un juriste et un responsable sécurité, pas avec un choix d'outil. Je ne fais pas de droit et ce n'est pas un avis juridique — c'est une observation de terrain sur l'endroit où le coût bascule.
4. La reprise par une équipe technique
Voilà la vraie question de maintenabilité. Le code généré tourne. Le problème apparaît le jour où plusieurs personnes doivent travailler dessus en parallèle : un développeur arrive, ouvre le projet, et doit comprendre une base qui n'a pas été structurée par une intention humaine continue. Il n'y a pas de conventions partagées, pas d'historique de décisions, souvent pas de tests.
Le coût de reprise est réel et il se paie une seule fois, mais il se paie. C'est le point à anticiper si tu sais que le produit finira dans les mains d'une équipe.
Quand migrer, et comment le décider
Je ne migre pas parce que le produit grandit. Je migre quand au moins deux de ces signaux sont là en même temps :
- Un besoin de performance sur les données que je ne sais plus traiter en restant dans l'outil.
- Une intégration critique avec un système existant qui refuse de coopérer.
- Une contrainte de conformité qui exige des garanties que je ne peux pas produire.
- Plus d'une personne qui doit modifier le produit de façon régulière.
Un seul de ces signaux se contourne presque toujours : on sort la partie lourde ailleurs — un service de calcul dédié, une base séparée, un connecteur écrit à la main — et on garde le reste. C'est souvent la meilleure décision, et elle est bien moins coûteuse qu'une réécriture.
La question utile n'est pas « est-ce que le no-code tiendra ? » mais « quelle partie précise ne tiendra pas, et à partir de quel seuil ? ».
Ce que je te conseille de faire maintenant
Écris les deux ou trois seuils au-delà desquels tu changeras d'approche — un volume, un délai d'affichage, un nombre de personnes qui interviennent. Note-les quelque part. Tant qu'ils ne sont pas atteints, le débat sur les limites est théorique, et il te fait perdre du temps que tu devrais passer à sortir le produit.