Qu'est-ce qu'une application full-stack ? Explication en termes simples

Une application full-stack est une application qui comprend toutes les couches nécessaires à son fonctionnement : le frontend que les gens voient et utilisent, le backend qui tourne sur un serveur et applique les règles, et la base de données qui retient tout. Une liste de tâches qui enregistre vos tâches, vous permet de vous connecter depuis n'importe quel appareil et n'affiche votre liste à personne d'autre est full-stack. Une page unique qui affiche seulement vos horaires d'ouverture ne l'est pas.

« Stack » signifie simplement les couches technologiques empilées les unes sur les autres. « Full » signifie qu'elles sont toutes là.

Pourquoi c'est important quand on construit avec l'IA

Quand vous décrivez une application à un créateur par IA, les mots que vous employez déterminent les couches qu'il construit. « Fais une page qui affiche notre carte » produit un frontend. « Permets aux clients de commander depuis notre carte et permets à la cuisine de voir les nouvelles commandes » demande les trois couches, car les commandes doivent être enregistrées, partagées entre deux types d'utilisateurs et gardées privées.

Connaître la différence vous aide de trois façons :

• Vous demandez la bonne chose. Si vous voulez que les données soient enregistrées, dites-le. Un outil qui ne construit que le frontend paraîtra terminé mais oubliera tout au rechargement.
• Vous repérez les fausses finitions. Une démo avec des données d'exemple peut ressembler en tout point à une application qui fonctionne. Connaître les couches vous permet de vérifier que les données vont bien quelque part.
• Vous comprenez les coûts de fonctionnement. Un frontend seul peut être servi sous forme de fichiers statiques. Un backend et une base de données sont des programmes qui tournent sur des serveurs, ce qui explique l'essentiel du coût d'hébergement.

Une analogie du quotidien : un restaurant

Pensez à un restaurant.

• La salle est le frontend. Menus, tables et calepin du serveur. C'est ce que voient les clients, et elle doit être agréable et facile à utiliser.
• La cuisine est le backend. Les clients n'y entrent jamais. Elle prend les commandes, vérifie qu'un plat est disponible, le cuisine et refuse les demandes incohérentes. Les règles se trouvent ici.
• La réserve et le carnet de commandes sont la base de données. Ils contiennent ce qui existe et ce qui a été commandé, pour que rien ne soit oublié au changement de service.

Un restaurant qui n'a qu'une salle peut vous montrer un beau menu, mais vous ne pouvez pas être nourri. C'est une application uniquement frontend qui fait semblant d'être full-stack.

Les trois couches en détail

Les couches communiquent dans un ordre fixe. Le frontend demande quelque chose au backend via une API, c'est-à-dire un ensemble de requêtes définies que le backend accepte. Le backend vérifie la requête, lit ou écrit dans la base de données, et renvoie une réponse. Le frontend ne parle jamais directement à la base de données.

Cet ordre est l'idée de sécurité la plus importante de toute la pile. Tout ce qui se trouve dans le frontend peut être lu et modifié par le visiteur, puisque cela s'exécute sur son appareil. Les règles — « seul le propriétaire peut voir cette facture », « un coupon ne peut servir qu'une fois » — doivent donc être appliquées dans le backend. Pour en savoir plus sur cette répartition, voir frontend et backend.

Un exemple concret : une application de réservation de cours

Imaginons que vous dirigez un studio de yoga et que vous voulez que les gens réservent leurs cours en ligne.

Ce que fait le visiteur : il ouvre le site, voit les cours de la semaine, en touche un, se connecte et réserve une place.

Ce qui se passe en coulisses :

1. Le frontend affiche l'emploi du temps. Pour le remplir, il demande au backend : « Quels cours ont lieu cette semaine, et combien de places restent ? »
2. Le backend interroge la base de données pour les cours et compte les réservations de chacun, puis répond.
3. Le visiteur touche Réserver. Le frontend envoie « réserver le cours 42 pour cette personne connectée ».
4. Le backend vérifie : cette personne est-elle bien connectée ? Le cours est-il complet ? A-t-elle déjà réservé ? Ce n'est que si tout est en ordre qu'il écrit une nouvelle ligne de réservation dans la base.
5. Le backend répond « réservé », et le frontend affiche une confirmation.
6. Plus tard, la responsable du studio se connecte et voit la liste des cours. Le backend vérifie qu'elle est administratrice avant d'afficher les noms de tout le monde.

