On accueille le nouveau CTO 🎉

Un nouveau capitaine technique débarque à la barre de WeLoveDevs ! Après le rachat par Insitoo, Aurélien prend les rênes de WeLoveDevs avec une mission claire : fournir un endroit bien pensé où chaque dev trouvera son prochain job. Entre expertise pointue et passion contagieuse, il nous dévoile sa vision pour faire de WeLoveDevs la plateforme incontournable des devs et recruteurs. Rencontre avec le CTO qui va tout chambouler (dans le bon sens, promis).

🦸 Aurélien, ton parcours va du développement pur à des rôles de CTO et d’entrepreneur. Quel est le fil rouge qui t’a guidé, et quelle est la leçon la plus marquante que tu en tires pour un CTO en 2025 ?

J’ai toujours voulu créer, depuis aussi loin que je m’en souvienne. Je pense que c’est cette motivation qui m’a guidée dans mes choix. En tant que développeur, j’ai pu m’éclater (et je m’éclate encore !), en alternant entre créer de toutes pièces la fonctionnalité qui répond parfaitement à mon besoin, et trouver les outils parfaits à combiner pour aller plus vite.
Si je devais choisir la leçon qui m’a le plus marqué, c’est l’échec. J’en ai rencontré plusieurs, à tous les niveaux : humain, produit, équipe. Et même si ce n’est vraiment pas facile à avaler sur le moment, ça m’a ensuite forcé à davantage étudier mes choix, et à relativiser (surtout). Donc ma leçon serait : “plantez-vous, ça vous aidera !”.

⚛️ Tu as travaillé sur des stacks variées et des produits à forte croissance (Insitoo). Quelle est ta philosophie pour construire une tech scalable, fiable et centrée utilisateur ? Un exemple concret où tu as appliqué cette philosophie ?

Je n’ai qu’une philosophie (merci Amel), c’est de commencer simple mais de viser loin. On ne sait jamais si ce qu’on est en train de construire sera le futur Netflix ou si ça finira au fond d’un tiroir. Je fais donc des choix très terre-à-terre concernant les technos et les frameworks :

• Soit je (ou le ou les développeurs) les maîtrise déjà, auquel cas on peut aller vite
• Soit leur courbe d’apprentissage permet rapidement d’obtenir ce que l’on cherche

Pour le user-centric (‘scuse my english), c’est avec un mix d’approche UX (on définit l’objectif produit, puis les scénarios, et on confronte le tout en permanence aux utilisateurs) et d’itérations rapides (“lean startup” + “fail-fast”). Chacun sa méthodo mais j’ai remarqué qu’en testant rapidement et en impliquant les utilisateurs les projets étaient plutôt efficaces.

Par contre pour l’architecture, pour assurer des projets scalables et fiables, mon expérience d’architecte cloud me dirige souvent dans la même direction :

• Une techno frontend only (je n’aime pas mixer front et back dans le même code)
• Un service tiers d’authentification (ce n’est pas mon métier, d’autres font ça beaucoup mieux que moi)
• Un back en micro-services (oui, ça existe encore 😅)
• Une base en SQL, NoSQL ou KV en fonction des besoins
• Et une colonne vertebrale en event-driven

Le meilleur exemple concret est OuiDesk. : on est sur des technos simples mais malléables, qui nous ont permis de pivoter plusieurs fois avec un minimum d’efforts.

🚨 Tous les CTO font face à des crises (bugs critiques, migrations ratées, etc.). Raconte-nous une situation où tu as dû gérer l’urgence, et comment tu t’en es sorti ?

On a eu plusieurs crises côté IT chez Insitoo. Le principe de base d’une crise, c’est qu’on ne la voit pas arriver. L’une des dernières dont je me souvienne est l’infra cloud de OuiDesk. qui est “tombée” sans raison apparente :

