Cloud et on-premise : deux stratégies pour l'exploitation de l'infrastructure

Dans les débats sur le cloud et les solutions sur site, on retrouve sans cesse les mêmes arguments. Les uns affirment qu’il est aujourd’hui impossible de fonctionner sans le cloud, tandis que les autres évoquent la perte de contrôle, la dépendance vis-à-vis des fournisseurs et l’affaiblissement de la souveraineté des données. En réalité, cependant, ce genre de décision se prend rarement au niveau des slogans. Elle se situe généralement à un niveau beaucoup plus pratique : budgets, personnel disponible, exigences opérationnelles, règles de sécurité et volonté d'assumer une certaine part de risque.

C'est précisément pour cette raison qu'il me semble judicieux d'examiner ces deux voies avec objectivité. Non pas comme un conflit idéologique, mais comme deux stratégies différentes de gestion des infrastructures. Chacune d'elles apporte quelque chose d'utile et chacune comporte également des coûts moins visibles. Le but n'est pas de désigner un vainqueur, mais d'expliquer ce que chaque choix implique réellement.

Qu'est-ce que le cloud et qu'est-ce que l'on-premise ?

Le terme « cloud » recouvre aujourd’hui un large éventail de services, allant des serveurs et bases de données virtuels aux logiciels complets fournis via Internet. Leur point commun est que l’infrastructure est gérée, tant sur le plan physique qu’opérationnel, par un tiers, et que le client y accède comme à un service. À l'inverse, « on-prem » signifie que l'organisation gère elle-même son infrastructure, que ce soit directement dans ses propres locaux, dans un rack loué ou dans un centre de colocation, mais sous sa propre administration.

Sur le papier, la différence est simple. Dans la pratique, c'est une autre histoire. De nombreuses organisations fonctionnent aujourd'hui selon un modèle hybride : une partie des systèmes tourne dans le cloud, une autre sur leurs propres serveurs, et certains services ne sont externalisés que partiellement. Il est donc d'autant plus important de comprendre non seulement les différences techniques, mais aussi comment la responsabilité, la visibilité et le degré de contrôle réel évoluent dans ces deux modèles.

Ce que le cloud offre

L'une des principales raisons pour lesquelles les entreprises et les institutions migrent vers le cloud est la flexibilité. Le cloud permet de mettre rapidement en place de nouveaux environnements, d'augmenter facilement la capacité et de s'adapter aux changements sans avoir à acheter de nouveau matériel ni à attendre son installation. Pour les petites équipes ou les projets à charge variable, c'est souvent un avantage décisif : ce qui, dans un modèle traditionnel, nécessiterait des semaines de préparation, peut parfois être réglé en une seule journée.

Un autre argument souvent avancé est d'ordre économique. Le cloud réduit généralement l'investissement initial en capital (CapEx), car il évite l'achat de matériel propre et transfère une partie des coûts vers les dépenses d'exploitation courantes (OpEx). Cela s'avère particulièrement intéressant lorsque l'entreprise ou l'institution ne souhaite pas ou ne peut pas supporter des dépenses initiales élevées. Cependant, il faut savoir que des coûts initiaux plus faibles ne signifient pas automatiquement des coûts totaux de possession plus bas. Avec une charge de travail stable et prévisible sur le long terme, il peut arriver que les coûts récurrents du cloud dépassent progressivement ce qu'aurait coûté une exploitation en interne – surtout si les services, les répliques, les instantanés et les environnements de test s'accumulent sans contrôle.

Responsabilité partagée : qui est responsable de quoi ?

Le cloud est parfois perçu comme „Sécurité “ en tant que service » : on confie les soucis aux experts et le problème est résolu. Il y a une part de vérité là-dedans, mais seulement jusqu’à un certain point. C’est précisément là qu’intervient le concept de responsabilité partagée (modèle de responsabilité partagée), que tous les grands fournisseurs utilisent aujourd’hui : AWS, Azure et Google Le cloud.

Le principe est simple. Le fournisseur assure la sécurité du cloud en tant que tel – l'infrastructure physique, les centres de données, la plateforme de base. Le client reste toutefois responsable de ce qu'il exploite dans le cloud : la configuration de ses services, les droits d'accès, chiffrement, les règles réseau et la sécurité des applications elles-mêmes. La frontière entre les deux parties varie selon le type de service : dans le cas de l'infrastructure (IaaS), le client assume davantage de responsabilités ; dans le cas des logiciels entièrement gérés (SaaS), il en assume moins, mais jamais aucune.

Il est important de le rappeler, car de nombreux incidents de sécurité dans le cloud ne sont pas dus à une défaillance du fournisseur, mais à une erreur de la part du client : un stockage mal configuré, des autorisations trop larges, des accès insuffisamment protégés ou une gestion des identités négligée. Le cloud peut très bien être un environnement sécurisé, mais seulement s’il est bien conçu et géré.

Qu'offre la solution sur site ?

Le principal avantage de l'infrastructure sur site réside dans le contrôle. L'opérateur sait exactement où l'infrastructure est déployée, qui y a accès physiquement et logiquement, et comment les différentes couches de l'environnement sont configurées. Il peut définir lui-même la journalisation, la segmentation du réseau, le mode de mise à jour ou la méthode de sauvegarde. Pour certaines équipes, ce niveau de gestion directe est essentiel, car elles ne souhaitent pas dépendre des décisions d'un grand fournisseur externe.

