Mettre en place un environnement de développement local avant publication Imprimer

Travailler en local permet de développer, tester et valider votre site sans impacter la production. Vous gagnez en rapidité (pas d’uploads constants), en qualité (tests complets) et en sécurité (aucune donnée réelle exposée).

Objectifs et bonnes pratiques

• Reproduire au plus près l’environnement serveur (version de PHP/MySQL, extensions, modules).
• Séparer développement, préproduction (staging) et production.
• Versionner le code avec Git et définir un flux clair (feature → staging → production).
• Isoler les secrets (fichiers .env, variables d’environnement), jamais dans le dépôt Git.

Prérequis

• Un gestionnaire de versions (Git).
• Un stack web local au choix :
  • Tout-en-un : MAMP/XAMPP/Laragon/Local…
  • Conteneurs : Docker + docker-compose (recommandé pour la portabilité).
  • Natif : PHP, MySQL/MariaDB et Apache/Nginx installés localement.
• Outils du projet : Composer (PHP), Node.js/npm (build front), etc.

Aligner les versions avec l’hébergement

• PHP : utilisez la même version locale que celle paramétrée dans cPanel (MultiPHP Manager). Installez les extensions nécessaires (intl, mbstring, gd, imagick, zip, pdo_mysql…).
• Base de données : choisissez MySQL/MariaDB proches de la version serveur pour éviter les surprises (modes SQL, encodage, collations).
• Serveur web : activez mod_rewrite (Apache) et vérifiez les règles .htaccess.

Créer le projet local

1. Cloner le dépôt : git clone <url>.
2. Installer les dépendances :
   • PHP : composer install --no-dev (ou install + --dev selon vos besoins locaux).
   • Front : npm ci (ou npm install) puis npm run build / dev.
3. Configurer les variables : dupliquez .env.example en .env, ajustez DB_HOST, DB_NAME, DB_USER, DB_PASS, URLs locales (ex. http://mon-projet.local).
4. Créer la base de données locale et importer un dump (si projet existant) via phpMyAdmin ou mysql < dump.sql.
5. Déclarez un VirtualHost (ou site Docker) pointant vers le dossier public (public/ ou public_html/).

HTTPS, mails et debug en local

• HTTPS local : générez un certificat de développement (ex. mkcert) pour tester les ressources mixtes, cookies sécurisés et redirections HTTPS.
• Mails : utilisez un capteur d’emails (MailHog/Mailpit) pour éviter l’envoi réel pendant les tests.
• Debug : activez Xdebug, logs d’erreurs PHP, et un niveau de reporting strict en local.

Préparer la publication

• Nettoyez : supprimez fichiers inutiles, désactivez le debug, minifiez/compilez vos assets.
• Mettez à jour la base de données (migrations) et les caches (ex. artisan optimize, wp cache flush).
• Vérifiez les URLs absolues, chemins, droits d’écriture (chmod/chown), et règles .htaccess.

Flux de déploiement recommandé

1. Local : développement + tests unitaires/fonctionnels.
2. Staging : synchronisation du code (Git/cPanel Git) et données anonymisées pour validation client.
3. Production : déploiement via cPanel (Git Version Control ou gestionnaire de fichiers), avec sauvegarde préalable et fenêtre de maintenance si nécessaire.

Gestion des données et sécurité

• N’embarquez jamais de secrets dans Git : utilisez .env et ne commitez pas ce fichier.
• Pour les CMS (WordPress, etc.), ne versionnez pas wp-config.php (ou équivalent) contenant des identifiants sensibles.
• Obfusquez/échantillonnez les données réelles pour vos environnements de test.

Erreurs fréquentes à éviter

• Différences de versions (PHP/MySQL) entre local et serveur → alignez-les dès le départ.
• Règles .htaccess non testées en local → activez AllowOverride All ou l’équivalent.
• Chemins/URLs codés en dur → préférez variables d’environnement et fonctions d’aide.
• Assets non compilés en prod → ajoutez une étape de build claire dans votre processus.

En résumé

Un environnement local bien configuré (versions alignées, variables isolées, HTTPS/mails simulés, debug activé) réduit drastiquement les régressions au moment de la mise en ligne. Combinez-le avec un staging et un déploiement soigné via cPanel pour des publications fiables et reproductibles.