Questions d’entretien DevOps Engineer au Sénégal

📌 Pilier : Carrière DevOps et Cloud au Sénégal — guide complet (à créer)
Voisins : Data Scientist · Développeur Full-Stack · Décrocher un job de dev remote en Afrique de l’Ouest

Que fait un DevOps Engineer ?

Un DevOps Engineer est l’ingénieur qui rapproche le développement applicatif et l’exploitation : il automatise les pipelines de livraison, gère l’infrastructure comme du code, supervise la production et tient les indicateurs de fiabilité. Sur les offres scrapées en mai 2026, les missions reviennent à provisionner et opérer des clusters Kubernetes, à construire des pipelines de CI/CD avec Jenkins ou GitLab CI, à instrumenter la supervision avec Prometheus et Grafana, et à coder les modules Terraform pour AWS ou un cloud privé. Vous travaillez aux côtés des équipes produit, sécurité et SRE chez des recruteurs tels qu’Alten Senegal, Wave ou les filiales d’opérateurs télécoms à Dakar.

Stack technique attendue à Dakar

Sur les deux offres DevOps Engineer analysées (mai 2026), une grande variété de technologies revient ; voici celles qui dominent et que les recruteurs vérifient en priorité :

• Kubernetes — citée dans les deux offres : orchestration des conteneurs en production, à pratiquer concrètement (manifests, helm, ingress). Référence utile : Sauvegardes Kubernetes avec Velero pas-à-pas.
• Terraform — IaC standard du marché, mention dans les deux offres. Côté tutoriels : Provisioning Hetzner avec Terraform — premier projet IaC et Modules Terraform réutilisables.
• Ansible — gestion de configuration, héritage encore très présent sur l’infra existante. Tutoriel : Déployer une application Node.js avec Ansible et systemd.
• Jenkins — toujours présent dans les SI sénégalais, en cohabitation avec GitLab CI plus récent. Pour le pipeline complet : Intégrer SAST + SCA + DAST dans un pipeline GitLab CI.
• Prometheus + Grafana — supervision et alertes, exigence très fréquente.
• PostgreSQL et SQL Server — bases applicatives à exploiter (sauvegardes, réplication, performances).
• Docker — pré-requis implicite, jamais demandé seul, toujours combiné à Kubernetes.

Si vous débutez et devez choisir un ordre d’apprentissage, commencez par Docker puis Terraform, et seulement après Kubernetes — c’est l’ordre que les recruteurs vérifient en premier sur un junior.

Salaire moyen au Sénégal pour ce poste

Sur les deux offres DevOps observées en mai 2026, aucune n’affichait de salaire explicite (c’est le cas pour environ 70 % des offres tech locales). Croisé avec les fourchettes du marché ouest-africain (sources : Talent.com, Glassdoor, Talent2Africa, Africashore), la grille suivante représente le marché DevOps sénégalais à cette date. Le DevOps tire fort en 2024-2026 : forte demande, peu de profils certifiés AWS Solutions Architect Pro ou CKA Kubernetes, ce qui pousse les fourchettes hautes vers le haut.

En freelance, le TJM d’un profil confirmé tourne autour de 120 000 – 200 000 – 350 000 FCFA selon la rareté de la stack et la part de télétravail international. Pour préparer la conversation rémunération côté candidat : Négocier son salaire de dev en CFA et USD — guide Afrique de l’Ouest.

Questions d’entretien & réponses

Question 1 : Quelle est la différence entre un déploiement blue-green et un déploiement canary ?

Ce que cherche vraiment le recruteur

Cette question vérifie que vous comprenez les stratégies de mise en production avancées, qui sont au cœur du métier. Le recruteur évalue votre capacité à choisir la bonne stratégie selon le contexte applicatif : criticité du service, capacité à mesurer l’impact en temps réel, contraintes de retour arrière. Il guette une réponse structurée qui mentionne la mise en parallèle de deux environnements identiques pour le blue-green, et le déploiement progressif par tranche de trafic pour le canary, ainsi que les outils concrets qui les supportent (Argo Rollouts, Flagger, Spinnaker).

