Bienvenue dans l’équipe, voici ton kit de survie (et non, pas juste un mug et un T-shirt)
1. Le piège classique : “Tu vas te débrouiller, t’es sénior non ?”
Être sénior, ce n’est pas un super-pouvoir de télépathie. Même un expert a besoin d’un minimum de repères pour être efficace. Penser qu’une personne va juste se poser avec un ordi et deviner quels outils utiliser est une erreur. Et au bout d’une semaine, un manager décrète qu’elle n’est pas autonome ou pas aussi qualifiée que prévu.
Perso, on m’a déjà mis sur un projet avec une tâche estimée à deux semaines. À la fin, on m’a demandé pourquoi j’avais mis… deux semaines.
Une autre fois, j’arrive dans un pays étranger pour un projet où je ne maîtrise pas la techno. Au bout d’une demi-journée, le manager me trouve incompétent et veut me virer. Heureusement, en étudiant le code, j’ai repéré une amélioration qui a fait gagner 4h de dev par semaine. En une seule journée. Et sans être expert. J’ai fini par rester sur le projet.
Mais bon, l’expérience ne doit jamais servir de prétexte pour bâcler l’accueil, quel que soit le niveau. L’onboarding “Dev in the jungle”, c’est non :
- Pas de doc, pas de contexte, juste un ticket Jira et un “Bon courage !”
- L’équipe trop occupée pour aider
- La fameuse phrase : “Ah oui, ça je crois que c’est dans Confluence, quelque part…”
« On n’attend pas d’un pilote de ligne qu’il devine où sont les commandes en plein vol. »
2. Les quatre piliers d’un onboarding réussi (avec un vrai cerveau derrière)
🗂️ A. La préparation de l’équipe en amont
Combien de fois avez-vous appris l’arrivée d’un nouveau… la semaine d’avant ? Voire le jour même ?
Et pourquoi les réunions d’avancement ne servent-elles qu’à remonter de l’info, et jamais à en faire descendre ?
Combien de fois avez-vous découvert un nouveau manager en pleine réunion ? Et appris le départ de l’ancien le jour J ?
On marche sur la tête.
🗂️ B. La documentation essentielle
Cela peut paraitre simple et basique, mais cela reste souvent uniquement dans la tête des anciens à qui on ne laisse pas le temps de se regrouper et d’écrire
- Check-list des demandes d’accès : Git, Jira, messagerie, VPN, Slack/Teams, cloud, bases de données, etc.
- Présentation claire de l’équipe : rôles, interlocuteurs, Slack-channels, qui fait quoi
- Où est la doc (et est-ce qu’elle est à jour, spoiler : souvent non)
- Processus d’équipe : cycle de dev, validation, merge, mise en prod, etc.
- Guide d’installation (code, envs, outils) : à rendre reproductible (Docker ou pas)
- Option bonus : wiki de survie avec les “petites astuces” que tout le monde oublie de dire
“L’install du poste m’a pris deux jours. Pas parce que c’est complexe… juste parce que personne ne savait quoi installer exactement.”
📅 C. Les réunions utiles (si, ça peut exister)
Et c’est loin d’être une perte de temps, on peut même les enregistrer pour que le nouveau puisse revenir dessus.
- Un vrai moment d’accueil, pas juste “salut en visio”
- Présentation du projet, vision, objectifs (passé-présent-futur)
- Tour de l’équipe, attentes de chacun, façon de bosser
- Pair programming, shadowing, ou toute autre forme de “mise en immersion active”
Conseil pratique : Préparer un onboarding calendar avec les réunions clés les premiers jours/semaines :
- Jour 1 : accueil RH + équipe
- Jour 2 : démo produit
- Jour 3 : dev + infra
- etc.
🙋 D. Clarifier sa place et ses missions
Oui, cela peut aussi être basique, mais est-ce-fait ?
- Ce qu’on attend de la personne dans les premières semaines
- Ce qu’on n’attend pas (pas besoin de réécrire l’archi en 3 jours hein)
- Qui peut l’aider / comment il peut contribuer rapidement
- Fixer un premier livrable réaliste (et utile)
Astuce :
Créer un petit “contrat moral” d’intégration :
“Tu n’es pas attendu comme sauveur, tu es ici pour apprendre, comprendre, et apporter ensuite.”
3. Comment organiser tout ça sans transformer l’accueil en usine à gaz ?
🛠️ A. Créer un kit onboarding réutilisable
- Modèle de page Notion / Confluence par rôle
- Template de demandes d’accès
- Email d’arrivée + programme type de la semaine 1
Ce que je mets souvent en place :
- Un guide d’installation
- Une fiche d’identité du projet (fonctionnel, archi, techno, équipe)
- La liste des accès
- Un welcome package fonctionnel
- Un welcome package technique
Il ne faut pas oublier que c’est une documentation vivante, l’arrivée d’un nouveau est aussi une occasion de l’améliorer.
🧠 B. Nommer un parrain/marraine
Quelqu’un qui connaît bien l’équipe et le projet, et qui peut “débroussailler” les premiers jours
✅ C. Faire un point de fin de semaine 1
Retour à chaud avec le nouvel arrivant :
“Qu’est-ce qui t’a manqué ? Qu’est-ce qui t’a aidé ?”
Et on améliore pour le suivant. Boucle itérative, agile quoi !
4. Conclusion : Un bon onboarding, c’est de l’architecture sociale
“Un bon onboarding, ce n’est pas du luxe. C’est de l’intelligence collective en action.”
Combien de fois vous êtes-vous demandé “où est-ce que je suis tombé…” ?
Des doutes personnels surgissent : ‘Je suis nul ? C’est moi le problème ?’ En l’absence d’accueil, même les meilleurs peuvent avoir envie de fuir ce projet en courant.”
Ce qu’un nouveau cherche, ce n’est pas juste une doc ou un accès VPN. C’est une équipe qui lui dit : on t’attendait, on a pris le temps de t’accueillir.
“Un onboarding raté, c’est comme un immeuble sans escalier : tu peux grimper, mais ça va être sportif… et tout le monde va y perdre du temps.”
Moralité, “Un nouvel arrivant, c’est comme une graine : sans terre, sans eau, sans lumière… elle crève.”
🔖 À retenir pour un onboarding digne de ce nom :
- Anticiper l’arrivée (on en parle avant, pas le jour J)
- Préparer la doc essentielle (accès, outils, install, équipe)
- Organiser les bonnes réunions (vision, code, pratiques)
- Clarifier les attentes (tu fais quoi ? pour quand ? avec qui ?)
- Nommer un référent humain (pas un bot Teams)
- Améliorer en continu (on apprend de chaque arrivée)
