Infrastructure cloud : le socle commun à tous vos projets

Un site, puis un CRM, puis quelques automatisations, puis un premier assistant d’IA. Si chaque projet arrive avec ses propres accès, son propre hébergement et sa propre facture, au bout de quelques années plus personne ne sait qui détient quelles clés, quelles données sont sauvegardées, ni pourquoi la facture a grimpé. Une infrastructure cloud se construit dans l’autre sens : un socle commun d’abord, sur lequel chaque projet vient se poser.

Ce guide de notre rubrique Infrastructure et cloud explique ce que contient ce socle, où le poser, ce qu’il coûte et ce qui le fait tenir dans la durée. Si vos outils vivent aujourd’hui dans des abonnements que vous aimeriez reprendre en main, notre sortie du SaaS pose ce socle sur un serveur à vous, sauvegardes testées et documentation comprises.

En bref

• Le socle, que les grands fournisseurs appellent landing zone, regroupe ce que tous vos projets partagent : comptes, identités et droits, réseau, journaux, sauvegardes, budgets, secrets et documentation.
• Google recommande de le poser avant le premier projet, et précise que la première version n’est souvent pas la dernière.
• Le lieu se choisit sur quatre critères : la nature des données, les compétences disponibles, le coût dans la durée et la facilité d’en sortir.
• Chez un grand fournisseur, la facture suit l’usage : budgets et alertes dès le premier jour. Chez Microsoft Azure, une alerte prévient, elle n’arrête pas la consommation.
• Un socle vaut ce que vaut son exploitation : sauvegardes restaurées pour de vrai, surveillance, mises à jour, plan de reprise écrit.

Qu’est-ce qu’un socle d’infrastructure cloud ?

Le socle est la première couche de toute architecture cloud, et la seule que tous vos projets partagent : l’ensemble des décisions prises une fois pour toutes sur les comptes, les accès, le réseau, les journaux, les sauvegardes et les dépenses.

Les trois grands fournisseurs ont un nom pour cela. Dans son guide de conception des landing zones, Google Cloud la décrit comme « une configuration modulaire et évolutive » qui permet à une organisation d’adopter son cloud, l’appelle aussi « fondation cloud », et ajoute qu’elle est « souvent un prérequis » au déploiement des charges de travail d’une entreprise (nous traduisons). AWS, dans la page « Landing zone » de son guide de migration, en fait une base pour démarrer avec une architecture multicomptes, la gestion des identités et des accès, la gouvernance, la sécurité des données, la conception du réseau et la journalisation. Microsoft, dans sa présentation de la zone d’atterrissage Azure, distingue la zone de plateforme, « la base centralisée qui établit la gouvernance, la sécurité et les ressources partagées pour toutes vos charges de travail », des zones où les équipes déploient leurs projets.

Le mot vient des grands fournisseurs, la question ne leur appartient pas : sur un serveur dédié ou un VPS, il faut aussi décider qui a les accès, où partent les sauvegardes et qui est prévenu d’une panne. Nous parlons donc de socle, quel que soit l’endroit où il est posé.

Que contient une landing zone ?

Google liste quatre éléments qu’une landing zone exige de concevoir : le provisionnement des identités, la hiérarchie des ressources, le réseau et les contrôles de sécurité. Il en ajoute d’autres selon les besoins de l’entreprise, dont la surveillance et la journalisation, la stratégie de sauvegarde et de reprise après sinistre, la conformité et la maîtrise des coûts. Pour une PME, cela donne ceci.

L’infrastructure as code décrit le socle dans des fichiers au lieu de le cliquer dans une console. Google la conseille, avec par exemple Terraform, parce qu’elle rend le déploiement « reproductible et modulaire » (nous traduisons) : le jour où il faut reconstruire ou partir ailleurs, la recette existe. La documentation, elle, n’apparaît dans aucun schéma, mais c’est elle qui permet à quelqu’un d’autre que son auteur d’intervenir un dimanche.

Le coffre-fort, enfin, fait plus que ranger les secrets : bien branché, il laisse vos automatisations et vos agents d’IA utiliser une clé sans jamais la lire. C’est l’objet de notre article sur le coffre-fort de secrets.

