Un script Cron qui s’exécute avec trop de privilèges, qui s’exécute en double ou qui échoue en silence représente un danger majeur pour la sécurité et l’intégrité de vos données.

Règle 1 : Ne lancez jamais vos scripts sous l’utilisateur root

Un script vulnérable exécuté en root compromet instantanément l’intégralité du serveur dédié. Utilisez le cron de l’utilisateur applicatif dédié (ex: www-data).

# Modifier le cron d'un utilisateur spécifique
crontab -u www-data -e

Règle 2 : Déclarer un environnement d’exécution (PATH) explicite

Contrairement à votre terminal interactif, l’environnement d’un Cron est extrêmement restreint. Spécifiez toujours les chemins absolus pour vos binaires ou déclarez le PATH en haut de votre fichier crontab :

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Exemple de tâche sécurisée avec chemins absolus
0 4 * * * /usr/bin/php /var/www/mon-projet/artisan backup:run

Règle 3 : Éviter l’exécution simultanée (Overlap) avec flock

Si un script de synchronisation configuré pour tourner toutes les 5 minutes met finalement 10 minutes à s’exécuter, une deuxième instance va se lancer en parallèle. Cela provoque souvent des corruptions de données ou des surcharges CPU. Utilisez flock pour verrouiller l’exécution :

*/5 * * * * usr/bin/flock -n /tmp/mon_cron_sync.lock -c "/usr/bin/php /var/www/mon-projet/sync.php"

(Le commutateur -n indique à flock de s’arrêter immédiatement sans attendre si le verrou est déjà actif).

Règle 4 : Capturer et masquer la sortie standard, mais logger les erreurs

Ne laissez pas vos crons polluer les boîtes mail locales ou les fichiers de logs génériques. Redirigez la sortie standard (stdout) vers le vide absolu /dev/null, tout en capturant les erreurs (stderr) :

0 2 * * * /usr/bin/python3 /scripts/clean.py > /dev/null 2> /var/log/cron_e

The post Comment sécuriser ses tâches planifiées ? first appeared on DEMARCQ.NET.

Nginx intègre un moteur de limitation de débit très puissant basé sur l’algorithme du Leaky Bucket. Il permet de bloquer l’abus de requêtes sans perturber les utilisateurs légitimes.

Étape 1 : Définir la zone de stockage (limit_req_zone)

Ouvrez votre fichier de configuration principal /etc/nginx/nginx.conf ou le bloc http de votre site :

http {
    # Crée une zone de 10 Mo nommée "login_limit" pour stocker les adresses IP (1 Mo = ~16 000 IP)
    # Limite le débit à 1 requête par seconde (1r/s) par adresse IP
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;
    
    # Zone globale pour le reste du site (ex: 10 requêtes par seconde max)
    limit_req_zone $binary_remote_addr zone=global_limit:10m rate=10r/s;
}

Étape 2 : Appliquer les limitations sur vos routes sensibles

Dans la configuration de votre serveur virtuel (server ou location), appliquez ces zones :

server {
    ...

    # Protection des formulaires sensibles (Authentification, inscription, recherche)
    location /login {
        # Applique la zone de limitation
        limit_req_req zone=login_limit burst=5 nodelay;
        
        # Définit le code d'erreur renvoyé au client (429 Too Many Requests au lieu de 503)
        limit_req_status 429;
        
        proxy_pass http://votre_backend;
    }

    # Limitation générale sur le reste du site
    location / {
        # burst=20 autorise temporairement jusqu'à 20 requêtes en rafale pour charger les assets (CSS, JS)
        limit_req zone=global_limit burst=20 nodelay;
        try_files $uri $uri/ /index.php?$query_string;
    }
}

• burst=X : Crée une file d’attente tampon. Si un utilisateur dépasse le débit de base, ses requêtes excédentaires (jusqu’à X) sont acceptées mais traitées au rythme configuré.

• nodelay : Indispensable pour éviter de ralentir artificiellement l’affichage de votre site pour les utilisateurs légitimes. Les requêtes dans la limite du burst sont exécutées immédiatement.

The post Comment mettre en place une limitation de débit avec Nginx ? first appeared on DEMARCQ.NET.

Attendre que votre serveur s’éteigne pour agir est une erreur critique. Le noyau Linux et le système d’exploitation envoient des signaux d’alerte bien avant la panne finale. Voici comment les traquer.

dmesg : Le journal du noyau (Kernel)

dmesg affiche les messages du tampon circulaire du noyau. C’est l’outil numéro un pour repérer les défaillances physiques directes.

