Pourquoi le DevOps ?

Quand j'ai commencé à m'intéresser au développement, je ne savais pas encore vers quoi me spécialiser. J'ai touché au C, au système, aux algorithmes pendant le tronc commun de 42. J'ai aimé comprendre comment les choses fonctionnent en dessous. Pas les interfaces, pas le design — les mécanismes, l'infrastructure, ce qui fait tourner un service.

Le DevOps, c'est ça. Le lien entre le code et la production. Déployer, automatiser, monitorer, sécuriser. C'est pas un rôle de support, c'est un rôle qui impacte toute la chaîne.

Ce qui m'a attiré, c'est pas uniquement la technique. C'est aussi la position. Un DevOps/SRE/Platform Engineer touche à tout : le code, l'infra, la CI/CD, le cloud, la sécurité. À long terme, ça ouvre vers des rôles d'architecte cloud ou de lead platform — des positions où tu prends des décisions structurantes.

Mais c'est pas qu'un calcul de carrière. J'aime ce que je fais. Configurer un reverse proxy, écrire un pipeline, débugger un conteneur qui ne démarre pas — c'est le genre de problèmes qui me plaît.

Pourquoi pas autre chose ?

L'IA — J'aime l'outil, je l'utilise au quotidien, et il y a énormément de choses à construire avec. Mais le secteur ne me convient pas. Beaucoup de hype, des investissements massifs pour des entreprises qui ne sont toujours pas rentables — OpenAI a perdu 8 milliards de dollars en 2025 malgré 13 milliards de revenus, avec des pertes prévues jusqu'en 2029. Et côté technique, c'est beaucoup d'algorithmie et de mathématiques — pas mon point fort, pas ce qui me motive.

La cybersécurité — J'ai touché à l'assembleur à 42, j'ai fait quelques projets liés à la sécurité. Mais le cœur du métier — investiguer, chercher des failles, analyser des traces — c'est pas ce qui me donne envie de me lever le matin.

Le full-stack — C'est ce que je vise en compétence secondaire, dans une logique T-shaped. Mais après l'infra, pas avant. Comprendre ce qui se passe sous le capot d'abord, construire des interfaces ensuite.

Apprendre par couches

Je n'ai pas suivi de roadmap trouvée sur internet. J'ai avancé par logique de dépendance : chaque étape crée une base solide pour la suivante.

C'est pas théorique. Si tu ne comprends pas comment fonctionne un conteneur Docker, tu ne peux pas utiliser Compose correctement. Si tu ne sais pas ce qu'est un utilisateur root, tu ne peux pas configurer Traefik ni sécuriser un conteneur avec un utilisateur non-root. Chaque couche s'appuie sur la précédente.

Linux / Bash — La base. Impossible de faire du DevOps sans être à l'aise dans un terminal. 42 m'a donné ça — pas une maîtrise complète, mais assez pour me débrouiller, lire des logs, écrire des scripts, naviguer dans un système.

Docker / Docker Compose — Le premier outil qui change tout. Comprendre les conteneurs, les images, les réseaux, les volumes. Le projet Inception à 42 m'a posé les bases, Glasck m'a fait pratiquer en conditions réelles.

AWS, Terraform, Ansible — Le cloud et l'Infrastructure as Code. Provisionner des ressources AWS avec Terraform, configurer des machines avec Ansible. Un même projet qui m'a fait toucher aux trois.

Monitoring — Prometheus, Grafana, Loki. Mis en place sur Glasck, pas dès le début comme j'aurais dû, mais l'expérience m'a montré pourquoi c'est indispensable le plus tôt possible.

Chaque étape a été motivée par un projet ou une technologie à explorer concrètement. Pas un programme théorique.

Ce n'est pas une checklist. C'est une logique : chaque étape prépare la suivante.

Où j'en suis — Mars 2026

Ce paragraphe est volontairement daté. Le reste de l'article décrit un état d'esprit qui ne changera pas. Mon niveau et mes priorités, eux, évoluent.

  • Fait : tronc commun 42 validé — C, C++, administration système de base, introduction réseau. Docker/Compose en prod sur Glasck. Un projet AWS avec Terraform et Ansible. Monitoring Prometheus/Grafana/Loki en place.
  • En cours : préparation AWS Cloud Practitioner
  • Prochaines étapes : Kubernetes, CI/CD (GitHub Actions, GitLab CI), GitOps (ArgoCD/Flux)

Être honnête sur son niveau, et prioriser

Je ne suis expert dans rien de tout ça. Linux, je connais les bases pour me débrouiller. Docker, je sais écrire un Compose et débugger, mais j'ai pas touché à tout. Terraform, Ansible, AWS — j'ai un projet derrière moi, pas dix.

J'apprends sur le tas. Chaque projet me fait progresser, chaque problème rencontré me force à creuser. C'est pas linéaire, c'est pas rapide, mais c'est concret.

Et tout ne peut pas être appris en même temps. Il faut choisir. Il y a des technologies qui m'intéressent, mais que je repousse volontairement — pas par désintérêt, par priorité.

Multi-cloud — Pas de GCP ou Azure avant de maîtriser AWS. AWS est utilisé par 85% des entreprises dans le monde — c'est le standard. Un cloud bien compris vaut mieux que trois survolés.

Kubernetes — J'y viendrai, mais Docker Compose suffit pour mes besoins actuels. Pas la peine d'ajouter de la complexité sans cas d'usage.

Certifications avancées — Une à la fois. Cloud Practitioner d'abord, Solutions Architect ensuite.

Des choix guidés par le marché, le temps disponible, et ce qui a le plus d'impact maintenant.

Vision long terme

Le DevOps, c'est pas une fin en soi pour moi. C'est un socle. L'objectif à terme : évoluer vers un rôle d'architecte cloud ou de lead platform. Des positions où tu ne fais plus juste exécuter — tu structures, tu décides, tu influences l'architecture technique d'une entreprise.

Pour y arriver, il faut un socle technique solide, une compréhension des enjeux métier, la capacité à penser l'expérience utilisateur, et savoir prendre du recul. C'est ce que je suis en train de construire.