Le dry-run, ou pourquoi l'automatisation ne pardonne rien

Automatiser, c’est transformer une suite de clics en code. Le problème, c’est que le code ne « sent » rien : il exécute exactement ce qu’on lui a écrit, y compris quand ce qu’on a écrit est une mauvaise idée à 3h du matin sur un parc de production.

Le contexte

Le projet consistait à migrer un parc VoIP Centrex virtuel plusieurs dizaines de serveurs SIP vers une nouvelle infrastructure, en pilotant le tout via l’API Nutanix depuis des playbooks Ansible et des scripts Python. Sur le papier, l’automatisation devait supprimer la variable humaine et fiabiliser la migration. Dans les faits, elle a surtout déplacé le risque : d’une erreur de manipulation ponctuelle vers une erreur de logique qui se reproduit identiquement sur chaque nœud.

Ce qui a mal tourné (un peu)

Le premier lot de tests fonctionnait parfaitement en environnement de lab. En production, deux ou trois cas limites des configurations d’équipements téléphoniques légèrement différentes selon les sites ont fait échouer certaines tâches à mi-chemin. Rien d’irrattrapable, mais assez pour comprendre une chose : un playbook qui fonctionne sur un environnement homogène ne prouve rien sur un parc hétérogène.

Ce qui a vraiment changé la donne

La réponse n’était pas d’écrire plus de code, mais d’écrire moins de code avant d’avoir vérifié. Concrètement :

• Systématiser le mode --check / dry-run avant toute exécution réelle, pour visualiser le diff attendu sans y toucher.
• Segmenter les playbooks par lot (canary) plutôt que de viser l’ensemble du parc en une passe.
• Journaliser chaque étape de façon suffisamment lisible pour qu’un collègue puisse comprendre l’échec sans relire le code source.

Rien de révolutionnaire c’est même la base de toute discipline de déploiement logiciel sérieuse. Mais c’est précisément le genre de rigueur qu’on sous-estime tant qu’on n’a pas vu un script mal anticipé se répéter identiquement sur 40 machines d’affilée.

Ce que j’en retiens

L’Infrastructure as Code n’élimine pas le risque : elle le rend systématique. C’est une bonne nouvelle si le code est juste, et une très mauvaise nouvelle sinon. La vraie valeur ajoutée de l’automatisation n’est pas la vitesse d’exécution, c’est la capacité à rejouer un déploiement de façon identique et vérifiable à condition d’avoir testé ce qu’on rejoue.

Depuis, un dry-run exhaustif n’est plus une option sur mes scripts de migration : c’est une étape du pipeline, au même titre que le déploiement lui-même.