La parole est aux speakers : Nicolas Perussel
Jusqu’au mois de mai 2026, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !
La conférence
Evolutionary Architecture : Comment éviter la prochaine "Grande Réécriture""On va tout réécrire, ça prendra 6 mois." Un an plus tard, le projet est abandonné, l'équipe est épuisée, et le code legacy a continué d'évoluer. Cette histoire vous semble familière ? Il existe une meilleure approche. L'Evolutionary Architecture est une discipline qui permet de faire évoluer continuellement votre système sans jamais avoir besoin de tout jeter. L'architecture n'est jamais finie. Les besoins changent, les technologies évoluent, l'équipe grandit. Comment construire une architecture qui s'adapte sans nécessiter de grandes réécritures ? Ce talk explore les Fitness Functions, les Architecture Decision Records (ADR), les tests architecturaux, et les stratégies de migration progressive pour faire évoluer votre code en continu. Ce que nous aborderons :
|
Bordeaux Ynov Campus 22/05/2026 09:20-10:00 |
Comment expliques-tu qu’autant d’entreprises s’essayent quand même à cette réécriture malgré les nombreux témoignages ?
Honnêtement ? Parce que réécrire, c’est excitant. Quand tu te bats tous les jours contre du code spaghetti, « on efface tout et on recommence » c’est le fantasme ultime. C’est beaucoup plus sexy qu’un plan d’évolution progressive sur 18 mois.
Et puis il y a un biais d’optimisme massif. On regarde le legacy et on se dit « c’est pas si compliqué, on peut faire mieux. » Sauf que ce code moche, il a absorbé 5 ans de edge cases, de hotfixes à 23h un vendredi, de logique métier que plus personne ne comprend mais qui tourne. Tout ça, c’est invisible — jusqu’au moment où tu essaies de le reproduire from scratch.
Côté orga, la réécriture se vend mieux. « On refait tout en 6 mois » ça rentre dans un roadmap, ça rassure un board. « On va améliorer en continu pendant 2 ans » c’est un pitch beaucoup plus dur, même si c’est bien plus réaliste. Et avec le turnover, chaque nouveau CTO ou lead pense que « cette fois ce sera différent » parce qu’il n’a tout simplement pas vécu les échecs précédents.
Tu évoques la nécessité de mesurer la qualité architecturale de manière objective. Quelles méthodes ou quels outils utilises-tu pour réaliser cette évaluation ?
Je distingue deux niveaux.
Le premier, c’est les Fitness Functions maison : des tests automatisés dans la CI qui vérifient tes invariants architecturaux. Chez PlayPlay par exemple, on vérifie que l’encoding vidéo reste sous un SLA donné, qu’on ne dépasse pas un seuil de requêtes GCS parallèles (on s’est pris un bel incident avec 1200 requêtes concurrentes qui faisaient tomber Istio…), ou que le naming des services Media reste cohérent. Ce sont des trucs très spécifiques à ton contexte, et c’est justement ça leur force.
Le deuxième niveau, c’est l’outillage PHP classique qu’on sous-exploite souvent : Deptrac pour renforcer les layers et empêcher les violations de dépendances, PHPat pour des règles archi custom, PhpMetrics pour suivre la complexité cyclomatique et le couplage. Et on a un CI-Guard (projet en WIP) qui détecte les anti-patterns de résilience, genre un appel API sans timeout ou sans retry.
Le truc important, c’est de ne pas juste regarder un snapshot « vert/rouge ». Ce qui a de la valeur, c’est de tracker ces métriques dans le temps. Un graphe qui montre l’évolution du couplage sur 6 mois, ça raconte une histoire et c’est ça qui convainc le management que l’investissement continu paie.
Si tu devais mettre ça en place dans un projet legacy, quelles seraient les premières questions que tu te poserais ?
Je me poserais 5 questions, dans cet ordre :
« Qu’est-ce qui fait le plus mal ? »: Pas partir de l’architecture idéale, partir de la douleur quotidienne. C’est le déploiement qui prend 45 minutes ? Les tests qui sont flaky ? Un module que tout le monde a peur de toucher ? C’est ta boussole.
« Où sont les frontières naturelles ? »: Même dans le pire monolithe, il y a des bounded contexts de facto. Les trouver, c’est identifier les endroits où un Strangler Fig est le plus simple à appliquer.
« Qu’est-ce que je ne peux PAS casser ? » : Tes invariants critiques métier. C’est ça tes premières fitness functions. Tu les écris avant de toucher une seule ligne de code.
« Est-ce que j’ai un filet de sécurité ? » : Tests, monitoring, capacité de rollback. Si la réponse est non, c’est le chantier numéro 1, point. Sans filet, toute évolution c’est du YOLO en prod.
« Quelle est la plus petite amélioration qui apporte de la valeur ? » : Résister à la tentation du grand plan. Un endpoint migré, un module découplé, une fitness function ajoutée. C’est d’ailleurs ce que je dis à la fin du talk : dès lundi, crée un dossier docs/adr/, écris une fitness function sur ta métrique la plus critique, et identifie un endpoint legacy à strangler. Rien de plus.
Une conférence présentée par
 Nicolas PERUSSEL |
Passionné par les nouvelles technologies, Nicolas est féru d'architecture logicielle. Sa spécialité : le développement web et les bonnes grosses architectures 😉 « Accro aux technos », il aime se diversifier dans divers domaines pour être toujours plus efficace et compétent. Actuellement, il est en charge de la direction de l'équipe PHP chez ekino (CTO). Architecture, industrialisation, PHP (Symfony / Drupal), encadrement, formation sont ses activités quotidiennes. Vous l'aurez compris, ses domaines de prédilection sont les casse-têtes architecturaux, les motifs de conception et le café ! |