Le contexte

Quand j'ai rencontré Winter, ils étaient trois, dans un petit bureau parisien. Trois personnes qui venaient de gagner quelque chose de très gros : un appel à projet de l'État sur la transition énergétique, avec un objectif vertigineux — accompagner 600 000 foyers français dans leur sobriété énergétique.

C'est le genre de victoire qui change une trajectoire. C'est aussi le genre de victoire qui peut tuer une jeune entreprise si elle n'est pas armée pour livrer. Parce que derrière l'ambition, il y avait un trou béant.

Winter avait l'essentiel : une expertise métier réelle sur l'énergie, une vision claire, un mandat public. Mais côté exécution, presque rien. Pas d'équipe technique. Pas de culture produit. Aucun site web. Et un développement entièrement externalisé, c'est-à-dire une dépendance totale à des prestataires extérieurs pour une mission qui allait devenir le cœur du réacteur.

Cette dépendance, c'est le point le plus dangereux. Quand le produit est la mission — quand l'État vous demande d'embarquer 600 000 foyers, ce qui passe forcément par des applications et des parcours numériques — déléguer entièrement sa construction revient à confier son destin à des gens dont ce n'est pas le combat. Chaque évolution coûte cher, prend du temps, et personne en interne ne possède vraiment ni le code, ni la logique produit. À ce stade, ce n'était pas un détail technique : c'était un risque existentiel.

3 → ~20personnes pendant l'accompagnement (dont 8 en tech & produit)

Mon rôle a commencé là : pas pour écrire une ligne de code dans mon coin, mais pour construire la machine capable de tenir cette promesse à 600 000 foyers.

Le défi

Le vrai défi de Winter n'était pas technique au sens étroit. C'était un défi de mise à l'échelle complète, à partir de presque rien, et sous contrainte de temps.

Il fallait tout faire, et le faire dans le bon ordre :

Constituer une équipe interne capable de porter le produit, au lieu de sous-traiter indéfiniment une compétence qui devait devenir stratégique.
Exister en ligne : pas de site web, donc pas de point d'entrée pour recruter les foyers que le mandat imposait d'accompagner.
Livrer des applications à la hauteur des usages réels — un foyer ne gère pas sa consommation d'énergie sur un tableur.
Recruter des utilisateurs à grande échelle, avec des parcours d'inscription qui transforment au lieu de faire fuir.
Tenir tout ça en production, de manière fiable, sans monopoliser l'équipe sur des sujets d'infrastructure.

Le piège classique, dans cette situation, c'est la sur-ingénierie. Vouloir construire une cathédrale technique parce que le mandat est ambitieux. J'ai fait l'inverse : un pivot vers une architecture moderne API-First, mais sans complexité gratuite — juste ce qu'il fallait pour aller vite aujourd'hui et garder les options ouvertes demain.

Mon approche

J'ai été, selon les mots de Laurent Fournié, « bien plus qu'un CTO ». Concrètement, j'ai mis en place toute la structure tech et produit de Winter, sur plusieurs fronts en parallèle.

Construire l'équipe (0 → 8)

La première priorité n'était pas de coder, c'était de recruter — et de recruter dans le bon ordre, à la bonne séniorité. J'ai composé une équipe tech et produit de 8 personnes, en partant de zéro : sourcing, entretiens, sélection de profils de haut niveau.

Le séquencement compte autant que les profils eux-mêmes. Recruter un Head of Product avant qu'il y ait une équipe à diriger, ou un profil ultra-senior avant qu'il y ait une stack à structurer, c'est brûler du budget pour un poste sous-occupé qui finira par partir. J'ai ordonné les recrutements selon les besoins réels du moment, en internalisant progressivement ce qui était jusque-là sous-traité.

Puis je les ai managés et fait monter en compétences : mise en place d'une culture produit avec des rituels agiles adaptés au stade de Winter — et que j'ai fait évoluer au fur et à mesure que l'équipe grandissait, plutôt que d'imposer un process rigide importé d'ailleurs. Surtout, j'ai investi dans une formation à l'IA agentique et à la Clean Architecture. La Clean Architecture, pour que le code reste lisible et modifiable à mesure que le produit se complexifie ; l'IA agentique, pour insuffler ces outils dans les process de l'équipe là où c'était le plus pertinent, et démultiplier ce qu'une petite équipe pouvait livrer. L'objectif n'était jamais de cocher des cases techniques, mais de rendre l'équipe autonome et durable, capable de tenir le produit longtemps après mon départ.

Construire le produit

iOS + Androidapplications natives livrées

En parallèle, j'ai piloté la construction du produit lui-même :

