Un plan d'intégration 30/60/90 jours pour développeurs logiciels

Vous avez passé des semaines à trier, interviewer et négocier pour embaucher un développeur. Puis, au jour un, il attend un portable, une invitation au dépôt et quelqu’un pour lui dire quoi faire. Les semaines deux et trois s’écoulent dans un brouillard d’accès à moitié accordés et de miettes de billets. Au troisième mois, il passe discrètement des entrevues ailleurs.

L’intégration est l’endroit où les gains de l’embauche se perdent. C’est aussi peu coûteux à corriger, parce que cela répond à la préparation, pas au budget. Voici un plan complet.

Avant le jour un : tout provisionner

Le signal d’intégration le plus fort ne coûte rien : quand le développeur ouvre son portable au jour un, tout fonctionne déjà. Cela exige une liste de contrôle exécutée la semaine précédant son arrivée.

• Matériel commandé et livré (pour les recrues à distance, expédié assez tôt pour arriver avec une marge)
• Comptes créés : courriel, Slack ou Teams, organisation GitHub ou GitLab, outil de suivi des billets, CI, console infonuagique avec des rôles au moindre privilège, gestionnaire de mots de passe, RPV
• Calendrier rempli pour la première semaine : rencontre de démarrage avec le gestionnaire, présentation du parrain, survol de l’architecture, rencontres individuelles déjà planifiées
• Un document d’intégration écrit avec le plan des jours 1 à 90, la première tâche déjà choisie et les liens vers les documents clés
• L’équipe informée de qui arrive, de ce que la personne prendra en charge et de qui est le parrain

Désignez un seul responsable pour cette liste. Quand l’accès est « presque prêt », la recrue passe le jour un à découvrir ce qui ne l’est pas.

La première semaine : environnement, contexte et un commit fusionné

La première semaine a trois objectifs : un environnement de développement fonctionnel, assez de contexte pour se repérer, et un vrai commit fusionné dans la branche principale.

Ce commit compte plus qu’il n’y paraît. Il peut être minuscule : une coquille corrigée, un nettoyage de lint, une vérification de valeur nulle manquante. L’important est que le livrer force un passage complet dans votre vrai flux de travail : cloner, créer une branche, exécuter localement, ouvrir une demande de tirage, passer la CI, être révisé, fusionner, déployer. Chaque étape brisée de cette chaîne apparaît dès la première semaine plutôt qu’à la quatrième, pendant que la corriger relève encore clairement de l’intégration et non d’un échec personnel.

Un effet secondaire utile : demandez à la recrue de corriger la documentation d’installation en la suivant. Elle est la seule personne de l’équipe capable de voir les trous, et sa première demande de tirage peut littéralement être un meilleur README.

Complétez la semaine avec un survol de l’architecture par un ingénieur senior (enregistré, si l’équipe est à distance), une démonstration du produit du point de vue d’un utilisateur, et une courte rencontre sur la circulation du travail : comment les billets sont cadrés, comment se font les déploiements, à quoi ressemble un incident.

La première tâche significative

Après le commit d’échauffement de la première semaine, la première vraie tâche donne le ton pour tout le reste. Choisissez-la délibérément, avant la date d’entrée en poste, selon quatre critères :

• Réelle. Elle est livrée en production et un utilisateur ou un collègue en profite. Pas de bac à sable, pas d’exercice jetable.
• Cadrée. Réalisable en trois à sept jours par quelqu’un qui découvre le code. Si votre estimation pour un vétéran de l’équipe est de deux jours, c’est à peu près juste.
• Centrale. Elle touche le code principal et le flux de travail normal, pas un dépôt secondaire isolé que personne ne révise.
• Non bloquante. Rien sur le chemin critique n’en dépend, de sorte qu’un premier essai lent ne coûte que du temps.

De bons exemples : un bogue signalé avec des étapes de reproduction claires, une petite fonctionnalité derrière un drapeau, l’ajout de validation et d’un message d’erreur convenable à un formulaire, l’instrumentation d’un point de terminaison sans métriques, l’ajout d’un champ bien spécifié à une API existante. De mauvais exemples : « améliorer la couverture de tests » (sans cadre), un microservice tout neuf (isolé), ou la refonte épineuse dont personne ne veut (un rite d’initiation, pas une première tâche).

Le plan 30/60/90

