Durcissement
Le travail que l'IA n'ajoute que si on le lui demande.
L'IA génère le chemin heureux. Elle ne génère presque jamais le chemin production : la rotation des secrets, le budget de timeouts, la clé d'idempotence, le dashboard, le runbook. Les ingénieurs seniors ajoutent ce travail par défaut, parce qu'ils ont été la personne réveillée à 3h du matin quand il manquait.
La boucle du stagiaire
Un junior fait la démo d'une fonctionnalité qui 'marche'. Elle marche en dev. En production : le secret est dans le repo, l'API n'a pas de timeout, les retries amplifient une panne en aval en auto-DDoS, et aucune ligne de log n'explique pourquoi le client #4127 a vu une erreur. La fonctionnalité est désormais un passif que l'équipe doit surveiller.
Par défaut, pas par héroïsme
Chaque fonctionnalité livrée passe une checklist de durcissement avant merge : les secrets au bon endroit, les catégories du passées en revue, des timeouts et retries avec budgets explicites, de l'idempotence sur tout ce qui mute, des logs structurés à chaque frontière, un tracker d'erreurs branché, une ligne dans le runbook. Rien d'héroïque. C'est le défaut qu'un ingénieur senior appliquerait avec ou sans IA dans la boucle.
Une réponse à 3h du matin
Quand quelque chose casse à 3h du matin, l'astreinte peut répondre 'quoi' et 'où' sans escalader. Quand rien ne casse, le système peut prouver que rien n'a cassé, traces à l'appui. Quand la charge fait ×10, l'équipe ne rattrape pas le retard. Elle livre.
- 01Quelqu'un déroule-t-il vraiment cette liste avant merge, ou vit-elle sur une page wiki que personne n'ouvre ?
- 02L'astreinte peut-elle répondre 'quoi' et 'où' à 3h du matin sans escalader ?
- 03Les secrets sont-ils dans un vrai coffre, ou dans des fichiers env commités par accident ?
- 04Combien de commentaires TODO dans votre codebase parlent de timeouts, de logs ou de gestion d'erreurs, et quel âge ont-ils ?