Les applications jetables #30
/** Commentaires #30 — */

Les applications jetables

La réalisation de nos idées est vraiment accélérée grâce au vibe coding, mais sans une architecture de base, on créer des applications jetables. Les SaaS choisissent le stack à ta place, parfaits pour un prototype, plus compliqué pour une prod. Énumération : DRY tes composants, pense local first, intègre la sécurité dès le départ. Les principes d'architecture ont servi à entrainer les modèles et servent encore à les bâtir.

Le problème avec les fourchettes en plastique, ce n’est pas leur existence, c’est que l’on en a besoin.

Peu importe les raisons qui exigent que les restaurants fournissent ce genre d’outils éphémères, ils font partie des services attendus et il faut les gérer.

Ne t’inquiète pas, , je ne pars pas sur une envolée environnementale.

J’utilise cet objet pour transposer l’existence de tous les petits mirages et miracles que les LLM créent et qui en découle une nouvelle sorte d’application.

Les Applications jetables; à usage unique.

Combien d’applications fais-tu par mois maintenant?

Je parle pour tous ces prototypes, ces idées de croisement de données ou littéralement à emprunter l’expertise d’un scientifique de données le temps d’une rencontre.

Ces utilisations font partie de la raison pour quoi les LLM sont partout.

On se sauve du temps. On bâtit des équipes pluridisciplinaires.

On peut explorer très loin des hypothèses en réduisant les coûts.

Rien de nouveau non plus.

Mais on oublie la pérennité de ces outils dans nos processus.

On oublie souvent que pour construire ces outils on a toujours besoin des principes de base, de la sécurité et de l’architecture logicielle.

Les limites

Se fier à 100% à un outil comme Lovable ou Base44, c’est sous contracter l’infrastructure et l’architecture logicielle de ton application.

Les choix techniques sont en partie déjà faits, et c’est difficile de construire sans dérailler ces modèles de langage.

Comme une équipe de dev et de devops, les LLM produisent et bâtissent ton application dans un stack prédéterminé.

C’est une partie du buzz et pour quoi je suis en transformation de mon entreprise depuis deux ans. Parce que maîtriser à un niveau expert tout ce spectre technique pour une personne, c’est presque impossible.

Pour un prototype ou pour brainstormer en testant l’UX, c’est fou comment on peut créer des trucs rapidement.

La pérennité

Ce qui détermine la longévité de ton nouvel outil, c’est principalement la charpente (l’infrastructure : serveur/tech stack/bd) de ton app/saas/dashboard et l’architecture logicielle (front-end, UX, tableau de bord).

La pérennité, c’est aussi relatif à la facilité avec laquelle on peut adapter l’application, la supporter, l’améliorer et la mettre à jour.

Avec un lovable ou un base44 qui encarcane rapidement ton application dans un stack déjà établi. Tout ce choix là est déjà fait pour toi.

Encore une fois, tout dépend de l’objectif finale, est-ce que c’est pour une présentation, pour une section de ton site web ou pour démarrer un saas ?

S’il te plait ne part de pas de saas avec des données personnelles et 100% vibe codés.

Je ne dis pas qu’on doit tous acquérir des habiletés de conception logicielle, mais j’aimerais que quelques notions d’architecture logicielles fassent partie du discours maintenant. C’est important pour ton entreprise et c’est important pour le paysage des outils et la sécurité des utilisateurs.

Quelques concepts à appliquer

Pour que ta prochaine app vibe coded soit plus pérenne. Et non un chemin pavé vers l’ère des logiciels jetables.

L’atomicité de tes éléments fonctionnels

Segmente tes fonctionnalités et dis aux modèles de les réutiliser lorsque nécessaire. Demande au modèle de créer les composants avant de les propager dans les autres sections. C’est une action qui s’appelle DRY le code.

Apprends le plus possible le vocabulaire du frontend et du backend autant conceptuel que technique. Et garde le même pendant tout le processus.

Par exemple, l’acronyme CRUD, c’est un acronyme pour : create, read, update et delete. Et c’est la base pour la gestion de données via une interface.

SPA : Single page application, se dit d’une application qui gère elle-même la navigation entre les sections.

Choisis une infrastructure en mode local (local first).

Surtout pour les petites applications, personnelles et/ou à usage unique.

La force de la base de données est là, sans l’infrastructure d’un serveur à maintenir/mettre en ligne.

Grâce aux bases de données SQLite ou nosql, ta base de données vivra en local seulement dans ton navigateur. Assure-toi de créer un moyen dans ton app pour faire une sauvegarde de cette base de données.

Pense à la sécurité au même moment qu’à tes données

Les permissions d’accès par types d’utilisateurs (RBAC), avec les types d’utilisateurs les plus communs : admin, editor, viewer et public). Les permissions de bases sont reliées au CRUD + toutes la spécificité de ton application.

Garde en note ces permissions et à quel rôle elles sont associées, pour détermine l’accès de toutes tes sections sécurisées.

Pour aller plus loin

Lit sur les design patterns autant au frontend qu’au backend.

Apprends le langage pour décrire l’UX pour diriger les modèles vers l’expérience que tu veux offrir.

Construis et/ou choisis les skills appropriés pour le type d’application que tu veux faire.

Informe-toi. Sur les librairies, sur les stacks, sur l’infrastructure idéale pour l’outil que tu es en train de faire.

Parce qu’au final, on vibe code pour être plus indépendant

Pour moi, l’avantage principal, c’est de pouvoir créer des applications qui règlent des problèmes hyper précis à moindre de coût de développement.

Pour toi et pour nos clients.

De plus, les LLM permettent de combler ces besoins hyper précis qui sont souvent délaissés dans le paysage des SaaS.

Trop précis, trop peu de demandes.

Donc moindre coût + marché délaissé = beaucoup de possibilités.

Mais si on ne prend pas le temps de construire des applications avec des structures plus faciles à supporter, à bâtir autour et surtout sur lesquels les modèles ont été entrainés.

C.

Je n’invente rien, le monde du dev est dans une grosse métamorphose. Sauf que le comment et le pourquoi on développe restent les mêmes.

L’architecture logicielle n’a pas changé, encore.

On risque d’avoir à encore plus ducktaper qu’avant, j’espère juste au début.

Comme les photographes à l’arrivée des iPhone ou des travailleurs à la chaine avec l’arrivée des robots, plusieurs métiers passeront dans le tordeur.

Et beaucoup de solutions sur comment survivre tiennent dans la multidisciplinarité des habiletés.

Comme l’architecture logicielle.

Mes découvertes du mois en vrac

Aucun lien d’affilié et je filtre vraiment beaucoup ce que j’inclus à propos des LLM (ai), parce qu’il y a de la brume sur ce qui est vraiment utile.

/** Commentaires */

  • Précédent

    Bilan mamarmite 2025 et mes plans pour 2026 #29
    #29


    Bilan mamarmite 2025 et mes plans pour 2026

    retrospectiveentrepreneuriat
  • Suivant

    Le web sémantique est de retour sous forme de Pog #31
    #31


    Le web sémantique est de retour sous forme de Pog

    donnees-structureesllm
Voir tous les numéros