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

Une app full-stack est une app qui comprend toutes les couches dont elle a besoin pour fonctionner : le frontend que les gens voient et utilisent, le backend qui s'exécute sur un serveur et applique les règles, et la base de données qui se souvient de tout. Une liste de tâches qui enregistre vos tâches, vous permet de vous connecter depuis n'importe quel appareil et ne montre votre liste à personne d'autre est full-stack. Une page unique qui affiche seulement vos heures d'ouverture ne l'est pas.

« Stack » désigne simplement les couches technologiques empilées les unes sur les autres. « Full » signifie qu'elles sont toutes présentes.

Pourquoi c'est important quand on crée avec l'IA

Lorsque vous décrivez une app à un créateur par IA, les mots que vous utilisez déterminent les couches qu'il construit. « Fais une page qui affiche notre menu » produit un frontend. « Permets aux clients de commander à partir de notre menu et permets à la cuisine de voir les nouvelles commandes » nécessite les trois couches, parce que 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 des données soient enregistrées, dites-le. Un créateur qui ne fait que le frontend aura l'air terminé, mais oubliera tout au rafraîchissement.
• Vous repérez les fausses finitions. Une démo avec des données fictives peut sembler identique à une app fonctionnelle. Connaître les couches vous permet de vérifier que les données vont réellement quelque part.
• Vous comprenez les coûts d'exploitation. 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, et c'est là que se trouve la majeure partie des coûts d'hébergement.

Une analogie du quotidien : un restaurant

Pensez à un restaurant.

• La salle à manger, c'est le frontend. Les menus, les tables et le carnet du serveur. C'est ce que voient les clients, et elle doit être agréable et facile à utiliser.
• La cuisine, c'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 inhabituelles. C'est là que vivent les règles.
• La dépense et le carnet de commandes, c'est la base de données. Ils contiennent ce qui existe et ce qui a été commandé, de sorte que rien n'est oublié au changement de quart.

Un restaurant qui n'a qu'une salle à manger peut vous montrer un beau menu, mais vous ne pouvez pas manger. C'est une app frontend seulement 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 par une API — un ensemble défini de requêtes 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 communique jamais directement avec 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 être utilisé qu'une fois » — doivent donc être appliquées dans le backend. Pour en savoir plus sur cette répartition, consultez frontend et backend.

Exemple concret : une app de réservation de cours

Supposons que vous dirigiez un studio de yoga et que vous vouliez que les gens réservent des 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 coulisse :

1. Le frontend affiche l'horaire. Pour le remplir, il demande au backend : « Quels cours sont offerts cette semaine, et combien de places restent-il? »
2. Le backend demande à la base de données les cours et compte les réservations pour chacun, puis répond.
3. Le visiteur touche Réserver. Le frontend envoie « réserve le cours 42 pour cette personne connectée ».
4. Le backend vérifie : cette personne est-elle vraiment connectée? Le cours est-il complet? L'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 de données.
5. Le backend répond « réservé », et le frontend affiche une confirmation.
6. Plus tard, la propriétaire du studio se connecte et voit la liste des cours. Le backend vérifie qu'elle est administratrice avant d'afficher le nom de chacun.

Imaginez maintenant que cela ait été construit en frontend seulement. L'horaire pourrait s'afficher, et le bouton Réserver pourrait montrer une belle coche, mais la réservation disparaîtrait au rafraîchissement, le compte des « places restantes » serait faux pour les autres, et la propriétaire ne verrait jamais la réservation. L'étape 4 — les vérifications — serait complètement absente. 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 l'appelle aussi 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, par opposition à plusieurs petits programmes (par exemple un site web et une API distincte). Les deux sont full-stack.

Erreurs courantes et idées fausses

• « Ça a l'air terminé, donc c'est terminé. » Des données fictives et un bouton qui semble fonctionner ne sont pas la même chose que des données enregistrées. Rafraîchissez 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 pas, n'importe qui qui connaît 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 être dans le backend, sous forme de variables d'environnement — voir variables d'environnement et secrets.
• Croire que full-stack signifie compliqué. Une petite app full-stack peut compter quelques écrans, une poignée de routes de backend et trois tables de base de données. C'est une description des couches, pas de la taille.
• Croire que vous devez choisir vous-même chaque technologie. N'importe quelle pile raisonnable 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 d'apps par IA

Décrivez l'app en fonction des trois couches, même si vous ne les nommez pas :

• Les données : « Enregistre les cours (nom, heure, capacité) et les réservations (cours, personne, heure 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 horaire hebdomadaire, une confirmation de réservation, une page d'administration qui liste les réservations par cours. »
• Les vérifications : « Applique ces règles sur le serveur, pas seulement dans la page. Conserve toutes les clés d'API sur le serveur. »

Ensuite, testez avec un esprit sceptique : rafraîchissez, connectez-vous avec deux personnes différentes, essayez de voir des données que vous ne devriez pas voir. Le guide pour créer une app avec l'IA présente cette démarche de bout en bout.

Les apps full-stack sur Mythex

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

Questions