IP dédiée ou serveur privé : pour une liste blanche professionnelle, j’ai fini par choisir ce que je voulais administrer

Le message du client ne contenait qu’une ligne :

« Envoyez-nous l’adresse IP publique à ajouter à la liste blanche. »

J’étais chez moi lorsque je l’ai reçue. J’ai cherché « quelle est mon IP », copié l’adresse et répondu.

Deux jours plus tard, je travaillais depuis un coworking.

Accès refusé.

J’ai renvoyé ma nouvelle IP.

Le lendemain, j’ai utilisé le partage de connexion de mon téléphone.

Accès refusé.

À ce stade, le problème devenait embarrassant. Je n’avais aucun souci de mot de passe, aucun problème de droits et aucune panne chez le client. Son portail faisait exactement ce qu’on lui avait demandé : accepter uniquement certaines adresses réseau.

C’était moi qui arrivais chaque fois avec une nouvelle.

Je pensais alors avoir devant moi un choix très technique : acheter une IP dédiée chez un fournisseur VPN ou louer un serveur privé et construire moi-même une sortie fixe.

En réalité, la question qui a fini par décider était beaucoup moins spectaculaire :

est-ce que j’avais besoin de posséder l’infrastructure, ou simplement d’arriver chaque matin avec la même adresse ?

Une liste blanche ne s’intéresse pas à l’endroit où je suis assis

Les restrictions par adresse IP restent courantes dans les outils professionnels.

GitHub Enterprise permet par exemple de limiter l’accès aux ressources privées à une adresse ou à une plage d’adresses précise. Microsoft Entra peut lui aussi utiliser des plages IP comme « emplacements nommés » dans ses politiques d’accès conditionnel.

Dans certains scénarios, ce contrôle ne s’arrête même pas au moment de la connexion. Microsoft documente aussi une application stricte de la localisation où une session peut être réévaluée lorsque l’adresse observée ne correspond plus à un emplacement autorisé.

Autrement dit, je pouvais être parfaitement autorisé en tant que personne et tout de même me retrouver dehors parce que ma connexion arrivait par la mauvaise porte.

À partir de là, mon problème devenait très concret.

Si le client autorise 203.0.113.27, je dois arriver en 203.0.113.27.

Que je sois sur ma fibre, la 5G ou le Wi-Fi d’un hôtel n’a aucune importance pour son pare-feu.

J’avais donc besoin d’une sortie stable.

Pas simplement d’un VPN affichant « France ».

J’ai commencé par le serveur privé, parce qu’il semblait plus professionnel

Un petit VPS avec une adresse publique fixe me paraissait être la solution propre.

Je louais une machine virtuelle.

Je lui attribuais une adresse statique.

J’installais WireGuard.

Je demandais au client d’autoriser l’IP du serveur.

Ensuite, où que je sois, mon ordinateur rejoindrait ce serveur avant d’accéder au portail.

L’idée était séduisante parce que tout était sous mon contrôle.

Les fournisseurs cloud permettent facilement ce montage. DigitalOcean, par exemple, propose des adresses IP réservées, publiques et statiques, qui peuvent être associées à une machine virtuelle.

WireGuard permet ensuite de construire le tunnel avec relativement peu d’éléments : des clés, des pairs et des routes.

J’ai configuré le serveur.

J’ai donné son IP au client.

Il l’a ajoutée.

J’ai activé le tunnel.

Le portail s’est ouvert.

À ce moment-là, j’ai cru avoir terminé.

Puis j’ai réalisé que je venais aussi de m’offrir un serveur à administrer.

Le serveur privé résolvait le problème — et m’en créait un nouveau

C’est facile à oublier au moment de regarder le prix mensuel d’un VPS.

Je n’avais pas seulement loué une adresse IP.

J’avais loué un système d’exploitation.

Il fallait décider quels ports restaient ouverts, conserver les clés, maintenir WireGuard, vérifier le routage, surveiller la machine et ne pas laisser traîner les mises à jour.

Rien de tout cela n’était hors de ma portée.

C’était précisément ce qui me gênait.

Mon métier n’était pas d’exploiter un serveur VPN.

Une discussion publique entre professionnels de l’informatique résumait assez bien ce sentiment. Une entreprise entièrement distante expliquait que ses clients réclamaient une IP publique à placer sur leurs listes blanches. L’un des participants racontait avoir résolu le problème avec un VPS et WireGuard : la solution fonctionnait, mais lui donnait malgré tout l’impression d’un montage qu’il fallait désormais porter.

C’est là que j’ai commencé à séparer deux besoins que j’avais confondus.

Si je voulais contrôler la machine, ses règles réseau, ses utilisateurs et plusieurs routes professionnelles, le serveur privé avait beaucoup de sens.

Mais mon client ne m’avait jamais demandé tout cela.

Il voulait une adresse.

Une seule.

Qui ne change pas.

L’IP dédiée faisait moins de choses, et c’était soudain son avantage

J’ai alors testé l’autre approche : une adresse dédiée gérée par un fournisseur VPN professionnel.

Le principe tient presque en trois lignes.

Je me connecte au serveur réservé.

Ma connexion ressort toujours par la même IP.

Le client ajoute cette IP à sa liste blanche.

C’est tout.

Les offres professionnelles de ce type sont précisément conçues pour donner à une organisation une adresse statique qu’elle peut utiliser pour accéder à des ressources internes ou protégées. Proton, par exemple, présente explicitement cet usage dans sa documentation professionnelle.

J’ai transmis cette seconde adresse au client.

Elle a été autorisée.