C’est habituel que certaines sondes remontent de “faux négatifs” donc voir arriver une alerte ne m’a pas surpris plus que ça, mais la succession d’alertes m’a vite fait changer d’avis.

Ce qui m’a sauvé ce jour-là, c’est la semaine précédente passée à buter sur des problèmes de dev, qui m’a mis dans un état d’esprit à mi-chemin entre “tiens ça faisait longtemps” et “est-ce que ça m’étonne ?”. Bref, j’ai pris le problème avec une sérénité qui m’étonne encore aujourd’hui, à remonter les historiques d’alertes, les logs applicatifs, d’infra, APM, etc… Pour finir par trouver les coupables : des sondes croisées et en chaîne (pour résumer, le service A se considère KO s’il n’arrive pas à contacter le service B, et le service B se considère KO s’il n’arrive pas à contacter le service A).

Donc comment je m’en suis sorti : en évitant de stresser (même si une infra de prod KO, ça n’est pas rien).

Et surtout : quand il vous arrive une crise, l’important c’est ce que vous en tirez : n’oubliez pas le post-mortem et les actions qui en découlent, c’est comme ça que vous éviterez qu’elle se reproduise.

⚙️ Quelle technologie ou méthodologie (IA, serverless, DevOps, etc.) te semble sous-estimée aujourd’hui, mais cruciale pour les 2 prochaines années ? Pourquoi ?

Très bonne question ! Pour moi, le Green-IT est vraiment sous-estimé. Alors oui, j’entends déjà certains dire “ce n’est ni une techno ni une méthodo” … et ce n’est pas forcément faux. Tout le monde fait (ou veut faire) du serverless, de l’IA à tout-va, du cloud … bref, des pratiques qui nous cachent complètement la quantité de ressources nécessaires à nos traitements. Pour moi, il est primordial de reprendre conscience et de s’outiller pour maîtriser l’impact de nos projets. Je pense que tout le monde (sauf quelques irréductibles climato-sceptiques d’outre-atlantique) sait maintenant que le changement climatique est inévitable (pour ne parler que ce ce point-là), alors il est crucial d’avoir ce point en tête quand on fait des choix techniques.

🤔 Comment évalues-tu un candidat tech en 2025 ? Un piège à éviter absolument pour les recruteurs, selon toi ?

De mon côté, pour évaluer un candidat tech, je combine mes impressions sur 3 niveaux, en fonction du besoin :

• L’étude du profil. Alors c’est simple dit comme ça, mais ce que je vérifie surtout c’est la cohérence de son parcours, la progressivité de ses responsabilités et de ses périmètres techniques (un dev junior qui est responsable d’un projet en première expérience, ou bien un devops junior qui fait aussi bien du on-prem que du cloud, j’aurais tendance à botter en touche). A mon avis, quand on veut trop en faire trop vite, on n’acquiert pas les bases solides et les bons réflexes pour travailler sereinement.
• En entretien, je vais tenter de cerner la posture du candidat dans le contexte professionnel. Pour caricaturer, je rencontre vraiment 2 postures opposées. Je ne dirais pas qu’une est la meilleure, mais je garde pour moi ma préférence 😉  :
  • Les personnes qui se positionnent en apprenants. Ils attendent de leur poste / mission de les faire monter en compétences, et auront tendance à se sous-estimer.
  • Les personnes qui se positionnent en sachants. Ils attendent de leur poste / mission de les mettre en valeur et de leur donner des responsabilités. Ils auront tendance à se surestimer.
• Toujours en entretien, enfin, je vais chercher à savoir comment le candidat peut s’intégrer à l’équipe / au projet : habitudes de méthodologie projet (Scrum, Safe, Cycle en V, Kanban, …), place dans l’équipe, …

Le piège à éviter pour les recruteurs, selon moi, c’est de choisir le profil le plus capé, peu importe le besoin. Alors oui, avoir un dev fullstack à culture DevOps qui fait du SEO et de l’UX ça peut paraître sexy sur le papier, mais :

