Les plateformes « low-code » et « no-code » manquent souvent de profondeur et de flexibilité
Ces plateformes gagnent du terrain parce qu’elles promettent des résultats rapides avec moins de ressources. C’est une bonne chose jusqu’à ce que vous construisiez quelque chose qui a besoin d’être étendu, d’évoluer ou de faire quelque chose d’avancé. La plupart de ces outils vous offrent des modèles et des composants préfabriqués. Vous glissez, déposez et expédiez. C’est simple. Mais le problème, c’est que vous êtes également enfermé dans le cadre de la vision de quelqu’un d’autre, et non de la vôtre. C’est très bien si vos besoins sont basiques. Mais si vous construisez quelque chose que vos clients attendent comme étant rapide, intuitif et personnalisé, c’est là que ces outils s’effondrent.
Clayton Davis, qui dirige le développement cloud-native chez Caylent, le dit simplement. Ces plateformes sont parfaites pour les applications simples. Mais si vous visez quelque chose qui offre une une expérience utilisateur de haute qualitéde haute qualité, en particulier pour les clients, vous allez vous heurter à des murs. Vous ne pouvez pas modifier grand-chose sous le capot. C’est un problème lorsque vous essayez de vous approprier la différenciation de votre produit.
Les ingénieurs sont souvent limités par cette structure. Arsalan Zafar, directeur technique de Deep Render, recommande d’intégrer des API ou d’utiliser des plates-formes extensibles à code bas comme solution de contournement. L’objectif est de comprendre leurs limites et de planifier. Si votre application a besoin d’une logique profonde, d’une personnalisation prédictive ou si vous construisez en fonction d’une feuille de route à long terme, commencez à vous demander si votre outil peut être à la hauteur de vos ambitions.
La demande est forte dans ce domaine. Selon Grand View Research, le marché mondial des plateformes de développement à code bas devrait croître à un taux de croissance annuel moyen d’environ 23 % entre 2023 et 2030. C’est énorme. Mais la croissance ne résout pas les problèmes de conception. Le message est simple : Ne renoncez pas au contrôle si votre produit a besoin de profondeur.
La simplification excessive des outils « low-code » ou « no-code » peut conduire à des solutions inefficaces.
La vitesse est un grand avantage, jusqu’à ce qu’elle cache la complexité. Les solutions « low-code » et « no-code » vous permettent d’atteindre les MVP rapidement. Mais lorsque le produit doit être approfondi ou étendu au-delà de l’idée initiale, vous vous heurtez à un mur. Les outils ne sont pas conçus pour gérer des exigences nuancées ou des fonctionnalités sophistiquées. Ils commencent à s’effondrer lorsque vous essayez d’empiler des fonctionnalités personnalisées sur le système de base.
Soyons directs. Arsalan Zafar, de Deep Render, dit avoir été confronté à ce problème de première main. Ils ont commencé par créer une application de comparaison de codecs vidéo en utilisant une plateforme sans code. Le prototype et le déploiement ont été rapides. Il n’y a pas eu de plaintes au début. Puis les exigences réelles du marché sont apparues : mesures de comparaison personnalisées, outils alimentés par l’IA, conception multicouche. Soudain, ils passaient plus de temps à travailler autour de la plateforme qu’à créer de la valeur ajoutée.
Voici la nuance. Les équipes sous-estiment généralement le coût de la réécriture ou de la mise à niveau une fois qu’elles sont allées trop loin dans ces plateformes. Parce que la plateforme ne prend pas en charge ce dont vous avez besoin, votre équipe se retrouve coincée à faire du travail redondant, à apporter des correctifs ou à reconstruire. Ce retard peut vous faire perdre de l’élan et des opportunités de marché.
La commodité que vous gagnez au départ est compensée plus tard. Si votre stratégie produit prévoit une différenciation concurrentielle dès le premier jour, vous devez vous demander si votre architecture la supportera dans six mois. En tant que décideur, c’est une question de clarté : de quoi avez-vous vraiment besoin aujourd’hui et quel niveau de complexité devrez-vous supporter demain ? La vitesse ne doit pas se faire au détriment de la structure fondamentale.
Les plates-formes « low-code » ou « no-code » peinent à s’adapter efficacement aux applications d’entreprise
La plupart des plateformes « low-code » et « no-code sont excellentes pour une chose : la rapidité au stade initial. Si votre objectif est de valider rapidement une idée ou de produire un produit minimum viable (MVP), ces outils sont à la hauteur. Le problème apparaît lorsque vous ne validez plus et que vous devez construire pour une utilisation à grande échelle, une fiabilité à long terme et des performances au niveau de l’entreprise. C’est là que les choses se gâtent.
Kushank Aggarwal, fondateur de DigitalSamaritan, en a fait l’expérience. Son équipe a utilisé un outil sans code pour lancer Prompt Genie. De l’idée au client payant en quatre jours, c’est objectivement efficace. Mais dès que l’échelle est apparue, l’infrastructure de l’outil n’a plus tenu. L’entreprise a été confrontée à de graves problèmes tels que la perte de données, des temps d’arrêt et des flux de travail interrompus. Finalement, ils ont dû reconstruire l’ensemble du produit à partir de zéro et migrer les utilisateurs, une manœuvre délicate et coûteuse qui leur a fait perdre du temps et des ressources.
Arsalan Zafar, directeur technique de Deep Render, souligne également que la plupart de ces plateformes ne sont pas conçues pour la complexité qu’exigent les solutions à l’échelle de l’entreprise. Il y a un décalage évident entre ce pour quoi ces plateformes ont été conçues à l’origine, à savoir des applications commerciales en libre-service, et ce que de nombreuses équipes essaient aujourd’hui de leur imposer : des logiciels critiques, prêts à être utilisés par les clients. Si la plateforme sous-jacente n’est pas en mesure de le gérer, aucun contournement astucieux ne pourra y remédier.
Avant d’engager votre équipe et vos clients dans ces outils, posez une question directe : cette plateforme peut-elle soutenir l’évolution de votre modèle d’entreprise ? La croissance n’est pas toujours linéaire, et le fait d’être pris dans une reconstruction rétroactive pendant une phase de croissance peut tuer l’élan rapidement. Les dirigeants doivent pousser les équipes produits à valider l’évolutivité dès le départ, et non après le lancement.
La dépendance à l’égard des grands modèles de langage (LLM) pose des problèmes de fiabilité et de coût.
Les grands modèles de langage (LLM) alimentent plus que jamais les plates-formes à code réduit et sans code. Ils génèrent du code à partir d’invites en langage clair, rendant le développement plus accessible. Mais il y a un problème majeur : les LLM ne pensent pas comme les ingénieurs ou les chefs de produit. Ils prédisent ce qui va probablement se passer ensuite en se basant sur des modèles de données. C’est utile, mais ce n’est pas du raisonnement. Cela signifie également que les LLM produisent souvent des résultats incohérents, en particulier lorsque les exigences ne sont pas entièrement définies ou qu’elles changent fréquemment, comme c’est souvent le cas dans le développement de produits dans le monde réel.
Devansh Agarwal, ingénieur principal en apprentissage automatique chez Amazon Web Services, souligne que les LLM sont bons pour la prédiction de textes, et non pour le raisonnement de logiciels complexes. Lorsque les exigences changent, ce qui est toujours le cas, le modèle peut ne pas s’adapter correctement. Si vous avez déjà utilisé des outils comme ChatGPT pour générer du code et lui demander de corriger quelque chose, vous savez déjà qu’il crée souvent une solution entièrement nouvelle au lieu d’affiner la solution existante. Cela crée de l’instabilité dans le processus de développement. Imaginez maintenant que vous exécutez ce flux de travail à l’échelle de l’entreprise.
Il y a également un aspect financier. Itérer avec un LLM pour obtenir le bon résultat peut être coûteux en termes d’utilisation de calcul, d’ingénierie rapide et de temps de développement. Ces inefficacités incrémentales peuvent s’accumuler, en particulier lorsque les délais de développement sont serrés ou que les équipes manquent d’expertise interne pour gérer ou interroger efficacement le comportement des LLM.
Les dirigeants doivent considérer les outils alimentés par le LLM comme des accélérateurs et non comme des décideurs. Ils améliorent la productivité lorsqu’ils sont utilisés par des équipes qualifiées capables d’interpréter et d’affiner leurs résultats, mais vous ne pouvez pas attendre de ces systèmes qu’ils remplacent la réflexion sur la conception, les décisions architecturales ou l’expérience du monde réel. Les personnes doivent toujours être au centre des processus de construction critiques.
Des risques de sécurité accrus accompagnent l’adoption de plates-formes à faible codage ou sans codage.
La sécurité dans les systèmes sans code ou à code bas est souvent une réflexion après coup, mais pour les entreprises opérant dans des environnements réglementés ou à enjeux élevés, elle devrait être l’une des premières. Ces plateformes évoluent rapidement et visent à réduire les obstacles au développement, mais elles ne sont pas toutes conçues avec des cadres intégrés de gouvernance, de conformité ou de contrôle d’accès. C’est un problème lorsque vous cherchez à faire évoluer des équipes, des départements ou des utilisateurs externes.
Jon Kennedy, DSI de Quickbase, a été très clair à ce sujet. Si la plateforme ne prend pas en charge d’emblée des fonctions de sécurité robustes, vous prenez des risques inutiles, en particulier lorsque la conformité des données et l’authentification des utilisateurs sont essentielles. Les secteurs hautement réglementés tels que la santé, la finance ou l’administration exigent des autorisations spécifiques, des journaux d’audit et des protocoles de cryptage des données. Bon nombre des outils sans code les plus populaires ne sont pas dotés de ces capacités.
Devansh Agarwal, d’AWS, met en évidence un risque encore plus grand : lorsqu’une seule vulnérabilité existe dans le code central d’une plateforme sans code, tous les produits construits sur cette plateforme héritent de cette faille. Les utilisateurs non techniques ne sont souvent pas équipés pour la reconnaître ou la corriger. Cela laisse une grande surface d’attaque ouverte, inconnue de la plupart des utilisateurs, difficile à surveiller et facile à exploiter. Au fur et à mesure que l’adoption de la plateforme s’étend, l’exposition au risque augmente également.
La solution n’est pas de rejeter purement et simplement le low-code. Il s’agit de s’assurer que le processus d’adoption de votre équipe comprend une supervision par des experts et des politiques internes strictes. Traitez tout ce qui provient de ces plateformes comme une première ébauche, et non comme un produit fini. Les entreprises ne doivent pas s’appuyer sur des fonctions de sécurité passives ou incohérentes. Vous avez besoin d’un modèle de gouvernance active qui s’appuie sur des personnes, et pas seulement sur des outils.
Le verrouillage des fournisseurs peut restreindre la flexibilité et gonfler les coûts à long terme.
L’un des principaux problèmes des plateformes « low-code » et « no-code » est qu’il s’agit souvent d’écosystèmes fermés. Vous construisez à l’aide d’outils propriétaires, vous stockez les données dans leur format et vous accédez à des fonctionnalités liées à leur infrastructure. C’est pratique au départ, mais lorsque vos besoins dépassent la plateforme ou que le fournisseur modifie ses prix, supprime des fonctionnalités ou ne parvient pas à suivre votre feuille de route, le changement devient un processus à fortes frictions.
Kushank Aggarwal, fondateur de DigitalSamaritan, décrit clairement ce scénario : changer de fournisseur signifie souvent tout reconstruire à partir de zéro. Ces plateformes ne s’adaptent pas bien d’un écosystème à l’autre et il y a peu de portabilité au niveau de la conception, des intégrations ou des configurations dorsales. Plus vous vous enfoncez, plus il est difficile d’en sortir sans perturbation opérationnelle ou financière.
Siri Varma Vegiraju, responsable technique de la sécurité chez Microsoft, confirme ce point de vue. Lorsque votre produit est intégré dans un outil propriétaire sans code, la migration implique l’apprentissage d’un tout nouveau système, la reconfiguration de l’infrastructure et la reproduction manuelle des flux de travail. Avec un code traditionnel, vous pouvez échanger des composants ou des dépendances. Dans les environnements sans code, la fidélité à la plateforme est intégrée.
Ne vous contentez pas d’évaluer les plateformes en fonction de leurs caractéristiques. Évaluez leurs voies de sortie. Que se passe-t-il si ce fournisseur supprime une fonctionnalité essentielle ou modifie son modèle de tarification ? Que se passe-t-il si le temps de fonctionnement diminue ou si vos normes de sécurité évoluent ? Si ces questions n’ont pas de réponses claires aujourd’hui, elles deviendront des problèmes urgents plus tard.
La sous-estimation de la puissance des outils « low-code » ou « no-code » peut nuire à leur utilisation efficace.
Les plateformes « low-code » et « no-code » sont souvent rejetées en raison de leur positionnement, à savoir des outils pour les non-développeurs ou des raccourcis pour la création d’applications de base. Cette perception limite leur utilisation et la valeur qu’elles peuvent générer. Ces plateformes évoluent rapidement, avec des capacités qui permettent de gérer des flux de travail de plus en plus complexes, de s’intégrer aux systèmes d’entreprise et de prendre en charge l’automatisation à grande échelle. Mais si une organisation ne les considère que comme des utilitaires légers, c’est tout ce qu’elle en retirera.
Alan Jacobson, directeur des données et de l’analyse chez Alteryx, estime que l’obstacle réside dans les préjugés. Parce que ces plateformes sont accessibles aux utilisateurs non techniques, de nombreux responsables technologiques supposent qu’elles ne sont pas adaptées au travail stratégique. Cet état d’esprit freine l’adoption et empêche les organisations d’explorer l’ensemble des cas d’utilisation. En conséquence, des outils puissants restent sous-utilisés, souvent à côté d’équipes qui pourraient être plus performantes avec une approche et une formation appropriées.
La solution réside dans l’intégration technique soutenue par une formation pratique. Si les équipes comprennent comment utiliser correctement ces outils, en exploitant les API, en intégrant les systèmes de données et en gérant la logique au bon niveau, elles peuvent stimuler l’innovation avec moins de frais généraux. C’est le fossé que de nombreuses entreprises n’ont pas encore comblé : comprendre le potentiel de l’outil et investir suffisamment de temps pour l’exploiter.
Pour les dirigeants, il s’agit d’une question d’effet de levier. L’avantage n’est pas seulement la rentabilité, c’est aussi la réactivité. Les équipes dotées de la bonne plateforme et d’un état d’esprit ouvert peuvent se mobiliser plus rapidement, expérimenter davantage et faire évoluer les produits sans subir de lourds retards d’ingénierie. Mais vous ne pouvez pas libérer un potentiel auquel vous ne croyez pas ou que vous ne comprenez pas. Pour cela, il faut d’abord que les dirigeants voient plus loin que l’étiquette.
Dernières réflexions
Les plateformes « low-code » et « no-code » ne sont pas le problème. C’est leur mauvaise application qui l’est. Ces outils peuvent accélérer les délais et réduire les coûts immédiats, mais uniquement lorsqu’ils sont utilisés dans le bon contexte, avec les bonnes attentes. Si vous les considérez comme des remplaçants à part entière du développement traditionnel, vous risquez de construire quelque chose de rapide qui échouera sous la pression.
Pour les chefs d’entreprise, cela se résume à la clarté de l’objectif. Si vous avez besoin de tester un concept, d’automatiser un flux de travail ou de permettre à des équipes non techniques de se déplacer sans goulots d’étranglement techniques, la valeur est évidente. Mais lorsqu’il s’agit d’une infrastructure de base, de produits en contact avec la clientèle ou d’opérations sensibles aux données, les raccourcis ont des conséquences réelles.
Équilibrer la vitesse et l’architecture. Adaptez l’échelle du problème à la capacité de l’outil. Assurez-vous que des personnes qualifiées sont dans la boucle, en particulier lorsque les plates-formes génèrent du code automatiquement. Le coût d’une reconstruction ultérieure est presque toujours plus élevé que celui d’une construction correcte dès la première fois.
Utilisez ces outils lorsqu’ils vous rendent agiles. Prenez du recul lorsqu’ils vous fragilisent. C’est ainsi que vous avancerez rapidement sans briser ce qui est important.
