Hostpoint ou manitu pour vérifier un webhook entrant après une migration WordPress

La page répond, le webhook a-t-il suivi ?

Une petite équipe publie sa documentation sur WordPress. Quand une version de son logiciel paraît, un webhook GitHub avertit le site et déclenche la préparation d’une note de version en brouillon. L’équipe déplace WordPress vers un autre hébergement en gardant le même nom de domaine. L’accueil répond sur le nouvel hébergement. Pendant ce temps, des requêtes peuvent encore arriver sur l’ancien, et un contrôle en GET ne dit rien sur le POST qui doit préparer le brouillon.

Le soir de la bascule, comparez trois traces pour chaque publication. GitHub indique si la livraison HTTP a été acceptée. Le récepteur indique si la livraison signée est entrée dans sa file. Le traitement en arrière-plan indique si le brouillon a été créé ou mis à jour. Notez l’identifiant de livraison, celui de la version et l’heure UTC. Vous pouvez ainsi expliquer un événement absent ou rejoué sans consulter le contenu signé dans un journal.

Hostpoint Hébergement Web Standard et manitu Webhosting M sont deux offres mutualisées qui permettent de faire tourner un récepteur PHP et de planifier le traitement. Le choix dépend de la place de la base, du délai admis avant l’apparition du brouillon et de la possibilité de suivre la même requête entre les deux hébergements. Les plafonds de PHP et du planificateur décrivent des ressources distinctes du délai de réponse de GitHub.

Deux forfaits pour un récepteur léger

Hostpoint affiche son Hébergement Web Standard à 15,90 CHF TTC par mois, avec 100 Go de stockage web et dix bases MariaDB. Douze mois au même prix donnent 190,80 CHF sur la base du tarif affiché. L’aide cite des durées d’hébergement de six, douze ou vingt-quatre mois, avec reconduction automatique pour la même durée et résiliation au plus tard trente jours avant l’échéance. Vérifiez le cycle proposé, la fiscalité de votre facture et le total du contrat. Le panneau documente le téléchargement des journaux d’accès et d’erreur par site et par date.

Le comparateur de manitu affiche Webhosting M à 1,00 € par mois pendant six mois, puis 5,99 €, au prix brut allemand avec 19 % de TVA. Il indique un engagement initial de douze mois, facturés d’avance, puis une prolongation d’un mois et une facturation semestrielle d’avance. Les deux durées répondent à des questions différentes. Le préavis indiqué est de deux semaines. Au barème allemand relevé et hors options, comptez 41,94 € pour la première année. Douze mois au tarif normal donnent un repère de 71,88 € si le prix reste stable. Le site indique un prix brut dépendant du pays sélectionné.

Pour un nouveau compte manitu M, le tableau de comparaison distingue 50 Go de stockage web et 50 Go de messagerie. La carte de l’offre annonce 100 Go de stockage. Pour dimensionner les fichiers WordPress, prenez le quota web du tableau et confirmez la répartition du compte. Le tableau annonce aussi cinq bases, avec 1 Go maximum chacune, et cinq tâches cron avec 120 secondes par exécution et jusqu’à douze exécutions par heure et par tâche. Mesurez le volume des tables existantes avant d’y ajouter la file. Si elle tient dans une base séparée, intégrez aussi la sauvegarde de cette base et le suivi de ses droits dans la recette. Les deux prestataires documentent des journaux web. Une trace d’accès peut aider à identifier le serveur et la réponse, tandis que l’identifiant de livraison et le statut du brouillon doivent venir de l’application.

Tester le POST qui arrivera vraiment

Sur la copie privée, repérez l’URL exacte qui reçoit le webhook, le type d’événement attendu et la version du code qui vérifie la signature. Excluez cette route du cache et des redirections générales qui risqueraient de remplacer ou détourner le POST. Une page de maintenance, une demande d’authentification interactive ou une page d’accueil statique peuvent répondre correctement aux visiteurs tout en rendant la route inutilisable pour l’émetteur. Faites servir la route sous le certificat et le nom de domaine prévus.