Je me suis connecté depuis chez moi.

Portail ouvert.

J’ai recommencé avec le partage de connexion de mon téléphone.

Même adresse publique.

Portail ouvert.

Puis depuis un autre Wi-Fi.

Toujours la même sortie.

Toujours le portail.

À ce moment-là, les deux solutions avaient réussi le même test.

Mais une seule avait disparu de ma liste de choses à maintenir.

C’est ce qui a fait basculer mon choix.

J’avais confondu « plus de contrôle » avec « plus adapté »

Un serveur privé donne réellement davantage de contrôle.

Si j’avais une équipe, plusieurs clients, des règles de routage particulières, des machines internes à joindre ou des besoins d’automatisation, cette différence pourrait devenir décisive.

Je pourrais attribuer mes propres clés, segmenter les accès, choisir exactement ce qui passe dans le tunnel et faire évoluer l’architecture à mesure que mes besoins changent.

À ce niveau, je ne loue plus seulement une IP : je construis un petit morceau de mon infrastructure professionnelle.

Mais pour un indépendant qui doit simplement dire à un client « voici l’adresse à autoriser », une grande partie de cette liberté devient aussi du travail.

L’IP dédiée ressemblait à un badge d’accès fourni par la réception.

Le serveur privé revenait à louer la réception, installer le portique et garder les clés du local technique.

Les deux me faisaient entrer.

Je n’avais simplement aucune raison de vouloir réparer le portique le dimanche.

Il restait pourtant une chose que je ne voulais pas faire avec mon IP professionnelle

Une fois le problème de liste blanche réglé, j’ai fait une erreur assez naturelle : j’ai laissé la connexion dédiée activée pour tout.

Messagerie.

Recherche.

Actualités.

Navigation personnelle.

Quelques heures plus tard, cela m’a paru absurde.

L’intérêt d’une IP professionnelle fixe est justement qu’elle me suit.

C’est excellent lorsqu’un client veut reconnaître une origine stable.

C’est beaucoup moins utile lorsque je n’ai aucune raison de présenter cette même identité réseau à chaque site que je visite.

Une IP partagée de VPN et une IP dédiée poursuivent ici presque deux objectifs opposés.

Avec une adresse partagée, plusieurs utilisateurs peuvent apparaître derrière la même sortie.

Avec l’adresse professionnelle, je voulais au contraire être reconnaissable : « cette IP, c’est l’accès autorisé du prestataire ».

Proton souligne d’ailleurs ce compromis dans sa documentation : une IP dédiée offre moins d’anonymat qu’une sortie partagée, précisément parce qu’elle est réservée à une organisation.

C’est là que mon organisation a pris sa forme définitive.

Je n’avais pas besoin qu’une seule connexion fasse tout.

Mon IP fixe est devenue une clé que je ne sors que devant la bonne porte

Pour le portail client, j’active la sortie fixe.

C’est celle qui figure sur la liste blanche. Je veux qu’elle reste stable, prévisible et facile à retirer à la fin de la mission.

Lorsque j’ai terminé, je la coupe.

Pour le reste de mes déplacements et de ma navigation, j’ai installé OnlydogVPN^↗.

L’intérêt était presque l’inverse de celui de l’IP professionnelle : je n’avais plus besoin de conserver une identité réseau fixe. Je voulais retrouver un VPN quotidien simple, sans administrer de serveur et sans utiliser mon adresse whitelistée pour tous les sites ouverts pendant la journée.

Le service peut être utilisé sans passer par le parcours classique adresse e-mail–mot de passe, et son mode automatique évite de revenir devant une longue liste de régions chaque fois que je quitte le contexte professionnel.

Après avoir passé du temps à distinguer « mon accès client » de « ma connexion quotidienne », cette simplicité m’a paru beaucoup plus importante qu’elle ne l’aurait été au départ.

Ce n’est pas l’adresse que je présente au client.

Et c’est précisément pour cela que la séparation fonctionne bien.

Le badge professionnel reste devant la porte professionnelle.

Le reste du temps, je n’ai aucune raison de continuer à le porter.

Alors, IP dédiée ou serveur privé pour une liste blanche ?

Si l’entreprise vous demande simplement une adresse publique fixe à ajouter à sa liste blanche, je choisirais aujourd’hui une IP dédiée gérée.

Elle résout directement la règle imposée sans me transformer en administrateur d’un serveur supplémentaire.

Le serveur privé devient plus intéressant dès que l’adresse fixe n’est que le début du besoin : plusieurs utilisateurs, règles réseau spécifiques, segmentation, contrôle des clés, automatisation ou architecture que vous voulez réellement posséder.

Il faut aussi prévoir ce qui se passe si cette adresse devient indisponible. GitHub recommande notamment de conserver des possibilités d’accès de secours lorsqu’une organisation utilise des restrictions par IP, car une liste blanche mal préparée peut finir par enfermer ses propres administrateurs dehors.

C’est un bon rappel : une adresse fixe est une clé d’accès, pas toute la stratégie de sécurité.

Dans mon cas, j’avais commencé en pensant que le serveur privé serait forcément la solution la plus sérieuse.

Il l’était seulement si je voulais devenir responsable du serveur.

Mon client, lui, ne m’avait jamais demandé une infrastructure privée. Il m’avait demandé une ligne à ajouter à sa liste blanche.

Une fois cette distinction comprise, mon organisation est devenue beaucoup plus simple : une IP dédiée pour franchir la porte du client, puis un VPN quotidien qui ne m’oblige pas à porter ce badge professionnel partout ailleurs sur Internet.