01C’est votre serveur qui décide du prix, jamais le navigateur
Le configurateur affiche un total pendant que le client choisit, mais le chiffre avec lequel la commande est écrite est recalculé sur le serveur à partir de la seule sélection. Un total envoyé par le navigateur est purement ignoré. L’argent est conservé en unités mineures entières, si bien qu’une longue commande ne dérive jamais d’un centime entre la facture et la commande.
02Les photos téléversées ne sont pas des pièces jointes de la médiathèque
Elles vont dans un répertoire dont le nom ne peut être deviné, protégé de quatre façons à la fois : une règle .htaccess, un web.config pour IIS, un index.php et des permissions de fichier qui n’autorisent que le site à les lire. Un fichier est accepté pour ce que sont ses octets, pas pour ce que prétend son nom : un exécutable renommé en .jpg est refusé à la porte. Elles ne reçoivent jamais d’URL publique.
03Une seule porte de sortie, et elle vérifie qui frappe
Chaque photo et chaque aperçu passe par une seule passerelle. Votre équipe passe grâce à sa permission de commandes WooCommerce ; le client passe grâce à un lien signé vérifié contre cette commande et aucune autre. Un lien fabriqué pour une commande ne peut pas ouvrir le fichier d’une autre, et un lien altéré n’ouvre rien.
04Le client valide sans créer de compte
La page de validation s’ouvre directement depuis l’e-mail : sans connexion, sans mot de passe, sans panier. Demander à quelqu’un de s’inscrire avant de pouvoir regarder son propre aperçu est le moyen le plus sûr de perdre la validation. Le lien porte lui-même son autorisation, il est signé et il expire ; la page n’est jamais mise en cache, de sorte que l’aperçu d’un client ne peut être servi à personne d’autre.
05Des retouches jusqu’au oui, puis la production et plus aucun changement
Avant la validation, le client peut demander une correction autant de fois qu’il le faut, et chaque demande est consignée sur la commande. Après la validation, le formulaire de retouche disparaît — et le serveur refuse aussi la demande, pas seulement l’écran. Selon la réglementation turque de la vente à distance, un article personnalisé ne donne pas de droit de rétractation une fois fabriqué ; le moment où le client l’accepte est donc inscrit avec la validation.
06Quatre états de commande qui n’avancent que vers l’avant
Modélisation, en attente de validation, en impression, terminé. Ce qui peut suivre quoi est écrit comme une liste de transitions autorisées, pas de transitions interdites : une étape à laquelle personne n’a pensé est refusée par défaut plutôt qu’autorisée en silence. Les états sont de vrais statuts de commande WooCommerce : ils apparaissent donc dans la liste des commandes, dans les rapports et dans vos filtres existants.
07Une file qui dit ce qui est en retard, pas seulement ce qui est ouvert
L’écran d’atelier trie les commandes ouvertes selon leur temps d’attente et marque en rouge celles qui ont dépassé le délai promis : vingt-quatre heures normalement, six pour une commande urgente. L’opérateur téléverse l’aperçu depuis le même écran et le client reçoit l’e-mail dans la même action ; il n’y a pas de second endroit où penser à cliquer.
08Quatre e-mails, envoyés par WooCommerce lui-même
Commande reçue, aperçu prêt, validation enregistrée, expédié. Ils passent par le modèle d’e-mail de votre propre boutique : ils ressemblent donc au reste de votre courrier et non à un ajout rapporté. Le lien de validation figure deux fois dans le message, en bouton et en texte brut, car certains clients de messagerie n’affichent pas le bouton.
09Les photographies ne restent pas pour toujours
Une tâche quotidienne supprime les téléversements et les aperçus des commandes terminées après une durée de conservation que vous fixez : soixante jours par défaut. La commande, son montant et son enregistrement de validation restent ; la photo du client, non. Garder indéfiniment la photo d’un enfant sur le serveur d’une boutique est une responsabilité, pas une fonctionnalité.
010Il ne se bat pas contre votre cache
Le configurateur et la page de validation désactivent tous deux le cache de page pour eux-mêmes, dans le langage que LiteSpeed, WP Rocket et W3 Total Cache comprennent tous, et envoient en plus des en-têtes no-store. Un configurateur mis en cache s’envoie avec un jeton périmé et échoue en silence ; une page de validation mise en cache montre l’aperçu d’un client au visiteur suivant. Ni l’un ni l’autre ne peut arriver ici.