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

Cela fait cinq ans que je développe des produits numériques, et j'ai eu la chance de voir un peu de tout.

D'abord le chaos organisé des startups, où tu touches à tout parce qu'il n'y a personne d'autre pour le faire. Puis le rythme des agences web, où le projet suivant commence avant que le précédent soit fini. Chez IVS, j'étais le couteau suisse de service : un bug critique en prod le matin, un entretien technique l'après-midi, et le lendemain sur un stand à Lille pour défendre l'appli devant des visiteurs. Ultra formateur. Mais on survole tout, tout le temps.

En septembre 2024, j'ai posé mes valises chez Decathlon Digital en freelance.

J'appréhendais. Pas le code, l'échelle.

Pendant près de deux ans, j'ai intégré l'équipe Teamwear (qui s'est appelée ODVC avant, puis MyClub ensuite). Notre mission : une plateforme e-commerce headless de personnalisation de produits sportifs, pour les clients professionnels et les clubs.

Concrètement, un club arrive avec son logo, le configure sur un maillot, choisit ses couleurs, et commande pour quarante joueurs avec un nom et un numéro par pièce. Le tout dans sept pays : Allemagne, Espagne, Italie, France, Belgique, Pologne et Pays-Bas.

C'est cette dernière phrase qui a tout changé pour moi.

Ce que le focus change

Mais avant d'en arriver là, il s'est passé quelque chose d'inattendu : pour la première fois, je n'avais qu'un seul sujet.

Le temps de poncer Next.js jusqu'à ce qu'il n'ait plus de secrets. Faire chuter les temps de build. Basculer une route en dynamique juste en lisant un cookie. Disséquer la façon dont Next optimise les images (WebP, AVIF, l'attribut sizes). Muter le cache serveur avec les Server Actions.

Ça a l'air anecdotique dit comme ça. Ça ne l'est pas. Quand tu passes deux ans sur le même outil, tu arrêtes de chercher sur Stack Overflow et tu commences à comprendre pourquoi c'est fait comme ça.

Le terrain de jeu aidait. Côté front, Next.js 16 et React 19 pour la personnalisation en temps réel. Côté back-office, Shopify, branché en headless via ses API GraphQL Storefront et Admin. Et pour tenir tout ça : TypeScript, une stratégie de tests unitaires avec Vitest, et un pipeline CI/CD sur GitHub Actions.

S'ajoutait Unmade pour le rendu des designs, et c'est un bon exemple de ce que le focus permet. Unmade génère l'image de la personnalisation, ce qui veut dire que notre application ne possède jamais le visuel final du produit qu'elle vend. Comprendre où s'arrête notre responsabilité et où commence la leur prend du temps. Le genre de temps qu'on n'a pas quand on jongle entre trois projets.

C'est en connaissant ce terrain qu'on a pu envisager la V2 sur Medusa, l'alternative open source à Shopify.

Le sujet n'était pas de suivre une mode, mais une limite qu'on connaissait par cœur à force de la contourner. Un maillot avec un logo de club, une taille, un numéro et un nom n'est pas un article de catalogue : c'est une combinaison, et elle est quasi unique à chaque commande. Shopify raisonne en variantes prédéfinies. Nous, on avait besoin de modéliser la personnalisation elle-même. Medusa, qu'on héberge et qu'on étend nous-mêmes, nous laissait faire ça.

Sur la mission, je travaillais sur une partie de Medusa. Je voulais voir le reste, alors j'ai monté mon propre e-commerce le soir, de la fiche produit jusqu'au paiement.

Un monorepo, Next.js 16 pour le storefront et Medusa v2 pour le back, avec PostgreSQL et Stripe pour les paiements. Le tout tourne sur un VPS Hostinger, conteneurisé avec Docker.

C'est la partie hébergement qui m'a le plus appris. En mission, tu pousses sur une branche et la plateforme s'occupe du reste. Sur ton propre VPS, il n'y a personne derrière : tu écris tes Dockerfile, tu gères ta base, tu comprends pourquoi le conteneur redémarre en boucle à deux heures du matin. Reproduire seul ce qu'une équipe fait à plusieurs, c'est le meilleur moyen de voir tout ce qu'on ne faisait pas soi-même.

Le petit flex

Le nombre de lignes de code ne veut rien dire. Je le sais.

Mais après deux ans à construire cette architecture headless, je termine sur le podium des contributeurs du projet. Je regarde le rétroviseur avec un petit sourire.

Ce n'est pas ça qui m'a marqué.

Sept pays, sept façons de casser

Ce qui m'a marqué, c'est ce qui se passe quand tu te trompes.

À petite échelle : tu codes, tu casses, tu fixes. Personne ne voit rien.

