Quand une intégration s’arrête, le réflexe est souvent d’examiner le logiciel qui ne reçoit plus ses données. Une modification d’infrastructure peut pourtant suffire à expliquer le problème. GitHub a annoncé le 29 octobre trois nouvelles plages IP pour ses webhooks. Les entreprises qui filtrent les messages entrants avec une liste statique doivent rapprocher ce réglage des nouvelles informations officielles, sans confondre autorisation réseau et validation du contenu transmis.
Une mise à jour pour les listes maintenues à la main
Le billet de GitHub ajoute les préfixes 9.234.98.160/28, 9.234.98.176/28 et 9.234.106.48/28 au champ hooks de l’API Meta. Les plages concernent github.com sur toutes les offres, dont Enterprise Cloud.
L’entreprise demande de les ajouter aux adresses déjà autorisées lorsque le filtrage repose sur une liste fixe. En revanche, une liste déjà alimentée depuis l’API Meta n’exige pas de modification particulière pour ces ajouts.
Cette différence mérite d’être vérifiée avant toute intervention. Le même service peut être utilisé par deux entreprises avec des modes de maintenance réseau très différents.
Un événement peut partir sans que la suite démarre
Le webhook transmet l’information qu’une action s’est produite. Le service destinataire utilise ensuite cette information pour poursuivre un traitement. Si le message est refusé avant d’atteindre l’application, cette dernière peut sembler ne rien faire alors que le blocage se situe plus tôt.
Pour un diagnostic, on peut donc suivre plusieurs étapes distinctes : l’événement a-t-il été créé, la livraison a-t-elle été tentée, le message a-t-il été accepté et quel traitement a suivi ? Chaque réponse réduit le périmètre de recherche.
Cette méthode évite de changer un réglage applicatif uniquement parce qu’il est le plus visible. Elle permet aussi de demander au bon interlocuteur le journal ou la preuve qui manque.
La liste IP ne remplace pas l’authentification du message
Les recommandations GitHub pour les webhooks prévoient notamment HTTPS, la vérification du certificat et un secret destiné à valider les livraisons. Le filtrage d’origine ne constitue donc pas l’ensemble du contrôle.
La documentation décrit aussi les délais de réponse et les identifiants de livraison. Lorsqu’un événement est renvoyé, son identifiant reste le même. Cette information est utile pour distinguer une reprise d’un événement réellement nouveau.
Il ne serait pas raisonnable d’ouvrir largement les accès pour faire disparaître un refus sans comprendre la cause. L’ajout doit correspondre au périmètre justifié et au fonctionnement attendu de l’intégration.
La preuve attendue est un résultat métier complet
Après une adaptation réalisée par les personnes responsables, un essai doit pouvoir montrer que le message passe et que son effet est correct. Une connexion acceptée ne prouve pas encore qu’une mise à jour de dossier ou qu’une action automatique a abouti.
Il faut également examiner le cas d’une reprise. Si une livraison manquée est renvoyée, le service doit éviter un effet répété lorsque l’opération ne devait avoir lieu qu’une fois. Le scénario mérite une discussion avant un incident, pas uniquement après l’apparition d’un doublon.
Notre article sur la conception de flux automatisés fiables revient sur ce besoin de suivre le parcours complet, avec ses erreurs et ses conditions de reprise.
Retrouver le responsable du réglage fait partie de la maintenance
Une liste peut rester figée parce que sa création est ancienne et que personne ne sait plus qui la suit. L’annonce offre une occasion de documenter la source utilisée, le responsable et la façon de vérifier une mise à jour.
Ce travail rejoint le suivi des dépendances présenté dans notre dossier sur le coût complet d’une application cloud. Les services reliés continuent à évoluer même lorsque l’application de l’entreprise ne change pas.
Les nouvelles adresses GitHub représentent une évolution limitée, mais elles peuvent avoir un effet très concret sur des automatismes quotidiens. Le bon contrôle commence par le type de liste utilisé et se termine par une livraison représentative dont le résultat est vérifié. Entre les deux, conserver les preuves et les responsabilités évite de transformer une petite mise à jour réseau en longue recherche de panne. Une vérification peut aussi noter le moment du dernier succès connu. Ce repère aide à rapprocher un refus des changements intervenus dans la chaîne. Il ne prouve pas à lui seul la cause, mais il fournit au support une chronologie plus utile qu’une simple impression de panne récente.
Je suis Romain Delcourt, rédacteur tech passionné par le numérique et l’intelligence artificielle. J’écris pour décoder les tendances, les outils et les changements qui façonnent nos usages au quotidien.