Mais le contrôle s'accompagne d'une responsabilité totale. Le modèle „ sur site “ implique que l'entreprise ou l'institution gère elle-même le matériel, l'alimentation électrique, le refroidissement, la surveillance, la sécurité physique, les mises à jour, les scénarios d'urgence ainsi que la relève du personnel. Lorsque l'on dispose d'une équipe interne solide et de processus clairs, cela peut très bien fonctionner. Mais lorsque l'infrastructure est gérée par un seul administrateur surchargé, « en plus de tout le reste », l'avantage du contrôle peut rapidement se transformer en source de fragilité.

Souveraineté des données

Un sujet très en vogue ces derniers temps est souveraineté des données – c'est-à-dire non seulement la question de savoir où se trouvent physiquement les données, mais aussi à quelle juridiction elles sont soumises, qui peut y avoir accès et quels acteurs participent à leur traitement. Dans le monde du cloud, il est courant que les fournisseurs permettent de choisir la région du centre de données, mais cela ne résout en soi que la question de la résidence des données, c'est-à-dire leur emplacement physique. La souveraineté totale englobe également la portée juridique, la gestion des accès et l'ensemble de la chaîne d'approvisionnement, ce que le choix de la région ne garantit pas automatiquement. Il est également important de penser à métadonnées les communications générées lors de l'exploitation du service et qui peuvent être soumises à des règles différentes de celles applicables au contenu lui-même.

Dans ce domaine, l'infrastructure sur site offre une plus grande transparence. L'opérateur a généralement une idée plus précise de l'emplacement des données et du chemin qui y mène. Mais ce n'est pas une solution miracle. Même une infrastructure propre utilise du matériel provenant de fabricants externes, la connectivité fournie par des opérateurs de télécommunications, et souvent divers composants logiciels tiers. La différence ne réside donc pas dans le fait que l'on-prem signifierait une isolation totale, mais plutôt dans le fait qu'il permet de définir plus précisément qui l'opérateur autorise à accéder à son environnement et dans quelle mesure.

Réalité hybride et agencement des services

Il est également important de distinguer l'externalisation de l'ensemble de l'infrastructure de celle de certains composants seulement. De nos jours, de nombreuses entreprises et institutions n'optent pas pour une solution unique, mais composent leur infrastructure à partir de différents services : DNS dans le cloud, authentification externe, surveillance spécialisée, plateforme de visioconférence autonome, CDN ou passerelle de messagerie.

Cette approche peut s'avérer très efficace, car elle permet de tirer parti de la spécialisation de chaque fournisseur. Mais elle implique également la création de multiples dépendances techniques et juridiques. Chaque nouveau service vient augmenter le nombre de points où sont traitées les données opérationnelles et les métadonnées de communication – un sujet que j'aborde plus en détail dans mon précédent article sur les métadonnées. Le risque de « vendor lock-in » augmente également : plus les processus de travail et les formats de données sont étroitement liés à un fournisseur spécifique, plus un éventuel transfert vers un autre fournisseur ou un retour à une infrastructure propre (ce que l'on appelle la « cloud repatriation ») s'avère difficile, tant sur le plan technique que financier.

Stabilité et résistance

Les grands fournisseurs de cloud investissent généralement dans la redondance, les restaurations automatiques et la répartition géographique des services, ce que les petites équipes ne parviennent souvent pas à reproduire par leurs propres moyens. La résilience qui en résulte dépend toutefois de l'architecture spécifique du client : la plateforme en elle-même ne la garantit pas. Parallèlement, une panne d'une grande plateforme cloud affecte simultanément un large éventail de clients. Dans le cas d'une solution sur site, l'impact d'une panne est plus localisé – mais seulement à condition que l'opérateur ait réellement mis en place des sauvegardes, un système de surveillance et des scénarios de crise. Sinon, l'environnement propre peut en réalité être moins résilient que ne l'admet son administrateur.

Ce qui compte

Le choix entre le cloud et l'infrastructure sur site n'est pas une décision ponctuelle, mais une discipline architecturale permanente. Il ne suffit pas de dire „ nous sommes dans le cloud “ ou „ nous fonctionnons sur site “. Il est plus important de savoir décrire quelles parties de l'environnement se trouvent où, pourquoi elles y sont, qui en est responsable et quels risques l'organisation accepte en toute connaissance de cause.

Le cloud offre rapidité, commodité et évolutivité, mais exige de la rigueur en matière de configuration, de gestion des identités, de maîtrise des coûts et de compréhension du principe de responsabilité partagée. L'infrastructure sur site offre un contrôle direct accru, une meilleure visibilité sur l'emplacement des données et parfois une meilleure prévisibilité, mais elle impose des exigences plus élevées en matière de personnel, de processus et de maturité opérationnelle. Aucune de ces deux voies n'est universellement valable. Ce qui est souvent une erreur, c'est de faire un choix dicté par la mode, par l'inertie ou sans vision réaliste de ses propres capacités.

C'est pourquoi il me semble plus judicieux d'aborder la question des infrastructures de manière moins idéologique et plus pragmatique. Il ne s'agit pas de se demander ce qui est le plus moderne ou ce qui sonne le mieux dans une présentation, mais ce dont une organisation a réellement besoin, ce qu'elle est capable de gérer et où elle parvient à trouver un juste équilibre entre confort, coûts, sécurité et contrôle.