Exemple de réponse

Le blue-green déploie la nouvelle version sur un environnement distinct identique à la production, puis bascule le trafic d’un coup en mettant à jour le routeur ou le load balancer. Le retour arrière est instantané, mais on consomme le double de ressources le temps du basculement. Le canary, lui, expose progressivement un pourcentage du trafic (5 %, puis 25 %, puis 100 %) vers la nouvelle version, en observant les métriques de fiabilité avant chaque palier. C’est plus économe en ressources et permet de détecter des régressions partielles, mais le retour arrière demande plus de coordination. Sur AWS, le canary se gère bien avec CodeDeploy ou Argo Rollouts ; le blue-green se fait avec des Target Groups distincts derrière un ALB.

Question 2 : Expliquez le rôle d’un Pod, d’un Deployment et d’un Service dans Kubernetes.

Ce que cherche vraiment le recruteur

Question fondamentale qui tri rapidement les candidats. Le recruteur cherche à savoir si vous maîtrisez le vocabulaire Kubernetes de base et la séparation des responsabilités entre les objets. Un Pod est l’unité d’exécution la plus petite, un Deployment garantit la disponibilité d’un nombre de répliques, un Service expose ces répliques sur un point d’entrée stable. La réponse doit être courte mais précise, sans confondre les rôles.

Exemple de réponse

Un Pod regroupe un ou plusieurs conteneurs partageant le même réseau et le même stockage, c’est l’unité d’exécution gérée par Kubernetes. Un Deployment décrit l’état désiré — combien de répliques de tel Pod, avec quelle image — et le contrôleur s’assure que cet état est respecté en permanence : si un Pod meurt, le Deployment en recrée un. Le Service donne une adresse IP et un nom DNS stables à un ensemble de Pods sélectionnés par labels, pour que les autres applications communiquent avec eux sans connaître l’IP volatile de chaque Pod. En production, on combine généralement Deployment + Service ClusterIP + Ingress pour exposer un service HTTP.

Question 3 : Vous devez déployer une infrastructure AWS multi-environnements avec Terraform. Comment structurez-vous vos modules ?

Ce que cherche vraiment le recruteur

Le recruteur évalue votre maturité sur l’IaC : passage à l’échelle, réutilisation, séparation des environnements (dev, staging, prod), gestion du tfstate distant. Il guette les pièges classiques — un seul fichier monolithique, secrets en clair, dépendances cycliques entre modules. Une bonne réponse mentionne le backend distant verrouillé, la promotion progressive entre environnements et l’usage de workspaces ou de répertoires séparés.

Exemple de réponse

Je structure le code en deux couches : des modules génériques réutilisables (réseau, EKS, RDS, IAM) dans un dépôt terraform-modules, versionnés par tag Git, et des appels de modules par environnement dans infra/{dev,staging,prod} avec un fichier main.tf qui consomme les modules en fixant les versions. Le backend est S3 chiffré avec verrou DynamoDB, un par environnement. Les variables sensibles passent par AWS Secrets Manager via data sources, jamais en clair. La promotion se fait par PR : un changement passe en dev, est validé en staging, puis appliqué en prod via une CI Jenkins ou GitLab CI qui exécute terraform plan puis terraform apply avec approbation manuelle. Voir le détail dans le tutoriel Modules Terraform réutilisables pour PME.

Question 4 : Comment instrumentez-vous une application pour mesurer la latence et les erreurs avec Prometheus ?

Ce que cherche vraiment le recruteur

Question de mise en pratique sur la stack observabilité standard. Le recruteur veut savoir si vous comprenez le modèle pull de Prometheus, les types de métriques (Counter, Gauge, Histogram, Summary), l’exposition via un endpoint /metrics, et l’usage de Grafana pour la visualisation. Il guette aussi la mention des SLO/SLI — vocabulaire SRE qui sépare le candidat junior du confirmé.

Exemple de réponse