• Vérifier les erreurs d’écriture disque / SATA :

  Bash

  dmesg | grep -Ei "ata|scsi|sd|sector|ext4|io error"
  

  Signe d’alerte : Des erreurs de type I/O error ou Buffer I/O error on dev sda indiquent que votre disque dur ou SSD est en train de rendre l’âme.

• Traquer l’instabilité de la mémoire RAM :

  Bash

  dmesg | grep -i "MCE"
  

  Signe d’alerte : Les erreurs MCE (Machine Check Exception) sont générées directement par le processeur lorsqu’il détecte une défaillance matérielle (souvent un problème de RAM ECC ou de surchauffe CPU).

journald et syslog : Les journaux du système

Avec systemd, journalctl centralise la majorité des logs.

• Lister uniquement les erreurs graves et critiques depuis le dernier démarrage :

  Bash

  journalctl -p 0..3 -b
  

  (Le paramètre -p 0..3 cible les niveaux Emergency, Alert, Critical et Error).

• Surveiller les kills par manque de mémoire (Out of Memory) : Si votre serveur s’arrête de répondre de façon aléatoire ou si vos services (comme MySQL) coupent tout seuls :

  Bash

  journalctl -ke | grep -i "oom-killer"
  

  L’OOM-Killer intervient pour tuer les processus gourmands lorsque la RAM est totalement saturée.

The post Comment analyser les logs système first appeared on DEMARCQ.NET.

Le choix et la configuration du gestionnaire de processus (process manager ou pm) dans votre pool PHP-FPM déterminent la réactivité de vos applications PHP sous forte charge.

Comparatif des 3 modes PHP-FPM

Comment calculer vos limites de processus (pm.max_children) ?

La mauvaise configuration de cette directive provoque l’erreur classique : [Server deadlocks / Gateway Timeout].

1. Calculez la mémoire RAM moyenne consommée par un seul de vos processus PHP. Exécutez :

   Bash

   ps -o rss -C php-fpm | tail -n +2 | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
   

   (Disons que le résultat est de 50 MB par processus).

2. Déterminez la RAM maximale que vous souhaitez allouer à PHP-FPM (ex: laissez au moins 1-2 GB pour le système, MySQL et Nginx). Sur un serveur de 8 GB, vous décidez d’allouer 5 GB à PHP.

3. Calculez pm.max_children : $5000 \text{ MB} / 50 \text{ MB} = 100$.

Exemple de configuration optimale (static pour production)

Modifiez le fichier de configuration de votre pool (ex: /etc/php/8.x/fpm/pool.d/www.conf) :

pm = static
pm.max_children = 100
pm.max_requests = 1000 # Évite les fuites de mémoire en recyclant les processus après 1000 requêtes

3. Comment analyser les logs système (journald, syslog, dmesg) pour identifier une panne matérielle ou système imminente ?

Attendre que votre serveur s’éteigne pour agir est une erreur critique. Le noyau Linux et le système d’exploitation envoient des signaux d’alerte bien avant la panne finale. Voici comment les traquer.

dmesg : Le journal du noyau (Kernel)

dmesg affiche les messages du tampon circulaire du noyau. C’est l’outil numéro un pour repérer les défaillances physiques directes.

• Vérifier les erreurs d’écriture disque / SATA :

  Bash

  dmesg | grep -Ei "ata|scsi|sd|sector|ext4|io error"
  

  Signe d’alerte : Des erreurs de type I/O error ou Buffer I/O error on dev sda indiquent que votre disque dur ou SSD est en train de rendre l’âme.

• Traquer l’instabilité de la mémoire RAM :

  Bash

  dmesg | grep -i "MCE"
  

  Signe d’alerte : Les erreurs MCE (Machine Check Exception) sont générées directement par le processeur lorsqu’il détecte une défaillance matérielle (souvent un problème de RAM ECC ou de surchauffe CPU).

journald et syslog : Les journaux du système

Avec systemd, journalctl centralise la majorité des logs.

• Lister uniquement les erreurs graves et critiques depuis le dernier démarrage :

  Bash

  journalctl -p 0..3 -b
  

  (Le paramètre -p 0..3 cible les niveaux Emergency, Alert, Critical et Error).

• Surveiller les kills par manque de mémoire (Out of Memory) :

  Si votre serveur s’arrête de répondre de façon aléatoire ou si vos services (comme MySQL) coupent tout seuls :

  Bash

  journalctl -ke | grep -i "oom-killer"
  

  L’OOM-Killer intervient pour tuer les processus gourmands lorsque la RAM est totalement saturée.

