Plateforme web multi-AZ à haute disponibilité pour Volkswagen Group

Contexte

Pour les plateformes GENWIN Web Platform et SA Platform de Volkswagen Group (Inventiv IT, 2025 – 2026, Paris), j’ai pris en charge l’architecture et le déploiement d’une plateforme web hautement disponible sur une infrastructure AWS multi-AZ définie en code. J’ai conçu l’application selon la Clean Architecture, accompagné les équipes sur le TDD, la qualité et la CI/CD, et contribué au cadrage fonctionnel, à la documentation d’architecture (le DAT) et au suivi des sprints Agile avec les équipes métier.

Problème

Une plateforme web utilisée par des équipes métier ne peut pas se permettre de tomber quand un seul composant défaille. La disponibilité doit être conçue dès le niveau de l’infrastructure, et rester reproductible : un environnement qui ne peut pas être reconstruit depuis du code dérive avec le temps, et la dérive est une cause fréquente de pannes.

Décisions d’architecture

Une architecture multi-AZ pour la disponibilité

La plateforme est conçue comme une architecture haute disponibilité multi-AZ sur AWS, qui répartit l’application sur plusieurs zones de disponibilité afin que la perte d’une zone ne fasse pas tomber la plateforme. L’architecture garantit une disponibilité de 99,9 %.

Compromis : fonctionner sur plus d’une zone coûte plus cher et demande un travail de conception sur l’état, la répartition de charge et le basculement. En échange, la plateforme tolère la panne d’une zone.

L’infrastructure as code

L’infrastructure est définie en code (IaC) : chaque environnement peut être relu, versionné et recréé à la demande.

Compromis : l’infrastructure as code exige de la discipline. Les modifications manuelles dans la console créent de la dérive, le code doit donc être le seul chemin de changement.

La Clean Architecture pour l’application

L’application suit la Clean Architecture : les règles métier sont au centre et ne dépendent ni des frameworks ni de l’infrastructure.

Compromis : il y a plus de couches et de frontières que dans une application en couches simple. En contrepartie, on gagne en testabilité et on peut changer de framework ou d’infrastructure sans réécrire la logique métier.

Des pratiques d’ingénierie : TDD, qualité et CI/CD

J’ai accompagné les équipes sur le TDD, la qualité et la CI/CD, pour que la fiabilité conçue dans l’infrastructure soit prolongée par la fiabilité du code et de sa livraison.

Compromis : l’accompagnement prend du temps sur le développement de fonctionnalités à court terme. Il se rembourse par moins de régressions et des livraisons plus sûres.

La documentation et la livraison

Le cadrage fonctionnel, la documentation d’architecture (le DAT) et le suivi des sprints Agile avec les équipes métier ont permis de garder les décisions par écrit et alignées sur les besoins du métier.

Compromis : une documentation n’est utile que tant qu’elle est à jour. Un DAT concis, maintenu au plus près du travail, vaut mieux qu’un long document qui devient obsolète.

Résultats

La plateforme repose sur une architecture AWS multi-AZ qui garantit une disponibilité de 99,9 %, définie en code et documentée dans un DAT, avec des équipes qui travaillent selon des pratiques TDD et CI/CD.