Un cabinet d'une trentaine de personnes installé à Annemasse reçoit deux propositions en trois semaines. La première recommande AWS pour héberger son application de gestion, la seconde recommande Azure pour la même application, avec des arguments techniques que le dirigeant n'a aucun moyen d'arbitrer. Il nous appelle pour savoir laquelle des deux plateformes est la meilleure.
La question n'a pas de réponse dans l'absolu, et c'est plutôt une bonne nouvelle. Les trois grands fournisseurs de cloud public font tourner des machines virtuelles, du stockage, des bases de données et des réseaux privés avec des niveaux de service tout à fait comparables pour les besoins d'une PME. Ce qui sépare un choix tenable d'un choix regretté ne se trouve pas dans le catalogue : cela se trouve dans votre entreprise, dans les compétences dont vous disposez réellement, dans les outils que vous utilisez déjà et dans ce que vos contrats clients vous imposent d'écrire.
Précisons de quoi nous parlons. Un fournisseur de cloud public vend de l'infrastructure à la demande, facturée à l'usage : vous payez le temps pendant lequel une machine tourne, le stockage qu'elle occupe et le trafic qu'elle génère. Ce n'est ni un hébergement de site vitrine, ni une messagerie d'entreprise. Un site WordPress de vingt pages n'a aucun besoin d'un compte chez AWS, Azure ou Google Cloud, car un hébergement mutualisé fait le travail et coûte moins cher à exploiter. Un parc de dix postes, une imprimante et un NAS relèvent de l'infogérance à partir de 120 HT / mois, pas d'une plateforme cloud. Nos missions de conception, de migration et de reprise en main cloud se facturent 1000 HT / jour, à distance, pour des clients de France et de Suisse.
Ce que votre écosystème actuel dit déjà du fournisseur le plus raisonnable
Si vos identités et votre messagerie vivent dans Microsoft 365, une partie du travail d'intégration est déjà faite du côté d'Azure. Vos comptes utilisateurs se trouvent dans Entra ID, l'annuaire que nous décrivons dans notre article sur l'annuaire d'identités derrière Microsoft 365, et ces mêmes identités peuvent servir à administrer un abonnement d'infrastructure. Vous évitez ainsi un deuxième annuaire, un deuxième jeu de mots de passe et une deuxième procédure à dérouler le jour du départ d'un salarié. Ce n'est pas un argument technique décisif, c'est une économie de temps humain qui pèse lourd dans une entreprise sans service informatique.
Si votre application métier est développée par un prestataire qui travaille sur AWS depuis des années, ses scripts de déploiement, sa gestion des droits et ses habitudes de sauvegarde sont écrits pour AWS. Le faire changer de plateforme revient à lui demander de réapprendre une partie de son métier à vos frais. Nous préférons alors consolider ce qui existe sur AWS plutôt que de tout retraduire pour un gain théorique.
Si votre besoin réel porte sur l'exploitation de données ou sur un entrepôt analytique, et si ce besoin est écrit dans un document plutôt qu'évoqué en réunion, Google Cloud mérite d'être comparé sur ce terrain précis. La question cesse alors de porter sur le fournisseur : c'est le service dont vous avez besoin qui entraîne le fournisseur.
Les compétences disponibles décident plus sûrement que le catalogue
La question la plus utile que nous posons en cadrage est rarement technique : qui exploitera cette plateforme dans un an ? Un fournisseur cloud n'est pas un produit que l'on installe et que l'on oublie. Il faut appliquer les correctifs, surveiller les sauvegardes, relire la facture chaque mois, retirer les droits d'une personne qui part. Si personne dans l'entreprise ne tiendra ce rôle, le débat entre AWS et Azure devient secondaire : le vrai sujet est l'exploitation, et elle doit être confiée à quelqu'un. C'est l'objet de notre maintenance cloud, que nous mettons en place après une période d'observation.
Nous avons repris des environnements où plus personne n'osait redémarrer une machine, faute de savoir ce qui en dépendait. Le bon fournisseur est celui dont une personne de votre entreprise pourra encore expliquer l'organisation dans un an : voici nos serveurs, voici nos sauvegardes, voici les accès.
La localisation des données se vérifie avant la signature, pas après
Certaines PME ont une contrainte réelle de localisation, inscrite dans un contrat client, dans un cahier des charges d'appel d'offres ou dans une politique de groupe. D'autres ont une préférence, exprimée oralement, qui n'a jamais été écrite. Les deux situations sont légitimes, mais elles n'entraînent pas les mêmes conséquences techniques, et il faut savoir dans laquelle vous vous trouvez avant de choisir une plateforme.
Sur ce sujet, deux précautions valent mieux qu'une conviction. D'abord, la disponibilité d'une région et celle d'un service dans cette région se vérifient au moment du projet, dans la documentation du fournisseur : les catalogues évoluent, et tous les services ne sont pas ouverts dans toutes les régions. Ensuite, la qualification juridique de votre obligation relève d'un conseil spécialisé, pas de votre prestataire informatique. Notre rôle consiste à traduire une exigence écrite en architecture vérifiable, comme nous l'expliquons dans notre article sur le choix d'une région cloud.
Le multi-cloud non décidé multiplie les mêmes oublis
Beaucoup de PME sont déjà multi-cloud sans l'avoir choisi : la messagerie est chez un éditeur, une application métier tourne chez un hébergeur, un développeur a créé un compte ailleurs pour une maquette. Cette dispersion subie se range, et ce rangement fait souvent partie de nos premières missions.
Le multi-cloud volontaire est une autre affaire. Répartir délibérément une infrastructure sur deux ou trois fournisseurs suppose de maîtriser autant de modèles de droits, de modèles de réseau et de factures. Sans équipe dédiée, vous obtenez surtout les mêmes oublis en plusieurs exemplaires : des disques détachés que personne ne supprime, des adresses réservées et jamais utilisées, un environnement de recette allumé depuis huit mois. Ces oublis se lisent sur la facture avant de se lire dans un schéma, et nous expliquons comment les traquer dans notre article sur la facture cloud qui augmente.
Quand la bonne réponse n'est pas un fournisseur public
Le cloud public n'est pas la seule option, et nous ne le présentons pas comme telle. Nous concevons et exploitons également des plateformes OpenStack chez un hébergeur partenaire ou sur votre matériel, ainsi que des serveurs virtualisés classiques. Cette voie se discute quand vous voulez garder la main sur l'hyperviseur, quand une exigence de localisation stricte est écrite, ou quand vos équipes connaissent déjà ce standard, sujet développé dans notre article sur les données en Suisse et le cloud privé.
Un dernier critère est souvent oublié au moment du choix, et c'est celui qui coûte le plus cher ensuite : la réversibilité. Une machine virtuelle standard, des données exportables et des déploiements décrits dans des fichiers se déplacent. Une architecture bâtie entièrement sur des services propres à un fournisseur ne se déplace qu'en la réécrivant. Nous ne rejetons pas les services managés, mais nous vous disons lesquels vous engagent.
Notre cadrage avant de recommander une plateforme
Nous commençons par un inventaire de ce qui existe déjà, avec un accès en lecture aux comptes en place quand il y en a : identités, applications, sauvegardes et obligations contractuelles écrites. Nous identifions ensuite le premier workload à traiter, un seul, car une plateforme se juge sur une mise en production réelle et non sur une feuille de route à trois ans.
Nous recommandons alors une seule plateforme cible, et nous posons les fondations avant tout service métier : un compte au nom de l'entreprise, une gestion des droits nominative, un réseau fermé par défaut, des sauvegardes séparées de la production, des étiquettes de coût et une alerte de budget dès le premier mois. Nous documentons les accès pour que le dispositif survive à un changement d'interlocuteur, chez vous comme chez nous. Ces missions se déroulent à distance dans toute la France et en Suisse tandis que l'infogérance du parc de bureaux reste un contrat local du Bassin Genevois.
Si un prestataire vous pousse vers un fournisseur sans avoir posé ces questions, demandez-lui qui exploitera la plateforme et ce que votre contrat client exige. Vous pouvez aussi nous soumettre le projet pour un second avis : nous vous dirons si le choix tient, ou s'il faut d'abord ranger les identités et les accès existants.