Rien n’oblige à tout poser le premier jour. Google le dit lui-même : la première itération d’une landing zone n’est souvent pas la version finale, et il conseille de centrer la conception initiale sur ce que demandent les premiers projets, puis d’ajouter le reste plus tard (nous traduisons).

Pourquoi le socle est-il le dénominateur commun de vos projets ?

Prenons une PME de quarante personnes, un exemple construit pour l’occasion. Son site est hébergé par l’agence qui l’a fait, son CRM est un abonnement, ses automatisations tournent sur le compte personnel d’un salarié, et un assistant d’IA vient d’être branché sur la carte bancaire d’un autre. Rien de choquant, projet par projet. Le jour où le premier salarié part, personne ne sait quelles automatisations s’arrêtent, quelles clés il détenait, ni où sont les sauvegardes du CRM, s’il y en a.

Chaque projet a improvisé les mêmes réponses : qui a accès, ce qui est sauvegardé, qui paie et combien. Le socle répond une fois, et chaque projet hérite de la réponse. Microsoft le formule à sa manière : « chaque abonnement et ses ressources Azure héritent des stratégies de gouvernance et de sécurité » posées au-dessus d’eux, et la zone d’atterrissage accueille les technologies nouvelles, l’IA comprise, « sans nécessiter de modifications apportées à l’architecture globale ». Le même texte pose une limite saine : ne centraliser que ce qui apporte « des avantages économiques, opérationnels ou de gouvernance clairs sur plusieurs charges de travail ». Le socle n’est pas un projet de plus : c’est ce que vos projets ont en commun, et rien d’autre.

C’est ainsi que nous fonctionnons pour nos propres outils. Un serveur unique héberge une douzaine de services pour cinq entreprises clientes : le CRM Twenty, en production chez nous depuis début 2025 (nous contribuons aussi au projet), l’automatisation n8n, les statistiques web Matomo, la signature électronique, la facturation et des modèles d’IA. Chaque nouveau service se branche derrière le même routeur et suit les mêmes règles d’exploitation : les questions de fond ont déjà leur réponse.

Où poser votre infrastructure : grand fournisseur, cloud européen ou serveur dédié ?

Pour l’hébergement cloud d’une entreprise, trois familles d’options, qui ne s’excluent pas.

• Un grand fournisseur (AWS, Google Cloud, Microsoft Azure). Un catalogue de services immense, une facture qui suit l’usage. Chez AWS, la landing zone se crée avec le service AWS Control Tower ou sur mesure, et « chaque option demande un niveau de connaissance d’AWS différent » (nous traduisons). C’est le bon choix quand vos projets ont besoin de ces services et que quelqu’un sait les exploiter.
• Un cloud européen. En France, l’ANSSI qualifie certaines offres sous le nom SecNumCloud. Sur sa page consacrée au cloud, elle les décrit comme des offres « de confiance » dont l’utilisation est « préconisée pour la protection des données sensibles ».
• Un serveur dédié ou un VPS. Un coût fixe et prévisible, mais une exploitation qui vous revient presque entièrement : mises à jour, sauvegardes, surveillance. C’est notre choix pour nos propres outils.

Pour trancher, quatre critères :

1. La nature des données. Données de santé, données personnelles en volume, secrets industriels : elles décident souvent du lieu avant tout le reste.
2. Les compétences disponibles. Un grand fournisseur demande de connaître sa console, ses droits et sa facturation ; un serveur, de savoir le maintenir. Choisissez ce que quelqu’un, chez vous ou chez un prestataire, saura encore exploiter dans deux ans.
3. Le coût dans la durée. Comparez sur trois ans, heures d’exploitation comprises, pas sur le prix du premier mois.
4. La dépendance au fournisseur. Un socle décrit en code et des données dans des formats ouverts gardent la porte de sortie ouverte.

La question de la souveraineté dépasse ce guide : nous la traitons dans notre analyse de la dépendance de l’Europe au cloud américain.

Rien n’empêche de combiner : vos outils de gestion sur un serveur à vous, un projet gourmand en calcul chez un grand fournisseur. Le socle reste alors un seul ensemble de règles, appliqué aux deux endroits.

Combien coûte le socle, et comment éviter la facture surprise ?