Trois phases, chacune avec un objectif distinct : le contexte, puis la prise en charge, puis la pleine contribution. Voici à quoi chacune ressemble quand tout va bien.

Jours 1 à 30 : contexte et petites victoires

Le premier mois sert à bâtir un modèle mental juste du système, du produit et de l’équipe, démontré par un flot régulier de petits changements livrés.

Au jour 30, un développeur bien intégré a :

• Un environnement local pleinement fonctionnel et les correctifs de documentation pour le prouver
• Cinq à dix demandes de tirage fusionnées, de taille croissante
• Une tâche significative livrée en production
• Révisé au moins quelques demandes de tirage de collègues, même seulement avec des questions
• Rencontré toutes les personnes avec qui il travaillera, y compris les gens de produit et de soutien qui alimentent la feuille de route
• Assisté aux rituels récurrents de l’équipe assez longtemps pour savoir comment les décisions se prennent

Ce qu’il ne devrait pas avoir au jour 30 : la responsabilité exclusive de quoi que ce soit de critique, la garde, ou un grand projet. Charger tout cela trop tôt ne fait que transformer la confusion en risque.

Jours 31 à 60 : prise en charge et autonomie

Le deuxième mois passe du travail guidé à la livraison autonome : le développeur prend une fonctionnalité de taille moyenne du billet jusqu’à la production, avec la révision normale mais sans supervision particulière.

Au jour 60, cherchez :

• Une fonctionnalité moyenne livrée de bout en bout, y compris les parties ingrates (tests, migration, documentation, notes de version)
• Des révisions de code qui attrapent de vrais problèmes, pas seulement du style
• Des questions qui passent de « comment ça fonctionne » à « pourquoi c’est fait ainsi », signe que le modèle mental est formé
• Un premier quart de garde en observation, jumelé à un vétéran, si votre équipe fait de la garde
• Une participation au cadrage et à l’estimation avec le reste de l’équipe

C’est aussi le mois où les inadéquations se révèlent honnêtement. Si au jour 60 le développeur ne peut toujours pas avancer sans directives pas à pas, agissez maintenant; cela coûte beaucoup moins cher qu’au sixième mois.

Jours 61 à 90 : pleine contribution

À la fin du premier trimestre, l’objectif se résume simplement : l’équipe remarquerait le départ de cette personne. Concrètement, au jour 90 :

• Elle possède un domaine défini : un service, un domaine fonctionnel ou un chantier, et l’équipe sait qu’elle le possède
• Elle prend une part normale de la garde, des incidents et des escalades de soutien
• Elle contribue à la direction technique : elle propose des changements, remet des conceptions en question, rédige au moins un document de conception ou une proposition
• Elle peut intégrer la prochaine recrue dans son domaine, ce qui est le test le plus net de sa vraie absorption du contexte
• Le gestionnaire peut répondre à « cette embauche est-elle un succès » avec des preuves plutôt qu’une impression

Fermez le trimestre avec une conversation explicite : à quoi ont ressemblé les 90 premiers jours des deux côtés, quels sont les objectifs du prochain trimestre et quel parcours de croissance est sur la table. Les développeurs quittent rarement les entreprises où quelqu’un a tracé leur prochain chapitre au bout de trois mois.

Le système de parrainage qui fonctionne vraiment

Un parrain est un pair désigné comme l’humain par défaut de la recrue : la personne pour les questions qui semblent trop petites pour une rencontre et trop gênantes pour un canal public. Le système fonctionne quand quatre conditions tiennent.

Le parrain n’est pas le gestionnaire, parce que le calcul « cette question est-elle stupide » change quand celui qui écoute rédige votre évaluation de rendement. Le parrain travaille dans le même code, pour que les réponses soient concrètes. Le parrain s’est porté volontaire, parce qu’un parrain conscrit répond par monosyllabes. Et le temps du parrain est budgété : deux à quatre heures par semaine le premier mois, comptées comme du vrai travail dans la capacité du sprint, pas arrachées à ses soirées.

Donnez au parrain une structure légère : un point de 30 minutes chaque jour la première semaine, puis deux fois par semaine jusqu’à la fin du premier mois. Son canal privé avec la recrue est une soupape; ce qui s’y dit remonte au gestionnaire seulement sous forme de thèmes, jamais de citations.

