6.3Bonnes pratiques & pièges
L'essentiel en 30 secondes
- Règle d'or : code propre, méfiance systématique envers les entrées, structure et livraison — la sûreté paie, jamais la vitesse brute.
- À faire : === et strict_types, requêtes préparées + échappement, MVC + Composer, password_hash + .env, PHPUnit, mesure puis livraison.
- À éviter : concaténation SQL, affichage brut, secrets en clair, validation client seule, tests négligés, erreurs exposées.
Fil Riad — trois habitudes qui paient
Après un an, Riad fait son bilan : ce qui a le plus compté n'est pas un framework, mais trois habitudes — comparer en strict et typer, préparer chaque requête et échapper chaque affichage, et livrer jusqu'au bout avec tests et déploiement. Et son plus gros piège évité de justesse : un mot de passe stocké en clair pendant une semaine de rush.
Choisissez une seule habitude à ancrer dans votre rituel, puis passez à la suivante.
Ce qui fait la différence
La différence entre un bricolage et une pratique pro ne tient pas aux outils, mais aux réflexes : écrire un code propre, ne jamais faire confiance aux entrées, structurer, tester, et livrer.
✓ À faire
- Écrire du PHP moderne : === par défaut, typage (declare(strict_types=1)), fonctions à responsabilité claire.
- Ne jamais faire confiance aux entrées : valider côté serveur, requêtes préparées, échapper à l'affichage.
- Structurer (MVC, séparation logique/affichage) et exploiter Composer (autoloading, bibliothèques éprouvées).
- Hacher les mots de passe (password_hash), protéger les secrets (variables d'environnement), HTTPS, autorisation.
- Écrire des tests (PHPUnit) sur la logique critique ; mesurer avant d'optimiser.
- S'appuyer sur les frameworks (protections par défaut) et livrer jusqu'au bout (déploiement, CI/CD).
✗ À éviter
- Concaténer des données dans le SQL (injection) ou afficher des données brutes (XSS).
- Stocker un mot de passe en clair ou un secret dans le dépôt Git.
- Se reposer sur la validation client (contournable) ; mélanger logique et affichage (spaghetti).
- Négliger les tests (« ça marche ») et laisser des régressions silencieuses.
- Optimiser prématurément au lieu de mesurer et cibler ; sur-ingénierie.
- Afficher les erreurs détaillées en production (divulgation d'informations).
Script prêt à dire — vérifier sa pratique avant de livrer (30 s)
« strict_types et === ? Entrées validées serveur, SQL préparé, affichage échappé, CSRF ? password_hash, secrets en .env, HTTPS, autorisation ? PHPUnit au vert, erreurs journalisées ? Si un non, je corrige avant de livrer. »
Modèle copier-coller — inscription sûre (hachage + préparée)
prepare("INSERT INTO users (email, hash) VALUES (:email, :hash)");
$stmt->execute(["email" => $email, "hash" => $hash]);
function verifier(string $saisi, string $hash): bool {
return password_verify($saisi, $hash);
}TPE / petit budget
Une seule habitude par trimestre suffit : requêtes préparées d'abord, le reste ensuite.
PME Constantine
Adapter les rituels aux pics et aux déplacements : un créneau de revue du code et des tests tenu chaque semaine.
Remote / hybride
La discipline n°1 à distance : revues écrites et tests au vert, même pour les petits correctifs.
Interculturel
Vérifier les usages locaux plutôt que supposer : une règle d'autorisation inhabituelle doit alerter partout.
Défi 48h — appliquez demain
Passez votre page principale au crible : zéro concaténation SQL, zéro affichage brut, zéro secret versionné. Corrigez le premier écart trouvé.
- Je connais les réflexes à faire et les pièges à éviter.
- J'ai vérifié mes 3 points critiques (SQL, affichage, secrets).
- J'ai fait le défi 48h ou planifié sa date.
Avant de livrer, Riad vérifie sa pratique. Quel réflexe le protège le mieux ?
Règle d'or : un bon développeur PHP n'est pas celui qui code le plus vite, mais celui dont les applications sont propres, sûres, maintenables et réellement livrées en production.