Zona est une plateforme de distribution de logiciels dédiée au domaine de l'audio.
Elle regroupe différents types de ressources (logiciels, SDK, frameworks, bibliothèques, moteurs audio, plugins, contenus...) au sein d'un catalogue unifié.
La première version publique se concentre sur la consultation du catalogue. L'architecture est cependant pensée dès le départ pour accompagner les futures évolutions de la plateforme (administration, organisations, comptes utilisateurs, fonctionnalités communautaires...) sans remettre en question les fondations existantes.

Mon rôle ne se limite pas au développement.
J'interviens sur le cadrage du projet, la documentation, le découpage des versions et la transformation des besoins fonctionnels en architecture logicielle.
Les orientations fonctionnelles sont définies en amont ; mon rôle consiste ensuite à les analyser, les structurer et concevoir les solutions techniques permettant de les concrétiser.

L’analyse du modèle produit a abouti à un dictionnaire de données et à un modèle relationnel PostgreSQL. L'étude des dépendances entre les données a ensuite permis de découper l'administration en plusieurs modules cohérents et de définir les responsabilités des endpoints, les validations métier et les transactions.
Les premières données de production ont constitué, quant à elles, une véritable épreuve pour le modèle. Elles ont révélé plusieurs cas d'usage qui ont conduit à revoir certaines décisions de conception afin de repartir sur des bases plus solides avant la mise en ligne.

J’ai mis en place une stratégie DTO distincte selon les usages.
Les DTO de lecture sont volontairement larges afin de couvrir rapidement le modèle de données. À l'inverse, les DTO de création et de mise à jour sont plus stricts et ne sont créés que lorsqu'un véritable besoin métier existe.
L'architecture repose sur plusieurs niveaux de services. Certains sont directement exposés par l'API, tandis que d'autres restent internes ou interviennent uniquement dans le cadre d'une orchestration. Cette approche permet de répartir les responsabilités entre plusieurs services spécialisés plutôt que de concentrer toute la logique métier dans un seul.
Les traitements impliquant plusieurs entités s'appuient sur des transactions afin de garantir la cohérence des données. Lorsque cela est pertinent, des optimisations sont également mises en œuvre afin de limiter les traitements inutiles et d'améliorer les performances, notamment grâce à des mécanismes de cache (Redis), de batch ou de request coalescing.
La plateforme est pensée pour accueillir, à terme, des organisations souhaitant publier leurs propres logiciels et ressources.
Le processus de publication repose sur deux niveaux complémentaires. Une validation métier automatique vérifie d'abord que chaque produit respecte les prérequis attendus selon sa nature (logiciel, application web, contenu, etc.). Une fois ces conditions remplies, une modération humaine contrôle les sources officielles ainsi que les fichiers distribués avant leur publication.
Cette séparation permet une publication progressive des contenus. Un produit peut être rendu public dès que les éléments indispensables sont validés, tandis que certaines ressources, comme les artifacts hébergés par la plateforme, suivent leur propre processus de vérification avant d'être publiées.
Le frontend repose sur Next.js et React. L'interface a été pensée selon une approche desktop-first. Bien qu'entièrement responsive, elle s'adresse avant tout à une utilisation sur ordinateur, plus adaptée au type de contenus consultés et au public visé.

Les contrats OpenAPI définissent l'interface entre le backend et le frontend. Les clients TypeScript sont générés automatiquement afin de garantir la cohérence des échanges avec l'API tout au long du développement.
La logique métier est volontairement centralisée dans le backend afin de limiter les traitements côté client. Le frontend se concentre principalement sur la présentation des données, la navigation et les interactions utilisateur.
Le déploiement est réalisé sur un VPS Linux. L'infrastructure est composée de plusieurs services Docker indépendants : frontend, API, PostgreSQL, Redis et reverse proxy.
Les mises en production sont automatisées avec GitHub Actions. Chaque déploiement construit les images Docker, les publie sur GitHub Container Registry puis met à jour les services en production. Les images étant versionnées, un rollback reste possible à tout moment.
L'infrastructure comprend également des environnements séparés, des healthchecks, des sauvegardes des données, des procédures de restauration et une configuration HTTPS avec Caddy.
En l'absence d'interface d'administration, les premières données sont créées via les routes de l'API exposées par Swagger. Elles passent ainsi par l'ensemble des validations métier, des transactions et des traitements prévus par le backend.
Une fois ces données validées, la base est exportée (schéma et data), puis réimportée lors du déploiement de nouveaux environnements.
Une partie importante du travail porte aussi sur la documentation technique.
Au fil du développement, j'ai défini des conventions concernant les DTO, les contrôleurs, les services, la sécurité ainsi que différents choix d'architecture. J'ai également mis en place plusieurs inventaires recensant les services, leurs méthodes, leurs responsabilités ainsi que les différents DTO.

La première version publique étant désormais déployée, le développement se poursuit autour de plusieurs axes. Les prochaines étapes concernent principalement l'espace d'administration, la gestion des organisations, les comptes utilisateurs ainsi que les premières fonctionnalités communautaires.
Zona est pensé comme un projet évolutif, dont l'architecture a été conçue pour accompagner ces futures évolutions sans remettre en question ses fondations.