Ah, les stagiaires… on les aime autant qu’on les déteste ensuite, souvent à cause de ce qu’ils laissent derrière eux comme héritage de code dans un projet, ou pire, sur la totalité d’un projet « from scratch » qui leur a été confié.

Alors le code du stagiaire serait-il voué à être mis dans la poubelle jaune la semaine qui suit son départ ? Non, évidemment, et je dirais même plus, si vous êtes incapables de reprendre le code du stagiaire, c’est de VOTRE FAUTE.

Le but du stagiaire

A quoi sert un stagiaire ? De nombreux anthropologues se sont penchés sur la question, et si les avis divergent notamment sur le rôle du stagiaire dans la socialisation du groupe, il est communément admis que celui-ci s’inscrit dans une démarche de perpétuation de l’espèce par la transmission d’un savoir ancestral.

Le stagiaire est avant tout là pour observer le groupe qui l’accepte et ensuite imiter les comportements grégaires comme “la pause café” ou “le repas du midi”, avant de pouvoir à son tour tenter de construire des trucs par lui-même comme par exemple : “installer microsoft word”.

La phase de construction qui suit la phase dite de “découverte sociale” est souvent accompagnée par un ancien. On observe que l’ancien à qui il a été confié cette tâche devra alors souvent s’armer de patience pour ne pas claquer la tête de son élève. Une récente étude sur le langage non verbal détaille des phases dites “périodes d’onboarding”, pouvant être ponctuées de périodes où l’ancien est pris de ce qu’on appelle le “désespoir”.

La « période de stage », désignant l’intervalle pendant lequel le stagiaire est accepté par la meute, s’achève systématiquement par la production d’un document papier ou informatisé appelé « rapport de stage ». Ce document détaille les activités du stagiaire comme « taper au clavier » ou « jouer au baby-foot » et est généralement relu puis validé par un ancien. Lors d’une activité de type informatique, le stagiaire remet également dans la plupart des cas l’ensemble des éléments qu’il aura produit dans un gros sac informatique appelé « zip » qu’il transmettra à l’aide d’une technologie de déplacement de données binaires, comme par exemple la « clé USB ».

Ainsi s’achève la « période de stage » et par là même disparaît le « stagiaire ». Dans certains cas, l’individu intégrera ensuite la meute, devenant un « employé junior », mais cette transformation ne semble pas systématique, et obéit à des règles sociales qui n’ont pas encore été décodées par les anthropologues.

Reprendre le code du stagiaire

Si vous exercez une activité de type informatique et que vous avez pris un stagiaire, il y a fort à parier que vous avez un objectif pour son activité. Que cela soit l’exploration d’un domaine dont vous ne pouvez vous occuper ou bien la consolidation d’un produit existant, il va vous falloir reprendre le code source du stagiaire.

La manière la plus efficace de reprendre le code du stagiaire est de travailler avec lui au quotidien. Ce n’est pas toujours possible mais c’est une composante qui permettra non seulement à celui ci d’acquérir de nouvelles compétences, mais aussi vous permettra d’obtenir un projet de qualité.

Source de l’image : https://www.monkeyuser.com/2022/done-done/

Alors quoi faire au quotidien des quelques lignes de code quotidiennes du stagiaire ? Faut-il lui demander de produire dans une branche et fusionner régulièrement ? Faut-il le laisser produire sur la branche principale et retoucher son travail ensuite ? Une chose est sûre : il faut éviter qu’il produise dans son coin trop longtemps.

Au cours d’une de mes précédentes expériences, j’ai pu moi-même au cours d’un de mes stages être mis en autonomie sur de très longues périodes de plusieurs semaines ou plusieurs mois. Ce sont des expériences intéressantes, mais très probablement, ce que j’ai produit n’a pas été utilisé, car au moment de la restitution j’ai bien senti l’effort conséquent qu’il faudrait au repreneur pour comprendre les choix techniques, comprendre le code, et potentiellement modifier le contenu.

La stratégie de la même branche

Lors de mon premier stage, j’étais dans une petite équipe avec une grande partie des contributions apportées par moi et mon maître de stage sur ce projet, et nous travaillions sur la branche principale tous les deux.

Ce mode de fonctionnement est très riche d’enseignements, notamment car il y avait parfois des soucis de fusion de code. J’ai pratiqué énormément git et ses commandes d’historique et cela me sert encore aujourd’hui. Souvent, je regardais ce que mon maître de stage modifiait, et je pouvais lui poser des questions sur ses choix. Très souvent, il repassait derrière moi pour modifier mes productions et comme c’était dans la même branche, c’était très facile de voir ses modifications et sa logique. Ses commits étaient toujours très nets et c’était très lisible, par exemple :

