Infrastructure cloud scalable à Nantes

Une infrastructure cloud scalable est l’ensemble des serveurs, bases de données et services réseau qui font tourner votre site ou votre application, loués à un fournisseur et capables d’ajouter des ressources quand le trafic monte, puis de les rendre quand il retombe. Depuis Nantes, nous concevons, migrons et exploitons ce type d’infrastructure cloud pour des boutiques en ligne à fort trafic, des applications métier et des produits SaaS, avec un hébergement en Europe. La mise en place démarre à 4 900 € HT et prend 4 à 8 semaines ; l’exploitation est ensuite facturée au mois.

Avez-vous vraiment besoin d’une infrastructure cloud ?

Pas toujours, et nous préférons vous le dire avant de chiffrer. Une architecture qui monte en charge demande plus de conception et de surveillance qu’un hébergement simple : elle se justifie quand une panne ou un ralentissement vous coûtent des ventes, des clients ou de la confiance.

• Site vitrine : un site statique, la solution que nous recommandons pour une vitrine, encaisse sans peine un afflux de visites ; l’hébergement compris dans notre maintenance de site internet suffit.
• Boutique Shopify : l’hébergement, inclus dans l’abonnement, et la montée en charge sont assurés par la plateforme ; avant un pic, votre travail porte sur le thème, les applications et les scripts ajoutés.
• Boutique WooCommerce ou PrestaShop au trafic régulier : un serveur bien dimensionné, un cache et un CDN couvrent l’essentiel.
• Boutique aux pics marqués, application métier critique, produit SaaS ou API : c’est pour ces cas que nous concevons une infrastructure évolutive et hautement disponible.

Si votre boutique reste à construire, le choix de la plateforme, et donc de l’hébergement, se tranche dès le cadrage de la création de votre site e-commerce. De même, quand l’outil reste à développer, son infrastructure se conçoit en même temps que votre application métier développée sur mesure.

Audit et dimensionnement : partir de vos chiffres

Tout commence par un état des lieux : trafic habituel et pics (soldes, newsletter, passage dans les médias), utilisateurs simultanés, volume de la base de données, services tiers dont vous dépendez — paiement, transporteurs, ERP. Nous fixons ensuite avec vous deux objectifs de reprise :

• le RTO (Recovery Time Objective) : la durée d’interruption maximale que votre activité supporte ;
• le RPO (Recovery Point Objective) : la quantité de données que vous acceptez de perdre, exprimée en temps.

Une boutique peut, par exemple, tolérer une heure d’arrêt, mais pas la perte de plus de cinq minutes de commandes. Avec un RPO de cinq minutes, une sauvegarde par nuit ne suffit plus : la base doit être copiée en continu. Avec un RTO d’une heure, il n’est plus temps de reconstruire un serveur à la main : la reprise doit être écrite et répétée à l’avance. Ces deux chiffres et votre budget mensuel fixent le reste : nombre de zones, mode de réplication, fréquence des sauvegardes.

L’audit relève aussi les contraintes propres à vos données. Héberger des données de santé recueillies lors d’activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, pour le compte de celui qui les a produites ou recueillies ou pour celui du patient, exige un certificat de conformité, dit HDS (article L. 1111-8 du Code de la santé publique). Le décret du 26 février 2018 relatif à l’hébergement de données de santé range parmi les activités concernées l’administration et l’exploitation du système qui contient ces données, ainsi que leur sauvegarde : notre studio n’étant pas certifié, ces missions reviennent alors à un prestataire qui l’est. Depuis septembre 2026, en application d’un décret du 24 mars 2026, ces données doivent en outre être stockées exclusivement dans un État de l’Union européenne ou de l’Espace économique européen.

Pour des données particulièrement sensibles, nous pouvons retenir une offre qualifiée SecNumCloud par l’ANSSI : cette qualification porte sur l’offre du fournisseur, pas sur nos propres prestations. Au terme de l’audit, vous repartez avec une architecture cible et une estimation de la facture mensuelle du fournisseur.

Un hébergement en Europe, chez le fournisseur cloud adapté

Le choix du fournisseur dépend de vos contraintes, pas de nos habitudes. Voici les options que nous comparons.

La région européenne d’un fournisseur américain garde vos données en Europe, mais pas hors de portée du droit américain. Le CLOUD Act américain, adopté en mars 2018 (texte en anglais), oblige un fournisseur de services cloud ou de communication soumis au droit américain à conserver ou à communiquer aux autorités américaines, sur réquisition légale, les données qu’il détient ou contrôle, même stockées hors des États-Unis. Selon la nature de vos données, ce critère pèsera, ou non, dans le choix.

Infrastructure réseau : ce qui relie vos visiteurs à vos serveurs

Pour un site, l’infrastructure réseau ne désigne ni le câblage ni le Wi-Fi de vos bureaux — ce chantier relève d’un intégrateur réseau, et nous n’y intervenons pas. Il s’agit des briques qui acheminent chaque visite jusqu’à vos serveurs et protègent ce qui doit l’être :

