Le serveur qu'on ne sait plus refaire
La configuration manuelle produit toujours le même résultat à long terme : une machine dont l'état actuel est la somme de trois ans d'interventions non documentées. Elle fonctionne, personne n'ose y toucher, et le jour où elle tombe, la remonter à l'identique relève de l'archéologie. C'est exactement le problème que l'Infrastructure as Code supprime.
Le principe est simple : tout ce qui définit l'environnement, serveurs, réseau, règles de pare-feu, bases de données, certificats, est décrit dans des fichiers stockés avec le code applicatif. Un outil lit ces fichiers et met l'infrastructure dans l'état décrit. La description devient la vérité, la machine n'est qu'une conséquence.
Les bénéfices qui se voient vite
Le premier est la reproductibilité. Créer un environnement de recette identique à la production devient une commande, pas un projet. Les incidents du type « ça marchait sur la recette » disparaissent, puisque les deux environnements sortent de la même description.
Le deuxième est la traçabilité. Chaque changement d'infrastructure passe par une modification de fichier, donc par l'historique : qui a ouvert ce port, quand, et pourquoi. Le troisième est la reprise après incident : la question n'est plus « qui se souvient de la configuration », mais « combien de temps prend l'exécution ».
Ce que ça demande
Ce n'est pas gratuit. Il faut décrire l'existant, ce qui suppose de le comprendre, et accepter une règle stricte : plus aucune modification à la main sur les serveurs, sinon la description ment et le filet ne tient plus. Sur un parc existant, la reprise se fait progressivement, environnement par environnement, en commençant souvent par les environnements de test où l'erreur est sans conséquence.
L'Infrastructure as Code se déploie naturellement avec une chaîne CI/CD : l'une livre l'application, l'autre le terrain sur lequel elle tourne. C'est la base de nos missions cloud et DevOps, détaillée sur notre page Infrastructure as Code.
