Ingénieur produit. Je conçois et je livre des systèmes de bout en bout, et ce que je construis n’a pas de secteur : l’exploitation d’une entreprise, une élection, un produit culturel, une plateforme d’apprentissage. Ce qui m’intéresse se trouve là où une décision produit et une décision technique se révèlent être la même décision.
Sur l’année écoulée : une plateforme SaaS multi-tenant en production chez de nombreux clients, une plateforme civique, quatorze implémentations de référence pour ceux qui apprennent à livrer, et la direction technique d’un produit culturel.
Une plateforme de compétences construite en solo sur une architecture polyglotte, entourée d’une gouvernance publique. Bêta ouverte en janvier 2027.
Architecte principal d’une plateforme ERP, CRM et RH multi-tenant, en production chez de nombreux clients.
Une plateforme de tech civique déployée pendant la campagne présidentielle béninoise de 2026, conçue et livrée de bout en bout.
Direction technique d’une plateforme culturelle et touristique : une identité numérique qui remplace le billet physique pour les événements, la restauration et le tourisme. Bêta privée, lancement public au quatrième trimestre 2026.
Six étapes, du premier cadrage jusqu’à l’exploitation. Elles s’adaptent à votre produit, quels que soient son domaine et sa taille.
J’identifie qui a le problème, ce qu’il lui coûte aujourd’hui, et le chiffre qui dira qu’il est réglé. Je note aussi ce qui restera hors du périmètre. Ce cadrage écrit sert d’arbitre pour la suite : chaque demande qui arrive en cours de route se mesure à lui, au lieu de relancer un débat.
Je liste le volume et le profil des usages, la disponibilité attendue, la nature des données et les règles qui s’y appliquent, les systèmes déjà en place, la taille de l’équipe, le budget et l’échéance. Je sépare ensuite ce qui est négociable de ce qui ne l’est pas, et je marque chaque choix restant comme réversible ou non. Les contraintes fermes écartent la majorité des architectures d’emblée ; le marquage fixe le temps qu’on accorde à chaque arbitrage.
Je conçois deux ou trois solutions viables et je les compare sur les critères posés à la première étape : coût, délai, risque, effet sur l’existant. Je rédige ensuite la décision retenue, avec les options écartées et le motif de chacune. Le document tient en une page et vit dans le dépôt : l’équipe peut trancher les cas voisins sans moi et retrouver le raisonnement quand la question revient.
Je définis la hiérarchie, la typographie, le rythme et la densité en même temps que le modèle de données, et je commence par les états : vide, chargement, erreur, droits insuffisants, données partielles. Ces états exigent des champs et des règles qu’un écran nominal ne fait jamais apparaître, donc les traiter d’abord évite de reprendre le modèle après coup.
Je repère l’hypothèse la plus risquée, celle dont l’invalidation obligerait à tout revoir, et je construis une tranche fine qui la traverse de bout en bout, jusqu’en production. Elle sort avant les fonctionnalités faciles. Si l’hypothèse tombe, elle tombe pendant qu’il reste du budget et du délai pour changer de trajectoire.
J’instrumente dès la première mise en ligne et je relis les chiffres contre l’objectif fixé à la première étape, à intervalle défini. Je livre en même temps les journaux, les alertes et les procédures de reprise, et je forme quelqu’un d’autre à les utiliser. Cela permet de corriger sur des mesures plutôt que sur des impressions, et de passer la main sans que le service en pâtisse.
39 poussées et 22 pull requests fusionnées sur 5 dépôts depuis le 1 septembre.
Je conçois et je construis des systèmes de production, de l’architecture jusqu’à l’exploitation.
Ce qui m’attire est la conception et la résolution de problèmes complexes : le moment où un système a trop de pièces pour tenir dans une seule tête, et où il faut trouver le découpage qui le rend de nouveau lisible.
Ce que je fais tient donc rarement dans une seule case. Sur la même année : un ERP multi-tenant qui fait tourner l’exploitation de nombreuses entreprises, une plateforme civique livrée dans une fenêtre qui ne se décalait pas, une application mobile pensée pour fonctionner sans réseau, et une plateforme d’apprentissage que je porte seul.
Je travaille sur les deux versants à la fois. La même journée peut aller d’un bus d’événements à une échelle typographique, et je ne considère pas que ce soient deux métiers. Une hiérarchie visuelle et un modèle de données décrivent le même produit, à deux endroits différents. Quand ils sont décidés séparément, cela se voit.
Je cherche un poste, et je reste ouvert aux collaborations et aux missions. Ce que je décline, en revanche : un produit dont personne ne saura dire s’il a marché, un travail sans accès à ceux qui s’en servent, et un périmètre qui s’élargit pendant que la date, elle, ne bouge pas.
En dehors, j’écris, je lis beaucoup, je joue du piano et je fais du sport. Je construis des mondes et je joue aux échecs, ce qui explique deux des entrées de cette archive.
Lire le parcours complet
Concevoir un produit, reprendre un système qui a grossi trop vite, ou porter la technique d’une équipe qui n’en a pas.
Écrivez-moi avec le problème plutôt qu’avec la solution attendue : ce qui ne fonctionne pas aujourd’hui, pour qui, et à quelle échéance. Une page suffit, et un appel de trente minutes suffit souvent à savoir si cela a du sens.
Je réponds sous deux jours ouvrés, et je le dis quand ce n’est pas pour moi.
Tous les moyens de me joindre