J'interviens là où les choix techniques ont un impact direct sur le produit, l'équipe ou la décision business. Selon le contexte, la mission peut être très opérationnelle, plus orientée architecture, ou centrée sur l'aide à la décision.
Repères
Les anciennes pages services, technologies, problèmes, méthodologie et FAQ sont regroupées ici pour éviter la dispersion et rendre les choix plus simples à lire.
J'interviens directement dans l'équipe pour prendre en charge des sujets qui demandent plus qu'un renfort de capacité : reprise d'une zone instable, refonte ciblée, structuration d'un front Angular ou Next.js, conception d'une API NestJS, amélioration de la qualité ou sécurisation d'une mise en production.
Sur un produit devenu difficile à faire évoluer, je n'oriente pas par défaut vers une refonte totale. J'analyse l'existant, j'identifie les briques critiques et je propose une reprise progressive liée aux enjeux business.
J'aide à porter la cohérence technique globale : choix de stack, architecture applicative, priorisation de la dette, standards d'équipe, stratégie de delivery et arbitrages entre court terme et long terme.
J'interviens auprès des dirigeants, équipes métier ou équipes produit pour transformer un besoin fonctionnel en trajectoire technique claire : cadrage, relecture de proposition ESN, choix de prestataire, priorisation ou suivi de livrables.
Mon socle principal reste JavaScript / TypeScript côté produit : Angular, Next.js, React.js et React Native pour les interfaces ; Next.js, APISIX, NestJS ou Rust selon les besoins côté backend, API gateway ou composants spécialisés. La stack sert le produit, pas l'inverse.
Sur un projet complet, je peux structurer un socle avec un backoffice Angular, une application web Next.js ou React.js, une application mobile React Native, une API gateway APISIX et des services backend Next.js, NestJS ou Rust selon les besoins. Le déploiement, les données et les traitements asynchrones sont choisis selon le contexte réel, pas par réflexe d'industrialisation.
Sur Angular, React ou Next.js, je travaille la séparation entre composants, hooks ou services, logique applicative, accès aux données, modèles, validations et tests pour éviter les interfaces difficiles à maintenir.
Quand plusieurs clients consomment la même API, je mets souvent en place des contrats TypeScript partagés et un SDK applicatif qui centralise routes, authentification, validation, erreurs, retry et comportements transverses.
Sur des applications métiers complexes, l'API peut exposer les actions autorisées selon l'utilisateur, ses droits et l'état de l'entité. Les fronts affichent ce que l'API déclare possible sans dupliquer toute la règle métier.
J'intègre l'IA comme un outil de travail, pas comme une promesse magique : Codex, Claude ou d'autres agents peuvent aider l'idéation, la conception, le développement, les tests ou la recette, avec règles de revue, critères de qualité et validation humaine.
Une mission commence rarement par coder plus vite. Elle commence par comprendre ce qui bloque vraiment, clarifier les risques, proposer des arbitrages, intervenir au bon niveau puis transmettre le cadre.
JavaScript / TypeScript reste mon terrain principal, mais l'architecture doit d'abord servir le produit, l'équipe et la maintenance. Les briques ci-dessous sont celles que j'utilise ou pilote le plus souvent selon le contexte.
Interfaces web, backoffices, produits SaaS et applications mobiles.
Services applicatifs, BFF, passerelles API et composants spécialisés.
Traitements asynchrones, découplage de services et files de messages.
Données relationnelles, documentaires, cache et usages produit.
Automatisation, conteneurisation, déploiement et environnements.
Agents et assistants utilisés avec règles, revue et garde-fous qualité.
Le besoin métier est clair, mais sa traduction technique ne l'est pas. Les devis ne parlent pas le même langage, les délais semblent difficiles à comparer et les décisions structurantes sont noyées dans des termes techniques.
Direction technique à temps partielVous avez un MVP, des premiers utilisateurs et peut-être une équipe qui grandit. Les choix faits pour aller vite commencent à peser : code difficile à reprendre, architecture peu explicite, dette qui ralentit la roadmap, recrutement CTO encore prématuré.
Relais senior pour équipe techniqueLe CTO ou le lead valide trop de décisions seul. Une zone du code est devenue sensible. Le front Angular grossit sans séparation claire. L'API NestJS porte trop de logique au mauvais endroit. Personne ne veut lancer une refonte complète, mais tout le monde sent qu'il faut reprendre une partie du socle.
Profil freelance seniorVotre client cherche un profil capable d'intégrer une équipe, mais aussi de reprendre un sujet sensible, challenger une architecture, clarifier des décisions ou rassurer une direction. La fiche hésite entre lead dev, architecte et CTO freelance.
Beaucoup d'entreprises utilisent déjà l'IA. Mais certaines découvrent aussi ses effets secondaires : coûts en tokens, perte de motivation, surcharge de review, QA saturée et valeur difficile à mesurer.
Lire l'articleVous avez reçu une proposition ESN mais pas d'équipe technique interne pour l'évaluer ? Voici les points à vérifier avant de signer : périmètre, risques, livrables, qualité, profils et pilotage.
Lire l'articleUne stratégie simple pour éviter les composants Angular qui font tout : vue dans le composant, état local en signals, orchestration dans une couche Business, accès externes dans des services et adapters.
Lire l'articleHATEOAS est souvent traité comme une curiosité théorique de REST. En pratique, le principe devient intéressant dès qu'une API porte beaucoup de règles métier, plusieurs workflows et plusieurs fronts à faire vivre en parallèle.
Lire l'articleLa dette technique n'est pas seulement un sujet de développeurs. Elle devient un risque business quand elle ralentit la roadmap, fragilise la qualité, brouille les estimations et rend chaque évolution anormalement coûteuse.
Lire l'articleLe lead developer porte surtout l'exécution senior. Le lead tech ajoute une responsabilité de cohérence technique et d'arbitrage. Le CTO externalisé couvre une fonction de direction technique à temps partiel, adaptée au stade du projet.
Oui. Je peux cadrer et arbitrer, mais j'interviens aussi dans le code lorsque c'est le meilleur moyen de débloquer, sécuriser ou transmettre.
JavaScript / TypeScript est mon cœur de stack, mais je ne l'impose pas par principe. Le choix dépend du besoin, de l'équipe, du produit et des contraintes de maintenance.
Oui. Je peux relire des propositions, préparer des questions de soutenance, identifier les zones floues et suivre les livrables avec un regard technique indépendant.
Non. L'IA ne remplace pas le discernement technique ni la connaissance métier. Elle peut accélérer certaines phases si elle est cadrée par des règles, des revues et des critères qualité.
Non. Je suis basé dans la région lyonnaise, mais les missions peuvent se faire à distance, en hybride ou avec des temps sur site selon le contexte.
Un premier échange permet de qualifier le stade du produit, les points de friction et le format d'intervention réellement utile.