Ingénierie défensive : des systèmes robustes

Un ingénieur junior d'une entreprise fintech de taille moyenne a lancé un script de migration de base de données un vendredi après-midi. Le script était censé nettoyer les enregistrements orphelins dans un environnement de staging. À la place, il s'est connecté à la base de production et a supprimé 4,2 millions d'enregistrements de transactions clients. La sauvegarde ? Vieille de trois jours. L'entreprise a passé les 72 heures suivantes en gestion de crise complète, à reconstituer manuellement les données à partir des journaux du prestataire de paiement. Le coût total dépassait les 400 000 $ entre le temps d'ingénierie, les avoirs clients et les déclarations réglementaires.

Le script n'avait aucune vérification d'environnement. Pas de mode dry-run. Aucune demande de confirmation indiquant quelle base il ciblait. La chaîne de connexion venait d'une variable d'environnement qui pointait par hasard sur la production sur le portable de l'ingénieur, suite à une session de débogage deux semaines plus tôt. Chacune de ces défaillances était évitable.

Pourquoi les dialogues « Êtes-vous sûr ? » ne fonctionnent pas

Le mécanisme de sécurité le plus courant en logiciel est la boîte de dialogue de confirmation. C'est aussi le plus inutile. Des études sur la fatigue de confirmation montrent que les utilisateurs cliquent sur les invites « Êtes-vous sûr ? » presque systématiquement après les avoir rencontrées plus de quelques fois. L'invite devient invisible : un simple clic de plus sur le chemin de ce que vous aviez déjà décidé de faire.

Le problème n'est pas que les confirmations soient une mauvaise idée. C'est que les confirmations génériques ne transmettent aucune information. « Voulez-vous vraiment continuer ? » ne vous dit rien sur ce que vous êtes sur le point de faire. Comparez avec : « Vous allez supprimer 4 217 893 lignes de la table transactions dans prod-us-east-1. Saisissez le nom de la base de données pour confirmer. » La seconde version vous oblige à lire réellement ce qui se passe. C'est la différence entre un ralentisseur et une molly guard.

Qu'est-ce qu'une molly guard et pourquoi c'est important

L'expression « molly guard » vient d'un capot en plastique posé sur le gros bouton rouge des mainframes pour éviter les arrêts accidentels. Le nom ferait référence à la fille d'un programmeur, Molly, qui aurait pris l'habitude d'appuyer dessus. En logiciel, une molly guard est tout mécanisme qui rend les actions destructrices difficiles à déclencher par accident tout en les laissant possibles quand on les veut vraiment.

Le paquet Linux molly-guard fait exactement cela. Il intercepte les commandes shutdown, reboot et halt sur les sessions SSH et vous demande de saisir le nom d'hôte de la machine que vous êtes sur le point d'arrêter. Impossible de passer en pilote automatique : vous devez prouver que vous savez sur quelle machine vous êtes.

$ sudo reboot
Good grief! You're on a remote SSH session to prod-web-03.
Please type the hostname to confirm: prod-web-03
# Compare with the useless version:
$ sudo reboot
Are you sure? (y/n): y
# *types y without reading, muscle memory*

Le principe est simple : la confirmation doit exiger une information qui prouve que l'opérateur comprend l'action. Taper « y » ne prouve rien. Taper le nom d'hôte, le nom de la table ou le nombre d'enregistrements concernés prouve que vous avez lu l'avertissement.

Modes dry-run : vérifier avant de tirer

Toute opération destructrice devrait avoir un mode dry-run. Pas « devrait » au sens de bonne pratique, mais « devrait » au sens où vous finirez par regretter de ne pas en avoir un. Un dry run exécute toute la logique d'une opération, journalise exactement ce qui se passerait, puis s'arrête. Aucun effet de bord. Visibilité totale.

Le schéma est facile à mettre en place. Voici un script de migration avec un dry-run intégré :

#!/bin/bash
set -euo pipefail
DRY_RUN=${DRY_RUN:-true}  # Default to dry-run!
DB_HOST=$(get_db_host)
DB_NAME=$(get_db_name)
echo "Target: $DB_HOST / $DB_NAME"
echo "Mode: $([ "$DRY_RUN" = true ] && echo 'DRY RUN' || echo 'LIVE')"
ROWS=$(psql -h "$DB_HOST" -d "$DB_NAME" -t -c \
"SELECT count(*) FROM orphaned_records WHERE created_at < now() - interval '90 days'")
echo "Records to delete: $ROWS"
if [ "$DRY_RUN" = true ]; then
echo "Dry run complete. Set DRY_RUN=false to execute."
exit 0
fi
# Require explicit confirmation for live runs
read -p "Type '$DB_NAME' to confirm deletion: " CONFIRM
if [ "$CONFIRM" != "$DB_NAME" ]; then
echo "Aborted."
exit 1
fi
psql -h "$DB_HOST" -d "$DB_NAME" -c \
"DELETE FROM orphaned_records WHERE created_at < now() - interval '90 days'"
echo "Deleted $ROWS records."

