Terraform : avez-vous vraiment besoin d'automatiser votre infrastructure ?

Terraform est un outil extraordinaire pour répliquer une infrastructure à l'infini de manière déterministe. Vous décrivez vos serveurs, vos réseaux, vos règles de sécurité dans des fichiers de configuration, et l'outil se charge de tout créer ou recréer à l'identique en quelques minutes. C'est puissant, c'est élégant, et c'est devenu un standard de l'industrie. Mais c'est aussi une grosse machine qui, dans beaucoup de cas, est mise en place bien trop tôt par rapport au besoin réel de l'entreprise.

Le piège de l'automatisation prématurée

Il y a plein de choses qui sont intéressantes à automatiser dans une équipe technique : les tests, le build, la sécurité, le déploiement des applications. Ces processus sont exécutés plusieurs fois par jour et chaque minute gagnée se multiplie rapidement. Mais le déploiement de serveurs est, pour beaucoup de sociétés, une activité qu'on fait une fois au démarrage et qu'on risque de ne pas toucher pendant une bonne année, voire deux. Le rapport entre le coût de mise en place d'un outil comme Terraform et la fréquence à laquelle on va réellement s'en servir est souvent défavorable.

J'ai vu plusieurs startups vouloir tout automatiser trop tôt. L'envie est compréhensible : on veut faire les choses bien, on a lu des articles sur l'Infrastructure as Code, on sait que les grandes entreprises utilisent Terraform. Mais les grandes entreprises ont aussi des centaines de serveurs, des dizaines d'environnements et des équipes dédiées à l'infrastructure. Une startup qui a trois serveurs en production n'est pas dans le même contexte, et appliquer les mêmes recettes est une forme d'over-engineering qui consomme du temps précieux qui pourrait être investi dans la création de valeur pour les utilisateurs.

La question à se poser : que gagne-t-on à automatiser ?

Avant de mettre en place Terraform ou n'importe quel outil d'Infrastructure as Code, il faut se poser deux questions simples. La première : est-ce pour gagner du temps ? Si oui, le coût de mise en place doit être remboursé rapidement par les gains futurs. La seconde : est-ce pour s'assurer de la pérennité d'un processus ? Dans ce cas, il faut valider que ce processus est réellement critique pour le business.

Chez Wizbii, nous utilisions massivement Terraform pour toute notre production sur GCP, et c'était parfaitement justifié. Mais nous avions aussi un serveur chez OVH pour nos besoins de build, des runners GitLab. On a voulu automatiser ce déploiement avec Terraform. Ça nous a pris entre 3 et 4 jours pour le faire proprement. Et on n'y a jamais retouché. Chez Winter, j'ai fait exactement la même chose manuellement en le documentant dans un README, en moins de 2 heures. On n'y a jamais retouché non plus. Quatre jours contre deux heures pour un résultat identique en pratique : déployer des runners GitLab n'est vraiment pas business critical, et l'automatisation n'a apporté aucune valeur supplémentaire.

L'alternative pragmatique : documenter puis scripter

Tant que vous ne déployez pas de serveur ou de nœud au moins une fois par mois, automatiser ce processus avec un outil comme Terraform n'a pas un immense intérêt. La démarche pragmatique est simple : faire la première installation complètement à la main, documenter chaque étape dans un Notion ou un README, puis rejouer cette documentation si besoin. Au pire, on peut transformer cette documentation en un script bash très simple qui enchaîne les commandes. Ce n'est pas de l'Infrastructure as Code au sens noble du terme, mais ça couvre parfaitement le besoin d'une équipe qui n'a pas vocation à recréer son infrastructure toutes les semaines.

Cette approche a un avantage supplémentaire : la documentation produite est compréhensible par n'importe quel développeur de l'équipe, même ceux qui n'ont jamais touché à Terraform. La barrière d'entrée pour comprendre et maintenir l'infrastructure reste basse, ce qui contribue à la résilience de l'équipe. Un fichier Terraform bien écrit est lisible par quelqu'un qui connaît l'outil, mais peut devenir une boîte noire pour le reste de l'équipe si personne d'autre ne maîtrise la syntaxe HCL.

Quand Terraform devient un must-have

Le moment où l'automatisation de l'infrastructure se justifie pleinement, c'est quand votre produit se développe, trouve son audience et nécessite une infrastructure solide et résiliente. Concrètement, c'est quand la fréquence de création ou de reconfiguration de serveurs augmente significativement : ajout de nœuds pour absorber la charge, création d'environnements éphémères pour les tests, réplication de l'infrastructure dans une nouvelle région pour des raisons de latence ou de conformité.

À ce stade, les erreurs humaines lors de la configuration manuelle deviennent un vrai risque, la reproductibilité devient un enjeu fort, et le temps passé à faire les choses à la main commence à peser. Terraform devient alors non seulement justifié mais indispensable. C'est aussi le moment où vous avez probablement besoin d'un SRE dans votre équipe, et lui laisser mettre cette stack en place à son arrivée est en général une excellente façon de le faire rentrer dans le vif du sujet. Avant ce seuil, un développeur backend peut tout à fait gérer l'infrastructure. Ce ne sera peut-être pas fait 100% dans les règles de l'art, mais ça suffira.

Au-delà de Terraform

Je parle de Terraform parce que c'est l'outil que je connais le mieux et qu'il est clairement le leader de ce marché. Mais les enseignements sont exactement les mêmes avec les autres outils disponibles : Pulumi, Ansible, CloudFormation, ou les outils natifs de votre cloud provider. La question n'est pas "quel outil choisir" mais "est-ce que ça vaut le coup d'automatiser maintenant". Et la réponse dépend toujours du même calcul : combien de temps va me coûter la mise en place, combien de fois vais-je m'en servir, et est-ce que ce temps ne serait pas mieux investi à créer de la valeur pour mes utilisateurs ?

C'est d'ailleurs un principe qui s'applique bien au-delà de l'infrastructure. Chaque fois qu'on est tenté de mettre en place un outil ou un processus sophistiqué, se poser la question du retour sur investissement réel permet d'éviter beaucoup de choix technologiques prématurés.

En résumé

Terraform est un outil formidable, mais il résout un problème que beaucoup de startups n'ont pas encore. Avant de l'adopter, demandez-vous à quelle fréquence vous touchez réellement à votre infrastructure. Si c'est une fois par an, documentez et scriptez. Si c'est plusieurs fois par mois, automatisez. Et dans tous les cas, rappelez-vous que le temps passé à mettre en place des outils d'infrastructure est du temps que vous ne passez pas à construire votre produit.