Le quotidien d'un ingénieur F5 tourne autour de LTM : virtual servers, pools, monitors, profils TCP, HTTP et SSL, persistance, SNAT. S'y ajoutent les iRules, BIG-IP DNS (l'ancien GTM) pour répartir entre datacenters, les paires en haute disponibilité et l'automatisation avec AS3 ou Ansible. Les offres parlent d'ingénieur F5, d'ingénieur load balancing ou d'expert migration F5, et les questions d'entretien doivent suivre ce périmètre.
Beaucoup de projets actuels sont des migrations : anciens boîtiers vers des tenants sur rSeries ou VELOS sous F5OS, vers BIG-IP VE ou vers le cloud. Les CV qui citent F5 viennent souvent du réseau classique, avec une pratique limitée à la création de virtual servers. Le bon profil raconte une migration ou une bascule réellement menée, un incident de flux retour, un monitor réécrit après une panne non détectée.
Ce poste reste du côté réseau et applicatif. La politique WAF relève d'un autre profil, même si les deux se croisent sur le même boîtier. Le PDF propose 30 questions sur six axes, un cas de 20 minutes et une grille.
Les briques F5 qu'un ingénieur load balancing configure
BIG-IP LTM
Le module de répartition de charge, sur lequel passe la plus grande part du travail. Un virtual server reçoit le trafic, l'envoie vers un pool de serveurs surveillés par des monitors, avec des profils qui décident du traitement TCP, HTTP et TLS. Le BIG-IP fonctionne en proxy complet : il tient une connexion avec le client et une autre avec le serveur.
Profils TCP, HTTP, OneConnect et SNAT
Les profils règlent le comportement de chaque côté de la connexion : délais d'inactivité, optimisation, insertion d'en-têtes, réutilisation des connexions serveurs. La SNAT garantit que la réponse des serveurs revient par le BIG-IP, au prix de l'adresse du client qu'il faut transmettre autrement.
Profils client-SSL et server-SSL
Le BIG-IP termine le TLS des clients, porte les certificats, choisit versions et chiffrements, et re-chiffre au besoin vers les serveurs. Avec des certificats publics limités à 200 jours depuis mars 2026, le renouvellement devient une tâche fréquente à outiller.
iRules et Local Traffic Policies
Les policies aiguillent et réécrivent sans code. Les iRules, écrites en Tcl, couvrent les cas que les policies ne savent pas traiter. Une bonne personne sait quand s'en passer et mesurer leur coût.
BIG-IP DNS (ex-GTM)
La répartition entre datacenters par le DNS : wide IP, pools de virtual servers, méthodes de répartition, état des sites remonté des LTM par iQuery. Sa présence sur un CV signale souvent des architectures multi-sites.
Haute disponibilité
Les paires actif-secours ou actif-actif, avec device group, synchronisation de configuration, traffic groups et adresses flottantes. Le mirroring des connexions et de la persistance décide de ce que voit l'utilisateur pendant une bascule.
TMOS, F5OS, rSeries, VELOS et VE
TMOS est le système historique du BIG-IP, dont les branches récentes comprennent 17.x et 21.x. Les nouvelles plateformes rSeries et VELOS tournent sous F5OS et accueillent des instances BIG-IP appelées tenants. BIG-IP VE est la version virtuelle, sur hyperviseur ou dans le cloud.
AS3, Ansible et Terraform
AS3 décrit une application en JSON déclaratif et la déploie par API. Ansible et Terraform l'appellent dans les chaînes d'automatisation. Les offres françaises citent souvent Ansible à côté de F5.
Alternatives : NetScaler, HAProxy, NGINX
NetScaler (ex-Citrix ADC), HAProxy et NGINX occupent le même terrain. Un profil F5 qui les connaît compare mieux les fonctions et prépare les migrations dans un sens ou dans l'autre.
Le poste existe chez les intégrateurs et ESN qui exploitent ou migrent des parcs F5, chez les hébergeurs et chez les clients finaux qui publient beaucoup d'applications. En run, l'ingénieur crée et modifie des publications, traite les incidents et applique les correctifs, sujet sensible depuis l'intrusion chez F5 révélée en octobre 2025. En build, il conçoit les architectures multi-sites et mène les migrations vers F5OS ou BIG-IP VE. Les certifications F5-CA BIG-IP et F5-CTS BIG-IP LTM attestent la connaissance du produit, la pratique se vérifie en entretien.
Ce que l'entretien F5 doit couvrir
- Objets LTM et monitors
- Flux, SNAT et profils
- TLS et certificats
- iRules et automatisation
- Haute disponibilité et BIG-IP DNS
- Diagnostic et migration
Cinq questions pour un ingénieur F5 LTM
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 · confirmé
Une nouvelle application passe derrière le BIG-IP. Les serveurs reçoivent bien les requêtes, mais les réponses n'arrivent jamais aux clients. Que soupçonnez-vous ?
Une bonne réponseUn retour asymétrique : la passerelle des serveurs n'est pas le BIG-IP, donc la réponse part directement vers le client, qui la rejette car elle ne vient pas de l'adresse du virtual server. Deux remèdes : la SNAT (Automap ou un SNAT pool) ou le BIG-IP comme passerelle des serveurs. Il connaît la contrepartie de la SNAT, l'adresse du client perdue côté serveur, et le risque d'épuisement des ports avec une seule adresse de translation pour beaucoup de connexions.
Signal d'alerteAccuser le pare-feu sans capture, ou activer Automap partout sans savoir ce qu'il change.
Question 2 · confirmé
Le monitor HTTP marque tous les membres du pool disponibles, mais l'application renvoie une page d'erreur. Comment écrivez-vous un monitor qui reflète l'état réel de l'application ?
Une bonne réponseUne send string complète en HTTP/1.1 avec l'en-tête Host, vers une page de santé que l'équipe applicative fait dépendre de la base et des services utiles. Une receive string qui cherche un contenu précis, pas un simple code 200, et une receive disable string pour vider un serveur avant maintenance. Il règle intervalle et timeout sur le modèle des valeurs par défaut de F5 (5 et 16 secondes), soit trois intervalles plus une seconde, pour qu'une seule sonde perdue ne retire pas un membre, et prend un monitor HTTPS si le serveur n'écoute qu'en TLS.
Signal d'alerteUn monitor TCP qui vérifie seulement que le port répond, ou le monitor http par défaut sans receive string.
Question 3 · confirmé
Un seul virtual server en 443 doit publier dix applications, chacune avec son certificat. Comment le configurez-vous ?
Une bonne réponsePlusieurs profils client-SSL portant chacun un nom de serveur SNI, dont un marqué par défaut pour les clients sans SNI, ou un certificat multi-domaines si le contexte le permet. Une Local Traffic Policy oriente ensuite chaque nom d'hôte vers son pool. Il précise les versions de TLS et les chiffrements, le re-chiffrement vers les serveurs si nécessaire, et l'organisation du renouvellement des certificats.
Signal d'alerteDix adresses IP, une par certificat, sans connaître SNI, ou un certificat unique imposé sans vérifier les noms couverts.
Question 4 · senior
Après une bascule de la paire BIG-IP, des utilisateurs doivent se reconnecter et certaines applications perdent leur session. Qu'est-ce qui manquait ?
Une bonne réponseLe mirroring des connexions sur les virtual servers concernés et celui de la persistance, qui ne sont pas activés par défaut. Il vérifie aussi que la configuration était synchronisée dans le device group sync-failover, que les floating self IP et les traffic groups ont bien basculé et que les équipements voisins ont mis à jour leur table ARP, avec MAC masquerade si besoin. Il distingue ce que le BIG-IP peut conserver et les sessions applicatives tenues par les serveurs.
Signal d'alerteCroire que tout l'état est copié automatiquement d'un membre à l'autre.
Question 5 · senior
Vous migrez une paire BIG-IP en fin de vie vers des tenants sur rSeries sous F5OS. Comment préparez-vous la bascule ?
Une bonne réponseUn inventaire des virtual servers, pools, monitors, iRules, profils et certificats, avec ce qui est encore utilisé. La version cible, le dimensionnement et la licence du tenant, les VLAN côté F5OS. Une conversion de configuration par UCS ou avec l'outil F5 Journeys, puis une relecture des iRules et profils qui changent entre versions. Des tests application par application sur des adresses de test, une bascule par vagues et un retour arrière prêt.
Signal d'alerteRestaurer l'UCS de l'ancien boîtier sur le nouveau et basculer tout le même soir.
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 F5 : questions fréquentes
Ingénieur F5 load balancing ou ingénieur F5 WAF : quel profil chercher ?
Le load balancing couvre la publication des applications : virtual servers, pools, monitors, TLS, SNAT, haute disponibilité, BIG-IP DNS. Le WAF ajoute les politiques de sécurité applicative, les faux positifs, la protection contre les robots. Beaucoup de parcs demandent les deux sur le même boîtier. Si le besoin principal est une migration ou l'exploitation des publications, un profil LTM solide suffit ; pour un projet de mise en blocage WAF, l'expérience dédiée s'impose.
Quelles certifications F5 regarder sur un CV ?
La F5-CA BIG-IP atteste l'administration de base. La F5-CTS BIG-IP LTM porte sur la publication d'applications et convient à ce poste. Elles montrent un examen réussi, pas l'expérience d'une bascule de paire ou d'une migration vers F5OS. Mieux vaut une configuration réellement construite, avec ses monitors, ses profils et ce qui a cassé lors de la mise en service.
Faut-il savoir écrire des iRules pour être ingénieur F5 ?
Sur un poste confirmé, oui : beaucoup de parcs en contiennent, et il faut au moins savoir les lire, les corriger et mesurer leur coût. Un bon profil sait aussi quand une Local Traffic Policy suffit. Sur un poste junior de run, la lecture d'une iRule simple peut suffire au départ. Le candidat explique une iRule du parc en place, ligne par ligne.
Quel test technique est donné à un ingénieur F5 ?
Le support est une configuration tmsh d'un virtual server avec son pool, son monitor et ses profils, suivie d'un symptôme : réponses perdues, membres disponibles alors que l'application est en erreur, sessions perdues après bascule. La personne donne la cause et la correction. Avec un BIG-IP VE de laboratoire, une publication HTTPS avec SNI à monter en vingt minutes montre la méthode.
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.