The post Comment configurer PHP-FPM pour maximiser les performances ? first appeared on DEMARCQ.NET.

Un goulot d’étranglement sur une base de données ralentit l’ensemble de votre pile applicative. Pour diagnostiquer efficacement l’origine de la lenteur (disque, CPU, verrouillage), suivez cette méthodologie d’analyse.

Étape 1 : Analyser l’utilisation des ressources système

Avant de plonger dans le moteur SQL, utilisez des outils système pour identifier la ressource saturée :

• htop ou top : Vérifiez si le processus mysqld ou postgres s’accapare l’intégralité du CPU.

• iotop ou iostat -xz 1 : Surveillez la valeur %util (utilisation du disque) et le temps d’attente d’écriture (await). Un disque saturé est le bottleneck le plus fréquent en base de données.

Étape 2 : Traquer les requêtes lentes (Slow Queries)

Identifiez les requêtes SQL mal indexées qui lisent des millions de lignes inutilement.

• Pour MySQL : Activez le Slow Query Log dans votre fichier /etc/mysql/my.cnf :

  Ini, TOML

  slow_query_log = 1
  slow_query_log_file = /var/log/mysql/mysql-slow.log
  long_query_time = 1.0 # Logge les requêtes de plus d'une seconde
  log_queries_not_using_indexes = 1
  

  Analysez ensuite ce fichier avec mysqldumpslow ou l’outil pt-query-digest (Percona Toolkit).

• Pour PostgreSQL : Utilisez l’extension incontournable pg_stat_statements. Ajoutez ceci dans postgresql.conf :

  Ini, TOML

  shared_preload_libraries = 'pg_stat_statements'
  

  Puis exécutez cette requête pour lister les requêtes les plus gourmandes en temps cumulé :

  SQL

  SELECT query, calls, total_exec_time, rows FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;
  

Étape 3 : Diagnostiquer les verrous (Locks)

Deux requêtes concurrentes qui s’attendent mutuellement peuvent paralyser votre base.

• MySQL : Visualisez l’état des verrous avec SHOW ENGINE INNODB STATUS; ou examinez la table information_schema.innodb_trx.

• PostgreSQL : Détectez les blocages actifs grâce à la table système pg_locks jointe à pg_stat_activity pour repérer quelle transaction bloque les autres.

The post Comment diagnostiquer un goulot d’étranglement sur une base de données first appeared on DEMARCQ.NET.

Lorsqu’un serveur dédié ralentit ou ne répond plus, chaque minute compte. Face à l’urgence, une méthodologie de diagnostic structurée permet de remonter rapidement à la source du problème, qu’il s’agisse d’une surcharge de ressources ou d’une erreur applicative. Voici le guide de secours pour identifier le goulot d’étranglement.
Étape 1 : Traquer les processus gourmands en temps réel

Le premier réflexe consiste à se connecter en SSH et à analyser l’état de la machine. Lancez la commande top ou, idéalement, htop (plus visuelle).

Regardez immédiatement la Load Average (charge moyenne) en haut à droite : si elle dépasse largement le nombre de cœurs de votre processeur, le serveur est saturé. Identifiez ensuite le coupable dans la liste : un processus PHP-FPM qui s’emballe ? Une requête MySQL mal optimisée qui bloque le CPU ? Un manque de mémoire RAM qui force le serveur à swapper ? htop vous donne la réponse en un coup d’œil.
Étape 2 : Analyser les journaux système (Syslog)

Si le serveur a planté ou si un service s’est arrêté brusquement (comme MySQL victime du Out Of Memory Killer), la mémoire vive a probablement saturé. Pour le vérifier, examinez les logs système généraux avec la commande suivante :
sudo tail -n 100 /var/log/syslog (ou /var/log/messages sur CentOS/RHEL). Vous y trouverez les alertes matérielles et les arrêts critiques de services.
Étape 3 : Inspecter les logs des serveurs web (Apache / Nginx)

La panne peut aussi être causée par une surcharge de trafic ou une attaque par déni de service (DDoS). Inspectez les fichiers de votre serveur web :

Les Access Logs (/var/log/nginx/access.log ou /var/log/apache2/access.log) : Un volume anormal de requêtes identiques provenant d’une même adresse IP indique souvent une attaque ou un bot malveillant à bannir.

Les Error Logs (/var/log/nginx/error.log) : Ils révèlent les scripts PHP défaillants, les ruptures de communication avec la base de données ou les problèmes de permissions de fichiers.

