5 questions à Antoine Sauvage, CTO d'Ovrsea

J'accompagne Ovrsea depuis plus d'un an en coaching technique, sur un rythme de 8 à 10 jours par mois. Plus d'une fois, la culture de cette entreprise m'a positivement interpelé : une culture de l'excellence technique, empreinte d'humilité. D'où l'envie de vous faire connaître leur démarche. Et pour cela, quoi de mieux que de laisser la parole à Antoine, CTO d'Ovrsea ?

Comment est née l’idée de vous faire accompagner sur la dimension technique ?

Nous avons de longue date une culture de la formation, qui fait partie intégrante de notre proposition de valeur en tant qu'employeurs. Nous embauchons entre autres des développeurs jeunes quand nous décelons un potentiel, et nous contribuons à les former. De fait, notre turnover est très faible : un seul départ depuis la création d'Ovrsea, il y a 5 ans, sur une équipe tech de 15 personnes. Mais au-delà de la volonté de progresser, je ressentais le besoin de creuser les angles morts. Je veux dire par là vérifier qu'on se rapproche d'un certain état de l'art, et surtout le faire continuellement. Aller toujours plus loin. Du coup, je recherchais un regard extérieur expérimenté, qui puisse nous procurer du feedback tout en nous aidant à grandir.

Quelles réticences avais-tu avant de démarrer la prestation ?

J'en avais plein ! Beaucoup de questions en tout cas. La principale concernait le ROI (*). Déjà, comment le mesurer, et à quel moment ça se voit concrètement sur la qualité du code, vu qu'il y a de l'inertie : il faut le temps de la progression individuelle, puis le temps que ces progrès se traduisent dans la codebase. Et puis il y a un coût d'opportunité à faire appel à un coach externe : pour la même enveloppe budgétaire, je pourrais embaucher un développeur sénior à temps plein. Est-ce que ça ne serait pas mieux ? L'autre sujet, c'est que je cherchais quelqu'un capable de nous accompagner vraiment sur notre code de prod. Je ne voulais pas que ça reste théorique, faire des exercices de code c'est bien, mais il faut que ça se traduise à la fin dans le code de prod.

Ces réticences sont-elles toujours d’actualité ?

Non, clairement le temps passé ensemble a permis de répondre à ces questions. En fait, je me suis senti rassuré 3 mois après le démarrage du coaching. Le ROI, je sais que je ne pourrai pas mettre un chiffre dessus, mais je constate que nous maintenons un rythme de delivery soutenu alors même que l'équipe croît (NDLR : +50% en un an) et que nous nous attaquons à des features de plus en plus complexes. Ça n'était pas gagné d'avance et c'est le signe que notre code a une bonne capacité à évoluer. De manière qualitative toujours, je vois bien aussi l'engagement des équipes, leur enthousiasme et le plaisir qu'elles ont à progresser. Nous avons une vraie culture du learning, de la remise en question, de la transparence, et le coaching technique y contribue vraiment.

Cette capacité du code à évoluer, à quoi tient-elle ?

Concrètement, l'apport le plus important du coaching sur ces derniers mois, c'est l'architecture hexagonale. Elle nous a permis de franchir un cap dans la structuration du code en mettant au clair le sens des dépendances. C'est radical, c'est limpide. Du coup, nous avons pris l'habitude d'écrire le domaine en premier, en Test-driven development tant qu'à faire. Aujourd'hui, c'est un pattern que nous maîtrisons bien et qui a diffusé au sein de toute l'équipe tech. Les plus seniors posent le cadre pour les plus juniors. C'est là qu'on voit que le coaching a des effets réels sur le code de prod, ça n'est pas que de la théorie.

Êtes-vous "arrivés" ?

Non ! Considérer que nous sommes arrivés serait le signe qu'on a loupé quelque chose. J’espère que le coaching ne prendra jamais fin, car on peut toujours faire mieux. Il y a toujours mieux pour les plus seniors, et la vocation d’Ovrsea est de former tout le monde. Avoir un regard extérieur est très précieux. En fait, plus on creuse, plus on voit d'opportunités d'amélioration. C'est un peu vertigineux parfois, mais ça n'enlève rien à la qualité du code aujourd'hui. Nous voulons notamment progresser sur le front-end et y apporter du systématisme. L'architecture hexagonale devrait aider, là aussi. Mais pour moi, ce qui est super positif, c'est que nous arrivons à faire évoluer la codebase en faisant cœxister l'ancien et le nouveau. On arrive à faire toutes les migrations en continu, pour ainsi dire. Il y a toujours une librairie dont on veut se séparer, un pattern que l'on veut systématiser. Tout ça se fait au fil de l'eau, sans big bang.

Vous comprenez pourquoi j'adore travailler avec eux ?

(*) Retour sur investissement