Architecture d’une application web : les choix à cadrer

L’architecture d’une application web définit comment son interface, ses règles métier, ses données et ses connexions fonctionnent ensemble. Pour la choisir, partez des opérations à réaliser et des erreurs à éviter, pas d’une liste de technologies. Une plateforme comportant de nombreux écrans n’a pas nécessairement besoin de nombreux services indépendants.

Ce guide s’adresse aux responsables techniques et aux équipes produit qui préparent une application web métier sur mesure. Il propose une méthode de cadrage et un exemple fictif, pas un retour d’expérience client ni une prescription valable pour tous les systèmes.

À retenir

• Décrivez les parcours critiques avant de dessiner les composants.
• Séparez les responsabilités dans le logiciel avant de multiplier les déploiements.
• Précisez qui possède chaque donnée et qui peut la modifier.
• Justifiez toute complexité supplémentaire par une contrainte vérifiable.

1. Décrire les opérations avant les composants

Le premier livrable utile est une carte des opérations : acteur, action, données utilisées, règle de validation et résultat attendu. Elle permet de discuter des frontières du système sans commencer par un débat sur les outils.

Pour chaque parcours important, consignez :

1. Qui déclenche l’action et dans quel contexte.
2. Quelles informations doivent être disponibles.
3. Quelle décision le logiciel prend et quelle validation reste humaine.
4. Ce qui arrive lorsqu’une dépendance ne répond pas.
5. Comment l’utilisateur sait que l’opération a réellement abouti.

Exemple fictif : un collaborateur demande un achat, un responsable le valide et un système comptable reçoit la commande. Le parcours n’est pas terminé quand le formulaire affiche un message vert. Il faut distinguer « demande enregistrée », « validation obtenue » et « commande transmise ».

Cette distinction révèle des questions d’architecture : la comptabilité peut-elle être indisponible sans bloquer la demande ? Une tentative répétée risque-t-elle de créer deux commandes ? Quelle information fait foi si les deux outils affichent des états différents ?

Point de contrôle : une personne métier et une personne technique doivent pouvoir raconter le même scénario, y compris son échec, sans utiliser de noms de composants.

2. Attribuer une responsabilité à chaque couche

Une architecture web repose notamment sur des échanges entre un client, souvent le navigateur, et un serveur. La documentation MDN sur les interactions client-serveur décrit ce cycle de requêtes et de réponses. Le serveur peut appliquer un traitement, accéder aux données puis retourner une page ou des données.

Pour cadrer une application métier, répartissez les responsabilités ainsi :

• Interface : présenter les informations, guider la saisie et signaler l’état d’une action.
• Règles métier : vérifier les transitions autorisées, calculer les résultats et contrôler les accès.
• Stockage : conserver les données et les contraintes nécessaires à leur cohérence.
• Intégrations : échanger avec les outils externes selon des contrats définis.
• Traitements différés : exécuter certaines opérations longues sans immobiliser une requête interactive.

Ce découpage est logique. Il n’impose pas un serveur physique par responsabilité. Dans le scénario d’achat, les domaines « demandes » et « validations » peuvent rester dans une application unique tout en étant clairement séparés dans le code et les règles d’accès.

Pour une connexion à un CRM ou ERP existant, documentez aussi la source de référence. Si le CRM possède le contact commercial, évitez qu’un autre écran crée silencieusement une seconde version concurrente de cette fiche.

3. Choisir entre application modulaire et microservices

Une application modulaire conserve des frontières internes tout en pouvant être livrée comme un ensemble. Des microservices séparent aussi des unités de déploiement et de communication. Cette indépendance peut répondre à un besoin réel, mais elle ajoute des dépendances à exploiter.

Le guide d’architecture de Microsoft sur les microservices souligne leurs contreparties : cohérence des données, transactions distribuées, communications entre services et tests des dépendances. Découper le logiciel ne supprime donc pas la complexité ; une partie devient celle du système distribué.

Pour démarrer la décision, utilisez cette grille, qui constitue une proposition de cadrage et non un classement universel :

• Les règles métier évoluent-elles encore ensemble ? : Application modulaire à examiner : Les changements sont coordonnés dans le même périmètre. ; Séparation de services à examiner : Des domaines sont suffisamment stables et distincts.
• Les équipes doivent-elles livrer indépendamment ? : Application modulaire à examiner : Une livraison coordonnée reste acceptable. ; Séparation de services à examiner : L’indépendance répond à une contrainte opérationnelle précise.
• La charge est-elle localisée ? : Application modulaire à examiner : Une optimisation ciblée peut suffire. ; Séparation de services à examiner : Un domaine exige une capacité ou une isolation distincte.
• L’exploitation est-elle préparée ? : Application modulaire à examiner : Le suivi d’un ensemble est déjà maîtrisé. ; Séparation de services à examiner : Déploiements, alertes et incidents distribués sont pris en charge.

Ne transformez pas cette grille en score automatique. Une seule exigence forte peut peser davantage que plusieurs préférences. À l’inverse, une hypothèse de croissance sans scénario de charge ne suffit pas à justifier une architecture distribuée.

