Les 90 premiers jours : Guide étape par étape pour les ingénieurs DevOps

Hey, nouvelle recrue. J’ai entendu parler de toi ! 

Tu as appris Kubernetes sur le bout des doigts, automatisé tout ce qui pouvait l’être et géré les pipelines. Tu as étudié les stratégies CI/CD, les outils IaC et les subtilités du YAML comme si ta vie en dépendait.

Félicitations, tu as décroché le poste d’Ingénieur DevOps !

On t’a donné l’accès à la console cloud, à la chaîne d’intégration, et peut-être — l’horreur — accès root en production (aucune pression).

La plupart des intégrations DevOps sont un mélange fragile de « lis cette doc au hasard datant de 2021 », « demande autour de toi », et « ne touche pas à ce script, on pense qu’il fait encore quelque chose ». 

Le rôle est rarement bien défini, les attentes sont absurdes alors que la documentation est quasi inexistante. Et… certains déploiements semblent sur le point d’invoquer une malédiction ancestrale.

Si l’entretien portait sur les outils, tes 90 premiers jours sont entièrement consacrés aux personnes, aux processus et aux priorités. C’est ici que tu gagnes ta crédibilité, découvres l’inexpliqué, et poses les bases de l’infrastructure sur laquelle ton équipe pourra compter.

Ce playbook ne résoudra pas l’infrastructure de ton équipe du jour au lendemain. Mais il t’aidera à éviter d’être celui qui l’a cassée.

Voix du terrain

« La leçon la plus importante que j’ai apprise est à quel point il faut comprendre rapidement tes clients — c’est-à-dire les développeurs — et leurs préférences. Chez Pixar, j’avais mis en place un système CI que personne n’utilisait tant que je n’avais pas ajouté d’alertes mail. C’est comme ça qu’ils aimaient être notifiés. Dans une autre entreprise, nous avons encouragé l’adoption des tests en les rendant ludiques avec des tableaux de classement en direct au bureau. La culture n’est pas un simple décor — c’est le véritable pipeline de livraison. » -Tara Hernandez, VP of Developer Productivity at MongoDB

Le rôle : DevOps vs. Plateforme vs. SRE

Commençons par l’éternelle mise en garde : « DevOps est une culture, pas un intitulé de poste. » D’accord, Jan — mais l’intitulé existe quand même. Et en pratique, cela signifie souvent un mélange de spécialiste de l’automatisation, architecte systèmes, SRE, et expert en outils internes.

On attend de toi que tu sois un facilitateur, un accélérateur, un champion du débit de livraison. Mais la vérité, c’est que tu seras la personne vers laquelle on se tourne lorsque :

• La chaîne d’intégration tombe en panne, et personne ne sait pourquoi.
• Quelqu’un a besoin d’un nouvel environnement de préproduction immédiatement.
• Un audit de conformité est imminent et des secrets circulent en clair.
• « On devrait vraiment automatiser ça » devient « Tu peux automatiser ça ? »

L’ingénierie de la plateforme, c’est du DevOps en mieux marketé.
SRE est du DevOps avec un SLA.

Quel que soit le nom employé, ton boulot est de permettre la montée en charge, d’assurer la disponibilité, et d’éviter la catastrophe.

Les 30 premiers jours : ne touche à rien (pour l’instant)

Conseil n°1 : Cartographie l’infrastructure, pas juste l’architecture 

Découvre ce dont tu es responsable : les fournisseurs cloud, les pipelines CI/CD, l’orchestration de conteneurs, la gestion des secrets, et les workflows d’incidents. Crée ta propre « carte infra » pour visualiser la stack. Bonus si tu ajoutes des liens vers des dashboards live ou des scripts.

A WEEKLY 5 MINUTE READ

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Phone

This field is for validation purposes and should be left unchanged.

Your email*

By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at anytime.

Conseil n°2 : Identifie la zone à risque

Toute équipe DevOps a un setup « s’il te plaît, ne touche pas à ça ». Recense tout ce qui pourrait exploser si mal manipulé. Cela comprend :

• Des scripts de déploiement qui font un SSH direct en production (pourquoi... pourquoiii ?)
• Des jobs Jenkins modifiés pour la dernière fois en 2019
• Des procédures d’exploitation manuelles stockées en PDF
• Des fichiers Terraform qui n’ont jamais été appliqués