Chez Decathlon, une erreur bête part dans sept pays, avec sept catalogues et sept jeux de règles métier. Tu ne casses pas ton bout de code. Tu casses la journée de gens que tu ne connais pas.

J'ai compris ça en regardant comment on gérait le support.

Au début, tu as le réflexe du dev héros : un pays remonte un bug, tu fonces, tu fixes en direct. Tu te sens utile.

C'est une erreur. Dès qu'un pays comprend que tu répares ses problèmes instantanément, tu deviens son support technique personnel. Et tu ne fais plus que ça.

Ce qui a débloqué la situation, c'est un système de ticketing strict géré par les PM. Frustrant au début. Sauf que l'objectif n'était plus de répondre vite, mais de voir l'ensemble : ce bug remonté par l'Espagne, est-ce qu'il touche aussi l'Italie ?

Livrer tous les jours

Une fois ce réflexe corrigé, restait la question qui angoisse tout le monde : comment on déploie sans tout faire sauter ?

On aurait pu y aller pays par pays, prudemment. On a fait l'inverse : tout le monde en même temps, tout le temps.

Nos releases s'appelaient 26-07-30. Année, mois, jour. Le nom seul dit l'intention, livrer le plus souvent possible. Le PM valide, on pousse sur les sept pays d'un coup.

Ça paraît risqué. C'est le contraire. Quand la mise en prod devient une routine banale, elle cesse de faire peur. Ce qui fait peur, c'est le déploiement qu'on repousse depuis trois semaines et qui embarque quarante changements.

L'i18n, ce n'est pas de la traduction

Déployer partout en même temps a une contrepartie : il faut que le produit ait du sens partout en même temps.

Traduire du texte, c'est facile. Formater des dates, une librairie s'en charge.

Les règles métier par pays, c'est autre chose.

L'Italie avait déjà la facture électronique obligatoire quand les autres n'en entendaient pas parler. Ce n'est pas une ligne de traduction, c'est un format, une transmission et des mentions légales à respecter, pour un seul pays sur sept.

La Belgique voulait mettre en avant sa partie clubstore, les autres non. Même code, même déploiement, mais une expérience qui devait différer. On est passés par un système de feature flags : chaque pays active ce qui a du sens pour lui, sans qu'on ait à maintenir sept versions de l'application.

Ça ne se factorise pas. Ça se documente, ça se teste (merci Vitest et GitHub Actions), et ça se paie à chaque nouvelle feature. Pour toujours.

C'est là que j'ai commencé à regarder le produit autrement. Ces règles ne sortent pas d'un fichier de config, elles sortent de discussions avec des gens qui connaissent leur marché.

La rétro qui m'a appris le plus

Ma meilleure claque n'a pas eu lieu dans VS Code.

J'ai pris l'initiative d'animer la rétro de l'équipe. Le Sprint 33. Christophe et Mehdi s'envolaient pour les US, alors je l'ai faite en version spéciale, entièrement en anglais. Sans pression, sans jugement.

Préparer cette cérémonie m'a obligé à enlever ma casquette de dev. Comment on calcule une vélocité réelle. Pourquoi un objectif de sprint compte plus qu'un compteur de tickets fermés. Ce que l'équipe vit et que je ne voyais pas depuis mon éditeur.

Une heure de préparation m'a appris plus sur le produit que trois mois de code.

Ce que j'ai ramené

Le plus étrange, c'est que tout ça m'a suivi jusque dans mes projets perso.

Avant, je fonctionnais en deux modes. Agile, Jira et process au boulot. Improvisation totale le week-end.

J'ai fusionné les deux. Pour Prospect Tracker, mon SaaS, je bosse avec la même rigueur que chez Decathlon.

Ce board, c'est le même que celui d'une équipe de dix. Je crée des sprints, je me fixe des objectifs, je laisse des commentaires sur mes propres tickets pour le moi du futur, celui qui aura tout oublié dans trois semaines.

Je fais aussi des rétros en solo. Oui, tout seul, avec moi-même. Si je rate un objectif, je cherche pourquoi. Si je l'explose, je me demande si je n'ai pas visé trop bas.

Et j'écris des ADR, des Architecture Decision Records. J'ai découvert ça avec l'équipe Design System de Decathlon. Écrire pourquoi j'ai choisi une stack m'évite de refaire le débat tous les six mois au gré des modes.

Deux ans chez Decathlon m'ont appris à coder des plateformes solides. Mais surtout que le code n'est jamais le plus dur. Comprendre le produit et l'organisation autour, c'est ce qui fait la différence entre un dev qui exécute et un dev qui a de l'impact.

Ça marche partout. Même quand ton seul utilisateur, c'est toi.