Audit serveur web (Apache/Nginx, PHP-FPM, MySQL) : performance & sécurité

Votre site est lent, tombe en erreur 502/504, ou manque de sécurité ? Votre serveur consomme 100% de CPU dès 50 visiteurs simultanés ? Je réalise un audit technique complet de votre serveur (Ubuntu/Debian, OVH/Scaleway, Contabo...) pour réduire le TTFB, stabiliser la charge et durcir la sécurité.

L'audit couvre l'ensemble de la pile technique : protocoles réseau (TLS/HTTP2), configuration serveur web (Nginx/Apache), optimisation PHP-FPM, analyse des requêtes MySQL lentes, sécurisation système, et mise en place d'outils de monitoring. Livrable : rapport clair et priorisé avec possibilité d'exécuter les correctifs moi-même.

Pourquoi faire un audit serveur web ?

Les symptômes qui doivent vous alerter

Votre infrastructure serveur montre des signes de faiblesse si vous rencontrez un ou plusieurs de ces problèmes :

Performance dégradée :

• Temps de réponse serveur (TTFB) supérieur à 600ms, alors que l'objectif est < 200ms
• Le site devient lent ou inaccessible dès que le trafic augmente (50-100 visiteurs simultanés)
• Les pages mettent 5-10 secondes à charger alors que le HTML seul devrait être servi en < 1 seconde
• Les Core Web Vitals sont en zone rouge (LCP > 4s, TTFB > 800ms)

Erreurs récurrentes :

• Erreurs 502 Bad Gateway ou 504 Gateway Timeout plusieurs fois par jour
• Erreurs 500 Internal Server Error sans cause apparente dans les logs applicatifs
• Connexions PHP-FPM qui saturent ("max children reached")
• MySQL qui refuse de nouvelles connexions ("Too many connections")

Problèmes de stabilité :

• Le serveur nécessite des redémarrages fréquents (plusieurs fois par semaine)
• Consommation CPU ou RAM à 90-100% en permanence sans pic de trafic justifié
• Les processus PHP-FPM ou MySQL se terminent de façon aléatoire (OOM Killer)
• Les logs montrent des dizaines de requêtes lentes (> 2 secondes) chaque jour

Vulnérabilités de sécurité :

• Certificat SSL/TLS expiré ou configuration faible (ciphers obsolètes, pas de HSTS)
• Pas de firewall configuré ou règles trop permissives
• Aucune protection contre les attaques par force brute (fail2ban absent)
• Versions de PHP, MySQL ou système d'exploitation obsolètes et non patchées
• Accès SSH en root avec mot de passe (au lieu de clés SSH)

Impact business de ces problèmes

Un serveur mal configuré a des conséquences directes et mesurables sur votre activité :

Perte de revenus : Un site qui met 5 secondes à charger perd 20% de ses visiteurs (étude Google). Pour un site e-commerce à 50 000€/mois, cela représente 10 000€ de manque à gagner mensuel.

Pénalités SEO : Google pénalise les sites lents dans son algorithme. Une page qui passe de 2 secondes à 5 secondes de chargement peut perdre 30-50% de son trafic organique en quelques mois.

Coûts d'infrastructure gonflés : Un serveur mal optimisé nécessite souvent un upgrade matériel coûteux (passage de 4 à 8 CPU, doublement de la RAM) alors qu'une simple optimisation logicielle résoudrait le problème pour 10 fois moins cher.

Risque de piratage : 43% des cyberattaques ciblent les PME (rapport Verizon 2024). Un serveur non durci est une porte d'entrée pour du phishing, du vol de données clients, ou du ransomware.

Ce que j'analyse en détail

Mon audit serveur couvre 7 couches techniques essentielles, avec des mesures avant/après pour quantifier les améliorations.

1. Réseau & protocole

Ce que je vérifie :

• Configuration TLS/HTTPS : version du protocole (TLS 1.2 minimum, idéalement 1.3), suites de chiffrement sécurisées, chaîne de certificats complète
• Headers de sécurité : HSTS, CSP, X-Frame-Options, X-Content-Type-Options
• HTTP/2 ou HTTP/3 activé pour multiplexing et compression headers
• Compression Gzip/Brotli configurée pour HTML/CSS/JS/JSON
• DNS : temps de résolution, configuration DNSSEC si applicable

Ce que ça révèle : Des ciphers obsolètes (RC4, 3DES) rendent votre site vulnérable aux attaques BEAST ou POODLE. L'absence de HTTP/2 coûte 20-30% de vitesse sur les pages avec beaucoup de ressources. Un TTFB DNS élevé (> 100ms) ralentit systématiquement toutes les requêtes.