Un socle coûte deux fois : à la mise en place, puis chaque mois en exploitation, et ce second coût se compte surtout en heures. Google prévient que la conception et le déploiement d’une landing zone peuvent prendre plusieurs semaines (nous traduisons). Pour comparer avec vos abonnements actuels, notre méthode est détaillée dans le vrai coût d’une sortie du SaaS sur trois ans.

Chez un grand fournisseur, la facture suit l’usage, et une ressource oubliée continue de coûter. Google cite d’ailleurs les outils pour piloter la répartition interne des coûts parmi les raisons de poser une landing zone avant le premier projet (nous traduisons). Posez donc un budget par projet et des alertes dès le premier jour.

Encore faut-il savoir ce qu’une alerte fait. La documentation de Microsoft sur les budgets Azure est claire : quand un seuil est dépassé, « les ressources ne sont pas affectées et votre consommation n’est pas arrêtée ». Les données de coûts arrivent en général « dans un délai de 8 à 24 heures », et les budgets sont évalués toutes les 24 heures : une dérive du lundi peut n’être signalée que le mardi. Pour agir automatiquement, il faut relier le budget à un « groupe d’actions ». Les autres fournisseurs ont leurs propres règles : lisez celles du vôtre avant de compter sur une alerte.

Le même raisonnement vaut hors des grands clouds. Sur Palmora, un portail immobilier que nous opérons, des automatisations tournaient dans un service d’intégration continue facturé à la minute ; après trois nuits à plus de quatre heures de minutes facturées, nous les avons rapatriées sur un serveur dédié. À l’inverse, certaines briques coûtent peu : le plan de sauvegarde hors serveur de Palmora revient à environ 6 dollars par mois. Ce qui coûte, ce sont les heures passées à exploiter.

Pourquoi l’exploitation compte-t-elle plus que l’installation ?

Un socle ne casse pas le jour de son installation. Il se dégrade en silence : une sauvegarde qui échoue, un certificat qui expire, une mise à jour repoussée, un accès jamais retiré. Quatre routines font la différence.

• Des sauvegardes restaurées pour de vrai. Une sauvegarde jamais restaurée reste une hypothèse. Sur Palmora, nous jugeons une restauration au nombre de tables et d’enregistrements retrouvés, pas au code de retour de l’outil, qui signale une erreur sur de simples avertissements. Le détail est dans notre guide des sauvegardes d’un serveur à soi.
• Une surveillance qui prévient. Google parle de tableaux de bord et d’alertes qui signalent « toute anomalie appelant une action » (nous traduisons). Encore faut-il qu’une personne les reçoive et les lise.
• Des mises à jour planifiées, avec un moyen de revenir en arrière si l’une d’elles casse un service. Notre guide de n8n auto-hébergé en production le montre sur un outil qui change presque chaque semaine.
• Un plan de reprise écrit. Google range la stratégie de sauvegarde et de reprise après sinistre parmi les éléments d’une landing zone ; pour une PME, c’est une page qui dit quoi relancer, dans quel ordre, et qui prévenir.

Nous parlons d’expérience. Le 5 juillet 2026, une commande de nettoyage mal ciblée a détruit d’un coup les conteneurs de dix services sur notre serveur. Les données, rangées dans des volumes, ont été sauvées, et nos règles d’exploitation sont désormais écrites. Sur Palmora, c’est la dépendance à une seule machine qui a motivé un coffre-fort de secrets auto-hébergé. Et le passage des fichiers du site vers un stockage objet s’est fait avec une intégrité vérifiée : 51 566 fichiers, 19 Go, aucune erreur, 20 Go libérés.

Si vous partez d’abonnements, l’ordre dans lequel les ramener sur votre socle compte aussi : nous le détaillons dans les outils à sortir du SaaS en premier.

Ce que nous proposons, et ce que nous pouvons prouver

Deux cas, selon le lieu choisi.

Votre socle sur un serveur à vous. C’est notre offre de sortie du SaaS : l’audit de vos abonnements et de leur coût réel sur trois ans, jusqu’à cinq outils installés, vos données migrées et vérifiées, des sauvegardes hors serveur avec restauration testée, et une documentation d’exploitation. Elle coûte 5 500 € et prend trois semaines ; l’infogérance, en option, coûte 450 € par mois et couvre la supervision, les mises à jour et des sauvegardes testées.

