La question « AWS ou Azure ? » arrive souvent trop tôt, posée comme un choix de principe. Elle se tranche mieux à partir de ce que vous avez déjà : vos applications, votre annuaire, vos licences, les compétences de vos équipes et l'endroit où vos données doivent rester. Les deux plateformes couvrent les mêmes besoins d'entreprise. Ce qui les sépare, pour une plateforme infogérée, c'est ce qu'elles coûtent à exploiter dans votre contexte précis.
Cet article donne les critères que nous utilisons pour orienter ce choix, puis ce qu'un contrat d'infogérance doit couvrir, quel que soit le cloud retenu.
Le critère qui pèse le plus : ce qui existe déjà
L'annuaire. Si votre entreprise vit déjà dans un annuaire Microsoft, Azure part avec une longueur d'avance : la gestion des accès se pense depuis Entra ID et se propage aux abonnements. Sur AWS, le même annuaire se raccorde sans difficulté à la gestion centralisée des identités, mais c'est un raccordement à concevoir et à maintenir, pas un point de départ.
Les licences. Les environnements Windows Server et SQL Server portent une dimension licence absente des environnements Linux. Les droits que vous détenez déjà, et la manière dont ils se transfèrent dans le cloud, peuvent peser plus lourd dans la facture que l'écart de prix entre deux machines virtuelles. C'est un point à chiffrer avant de choisir, avec vos contrats sous les yeux.
Les applications. Une application .NET liée à l'écosystème Microsoft, ou un parc hybride qui doit continuer à dialoguer avec des serveurs sur site, s'exploite naturellement sur Azure. Une application construite autour de services managés, d'architectures sans serveur ou d'une diffusion mondiale trouve sur AWS le catalogue le plus large. Ce sont des tendances, pas des règles : la plupart des applications d'entreprise tournent très bien sur l'une comme sur l'autre.
Les critères qui départagent ensuite
La localisation des données. Les deux fournisseurs disposent de régions en France et en Suisse. La question utile n'est pas « où sont les datacenters ? » mais « quels services dont j'ai besoin sont disponibles dans la région qui m'est imposée ? ». La réponse varie d'un service à l'autre, et se vérifie service par service.
Les compétences de vos équipes. Une plateforme infogérée n'efface pas votre équipe interne : elle continue de déployer, de développer et de décider. Choisir le cloud que vos développeurs connaissent déjà réduit le coût caché de chaque évolution.
La structure de facturation. Sur Azure, le découpage en abonnements et groupes de ressources conditionne la lisibilité des coûts. Sur AWS, c'est l'organisation des comptes. Dans les deux cas, un découpage fait à la hâte au démarrage rend le suivi des coûts difficile ensuite, et le corriger impose de déplacer des ressources. Ce critère ne départage pas les deux clouds ; il dit qu'il faut le traiter dès le premier jour.
La relation commerciale. Selon votre taille, votre accord existant avec Microsoft ou vos engagements de consommation chez AWS peuvent orienter le choix. Faites-les entrer dans le calcul, sans les laisser décider seuls.
Ce qui ne devrait pas décider
- Un comparatif de prix unitaires. Le prix d'une machine virtuelle compte moins que le dimensionnement, l'extinction des environnements hors production et les licences.
- Le multicloud par principe. Exploiter deux clouds double l'outillage, les compétences et les procédures à maintenir. Il se justifie par une contrainte réelle, réglementaire, contractuelle ou technique, pas par prudence générale.
- La préférence du prestataire. Un infogérant qui ne sait exploiter qu'un cloud vous recommandera celui-là. Demandez-lui sur quels critères il vous orienterait vers l'autre.
Ce que le contrat doit couvrir, quel que soit le cloud
Le choix du cloud fixe l'outillage ; le contrat fixe la qualité de l'exploitation. Les points suivants valent sur AWS comme sur Azure.
- Le périmètre exact. Ce qui est exploité par le prestataire, ce qui reste chez vous, et qui décide en cas de doute. Un périmètre flou produit des incidents que personne ne prend.
- La supervision et l'astreinte. Les horaires couverts, ce qui déclenche une intervention, et le délai de réponse attendu. Si une infogérance 24/7 est nécessaire, elle doit être écrite comme telle.
- Les sauvegardes et leur restauration. Une sauvegarde qui n'a jamais été restaurée est une hypothèse. Le contrat doit prévoir des tests de restauration réguliers.
- Les changements. Comment une mise à jour ou une montée de version est préparée, validée et, si besoin, annulée.
- Le suivi des coûts. Un rapport régulier, lisible par une direction, et des actions de réduction intégrées à l'exploitation plutôt que facturées à part après la dérive.
- La réversibilité. La documentation, les accès et le code d'infrastructure vous appartiennent, et la sortie du contrat est décrite avant d'en avoir besoin.
Partez de l'inventaire : applications, dépendances, annuaire, licences, contraintes de localisation. Pour chaque application, notez ce qui la rattache à l'un ou l'autre cloud. Si une majorité penche nettement d'un côté, la décision est prise. Si l'inventaire ne tranche pas, choisissez le cloud que vos équipes maîtrisent, et refusez de payer pour en exploiter deux sans raison.
C'est précisément ce que fait notre audit cloud, gratuit et sans engagement : il compare les options sur votre cas réel, avant que le choix ne vous engage pour des années. Et si la question de fond est de savoir ce que vous paierez chaque mois, notre page sur le coût de l'infogérance détaille les modes de facturation.