Situation réelle

Nouveau job. Premier jour. Tout est nouveau : codebase, outils, équipe, culture, processus. Ces 90 premiers jours vont largement déterminer ta trajectoire dans cette boîte.

Ce que j’ai observé : les 90 premiers jours sont une fenêtre critique. Bien navigués, ils posent des fondations solides. Mal navigués, tu rattrapes pendant 6-12 mois.

Le faux problème

Le faux problème serait de croire que tu dois tout comprendre et livrer immédiatement. En réalité, ces 90 jours sont pour apprendre, observer, créer des relations. La performance viendra après.

Un autre faux problème : penser que tu dois juste “faire ton job”. En réalité, les 90 premiers jours sont aussi politiques : comprendre culture, dynamiques, qui est qui.

Le vrai enjeu

Le vrai enjeu est de poser de bonnes fondations sans te griller :

Les 3 phases des 90 jours :

Phase 1 - Jours 1-30 : Écouter et apprendre : Objectifs : comprendre contexte (produit, archi, processus), créer relations (équipe, stakeholders), premiers quick wins. Focus : 80% écoute, 20% action. Livrer : petites tâches, bugs simples, améliorer doc. Piège à éviter : critiquer processus existants, proposer changements majeurs, isolement. Indicateur de succès : tu comprends qui fait quoi, comment les choses fonctionnent, premières PRs mergées.

Phase 2 - Jours 31-60 : Contribuer : Objectifs : autonomie croissante sur tâches normales, relations consolidées, compréhension approfondie domaine. Focus : 50% écoute, 50% action. Livrer : features de taille moyenne, participation active rituels. Proposer : améliorations mineures (après avoir compris pourquoi c’est comme ça). Piège à éviter : trop de confiance trop vite, ignorer feedback. Indicateur de succès : tu livres régulièrement, équipe te fait confiance, tu participes activement.

Phase 3 - Jours 61-90 : S’affirmer : Objectifs : pleinement productif sur ton scope, relations solides, commencer à influencer. Focus : autonomie maximale, propositions réfléchies. Livrer : features complexes, ownership morceaux. Proposer : améliorations avec contexte (« J’ai vu qu’on fait X, j’ai compris pourquoi, et si on essayait Y pour raison Z ? »). Piège à éviter : arrogance, changements non consensuels. Indicateur de succès : considéré comme membre à part entière, pas « le nouveau ».

Les 7 règles d’or des 90 premiers jours :

Règle 1 - Écouter avant de parler : Pratique : observer 2-4 semaines avant critiquer. Chercher à comprendre POURQUOI les choses sont comme elles sont. Bénéfice : éviter propositions naïves type “pourquoi vous faites pas X ?” alors que X a été essayé et a échoué. Message : humilité initiale crée crédibilité future.

Règle 2 - Poser beaucoup de questions : Pratique : questions sur contexte, histoire, décisions passées. Approche : “Je suis nouveau, j’essaie de comprendre : pourquoi vous avez choisi cette archi ?” Bénéfice : apprentissage accéléré, montrer intérêt, créer liens. Message : période de grâce où questions massives sont attendues.

Règle 3 - Quick wins visibles : Pratique : chercher petites améliorations (doc, bugs, DX). Livrer vite pour montrer valeur. Bénéfice : confiance équipe, sentiment d’utilité, momentum positif. Exemple : première semaine corriger 3 bugs + améliorer doc onboarding. Message : action rapide mais calibrée.

Règle 4 - Créer relations 1-1 : Pratique : café/déj 1-1 avec équipe et stakeholders. Comprendre qui fait quoi, contexte, priorités. Bénéfice : réseau interne, compréhension dynamiques, alliés futurs. Timing : premiers 30 jours. Message : investir dans relations paie long terme.

Règle 5 - Comprendre culture implicite : Pratique : observer codes non-écrits (horaires, communication, décisions, qui a vraiment le pouvoir). Questions : “Comment on prend les décisions ici ?” “Qui influence quoi ?” Bénéfice : naviguer politique sans faux pas. Message : culture réelle ≠ culture affichée.

