Architecture Logicielle & Système
Onze ans à concevoir des architectures de production, du monolithe PHP aux plateformes SaaS B2B cloud-native. Master Expert en Ingénierie du Logiciel, postes de Lead Symfony et Lead Magento, aujourd'hui CTO. Application de SOLID, DDD et patterns event-driven.
Chaque segment représente une période (parcours ou réalisation) où la compétence a été mobilisée. La couleur et la taille du point final reflètent le niveau atteint sur cette période.
Ma définition
L'architecture logicielle et système, dans ma pratique, c'est l'art de choisir les bonnes frontières entre sous-systèmes, les bons contrats entre eux et la bonne forme opérationnelle. C'est là que SOLID, les design patterns, le REST API design et le DDD rencontrent les réalités du cloud, de l'observabilité et des topologies d'équipe. Une bonne architecture rend la croissance d'une codebase linéaire au lieu d'exponentielle ; une mauvaise architecture transforme chaque nouvelle feature en dette structurelle.
Je pratique l'architecture sur 4 échelles différentes selon le contexte. Module : SOLID, hexagonal, domain-driven design. Système : REST + async + event-driven, contrats inter-services, gestion d'erreurs. Plateforme : monorepo Turborepo, packages partagés, environnements Terraform multi-tenants. Écosystème : intégration B2B, fournisseurs externes, contrats versionnés. 11 ans de pratique continue, du monolithe PHP (Joomla, Zend, Symfony 2-7, Magento 1-2) au SaaS moderne TypeScript (Next.js 16, Prisma, Payload CMS), avec 28 références dans le portfolio (Top 4 en fréquence brute) et le Master ESIEA Expert en Ingénierie du Logiciel comme socle théorique.
En 2026, l'architecture entre dans une nouvelle phase : les SaaS verticaux régulés (clinique, défense, énergie, comptabilité) reposent sur des architectures AI-native où les workflows sont exprimés en actions et contraintes plutôt qu'en écrans. Le moat n'est plus dans la stack mais dans la donnée gouvernée + les workflows embarqués + les intégrations profondes. ce que Rob Saker analyse précisément dans AI is Eating Enterprise SaaS. L'architecture devient le pari technique le plus défendable d'un CTO : feature-driven, observabilité par défaut, contrats inter-services traçables, et frontières module/cœur survivantes aux upgrades. Maddyness pose le même diagnostic côté francophone dans Tendances IA 2026 : les 4 mutations qui changent tout, où interface, donnée et souveraineté redéfinissent le modèle SaaS.
Mes éléments de preuve
Anecdote 1 : Architecture feature-driven du SaaS comptable ACCENSEO
Quand j'ai démarré le SaaS comptable d'ACCENSEO début 2025, je savais que je serais seul à coder pendant 14 mois sur plus de 200 K lignes de code, avec un domaine régulé qui interdisait les raccourcis (PCG, CGI, e-facturation 2026-2027). Le piège classique sur ce genre de codebase, c'est de partir sur un découpage par couche technique (controllers / services / repositories) qui devient ingérable une fois passé les 30 modules. Il me fallait une architecture qui tienne 2 ans sans dette structurelle.
J'ai posé une architecture feature-driven dès le premier commit : 42 modules autonomes dans `src/features/` (banque, facturation, comptabilité, fiscalité, paie, IA assistant, reporting, juridique, OCR...), chacun avec ses propres composants, hooks, services, models et types. `src/app/` ne contient que le routing Next.js, jamais de logique métier. Pour la donnée, 91 modèles Prisma organisés autour des entités domain (pas autour des tables SQL), avec 63 enums typés, et 6 rôles différenciés contrôlés par Better Auth. Côté contrats inter-features, j'ai exposé un `index.ts` par feature qui définit la surface publique consommable - tout le reste reste interne au module.
382 routes API générées, nouvelles features ajoutées en jours plutôt qu'en semaines, et les frontières module/feature ont survécu à plusieurs refactorings majeurs (passage à Next.js 16, migration React 19, ajout de l'extension Chrome Teledec) sans avoir à toucher la structure d'ensemble.
Ce que j'ai validé sur ce projet, c'est qu'une bonne architecture rend la croissance linéaire au lieu d'exponentielle : à la 30ème feature, j'allais aussi vite qu'à la 5ème. C'est exactement la promesse que je dois pouvoir tenir sur le prochain rôle CTO scale-up - et je l'ai désormais éprouvée en solo, ce qui rend la transposition à une équipe beaucoup plus crédible.
Anecdote 2 : Réécriture v2 Rebirth de l'extranet European Sourcing
L'Extranet European Sourcing était le back-office central du plus grand salon en ligne européen d'objets publicitaires - 15 sous-projets interconnectés, base MySQL partagée de 15 Go sur 97 tables, 7 langues, 800 fournisseurs, et certains catalogues comme SOL's portaient 15 000 variations pour un seul produit. La v1, écrite en 2008-2013 sur un framework MVC PHP maison, ne tenait plus la cadence : chaque ajout métier coûtait de plus en plus cher.
Le 14 mars 2016, on a démarré la v2 "Rebirth" sous Symfony 3.1, avec PostgreSQL à la place de MySQL, RabbitMQ pour la messagerie asynchrone, et surtout 2 bundles partagés - ESCoreBundle (entités, auth, système de fichiers) et ESSourcingBundle (logique métier) - pour mutualiser ce que les 15 sous-projets dupliquaient. Pour industrialiser les écrans d'administration, j'ai bâti un système de listes génériques (EntityList) avec colonnes configurables, actions en masse, actions par ligne et pagination. Côté formulaires, j'ai développé plus de 70 Form Types Symfony couvrant produits, variantes, marquages statiques et dynamiques avec profils, attributs simples / multiples / groupes, catégories, mots-clés, labels avec synonymes, abonnements et workflows d'import-export.
La v2 a tenu plus de 5 ans en production (2016-2021), elle alimentait 37 connecteurs d'import automatisés (Pixika, Makito, Midocean, BIC, Paul Stricker, Clipper, TopTex, Cybernecard...), et la pattern library posée à cette occasion a été reprise par les apps en aval sans qu'on ait à réécrire l'architecture une seule fois.
Ce projet m'a appris à mutualiser sans coupler : les bundles partagés sont restés stables pendant que chaque sous-projet évoluait à son rythme. C'est le pattern que je rejoue aujourd'hui sur le monorepo Turborepo d'ACCENSEO et que j'imposerai sur la prochaine plateforme scale-up - le coût d'une bonne factorisation est faible, le coût d'une mauvaise est toxique sur 10 ans.
Anecdote 3 : Architecture Magento Enterprise multi-store chez Fleurance Nature
À la refonte de Fleurance Nature en 2017 chez Smile, j'ai trouvé une plateforme Magento Enterprise Edition 1.10 chargée à bloc : 1 040 fichiers PHP modifiés, 60 modules custom accumulés, 3 storefronts (Fleurance Nature France, International, Mincifine) à servir avec une matrice tarifaire EAV partagée entre 4 groupes clients (anonymes, général, abonnés fidèles, comités d'entreprise) - soit 12 combinaisons tarifaires actives. Les spécifications elles-mêmes ont traversé 7 versions en 2 mois (de 30 à 50 pages) au fil de la découverte des règles métier encapsulées dans le code legacy.
J'ai refusé la tentation du big-bang. J'ai posé un découpage clair backend/frontend sur les 3 storefronts, backporté ElasticSearch sur Magento EE 1.10 pour remplacer Solr (autocomplete, navigation à facettes, catégories virtuelles), et imposé sur chaque module custom le respect des patterns Observer/Strategy pour rester PCI-aware sans toucher au cœur Magento. Pour sécuriser les déploiements, j'ai mis en place une suite de régression complète sur les 3 sites avant chaque release, parce que toucher un module impactait potentiellement les 12 matrices tarifaires.
La plateforme refondue a tenu plus de 5 ans en production sans nouvelle réécriture architecturale, zéro incident sécurité majeur pendant et après la migration, et le cache Varnish est resté opérationnel tout au long du process de refonte malgré la sensibilité du site live.
Ce que j'ai compris sur ce projet, c'est que les frontières module/cœur sont ce qui fait survivre une codebase aux changements de prestataire et aux montées de version - pas la qualité du code lui-même. Sur chaque audit CTO advisory que j'anime aujourd'hui chez ACCENSEO, c'est la première chose que je regarde dans la codebase du client.
Mon autocritique
Niveau Expert (5/5). 11 ans de pratique architecturale, du monolithe PHP au SaaS moderne TypeScript en passant par les plateformes d'intégration ESB. Master ESIEA comme socle théorique, 28 références portfolio comme volume de pratique.
Couverture confirmée sur les 4 échelles :
- module : SOLID, DDD, hexagonal
- système : REST, async, event-driven, CQRS partiel
- plateforme : monorepo Turborepo, packages partagés, Terraform multi-env
- écosystème : intégration B2B
Ce qui reste à muscler : event sourcing pur et service mesh à grande échelle.
Cœur de ma crédibilité de CTO. Sans architecture solide, le produit ne tient pas la croissance, l'équipe ne scale pas et la dette devient existentielle en 18 mois. C'est aussi ce qui distingue le CTO opérationnel du CTO advisory : savoir traduire une intention business en frontières techniques, contrats inter-équipes et plan de migration concret.
Première mobilisation significative : CTO · Founder · directeur technique. Progression jusqu'à CTO · Founder · directeur technique, avec un niveau actuel de 5/5 (Expert). Cette continuité témoigne d'une acquisition solide, éprouvée par la répétition et la diversité des contextes.
Mes principes d'arbitrage
À moi-même : *écrire un ADR pour chaque décision irréversible* et tenir un diagramme système vivant. Aux autres : préférer la simplicité jusqu'à preuve du contraire, refuser le pattern par autorité (« on fait comme ça parce que Netflix ») et exiger le critère métier qui le justifie. Toujours simuler le coût opérationnel d'un découpage avant de le valider, *un microservice, c'est aussi un pipeline, un dashboard et une astreinte*.
Mon évolution dans cette compétence
L'architecture est ce qui transforme une intuition CTO en plateforme défendable sur 3 ans. Dans le projet à 24 mois, elle rend possibles les arbitrages *build vs buy* lourds, les migrations majeures sans interruption produit et la discipline d'équipe (revue de code, ADRs, contrats inter-services). Sans elle, l'organisation peut grandir mais la dette finit par tuer la cadence.
L'objectif est l'extension event-driven et service mesh : pouvoir dessiner et implémenter une bascule monolithe → modules autonomes sans interruption produit, et défendre cette trajectoire devant un board en langage business (risque, cycle, OPEX). Maintenir la maîtrise Expert sans dégradation reste la base. l'effort se porte sur les frontières où je n'ai pas encore opéré en production.
Lecture continue : Martin Kleppmann *Designing Data-Intensive Applications* (relu chaque année), Neal Ford / Mark Richards *Software Architecture: The Hard Parts*, Sam Newman *Building Microservices*. Pratique quotidienne sur les codebases ACCENSEO. Master Expert en Ingénierie du Logiciel actif jusqu'en 2026.
Conférence QCon Paris 2026, possible programme Domain-Driven Design avancé (Vlad Khononov ou Eric Evans masterclass) en 2027. Certification AWS Solutions Architect Professional envisagée selon le contexte CTO cible.
Mes routines d'architecte
- production systématique d'un pack ADR + diagramme C4 à chaque nouveau projet
- veille hebdo sur les blogs d'architecture (ThoughtWorks Tech Radar, AWS Architecture Blog, martinfowler.com)
- étude trimestrielle d'un système open-source de référence, PostgreSQL internals, Linkerd, Temporal