L'onboarding Développeur Qui Livre Dès La Semaine Une

L’onboarding développeur se mesure d’habitude à la durée de l’accueil administratif, et c’est prendre le problème par le mauvais bout. Le chiffre qui compte est un autre : combien de temps s’écoule avant qu’un nouvel ingénieur puisse modifier quelque chose en étant sûr de n’avoir rien cassé ailleurs. Dans la plupart des équipes, cela se compte en mois plutôt qu’en jours.

Le retard tient rarement à la personne. Il tient à la part du système qui n’existe que dans la tête des autres, et à la part de la première quinzaine passée à l’en extraire, une interruption après l’autre.

La seule métrique qui vaut d’être suivie : le temps avant que leur première modification arrive en production. Pas leur premier commit, qui peut n’être qu’une faute de frappe corrigée, mais un changement qui comptait et qui est parti en ligne. Si cela dépasse une semaine, l’obstacle n’est presque jamais la compétence. C’est une procédure d’installation que personne n’a rejouée depuis longtemps, ou une base de code dont les points d’entrée restent introuvables sans guide.

Ce à quoi l’onboarding développeur fait concurrence

Trois coûts, et un seul concerne le temps de la nouvelle personne.

Son temps, celui que l’on voit et celui que tout le monde cherche à optimiser. Le temps de l’équipe, parce que chaque question interrompt quelqu’un qui faisait autre chose, et ce poste pèse plus lourd que le premier. Et le coût des questions jamais posées, quand un nouvel ingénieur préfère deviner plutôt que de déranger pour la cinquième fois dans la matinée, et que sa supposition est fausse d’une manière qui ne se verra que deux mois plus tard.

C’est ce troisième coût qu’un bon onboarding supprime réellement. La documentation vaut d’être écrite non pas parce que lire irait plus vite que demander, mais parce qu’elle permet de trouver la réponse à onze heures du soir sans avoir à peser le prix social d’une question de plus.

Réparez d’abord l’environnement

Le facteur qui détermine le plus la première semaine, c’est de savoir si le projet démarre sur une machine neuve sans aide de personne.

Les équipes sous-estiment cela systématiquement, parce que tout le monde dispose déjà d’un environnement qui marche et que personne n’en a reconstruit un depuis deux ans. Pendant ce temps, le document d’installation renvoie à une version qui a bougé, oublie la variable d’environnement ajoutée au printemps dernier, et suppose l’accès à un service que la nouvelle personne n’a jamais obtenu.

Le remède manque de panache. Demandez à la prochaine recrue de suivre le document à la lettre, sans rien changer, et notez chaque endroit où il échoue. Cette liste est votre véritable procédure d’installation. Mieux encore : ramenez-la à une seule commande qui produit un système démarré avec des données de test utilisables, car chaque étape manuelle est une étape qui finira par dériver.

Les accès font partie de l’environnement. Quelqu’un qui a le code mais pas les droits sur le dépôt, les identifiants de préproduction ou l’outil de suivi n’est pas installé. Préparez les comptes avant la date d’arrivée plutôt que de découvrir les trous le premier matin.

Confiez-leur une vraie tâche tout de suite

Le réflexe de protéger une nouvelle personne du travail réel pendant quinze jours part d’une bonne intention et produit l’effet inverse. Lire une base de code sans objectif n’apprend presque rien, parce qu’il n’y a rien à quoi rattacher la lecture.

Une modification petite, authentique et livrable dès le deuxième ou le troisième jour enseigne tout le chemin de livraison : où vit le code, comment tournent les tests, comment se passe la revue, comment se déroule le déploiement et à qui il faut le dire. C’est ce chemin dont un nouvel ingénieur a le plus besoin, et c’est celui qui a le moins de chances d’être écrit quelque part.

Choisissez quelque chose qu’un vrai utilisateur attend, pas un exercice inventé. Les gens font la différence, et cette différence décide s’ils prendront les retours au sérieux.

Puis faites-le en binôme. Une heure aux côtés de quelqu’un qui connaît le système transmet plus qu’une journée de lecture, et celui qui accompagne découvre en général quelque chose sur sa propre base de code.