Impact mesurable : Passage à TLS 1.3 + HTTP/2 + Brotli = réduction de 25-40% du temps de chargement total et grade A+ sur SSL Labs.

2. Configuration Nginx / Apache

Ce que je vérifie :

• Cache statique : directives expires, cache-control, etag pour images/CSS/JS
• Headers de compression : gzip_types, brotli_types
• Logs : format personnalisé avec $request_time et $upstream_response_time pour débugger
• Rate limiting : protection contre les scrapers et bots agressifs
• WAF basique : ModSecurity ou Nginx limit_req pour bloquer les patterns d'attaque courants
• Fichiers de configuration : worker_processes, worker_connections, keepalive_timeout, client_max_body_size

Ce que ça révèle : Des worker_connections à 768 au lieu de 4096 limitent artificiellement le nombre de connexions simultanées. L'absence de cache statique force le navigateur à re-télécharger les assets à chaque visite. Un client_max_body_size à 2M bloque l'upload de fichiers média.

Impact mesurable : Configuration optimale = 50-60% de bande passante économisée grâce au cache navigateur + capacité de traiter 4x plus de connexions simultanées.

3. PHP-FPM : le goulot d'étranglement invisible

Ce que je vérifie :

• Stratégie de gestion des processus : pm = dynamic vs static vs ondemand
• Dimensionnement : pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers
• Limites : pm.max_requests (recyclage des workers), request_timeout, request_terminate_timeout
• Opcache : opcache.memory_consumption, opcache.interned_strings_buffer, opcache.max_accelerated_files, taux de hit
• Limites PHP : memory_limit, max_execution_time, post_max_size, upload_max_filesize
• Logs slow : activation et analyse des requêtes PHP lentes (> 1s)

Ce que ça révèle : C'est LE point de blocage n°1 sur 80% des serveurs. Exemple type : pm.max_children = 5 sur un serveur 4 CPU → dès 6 requêtes simultanées, les suivantes sont mises en queue, créant des timeouts.

Un opcache mal configuré (trop petit, pas de preloading PHP 8.x) force PHP à recompiler les scripts à chaque requête, multipliant la charge CPU par 5-10x.

Impact mesurable : Passage de pm.max_children = 5 à pm.max_children = 40 (dimensionné selon RAM disponible) + opcache optimisé = réduction de 70% du TTFB + disparition des erreurs "502 Bad Gateway".

Exemple concret : Site WordPress avec WooCommerce, 4GB RAM, pm.max_children = 5 (défaut).

• Avant : 502 errors dès 8 visiteurs simultanés, TTFB 3-6 secondes
• Après : pm.max_children = 30, pm = dynamic, opcache activé → TTFB 0.4s, aucun 502 jusqu'à 100 visiteurs simultanés

4. Base de données MySQL / MariaDB

Ce que je vérifie :

• Configuration connexions : max_connections, wait_timeout, interactive_timeout
• Buffers et cache : innodb_buffer_pool_size, query_cache_size (si MySQL < 8.0), tmp_table_size
• Slow query log : activation et analyse des requêtes > 1 seconde
• Index manquants : EXPLAIN sur les requêtes les plus fréquentes pour identifier les full table scans
• Verrouillage : détection des deadlocks et transactions longues
• Optimisation tables : fragmentation, tables non utilisées, ANALYZE TABLE

Ce que ça révèle : Un innodb_buffer_pool_size à 128MB (défaut) sur un serveur avec 16GB RAM = MySQL ne peut pas mettre en cache les données fréquentes et sollicite constamment le disque.

Des requêtes sans index forcent MySQL à scanner 500 000 lignes au lieu de 10, multipliant le temps d'exécution par 5000x (de 0.001s à 5s).

Impact mesurable : innodb_buffer_pool_size ajusté à 70% de la RAM + ajout de 3-5 index stratégiques = réduction de 80% des slow queries + temps de réponse page divisé par 3.

5. Performance applicative & TTFB

Ce que je mesure :

• TTFB (Time To First Byte) depuis différents points géographiques : objectif < 200ms pour l'Europe
• LCP (Largest Contentful Paint) : objectif < 2.5s
• Temps de génération HTML pur (sans assets) : doit être < 400ms pour une page dynamique
• Nombre de requêtes SQL par page : plus de 50 requêtes = problème N+1 à investiguer
• Taille et poids des assets : images non optimisées, JS/CSS non minifiés
• Stratégie de cache applicatif : Redis/Memcached, cache HTML statique (Varnish, nginx fastcgi_cache)