Demande : Qu’est-ce qui est critique mais non documenté ? Qui en est responsable ? Et quel est le plan de retour arrière en cas d’échec ?

Conseil n°3 : Assiste à un déploiement (ou mieux, observe-en un en temps réel) 

Tu apprendras plus en un seul déploiement (et ses accrocs) qu’en des heures de documentation. Quelles étapes sont manuelles ? Où ça coince ? Qu’est-ce qui relève du folklore ou de la documentation ? Tu n’es pas encore là pour balancer des idées géniales. Tu es là pour récupérer les infos terrain.

Tu dois pouvoir suivre un commit de la fusion jusqu’à la production les yeux fermés. Comprends :

• Le pipeline CI/CD (où il casse, où il crée des goulets d’étranglement)
• Gestion des secrets (merci de ne pas les stocker dans les variables d’environnement)
• Flux d’approbation (déployons-nous sans filet depuis Slack ?)

Ne livrez pas de code. Observez simplement le fonctionnement interne et prenez des notes.

Voix du terrain

« Une bonne intégration ne s’accompagne pas toujours d’une bonne documentation. Parfois, la seule façon de traverser le chaos, c’est la curiosité et la persévérance. Lorsque j’ai rejoint une équipe et que j’ai récupéré un lancement complexe sans documentation, j’ai rétro-ingéniéré l’ensemble du flux. Cette expérience m’a appris : s’il manque la documentation, vous devenez la documentation. » –Anant Agarwal, CTO chez Aidora

Les 60 premiers jours : Identifiez les risques, réduisez les frictions

Astuce n°4 : Proposez une victoire en 5 minutes

Trouvez des tâches à forte friction et faible risque que vous pouvez automatiser ou transformer en modèles. Ces améliorations « 1 % » rendent votre quotidien plus simple et renforcent la confiance de l’équipe. Trouvez simplement une tâche qui dure 5 minutes de trop et rendez-la plus rapide :

• Un wrapper shell pour configurer l’environnement de développement local
• Un assistant CLI 
• Un module Terraform réutilisable
• Un script pour supprimer les environnements de test bloqués
• Une notification Slack pour les builds en échec

Les petites victoires créent la confiance. La confiance vous donne la marge nécessaire pour changer en profondeur.

Astuce n°5 : Auditez le pipeline CI/CD avec la plus grande rigueur

Regardez les temps de build. Regardez la couverture des tests. Identifiez ce qui casse au quotidien. Posez des questions comme :

• Pouvons-nous paralléliser les tests ?
• Est-ce qu’on aurait pu éviter ce problème plus tôt dans la CI ?
• Cache-t-on les dépendances ?
• Déployons-nous à la fusion… ou au « petit bonheur la chance » ?

Vous n’êtes pas là pour désigner des coupables. Vous êtes là pour fluidifier les processus.

Voix du terrain

« Lors d’une récente reprise d’app à fort trafic, il n’existait aucune documentation — nous avons tout découvert par essais et erreurs, à vitesse grand V. Mon conseil ? Exploitez l’IA sans réserve. De l’analyse de logs à la rétro-ingénierie des API, l’IA nous a permis de nous intégrer et de stabiliser plus vite qu’on ne l’aurait cru possible. Elle transforme la routine fastidieuse en progrès réel.” –Denis Tiumentsev, Lead DevOps Engineer chez Integro Technologies

Astuce n°6 : Créez des tableaux de bord vraiment utilisés, clarifiez les responsabilités 

 Grafana, Prometheus, Datadog — peu importe l’outil. Ce qui compte :

• Votre équipe peut-elle visualiser le taux de réussite des déploiements ?
• Les alertes sont-elles utiles ou juste du bruit ?

Quelqu’un surveille-t-il les taux d’erreur avant les réclamations utilisateur ? Qui est responsable du pipeline de build ? Des charts Helm ? Des configs DNS ? Les limites de périmètre sont rarement nettes. Dressez la liste des zones grises puis clarifiez-les en équipe. Cela évitera le jeu des responsabilités plus tard.

Vous êtes maintenant responsable de la visibilité. Faites-en bon usage.

Les 90 premiers jours : Gagnez la confiance par la fiabilité

