Modernisation
Modernise your systems
Legacy systems slow down change.
I modernise incrementally to reduce risk.
Technical Leadership for Scalable Product Delivery (Fr)
Technology Consultant
Engineering that creates business value.
I help companies build scalable digital products by bringing together software architecture, product strategy and engineering leadership.
Who I work with
- Startups
- Scale-ups
- SMEs
- Enterprise
Technology for growth
Your technology investment should grow your business.
The right architecture accelerates delivery, reduces operating costs and prepares your company for future growth. I design and deliver that transformation.
- 01
Business goals
I make sure your software investment supports company goals and measurable outcomes.
- Faster delivery
- Lower costs
- Measurable value
- 02
Right architecture
I design systems that solve today's needs without limiting tomorrow's growth.
- Less technical debt
- Ready for change
- Scalable systems
- 03
Reliable delivery
I help new features reach customers safely and predictably.
- Safer releases
- Faster development
- Operational continuity
- 04
Sustainable growth
I turn technology into long-term efficiency and competitive advantage.
- Controlled costs
- Resilient operations
- Ready to scale
Measured by impact numbers that reflect our growth and trust.
Help when you need it!
Where technology holds you back
Turn your technology investment into a competitive advantage.
Are your systems limiting growth?
Legacy systems and technical debt become an adaptable, sustainable architecture.
Explore the approach →Is delivery slowing down?
Your teams gain the practices needed to deliver faster, predictably and reliably.
Explore the approach →Is technology investment falling short?
Technical decisions align with growth, cost and operational goals, turning investment into measurable business outcomes.
Explore the approach →11+ years · Cloud · AI · Marketplaces · Distributed systems
The right fit
I work with you when the problem is the right one.
The best projects happen when technical goals and business goals move in the same direction. That is why I choose every engagement with care.
Where I create the most value
- SaaS companies preparing to scale their product
- Marketplace and e-commerce platforms
- Teams modernising legacy systems
- Companies integrating AI into business processes
- Engineering teams building cloud and distributed systems
It may not be the right fit
- Companies that make price the only decision criterion
- Teams that put short-term fixes ahead of long-term architecture
- Organisations that continually postpone technical debt
- Teams that change priorities without establishing delivery discipline
- Companies seeking code delivery without product ownership
Working principles
Stop technology from slowing your company down.
Every technical decision should produce faster delivery, lower risk and sustainable growth.
- ↗New features reach customers sooner.
Reach production faster
Small changes should not create major release risk.
- ↗Technical risk no longer blocks growth.
Bring technical debt under control
Complexity becomes visible and priorities follow business impact.
- ↗Delivery accelerates and dependencies decrease.
Help teams move independently
Clear system boundaries reduce how often teams wait on one another.
- ↗Safer releases and more resilient operations.
Make delivery predictable
Automation, measurement and observability reduce operational risk.
Work built together
I turn distinct business models into reliable, scalable digital products.
Each engagement is a case study in bringing business context, technical decisions, and delivery discipline into one system.
Kayra Export : Marketplace et plateforme de commerce électronique (CTO)
ABC Logistics : plateforme de suivi SIG en temps réel
Crypto nue : DApp minière du marché NFT
Rapid Render : configurateur de produit 3D en temps réel
Dunelm : expérience AR « View-in-Room » prise en charge par LiDAR
Mulcol : Simulation d'assemblage coupe-feu VRMulcol : catalogue d'assemblage AR (basé sur des marqueurs)Featured engagement
Kayra Export : Marketplace et plateforme de commerce électronique (CTO)
En tant que CTO, j'ai géré la transformation du e-commerce et du marché ; J'ai construit une architecture microservice .NET + CQRS et l'ai mise à l'échelle sur AWS. J'ai produit l'infrastructure de commerce multicanal avec des modules de paiement/intégration et d'intelligence artificielle.
See what I delivered in this case studyPerspectives
Technology, growth and better decisions.
Que recherchent réellement les entreprises Fintech ?
Perspective de carrière : les entreprises de technologie financière et non le SDK Stripe ; Il recherche la pensée de l’échec, la réconciliation,…
Plan de la série
Moteur de paiement distribué
Partie 22 / 22
- Partie 1 Pourquoi les systèmes de paiement sont-ils des systèmes distribués ?
- Partie 2 Conception de la machine à statut de paiement : pourquoi le paiement et le paiement ne sont-ils pas la même chose ?
- Partie 3 Pourquoi la collecte (capture) est-elle facile mais la finalisation est-elle difficile ?
- Partie 4 Conception d'instantanés de paiement immuables : la décision qui gèle le panier
- Partie 5 Demande d'idempotence (transaction sécurisée répétable) au-delà de l'API (interface de programmation d'application)
- Partie 6 Fiabilité des webhooks dans les systèmes de paiement
- Partie 7 Modèle de boîte d'envoi/boîte de réception dans les systèmes de paiement
- Partie 8 Preuve de paiement et statut de paiement : pourquoi il ne faut pas confondre
- Partie 9 Abstraction du fournisseur sans fuite SDK (kit de développement logiciel) : la limite de la passerelle
- Partie 10 Événement sémantique au lieu de données brutes du fournisseur
- Partie 11 Taxonomie des erreurs de paiement
- Partie 12 Algorithmes de nouvelle tentative pour les agents de paiement
- Partie 13 Base de données prise en charge fonctionne avec location
- Partie 14 Travailleur au rapprochement des paiements dans la construction
- Partie 15 Payé mais pas de commande : amélioration
- Partie 16 Pourquoi la cohérence finale est supérieure à la transaction distribuée
- Partie 17 Concurrence optimiste sous Webhook
- Partie 18 Observabilité et corrélation des paiements
- Partie 19 Pipeline et Runbook de récupération des paiements
- Partie 20 Traitement efficace des paiements une seule fois
- Partie 21 Conception d'un moteur de paiement de production
- Partie 22 Que recherchent réellement les entreprises Fintech ?
Conception d'un moteur de paiement de production
Synthèse de la série en 22 parties : liste de contrôle architecturale pour le moteur de paiement de production avec orchestrateur de caisse et passerelle…
Plan de la série
Moteur de paiement distribué
Partie 21 / 22
- Partie 1 Pourquoi les systèmes de paiement sont-ils des systèmes distribués ?
- Partie 2 Conception de la machine à statut de paiement : pourquoi le paiement et le paiement ne sont-ils pas la même chose ?
- Partie 3 Pourquoi la collecte (capture) est-elle facile mais la finalisation est-elle difficile ?
- Partie 4 Conception d'instantanés de paiement immuables : la décision qui gèle le panier
- Partie 5 Demande d'idempotence (transaction sécurisée répétable) au-delà de l'API (interface de programmation d'application)
- Partie 6 Fiabilité des webhooks dans les systèmes de paiement
- Partie 7 Modèle de boîte d'envoi/boîte de réception dans les systèmes de paiement
- Partie 8 Preuve de paiement et statut de paiement : pourquoi il ne faut pas confondre
- Partie 9 Abstraction du fournisseur sans fuite SDK (kit de développement logiciel) : la limite de la passerelle
- Partie 10 Événement sémantique au lieu de données brutes du fournisseur
- Partie 11 Taxonomie des erreurs de paiement
- Partie 12 Algorithmes de nouvelle tentative pour les agents de paiement
- Partie 13 Base de données prise en charge fonctionne avec location
- Partie 14 Travailleur au rapprochement des paiements dans la construction
- Partie 15 Payé mais pas de commande : amélioration
- Partie 16 Pourquoi la cohérence finale est supérieure à la transaction distribuée
- Partie 17 Concurrence optimiste sous Webhook
- Partie 18 Observabilité et corrélation des paiements
- Partie 19 Pipeline et Runbook de récupération des paiements
- Partie 20 Traitement efficace des paiements une seule fois
- Partie 21 Conception d'un moteur de paiement de production
- Partie 22 Que recherchent réellement les entreprises Fintech ?
Traitement efficace des paiements une seule fois
La messagerie exactement une fois est un mensonge. Comment obtenir des résultats opérationnels efficaces lorsque la Défense en profondeur est combinée à…
Plan de la série
Moteur de paiement distribué
Partie 20 / 22
- Partie 1 Pourquoi les systèmes de paiement sont-ils des systèmes distribués ?
- Partie 2 Conception de la machine à statut de paiement : pourquoi le paiement et le paiement ne sont-ils pas la même chose ?
- Partie 3 Pourquoi la collecte (capture) est-elle facile mais la finalisation est-elle difficile ?
- Partie 4 Conception d'instantanés de paiement immuables : la décision qui gèle le panier
- Partie 5 Demande d'idempotence (transaction sécurisée répétable) au-delà de l'API (interface de programmation d'application)
- Partie 6 Fiabilité des webhooks dans les systèmes de paiement
- Partie 7 Modèle de boîte d'envoi/boîte de réception dans les systèmes de paiement
- Partie 8 Preuve de paiement et statut de paiement : pourquoi il ne faut pas confondre
- Partie 9 Abstraction du fournisseur sans fuite SDK (kit de développement logiciel) : la limite de la passerelle
- Partie 10 Événement sémantique au lieu de données brutes du fournisseur
- Partie 11 Taxonomie des erreurs de paiement
- Partie 12 Algorithmes de nouvelle tentative pour les agents de paiement
- Partie 13 Base de données prise en charge fonctionne avec location
- Partie 14 Travailleur au rapprochement des paiements dans la construction
- Partie 15 Payé mais pas de commande : amélioration
- Partie 16 Pourquoi la cohérence finale est supérieure à la transaction distribuée
- Partie 17 Concurrence optimiste sous Webhook
- Partie 18 Observabilité et corrélation des paiements
- Partie 19 Pipeline et Runbook de récupération des paiements
- Partie 20 Traitement efficace des paiements une seule fois
- Partie 21 Conception d'un moteur de paiement de production
- Partie 22 Que recherchent réellement les entreprises Fintech ?
Pipeline et Runbook de récupération des paiements
Avant l'automatisation : agent de réconciliation et pipeline de récupération. Les runbooks humains fondés sur des preuves entrent en jeu lorsque des murs…
Plan de la série
Moteur de paiement distribué
Partie 19 / 22
- Partie 1 Pourquoi les systèmes de paiement sont-ils des systèmes distribués ?
- Partie 2 Conception de la machine à statut de paiement : pourquoi le paiement et le paiement ne sont-ils pas la même chose ?
- Partie 3 Pourquoi la collecte (capture) est-elle facile mais la finalisation est-elle difficile ?
- Partie 4 Conception d'instantanés de paiement immuables : la décision qui gèle le panier
- Partie 5 Demande d'idempotence (transaction sécurisée répétable) au-delà de l'API (interface de programmation d'application)
- Partie 6 Fiabilité des webhooks dans les systèmes de paiement
- Partie 7 Modèle de boîte d'envoi/boîte de réception dans les systèmes de paiement
- Partie 8 Preuve de paiement et statut de paiement : pourquoi il ne faut pas confondre
- Partie 9 Abstraction du fournisseur sans fuite SDK (kit de développement logiciel) : la limite de la passerelle
- Partie 10 Événement sémantique au lieu de données brutes du fournisseur
- Partie 11 Taxonomie des erreurs de paiement
- Partie 12 Algorithmes de nouvelle tentative pour les agents de paiement
- Partie 13 Base de données prise en charge fonctionne avec location
- Partie 14 Travailleur au rapprochement des paiements dans la construction
- Partie 15 Payé mais pas de commande : amélioration
- Partie 16 Pourquoi la cohérence finale est supérieure à la transaction distribuée
- Partie 17 Concurrence optimiste sous Webhook
- Partie 18 Observabilité et corrélation des paiements
- Partie 19 Pipeline et Runbook de récupération des paiements
- Partie 20 Traitement efficace des paiements une seule fois
- Partie 21 Conception d'un moteur de paiement de production
- Partie 22 Que recherchent réellement les entreprises Fintech ?
Observabilité et corrélation des paiements
Comment corréler chaque journal, métrique et trace avec l'identifiant de paiement ? Comment le journal des événements étape par étape et les métriques de…
Plan de la série
Moteur de paiement distribué
Partie 18 / 22
- Partie 1 Pourquoi les systèmes de paiement sont-ils des systèmes distribués ?
- Partie 2 Conception de la machine à statut de paiement : pourquoi le paiement et le paiement ne sont-ils pas la même chose ?
- Partie 3 Pourquoi la collecte (capture) est-elle facile mais la finalisation est-elle difficile ?
- Partie 4 Conception d'instantanés de paiement immuables : la décision qui gèle le panier
- Partie 5 Demande d'idempotence (transaction sécurisée répétable) au-delà de l'API (interface de programmation d'application)
- Partie 6 Fiabilité des webhooks dans les systèmes de paiement
- Partie 7 Modèle de boîte d'envoi/boîte de réception dans les systèmes de paiement
- Partie 8 Preuve de paiement et statut de paiement : pourquoi il ne faut pas confondre
- Partie 9 Abstraction du fournisseur sans fuite SDK (kit de développement logiciel) : la limite de la passerelle
- Partie 10 Événement sémantique au lieu de données brutes du fournisseur
- Partie 11 Taxonomie des erreurs de paiement
- Partie 12 Algorithmes de nouvelle tentative pour les agents de paiement
- Partie 13 Base de données prise en charge fonctionne avec location
- Partie 14 Travailleur au rapprochement des paiements dans la construction
- Partie 15 Payé mais pas de commande : amélioration
- Partie 16 Pourquoi la cohérence finale est supérieure à la transaction distribuée
- Partie 17 Concurrence optimiste sous Webhook
- Partie 18 Observabilité et corrélation des paiements
- Partie 19 Pipeline et Runbook de récupération des paiements
- Partie 20 Traitement efficace des paiements une seule fois
- Partie 21 Conception d'un moteur de paiement de production
- Partie 22 Que recherchent réellement les entreprises Fintech ?
Concurrence optimiste sous Webhook
Comment le jeton de version et le bail résolvent-ils la course lorsque la réponse synchrone avec le webhook touche le même paiement en même temps ? Lecture…
Plan de la série
Moteur de paiement distribué
Partie 17 / 22
- Partie 1 Pourquoi les systèmes de paiement sont-ils des systèmes distribués ?
- Partie 2 Conception de la machine à statut de paiement : pourquoi le paiement et le paiement ne sont-ils pas la même chose ?
- Partie 3 Pourquoi la collecte (capture) est-elle facile mais la finalisation est-elle difficile ?
- Partie 4 Conception d'instantanés de paiement immuables : la décision qui gèle le panier
- Partie 5 Demande d'idempotence (transaction sécurisée répétable) au-delà de l'API (interface de programmation d'application)
- Partie 6 Fiabilité des webhooks dans les systèmes de paiement
- Partie 7 Modèle de boîte d'envoi/boîte de réception dans les systèmes de paiement
- Partie 8 Preuve de paiement et statut de paiement : pourquoi il ne faut pas confondre
- Partie 9 Abstraction du fournisseur sans fuite SDK (kit de développement logiciel) : la limite de la passerelle
- Partie 10 Événement sémantique au lieu de données brutes du fournisseur
- Partie 11 Taxonomie des erreurs de paiement
- Partie 12 Algorithmes de nouvelle tentative pour les agents de paiement
- Partie 13 Base de données prise en charge fonctionne avec location
- Partie 14 Travailleur au rapprochement des paiements dans la construction
- Partie 15 Payé mais pas de commande : amélioration
- Partie 16 Pourquoi la cohérence finale est supérieure à la transaction distribuée
- Partie 17 Concurrence optimiste sous Webhook
- Partie 18 Observabilité et corrélation des paiements
- Partie 19 Pipeline et Runbook de récupération des paiements
- Partie 20 Traitement efficace des paiements une seule fois
- Partie 21 Conception d'un moteur de paiement de production
- Partie 22 Que recherchent réellement les entreprises Fintech ?
Before you decide
What you should know before deciding.
Do you need to rewrite the entire system?
Usually not. I first identify the areas creating the greatest business risk and cost, then modernise the system incrementally and with controlled risk.
How soon will you see the first result?
Timing depends on the scope of the problem. I divide the work into small, measurable steps and clarify both quick wins and the long-term roadmap first.
Will you need to replace your team or change how it works?
Usually not. The goal is not to replace the team, but to preserve its knowledge while strengthening decision-making, development and delivery.
How do you measure whether the investment creates value?
I clarify success measures with you at the start, using indicators relevant to the problem such as delivery time, defect rate, operating cost and team wait time.
What happens in the first technical conversation?
I discuss your current system, team and business goals, clarify the priority risks and recommend the most useful next step for you.