Ma Façon de Travailler
Plus de trois décennies d'expérience ont forgé une méthodologie claire : conception orientée objectif, architecture propre et qualité durable. Ce sont les principes qui guident chaque ligne de code que j'écris.
Pour des raisons de confidentialité, je ne peux pas partager le code de la plupart de mes projets en production. Cependant, je vous invite à explorer mes dépôts publics où je partage des outils open-source, des expériences et des contributions à la communauté des développeurs.
Voir sur GitHubAvant d'écrire une ligne, je définis ce que signifie le succès — objectifs business, risques, utilisateurs, métriques — et je traduis cela en langage de domaine : concepts, invariants, processus, exceptions et règles. Pour les domaines complexes, j'applique le DDD pour que le modèle devienne un outil de communication et de décision, pas un diagramme décoratif.
L'UX ne consiste pas à rendre les choses jolies — c'est réduire la charge cognitive, anticiper les erreurs, guider les décisions et aider les utilisateurs à avancer avec confiance. Je conçois les flux, états, états vides, permissions, latences, erreurs et happy paths avec la même rigueur qu'une API. L'expérience doit être prévisible, accessible et cohérente sur tous les écrans.
L'interface est construite comme un système : composants réutilisables, tokens, variantes, états et composition hiérarchique. Avec Atomic Design je maintiens l'ordre, l'évolutivité et la cohérence visuelle/fonctionnelle (atomes → molécules → organismes → templates → pages). Cela réduit le coût du changement et évite le spaghetti UI.
Séparer les responsabilités n'est pas un dogme — c'est de la vélocité durable. Je définis des limites (domaine, application, infrastructure, présentation), des contrats stables et des dépendances correctes. Quand c'est approprié, j'applique l'architecture hexagonale pour découpler le cœur des bases de données, de la messagerie, des fournisseurs externes et des frameworks.
J'utilise des principes comme SOLID et des patterns (Repository, Strategy, Factory, Adapter, Facade, CQRS quand nécessaire) pour gérer la complexité réelle : testabilité, extension sûre, réduction du couplage et compréhension du code. Les patterns sont des outils ; l'objectif est que le système soit lisible, prévisible et facile à faire évoluer.
La sécurité n'est pas ajoutée à la fin. J'en fais une exigence architecturale : authentification, autorisation, isolation, traçabilité, chiffrement, gestion des secrets, rate limiting, hardening et validation aux limites. Je m'appuie sur des standards et des checklists — par exemple, les vérifications type ASVS et l'approche Secure-by-Design d'OWASP.
Je n'optimise pas par intuition — je mesure, profile et remesure. Je conçois avec une performance extrême en tête quand nécessaire : mise en cache, files d'attente et traitement asynchrone, vraie pagination, backpressure, utilisation correcte des index, minimisation des charges utiles et stratégies de cohérence. L'objectif : expérience fluide, stabilité et coût maîtrisé sous charge.
En frontend et backend, l'état est modélisé explicitement — pas caché dans des effets de bord. Je différencie état local vs. état applicatif, définis des sources de vérité et utilise des Facades pour isoler les frameworks et empêcher l'UI de connaître les détails internes. Résultat : moins de bugs fantômes, plus de prévisibilité, refactors moins coûteux.
La qualité ne se négocie pas — elle s'automatise. J'applique la pyramide de tests (unitaires, intégration, e2e quand ça apporte de la valeur), contrats stables, linters, CI et une vraie definition of done. J'inclus aussi l'observabilité : logs utiles, métriques, traces, corrélation et alertes. Et je documente le minimum essentiel, mais toujours actionnable et maintenable : ADRs, diagrammes, READMEs opérationnels, guides de déploiement et runbooks.
Je construis verticalement : petites pièces complètes qui arrivent en production avec confiance. Je travaille avec cadence, feedback et adaptation, aligné sur les principes Scrum : itération, inspection et adaptation pour contrôler le risque et maximiser la valeur. L'architecture accompagne la roadmap et évolue sans bloquer l'équipe.
Notes sur les logiciels d'entreprise, les agents IA et la pratique d'ingénierie derrière.
1 min de lecture
L'inspection robotisée collecte plus de données, et plus précises, que jamais. Mais les collecter n'est que la moitié du problème. L'autre moitié est d'en faire une base de décision.
2 min de lecture
Je recommande rarement un logiciel. Voici une exception : il résout un problème que je vois partout dans les PME et, plus grave encore, dans certaines très grandes entreprises.
3 min de lecture
« L'IA va nous prendre notre travail. » « L'IA est consciente. » « L'AGI est arrivée. » Vraiment ? Après 30 ans en génie logiciel, le hype nous échappe.
J'aimerais en savoir plus sur votre projet et explorer ensemble comment je peux vous aider à le concrétiser avec la qualité et le professionnalisme qu'il mérite.
Me Contacter