J’expose les métriques applicatives via la bibliothèque cliente Prometheus du langage : prom-client en Node, prometheus-client en Python, le starter Micrometer en Spring Boot. L’application publie sur /metrics quatre indicateurs essentiels : un Counter pour le nombre total de requêtes, un Histogram pour la latence (buckets adaptés au SLO, par exemple 50ms, 100ms, 500ms, 1s), un Counter pour les erreurs HTTP 5xx, et une Gauge pour les jauges métier (connexions actives, files d’attente). Prometheus scrape ce endpoint toutes les 15 secondes. Sur Grafana, je construis un dashboard RED (Rate, Errors, Duration) par service et je configure des alertes Alertmanager sur les SLO : par exemple, alerte si le taux d’erreur dépasse 1 % sur 5 minutes ou si le 95e percentile de latence dépasse le seuil contractuel.

Question 5 : Une production tombe à 3 h du matin, votre dashboard Grafana montre que les pods en boucle de redémarrage. Décrivez vos premières actions.

Ce que cherche vraiment le recruteur

Mise en situation classique d’astreinte. Le recruteur évalue votre méthode de diagnostic sous pression : par où commencer, comment isoler la cause sans aggraver l’incident, quand escalader. Une bonne réponse suit une séquence ordonnée — accusé de réception de l’alerte, isolation, diagnostic, action conservatoire, post-mortem.

Exemple de réponse

J’accuse réception de l’alerte sur le canal d’astreinte pour signaler que je prends en charge l’incident, puis j’ouvre le runbook du service concerné s’il existe. J’identifie d’abord la portée : un seul Pod ou tous les Pods du Deployment, un seul nœud ou plusieurs, un environnement ou tous. La commande kubectl describe pod me montre l’événement de redémarrage et kubectl logs --previous les logs avant le crash. Si c’est un OOMKilled, j’augmente temporairement la limite mémoire. Si c’est un déploiement récent, je rollback avec kubectl rollout undo deployment/<nom>. En parallèle, je vérifie les dépendances : base de données saturée, certificat TLS expiré, secret manquant. Je documente chaque action dans un ticket d’incident en temps réel. Si après 30 minutes la cause reste opaque, j’escalade à l’astreinte N2 sans attendre.

Question 6 : Décrivez un conflit en équipe que vous avez géré entre les développeurs et la sécurité.

Ce que cherche vraiment le recruteur

Question comportementale au format STAR (Situation, Tâche, Action, Résultat). Le recruteur veut tester votre capacité à arbitrer entre vélocité des développeurs et exigences de sécurité — tension récurrente du métier DevOps. Il guette la diplomatie, la recherche de compromis chiffré, l’usage d’un cadre objectif plutôt que d’une bataille d’autorité.

Exemple de réponse

Sur un projet précédent, l’équipe sécurité bloquait la sortie d’une fonctionnalité parce qu’une dépendance npm contenait une vulnérabilité de sévérité moyenne, sans correctif publié. Les développeurs voulaient sortir quand même pour tenir la date promise au client. J’ai organisé une réunion de 30 minutes avec les deux camps pour qualifier le risque réel : la vulnérabilité concernait un module non utilisé par notre chemin d’exécution, confirmé par audit du code. Nous avons documenté l’analyse, ajouté un test automatisé interdisant l’usage du module incriminé, et mis la dépendance sur une liste de surveillance avec revue à 30 jours. La fonctionnalité est sortie, la sécurité a validé, et nous avons institué cette procédure pour les futurs cas similaires.

Question 7 : Comment gérez-vous une astreinte avec un client basé à Paris quand vous êtes à Dakar ?

Ce que cherche vraiment le recruteur

Question locale Afrique de l’Ouest spécifique aux profils confirmés et seniors, qui travaillent fréquemment avec des donneurs d’ordre européens. Le recruteur évalue votre capacité à gérer le décalage horaire (Paris est à GMT+1 ou GMT+2, Dakar à GMT+0), la communication asynchrone, et la clarté écrite en français comme en anglais. Il guette une réponse pragmatique sur les outils et la discipline personnelle.

Exemple de réponse

