La sauvegarde, avant tout le reste
Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde : c'est un fichier dont on espère quelque chose. Le seul contrôle qui vaut consiste à restaurer la copie dans une base vide et à comparer le nombre de lignes, table par table.
Tant que cette restauration n'a pas été faite une fois, considérez que vous n'avez pas de sauvegarde. La question n'est pas théorique : elle se pose le jour où quelqu'un supprime une donnée sans le vouloir, et ce jour-là il est trop tard pour découvrir que l'archive était vide.
- Une sauvegarde automatique tourne, à une fréquence qui correspond à ce que vous acceptez de perdre.
- Une restauration complète a été effectuée au moins une fois, et le nombre de lignes a été comparé.
- Les archives sont conservées ailleurs que sur le serveur qu'elles sauvegardent.
- Quelqu'un est prévenu si une sauvegarde échoue — sans alerte, l'échec passe inaperçu pendant des mois.
Les secrets
Un mot de passe ou une clé d'API qui entre une fois dans un dépôt de code y reste, même effacé au commit suivant : l'historique le conserve. Le retirer suppose de réécrire cet historique, ce qui casse le travail de tout le monde.
Le contrôle à faire avant la mise en ligne est simple : chercher dans l'historique complet, pas seulement dans les fichiers actuels. Et changer toute clé qui s'y trouve, plutôt que d'espérer que personne ne l'a vue.
- Aucun secret dans le dépôt, historique compris — les fichiers de sauvegarde d'éditeur (« .env.bak ») sont le piège classique.
- Les clés d'accès au dépôt sont en lecture seule si elles servent seulement à déployer.
- Les mots de passe créés pendant l'installation ont été changés, et les fichiers qui les contenaient supprimés.
- Les secrets sont saisis masqués, jamais passés en argument de commande : la liste des processus est lisible par d'autres comptes.
Ce qui se vérifie en une minute et se paie cher
Ces points ne demandent aucun outil particulier. Ils sont pourtant les plus fréquemment oubliés, parce qu'ils ne provoquent aucune erreur visible : le site fonctionne, simplement il ne fait pas ce qu'on croit.
- Le certificat est valide et se renouvelle tout seul — vérifiez la date d'expiration, pas seulement le cadenas.
- Le site répond aussi bien avec « www » que sans, et l'un redirige vers l'autre.
- Le fichier robots.txt n'interdit pas l'indexation. Une consigne de préproduction oubliée rend le site invisible sans rien casser.
- Les pages ont un titre et une description distincts les uns des autres.
- Un formulaire envoyé arrive réellement : testez-le depuis une adresse extérieure à l'organisation.
- Les messages d'erreur ne montrent ni chemin de fichier ni trace technique au visiteur.
- La page 404 existe et permet de repartir ailleurs.
Accessibilité
Les outils automatiques détectent une partie des problèmes — contrastes insuffisants, images sans description, champs sans étiquette — et c'est déjà beaucoup. Ils ne détectent pas si l'ordre de lecture a du sens, ni si un formulaire reste utilisable au clavier seul.
Le contrôle qui rapporte le plus, et qui ne coûte rien : parcourir le site entier à la touche de tabulation, sans souris. Si vous ne voyez pas où vous êtes, ou si vous restez bloqué dans un menu, un utilisateur au clavier le sera aussi.
Une déclaration de conformité, elle, suppose un audit humain. La produire sur la seule foi d'un outil automatique revient à déclarer ce qu'on n'a pas vérifié.
Savoir que quelque chose ne va pas
La plupart des pannes ne sont pas détectées par celui qui exploite le site, mais signalées par un client — souvent des heures plus tard, parfois jamais, la personne étant simplement partie ailleurs.
Une sonde qui interroge une adresse toutes les quelques minutes et prévient en cas d'échec règle l'essentiel du problème. Ce n'est pas un dispositif coûteux, et c'est la différence entre découvrir une interruption soi-même et l'apprendre.