6.4Checklists & modèles
L'essentiel en 30 secondes
- Au démarrage : environnement aligné sur la prod, Composer + .gitignore, MVC/PSR-4, base modélisée, strict_types et ===.
- Avant production : préparées + htmlspecialchars + CSRF, secrets en .env, erreurs journalisées, PHPUnit + CI/CD, sauvegardes.
- Règle : une checklist cochée à chaque fois vaut mieux qu'une méthode connue par cœur — en rush, on exécute.
Fil Riad — les fiches sous la main
Après un an, les deux fiches ci-dessous sont affichées chez Riad : celle de démarrage à côté de l'écran, celle de mise en production dans son tiroir avec le contact du référent. « Ce qui m'a sauvé, dit-il en substance, ce n'est pas de connaître les points, c'est de les cocher chaque fois — surtout les semaines de rush. »
Adaptez les formulations à votre contexte, gardez la structure : c'est elle qui évite oublis et incidents.
Deux listes à garder sous la main
Une checklist au démarrage d'un projet PHP, une avant la mise en production. Elles transforment les bons réflexes en routine vérifiable.
Au démarrage d'un projet PHP
- Environnement local prêt (pack AMP ou Docker), version de PHP alignée sur la production.
- Composer initialisé ; .gitignore (vendor/, .env) ; secrets hors du dépôt.
- Structure décidée (fichiers logiques ou MVC / framework), namespaces cohérents (PSR-4).
- Base modélisée (tables, relations) ; accès via PDO (mode exception) ou un ORM.
- Réflexes actifs : declare(strict_types=1), === par défaut, ne jamais faire confiance aux entrées.
Avant la mise en production
- Sécurité : requêtes préparées (SQL), htmlspecialchars (affichage), CSRF, mots de passe hachés, autorisation.
- Secrets et config par variables d'environnement (jamais dans le code ni Git) ; HTTPS activé.
- Erreurs NON affichées (journalisées) ; OPcache activé ; autoloader Composer optimisé.
- Tests (PHPUnit) au vert ; pipeline CI/CD qui teste avant de déployer ; déploiement via Git.
- Migrations exécutées, environnements séparés (dev/staging/prod), sauvegardes en place.
Script prêt à dire — valider une mise en production (30 s)
« Préparées, htmlspecialchars, CSRF, hash, autorisation ? Secrets en .env hors Git, HTTPS ? Erreurs journalisées, OPcache, autoload optimisé ? PHPUnit au vert et CI/CD ? Migrations, environnements séparés, sauvegardes ? Si un non, on ne met pas en production. »
Modèle copier-coller — suivi démarrage + production (1 ligne par point)
TPE / petit budget
Fiches sur une page affichée au mur : l'essentiel (versions, préparées, .env, tests) suffit.
PME Constantine
Prévoir les réalités locales dans la fiche : référents connus, pics, déplacements, sauvegardes vérifiées.
Remote / hybride
Ajouter une ligne confirmation écrite au suivi : à distance, une mise en production datée et validée évite les malentendus.
Interculturel
Expliciter les intitulés par écrit : ce qui semble évident (qui valide, quel environnement) ne l'est pas pour tous.
Défi 48h — appliquez demain
Prenez 1 projet réel, passez la checklist « au démarrage » et cochez où il en est. Notez le référent sur la fiche production.
- J'ai coché une checklist sur un projet réel.
- Je sais dégainer le démarrage et l'avant-production au bon moment.
- J'ai fait le défi 48h ou planifié sa date.
Riad s'apprête à mettre son application PHP en production. Que doit-il cocher en priorité ?
Astuce : ces checklists évitent l'essentiel des incidents — faille de sécurité, secret fuité, erreurs exposées en production, régression non détectée, déploiement raté.