• Comment va-t’il/elle s’intégrer (humainement / techniquement) à l’équipe actuelle ?
• Du SEO pour un projet interne ? vraiment ?
• Si vous choisissez un profil confirmé, il aura déjà ses convictions sur les technos / pratiques / méthodos. Préparez-vous à vous faire challenger vos choix, sans forcément prendre en compte votre contexte métier.
• Si vous choisissez un profil à “plusieurs casquettes” et qu’il n’a pas la liberté d’action nécessaire (e.g. un profil DevOps mais il sera dans une équipe de build, sans lien avec la prod), il risque de ne pas faire de vieux os.

⚖️ Un CTO doit souvent arbitrer entre perfection technique et contraintes business. Comment trouves-tu cet équilibre ? Un cas où tu as dû faire un compromis difficile ?

Pour moi l’équilibre est même à trouver entre :

• La robustesse (la solution la plus solide en terme de résilience)
• La performance (la solution la plus efficace)
• La hype (la solution à la mode)
• Les contraintes métier
• Les besoins métier (qui ne sont pas forcément compatibles d’ailleurs)

Comment je trouve cet équilibre ? Je vais botter en touche en disant “c’est le budget qui décide” ! Mais plus précisément, le seul point sur lequel on ne peut pas transiger, ce sont les contraintes métier, donc on part de là. Ensuite c’est un joli travail d’équilibriste pour trouver le bon compromis entre tous ces points. Le fonctionnement que j’adopte en général est celui du benchmark : je mets sur la table les différents choix, j’établis des critères de référence sur lesquels j’analyse chaque solution … et je laisse le grand patron choisir ! (bien penser aux images, e.g. des graphiques radars, parce qu’un grand chef ça n’a pas beaucoup de temps)

J’ai un cas en tête qui m’a bien fait cogiter il y a quelques années : le client voulait mettre en place un BPM, mais sans renoncer à ses choix architecturaux en place (cloud, EDA, scalabilité, …). Et bien c’est ce genre de cas qui m’a le plus passionné ces dernières années : étudier des solutions inconnues (oui, parce que forcément je n’y connaissais rien en BPM), souvent legacy / archaïques, et se projeter dans un contexte technique et métier qui n’a rien à voir. Je pense avoir réussi, avec l’aide des équipes chez le client, à trouver le meilleur compromis pour le projet.

🎯 Tu deviens CTO de WeloveDevs, une plateforme historique pour les devs. Quel est ton premier objectif pour redonner de l’élan à son écosystème technique ?

J’adore (et je déteste aussi, c’est mon côté schizophrène) cette phase de reprise d’un projet. La plateforme WeLoveDevs est un énorme challenge pour Insitoo pour plusieurs raisons :

• C’est une référence pour les recruteurs et pour les devs, il s’agit de ne décevoir personne.
• Ce sont des choix techniques que je n’ai pas faits. Certains choix étant une source d’inspiration pour moi (c’est très enrichissant de voir comment les autres ont construit leurs projets), d’autres une source d’urticaire 😅. Alors attention, je ne juge pas du tout, ce que je vois aujourd’hui n’est qu’une photo du projet, je n’ai aucune idée du parcours qui a été nécessaire pour en arriver là.

Avec tout ça, mon premier objectif est de nous approprier le produit, au niveau métier et technique, et de monter en efficacité pour rapidement relancer des évolutions !
Avant toute chose, nous sommes en train d’intégrer WeLoveDevs à notre écosystème Insitoo : supervision, CI/CD, hébergement, sécurité, services tiers. En parallèle, nous montons en compétences sur les technos utilisées.

🚀 Insitoo a ouvert une agence sur Paris. Quel est ton conseil n°1 pour un dev qui veut se lancer en freelance aujourd’hui ? Et pour une entreprise qui veut travailler avec des freelances ?

Alors mon conseil de vieux briscard, après 15 ans de freelancing, je dirais au dev qui veut se lancer :

