Votre projet, de l’idée à la production

Je les ai montés comme un multisite : deux boutiques WordPress distinctes, bâties sur un seul thème. Chaque marque a son dossier de réglages (logo, couleurs, menu, textes, atouts, réseaux), tout le reste est commun : fiches produit, demande de devis, chat WhatsApp, formulaires, balisage structuré. Une correction faite une fois vaut pour les deux boutiques. L’appel, le devis gratuit et le chat WhatsApp restent accessibles sur chaque page, mobile compris.

Les deux boutiques sont pensées pour un seul stock, tenu dans Sellsy, où arriveront les commandes de l’une comme de l’autre.

Elles sont ouvertes aux moteurs avec un balisage structuré (JSON-LD, fil d’Ariane) et un plan du site envoyé à Search Console.

Autour des boutiques, je prends en charge le pilotage des campagnes de chaque marque et le branchement d’agents IA pour la prospection, le chatbot et les réseaux sociaux.

Technique : WordPress, WooCommerce, thème commun, réglages par marque, Kinsta, Sellsy, JSON-LD, Search Console.

Une enchère en ligne a l’air simple, c’est un des cas les plus durs à bien faire : de l’argent réel, des offres concurrentes à la milliseconde, zéro tolérance à l’erreur. Horloge unique côté serveur, offres écrites en transaction sérialisée avec clé d’idempotence (deux offres simultanées départagées sans ambiguïté), offre confirmée seulement si enregistrée, prolongation si offre dans la dernière minute, règle écrite pour une panne en pleine clôture.

Séquestre : le prix ne transite jamais par le compte de la société mais par un établissement de paiement agréé. Calendrier de l’argent (adjudication, paiement, transfert de propriété, libération au vendeur), un délai écrit par étape. Les webhooks signés du prestataire mettent à jour l’état de chaque paiement, une notification perdue est rattrapée par rapprochement. Vendeurs vérifiés (KYC) avant mise en vente, commissions calculées après le transfert de propriété.

Annonce créée par IA en un clic à partir du nom du modèle et d’une photo : mapping et validation humaine par l’équipe.

Backend : PostgreSQL avec row lock, job queue pour les clôtures et les rejeux de webhooks, temps réel par WebSocket, journal d’audit, alertes e-mail et SMS, gestion des backups.

L’audit du 25 septembre a relevé une icône de site absente, une livraison gratuite affichée alors que la livraison à domicile était payante, des délais de retour qui se contredisaient et des libellés de panier en anglais. Corrigés ensuite : un seul délai de retour, 42 anciennes adresses redirigées (une chaîne de trois sauts ramenée à un) et, sur téléphone, un bandeau de cookies qui passe de 410 à 167 px de haut.

Sept fiches produit, l’accueil et la page Boutique ont été refaites à partir d’une maquette, en sections sur mesure, et publiées le 5 octobre après validation du client ; la page partenaires l’a été après son accord écrit du 13 octobre. Côté acquisition : campagnes Google Ads Marque et Achat lancées le 8 octobre avec un garde-fou de dépense, campagne Shopping créée le 11, scénario de relance de paniers en trois e-mails dans Brevo, haut de l’accueil et trois fiches traduits en anglais.

Recette du 15 octobre sur 41 pages, 107 liens et 504 images : aucun contrôle critique en échec, aucune erreur JavaScript. Une quarantaine de scripts de modification passent d’abord en mode plan, qui liste ce qu’ils changeraient, avant d’être appliqués.

Technique : thème Shopify Horizon, sections Liquid sur mesure, API Admin GraphQL via Shopify CLI, Google Ads, Merchant Center, GA4, Brevo.

Trois ans de ventes dormaient dans des exports de caisse Excel, découpés par trimestre. Tout l’historique a été repris et unifié (236 000 lignes de ventes à fin juin 2026), les deux référentiels produits rapprochés, et une collecte automatique relève chaque jour les rapports de caisse. Un rapport partiel qui écraserait une journée complète est signalé.

La prévision croise l’historique de l’année précédente, la tendance des dernières semaines, la météo et le calendrier. Les ruptures et la casse de l’un des deux points de vente, relevées sur une feuille papier remplie chaque soir, corrigent la lecture des ventes passées : un produit épuisé à 11 h a vendu moins qu’il n’aurait pu.