• Corriger une typo = un commit
• Séparer des responsabilités dans le code = un commit
• Changer le nom d’une fonction = un commit

J’ai beaucoup appris au cours de ce stage car chaque élément retouché avait du sens, et j’avais un retour immédiat quand il fallait modifier quelque chose.

Ce mode de fonctionnement est pour moi le meilleur qu’il soit pour le stagiaire comme pour l’encadrant, à condition bien évidemment que l’encadrant travaille au quotidien sur le même projet que son stagiaire et avec un nombre d’heures équivalent. Les temps de relecture et d’explication du code par l’encadrant à son élève pourront ainsi être absorbés au fil de l’eau.

La stratégie “fusions régulières”

Lorsque j’ai été plus tard encadrant d’un stagiaire, je ne travaillais pas à temps plein sur son projet de stage : seul un jour par semaine m’était alloué. Il fallait donc trouver une solution qui me permette de relire ce qu’il faisait tout en lui laissant la main libre sur la plupart des choix technologiques du quotidien. J’ai donc opté pour la stratégie suivante : il travaillait dans des branches et moi j’utilisais ma journée avec lui pour relire le travail de la semaine. Ensuite, on fusionnait ensemble la production en peer-programming. Un effet immédiat de ce fonctionnement est que mon stagiaire n’a malheureusement pas beaucoup pratiqué les commandes de fusion git et la résolution de conflits de fusion.

Lors des journées où on faisait la fusion sur la branche principale, je ne faisais bien entendu pas que critiquer, on ajoutait ensemble des commits le plus nets possibles (comme le faisait mon maître de stage pour moi auparavant) pour que le code du stagiaire finisse par me convenir, tout en lui expliquant pourquoi je changeait chaque chose, en pair programming avec lui à côté. J’espère avoir pu lui transmettre du mieux possible les éléments dont je disposais, n’étant pas à temps plein sur le projet je ne pouvais malheureusement pas fonctionner différemment.

En bref, pour travailler à base de fusion de branche, mon conseil sera le même que le conseil général : évitez de laisser les choses avancer toutes seules trop longtemps, sinon vous passerez des journées entières pour relire et fusionner le travail d’une seule personne. Evaluez la vélocité de votre stagiaire, demandez-lui de produire des merge request “prête à fusionner” tous les jours ou tous les semaines par exemple, et s’il y a des choses “pas finies” sur lequel il est toujours en train de travailler dites lui de garder ça pour une autre merge request : cela lui apprendra aussi à travailler par fonctionnalité au lieu d’écrire tout d’un seul bloc.

En conclusion (1)

Bref, vous allez crier à l’arnaque, mais pour reprendre le code du stagiaire il suffit de le faire au fil de l’eau, c’est aussi simple que ça.

Cependant, comment faire si vous héritez d’un projet de stagiaire à maintenir alors que vous n’avez pas surveillé son avancée ? Cela m’est arrivé chez Devoteam Revolve, lorsque j’ai voulu modifier un projet intéressant qu’avait produit un de nos stagiaires. Problème : je n’avais pas participé à ce projet et le maître de stage n’y avait pas contribué en pair programming non plus. Voici, dans le prochain chapitre, quelques astuces pour arriver à reprendre le code d’un stagiaire sans tout refaire de zéro.

Reprendre quand même le code du stagiaire quand on a rien suivi de son projet

En supposant que le stagiaire soit parti et que vous n’ayez que peu – voire pas du tout – suivi l’activité de votre stagiaire, ou bien que le projet était suivi par une autre personne qui a quitté cette activité, la reprise du travail s’annonce très difficile voire impossible. On pourrait être tenté de tout mettre à la poubelle et recommencer, et pourtant, il serait dommage de tirer un trait sur tout le travail d’un humain : il y a quand même des éléments qui sont utiles voire utilisables.

Bien évidemment, je vois d’ici mes collègues brandir le biais des coûts irrécupérables, le but n’est pas de reprendre le projet à tout prix. Cependant, reprendre quelque chose de bancal reste profitable pour peu qu’on ait un peu de techniques pour le faire, ce que je vais vous enseigner dans ce chapitre. Certes, l’argument « on a investi il faut que ça serve » n’est pas un argument, mais je regrette que trop souvent l’abandon des coûts irrécupérables serve de tête de pont aux fadas du « from scratch » comme on dit dans le sud. Reprendre un projet « tout merdique » est une option tout à fait envisageable même en considérant perdus les coûts passés.

