Cluster dédié par client, stack LAMP durcie, scaling vertical et horizontal à chaud, supervision 24/7. Quatre paliers, du bare metal infogéré à l'auto-scaling horizontal multi-DC.
| Metric | Valeur | Unité | Contexte |
|---|---|---|---|
| peak.requests | 10 000 | req/s | cluster horizontal |
| sla.uptime | 99,9 | % | contractuel |
| backup.points | 9+ | restaurations | 2 pays UE distincts |
| monitoring.probes | 100+ | sondes | par cluster |
02 / CMS COUVERTS
Pas de stack générique.
Chaque CMS a sa configuration PHP, son schéma de cache, ses jobs cron, son indexation. Nous arrivons sur votre projet avec les playbooks Ansible déjà tunés pour la plateforme cible.
Cœur de métier. Mid-market et grands catalogues.
PHP-FPM tuné, OPcache, OpenSearch, Varnish full-page, indexers contrôlés.
WordPress + WooCommerce, du shop vitrine au catalogue dense.
object-cache Redis, page-cache Varnish, durcissement wp-config et XML-RPC.
Prestashop 1.7 et 8, hooks et modules tiers maîtrisés.
cache hybride Smarty + Redis, isolation media, profilage des modules lourds.
Symfony-based, projets headless et architectures custom.
composer optim, Doctrine cache, FrankenPHP ou PHP-FPM selon le projet.
Gestion produit centralisée pour catalogues complexes.
jobs Akeneo, queues, exports planifiés, sizing RAM dédié.
Sites éditoriaux denses, applicatifs métier.
cache page Varnish, drush, supervision worker queue.
03 / ARCHITECTURE & PROGRESSION
Du shop au cluster horizontal.
Chaque palier monte en résilience et en capacité. Le module Haute Disponibilité se greffe à partir du niveau 3, recommandé sur le niveau 4.
1 serveur dédié, scaling vertical à chaud.
Choix d'architecture mono-serveur assumé : meilleur rapport perf / coût pour la majorité des sites mid-market.
1 à 2 webservers auto-scale + 1 serveur BDD externe.
Le découplage web / DB lève le premier goulot, sans complexifier la stack.
2 à 4 webservers, master / slave BDD, 2 nœuds OpenSearch.
Profil typique pour les boutiques qui ne peuvent plus se permettre une coupure de 24 h pour restauration.
1 à 30 webservers, jusqu'à 10 000 req/s soutenues.
10 000 req/s pic démontré par cluster. Architecture multi-zone, failover transparent.
04 / STACK TECHNIQUE
Composants éprouvés, intégrés, tunés.
Aucune brique exotique. Chaque composant a fait ses preuves en production sur des dizaines de boutiques. La configuration est versionnée dans Ansible, l'inventaire centralisé.
| layer | composant | rôle |
|---|---|---|
| cdn.edge | Cloudflare | CDN, WAF, DDoS mitigation, anti-bot Proof-of-Work, Load Balancer (option HA). |
| web.balancer | Nginx LB | Health-checks actifs, bascule auto, session affinity. Alternative Cloudflare LB. |
| web.runtime | Apache / NGINX + PHP-FPM | Pool PHP-FPM dédié par projet, OPcache, JIT activable selon CMS. |
| cache.page | Varnish | Cache full-page mémoire, VCL tuné par CMS, purge ciblée par tag. |
| cache.object | Redis Sentinel | Sessions partagées, object cache, file d'attente. Bascule auto en HA. |
| db | MariaDB / Galera | Master-slave par défaut, Galera multi-master synchrone en module HA. |
| search | OpenSearch / ElasticSearch | Cluster 2+ nœuds, indexation contrôlée, requêtes catalog tunées. |
| sync.files | lsyncd | Synchronisation médias temps réel entre nœuds (HA, scale horizontal). |
| config | Ansible | Playbooks versionnés, inventaire centralisé, déploiements reproductibles. |
| os | Debian stable durci | Patches sécurité J+1, chroot par vhost, utilisateur Unix dédié par projet. |
05 / ARCHITECTURE HA
Placement multi-rack, quorum strict.
La perte d'un nœud (rack, machine, hyperviseur) est absorbée sans interruption. La perte du datacenter majoritaire bascule en mode dégradé contrôlé, intervention manuelle objectif 15 à 30 min.
06 / SUPERVISION & SLA
100+ sondes par cluster, 24/7.
Monit, Munin, sondes applicatives, corrélation événements externes. Alerting SMS d'astreinte avec escalade automatique. La résolution prime sur la communication, le rapport vient ensuite.
| key | valeur | unité | commentaire |
|---|---|---|---|
| sla.uptime | 99,9 | % | Disponibilité mensuelle contractuelle. |
| sla.high_priority.h | 30 | min | Intervention haute priorité, heures ouvrées. |
| sla.high_priority.x | 6 | h | Intervention haute priorité, heures non ouvrées. |
| sla.network | 2 | h | Rétablissement réseau. |
| sla.hardware | 2 | h | Rétablissement matériel (hors délai fournisseur DC). |
| monitoring.probes | 100 | + | Sondes système et applicatives par cluster. |
| support.window | 24/7 | Astreinte permanente, ingénieur senior joignable. | |
| team.intervention | <10 | min | Intervention réelle constatée heures ouvrées (objectif, non contractuel). |
SLA contractuels définis dans les Conditions Particulières d'Hébergement Cloud (article 5). Les délais d'intervention réels observés sont communément inférieurs aux délais contractuels, sans constituer un engagement.
Vues console, sondes en production
07 / PRA & SAUVEGARDES
RPO / RTO par profil de résilience.
Trois profils : Standard (mono-VM), Résilience (master-slave ou LB), Haute Disponibilité (Galera + Sentinel). Document PRA complet disponible sur demande, annexé aux Conditions Particulières.
Stockage sur au moins 2 serveurs distincts, 2 pays UE différents, chez des fournisseurs distincts du serveur de production. Tier-3 indépendant côté client recommandé.
| type | fréquence | rétention |
|---|---|---|
| Quotidienne | Tous les jours | 7 jours glissants |
| Bimensuelle | Le 1er du mois | Conservée 1 cycle |
| Bimensuelle | Le 16 du mois | Conservée 1 cycle |
Objectifs opérationnels en heures ouvrées. Cibles de conception sur le profil HA, validées en phase de recette d'un mois avant mise en production.
| scénario | standard | HA |
|---|---|---|
| Service applicatif défaillant | 0 / quelques minutes | 0 / automatique (~secondes) |
| VM inaccessible, panne matérielle | 24 h / objectif 90 min | 0 / automatique (~secondes) |
| Perte datacenter, sinistre majeur | 24 h / objectif 1 à 2 h | 0 / automatique si multi-DC |
| Corruption base de données | 24 h / objectif 1 à 4 h | 0 / 1 nœud auto, multi 1 h |
CONSOLE.FAST-MAGE.COM
Chaque sauvegarde est tracée : horodatage, périmètre (fichiers, base de données, complet), taille, serveur de stockage cible. La restauration s'ouvre par ticket depuis cette vue, sans passer par un support tier 1.
L'historique est conservé pendant toute la durée du contrat. Audit possible côté client à tout moment, sans demande préalable.
08 / SOUVERAINETÉ & DATACENTERS
RGPD, Debian durci, PCI compliant.
Sélection sur critères techniques (latence, capacité, localisation) et juridiques. Aucune dépendance forcée à un hyperscaler non-européen, sauf demande explicite du client.
| fournisseur | localisations principales | type |
|---|---|---|
| OVH | Roubaix, Strasbourg, Gravelines | Bare metal |
| Scaleway | Paris, Amsterdam, Varsovie | Bare metal + cloud |
| Hetzner | Falkenstein, Nuremberg, Helsinki | Bare metal |
| Upcloud | Helsinki, Francfort, Madrid | Cloud VM |
| Google Cloud | Régions UE (sur demande) | Cloud, projets ponctuels |
| AWS | Régions UE (sur demande) | Cloud, projets ponctuels |
Patches sécurité J+1, isolation LXC stricte par client, pool PHP-FPM dédié par projet, chroot Linux par vhost.
Matériel PCI compliant sur les offres concernées, données strictement en UE, audit de conformité disponible à la demande.
Validation par un pair en heures ouvrées, évaluation d'impact, rollback rapide, notification systématique. Protocole documenté.
09 / RETOURS CLIENTS
~120 clients actifs, 60 % en reco agence.
Magento, Prestashop, WooCommerce, Sylius. Mid-market et grands catalogues. La majorité de notre croissance vient des recommandations d'agences et de DSI.
« La réactivité des équipes nous permet de faire évoluer nos sites rapidement, et de réagir vite en cas d'incident. »
« La réactivité et l'efficacité de Fast-Mage nous permettent d'améliorer notre infrastructure. »
06, QUESTIONS FRÉQUENTES
Cinq points clés.
Réponses vérifiées par nos ingénieurs. Si une question manque, écrivez-nous : on répond rapidement, sans script commercial.
Sur défaillance isolée d'un nœud, le service est conçu pour basculer sans intervention humaine via Galera, Redis Sentinel et le Load Balancer health-checks. Sur perte du datacenter majoritaire (2 nœuds), une intervention manuelle est nécessaire pour bootstrap le nœud restant en cluster autonome, objectif 15 à 30 min en heures ouvrées. Les RPO/RTO du profil HA sont des objectifs de conception validés en phase de recette d'un mois minimum avant mise en production.
Minimum 9 points de restauration à tout moment : 7 sauvegardes quotidiennes glissantes plus 2 sauvegardes bimensuelles (1er et 16 du mois). Sauvegardes stockées sur au moins 2 serveurs distincts, dans 2 pays européens différents, chez des fournisseurs distincts du serveur de production. Restauration sur demande par email ou téléphone, périmètre fichier / dossier / base de données / complet. Une stratégie de sauvegarde Tier-3 indépendante reste recommandée côté client.
Données hébergées en Union européenne, RGPD applicable de bout en bout. Fournisseurs d'infrastructure européens : OVH, Scaleway, Hetzner, Upcloud. Debian stable durci, patches sécurité appliqués J+1, isolation LXC stricte entre clients. Matériel PCI compliant disponible sur les offres concernées (CPU Ryzen, cache L3 substantiel, DDR5). Audit de conformité possible à la demande.
Audit de l'existant, montée d'une pré-production identique, synchronisation des données, recettage côté staging avant bascule. La bascule DNS est planifiée hors heures de trafic, avec rollback prêt. Le module Cloudflare est configuré et validé par un pair avant activation. Aucune coupure visible côté client final pour la majorité des migrations.
À un ingénieur senior d'astreinte qui connaît votre infrastructure. Détection automatique via les sondes de supervision, SMS d'escalade, prise en charge effective sous 20 à 30 min en heures non ouvrées. Pas de support tier 1 jetable, pas de script de qualification. Notification client par email ou téléphone dès que la situation le permet, rapport de fin d'intervention transmis pour tout incident majeur.
Tous nos paliers supportent Magento 2, WooCommerce, Prestashop, Sylius, Akeneo, Drupal, Symfony. Le choix du palier dépend du trafic réel, de la taille du catalogue et de la tolérance à l'indisponibilité, pas du CMS. Un audit gratuit cadre le sizing avant tout devis.
Une question reste sans réponse ?
Nous contacter →CONTACT, AUDIT GRATUIT
Audit gratuit, réponse sous 24h ouvrées.
Décrivez votre stack et votre situation, un ingénieur Fast-Mage vous rappelle. Pas de commercial, pas de script. L'audit reste à vous, même si vous ne migrez pas.