Ma manière de travailler

Je travaille à partir du problème à résoudre, pas d’une solution décidée à l’avance.

Que j’intervienne sur un sujet backend ciblé ou dans un rôle de Fractional CTO, j’essaie de garder la même approche : comprendre le contexte, rendre les décisions explicites, aller jusqu’au résultat utile et permettre à l’équipe de reprendre la suite.

Comprendre avant de proposer¶

Je commence par comprendre ce qui vous pousse à agir : le problème rencontré, son impact, ce qui a déjà été essayé et les contraintes à respecter. L’objectif est aussi de définir ce qui devra avoir changé à la fin de mon intervention.

Je ne pars pas du principe qu’un problème backend nécessite une réécriture, que Go est nécessairement la bonne réponse ou qu’une équipe a besoin d’un Fractional CTO.

Savoir où l’on va¶

Pour une mission backend, nous définissons le résultat attendu, le périmètre de l’intervention et les conditions qui permettront de considérer le travail terminé.

Je préfère travailler ainsi plutôt que vendre une simple consommation de jours : le temps nécessaire est mon problème de gestion, le résultat convenu est notre point de référence commun.

Un rôle de Fractional CTO fonctionne différemment : je réserve de la capacité dans la durée pour porter cette responsabilité technique. Les décisions structurelles (architecture, organisation) demandent un suivi, des ajustements et une continuité d’exercice.

Travailler avec l’équipe¶

Les problèmes techniques sont rarement uniquement techniques. Je travaille donc avec les personnes qui possèdent le contexte nécessaire : développeurs, produit, SRE/opérations, direction ou utilisateurs internes selon le sujet.

Je privilégie une communication directe, des décisions explicites et le moins de cérémonial possible. Je travaille à distance par défaut, avec des interventions sur place lorsqu’elles apportent quelque chose : démarrage d’une mission, atelier, travail d’équipe ou décision importante.

Chez Molotov, où je suis resté sept ans en passant de développeur backend à tech lead puis Engineering Manager, deux choses m’ont particulièrement marqué : la qualité des relations entre équipes et l’attention portée à l’expérience développeur. Ce sont des leviers moins visibles qu’un choix d’architecture, mais qui comptent énormément quand un système et une organisation évoluent dans la durée.

Partir du problème, pas de l’outil¶

Mon expertise porte principalement sur Go, le backend, l’infrastructure et la production, mais je ne cherche pas à vous vendre ces solutions si votre problème ne le nécessite pas.

J’ai déjà vu des outils d’IA générative introduits très largement avant que le problème à résoudre soit réellement identifié. Le résultat n’était pas à la hauteur de l’effort engagé. Depuis, je garde la même règle : partir du problème, puis choisir l’outil.

Je peux utiliser l’IA générative lorsqu’elle apporte un gain réel, dans le respect des contraintes de sécurité et de confidentialité du client. Si le contexte impose de travailler sans, je travaille sans.

L’outil doit servir le problème, pas le dicter.

Aller jusqu’au bout, puis transmettre¶

Sur une mission de réalisation, mon travail ne s’arrête pas à une recommandation ou à du code : selon le sujet, cela peut demander d’investiguer, de construire, de faire évoluer l’existant et d’aller vérifier le résultat jusqu’en production. Mon but est d’aller vers un résultat réellement utilisable.

Enfin, je ne cherche pas à devenir la seule personne capable de comprendre ce qui a été construit ou décidé : les choix importants doivent pouvoir être expliqués et documentés, le système doit avoir été mis à l’épreuve en production et l’équipe doit pouvoir reprendre la suite.