Analyse Strategique : AWS vs Azure pour CLS

Document : Aide a la decision — Architecture cloud et developpement applicatif
Auteur : Christophe Kersuzan — Digital Manager — DSI CLS
Date : Avril 2026  |  Classification : Interne  |  Public : Direction IT / Architecture

Resume executif

CLS exploite 800 licences M365 avec Entra ID comme socle identitaire. L'equipe IT maitrise AWS (infra, securite), mais les applications metiers recentes (webapps, n8n, IA) se deployent naturellement sur Azure en raison de l'integration native avec M365 et Entra ID. Le cout marginal de ces apps Azure est quasi nul (Static Web App Free, Cosmos DB Free, Container Apps Consumption).

La question n'est pas "AWS ou Azure" mais "quoi va ou". Forcer les applications qui dependent de l'identite M365 sur AWS ajoute de la complexite (SAML/OIDC bridges, federation, latence cross-cloud) sans gain fonctionnel. Inversement, migrer l'infra AWS existante vers Azure serait couteux et inutile.

Recommandation : Azure-first pour les applications metiers et l'IA, AWS pour l'infrastructure existante. Pas de multi-cloud subi — un multi-cloud maitrise avec des regles claires.

1. Comparatif AWS vs Azure dans le contexte CLS

CritereAWSAzure
Integration M365 / Entra ID Possible via federation SAML/OIDC. Chaque app AWS necessite une configuration IAM + un bridge d'identite. Pas d'integration native avec Teams, SharePoint, Outlook. Native. Azure Static Web App + Entra ID = SSO en 0 config. Graph API = acces direct aux emails, calendriers, Teams. Les apps Azure sont des citoyens de premiere classe dans l'ecosysteme M365.
Complexite auth / permissions IAM AWS + Entra ID = deux systemes de permissions a synchroniser. Cognito ou federation SAML obligatoire. Chaque app necessite un travail d'integration specifique. Un seul systeme. Entra ID gere l'identite pour M365 ET les apps Azure. Les Static Web Apps ont un provider Microsoft built-in (0 config). Les conditional access policies s'appliquent uniformement.
Vitesse de developpement (avec IA) AWS Amplify + Lambda = efficace mais necessitent des connaissances IAM. Le developpement assiste par IA produit du code qui s'integre mal avec les permissions AWS (policies JSON complexes). Plus rapide. L'IA genere du HTML/JS + Azure Functions qui se deployent en une commande. L'auth est automatique (SSO built-in). Pas de politique IAM a ecrire. Preuve : 7 apps deployees en 2 jours avec Claude Code.
Maintenabilite / dette technique AWS bien maitrise par l'equipe IT. Outillage Terraform/CDK en place. Risque : le "vibe coding" produit des apps que seul le developpeur comprend. Azure moins maitrise par l'equipe IT. Risque : dependance au developpeur qui a cree les apps. Mitigation : code sur GitHub, architecture simple (HTML/JS + Azure Functions), pas de framework complexe.
Services IA Bedrock : acces a Claude, Llama, Mistral. Bien integre a l'infra AWS. Modeles varies. Mais pas d'integration avec M365 (emails, documents, Teams). Azure AI Foundry : acces a GPT-4o, Grok, Mistral. Integration native avec M365 Copilot. Azure AI Search + SharePoint = RAG sur les documents CLS. Azure Speech = transcription. Document Intelligence = OCR.
Gouvernance / securite Mature (AWS Organizations, SCPs, GuardDuty, CloudTrail). L'equipe IT maitrise. Multi-account = isolation forte. Azure Policy, Defender for Cloud, Log Analytics. Avantage : une seule console pour M365 + apps + IA. Entra ID Conditional Access = MFA + geo-restriction + device compliance unifie.
Cout Infra existante deja payee. Ajout de services = cout incremental. Bedrock = pay-per-use. Apps recentes = quasi 0 EUR (Static Web App Free, Cosmos DB Free, Container Apps Consumption ~20 EUR/mois). Pas de licences supplementaires — M365 est deja paye.

2. Risques d'une strategie "full AWS"

