AWS, Azure, Google Cloud : trois catalogues, trois factures, trois façons de se perdre. Une PME n'a pas besoin des trois. Elle a besoin d'un propriétaire, d'identités propres, et d'un motif autre que « tout le monde y est ». Nous travaillons les trois, plus OpenStack. Le TJM est 1000 HT, même chiffre en euros et en francs. Le conseil, c'est d'abord d'éviter d'empiler.
Ce qui tranche vraiment, pour une PME
Vous êtes déjà dans Microsoft 365. Exchange, Teams, postes joints au tenant. Azure et Entra ID collent à ce que vous avez. Apprendre un deuxième nuage pour trois machines, c'est un coût humain, pas seulement une ligne AWS.
Votre équipe parle déjà AWS (souvent un prestataire, un DSI de passage, un projet data). Rester sur Amazon évite de tout retraduire. IAM, VPC, sauvegardes : les fondations avant Lambda « parce que c'est serverless ».
Vous avez un besoin data / ML / GKE clairement identifié, pas un slide. GCP se discute. Un projet Google orphelin, lui, se discute aussi : c'est souvent là que la facture part, comme en FinOps.
Vous ne pouvez pas, ou ne voulez pas, le cloud public. Résidence, métier réglementé, déjà du fer. OpenStack ou de l'infogérance de serveurs dans le Genevois. Ce n'est pas « ringard ». C'est un choix.
Le dirigeant achète un risque de dépendance et une facture variable. Le profil technique achète des API, des régions, des certifications. Nous traduisons : une région eu-west ou Zurich, pas un débat de salon.
Ce que nous refusons de faire
Poser un EKS, un AKS et un GKE « pour être multi-cloud ». Le multi-cloud subi (un SaaS ici, une VM là) existe déjà. Le multi-cloud voulu, sans équipe, c'est trois fois les oublis (disques, IP, recette allumée). Voir facture cloud.
Nous posons les fondations : comptes, droits, réseau, sauvegardes, étiquettes. Ensuite seulement les services métier. EKS ou une VM bien sauvée : le besoin décide, pas le catalogue de l'année.
Les missions se font en France et en Suisse. L'infogérance du parc de bureaux, elle, reste le contrat local. Le cloud n'a pas remplacé le PC de la compta.
Grille de décision, sans tableau magique
- Où sont déjà les identités et les mails ?
- Qui saura exploiter la plateforme dans un an (vous, nous, un salarié) ?
- Y a-t-il une contrainte de résidence écrite ?
- Quel est le premier workload, pas les vingt suivants ?
Si la réponse à 2 est « personne », le problème n'est pas AWS vs Azure. C'est le run. La maintenance cloud existe pour ça, après une période d'observation. Pas pour apprendre le métier le jour de la prod.
Comment nous procédons
Cadrage court, accès lecture aux comptes existants s'il y en a, recommandation une plateforme cible, fondations, puis les workloads. Documentation des droits. Alerte de budget dès le début, pas à la troisième facture.
Une PME de vingt personnes n'a pas un département cloud. Elle a un DSI à temps partiel, ou nous. Le bon choix, c'est celui qu'une personne peut encore expliquer dans un an : « nos VMs sont là, nos sauvegardes là, nos comptes sont ceux-là ». Trois catalogues, zéro schéma, c'est une facture et une panne sans mode d'emploi. Un logo suffit. Encore faut-il le tenir.
Si on vous pousse vers un logo sans ces quatre questions, demandez un second avis. Nous vous disons si le choix tient, ou s'il faut d'abord ranger les identités.