Alors comment faire ? C’est très simple : la première chose est de se poser la question de ce que le stagiaire peut nous enseigner à travers son projet. COMMENT ? UN STAGIAIRE À L’EXPÉRIENCE LIMITÉE PEUT APPRENDRE QUELQUE CHOSE À UN VIEUX BARBU COMME MOI ?? Réponse : oui. Et au passage arrêtez avec ce truc des barbus s’il vous plaît : la pilosité faciale ne procure aucune compétence en informatique, toutes les études l’ont démontré.

Sortons donc un instant de notre tour d’ivoire, et contemplons la boîte mystère que le stagiaire nous a léguée et qu’il a construite avec ses petites mains sur le clavier que vous lui avez prêté. Commençons par une analyse statique du code, en ouvrant des fichiers et en essayant de comprendre la structure, sans rien modifier ni exécuter. Tout au long de l’analyse, vous devrez noter sur un coin de table les éléments suivants :

• Quelles sont les parties visiblement achevées et quels sont les éléments inachevés (« achevé » ne veux pas dire « fonctionnel » !)
• A quels endroits le stagiaire a visiblement galéré
• Quels sont les solutions surprenantes que je stagiaire a implémentées (ou qui vous paraissent stupides)
• Pourquoi le stagiaire a fait tel ou tel choix, est-ce par méconnaissance, ou bien y avait-il quelque chose que vous ne voyez pas ?
• Pourquoi certains éléments ont pu être réalisés et pas les autres ?

Chemin faisant dans le code source, vous avez déjà collecté une véritable montagne d’informations utiles, par exemple :

• Si les parties inachevés sont le fait d’un manque de droits d’accès par exemple, il y a peut être quelques chose à améliorer dans votre organisation sur les méthodes de travail, l’encadrement des juniors, ou tout simplement le processus d’octroi des accès.
• Si des éléments ont été construits de manière trop naïve, le stagiaire n’a très probablement pas eu l’opportunité d’apprendre d’un pair plus expérimenté et c’est terrible autant pour vous que pour lui. Il faudra de toute urgence corriger ce problème avec les prochains stagiaires.
• Si en analysant une méthode surprenante vous identifiez qu’il s’agit d’un contournement d’une contrainte technique que vous ignoriez : bingo ! Notez-le, ça vous fera un truc pour le crédit impôt recherche.

Vous voyez que même sans exécuter le projet, votre stagiaire vous a laissé des dizaines d’éléments d’apprentissage, techniques ou non, et c’est déjà une réussite. Oui, un stagiaire vous a appris quelque chose !!

Allez maintenant c’est le moment de rentrer dedans : on va reprendre le projet. Quelques questions simples :

• Le projet compile-t-il ? (si langage compilé)
• Le projet peut-il être exécuté dans un environnement « vide » voire « initialisé automatiquement » à minima ?
• Le projet s’intègre-t-il au aux outils de développement de l’entreprise ? (Usine logiciel, pipelines de livraison, etc)
• Le projet possède-t-il des tests unitaires ?
• Le projet remplit-il les fonctionnalités pour lesquelles il est conçu ? Si oui, lesquelles ?
• La structure du code et du projet le rend-il facilement modifiable ? (On peut penser notamment à OpenClose Principle par exemple)

En fonction des réponses, il suffira ensuite de dérouler les étapes suivantes :

