Portfolio Projects for DevOps Engineer

Vous avez trois certificats cloud et toujours aucune réponse après 40 candidatures. Le problème n'est pas le certificat. C'est que personne ne voit ce que vous savez faire quand rien ne tourne comme prévu.

Un recruteur technique passe rarement plus de deux minutes sur un profil. Il cherche des preuves de décisions, pas des badges. Voici trois projets qui donnent ces preuves, et la façon de les présenter pour qu'ils travaillent à votre place.

Pourquoi les projets battent les certificats#

Un certificat dit que vous avez retenu une matière. Un projet montre que vous avez pris une décision technique, accepté un compromis, puis nettoyé le désordre. C'est exactement le quotidien du poste.

Les certificats restent utiles pour passer un filtre RH ou valider une stack imposée par l'entreprise. Mais à eux seuls, ils ne décollent pas un profil. Un dépôt GitHub avec un vrai pipeline et un post-mortem, ça, ça décolle.

Projet 1 : une chaîne CI/CD qui refuse un mauvais commit#

Le projet classique, c'est un pipeline qui build et déploie. Tout le monde a le même. Le vôtre doit montrer que vous savez dire non.

Prenez une petite application web, même une API de trois endpoints. Branchez dessus une chaîne qui exécute des tests, une analyse de code, un scan de vulnérabilités sur l'image Docker, puis un déploiement conditionnel. Ajoutez une règle : si le scan trouve une CVE au-dessus d'un seuil, le build échoue et personne ne déploie.

Ce qui fait la différence, c'est le journal. Dans le dépôt, documentez une fois où le pipeline a bloqué quelque chose, pourquoi vous avez choisi ce seuil, et ce que ça a coûté en temps de build. Un arbitrage assumé vaut dix pages de README.

Exemple de ligne de CV

Avant : "Mise en place d'une chaîne CI/CD avec GitHub Actions et Docker."

Après : "Chaîne CI/CD sur GitHub Actions : build, tests, scan de CVE bloquant sur image Docker, déploiement auto sur staging. Réduit le temps de mise en prod de 2 jours à 40 min, 3 blocages de release évités sur 6 mois."

La deuxième version dit la stack, le résultat et la limite. Elle donne envie de poser une question, ce qui est tout ce qu'on demande à une ligne de CV.

Projet 2 : de l'infrastructure modulaire, avec un état partagé#

Tout le monde fait un Terraform qui crée une machine virtuelle. Faites mieux : un module réutilisable, un état distant, et deux environnements qui partagent le même code.

Concrètement, un module "réseau" et un module "service", appelés deux fois, une pour staging et une pour prod, avec des variables différentes. L'état Terraform stocké dans un bucket avec verrouillage. Un plan automatisé à chaque pull request, commenté sur la PR.

Montrez surtout la gestion de la dérive. Ajoutez une tâche planifiée qui compare l'infrastructure réelle à l'état attendu et ouvre une alerte en cas d'écart. C'est un sujet que personne ne couvre dans les tutoriels, et c'est celui qui arrive en production dès le premier mois.

Ce que le reviewer cherche à voir

• Un état distant avec verrouillage, pas un state local commité par erreur
• Des modules avec des entrées et sorties claires, pas un gros main.tf de 400 lignes
• Un plan Terraform affiché dans la PR, avant le merge
• Une gestion explicite des secrets, jamais de clé en clair dans le dépôt
• Un README qui explique comment détruire proprement l'environnement
• Un exemple de dérive détectée et corrigée

Projet 3 : de l'observabilité qui déclenche une action#

Un dashboard Grafana, tout le monde en a un. La question, c'est : et après ?

Montez une stack de supervision sur votre projet précédent. Métriques, logs, traces si vous voulez pousser. Puis ajoutez l'étape qui manque à 90 % des portfolios : une alerte qui arrive quelque part et une réponse documentée.

Un seuil de latence, une notification sur un canal, un playbook d'une page qui dit quoi regarder en premier. Et surtout, un post-mortem rédigé comme si l'incident était réel : chronologie, cause, action corrective, date de vérification. Trois pages suffisent.

Ce document est l'artefact le plus fort de votre portfolio. Il montre que vous pensez en termes de service rendu, pas seulement d'outils installés.

Comment présenter ça sur GitHub#

Un dépôt propre se lit en deux minutes. Faites en sorte que ce soit possible.