• Fais d’abord tes armes. A mon époque (oui, je parle comme un vieux), on se lançait freelance quand on était devenu expert. Aujourd’hui le marché est moins binaire mais pour moi (et pour beaucoup) un freelance doit être autonome et performant, une valeur sûre dans son domaine.

• Définit ensuite ce que tu attends du freelancing, et tu sauras où aller. Il n’y a pas 2 freelances identiques (on en connaît pourtant plus de 16.000 chez Insitoo), et plus tu sauras te positionner / différencier et plus le choix client sera simple. Ton expérience de salarié t’aura montré ce que tu aimes / n’aimes pas, et où tu veux aller.
• Le freelancing t’apporte la liberté (de choisir ta mission, potentiellement ton tarif en fonction de l’état du marché, ton planning de carrière), c’est un vrai plaisir quand tu sais ce que tu veux. N’hésite pas, tu peux y aller par étape avant de sauter dans le grand bain : le portage salarial te permettra de “tester” l’approche pour confirmer ton choix.

Pour une entreprise qui veut travailler avec des freelances, finalement mon conseil s’en rapproche un peu : définissez ce que vous attendez des freelances (oui, je vouvoie l’entreprise).

• N’ayez pas peur, freelancing ne veut pas dire volatilité des missions (vous seriez surpris de la durée moyenne des missions chez Insitoo)
• Un freelance, c’est avant tout un consultant, mais qui sait ce qu’il veut / ce qu’il vaut. Ne vous attendez pas à ce que le freelance fasse “juste” son travail, vous seriez surpris !

🗣️ Comment comptes-tu utiliser LinkedIn ou d’autres canaux pour partager ton expertise ? Un format de contenu que tu adores (threads, vidéos, articles…) ?

Ah ah, je vois la question piège 😅. Pour mes contenus, je consomme aussi bien des articles (Medium, Hacker News, et bien d’autres que mon feed Google aime bien me proposer) que des vidéos (en mode podcast, j’avoue, les images c’est pour les jeunes). Je suis pas mal de monde sur Linkedin mais je filtre beaucoup pour que ça reste productif :

• Si je détecte un ton “le XXX est mort, vive le YYY”, je passe
• Idem pour les “Depuis que je ZZZ, je suis millionnaire”, ou tout autre titre aguicheur
• Si c’est extra-professionnel, je ne fais même pas attention

Si je devais choisir un format de contenu préféré, ce serait l’article (une réminiscence de mon passé dans la recherche) : quand il est bien fait, le TLDR; me dit tout de suite si je dois continuer, et si je suis pressé la recherche me permet de trouver tout de suite ce que je veux.

⚙️📚 Un outil, un livre ou une habitude qui a changé ta façon de travailler ces dernières années ?

Alors 2 choses qui ont structuré ma façon actuelle de travailler :

• Au niveau personnel, une habitude que j’ai prise au fil du temps sur mes projets indés : la gestion du planning. J’ai une capacité à travailler efficacement, mais sur une période de temps réduite (si je fais du 8h 18h “à fond”, je suis KO pour plusieurs jours ensuite).
  Alors mon planning actuel est segmenté : travail tech le matin (1 à 2h), puis pause café, puis support / gestion transverse / projets, puis pause repas, puis administratif / gestion des contrats / gestion de carrière / veille tech (après le repas, ça permet de digérer), dernier café (déca pour l’après-midi) puis de nouveau travail tech pour finir la journée.
  Et ne surtout pas oublier la déconnexion le soir et le week-end (relativement, il ne faut pas oublier la prod quand même).
• Et au niveau projet, un petit livre que j’ai découvert en 2019 : “Lean Startup”, de Eric Ries (pas d’inquiétude, il existe en français aussi). C’est davantage un déclic pour moi qu’une Bible à suivre, mais ça a bien structuré ma façon de mener les projets depuis.

👉 Son Linkedin