En combinant l’analyse des ressources matérielles et la lecture des logs, vous transformez une panne inexpliquée en un problème technique simple à résoudre.

The post Comment diagnostiquer une baisse de performance sur son serveur dédié ? first appeared on DEMARCQ.NET.

Incendie, cyberattaque par ransomware, panne matérielle majeure ou simple erreur humaine : le risque zéro n’existe pas en informatique. Face à un sinistre, la question n’est pas de savoir si vous allez être touché, mais quand vous le serez.

Le Plan de Reprise d’Activité (PRA) est la police d’assurance de votre infrastructure. Il regroupe l’ensemble des procédures techniques et organisationnelles permettant de reconstruire vos serveurs et de relancer vos services après un arrêt critique.

Voici les clés pour bâtir un PRA solide, centré sur le véritable moteur de la reprise : la stratégie de sauvegarde.

1. Définir les deux indicateurs stratégiques : RTO et RPO

Avant de parler technique, vous devez fixer le seuil de tolérance de votre entreprise à travers deux métriques fondamentales :

• Le RPO (Recovery Point Objective – Perte de données maximale admissible) : Quelle quantité de données pouvez-vous vous permettre de perdre ? Si votre dernière sauvegarde a 24 heures et que votre serveur crash, vous perdez une journée de travail. Pour des données critiques, le RPO doit souvent être réduit à quelques minutes.

• Le RTO (Recovery Time Objective – Durée maximale d’interruption admissible) : Combien de temps votre entreprise peut-elle rester à l’arrêt ? C’est le temps nécessaire pour restaurer vos systèmes et rouvrir les accès aux utilisateurs.

2. Le cœur du PRA : L’automatisation des sauvegardes

Compter sur une action humaine pour effectuer une sauvegarde est le meilleur moyen d’échouer le jour où le sinistre survient. L’oubli d’une clé USB ou le report d’une manipulation à un lendemain “plus calme” sont des classiques du crash informatique.

• L’automatisation élimine le facteur humain. Vos scripts (qu’il s’agisse de snapshots de machines virtuelles, de dumps de bases de données ou de synchronisations de fichiers) doivent s’exécuter à intervalles réguliers (toutes les heures, toutes les nuits) sans aucune intervention.

• Le monitoring des sauvegardes : Une sauvegarde automatisée qui échoue en arrière-plan sans prévenir est invisible… jusqu’au jour de la restauration. Vos outils de supervision (ou des rapports quotidiens par email/Slack) doivent valider le succès de chaque tâche.

3. L’externalisation : La règle d’or du 3-2-1

Sauvegarder vos serveurs sur un disque dur posé sur la même baie informatique ou dans la même pièce ne sert à rien si le bâtiment subit un incendie ou un dégât des eaux. De même, si un ransomware chiffre votre réseau, il infectera également vos sauvegardes locales si elles sont accessibles.

Pour sécuriser vos données, appliquez rigoureusement la stratégie de sauvegarde 3-2-1 :

• 3 copies de vos données au total (la production + 2 sauvegardes).

• 2 supports différents (par exemple : un stockage local NAS et un stockage Cloud).

• 1 copie externalisée, hors de votre infrastructure principale (Cloud sécurisé, deuxième centre de données géographiquement distant).

L’importance de l’immuabilité (Object Lock) : Pour contrer les rançongiciels les plus agressifs qui cherchent à détruire vos sauvegardes cloud, optez pour des stockages externalisés dits immuables. Une fois écrites, les données ne peuvent être ni modifiées ni supprimées pendant une période définie, même avec les identifiants administrateur.

4. Un PRA n’existe que s’il est testé

Le piège le plus courant est de rédiger un magnifique document de PRA, de configurer les sauvegardes, puis de refermer le dossier.

Une stratégie de sauvegarde n’est valide que si la procédure de restauration fonctionne. Un fichier de sauvegarde peut être corrompu, une clé de chiffrement peut être perdue, ou le temps de téléchargement depuis le cloud peut s’avérer beaucoup plus long que prévu (impactant directement votre RTO).

• Simulez des pannes : Organisez au moins une à deux fois par an un “exercice de crise”.

• Restaurer à blanc : Testez la reconstruction d’un serveur web ou d’une base de données sur un environnement isolé pour mesurer le temps réel de reprise et ajuster vos procédures.

