Technologies cloud : des socles maîtrisés, de la machine virtuelle au conteneur
Microsoft Azure, Amazon Web Services, cloud privé, Kubernetes, Docker, Infrastructure as Code : les plateformes que nous concevons, déployons et opérons — et les critères qui décident où va chaque charge de travail.
Ni dogme du tout-public, ni dogme du multi-cloud
Deux discours simplistes dominent le marché : « tout dans le cloud public » et « le multi-cloud partout ». Nous ne souscrivons ni à l’un ni à l’autre. Notre pratique : chaque charge de travail va sur le socle qui lui convient — public pour l’élasticité et les services managés, privé pour certaines économies à charge stable et pour la souveraineté, hybride quand la réalité l’impose. Le multi-cloud se justifie par des besoins réels (résilience réglementée, couverture géographique), pas par principe : le pratiquer sans raison, c’est payer deux courbes d’apprentissage pour diluer deux expertises. Et une constante non négociable : tout socle est décrit en Infrastructure as Code — c’est ce qui rend les environnements reproductibles, auditables et réversibles.
Les briques de nos socles cloud
Ce qui fait un socle d’entreprise, au-delà des services
Un compte cloud n’est pas un socle. Nous industrialisons : des landing zones qui posent d’emblée l’identité, le réseau, la sécurité et la gouvernance des coûts ; des pipelines GitOps où chaque changement d’infrastructure est une revue de code ; des politiques automatisées (conformité, étiquetage, budgets) qui préviennent les dérives au lieu de les constater ; et l’observabilité native (cohérence avec la page Technologies ITSM et supervision). C’est ce cadre qui permet d’aller vite ensuite — les équipes projet consomment des fondations sûres au lieu de réinventer chaque fois la sécurité.
Quel socle pour quelle charge de travail ?
Application à trafic variable ou saisonnier
Cloud public (Azure/AWS) — critères clés : élasticité réelle, coût à l’usage, services managés
Charge stable et prévisible, forte volumétrie
Cloud privé ou hybride — critères clés : coût complet à 3-5 ans, maîtrise physique
Données soumises à localisation ou souveraineté
Cloud privé, hébergement national ou périmètre dédié — critères clés : cadre réglementaire, traçabilité
Applications conteneurisées multiples
Kubernetes (managé de préférence) — critères clés : volume d’applications, compétences d’exploitation
Application unique ou simple
Conteneurs sans orchestrateur, ou services managés simples — critère clé : ne pas sur-outiller
Traitement proche du terrain (usine, site distant)
Edge + synchronisation cloud — critères clés : latence, connectivité, autonomie locale
Règle transverse : le coût complet se calcule sur la durée (infrastructure, licences, compétences, sortie) — jamais sur le prix d’appel.
Où s’exécutent vos charges — et sous quel droit
La localisation n’est pas un détail technique : régions cloud utilisées et localisation effective des données (y compris sauvegardes et métadonnées), cadre juridique applicable aux fournisseurs, options de chiffrement avec clés maîtrisées par le client, offres d’hébergement national ou de cloud de confiance selon les pays. Nous documentons ces choix noir sur blanc au cadrage : la classification des données décide de l’architecture — en cohérence avec le service Cybersécurité et les exigences sectorielles des pages Solutions (e-Gov, santé, finance).
Questions fréquentes
Celui qui correspond à votre existant et à vos charges : Azure s’impose souvent dans les organisations Microsoft 365 (identité et gouvernance unifiées) ; AWS excelle par la profondeur de son catalogue. Nous pratiquons les deux — l’arbitrage se fait sur vos critères, pas sur nos préférences.
Parlons de votre projet
Un besoin de conseil, un projet à cadrer, une solution à intégrer ou des équipes à former : nos experts vous répondent et construisent avec vous la réponse adaptée à votre contexte.