Ce que ça révèle : Un TTFB de 2-4 secondes indique que le serveur met ce temps juste pour commencer à envoyer les données. Même avec une connexion fibre, l'utilisateur attend. Le problème est souvent une combinaison PHP lent + requêtes MySQL non optimisées + absence de cache.

Impact mesurable : Optimisation combinée (PHP-FPM + MySQL + cache Redis) = TTFB qui passe de 2.8s à 0.3s, LCP de 6s à 2.1s → passage dans les "Good" des Core Web Vitals.

6. Sécurité système & durcissement

Ce que je vérifie :

• Firewall : UFW ou iptables configuré, ports ouverts minimaux (22, 80, 443), blocage des scans de ports
• Fail2ban : protection SSH, HTTP, MySQL contre les attaques par force brute
• Accès SSH : désactivation du root login, authentification par clés SSH uniquement, port non standard
• Utilisateurs et permissions : pas d'exécution de services en root, séparation des utilisateurs web/db
• Mises à jour : versions de PHP, MySQL, système d'exploitation à jour avec patches de sécurité
• Sauvegardes : fréquence, rétention, test de restauration, stockage hors serveur
• Rotation des logs : logrotate configuré, compression, suppression automatique des vieux logs
• Surveillance intrusion : détection de fichiers modifiés, surveillance de l'intégrité système

Ce que ça révèle : 80% des serveurs audités ont fail2ban absent ou mal configuré, permettant des milliers de tentatives de connexion SSH par jour. L'absence de backups testés = risque de perte totale de données en cas de crash disque ou ransomware.

Impact mesurable : Durcissement complet = réduction de 95% des tentatives d'intrusion (logs fail2ban) + assurance de restauration en < 2h en cas d'incident majeur.

7. Observabilité & monitoring

Ce que je mets en place :

• Analyse des logs : erreurs PHP, erreurs Nginx, slow queries MySQL, erreurs système
• Métriques serveur : CPU, RAM, disque, réseau, swap
• Alerting basique : email/SMS si CPU > 90% pendant 5 min, disque > 85%, service down
• Outils : Netdata (léger, gratuit) ou New Relic (si budget)
• Dashboard simple : un coup d'œil pour voir la santé du serveur

Impact : Détection proactive : alerte reçue 10 minutes avant que le serveur ne tombe au lieu de découvrir le problème via des clients mécontents. Réduction du MTTR (Mean Time To Repair) de 2 heures à 15 minutes.

Ma méthodologie complète

Phase 1 : Accès & analyse préliminaire (30 min)

Accès :

• Connexion SSH (clé publique fournie) ou accès panel OVH/Plesk/ISPConfig
• Accès lecture aux logs (/var/log/nginx, /var/log/php-fpm, /var/log/mysql)
• Identifiants MySQL lecture seule pour analyse des slow queries

Collecte initiale :

• Inventaire : versions PHP, MySQL, système, serveur web
• Statistiques : uptime, load average, utilisation CPU/RAM/disque actuelle
• Lecture rapide des logs : repérage des erreurs récurrentes

Phase 2 : Tests de performance & charge (1h)

Mesures baseline :

• TTFB depuis 3 localisations différentes (Europe, US, Asie) avec curl/webpagetest
• Load test : simulation de 10, 50, 100 utilisateurs simultanés avec Apache Bench ou k6
• Profiling PHP : activation de Xdebug ou Blackfire pour identifier les fonctions lentes
• Analyse MySQL : top 20 des requêtes lentes via pt-query-digest (Percona Toolkit)

Identification des goulots : Le load test révèle exactement où ça casse : est-ce PHP-FPM qui sature ? MySQL qui lock ? La RAM qui swape ?

Phase 3 : Analyse de sécurité (45 min)

Scan de vulnérabilités :

• Test SSL : ssllabs.com, testssl.sh pour identifier les faiblesses TLS
• Scan ports ouverts : nmap pour détecter les services exposés non nécessaires
• Vérification des CVE : versions de PHP/MySQL obsolètes avec vulnérabilités connues
• Audit fichiers : fichiers avec permissions 777, scripts backdoor potentiels

Review configuration :

• Analyse du /etc/ssh/sshd_config, firewall rules, fail2ban jails
• Vérification de l'existence et validité des backups

Phase 4 : Analyse des configurations (1h)

Deep dive dans les configs :