Dans l’exemple GitHub, le récepteur vérifie l’en-tête de signature avec le secret du webhook et le corps brut, avant de décoder le JSON. Le code compare la signature en temps constant et contrôle que l’événement et l’action correspondent au cas attendu, ici une version publiée d’un dépôt prévu. Installez le secret dans la configuration du serveur et maintenez-le hors des URLs, journaux et artefacts. Pour le test, utilisez des événements et un secret de démonstration dans un environnement maîtrisé.

Une réponse 2xx n’a de valeur que si elle suit l’écriture durable de la livraison. Enregistrez l’identifiant et ce qui sera nécessaire au traitement dans une transaction courte. Répondez rapidement après validation de l’écriture. GitHub attend une réponse 2xx sous dix secondes. Une page WordPress lourde, un appel externe ou l’écriture complète du brouillon dans la requête réduisent cette marge. Une base indisponible doit remonter une erreur observable au lieu de faire disparaître l’événement derrière une page de succès.

Garder les livraisons quand l’ancien serveur répond encore

Préparez une fenêtre pendant laquelle l’ancien serveur reste accessible, avec des repères UTC sur les deux copies. Gardez l’URL du webhook et son secret lorsque la migration le permet. Le nom de domaine peut rester identique alors que deux origines se succèdent. Identifiez l’origine qui a accepté chaque requête dans le journal applicatif. Si vous changez aussi l’URL configurée chez l’émetteur, notez l’heure exacte et vérifiez quel chemin recevra les relivraisons.

Deux récepteurs temporaires sont acceptables s’ils écrivent dans le même registre durable et si l’effet est appliqué par un seul traitement autorisé. Le tableau manitu indique que ses bases ne sont pas joignables depuis l’extérieur. Avec une base manitu, privilégiez une seule entrée stable. Le guide de l’hébergement Web Hostpoint décrit la possibilité d’autoriser un hôte externe pour un utilisateur de base. Confirmez les droits sur Standard, les restrictions réseau des deux comptes et la possibilité d’utiliser une connexion protégée avant de retenir un registre partagé. Si la voie n’est pas disponible, choisissez une entrée stable ou suspendez brièvement la réception pendant la transition. Dans ce deuxième cas, rendez l’échec explicite et réconciliez les tentatives de cette fenêtre depuis GitHub avant de clore le transfert.

Une ancienne copie qui accepte une livraison dans une base abandonnée peut faire afficher un succès chez GitHub. Le nouvel hébergement ne pourra alors rien traiter. Si les bases doivent rester distinctes, révoquez le droit d’accepter les livraisons sur l’ancienne copie avant d’autoriser la nouvelle. Une sauvegarde initiale de la base ne contient aucune livraison reçue après l’export. Relevez précisément le dernier identifiant transféré et inspectez les deux journaux pendant le recouvrement.

Séparer la livraison de son effet

L’identifiant de livraison répond à la question « avons-nous déjà enregistré cette requête ? ». Le brouillon répond à une autre question. Enregistrez une clé métier stable, par exemple le dépôt et l’identifiant de la version publiée. En cas de relivraison GitHub, l’en-tête X-GitHub-Delivery conserve la valeur d’origine. Un autre identifiant de livraison peut toutefois désigner la même version dans une intégration ou une recette. Le traitement doit retrouver le même brouillon. Une contrainte d’unicité protège la file contre deux insertions concurrentes.

Le traitement relit les lignes en attente par petits lots. Dans la maquette, l’effet et la mise à jour du statut partagent une transaction. Quand le vrai WordPress ou un service externe ne permet pas cette atomicité, utilisez une écriture répétable à partir de la clé métier et un état de traitement que vous pouvez réconcilier. Après une panne entre la création du brouillon et le marquage de la livraison, retrouvez le brouillon par sa clé avant toute nouvelle tentative. Une action déjà envoyée à un service externe exige la vérification de ce service. L’atomicité de SQLite dans la maquette ne prouve pas celle d’une opération WordPress ou externe.

