2025-01-15 - Retour d’expérience CTO, de la restructuration au rachat

Après 6 ans comme Lead Dev, j’avais envie de tester autre chose, et notamment prendre plus de responsabilités managériales et stratégiques. En février 2023, j’ai donc pris un poste de CTO dans une plateforme de crowdfunding d’environ 20 personnes, en pleine restructuration. Deux ans plus tard, en juin 2025, je quitte ce poste après un rachat par notre concurrent principal. Voici donc un retour sur une expérience intense.

Le départ : février 2023

L’entreprise sort d’une période difficile liée à une restructuration, les équipes sont nouvelles, il faut trouver un nouvel élan pour atteindre des objectifs de rentabilité sous 3 ans. Je découvre une boîte avec un vrai esprit de corps, des gens très impliqués, et l’envie collective d’avancer. J’ai 4 mois de tuilage pour prendre le poste.

Mon équipe est en cours de rééquilibrage. Il y a 5 personnes côté tech, en coordination proche avec les 3 personnes au produit. Pas énorme, mais suffisant pour les enjeux prioritaires qu’on a devant nous.

Côté technique, c’est un chantier multiple :

• Code et infrastructure : dette technique importante, mise à jour des dépendances
• Conformité à poursuivre : LCB-FT, RGPD, …
• Performance : des problèmes critiques à résoudre lors de pics de trafic
• Coûts : objectif de rentabilité nécessitant de rationaliser les services

Mon plan d’action s’articule autour de 4 axes :

1. Reconstruire et stabiliser l’équipe technique
2. Moderniser l’infrastructure
3. Mettre à jour les applicatifs et résoudre les problèmes de performance
4. Planifier la roadmap avec l’équipe Product

Si établir un inventaire exhaustif de l’existant et des enjeux dès mon arrivée fut une bonne idée, la prioritisation n’a pas été simple à mettre en place à cause de la reprise en main des sujets techniques et produits, du besoin de stabilisation initiale dans l’équipe et de la gestion de la performance opérationnelle.

Baptême du feu : Plus grosse campagne européenne et un crash

En parlant de cette dernière, les lancements de campagne sont toujours des moments particuliers sur une plateforme de crowdfunding avec de gros pics de trafic et des yeux grands ouverts sur les outils de monitoring (AWS Cloudwatch, DataDog).

Dès septembre, alors que je me familiarisais encore avec les manettes, il se lança ce qui allait devenir la plus grosse campagne de crowdfunding européenne de l’époque, avec 2,2 millions d’euros levés au final.

Bim! L’application plante.

On déclenche une situation de crise et on procède méthodiquement :

1. Isolation (T+0) : On garrotte le trafic sur le projet concerné pour protéger les autres campagnes en cours. Les autres projets peuvent continuer à utiliser la plateforme, mais le gros projet est bloqué. Le téléphone sonne continuellement, gros travail pour les équipes business et marketing…

2. Optimisation cache (T+45min) : Le souci est bien isolé sur la base de données. On améliore sensiblement la mise en cache pour réduire la charge sur la base. Cela allège d’environ 40%, mais ce n’est pas suffisant face au trafic multiplié par 30 par rapport à la veille.

3. Scaling infrastructure (T+2h) : Il n’y a plus le choix, on décide de doubler les capacités de notre RDS AWS en direct. Le trafic a un peu réduit également depuis le lancement. Et là, ça respire enfin. Merci à toute l’équipe (Et big up à SM). Les contributions arrivent en nombre sur le projet! Youpi, et j’ai besoin d’une bonne douche :)

On s’en sort donc avec 3 heures de coupure totale sur le projet principal. C’est dur à encaisser, surtout quand des milliers d’euros sont en jeu et que des centaines de personnes attendent. Avec un peu plus d’expérience sur l’application, j’aurais sans doute foncé directement sur l’augmentation des capacités RDS, toujours plus facile après coup.

La fin de campagne, où il y a généralement également beaucoup de trafic, s’est finalement bien passée. Il y a eu quelques ralentissements, mais rien de critique, avec un trafic 50 fois supérieur à la normale par moment … L’expérience du crash initial nous a permis de mieux réagir. Nous avons dû encore doubler la base de données RDS.

