De la startup à l'entreprise : ce que 5 pays m'ont appris

Cela fait maintenant 5 ans que je développe des produits numériques. J'ai eu la chance de voir un peu de tout : le chaos organisé des startups, le rythme effréné des agences web, jusqu'à atterrir dans la cour des grands.

En septembre 2024, j'ai posé mes valises chez Decathlon Digital en freelance. Pendant deux ans, notre équipe (qui s'est appelée ODVC, puis Teamwear, puis MyClub) avait une mission claire : créer une expérience de personnalisation de produits de dingue pour les pros et les clubs sportifs.

Je vais être honnête : j'appréhendais. Pas le code, non. L'échelle monumentale de Decathlon.

Le pouvoir du focus

Avant cette mission, surtout à l'époque où j'étais chez IVS, j'étais un véritable couteau suisse. Le genre de dev qui fixait un bug critique en prod le matin, faisait passer un entretien technique l'après-midi, et se retrouvait le lendemain à défendre l'application sur un stand lors de journées portes ouvertes à Lille. C'est ultra formateur, mais on a tendance à tout survoler.

L'environnement grand compte de Decathlon m'a appris un truc puissant : le focus.

J'ai enfin eu le temps de poncer Next.js jusqu'à ce qu'il n'ait plus aucun secret pour moi. J'étais un peu dans la peau de Satoshi Nakamoto rédigeant son whitepaper : isolé du bruit, focus à 100 % sur l'architecture, avec une exécution millimétrée. Faire chuter les temps de build d'un blog, basculer une route en dynamique juste en lisant un cookie, disséquer comment Next optimise les images sous le capot (WebP, AVIF, attribut sizes), ou muter le cache côté serveur avec les Server Actions... C'est devenu mon terrain de jeu.

On tournait sur Next.js 16, React 19, une intégration via Iframe pour les designs, et pour notre V2, on fait même de l'ombre à Shopify avec Medusa, son alternative open source.

Petit flex au passage

Je sais que le nombre de lignes de code n'est pas une fin en soi. Mais bon, on a refait toute l'architecture headless de la plateforme, et je regarde le rétroviseur avec un petit sourire : je termine sur le podium des plus gros contributeurs du projet.

Mais au fond, ce n'est pas cette quantité de code qui a été mon plus gros choc.

Le boss final : le blast radius

À petite échelle, tu codes, tu casses, tu fixes, personne ne voit rien. À l'échelle de Decathlon ? Ton blast radius (ta zone d'impact) est massif. Une erreur bête, et ce sont 5 pays, 5 devises et 5 contextes différents qui explosent.

J'ai vraiment capté ça en regardant comment on gérait le support. Au début, face à un bug remonté par un pays, tu as ce réflexe de "dev héros" : tu veux foncer et fixer le truc en direct. Grosse erreur. Dès qu'un pays capte que tu répares ses petits soucis instantanément, c'est fini. Tu deviens leur support technique personnel et c'est l'enfer.

Le vrai déclic ? L'arrivée d'un système de ticketing strict géré par les PM. Le but n'était plus d'être rapide, mais d'être intelligent et d'avoir une vision globale.

Comment on survit

Déployer tous les jours

Plutôt que de transpirer à chaque déploiement en faisant du pays par pays, on a opté pour la méthode bourrin, mais ultra safe : on livre tout le monde en même temps, tout le temps.

Nos releases s'appelaient 26-07-30 (Année-Mois-Jour). Le but ? Se forcer à ship le plus souvent possible. Le PM valide, on pousse sur les 5 pays d'un coup. Quand la mise en prod devient une routine quotidienne et banale, la peur disparaît.

L'i18n, ce n'est pas que traduire

Sur 5 pays, la vraie dette n'est pas technique, elle est fonctionnelle. Traduire du texte ? Facile. Formater des dates ? Une librairie fait ça très bien. Par contre, les règles métier par pays, c'est une autre histoire. Une règle de personnalisation qui passe en France mais qui est interdite en Allemagne, ça ne se factorise pas. Ça se documente, ça se teste (merci Vitest et GitHub Actions), et tu le paies à chaque nouvelle feature.

Penser comme un PM

L'une de mes meilleures claques n'a même pas eu lieu dans VS Code. J'ai pris l'initiative d'animer la rétro de l'équipe (le fameux "Sprint 33").

Pour marquer le coup (et parce que Christophe et Mehdi s'envolaient pour les US), j'ai fait ça en version "Special Edition" 100% en anglais. Le mood : "No pressure, no judgment, just good vibes".

Préparer cette cérémonie m'a obligé à retirer ma casquette de codeur pour mettre celle du PM. J'ai dû regarder ce qui comptait vraiment : comment on calcule notre vélocité réelle, pourquoi définir des vrais objectifs de sprint est vital, plutôt que de juste cramer des tickets comme des zombies.

Ce que j'en ai gardé

Avant, j'étais en mode "Agile, Jira, process" pour le boulot, et "YOLO on verra bien" pour mes projets persos. Aujourd'hui, j'ai fusionné les deux.

L'environnement carré de Decathlon m'a complètement influencé. Pour mon SaaS actuel, Prospect Tracker, je bosse avec la même rigueur :

• Linear est devenu mon meilleur ami : Je crée mes sprints et je me fixe des objectifs.
• Rétro en solo : Oui, je fais des bilans avec moi-même. Si je rate un objectif, j'essaie de comprendre pourquoi. Si j'ai tout explosé, je me demande si j'étais assez ambitieux. Je laisse même des commentaires sur mes propres tickets pour le "moi" du futur.
• Les ADR (Architecture Decision Records) : J'ai découvert ça avec l'équipe Design System de Decathlon. Écrire pourquoi je choisis une stack m'évite de refaire le monde tous les 6 mois au gré des modes. Le but, c'est de ship fast.

Bref, deux ans chez Decathlon, ça t'apprend à coder des plateformes solides. Mais ça t'apprend surtout que pour avoir de l'impact, un dev doit capter le produit et l'organisation. Et ça, c'est une compétence qui marche partout, même quand ton seul utilisateur, c'est toi.