Une partie importante de mon parcours s'est construite en dehors du cadre professionnel : par la pratique, les projets personnels, l'expérimentation et l'envie de comprendre.
Cette pratique a commencé très tôt, avec des projets simples, puis s'est élargie au fil du temps : sites web, scripts, outils internes, prototypes, APIs, produits SaaS et bases techniques réutilisables.
Avant même mon parcours professionnel, j'ai exploré différents sujets en autodidacte : maintenance informatique, réseau, développement web, scripts, outils et expérimentations. Cette approche m'a donné une vision très concrète de la technique : comprendre, tester, réparer, améliorer, puis structurer.
Aujourd'hui encore, le développement reste mon principal terrain d'expérimentation en dehors du cadre professionnel. Je consacre une part importante de mon temps personnel à mes propres produits, outils et prototypes : SaaS, dashboards, APIs, templates techniques, automatisations, expérimentations frontend et contributions open source.
Avec le temps, cette curiosité s'est transformée en une approche plus structurée : concevoir des outils complets, comprendre les usages, choisir une architecture adaptée, garder le code maintenable et livrer des produits capables d'évoluer dans la durée.
Cette pratique continue a construit une façon d'aborder le développement basée sur l'autonomie, la compréhension globale des systèmes et le recul technique.
Autonomie
Apprendre vite, tester, comprendre et progresser sans attendre que tout soit entièrement cadré.
Une autonomie qui me permet de m’adapter rapidement à de nouveaux contextes techniques ou métiers.
Vision produit
Concevoir au-delà du code : usage réel, UX, backend, infrastructure, sécurité et maintenabilité.
Une approche globale construite à travers mes propres projets SaaS et produits web.
Discernement technique
Choisir une technologie ou une architecture pour répondre à un contexte, pas par tendance.
Un recul construit par les contraintes réelles et la recherche de solutions durables.
Cette trajectoire se traduit aujourd'hui par une façon de travailler concrète : comprendre le contexte, structurer sans surcomplexifier, livrer avec exigence et faire progresser les projets comme les équipes.
Dans mon travail, je cherche d'abord à comprendre ce qui doit réellement être résolu : le besoin métier, les contraintes techniques, les usages, les risques et la trajectoire du produit. C'est ce qui permet d'éviter les réponses trop rapides, la complexité inutile ou les choix techniques déconnectés du contexte.
J'accorde beaucoup d'importance à la lisibilité des décisions : une architecture doit être compréhensible, un code doit pouvoir être repris, une solution doit pouvoir évoluer, et une équipe doit pouvoir comprendre pourquoi un choix a été fait.
Cette approche se retrouve autant dans mes missions en entreprise que dans mes projets indépendants : produits SaaS, outils internes, bases techniques réutilisables, contribution open source, qualité logicielle, CI/CD, documentation et amélioration continue.
Je préfère construire des outils utiles et durables plutôt que multiplier les effets techniques sans valeur réelle. Une bonne solution doit être compréhensible, exploitable et capable d'évoluer avec les besoins.
Un projet, une opportunité ou simplement envie d'échanger ?