• un réseau privé isolé (VPC, pour Virtual Private Cloud) : la base de données et les services internes n’ont pas d’adresse publique ; seuls les points d’entrée prévus sont joignables depuis Internet ;
• la répartition de charge : un répartiteur distribue les requêtes entre plusieurs serveurs, vérifie en continu qu’ils répondent et écarte celui qui flanche ;
• un CDN : images, scripts et pages mises en cache partent de serveurs proches de vos visiteurs, ce qui soulage les vôtres pendant les pics ;
• le DNS, l’annuaire qui associe votre nom de domaine à l’adresse de vos serveurs : géré par un service spécialisé, avec des durées de mise en cache réglées pour pouvoir basculer vite d’une infrastructure à l’autre ;
• un pare-feu applicatif (WAF) : il filtre les requêtes malveillantes et freine les robots trop insistants, en complément des protections contre le déni de service proposées par l’hébergeur ou le CDN.

Une montée en charge automatique, mais préparée

La mise à l’échelle automatique ajoute des instances de votre application quand un seuil est franchi — charge du processeur, nombre de requêtes, temps de réponse —, puis les retire quand le trafic retombe. C’est la forme automatique de la scalabilité horizontale : vous payez la capacité supplémentaire pendant le pic, pas toute l’année. Elle ne s’improvise pas pour autant :

• l’application doit pouvoir tourner sur plusieurs serveurs à la fois : sessions, fichiers envoyés par les utilisateurs et tâches planifiées sont sortis des serveurs eux-mêmes ;
• une nouvelle instance met un peu de temps à démarrer : avant un pic prévisible, nous relevons la capacité minimale à l’avance ;
• la base de données ne se démultiplie pas aussi facilement : cache, requêtes optimisées et copies en lecture la protègent ;
• des plafonds empêchent qu’un robot ou une erreur de code ne fasse exploser la facture.

Avant la mise en production, un test de charge simule vos pics et révèle le maillon qui cède le premier. Pour un temps fort commercial, notre guide pour préparer votre site au Black Friday et à ses pics de trafic détaille les préparatifs, du test de charge au jour J.

Infrastructure as code : une infrastructure décrite et reproductible

Serveurs, réseaux, bases de données, règles de pare-feu : tout est décrit dans des fichiers de configuration, avec Terraform ou OpenTofu, sa version dérivée restée open source, placée sous l’égide de la Linux Foundation. Ces fichiers sont versionnés comme du code : chaque changement est relu, daté et peut être annulé. Concrètement :

• la recette et la production sont identiques : elles sortent du même code, aux paramètres près (taille, noms de domaine) ; une version validée en recette ne bute pas, en production, sur un réglage oublié ;
• fini le serveur « configuré à la main » : la configuration ne dépend plus de la mémoire d’une seule personne ;
• une reconstruction sans tâtonnements : après un incident grave, l’infrastructure se recrée à partir du code, puis les données sont restaurées depuis les sauvegardes ;
• aucun secret dans le code : mots de passe et clés d’API sont rangés dans un coffre dédié, jamais écrits en clair dans les fichiers.

Déploiement automatisé (CI/CD) : mettre en production sans trembler

Chaque modification, du code de l’application comme de l’infrastructure, suit la même chaîne automatisée : tests, construction, déploiement en recette, puis en production une fois la version validée — on parle alors de livraison continue. Une mise en production devient un geste courant, et non plus une opération risquée que l’on repousse.

Les déploiements se font sans interruption : la nouvelle version démarre à côté de l’ancienne et ne reçoit le trafic qu’une fois prête. Si quelque chose cloche, le retour à la version précédente tient en une commande, à condition que les changements de base de données restent compatibles avec elle : nous les préparons dans ce sens. Pour comprendre ce qui se joue à chaque étape, lisez notre article qui explique le pipeline CI/CD sans jargon.

Haute disponibilité et plan de reprise testé

Un hébergement haute disponibilité supprime les points de défaillance uniques : plusieurs instances de l’application réparties dans au moins deux zones de disponibilité — des centres de données distincts d’une même région, alimentés et raccordés séparément —, une base de données répliquée qui bascule automatiquement sur sa copie, un répartiteur qui contourne la zone en panne. Si une zone s’arrête, vos visiteurs sont servis depuis une autre.

La réplication protège d’une panne, pas d’une erreur : une suppression accidentelle est recopiée aussitôt. Les sauvegardes, restaurables à un instant précis, partent donc dans une autre région que la production. Dans sa fiche consacrée à la sécurité du cloud, la CNIL range parmi les erreurs à éviter le fait de sauvegarder dans le centre de données qui héberge les données, et rappelle que la sécurité n’incombe pas au seul fournisseur. L’incendie d’un centre de données à Strasbourg, en mars 2021, l’a montré : un bâtiment détruit, le courant coupé sur tout le site, et des sauvegardes gardées sur place perdues ou inaccessibles avec les serveurs.