• Nginx/Apache : lecture ligne par ligne des fichiers de config + benchmarks
• PHP-FPM : calcul de la mémoire totale consommée (pm.max_children * memory_limit) vs RAM disponible
• MySQL : analyse du my.cnf, recommandations MySQLTuner
• Système : configuration des limites (ulimit), swap, kernel parameters

Phase 5 : Rédaction du rapport (1-2h)

Structure du rapport :

1. Executive Summary (2 pages)

• Les 3 problèmes critiques identifiés
• Impact business estimé (ex: perte de 15% du trafic SEO, 25% de visiteurs qui abandonnent)
• Budget correctifs : 0-500€ (config), 500-1500€ (optimisations complexes), > 1500€ (migration/upgrade matériel)

2. Diagnostics détaillés (5-10 pages)

• Chaque problème documenté avec captures d'écran, extraits de logs, métriques
• Explication technique accessible (pas de jargon inutile)
• Gravité : Critique / Important / Opportunité

3. Plan d'actions priorisé (2-3 pages) Tableau : Action | Impact estimé | Complexité | Temps | Coût

Exemple :

• Augmenter pm.max_children de 5 à 30 | Réduction 70% erreurs 502 | Faible | 10 min | Inclus
• Ajouter 3 index MySQL sur table orders | Requêtes 50x plus rapides | Moyen | 1h | Inclus
• Migrer vers serveur 8GB RAM | Tient la charge 3x | Élevé | 4h | 150€ migration

4. Recommandations long terme

• Plan de monitoring continu
• Fréquence de mise à jour recommandée
• Roadmap d'amélioration sur 6-12 mois

Cas client concret : Site e-commerce sous WooCommerce

Contexte initial

Client : Boutique en ligne spécialisée dans les produits artisanaux, 500-800 visiteurs/jour, 5000 produits, panier moyen 85€.

Infrastructure :

• VPS OVH Comfort (4 vCPU, 4GB RAM)
• Ubuntu 20.04, Nginx 1.18, PHP 7.4, MySQL 5.7
• WordPress 6.1 + WooCommerce 7.5 + 15 plugins actifs

Symptômes rapportés

• Pics de lenteur tous les jours entre 14h-16h (pause déjeuner = trafic max)
• Erreurs 502 Bad Gateway 2-3 fois par jour nécessitant un redémarrage PHP-FPM
• Pages produits qui mettent 6-8 secondes à charger
• Google Search Console signale "Poor" sur 70% des pages (LCP > 4s)
• Taux de rebond passé de 45% à 62% en 3 mois
• Perte estimée : 200-300€/jour de ventes manquées

Diagnostics de l'audit (2h30)

1. PHP-FPM : configuration catastrophique

pm = dynamic
pm.max_children = 5 ATTENTION: (CRITIQUE)
pm.start_servers = 2
memory_limit = 128M

Calcul : 5 enfants × 128MB = 640MB max pour PHP alors que 4GB RAM disponibles → Dès 6 requêtes simultanées, mise en queue → timeout 502

2. MySQL : requêtes lentes et index manquants

• 847 requêtes > 2 secondes dans les dernières 24h
• Requête sur wp_postmeta sans index : 3.8s pour filtrer par meta_key
• innodb_buffer_pool_size = 128M (défaut) alors que base de données = 2.1GB

3. Opcache PHP : désactivé

• PHP recompile tous les fichiers WordPress/WooCommerce à chaque requête
• Charge CPU inutile multipliée par 8-10x

4. Pas de cache applicatif

• Aucun plugin de cache HTML (WP Super Cache, W3 Total Cache)
• Chaque page recalculée à chaque visite, même pour visiteurs non connectés

5. Sécurité faible

• Fail2ban non installé : 3200 tentatives de login SSH/jour
• PHP 7.4 : 12 CVE critiques non patchées (PHP 8.1 disponible)

Correctifs appliqués (3h)

PHP-FPM (15 min)

pm.max_children = 30 (4GB RAM / 130MB par enfant)
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500

Opcache (5 min)

opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 10000
opcache.validate_timestamps = 0 (prod)
opcache.enable_cli = 1

MySQL (45 min)

-- Ajout index manquant
ALTER TABLE wp_postmeta ADD INDEX meta_key_value (meta_key, meta_value(20));
-- Configuration
innodb_buffer_pool_size = 2G (50% de la RAM)
max_connections = 200
query_cache_size = 0 (inutile MySQL 5.7+)

Cache applicatif (30 min)

• Installation WP Rocket (licence client)
• Configuration : cache HTML, minification CSS/JS, lazy loading images
• Génération du cache pour top 500 pages

Sécurité (1h)