• Faire compiler le projet. Cela demandera peut être à se battre avec des librairies, rétro-concevoir le code source ou encore lire le document explicatif que le stagiaire a laissé (ou pas). Ne modifiez rien, ou alors uniquement dans le but de faire fonctionner la compilation sur votre poste.
• Faire fonctionner le projet dans un écosystème vide ou initialisé automatiquement. Cela demandera peut-être de créer un écosystème de référence (avec Docker, pourquoi pas) ou bien de faire fonctionner ce qui existe avec des scripts d’initialisation. Essayez d’en faire le minimum: ne vous lancez pas dans l’automatisation avec Ansible si cela n’existe pas, par exemple. Faites au plus rapide, comme s’il fallait mettre en prod dans une heure.
• Intégrez le projet aux environnements de développement de l’entreprise (si ce n’est pas déjà fait, bien sûr). Renforcé par des deux précédentes étapes, il vous est désormais facile de faire rentrer le projet dans une chaîne de compilation automatisée, ainsi que dans un environnement d’intégration continu (même sans tests unitaires, à minima vous pourrez faire un déploiement de démo grâce à l’étape 2). Évidemment, si le projet n’est pas suivi par un gestionnaire de version comme git, versionnez-le…
• Ajoutez des tests unitaires ou d’intégration s’ils n’existent pas ou sont insuffisants. C’est probablement l’étape la plus pénible, mais encore une fois, faites au plus rapide : le but n’est pas d’accorder une couverture complète mais de poser quelques validations sur « tel que ça fonctionne actuellement ». Peut être que certains tests que vous écrirez sont en contradiction avec la spécification initiale, mais c’est la photo du code « tel qu’il est », respectez-le. Cette étape est cruciale pour permettre un refactoring serein plus tard.
• Armé-e des tests unitaires et de votre environnement d’intégration et de test automatique, faites un point sur les fonctionnalités pour mettre le logiciel en test utilisateur: si certaines sont absolument nécessaires (l’intégration au SSO de l’entreprise par exemple) alors ajoutez-les (en modifiant le minimum de choses !). Les tests unitaires écrits tantôt vous permettront de valider la non-régression, et avec l’appui des utilisateurs, vous identifierez peut-être que certaines fonctionnalités contraires à la spécification sont en réalité celles attendues, car le stagiaire a vu ça en direct avec les utilisateurs sans le reporter dans les documents d’architecture. Le cas échéant, mettez à jour la spécification ou bien corrigez le comportement en modifiant le moins possible l’application (oui ça fait mal au cœur mais patience)
• Enfin, refactorez ! Il est très probable que le code du stagiaire ne soit pas fait dans les règles de l’art ou dans les standards de l’entreprise, et c’est normal. À l’aide des tests unitaires et de l’intégration continue, vous pourrez modifier le code sans changer le comportement. Un conseil : agissez par étapes, concentrez-vous sur des éléments « quick win » comme par exemple utiliser un framework pour la base de données au lieu de requêtes SQL en direct. Valorisez à chacune de vos modifications en vous écrivant mentalement à quoi sert chacune de vos interventions, par exemple : « ce code sera davantage sécurisé » ou bien « ceci permettra de retirer les éléments inutilisés ». Cela vous aidera à ne pas vous essouffler et à garder du sens à votre travail. Réservez les grand chantiers comme l’éclatement d’une fonction monolithique à des zone où vous pouvez baliser le code avec des tests en « boîte noire », que vous supprimerez lorsque vous aurez validé le nouveau comportement avec les tests unitaires créés au cours du refactoring (oui, bien évidemment, vous fera des tests unitaires au fil des modifications). Les étapes de reconstruction structurelle, si nécessaires, comme par exemple basculer sur une architecture Modèle-Vue-Présentation sont à placer à la toute fin de la reconstruction, car elle nécessite d’avoir éclaté les fonctions monolithiques, et d’avoir suffisamment de tests unitaires qui protègent les fonctionnalités. C’est exactement comme refaire un tableau électrique sans étiquette : une fois que tous les fils sont enfin rangés par responsabilité, il suffit de placer les nouveaux disjoncteurs et ranger par ligne en respectant les règles d’ampérage bien sûr.

Vous avez terminé ? Félicitations, vous avez repris le code du stagiaire !

Reprendre le stagiaire

Nous l’avons vu en introduction, parfois, on reprend aussi le stagiaire. Alors est-ce une bonne idée de faire travailler ce nouvel employé sur le même projet que celui de son stage ? Cela peut paraître surprenant, mais je vous le déconseille fortement. En cas d’embauche du stagiaire, il faudra à tout prix lui trouver un autre projet pour son expérience d’employé, comme si c’était une nouvelle personne.

Le pire combo, qui malheureusement se produit dans certaines entreprises serait de faire travailler l’ancien stagiaire avec un nouveau stagiaire pour améliorer le code du stagiaire initial. Bonus si en prime l’ancien stagiaire est maître de stage du nouveau : vous avez créé à coup sûr une usine de mésapprentissage qui se terminera tragiquement pour le projet ou l’entreprise ou les individus.

Sans aller à ces extrémités qu’on pourrait appeler un “projet conduit par une blockchain de stagiaire », plusieurs raisons m’amènent à déconseiller le réemploi de l’ancien stagiaire à son activité initiale :