Un connecteur MCP ouvre les données à l’assistant. Le dirigeant demande ce qu’il faut produire samedi et obtient un chiffrage par rayon et par produit, avec la feuille de production à imprimer. Chaque lot de prévisions est enregistré sans modification possible ; l’écart entre prévu et réalisé se calcule en série, et les leçons que l’assistant en tire ne s’appliquent qu’une fois validées par le dirigeant.

Les commandes clients arrivent en PDF : l’outil les lit, les affiche à l’écran et prépare les tickets à imprimer. En production depuis fin août 2026, les commandes clients depuis fin septembre.

Technique : Python, SQLite, Flask, serveur MCP, Caddy et systemd.

À l’audit du 18 septembre, le LCP mobile de l’accueil atteignait 8,3 s, dont 93 % de délai d’affichage. Le visuel d’accueil, un slider, était masqué puis son script retardé par l’extension de cache elle-même ; 77 pages sur 205 étaient servies hors cache.

Côté site, une extension sur mesure écrit le premier visuel dans la page, limite reCAPTCHA à 2 pages au lieu de 205 et supprime les 5 erreurs JavaScript d’un badge d’annuaire ; 103 images passent en WebP (8,3 Mo au lieu de 19,1 Mo). Côté serveur : Apache en mode event avec HTTP/2, Brotli, PHP-FPM élargi, préchargement du cache de pages chaque minute. Il reste à 10 h : l’allonger aurait fait servir des jetons de formulaire périmés.

Lighthouse mobile simulé, médiane de 3 passages, 26 septembre puis 13 octobre vers 1 h, cache chaud : le LCP des quatre pages lentes, entre 5,8 et 8,1 s, tombe entre 2,4 et 2,9 s ; la note de l’accueil passe de 71 à 92 (de 85 à 95 d’un passage à l’autre le 13) et celle de la page contact de 73 à 95. Les deux pages déjà rapides ne gagnent rien (de 96 à 95 et de 93 à 88).

Lighthouse ne voit pas le gain serveur : à 80 ms d’aller-retour, la réception de l’accueil et de ses 27 fichiers passe en moyenne de 904 ms en HTTP/1.1 à 521 ms en HTTP/2 avec Brotli (12 octobre).

Technique : WordPress, Divi, WP Rocket, Apache, PHP-FPM, Lighthouse.

Le constat de départ : 30 % de pages introuvables, 9 % de pages blanches (erreur 500), 14 Go de journaux qui remplissaient l’hébergement, des journaux d’extension gardés en base sans limite, et un Google qui connaissait environ 85 000 adresses du site, dont plus de 80 000 issues de la seule page de recherche de profils, pour 2 580 indexées.

Les sept points du devis ont été livrés en deux jours, chaque modification gardant l’empreinte du fichier avant et après, avec un retour arrière répété sur une copie : les 404 et les 500, les journaux, la base, l’indexation des pages de recherche, les pages sans en-tête ni titre, entre autres.

Un mois plus tard, sur deux fenêtres égales de 29 jours du journal d’accès : erreurs de 40 % à 5 % des demandes (hors une heure de panne de la base de données le 8 octobre), pages réellement servies de 51 % à 75 %, 46 % de demandes en moins par jour. Le journal d’erreurs PHP perd 96 % de ses lignes (fenêtres de 28 jours). Les pages consultées par jour n’ont pas baissé (26 259 puis 28 842, robots déclarés exclus) et la position moyenne dans Google passe de 10,35 à 9,25 (Search Console, 28 jours).

Technique : WordPress et DateBook chez o2switch, règles Cloudflare, journaux lus par scripts Python, Search Console par API.

Le travail s’est fait sur une copie fermée aux visiteurs et aux moteurs, e-mails et paiements coupés. Les personnalisations ont été relevées et comparées aux sources officielles, puis la montée de version a été rejouée palier par palier : de la 1.7.8.11 à la 8.2.8, puis à la 9.2, en changeant de version de PHP entre les deux, avec un rapport module par module.

