PHP ou JavaScript : lequel choisir ?

Comprendre le rôle de chacun — et pourquoi la sécurité n'est pas symétrique

1. Deux rôles différents, pas deux concurrents

Imaginez un restaurant.

PHP, c'est la cuisine. Ça se passe en coulisses, avant que le plat n'arrive à table. Le serveur web reçoit la commande (la requête), va chercher les ingrédients (base de données, fichiers), prépare le plat (la page HTML), et l'envoie déjà prêt.
JavaScript (dans le navigateur), c'est le service en salle. Une fois le plat arrivé, on peut encore agir dessus sans retourner en cuisine : ajouter du sel, réchauffer, réagir aux clics du client. C'est l'interactivité après le chargement de la page.

	PHP (côté serveur)	JavaScript (côté navigateur)
Où ça tourne	Sur le serveur	Sur l'ordinateur de l'internaute
Quand	Avant l'arrivée de la page	Après l'arrivée de la page
Peut voir / toucher	Base de données, mots de passe, fichiers privés du serveur	Uniquement ce qui est déjà dans la page — rien de secret
Visible par l'internaute ?	Non, jamais (le code source PHP n'est jamais envoyé)	Oui, toujours (clic droit → Afficher le code source)
Exemple concret	Vérifier un mot de passe, calculer une facture, interroger MariaDB	Afficher un menu déroulant, valider un email avant l'envoi, animer un bouton

2. Le schéma du trajet d'une page web

sequenceDiagram
    participant N as Navigateur
    participant S as Serveur (PHP)
    N->>S: ① Requête (clic, adresse tapée)
    S->>S: ② Prépare la réponse (BDD, calculs, sécurité)
    S-->>N: ③ Renvoie la page toute prête
    N->>N: ④ JavaScript rend l'interface vivante

① L'internaute clique ou tape une adresse. ② PHP prépare la réponse en coulisses (base de données, calculs, sécurité). ③ ④ Une fois la page affichée, JavaScript rend l'interface vivante, sans recharger la page.

3. La sécurité : pourquoi ce n'est pas symétrique

Règle d'or : Never trust the client

Le code JavaScript tourne chez l'internaute, qui en a le contrôle total : il peut l'ouvrir, le modifier, le désactiver, ou envoyer une requête directement au serveur en ignorant complètement la page et son JavaScript.

Une vérification de sécurité faite uniquement en JavaScript est donc décorative : elle améliore le confort d'usage, mais ne protège rien contre quelqu'un de décidé.

Le code PHP tourne chez vous, sur le serveur : l'internaute ne le voit jamais et ne peut pas le modifier. C'est donc le seul endroit où une vérification de sécurité a un sens réel.

Attention cependant : « PHP est sûr » ne veut pas dire « PHP est sûr automatiquement ». La sécurité dépend toujours de la rigueur du programmeur.

Risque côté PHP (serveur)	Risque côté JavaScript (navigateur)
Injection SQL : un formulaire mal filtré permet de manipuler la base de données de tous les utilisateurs.	Manipulation du code : l'internaute modifie le JS dans son navigateur (ex : débloquer un bouton désactivé, changer un prix affiché).
Inclusion de fichiers : un script mal conçu charge des fichiers que l'attaquant choisit lui-même.	Requêtes forgées : l'attaquant envoie directement au serveur une requête que le site n'attendait pas, sans jamais passer par la page.
Mot de passe / clé secrète oublié dans le code : catastrophique si le fichier est mal protégé.	Secret exposé par erreur : toute clé, mot de passe ou logique « secrète » écrite en JS est visible par n'importe qui.

4. Ce qu'il faut retenir

PHP et JavaScript ne sont pas rivaux : l'un prépare, l'autre anime.
Tout ce qui doit rester secret ou fiable (mot de passe, prix, droits d'accès) se décide côté PHP.
JavaScript rend une page agréable à utiliser, mais on ne doit jamais lui faire confiance pour sécuriser quoi que ce soit.

Exercice — à vous de jouer

Pour chaque situation, indiquez si la vérification doit être faite en PHP, en JavaScript, ou dans les deux (et pourquoi) :

Vérifier qu'un email a bien la forme nom@domaine avant l'envoi du formulaire.
Vérifier qu'un mot de passe correspond bien à celui enregistré pour cet utilisateur.
Empêcher un internaute d'acheter un article à un prix qu'il aurait modifié lui-même dans la page.
Afficher un message d'erreur immédiat si un champ obligatoire est resté vide.

Corrigé

Les deux : en JS pour un retour immédiat et agréable, mais impérativement revérifié en PHP, car un attaquant peut envoyer un email invalide en contournant le formulaire.
PHP uniquement : c'est une vérification de sécurité contre une base de données — jamais accessible ni fiable côté navigateur.
PHP uniquement : le prix affiché dans la page est modifiable par l'internaute ; seul le serveur connaît le vrai prix.
Les deux, mais surtout JS pour le confort ; PHP doit quand même refuser une requête où le champ est vide, au cas où JS aurait été désactivé ou contourné.

Et avec Python ?

La même règle s'applique, car ce n'est jamais une question de langage mais d'endroit d'exécution.

Python côté serveur (Flask, Django) est dans le même camp que PHP : invisible et inaccessible à l'internaute, donc le seul endroit où une vérification de sécurité a un sens réel.
Python côté navigateur (via Brython ou Pyodide) est dans le même camp que JavaScript : le code est téléchargé et visible par l'internaute, donc jamais de secret ni de vérification de sécurité fiable là-dedans.

Le langage ne détermine rien à lui seul — seul l'endroit où le code tourne compte.

Linux Challans — atelier programmation