Astuce n°7 : Livrez quelque chose qui augmente la stabilité 

Ce pourrait être :

• Mettre en place un système d’alertes sur une partie peu surveillée
• Améliorer la couverture des tests en pré-production
• Réduire la « flake » dans les pipelines CI
• Refactorer un script bash qui n’était qu’à un « rm -rf » d’un désastre

Il n’est pas nécessaire que ce soit énorme. Cela doit simplement permettre à votre équipe de souffler.

Voix du terrain

« L’un de mes premiers succès dans un nouveau poste DevOps a été la mise en place d’un pipeline CI/CD centralisé avec retour arrière automatisé et des workflows GitOps. Avant cela, l’équipe utilisait des scripts fragmentés et des bidouillages manuels. Cela a réduit les temps de déploiement de plus de 50 % et nous a permis de passer de l’urgence à la fiabilité proactive. La crédibilité acquise grâce à ce lancement a fait toute la différence. » –Divya Parashar, Senior Staff Engineer

Astuce n°8 : Rédigez une note de retour d’expérience “DevEx”

Recueillez les retours anonymes ou informels des développeurs sur les points où l’infrastructure les freine. Présentez vos constats et suggérez des pistes d’expérimentation (par exemple : accélérer le dev local, proposer des environnements éphémères, améliorer la journalisation).

Rédigez un document intitulé « Voici ce que j’ai appris et ce que je compte faire ensuite ». Ce sera votre feuille de route (et pourquoi pas une feuille de réussite ;)). Partagez-le avec votre manager et votre équipe.

Créez une liste « À ne pas oublier » :

• Les bizarreries que vous avez dénichées
• L’infrastructure fantôme que personne n’avoue gérer
• Les savoirs tacites que seul Carl de l’IT semble maîtriser

Transformez cette liste en documentation, automatisations ou tickets — ou gardez-la sous la main. Cela prouve à la direction que vous construisez des systèmes à toute épreuve.

Voix du terrain

« Concentrez-vous sur les résultats que vous pouvez obtenir aujourd’hui. Rappelez-vous pourquoi votre travail compte pour les clients — ce changement de perspective fait toute la différence durant les 90 premiers jours. » –Rukmini Reddy, SVP of Engineering at PagerDuty

Astuce n°9 : Identifiez un projet à fort impact et commencez à le cadrer 

À ce stade, vous devriez avoir assez d’indices pour repérer un axe majeur d’amélioration. Profitez de la dernière ligne droite de vos 90 premiers jours pour en définir la portée, en parler autour de vous et obtenir l’adhésion.

• Faire migrer les jobs instables vers GitHub Actions
• Remplacer un serveur « flocon de neige » par de l’infrastructure en tant que code
• Construire un chemin d’or pour que les devs créent de nouveaux services

Commencez petit et démontrez votre valeur. Documentez tout.

Dernier mot

Avec un peu de chance, en 90 jours, vous pourrez stabiliser la situation, réussir les déploiements et, surtout, éviter que les ingénieurs ne crient dans le vide.

Ces premiers temps servent à poser les bases pour la suite. Repérez les failles et documentez tout avec acharnement ! 

Voix du terrain

« Vous n’avez pas à faire vos preuves en un seul jour. Respirez. Privilégiez d’abord la stabilité, la rapidité viendra ensuite. Posez les questions bêtes dès le début — ce sera plus difficile plus tard. Et souvenez-vous : un système ennuyeux mais fonctionnel vaut mieux qu’un système tape-à-l’œil qui tombe en panne. » –Pablo Gerboles, CEO chez Alive DevOps

Pas votre première expérience tech ?

Ce playbook DevOps fait partie d’une série grandissante dédiée aux nouveaux arrivants qui veulent faire la différence avant qu’on leur confie de la « dette legacy ».

👉 Vous débutez dans un rôle de Security Engineer ? On a ce qu’il vous faut :
Les 90 premiers jours : Edition Cybersécurité

👉 Plutôt branché commits que accès root ? Découvrez :
Les 90 premiers jours : Edition Software Engineer

Et oui — d’autres rôles arrivent bientôt. Restez à l’écoute ou, mieux encore, inscrivez-vous à la newsletter pour ne pas manquer le prochain.