Le décalage est faible — une à deux heures selon la saison — ce qui facilite le travail synchrone en journée. Pour l’astreinte, je distingue les fenêtres d’intervention : les incidents critiques (production en panne) sont traités immédiatement quelle que soit l’heure, avec un accusé de réception sur Slack ou PagerDuty dans les 15 minutes. Les demandes non urgentes basculent en mode asynchrone : je réponds sur un ticket Jira ou un thread Slack en début de journée, avec un horaire de réponse garanti précisé dans le SLA. Je tiens à jour un runbook partagé pour que mon homologue côté Paris puisse prendre le relais sans contexte additionnel. Le français écrit est exigé sans accent forcé, l’anglais technique aussi pour la documentation et les communications avec les éditeurs.

Difficulté de l’entretien

8 / 10 — Difficile

Le process tient généralement en quatre étapes : pré-qualification RH, entretien technique avec un Tech Lead, test pratique (souvent un exercice Terraform ou un diagnostic Kubernetes en 90 minutes), et entretien final avec le manager d’équipe ou le DSI. Le live-coding n’est pas systématique mais la maîtrise de l’anglais technique en lecture est presque toujours vérifiée car la documentation et les éditeurs cloud sont en anglais. Pour les postes seniors et leads, une présentation d’architecture s’ajoute. Le délai moyen de réponse se situe entre dix et vingt jours ouvrés.

Difficulté du métier

8 / 10 — Difficile

Le quotidien DevOps mêle pression d’astreinte, étendue de stack à maintenir (réseau, sécurité, conteneurs, observabilité, IaC, scripts), et veille techno permanente — Kubernetes change rapidement, AWS publie de nouveaux services chaque mois, et les CVE de sécurité dans les images conteneurs imposent des mises à jour fréquentes. Le risque opérationnel est élevé : une mauvaise mise en production peut couper un service à des milliers d’utilisateurs, et la responsabilité du retour à la normale repose sur l’équipe. L’autonomie attendue est forte dès le niveau confirmé : le DevOps prend des décisions techniques structurantes, souvent sans validation hiérarchique en temps réel. Métier exigeant, recherché, et bien rémunéré en conséquence.

Pré-requis pour ce poste

• Diplôme Bac+3 à Bac+5 en informatique, ou expérience démontrée équivalente.
• Expérience minimale typique : 2 à 5 ans en système, réseau ou développement avec exposition à l’infra.
• Maîtrise solide de Linux (administration, scripting bash, systemd, journald) et de Git.
• Connaissance opérationnelle de Docker et Kubernetes (manifests, helm, debug en CLI).
• Pratique de Terraform ou d’un autre outil IaC sur au moins un cloud public.
• Bases en CI/CD avec Jenkins ou GitLab CI et compréhension des modèles de pipelines.
• Anglais technique lu et écrit (documentation cloud, GitHub, Stack Overflow) — exigence universelle.
• Anglais professionnel oral souhaitable pour les missions avec donneurs d’ordre internationaux.
• Certification AWS Solutions Architect Associate ou Pro, CKA Kubernetes, ou Terraform Associate : non obligatoire mais bouge la fourchette salariale de 20 à 40 %.

Pour aller plus loin

Si vous visez aussi un poste de Développeur Full-Stack ou de Data Scientist, notre bibliothèque d’articles entretien détaille les points communs et les divergences techniques entre ces métiers.

Pour combler les bases du DevOps moderne, parcourez notre pilier DevOps moderne pour PME : guide CI/CD et IaC, puis attaquez la certification HashiCorp Terraform Associate (004) ou le parcours AWS DevOps Engineer Professional DOP-C02 qui calibre votre niveau face aux exigences du marché ouest-africain.

→ Voir tous les articles du cluster (à créer)

Autres entretiens techniques

• Réussir un entretien technique en anglais : préparation, scripts, mock interviews
• Questions d’entretien Développeur Full-Stack au Sénégal
• Questions d’entretien Développeur Frontend Angular au Sénégal
• Questions d’entretien Data Scientist au Sénégal
• Questions d’entretien Développeur Mobile multi-plateformes au Sénégal