Scripter n'est pas industrialiser

La discussion portait sur Windows et je tenais à l’écrire d’emblée pour couper court au réflexe habituel : Windows se prête très bien à l’automatisation et ce n’est pas le sujet. J’ajoutais simplement une distinction qu’on escamote souvent, entre scripter ou automatiser une tâche d’un côté et industrialiser de l’autre. Un CSV qui alimente un script PowerShell, c’est déjà un vrai progrès, mais on reste essentiellement dans du scripting avec du templating et de l’orchestration ad hoc. La frontière est ailleurs et elle est conceptuelle avant d’être technique.

Le script ad hoc, utile et honnête

Ne méprisons pas le script, il fait le travail et il le fait bien. Un CSV en entrée, une boucle PowerShell qui itère, deux-trois jointures, un template généré à la volée : c’est lisible, c’est immédiat et pour un besoin ponctuel ou un parc modeste, c’est souvent la bonne réponse. Côté Unix, l’équivalent est un inventaire clé/valeur en .env couplé à un .ssh/config, du SSH/SCP, du bash bien structuré et un moteur de template comme envsubst ou mo. Chaque composant est auditable, aucune magie et ça tourne partout où il y a un bash, un ksh ou un zsh.

C’est une excellente école et je continue à penser que savoir monter ce socle à la main est un marqueur sérieux. Mais c’est aussi, peu ou prou, ce que fait Ansible, en y ajoutant l’idempotence et des centaines de modules maintenus par la communauté ; réinventer tout ça en shell est formateur, mais coûteux en production et comme j’en ai déjà parlé ailleurs, dans l’ancêtre d’Ansible et dans la frugalité Unix , je n’y reviens pas, parce que ce n’est pas le point de cet article. Le point, c’est que même parfaitement exécuté, ce socle reste un script et qu’un script n’est pas une plateforme.

Ce qu’une plateforme ajoute et qui change de nature

La différence n’est pas une question de volume de code ni de propreté : on peut écrire du shell magnifique qui reste du scripting et du YAML immonde qui relève pourtant d’une plateforme. Ce qui fait basculer, c’est une série de propriétés qui, mises ensemble, changent la nature de ce qu’on construit.

L’état désiré, d’abord : on ne décrit plus une suite d’actions à exécuter, mais la cible à atteindre et l’outil se charge de l’écart. L’idempotence, qui en découle : rejouer dix fois produit le même résultat qu’une fois et c’est cette garantie qui transforme une exécution en convergence. L’inventaire comme source de vérité, les variables et les rôles réutilisables qui factorisent le savoir au lieu de le copier-coller d’un script à l’autre. La gestion des secrets, qui cesse d’être un fichier qu’on n’ose pas committer pour devenir un coffre intégré. Et enfin l’exécution contrôlée, le reporting et la traçabilité : savoir qui a fait tourner quoi, sur quelles cibles, avec quel résultat et pouvoir le prouver.

Un script à la mano peut singer chacune de ces propriétés prise isolement, j’ai codé des vérifications d’idempotence maison, j’ai bricolé des coffres à secrets en shell. Mais les tenir toutes, ensemble, de manière cohérente et sans y passer ses soirées, c’est précisément ce qu’une plateforme comme Ansible ou Salt vous donne par construction. Le script automatise une tâche ; la plateforme construit un système reproductible et industrialise. C’est là, exactement, que je place la frontière.

Ce n’est pas une question de système

Il faut tuer une idée reçue au passage, parce qu’elle pollue toujours ce genre de débat : ces outils ne sont pas réservés à Linux. Ansible pilote nativement Windows via WinRM ou PSRP, Salt dispose aussi d’un support Windows avec ses minions et j’ai assez de playbooks qui causent Kerberos et CredSSP pour affirmer que ça marche en production, pas seulement sur le papier.

Autrement dit, le CSV plus PowerShell d’un côté et le playbook Ansible de l’autre peuvent viser exactement le même parc Windows. La frontière ne passe pas entre deux systèmes d’exploitation, elle passe entre deux natures d’outillage. Windows s’automatise très bien, encore une fois et ce n’est pas lui qu’on oppose à quoi que ce soit : on oppose le script ad hoc, quel que soit l’OS, à la plateforme d’automatisation, quel que soit l’OS.

Le coût du choix, dans les deux sens

Reste à ne pas transformer cette distinction en dogme, parce que l’industrialisation a un coût et qu’elle n’est pas gratuite à mettre en place. Déployer Ansible ou Salt, structurer l’inventaire, écrire des rôles propres, intégrer un coffre, câbler le reporting, tout cela demande un investissement initial qui ne se justifie pas pour trois machines qu’on touche une fois par trimestre. Pour ce besoin-là, le CSV plus PowerShell ou le .env plus bash reste la réponse honnête et prétendre le contraire serait de la cérémonie.

Le vrai arbitrage est celui de l’échelle et de la récurrence. Dès qu’un parc grandit, qu’une opération se répète, qu’il faut rendre des comptes sur ce qui a tourné, le script finit par recréer, mal et lentement, les propriétés qu’une plateforme offre d’emblée et c’est à ce moment-là, pas avant, qu’il faut déplacer son énergie de l’outillage vers l’infrastructure. Scripter reste utile, parfois suffisant ; mais scripter n’est pas industrialiser et confondre les deux coûte cher dans un sens comme dans l’autre, qu’on industrialise trois machines ou qu’on scripte un parc de mille. Pour le reste de l’outillage artisanal, ce que le script ignore et ce que le conteneur déplace, j’en parle dans Docker et Ansible et l’inventaire par le DNS .

Où atterrir

La bonne question n’est pas “shell ou Ansible”, ni même “Linux ou Windows”, c’est “une tâche à automatiser ou un système à industrialiser”. Si c’est une tâche, scriptez, assumez-le et ne vous excusez pas d’un CSV plus PowerShell qui fait le travail. Si c’est un système, avec de l’échelle, de la récurrence et des comptes à rendre, offrez-vous l’état désiré, l’idempotence, l’inventaire, les secrets et la traçabilité et laissez la plateforme porter ce que le script ne peut tenir qu’en apparence. La frontière est conceptuelle, elle ne dépend ni du langage ni de l’OS et c’est en la voyant clairement qu’on arrête de payer le mauvais prix.