• Mise à jour PHP 7.4 → 8.1
• Installation fail2ban avec jails SSH + HTTP
• Durcissement SSH : désactivation root, clés uniquement
• Backups automatiques quotidiens vers S3

Résultats mesurés (7 jours après)

Performance :

• TTFB : ~~3.2s~~ → 0.4s (-87%)
• LCP : ~~6.1s~~ → 2.0s (-67%)
• Page produit : ~~7.2s~~ → 1.8s (-75%)
• Core Web Vitals : ~~12% Good~~ → 89% Good

Stabilité :

• Erreurs 502 : ~~2-3/jour~~ → 0 en 7 jours
• Load average : ~~4.5~~ → 0.8 (sur 4 CPU)
• RAM utilisée : ~~92%~~ → 65%

Business :

• Taux de rebond : ~~62%~~ → 48% (-14 points)
• Temps sur site : +22%
• Conversions : +18% (calculé sur 7 jours vs semaine précédente)
• Estimation : +280€/jour de CA soit +8400€/mois

Sécurité :

• Tentatives SSH bloquées : 3200/jour → 0 (IP bannies automatiquement)
• Vulnérabilités CVE : ~~12 critiques~~ → 0

Coût total : Audit (490€) + Exécution (350€) + Licence WP Rocket (59€/an) = 899€ HT ROI : Rentabilisé en 3 jours de CA supplémentaire

Audit serveur vs autres types d'audits

Il est important de bien distinguer les différents types d'audits web, car ils ne couvrent pas les mêmes aspects :

Mon conseil : Pour un site qui rame, commencez toujours par l'audit serveur. Inutile d'optimiser vos images si votre TTFB est à 4 secondes à cause de PHP-FPM mal configuré.

Checklist : Avez-vous besoin d'un audit serveur ?

Répondez honnêtement aux questions suivantes. Si vous cochez 3 cases ou plus, un audit serveur est fortement recommandé.

• [ ] Mon site met plus de 3 secondes à charger sur une bonne connexion
• [ ] J'ai des erreurs 502, 504 ou 500 au moins une fois par semaine
• [ ] Mon serveur nécessite un redémarrage manuel au moins une fois par mois
• [ ] Je ne connais pas la valeur de pm.max_children de mon PHP-FPM
• [ ] Mon site ralentit fortement quand j'ai 50+ visiteurs simultanés
• [ ] Je n'ai jamais optimisé ma base de données MySQL
• [ ] Mon certificat SSL a un grade < A sur SSL Labs
• [ ] Je n'ai pas fait de mise à jour système ou PHP depuis plus de 6 mois
• [ ] Je n'ai pas de système de sauvegarde automatique testé
• [ ] Mon hébergeur m'a déjà contacté pour "utilisation excessive de ressources"
• [ ] Google Search Console indique "Poor" sur mes Core Web Vitals
• [ ] Mon taux de rebond a augmenté de plus de 10% ces derniers mois sans raison apparente

Score :

• 0-2 coches : Votre serveur semble OK, mais une vérification préventive tous les 12-18 mois reste recommandée
• 3-5 coches : Audit conseillé sous 1-2 mois, vous avez probablement des quick wins faciles
• 6+ coches : Audit urgent, vous perdez probablement des clients et du CA chaque jour

Livrables & déroulé

Ce que vous recevez

1. Rapport d'audit complet (PDF 15-25 pages)

• Executive summary avec top 3 problèmes critiques
• Diagnostics détaillés avec captures d'écran et extraits de logs
• Plan d'actions priorisé par impact/complexité
• Recommandations long terme

2. Fichiers de configuration optimisés

• Configurations Nginx/Apache commentées et prêtes à déployer
• Pool PHP-FPM dimensionné pour votre serveur
• Fichier my.cnf MySQL optimisé
• Scripts de monitoring et d'alerte basiques

3. Documentation procédures

• Checklist de déploiement des correctifs
• Guide de rollback en cas de problème
• Procédure de restauration backup

4. Suivi post-intervention (optionnel)

• Accès tableau de bord monitoring 30 jours
• Support email 7 jours pour questions
• Session de formation 30 min (configuration, lecture des métriques)

Déroulement typique

J0 : Premier contact

• Brief téléphonique ou visio 15 min pour comprendre vos problèmes
• Envoi d'un questionnaire technique préalable
• Devis sous 24h

J+1 à J+2 : Accès & préparation

• Création des accès SSH/panel
• Installation d'outils de monitoring non intrusifs si accepté
• Collecte des logs et métriques baseline

J+3 : Audit (2-4 heures)

