Un événement est bien déclenché dans un service, mais rien ne se passe dans l’outil qui devait le recevoir. Avant de chercher une erreur dans le code, certaines équipes devront vérifier leur filtrage réseau. GitHub annonce le 29 octobre de nouvelles plages IP pour les livraisons de webhooks. L’évolution concerne particulièrement les intégrations dont les adresses autorisées ont été inscrites une fois, puis laissées sous forme de liste statique.
Les données officielles incluent trois préfixes supplémentaires
Le billet de GitHub ajoute 9.234.98.160/28, 9.234.98.176/28 et 9.234.106.48/28 dans le champ hooks de l’API Meta. Les listes statiques doivent intégrer ces ajouts aux plages déjà présentes pour ne pas refuser certaines livraisons.
GitHub précise que l’évolution concerne github.com et toutes ses offres, dont Enterprise Cloud. Les systèmes qui maintiennent déjà leur liste depuis l’API Meta n’ont pas de changement spécifique à effectuer pour ces ajouts.
L’annonce ne demande donc pas de supprimer le filtrage. Elle invite à confronter les adresses effectivement autorisées à la source officielle utilisée pour les tenir à jour.
Le symptôme métier peut cacher un refus technique
Un webhook sert à transmettre une information d’événement d’un service à un autre. L’intégration peut ensuite actualiser un état, créer un élément ou déclencher une autre tâche. Si le message est bloqué avant d’arriver au traitement, le résultat attendu ne se produit pas.
La personne qui constate le problème peut ne voir qu’un retard dans son tableau ou une action absente. Pour diagnostiquer, il faut séparer le départ du message, sa réception et son traitement. Chaque étape apporte une preuve différente.
Cette distinction permet aussi de répartir le travail entre les responsables du service source, du réseau et de l’application destinataire. Elle évite que chacun modifie son composant sans savoir à quel endroit le parcours s’interrompt.
Le secret et le certificat gardent leur rôle
Les bonnes pratiques officielles recommandent l’usage de HTTPS et la vérification du certificat. Elles décrivent également un secret permettant de valider les livraisons, ainsi que l’identification des événements.
Le filtrage des adresses ne doit donc pas être présenté comme l’unique validation du message reçu. Une autorisation réseau et une vérification de contenu répondent à des questions différentes dans le même parcours.
La documentation prévoit aussi une réponse rapide du serveur et la possibilité de traiter le contenu en arrière-plan. Ces aspects doivent être examinés dans la configuration réelle de l’intégration, avec les personnes qui en assurent la maintenance.
Le renvoi d’un message n’est pas un nouvel événement
Un service peut devoir renvoyer une livraison manquée. Il faut alors éviter que la reprise produise deux fois un effet qui ne devait se produire qu’une seule fois. La documentation GitHub précise qu’une nouvelle livraison du même événement conserve son identifiant.
Pour l’équipe métier, cela invite à poser une question simple : que se passe-t-il si le même message arrive de nouveau ? Un succès dans le cas habituel ne permet pas de répondre à cette situation.
Notre article sur les erreurs et doublons dans les intégrations détaille cette exigence de démonstration. Les scénarios de reprise font partie du fonctionnement à vérifier, au même titre que le premier passage réussi.
Une règle entretenue est plus utile qu’un réglage oublié
La nouvelle plage IP peut être l’occasion de retrouver qui possède la responsabilité de la liste et à quelle fréquence elle est revue. Une intégration reste parfois fragile simplement parce que personne ne sait plus quelle information fait référence.
Il est utile de conserver un compte rendu bref après un contrôle : source consultée, règle examinée et résultat d’un événement représentatif. Cette trace aide à distinguer une configuration vérifiée d’une supposition lorsque le prochain incident survient.
Notre dossier sur les questions à poser avant de connecter deux logiciels rappelle que la maintenance doit être discutée avant de considérer une liaison comme acquise.
L’annonce du 29 octobre est technique, mais son intérêt pour l’entreprise est concret : préserver le passage entre un événement et son résultat. Identifier les listes statiques, suivre la source officielle et vérifier une livraison complète permet d’aborder ce changement sans confondre ouverture réseau, authenticité du message et bonne exécution de la tâche. Cette vérification peut aussi servir d’exemple pour le prochain changement d’infrastructure : une source identifiée, un responsable connu et une preuve du résultat attendu rendent la maintenance plus simple.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
