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.

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 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. Le développement principal a été co-tenu avec Thomas C. sur la v2, dans une équipe resserrée de 4 développeurs actifs où j'étais auteur principal de la v1 et du Supplier BO. 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, 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.

Quand j'ai pris la responsabilité du périmètre ESB du Groupe Pichet en 2021, la plateforme middleware orchestrait déjà 50+ flux distincts entre 20+ applications métier critiques : ERP comptable, logiciel de comptabilité, trésorerie, PMS hôtelier, CRM, PIM, DAM, marketing automation, gestion des identités, SIRH et gestion de flotte. Une panne ESB bloquait les écritures comptables, les prélèvements étudiants, les leads CRM, les mises à jour de prix sur les sites - chaque flux portait un processus métier critique sur un groupe de 1 400 salariés.

J'ai posé une architecture middleware structurée par domaine métier (Finance, Hôtellerie, RH, Patrimoine) plutôt que par application source, pour que chaque direction puisse lire la cartographie de ses propres flux. Côté observabilité, j'ai cadré le passage de SOFT Monitor à un pipeline ELK Stack (Elasticsearch + Logstash + Kibana) avec MongoDB Atlas pour la persistance. Côté qualité, j'ai installé une chaîne CI/CD GitLab avec critères d'arrêt explicites et des runbooks par flux (DAA, DAT, DEX, DFX). Pour la modernisation, j'ai conduit l'audit iPaaS en évaluant Middleway SAS et RS2I/TIBCO Cloud Integration, et cadré la roadmap 2022-2024 avec les 8 directions métier impliquées et un budget annuel d'environ 370 K€.

100+ flux en production maintenus avec un taux d'incident à un chiffre, survie à 4 changements de DSI consécutifs, et la roadmap 2022-2024 validée chaque année. Les 2 377 alertes mensuelles SOFT Monitor ramenées à un signal exploitable, le Bus Factor passé de 1 à 4 sur les flux critiques, et le framework de post-mortem est devenu le standard du département pour tous les incidents critiques.

Ce projet m'a confirmé qu'une architecture d'intégration vit ou meurt sur la lisibilité des frontières inter-systèmes, pas sur la sophistication du middleware. Les contrats de flux explicites et la documentation par direction métier sont ce qui m'a permis de transmettre le périmètre sans rupture - c'est le pattern que je rejoue aujourd'hui chez ACCENSEO sur tout audit CTO advisory qui touche à l'intégration multi-systèmes.