Portfolio Projects for Cloud Engineer

Vous avez trois certifications cloud et zéro retour d'entretien. Le problème n'est pas votre niveau. C'est que vos projets ressemblent à ceux de tout le monde, et qu'un recruteur technique le voit en dix secondes.

Un portfolio cloud, ça ne sert pas à prouver que vous savez lancer une machine. Ça sert à montrer que vous prenez des décisions, que vous documentez, et que vous savez quand quelque chose casse. Voici trois projets qui font ça, et comment les présenter pour qu'ils travaillent pour vous.

Ce que les recruteurs regardent vraiment#

Ils ne lisent pas votre README en entier. Ils scannent. Ils cherchent trois choses : est-ce que le projet a un objectif clair, est-ce que les choix techniques sont justifiés, et est-ce que le code montre une vraie main dessus.

Le dernier point est le plus dur. Un dépôt qui ne contient que du YAML copié d'un tutoriel se repère vite. Les noms de variables génériques, l'absence de commentaires, aucune trace d'itération : tout ça crie "je suis allé jusqu'à l'étape 12 du guide".

Ce qui attire l'œil à l'inverse : une architecture avec des arbitrages assumés, des coûts estimés, une section "ce qui a planté et comment je l'ai résolu", et des scripts qui montrent que vous avez automatisé quelque chose de pénible.

Projet 1 : une infrastructure multi-environnements avec Terraform#

L'idée : déployer la même application en dev, staging et prod, avec des états Terraform séparés, des modules réutilisables, et un pipeline qui planifie avant d'appliquer.

Ce qui le rend intéressant, c'est la gestion des environnements. La plupart des candidats dupliquent un dossier. Vous, vous écrivez un module et vous l'appelez trois fois avec des variables. Vous documentez pourquoi vous avez séparé les états plutôt que d'utiliser des workspaces.

Exemple concret de présentation

Mauvaise ligne sur le CV :

• Mise en place d'une infrastructure cloud avec Terraform

Ligne réécrite :

• Infrastructure multi-environnements (dev/staging/prod) sur AWS avec Terraform : 14 modules réutilisables, états isolés sur S3 avec verrouillage DynamoDB, pipeline GitLab qui exécute terraform plan sur chaque merge request. Réduction du temps de déploiement de 45 minutes à 6 minutes.

La deuxième version dit quoi, pour qui, avec quel outil, et avec quel résultat. C'est ça qu'on retient.

Projet 2 : une plateforme d'observabilité qui répond à une vraie question#

L'idée : instrumenter une application, collecter les logs, les métriques et les traces, et construire des alertes qui ne réveillent personne pour rien.

Choisissez un scénario précis. Par exemple : une API de commande qui doit répondre en moins de 200 ms au 95e centile, avec une alerte sur le taux d'erreur 5xx et un dashboard qui montre la latence par endpoint. Le choix de l'outil importe moins que la logique derrière.

Ce que les recruteurs veulent voir ici : est-ce que vous savez définir un SLI, est-ce que vous comprenez le coût du bruit d'alerte, et est-ce que vous avez pensé à ce qui se passe quand le système de monitoring lui-même tombe. Documentez vos seuils et pourquoi vous les avez fixés ainsi.

Projet 3 : une chaîne de livraison avec sécurité intégrée#

L'idée : un pipeline CI/CD qui construit une image, la scanne, la pousse dans un registre privé, et la déploie avec une stratégie blue-green ou canary.

Ajoutez une couche sécurité. Un scan de dépendances, une analyse de secrets dans l'historique Git, des politiques de réseau qui limitent qui peut parler à quoi. Vous n'avez pas besoin d'être expert en sécurité. Vous devez montrer que vous ne la traitez pas comme une étape optionnelle à la fin.

Le point fort de ce projet : il montre que vous comprenez le cycle de vie complet, du commit à la production, et que vous savez ce qu'est un rollback. Peu de portfolios juniors vont jusque-là.

Comment présenter ça sur GitHub#

Votre dépôt est un produit. Traitez-le comme tel. Un recruteur passe moins de deux minutes dessus avant de décider s'il continue.

• Un README qui commence par une phrase décrivant le problème résolu, pas par une liste de technologies
• Un schéma d'architecture simple, même fait à la main, qui montre les flux de données
• Une section "Choix techniques" avec deux ou trois arbitrages expliqués, y compris ce que vous avez écarté
• Une section "Ce qui a cassé" avec un ou deux incidents réels et leur résolution
• Des instructions de reproduction qui fonctionnent, testez-les sur une machine propre
• Un fichier de coûts estimés, même approximatif, pour montrer que vous pensez budget
• Des captures d'écran du résultat final : dashboard, pipeline vert, alerte déclenchée

