Retour au blog

Licence Pro Métiers de l'Informatique : Développement Web, Cybersécurité et Cloud

Le trajet d'une requête web, les failles qui reviennent, les modèles du cloud et les règles du diplôme, avec trois exercices corrigés.

Cet article a été rédigé à des fins pédagogiques. Les informations présentées peuvent évoluer. Nous t’invitons à vérifier auprès de sources officielles.

Développement web, cybersécurité et cloud décrivent le même trajet vu de trois côtés : un navigateur envoie une requête, un serveur la traite avec sa base de données, puis renvoie une réponse. Le développeur écrit ce trajet, la sécurité empêche qu'on le détourne, le cloud loue les machines où il tourne. Quand tu te connectes à un site, ton mot de passe voyage chiffré, le serveur compare son empreinte à celle rangée en base, et ce serveur est peut-être une machine louée à l'heure.

Le trajet d'une requête web

Le client (ton navigateur, une application mobile) demande, le serveur répond, et ils se parlent en HTTP. Une requête porte une méthode, une adresse et parfois des données : GET demande une ressource sans rien modifier, POST envoie des données, celles d'un formulaire par exemple.

La réponse porte un code de statut et un contenu : une page HTML, ou des données JSON (du texte rangé en paires nom-valeur) si le serveur est une API, un service interrogé par d'autres programmes. Le front-end tourne dans le navigateur ; le back-end, c'est le code du serveur et sa base.

Le code dit comment ça s'est passé : 200 pour un succès, 404 pour une ressource introuvable, 500 pour un serveur en échec. Ne confonds pas 401, « identifie-toi », et 403, « je sais qui tu es, et c'est non ».

Les failles qui reviennent

L'OWASP, une fondation consacrée à la sécurité des logiciels, classe les dix risques les plus critiques des applications web. Dans son Top 10 de 2025, le contrôle d'accès défaillant arrive premier ; l'injection, qui regroupe l'injection SQL et le cross-site scripting, est cinquième (troisième en 2021). Ces failles viennent du même oubli.

Règle : tout ce qui vient du client peut avoir été fabriqué par un attaquant. Le serveur vérifie lui-même les droits, et une saisie n'est jamais exécutée comme du code.

Contrôle d'accès : ta facture s'affiche à l'adresse /facture?id=1042 ; tu tapes 1043 et tu lis celle d'un autre client. Le serveur aurait dû vérifier que la facture appartient au compte connecté ; cacher un bouton n'y change rien, la requête peut partir à la main.

Injection SQL : quand le serveur colle la saisie dans sa requête SQL (le langage qui interroge la base), un attaquant peut taper du SQL au lieu d'un nom, et la base l'exécute. La parade est la requête préparée : le code est écrit d'avance avec un emplacement, WHERE login = ?, et la valeur arrive à part, traitée comme un simple texte.

Cross-site scripting (XSS) : un commentaire contenant <script>, réaffiché tel quel, s'exécute chez chaque visiteur. La parade est d'échapper à l'affichage : < devient &lt;, que le navigateur montre sans l'interpréter.

Piège classique : le cadenas HTTPS ne protège d'aucune de ces failles. Il chiffre le trajet entre navigateur et serveur, mais la saisie piégée arrive intacte au serveur. HTTPS protège le transport, pas l'application.

Les mots de passe : hacher, pas chiffrer

Définition : chiffrer transforme une donnée avec une clé, qui permet de la retrouver. Hacher calcule une empreinte à sens unique : on ne remonte pas de l'empreinte à la donnée.

Un site n'a jamais besoin de relire ton mot de passe : il hache ta saisie et compare le résultat à l'empreinte stockée. MD5 ou SHA-256, trop rapides, laissent un attaquant tester un très grand nombre de mots de passe par seconde ; Argon2id, bcrypt ou scrypt sont lentes exprès. Elles mêlent aussi au mot de passe un sel, une chaîne aléatoire propre à chaque compte : deux mots de passe identiques donnent alors deux empreintes différentes.

Le cloud : qui gère quoi

Le cloud, c'est louer à un fournisseur du calcul, du stockage ou des logiciels, à la demande et payés à l'usage. Son atout est l'élasticité : on ajoute des machines quand le trafic monte, on les rend quand il baisse. En IaaS (infrastructure en tant que service), tu loues des machines virtuelles, des ordinateurs simulés par logiciel. En PaaS (plateforme), tu déposes ton code et le fournisseur fait tourner le reste. En SaaS (logiciel), tu utilises une application toute faite, comme une messagerie en ligne.

Qui gère ?IaaSPaaSSaaS
Matériel et réseauFournisseurFournisseurFournisseur
Système d'exploitationToiFournisseurFournisseur
Code de l'applicationToiToiFournisseur
Données et comptes des utilisateursToiToiToi

