Endpoint

Point de terminaison : l’extrémité d’un échange

Une adresse par opération

Une boutique en ligne qui fait payer une commande ne clique sur rien : elle envoie une demande au service de paiement et reçoit une réponse lisible par une machine. Vérifier une carte, encaisser, rembourser : chaque opération a son adresse propre. Une API expose donc rarement une seule adresse, mais une liste, que la documentation du service décrit une à une.

Le même mot désigne aussi vos postes

En sécurité, « endpoint » ne veut pas dire une adresse mais un appareil : le poste de travail, le portable, le téléphone, tout ce qui se trouve au bout du réseau et par où entre la plupart des attaques. C’est le sens du E dans EDR. Un fournisseur qui parle de « protection des endpoints » parle de vos machines ; un développeur qui parle d’un « endpoint à migrer » parle d’une adresse. Le contexte tranche, mais il faut savoir que les deux existent.

Pourquoi ils survivent à ceux qui les ont créés

Un endpoint n’est pas un objet qu’on voit : il n’a ni icône, ni fenêtre, ni facture mensuelle. Quand le service qu’il servait est remplacé, la nouvelle adresse est mise en service, l’ancienne reste joignable, et personne n’est chargé de l’éteindre. Elle répond encore, avec le code et les droits du jour où elle a été posée, comme un Shadow IT que l’entreprise aurait fabriqué elle-même.

La question qui les fait apparaître

« Quelles adresses de notre système répondent aujourd’hui à quelqu’un qui les appelle depuis l’extérieur ? » Elle se pose à un prestataire comme à une équipe interne, et la réponse tient en une liste : l’adresse, ce qu’elle expose, qui a le droit de l’interroger, et la date prévue de son retrait. Tenir cette liste à jour est ce qui sépare une surface d’attaque connue d’une surface d’attaque subie.

Mise à jour : 27 septembre 2026