Et si le cloud ne devait pas forcément quitter l’entreprise ?
Le cloud public a profondément changé la manière dont les entreprises conçoivent leur infrastructure informatique.
Plus besoin d’acheter systématiquement des serveurs avant de lancer une nouvelle application. Les ressources peuvent être provisionnées rapidement, les capacités adaptées aux besoins et de nombreux services deviennent accessibles sans administrer directement toute l’infrastructure sous-jacente.
Pourtant, toutes les applications ne peuvent pas être déplacées vers un cloud public.
Certaines données doivent rester dans les locaux de l’entreprise. Certaines applications nécessitent une latence très faible. D’autres dépendent encore de systèmes industriels ou de ressources qui ne peuvent pas être migrés facilement.
Une entreprise peut également vouloir conserver une partie de son infrastructure dans son propre datacenter tout en profitant des outils et services proposés par AWS.
C’est précisément dans cet espace que se positionne AWS Outposts.
Le principe est particulièrement intéressant : AWS étend son infrastructure, ses services, ses API et ses outils directement dans les locaux du client. L’entreprise peut ainsi exécuter certaines applications sur son propre site tout en conservant une expérience proche de celle proposée dans les régions AWS.
Cette approche change la manière de concevoir le cloud hybride.
Il ne s’agit plus simplement de connecter un datacenter à AWS. Il devient possible d’apporter une partie de l’environnement AWS directement là où se trouvent les applications et les données.
Cette évolution est particulièrement pertinente pour les organisations qui cherchent à moderniser leur infrastructure sans abandonner immédiatement leurs ressources locales.
Notre article consacré au cloud hybride en entreprise présentait déjà cette logique de répartition entre infrastructures locales et cloud public. AWS Outposts permet d’aller plus loin en rapprochant physiquement certaines capacités cloud des systèmes qui doivent rester sur site.
Pourquoi toutes les entreprises ne peuvent pas basculer entièrement dans le cloud
Le discours autour du cloud donne parfois l’impression que la migration complète constitue l’étape naturelle de toute transformation numérique.
Dans la réalité, les infrastructures sont beaucoup plus complexes.
Une entreprise industrielle peut posséder des machines qui génèrent des données en continu. Une banque peut devoir conserver certains traitements dans un environnement contrôlé. Un établissement de santé peut manipuler des informations particulièrement sensibles. Une entreprise logistique peut avoir besoin d’exécuter une application au plus près de ses équipements.
Dans ces situations, déplacer toutes les données et toutes les applications vers une région cloud distante peut créer des contraintes importantes.
La première concerne la latence. Lorsqu’une application doit réagir rapidement à un événement local, chaque échange avec une infrastructure distante peut ajouter un délai inutile.
La deuxième concerne la connectivité. Une application critique qui dépend entièrement d’une liaison vers le cloud public doit prendre en compte les éventuelles interruptions de cette connexion.
La troisième concerne la résidence des données. Certaines organisations souhaitent conserver leurs informations dans un environnement physique maîtrisé pour répondre à leurs politiques internes, à leurs contraintes contractuelles ou à des exigences réglementaires.
Enfin, certaines applications anciennes ne sont tout simplement pas conçues pour être déplacées facilement.
La migration vers AWS reste pertinente dans de nombreux cas. NextHope accompagne d’ailleurs les entreprises dans cette transformation, comme nous l’avons expliqué dans notre article consacré à la migration AWS Cloud.
Mais une stratégie cloud mature ne consiste pas nécessairement à tout migrer.
Elle consiste à déterminer où chaque workload doit être exécuté.
AWS Outposts : apporter l’expérience AWS sur site
AWS Outposts répond précisément à cette problématique. Le service permet de déployer une infrastructure AWS dans les locaux de l’entreprise afin d’exécuter certaines applications avec des ressources de calcul et de stockage locales.
L’intérêt ne réside pas uniquement dans la présence physique du matériel.
L’entreprise retrouve également des méthodes de fonctionnement familières aux équipes déjà habituées à AWS. Les applications peuvent utiliser des services compatibles avec l’environnement AWS et être administrées avec les outils et API associés à la plateforme. ([docs.aws.amazon.com](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html))
Cette continuité réduit la rupture entre les environnements.
Une équipe peut par exemple conserver une application critique sur son site tout en utilisant AWS pour d’autres composants. Les ressources locales et les services exécutés dans les régions AWS peuvent alors faire partie d’une même stratégie d’architecture hybride.
Cette approche évite également de considérer le cloud et le datacenter comme deux mondes totalement séparés.
Le datacenter devient une extension de l’environnement cloud.
Cette évolution est particulièrement intéressante pour les entreprises qui souhaitent moderniser progressivement leur système d’information. Elles peuvent conserver certains workloads localement tout en adoptant progressivement les méthodes, outils et services du cloud.
Le vrai avantage : rapprocher le calcul des données
Le cloud public apporte une capacité considérable. Mais certaines applications ont besoin que le calcul soit effectué au plus près des données.
Prenons l’exemple d’une usine connectée.
Des capteurs produisent en permanence des informations sur les machines. Une application d’analyse doit traiter ces données rapidement afin de détecter une anomalie et déclencher une intervention.
Envoyer systématiquement toutes les informations vers une infrastructure distante peut ajouter une latence inutile et augmenter les volumes de données transférés.
Avec une infrastructure AWS déployée sur site, certaines opérations peuvent être exécutées localement. Les données restent proches des applications qui les utilisent et les traitements sensibles à la latence bénéficient d’un environnement plus proche de leur source.
Cette logique rejoint également les besoins de l’intelligence artificielle.
Comme nous l’avons expliqué dans notre article sur les serveurs IA et les GPU en entreprise, certaines charges d’inférence peuvent avoir intérêt à être exécutées localement. Le choix dépend alors du volume de données, de la latence attendue, du niveau de confidentialité et du coût des échanges avec le cloud.
AWS Outposts devient ainsi une pièce possible d’une architecture où chaque workload est placé dans l’environnement le plus pertinent.
AWS Outposts ne signifie pas supprimer le cloud public
L’intérêt d’AWS Outposts apparaît surtout lorsque l’entreprise cesse d’opposer cloud et infrastructure locale.
Un Outpost fonctionne comme une extension d’une région AWS. Les ressources déployées localement peuvent communiquer avec les services disponibles dans la région associée, tout en conservant une proximité physique avec les applications et les données qui doivent rester sur site. ([docs.aws.amazon.com](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html))
Cette architecture permet donc de répartir les workloads selon leurs contraintes.
Une application nécessitant une très faible latence peut être exécutée localement. Une autre application peut continuer à utiliser les services disponibles dans la région AWS. Les équipes disposent ainsi d’un environnement hybride dans lequel chaque workload est placé là où il présente le meilleur compromis entre performance, sécurité, coût et disponibilité.
Cette logique est particulièrement intéressante pour les entreprises qui modernisent progressivement leur système d’information. Elles n’ont pas besoin de choisir entre un datacenter traditionnel et le cloud public. Elles peuvent construire une architecture combinant les deux.
Les applications qui peuvent tirer parti d’Outposts
AWS Outposts n’est pas destiné à tous les workloads. Sa pertinence apparaît surtout lorsque les applications doivent rester proches des systèmes locaux, traiter des données sur site ou répondre à des contraintes de résidence des données.
Les environnements industriels constituent un premier exemple.
Une usine peut utiliser des capteurs, des systèmes de vision et des équipements automatisés qui génèrent des données en continu. Certaines décisions doivent être prises rapidement, sans attendre un aller-retour vers une région cloud distante.
Avec des ressources AWS déployées localement, les traitements sensibles à la latence peuvent rester au plus près des équipements. AWS cite notamment les environnements industriels, les sites de santé et les points de vente parmi les scénarios adaptés à ce type d’architecture.
Le secteur financier constitue un autre cas d’usage. Certaines applications doivent traiter des informations localement ou répondre à des exigences de résidence des données. AWS présente notamment les Outposts racks comme une solution permettant de conserver le contrôle de l’emplacement d’exécution des applications et des données tout en utilisant une infrastructure cohérente avec AWS.
Les entreprises disposant de nombreux sites peuvent également rechercher cette proximité. Une agence, un centre logistique ou un établissement de santé peut avoir besoin de ressources informatiques locales tout en souhaitant conserver les mêmes outils de développement et d’administration que le reste de son environnement cloud.
Une architecture qui rapproche aussi les bases de données
Les applications modernes ne fonctionnent pas uniquement avec des serveurs applicatifs. Elles dépendent également des bases de données, des systèmes de stockage et de nombreux services complémentaires.
AWS Outposts permet notamment d’exécuter certaines ressources Amazon EC2, EBS, ECS, EKS et RDS sur les racks Outposts, selon la région et les services pris en charge.
Cette possibilité est importante pour les applications qui doivent conserver leurs traitements et leurs données à proximité.
Une application métier peut ainsi exécuter son traitement localement et accéder à une base de données également déployée sur l’Outpost. L’entreprise évite alors de construire une architecture où chaque opération dépend systématiquement d’une liaison vers le cloud public.
Cette logique peut également faciliter certaines migrations.
Une application ancienne peut dépendre d’une base de données locale ou d’un système qui ne peut pas être déplacé immédiatement. Plutôt que de procéder à une migration complète en une seule étape, l’entreprise peut construire progressivement une architecture hybride.
Le cloud devient alors une trajectoire de transformation plutôt qu’un projet de remplacement immédiat.
EKS, conteneurs et applications modernes sur site
Les applications d’entreprise évoluent également vers les architectures conteneurisées. Kubernetes est devenu un composant important de cette transformation, notamment pour les organisations qui cherchent à standardiser leurs déploiements.
AWS Outposts permet d’exécuter des workloads conteneurisés sur site avec des services AWS adaptés. Les clusters Amazon ECS peuvent notamment être utilisés sur Outposts, tandis que les racks prennent également en charge des nœuds Amazon EKS.
Pour les développeurs, cette approche réduit les différences entre les environnements. Les équipes peuvent utiliser des outils et des méthodes proches de ceux qu’elles utilisent déjà dans AWS.
Pour les directions informatiques, cette standardisation facilite également la gouvernance. Les équipes peuvent concevoir des processus de déploiement cohérents tout en décidant où chaque application doit réellement s’exécuter.
Cette capacité devient particulièrement intéressante lorsque plusieurs environnements doivent être maintenus simultanément : datacenter, sites distants et régions AWS.
La connectivité reste un élément déterminant
Il serait toutefois incorrect de présenter AWS Outposts comme un cloud totalement indépendant du reste d’AWS.
Un Outpost doit maintenir une connexion avec sa région AWS associée. Cette liaison, appelée service link, permet notamment les fonctions de gestion et certaines communications entre l’Outpost et la région. L’infrastructure locale doit donc disposer d’une connectivité réseau adaptée.
Ce point doit être étudié dès la conception du projet.
Le réseau local, la liaison WAN, le routage, la sécurité et les mécanismes de redondance doivent être dimensionnés en fonction des applications concernées.
Cette problématique rejoint directement le rôle de l’intégrateur réseau. Une architecture AWS Outposts ne peut pas être étudiée indépendamment du système d’information existant.
Les équipements réseau Cisco, les solutions de sécurité Fortinet ou les mécanismes d’identité Microsoft peuvent par exemple participer à la construction d’un environnement hybride cohérent. Les politiques d’accès doivent rester homogènes, que l’utilisateur consulte une application située dans le datacenter, sur un Outpost ou dans une région AWS.
Notre article consacré à Microsoft Entra ID et l’identité numérique permet justement d’approfondir cette dimension. L’identité devient un point de contrôle transversal, indépendamment de l’endroit où l’application est exécutée.
Deuxième génération : AWS fait évoluer le modèle Outposts
L’offre Outposts évolue également sur le plan matériel.
AWS présente désormais ses racks de deuxième génération comme une évolution destinée à fournir davantage de capacités de traitement, de mémoire et de bande passante réseau. Cette génération introduit notamment une architecture avec un rack réseau permettant de dissocier davantage l’évolution des capacités de calcul et celles du réseau.
Cette évolution est importante pour les entreprises qui envisagent une montée en charge progressive.
Le besoin informatique d’une organisation peut augmenter sans que ses besoins réseau évoluent exactement au même rythme. Une architecture permettant de faire évoluer ces ressources de manière plus indépendante offre donc davantage de flexibilité.
Il faut également noter une évolution importante du catalogue : AWS a arrêté les nouvelles ventes des anciens serveurs Outposts 1U et 2U et concentre désormais son développement sur les racks Outposts, avec de nouveaux formats destinés aux environnements disposant de contraintes d’espace.
Pour une entreprise qui étudie un nouveau projet, cette évolution doit être prise en compte dès la phase de dimensionnement.
AWS Outposts ne remplace pas l’intégrateur : il renforce son rôle
Une infrastructure hybride ne devient pas automatiquement cohérente parce qu’elle utilise des technologies cloud.
La complexité se déplace. Il faut désormais gérer les connexions entre les environnements, les identités, les politiques de sécurité, les applications, les données et les ressources locales.
Un projet AWS Outposts doit donc commencer par une analyse précise des workloads.
Chaque application doit être évaluée selon plusieurs critères : besoin de latence, volume de données, niveau de confidentialité, dépendances avec les systèmes existants, exigences de disponibilité et capacité à fonctionner lorsque la connectivité avec le cloud est temporairement perturbée.
Cette analyse permet ensuite de déterminer quelles ressources doivent rester sur site, lesquelles peuvent être exécutées dans AWS et comment les différents environnements doivent communiquer.
Le réseau devient alors une composante stratégique du projet. Les solutions Cisco peuvent assurer la connectivité entre les différents environnements, tandis que les solutions de sécurité comme Fortinet peuvent contrôler les flux et segmenter les accès.
L’identité doit également rester cohérente. Un collaborateur ne devrait pas avoir des règles d’accès complètement différentes selon qu’il utilise une application située sur l’Outpost ou dans une région AWS. Une gestion centralisée avec Microsoft Entra ID permet de conserver une politique d’identité homogène à travers les différents environnements.
Cette logique rejoint directement les principes développés dans notre article consacré à Microsoft Entra ID et l’identité numérique.
L’objectif est simple : l’utilisateur doit avoir une expérience cohérente, même lorsque l’infrastructure qui exécute les applications est distribuée.
En pratique : une entreprise industrielle entre cloud et infrastructure locale
Imaginons une entreprise industrielle disposant de plusieurs sites de production.
Chaque usine utilise des applications de supervision, des équipements connectés et des systèmes d’analyse qui génèrent des volumes importants de données.
L’entreprise souhaite moderniser son infrastructure et adopter davantage de services AWS. Mais certaines applications doivent continuer à fonctionner au plus près des machines. Une interruption de connexion avec le cloud ne doit pas arrêter la production.
Une migration complète vers AWS ne répond donc pas parfaitement à ses contraintes.
L’entreprise peut envisager une architecture hybride dans laquelle les workloads nécessitant une faible latence restent sur site, tandis que d’autres applications utilisent les services AWS dans le cloud public.
Un environnement AWS Outposts peut alors fournir les ressources locales nécessaires aux applications concernées. Les données peuvent être traitées au plus près des équipements, tandis que les workloads qui bénéficient davantage de l’élasticité du cloud continuent d’utiliser les ressources AWS distantes.
Le réseau assure la communication entre les différents environnements. Les politiques d’identité restent centralisées. Les mécanismes de sécurité protègent les flux et les applications.
Le résultat n’est pas un simple datacenter équipé de matériel AWS.
C’est une architecture hybride cohérente, dans laquelle chaque workload est exécuté dans l’environnement correspondant à ses contraintes.
Cloud hybride : choisir l’emplacement du workload plutôt que suivre une doctrine
Le débat entre cloud et infrastructure locale devient progressivement moins pertinent.
Une entreprise moderne peut avoir besoin des deux.
Notre article consacré au cloud hybride pour l’entreprise montre déjà pourquoi cette approche permet de combiner flexibilité, performance et maîtrise des données.
AWS Outposts apporte une réponse concrète à l’un des problèmes de cette architecture : comment conserver une expérience cloud tout en exécutant certaines ressources dans les locaux de l’entreprise ?
Cette logique peut également s’appliquer aux projets d’intelligence artificielle. Une entreprise peut entraîner certains modèles dans le cloud lorsque la capacité de calcul nécessaire est importante. Elle peut ensuite exécuter l’inférence localement lorsque la latence, la confidentialité ou la connectivité deviennent prioritaires.
Notre article consacré à Dell AI Factory et au passage de l’expérimentation IA à la production montre justement que le choix de l’emplacement des workloads devient un élément essentiel de l’architecture IA.
Il n’existe donc pas une réponse universelle. Le bon modèle dépend des applications, des données, des utilisateurs et des contraintes de l’entreprise.
Une infrastructure hybride doit être pensée pour durer
Le choix d’une architecture ne doit pas seulement répondre aux besoins actuels. Il doit également permettre à l’entreprise d’évoluer.
Les applications vont changer. Les volumes de données vont augmenter. De nouveaux services cloud vont apparaître. Les usages de l’intelligence artificielle vont progresser.
Une infrastructure hybride doit donc rester suffisamment flexible pour accompagner ces évolutions.
C’est précisément pourquoi l’intégration entre les différentes briques technologiques est essentielle. AWS Outposts ne doit pas être considéré comme une solution isolée. Il doit s’intégrer au réseau, à la cybersécurité, aux systèmes d’identité, au stockage et aux outils de supervision existants.
Cette approche permet également de préserver les investissements déjà réalisés. Une entreprise n’a pas besoin de remplacer immédiatement toute son infrastructure pour commencer sa transformation cloud.
Elle peut avancer progressivement, workload par workload, en conservant les ressources qui restent pertinentes et en modernisant celles qui doivent évoluer.
Conclusion
Le cloud public a changé les règles de l’infrastructure informatique. Mais cette transformation ne signifie pas que tous les workloads doivent quitter les locaux de l’entreprise.
AWS Outposts propose une approche différente : apporter une partie de l’expérience AWS directement dans l’environnement du client afin d’exécuter localement les applications qui nécessitent proximité, faible latence ou maîtrise de l’emplacement des données.
Cette approche devient particulièrement pertinente pour les entreprises qui doivent combiner applications locales, services cloud, données sensibles et nouveaux workloads d’intelligence artificielle.
La question n’est donc plus de choisir entre le cloud et le datacenter.
Elle consiste à déterminer où chaque workload doit fonctionner pour offrir le meilleur équilibre entre performance, sécurité, disponibilité, coût et flexibilité.
C’est cette capacité à construire un système cohérent entre plusieurs environnements qui transforme véritablement le cloud hybride en avantage stratégique.
Prêt à construire une architecture cloud hybride adaptée à votre entreprise ?
Les équipes NextHope accompagnent les entreprises dans la conception et l’intégration d’architectures cloud, réseau et infrastructure adaptées à leurs contraintes métiers.
Migration AWS, environnement hybride, connectivité entre datacenter et cloud, cybersécurité, gestion des identités ou modernisation des infrastructures : chaque projet nécessite une architecture pensée dans sa globalité.
Vous souhaitez conserver certaines applications sur site tout en profitant des services AWS ? Contactez NextHope pour étudier l’architecture la plus adaptée à votre environnement.
La vision NextHope
Pour Ranarison Tsilavo, la transformation numérique ne doit pas imposer aux entreprises un modèle unique. Chaque organisation possède ses propres contraintes, ses propres données et ses propres priorités. Cette conviction guide la vision de NextHope : construire des infrastructures capables de combiner les meilleures technologies disponibles avec les réalités opérationnelles des entreprises africaines.
Cloud public, infrastructure locale, réseau, cybersécurité, intelligence artificielle ou postes de travail : ces composants doivent être pensés ensemble pour créer un système d’information réellement performant. Grâce à ses partenariats technologiques et à son expertise dans l’intégration informatique, NextHope accompagne les organisations dans cette évolution en privilégiant une approche progressive, pragmatique et orientée vers les résultats.
L’objectif n’est pas simplement de déployer une nouvelle technologie. Il est de construire une infrastructure capable d’accompagner durablement la croissance de l’entreprise.
Foire aux questions
Qu’est-ce qu’AWS Outposts ?
AWS Outposts permet d’exécuter certaines ressources et certains services AWS directement dans les locaux d’une entreprise. Il rapproche ainsi les capacités du cloud des applications et des données qui doivent rester sur site.
AWS Outposts remplace-t-il un datacenter traditionnel ?
Pas nécessairement. Outposts s’intègre généralement dans une architecture hybride. Il peut compléter une infrastructure existante en apportant des ressources AWS locales pour certains workloads.
Pourquoi utiliser AWS Outposts plutôt que le cloud public ?
Outposts peut être pertinent lorsque certaines applications nécessitent une faible latence, un traitement local ou une maîtrise particulière de l’emplacement des données. Le choix dépend toutefois des contraintes propres à chaque workload.
AWS Outposts fonctionne-t-il sans connexion avec AWS ?
Outposts reste associé à une région AWS et nécessite une connectivité adaptée avec celle-ci pour certaines fonctions de gestion et de fonctionnement. La connectivité doit donc être étudiée dès la conception de l’architecture.
Quels secteurs peuvent utiliser AWS Outposts ?
Les environnements industriels, la santé, la finance, les sites distants et les entreprises disposant d’applications sensibles à la latence peuvent notamment trouver un intérêt dans cette architecture hybride.
Quel est le rôle d’un intégrateur dans un projet AWS Outposts ?
L’intégrateur analyse les workloads, dimensionne l’infrastructure, conçoit la connectivité et assure l’intégration avec les systèmes existants. Il veille également à la cohérence entre le cloud, le réseau, la sécurité et les identités.