Règle 6 - Demander feedback tôt et souvent : Pratique : one-on-one manager J15, J30, J60. Question : “Comment je m’en sors ? Où m’améliorer ?” Bénéfice : ajustements rapides, pas de surprises à J90. Message : feedback précoce évite dérapage.

Règle 7 - Documenter ce que tu apprends : Pratique : notes sur archi, processus, qui fait quoi. Partager (wiki, doc) pour futurs nouveaux. Bénéfice : ancre apprentissage, aide équipe, montrer proactivité. Message : contribution utile même en apprenant.

Cadre de décision

Voici comment structurer tes 90 jours :

1. Semaine 1 : Setup et contexte Actions : environnement opérationnel, rencontres clés (équipe, manager, buddy), contexte minimal (produit, archi), premier micro-projet. Objectif : bases posées, pas noyé.

2. Semaines 2-4 : Apprentissage actif Actions : petites tâches réelles, pair programming, 1-1s avec stakeholders, lecture code/doc. Objectif : comprendre comment ça marche, créer relations.

3. Mois 2 : Montée en autonomie Actions : features normales, participation rituels, propositions mineures. Objectif : productif sur scope défini.

4. Mois 3 : Pleine contribution Actions : features complexes, ownership, propositions réfléchies. Objectif : membre à part entière.

5. Checkpoints réguliers Timing : J15, J30, J60, J90. Format : one-on-one manager, feedback bidirectionnel. Objectif : ajuster trajectoire.

Retour terrain

Ce que j’ai observé chez différents profils :

Le nouveau arrogant : Arrive, J3 critique processus existants, propose refonte complète sans comprendre contexte. Équipe se braque. 6 mois : toujours « le nouveau qui sait tout », relations tendues. Message : humilité initiale est critique.

Le nouveau qui écoute : Arrive, 3 semaines d’observation et questions. Comprend pourquoi c’est comme ça. Mois 2 : propose amélioration avec contexte. Équipe réceptive. 6 mois : influent, respecté. Message : comprendre avant changer.

L’exemple du quick win : Nouveau dev, J5 : corrige bug qui traînait + améliore doc onboarding. Équipe : « Oh nice, merci ! » Momentum positif créé. Message : action rapide mais utile ouvre portes.

Le piège de l’isolement : Nouveau dev, focus 100% code, zéro 1-1, zéro pause café. 3 mois : compétent mais isolé, pas compris dynamiques. Friction évitables. Message : relations comptent autant que code.

Erreurs fréquentes (et comment les éviter)

Erreur 1 - Critiquer avant de comprendre Piège : “Pourquoi vous faites pas X ?” sans savoir que X a été essayé et a échoué. Réalité : paraît naïf. Correction : comprendre contexte, puis proposer.

Erreur 2 - Ne pas créer relations Piège : focus 100% technique, ignorer l’humain. Réalité : relations critiques pour naviguer. Correction : investir temps 1-1s, pauses café.

Erreur 3 - Trop attendre pour contribuer Piège : “Je vais attendre de tout comprendre avant de livrer.” Réalité : impossible et frustrant. Correction : quick wins précoces.

Erreur 4 - Ignorer feedback Piège : manager donne feedback J30, ignoré. Résultat : problème persiste, frustration. Correction : appliquer feedback rapidement.

Message de responsabilité

Ces 90 jours dépendent largement de toi :

  • Tu es responsable d’observer et comprendre avant de critiquer
  • Tu es responsable de créer des relations activement
  • Tu es responsable de demander feedback et de l’appliquer
  • Tu es responsable de livrer rapidement tout en apprenant

Une bonne intégration n’est pas juste luck. C’est méthode et attitude.

Pour aller plus loin

Le livre "Être ou ne pas être CTO" explore comment réussir ses transitions et prises de poste.

Tu peux aussi consulter l’article "Onboarding : intégrer sans noyer" ou les autres contenus du pilier "Trouver sa place".