Arrêtez de perdre des leads : résilience et observabilité des intégrations WordPress

Un formulaire envoie ses leads vers le CRM par API. Validé en recette, ça marche. Six mois plus tard, le CRM tombe deux heures un mardi matin. Aucune alerte, aucun log, aucune reprise. Les leads partent dans le vide, et personne ne le découvre avant trois semaines.

Cette conférence part d’un constat fait sur des dizaines d’audits de projets, toutes agences confondues : la résilience est le point aveugle des intégrations WordPress. La recette valide le chemin qui marche, jamais le chemin qui échoue. Chaque dépendance externe est traitée comme si elle était éternellement disponible – une panne silencieuse en attente.

En partant du principe que « si ça peut échouer, ça échouera », on déroule les trois piliers d’une intégration qui résiste : savoir qu’elle a échoué (observabilité, logs structurés, alerting), ne pas perdre la donnée (découplage, persistance locale, outbox, files fiables), et réparer intelligemment (retry, backoff, circuit breaker). Le tout ancré dans WordPress (Action Scheduler, wp_remote_*, fragilité de WP Cron) et calibré par une échelle de maturité : tout le monde n’a pas besoin de tout blinder, mais tout le monde doit choisir son niveau en conscience du risque métier.

https://bretagne.wordcamp.org/2026/session/arretez-de-perdre-des-leads-resilience-et-observabilite-des-integrations-wordpress/

Transcript

1. Arrêtez de perdre des leads Résilience et observabilité des intégrations WordPress Amaury Balmer · Be API
2. WordPress au cœur des échanges Offres d'emploi Catalogue ATS WordPress Recrutement le site Candidatures CRM / ERP Métier Leads (formulaire) Chaque intégration peut échouer. 2 / 26
3. Un scénario trop fréquent en audit wp_remote_post( $url, array( 'body' => $data, ) ); delete_data(); On envoie. On supprime. On ignore le résultat. 3 / 26
4. Première réflexion : autant l’assumer wp_remote_post( $url, array( 'body' => $data, 'blocking' => false, ) ); Sans réponse, l’appel reste un monologue. 4 / 26
5. L’anticipation s’apprend Faire fonctionner le cas attendu. Imaginer aussi ce qui peut échouer. L’expérience construit ce réflexe. 5 / 26
6. Ce que j’aurais aimé apprendre Au-delà des algorithmes et des langages… Anticiper les risques du projet. Concevoir le comportement en cas d’échec. 6 / 26
7. LA LOI DE MURPHY Tout ce qui peut mal tourner tournera mal. Une consigne de conception.
8. Murphy et les intégrations tierces Réseau coupé. API lente. Token expiré. Format modifié. Quota dépassé. Bref : un lundi ordinaire. 8 / 26
9. Les six questions du client 01 Est-ce que ça marche ? 02 Combien d’échecs, et depuis quand ? 03 A-t-on perdu des données ? 04 Pourquoi ça échoue ? A-t-on les erreurs ? 05 Peut-on renvoyer les données après correction ? 06 Peut-on les exporter ? 9 / 26
10. C HA N G E M E N T D E P A R A D I G M E 1 La conduite de projet ▪ Le comportement en cas d’échec se décide dès le projet.
11. Le coût métier de l’échec 100 candidatures perdues chaque jour Scénario illustratif Un lead payé puis perdu : un budget d’acquisition gaspillé. La criticité métier détermine l’effort de résilience. 11 / 26
12. La recette des scénarios d’échec Est-ce que ça marche ? Est-ce que ça résiste ? Les deux questions font partie de la recette. 12 / 26
13. Un premier test de panne En recette, rendre l’API inaccessible. La donnée est-elle conservée ? L’échec est-il détecté ? Au retour du service, la reprise fonctionne-t-elle ? 13 / 26
14. À froid, pas sous les SMS Le client attend des réponses. Vous cherchez des traces et un moyen de réparer. Ces moyens se préparent avant l’incident. 14 / 26
15. C HA N G E M E N T D E P A R A D I G M E 2 7 points côté développement ▪ De la réponse de l’API à la reprise des données.
16. La programmation défensive Le tiers peut être absent. La donnée peut être invalide. Le réseau peut lâcher. Le code prévoit la suite. 16 / 26
17. 1. Écouter 2. Journaliser Vérifier le statut et le contenu de la réponse. Relier les événements avec un identifiant commun. Garder le contexte métier et l’horodatage. Activer le debug au besoin, en masquant les secrets. 17 / 26
18. Toutes les erreurs ne se valent pas TRANSITOIRE CORRECTION REQUISE Indisponibilité temporaire Quota dépassé Champ devenu obligatoire Donnée invalide Réessayer avec un délai. Isoler, alerter, corriger. Puis rejouer. 18 / 26
19. Des faits pour diagnostiquer Quel appel, à quelle heure ? Quelle donnée envoyée ? Quelle réponse reçue ? Un identifiant partagé pour rapprocher les traces. Logs détaillés : accès limité, données minimisées, durée bornée. 19 / 26
20. L A R ÈG L E D ’O R La donnée touche le disque avant de toucher le réseau ▪ Stocker d’abord. Envoyer ensuite. ▪ Conserver tant que le succès n’est pas confirmé.
21. 3. Notifier 4. Conserver dans un tampon 1. Stockage durable 2. Envoi asynchrone 3. API du tiers Succès confirmé Échec ou résultat incertain Sortir la donnée du tampon. Conserver, tracer, puis reprendre. Alerter selon la criticité. Le traitement doit distinguer « enregistré » et « transmis ». 21 / 26
22. Le stockage et les données personnelles La transmission est déjà un traitement. Le tampon ajoute une conservation locale. Limiter les données, les accès et la durée. Purger le tampon après succès, selon le besoin métier. 22 / 26
23. 5. Rejouer sans créer de doublon Des tentatives de plus en plus espacées 1 Envoi 2 3 4 + 1 min + 2 min + 4 min Exemple illustratif. Ajouter du jitter et borner les tentatives. Un retry idiot achève le tiers ou votre appli. . 23 / 26
24. 6. Analyser 7. Exporter Voir les erreurs et relancer les données corrigées. Superviser le traitement planifié côté serveur. Exporter les données en attente si le tiers reste bloqué. Détecter tôt pour permettre une action métier. 24 / 26
25. L’IA a besoin de ces exigences /goal Aucune donnée perdue Aucun échec silencieux Aucun mystère Les six questions guident le développement et la revue. Les tests vérifient ce que le code fait réellement. 25 / 26
26. Trugarez Merci Aucune donnée perdue. Aucun échec silencieux. Aucun mystère. bretagne.wordcamp.org/2026 · #WCBZH