Choisir l'architecture de ton projet E6

Choisir une architecture, c'est partir du besoin (qui utilise l'application, où, avec quelles données et quelles règles) et des contraintes (taille de l'équipe, délais, compétences, exigences de l'épreuve) pour retenir l'organisation la plus simple qui y répond. Ce chapitre donne une méthode en cinq questions, l'applique à des réalisations d'E6, liste les questions que pose la commission sur l'architecture et les erreurs qui coûtent des points, puis termine par des cas corrigés et un aide-mémoire du cours.

La méthode en cinq questions

La réponse aux questions 1 et 4 détermine les tiers (chapitre 9) et les clients (chapitre 10). La réponse à la question 3 détermine les couches (chapitre 6). La question 5 rappelle qu'on choisit l'architecture la plus simple qui répond au besoin, pas la plus impressionnante.

Des besoins aux architectures

Deux réalisations complémentaires pour l'E6

L'environnement exigé à l'E6 SLAM demande, sur l'ensemble de tes réalisations, un cadre applicatif (framework), au moins deux langages, des appels à des services applicatifs distants et au moins trois des quatre situations d'exécution : poste fixe, navigateur, terminal mobile, serveur (les exigences détaillées). Deux réalisations bien choisies les couvrent :

Le framework, c'est ici Express côté API (ou ASP.NET Core si ton API est en C#), et .NET avec WinForms côté poste de travail. Du PHP natif seul n'en fournit pas : si ta réalisation web est en PHP sans framework, l'autre doit en utiliser un.

Autre combinaison classique : une application web en PHP et PDO rendue par le serveur (serveur et navigateur, en client léger) et un client lourd C# qui appelle une petite API Express. L'important est de pouvoir montrer, schéma à l'appui, où s'exécute chaque partie de ton code.

Ton architecture pendant l'épreuve