Forcer les apps metiers M365-dependantes sur AWS cree de la complexite sans valeur.
RisqueImpactExemple concret CLS
Bridge d'identite obligatoire Chaque app AWS qui authentifie des utilisateurs CLS necessite un Cognito User Pool + federation SAML avec Entra ID. Maintenance, latence, point de defaillance. La Checklist Salles sur AWS Amplify necessiterait Cognito + SAML federation + IAM policies. Sur Azure SWA = 0 config, SSO natif.
Pas d'acces natif a Graph API Impossible d'envoyer un email via CLSWorkflow@groupcls.com depuis AWS sans un bridge (Lambda → Graph API via token). Sur Azure = appel direct. L'envoi d'email PauseCafe/Checklist utilise Graph API directement depuis Azure Functions. Sur AWS = Lambda + Secrets Manager + federation token.
Duplication des donnees d'identite Les roles metiers (hotesse, admin, EADM) sont dans Entra ID. Les repliquer dans IAM AWS = source de desynchronisation. PauseCafe : roles bases sur l'email Entra ID. Sur AWS = doublon dans Cognito ou DynamoDB.
Cout d'integration avec M365 Teams notifications, SharePoint access, Outlook send — tout necessite un pont cross-cloud. Le Transcript CR genere un email via Graph API. Sur AWS = SES (domaine a configurer) ou pont vers Exchange.
Friction developpement IA Le "vibe coding" avec l'IA genere naturellement du code Azure (CLI, Graph API, SWA). Forcer AWS = retravail manuel de chaque output IA. Claude Code a deploye 7 apps Azure en 2 jours. Le meme travail sur AWS aurait necessite 2 semaines (IAM, Cognito, API Gateway, Lambda, S3, CloudFront).

3. Risques d'une strategie "full Azure"

Migrer l'infra AWS existante vers Azure serait couteux et risque.
RisqueImpactMitigation
Perte de maitrise equipe IT L'equipe IT maitrise AWS. Migrer tout sur Azure = courbe d'apprentissage significative. Ne pas migrer l'infra existante. Azure uniquement pour les nouvelles apps metiers.
Cout de migration Migrer EC2, RDS, S3, Lambda existants vers Azure = 6-12 mois de projet, risque de regression. Pas de migration. Cohabitation AWS (infra) + Azure (apps M365).
Vendor lock-in Azure Les apps utilisant Graph API, Entra ID, Cosmos DB sont liees a Azure. Acceptable : ces apps SONT des extensions de M365. Le lock-in est le meme que celui des 800 licences M365.
Gouvernance multi-cloud Deux consoles, deux systemes de facturation, deux equipes de monitoring. Regles claires : AWS = infra/compute, Azure = apps M365/IA. Pas de chevauchement.

4. Architecture cible pragmatique

ComposantCloudJustification
Infrastructure existante
(EC2, RDS, S3, VPC, monitoring)
AWSDeja en place, maitrise, pas de raison de migrer. L'equipe IT continue de gerer.
Applications metiers web
(Checklist, PauseCafe, Flotte Mobile, dashboards)
AzureSSO Entra ID natif, 0 EUR (SWA Free), deploiement en minutes. Dependance directe a M365.
n8n (orchestration workflows)AzureContainer Apps, recoit des webhooks Internet (Zoho), appelle Graph API pour emails. Sur AWS = Cognito + API Gateway + ECS + pas d'integration M365.
PostgreSQL (donnees metier)AzureFlexible Server dans le meme VNet que les apps Azure. 13 EUR/mois. Sur AWS = RDS + VPN cross-cloud pour les apps Azure.
IA — Apps metiers
(OCR, transcription, generation CR, RAG)
AzureAzure AI Foundry = meme tenant que M365. Azure Speech = transcription. Document Intelligence = OCR. Integration Copilot Studio possible.
IA — Workloads data/ML
(training, batch processing, pipelines)
AWSSi l'equipe IT a deja des pipelines SageMaker/Bedrock, les garder sur AWS. Pas de raison de migrer.
EmailAzureGraph API via M365. CLSWorkflow@groupcls.com = BAL partagee existante. Zero cout, zero config SMTP.
Identite / SSO / MFAAzureEntra ID EST l'autorite d'identite. Les apps Azure l'utilisent nativement. Les apps AWS doivent s'y federer.
Monitoring / SecuriteLes deuxAWS : CloudTrail + GuardDuty pour l'infra. Azure : Defender + Log Analytics pour les apps M365. Une vue unifiee est possible via Sentinel (Azure).

