Votre backend est devenu lent, fragile ou coûteux. Vous devez faire évoluer un existant, construire une nouvelle capacité, ou simplement mieux comprendre la situation avant de décider.
J’interviens sur ce type de problème avec votre équipe, depuis le cadrage jusqu’à la mise en production et la transmission.
Mon expertise technique est particulièrement ancrée dans Go, les systèmes backend et les problématiques de production — sans imposer une technologie lorsque le problème en appelle une autre.
C’est probablement pertinent si¶
- le problème a un impact réel sur le produit, l’exploitation ou l’équipe ;
- vous avez besoin de seniorité et d’autonomie, pas simplement de capacité supplémentaire ;
- vous voulez une intervention bornée, avec une sortie claire ;
- votre équipe doit pouvoir reprendre le sujet après mon intervention.
Quatre façons d’intervenir¶
Diagnostic technique ciblé¶

Vous savez qu’il faut agir, mais pas encore dans quelle direction.
Le diagnostic sert à réduire suffisamment l’incertitude pour prendre une décision : comprendre les faits, qualifier les causes, comparer les options et recommander une direction.
Selon le sujet, cela peut passer par du profiling, l’analyse de métriques et de logs, des benchmarks, une revue d’architecture ou un prototype limité.
Vous repartez avec :
- les constats ;
- le diagnostic ;
- les options envisageables ;
- une recommandation argumentée.
Un diagnostic n’est pas une étape obligatoire. Si le problème et la direction sont déjà suffisamment clairs, nous pouvons directement définir une phase de réalisation.
Stabiliser¶

Votre backend est devenu lent, fragile, coûteux ou difficile à exploiter.
L’objectif est de remettre une situation sous contrôle, pas de devenir la personne qui compense durablement ses défauts.
L’intervention peut combiner investigation, changements applicatifs, performance, observabilité, infrastructure, déploiement ou architecture lorsque le problème l’exige.
Quelques situations typiques :
- incidents récurrents ;
- temps de réponse ou consommation de ressources qui dérivent ;
- coûts d’infrastructure difficiles à expliquer ou à maîtriser ;
- manque d’observabilité qui empêche de comprendre le système ;
- déploiements risqués ou exploitation devenue fragile.
La sortie est définie à l’avance par des critères observables liés au problème traité.
Transformer¶

Votre système fonctionne encore, mais son architecture ou ses choix techniques commencent à limiter son évolution.
Migration de langage ou de plateforme, remplacement progressif d’un composant, découpage d’un existant, réécriture partielle ou évolution d’architecture : l’objectif est de passer d’un état à un autre sans perdre de vue la production.
Je privilégie les transformations progressives : une première verticale représentative, des états intermédiaires exploitables et des points de décision explicites plutôt qu’un big bang.
Quelques situations typiques :
- migration technologique ;
- composant devenu difficile à maintenir ;
- architecture qui ralentit le delivery ;
- dette technique qui empêche une évolution importante ;
- besoin de faire évoluer progressivement un système critique.
Une transformation importante peut être découpée en plusieurs phases successives. Chacune doit produire un résultat utile et permettre de décider de la suite.
Construire¶

Vous avez besoin d’une nouvelle capacité backend clairement délimitée.
J’interviens surtout lorsque le sujet nécessite de la seniorité technique, des arbitrages ou une responsabilité forte de mise en production — pas pour remplacer une équipe produit complète.
Je peux partir du besoin, poser les choix techniques, développer, intégrer, déployer et transmettre un composant que votre équipe pourra ensuite maintenir et faire évoluer.
Je ne prends pas une file de tickets dans votre backlog : nous convenons d’une capacité précise à livrer, avec une sortie définie.
Quelques exemples :
- nouveau service backend ;
- intégration ou flux métier critique ;
- composant d’infrastructure applicative ;
- outil interne ;
- nouvelle capacité opérationnelle.
Les montants indiqués correspondent aux missions pour lesquelles une intervention Cabestan est généralement pertinente. Un besoin beaucoup plus petit peut parfois appeler une solution plus simple — ou ne pas justifier une mission de conseil.
Comment se déroule une mission ?¶
Comprendre
Pourquoi faut-il agir maintenant ? Quel est l'impact du problème et quelles contraintes faut-il respecter ?
Définir la sortie
Nous convenons de ce qui devra avoir changé pour considérer la mission comme terminée.
Réaliser
Selon le problème : investigation, conception, développement, migration, infrastructure, CI/CD, observabilité ou mise en production.
Transmettre
Les décisions et le fonctionnement sont transmis à l'équipe pour qu'elle puisse reprendre le sujet et le faire évoluer.
En savoir plus sur ma manière de travailler →
Comment sont fixés les prix ?¶
Le prix est attaché au résultat convenu et à son périmètre, pas au temps effectivement consommé.
Les montants indiqués sur cette page sont des repères budgétaires, pas une grille automatique. Le prix précis dépend notamment de l’état du système, du résultat attendu, des contraintes de production, des dépendances externes et du niveau de risque à prendre en charge.
Lorsque le sujet est trop incertain pour définir honnêtement une phase de réalisation, je propose d’abord un Diagnostic technique ciblé. Si la situation est déjà suffisamment claire, inutile d’ajouter un audit simplement pour pouvoir établir une proposition.
Ce n’est probablement pas la bonne formule si…¶
- vous cherchez surtout un développeur supplémentaire pour avancer sur un backlog ou apporter de la capacité d’exécution ;
- le périmètre doit rester ouvert sans résultat de sortie défini ;
- vous cherchez une maintenance permanente ou une astreinte ;
- personne ne pourra reprendre le sujet après mon intervention.
Vous cherchez plutôt quelqu’un pour porter les décisions techniques et accompagner l’équipe dans la durée ?
Quelques réalisations¶
NuCorder : Transformer
Migration progressive du backend de Java/Spring vers Go, évolution de l'infrastructure de production et CI ramenée de 30 à 5 minutes.
Lire le retour d'expérience sur la migration Java → Go →Molotov : Backend & production
Plusieurs années sur des systèmes backend à grande échelle, puis des responsabilités de Tech Lead et Engineering Manager, avec des sujets d'infrastructure, Kubernetes, CI/CD et developer experience.
Voir les réalisations →