Livrable attendu : une décision écrite avec l’option retenue, l’alternative écartée, ses raisons et les conditions qui déclencheraient un réexamen.

4. Concevoir les droits et les erreurs avec les données

La sécurité ne doit pas dépendre uniquement des éléments visibles dans l’interface. L’OWASP recommande de vérifier les autorisations à chaque requête et d’adopter un refus par défaut. Masquer le bouton « Valider » ne suffit pas à empêcher une validation non autorisée.

Dans l’exemple fictif, précisez qui peut demander, valider, annuler et consulter un achat. Ajoutez le périmètre : son service, son établissement ou l’ensemble de l’organisation. Testez aussi l’accès direct à une demande appartenant à un autre périmètre.

Pour les échanges entre systèmes, préparez une fiche par flux :

• Donnée envoyée et source de référence.
• Événement qui déclenche l’envoi.
• Identifiant permettant de reconnaître une tentative déjà traitée.
• Réponse attendue, délai maximal et comportement en cas d’erreur.
• Responsable d’une reprise manuelle lorsque l’automatisation échoue.

Une file d’attente n’exonère pas de cette réflexion. Elle peut différer un envoi, mais il faut encore décider comment détecter un doublon, rendre l’échec visible et rejouer l’action sans effet indésirable.

Point de contrôle : la démonstration doit inclure un accès refusé, une dépendance indisponible et une nouvelle tentative. Un parcours réussi ne valide pas, à lui seul, l’architecture.

5. Vérifier la capacité et l’exploitation sur des scénarios

« L’application doit être scalable » n’est pas un critère de recette. Remplacez cette formule par des hypothèses : parcours concerné, utilisateurs simultanés, volume de données, fréquence des imports et comportement acceptable pendant un pic.

Choisissez les indicateurs en fonction de ces parcours : durée d’une recherche, erreurs de validation, attente d’un traitement différé ou délai d’une synchronisation. Définissez également comment retrouver la cause d’un problème. La documentation OpenTelemetry sur l’observabilité explique notamment la complémentarité des mesures, journaux et traces pour comprendre l’exécution d’un système.

Pour la recette, demandez des preuves ciblées plutôt qu’une promesse générale :

1. Une opération représentative fonctionne avec un volume de données convenu.
2. Son comportement est mesuré dans un environnement décrit.
3. Une panne de dépendance produit un état compréhensible.
4. La restauration d’une sauvegarde est essayée dans un environnement isolé.
5. Le déploiement et le retour à une version connue sont documentés.

Si une application mobile d’entreprise utilise les mêmes données, incluez ses contraintes réseau et ses versions encore actives. Une interface web récente ne prouve pas la compatibilité d’une application mobile plus ancienne.

Les documents à obtenir avant de développer

Un cadrage exploitable peut tenir dans un dossier court, à condition qu’il expose les décisions :

• La carte des parcours prioritaires et de leurs échecs.
• Le schéma des responsabilités et des échanges.
• La définition des données de référence et des droits.
• Les contrats d’intégration et les règles de reprise.
• Les hypothèses de charge et les critères de recette.
• Les décisions d’architecture, leurs limites et leur responsable.

Le niveau de détail dépend du risque. Une opération qui modifie une commande demande un traitement plus explicite qu’une préférence d’affichage. Une dépendance difficile à remplacer mérite une justification écrite dès le départ.

Questions fréquentes

Faut-il des microservices pour accueillir plus d’utilisateurs ?

Pas systématiquement. Il faut d’abord identifier la ressource qui limite le parcours : requêtes de données, traitement, réseau ou dépendance externe. Séparer un domaine est une option à évaluer lorsque cette séparation répond à une contrainte démontrée, pas une conséquence automatique du nombre d’utilisateurs.

Peut-on faire évoluer l’architecture sans tout reconstruire ?

Une évolution progressive peut être étudiée si les dépendances et les données sont suffisamment comprises. Commencez par isoler un périmètre, définir ses interfaces et prévoir sa coexistence avec l’existant. La faisabilité dépend du système actuel ; elle ne se déduit pas d’un schéma cible seul.

Faut-il choisir l’architecture avant le cahier des charges ?

Définissez d’abord les objectifs, les parcours et les contraintes. Les premiers choix techniques peuvent ensuite révéler des risques qui précisent le périmètre. Le cadrage et l’architecture se nourrissent mutuellement ; l’un ne doit pas devenir un prétexte pour figer l’autre trop tôt.

Transformer le cadrage en prochaine décision

Avant de demander une solution complète, réunissez un parcours prioritaire, un exemple de données anonymisées, les outils à connecter et les contraintes non négociables. Cette base permet de comparer des options sur leurs effets concrets plutôt que sur leur vocabulaire.

Planifier une consultation technique pour examiner ce périmètre et les décisions à prendre avant le développement.

Article de 3N Corporation, préparé avec une assistance IA à partir de documentation technique publique. Sources consultées le 19 octobre 2026. Les exemples sont fictifs ; aucun test client ni résultat mesuré n’est revendiqué.