• Aussi compétent qu’est votre nouvel employé, il a très probablement fait des erreurs au cours de son stage, que cela soit dans son code ou au-delà. Le placer au même poste le prive d’une opportunité de comprendre ces erreurs dans un contexte différent. La première raison pour laquelle il ne faut pas demander à un ancien stagiaire de reprendre son projet de stage, est que cela l’enferme dans le niveau de compétence dans lequel il était lors de son stage.
• Ensuite, pour que le projet du stagiaire puisse prendre une dimension globale, il est dans tous les cas absolument nécessaire qu’une personne expérimentée aux rouages de l’entreprise puisse lui insuffler un nouvel élan. Cette opération de reprise du code du stagiaire que je détaillais tantôt peut être fastidieuse, et ce n’est pas rendre service au nouvel employé de le mettre face à une personne qui déconstruira peut être pièce par pièce plusieurs parties de son travail. Même avec le plus bienveillant des employés (si tenté que vos profils seniors le soient…), il est tout à fait improbable que l’employé expérimenté prenne le temps d’expliquer point par point tout ce qu’il reconstruira et que l’ex-stagiaire désormais doté d’une légitimité d’employé junior l’entende avec toute l’écoute nécessaire. Cela va paraître terriblement fataliste mais placer un employé expérimenté avec l’ancien stagiaire sur le code du stagiaire cela ne fonctionnera pas et cela se terminera par le départ de l’un ou l’autre du projet voir de l’entreprise.
• Par ailleurs, dans l’éventualité où le stagiaire ait travaillé en autonomie ou quasi autonomie, vous devrez considérer quelque chose de non technique qui vous arrivera en plein visage: la fierté. L’ancien stagiaire est souvent assez fier de son travail, ou au moins de certaines parties. Voir quelqu’un d’autre critiquer ou modifier son code qu’il pensait parfait peut provoquer des conflits. J’ai pu faire l’expérience au cours de ma carrière de personnes (pas forcément stagiaires par ailleurs), qui considéraient que ce qu’ils avaient produit était divin et qu’il ne fallait absolument pas y toucher sans leur envoyer un mail détaillant pourquoi. De telles manières de travailler sont non seulement inefficaces mais toxiques. En retirant le stagiaire de son ancien code, vous éliminez une potentielle « propriété » et limitez ainsi les velléités de paternité stériles.
• Enfin, votre ancien stagiaire est désormais un employé et doit être considéré comme un collaborateur par les autres. Placer ce nouvel employé dans une équipe différente le mettra automatiquement dans une position d’employé junior reconnu comme tel sans effort de votre part. L’expérience montre que conserver les activités pré-embauche d’un individu demande davantage de temps à l’ancien stagiaire pour être accepté comme employé à part entière et nécessite souvent des rappels à l’ordre de la hiérarchie auprès des autres pour que celui-ci ne soit plus appelé « le stagiaire ». Cela peut vous paraître potache, mais vous devez combattre ce genre “d’humour” car il est tout à fait condescendant de continuer à appeler un collègue « stagiaire » lorsque celui-ci ne l’est plus. Cela peut vous sembler exagéré mais ce sont des situations auxquelles j’ai déjà assisté.

Pour conclure

Pour conclure, le stagiaire est un animal fascinant, à bien des égards. Comme une sorte de bébé kangourou se développant dans la poche d’un adulte, le stagiaire a encore beaucoup à nous apprendre sur ses interactions et l’impact de sa présence auprès des autres membres du troupeau.

Les anthropologues ayant étudié ces créatures et leur rôle au sein de l’écosystème « entreprise » s’accordent en tout cas sur une chose : la présence d’un stagiaire change très sensiblement le comportement de la meute, et les effets perdurent après son départ. Certains chercheurs avancent le fait que le stagiaire joue le rôle de poupon de substitution, permettant aux plus âgés d’exercer une qualité de « parent enseignant » et ainsi démontrer aux autres leurs capacités à être de bons partenaires pour la reproduction. De telles études restent cependant très critiquées et sont souvent qualifiées de loufoques. En effet, la reproduction sexuée au sein de l’entreprise, si elle n’est pas anecdotique, reste rare et aucune corrélation n’a été établie par rapport à une meilleure attractivité sexuelle des maîtres de stage par rapport aux autres employés de la meute.

Il reste cependant indubitable que le stagiaire fait partie d’un processus de perpétuation de l’espèce, par la transmission du savoir ancestral d’une entreprise. L’employé de bureau ne possède en effet que peu d’alternatives pour transmettre son savoir-faire, la reproduction sexuée engendrant un délai d’onboarding de plusieurs années. Une raison suffisante, s’il en fallait une, pour convaincre vos dirigeants d’adopter un stagiaire pour quelque temps et pourquoi pas le garder par la suite si vous vous y êtes attachés.