Aller au contenu

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

Du clic à la page affichéeQuatre étapes : l'utilisateur agit, le navigateur envoie une requête, le serveur construit la page, le navigateur l'affiche.1ActionL'utilisateur clique sur un lien ou valide un formulaire2RequêteLe navigateur envoie une requête au serveur3ConstructionLe serveur fabrique la page demandée4AffichageLe navigateur affiche la nouvelle page
  1. ActionL'utilisateur clique sur un lien ou valide un formulaire
  2. RequêteLe navigateur envoie une requête au serveur
  3. ConstructionLe serveur fabrique la page demandée
  4. AffichageLe navigateur affiche la nouvelle page
Du clic à la page affichée · Chaque lien d'une application web provoque ce cycle.

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é.

Site statique et application web
CritèreSite statiqueApplication web
Origine de la pageFichier enregistré à l'avanceConstruite à chaque requête
ContenuLe même pour tousDépend de la demande
ExemplePage de présentation fixeSuivi de commande
Site statique et application web · La différence tient à la façon dont la page est produite.

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.

Langages côté client et côté serveur
LangageRôleCôté
HTMLPrésentation des pagesClient
CSSCharte graphiqueClient
JavaScriptAutomatismes du clientClient
PHP ou JavaAutomatismes du serveurServeur
Langages côté client et côté serveur · Chaque langage a un rôle précis.

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.

L'équipe d'une application webCarte mentale avec l'application web au centre et cinq rôles : développeur, designer UI, designer UX, chef de produit, architecte.Code clientCode serveurDéveloppeurÉcransBoutonsDesigner UIParcoursFacilité d'usageDesigner UXPrioritésBesoinsChef de produitOrganisationChoix techniquesArchitecteApplication web

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
L'équipe d'une application web · Plusieurs métiers contribuent à une application.

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

★☆☆Environ 8 min

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 :

  1. la couleur des boutons de la page ;
  2. la vérification que le champ « nom » n'est pas vide, avant l'envoi du formulaire ;
  3. l'enregistrement de la commande dans la base de données ;
  4. 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
  1. Élément 1 : la couleur des boutons relève de la charte graphique, donc du CSS, exécuté côté client.

  2. Élément 2 : une vérification faite dans le navigateur est un automatisme côté client, écrit par exemple en JavaScript.

  3. É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.

  4. Élément 4 : l'organisation du contenu (titres, paragraphes, champs) relève de la présentation des pages, donc du HTML, côté client.

  5. 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

★★☆Environ 8 min

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
  1. On repère les données : 1 requête pour la page d'accueil, puis 7 clics sur des liens.

  2. Chaque clic provoque une nouvelle requête, donc 7 requêtes supplémentaires.

  3. On additionne : 1+7=81 + 7 = 8.

  4. 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

★★☆Environ 10 min

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.

  1. Qui est le fournisseur ? Qui est le consommateur ?
  2. Le développeur du site a-t-il besoin de connaître le code interne du prestataire ? Justifie.
  3. 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
  1. Question 1 : le prestataire offre le service de paiement, c'est le fournisseur. Le site de billets s'en sert, c'est le consommateur.

  2. Question 2 : non. L'API montre les fonctionnalités et cache le fonctionnement interne ; le développeur lit sa description et s'en sert.

  3. 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.

  4. 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

★★★Environ 12 min

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.

  1. Quelle attaque possible illustre cette situation ?
  2. Où faut-il placer le contrôle des données saisies : dans le navigateur, sur le serveur, ou les deux ? Justifie.
  3. 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
  1. Question 1 : insérer un texte non contrôlé dans une requête de base de données ouvre la porte à l'injection SQL.

  2. 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.

  3. 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.

  4. 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.

  1. Quelle est la caractéristique principale d'une application web ?

  2. Dans une application web, comment les pages sont-elles produites ?

  3. Quel langage sert à la charte graphique d'une page web ?

  4. Une vérification de saisie qui doit absolument être fiable pour la gestion (par exemple un droit d'accès) doit être faite côté serveur.

  5. Que désigne le sigle API ?

  6. Que cache normalement une API à celui qui l'utilise ?

  7. Parmi ces attaques, lesquelles visent une application web ?

    Plusieurs réponses possibles.

  8. Pour une entreprise, comment peut-on voir une API ?

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 ?

Elle permet à un logiciel d'utiliser les services d'un autre sans connaître son fonctionnement interne.4 Les équipes gagnent du temps et peuvent se spécialiser.4

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

  1. Ressources d'accompagnement - Développement d'applications, Éduscol. Consulté le 11 novembre 2026.
  2. Programme de management et numérique - Terminale STMG, Ministère de l'Éducation nationale. Consulté le 11 novembre 2026.
  3. Application web, Wikipédia. Consulté le 11 novembre 2026.
  4. 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.

Signaler une erreur sur cette page

Je suis en…

Primaire

  • CP Bientôt
  • CE1 Bientôt
  • CE2
  • CM1
  • CM2 Bientôt

Collège

Lycée

Supérieur

  • BTS Bientôt
  • BUT Bientôt
  • Licence Bientôt
  • Prépas Bientôt

Sur cette page