La bascule en production a tenu en une heure de maintenance. Avant de rouvrir, 71 pages et 51 listes d’articles ont été comparées à l’état d’avant la migration : identiques, et toujours identiques site ouvert. Les commandes sont conservées, PayPal et Payplug sont actifs, et l’ancienne version reste intacte à côté : le retour arrière tient à un renommage de dossier. Deux commandes d’essai, une par moyen de paiement, sont passées de bout en bout.

Trois adaptations dans la foulée : la date du dernier article retirée de l’accueil, un captcha sur les réponses aux petites annonces pour freiner les robots, et un bouton « Faire une offre » écrit sur mesure à la place d’un module du marché.

Technique : PrestaShop 9.2 sous PHP 8.4, hébergement mutualisé OVH, module autoupgrade, module sur mesure en PHP.

L’audit, mené en lecture seule, a trouvé le défaut qui comptait : le WAF n’inspectait aucun corps de requête. Là où le moteur bloquait, une injection SQL dans l’adresse était refusée, la même dans un formulaire ou dans du JSON passait. Les 22 sites WordPress n’étaient qu’en détection, un journal d’audit de 62 Go grossissait dans la couche d’écriture du conteneur et la supervision était à l’arrêt depuis huit semaines.

Les corrections ont été testées sur une copie exacte de l’image Docker de production, puis appliquées un changement à la fois, chacun avec sa vérification et son retour arrière : rechargement du Caddyfile, rotation des journaux, supervision remise sur un volume, recréation du conteneur du WAF avec 6,2 secondes de coupure mesurées. Le journal de 62 Go est archivé en 4,9 Go.

Les faux positifs (cookie de consentement, formulaire de commande, API REST, champ de mot de passe) sont traités par des exclusions ciblées, écrites par règle et par chemin, puis rejouées sur le banc : 22 cas de visiteurs légitimes passent de 403 à 200 et 31 contrôles voisins restent bloqués. Le passage en blocage se décide ensuite site par site avec l’équipe du client.

Technique : Caddy 2, Coraza, OWASP CRS 4, Docker Compose, Loki, Alloy, Alertmanager, Grafana.

Le client partait de zéro : ni site, ni nom de domaine, ni hébergement, une fiche Google et un historique de courses. Chaque page se juge aux appels qu’elle produit : numéro et bouton d’appel dès l’écran d’arrivée, barre d’appel fixe sur mobile, WhatsApp, formulaire de rappel qui ne demande aucune donnée de santé.

Le site compte 21 pages dont 20 ouvertes aux moteurs : trajets vers les soins, gares et aéroports, et une page par commune ou secteur desservi. Les communes à développer ont été choisies en croisant la demande de recherche et la concurrence, pas la seule fréquence des courses passées, qui peut venir d’un seul client régulier.

Côté référencement : titres et descriptions uniques, un seul H1 par page, balisage TaxiService validé sur l’accueil (téléphone, horaires, 15 communes), redirections propres, image de partage, plan du site soumis à Google, mesure d’audience derrière un bandeau de consentement. Au contrôle en ligne, 20 pages répondent en 188 à 271 ms, sans lien interne cassé ni image sans texte alternatif. Deux jours après l’envoi du plan du site, Google l’avait lu et découvert les 20 pages ; l’indexation page par page suit son cours.

Technique : WordPress sur GeneratePress, extension sur mesure, The SEO Framework, GA4 et Search Console.

La fiche est d’abord mal catégorisée. En catégorie principale « Centre équestre », qui suppose un lieu ouvert au public, Google exige une adresse visible et une validation par vidéo, alors qu’elle se déplace chez ses clients : la validation échoue et la fiche reste invisible. La catégorie principale passe sur « Dresseur pour chiens », les secondaires sont gardées, l’adresse est masquée au profit d’une zone desservie et chaque service est décrit. Validée le 6 octobre, la fiche est visible le lendemain.

Le site est une page unique et statique sur Cloudflare Pages, sur un domaine qui appartient à la cliente. Les photos d’origine, 7 Mo pour 5 760 px de large, sont ramenées de 87 à 403 Ko en JPEG progressif. Les données structurées portent la zone de 70 km, dix-huit communes nommées et une FAQ de sept questions. La carte du secteur est une image : ni service tiers, ni cookie.