En résumé : Le PRA n’est pas un projet informatique optionnel, c’est une stratégie de survie d’entreprise. Automatiser pour ne pas oublier, externaliser pour se protéger des sinistres physiques, et tester pour garantir l’efficacité : voilà le triptyque d’une infrastructure résiliente.

The post Plan de Reprise d’Activité (PRA) informatique first appeared on DEMARCQ.NET.

Chaque seconde de chargement supplémentaire sur un site web fait fuir vos visiteurs et dégrade votre référencement SEO. Pour un CMS dynamique comme WordPress, chaque affichage de page impose au serveur d’exécuter du code PHP et d’interroger la base de données MySQL. Face à un pic de trafic, ce processus sature rapidement les ressources. La solution ? Implémenter un système de cache côté serveur avec Redis ou Memcached.

L’impact du cache d’objets sur les performances

Le principe du cache en mémoire RAM (Object Cache) est simple : au lieu de reconstruire la page à chaque requête, le serveur stocke les résultats des requêtes de base de données les plus fréquentes dans la mémoire vive.

Lorsqu’un nouvel utilisateur visite le site, le serveur distribue instantanément les données pré-calculées depuis la RAM, dont la vitesse de lecture est infiniment supérieure à celle d’un disque dur (même NVMe). L’impact est immédiat : le temps de réponse du serveur (TTFB) s’effondre, la charge CPU diminue drastiquement et votre site peut supporter dix fois plus de connexions simultanées.

Redis vs Memcached : Lequel choisir ?

• Memcached est une solution historique, réputée pour sa simplicité et son efficacité brute sur les structures de données simples.

• Redis, plus moderne, est souvent privilégié aujourd’hui. Il offre des fonctionnalités avancées (persistance des données, réplication) et s’avère particulièrement redoutable pour booster l’infrastructure de sites e-commerce complexes.

Comment le mettre en place en 3 étapes ?

1. Activation sur le serveur : Installez le composant Redis ou Memcached depuis le panneau de contrôle de votre hébergement (cPanel, Plesk) ou via votre infogéreur.

2. Liaison PHP : Activez l’extension PHP correspondante (php-redis ou php-memcached) pour que votre environnement puisse communiquer avec le cache.

3. Configuration du CMS : Sur WordPress, installez une extension de performance de confiance (comme LiteSpeed Cache, W3 Total Cache ou Redis Object Cache) et renseignez les identifiants de connexion.

Mettre en place un cache de données est l’optimisation technique la plus rentable pour offrir une expérience utilisateur fluide et ultra-rapide.

The post Pourquoi et comment mettre en place un système de cache first appeared on DEMARCQ.NET.

Optimiser un serveur web pour absorber un trafic de masse ne consiste pas seulement à lui ajouter de la RAM ou du CPU. Il s’agit d’ajuster sa configuration pour qu’il gère les connexions simultanées sans gaspiller les ressources.

Voici les clés techniques de “tuning” pour Apache et Nginx afin de maximiser leurs performances.

1. Nginx : L’as des connexions simultanées

Nginx utilise une architecture événementielle (asynchrone), ce qui le rend naturellement très performant pour le trafic de masse. Voici les paramètres à modifier dans /etc/nginx/nginx.conf :

Ajuster les Workers (Processus)

• worker_processes auto; : Permet à Nginx de créer un processus par cœur de processeur disponible.

• worker_connections 1024; (ou plus, ex: 4096) : C’est le nombre maximum de connexions simultanées que chaque worker peut gérer.

  Calcul de la capacité max : worker_processes $\times$ worker_connections = Nombre max de clients simultanés.

Optimiser la gestion des fichiers et connexions

events {
    worker_connections 4096;
    use epoll; # Optimisation spécifique à Linux pour gérer efficacement les connexions
    multi_accept on; # Demande aux workers d'accepter toutes les nouvelles connexions d'un coup
}

http {
    sendfile on; # Accélère l'envoi des fichiers en évitant la copie de données en mémoire tampon
    tcp_nopush on; # Envoie les en-têtes HTTP en un seul paquet (idéal pour la bande passante)
    tcp_nodelay on; # Force l'envoi immédiat des données (réduit la latence des petits paquets)
    
    keepalive_timeout 30; # Réduit le temps d'attente des connexions inactives pour libérer les slots
    keepalive_requests 500; # Nombre de requêtes autorisées par connexion persistante
}

2. Apache : Le passage obligatoire à MPM Event

Si vous utilisez encore le vieux module Prefork d’Apache, votre serveur s’effondrera sous le trafic de masse car il crée un processus lourd par utilisateur. Pour le trafic de masse, vous devez utiliser le module MPM Event (généralement couplé à PHP-FPM).

