Terraform, Ansible, Pulumi, CloudFormation : les outils d’infrastructure as code apparaissent sur la plupart des CV d’ingénieurs DevOps, SRE, cloud ou plateforme, et de plus en plus sur ceux des développeurs backend. Pour un responsable d’équipe plateforme, la liste de ces outils ne suffit pourtant pas. Ce qu’il veut savoir, c’est ce qui était géré en code : combien d’environnements, quels services, quelle part de l’infrastructure, avec quel niveau de revue et d’automatisation. Un même mot, Terraform, peut désigner la modification occasionnelle d’un fichier écrit par d’autres ou la conception des modules partagés par toute une organisation. Cet article explique comment décrire ce périmètre, avec des exemples de lignes avant et après.
Ce que recouvre l’infrastructure as code
L’infrastructure as code consiste à décrire l’infrastructure (réseaux, machines, bases de données, droits d’accès, clusters, services managés) dans des fichiers versionnés, plutôt qu’à la configurer à la main dans une console. Ces fichiers sont relus, testés et appliqués de façon automatisée, comme du code applicatif.
On distingue généralement deux familles d’usages.
- Le provisionnement : créer et faire évoluer les ressources d’infrastructure, en particulier dans le cloud. C’est le terrain de Terraform 🔗, de son équivalent open source OpenTofu 🔗, de Pulumi 🔗 ou des outils propres à chaque fournisseur.
- La gestion de configuration : installer et configurer des logiciels sur des machines existantes, maintenir leur état. C’est le terrain d’Ansible 🔗 et d’outils comparables.
À ces deux familles s’ajoutent les approches GitOps, où l’état souhaité d’un cluster Kubernetes est décrit dans un dépôt et appliqué en continu par un outil comme Argo CD 🔗. Notre article sur Kubernetes sur un CV détaille la façon de présenter ce niveau.
Un recruteur cherche à comprendre lequel de ces usages vous pratiquez, à quelle échelle et avec quelle autonomie.
Terraform, Ansible, Pulumi : ce que chaque outil dit de vous
Chaque outil envoie un signal un peu différent, qu’il est utile de connaître pour construire sa rubrique compétences.
- Terraform ou OpenTofu : l’outil de provisionnement le plus répandu, multi-cloud, avec un langage déclaratif. Il signale une pratique du cloud et de la gestion d’état (le fichier d’état 🔗 qui décrit ce qui existe réellement). C’est souvent l’outil que les offres citent en premier.
- Ansible : signale une pratique de la configuration de serveurs, fréquente dans les environnements hybrides, sur site ou chez les hébergeurs. Il est apprécié des profils venus de l’administration système.
- Pulumi : permet d’écrire l’infrastructure dans un langage de programmation généraliste (TypeScript, Python, Go). Il signale souvent un profil proche du développement, dans une équipe qui partage le langage de l’application.
- CloudFormation, Bicep et les outils des fournisseurs : signalent une spécialisation sur un cloud précis.
- Helm, Kustomize et les outils GitOps : signalent une pratique du déploiement sur Kubernetes.
Les citer ne suffit pas : ce qui compte, c’est ce que vous en avez fait. Regroupez ces outils dans une ligne « Infrastructure et automatisation » de votre rubrique compétences, comme le propose notre article sur la présentation de la stack technique, puis prouvez leur usage dans les expériences.
Décrire un périmètre plutôt qu’un outil
Une bonne description d’infrastructure as code répond à cinq questions.
- Quoi ? Les ressources gérées en code : réseau, calcul, bases de données, clusters, droits d’accès, DNS, supervision.
- Combien ? Le nombre d’environnements, de comptes ou de projets cloud, de services, de serveurs.
- Quelle part ? Tout est-il en code, ou seulement une partie ? Avez-vous migré des ressources créées à la main ?
- Comment ? Modules partagés, conventions, revue par pull request, plans automatiques, tests.
- Avec quel effet ? Délai de création d’un environnement, incidents évités, dérives détectées, autonomie gagnée par les équipes.
Il n’est pas nécessaire de répondre aux cinq dans chaque puce, mais au moins à trois. Un recruteur qui lit « 4 environnements et 3 comptes AWS gérés intégralement en code, avec revue par pull request » comprend immédiatement votre niveau.
Exemples de lignes avant et après
Un développeur backend qui touche à l’infrastructure
Avant : « Terraform, Docker, AWS. »
Après : « Ajout et maintenance des ressources de mon service dans les modules Terraform de l’équipe plateforme (file de messages, base de données managée, droits d’accès), avec revue par l’équipe plateforme avant chaque application. »
Cette version est honnête sur le rôle (contributeur, pas concepteur) et montre une vraie pratique.
Un ingénieur DevOps
Avant : « Mise en place de l’infrastructure as code avec Terraform et Ansible. »
Après : « Reprise en Terraform de l’infrastructure de trois environnements créés à la main (réseau, bases de données, équilibreurs de charge) et configuration de cent vingt serveurs avec Ansible ; création d’un nouvel environnement client ramenée de deux jours à deux heures. »
Le périmètre, la migration et l’effet sont explicites. Le modèle de CV d’ingénieur DevOps ou SRE contient des puces de cette forme, avec Terraform et Ansible.
Un ingénieur plateforme
Avant : « Conception de modules Terraform. »
Après : « Conception d’une bibliothèque de modules Terraform versionnés (réseau, cluster, base de données, supervision), utilisée par quinze équipes produit pour créer leurs environnements en autonomie ; tests automatisés des modules et politique de mise à jour documentée. »
Ici, le recruteur lit une responsabilité d’organisation : des utilisateurs internes, des versions, des tests et une politique.
Un profil en évolution depuis l’administration système
Avant : « Scripts d’automatisation. »
Après : « Remplacement de scripts Bash de déploiement par des rôles Ansible testés, puis provisionnement des machines virtuelles de l’hébergeur en Terraform ; documentation et formation de deux collègues de l’équipe d’exploitation. »
CI/CD et revue de code de l’infrastructure
Un signe de maturité très regardé par les équipes plateforme : l’infrastructure est-elle traitée comme du code, avec les mêmes garanties ?
Les pratiques qui méritent une mention :
- la revue par pull request de toute modification d’infrastructure ;
- les plans automatiques affichés dans la pull request, pour voir l’effet d’une modification avant de l’appliquer ;
- l’application automatisée depuis une chaîne d’intégration continue, plutôt que depuis un poste personnel ;
- la gestion de l’état partagée et verrouillée, et la séparation des environnements ;
- les tests et les contrôles : validation de syntaxe, règles de sécurité, détection des dérives entre le code et l’infrastructure réelle ;
- la gestion des secrets, hors des fichiers versionnés.
Une ligne suffit souvent pour l’exprimer : « Toute modification d’infrastructure passe par une pull request avec plan automatique et application depuis la CI ; détection hebdomadaire des dérives. »
Les certifications peuvent compléter ce tableau. HashiCorp propose une certification Terraform Associate 🔗, et les certifications associées des fournisseurs cloud valident la connaissance des services que vous décrivez en code ; notre article sur les certifications cloud aide à choisir.
Pour que ce périmètre soit lu, il faut aussi que le CV soit extrait correctement par les logiciels de recrutement, qui filtrent souvent sur « Terraform » ou « Ansible ». L’éditeur de TechCV garde vos outils et vos puces en texte simple, dans une mise en page en une colonne, ce qui leur évite d’être perdus en route. Vous pouvez reprendre votre CV à partir du modèle DevOps.
Questions fréquentes
Faut-il citer Terraform si l’on n’a jamais conçu de module ?
Oui, si vous l’avez utilisé réellement, en précisant votre rôle : contribution à des modules existants, ajout de ressources, revue. C’est une compétence recherchée même à ce niveau, et l’honnêteté sur le périmètre rassure.
Terraform ou OpenTofu : que mettre sur le CV ?
Citez celui que vous avez utilisé. Les deux outils partagent une grande partie de leur langage et de leurs concepts ; mentionner « Terraform (et OpenTofu) » est raisonnable si vous avez pratiqué les deux ou suivi une migration.
L’infrastructure as code a-t-elle sa place sur un CV de développeur ?
Oui, de plus en plus. Beaucoup d’équipes demandent aux développeurs de décrire les ressources de leur service en code. Une puce qui montre cette pratique distingue un développeur autonome sur la mise en production.
Comment montrer l’effet de l’infrastructure as code ?
Par des indicateurs d’exploitation : délai de création d’un environnement, nombre d’environnements gérés, incidents liés à des modifications manuelles, temps de reprise après sinistre. Choisissez ceux que vous avez réellement suivis.