Le site web from scratch — l'inexistant est devenu le point d'entrée de toute l'acquisition.
Des applications natives iOS et Android, parce que l'accompagnement énergétique d'un foyer mérite une expérience mobile aboutie, pas un habillage web.
Un moteur de formulaires piloté par la configuration : guider un foyer à travers sa situation énergétique demande des parcours longs et conditionnels. On les crée et on les fait évoluer sans toucher une ligne de frontend ni de logique métier — du code qui génère la configuration d'un algorithme, et une équipe produit qui compose les parcours.
L'installation d'une culture data dans l'équipe : la mise en place de Zoho a changé assez drastiquement le rapport à la donnée d'une grande partie de l'équipe, du marketing au produit. On cesse de décider à l'instinct, on mesure. L'A/B testing à plusieurs niveaux n'en est qu'une facette.

Cette culture data est centrale quand on a un objectif de 600 000 foyers : à cette échelle, un point de pourcentage de conversion gagné sur l'onboarding représente des milliers de foyers en plus. Mettre la donnée entre les mains de l'équipe — outillée pour la regarder elle-même plutôt que de l'attendre dans un rapport mensuel — c'est ce qui transforme une intuition produit en décision étayée : l'ordre des étapes d'un formulaire, le wording d'une question sensible, l'endroit précis où les foyers décrochent. Le réflexe compte plus que l'outil : passer d'une équipe qui suppose à une équipe qui vérifie.

Ouvrir les lignes de revenus

L'accompagnement ne s'arrêtait pas à la sensibilisation. J'ai contribué à lancer les activités de vente qui donnent à Winter un modèle économique concret : thermostats connectés, panneaux solaires, pompes à chaleur. Le produit devait non seulement informer les foyers, mais aussi leur permettre de passer à l'action.

Tenir la maison

Enfin, j'ai pris en charge la production et la CI en totale autonomie. C'est un choix délibéré, pas un repli technique : dans une équipe de huit, chaque personne mobilisée sur l'infrastructure est une personne en moins sur le produit. En absorbant moi-même le déploiement, l'intégration continue et la fiabilité de la prod, je faisais en sorte que l'équipe reste concentrée sur ce qui crée de la valeur pour les foyers — les parcours, les apps, l'acquisition — plutôt que sur la plomberie. C'est aussi ce qui m'a permis de garder l'architecture juste assez complexe : quand on opère soi-même ce qu'on construit, on est naturellement incité à ne pas empiler des couches qu'il faudra maintenir.

Rémi a été bien plus qu'un CTO. Il a entièrement mis en place notre structure tech et produit. Pour un fondateur, c'est exactement le profil dont on rêve pour scaler sereinement.

— Laurent Fournié, CEO de Winter

Les résultats

L'équipe de trois personnes au développement externalisé est devenue une organisation produit interne et autonome, et la promesse faite à l'État a trouvé sa machine pour la tenir.

80 000+utilisateurs recrutés

Une équipe tech & produit de 8 personnes, recrutée, formée et opérationnelle, là où il n'y avait personne.
Plus de 80 000 utilisateurs recrutés sur les applications et le site — une base réelle, embarquée dans des parcours d'onboarding pensés pour transformer.
Des applications natives iOS et Android en production, livrées et maintenues par l'équipe interne.
Une architecture moderne, API-First, suffisamment simple pour rester rapide, suffisamment solide pour encaisser la croissance vers les 600 000 foyers visés par le mandat.
Des lignes de revenus lancées (thermostats, solaire, pompes à chaleur), qui transforment un mandat public en activité économique viable.

Et l'entreprise elle-même a grandi : du petit bureau parisien à trois, Winter est passé à une vingtaine de personnes au sein d'un accélérateur de startups.

Et après

Ce que dit cette mission de ma façon de travailler tient en une phrase : je ne livre pas un livrable, je laisse une équipe capable de continuer sans moi.

Tout, dans cet accompagnement, a été orienté vers l'autonomie de Winter. Recruter au bon niveau plutôt qu'empiler les profils. Former à l'IA agentique et à la Clean Architecture plutôt que de garder le savoir pour moi. Choisir une architecture juste assez complexe plutôt qu'une cathédrale impressionnante mais ingérable. Absorber la production pour que l'équipe reste sur le produit. Savoir, aussi, quand accepter un compromis court terme tout en gardant les options ouvertes.

C'est ce mélange — vision tech long terme et exécution au quotidien — qui permet à un fondateur de scaler sereinement. C'est exactement ce que je viens apporter quand une entreprise a la traction et l'ambition, mais pas encore la machine pour les soutenir.

Pour aller plus loin sur la méthode : Création d'équipe Tech & Produit et Scaling Tech & Produit.

De 3 personnes à une équipe tech & produit qui a embarqué 80 000 foyers