Rendez les états lisibles. Une ligne en attente a passé le contrôle d’entrée mais attend le prochain lot. Une ligne traitée pointe vers un identifiant de brouillon. Une erreur réessayable porte un compteur et une heure de dernière tentative. Une ligne écartée pour événement hors périmètre doit être distinguée d’une livraison perdue. Définissez combien de temps garder ces preuves, combien de données du corps stocker et qui peut accéder aux journaux. Un identifiant et une empreinte peuvent suffire après traitement.

Dimensionner la file et mesurer son retard

Sur manitu M, le plafond de douze exécutions par heure et par tâche rend un contrôle périodique toutes les cinq minutes cohérent avec le barème. L’attente avant le premier passage peut approcher cinq minutes si tout va bien. Elle augmente si des lots s’empilent ou si le processus échoue. La durée autorisée de 120 secondes par tâche impose un budget par lot. Mesurez le nombre de lignes effectivement traitées au cours d’une exécution et gardez une marge avant la fin du temps disponible.

Sur Hostpoint, le gestionnaire cron documente un exemple toutes les cinq minutes. Cette configuration ne fixe pas un délai de traitement garanti. Vérifiez les paramètres d’exécution réellement disponibles sur Standard. Associez aux journaux du panneau un statut de traitement applicatif et une mesure du plus ancien événement en attente. Testez la sortie du cron en recette pour pouvoir distinguer une panne du traitement d’une absence de livraisons.

Supposons que votre test applique vingt mises à jour en un passage et que quarante-cinq événements arrivent en même temps. Si aucune autre ligne n’arrive et si chaque passage fonctionne, il en faut trois. Avec un passage toutes les cinq minutes, la fin du dernier lot peut tomber jusqu’à environ quinze minutes après l’arrivée, auxquels s’ajoute le temps de traitement du lot. Si la rédaction attend une mise à jour en deux minutes, adaptez l’architecture ou le délai accepté. Gardez séparés le temps de réponse HTTP et l’âge du plus ancien événement en attente.

Mesurez également la taille de la file avec ses index et son historique. Sur manitu M, une base WordPress déjà proche de 1 Go ne retrouve pas de marge parce que le forfait annonce 50 Go de stockage web. Sur les deux offres, un volume de webhooks sans commune mesure avec le scénario d’un petit site demande un essai de charge maîtrisé, une politique de purge et une estimation du temps de vidage après panne. Le calcul de trois passages illustre le débit, avec des valeurs fictives.

Réconcilier les tentatives avant de retirer l’ancien site

Prenez dans GitHub les tentatives de livraison depuis le dernier point de contrôle précédant la bascule. Comparez-les au registre commun ou, si la réception a dû être arrêtée, au journal importé et à celui du nouveau site. Pour une tentative en échec avec un identifiant déjà enregistré, vérifiez le traitement avant de relancer. Il est possible que l’écriture ait abouti et que la réponse n’ait pas été reçue. Un deuxième envoi du même identifiant doit laisser une seule ligne.

Une tentative HTTP réussie qui ne correspond à aucune entrée de la file exige aussi une action. Vérifiez d’abord si la requête a atteint l’ancienne copie, le cache ou une page générique. Corrigez la destination, puis redemandez la livraison et vérifiez l’écriture. GitHub ne relivre pas automatiquement les webhooks en échec. Sa documentation indique que les livraisons des trois derniers jours peuvent être renvoyées. Planifiez le contrôle et la reprise dans cette fenêtre.

Si une livraison sort de la fenêtre de reprise, comparez l’état métier avec la liste des versions déjà publiées. Reconstituez les brouillons qui manquent à partir d’une source approuvée et rattachez la correction au journal de migration. Sur le vrai site, confirmez que les brouillons restent privés et que l’ancien traitement ne peut plus modifier les données. Relever des totaux seuls peut masquer un doublon et une absence qui se compensent. Vérifiez les identifiants ligne par ligne sur la période courte de transfert.

