30 premiers jours en mission ESN : la méthode jour-par-jour
Une nouvelle mission qui démarre, c'est 30 jours qui définissent les 12 suivants. Trop d'intégrations ratent parce que ni le consultant ni le manager mission n'ont de plan structuré. On se dit "on verra au feeling". Erreur.
Voici la méthode en 5 semaines qu'on applique chez Orenda. Elle est testée sur 50+ missions. Elle ne garantit pas le succès, mais elle évite 80% des échecs prévisibles. Imprimable, partageable avec votre client.
Semaine 1 — Observer, écouter, cartographier
- Cartographier l'organisation : qui décide, qui valide, qui peut bloquer
- Cloner le repo, faire tourner l'environnement de dev en local
- Lire le README, le CHANGELOG, les ADR si présents
- Faire un 1:1 avec votre tech lead, votre product owner, et 2-3 développeurs
- Noter 10 questions à poser plus tard (ne pas les poser tout de suite)
Signal à observer : Vous devez sortir de la semaine 1 capable de dessiner sur un papier le RACI de votre équipe. Si vous ne pouvez pas, alertez votre manager Orenda.
Semaine 2 — Premier ticket, petit scope
- Prendre un ticket de petite taille (1-2 jours estimés)
- Ouvrir la première PR avant la fin de la semaine
- Faire reviewer par 2 personnes — pas seulement le tech lead
- Documenter ce que vous découvrez (gotchas, conventions implicites)
- Demander un feedback explicite à mi-semaine sur votre intégration
Signal à observer : Une PR mergée avant J10 = bon signal. Si bloqué 3 jours sur un ticket "simple", parlez-en — soit le ticket cache de la dette, soit l'onboarding doc manque.
Semaine 3 — Premier livrable visible
- Livrer une fonctionnalité bout-en-bout (front + back si full-stack)
- Présenter votre livrable en démo équipe (10 min max)
- Avoir une discussion technique de fond avec votre tech lead
- Identifier 2-3 améliorations possibles dans la codebase (à proposer, pas à imposer)
- Commencer à participer aux rituels (daily, retro, refinement)
Signal à observer : La démo équipe est le premier moment où vous devenez "un des nôtres" plutôt que "le nouveau d'Orenda". Préparez-la sérieusement.
Semaine 4 — Prise d'autonomie
- Prendre un ticket de taille moyenne (3-5 jours estimés)
- Estimer vos propres tickets (et accepter que vous vous tromperez)
- Aider un autre développeur sur sa PR (signal de maturité)
- Proposer une amélioration technique mesurable (build time, test flaky, etc.)
- Point milieu de période avec votre manager Orenda — 30 min, format check-in
Signal à observer : Si à J22 vous attendez encore qu'on vous distribue les tickets, ce n'est pas grave — mais c'est le moment de demander explicitement à les choisir vous-même.
Semaine 5 — Bilan, projection, ajustement
- Faire le bilan des 30 jours par écrit (Orenda + vous + client)
- Identifier ce qui vous nourrit vs ce qui vous use
- Discuter avec votre manager mission Orenda du planning des 90 jours suivants
- Bloquer dans le calendrier vos 4h hebdo de formation à partir de la semaine 6
- Décider d'1 contribution structurante à porter sur les 60 jours suivants (refacto, doc, mentorat junior, etc.)
Signal à observer : À J30, vous devriez pouvoir répondre OUI à : "Est-ce que je sens que ma présence apporte de la valeur ?" Si non, on en parle — c'est notre boulot de manager Orenda de comprendre pourquoi.
Le point bilan J30
À J30, faites un point écrit en 3 sections, 1 page max :
- Ce qui marche — équipe, projet, stack, autonomie
- Ce qui frotte — process, communication, rythme
- Ce que je veux ajuster sur les 30 prochains jours
Ce document, vous le partagez avec votre manager Orenda. Pas avec le client. C'est votre espace de pilotage personnel. On en discute en 30 minutes, on ajuste, on continue.