Au relevé du 1er octobre, douze jours après la mise en ligne, le site est 4e sur « éducation comportementale chien Le Vigan » et 9e sur « cours d’équitation Le Vigan ».

Technique : HTML statique, Cloudflare Pages, JSON-LD (ProfessionalService, FAQPage), Google Business Profile, Search Console, OpenStreetMap.

La demande de départ était une boutique Shopify. Or la maison avait déjà un site WordPress soigné, et WooCommerce y vendait sa carte cadeau. Un Shopify à côté, c’était un second socle à maintenir et un sous-domaine séparé du site que Google connaît déjà. J’ai proposé d’ajouter la brique boutique au site existant, et de mettre en valeur ce qui y était.

Le configurateur « Je choisis mon gant » tient en six étapes : la pointure, qui donne la taille de gant recommandée, la doublure, la matière, le budget, le modèle et son coloris, le papier cadeau. Chaque choix filtre le suivant, une combinaison sans modèle est barrée, et le récapitulatif affiche le prix à chaque clic.

Le catalogue ne se saisit pas à la main : le fabricant tient le sien sur Shopify, et Syncio le synchronise avec WooCommerce. 250 gants importés avec tailles, coloris et photos, la boutique gardant ses prix. Syncio ne transmet pas les commandes : une extension envoie donc au fabricant chaque commande payée, par e-mail, sans aucune donnée du client.

Tunnel de commande en français, paiement Stripe, livraison à domicile ou retrait en boutique.

Technique : WordPress, WooCommerce et Elementor chez Kinsta, deux extensions sur mesure (configurateur et habillage de la marque), Syncio, Stripe.

Le service branche les vraies données du site, Search Console, Analytics, Google Ads, DataForSEO, et une exploration du site lui-même. Il en sort des cartes : une page à écrire, un article, l’optimisation d’une page existante ou un correctif technique. Chaque carte porte ses preuves, la source, la commande ou le fichier, et la date de mesure. Sans preuve, la carte ne s’affiche pas.

La rareté d’une carte dit la taille du marché mesuré : or au-delà de 5 000 recherches mensuelles, puis épique, rare et commune. Le client voit ce que vaut l’occasion avant de commander, et le prix suit le travail demandé, pas le type de carte.

Tout se paie en gemmes, la monnaie de la boutique. Le compte se charge une fois, se dépense carte par carte sur tous les sites du client, et le solde ne périme pas. Le contenu commandé est ensuite produit, traduit en dix langues et mis en ligne.

Technique : Cloudflare Workers et base D1, paiement et abonnement Stripe, connexion par mot de passe ou par lien reçu par courrier, vérification des accès Google par compte de service. Un serveur MCP laisse l’IA poser les cartes directement dans la base, avec leurs preuves, au lieu d’une saisie à la main.

Le chantier commence par la concurrence. Qui occupe les requêtes de transfert CDG, Orly, Beauvais, avec quelles pages, quelle profondeur, quelles intentions laissées de côté. Les volumes et la difficulté de chaque requête sortent de DataForSEO, pas d’une intuition : c’est ce qui sépare une page qui rapporte d’une page que personne ne verra jamais.

La cannibalisation a été traitée en premier. Articles de blog et pages de destination se disputaient les mêmes requêtes, et Google tranchait seul, rarement en faveur de la page qui convertit. Chaque intention a désormais sa page, une seule, et le maillage interne pousse l’autorité vers elle au lieu de la diluer sur vingt et un liens identiques.

La technique suit le même fil : polices bloquantes au rendu, styles en ligne, sitemap, hreflang sur les dix versions, données structurées TaxiService, Offer et FAQPage, robots.txt qui ouvre la porte aux robots des moteurs de réponse et refuse l’entraînement. Le GEO, la visibilité dans les réponses générées par IA, se prépare maintenant, pas le jour où le trafic aura basculé.

43 contenus écrits, 28 pages et 15 articles, déclinés dans chaque langue, soit quelques centaines d’URL. Mise en ligne par vagues, Search Console ouverte à chaque étape : on sait ce que chaque lot a rapporté avant d’envoyer le suivant.