Ces dernières années ont vu une adoption massive des outils de développement rapide et des plateformes « no-code » ou « low-code », permettant à de nombreux utilisateurs de créer rapidement des applications sans connaissances approfondies en programmation. Cette évolution a considérablement augmenté le nombre d'applications, mais a également soulevé des questions quant à leur qualité et leur pérennité.
Cette expansion rapide a facilité le lancement d'applications à l'apparence attrayante, mais dépourvues de fondements techniques solides. Il en résulte un marché saturé d'applications similaires, dont certaines souffrent de performances médiocres, de failles de sécurité ou d'une expérience utilisateur instable.
Dans cet article, nous expliquons comment la « bulle de la programmation superficielle » peut conduire à la prolifération d’applications de mauvaise qualité, et pourquoi cette tendance peut s’avérer dangereuse pour la qualité de l’innovation dans le futur numérique.
La programmation intuitive a conquis le monde du développement et constitue une véritable merveille moderne à suivre de près. Le problème, c'est que l'engouement qu'elle suscite risque de laisser de nombreuses applications dysfonctionnelles une fois que les développeurs se seront tournés vers la prochaine tendance. Au final, beaucoup d'entre nous se retrouveront avec des applications défaillantes sans solution en vue.
De nombreux « programmeurs Vibe » sont en réalité simplement des rédacteurs de prompts.
Ils n'ont jamais touché à une seule ligne de code.
La programmation Vibe a rendu le développement plus accessible que jamais. Il suffit d'utiliser un outil d'IA, de saisir une requête dans un champ texte, et une application apparaît. Elle peut nécessiter quelques améliorations, mais généralement, la version initiale reste fonctionnelle tant que vous programmez avec Vibe.
Le problème vient des « développeurs » qui n'ont jamais écrit une seule ligne de code. Ils utilisent la programmation Vibe simplement parce que c'est tendance ou parce qu'ils pensent pouvoir gagner de l'argent rapidement, mais ils n'ont aucune connaissance réelle du développement – ni aucune envie d'apprendre à développer correctement.
Imaginez ces programmeurs de phables comme des personnes qui, réalisant qu'elles peuvent utiliser une calculatrice et des outils en ligne pour résoudre leurs problèmes de maths, tentent de construire une fusée. Ils parviendront peut-être à faire fonctionner quelque chose tant bien que mal, mais ils n'atteindront jamais la Lune, même s'ils en sont persuadés.
N'importe qui peut programmer un prototype en utilisant la programmation Vibe.
Mais il est vraiment indispensable de savoir ce que l'on fait pour construire sur le long terme.
Pour ceux qui ne savent pas ce qu'ils font, la programmation Vibe est une solution. رائعة Pour créer un prototype. J'ai programmé Vibe pour plusieurs projets jusqu'à présent, et de tout ce que j'ai fait, j'ai réalisé une chose : la qualité de la programmation Vibe dépend entièrement de la personne qui la maîtrise. J'ai passé plus de temps à corriger mes erreurs de programmation Vibe qu'à programmer Vibe réellement. En réalité.
Chaque projet que j'ai réalisé avec le langage de programmation Vibe aurait facilement pu être « fonctionnel » en une heure ou deux, voire moins. Mais pour créer quelque chose de vraiment qualité, il m'a toujours fallu de très nombreuses heures.
Le codage Vibe est certes plus rapide que le codage traditionnel pour une équipe restreinte, mais il est loin d'être rapide si l'on vise un produit de haute qualité. Il en va de même pour les mises à jour continues.
J'ai passé la majeure partie de trois mois à construire Application Météo pour iPhoneC'est une application simple, mais elle comporte aussi de nombreux processus complexes qui se déroulent en arrière-plan.
L'application est sortie récemment sur l'App Store, ce qui est un véritable exploit. Cependant, je reçois encore quelques signalements de plantages par semaine et je travaille sans relâche à la correction des bugs et au développement de nouvelles fonctionnalités. En effet, je compte assurer le support de L'application sur le long terme, et pas seulement le week-end de son lancement, ce qui représente un travail considérable.
Les programmeurs qui pratiquent la programmation spontanée passent souvent d'une application à l'autre sans se soucier de la continuité.
L'application était finalement un projet de week-end.
Je l'ai vu maintes fois : un programmeur doué en programmation se vante d'avoir créé cette « application complexe » en 48 heures, comme si c'était un exploit. Certes, c'est impressionnant d'avoir une version fonctionnelle en deux jours, mais fonctionnait-elle correctement ? Combien de bugs contenait-elle ? Y avait-il des problèmes de concurrence provoquant des plantages aléatoires ?
Mon application météo présente un problème étrange que je suis en train de suivre. Elle plante parfois lorsque je l'ouvre depuis Spotlight sur mon iPhone. Ce n'est pas systématique, mais occasionnel.
Si le seul but d'un programmeur adepte de la programmation spontanée est de créer des applications en peu de temps afin de pouvoir se vanter de la rapidité avec laquelle il les a développées, il est peu probable qu'il prenne le temps de corriger de petits détails comme celui-ci.
Je n'utilise pas la programmation spontanée de cette manière dans mes applications, et je connais beaucoup d'autres programmeurs adeptes de la programmation spontanée qui ne le font pas non plus — mais nous avons tous commencé par de la programmation proprement dite, et pas seulement par l'écriture d'une commande.
N'importe qui peut être un programmeur émotionnel, mais tous les programmeurs émotionnels ne sont pas des développeurs.
« Quand tout le monde est un super-héros… personne ne l’est. » – Syndrome, Les Indestructibles. Cette citation pourrait sembler tout droit sortie d’un film pour enfants, mais elle résonne particulièrement fort à l’ère de la manipulation émotionnelle. Quand chacun pense pouvoir créer une application en un week-end, chacun se prend pour un développeur.
À l'inverse, tous les programmeurs passionnés ne sont pas forcément des développeurs, et c'est là le problème. Il est difficile de savoir si l'application que l'on utilise a été conçue par quelqu'un qui prévoit d'en assurer le support à long terme ; c'est pourquoi de nombreuses applications dysfonctionnelles verront le jour.
Je le vois déjà venir : les applications développées en un week-end, par simple défi, resteront tout simplement à l’abandon, sans aucune mise à jour. Même si l’application fonctionne parfaitement pendant des semaines, voire des mois, une mise à jour de l’API viendra la rendre incompatible. À ce moment-là, on verra bien qui a codé avec passion pour créer une véritable application et qui l’a fait uniquement pour la gloire sur Internet. Le plus triste, c’est que les consommateurs seront souvent les grands perdants à cause de ces applications défectueuses.
La facilité de développement d'applications n'est pas problématique en soi, mais un manque d'expertise technique peut engendrer des résultats médiocres, préjudiciables à l'utilisateur final. Dans un marché des applications aussi concurrentiel, il est devenu essentiel de trouver un juste équilibre entre rapidité et qualité.
En définitive, le véritable succès des applications reste lié à la solidité de leur structure interne et non pas seulement à la rapidité de leur lancement ou à la simplicité de leur développement.
