An Azure service that provides an event-driven serverless compute platform.
hi GROUPE PRIMA S.A & thx for sharing urs issue here at Q&A portal,
Votre projet est très ambitieux et dépasse largement le périmètre d'Azure Functions. Avec plus de 5 500 fichiers, 420 entités, 2 100 fonctions backend et 110 agents IA, il s'agit d'un véritable programme de transformation d'entreprise plutôt que d'un simple projet de migration. Je vous conseillerais de commencer par définir une architecture cible plutôt que de reconstruire l'application à l'identique. Une migration « bloc par bloc » risque de reproduire la complexité actuelle au lieu de la simplifier. Pour une solution de type ERP moderne, je partirais sur une Azure Landing Zone avec des abonnements distincts pour les environnements de développement, de test et de production. J'intégrerais dès le départ Microsoft Entra ID, Azure Policy, Defender for Cloud, Key Vault, Private Link, un monitoring centralisé (Azure Monitor / Log Analytics) ainsi que de l'Infrastructure as Code (Bicep ou Terraform). Cela constituera une base solide pour une plateforme souveraine et gouvernée.
Côté données, Azure SQL Database est généralement le meilleur choix pour un ERP multi-filiales, car il offre des transactions ACID, Row Level Security (RLS), des performances élevées et une gouvernance mature. Avant de migrer les 420 entités, je recommanderais d'identifier les domaines fonctionnels (bounded contexts), de revoir les modèles de données et de supprimer les redondances éventuelles plutôt que de tout recopier tel quel. Pour les traitements métier, une combinaison d'App Service ou Azure Container Apps pour les API, Durable Functions pour les orchestrations longues, Service Bus et Event Grid pour les traitements asynchrones, ainsi qu'API Management pour l'exposition sécurisée des API constitue une architecture éprouvée. Les orchestrateurs métier (Order to Cash, Procure to Pay, Hire to Retire, etc.) devraient rester pilotés par la logique applicative, tandis que les agents IA viendraient assister les processus sans être responsables des transactions critiques.
Pour la partie IA, Azure OpenAI et les services d'agents de Microsoft constituent une bonne base. Je recommande toutefois de séparer clairement les responsabilités : les agents IA doivent assister les utilisateurs (analyse, génération de contenu, recommandations), alors que les validations métier, les règles de gouvernance et les écritures en base doivent rester sous le contrôle des services applicatifs.
Compte tenu de l'ampleur du projet, je vous suggère également de réaliser un atelier d'architecture avec un Cloud Solution Architect Microsoft ou un partenaire Azure avant de commencer le développement. Cela permettra de définir une architecture de référence, un plan de migration progressif et les objectifs de disponibilité (RTO/RPO), de sécurité et de conformité (RGPD, ISO 27001, SOC 2).
Enfin, je commencerais par reconstruire un premier domaine métier complet (par exemple Order to Cash) avant de généraliser le modèle à l'ensemble de PrimaOps. Cette approche permet de valider les choix d'architecture, de sécurité et d'exploitation avant d'engager la migration des centaines d'entités restantes.
rgds,
Alex
&
If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal
and at my blog https://ctrlaltdel.blog/