Votre socle chez un grand fournisseur ou dans un cloud européen. Nous le posons chez le fournisseur que vous avez choisi, ou que nous choisissons ensemble sur les critères ci-dessus : organisation des comptes, identités et droits, budgets et alertes, journaux, sauvegardes, infrastructure décrite en code et documentation. Ensuite, nous l’exploitons, ou nous vous le remettons avec sa documentation.

Ce que nous pouvons prouver, c’est notre propre socle : un serveur unique, une douzaine de services, cinq entreprises clientes, avec les arbitrages et les incidents que cela suppose. Nous ne revendiquons pas de socles déjà posés chez AWS, Google Cloud ou Microsoft Azure. Les trois guides cités plus haut le montrent : les briques d’un socle se ressemblent d’un fournisseur à l’autre, ce sont les outils qui changent. Et si votre projet demande une expertise pointue d’un fournisseur que nous n’avons pas, nous vous le dirons avant de commencer.

Par où commencer

1. Faites l’inventaire. Les comptes cloud et les abonnements, qui y a un accès administrateur, quelles données y vivent, quelles factures tombent chaque mois.
2. Triez vos données. Celles qui sont sensibles, celles qui ne le sont pas : ce tri décide souvent du lieu.
3. Posez le minimum du premier jour. Des accès nominatifs avec authentification forte, un budget et des alertes, des sauvegardes hors du lieu principal avec une restauration testée, et une page de documentation.
4. Faites entrer un premier projet peu critique. Google conseille de déployer d’abord les charges de travail qui tournent le plus facilement sur son cloud (nous traduisons) : c’est sur ce premier projet que le socle se rode.
5. Ajoutez le reste au fil des projets. Chaque nouveau projet vérifie que le socle tient, et le complète si besoin. Pour déplacer ce qui tourne déjà sans rien casser, avancez charge par charge : nous détaillons la méthode dans Migration cloud : déplacer l’existant sans tout casser.

Si vous voulez ce socle sur un serveur à vous, notre sortie du SaaS l’installe en trois semaines, sauvegardes testées et documentation comprises. S’il doit vivre chez un grand fournisseur ou dans un cloud européen, décrivez-nous vos projets et le fournisseur envisagé : nous vous dirons ce que votre socle doit contenir.

Questions fréquentes

Une landing zone, est-ce réservé aux grandes entreprises ?

Non. Le mot vient des grands fournisseurs de cloud, mais le besoin existe dès le deuxième projet : des accès, des sauvegardes, un budget. Pour une PME, la première version tient en peu de choses : accès nominatifs, budgets et alertes, sauvegardes testées, une page de documentation. Ce qui compte n’est pas la taille du socle, c’est qu’il existe avant que les projets se multiplient.

AWS, Google Cloud ou Azure : lequel choisir pour une PME ?

Aucun n’est meilleur dans l’absolu. Leurs guides décrivent des briques très proches : organisation des comptes, identités, réseau, journaux et surveillance. Le choix se fait sur vos critères : les services dont vos projets ont besoin, les compétences de votre équipe ou de votre prestataire, la nature de vos données et le coût sur trois ans. Si rien ne vous lie déjà à l’un d’eux, un serveur dédié ou un cloud européen mérite aussi d’être comparé.

Une alerte de budget arrête-t-elle la dépense ?

Chez Microsoft Azure, non : sa documentation précise que la consommation n’est pas arrêtée quand un seuil est dépassé. Pour agir automatiquement, il faut relier le budget à un groupe d’actions, qui peut déclencher différentes actions quand le seuil est atteint. Chez un autre fournisseur, lisez sa documentation : ne supposez jamais qu’une alerte coupe quoi que ce soit.

Un hébergement SecNumCloud suffit-il à protéger mes données ?

Non, et l’ANSSI le dit elle-même : la qualification « ne préjuge pas du niveau de sécurité » des services que les clients font tourner sur ces offres, un site web hébergé par exemple. La qualification porte sur l’offre du fournisseur. Vos accès, vos sauvegardes, vos mises à jour et la sécurité de vos applications restent à votre charge : c’est précisément le rôle du socle.