Vérifiez le serveur avant l'ouverture de la boutique
SixPreflight est un contrôleur de préparation de serveur pour 6amMart. Envoyez un dossier, ouvrez-le dans un navigateur, et jusqu'à 163 vérifications se terminent par une seule phrase : prêt à ouvrir, ou pas prêt — et exactement quoi corriger en premier.
Toujours la version en cours, et il tourne sur votre propre serveur. Il lit : il ne lit ni n'écrit jamais dans une table de l'application, et n'envoie jamais d'e-mail ni de SMS à personne. Trois surfaces peuvent agir en dehors du dossier de l'outil, et une quatrième écrit à l'intérieur — chacune seulement quand vous appuyez sur son bouton. Voir « Ce qu'il changera, si vous le lui demandez ».
163
vérifications distinctes dans le code
10
étapes, les moins coûteuses et les plus souvent cassées d'abord
1
phrase à la fin
A–F
note, avec chaque bloquant nommé
Vous lisez cette page avec un assistant IA ?
Obtenir SixPreflight
SixPreflight est un dossier PHP que vous téléversez. Rien à installer avant, et rien à créer. C'est gratuit.
Essayez avant de télécharger
Mot de passe de la démo
Password: a3uap648vnh7yqenc9vb
No username — SixPreflight asks for the password only.
The shop runs a real dataset — tens of thousands of orders — so the screens behave the way they will on yours, not the way a demo with forty products does. Two things are switched off on the demo: maps and SMS one-time passwords. Both use keys locked to a single server, which is how they should be held, so they cannot answer from a demo host. They work normally on your own install.
Obtenir SixPreflight
Free- Mises à jour incluses — chaque version arrive sur CodeCanyon sans frais supplémentaires. Pas de serveur de licence, aucune clé à renouveler.
- La première installation est offerte — envoyez votre code d'achat et les informations du serveur par WhatsApp ou e-mail.
Rien à activer — cela tourne sur votre propre serveur, sans appel vers l'extérieur, et continue de fonctionner même si ce site est hors ligne.
Ce qu'il fait
Pour un commerçant, pas pour un ingénieur
Vous avez acheté 6amMart, vous avez loué un serveur, et quelqu'un l'a installé. Le site s'affiche. Ce n'est pas la même chose qu'être prêt. Une boutique peut paraître tout à fait normale dans un navigateur alors que sa passerelle de paiement n'a aucun identifiant valide, que ses notifications push ne vont nulle part, que son fichier .env est lisible par n'importe qui sur internet, que ses tâches planifiées n'ont jamais tourné une seule fois, et que sa base de données est configurée pour n'utiliser qu'une fraction de la mémoire que vous payez. Rien de tout cela n'apparaît avant qu'un vrai client passe une vraie commande et que quelque chose tourne mal en silence.
SixPreflight est la vérification à faire avant que cela n'arrive. Vous envoyez un dossier dans votre site, l'ouvrez dans un navigateur, définissez un mot de passe et appuyez sur un bouton. Il examine le serveur comme le ferait un ingénieur méticuleux — le matériel, PHP, les réglages de la base de données, le serveur web, les permissions de fichiers, ce qu'internet peut atteindre, et si les paiements, l'e-mail, les SMS, les cartes et les notifications push fonctionnent vraiment quand on les appelle pour de bon.
Puis il vous donne une phrase — « Prêt à ouvrir » ou « Pas prêt à prendre des commandes » — une note en lettre, et une liste ordonnée de ce qu'il faut corriger, chaque point avec la ligne exacte à changer, le fichier où elle se trouve, et ce que cela coûte à votre boutique de la laisser en l'état.
L'analyse elle-même ne fait que lire. Là où l'outil peut agir, il agit sur un bouton que vous pressez, jamais de lui-même.
Avec versus sans
Ce que vous savez avant d’ouvrir
Le même serveur des deux côtés. La différence, c’est de savoir si c’est vous qui trouvez les problèmes, ou un client qui paie.
Le jour de l’ouverture
Sans SixPreflight
Le site s’affiche dans un navigateur, alors vous ouvrez. Une boutique peut paraître parfaitement normale alors que sa passerelle de paiement n’a aucun identifiant fonctionnel, que ses notifications push ne vont nulle part, que son .env est lisible par n’importe qui sur internet, que ses tâches planifiées n’ont jamais tourné une seule fois, et que sa base de données est réglée pour n’utiliser qu’une fraction de la mémoire que vous payez.
Avec SixPreflight
Jusqu’à 163 contrôles se terminent par une seule phrase — prête à ouvrir, ou pas prête à prendre des commandes — avec une note de A à F et une liste ordonnée de ce qu’il faut corriger en premier.
Comment vous apprenez qu’il y a un problème
Sans SixPreflight
Un vrai client passe une vraie commande et quelque chose se casse en silence. C’est votre premier signal, et il vous coûte la commande et le client.
Avec SixPreflight
Vous l’apprenez avant d’ouvrir, par une analyse que vous lancez vous-même — chaque point nommant la ligne exacte à changer, le fichier où elle se trouve, et ce que cela coûte à votre boutique de la laisser.
Un identifiant présent mais faux
Sans SixPreflight
Il ressemble exactement à un identifiant qui fonctionne. Un fichier de configuration contenant une valeur vous dit que la valeur est là, pas qu’elle est juste.
Avec SixPreflight
Des appels réels tranchent : un vrai jeton Firebase généré et envoyé au point d’accès de Google, une vraie conversation SMTP avec EHLO / STARTTLS / AUTH, et un appel de géocodage en direct à Google Maps. Présent-mais-faux échoue ici — le seul endroit où on peut l’attraper avant qu’un client ne le trouve.
Ce qu’internet atteint déjà
Sans SixPreflight
Vous supposez que les fichiers qui ne devraient pas être publics ne le sont pas. Rien sur le serveur ne vous dit le contraire, parce que rien ne fait les requêtes.
Avec SixPreflight
Il récupère une liste fixe d’adresses connues comme risquées sur votre propre site en ligne — /.env, /.git/config, /artisan, le database.sql de l’installateur et les fichiers de l’outil lui-même — et rapporte ce qui est réellement revenu.
Ce que cela coûte
Sans SixPreflight
L’apprendre par un client, c’est la version chère.
Avec SixPreflight
Rien. SixPreflight est gratuit sur CodeCanyon et la première configuration est gratuite. Rien dans le paquet ne vérifie une licence, un compte ou une date d’expiration, et rien n’y renvoie quoi que ce soit à AllsWeb.
Exécuté sur de vrais serveurs
Le score obtenu quand nous l'avons pointé sur nos propres machines
Un vérificateur qui n'a jamais publié de résultat n'est qu'une affirmation. Ceux-ci viennent de la même campagne de mesures que le benchmark SixPanel — l'outil déployé sur de vrais serveurs faisant tourner une vraie boutique, et noté comme un navigateur le note, non depuis un shell.
SixPanel
97 · A
Lignes demandant attention: Aucune
SixPanel Docker
96 · A
Lignes demandant attention: Aucune
Bien lire un score plafonné
Le score plafonne à 88 tant qu'une seule ligne est au rouge, quelle que soit la qualité du reste. C'est volontaire — une boutique qui ne peut pas vendre ne devrait pas se lire comme un bon élève — mais cela veut dire qu'un score plafonné ne vous apprend presque rien sur les quatre-vingt-dix-neuf autres contrôles. Plus tôt dans la même campagne, un serveur affichait 88 et un autre 96, et l'écart entre leurs scores sous-jacents était de 0,03 sur une centaine de contrôles. Tout l'écart visible tenait à une tâche de fond périmée. Lisez toujours les lignes rouges, jamais le seul titre.
Un défaut que cette campagne a trouvé dans l'outil lui-même
Le moteur d'analyse de SixPreflight n'avait aucune gestion d'erreur. Sur un serveur où l'hébergeur a désactivé une fonction PHP, l'appeler en PHP 8 n'est pas un avertissement que l'on peut faire taire : c'est une erreur fatale — une seule fonction désactivée mettait donc fin à toute l'analyse avec une trace d'appels au lieu d'un rapport. Et c'est exactement l'hébergement mutualisé cPanel et Plesk qui a le plus besoin de cet outil. C'est corrigé : une fonction désactivée est désormais une ligne qui indique qu'elle n'a pas pu être mesurée, et l'analyse va jusqu'au bout.
Et un point sur lequel il se trompe sur un serveur durci
Sur un serveur où PHP est enfermé dans un bac à sable du noyau, SixPreflight ne peut pas lire la configuration du serveur web — et il signale un délai d'attente comme non défini alors que le serveur web l'a bien défini. Une absence de preuve lue comme une preuve d'absence, ce qui pénalise un serveur parce qu'il est durci. C'est indiqué ici parce qu'un outil qui signale ses propres angles morts vaut mieux qu'un outil qui n'en aurait aucun.
Comment ça marche
Par étapes, pas une longue attente
La page elle-même n'exécute aucune vérification. Elle dessine une coquille vide, puis le navigateur demande au serveur une étape à la fois.
Le premier affichage est instantané
Mesuré sur l'installation de test : 6.8 KB en 2 ms, contre 36 KB et environ 1.6 s quand la page faisait tout le travail avant de s'afficher. Sur un serveur qui est par définition peut-être mal configuré, attendre la vérification la plus lente avant de montrer quoi que ce soit est le mauvais compromis.
La barre de progression est réelle
Étapes terminées sur étapes totales, pas une animation. Quand elle s'arrête, c'est que quelque chose est vraiment bloqué, et l'étiquette dit quelle vérification.
Une vérification bloquée ne peut pas faire tomber la page
Chaque étape est sa propre requête courte, donc rien ne se heurte à max_execution_time. Une étape qui lève une erreur est rapportée comme un constat et l'analyse continue. Chaque étape terminée est écrite sur disque au fur et à mesure, donc une analyse interrompue reste lisible.
Deux boutons
Vérifier maintenant
Lit la configuration locale et cherche l'IP publique du serveur — environ une seconde.
Vérification approfondie
Ajoute les deux étapes qui font de vrais appels sortants : les tests d'exposition publique contre votre propre URL, et les tests d'intégration en conditions réelles.
Détail honnête : « Vérifier maintenant » n'est pas entièrement hors ligne. La ligne de l'IP publique interroge un service d'écho externe — ifconfig.me, puis api.ipify.org, puis icanhazip.com, essayés dans cet ordre et mis en cache entre les analyses, délibérément trois fournisseurs pour qu'une mauvaise minute n'écrase pas une réponse connue comme bonne.
Les trois façons dont il tourne
SixPreflight détermine ce qu'il regarde et change ce qu'il dit, parce qu'un conseil honnête est différent dans chaque cas.
Sur un serveur nu — aucune application encore installée
C'est le mode pour choisir un serveur ou en préparer un nouveau. Le matériel, PHP, le serveur de base de données, le serveur web, les permissions et l'exposition publique sont tous vérifiés quand même. L'étape .env ne renvoie rien, l'étape application ne renvoie que la ligne de profil, et l'étape base de données rapporte « non vérifié — aucune application ici pour porter des identifiants » comme une réussite, plutôt que de laisser une connexion absente devenir la pire ligne d'une machine à juste titre vide.
Vous pouvez tout de même auditer la base d'une machine nue en pointant env_path vers un .env factice qui porte les identifiants.
Dans votre boutique — au niveau du code admin 6amMart
Envoyez le dossier dans public/, le répertoire que votre serveur web sert réellement. La racine de l'application est trouvée en remontant depuis le dossier de l'outil, sur cinq niveaux au maximum, jusqu'au répertoire qui contient artisan — donc public/preflight/ comme un dossier à la racine de l'application fonctionnent, et un envoi enfoui plus profond que cinq niveaux bascule silencieusement en mode autonome. Le bon emplacement est public/ — un dossier à la racine de l'application n'est atteignable par URL que si la racine du site est mal réglée, ce qui est justement la chose la plus grave que cet outil recherche.
Ici, toutes les vérifications s'exécutent, y compris celles écrites spécifiquement à partir du code de 6amMart : le planificateur qui paie les boutiques et les livreurs, les modules marqués actifs mais absents, les extensions PHP exactes que ses paquets fournisseurs exigent, et la couche websocket derrière le suivi de livraison en direct. Sur toute autre application Laravel, tout ce qui concerne le serveur s'applique exactement tel quel, et les vérifications propres à 6amMart sont sautées plutôt que devinées.
Intégré dans SixPanel
Sur un serveur SixPanel, le panneau gère le serveur web, PHP, la configuration de la base de données, cron, le worker de file d'attente et le certificat, et réécrit ces fichiers depuis ses propres gabarits à chaque déploiement — donc une valeur collée à la main est silencieusement perdue au déploiement suivant. Dans ce mode, SixPreflight abandonne les blocs à coller, les blocs nginx et Apache bruts, les lignes de redémarrage de php-fpm et les chemins « où cliquer dans votre panneau d'hébergement », et pointe à la place vers la page SixPanel qui gère chaque réglage. Il garde tout ce qui concerne l'application — .env, réglages métier, clés manquantes ou fausses, une APP_URL erronée, un stockage cassé, des erreurs dans le journal — parce que c'est la moitié que le panneau ne peut pas corriger seul. Il indique dans quel mode il est, en une ligne en haut de la page, pour que le mode ne soit jamais un mystère.
Le mode est décidé par une variable d'environnement définie par le bloc serveur qui répond à ce chemin (SIXPANEL_EMBED=1), ou par 'embedded' => true dans config.php. Un en-tête de requête n'est délibérément pas le signal principal : un en-tête est écrit par celui qui fait la requête, il survivrait donc au cadre du panneau et à rien d'autre — ouvrez la même page dans un nouvel onglet et l'outil reviendrait aux conseils autonomes sur le même serveur. X-SixPanel-Embed: 1 n'est honoré que si vous activez 'trust_embed_header', désactivé par défaut, parce que sans garde-fou n'importe quel visiteur pourrait s'attribuer la vue « serveur géré » sur un serveur qui est en fait le sien à corriger.
Ce qu'il vérifie
163 vérifications distinctes, en dix étapes
163 vérifications distinctes vivent dans le code, exécutées en dix étapes, classées des moins coûteuses et des plus souvent cassées en premier. Les deux étapes qui font des appels sortants sont marquées lentes et ne s'exécutent que sur une Vérification approfondie.
| Étape | Ce qu'elle examine | Vérifications | Exemples réels |
|---|---|---|---|
| Système et matériel | La machine que vous payez | 7 | nombre de vCPU, RAM, swap, espace disque libre, charge moyenne, version de l'OS, présence ou non d'un outil de sauvegarde |
| Environnement PHP | Le langage sur lequel tourne la boutique | 18 | tranche de version PHP, 25 extensions requises, memory_limit, max_execution_time effectif, display_errors, OPcache activé ou non, mémoire et nombre de fichiers OPcache, taux de succès |
| Santé de l'application | Laravel et 6amMart eux-mêmes | 22 | .env suivi dans git, migrations en attente, tâches en échec, arriéré de file d'attente, taille du journal, nombre d'erreurs dans le journal, planificateur déjà exécuté ou non, liste de modules valide, proxys de confiance, réglages d'installation présents |
| Environnement (.env) | Le seul fichier que tout le monde lit | 14 | clés en double (la dernière l'emporte, donc votre modification ne fait rien), caractères \r invisibles, une APP_KEY invalide ou livrée telle quelle, APP_DEBUG=true, une APP_URL mal formée, des clés que rien ne lit, des clés qui deviennent nulles une fois la config mise en cache |
| Identité de l'hôte et permissions | À qui appartiennent les fichiers | 9 | IPv4 et IPv6 publiques, l'utilisateur PHP, la propriété des fichiers, les six répertoires qui doivent être accessibles en écriture, les fichiers accessibles en écriture par tous, un .env lisible par tous, tout ce qui est à la fois exécutable et accessible en écriture dans public/ |
| Serveur web | nginx ou Apache en frontal | 17 | type de gestionnaire, gzip, jetons serveur, délai de lecture FastCGI, modules et MPM Apache, nombre de workers php-fpm face à la mémoire, la chaîne de taille d'envoi, compression en conditions réelles, cache statique, HSTS, expiration du certificat |
| Cache, file d'attente et temps réel | Le travail en arrière-plan | 11 | connexion de file d'attente, worker de file réellement en marche et supervisé, pilotes de session et de cache, Redis, Memcached, identifiants et schéma Reverb, identifiants Pusher |
| Configuration de la base de données | Là où vit l'argent | 32 | buffer pool InnoDB dimensionné face à vos vraies données et à votre RAM, journal redo, méthode de vidage, max_connections face aux workers php-fpm, skip_name_resolve, sql_mode, jeu de caractères, décalage d'horloge entre PHP et la base, taux de succès du buffer pool, tables temporaires sur disque, privilèges de l'utilisateur de la base |
| Exposition publiquelent | Ce qu'un inconnu peut récupérer | 12 | HTTPS, .env lisible sur le web, .git/config lisible, laravel.log servi, un fichier .php envoyé qui s'exécute vraiment, Debugbar ou Telescope qui répondent, exports de base de données de l'installateur laissés en place, les propres fichiers de cet outil servis en texte |
| Paiements, e-mail et SMSlent | Les services qui doivent fonctionner | 21 | une vraie conversation SMTP, une vraie émission de jeton Firebase, un vrai appel de géocodage Google Maps, moyens de paiement utilisables, identifiants de passerelle SMS, disque de stockage accessible en écriture, mode maintenance, reCAPTCHA, fuseau horaire, devise |
La colonne fait 163 au total. Deux lignes portent une réserve.
- L'une des 32 vérifications de base de données — db_standalone — n'existe que pour le cas où il n'y a aucune application pour porter des identifiants. Elle remplace les 31 autres au lieu de s'y ajouter.
- Deux des 21 vérifications paiements/e-mail/SMS sont des bases de préfixe (sms_, social_) qui se développent à l'exécution en une ligne par passerelle active ou par connexion sociale configurée. Cette étape peut donc produire plus de 21 lignes sur une boutique chargée, ou moins sur une boutique vide.
Aucune exécution ne réalise les 163 — et voici exactement pourquoi
Une boutique installée peut produire au plus 162 lignes distinctes — et aucune exécution unique ne produit les 162
db_standalone n'est émise que lorsqu'il n'y a pas d'application, donc une boutique installée ne peut jamais la voir ; c'est la 163e. Le 162 est un plafond, pas une exécution.
Une Vérification approfondie sur une boutique installée produit 160 lignes
Quand l'étape approfondie va suivre, la classe serveur web supprime ses deux jumelles lues en configuration — gzip et server_tokens pour nginx, keepalive et server_tokens pour Apache — parce que la mesure en conditions réelles répond à la même question depuis une vraie réponse, et les deux peuvent diverger (gzip activé ; avec une liste gzip_types qui omet application/json, c'est une réussite selon la configuration et un avertissement selon la mesure, pour un même réglage). Ces jumelles sont à l'intérieur des 162 ; c'est pour cela qu'une Vérification approfondie tombe à 160 plutôt qu'à 162, ce n'est pas une paire supplémentaire par-dessus.
Un « Vérifier maintenant » produit 123 lignes — il en saute 39
Ces 39 sont les 12 vérifications d'exposition publique, les 21 vérifications paiements/e-mail/SMS, et les six lignes de serveur web qui ne peuvent être lues que depuis une réponse en conditions réelles — compression, static_cache, keepalive_live, server_banner, hsts et cert_expiry. Les deux jumelles lues en configuration sont présentes dans cette exécution, puisque la mesure en conditions réelles qui les aurait remplacées ne viendra pas.
Ces deux chiffres comptent des clés distinctes, et un vrai serveur descend encore plus bas — retenez la borne basse
Trois des 17 clés de serveur web appartiennent au serveur web que vous n'utilisez pas (nginx apporte client_max_body_size, gzip et fastcgi_read_timeout ; Apache apporte apache_modules, apache_mpm et keepalive), et l'étape base de données porte des paires conditionnelles selon le moteur — MySQL 8.0.30+ rapporte innodb_redo_log_capacity, tout le reste rapporte innodb_log_file_size, jamais les deux. Rien qu'en comptant la séparation du serveur web, une Vérification approfondie sur une installation nginx ou Apache produit au plus 157 lignes, et un « Vérifier maintenant » au plus 120 ; chaque ligne de base de données conditionnelle au moteur fait encore baisser le total.
Sur un serveur nu, 40 lignes n'ont rien à lire
Les 14 vérifications .env, les 12 vérifications applicatives Laravel, les 9 vérifications de plateforme 6amMart et les 5 vérifications temps réel n'ont absolument rien à lire — 40 lignes, ne laissant que la ligne de profil de l'étape application.
La forme honnête est donc « jusqu'à 163 » — avec une Vérification approfondie sur une installation 6amMart qui exécute l'ensemble complet dont elle dispose, soit 160 clés distinctes et pas plus de 157 lignes sur une vraie machine à un seul serveur web.
Aucune des deux étapes lentes n'est de la devinette
L'étape d'exposition récupère de vraies adresses sur votre vrai site
Elle récupère une liste fixe d'adresses connues pour être risquées sur votre propre site en ligne — /.env, /.git/config, /storage/logs/laravel.log, /artisan, /composer.json, /vendor/autoload.php, le database.sql et le public.zip de l'installateur, /telescope, /_debugbar/open, la route d'inscription des boutiques, et les propres fichiers de cet outil — et rapporte ce qui est réellement revenu.
L'étape des services fait de vrais appels
Elle génère un vrai JWT et le poste au point de jeton de Google pour prouver que votre compte de service Firebase fonctionne, ouvre une vraie conversation SMTP avec EHLO / STARTTLS / AUTH, et fait un vrai appel de géocodage à Google Maps. Un identifiant présent mais faux échoue ici, et c'est le seul endroit où on peut le détecter avant qu'un client ne le trouve.
La sonde SMTP s'arrête à l'authentification. Elle envoie EHLO, négocie STARTTLS, s'authentifie puis fait QUIT — il n'y a ni MAIL FROM, ni RCPT TO, ni DATA dans cette classe, donc rien n'est délivré à personne.
Deux pages de plus qui ne font pas partie des 163
Les deux sont de vraies surfaces du produit et aucune ne compte dans le score.
Suivi de livraison en direct — 15 vérifications
Sa propre page, couvrant le processus Reverb, le gestionnaire de processus, le socket d'écoute, le pare-feu, le proxy, le certificat, les identifiants, les clés d'application, les réglages d'application, l'authentification de canal, la cible cliente, le cache de configuration, la file d'attente, le CDN et le pilote. Pour un acheteur de 6amMart, c'est la fonctionnalité derrière la carte en direct, et elle est vérifiée à part plutôt que fondue dans le score du serveur.
Alerte de commande de test
Envoie une vraie notification push à un vrai appareil de boutique ou de livreur, via la commande artisan de la plateforme plutôt qu'un contenu fabriqué à la main. Il existe un bouton « Montrer ce qui serait envoyé » qui l'exécute à blanc, mais le bouton par défaut envoie pour de vrai.
Comment il note
Un seul chiffre — et il vous dit ce qu'il n'a pas pu mesurer
Chaque vérification se termine par l'une de quatre issues : réussite, avertissement, problème, ou non mesuré.
Le chiffre est une moyenne pondérée, pas un comptage. Le tableau de pondération va de 200 à 11, fixé par ce que cela vous coûte quand c'est faux — APP_DEBUG=true est à 200, la ligne du nom de l'OS est à 12, et app_profile et public_ipv6 sont à 11. Toute clé absente de ce tableau retombe à une valeur par défaut de 10, et une clé d'analyse en production fait exactement cela : db_standalone, qui n'est réellement pas classée et apparaît dans le rapport d'écart de l'outil lui-même. Une réussite gagne tout son poids, un avertissement la moitié, un problème rien.
| Score | Note | Ce que cela veut dire |
|---|---|---|
| 90 et plus | A | Prêt pour la production |
| 75–89 | B | Bon. Traitez les points orange et revérifiez |
| 55–74 | C | Utilisable, mais vous laissez de la performance de côté |
| 35–54 | D | Pas prêt. Plusieurs réglages feront mal sous charge |
| Moins de 35 | F | Ne passez pas en production sur cette configuration |
Les bloquants plafonnent la note
Certains échecs ne sont pas des « points en moins » — ils veulent dire que la boutique ne peut pas vendre. Un bloquant plafonne le score à 74, deux à 54, trois ou plus à 34 : un bloquant force donc la tranche de note vers le bas et la moyenne pondérée décide seulement où vous atterrissez à l'intérieur de cette tranche. Sans aucun bloquant, une seule ligne rouge plafonne quand même le score à 88 — un A est hors d'atteinte avec le moindre rouge sur la page.
La liste des bloquants est courte et précise, et ce sont exactement dix-neuf clés nommées plus tout ce qui commence par sms_ : .env lisible sur le web, journaux servis sur le web, site en mode maintenance, un fichier .php envoyé qui s'exécute, impossibilité pour de nouvelles boutiques de s'inscrire, aucun moyen de paiement utilisable, base de données injoignable, stockage mal configuré, e-mail en échec, SMS en échec, un sql_mode sous lequel la plateforme casse, le mauvais jeu de caractères, le planificateur qui ne tourne pas, un certificat qui expire dans moins de 14 jours, et cinq autres défauts du .env — une APP_KEY manquante ou livrée telle quelle, APP_DEBUG=true, un bloc base de données cassé, un bloc e-mail cassé, et des clés en double.
Notez ce qui n'est délibérément pas un bloquant : des fichiers au-dessus de la racine du site qui sont lisibles sont notés comme un avertissement, pas comme un bloquant, parce que c'est de la divulgation plutôt qu'une compromission. La liste est courte exprès — si tout est une urgence, rien ne l'est.
Une conséquence qui mérite d'être dite clairement : cert_expiry est un bloquant qui n'est mesuré que lors d'une Vérification approfondie, parce qu'il se lit sur une vraie poignée de main TLS. Un « Vérifier maintenant » ne peut pas vous dire que votre certificat expire la semaine prochaine.
Pourquoi « non mesuré » n'est jamais noté — et pourquoi cela compte
Une vérification que l'outil n'a pas pu exécuter est entièrement exclue du score.
C'est la chose la plus importante à comprendre à propos de ce chiffre. Sur un panneau géré, PHP est confiné au répertoire du site — ce qui est correct et à conserver — et cela veut dire que /proc, /etc/os-release, la configuration nginx et la configuration du pool php-fpm ne peuvent pas être lus du tout. Sept vérifications n'ont alors aucune réponse à donner.
Un outil qui les noterait comme des échecs vous punirait pour une mesure de durcissement qu'il faut garder. Un outil qui les noterait comme des réussites mentirait. SixPreflight ne fait ni l'un ni l'autre : ces lignes disent « non lisible depuis ici », une ligne de la section PHP explique pourquoi une fois pour toutes et donne les deux façons de contourner, et aucune ne touche au score.
La même règle s'applique à la vérification des sauvegardes. Si aucun outil de sauvegarde n'est trouvé, la ligne est non mesurée — pas un avertissement — parce que les instantanés de votre hébergeur sont invisibles depuis l'intérieur du serveur, et l'outil refuse de qualifier de cassé ce qu'il ne peut tout simplement pas voir.
Un serveur bien verrouillé ne doit pas obtenir une mauvaise note parce qu'il est verrouillé. C'est la règle, et c'est pour cela que le chiffre vaut la peine d'être lu.
La liste de corrections
Chaque avertissement et chaque problème atterrit sur la page Quoi corriger, les rouges d'abord, puis par ordre de poids. Chacun porte une étiquette d'impact dérivée du même poids qui a produit le score, donc rien n'est noté sur une échelle et priorisé sur une autre.
- Bloque les commandes
- Peut bloquer les commandes
- Risque sérieux
- Risque
- Ralentit le site
- Utile à corriger
- Rangement
Chaque carte vous dit ce qu'est le réglage aujourd'hui, ce qu'il devrait être, dans quel fichier il se trouve, la commande à exécuter s'il y en a une, et comment prouver que le changement a bien pris. Il y a un bloc « montrez-moi toutes les lignes à coller » par fichier de destination, ne contenant que les lignes qui restent à changer — parce que copier vingt valeurs une par une, c'est ainsi qu'on perd un chiffre. Les réglages à coller et les commandes à exécuter sont gardés dans des blocs séparés ; ils vont à des endroits différents.
Les cibles de base de données sur les cartes sont dérivées du même calcul qui produit le bloc my.cnf que vous copiez, donc le chiffre ligne par ligne et le bloc ne peuvent jamais diverger.
Il se souvient aussi
L'outil garde les 60 dernières analyses sur disque. La page d'historique affiche une carte « depuis la dernière analyse » — ce qui vient de casser et ce que vous venez de corriger — vous pouvez comparer deux vérifications enregistrées côte à côte, et exporter une exécution sous forme de fichier texte.
Un endpoint ?api=findings en lecture seule renvoie la dernière vérification enregistrée au format JSON, pour un tableau de bord ou une supervision. Il ne lance jamais d'analyse : une supervision qui déclencherait une analyse complète — dont une étape récupère des URL sur votre site en ligne — à chaque rafraîchissement du tableau de bord serait un générateur de charge déguisé en outil de supervision. La réponse porte run.age_seconds pour que l'appelant puisse dire « ceci date de deux semaines » au lieu de présenter une vieille information comme actuelle.
L'autre moitié
Il a aussi une seconde moitié : le script de configuration
SixPreflight lit et explique. bin/setup-6ammart.php est l'autre moitié du paquet : c'est lui qui fait les changements. La page de documentation livrée le dit en une ligne — « SixPreflight lit un serveur et explique quoi changer. setup-6ammart.php est l'autre moitié : il fait ces changements. »
Un script bash avec une extension .php, délibérément
PHP prend le fichier, tombe sur un exit à la ligne 3, et ne rend rien à un navigateur. Exécutez-le avec bash, jamais depuis un navigateur.
Le mode par défaut est une simulation
L'exécuter par accident ne change rien. --check rapporte l'état actuel face à l'état recommandé. --apply fait le travail.
84 entrées de catalogue, dont 40 sûres à appliquer sans demander
Sa source de vérité est le même catalogue de réglages que celui des cartes de correction — 84 entrées réparties entre php, php-fpm, os, mysql, nginx, laravel et 6ammart, dont 40 sont marquées sûres à appliquer sans demander et 44 sont soumises à confirmation avec le compromis énoncé en une ligne, ou affichées comme une instruction manuelle. Aucune entrée du second groupe n'est jamais appliquée en silence, y compris avec --yes.
Comptage contesté, énoncé ouvertement
La page docs/setup.html livrée indique 84 entrées, 40 automatisables sans risque, 44 non. L'en-tête du script lui-même et un comptage direct des trois fichiers data/tuning-*.json.php disent tous deux 86 / 41 / 45. C'est le chiffre publié le plus bas qui est utilisé ci-dessus.
Les écritures dans un vhost nginx en production, le cron du planificateur et tout ce qui démarre un worker de file d'attente sur un arriéré relèvent tous de la catégorie avec confirmation : chacun montre exactement ce qu'il s'apprête à faire et demande, et --yes ne répond pas à leur place.
SixPreflight est donc un contrôleur avec un correcteur optionnel à côté, pas un contrôleur seul.
Quatre guides sont livrés avec
L'ensemble de la documentation consacre un quart de ses pages au correcteur.
Comment l'utiliser
index.html — le tableau de bord, les deux boutons d'analyse, la liste de corrections et la page d'historique.
Quoi installer, et d'où vient chaque identifiant
requirements.html — les paquets, les extensions, et depuis quelle console chaque clé est émise.
Quel PHP, quelle base de données et quel OS
versions.html — la recommandation, le classement noté, et la raison derrière chaque choix.
Ce que fait le script de configuration
setup.html — le catalogue, quelles entrées s'automatisent, et lesquelles s'arrêtent pour demander.
Pourquoi cela vaut mieux que deviner
Quatre choses que vous ne pouvez pas vérifier à l'œil
Face à votre propre jugement
La page de prérequis de l'éditeur liste des minimums, et les minimums sont la mauvaise base pour construire. « MySQL 5.7+ / MariaDB 10.3+ » cache que les deux variantes se comportent différemment sous ONLY_FULL_GROUP_BY : MySQL 5.7.5+ l'active par défaut et s'en sort, parce qu'il déduit la dépendance fonctionnelle sur laquelle ces rapports reposent ; MariaDB le laisse désactivé, et casse si vous l'activez — le rapport article par article échoue alors avec ERROR 1055. Cela a été vérifié en exécutant le rapport sur les deux, pas supposé. Le mode doit donc rester désactivé sur MariaDB, et sur MySQL il faut laisser la valeur par défaut tranquille. L'outil note cette combinaison précise, pas le numéro de version.
Face à une page phpinfo()
phpinfo() affiche des valeurs, et rien de plus. Votre vrai max_execution_time est le plus petit entre php.ini et le request_terminate_timeout de php-fpm ; SixPreflight calcule ce nombre effectif et le note. phpinfo() ne peut pas dimensionner votre buffer pool InnoDB à partir de votre RAM réelle, de votre nombre réel de workers php-fpm et de la taille réelle de vos données — SixPreflight le fait, puis vérifie si les workers de php-fpm peuvent seulement tenir dans max_connections. Il ne peut pas calculer un objectif de nombre de fichiers OPcache à partir du nombre de fichiers PHP de votre projet. Et il ne peut pas vous dire ce qu'internet peut récupérer sur votre site, parce qu'il ne fait aucune requête.
Face à la parole de votre hébergeur
« Le serveur va bien » n'est pas une affirmation que quiconque peut vérifier. Ceci l'est : il récupère /.env sur votre propre URL en ligne et vous dit ce qui est revenu. Il ouvre une vraie session SMTP. Il génère un vrai jeton Firebase. Il fait un vrai appel Maps. Chacun de ces éléments est un fait horodaté, enregistré dans un fichier que vous pouvez exporter et envoyer à celui qui vous a dit que tout allait bien.
Et il vous dit quand il ne sait pas
Un outil qui a toujours une réponse devine quelque part. Celui-ci nomme les lignes qu'il n'a pas pu mesurer et les sort du score.
Déjà sur SixPanel ?
Déjà sur SixPanel ? Vous l'avez déjà
Sur cPanel, aaPanel, CloudPanel ou un VPS nu, SixPreflight est fait pour vous
Vous gérez le serveur web, PHP, la configuration de la base de données, cron et le certificat : chaque bloc à coller et chaque commande sont à vous d'utiliser.
Sur un serveur SixPanel, il est déjà là
SixPanel monte SixPreflight à l'intérieur de la boutique et l'affiche comme sa propre page Bilan de la boutique. Vous ne téléchargez rien, et les réglages que le panneau gère pointent vers la page du panneau qui les gère plutôt que vers un bloc à coller que le prochain déploiement écraserait.
Voir SixPanelUne note honnête de plus pour ce mode : sur une machine SixPanel, les réglages propres à l'application — paiements, e-mail, SMS, Firebase, cartes, fuseau horaire, devise — sont tenus hors du score du serveur et listés séparément, parce qu'ils relèvent du commerçant et non du serveur. Le verdict en clair en haut de page parle toujours pour l'ensemble de l'activité.
Prérequis et utilisation
Prérequis, comment l'utiliser, et ce qu'il changera
Ce dont l'outil lui-même a besoin
| Prérequis | Ce qu'il lui faut |
|---|---|
| PHP | 8.2 ou plus récent pour faire tourner l'outil |
| Serveur web | N'importe lequel qui sert le répertoire public/ de votre site |
| Accès en écriture | preflight/config.php (ou collez une empreinte de mot de passe à la main) et preflight/history/ |
| Application | Aucune requise. Il tourne sur un serveur nu |
| Panneaux qu'il reconnaît | cPanel · aaPanel · CloudPanel · DirectAdmin · Plesk · CWP · serveur nu |
Ce sur quoi il note votre serveur
| Ressource | Plancher | Quoi choisir |
|---|---|---|
| vCPU | 2 | 4 |
| RAM | 4 GB | 8 GB |
| Espace disque libre | 20 GB sur la page des prérequis — mais la vérification du disque, elle, réussit à 20 GB, avertit entre 10 et 20, et n'échoue qu'en dessous de 10 | 40 GB+ |
| Type de stockage | SSD | NVMe |
| Type d'hébergement | VPS ou dédié | VPS avec accès root |
La ligne de l'espace disque libre se contredit vraiment, et vous le verrez à l'écran
Requirements::platform() code en dur « il faut 20 GB, prenez 40 GB+ », alors que la vérification matérielle note face à min_free_disk_gb = 10 issu de config.php — donc un serveur avec 12 GB libres est un échec de prérequis dans un tableau et un avertissement orange dans un autre, sur la même page.
Dans un navigateur — la façon normale
Envoyez le dossier
Envoyez tout le dossier preflight/ dans le répertoire public/ de votre site.
Définissez un mot de passe sur le premier écran
Ouvrez https://votre-domaine/preflight/ et définissez un mot de passe. Il ne démarrera pas sans, et c'est la première personne qui l'ouvre qui le définit — faites-le donc dès la fin de l'envoi. Huit caractères minimum. Si config.php n'est pas accessible en écriture, la page le dit et vous donne la commande password_hash() en une ligne à coller à la place.
Appuyez sur un bouton
Vérifier maintenant prend environ une seconde. Vérification approfondie ajoute les tests sortants.
Supprimez le dossier quand vous avez fini
Il est protégé, mais il expose des détails internes du serveur et n'a aucune raison de rester sur un site en ligne.
Optionnel : restreignez l'accès par IP avec allow_ips dans config.php (adresses seules ou plages CIDR, IPv4 et IPv6). Derrière Cloudflare ou un répartiteur de charge, l'adresse qu'il voit est celle du proxy, donc une liste d'autorisation contenant votre propre IP vous enferme dehors — laissez-la vide et fiez-vous au mot de passe, ou restreignez au niveau du proxy. Si vous vous enfermez quand même dehors, la page 403 affiche l'adresse réellement reçue et ce que le proxy prétend qu'elle est.
Ce qu'il changera, si vous le lui demandez
L'analyse lit. Quatre surfaces du paquet peuvent écrire, et aucune ne se déclenche d'elle-même — chacune demande un bouton ou une commande.
La page Journaux d'erreurs peut vider un journal
Le bouton Vider tronque le fichier avec ftruncate plutôt que de le supprimer, parce que PHP, MySQL et nginx gardent ces fichiers ouverts et que les délier les laisse écrire dans un descripteur sans nom. Cela exige le jeton CSRF, et si le fichier n'est pas accessible en écriture par l'utilisateur PHP, il affiche la commande shell au lieu d'agir. C'est une écriture dans les journaux Laravel, les journaux MySQL lents et d'erreurs, php-fpm et le serveur web — des fichiers que l'outil ne possède pas.
La page Alerte de commande de test envoie une vraie notification push
Vers un vrai appareil de boutique ou de livreur, via la commande artisan de la plateforme. Un bouton de simulation « Montrer ce qui serait envoyé » existe ; ce n'est pas celui par défaut.
Le test de performance de la base de données crée et supprime sa propre table
Nommée zz_preflight_bench_<random> avec un suffixe aléatoire différent à chaque exécution — l'argumentaire de sécurité complet est plus bas.
Définir un mot de passe réécrit config.php
Et l'action « enregistrer le profil » du tableau de bord écrit les valeurs de RAM et de vCPU fournies par l'opérateur dans le fichier de profil du serveur. Les deux vivent à l'intérieur du dossier preflight/.
Et séparément, exprès : bin/setup-6ammart.php applique des changements quand vous le lancez avec --apply. C'est son rôle.
Depuis la ligne de commande — sans application, sans navigateur
Les deux outils de comparaison sont réservés à la ligne de commande et refusent de répondre en HTTP.
php preflight/server-compare.php # mesurer cette machinephp preflight/server-compare.php --save=box-a.jsonphp preflight/server-compare.php --compare=box-a.json,box-b.jsonphp preflight/detect-size.php # relever la RAM et les vCPUCe ne sont pas les seuls fichiers avec ce garde-fou. Onze fichiers du paquet refusent de s'exécuter en dehors de la ligne de commande — ces deux-là, huit bancs d'essai dont tests/smoke.php, et bin/setup-6ammart.php. tests/smoke.php est la raison pour laquelle ce garde-fou compte : laissé accessible sur le web sans mot de passe, comme il a été livré une fois, un seul GET anonyme coûtait onze secondes de CPU, un sondage complet de la base de l'application, dix requêtes que le serveur faisait vers sa propre URL publique, et des appels sortants vers Google Maps, le serveur SMTP configuré et Firebase, répétables autant de fois que quiconque le souhaitait. L'analyse cherche désormais exactement ce fichier sur votre serveur, parce qu'un dossier comme celui-ci se recopie de machine en machine pendant des années.
server-compare.php est autonome et n'a aucune dépendance — il n'a besoin d'aucune application, ce qui en fait l'outil adapté pour comparer deux serveurs que vous envisagez de louer, avant de vous engager sur l'un ou l'autre.
Lire les scores du test de performance
Les deux scores sont normalisés pour vouloir dire la même chose à n'importe quel niveau de difficulté — seule la machine les fait varier, et plus haut veut dire plus rapide. Un vCPU cloud actuel affiche environ 100. Lancez-le deux ou trois fois à des heures différentes : une instance à crédits chute nettement une fois ses crédits épuisés, et cela n'apparaîtra pas sur une seule exécution. La machine de référence derrière ce 100 est un vCPU AMD EPYC 7713 avec du NVMe local, PHP 8.3, OPcache activé.
Sur le score de base de données, surveillez surtout les INSERT/sec sur une seule ligne : avec innodb_flush_log_at_trx_commit=1, chacun attend une synchronisation disque, donc ce nombre est en réalité la latence fsync de votre stockage. C'est la différence la plus nette entre hébergeurs.
Appliquez d'abord le my.cnf suggéré, puis comparez deux serveurs — sinon vous comparez des configurations, pas des machines.
Ce qu'il faut installer
La recommandation propre à SixPreflight, pour une installation native sans conteneurs :
- Ubuntu 26.04 LTS
- PHP 8.5
- MariaDB 11.8
PHP 8.5
Celui que l'archive de votre version apporte elle-même — 8.5 sur Ubuntu 26.04, 8.4 sur Debian 13, 8.3 sur Ubuntu 24.04. On a douté de 8.5 parce que phpspreadsheet, via maatwebsite/excel, déclare php <8.5 ; c'est une déclaration dans composer.json et non une mesure, la vérification de plateforme de composer est désactivée, et faire tourner le code sur 8.5.4 a produit un export de tableur identique au bit près, aussi bien sur l'arbre CodeCanyon brut que sur notre propre fork. Tous tournent à une vitesse pratiquement identique : ce n'est donc pas une décision de vitesse — prenez celui que votre version corrige pour vous.
MariaDB 11.8 ou 10.11
L'une ou l'autre, celle que votre version apporte — mesurées sur la même boutique, 11.8 contre 10.11 c'est une égalité. Ce qui n'est pas une égalité, c'est la famille : les deux versions de MySQL exigent des modifications de code avant que 6amMart y tourne, parce que la recherche d'articles active un drapeau d'optimiseur propre à MariaDB et que deux migrations d'index lisent un catalogue serveur dans une casse que MySQL ne renvoie pas, laissant le schéma à moitié appliqué.
Ubuntu 26.04
À égalité avec Ubuntu 24.04 et Debian 13 en vitesse — les écarts mesurés étaient plus petits que la divergence d'une machine avec elle-même. Ce qui les sépare, c'est la fenêtre de support : avril 2031 pour 26.04, contre mai 2029 pour 24.04 et août 2028 pour Debian 13. C'est une décision de fenêtre de support, pas de vitesse.
Ce que couvrent ces chiffres sur les moteurs Ils viennent d'une seule machine et d'un seul jeu de données — l'export d'une vraie boutique de 66,701 commandes — chaque moteur ayant d'abord été migré et les jeux d'index obtenus comparés à 460 index, identiques sur les cinq, pour que la comparaison porte sur les moteurs et non sur des index manquants. Ils comparent les cinq moteurs entre eux sur cette seule machine. Ce n'est pas une affirmation sur la vitesse de 6amMart en général.
Rien ici ne dit qu'un système d'exploitation est plus rapide qu'un autre : les différences mesurées entre systèmes d'exploitation étaient plus petites que l'écart d'une seule machine avec elle-même.
Comment il fonctionne
Rien dans le paquet ne vérifie une licence, un compte ou une date d'expiration, et rien n'y renvoie quoi que ce soit à AllsWeb. Les appels sortants qu'il fait vont tous vers des endroits avec lesquels vous traitez déjà — votre propre site, votre propre serveur SMTP, les points de jeton et de géocodage de Google — plus un service d'écho d'IP publique pour découvrir votre propre adresse.
La vraie raison pour laquelle ces vérifications existent : elles sont nées de la construction et de la réparation de ces serveurs, et chacune est une question que nous devrions vous poser de toute façon. Un commerçant qui peut y répondre avant de nous contacter gagne une journée ; un commerçant qui ne le peut pas obtient un rapport qu'il peut envoyer à son hébergeur.
Limites honnêtes
Lisez ceci avant de vous fier au chiffre
Il ne peut pas voir ce que le serveur ne lui montre pas
Les vérifications qui ont besoin de shell_exec ou de /proc retombent sur « non mesuré » plutôt que de deviner. Les panneaux gérés désactivent des choses différentes, donc certaines lignes sont vides chez un hébergeur et remplies chez un autre.
Sur un panneau géré, sept vérifications n'ont aucune réponse
open_basedir confine PHP au répertoire du site. C'est correct et à conserver. Les lignes le disent et sont exclues du score.
Un « Vérifier maintenant » ne peut pas voir six des lignes de serveur web, et l'une d'elles est un bloquant
La compression, le cache statique, le keep-alive en conditions réelles, la bannière du serveur, HSTS et l'expiration du certificat se lisent sur une vraie réponse : ils n'apparaissent donc que sur une Vérification approfondie — et cert_expiry est sur la liste des bloquants. Lancez la Vérification approfondie avant de vous fier à un résultat vert.
L'outil se contredit sur l'espace disque libre
Le tableau des prérequis dit qu'il vous faut 20 GB libres ; la vérification du disque qualifie 10–20 GB d'avertissement et n'échoue qu'en dessous de 10. Deux réponses à une même question, sur une même page.
Il rapporte ce que le serveur dit être configuré
Si un panneau applique de la configuration à une couche que cet outil ne peut pas voir, fiez-vous à l'interface du panneau plutôt qu'à lui. cPanel et aaPanel gèrent la configuration PHP et MySQL via leur propre interface et peuvent écraser des fichiers modifiés à la main ; CloudPanel et un serveur nu laissent les fichiers de configuration faire autorité. Si un réglage revient sans cesse en arrière après un redémarrage, c'est le panneau qui le réécrit — changez-le depuis le panneau.
Les tests de performance mesurent cette machine à cet instant
Un voisin bruyant rend chaque chiffre pessimiste — regardez la ligne de la charge moyenne avant de tirer des conclusions.
L'étape d'exposition n'est pas un test d'intrusion
Elle récupère une liste fixe d'adresses connues pour être risquées sur votre propre URL et rapporte ce qui est revenu. Elle ne cherche pas de vulnérabilités inconnues et ce n'est pas un audit de code.
Une chose ne peut vraiment pas être testée depuis un serveur
La clé client Google Maps est restreinte par référent de navigateur, donc l'outil peut vous dire qu'elle est absente, ou qu'elle est dangereusement identique à votre clé serveur — mais il ne peut pas vérifier depuis le serveur une clé correctement restreinte, et il le dit au lieu de la valider.
Les nombres de lignes du tableau des tailles sont des estimations
Ils viennent d'information_schema. Des comptages exacts demanderaient un parcours complet de chaque table sur un site en production.
Un envoi enfoui à plus de cinq répertoires sous artisan bascule en mode autonome
Silencieusement — la recherche de la racine de l'application s'arrête à cinq niveaux.
C'est d'abord un contrôleur
L'analyse elle-même ne change rien. Quatre surfaces du paquet écrivent quand vous pressez leur bouton, et bin/setup-6ammart.php applique des changements quand vous le lancez avec --apply. Les cinq sont listées ci-dessus.
Est-ce sans risque sur une boutique en production ?
Oui, et voici exactement pourquoi.
Les sondes sur données réelles sont en lecture seule par construction
Chaque sonde passe par une seule méthode query() qui refuse tout ce qui ne commence pas par SELECT, EXPLAIN, SHOW ou WITH — et il n'existe dans cette classe aucun chemin de code pouvant émettre INSERT, UPDATE, DELETE, ALTER, CREATE ou DROP, ce qui est la garantie qui porte réellement la promesse. La session est placée en TRANSACTION READ ONLY là où le serveur le permet, donc même une erreur serait rejetée par la base plutôt que par ce code. Chaque instruction porte une limite de 15 secondes côté serveur, donc une sonde lancée sur une table étonnamment énorme ne peut pas rester à occuper des ressources — et une sonde qui dépasse cette limite est rapportée comme « trop lente », ce qui est en soi le constat. Vérifié : les nombres de lignes et SUM(order_amount) sont identiques avant et après.
Le test de performance de la base de données ne touche jamais à une table de l'application
Chaque objet qu'il crée s'appelle zz_preflight_bench_<random> avec un suffixe aléatoire différent à chaque exécution ; il vérifie que le nom est libre avant de créer quoi que ce soit et s'interrompt plutôt que de toucher à une table existante ; aucune instruction ne peut nommer une table qu'il n'a pas créée ; le nettoyage est conditionné à la création effective de la table, s'exécute dans un bloc finally et dans un gestionnaire d'arrêt, et il valide par petits lots pour que rien ne garde un verrou long. Vérifié : les nombres de lignes des commandes et des articles sont identiques avant et après, et aucune table zz_preflight_ ne survit à l'exécution.
La portée est la table, pas la base de données, et cette différence est toute la promesse
Il ne lit ni n'écrit jamais dans une table de l'application — c'est la formulation du README lui-même et c'est la bonne. Le test de performance crée et supprime une table à lui à l'intérieur de la base de l'application, sous un nom qu'il génère, et l'enlève ensuite ; rien d'autre dans cette base n'est touché.
À l'intérieur de son propre dossier, il écrit une seule chose
preflight/history/, un fichier par analyse enregistrée. Ces fichiers décrivent en détail les faiblesses du serveur, chacun est donc nommé .json.php et commence par une instruction PHP exit — récupéré en HTTP, le serveur web l'exécute, s'arrête immédiatement, et ne renvoie rien. Cela vaut aussi sur nginx, qui ignore .htaccess.
Une liste rouge et pas le temps ?
Envoyez-nous le rapport exporté. Nous installons, configurons et livrons 6amMart sur votre propre serveur, avec un ingénieur senior qui valide la mise en production.
Serveur prêt, boutique toujours lente ?
SixPreflight vous dit si le serveur est prêt. Si c'est la boutique elle-même qui est lente, cela vient de l'application, pas du serveur — et c'est ce que le service d'installation 6amMart livre désormais par-dessus la dernière version de 6amMart : le build 6amMart optimisé par AllsWeb, mesuré 10× à 22× plus rapide — 90–95% plus rapide — sur chaque écran vu par les clients, mesuré sur le serveur en production, avec le CDN contourné.
FAQ
Les questions que les gens posent vraiment
Comment savoir si mon serveur est prêt pour 6amMart ?
Lancez SixPreflight dessus. Il contient 163 vérifications sur le matériel, PHP, l'application, .env, les permissions, le serveur web, la mise en cache, la base de données, l'exposition publique et chaque service externe. Une Vérification approfondie sur une installation 6amMart exécute l'ensemble complet dont elle dispose — 160 vérifications distinctes, et pas plus de 157 lignes sur une vraie machine à un seul serveur web ; un rapide « Vérifier maintenant » en exécute 123, pas plus de 120 sur cette même machine, en sautant les 12 vérifications d'exposition, les 21 vérifications de services et les six lignes de serveur web qui exigent une réponse en conditions réelles. Dans les deux cas, cela se termine par une phrase, une note en lettre de A à F, et une liste ordonnée de ce qu'il faut corriger en premier.
SixPreflight change-t-il quelque chose sur mon serveur ?
L'analyse, non. Elle ne lit ni n'écrit jamais dans une table de l'application, et n'envoie jamais d'e-mail ni de SMS à personne. Quatre surfaces écrivent quand vous pressez leur bouton : la page Journaux d'erreurs peut tronquer un fichier de journal, la page Alerte de commande de test envoie une vraie notification push à un vrai appareil, le test de performance optionnel de la base crée et supprime sa propre table, et définir un mot de passe réécrit le config.php de l'outil. Le paquet livre aussi bin/setup-6ammart.php, qui applique des changements volontairement quand vous le lancez avec --apply.
Est-ce sans risque de le lancer sur une boutique en production qui prend des commandes ?
Oui. Les sondes de base de données sont en lecture seule par construction — la méthode query() refuse tout ce qui ne commence pas par SELECT, EXPLAIN, SHOW ou WITH, il n'existe dans cette classe aucun chemin de code pouvant écrire, et la session tourne en TRANSACTION READ ONLY là où c'est possible. Le test de performance optionnel ne travaille que sur une table qu'il crée lui-même avec un nom aléatoire, et il la supprime dans un bloc finally et dans un gestionnaire d'arrêt. Les deux ont été vérifiés en comparant les nombres de lignes et SUM(order_amount) avant et après.
Ai-je besoin de 6amMart pour l'utiliser ?
Non. Il détecte ce qu'il regarde. Sur un serveur nu sans application, il vérifie toujours le matériel, PHP, le serveur de base de données, le serveur web, les permissions et l'exposition — même si les 14 vérifications .env, les 12 vérifications applicatives Laravel, les 9 vérifications de plateforme 6amMart et les 5 vérifications temps réel n'ont rien à lire, ne laissant que la ligne de profil de l'étape application. Sur toute application Laravel, tout ce qui concerne le serveur s'applique toujours et les vérifications propres à 6amMart sont sautées plutôt que devinées. Sur 6amMart, chaque vérification qui peut s'exécuter le fait.
Quel score me faut-il avant de passer en production ?
90 ou plus, c'est un A — prêt pour la production. En dessous, lisez d'abord les bloquants : un seul bloquant plafonne le score à 74 quelle que soit la qualité du reste, deux le plafonnent à 54, trois ou plus à 34. Même sans bloquant, une seule ligne rouge vous plafonne à 88. Les bloquants sont ce qui empêche la boutique de vendre — aucun moyen de paiement utilisable, e-mail en échec, base de données injoignable, .env lisible sur le web, un certificat qui expire dans moins de 14 jours. Lancez une Vérification approfondie avant de vous fier au chiffre : ce dernier point, et cinq autres lignes de serveur web, ne sont pas mesurés du tout lors d'une vérification rapide.
Pourquoi certaines lignes disent-elles « non lisible depuis ici » ?
Parce que votre panneau d'hébergement confine PHP au répertoire de votre propre site, ce qui est correct et à conserver — donc /proc, /etc/os-release, la configuration nginx et la configuration du pool php-fpm ne peuvent vraiment pas être lus. Sept vérifications n'ont alors aucune réponse. Elles sont rapportées honnêtement et entièrement exclues du score, pour qu'un serveur bien verrouillé ne soit jamais puni parce qu'il est verrouillé.
Fonctionne-t-il sur cPanel, aaPanel, CloudPanel ou un VPS nu ?
Oui — c'est son marché principal. Il reconnaît cPanel, aaPanel, CloudPanel, DirectAdmin, Plesk, CWP et un serveur nu, et donne des commandes et des chemins d'installation par panneau. Bon à savoir : cPanel et aaPanel gèrent la configuration PHP et MySQL via leur propre interface et peuvent écraser des fichiers modifiés à la main, donc si un réglage revient sans cesse en arrière après un redémarrage, changez-le depuis le panneau.
Me dit-il seulement ce qui ne va pas, ou peut-il le corriger ?
Les deux, et la moitié qui corrige est optionnelle. Le tableau de bord vous demande d'abord de faire chaque changement à la main, parce qu'une personne qui fait un changement comprend ce qu'elle a changé. Quand ce n'est pas praticable, bin/setup-6ammart.php fait le même travail depuis la ligne de commande : simulation par défaut, --check pour rapporter, --apply pour agir. Il n'applique que les entrées du catalogue marquées comme automatisables sans risque — 40 des 84 entrées publiées — et demande ou affiche les autres, y compris avec --yes.
J'utilise SixPanel. Dois-je télécharger ceci ?
Non. SixPanel monte SixPreflight à l'intérieur de la boutique et l'affiche comme la page Bilan de la boutique du panneau. Dans ce mode, il abandonne les blocs à coller pour tout ce que le panneau gère — le serveur web, PHP, la configuration de la base de données, cron, le worker de file d'attente, le certificat — et pointe vers la page du panneau qui gère chaque réglage, parce qu'une valeur collée à la main y est perdue au déploiement suivant. Il garde toutes les vérifications au niveau de l'application.
Quelle version de PHP et de base de données dois-je vraiment installer ?
Ubuntu 26.04 LTS, puis ce que son archive apporte elle-même — PHP 8.5 et MariaDB 11.8 — pour une installation native. On a douté de PHP 8.5 parce qu'une dépendance déclare une borne en dessous, mais cette borne est une déclaration et non une mesure : faire tourner le code sur 8.5.4 a donné un export de tableur identique au bit près sur l'arbre CodeCanyon brut et sur notre fork. Toutes les versions de PHP et de MariaDB mesurées ont tourné à une vitesse pratiquement identique : rien de tout cela n'est donc une décision de vitesse. Ce qui est réel, c'est la famille : les deux versions de MySQL exigent des modifications de code avant que 6amMart y tourne, parce que la recherche d'articles active un drapeau d'optimiseur propre à MariaDB et que deux migrations d'index lisent un catalogue serveur dans une casse que MySQL ne renvoie pas.
Puis-je brancher le résultat sur mon propre tableau de bord ?
Oui. ?api=findings renvoie la dernière vérification enregistrée au format JSON en HTTP Basic, avec une version de contrat stable. Il ne lance jamais d'analyse, et la réponse porte run.age_seconds pour que votre tableau de bord puisse dire « cette lecture date de deux semaines » au lieu de présenter une vieille information comme actuelle.
Envoyez un dossier. Ouvrez-le dans un navigateur. Obtenez une réponse.
Toujours la version en cours, tournant sur votre propre serveur. Il lit d'abord, et il vous dit ce qu'il n'a pas pu mesurer au lieu de deviner.
Rien dans le paquet ne vérifie une licence, un compte ou une date d'expiration, et rien n'y renvoie quoi que ce soit à AllsWeb.