Side Quests pour développeurs juniors — un chemin léger vers la montée en compétences – Sylvain Artois

En 2024, je dirigeais une petite équipe technique chez Harvy, une startup early-stage dans le secteur agricole, basée à Station F à Paris. Notre équipe tech, deux développeurs juniors et moi-même en tant que CTO. Notre mission principale était de construire un système de facturation flexible. Pensez facturation consolidée à la Amazon : une seule facture pour plusieurs fournisseurs. Techniquement exigeant, nécessitant précision et coordination.

Pour livrer dans les temps, nous avions adopté une organisation assez top-down : je rédigeais la plupart des user-stories sous forme de « recettes » afin de minimiser les frictions et d’assurer l’alignement. Cette approche a fonctionné — nous avons livré un système de facturation complet en octobre — mais elle laissait peu de place à l’initiative et à la créativité côté développement.

C’est là que j’ai introduit ce que nous avons appelé la side quest du développeur Harvy.

Qu’est-ce qu’une Side Quest ?

Une side quest est un petit projet personnel, mené dans le cadre du travail de sprint habituel. La seule règle ? Le projet doit apporter de la valeur à l’équipe. Au-delà de ça, le développeur est libre d’explorer. Une fois le périmètre validé, les tâches de la side quest sont traitées comme n’importe quelle autre : elles peuvent être estimées, priorisées, ajoutées au board et revues exactement comme des stories de sprint.

Chez Harvy, nous avions formalisé ce concept dans le cadre de nos revues semestrielles. Chaque développeur choisissait une side-quest en collaboration avec l’équipe de direction. Le périmètre était co-défini pendant la revue, et l’avancement était suivi de manière informelle lors des 1:1 réguliers. Ce n’était pas un projet hobby — c’était une étape intentionnelle vers l’autonomie et la maturité technique.

Nous avions identifié trois types courants de side quests :

Auto-formation — par exemple, se plonger dans les techniques avancées de Git et produire une note de workflow, une synthèse ou une cheatsheet pour le reste de l’équipe.
Refactoring — s’attaquer à un morceau de dette technique identifié avec le CTO (restructurer un contrôleur, améliorer des modèles de données, nettoyer une vue legacy).
Outillage développeur — optimiser la vitesse de build, améliorer la fiabilité de Docker, mettre en place Storybook, ou construire des dashboards internes comme des panneaux Datadog.

Une fois lancée, la side quest appartenait au développeur. Il pouvait rédiger des stories ou de la documentation s’il le souhaitait, mais l’essentiel, c’est lui le pilote.

Pourquoi ça a marché

Les side quests coûtent peu, mais rapportent beaucoup. Dans un environnement où les tâches de sprint sont très cadrées, elles offrent :

De l’autonomie — une occasion rare d’explorer, d’expérimenter et de prendre des décisions.
De la motivation — les développeurs sont plus engagés quand ils sont propriétaires de ce qu’ils construisent.
De l’apprentissage — les side quests amènent souvent les développeurs à toucher des zones qu’ils n’auraient jamais atteintes par le seul travail de sprint.

Mais pour que ça fonctionne bien, j’ai constaté qu’un lancement bien cadré fait toute la différence. La liberté sans structure peut mener à l’inertie. La meilleure façon de démarrer :

Poser le cadre tôt — dans les premiers jours.
Aider à définir les premiers jalons — même grossièrement.
Puis prendre du recul — et laisser l’appropriation grandir.

Pour conclure

Tous les développeurs ne saisiront pas l’opportunité. Mais quand ils le font, le retour est réel — en confiance, en compétences et en culture d’équipe. Dans les équipes très encadrées, en particulier celles avec des profils juniors, les side quests offrent une bouffée d’air frais et un chemin vers une vraie montée en compétences.