Architecture de GC.Platform
Documentation technique pour les équipes architecture et développement côté client. Vous y trouverez sur quelle pile technologique fonctionne GC.Platform, comment elle est organisée, comment elle s'intègre et comment elle scale.
L'architecture en une image
GC.Platform est une architecture microservices, multi-cloud, hébergée intégralement dans l'Union européenne. Chaque module fonctionne comme un service indépendant, avec son propre cycle de déploiement et de mise à l'échelle. La vue d'ensemble des composants principaux :
Le schéma montre les principaux composants qui assurent le flux depuis l'utilisateur final jusqu'aux données produit. Les backends des modules (GC.Catalog, GC.Platform API, ERP, CART, AUTH, DASHBOARD, Messaging, AI.Assistant) fonctionnent indépendamment, communiquant via API et événements. Chacun a son propre App Service Plan et se met à l'échelle individuellement.
Nous hébergeons dans trois régions UE, sur deux clouds
GC.Platform fonctionne en mode multi-cloud avec trois régions cloud dans l'Union européenne : Microsoft Azure en Pologne, Microsoft Azure en Allemagne et Oracle Cloud en Allemagne. Chaque couche du système se trouve dans le cloud où elle fonctionne le mieux : données transactionnelles et applications sur Azure, données produit (couche MDM) sur Oracle Cloud.
Le trafic des clients de votre plateforme est géré par Cloudflare — la couche edge qui protège contre les attaques DDoS, filtre le trafic dans le WAF et accélère les contenus statiques dans le monde entier. Sous Cloudflare fonctionne Azure Front Door — le load balancer multi-régions de Microsoft, qui dirige le trafic vers l'instance applicative la plus proche disponible et le redirige automatiquement en cas d'indisponibilité d'un composant.
Chaque microservice de GC.Platform fonctionne sur au moins deux instances applicatives dans Azure App Service, sur un plan dédié. Les données transactionnelles dans Azure SQL fonctionnent en mode Zone Availability — résilient aux pannes d'une seule zone de disponibilité. C'est une approche standard pour une architecture enterprise, mais souvent ignorée par les plateformes e-commerce qui se présentent comme « cloud ».
Ce qu'il y a sous le capot
Nous choisissons les technologies de manière réfléchie — pour la tâche concrète, pas pour la mode. La pile de GC.Platform combine des solutions matures et éprouvées avec des outils modernes là où ils apportent un avantage réel.
Backend
- •.NET (versions LTS actuelles) — services backend (GC.Platform API, ERP, CART, AUTH, DASHBOARD, Messaging, AI.Assistant)
- •PHP — server-side rendering pour GC.Catalog, optimisé pour le SEO et le temps de premier rendu des catalogues avec de grandes bases SKU
- •Azure App Service — runtime applicatif pour tous les backends
Frontend
- •GC.Catalog — JavaScript natif ES6+ sans framework, SCSS pour les styles, Vite comme bundler. Décision délibérée : pour les catalogues automobiles, une couche d'interactivité légère côté navigateur donne de meilleurs résultats SEO et performances qu'un framework SPA lourd
- •GC.Dashboard — React, pour l'interface administrative avancée
- •AI.Assistant — React, composant de chat intégré dans GC.Catalog
Données
- •Azure SQL Pool — données transactionnelles de GC.CART, GC.Messaging, GC.AUTH (chaque module avec une instance SQL séparée)
- •Oracle Cloud — couche GC.MDM (Master Data Management), où la structure et la performance des requêtes produits sont essentielles
- •Azure Cognitive Search — recherche dans le catalogue produit, indexation et facettes
- •Azure Cache for Redis — couche de cache pour les données fréquemment interrogées
Communication entre services
- •Azure Service Bus — files et topics pour les événements métier (commandes, changements d'état, intégrations)
- •Azure Storage Queues — files pour les tâches en arrière-plan et le traitement asynchrone
Infrastructure edge
- •Cloudflare — WAF, protection anti-DDoS, accélération CDN
- •Azure Front Door — load balancing multi-régions
Sécurité et identité
- •Microsoft Entra ID — gestion d'identité pour l'équipe maintenant la plateforme, MFA imposée
- •Azure Key Vault — secrets, clés cryptographiques, certificats
- •Azure Log Analytics, Application Insights — logs, monitoring, audit
Chaque module indépendant
GC.Platform n'est pas un monolithe. Chaque module — GC.CATALOG, GC.CART, GC.AUTH, GC.MDM, GC.CMS, GC.DASHBOARD, AI.Assistant — est un service backend séparé, sur son propre App Service Plan, avec ses propres instances et sa propre responsabilité. La communication entre les modules se fait via API REST et via événements sur Azure Service Bus.
Conséquence pratique : quand le trafic sur le catalogue augmente pendant la saison de changement de pneus, nous scalons GC.CATALOG. Quand le nombre de commandes augmente, nous scalons GC.CART. Quand AI.Assistant gère plus de conversations, nous scalons ce service précis. Sans coupure, sans interruption, sans effet domino sur les autres parties de la plateforme.
Chaque module a son propre pipeline CI/CD dans Azure DevOps et peut être déployé indépendamment des autres. Cela signifie que la mise à jour d'un élément ne nécessite pas de redéployer toute la plateforme.
API ouverte pour l'intégration ERP
GC.Platform expose des API selon une architecture REST. Tous les services backend (GC.Platform API, ERP API, CART API, AUTH API, DASHBOARD API, Messaging API, AI.Assistant) communiquent selon le même standard — cela simplifie le travail des équipes d'intégration côté client.
Integration API — l'interface dédiée à l'intégration avec les systèmes ERP du client — dispose d'une documentation publique. Le périmètre standard d'intégration couvre l'échange des prix, disponibilités, commandes, factures et routes de transport entre GC.Platform et l'ERP du client. Le périmètre détaillé est défini en phase d'analyse de l'implémentation, en adaptation aux spécificités de l'ERP côté client.
Les autres interfaces — internes entre les modules GC.Platform, frontend entre les applications clientes et le backend, intégration avec les partenaires sectoriels — sont documentées en phase d'implémentation et mises à disposition de votre équipe dans le cadre des travaux d'intégration.
Cycle de vie du système après le déploiement
Chaque déploiement de GC.Platform comprend au moins deux environnements : production et staging. L'environnement staging sert aux tests d'intégration, à la vérification des mises à jour et aux essais de changements de configuration avant leur déploiement en production.
Nous déployons les mises à jour de GC.Platform de manière asynchrone — c'est-à-dire qu'il n'y a pas de « fenêtre de maintenance » rigide à surveiller. Chaque module est mis à jour indépendamment, sans interrompre les autres composants. Dans les cas nécessaires — p. ex. un changement structurel important ou une mise à jour nécessitant une migration de données — nous fixons une fenêtre de maintenance à l'avance, en accord avec votre équipe.
Le déploiement en production est réalisé par notre équipe, via le pipeline CI/CD dans Azure DevOps. Chaque déploiement dispose d'une capacité de rollback automatique — en cas de problème après un déploiement, nous pouvons rapidement revenir à la version précédente, fonctionnelle. Sans reconfiguration manuelle, sans risque d'erreur humaine en situation de stress.
Sécurité au niveau cloud Enterprise
Toute la communication — entre le client et la plateforme et au sein de GC.Platform — s'effectue via TLS 1.2 ou supérieur. Les données dans les bases Azure SQL sont chiffrées par Transparent Data Encryption (TDE), les clés sont stockées dans Azure Key Vault. L'équipe maintenant la plateforme se connecte via Microsoft Entra ID avec authentification multifacteur, chaque opération en production est journalisée et auditable. L'infrastructure sur laquelle fonctionne GC.Platform est certifiée ISO 27001, SOC 1, SOC 2 et SOC 3.
La politique complète de sécurité, de protection des données et RGPD est décrite sur la page Données et sécurité.
Retour à GC.Platform
La description des modules, des scénarios d'utilisation et l'image complète de la plateforme se trouvent sur la page GC.Platform.