L’accueil d’un nouvel arrivant

L’Aventure du Nouvel Arrivant : Un Jeu de Piste Informatique

Un nouveau débarque sur le projet ? On ne l’attendait plus… mais le voilà ! Il ne sait pas dans quoi il met les pieds, et nous non plus. Bref, un moment toujours aussi palpitant (et vaguement inquiétant).

Le moment où l’on se pose de nombreuses questions. Qui va l’accueillir ? (C’est la période de vacances…). Qui va lui faire le transfert de compétences ? Où sont les docs ? Comment cela, on n’a pas de docs ? Qui a commandé son ordinateur ? Comment cela, pas d’ordinateur livré avant 3 mois ?

Jour 1 : L’atterrissage forcé

Il débarque, motivé, sourire aux lèvres. On lui donne un PC encore sous blister (miracle !) et un accès réseau… enfin, sur le papier. Après quelques tentatives infructueuses, il découvre que la procédure d’ouverture de compte nécessite cinq validations, dont celle d’un collègue actuellement en congé sabbatique. Pas grave, il va commencer par comprendre le projet. Et là, premier obstacle : « Ah ? On ne t’a pas envoyé la doc ? » Spoiler : il n’y a pas de doc.

Jour 2 : La quête des accès

Le matin, il tente de se connecter aux outils essentiels. Mauvaise surprise : le VPN ne fonctionne pas. Après un échange avec le support IT, il découvre que son compte n’a pas été ajouté au bon groupe. Deux formulaires, un ticket et trois heures d’attente plus tard, il obtient enfin un accès… partiel. Git ? Ah non, il faut une autre demande. Jira ? Encore une autre. Son manager compatit mais ne peut rien faire : « C’est comme ça ici ».

Jour 3 : La jungle des acronymes

Après deux jours à essayer de comprendre ce que signifie TBD dans les spécifications (« To Be Defined »… depuis trois ans), il parvient enfin à poser une question en réunion. Réponse immédiate : « Ça, c’est dans le Wiki ». Le fameux Wiki. Une légende locale, dont l’URL se transmet par bouche-à-oreille, un Graal numérique où chaque page date du siècle dernier. Après une longue expédition, il met enfin la main dessus… pour constater que les trois quarts des liens sont cassés.

Jour 4 : L’exploration du code

Il se plonge dans le code source. Structure anarchique, commentaires absents ou ésotériques (« Ne touche pas à ça, ça casse tout »), commits dont les messages rivalisent avec Da Vinci Code (« Fix bug », « Essai 2 », « Marche enfin ! »). Il repère une dépendance critique… qui a été développée en interne par un ancien développeur parti depuis cinq ans. Aucun README, aucune documentation.

Jour 5 : L’intégration (ou tentative)

C’est là qu’il se dit qu’il aurait mieux fait de se reconvertir dans le jardinage. Il lui faut une VM pour commencer à tester. « Ah, faut voir avec l’équipe infra ». Après une quête administrative digne des douze travaux d’Hercule et une série d’échanges par e-mail où tout le monde est en copie, il obtient enfin son environnement… sauf qu’il manque une librairie critique qui n’est plus maintenue depuis 2015. Il sollicite un collègue, qui lui répond : « Ah oui, on a un patch maison pour ça… attends, je retrouve où je l’ai mis. » Suspense.

Semaine 2 : Le grand test

On lui confie une première tâche. Facile en apparence, jusqu’à ce qu’il découvre que le code qu’il doit modifier a été écrit par un ancien développeur visionnaire, parti vers d’autres horizons en laissant derrière lui un héritage digne d’une enquête archéologique. Le tout sans tests unitaires, bien sûr. Il essaie de faire une modification, compile… erreur. Il suit la trace des logs, tombe sur une dépendance cassée, tente de la mettre à jour… et casse autre chose.

Semaine 3 : Les questions du management

Les premières questions fusent du côté du management : « Ça fait trois semaines et il n’a encore rien produit ? Il est vraiment à la hauteur ? Pose-t-il des questions ? Mais surtout… est-ce qu’il a l’air occupé en visio ?

Bref, on ne laisse pas le temps aux nouveaux d’atterrir sereinement, productivité à tout prix !

Semaine 4 : Premier ticket en production

Après des jours de correction et de contournements, il est prêt pour la mise en prod. C’est vendredi, bien sûr. Tout semble rouler jusqu’à l’annonce fatidique : « On a une régression en prod ! ». Panique générale, rollback, réunion de crise. Son fix a révélé un effet de bord caché depuis des années. Dans l’équipe, certains lui tapent sur l’épaule en souriant : « Ça y est, t’es vraiment des nôtres ! ».

La morale de l’histoire

Ce scénario vous semble familier ? L’intégration d’un nouveau dans une équipe est souvent un mélange de non-dits, de process flous et de documentation en ruines. Pourtant, quelques bonnes pratiques pourraient transformer ce chaos en accueil fluide :

1. Un onboarding digne de ce nom : un guide de survie pour le projet, avec les accès, les outils, et l’URL du Wiki.
2. Une documentation vivante : mise à jour régulièrement, sans informations obsolètes.
3. Un référent désigné : un parrain/marraine pour répondre aux questions sans soupirer (ou du moins en soupirant discrètement).
4. Une infrastructure accessible : des accès configurés en amont pour éviter les délais absurdes.
5. Un projet lisible : tests, conventions de code, et pourquoi pas un peu d’automatisation pour éviter les épreuves dignes d’Indiana Jones.

Bref, accueillons nos nouveaux avec plus qu’un « Installe-toi là, on verra plus tard ». On dit que le code, c’est de la technique. Mais accueillir un nouveau, c’est de l’humain. Et l’humain, ça ne se documente pas… mais ça se prépare. Parce qu’un onboarding raté, c’est non seulement frustrant pour le nouvel arrivant, mais aussi une perte de temps pour toute l’équipe. Et après, on s’étonne qu’il parte avant la fin de sa période d’essai…

Et vous, quel est votre pire expérience d’intégration ?