Ce qu’il faut écrire, et ce qu’il ne faut pas

La documentation se périme, alors n’écrivez que ce qui reste vrai et rembourse son entretien.

Vaut la peine : comment installer et lancer le système, comment le déployer, la forme de l’architecture et la raison de cette forme, les décisions qui seraient sinon rejugées sans fin, et qui possède quoi. Notre guide de la documentation technique traite plus en détail le problème de l’entretien.

Ne vaut pas la peine : tout ce que le code énonce déjà clairement, les parcours pas à pas d’écrans qui changent tous les mois, et les références d’API exhaustives tenues à la main. Ce sont ces pages qui se périment le plus vite et qui trompent le plus.

Dans la plupart des équipes, le document le plus utile est un court aperçu d’architecture expliquant quelles sont les grandes pièces et pourquoi elles ont été séparées. Il coûte un après-midi, change rarement, et répond à la question que chaque nouvel ingénieur passe sa première semaine à reconstituer.

L’onboarding est un test pour l’équipe

Tout ce sur quoi une nouvelle personne bute est une chose que l’équipe absorbait sans la voir.

Si l’installation prend trois jours, ce coût a toujours existé, payé en petites sommes par tous ceux qui ont un jour reconstruit une machine. Si personne ne sait dire pourquoi un composant existe, cette ambiguïté coûte des décisions depuis longtemps. Si le déploiement exige une personne précise, cette dépendance était déjà un risque, et c’est le même qui remonte lors d’une due diligence technique et dans tout plan de reprise sérieux.

Traitez donc les premières semaines comme un audit gratuit. Demandez à la nouvelle personne de tenir la liste de tout ce qui l’a déroutée, et lisez cette liste comme un backlog, non comme un jugement sur ses capacités. C’est la description la plus honnête de votre système que quiconque produira, car au bout de deux mois elle aussi aura cessé de remarquer.

Mecanik rejoint régulièrement des bases de code existantes dans le cadre de nos missions de développement logiciel, ce qui revient à faire passer ce test aux systèmes des autres à longueur d’année. Les équipes qui intègrent vite ne sont pas celles qui ont la meilleure documentation. Ce sont celles où quelqu’un a reconstruit son environnement récemment et réparé ce qui a cassé.

Questions fréquentes

Combien de temps doit durer l’onboarding développeur ? Mesurez le délai jusqu’à la première modification significative en production plutôt que la durée de l’accueil. Si cela dépasse une semaine, l’obstacle est rarement la compétence. C’est en général une procédure d’installation que personne n’a rejouée depuis longtemps, ou une base de code dont les points d’entrée restent introuvables sans guide.

Que doit faire un nouveau développeur pendant ses premiers jours ? Une modification petite, authentique et livrable, attendue par un vrai utilisateur. Lire une base de code sans objectif n’apprend presque rien faute de point d’ancrage, alors qu’un seul changement réel montre où vit le code, comment tournent les tests, comment se passe la revue, comment se déroule le déploiement et à qui le dire.

Pourquoi la mise en place de l’environnement prend-elle si longtemps ? Parce que tout le monde en a déjà un qui marche et que personne n’a reconstruit depuis des années, si bien que le document dérive. Le remède est de faire suivre ce document à la lettre par la prochaine recrue, sans rien changer, et de noter chaque échec. Cette liste est la vraie procédure, et la ramener à une seule commande l’empêche de dériver de nouveau.

Quelle documentation vaut la peine d’être maintenue pour l’onboarding ? Comment installer et lancer le système, comment le déployer, la forme de l’architecture et sa raison d’être, les décisions qui seraient sinon rejugées, et qui possède quoi. Laissez de côté ce que le code dit déjà, les parcours d’écrans qui changent tous les mois et les références d’API tenues à la main.

Que révèle un onboarding lent sur une équipe ? Que les coûts absorbés sans être vus sont bien réels. Trois jours d’installation étaient déjà payés en petites sommes par tous ceux qui reconstruisaient une machine. Un composant que personne ne sait justifier coûte des décisions depuis longtemps. Un déploiement qu’une seule personne sait faire était déjà un risque avant toute arrivée.