Mise en place et finalisation de WooCommerce : intégration avec 1C et SDEK, mise en cache, journalisation, contrôle de la balance

Situation initiale : une boutique en ligne sur WordPress 6.x + WooCommerce 8.x fonctionnant sur un VPS (Ubuntu 22.04, Nginx, PHP 8.2, MariaDB). Catalogue d'environ 25 000 produits et 60 000 variantes. Désormais, l'échange avec 1C s'effectue via un module obsolète, les produits sont périodiquement dupliqués, les prix et les soldes baissent, et pendant les heures de pointe (ventes), le traitement des commandes est lent et donne parfois 502. La livraison est calculée via le plugin SDEK, mais certaines commandes sont envoyées sans le point de retrait sélectionné en raison de courses lors du recalcul du panier. Il faut une analyse et un paramétrage systématiques, sans changer le CMS et sans retravailler complètement le thème.

Environnement technique et restrictions : vous ne pouvez pas arrêter les ventes plus de 10 minutes à la fois, toutes les modifications via staging et Git, déploiement via SSH. Vous ne pouvez pas connecter de caches SaaS externes comme Cloudflare APO ; vous pouvez utiliser Redis sur un VPS. Vous ne pouvez pas modifier le module de paiement actuel et la structure de l'URL. Les modifications de code pointues sont acceptables sous la forme d'un petit plugin MU ou de votre propre plugin, sans modifier le cœur de WordPress et WooCommerce.

Ce qu'il faut faire:
1) Effectuer un audit de la configuration actuelle des performances et de la logique de classement - profilage des requêtes lentes (Query Monitor/New Relic ou équivalent), analyse des journaux PHP-FPM/Nginx, identification des goulots d'étranglement dans la base de données (index, requêtes lentes, tables de recherche WooCommerce, wp_postmeta).
2) Configurer la mise en cache et la stabilité - activez et configurez correctement le cache d'objets Redis, les exceptions pour les pages dynamiques (panier, paiement, compte personnel), configurez le cache des pages sur Nginx ou configurez correctement le plugin de cache existant afin que les prix, les coupons et le recalcul de la livraison ne soient pas interrompus.
3) Mettre de l'ordre dans l'échange avec 1C - stabiliser l'importation de biens, les prix et les soldes afin que des doublons ne soient pas créés et que les connexions de variations ne soient pas perdues. Configurez le mappage par identifiant externe (SKU/UUID), le traitement des produits supprimés, le contrôle d'intégrité après importation. Ajoutez un journal d'importation avec des erreurs claires (dans wp-content/uploads/logs ou dans un tableau), sans générer de données sensibles.
4) Corrigez le script de sélection du point de retrait SDEK - corrigez le problème lorsque, lors du recalcul du panier, le point de retrait sélectionné est réinitialisé ou n'entre pas dans la commande. Le résultat doit être enregistré dans l'ordre sous forme de méta et affiché dans le panneau d'administration et dans les e-mails. Si le plugin actuel ne fournit pas les hooks nécessaires, créez-le via les hooks WooCommerce sans interrompre la possibilité de mise à jour du plugin.
5) Configurez la surveillance et les protections - activez la rotation des journaux, configurez les alertes sur 5xx (l'envoi par e-mail suffit), ajoutez un point de terminaison de contrôle de santé pour vérifier la disponibilité des composants clés (DB, Redis, wp-cron).

Résultat spécifique :
- La passation d'une commande se déroule systématiquement sans 502 et sans perdre le point de retrait sélectionné.
- L'importation depuis 1C cesse de créer des produits et des variations en double ; les soldes et les prix après échange coïncident avec le déchargement.
- Le site peut supporter des pics de charge sans dégradation brutale grâce à une mise en cache correcte.

Critères d'acceptation mesurables :
- Temps de réponse de la page de paiement P95 - pas plus de 2,5 secondes avec 20 utilisateurs simultanés sur scène (k6 ou analogique), sans 5xx.
- Après un échange complet avec 1C, le nombre de produits et de variantes n'augmente pas en raison des doublons, 0 nouveau doublon par SKU/UUID externe.
- Dans 50 commandes tests consécutives, le point de retrait SDEK sélectionné est toujours enregistré et affiché dans le panneau d'administration et dans une lettre au client.
- Le taux de réussite du cache Redis sur les pages de catalogue typiques n'est pas inférieur à 70 % (selon les métriques d'informations du plugin/redis), tandis que le panier et le paiement ne sont pas mis en cache en tant que page.

Étapes attendues : mise en place du staging et de la collecte des diagnostics - plan de travail et des risques - mise en œuvre de la mise en cache - correction de l'échange 1C - correction du SDEK - tests de charge - déploiement final et liste de contrôle.

Accès et matériel : je fournirai SSH pour la préparation et la production, un vidage de base de données pour une analyse locale sur demande, un accès au panneau d'administration WP, des exemples de téléchargement 1C (XML) et plusieurs commandes problématiques de reproduction.