Redspher — Structurer une équipe tech de 4 à 30+ développeurs

Contexte

Quand je suis arrivé chez Redspher en février 2016, l’entreprise était en pleine bascule : un acteur historique du transport express européen qui devait se réinventer en plateforme SaaS pour tenir tête à une nouvelle génération de concurrents digitaux. Le projet de transformation existait sur le papier. L’équipe technique pour l’exécuter, en revanche, était à construire.

À mon arrivée, nous étions quatre développeurs. Le produit tournait sur un monolithe, et les modifications en production se faisaient en VI directement sur les serveurs. Pas de pipeline d’intégration, pas d’environnement de staging isolé, pas de revue de code systématique. C’était un environnement devant lequel plus d’un avait baissé les bras avant moi — pas par manque de compétence, mais parce que l’inertie installée rendait chaque amélioration coûteuse.

Problématique

Le problème n’était pas “faire du code plus propre”. C’était de construire une organisation tech capable d’absorber la croissance : croissance des utilisateurs, des fonctionnalités à livrer, et de l’équipe elle-même.

Trois chantiers à mener en parallèle, chacun urgent :

L’industrialisation technique. Sortir des déploiements en VI, introduire du versioning propre, de l’intégration continue, des tests automatisés. Sans ça, impossible de faire grandir l’équipe sans que chaque nouveau développeur casse ce que les autres venaient de livrer.

L’architecture. Le monolithe ne tiendrait pas. Il fallait préparer le terrain pour des composants plus petits, indépendants, que des équipes distinctes pourraient faire évoluer en parallèle.

L’équipe. Recruter, structurer, faire monter en compétences. Quatre développeurs qui se parlent informellement, c’est simple à coordonner. Trente développeurs répartis sur plusieurs chantiers, c’est un métier à part entière.

Approche

Je suis arrivé comme Technical Lead, et j’ai pris le rôle de CTO un an plus tard, début 2017. L’approche a été la même sur les trois ans : ne pas essayer de tout changer en même temps, séquencer avec discipline.

Année 1 — Installer les fondations techniques. Avant de parler microservices, il fallait pouvoir déployer proprement. Mise en place de l’intégration continue, conteneurisation Docker progressive, tests automatisés sur les parties critiques, revues de code systématiques. J’ai commencé par imposer ces pratiques sur mes propres contributions, puis je les ai étendues à l’équipe. La résistance était réelle — “on a toujours fait comme ça, ça marche” — et la réponse ne pouvait pas être autoritaire. Elle passait par montrer, concrètement, que la nouvelle manière était moins pénible une fois prise en main. Les tests qui évitent les régressions du vendredi soir. Le déploiement en un clic qui remplace la connexion SSH. Les environnements qui ne cassent plus parce que chacun bosse dans sa bulle.

Année 2 — Structurer l’architecture et l’équipe. Avec les fondations en place, on a commencé à découper. Sortie progressive du monolithe vers une architecture orientée services, avec un bus d’événements pour découpler les composants, des WebSockets pour le temps réel client. Chaque découpe suivait un domaine métier, pas une fonctionnalité isolée. En parallèle, recrutement actif et création des premières équipes produit. L’objectif n’était pas “faire des microservices” pour faire des microservices, mais de permettre à plusieurs équipes de travailler en parallèle sans se marcher sur les pieds.

Année 3 — Scaler l’organisation. Quatre équipes produit, chacune avec son Tech Lead, son Product Owner, son périmètre fonctionnel clair. Mise en place d’un Release Manager pour coordonner les livraisons. Mon rôle a évolué d’exécution et coaching rapproché vers pilotage et arbitrage transverse : roadmap, priorités, résolution des conflits entre équipes, recrutement des postes clés, culture tech au niveau du département.

Réalisation

À mon départ début 2019, la photo était radicalement différente de celle de mon arrivée :

• L’équipe était passée de 4 développeurs à plus de 30 personnes, incluant développeurs, Tech Leads, Product Owners, et un Release Manager. Quatre équipes produit autonomes, chacune propriétaire de son périmètre.
• L’architecture avait basculé d’un monolithe unique vers une collection de services découplés communiquant via un bus d’événements, avec du temps réel pour les usages client.
• L’industrialisation technique était en place : intégration continue, déploiement automatisé, Docker, tests, scaling vertical maîtrisé. Le “VI en prod” avait disparu depuis longtemps.
• La culture avait basculé : revues de code systématiques, processus de release documenté, rituels d’équipe qui scalent.

Côté leadership, mon rôle final n’était plus celui d’un développeur qui coache, mais d’un CTO qui structure, arbitre, pilote, recrute, et porte la vision technique auprès de la direction et des métiers.

Ce qu’en ont dit les gens

Ce que j’ai le plus appris sur cette mission, ce n’est pas en me regardant faire. C’est en écoutant ce que les gens de l’équipe ont dit après coup. Ces recommandations sont publiques sur mon profil LinkedIn et vérifiables.

“Approche pragmatique et détermination à améliorer de façon continue la qualité technique et process d’un environnement devant lequel plus d’un avait baissé les bras. Éclectique, efficace, il sait intégrer les bonnes pratiques jusqu’à qu’elles deviennent la prime nature de cet environnement.” — Constantin Greffe, Web Developer, novembre 2018

“Malgré un environnement technique pauvre, Renaud a su mettre et aider à la mise en place de nouvelles technologies. Il a démontré l’ensemble de ses compétences aussi bien en PHP que dans d’autres technologies innovantes.” — Mathieu Hecker, PHP Senior Developer, novembre 2018

“J’ai rejoint l’entreprise en grande partie grâce à Renaud. Durant plus de deux années, il a su motiver son équipe et la faire progresser malgré de nombreux profils différents. Il a toujours su s’adapter et n’a jamais cherché à se reposer sur ses acquis.” — Jérôme Schaeffer, Lead Développeur Web, novembre 2018

Ce que j’en retiens

Deux leçons que j’applique depuis systématiquement.

La transformation technique est d’abord une transformation humaine. Passer du VI en prod au déploiement automatisé, ça prend quelques semaines côté tuyauterie. Ça prend deux ans côté habitudes d’équipe. Ne pas sous-estimer ce deuxième temps, c’est la principale raison pour laquelle tant de projets de transformation plantent. Ce ne sont pas les outils qui résistent, ce sont les réflexes installés.

Scaler une équipe, ce n’est pas “embaucher plus” — c’est créer les conditions pour qu’une équipe de trente personnes puisse se coordonner sans que tout remonte à la même personne. Quand chaque décision remonte au CTO, on a recruté trente développeurs mais on a toujours l’efficacité de quatre. La vraie réussite, c’est d’en arriver à un point où on peut s’absenter une semaine sans que rien ne s’arrête.

C’est à Redspher que j’ai compris que mon métier n’est pas de coder le mieux de l’équipe. C’est de construire une équipe qui produit ensemble plus que ce que j’aurais produit seul. Depuis, c’est ce que je cherche à reproduire dans chaque mission de pilotage qu’on me confie.