Un dépôt avec un seul commit "initial" et un autre "final" ne passe pas. Poussez votre travail au fur et à mesure. L'historique Git est une preuve de travail réel.

Les erreurs qui font "tutoriel" en un coup d'œil#

La plus fréquente : reprendre un projet de formation sans rien changer, avec les mêmes noms de ressources et la même région. Si le recruteur a vu ce tutoriel, votre candidature est morte.

La deuxième : lister dix technologies dans le README sans dire pourquoi. "Docker, Kubernetes, Terraform, Ansible, Prometheus, Grafana" sans contexte, ça ne dit rien de votre jugement.

La troisième : aucune gestion des erreurs. Pas de try, pas de retry, pas de logging dans vos scripts. Un script qui échoue silencieusement, c'est un signal négatif très fort.

Enfin, ne mentez pas sur les résultats. Si vous n'avez pas mesuré, ne dites pas "amélioration de 80 %". Dites "le pipeline passe de 12 à 4 étapes manuelles". C'est vérifiable et ça compte autant.

Comment en parler en entretien#

Préparez un récit de trois minutes par projet. La structure : le problème, votre approche, une difficulté rencontrée, la solution, le résultat. Restez concret.

Exemple de réponse

"J'ai construit une plateforme de monitoring pour une API de commande parce qu'on recevait des alertes toutes les heures sans savoir si c'était grave. J'ai défini trois SLI : latence au 95e centile, taux d'erreur 5xx, et saturation mémoire. J'ai calé les seuils sur une semaine de données réelles plutôt qu'au feeling. Le point dur, c'était le bruit : mes premières alertes sur la latence se déclençaient à chaque batch nocturne. J'ai ajouté une fenêtre glissante de 15 minutes et un blackout pendant les traitements. Résultat, le nombre d'alertes de nuit est passé de une vingtaine par semaine à deux ou trois."

Ce type de réponse montre que vous avez touché du doigt un vrai problème. C'est bien plus fort qu'une liste d'outils.

On va vous poser des questions de fond : pourquoi pas une autre approche, qu'est-ce que vous referiez différemment, comment ça se comporte à dix fois la charge. Préparez ces réponses à l'avance en étant honnête sur les limites de votre projet.

Où trouver l'inspiration et les offres#

Regardez les offres d'emploi pour les postes qui vous visent et repérez les compétences revendues. C'est le meilleur guide pour choisir votre prochain projet, et c'est plus fiable que n'importe quelle liste générique. Vous pouvez consulter les offres cloud et DevOps sur notre moteur d'offres et décoder les annonces pour comprendre ce qui se cache derrière les intitulés flous avec notre analyseur d'offres.

Un dernier point : faites vérifier votre CV par un outil qui simule la lecture d'un ATS avant d'envoyer, c'est gratuit avec notre vérificateur de CV, et lisez nos autres guides sur le blog pour creuser la préparation d'entretien.

Outils gratuits#

• jobrise.io/fr/free-ats-checker/
• jobrise.io/fr/free-jd-decoder/
• jobrise.io/fr/jobs/
• jobrise.io/fr/blog/

Questions fréquentes#

Faut-il des certifications cloud si j'ai un bon portfolio ?

Les deux ne se remplacent pas tout à fait. La certification rassure sur un socle de connaissances, le portfolio montre votre façon de travailler. Si vous devez choisir, un portfolio solide avec deux projets aboutis passe souvent mieux qu'une certification de plus sans preuve de pratique.

Combien de projets faut-il dans un portfolio cloud ?

Deux ou trois projets aboutis valent mieux que dix projets esquissés. Choisissez ceux qui couvrent des compétences différentes : infrastructure, observabilité, livraison. Mieux vaut un dépôt impeccable que cinq dépôts à moitié finis.

Puis-je utiliser un projet de formation comme base ?

Oui, à condition de le transformer en profondeur. Changez le scénario, ajoutez des environnements, une couche sécurité, une gestion d'erreur, et documentez vos propres choix. Si votre dépôt est identique à celui du tutoriel, il ne vous apporte rien.

Faut-il publier le code en open source ?

C'est préférable, un dépôt privé qu'on ne peut pas voir ne sert pas grand chose. En revanche, ne publiez jamais de secrets, de clés d'accès ou de données réelles. Utilisez des variables d'environnement et un outil de détection de secrets avant chaque push.

Combien de temps faut-il pour construire ces trois projets ?

En travaillant à côté d'un emploi, comptez trois à six semaines par projet si vous partez de bases correctes. Le plus long n'est pas le code, c'est la documentation et les tests de reproduction. C'est justement cette partie qui fera la différence à la lecture.