La version originelle de notre check-list de mise en production serveur comptait six points, rédigée un peu vite après un premier client mal préparé. Trois ans et plusieurs incidents plus tard, elle en compte dix-neuf, chacun ajouté après un oubli réel qui a coûté du temps, parfois de l’argent, toujours de la crédibilité auprès d’un client.
Cette check-list est distincte de la check-list de mise en production applicative déjà couverte côté outils de notre blog, qui traite du site lui-même. Celle-ci concerne exclusivement la préparation de l’infrastructure serveur avant l’arrivée d’un nouveau client, point par point, dans l’ordre où elle est effectivement suivie.
Les points hérités des premiers incidents
Les six premiers points de la version originelle couvraient l’essentiel apparent : création du compte d’hébergement, configuration du bloc serveur Nginx, installation de WordPress, configuration DNS de base, activation du certificat TLS, et création des accès FTP pour l’équipe. Chacun de ces points reste dans la version actuelle, mais ne suffisait déjà plus après les deux premiers mois d’utilisation de la liste.
Le septième point, ajouté après un incident précis, vérifie explicitement la configuration des limites PHP (upload_max_filesize, post_max_size, memory_limit) avant même l’installation du site, un réglage qui semblait couvert par les valeurs par défaut de l’hébergeur jusqu’à ce qu’un client avec un import massif de médias bute dessus dès sa première semaine d’utilisation.
Sécurité et accès, la section la plus étoffée
- Créer un utilisateur MySQL dédié avec des droits restreints à la seule base du site, jamais un compte partagé.
- Vérifier que les identifiants par défaut de l’hébergeur (souvent un compte administrateur générique) sont désactivés ou renommés.
- Configurer une authentification par clé SSH plutôt que par mot de passe pour tout accès en ligne de commande.
- Restreindre l’accès à
wp-adminpar IP quand la nature du client le permet, ou à défaut activer une authentification à deux facteurs. - Vérifier que les fichiers de sauvegarde ne sont pas accessibles publiquement via une URL directe.
- Contrôler les permissions de fichiers (jamais de
777sur les répertoires du site).
Supervision et sauvegardes, les points ajoutés après coup
Ces points n’existaient pas dans la version originelle de la liste, ajoutés après qu’un site soit resté en panne plusieurs heures sans qu’aucune alerte ne remonte, faute de supervision configurée avant la mise en ligne effective plutôt qu’après.
- Ajouter le nouveau site à l’outil de supervision de disponibilité avant toute annonce de mise en ligne au client.
- Configurer une sauvegarde automatique quotidienne, avec vérification explicite qu’elle s’exécute correctement dès la première nuit suivant la mise en production.
- Documenter l’emplacement et la méthode de restauration des sauvegardes dans la fiche technique interne du client.
- Vérifier que les journaux d’erreurs PHP sont bien écrits dans un fichier accessible, pas silencieusement ignorés par une configuration par défaut.
Les points qui semblent redondants mais ne le sont pas
Certains points de la liste vérifient des éléments théoriquement déjà garantis par l’hébergeur, comme la validité du certificat TLS ou la configuration correcte des enregistrements SPF et DKIM pour la messagerie du site. Nous les vérifions pourtant systématiquement nous-mêmes, indépendamment des garanties affichées par l’hébergeur, après avoir constaté sur plusieurs dossiers que l’automatisation annoncée par l’hébergeur avait échoué silencieusement sans notification visible.
Faire confiance à un hébergeur pour la configuration de base ne dispense jamais de vérifier soi-même que cette configuration a bien été appliquée. La confiance ne remplace pas le contrôle, elle le complète.
Une check-list volontairement manuelle
Nous avons envisagé d’automatiser entièrement cette check-list via un script de provisioning exécutant chaque vérification automatiquement. Le choix final a été de conserver une bonne partie des points en vérification manuelle, cochés explicitement par la personne en charge de la mise en production, précisément parce qu’une automatisation silencieuse peut elle-même échouer sans que personne ne s’en aperçoive — le même problème que celui qui a motivé l’ajout de plusieurs points de cette liste à l’origine.
Ce que cette liste nous a réellement apporté
Depuis l’adoption de la version complète à dix-neuf points, aucun incident de mise en production n’est directement imputable à un oubli couvert par la liste. Les incidents survenus depuis relèvent tous de causes non anticipées, ce qui, paradoxalement, valide l’utilité de la liste : elle ne prétend jamais tout couvrir, seulement ce qui a déjà causé un problème une première fois.