• Analyse approfondie de toutes les couches (réseau, serveur, PHP, MySQL, sécurité)
• Tests de charge pour identifier les limites
• Documentation des findings en temps réel

J+4 à J+5 : Rédaction & présentation

• Rédaction du rapport complet
• Visio 30-45 min pour présenter les findings et recommandations
• Réponses à vos questions techniques

J+6 (optionnel) : Exécution des correctifs

• Sauvegarde complète système avant intervention
• Application des optimisations par ordre de priorité
• Tests de non-régression après chaque modification
• Mesures post-intervention : vérification que les objectifs sont atteints

J+7 : Validation & clôture

• Rapport de validation avec métriques avant/après
• Transfert de connaissance et formation rapide
• Documentation finale + support 7 jours

Résultats typiques après audit + optimisation

Sur la base de 40+ audits serveurs réalisés depuis 2020, voici les améliorations moyennes constatées :

Performance

• TTFB réduit de 30 à 70% : passage de 1.5-3s à 0.3-0.8s en moyenne
• LCP amélioré de 40-60% : la plupart des sites passent de "Poor" à "Good" (< 2.5s)
• Capacité de charge multipliée par 3-5x : un serveur qui crashait à 30 visiteurs simultanés tient maintenant 100-150
• Disparition des erreurs 5xx : 90% des sites n'ont plus aucune erreur 502/504 après optimisation

Sécurité

• Réduction de 95%+ des tentatives d'intrusion grâce à fail2ban
• Surface d'attaque réduite : fermeture des ports inutiles, MAJ de sécurité appliquées
• Grade SSL passant de B/C à A+ via durcissement TLS
• Conformité renforcée : RGPD (chiffrement, backups), PCI DSS (si e-commerce)

Coûts

• 30-50% d'économie sur l'infrastructure : évite souvent un upgrade serveur coûteux
• Réduction de 70-80% du temps de maintenance : moins de firefighting, monitoring proactif
• ROI moyen : 3-6 mois pour un e-commerce (via augmentation des conversions)

SEO & Conversion

• Amélioration du trafic organique de 15-30% grâce aux Core Web Vitals (facteur de ranking Google)
• Baisse du taux de rebond de 10-20 points : les visiteurs ne quittent plus à cause de la lenteur
• Augmentation du taux de conversion de 10-25% : un site rapide convertit mieux

Environnements couverts

Systèmes d'exploitation

• Ubuntu 18.04, 20.04, 22.04, 24.04 LTS
• Debian 10, 11, 12
• Autres distributions Linux sur demande (CentOS, Rocky Linux, Alpine)

Hébergeurs & infrastructures

• OVH / OVHcloud (VPS, Dedicated, Public Cloud)
• Scaleway (Instances, Elastic Metal)
• Contabo (VPS, Dedicated)
• Hetzner (Cloud, Dedicated)
• DigitalOcean, Linode, Vultr
• Serveurs dédiés on-premise

Panels d'administration