Imaginez maintenant que cela ait été construit uniquement en frontend. L'emploi du temps s'afficherait peut-être, et le bouton Réserver montrerait peut-être une belle coche, mais la réservation disparaîtrait au rechargement, le compteur de places serait faux pour les autres, et la responsable ne verrait jamais rien. L'étape 4 — les vérifications — manquerait complètement. C'est la différence concrète.

Termes clés

• Frontend (côté client) : la partie qui s'exécute dans le navigateur.
• Backend (côté serveur) : la partie qui s'exécute sur un serveur. On parle aussi de serveur d'API.
• Base de données : l'endroit où les données sont stockées de façon organisée. Voir qu'est-ce qu'une base de données.
• API : la liste des requêtes que le backend accepte du frontend ou d'autres programmes.
• Authentification : vérifier qui est une personne (connexion). Autorisation : vérifier ce qu'elle a le droit de faire.
• Déploiement : mettre toutes les couches sur des serveurs pour que le public puisse les utiliser.
• Monolithe ou services : un seul programme qui fait tout, ou plusieurs petits programmes (par exemple un site web et une API séparée). Les deux sont full-stack.

Erreurs courantes et idées reçues

• « Ça a l'air terminé, donc c'est terminé. » Des données d'exemple et un bouton qui semble fonctionner ne sont pas des données enregistrées. Rechargez la page, ouvrez-la dans une fenêtre privée et vérifiez que les données sont toujours là.
• Mettre les règles dans le frontend. Cacher un bouton n'est pas de la sécurité. Si le backend ne vérifie rien, n'importe qui connaissant la requête peut la faire.
• Mettre des clés secrètes dans le frontend. Une clé de fournisseur de paiement ou d'IA dans le code du navigateur est lisible par chaque visiteur. Les clés doivent se trouver dans le backend, dans des variables d'environnement — voir variables d'environnement et secrets.
• Penser que full-stack veut dire compliqué. Une petite application full-stack peut comporter quelques écrans, quelques routes backend et trois tables de base de données. C'est une description des couches, pas de la taille.
• Penser qu'il faut choisir soi-même chaque technologie. N'importe quelle pile sérieuse et largement utilisée convient pour une première version. Ce qui compte davantage, c'est une description claire des données et des règles.

Ce qu'il faut demander à votre créateur par IA

Décrivez l'application en termes de trois couches, même si vous ne les nommez pas :

• Les données : « Enregistre les cours (nom, horaire, capacité) et les réservations (cours, personne, date de réservation) dans une base de données. »
• Les règles : « Un cours ne peut pas être réservé au-delà de sa capacité. Une personne ne peut réserver un cours qu'une fois. Seuls les administrateurs peuvent voir qui a réservé. »
• Les écrans : « Un emploi du temps hebdomadaire, une confirmation de réservation, une page d'administration listant les réservations par cours. »
• Les vérifications : « Applique ces règles côté serveur, pas seulement dans la page. Garde toutes les clés d'API côté serveur. »

Testez ensuite comme un sceptique : rechargez, connectez-vous avec deux personnes différentes, essayez de voir des données que vous ne devriez pas voir. Le guide pour construire une application avec l'IA détaille cette boucle de bout en bout.

Applications full-stack sur Mythex

Mythex construit des applications web full-stack à partir d'une description dans le chat. Par défaut, une nouvelle application reçoit un frontend React et TypeScript ; lorsque l'application doit enregistrer des données, Mythex ajoute au projet une base Postgres dédiée, et vous pouvez demander un serveur d'API séparé (par exemple en Python, Node, C# ou Java) à côté du site web. Le tout tourne ensemble dans un aperçu en direct et se publie sur une URL publique. La page de documentation sur les applications multi-services montre comment un site web et une API sont prévisualisés et publiés ensemble, et la page créateur d'applications full-stack propose des points de départ.

Questions