Leçon retenue : En cas de crise, il faut toujours avoir un plan de base, procéder par étapes et communiquer proprement dans des canaux dédiés. Ajouter des ronds dans l’infra avec un scaling vertical, c’est le dernier recours en situation normale, mais en situation de crise, cela peut s’avérer être une tactique efficace du point de vue opérationnel.

Migration d’infrastructure : containeurisation et gains

Face au décommissionnement d’une version du service Opswork par AWS, nous avons décidé de migrer notre infrastructure AWS d’OpsWorks/EC2 vers ECR/ECS. Concrètement, cela a généré divers chantiers dont :

• la containeurisation de l’application via Docker
• l’amélioration du Pipeline CI/CD sur CircleCI
• le pilotage plus fin des ressources grâce à l’IaC Terraform mis en place par un partenaire
• l’amélioration de la scalabilité avec des déploiements plus rapides grâce aux configurations de charge sur ECS

Les gains concrets ont été mesurés sur :

• le temps de déploiement : de 36min à 15min, grâce aussi au refactoring des tests
• le scaling : de 8 min en manuel avec EC2 à moins de 2 minutes en auto-scaling via RDS
• les coûts : réduction d’environ 20% grâce à une meilleure utilisation des ressources (économie utilisée pour la mise en place d’un serveur de staging dédié et le financement d’une partie de l’infogérance avec notre partenaire)
• la stratégie : portabilité plus grande grâce à la containeurisation et à l’IaC

Le tournant : l’annonce du rachat

Juste après avoir finalisé cette migration, à un moment où l’on commence enfin à respirer un peu, j’apprends que notre actionnaire se restructure et décide de se séparer de filiales, dont la nôtre… Quel timing :)

Notre concurrent principal, une plateforme de 45 personnes, veut nous racheter avec une logique stratégique et cohérente : Consolider le marché français du crowdfunding.

Dans les faits, j’ai dû rester 3 mois dans le secret avant de l’annoncer à mon équipe pour des raisons légales et stratégiques assez évidentes. L’exercice de la due diligence fut nouveau pour moi et consista principalement à trouver l’équilibre entre transparence nécessaire et protection des données sensibles (personnelles, confidentielles).

La transition : décembre 2024 - juin 2025

Une fois l’absorption effectuée, les priorités changent complètement pour moi:

• Gérer la fusion de mon équipe dans la nouvelle équipe, sous l’égide du directeur technique / CTO du repreneur
• Migrer rapidement l’application sur l’infrastructure du repreneur (Seconde migration en 1 an… Merci la containeurisation!)
• Organiser le transfert de connaissances
• Planifier le décommissionnement de nos applicatifs
• Rationaliser les coûts cloud avant la fermeture

Gérer une équipe dans ce contexte n’est pas simple : certaines personnes partent, d’autres restent dans l’incertitude, il faut maintenir la motivation tout en accompagnant au mieux les différents choix.

En juin 2025, la transmission a été accomplie, le repreneur a déjà son directeur technique en place, et plutôt des projets de rationalisation que d’expansion. Mon rôle n’a plus de sens ce qui est logique. Je pars en bons termes et c’est important.

Ce que j’en retiens

Un poste de CTO dans une entreprise en restructuration, c’est avant tout de la gestion de la charge de travail et de la priorisation constante.

Humainement, cela fut également une expérience incroyable, avec des équipes qui ont su rester unies malgré les crises et les tensions, et faire preuve d’une intelligence collective inspirante, trop souvent peu mise en avant. J’ai pu aussi approfondir mon expérience sur le feedback, la délégation et le lâcher-prise.

Cette expérience m’a aussi permis d’approfondir énormément de sujets (management, technique, produit) et d’en explorer de nouveaux (conformité, stratégie). En 2 ans, j’ai plus appris qu’en 5 ans sur un poste stable. Je ne regrette rien, mais je sais maintenant ce que “challenge” veut vraiment dire dans une offre d’emploi 😄