Remarquez trois choses : par défaut, on est en dry-run (il faut choisir d'activer la destruction, et non la désactiver), le script affiche la base cible et le nombre de lignes avant toute action, et même en mode réel il exige de saisir le nom de la base. Trois niveaux de défense. N'importe lequel d'entre eux aurait suffi à éviter l'incident décrit au début.

Filets de sécurité pour les migrations de base de données

Les migrations de base de données font partie des opérations les plus risquées de tout pipeline de déploiement. Elles sont souvent irréversibles, s'exécutent sur un état partagé, et une mauvaise migration peut faire tomber toute votre application. Pourtant, la plupart des équipes les traitent comme une étape de déploiement comme une autre.

Voici une hiérarchie des mécanismes de sécurité, du plus basique au plus solide :

1. Vérifications d'environnement — Le script de migration vérifie qu'il cible bien l'environnement prévu avant d'exécuter quoi que ce soit. Ça semble évident. Vous seriez surpris de voir à quelle fréquence c'est absent.
2. Snapshots avant migration — Créer automatiquement un snapshot de la base avant chaque migration. Si la migration échoue ou pose problème, vous pouvez restaurer en quelques minutes, et non en quelques heures.
3. Garde-fous sur le nombre de lignes — Si une migration affecte plus de N lignes, exiger une confirmation explicite. Une migration qui touche soudainement des millions de lignes est presque toujours un bug.
4. Timeouts de requête — Définir des timeouts agressifs sur les requêtes de migration. Une migration qui tourne pendant 45 minutes verrouille des tables et dégrade les performances. Échouer vite.
5. Compatibilité ascendante uniquement — Imposer que chaque migration soit compatible avec le code actuellement déployé. Cela signifie pas de renommage de colonnes, pas d'ajout de NOT NULL sans valeur par défaut, pas de suppression de colonnes encore référencées.

# Rails example using strong_migrations gem
class AddPhoneToUsers < ActiveRecord::Migration[7.1]
def change
# This will raise an error with a safe alternative:
# add_column :users, :phone, :string, null: false
#
# Instead, do it in two steps:
add_column :users, :phone, :string
# Then in a separate migration after backfill:
# change_column_null :users, :phone, false
end
end

Des outils comme strong_migrations pour Rails, squawk pour PostgreSQL et skeema pour MySQL détectent les schémas dangereux avant qu'ils n'atteignent la production. Si vous n'utilisez rien de tel, vous comptez sur la revue de code pour attraper des problèmes de migration subtils, et les relecteurs passent parfois à côté.

Suppressions logiques et fenêtres d'annulation

Les suppressions définitives sont un engagement permanent pris à un moment de certitude. Le problème, c'est que cette certitude est souvent fausse. Les suppressions logiques, qui consistent à marquer des enregistrements comme supprimés sans les retirer réellement, vous laissent une fenêtre pour rattraper les erreurs.

-- Hard delete: gone forever
DELETE FROM projects WHERE id = 4872;
-- Soft delete: recoverable
UPDATE projects
SET deleted_at = now(),
deleted_by = 'user:priya'
WHERE id = 4872;
-- Recovery is trivial
UPDATE projects
SET deleted_at = NULL,
deleted_by = NULL
WHERE id = 4872;

Le compromis est réel : les suppressions logiques compliquent les requêtes (il faut un WHERE deleted_at IS NULL partout), augmentent le stockage et peuvent créer de la confusion sur l'état réel des données. Mais pour toute donnée utilisateur où une suppression accidentelle est possible, le jeu en vaut la chandelle. GitHub ne supprime pas réellement votre dépôt avant 90 jours. Slack conserve les messages supprimés pour des raisons de conformité. La corbeille de Gmail se vide après 30 jours. Ce ne sont pas des accidents : ce sont des choix d'ingénierie délibérés.

Le même principe s'applique à l'infrastructure. Au lieu de terminer une instance EC2, arrêtez-la d'abord. Au lieu de supprimer une base, renommez-la en mydb_deleted_20260315 et créez un rappel dans votre agenda pour la supprimer réellement deux semaines plus tard. Le coût de garder une instance arrêtée ou une base renommée pendant quelques jours est négligeable comparé au coût d'une restauration depuis une sauvegarde.

Sécurité des déploiements : canaris, disjoncteurs et rollbacks

Les déploiements constituent une autre catégorie d'actions destructrices que la plupart des équipes ne traitent pas avec assez de prudence. Un mauvais déploiement peut mettre la production à genoux tout aussi efficacement qu'une base supprimée, et il arrive beaucoup plus souvent.

La configuration minimale viable de sécurité pour les déploiements comprend :

• Déploiements canaris — Envoyer 1 à 5 % du trafic vers la nouvelle version. Si le taux d'erreur grimpe, revenir automatiquement en arrière avant que le rayon d'impact ne s'élargisse.
• Déclencheurs de rollback automatique — Définir des seuils de taux d'erreur, de latence et d'échecs de health check qui déclenchent un retour en arrière automatique. Ne comptez pas sur un humain qui remarquera le problème à 2 h du matin.
• Gel des déploiements pendant les incidents — S'il y a un incident en cours, bloquer tous les déploiements. La dernière chose dont vous avez besoin pendant qu'on éteint un incendie, c'est que quelqu'un déploie des changements sans rapport.
• Rollback en un clic — Revenir en arrière doit être plus simple qu'avancer. Si votre procédure de rollback implique de se connecter en SSH sur les serveurs et de lancer des commandes manuellement, ce n'est pas une procédure de rollback.

# Kubernetes progressive delivery with Argo Rollouts
apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
strategy:
canary:
steps:
- setWeight: 5
- pause: { duration: 5m }
- analysis:
templates:
- templateName: error-rate-check
- setWeight: 25
- pause: { duration: 5m }
- setWeight: 50
- pause: { duration: 10m }
- setWeight: 100
# Auto-rollback if error rate exceeds 1%
abortScaleDownDelaySeconds: 30

Le principe ici est l'engagement progressif. On ne passe pas de 0 à 100 % d'un coup. On fait de petits pas, on vérifie chacun d'eux et on garde la possibilité de reculer à chaque étape. C'est plus lent que de déployer en yolo sur toutes les instances à la fois, mais la première fois qu'il attrapera un mauvais déploiement avant qu'il n'atteigne tous vos utilisateurs, vous serez reconnaissant de chaque minute supplémentaire.

Prévention architecturale : rendre la mauvaise action impossible

Les meilleurs mécanismes de sécurité ne vous demandent pas d'être prudent. Ils rendent structurellement impossible de faire la mauvaise chose. C'est la différence entre un garde-corps et un panneau d'avertissement.

• Infrastructure immuable — Si vous ne pouvez pas vous connecter en SSH aux serveurs de production, vous ne pouvez pas y exécuter de commandes par accident. Si les déploiements créent toujours de nouvelles instances à partir d'une image connue, la dérive de configuration devient impossible.
• Accès au moindre privilège — Les ingénieurs ne devraient pas avoir d'identifiants de base de production sur leur portable. Point final. Utilisez des outils d'accès juste-à-temps qui accordent des identifiants temporaires avec traçabilité.
• Identifiants séparés par environnement — Si staging et production utilisent des magasins d'identifiants différents, vous ne pouvez littéralement pas vous connecter à la production par accident avec les outils de staging.
• Protection contre la suppression — AWS permet d'activer la protection contre la résiliation sur les instances EC2 et la protection contre la suppression sur les bases RDS. Activez-les pour tout ce qui compte. C'est une modification de configuration de cinq secondes qui élimine toute une classe d'erreurs catastrophiques.

Si quelqu'un peut détruire la production par accident avec une seule commande, le problème n'est pas la personne, c'est le système qui a permis qu'une seule commande détruise la production.

J'ai vu des équipes réagir à des incidents de production en ajoutant plus de documentation, plus de checklists, plus de formations. Ces mesures aident, mais elles reposent toutes sur l'hypothèse que les humains sont parfaits. Or ils ne le sont pas. La meilleure réponse consiste à modifier le système pour que l'erreur ne puisse pas se produire, ou, si elle se produit, à limiter son rayon d'impact et à accélérer la reprise.

Construire une culture d'ingénierie axée sur la sécurité

Les outils et l'architecture comptent, mais c'est la culture qui détermine s'ils seront réellement mis en place. Les équipes qui considèrent les mécanismes de sécurité comme une surcharge ou de la bureaucratie les sauteront sous la pression des délais, et la pression des délais, elle, est permanente.

Le modèle le plus efficace que j'ai vu consiste à traiter les mécanismes de sécurité comme une exigence d'ingénierie de premier plan, et non comme un bonus. Chaque opération destructrice fait l'objet d'une revue de conception qui pose explicitement les questions suivantes : que se passe-t-il si elle s'exécute sur la mauvaise cible ? Que se passe-t-il si elle est lancée deux fois ? Que se passe-t-il avec des données périmées ? Comment l'annuler ?

Les post-mortems sans recherche de coupable sont désormais la base. Mais la pratique moins courante, et à mon avis plus importante, est le pre-mortem. Avant de lancer un changement risqué, réunissez l'équipe et demandez : « Imaginez que tout a très mal tourné. Que s'est-il passé ? » Les gens sont étonnamment doués pour identifier les modes de défaillance quand on les invite à imaginer plutôt qu'à prédire. Les défaillances qu'ils identifient deviennent les mécanismes de sécurité que vous construisez.

Ce jeune ingénieur qui a supprimé la base de production ? Il est toujours dans l'entreprise. Il est aujourd'hui l'un des plus fervents défenseurs de l'ingénierie défensive dans l'équipe. L'incident n'était pas sa faute : c'était une défaillance du système. Et ce système est aujourd'hui bien plus difficile à faire tomber.