Un ingénieur Ansible travaille rarement seul depuis son terminal. Dans les offres, il exploite et fait évoluer Ansible Automation Platform (AAP), la version Red Hat qui ajoute au moteur open source une interface, des inventaires centralisés, des droits par équipe, un hub de collections et l'automatisation sur événements. Les missions mêlent run et build : montées de version, incidents tracés dans ServiceNow, nouveaux rôles pour Linux, Windows ou le réseau, intégration avec OpenShift et HashiCorp Vault.
Le niveau se voit dans la structure du code. Un junior écrit des playbooks pleins de tâches shell. Un confirmé publie des rôles dans une collection versionnée, les teste avec Molecule et ansible-lint et les exécute dans une Execution Environment, l'image de conteneur qui fige ansible-core, les collections et leurs dépendances. Le passage à ansible-core 2.19 a durci le moteur de templates et cassé une partie des playbooks existants, un bon sujet de discussion.
L'entretien part d'un job template qui échoue dans AAP, et le candidat déroule le diagnostic : sortie du job, image utilisée, identifiants, inventaire. L'examen EX294 (Red Hat Certified Advanced System Administrator in Ansible, qui compte pour le titre Red Hat Certified Engineer in Ansible) valide l'usage d'Ansible pour administrer RHEL, EX374 le développement de contenu pour AAP. Le PDF contient 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.
Le moteur, la plateforme et l'outillage autour d'Ansible
ansible-core
Le moteur open source, sans agent : il se connecte en SSH (WinRM ou PSRP pour Windows), envoie les modules sur la cible, les exécute puis les supprime. ansible-core 2.22, sorti le 2 novembre 2026, est la version courante, et chaque version supporte trois versions de Python sur la machine de contrôle. Le paquet communautaire ansible y ajoute un lot de collections.
Ansible Automation Platform (AAP)
La plateforme de Red Hat. Le contrôleur, héritier de Tower, lance les job templates et les workflows et gère inventaires, identifiants et droits par équipe. Depuis la 2.5, une passerelle commune gère l'authentification et l'interface. La 2.7, publiée en juin 2026, s'installe en conteneurs ou sur OpenShift. AWX, le projet amont, n'a plus publié de version depuis juillet 2024 pendant sa refonte.
Collections et automation hub
Une collection regroupe rôles, modules, plugins et filtres sous un nom complet (ansible.posix, community.general). Les projets les déclarent dans un requirements.yml. Automation hub, privé ou hébergé par Red Hat, distribue les collections certifiées, validées et internes. Reste à savoir si le candidat a déjà publié une collection, pas seulement s'il en a installé.
Execution Environments, ansible-builder, ansible-navigator
Les jobs d'AAP tournent dans une image de conteneur qui contient ansible-core, les collections et leurs dépendances Python et système. ansible-builder construit cette image à partir d'un fichier de définition, ansible-navigator la fait tourner sur un poste pour reproduire un job. Un candidat qui ne connaît pas ces outils n'a pas exploité AAP récemment.
Jinja2, variables et filtres
Les variables viennent de l'inventaire, des rôles, des faits collectés et des extra vars, avec un ordre de priorité qu'il faut connaître. Jinja2 et les filtres d'Ansible transforment les données et génèrent les fichiers de configuration. Depuis ansible-core 2.19, les conditions doivent renvoyer un booléen et les templates imbriqués ne sont plus évalués.
Molecule et ansible-lint
Molecule crée des instances de test, applique le rôle, le rejoue pour vérifier l'idempotence puis lance des vérifications. ansible-lint signale les mauvaises pratiques selon des profils, du plus souple au plus strict. Les deux tournent dans la CI à chaque merge request, avec ansible-test pour les collections.
Event-Driven Ansible
Des rulebooks écoutent des sources d'événements (webhook, alertes de supervision, Kafka) et lancent un job template quand une condition est remplie. Le contrôleur Event-Driven Ansible fait partie d'AAP. Les offres le citent pour la remédiation automatique d'incidents simples.
Modules et plugins en Python
Quand aucun module n'existe, l'ingénieur écrit le sien en Python avec la classe AnsibleModule, ou un plugin d'inventaire, de filtre ou de lookup. Un module correct lit l'état avant d'agir, gère le mode check et renvoie changed. C'est un bon marqueur de niveau senior.
ServiceNow, HashiCorp Vault et Git
AAP synchronise ses projets depuis Git, lit ses secrets dans Vault ou CyberArk par des plugins d'identifiants et se branche sur ServiceNow pour lancer un job après approbation d'un changement ou mettre à jour un ticket. Ces intégrations reviennent dans la plupart des offres AAP.
Les offres disent ingénieur Ansible, expert AAP, intégrateur ou exploitant Ansible Automation Platform, ingénieur DevOps automatisation. Deux profils se cachent derrière. Le premier exploite la plateforme : installation, montées de version, sauvegardes, nœuds d'exécution, incidents, droits des équipes. Le second écrit le contenu : collections, rôles, modules, workflows, souvent pour des équipes système, réseau ou middleware qui lancent ensuite les jobs elles-mêmes. Beaucoup de missions demandent les deux, avec des astreintes et des changements tracés dans ServiceNow. Un ingénieur Ansible doit aussi connaître les systèmes qu'il automatise : RHEL, Windows Server, équipements réseau. Sans ce socle, ses tâches passent au vert et laissent une configuration fausse.
Les compétences qui séparent un ingénieur Ansible d'un auteur de playbooks
- Rôles, collections et idempotence
- Jinja2, variables et inventaires
- Execution Environments et dépendances
- Administration d'AAP : RBAC, workflows, mesh
- Tests : Molecule, ansible-lint, ansible-test
- Modules et plugins en Python
Questions d'entretien Ansible, de l'idempotence à l'administration d'AAP
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · junior à confirmé
Une tâche de votre rôle ajoute une ligne dans un fichier avec le module shell. Au deuxième passage, elle affiche encore changed. Que corrigez-vous ?
Une bonne réponseIl remplace shell par le module dédié (lineinfile, blockinfile ou template), qui compare l'état avant d'agir. Si aucun module ne convient, il garde command avec creates ou removes, ou un changed_when calculé sur la sortie, et vérifie que la tâche supporte le mode check. Il explique le problème : un rapport toujours en changed cache les vraies modifications et déclenche les handlers à chaque passage.
Signal d'alerteAjouter changed_when: false partout pour obtenir un rapport vert. Ou ne voir aucun problème.
Question 2 · confirmé
Une même variable est définie dans les defaults du rôle, dans group_vars et en extra vars. Laquelle gagne, et comment organisez-vous vos variables pour éviter ce cas ?
Une bonne réponseLes extra vars l'emportent sur tout, group_vars passe devant les defaults du rôle, qui ont la priorité la plus basse. Il place les valeurs par défaut dans defaults, ce qui varie par groupe ou par environnement dans l'inventaire, réserve vars du rôle aux constantes internes et les extra vars aux surcharges ponctuelles d'un job. Il préfixe les variables par le nom du rôle pour éviter les collisions.
Signal d'alerte« La dernière lue gagne », ou des set_fact partout pour imposer une valeur.
Question 3 · confirmé
Un job template fonctionne sur votre poste et échoue dans AAP avec un module introuvable. Que regardez-vous ?
Une bonne réponseL'Execution Environment associée au job template, qui ne contient pas forcément la collection ou la bibliothèque Python dont le module a besoin. Il inspecte l'image (ansible-navigator, liste des collections), vérifie le requirements.yml du projet et sa synchronisation, puis reconstruit l'image avec ansible-builder si besoin, versions fixées. Il reproduit l'erreur en local avec ansible-navigator et la même image.
Signal d'alerteInstaller la collection à la main sur les nœuds d'exécution, ou relancer le job en espérant que ça passe.
Question 4 · confirmé
Une équipe réseau doit lancer vos jobs de configuration sans voir les mots de passe des équipements. Comment le configurez-vous dans AAP ?
Une bonne réponseUne équipe avec le rôle d'exécution sur les job templates concernés, sans droit d'administration sur les identifiants. Les mots de passe sont dans un credential, éventuellement alimenté par un plugin vers HashiCorp Vault ou CyberArk, que l'équipe utilise sans pouvoir le lire. Un survey limite les paramètres saisis, et no_log évite que le secret apparaisse dans la sortie du job.
Signal d'alerteDonner le rôle admin à l'équipe, ou mettre les mots de passe dans les variables du dépôt Git.
Question 5 · confirmé
Votre pipeline doit bloquer une merge request sur une collection Ansible. Quels contrôles y mettez-vous ?
Une bonne réponseansible-lint avec un profil exigeant, ansible-test sanity pour la collection, des scénarios Molecule sur les distributions ciblées avec converge, idempotence et verify, et la construction de l'Execution Environment si les dépendances changent. La collection suit le versionnement sémantique avec un changelog, et la publication vers automation hub ne part que d'un tag.
Signal d'alerteUn yamllint et un passage manuel sur un serveur de recette.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Ingénieur Ansible : les points qui reviennent
Quelle expérience d'AAP attendre d'un ingénieur Ansible ?
Pour écrire des rôles, Ansible suffit, et un bon profil apprend l'interface d'AAP vite. Pour exploiter la plateforme, l'expérience d'AAP ou d'AWX compte : Execution Environments, mesh, sauvegarde avec la clé secrète, montées de version, droits par équipe. Tout part de l'offre du manager. Si elle parle de run, d'astreintes et de montée de version, une plateforme déjà tenue en production est exigée.
Que valent les examens Red Hat EX294 et EX374 ?
EX294, qui donne la certification Red Hat Certified Advanced System Administrator in Ansible et compte pour le titre Red Hat Certified Engineer in Ansible, est un examen pratique qui porte sur l'administration de RHEL avec Ansible : inventaires, rôles, collections, Vault, ansible-navigator. EX374 porte sur le développement de contenu pour AAP. Les deux se passent sur des machines réelles, ce qui leur donne plus de poids qu'un QCM. Ils ne couvrent ni l'exploitation d'une grande plateforme ni l'écriture de modules en Python.
Quel exercice donner à un ingénieur Ansible en test technique ?
Un petit dépôt avec un rôle défectueux suffit : une tâche shell non idempotente, un handler qui ne se déclenche pas, une variable mal placée. La personne lance Molecule ou un playbook sur un conteneur, explique ce qu'elle voit et corrige. Quarante minutes en direct montrent les réflexes. Pour un poste d'exploitation s'ajoute un job AAP en échec à diagnostiquer à partir de sa sortie.
Ansible ou Terraform : quel profil pour quel besoin ?
Terraform crée et détruit des ressources d'infrastructure en gardant un état, surtout dans le cloud. Ansible configure des systèmes déjà présents et orchestre des opérations : correctifs, déploiements, changements réseau. Beaucoup d'équipes utilisent les deux. Si le poste porte sur un parc de serveurs ou d'équipements à configurer, un profil Ansible vient en premier. Le socle système se vérifie alors autant que l'outil.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