Regle de decision simple

Si l'application a besoin de l'identite d'un utilisateur @groupcls.com → Azure.
Si l'application est de l'infrastructure pure (compute, storage, network) → AWS.
Si l'application utilise l'IA pour des interactions utilisateur (chat, email, OCR) → Azure.
Si l'application utilise l'IA pour du traitement batch/data → la ou les donnees sont deja.

5. L'impact du developpement assiste par IA ("vibe coding")

Ce facteur est souvent sous-estime dans les analyses d'architecture. Voici la realite observee :

AspectAvec AzureAvec AWS
Deploiement d'une webapp avec auth 1 commande : az staticwebapp create + SSO automatique. L'IA genere le code, on deploie. 5 etapes : S3 + CloudFront + Cognito + API Gateway + Lambda. L'IA genere le code mais l'integration IAM est manuelle.
Envoi d'email corporate 1 appel Graph API (3 lignes). L'IA le genere correctement a chaque fois. SES (configuration domaine + verification) ou bridge vers Exchange (federation token). L'IA ne genere pas les policies IAM correctement.
Productivite observee 7 apps en 2 jours (Checklist, PauseCafe, Flotte Mobile, VMS Dashboard, Hub, Transcript CR, ETL). Inclut auth, email, PostgreSQL, dashboards. Estimation : 2-3 semaines pour le meme perimetre (IAM, Cognito, API Gateway, CloudFront, Lambda, RDS, SES).
Risque de dette technique Faible : HTML/JS + Azure Functions = stack simple. N'importe quel dev web peut reprendre. Moyen : les policies IAM generees par IA sont souvent trop permissives ou incorrectes. Risque securite.
Le "vibe coding" n'est pas un argument technique — c'est un multiplicateur de productivite. Dans un contexte M365, l'IA genere du code Azure qui fonctionne immediatement (SSO, Graph API, SWA). Le meme code sur AWS necessite un travail d'adaptation significatif pour l'authentification et les permissions.

6. Recommandation

Azure-first pour les applications metiers. AWS pour l'infrastructure existante.

Concretement :

Ce n'est pas du multi-cloud subi. C'est une repartition rationnelle : chaque cloud fait ce pour quoi il est le meilleur. Azure = extension de M365. AWS = infrastructure compute.

Le risque reel n'est pas d'utiliser Azure a cote d'AWS.
Le risque reel est de forcer des applications M365-dependantes sur AWS et de payer en complexite, en temps, et en securite ce qu'Azure offre nativement et gratuitement.

7. Cas concret : VMS Indonesie — la frontiere AWS/Azure

Le projet VMS Indonesie (PTCLS) illustre parfaitement pourquoi les applications metiers CLS ont besoin d'Azure et non d'AWS. C'est un projet qui se situe a la frontiere des deux environnements et qui pointe vers le besoin de middleware/orchestrateur central evoque par Sylvain Leduc.

7.1 Le probleme initial

CLS Indonesia gere ~4000 commandes VMS via un fichier Excel SharePoint de 110 colonnes, maintenu manuellement par 3 personnes. Les donnees transitent entre Zoho Creator (formulaires terrain), des documents papier (KTP, NPWP, SIPI), des emails, et l'Excel.

7.2 La solution deployee (en production)

ComposantServiceCloudPourquoi ce choix
Formulaire terrainZoho CreatorSaaSDeja en place, utilise par les BD indonesiens
OCR documentsGemini (Google)SaaSMeilleur OCR pour les documents indonesiens
Orchestrationn8n (Container Apps)AzureRecoit les webhooks Zoho, orchestre OCR + SQL + notifications
Base de donneesPostgreSQL FlexibleAzure9 tables, 20K+ lignes, vues SQL, jointures — sur le meme serveur que les autres apps
DashboardStatic Web AppAzure3748 commandes, filtres, edition inline, export CSV/Excel, auth SSO @groupcls.com
NotificationsGraph API (M365)AzureEmail CLSWorkflow@groupcls.com a chaque nouvelle commande