Modifiez le fichier de configuration du module (ex: /etc/apache2/mods-enabled/mpm_event.conf) :

<IfModule mpm_event_module>
    StartServers             4
    MinSpareThreads          25
    MaxSpareThreads          75
    ThreadLimit              64
    ThreadsPerChild          25
    MaxRequestWorkers        1000  # Le paramètre CRITIQUE (anciennement MaxClients)
    MaxConnectionsPerChild   5000  # Relance les processus après X requêtes pour éviter les fuites de mémoire
</IfModule>

• MaxRequestWorkers : C’est la limite absolue de requêtes simultanées traitées.

  Attention au calcul : Assurez-vous que votre RAM peut supporter ce nombre. Si un processus Apache consomme 50 Mo et que vous fixez MaxRequestWorkers à 1000, Apache peut consommer jusqu’à 50 Go de RAM en pic de trafic.

3. Techniques globales indispensables (Valables pour les deux)

Le Keep-Alive : Trouver le bon équilibre

Le Keep-Alive permet de maintenir la connexion ouverte entre le serveur et le navigateur pour charger plusieurs fichiers (images, CSS, JS) sans rouvrir une connexion à chaque fois.

• Trafic modéré : Activez-le (KeepAlive On ou keepalive_timeout 65).

• Trafic de masse extrême : Réduisez le timeout à 2 ou 5 secondes, ou désactivez-le si vous utilisez un CDN en amont. Cela libère instantanément les ressources pour les nouveaux visiteurs.

Activer la compression Gzip / Brotli

Compresser le texte (HTML, CSS, JS) avant de l’envoyer réduit drastiquement l’utilisation de la bande passante et accélère le temps de réponse (TTFB).

# Exemple Nginx
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml;
gzip_comp_level 5; # Bon compromis entre réduction de taille et utilisation du CPU

Le Tuning Système (OS) au niveau de Linux

Souvent négligé, le système d’exploitation Linux limite par défaut le nombre de fichiers qu’un processus peut ouvrir simultanément (généralement 1024). Pour un trafic de masse, chaque connexion est un fichier ouvert.

Modifiez /etc/security/limits.conf pour augmenter les limites de l’utilisateur de votre serveur web (www-data ou nginx) :

www-data soft nofile 65536
www-data hard nofile 65536

Règle d’or : Après chaque modification, testez toujours la configuration (nginx -t ou apachectl configtest) avant de redémarrer le service, et validez la tenue de charge avec un outil de stress-test comme ApacheBench (ab) ou k6.

The post Comment optimiser la configuration de votre serveur web (Apache / Nginx) pour le trafic de masse ? first appeared on DEMARCQ.NET.

Étape 1 : Anticiper en réduisant le TTL des DNS

C’est le secret d’une bascule réussie. Quelques jours avant l’opération, connectez-vous chez votre registraire de domaine et abaissez le TTL (Time To Live) de votre zone DNS à une valeur minimale (par exemple, 300 secondes). Cela force les fournisseurs d’accès à mettre à jour l’adresse de votre site toutes les 5 minutes au lieu de toutes les 24 heures, garantissant une propagation ultra-rapide le jour J.

Étape 2 : Préparer le nouveau serveur et synchroniser les données

Déployez l’environnement technique sur le nouveau serveur (fichiers, bases de données, certificats SSL). Testez le site en local via votre fichier hosts pour valider que tout fonctionne. Une fois prêt, effectuez une première synchronisation des données. Juste avant la bascule DNS, passez temporairement le site d’origine en mode maintenance pour figer les données (commandes, commentaires), puis réalisez une synchronisation finale (via rsync pour les fichiers et un export de la base de données).

Étape 3 : Modifier le pointage DNS et observer la bascule

Modifiez l’adresse IP de vos enregistrements A (et AAAA) pour pointer vers le nouveau serveur. Grâce au TTL réduit précédemment, les visiteurs vont basculer de manière invisible et progressive vers la nouvelle infrastructure informatique.

Étape 4 : Le nettoyage après migration

Une fois la propagation DNS totalement finalisée partout dans le monde (comptez 24 à 48 heures par sécurité), vous pourrez remonter le TTL à sa valeur d’origine (86400 secondes) et résilier sereinement votre ancien abonnement. Une migration sans coupure ne s’improvise pas, elle se planifie !

The post Migrer son site web vers un nouveau serveur sans coupure first appeared on DEMARCQ.NET.