Une machine virtuelle embarque tout un système d'exploitation ; un conteneur n'emporte que l'application et ses dépendances, en partageant le noyau (le cœur) du système hôte. Il est donc plus léger et démarre plus vite.

Piège classique : « c'est dans le cloud, donc le fournisseur gère la sécurité ». Il protège ce qu'il gère, rien de plus. Un stockage laissé public ou un compte d'administration mal protégé restent ta responsabilité, quel que soit le modèle.

Ce que le diplôme exige

La licence professionnelle confère le grade de licence (180 crédits européens, 60 par année) : après un bac+2, il reste un an.

Aucune mention nationale (l'intitulé officiel) ne s'appelle « développement web, cybersécurité et cloud ». La nomenclature officielle en compte cinq qui commencent par « Métiers de l'informatique » : administration et sécurité des systèmes et des réseaux ; applications web ; conception, développement et test de logiciels ; conduite de projets ; systèmes d'information et gestion de données. Seule la fiche de ta formation dit quelle place y tiennent le cloud et la sécurité.

L'arrêté du 6 décembre 2019 fixe des règles communes. Les mises en situation professionnelle, dont projets tutorés (encadrés par un enseignant) et stages, pèsent au moins un tiers des crédits du parcours. Stages ou projets tutorés donnent lieu à un mémoire soutenu à l'oral. En alternance, les périodes en entreprise tiennent lieu de stage.

Exercices corrigés

Cherche chaque exercice sur ta feuille avant d'ouvrir la correction.

Exercice 1 : Données fictives. Une association loue pour sa billetterie des machines virtuelles à 0,10 € l'heure chacune. Sur un mois de 30 jours, 2 machines suffisent, sauf pendant les 3 jours de mise en vente, où il en faut 8 jour et nuit. Compare le coût du mois avec 8 machines allumées en permanence et avec un nombre ajusté à la demande.

Correction :

En permanence : $8 \times 30 \times 24 = 5\,760$ heures-machine, soit $5\,760 \times 0{,}10 = 576$ €.

Ajusté : 27 jours à 2 machines et 3 jours à 8, soit $(27 \times 2 + 3 \times 8) \times 24 = 1\,872$ heures-machine, et $1\,872 \times 0{,}10 = 187{,}20$ €.

L'élasticité fait économiser $576 - 187{,}20 = 388{,}80$ € sur le mois.

Exercice 2 : Le moteur de recherche d'une boutique construit sa requête ainsi :

"SELECT nom, prix FROM produits WHERE nom = '" + saisie + "'"

a) Un attaquant tape ' OR '1'='1. Écris la requête obtenue et dis ce qu'elle renvoie. b) Un collègue propose de passer le site en HTTPS. Est-ce la bonne correction ?

Correction :

a) La requête devient SELECT nom, prix FROM produits WHERE nom = '' OR '1'='1'. La condition se lit « nom vide, ou 1 égale 1 » : toujours vraie, elle renvoie toute la table.

b) Non. HTTPS chiffre le trajet, mais la saisie arrive intacte au serveur. La vraie correction est la requête préparée, WHERE nom = ?, avec la saisie passée à part : la base cherche alors un produit nommé ' OR '1'='1 et n'en trouve aucun.

Exercice 3 : Un attaquant a copié la base des comptes d'un site et le code du serveur. Quatre cas : les mots de passe étaient stockés A) en clair ; B) chiffrés, la clé étant écrite dans le code ; C) en empreintes SHA-256 sans sel ; D) en empreintes bcrypt avec un sel par compte. a) Classe ces cas du plus dangereux au plus sûr, en justifiant. b) Deux comptes ont le même mot de passe : que voit l'attaquant en C, et en D ?

Correction :

a) A, B, C, puis D. En A, tout se lit ; en B, la clé est dans le code volé, donc tout se déchiffre aussitôt, mots de passe solides compris. En C, l'empreinte ne se renverse pas, mais SHA-256 est rapide : l'attaquant hache des listes de mots de passe courants et retrouve les faibles. En D, chaque essai est lent et se refait compte par compte, car les sels diffèrent.

b) En C, deux mots de passe identiques donnent la même empreinte : l'attaquant voit le doublon, et en casser un lui donne l'autre. En D, les sels diffèrent, donc les empreintes aussi : rien ne trahit le doublon.

À retenir

À retenir :

  • Tout ce qui vient du client est suspect : droits vérifiés côté serveur, requêtes préparées, échappement à l'affichage.
  • HTTPS protège le transport, pas l'application.
  • Un mot de passe se hache, avec une fonction lente et un sel.
  • De l'IaaS au SaaS, le fournisseur gère de plus en plus, mais les données et les accès restent à toi.
  • Licence pro : au moins un tiers des crédits en mises en situation professionnelle, et un mémoire soutenu à l'oral.

Sources

Tu peux partager cette page librement, en citant ORBITECH AI Academy avec son lien.