L’onboarding d’un dev fait partie des sujets qui sont sous-estimés par le management. On en parle souvent comme d’une formalité (un PC, des accès et une présentation généraliste), alors qu’en fait c’est un bon indicateur de la santé d’un projet.
Les bons signaux à regarder
Pour savoir si un onboarding fonctionne, on n’a pas besoin d’un tableau de bord compliqué. Quelques questions simples suffisent déjà à prendre le pouls:
Combien de temps faut-il avant le premier commit ?
Combien de temps avant la première Pull Request relue, mergée, et idéalement déployée ?
Combien de temps avant que la personne puisse prendre un ticket simple sans être accompagnée pas à pas ?
Dans une équipe qui tourne bien, ces délais se comptent souvent en quelques jours pour les premières contributions simples puis en une à deux semaines pour gagner en autonomie sur des sujets modestes. Dans une équipe plus en difficulté, ils peuvent vite s’étirer sur plusieurs semaines, voire davantage. Et ce n’est pas parce que les développeurs sont moins bons. C’est souvent parce que le système est trop difficile à appréhender.
Le scénario récurrent
Jour 1, ça commence par de l’attente : PC pas tout à fait prêt, VPN en cours, droits Git ou Jira incomplets… Pour occuper, on dit “tu peux lire la doc”. Sauf que la doc est rarement un vrai parcours : c’est un ensemble de pages écrites à des moments différents, avec parfois des contradictions.
Ensuite vient le premier ticket, souvent choisi avec de bonnes intentions : “un petit fix pour démarrer”. Et là, le petit fix n’est pas si petit.
Il touche plusieurs services. Il dépend d’une règle métier implicite. Il nécessite une variable d’environnement que personne n’a documentée. Il faut comprendre un pipeline CI/CD qui échoue pour une raison obscure. Ou demander un secret à quelqu’un qui “sait comment faire”.
Résultat : la personne avance à l’aveugle, pose beaucoup de questions, attend des réponses, et l’équipe est ralentie elle aussi.
Sur un de mes précédents projets, en arrivant, j’ai eu l’impression d’être plongée dans le grand bain. Le code était bien là, mais rien n’avait été pensé pour permettre à un nouvel arrivant de s’approprier l’environnement et progresser sereinement.
J’ai mis plusieurs jours à obtenir un environnement local stable : versions d’outils non alignées, dépendances externes mal simulées, secrets gérés au cas par cas. Et pendant ce temps-là, je ne pouvais pas vraiment contribuer. Donc au lieu de produire de la valeur, je passais ces journées à réduire l’incertitude.
On peut avoir de bons développeurs et un bon produit et perdre énormément d’efficacité juste parce que l’entrée dans le projet est trop chaotique. Le piège, c’est que l’équipe finit souvent par s’habituer à devoir aider en continu les nouveaux et considère ça comme normal. Alors qu’en réalité, c’est un coût récurrent qui revient à chaque arrivée.
À quoi ressemble un onboarding qui marche
Ici, il ne s’agit pas de détailler tout l’onboarding entreprise, mais de se concentrer sur ce qui conditionne réellement l’autonomie d’un développeur dans son équipe et sur son projet.
Un onboarding réussi n’a rien d’exceptionnel : c’est un cadre qui permet aux nouveaux de prendre leurs marques rapidement, à la fois dans l’équipe et sur le projet.
Avant l’arrivée, les accès essentiels sont prêts. Un buddy peut être désigné : une personne référente dans l’équipe à qui le nouveau peut poser ses questions sans hésiter, et qui l’accompagne dans ses premiers pas sur le projet.
Il existe un point d’entrée clair : une page unique “Start here” ou “Day 1” qui dit quoi faire, dans quel ordre, et où est la source de vérité.
Quelques jalons simples suffisent :
Jour 1 : comprendre le contexte métier, visualiser rapidement l’architecture, identifier les principaux services, les dépendances, les équipes avec lesquelles on interagit, puis faire tourner le projet localement.
Jour 2 : prendre une première tâche préparée à l’avance, avec un périmètre maîtrisé.
Fin de première semaine : ouvrir une première Pull Request, la faire relire, la merger.
Fin du premier mois : faire un retour d’expérience sur l’onboarding et commencer à prendre des tickets simples avec plus d’autonomie.
Le résultat se voit vite : moins de blocages, moins de questions répétées, des PR qui sortent plus tôt, et une personne qui s’intègre dans le rythme de l’équipe au lieu d’avoir l’impression de le freiner.
Le vrai test : faire mieux au prochain arrivant
L’onboarding mérite d’être traité comme un produit interne : quelque chose qu’on observe, qu’on ajuste, et qu’on essaie de rendre un peu meilleur à chaque arrivée.
Pour cela, le retour du nouvel arrivant est précieux. Après quelques semaines, une mini-rétrospective de son onboarding permet d’identifier ce qui l’a aidé, ce qui l’a ralenti, ce qui manquait.
Au final, le meilleur signe qu’un onboarding fonctionne, c’est quand on n’a plus vraiment besoin d’en parler. Les nouveaux arrivent, trouvent ce qu’il leur faut, posent moins de questions urgentes, et entrent dans le rythme sans friction inutile. C’est rarement spectaculaire, mais c’est souvent ce qui fait la différence entre une équipe qui avance et une équipe qui s’épuise à se réexpliquer en boucle.
Alexandra COURTIOLE – software crafter Arolla