La documentation et les accès comme produit d’intégration

Chaque intégration expose la même vérité : votre documentation est pire que vous le pensez, et les accès sont accordés sur le mode « demande quand tu es bloqué », ce qui transforme le premier mois de chaque recrue en chasse au trésor.

Traitez les deux comme des produits avec des responsables. L’ensemble documentaire minimal : un guide d’installation qu’une recrue peut suivre sans aide, un survol d’architecture avec un diagramme conforme à la réalité, un glossaire des termes et acronymes internes, un document « comment nous travaillons » (branches, normes de révision, processus de déploiement, processus d’incident) et un journal des décisions pour les choix que les gens vont autrement rejuger sans fin.

Pour les accès, maintenez une liste par rôle (« un développeur dorsal reçoit ces douze comptes avec ces niveaux de permission ») et accordez tout avant le jour un. L’alternative est que la recrue découvre l’accès manquant au moment exact où elle en a besoin, ce qui est toujours le pire moment.

Points de rétroaction : quoi demander à 30, 60 et 90 jours

Les rencontres individuelles hebdomadaires courent sur tout le trimestre, mais trois points méritent une structure. Posez des questions qui font remonter les problèmes pendant qu’ils coûtent encore peu.

À 30 jours : Qu’est-ce qui a été plus déroutant que prévu? Où la documentation vous a-t-elle menti? Que savez-vous maintenant que vous auriez aimé qu’on vous dise la première semaine? Le travail est-il plus difficile, plus facile ou différent de ce que les entrevues laissaient croire?

À 60 jours : Qu’est-ce qui vous ralentit et ne le devrait pas? Que changeriez-vous dans la façon de travailler de cette équipe? Avez-vous ce qu’il faut pour prendre votre domaine en charge? Qu’avez-vous vu chez nous qui semble une erreur, pendant que vous avez encore un regard extérieur?

À 90 jours : À quoi devrait ressembler le prochain trimestre? Que voulez-vous prendre en charge que vous n’avez pas encore? Qu’est-ce qui a failli vous faire regretter d’être venu, s’il y a quelque chose? Que devrions-nous changer dans l’intégration avant la prochaine embauche?

La question du jour 90 sur l’intégration elle-même n’est pas une politesse. Réinjectez les réponses dans la liste de contrôle, et l’intégration se bonifie au lieu de repartir de zéro à chaque embauche.

Intégration à distance : rendre l’implicite explicite

L’intégration à distance est le même plan avec une règle de plus : rien ne peut s’absorber par proximité, donc tout doit être écrit ou planifié.

• Expédiez le matériel au moins une semaine d’avance, avec un plan B s’il est en retard
• Enregistrez le survol d’architecture et la démonstration du produit, puis gardez-les à jour; ils deviennent des actifs pour chaque future embauche
• Planifiez plus de contact humain délibéré dans les semaines un et deux : de courtes rencontres individuelles avec chaque membre de l’équipe, pas seulement un appel de groupe
• Établissez la norme que les questions vont par défaut dans les canaux publics, et faites-la incarner par les seniors
• Faites faire au parrain un point vidéo quotidien les deux premières semaines; le silence est ambigu au bureau et invisible à distance
• Surveillez les heures de travail le premier mois; les nouvelles recrues à distance travaillent trop pour faire leurs preuves, jusqu’à l’épuisement

Le document d’intégration écrit compte doublement ici : une recrue à distance avec un plan clair se sent soutenue, et une recrue sans plan se sent abandonnée dès le troisième jour.

Le raccourci

Rien de tout cela ne peut être sauté, mais une partie peut être payée d’avance. Une grande part de l’anxiété du premier trimestre, des deux côtés, tient à la vérification des compétences : le gestionnaire qui guette les signes que la recrue peut vraiment faire le travail, la recrue qui performe devant un public. Quand un développeur arrive d’un réseau évalué comme turnkey.dev, la vérification des compétences a déjà eu lieu avant même que vous voyiez un profil, alors vos 90 jours peuvent se concentrer sur ce que vous seul pouvez enseigner : votre code, votre produit, vos clients et votre façon de travailler. C’est à cela que sert vraiment l’intégration. Peu importe la voie d’embauche, le plan ci-dessus fait la différence entre une recrue qui livre au premier mois et une recrue qui démissionne au quatrième.