Qu'est-ce qu'un serveur? Guide en termes simples pour les créateurs d'apps

Un serveur est un ordinateur — ou un programme qui tourne sur un ordinateur — qui attend des requêtes et y répond. Quand vous ouvrez un site web, votre navigateur (le client) envoie une requête à travers Internet, et un serveur quelque part renvoie la page, les images ou les données. Chaque app que vous utilisez, du courriel à la banque en ligne, dépend de serveurs qui font ce travail des millions de fois par jour.

Pourquoi les serveurs comptent quand on crée avec l'IA

Lorsqu'un créateur par IA vous fabrique une app, une partie du code s'exécute dans le navigateur du visiteur, et une autre partie s'exécute habituellement sur un serveur. La partie serveur fait ce à quoi le navigateur ne peut pas être confié ou ce qu'il ne peut pas faire seul :

• Enregistrer et charger des données depuis une base de données.
• Garder les secrets, comme les clés d'API des fournisseurs de paiement ou d'IA, qui ne doivent jamais atteindre le navigateur.
• Vérifier les permissions — s'assurer qu'un utilisateur ne peut voir et modifier que ses propres enregistrements.
• Communiquer avec d'autres services : débiter une carte, envoyer un courriel, appeler un modèle d'IA.

Connaître le rôle du serveur vous aide à comprendre où vivent réellement les règles de votre app, pourquoi certaines modifications exigent une republication, et ce que vous payez lorsque vous hébergez une app. Pour la répartition entre les deux moitiés, voir frontend et backend.

Une analogie du quotidien

Un serveur ressemble au personnel du comptoir d'un bureau de poste. Il ne va pas chercher les clients; il attend. Un client (le client) se présente avec une demande — « envoyer ce colis », « y a-t-il du courrier pour moi? » — et l'employé la traite et remet un résultat. Un seul employé peut servir de nombreux clients les uns après les autres, et un bureau de poste achalandé ouvre davantage de guichets.

Le bureau de poste a aussi des règles que le client ne peut pas contourner : il faut présenter une pièce d'identité pour retirer un colis. C'est aussi le rôle du serveur dans une app — le navigateur peut demander n'importe quoi, mais c'est le serveur qui décide ce qu'il obtient.

Comment une requête atteint un serveur

Quand quelqu'un visite https://bookings.example.com/schedule :

1. Recherche DNS. Le navigateur demande au système de noms de domaine vers quelle adresse IP pointe bookings.example.com. Voir le fonctionnement des domaines et du DNS.
2. Connexion. Le navigateur se connecte à cette adresse, sur le port 443 pour HTTPS, et établit une connexion chiffrée. Voir qu'est-ce que HTTPS.
3. Requête. Il envoie une requête HTTP : GET /schedule.
4. Traitement. Le serveur exécute le code qui gère /schedule — par exemple en consultant les réservations du jour dans la base de données.
5. Réponse. Il renvoie un code d'état (200 OK) et le contenu — une page HTML, ou des données JSON que la page affichera.

Tout cela prend habituellement une fraction de seconde.

Les types de serveurs dont vous entendrez parler

Notez que « serveur » désigne à la fois la machine et le programme. « Le serveur a planté » peut vouloir dire l'un ou l'autre.

Exemple concret : une app de réservation pour un salon

Voici le rôle du serveur dans une petite app de réservation pour un salon :

• Un visiteur ouvre le site. Le serveur (ou un CDN qui le précède) envoie les fichiers de la page.
• La page demande au serveur GET /api/slots?date=2026-10-03. Le serveur interroge la base de données pour les créneaux libres et les renvoie en JSON.
• Le visiteur réserve à 14 h. La page envoie POST /api/bookings. Le serveur vérifie que le créneau est toujours libre — il ne fait pas confiance à la parole du navigateur sur ce point —, enregistre la réservation et renvoie 201 Created.
• Le serveur appelle un service de courriel à l'aide d'une clé secrète, conservée sur le serveur, pour envoyer une confirmation.

Si vous éteigniez le serveur, la page pourrait encore se charger depuis un CDN, mais elle ne pourrait ni afficher les créneaux ni enregistrer les réservations.

Ce dont un serveur a besoin pour bien fonctionner

• Mémoire (RAM) et processeur. Trop peu de mémoire et l'app plante sous la charge; trop peu de processeur et elle ralentit.
• Être en marche. Un serveur éteint ne peut pas répondre. Certaines plateformes mettent les apps inactives en veille et les réveillent à la visite suivante, ce qui fait économiser de l'argent mais peut rendre la première requête plus lente.
• Configuration et secrets, fournis sous forme de variables d'environnement.
• Journaux — le registre du serveur de ce qui s'est passé, qui est le premier endroit où regarder quand quelque chose ne fonctionne plus.
• Mises à jour et correctifs de sécurité, que l'hébergement géré prend en charge pour vous.

Idées fausses courantes

• « Le nuage signifie qu'il n'y a pas de serveurs. » Le nuage correspond aux serveurs d'autres entreprises, loués à l'heure ou selon l'utilisation.
• « Un serveur est un gros ordinateur spécial. » N'importe quel ordinateur peut jouer le rôle de serveur. Votre ordinateur portable en exécute un quand vous ouvrez localhost pendant le développement.
• « Si le bouton est caché, les utilisateurs ne peuvent pas le faire. » N'importe qui peut envoyer des requêtes directement à votre serveur. Les vérifications de permissions doivent se faire sur le serveur, et non seulement dans la page.
• « Plus de serveurs règle les lenteurs. » Souvent, la vraie cause est une requête de base de données lente ou une API externe. Trouvez d'abord le goulot d'étranglement.
• « Je dois gérer un serveur pour avoir une app. » Les plateformes gérées font fonctionner les serveurs pour vous; vous déployez le code, et elles s'occupent des machines.

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

• « Quelles parties de cette app s'exécutent sur le serveur, et lesquelles dans le navigateur? »
• « Conserve toutes les clés d'API sur le serveur et lis-les depuis des variables d'environnement. »
• « Vérifie les permissions sur le serveur pour chaque requête qui lit ou modifie des données. »
• « Où trouve-t-on les journaux du serveur, et que disent-ils au sujet de cette erreur? »
• « Cette app a-t-elle vraiment besoin d'un serveur, ou peut-elle être un site statique? »
• « Que se passe-t-il pour la première requête après une période d'inactivité de l'app? »

Les serveurs dans Mythex

Dans Mythex, vous ne configurez ni ne gérez de serveurs. Pendant que vous créez, votre app fonctionne dans un bac à sable infonuagique privé pour l'aperçu en direct. Lorsque vous publiez, Mythex la déploie — les interfaces statiques comme des sites statiques, et les backends (Node, Python, C#, Java et d'autres) comme des conteneurs construits à partir d'un Dockerfile — sans hébergement à configurer vous-même. Mythex choisit la taille de la machine au moment du déploiement : par défaut 1 processeur et 512 Mo de mémoire, avec davantage offert sur demande (jusqu'à 1 Go dans le forfait Gratuit, et jusqu'à 2 processeurs, 4 Go et 3 machines dans le forfait Pro). Les apps publiées se mettent en veille lorsqu'elles sont inactives et se réveillent à la visite suivante; une app en veille ne génère aucun coût de calcul. Les détails se trouvent dans la documentation sur les backends d'API et les limites d'hébergement, et notre guide sur l'hébergement web présente le portrait général.

Questions