Ansible sur Windows et Linux : automatisation unifiée des serveurs d'un centre hospitalier

Dans les bonnes pratiques de gestion d'infrastructure, il est recommandé de différencier les outils selon leur périmètre : d'un côté un outil de gestion des logiciels sur les postes de travail, de l'autre un outil d'automatisation dédié aux serveurs. C'est dans ce cadre que nous avons mis en place Ansible, piloté par Ansible Semaphore, pour centraliser et automatiser la gestion des serveurs du centre hospitalier - qu'ils soient Linux ou Windows.

Ansible : puissant sur Linux, sous-estimé sur Windows

Ansible est aujourd'hui l'un des outils d'automatisation les plus utilisés dans les environnements Linux. Il permet de décrire la configuration d'un serveur sous forme de code (infrastructure as code), de déployer des logiciels, de vérifier la conformité d'un parc et d'orchestrer des tâches complexes - sans agent à installer sur les machines cibles.

Dans le monde Windows, cet outil reste beaucoup moins connu - et pourtant il est tout aussi puissant. La réticence vient souvent d'une idée reçue : Ansible serait un outil Linux. Ce n'est pas le cas. Avec la bonne configuration, Ansible administre des serveurs Windows avec la même efficacité que des serveurs Linux.

Le problème : WinRM, un protocole trop buggé

Sur Windows, Ansible communique par défaut via WinRM (Windows Remote Management), le protocole de gestion à distance natif de Microsoft. En théorie, il est la solution évidente. En pratique, WinRM s'est révélé très instable dans notre contexte : connexions aléatoires, authentifications qui échouent, comportements imprévisibles selon les versions de Windows Server. Ces bugs rendaient l'automatisation peu fiable - ce qui est exactement l'opposé de ce qu'on cherche.

Notre solution : SSH sur les serveurs Windows

Pour contourner ces limitations, nous avons activé SSH sur les serveurs Windows. Microsoft intègre un serveur OpenSSH natif depuis Windows Server 2019, mais il est rarement activé. En le déployant sur l'ensemble des serveurs Windows du parc, nous avons pu utiliser le même protocole de communication qu'avec les serveurs Linux.

En faisant parler Ansible en SSH sur tous les serveurs - Linux comme Windows - nous avons obtenu un fonctionnement homogène, stable et prévisible sur l'ensemble du parc, sans les aléas de WinRM.

Ansible Semaphore : piloter les automatisations depuis une interface web

Pour rendre Ansible accessible aux équipes sans passer systématiquement par la ligne de commande, nous avons déployé Ansible Semaphore. Cette interface web permet de lancer des playbooks, de planifier des exécutions, de suivre les résultats et de gérer les droits d'accès - tout en conservant la traçabilité complète de chaque opération.

Les bénéfices : centralisation, déploiement automatisé et conformité homogène

La mise en place de cette stack a produit trois bénéfices structurants pour le centre hospitalier :

• Centralisation des tâches : toutes les opérations d'administration serveur sont pilotées depuis un point unique, avec une visibilité complète sur ce qui est exécuté et quand.
• Déploiement automatisé des logiciels : l'installation et la mise à jour d'applications sur les serveurs sont désormais reproductibles et ne dépendent plus d'une intervention manuelle poste par poste.
• Vérification homogène des règles de conformité : les mêmes règles de sécurité et de configuration sont appliquées et vérifiées sur l'ensemble des serveurs, qu'ils tournent sous Linux ou Windows. Plus de dérive de configuration, plus de serveur oublié lors d'une mise à jour de politique.

Une séparation saine des responsabilités

Ce déploiement illustre aussi une bonne pratique d'architecture : Ansible gère les serveurs, tandis qu'un outil dédié comme Chocolatey ou SCCM gère les postes de travail. Chaque outil dans son périmètre, chaque périmètre avec son outil adapté. C'est cette rigueur dans la séparation des responsabilités qui garantit la maintenabilité et la fiabilité du SI à long terme.