Quand l’imprévu frappait, Phileas Fogg improvisait : un éléphant acheté en pleine Inde, un bateau affrété au dernier moment. Une infrastructure ne devrait rien devoir à l’improvisation. Un plan de reprise d’activité (PRA) n’a de valeur que s’il a été exercé : nous le testons avant la mise en production, par une restauration complète chronométrée, puis à intervalles réguliers, comme le recommande la CNIL dans sa fiche sur la continuité et la reprise d’activité.

Quel niveau de disponibilité viser ?

Voici ce que représentent les pourcentages souvent affichés, sur une année de 365 jours et un mois de 30 jours (valeurs arrondies à la minute) :

Viser 99,99 %, c’est s’en tenir à quatre minutes d’arrêt par mois : moins que le temps de réveiller quelqu’un. Ce niveau suppose donc une reprise entièrement automatique — plusieurs zones, base répliquée, déploiements sans interruption — et une astreinte jour et nuit, toute l’année, pour le reste. Et la disponibilité promise par un fournisseur porte sur ses propres services, pas sur votre application : une mise à jour ratée ou une base saturée peuvent arrêter un site posé sur une infrastructure parfaitement disponible.

Pour fixer votre objectif, comparez ce que vous coûte une heure d’arrêt — ventes perdues, équipes bloquées, clients à rassurer — au surcoût de chaque niveau supplémentaire : zones en plus, base répliquée, astreinte. C’est ce calcul, plutôt que le pourcentage le plus flatteur, que nous posons avec vous pendant l’audit.

Migrer vers le cloud avec un plan de retour arrière

Une migration vers le cloud se prépare comme un déménagement où l’on garderait les clés de l’ancien logement jusqu’à être sûr du nouveau :

1. inventaire de l’existant et, si besoin, audit de sécurité de votre site actuel, pour ne pas emporter de failles dans les cartons ;
2. construction de la nouvelle infrastructure à côté de l’ancienne, puis synchronisation des données ;
3. répétition générale : migration à blanc, test de charge, test de restauration ;
4. durée de mise en cache DNS abaissée quelques jours avant, puis bascule à un moment creux choisi avec vous — pour une boutique, loin des temps forts commerciaux, jamais à la veille des soldes ;
5. ancienne infrastructure laissée en place le temps de valider la nouvelle : si un critère d’échec fixé à l’avance est atteint, nous rebasculons, en reportant les commandes et les données saisies entre-temps.

Exploitation et infogérance cloud : supervision, alertes, comptes rendus

En production, l’infrastructure est surveillée en continu : disponibilité vue de l’extérieur, temps de réponse, taux d’erreur, saturation des serveurs et de la base, échéance des certificats, dépenses. Les mécanismes automatiques — redémarrage, bascule, ajout d’instances — agissent à toute heure, et les alertes qui demandent une décision humaine nous parviennent aussitôt.

Nous intervenons aux horaires du studio, du lundi au vendredi de 9 h à 18 h. Pour une période critique — soldes, Black Friday, lancement d’un produit —, une astreinte peut être organisée sur devis. Des comptes rendus écrits retracent les incidents, la disponibilité mesurée, l’évolution des coûts et les ajustements à prévoir.

Une facture maîtrisée, une infrastructure qui reste la vôtre

Le cloud se paie à l’usage : c’est sa force, et un risque quand personne ne regarde la facture. Nous dimensionnons au juste besoin, réduisons la capacité aux heures creuses quand l’application le permet et posons une alerte budgétaire dès le premier jour. Chaque ressource est étiquetée par environnement : vous savez ce que coûtent la recette, la production et les sauvegardes, et les ressources oubliées — un serveur de test, un disque orphelin — sont repérées puis, avec votre accord, supprimées.

Quand une part de la charge est stable, un engagement de durée auprès du fournisseur, s’il en propose, peut alléger la facture. Nous ne le recommandons qu’une fois la consommation réelle connue.

Le compte chez le fournisseur est ouvert à votre nom et sa facture vous est adressée directement. Le code d’infrastructure, documenté, vous est remis avec les procédures d’exploitation et de reprise. Nous privilégions des briques standard que l’on retrouve chez plusieurs fournisseurs, comme les conteneurs et PostgreSQL, et des outils, Terraform ou OpenTofu, qui pilotent chacun des fournisseurs cités plus haut : changer d’hébergeur reste un projet, pas une impasse.

Le droit européen va dans le même sens. Le règlement européen sur les données (Data Act), applicable depuis le 12 septembre 2025, supprimera à partir du 12 janvier 2027 les frais de changement de fournisseur cloud, frais de sortie des données compris ; d’ici là, un fournisseur peut encore facturer les coûts liés au changement, précise la Commission européenne dans sa présentation du Data Act.

Budget et délais

La mise en place — audit, architecture, code d’infrastructure, pipeline, tests et migration — démarre à 4 900 € HT, pour 4 à 8 semaines selon l’existant. L’exploitation est ensuite facturée au mois, à partir de 290 € HT, hors facture du fournisseur cloud, que nous estimons pendant l’audit. La grille tarifaire de l’infrastructure cloud précise ce qui fait varier ces montants. Pour faire le point sur votre hébergement actuel et vos prochains pics, le premier rendez-vous de 30 minutes est gratuit, à notre studio à Nantes ou en visio.