Infrastructure as code : par où commencer sans tout réécrire

L’objection est légitime : « nous avons quarante serveurs configurés à la main, nous n’allons pas tout recommencer ». Effectivement, non. L’adoption de l’infrastructure en code ne commence jamais par une réécriture complète.

Étape 1 — Les environnements jetables

Commencez par ce qui est détruit et recréé souvent : environnements de test, plateformes de démonstration, bacs à sable. L’erreur y est sans conséquence, et le gain immédiatement visible.

Étape 2 — Les nouveaux serveurs

Adoptez une règle simple : tout nouveau serveur est déployé depuis du code. L’existant n’est pas touché, mais la proportion d’infrastructure décrite augmente mécaniquement à chaque projet.

Étape 3 — La configuration avant le provisionnement

Ansible apporte un gain plus rapide que Terraform sur un parc existant : il décrit la configuration de serveurs déjà en place, sans les recréer. Le provisionnement en code vient ensuite, au rythme des renouvellements.

- name: Durcissement SSH
  hosts: serveurs_applicatifs
  become: true
  tasks:
    - name: Interdire l'authentification par mot de passe
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^#?PasswordAuthentication'
        line: 'PasswordAuthentication no'
      notify: reload sshd

Le piège à éviter

Une infrastructure partiellement décrite, modifiée aussi à la main, devient plus dangereuse qu’une infrastructure entièrement manuelle : le code ne reflète plus la réalité. La règle doit être absolue sur le périmètre couvert — aucune modification manuelle, même urgente.