Contexte du stage - l'entreprise

La structure

Le stage s'est déroulé chez Youkyi, la structure d'Alexandre Agasseau, professionnel indépendant basé dans le nord de la France. Secteur d'activité : l'hébergement et l'infrastructure. Son activité repose sur une infrastructure auto-hébergée qu'il administre lui-même, et sur laquelle ses clients font tourner leurs propres services.

Sa clientèle est composée de particuliers qui veulent héberger leurs propres solutions chez un prestataire plutôt que de les confier à un grand fournisseur. C'est un positionnement de niche, entre deux offres qui dominent le marché : l'hébergement mutualisé grand public, bon marché mais rigide, et les fournisseurs cloud, souples mais facturés à l'usage et exigeants en compétences. Une structure indépendante occupe l'espace intermédiaire, et y vend autant l'accompagnement que la machine.

Concrètement, il s'agit d'un homelab de taille conséquente : plusieurs machines Linux, des services mutualisés entre les clients, et les contraintes qui vont avec. Ce n'est pas un environnement de démonstration - ce qui tourne dessus est en production, et une erreur de configuration se voit immédiatement côté client.

J'ai choisi ce stage pour sa dimension infrastructure. Mon parcours était jusque-là orienté développement, et il me manquait la partie réseau et système pour aller vers un profil DevOps. Une structure indépendante offrait exactement ça : un périmètre large, peu de cloisonnement entre les rôles, et un accès direct à l'ensemble de l'infrastructure plutôt qu'à un domaine restreint.

Le stage a eu lieu de mai à juillet 2026, en fin de Bachelor 2. Ce format explique l'étendue des missions : sur une même période, elles couvrent l'administration de cette infrastructure, le développement web et les pratiques DevOps.

L'environnement de travail

Tout s'est fait à distance, sans aucune présence sur site. Trois canaux cohabitaient : Discord pour le quotidien, Teams pour les échanges plus cadrés, et la plateforme interne du tuteur, qui regroupait la documentation des services et les tâches à traiter.

Cette plateforme a compté plus que je ne l'imaginais au départ. Chaque service disposait de sa fiche, et une tâche renvoyait vers la documentation correspondante : avant de toucher à quoi que ce soit, on savait à quoi on avait affaire. C'est aussi ce qui m'a fait comprendre qu'une intervention n'est terminée que lorsqu'elle est écrite quelque part.

Le travail était organisé en deux créneaux par jour, le midi et le soir, chacun ouvert par un point avec le tuteur. En pratique, il consacrait environ deux heures à chaque prise et à chaque fin de poste : cadrage de ce qu'il y avait à faire en arrivant, revue de ce qui avait été produit en partant. Ce n'était donc jamais du travail en autonomie sèche - il y avait toujours quelqu'un pour valider une approche avant de la lancer.

Travailler à distance sur une infrastructure en production change la façon d'intervenir. Sans accès physique aux machines, chaque manipulation doit préserver le lien distant : une erreur qui coupe l'accès ne se rattrape pas en se levant de sa chaise. Cette contrainte a structuré ma méthode plus que n'importe quelle consigne.

Le périmètre technique couvre les services auto-hébergés (DNS, DHCP, VPN, supervision) et le site web de l'activité. Comme tout est utilisé en continu, chaque intervention impose une méthode : sauvegarde préalable, fenêtre d'intervention annoncée, plan de retour arrière prêt avant de toucher quoi que ce soit.

Travailler à trois

Nous étions trois stagiaires : Xerly, Romain et moi. Il n'y a pas eu de répartition des tâches entre nous - nous avancions en parallèle sur les mêmes sujets, chacun sur son périmètre, en restant en appel quasiment en continu. Cette configuration a changé la vitesse d'apprentissage : quand l'un bloquait, il y avait souvent quelqu'un qui avait rencontré le même mur une heure plus tôt.

L'infrastructure de travail était partagée, et c'est là que la collaboration est devenue une contrainte technique plutôt qu'une question d'organisation. Une machine commune, mais un compte par personne plutôt qu'un compte unique - décision prise pour la traçabilité : savoir qui a fait quoi n'est pas une formalité quand trois personnes interviennent au même endroit.

Concrètement, cela imposait des réflexes que je n'avais jamais eus en travaillant seul : préfixer ses conteneurs à son nom, vérifier quels ports étaient déjà occupés avant d'en publier un, et surtout identifier ce qui appartenait aux autres pour ne pas y toucher. Plusieurs fois, la bonne décision a été de contourner plutôt que de corriger quelque chose qui n'était pas à moi.

Côté encadrement, la structure est simple : un seul interlocuteur, le tuteur, qui validait les approches avant qu'on les lance et relisait ce qui avait été produit en fin de créneau. Aucune hiérarchie entre nous trois. Ma responsabilité portait sur mon propre périmètre - mes machines, mes services, mes interventions - avec l'obligation de ne pas dégrader celui des autres.

C'était ma première expérience d'un environnement où mon travail peut interrompre celui de quelqu'un d'autre. En projet scolaire, une erreur n'engage que soi. Ici, publier un port déjà pris ou redémarrer le mauvais conteneur arrêtait le travail de deux personnes.

Mes missions

• Administration réseau & infrastructure : cartographie du réseau, gestion DNS/DHCP/VPN, supervision et monitoring.
• Développement web : nouvelles fonctionnalités, audit qualité du code, refactoring et optimisation UI.
• DevOps : conteneurisation Docker/Compose, scripts Bash/Python, initiation Ansible, pipeline CI/CD (GitHub Actions).

Les articles de ce blog documentent ces missions : intégration, administration réseau, conteneurisation et automatisation, difficultés rencontrées, puis bilan.