Récemment, j'ai eu l'opportunité de passer un entretien technique pour un poste qui m'intéressait beaucoup. Le test consistait à construire une infrastructure AWS en utilisant Terraform. Bien que je sois familier avec Terraform, je me suis rapidement rendu compte que cette épreuve allait être plus difficile que prévu. Finalement, j'ai échoué à ce test, principalement en raison de mon manque de pratique récente avec Terraform et de ma connaissance limitée d'AWS. Mais cette dure réalité m'a ouvert les yeux sur mes lacunes, tout en révélant des opportunités d'amélioration dans un domaine en constante évolution.
Le défi
Sur le papier, le test semblait relativement simple : utiliser Terraform pour créer une petite infrastructure AWS fonctionnelle. Il s’agissait simplement de configurer un serveur web accessible uniquement en HTTP ou HTTPS, connecté à une base de données qui devait être complètement inaccessible depuis Internet. Le tfstate devait être sauvegardé sur un bucket S3 avec un verrou DynamoDB, eux aussi crées avec Terraform précédemment.
J’étais confiant au départ, sûrement trop, pensant que mes bases en Terraform suffiraient. Cependant, ce que je n'avais pas anticipé, c'était à quel point chaque détail technique de cet petit exercice allait se concentrer sur Terraform et AWS. L'ensemble du processus s'est révélé plus intensif que prévu.
Les difficultés rencontrées
Dès les premières étapes du test, j'ai ressenti que mon utilisation rare de Terraform se faisait sentir. C’est un outil puissant, mais il peut aussi te ralentir si tu n’es pas attentif aux subtilités. Il ne pardonne pas les erreurs de syntaxe, les mauvaises configurations ou les paramètres spécifiques à chaque service cloud. Ces détails, souvent triviaux en apparence, m'ont coûté beaucoup de temps. Par exemple, j'avais commencé plusieurs blocs de ressources sans entourer les types et identifiants de guillemets. Cela ne posait pas de problème technique en soi, mais cela a surpris mon examinateur, car ce n’était pas en accord avec les standards de la documentation officielle.
De plus, ma maîtrise d'AWS était insuffisante. Bien qu'AWS soit mentionné dans mes compétences sur mon CV (ce que je vais vite retirer), je n'ai pas d'expérience importante ou récente sur cette plateforme. Mon expérience cloud repose principalement sur Google Cloud Platform (GCP) et se limite souvent à la création de clusters GKE, une tâche que je trouve relativement simple à gérer avec moins de configurations complexes. Je ne me suis pas retrouvé bloqué, mais plutôt ralenti à chaque nouvelle étape, car je devais régulièrement consulter la documentation du provider AWS pour Terraform.
En sortant de l’entretien, j’ai immédiatement ressenti que ma performance avait été impactée par ces ralentissements. Cette impression a été confirmée par le retour négatif de l'entreprise, qui soulignait que mon manque d’automatismes sur ces deux technologies n’était pas suffisant pour les exigences du poste.
Cela a validé mon ressenti : mes compétences en AWS n’étaient pas à la hauteur des attentes, même si je n'avais jamais prétendu maîtriser cette plateforme dans mes expériences professionnelles récentes.
Une évaluation limitée pour un rôle plus vaste
Je savais que les missions du poste se basaient en grande partie sur Terraform, donc je n'ai pas été surpris que l'évaluation se focalise sur cet aspect. Toutefois, en tant que DevOps, les outils et technologies que nous utilisons varient souvent en fonction des contextes. La concentration exclusive sur Terraform et AWS était donc un peu limitante par rapport à la diversité des compétences qu’un DevOps peut apporter.
Je me considère bien plus compétent sur des sujets comme Kubernetes ou le monitoring, des domaines où j'ai beaucoup plus d'expérience et de pratique. Pourtant, ces aspects n'ont pas été abordés pendant le test. La difficulté de mesurer les compétences DevOps réside justement dans cette diversité d'outils et de technologies. Ce rôle nécessite une approche holistique qui touche aussi bien à l'infrastructure, à l'automatisation, qu'à la surveillance des systèmes en production.
Un test technique qui se concentre uniquement sur un outil, aussi important soit-il, ne reflète pas toujours la réalité quotidienne d’un poste de DevOps. Et à l'ère de l'IA et des assistants comme Copilot, la connaissance "brute" sur un outil a tendance, je trouve, à être moins cruciale que la capacité à réfléchir et à appliquer une méthodologie solide.
Les leçons apprises
Malgré tout, cette expérience m'a permis de tirer plusieurs leçons précieuses :
- Terraform, malgré sa puissance, peut te ralentir : Même avec toute l'automatisation qu’il permet, une connaissance imparfaite des services cloud ou des subtilités de l’outil peut te faire perdre du temps. Une attention minutieuse est nécessaire pour éviter des erreurs qui peuvent sembler triviales, mais qui s'accumulent rapidement.
- La connaissance approfondie des services AWS est cruciale : J'ai réalisé que transposer mes connaissances de GCP à AWS ne suffisait pas. Chaque plateforme a ses particularités, et il est crucial de bien maîtriser les services AWS spécifiques avant de tenter de les implémenter avec Terraform.
- Savoir évaluer ses propres compétences par rapport aux exigences du poste : Une des leçons les plus importantes que j'ai tirées de cette expérience est la nécessité de savoir reconnaître si les exigences techniques d'un test sont trop éloignées de ses compétences actuelles. Dans de tels cas, il ne faut pas hésiter à alerter ou à discuter avec les recruteurs avant de se lancer dans le test technique, afin d'éviter de se retrouver en difficulté inutilement.
Conclusion
Même si je n'ai pas réussi ce test technique, cette expérience m'a apporté une prise de conscience importante. Savoir utiliser des outils comme Terraform est essentiel, mais cela ne fait pas tout, surtout lorsqu’ils sont couplés à des plateformes aussi complexes qu’AWS. Ce n'est pas tant que j'étais bloqué, mais le manque de fluidité dans mon travail a joué contre moi. Cela m’a permis de mieux comprendre mes lacunes et de voir où je dois concentrer mes efforts à l'avenir.
L’échec fait partie du processus d'apprentissage dans la tech. Il m’a donné l’élan pour me remettre à niveau sur AWS, et m’a rappelé qu'il y a toujours des détails à maîtriser, même dans les outils qu'on pense connaître.
