Systèmes d'information de gestion · Terminale STMGBac
Interfaces et applications web : cours de Terminale STMG
Publié le 11 novembre 2026 · Mis à jour le 11 novembre 2026 · Signaler une erreur
L'essentiel
- Une application web s'utilise dans un navigateur, sans installation sur le poste du client ; elle est hébergée sur un serveur.3
- Dans une application web, chaque page est fabriquée par le logiciel à chaque requête ; dans un site statique, les pages sont des fichiers déjà enregistrés.3
- Le code s'exécute des deux côtés : HTML, CSS et JavaScript pour le client, PHP ou Java pour le serveur.3
- Une API est la façade par laquelle un logiciel fournisseur offre ses services à un logiciel consommateur, sans montrer son fonctionnement interne.4
- Une application web doit être protégée : le cross-site scripting et l'injection SQL font partie des attaques possibles.3
Pourquoi parler d'interfaces et d'applications web ?
Tu utilises tous les jours des applications web sans y penser : consulter ta messagerie, remplir un formulaire d'inscription, suivre une commande sur un site marchand. Dans une entreprise, c'est pareil : saisir une facture, consulter un stock ou suivre un client passe de plus en plus par un navigateur.
Ce chapitre répond à trois questions. Qu'est-ce qu'une application web, et en quoi diffère-t-elle d'un simple site ? Que veut dire le mot interface quand on parle d'informatique ? Comment les logiciels dialoguent-ils entre eux ?
Tu es déjà passé par l'algorithmique de gestion et la programmation. Ici, tu prends du recul : tu ne cherches plus seulement à écrire du code, mais à comprendre comment une application est organisée et comment elle se branche sur d'autres logiciels.
Le programme de Terminale STMG parle d'expérimentations dans divers environnements numériques, parmi lesquels figure l'environnement de développement d'applications.2 Ce cours te donne le vocabulaire et les repères pour ces expérimentations.
Qu'est-ce qu'une application web ?
Comme un site web, une application web est en général installée sur un serveur. L'utilisateur la manipule dans son navigateur, à travers un réseau : Internet, mais aussi un intranet ou un réseau local.3 Cela compte pour une organisation : un intranet permet de proposer un outil de gestion aux seuls salariés, sans rien installer sur chaque poste.
L'utilisateur agit sur des widgets, c'est-à-dire des éléments graphiques comme les boutons, les listes déroulantes ou les cases à cocher.3
- ActionL'utilisateur clique sur un lien ou valide un formulaire
- RequêteLe navigateur envoie une requête au serveur
- ConstructionLe serveur fabrique la page demandée
- AffichageLe navigateur affiche la nouvelle page
Pages statiques et pages dynamiques
Pour comprendre une application web, il faut comparer deux façons de produire une page.
Dans un site statique, chaque page est un fichier préparé à l'avance et enregistré sur le serveur.3 Le serveur l'envoie telle quelle, quel que soit le visiteur.
Dans une application web, le logiciel fabrique les pages de toutes pièces à chaque requête.3 Le contenu dépend donc de la demande : le même écran « Mes commandes » affiche des lignes différentes selon le client connecté.
| Critère | Site statique | Application web |
|---|---|---|
| Origine de la page | Fichier enregistré à l'avance | Construite à chaque requête |
| Contenu | Le même pour tous | Dépend de la demande |
| Exemple | Page de présentation fixe | Suivi de commande |
Les langages : côté client et côté serveur
Une application web fait travailler deux ordinateurs : celui de l'utilisateur (le client) et le serveur. Chacun exécute son propre code. Cette séparation est la clé pour lire un projet de développement.
Un exemple de gestion fait comprendre l'intérêt de cette séparation. Sur un formulaire de commande, le navigateur peut vérifier tout de suite qu'un champ n'est pas vide : c'est un automatisme côté client. Mais l'enregistrement de la commande dans la base de l'entreprise se fait sur le serveur, qui seul a accès aux données.
Autre exemple : le style d'un bouton (couleur, taille, police) relève de la charte graphique, donc du CSS. Le fait que ce bouton déclenche l'enregistrement relève du programme du serveur.
| Langage | Rôle | Côté |
|---|---|---|
| HTML | Présentation des pages | Client |
| CSS | Charte graphique | Client |
| JavaScript | Automatismes du client | Client |
| PHP ou Java | Automatismes du serveur | Serveur |
L'interface utilisateur et le travail d'équipe
L'interface utilisateur est la partie visible de l'application. Sa qualité décide si les utilisateurs s'en servent facilement ou y renoncent. Concevoir une application web ne se résume donc pas à écrire du code.
Application web
- Développeur
- Code client
- Code serveur
- Designer UI
- Écrans
- Boutons
- Designer UX
- Parcours
- Facilité d'usage
- Chef de produit
- Priorités
- Besoins
- Architecte
- Organisation
- Choix techniques
Pour le programme de STMG, tu es aussi amené à utiliser un environnement de développement d'applications et à en comprendre l'interface.2 Un environnement de développement est l'outil dans lequel on écrit, organise et essaie le code d'une application.
L'interface de programmation : l'API
Prends l'image d'un distributeur de boissons. Tu vois des boutons et une fente : c'est la façade. Tu n'as pas besoin de connaître le mécanisme interne pour obtenir ta boisson. Une API joue ce rôle entre logiciels.
On distingue deux rôles. Le programme fournisseur offre des fonctionnalités. Les programmes consommateurs s'en servent en suivant la description de l'API.4
Pourquoi et comment réutiliser des API
Les applications actuelles ne partent presque jamais de zéro. La programmation réutilise des briques fonctionnelles fournies par des logiciels tiers.4 Pour assembler ces briques, il faut savoir comment dialoguer avec chacune, ce qui dépend de son API.4 Une application se sert souvent de nombreuses API, apportées par des bibliothèques qui s'appuient elles-mêmes sur d'autres API.4
Dans une architecture orientée services, les applications peuvent s'appuyer sur des fonctionnalités de logiciels tiers. Ces fonctionnalités sont offertes par des API mises en œuvre sous forme de services web.4
Prenons un exemple de gestion : un site de vente en ligne doit faire payer ses clients. Il peut fabriquer lui-même un module de paiement, ce qui est long et risqué. Il peut aussi utiliser le service d'un prestataire spécialisé, qui fournit une API : le site envoie la demande, reçoit la réponse, et n'a rien à savoir du fonctionnement interne du prestataire.
Sécuriser une application web
Une application web est exposée : n'importe qui peut essayer de l'utiliser. La sécurité fait donc partie du développement dès le départ.
Méthode : analyser une application web
Exercices corrigés
Exercice 1 Classer les éléments d'une boutique en ligne
Une boutique en ligne de vêtements est une application web. Pour chaque élément, indique s'il relève du client ou du serveur, et quel langage ou quelle notion du cours s'y rattache :
- la couleur des boutons de la page ;
- la vérification que le champ « nom » n'est pas vide, avant l'envoi du formulaire ;
- l'enregistrement de la commande dans la base de données ;
- l'organisation du contenu de la page (titres, paragraphes, champs du formulaire).
Indice 1
Relis le rôle de HTML, CSS et JavaScript dans le cours.
Indice 2
Pose-toi la question : ce traitement a-t-il besoin d'accéder aux données de l'entreprise ?
Voir la correction pas à pas
Élément 1 : la couleur des boutons relève de la charte graphique, donc du CSS, exécuté côté client.
Élément 2 : une vérification faite dans le navigateur est un automatisme côté client, écrit par exemple en JavaScript.
Élément 3 : l'enregistrement dans la base se fait côté serveur, avec un langage comme PHP ou Java, car seul le serveur accède aux données.
Élément 4 : l'organisation du contenu (titres, paragraphes, champs) relève de la présentation des pages, donc du HTML, côté client.
Bilan : 1, 2 et 4 sont côté client ; 3 est côté serveur.
Retiens la règle : ce qui concerne l'affichage est côté client, ce qui concerne les données est côté serveur.
Exercice 2 Compter les requêtes d'une navigation
Un utilisateur ouvre la page d'accueil d'une application web de gestion de commandes. Il clique ensuite sur 7 liens, un après l'autre. Chaque lien provoque l'envoi d'une nouvelle requête. L'ouverture de la page d'accueil a elle-même nécessité une requête.
Combien de requêtes ont été envoyées en tout ?
Indice 1
Chaque lien envoie une nouvelle requête, et l'ouverture de l'accueil en compte une aussi.
Voir la correction pas à pas
On repère les données : 1 requête pour la page d'accueil, puis 7 clics sur des liens.
Chaque clic provoque une nouvelle requête, donc 7 requêtes supplémentaires.
On additionne : .
Chaque requête donne en retour une nouvelle page : l'utilisateur a donc reçu 8 pages.
Il y a eu 8 requêtes. Le principe à retenir : un lien égale une requête, une requête égale une nouvelle page construite.
Exercice 3 Identifier le consommateur et le fournisseur
Un site de vente de billets de spectacle propose le paiement en ligne. Pour cela, il utilise le service d'un prestataire de paiement, qui met une API à disposition.
- Qui est le fournisseur ? Qui est le consommateur ?
- Le développeur du site a-t-il besoin de connaître le code interne du prestataire ? Justifie.
- Cite un avantage de cette solution par rapport à la création d'un module de paiement maison.
Indice 1
Le fournisseur offre des fonctionnalités, le consommateur s'en sert.
Indice 2
Pense à ce que l'API cache et à ce qu'elle montre.
Voir la correction pas à pas
Question 1 : le prestataire offre le service de paiement, c'est le fournisseur. Le site de billets s'en sert, c'est le consommateur.
Question 2 : non. L'API montre les fonctionnalités et cache le fonctionnement interne ; le développeur lit sa description et s'en sert.
Question 3 : le site gagne du temps et se concentre sur sa propre logique (spectacles, places, clients), pendant que le prestataire se spécialise dans le paiement.
Remarque : l'API fonctionne comme un contrat, donc le développeur doit aussi lire les limites annoncées par le prestataire.
Une API permet de réutiliser un service sans en connaître le fonctionnement. Réponds toujours en nommant les deux rôles.
Exercice 4 Repérer les risques d'un formulaire
Une application web d'une association permet de rechercher un adhérent par son nom. Le développeur insère directement le texte saisi dans une requête vers la base de données, sans le contrôler.
- Quelle attaque possible illustre cette situation ?
- Où faut-il placer le contrôle des données saisies : dans le navigateur, sur le serveur, ou les deux ? Justifie.
- Propose deux réflexes pour réduire le risque.
Indice 1
Une des attaques citées dans le cours porte sur le langage des bases de données.
Indice 2
Un contrôle fait dans le navigateur peut être contourné.
Voir la correction pas à pas
Question 1 : insérer un texte non contrôlé dans une requête de base de données ouvre la porte à l'injection SQL.
Question 2 : le contrôle indispensable est côté serveur, car un contrôle côté client peut être contourné. Un contrôle côté client reste utile pour le confort de l'utilisateur, en complément.
Question 3 : premier réflexe, considérer toute donnée saisie comme potentiellement malveillante ; second réflexe, contrôler ces données sur le serveur avant tout traitement.
Remarque : l'environnement d'hébergement joue aussi un rôle dans la sécurité de l'application.
Une application web ne doit jamais faire confiance à ce qu'elle reçoit. Le contrôle décisif se fait sur le serveur.
Quiz
8 questions · correction immédiate · ton score reste sur ton appareil.
-
Une application web se manipule en ligne depuis un navigateur et ne demande aucune installation chez le client.3 Les applications mobiles, elles, s'installent : c'est la confusion tentante de la dernière réponse. Un réseau est toujours nécessaire, même s'il peut être un simple réseau local.
-
Le logiciel crée les pages de toutes pièces à chaque requête.3 La première réponse décrit le site statique, où les pages sont des fichiers préparés d'avance. Le serveur ne reçoit pas les pages de l'utilisateur : il reçoit des requêtes.
-
Le CSS s'occupe de la charte graphique.3 Le HTML décrit la présentation des pages, ce qui est proche mais différent : il organise le contenu, le CSS en règle l'apparence. PHP s'exécute côté serveur.
-
Vrai : un contrôle fait seulement dans le navigateur peut être contourné par l'utilisateur. Le serveur, qui détient les données, doit refaire le contrôle. Le contrôle côté client est un confort, pas une protection.
-
Une API est une façade par laquelle un logiciel fournit ses services à d'autres logiciels.4 Elle ne s'adresse pas à l'utilisateur humain : l'écran de saisie, c'est l'interface utilisateur. Ce n'est ni un langage de pages, ni un réseau.
-
La description d'une API met en avant les fonctionnalités et cache les détails du fonctionnement interne.4 La première réponse est donc l'inverse de la vérité : les fonctionnalités sont justement ce qu'elle montre.
-
L'injection SQL, l'injection JavaScript et le cross-site scripting figurent parmi les attaques ou failles possibles d'une application web.3 Le recto-verso n'a aucun rapport avec la sécurité informatique : c'est un mode d'impression.
-
Du point de vue de l'entreprise, une API est un contrat dans lequel le fournisseur décrit ses fonctionnalités et d'éventuelles limitations.4 La charte graphique relève du CSS et concerne l'apparence, pas les échanges entre logiciels.
Les questions qu'on se pose
Quelle différence y a-t-il entre un site web et une application web ?
Un site statique envoie des pages déjà enregistrées. Dans une application web, le logiciel construit les pages à chaque requête.3 L'utilisateur y agit (saisie, validation), et la réponse dépend de ses actions.
À quoi sert une API en pratique ?
Faut-il connaître tous les langages du web pour comprendre ce cours ?
Non. Il faut savoir situer les grandes familles : HTML pour la présentation, CSS pour la charte graphique, JavaScript côté client, PHP ou Java côté serveur.3 Le but est de comprendre qui fait quoi, pas de programmer dans chacun.
Pourquoi ne suffit-il pas de contrôler les saisies dans le navigateur ?
Parce que le navigateur est entre les mains de l'utilisateur, qui peut contourner un contrôle. Le serveur doit donc vérifier les données sensibles. Une faille dans le code, comme l'injection SQL, expose l'application à une attaque quand le développeur n'a rien prévu pour la sécuriser.3
Sources
- Ressources d'accompagnement - Développement d'applications, Éduscol. Consulté le 11 novembre 2026.
- Programme de management et numérique - Terminale STMG, Ministère de l'Éducation nationale. Consulté le 11 novembre 2026.
- Application web, Wikipédia. Consulté le 11 novembre 2026.
- Interface de programmation, Wikipédia. Consulté le 11 novembre 2026.
Les numéros dans le texte renvoient à ces sources. Une source qui ne dit pas ce qu'on lui fait dire ? Signale-le.