L'architecture d'une application web organise ses briques (interface, serveur, base de données, services externes) et leurs échanges. Fonctionnement d'une requête, composants, monolithe, microservices, serverless, modèles de rendu et critères pour choisir.
L’architecture d’une application web, c’est l’organisation de ses grandes briques (interface dans le navigateur, serveur applicatif, base de données, services externes) et la façon dont elles communiquent. Les trois grands modèles sont le monolithe (une seule application), les microservices (plusieurs petits services indépendants) et le serverless (des fonctions exécutées par un hébergeur cloud). Pour la plupart des projets de PME, un monolithe bien structuré est le bon point de départ ; on découpe plus tard, quand la charge ou l’organisation l’exigent.
On explique comment fonctionne une application web de la requête à la réponse, quels sont ses composants, les différents types d’architecture et de rendu, comment choisir, et les bonnes pratiques qui évitent de tout reconstruire au bout de deux ans. Pas besoin d’être développeur pour suivre : l’objectif est que vous puissiez discuter des choix techniques avec votre équipe ou votre prestataire.
- Qu’est-ce que l’architecture d’une application web ?
- Comment fonctionne une application web, de la requête à la réponse ?
- Quels sont les composants d’une architecture web ?
- Architecture ou conception logicielle : quelle différence ?
- Quels sont les principaux types d’architecture ?
- Quelle place pour les API dans l’architecture ?
- SPA, rendu serveur ou site statique : quel modèle de rendu ?
- Comment choisir l’architecture de votre projet ?
- Quelles sont les bonnes pratiques ?
- Quelles erreurs éviter ?
- Questions fréquentes
- Sources
Qu’est-ce que l’architecture d’une application web ?
Une application web est un programme qu’on utilise dans un navigateur, sans installation : un espace client, un outil de réservation, un logiciel de gestion interne, une plateforme de commande. Elle repose sur le modèle client-serveur : le navigateur (le client) envoie des requêtes, le serveur les traite et renvoie une réponse.
L’architecture, c’est le plan d’ensemble de ce système : quelles briques existent, où elles tournent, qui parle à qui et comment. Comme pour un bâtiment, elle se décide avant la construction et se modifie difficilement ensuite. Elle conditionne directement les performances, la capacité à encaisser la charge, la tolérance aux pannes, la sécurité et le coût de maintenance.
Les avantages d’une application web par rapport à un logiciel installé expliquent son succès en entreprise : une seule version à mettre à jour (sur le serveur), un accès depuis n’importe quel appareil doté d’un navigateur, des données centralisées au même endroit. Pour le détail d’un projet, de l’idée à la mise en ligne, voyez notre article sur comment créer une application web.
Comment fonctionne une application web, de la requête à la réponse ?
Le parcours d’une requête dynamique, tel que le décrit la documentation MDN de Mozilla, se déroule en quelques étapes :
- L’utilisateur saisit une adresse ou clique sur un bouton ; le navigateur envoie une requête HTTP (GET pour lire, POST pour envoyer des données, etc.).
- Le serveur web la reçoit. S’il s’agit d’un fichier statique (image, CSS, JavaScript), il le renvoie directement.
- Sinon, il transmet la requête à l’application, qui identifie ce qui est demandé et interroge la base de données.
- L’application construit la réponse : une page HTML générée à partir d’un gabarit, ou des données (souvent en JSON) que le navigateur mettra en forme.
- Le serveur renvoie la réponse avec un code d’état (200 si tout va bien, 404 si la ressource n’existe pas, etc.).
- Le navigateur affiche le résultat et télécharge les fichiers complémentaires (feuilles de style, scripts, images).
Point important pour la sécurité : tout le code qui s’exécute dans le navigateur (HTML, CSS, JavaScript) est visible et modifiable par l’utilisateur. Les contrôles qui comptent (droits d’accès, calcul d’un prix, validation d’un formulaire) doivent donc toujours être refaits côté serveur.
Quels sont les composants d’une architecture web ?
| Composant | Rôle | Exemples de technologies |
|---|---|---|
| Interface (front-end) | Ce que voit et manipule l’utilisateur dans son navigateur | HTML, CSS, JavaScript, React, Vue, Angular |
| Serveur web | Reçoit les requêtes, sert les fichiers statiques, transmet le reste à l’application | Nginx, Apache |
| Application (back-end) | Logique métier, règles, droits, génération des réponses | PHP (Laravel, Symfony), Python (Django), Node.js, Ruby on Rails |
| Base de données | Stocke et restitue les données | PostgreSQL, MySQL, MongoDB |
| Cache et CDN | Évitent de recalculer ou de retransférer ce qui ne change pas | Redis, cache HTTP, réseau de diffusion de contenu |
| Tâches en arrière-plan | Traitements longs sortis du parcours de l’utilisateur (e-mails, exports) | Files de messages, workers |
| Services externes | Fonctions confiées à des tiers via API | Paiement, envoi d’e-mails, cartographie, CRM |
| Supervision | Journaux, métriques et alertes pour savoir ce qui se passe en production | Outils de monitoring et de logs |
Toutes ces briques ne sont pas nécessaires dès le départ. Une application simple tient très bien avec une interface, un back-end et une base de données. Les autres s’ajoutent quand un besoin réel apparaît : lenteur, volume, traitements longs. Pour la couche cache, notre article sur le cache d’un site internet détaille les options.
Architecture ou conception logicielle : quelle différence ?
Les deux termes sont souvent confondus. L’architecture définit le squelette : les grands composants, leurs responsabilités et leurs échanges. Faut-il un seul serveur applicatif ou plusieurs services ? Des fonctions serverless ? Une base unique ou une base par domaine ? Ces choix sont coûteux à changer.
La conception (design logiciel) se situe au niveau du code : ce que fait chaque module, l’organisation des classes et des fonctions, l’usage de modèles de conception (design patterns) éprouvés qui évitent de réinventer la roue et donnent à l’équipe un vocabulaire commun. Une bonne conception rend le code lisible et testable ; une bonne architecture rend le système capable d’évoluer.
Quels sont les principaux types d’architecture ?
Le monolithe
Toute l’application (interface serveur, logique métier, accès aux données) forme un seul programme, déployé d’un bloc. C’est simple à développer, tester et héberger, et c’est le cas de la grande majorité des sites et applications métier. La variante moderne est le monolithe modulaire : un seul déploiement, mais un code découpé en modules bien séparés, qu’on pourra extraire plus tard si nécessaire. Plus de détails dans notre article sur l’architecture monolithique.
Les microservices
Dans l’article de référence publié en mars 2014, James Lewis et Martin Fowler décrivent le style microservices comme une façon de construire une application sous forme d’un ensemble de petits services, chacun tournant dans son propre processus et communiquant par des mécanismes légers, souvent une API HTTP. Chaque service correspond à une capacité métier (catalogue, paiement, facturation), se déploie indépendamment et gère ses propres données.
Avantages : équipes autonomes, montée en charge ciblée, pannes isolées. Contreparties : réseau, supervision, cohérence des données et déploiements deviennent nettement plus complexes. C’est une architecture pensée pour de grandes équipes et de gros volumes, voir notre article sur l’architecture de microservices.
Le serverless
« Sans serveur » ne veut pas dire qu’il n’y a pas de serveur, mais que vous ne les gérez plus : l’hébergeur cloud exécute votre code à la demande. On combine en général des fonctions déclenchées par des événements (FaaS, functions as a service) et des services gérés prêts à l’emploi (BaaS, backend as a service) pour l’authentification, le stockage ou la base de données. La facturation suit l’usage réel, ce qui convient aux charges irrégulières ; en contrepartie, on dépend davantage du fournisseur.
| Critère | Monolithe | Microservices | Serverless |
|---|---|---|---|
| Mise en route | Rapide | Lente | Rapide pour des fonctions isolées |
| Complexité d’exploitation | Faible | Élevée | Faible côté serveurs, plus élevée côté supervision |
| Montée en charge | Globale (on duplique tout) | Service par service | Automatique |
| Taille d’équipe adaptée | Petite à moyenne | Plusieurs équipes | Petite à moyenne |
| Dépendance au fournisseur | Faible | Faible à moyenne | Forte |
Quelle place pour les API dans l’architecture ?
Quel que soit le modèle retenu, les API (interfaces de programmation) sont devenues la colonne vertébrale des applications web. Une API expose les fonctions et les données du back-end sous une forme standard, le plus souvent en HTTP avec des réponses en JSON. La même API peut alors servir plusieurs clients : l’interface web, une application mobile, un partenaire, un outil interne.
Concevoir l’API avant les écrans (on parle d’approche « API first ») présente trois avantages concrets :
- l’interface et le back-end peuvent être développés en parallèle, chacun s’appuyant sur un contrat clair ;
- l’ajout d’un nouveau canal (application mobile, borne, intégration chez un client) ne demande pas de réécrire la logique métier ;
- les échanges avec vos outils existants (ERP, CRM, comptabilité, e-mailing) passent par le même mécanisme, documenté et sécurisé.
La contrepartie : une API publique ou partenaire doit être versionnée, documentée, protégée (authentification, limitation du nombre d’appels) et surveillée. Une modification non annoncée peut casser toutes les applications qui en dépendent. C’est un investissement qui se justifie dès que l’application a plus d’un client ou qu’elle doit dialoguer avec d’autres logiciels.
SPA, rendu serveur ou site statique : quel modèle de rendu ?
Indépendamment du découpage du back-end, il faut choisir où les pages sont construites :
- Rendu côté serveur (SSR) : le serveur envoie une page HTML complète. C’est le modèle historique (PHP, WordPress, Django) et celui des frameworks modernes comme Next.js ou Nuxt.
- Application monopage (SPA) : selon la définition de MDN, l’application charge un seul document, puis met à jour son contenu en JavaScript. L’expérience est fluide, mais MDN signale des difficultés de référencement et une gestion d’état plus lourde.
- Génération statique : les pages sont produites à l’avance et servies telles quelles, très rapides et peu exposées. C’est le principe de l’architecture Jamstack.
Google sait exécuter le JavaScript (il explore, rend puis indexe les pages), mais il écrit lui-même que le rendu côté serveur ou le pré-rendu reste une excellente idée, car il accélère le site pour les utilisateurs comme pour les robots et que tous les robots n’exécutent pas le JavaScript. Pour une partie publique qui doit être trouvée sur Google, privilégiez donc le rendu serveur ou statique ; une SPA convient bien à un espace connecté.
Comment choisir l’architecture de votre projet ?
Quelques questions suffisent à orienter la décision :
- Combien d’utilisateurs, et avec quels pics ? Une application interne pour 50 personnes n’a pas les contraintes d’une plateforme grand public.
- Quelle taille d’équipe, aujourd’hui et dans deux ans ? Les microservices servent d’abord à faire travailler plusieurs équipes en parallèle.
- Le produit est-il stabilisé ? Tant que le périmètre bouge, il est difficile de tracer les bonnes frontières entre services.
- Quelles intégrations ? ERP, CRM, paiement, outils métiers : elles pèsent souvent plus que le reste.
- Quel budget d’exploitation ? Plus l’architecture est distribuée, plus l’hébergement et la supervision coûtent.
Martin Fowler résume la position la plus prudente dans son billet « MonolithFirst » (juin 2015) : ne pas démarrer un nouveau projet en microservices, même si l’on pense qu’il deviendra assez gros pour le justifier. On valide d’abord le produit, on découvre les vraies frontières à l’usage, puis on découpe si besoin.
Ces arbitrages se font au moment du cadrage. Si vous avez un projet d’outil métier, d’espace client ou de plateforme, on conçoit des applications web sur mesure en commençant par ce travail d’architecture. Un bon cahier des charges d’application web vous fera aussi gagner du temps. Pour en parler, écrivez-nous à contact@osmova.com ou passez par le formulaire de contact.
Quelles sont les bonnes pratiques ?
Une bonne architecture se reconnaît à ce qu’elle rend le développement et la maintenance plus simples : le code est facile à comprendre, à tester, à modifier et à étendre. Les principes les plus utiles :
- Séparer les responsabilités : interface, logique métier et accès aux données dans des couches distinctes.
- Appliquer la méthode « Twelve-Factor App », rédigée par Adam Wiggins à partir de l’expérience de la plateforme Heroku : une seule base de code versionnée, dépendances déclarées, configuration dans l’environnement (jamais de mot de passe dans le code), processus sans état, parité entre développement et production, logs traités comme un flux.
- Prévoir des environnements séparés (développement, préproduction, production) pour tester avant de mettre en ligne.
- Penser sécurité dès la conception : HTTPS partout, contrôle des droits côté serveur, dépendances à jour, sauvegardes testées.
- Automatiser les tests et le déploiement pour livrer souvent sans casser l’existant.
- Superviser la production : sans journaux ni métriques, on découvre les pannes par les clients.
- Documenter les décisions importantes et leur raison, pour les développeurs qui viendront après.
Quelles erreurs éviter ?
- Copier l’architecture des géants. Ce qui fonctionne pour une entreprise de milliers de développeurs est souvent un fardeau pour une équipe de trois.
- Découper trop tôt. Des microservices mal délimités créent un « monolithe distribué » : toute la complexité du réseau, sans l’indépendance promise.
- Ignorer le référencement en livrant une SPA pour des pages qui doivent être trouvées sur Google.
- Tout bâtir sur un fournisseur unique sans mesurer le coût d’une sortie.
- Oublier l’exploitation : sauvegardes, mises à jour, supervision ont un coût récurrent à prévoir dès le devis.
Questions fréquentes
Quelle est l’architecture la plus courante pour une application web ?
L’architecture en trois couches : une interface dans le navigateur, un serveur applicatif et une base de données, le plus souvent organisés en monolithe. Elle convient à la grande majorité des projets de PME.
Quand passer aux microservices ?
Quand plusieurs équipes se gênent sur la même base de code, quand certaines parties ont des besoins de charge très différents, et quand le produit est assez stable pour tracer des frontières claires. Pas avant.
Une application monopage (SPA) est-elle mauvaise pour le SEO ?
Pas forcément, Google exécute le JavaScript. Mais il recommande lui-même le rendu serveur ou le pré-rendu pour la rapidité et la compatibilité avec tous les robots. Pour des pages publiques, c’est le choix le plus sûr.
Quelle différence entre architecture web et architecture de l’information ?
L’architecture web (ou applicative) concerne l’organisation technique du système. L’architecture de l’information concerne l’organisation des contenus et de la navigation pour l’utilisateur : menus, rubriques, arborescence.
Comment devenir architecte logiciel ?
Presque toujours après plusieurs années comme développeur. Concevoir ses propres applications de bout en bout (cache, files de messages, montée en charge, déploiement) et étudier les choix d’architecture de projets existants est la meilleure école.