• Plesk Obsidian
• ISPConfig 3.x
• cPanel/WHM (moins d'expérience, mais faisable)
• Configuration manuelle (sans panel) : préféré pour performance maximale

Serveurs web

• Nginx 1.18+ (recommandé pour performance)
• Apache 2.4+ avec MPM Event ou Worker
• OpenLiteSpeed (sur demande)
• Configurations hybrides (Nginx reverse proxy + Apache backend)

PHP

• PHP 7.4, 8.0, 8.1, 8.2, 8.3 (toutes versions FPM)
• Support multi-versions PHP simultanées
• Extensions : opcache, APCu, Redis, Memcached, imagick, etc.

Bases de données

• MySQL 5.7, 8.0+
• MariaDB 10.3, 10.5, 10.6, 10.11+
• PostgreSQL (sur demande, moins d'expérience que MySQL)

Applications web courantes

• WordPress / WooCommerce (80% de mon expérience)
• Magento 2.x
• PrestaShop 1.7, 8.x
• Drupal 9, 10
• Laravel, Symfony, CodeIgniter (frameworks PHP)
• Applications custom PHP

Prix & délais

Formules d'audit

Audit Essentiel – 390€ HT

• Serveur simple : 1 site, stack standard (Nginx/Apache + PHP + MySQL)
• 2-3h d'analyse
• Rapport 10-15 pages avec plan d'actions priorisé
• Fichiers de configuration optimisés fournis
• Idéal pour : site vitrine, blog, petit e-commerce (< 1000 visiteurs/jour)

Audit Avancé – 690€ HT

• Serveur complexe : multi-sites, configurations personnalisées, trafic élevé
• 4-6h d'analyse approfondie
• Rapport 20-30 pages + tests de charge + profiling applicatif
• Recommandations architecture (Redis, CDN, load balancing)
• Présentation visio 1h des findings
• Idéal pour : e-commerce moyen/gros, SaaS, applications métier

Audit + Exécution – Sur devis (typiquement 900-1500€ HT)

• Audit Avancé + j'applique moi-même les correctifs
• Sauvegarde complète avant intervention
• Tests de non-régression
• Mesures avant/après avec rapport de validation
• Support 7 jours post-intervention
• Idéal pour : vous n'avez pas de compétences système en interne

Audit Urgence (< 24h) – Tarif × 1.5

• Intervention sous 24h (jours ouvrés)
• Rapport express sous 48h
• Idéal pour : crise en cours, site down, piratage récent

Options complémentaires

• Session de formation (1h) : +150€ HT
  • Lecture des métriques, utilisation du monitoring, maintenance préventive
• Support maintenance mensuel : à partir de 200€ HT/mois
  • Mises à jour de sécurité mensuelles
  • Monitoring 24/7 avec alerting
  • Interventions correctrices incluses (jusqu'à 2h/mois)
• Audit de suivi (6 mois après) : -50% sur tarif initial
  • Vérification que les optimisations tiennent dans le temps
  • Ajustements si évolution du trafic

Délais standards

• Devis : sous 24h après brief initial
• Accès & préparation : J+1 à J+2
• Audit : J+3 (2-4h de travail concentré)
• Livraison rapport : J+4 à J+5
• Exécution (si option) : J+6
• Validation finale : J+7

Délai total : 7 jours ouvrés en moyenne, 3-4 jours si urgence.

Ce qui est inclus dans tous les tarifs

Analyse complète des 7 couches (réseau, serveur, PHP, MySQL, sécu, perfs, monitoring) Rapport PDF détaillé avec captures et recommandations actionnables Fichiers de configuration optimisés prêts à déployer Présentation visio 30 min des findings (formule Avancé et +) 1 aller-retour de questions par email après livraison

Moyens de paiement

• Virement bancaire (IBAN fourni sur facture)
• Carte bancaire via Stripe (lien de paiement sécurisé)
• PayPal (entreprises françaises)

Conditions : 50% à la commande (après acceptation devis), 50% à la livraison du rapport.

Questions fréquentes

Que couvre exactement l'audit serveur web ?

L'audit analyse 7 couches techniques : protocole réseau (TLS/HTTP2), configuration du serveur web (Nginx/Apache), optimisation PHP-FPM (pm.*, opcache), base de données MySQL (requêtes lentes, index manquants), sécurité système (fail2ban, firewall, mises à jour), performance applicative (TTFB, Core Web Vitals), et monitoring (logs, métriques, alerting). Vous recevez un rapport détaillé avec plan d'actions priorisé.

Pouvez-vous corriger les problèmes trouvés ou seulement les identifier ?

Les deux sont possibles. La formule "Audit Essentiel" ou "Avancé" identifie les problèmes et fournit les fichiers de configuration optimisés que votre équipe technique peut déployer. La formule "Audit + Exécution" inclut l'application des correctifs par mes soins, avec sauvegarde préalable, tests de non-régression, et mesures avant/après. C'est l'option recommandée si vous n'avez pas de sysadmin en interne.

Quels sont les délais et le coût d'un audit ?

Audit de base à partir de 390€ HT pour un serveur simple, réalisé sous 7 jours ouvrés (urgence 24h possible moyennant supplément). La formule "Audit + Exécution" est sur devis (typiquement 900-1500€ HT) selon la complexité. Un brief initial gratuit de 15 min permet d'établir un devis précis sous 24h.

Dois-je arrêter mon site pendant l'audit ?

Non, l'audit est non intrusif. L'analyse se fait via SSH en lecture principalement (logs, configurations, métriques). Les tests de charge se font en accord avec vous et peuvent être planifiés en heures creuses si souhaité. Seule l'exécution des correctifs (formule optionnelle) peut nécessiter 2-5 minutes d'indisponibilité pour redémarrer des services (PHP-FPM, MySQL), ce qui est planifié en avance.

Mon serveur est hébergé chez OVH/Scaleway/autre, est-ce un problème ?

Absolument pas. Je travaille régulièrement avec OVH, Scaleway, Hetzner, Contabo, DigitalOcean et autres hébergeurs standards. L'audit se fait indépendamment de l'hébergeur tant que j'ai un accès SSH ou panel (Plesk, ISPConfig). Si votre hébergeur est très spécifique (ex: hébergement managé AWS avec restrictions), un brief préalable permettra de valider la faisabilité.

Que se passe-t-il si vous trouvez des failles de sécurité critiques ?

Je vous alerte immédiatement (même avant la fin de l'audit complet) si je détecte une vulnérabilité critique activement exploitable (backdoor, version PHP avec CVE critique exploitée dans la nature, serveur complètement ouvert). Le rapport inclut ensuite un plan d'actions priorisé avec les correctifs urgents en tête de liste. Avec la formule "Audit + Exécution", je peux appliquer les patches de sécurité en priorité dès leur identification.

L'audit couvre-t-il l'optimisation du code de mon application ?

L'audit serveur se concentre sur l'infrastructure et la configuration système (serveur, PHP, MySQL). Je peux identifier qu'une page fait 150 requêtes SQL ou que certaines fonctions PHP sont lentes (via profiling), mais l'optimisation détaillée du code applicatif (refactoring, réécriture de requêtes complexes) relève d'un audit applicatif dédié. Cependant, 80% des problèmes de performance viennent de la configuration serveur, donc l'audit résout la majorité des cas.

Fournissez-vous une garantie de résultats ?

Je garantis que le rapport contiendra des recommandations actionnables et mesurables. Pour la formule "Audit + Exécution", je m'engage sur des objectifs chiffrés définis ensemble en amont (ex: TTFB < 400ms, 0 erreur 502 pendant 7 jours, Core Web Vitals "Good" sur 80%+ des pages). Si les objectifs ne sont pas atteints après intervention, je reprends l'optimisation sans surcoût jusqu'à satisfaction.

Puis-je obtenir un exemple de rapport d'audit ?

Oui, je peux vous envoyer un rapport anonymisé (données client masquées) sur demande par email, ce qui vous donnera une idée précise du niveau de détail et du format. Contactez-moi à [votre email] avec "Exemple rapport audit" en objet.

Proposez-vous un suivi ou de la maintenance après l'audit ?

Oui, plusieurs options :

• Support post-audit inclus : 7 jours de questions/réponses par email après livraison
• Audit de suivi à 6 mois : -50% sur le tarif initial pour vérifier que tout tient dans le temps
• Maintenance mensuelle : à partir de 200€/mois incluant mises à jour de sécurité, monitoring 24/7, et interventions correctrices (jusqu'à 2h/mois)

Mon site est sous WordPress/Shopify/autre CMS, ça change quelque chose ?

L'audit serveur est agnostique du CMS car il se concentre sur la couche système (Linux, Nginx, PHP, MySQL). Cependant, ma forte expérience sur WordPress/WooCommerce (80% de mes audits) me permet d'aller plus loin : je peux auditer les plugins problématiques, optimiser la base de données WP (wp_options, transients), configurer du cache objet (Redis), etc. Pour Shopify hébergé, l'audit serveur n'est pas applicable (infrastructure managée par Shopify), mais je peux auditer les apps Shopify custom si hébergées sur votre serveur.

Quels accès devez-vous avoir à mon serveur ?

Minimum requis :

• Accès SSH (compte utilisateur avec sudo, ou root si accepté) via clé publique que je fournis
• Accès lecture aux logs (/var/log/nginx, /var/log/php-fpm, /var/log/mysql)
• Identifiants MySQL lecture seule pour analyser les slow queries

Optionnel (mais recommandé) :

• Accès au panel (Plesk, ISPConfig) si existant
• Identifiants CMS (WordPress admin) pour tester en conditions réelles
• Accès Google Search Console / Analytics pour corréler avec métriques business

Sécurité : Tous les accès fournis sont supprimés immédiatement après l'audit (sous 48h max). Un NDA peut être signé sur demande.

Si vous cherchez des solutions complémentaires, consultez également :

• Audit sécurité site web : Focus applicatif (vulnérabilités XSS/CSRF/SQLi, plugins obsolètes, conformité RGPD)
• Dépannage site piraté : Intervention d'urgence après piratage (nettoyage backdoors, restoration)
• Optimisation Core Web Vitals : Amélioration LCP/FID/CLS côté front-end
• Optimisation vitesse site : Optimisation globale (front + back)
• Dépannage et optimisation de sites : Vue d'ensemble de mes services dépannage
• Performance et vitesse : Ressources et guides sur l'optimisation web
• Sécurité et conformité : Centre de ressources sécurité (RGPD, SSL, backups)

Prêt à booster les performances et la sécurité de votre serveur ? Demandez votre audit gratuit