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

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 application que vous utilisez, de la messagerie à la banque en ligne, repose sur des serveurs qui font cela des millions de fois par jour.

Pourquoi les serveurs comptent quand on construit avec l'IA

Quand un créateur par IA vous fabrique une application, une partie du code s'exécute dans le navigateur du visiteur et une autre partie tourne généralement sur un serveur. La partie serveur fait ce que le navigateur ne peut pas faire seul, ou auquel on ne peut pas se fier :

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

Savoir ce que fait le serveur vous aide à comprendre où résident réellement les règles de votre application, pourquoi certaines modifications exigent une nouvelle publication, et ce que vous payez quand vous hébergez une application. Pour la répartition entre les deux moitiés, voir frontend et backend.

Une analogie du quotidien

Un serveur ressemble aux guichetiers d'un bureau de poste. Ils ne vont pas chercher les clients ; ils attendent. Un client (le client, côté réseau) s'approche avec une demande — « envoyer ce colis », « y a-t-il du courrier pour moi ? » — et le guichetier la traite et rend un résultat. Un seul guichetier peut servir plusieurs clients les uns après les autres, et un bureau de poste chargé 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 le rôle du serveur dans une application : le navigateur peut demander n'importe quoi, mais le serveur 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 à quelle adresse IP bookings.example.com correspond. Voir comment fonctionnent les domaines et le 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, il cherche les réservations du jour dans la base de données.
5. Réponse. Il renvoie un code de statut (200 OK) et le contenu — une page HTML, ou des données JSON que la page affiche.

Tout cela prend en général une fraction de seconde.

Les types de serveurs que vous entendrez citer

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

Un exemple concret : une application de réservation pour un salon

Voici ce que fait le serveur dans une petite application de réservation pour un salon :

• Un visiteur ouvre le site. Le serveur (ou un CDN placé devant lui) 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 trouver les créneaux libres et les renvoie au format 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 d'e-mail avec une clé secrète, stockée côté 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 (CPU). Trop peu de mémoire et l'application 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 applications 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.
• Une configuration et des secrets, fournis sous forme de variables d'environnement.
• Des journaux — l'historique de ce qui s'est passé sur le serveur, où l'on regarde en premier quand quelque chose casse.
• Des mises à jour et des correctifs de sécurité, que l'hébergement géré prend en charge à votre place.

Idées reçues courantes

• « Le cloud signifie qu'il n'y a pas de serveurs. » Le cloud, ce sont les serveurs d'autres entreprises, loués à l'heure ou à l'usage.
• « Un serveur est un gros ordinateur spécial. » N'importe quel ordinateur peut jouer le rôle de serveur. Votre portable en fait tourner un lorsque vous ouvrez localhost pendant le développement.
• « Si le bouton est caché, les utilisateurs ne peuvent pas agir. » N'importe qui peut envoyer des requêtes directement à votre serveur. Les vérifications de droits doivent se faire sur le serveur, pas seulement dans la page.
• « Plus de serveurs résout la lenteur. » 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.
• « Il faut gérer un serveur pour avoir une application. » Les plateformes gérées font tourner les serveurs à votre place ; vous déployez le code, elles s'occupent des machines.

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

• « Quelles parties de cette application tournent sur le serveur, et lesquelles dans le navigateur ? »
• « Garde toutes les clés API côté serveur et lis-les depuis des variables d'environnement. »
• « Vérifie les droits côté serveur pour chaque requête qui lit ou modifie des données. »
• « Où se trouvent les journaux du serveur, et que disent-ils de cette erreur ? »
• « Cette application 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'application ? »

Les serveurs dans Mythex

Dans Mythex, vous n'installez ni ne gérez de serveurs. Pendant la construction, votre application tourne dans un bac à sable cloud privé pour l'aperçu en direct. Quand 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 déploiement : par défaut 1 CPU et 512 Mo de mémoire, avec davantage sur demande (jusqu'à 1 Go sur Free, et jusqu'à 2 CPU, 4 Go et 3 machines sur Pro). Les applications publiées se mettent en veille lorsqu'elles sont inactives et se réveillent à la visite suivante ; une application en veille ne consomme aucun calcul. Les détails figurent dans la documentation sur les backends d'API et sur les limites d'hébergement, et notre guide sur l'hébergement web couvre l'ensemble du sujet.

Questions