• Un README qui commence par le problème résolu, pas par la liste des outils
• Un schéma d'architecture simple, une image PNG lisible sur téléphone
• Une section "Comment déployer chez vous" avec les commandes exactes
• Un fichier décrivant les compromis retenus et les pistes abandonnées
• Des dépôts séparés pour des projets distincts, pas tout dans un monolithe
• Une licence explicite et un .gitignore sérieux, aucun secret jamais commité

Piquez vos dépôts dans GitHub et retirez les anciens projets abandonnés. Trois dépôts solides battent quinze dépôts morts. Vous pouvez aussi passer votre CV dans notre vérificateur de CV compatible ATS pour voir si les mots-clés techniques ressortent bien.

Les erreurs qui font "tutoriel"#

Un reviewer reconnaît un clone de tutoriel en trente secondes. Voici les signaux qui tuent un projet.

Le README qui commence par "Dans ce projet nous allons apprendre à...". Vous ne formez personne, vous prouvez quelque chose. Le dépôt qui contient exactement les fichiers de la vidéo, sans une seule modification. L'absence totale de problème rencontré, comme si tout avait marché du premier coup.

Autre signal : la stack gonflée pour faire joli. Kubernetes pour trois endpoints, une grille complète de douze outils, un pipeline de 40 étapes. Un reviewer aguerri y voit de la peur de choisir, pas de la maîtrise.

Enfin, le dépôt sans historique. Un commit unique "final project" ne raconte rien. Un historique avec des messages normaux, des corrections, une revert, ça raconte une méthode de travail.

Comment en parler en entretien#

Ne récitez pas la liste des outils. Racontez une décision et sa conséquence.

Bonne réponse à "parlez-moi de votre projet CI/CD"

"J'ai monté une chaîne pour une petite API, avec un scan de CVE qui bloque le build au-dessus d'un certain seuil. Au début j'avais mis le seuil trop bas, chaque build échouait sur des failles sans impact réel et l'équipe perdait une heure par jour à relancer. J'ai passé une soirée à classer les CVE par sévérité et par exposition réelle, puis remonté le seuil. Ça nous a fait perdre une couverture théorique, mais le pipeline est redevenu crédible et personne ne l'a plus contourné."

Cette réponse contient un choix, une erreur, une correction. C'est exactement ce qu'on évalue.

Préparez ces réponses à l'avance

• Le compromis technique dont vous êtes le moins fier, et pourquoi
• Ce que vous feriez autrement avec deux semaines de plus
• La partie du projet qui casserait en premier sous dix fois plus de charge
• Comment vous vérifiez qu'un déploiement s'est bien passé
• Ce que vous avez supprimé, et la raison de cette suppression

Pour trouver des offres où ces projets feront la différence, parcourez nos offres d'emploi en DevOps et cloud. Et si vous préparez plusieurs entretiens, nos guides de préparation aux entretiens donnent des scripts concrets.

Questions fréquentes#

Faut-il publier ses projets en open source ?

Oui, sauf si le code contient des informations liées à un ancien employé ou à un client. Un dépôt public est la seule façon pour un reviewer de juger votre travail sans vous appeler. Sinon, un dépôt privé partagé sur demande passe aussi, mais beaucoup de recruteurs ne prendront pas la peine de demander.

Combien de projets faut-il dans un portfolio DevOps ?

Trois projets aboutis valent mieux que dix esquisses. Visez deux projets solides et un troisième plus ambitieux qui montre une montée en charge ou une gestion d'incident. Un seul projet très abouti peut suffire pour un premier poste junior.

Mes projets personnels doivent-ils utiliser les mêmes outils que l'annonce ?

En partie, oui. Repérez les outils récurrents dans les offres qui vous intéressent et alignez un projet dessus, sans copier mot pour mot l'annonce. Le décodeur d'offres d'emploi aide à repérer ce qui compte vraiment dans une annonce.

Est-ce que des projets sur des comptes cloud gratuits suffisent ?

Oui pour apprendre et pour montrer votre travail. Précisez simplement dans le README que le projet tourne sur un compte gratuit ou un cluster local, cela évite les questions sur la facture. Les reviewers regardent la méthode, pas le budget.

Dois-je mettre ces projets dans mon CV ou seulement sur GitHub ?

Les deux. Une ou deux lignes par projet dans le CV, avec un résultat chiffré si vous l'avez, et le lien GitHub en entête. Un reviewer qui lit le CV doit pouvoir trouver le code en un clic, sinon il ne le cherchera pas.