Déployer, configurer et surveiller

Une application qui fonctionne sur votre machine ne fonctionne nulle part ailleurs. C'est la phrase la plus banale du métier, et elle reste vraie : entre le développement et la production, presque tout change — la configuration, les données, la charge, et la façon dont vous apprenez qu'une chose a cassé.

La configuration : la frontière à ne jamais franchir

La règle est absolue : aucun secret ne figure jamais dans le code source.

Pas dans un fichier de configuration versionné, pas dans une constante, pas dans un commentaire, pas dans le code du navigateur. Une clé publiée dans un dépôt, même privé, même effacée ensuite, doit être considérée comme compromise : l'historique la conserve, et les dépôts sont analysés en continu par des robots.

Ce qui sépare une configuration saine :

Les variables d'environnement sont lues au démarrage, fournies par l'hébergeur, et jamais écrites dans le dépôt.

Le fichier d'exemple — souvent nommé avec un suffixe explicite — est versionné et contient les noms des variables attendues, jamais leurs valeurs.

La distinction entre public et privé. Certains cadres applicatifs exposent au navigateur les variables portant un préfixe convenu. Tout ce qui ne porte pas ce préfixe reste côté serveur. Confondre les deux est la faute la plus fréquente, et la plus coûteuse : une clé secrète préfixée « public » se retrouve dans le code téléchargé par chaque visiteur.

La vérification au démarrage. Une application qui démarre sans sa configuration et échoue à la première requête est plus difficile à diagnostiquer qu'une application qui refuse de démarrer en nommant la variable manquante.

Ce qui change entre les deux environnements

Deux conséquences pratiques.

La latence rend visibles les requêtes en cascade. Cent requêtes successives sur une base locale sont instantanées ; les mêmes vers une base distante prennent plusieurs secondes. C'est le problème classique où une boucle interroge la base une fois par élément affiché.

Les messages d'erreur ne doivent jamais fuiter. Une trace d'exécution affichée à l'utilisateur révèle la structure du code, parfois le schéma de la base, et facilite une attaque. En production : un message générique pour l'utilisateur, le détail complet dans les journaux du serveur.

Les migrations de base de données

Le schéma évolue, et il évolue sur une base qui contient des données réelles.

Chaque changement passe par une migration versionnée, appliquée dans le même ordre partout. Modifier la base à la main en production est la façon la plus sûre de la rendre différente de ce que le code attend.

Les changements destructifs se font en plusieurs étapes. Supprimer une colonne encore lue par le code en cours d'exécution provoque une panne pendant le déploiement. La séquence sûre : ajouter la nouvelle colonne, écrire dans les deux, migrer les données, basculer la lecture, puis seulement supprimer l'ancienne.

Sauvegardez avant, et vérifiez que la sauvegarde se restaure. Une sauvegarde jamais testée n'est pas une sauvegarde : c'est une hypothèse.

Surveiller : savoir avant l'utilisateur

Une application sans surveillance ne vous apprend ses pannes que par un message d'un client — c'est-à-dire tard, et par le pire canal.

Le minimum utile, dans l'ordre d'installation :

1. Des journaux structurés. Des lignes lisibles par un humain et filtrables par machine, avec un identifiant de requête pour relier les événements d'un même parcours. Et jamais de secret, de mot de passe ni de jeton dans un journal.
2. Un rapport d'erreurs qui regroupe les exceptions, indique leur fréquence et conserve le contexte. Vingt occurrences d'une même erreur doivent apparaître comme un problème, pas comme vingt lignes noyées.
3. Une vérification d'état : une adresse qui répond « tout va bien » seulement si la base répond aussi. Une application qui démarre sans base est en ligne sans être fonctionnelle.
4. Une alerte, sur les erreurs répétées et sur l'indisponibilité.

Déployer sans couper le service

Revenez en arrière plutôt que de corriger dans l'urgence. Le retour à la version précédente doit être une opération d'une commande, connue et déjà répétée. Un correctif écrit sous pression en produit généralement un autre.

Séparez le déploiement de l'activation. Une fonctionnalité livrée mais désactivée par un interrupteur se met en service sans nouveau déploiement, et se retire aussi vite en cas de problème.

Ne déployez pas un vendredi soir sans raison impérieuse. Ce n'est pas une superstition : c'est le moment où le moins de monde est disponible pour réagir.

À retenir

• Aucun secret dans le code, jamais. Un secret publié est un secret compromis.
• Fichier d'exemple versionné : les noms, pas les valeurs.
• Attention au préfixe qui expose une variable au navigateur.
• Refusez de démarrer sans configuration, plutôt que d'échouer plus tard.
• Message générique à l'utilisateur, détail complet dans les journaux.
• Migrations versionnées ; les suppressions se font en plusieurs étapes.
• Une sauvegarde non testée n'est pas une sauvegarde.
• Le retour arrière doit être plus rapide que le correctif.