7.3 Pourquoi pas sur AWS ?

BesoinSur Azure (actuel)Sur AWS (hypothetique)
Recevoir un webhook Zoho n8n Container Apps (URL publique, 0 config) API Gateway + Lambda + IAM policy + deploi CloudFormation
Dashboard avec auth @groupcls.com Static Web App + SSO built-in (0 config) S3 + CloudFront + Cognito + SAML federation + API Gateway
Envoyer un email CLSWorkflow@ Graph API (3 lignes de code) SES (config domaine + verification) ou bridge Exchange
Editer une commande depuis le dashboard Azure Function → PostgreSQL (meme reseau) Lambda → RDS (VPC peering si cross-cloud) ou DynamoDB (pas de SQL)
Temps de developpement 1 journee (migration homelab → Azure) Estime 1-2 semaines (IAM, Cognito, API Gateway, Lambda, RDS, CloudFront)

7.4 Ce que ce projet demontre

VMS Indonesie est exactement le type de projet que Sylvain decrit : automatisation E2E, orchestration entre systemes (Zoho → OCR → SQL → Dashboard → Email), avec des donnees qui transitent entre un SaaS externe (Zoho) et l'ecosysteme M365 (identite, email, dashboard).

Ce projet pointe vers le besoin de "middleware/datalake central" evoque dans le mail. n8n sur Azure joue ce role d'orchestrateur : il recoit de n'importe quelle source (webhook, formulaire, API), transforme, stocke dans PostgreSQL, et distribue vers les systemes cibles (email, dashboard, notifications).

Sur AWS, ce meme orchestrateur necessiterait Step Functions + Lambda + API Gateway + Cognito + SES — plus complexe, plus cher, et deconnecte de M365.

7.5 Le pattern replicable

L'architecture VMS Indonesie est un blueprint pour les futurs projets mentionnes par Sylvain :

Projet a venirPoint d'entreeOrchestrateurSortie
RockFleet France
(800 balises peche, declaratif automatique)
Shopify / Middleware Galadreamn8n AzuremyData API + Dashboard + Email CLSWorkflow
Automatisation inter-systemes
(Zoho ↔ Jira ↔ M365)
Webhooks multi-sourcesn8n AzurePostgreSQL central + Dashboards SWA + Notifications Graph
Plateforme middleware/datalakee-Commerce, Zoho Forms, APIsn8n Azure + PostgreSQLSystemes cibles (CRM, ERP, BI, email)
n8n sur Azure EST le "middleware central" que Sylvain cherche. Il est deja en production avec VMS Indonesie. Le deployer pour RockFleet et les autres projets est une question de jours, pas de mois. Et il coute 20 EUR/mois — pas un projet d'infrastructure a 6 chiffres.

Annexe : Applications CLS deployees sur Azure (avril 2026)

ApplicationService AzureCout/moisEquivalent AWSCout AWS estime
Hub CLS DigitalStatic Web App Free0 EURS3 + CloudFront + Cognito~5 EUR
Checklist SallesSWA Free + Cosmos DB Free0 EURS3 + CF + Cognito + DynamoDB + Lambda~10 EUR
PauseCafeSWA Free + Cosmos DB Free0 EURS3 + CF + Cognito + DynamoDB + Lambda + SES~15 EUR
Flotte MobileSWA Free + PostgreSQL Azure0 EUR (PG partage)S3 + CF + Cognito + RDS + Lambda~20 EUR
VMS DashboardSWA Free + PostgreSQL Azure0 EUR (PG partage)S3 + CF + Cognito + RDS + Lambda~20 EUR
Transcript CRSWA Free + AI Foundry~2 EUR (tokens IA)S3 + CF + Cognito + Lambda + Bedrock + SES~15 EUR
n8n + PostgreSQLContainer Apps + PG Flexible~20 EURECS Fargate + RDS~40 EUR
Total Azure~22 EURTotal AWS equivalent~125 EUR
Economie mensuelle : ~100 EUR/mois. Mais le vrai gain n'est pas financier — c'est le temps de developpement (7 apps en 2 jours vs 2-3 semaines) et la complexite evitee (0 config IAM/Cognito/SAML).
CLS — Collecte Localisation Satellites — Document interne — Avril 2026