Bonjour à toutes et à tous,
Je rejoins le forum après une formation de développeur web orientée DevOps que je viens de terminer. Christophe avait joint une collègue de formation qui m’a parlé de ce forum en retour. Je cherche à échanger avec des professionnels du domaine pour progresser et mieux comprendre les attentes concrètes du marché.
Mon parcours est un peu atypique. J’ai un master en enseignement à l’origine, j’ai été maître du jeu Donjons et Dragons pendant un peu plus de 2 ans puis j’ai décidé de me réorienter vers le développement web et les pratiques DevOps. J’ai travaillé sur plusieurs projets personnels et de formation, avec un stack orienté React, TypeScript, Node, PostgreSQL, ainsi que des bases solides en CI CD, conteneurisation et déploiement cloud (pour cette partie rien d’actif en ligne étant sorti de formation ce Novembre 2025)
Je m’intéresse particulièrement à tout ce qui touche à l’architecture, à l’automatisation, aux bonnes pratiques de sécurité et à la mise en production propre d’une application. Ayant un ami DevOps, j’ai pas mal échangé avec lui sur les réalités du métier pour en savoir plus sur le quotidien du métier et les tâches qui y sont liées.
Je suis preneur de retours d’expérience sur :
– les compétences réellement différenciantes pour un profil junior DevOps
– les erreurs fréquentes à éviter quand on débute
– les types de projets personnels qui font vraiment la différence pour obtenir un premier emploi dans le milieu. On me dit souvent qu’on ne peut (presque) pas devenir DevOps sans avoir déjà de l’expérience de dev
Au plaisir d’échanger avec vous et d’apprendre de vos retours.
Tanguy
Hello! Bienvenue sur le forum!
Effectivement, les missions du « DevOps » peuvent être très différentes d’une entreprise à une autre. Ça oscille entre support de l’équipe dev qui peut se résumer à faire des pipelines CI/CD, ou faire de l’admin système
Pour répondre à tes questions (selon mon avis sûrement périmé)
1- compétences differentiantes pour un profile junior: avoir eut une autre vie pro avant! Dev senior ou admin sys senior
2- erreur fréquente: appeler un chat un chien 
c’est un univers très large, on peut s’emmêler vite les pinceaux dans tout ces termes techniques. Blague à part, je dirais splitter le code (pas de terraform avec 100 ressources, pas de playbook Ansible qui font 1000 lignes, des règles de développeur au final), et chercher/demander si une solution de l’écosystème n’existe pas déjà avant de la développer.
3- projet perso: une app, packagée, déployée, avec de la ci/cd, et faire des essais de scaling, c’est parfait
2 « J'aime »
Bienvenue Tanguy !
Comme indiqué précédemment le monde du DevOps est large, et la réalité du marché aujourd’hui est que deux rôles « DevOps » présentés sur des offres d’emploi de deux entreprises différentes peuvent n’avoir presque rien en commun. Néanmoins les compétences techniques que tu listes, la capacité à avoir une compréhension globale du cycle de développement et de déploiement et un point de vue critique sur ce qui est en place sur un projet sont toujours bienvenues.
Le fait que tu disposes d’un bagage en enseignement me semble particulièrement intéressant, une partie du métier est de réussir à communiquer avec une grande variété de personnes et bien comprendre et leurs besoins et les éventuelles frictions qu’ils ont au quotidien. Si la charge de travail le permet être force de proposition pour améliorer le cadre de travail organisationnel et technique dans lequel tu t’inscris est souvent apprécié.
En tant que junior le plus important à mes yeux soit que tu montres une volonté d’apprendre et de contribuer positivement aux projets auxquels tu participeras (tes projets persos sont un très bon point à ce sujet). Savoir être à l’écoute et ne pas avoir peur de poser des questions, même si les collègues en place et notamment les profils séniors ont tout le temps l’air occupés ne pas oser les « déranger » peut te desservir et ralentir le travail de l’équipe dans son ensemble. Le rôle d’un sénior est justement en partie d’aider les autres et les tirer vers le haut, donc il faut aussi les aider à identifier comment ils peuvent t’aider au mieux. Et comme on n’a pas tous la même vie et les mêmes expériences même une personne fraichement sortie de l’école peut nous apprendre des choses ! 
Enfin un point d’attention important de mon point de vue est de limiter la complexité de ce que l’on produit. C’est facile de mettre en place des choses « malines » un peu complexes que l’on a soi-même du mal à reprendre après 6 mois à ne pas y avoir touché. Il y a toujours une complexité intrinsèque à tout problème avec laquelle on doit travailler, mais il faut faire attention à la complexité incidente qui s’y ajoute, qui est aussi bien en lien avec nos outils (ils ne sont pas parfait) et avec nos pratiques. Savoir mettre en place une documentation minimale qui décrit le pourquoi et comment utiliser ce que l’on met en place est aussi une compétence appréciable et aide justement à contrôler cet aspect. 
3 « J'aime »
Bonjour Tanguy,
En ce qui concerne les erreurs à ne pas faire quand on débute, je dirai que le mieux est encore de prendre le problème dans l’autre sens. Plutôt que de lister les choses à s’interdire, il vaut mieux se lister les choses à faire à tout prix. Et pour moi, une des choses que j’ai commencé à faire bien trop tardivement, c’est une documentation personnelle. Capitalise dès le début les savoir-faire fondamentaux sur le système, le réseau, la conteneurisation, l’automatisation, l’observabilité…etc. Là tu ne documentes pas pour les autres, tu travailles pour toi-même. C’est très chronophage au début mais ça te le rend au centuple ensuite ! Là où tes collègues referont dans la même semaine 9 fois la même recherche google/chatgpt pour avoir la bonne syntaxe pour tel outil, toi t’auras juste à te rappeler l’avoir vaguement déjà fait avant et tu iras piocher dans ta documentation. Sur le temps long, tu vas gagner quotidiennement un temps précieux. Par contre, attention à ne pas tomber dans le piège du copier-coller et au final tu te retrouve juste à aspirer tout internet pour rien. Il faut s’obliger à écrire soi-même les choses, à reformuler, à synthétiser, sinon il n’y a aucun intérêt !
Personnellement j’utilise Trilium mais tu en as d’autres comme Obsidian.