Ocus
Comment Ocus a livré sa V0 en 2 mois et stabilisé son équipe après un rebuild complet de sa stack
Contexte
Ocus est une startup parisienne qui s'appuie sur une plateforme technologique pour automatiser la création de contenus visuels personnalisés pour des marques internationales, en s'appuyant sur une communauté de 20 000 photographes et créateurs.
Quand Hones est entré dans le dossier, la situation avait déjà une histoire. Un premier CTO externe avait réalisé un audit et proposé un rebuild complet, ce qui n'était pas un mauvais diagnostic sur le fond. Mais sa proposition était dimensionnée pour une organisation de 50 personnes avec deux ans devant elle. Ocus avait une équipe de dix personnes et six mois de runway. L'écart entre l'ambition de la solution et les contraintes réelles de la société avait généré des tensions dans l'équipe technique, qui s'était retrouvée dans une position inconfortable. Ce premier CTO n'est pas resté. Le CTO interne avait également quitté la société dans l'intervalle.
C'est dans ce contexte que le dirigeant d'Ocus a fait appel à Hones. Ce qui était au départ un simple audit est devenu une mission de CTO de transition sur plusieurs mois.
Défis
Défi #1 — Redonner à l'équipe interne la main sur son propre projet
La tentative précédente avait fait entrer une agence étrangère dans le projet, avec une architecture ambitieuse mais perçue en interne comme disproportionnée. L'équipe technique s'était retrouvée dans une position de spectateur sur un projet qui était le sien. Reconstruire la dynamique passait d'abord par là : sortir l'agence, réinternaliser le projet, et travailler en proximité directe avec les développeurs pour qu'ils redeviennent acteurs des décisions.
Ce n'était pas qu'un problème technique. Nous avons consacré autant de temps à recréer de la lisibilité et de la confiance qu'à définir la nouvelle architecture.
Défi #2 — Définir un périmètre de rebuild réaliste adapté aux contraintes réelles
Tout reconstruire de zéro était la bonne décision. La stack existante était bloquée, les fondamentaux techniques ne permettaient pas d'évoluer et ces blocages freinaient concrètement la réalisation produit. Mais "reconstruire de zéro" avec six mois de runway impose une discipline de priorisation très différente d'un projet avec du temps devant soi.
La reconstruction a impliqué de repenser le métier différemment, pas uniquement de reproduire l'existant dans une autre technologie. Le périmètre fonctionnel de la V0 a été défini avec l'équipe produit, avec des arbitrages stricts sur ce qu'on incluait et ce qu'on différait. En parallèle, une personne dédiée gérait les urgences sur la stack existante pour assurer la continuité de service pendant la période de transition.
Défi #3 — Maintenir un cap stable dans un contexte de forte pression
Dans une startup avec peu de runway et une équipe en cours de reconstruction, chaque décision technique est scrutée de près par la direction. C'est légitime : les marges d'erreur sont réduites et les enjeux immédiats. Mais cette pression, mal canalisée, peut déstabiliser les priorités et ralentir le delivery plus qu'elle ne le sécurise.
L'équipe Hones a structuré une interface claire entre la direction et l'équipe technique. Les arbitrages de priorisation étaient documentés et expliqués, les décisions défendues avec des arguments compréhensibles pour un non-technicien. Ce travail de traduction et de cadrage a permis à l'équipe de tenir un rythme de delivery stable pendant toute la mission.
Défi #4 — Continuer à avancer malgré un turnover en cours de mission
Le changement de cap a entraîné plusieurs départs dans l'équipe technique, ce qui est une dynamique fréquente dans ce type de situation. Nous avons recruté trois profils en remplacement, en parallèle du rebuild, sans interrompre le delivery.
Résultats
- La V0 a été livrée en 2 mois à partir du lancement du rebuild, avec un périmètre fonctionnel défini et tenu, malgré les recrutements en cours de mission.
- L'équipe technique s'est stabilisée. Les développeurs ont retrouvé une direction claire et un rythme de delivery visible : du code livré à chaque sprint, des fonctionnalités démontrables régulièrement.
- La stack a été reconstruite et la bascule opérée de l'ancien vers le nouveau système au terme des 9 mois de mission.
- Les processus ont été structurés : sprints courts, priorisation documentée, communication clarifiée entre équipe produit et équipe technique.
- Hones a participé activement au processus de recrutement du CTO permanent, en assurant l'évaluation des profils pour que la passation se fasse sur des bases solides.
Ce qu'on a appris
Quand une équipe technique traverse une période d'instabilité, la priorité n'est pas toujours technique. Avant de changer l'architecture, il faut souvent reconstruire la lisibilité : qui décide quoi, pourquoi, sur la base de quels critères. Une équipe qui comprend les arbitrages accepte plus facilement les contraintes qui vont avec.
Le dimensionnement des solutions a aussi de l'importance. Une proposition techniquement correcte mais inadaptée au contexte réel de la société, sa taille, son runway, ses délais, ne produit pas de la valeur. Elle produit de la friction. La qualité d'un CTO de transition se mesure en partie à sa capacité à faire tenir une ambition dans des contraintes qui ne sont pas idéales.
Le recrutement du CTO permanent mérite d'être traité comme un enjeu à part entière de la mission. Une passation réussie suppose que le profil recruté soit aligné avec la réalité de la société, ses contraintes et sa culture, ce qui demande une connaissance fine du contexte interne que peu de personnes extérieures à la mission possèdent.