L'E6 ne te demande pas de présenter ton projet : la commission rédige une expression des besoins sur l'une de tes deux réalisations, et tu dois la traiter (le déroulement de l'E6). Ton architecture intervient à trois moments.

1. Dans le dossier. Les éléments techniques joints aux fiches descriptives montrent l'architecture de chaque réalisation : le diagramme de conteneurs avec technologies, versions et protocoles, le diagramme de déploiement (chapitre 12), l'arborescence commentée du code, couche par couche. La commission s'en sert pour écrire un besoin réaliste.
2. À l'entretien de la phase 1. Tu présentes ton analyse du besoin, les spécifications techniques et la démarche envisagée. C'est le moment de situer l'évolution dans ton architecture : « la règle va dans ReservationService.reserver, la colonne dans la table salle, l'affichage dans le composant ReserverSalle », et de justifier les outils choisis.
3. Pendant la réalisation, la recette et l'entretien d'explicitation. L'architecture te sert de carte pour coder vite : la méthode « de la base vers l'écran » du chapitre 3 s'applique à toutes les piles (base, Repository, service, contrôleur et route, vue ou composant, test). Ensuite, tu racontes le trajet de ta modification à travers les couches et tu montres le test qui la prouve.

Pour t'y préparer, entraîne-toi sur chaque réalisation à décrire le trajet d'une fonctionnalité de bout en bout (« quand l'utilisateur clique sur Réserver, la requête arrive dans la route POST /api/reservations, le contrôleur la vérifie, le service applique les quatre règles, le Repository insère la ligne ») et à justifier deux ou trois choix avec leur alternative : pourquoi une API plutôt qu'une connexion directe, pourquoi une SPA plutôt que des pages rendues par le serveur.

Les questions de la commission sur l'architecture

Les erreurs d'architecture qui coûtent des points

Lire une architecture à l'écrit E7

L'écrit E7 de l'option SLAM ne te demande pas de concevoir une architecture, mais il te fait lire du code et des schémas d'applications réelles : un extrait de contrôleur, une classe d'accès aux données, une requête, un diagramme. Savoir dans quelle couche chercher fait gagner du temps :

• un contrôle d'accès manquant (un utilisateur qui modifie la fiche d'un autre) se cherche dans le contrôleur, un middleware ou le service ;
• une injection SQL se cherche dans la couche d'accès aux données, là où une valeur est concaténée dans une requête ;
• une faille XSS se cherche dans la vue, là où une donnée est affichée sans échappement ;
• une fuite de données dans une API se cherche dans ce que le contrôleur renvoie (un objet complet au lieu d'un DTO).

Le cours Épreuve E7 SLAM détaille ces questions.

Cas corrigés

Exercice 1 sur 4 Cas 1 : proposer une architecture Réussi À revoir

Un club de handball de 300 licenciés veut une application pour gérer les inscriptions des joueurs aux matchs du week-end. Les entraîneurs composent les équipes depuis un ordinateur ; les joueurs indiquent leur disponibilité depuis leur téléphone, souvent dans les vestiaires ; le trésorier exporte chaque mois les présences vers un tableur. L'application est développée par un binôme d'étudiants de BTS SIO.

1. Propose une architecture (tiers, clients, organisation du code) et justifie-la.
2. Combien de situations d'exécution de l'annexe II.E couvre-t-elle ?
3. Où places-tu la règle « un joueur ne peut pas être sélectionné dans deux équipes le même jour » ?

Voir la réponseMasquer la réponse de l'exercice 1

1. Une API REST (Node.js et Express, ou PHP) en couches, avec une base MySQL : elle porte les règles et les données partagées par tous. Deux clients : une interface web pour les entraîneurs (SPA React, ou pages rendues par le serveur), et une application mobile (ou une interface web adaptée au téléphone) pour les joueurs. L'export du trésorier est une route de l'API qui renvoie un fichier CSV. Un monolithe suffit : un binôme, une charge modeste, des données liées (joueurs, équipes, matchs).
2. Avec une SPA et une application mobile : navigateur, terminal mobile et serveur, soit trois situations, plus l'appel de l'API comme service distant. Avec une simple interface web adaptée au téléphone au lieu d'une application mobile, le code ne s'exécute plus sur le terminal mobile : il reste navigateur et serveur.
3. Dans la couche service de l'API (SelectionService.selectionner), qui interroge le Repository pour savoir si le joueur est déjà sélectionné ce jour-là. Pas dans l'interface des entraîneurs : la règle doit tenir quel que soit le client.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 4 Cas 2 : critiquer une architecture Réussi À revoir

Voici la description de la réalisation d'une étudiante : « GestStock est une application WinForms installée sur les 12 postes du magasin. Elle se connecte au serveur MySQL avec le compte root, dont le mot de passe est dans le fichier App.config. Chaque formulaire contient ses requêtes SQL. Le calcul du prix de vente (prix d'achat, marge, remise selon la catégorie de client) est fait dans le formulaire de vente et dans le formulaire de devis. »

Relève les problèmes d'architecture et de sécurité, et propose une architecture cible.

Voir la réponseMasquer la réponse de l'exercice 2

Problèmes :

• Compte root : chaque poste a tous les droits sur le serveur MySQL, y compris supprimer les bases ou créer des comptes.
• Mot de passe dans App.config, lisible sur les 12 postes et sans doute versionné dans Git.
• Architecture 2 tiers : le port 3306 est ouvert à tout le magasin, n'importe quel outil peut interroger la base en contournant l'application.
• SQL dans les formulaires : aucune séparation, risque d'injection à vérifier partout, requêtes recopiées.
• Règle de prix recopiée dans deux formulaires : une modification de la remise risque de n'être faite qu'à un endroit, et les devis ne correspondront plus aux ventes.

Architecture cible :

• À court terme, sans tout réécrire : un compte MySQL dédié aux droits réduits, des DAO ou Repository qui regroupent le SQL, une classe PrixService utilisée par les deux formulaires, des formulaires qui ne contiennent plus que l'affichage.
• À moyen terme : une API (ASP.NET Core ou Express) qui porte les services et l'accès aux données ; l'application WinForms l'appelle en HTTPS ; MySQL n'accepte plus que les connexions du serveur de l'API.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 Cas 3 : situer une évolution Réussi À revoir

L'expression des besoins de ton E6 demande d'ajouter à ResaSalles (version SPA + API) la règle : « une salle équipée pour la visioconférence ne peut pas être réservée pour moins de 3 participants ». Elle demande aussi d'afficher une icône de caméra à côté des salles équipées dans la liste déroulante. Liste les fichiers à modifier, dans l'ordre, et le test à écrire.

Voir la réponseMasquer la réponse de l'exercice 3

1. Base et Repository : rien à modifier, SalleRepository.trouverParId renvoie déjà la colonne visio. Vérifie-le en lisant la requête.
2. Service (reservation.service.js) : après la vérification de capacité, if (salle.visio && participants < 3) throw new ErreurMetier('Une salle de visioconférence se réserve pour 3 personnes au moins');.
3. Contrôleur et route : rien, l'ErreurMetier est déjà traduite en 422 par le gestionnaire d'erreurs.
4. Front : dans ReserverSalle.jsx, ajouter l'icône dans le texte de l'option quand s.visio est vrai. La liste des salles renvoyée par GET /api/salles doit contenir visio ; si ce n'est pas le cas, ajouter la colonne dans la requête du Repository et dans la réponse du contrôleur.
5. Test : dans reservation.service.test.js, un faux salleRepository qui renvoie une salle avec visio: 1 et une demande de 2 participants doit être refusée (statut: 422) ; une demande de 3 participants doit passer.

C'est la démonstration attendue : la règle est à un seul endroit, le reste de l'application n'a presque pas bougé, et un test prouve qu'elle fonctionne.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Cas 4 : QCM de synthèse Réussi À revoir

Une seule bonne réponse par question.

1. Une application Express organisée en routes, contrôleurs, services et Repository, qui interroge MySQL, est : a) une architecture en couches ; b) une architecture en microservices ; c) une architecture 1 tiers ; d) une application serverless.
2. L'injection de dépendances consiste à : a) injecter du SQL dans une requête ; b) fournir à une classe les objets dont elle a besoin au lieu qu'elle les crée ; c) installer les dépendances avec npm ; d) ajouter des dépendances entre les tables.
3. Dans le modèle C4, un « conteneur » est : a) un conteneur Docker ; b) une classe ; c) un programme ou un stockage qui s'exécute séparément ; d) un serveur physique.
4. Le principal risque d'un client lourd connecté directement à la base est : a) la lenteur de l'interface ; b) la présence des identifiants de la base sur chaque poste ; c) l'impossibilité d'utiliser des requêtes préparées ; d) l'absence de MVC.

Voir la réponseMasquer la réponse de l'exercice 4

1. a) Une architecture en couches (et 3 tiers si l'on compte le navigateur, le serveur Node.js et MySQL).
2. b) Le plus souvent par le constructeur.
3. c) Une application web, une API, une application de bureau ou mobile, une base de données.
4. b) N'importe quel utilisateur peut récupérer les identifiants et contourner les règles de l'application.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Aide-mémoire du cours