L’automatisation : ce qu’elle cache vraiment quand on néglige l’amont

Vous recevez à 3 h du matin un mail qui vous propose de corriger votre DMARC. Le ton est sûr, les détails techniques sont justes. Pourtant, la configuration n’a rien à corriger : elle a été laissée volontairement à p=none dans le cadre d’un déploiement progressif géré par Terraform.

Ce genre de sollicitation révèle un problème plus large. Les systèmes automatisés font ce qu’on leur demande, mais ils ne vérifient jamais si la demande avait un sens.

Une recherche superficielle

L’outil qui a repéré votre domaine a fait le minimum : il a lu la politique DMARC et a lancé une campagne. Il n’a pas consulté l’historique des changements ni les notes qui expliquaient le choix de p=none. Le résultat est une alerte inutile et un temps perdu.

Le même schéma se répète ailleurs : bases de données obsolètes, listes de prospects jamais mises à jour, scripts qui envoient des messages à des cibles qui n’existent plus. La partie bon marché — envoyer — passe avant la partie coûteuse — vérifier.

Même logique du côté de l’infrastructure

Quand un pipeline CI/CD déploie du code sur un simple tag, il applique la même règle : il exécute la consigne sans remettre en question son bien-fondé. Si la validation initiale a été sautée, vous obtenez un déploiement qui paraît légitime mais qui repose sur des hypothèses fragiles.

Les modèles de langage fonctionnent de la même manière. Ils produisent du texte cohérent à partir de ce qu’on leur donne. Deux requêtes identiques donnent deux résultats différents, car ils complètent les zones laissées vides par le prompt. Sans garde-fous en amont, la sortie reste plausible tout en étant potentiellement fausse.

Ce qui se passe quand on saute les contrôles

• Un certificat SSL arrive à expiration parce que le script de renouvellement n’a jamais été testé sur ce nom de domaine précis.
• Un enregistrement DNS modifié par erreur reste en ligne plusieurs jours, car personne n’a mis d’alerte sur les changements.
• Une politique DMARC passe directement de p=none à p=reject sans phase de test, et les mails légitimes sont bloqués.

Ces incidents ne viennent pas d’une faille technique complexe. Ils viennent du fait qu’on a confié à l’automatisation le soin de décider à la place des humains.

La leçon

Le travail qui précède l’automatisation coûte plus cher en apparence, mais il reste toujours moins onéreux que les conséquences d’une erreur non détectée. Ce travail comprend :

• la documentation des décisions prises (pourquoi ce TTL, pourquoi ce p=none) ;
• l’ajout de tags dans l’IaC pour rendre ces choix visibles ;
• des tests automatisés avant toute montée en charge d’une politique de sécurité ;
• une supervision des changements DNS et SSL plutôt qu’une confiance aveugle dans le renouvellement.

Ce que font les équipes qui s’en sortent

Elles traitent la vérification comme une étape du pipeline, pas comme une option. Elles relisent les prompts avant de les envoyer à un modèle. Elles exigent une approbation humaine sur les modifications critiques. Elles mesurent le taux de faux positifs de leurs outils avant de leur faire confiance à grande échelle.

L’automatisation ne remplace pas le contrôle ; elle le rend simplement plus rapide quand il est bien conçu. À l’inverse, quand elle fonctionne seule, elle reproduit les mêmes erreurs que l’e-mail reçu à 3 h du matin : rapide, crédible, et complètement à côté de la plaque.