Rejouer le scénario hors ligne

Le ZIP de recette fait tourner deux serveurs HTTP locaux et un registre SQLite partagé. Les requêtes d’essai sont signées et envoyées aux deux origines. Le premier test reçoit 200 sur l’accueil et 404 sur un mauvais chemin POST. Un POST à signature incorrecte est rejeté. Une page générique rend également un vrai 200, tandis que le compteur du registre ne bouge pas. La recette rejoue cette livraison et une tentative à 503 après avoir rétabli la bonne destination.

L’ancien serveur accepte la première livraison. Le banc suppose ensuite que l’émetteur n’a pas observé son accusé et lui fait renvoyer le même identifiant au nouveau serveur. Le registre garde une seule entrée et conserve l’origine de la première écriture. Une autre livraison du même événement métier remplit une ligne distincte de la file. Elle doit aboutir au même brouillon de version, ce qui vérifie la différence entre les deux clés.

Le traitement insère un brouillon puis déclenche une panne avant la fin de la transaction. La base annule l’insertion. La relance traite les quatre entrées et produit trois brouillons. Un passage supplémentaire ne change rien. Le rapport donne les codes HTTP et les compteurs avant et après traitement. Il démontre ces comportements dans la maquette, où l’effet et le statut partagent SQLite. Faites une recette séparée du DNS, du certificat, du planificateur et de la persistance des brouillons sur l’environnement réel.

• Extrayez le ZIP dans un dossier vide. Lancez python recette.py avec Python 3.10 ou supérieur.
• Comparez les codes HTTP et les compteurs. Un 200 sans enregistrement et un 503 sont tous deux repris par la recette.
• Vérifiez que les quatre livraisons produisent trois brouillons et qu’un passage supplémentaire ne crée aucun effet. Rejouez ensuite les contrôles propres à votre hébergement et à votre intégration.

Décider à partir du délai et des preuves

Hostpoint Standard convient si les journaux téléchargeables facilitent le suivi de la bascule et si votre équipe peut suivre la file avec un cron testé. Ses dix bases offrent de la souplesse pour séparer la recette ou la file de WordPress. Vérifiez la limite d’une base et les conditions d’accès si un registre partagé entre deux origines est nécessaire. Le tarif mensuel affiché doit être rapproché de la durée choisie et de la période de coexistence.

manitu Webhosting M convient si la file tient dans les limites documentées et si le délai éditorial tolère le rythme de la tâche. Prenez comme repères le plafond par base, les cinq tâches et les 120 secondes par exécution. Si WordPress et la file partagent une base, mesurez la marge de celle-ci. Les six premiers mois à tarif réduit ne ramènent pas l’engagement à six mois. Vérifiez le montant d’avance et le prix brut associé à votre pays.

Autorisez la bascule lorsque le POST signé atteint l’origine prévue et que chaque livraison testée se retrouve dans le registre avec un effet unique. Documentez le délai de réponse, l’âge de la file et le mode de reprise. Si une des tentatives reste ambiguë, gardez le site ancien en état de diagnostic et empêchez-le d’appliquer les événements. Au terme de la fenêtre, consignez le dernier identifiant rapproché et le moment où l’ancienne origine a cessé de traiter. Une future relivraison doit trouver la preuve précédente.

• Vérifier la route POST et l’enregistrement durable avec un événement de test.
• Comparer les tentatives et les entrées du registre par identifiant.
• Rejouer les livraisons manquées dans la fenêtre disponible.
• Valider le délai de traitement et le brouillon unique avant de retirer l’ancienne origine.

Pour aller plus loin

• Lire la fiche Hostpoint
• Lire la fiche manitu
• Comparer les outils de migration WordPress
• Télécharger la recette du webhook entrant (ZIP)