De combien d’espace IPv4 avez-vous besoin ? Tailles de blocs (/24, /23, /22, /21, /20) et guide de dimensionnement
La plupart des entreprises devraient dimensionner leur espace IPv4 en commençant par un /24 — le plus petit bloc que l’Internet mondial peut router de manière fiable — puis augmenter la taille en fonction du nombre d’adresses réellement consommées par leurs services, tout en prévoyant une marge pour la croissance. Un /24 fournit 256 adresses ; chaque niveau supérieur double approximativement ce nombre. La bonne taille est celle qui couvre votre utilisation réelle des adresses et votre croissance à court terme, sans vous obliger à payer pour de grandes quantités d’espace que vous ne pouvez ni justifier ni utiliser.
Table of Contents
ToggleLa question revient constamment lorsqu’une entreprise loue ou achète des adresses IPv4, et elle s’accompagne généralement d’une seconde question : que signifient réellement des notations comme /24, /22 ou /20 ? Ce guide répond aux deux. Il associe chaque taille de bloc courante au nombre d’adresses qu’elle contient et aux situations auxquelles elle convient, puis propose un cadre pratique pour traduire vos besoins de services en taille de bloc. L’objectif est de prendre une décision que vous pouvez justifier — auprès d’un registre, de votre équipe financière et dans votre propre planification de capacité — plutôt que de faire une estimation qui vous laisserait à l’étroit ou en situation de surprovisionnement.
Il s’agit d’un guide de dimensionnement et de choix de taille de bloc, et non d’un tutoriel sur le subnetting. Pour comprendre les mécanismes sous-jacents de division des blocs d’adresses et le fonctionnement de la notation CIDR au niveau des bits, consultez notre guide dédié au subnetting IP et au CIDR ; ici, l’objectif est de choisir la quantité d’espace appropriée pour un déploiement réel.
De combien d’IPv4 avez-vous besoin ? Réponse courte
Additionnez les adresses publiques dont vos services ont réellement besoin, ajoutez une marge de croissance raisonnable, puis arrondissez à la taille de bloc routable la plus proche — avec /24 comme minimum pratique. Trois facteurs déterminent la réponse :
-
- Le seuil du /24. Le système de routage mondial n’accepte généralement pas les préfixes plus petits qu’un /24. Un /24 (256 adresses) constitue donc le minimum pratique pour un espace public annoncé indépendamment, même si vous avez besoin de moins d’adresses.
-
- Votre empreinte réelle de services. Le nombre d’adresses publiques réellement consommées par votre hébergement, vos serveurs de messagerie, VPN, équilibreurs de charge et autres services — souvent inférieur à ce que l’on imagine au départ, mais parfois supérieur.
-
- La marge de croissance. Une capacité disponible suffisante pour vous développer sans devoir renuméroter rapidement, mais pas au point de conserver — et de payer — un espace que vous ne pouvez ni utiliser ni justifier.
Si ces trois éléments sont correctement évalués, la taille du bloc devient généralement évidente. Le reste de ce guide explique comment les déterminer avec précision.
Tailles des blocs IPv4 en un coup d’œil
Les tailles de blocs IPv4 sont exprimées en notation CIDR sous la forme d’une barre oblique suivie d’un nombre — plus le nombre est petit, plus le bloc est grand. Chaque diminution du numéro de préfixe (de /24 à /23 puis /22) double le nombre d’adresses. Voici les tailles les plus courantes lors de la location ou de l’achat d’IPv4 :
| Notation CIDR | Nombre total d’adresses | Équivalent | Utilisation typique |
|---|---|---|---|
| /24 | 256 | 1× /24 | Plus petit bloc routable ; petits déploiements, services uniques, location d’entrée de gamme |
| /23 | 512 | 2× /24 | Hébergement en croissance, petits pools VPN, entreprises dépassant la capacité d’un seul /24 |
| /22 | 1,024 | 4× /24 | Fournisseurs d’hébergement et de services de taille moyenne, déploiements VPN ou SaaS plus importants |
| /21 | 2,048 | 8× /24 | Fournisseurs de plus grande taille, opérateurs multi-services |
| /20 | 4,096 | 16× /24 | FAI, grandes plateformes d’hébergement, opérateurs réseau de taille importante |
Une remarque concernant les adresses « utilisables » : lorsqu’un bloc routé est subdivisé en sous-réseaux, un petit nombre d’adresses sont traditionnellement réservées dans chaque sous-réseau, notamment l’adresse réseau et l’adresse de broadcast, et certaines plateformes cloud réservent également des adresses supplémentaires. Le nombre réellement disponible pour les hôtes devient donc légèrement inférieur aux totaux ci-dessus une fois le bloc utilisé — le chiffre exact dépend de votre manière de le subnetter. Pour le dimensionnement, vous pouvez prévoir un nombre proche du total pour un bloc non subdivisé, tout en tenant compte des réservations par sous-réseau si vous comptez diviser le bloc en interne. Les mécanismes de subdivision sont détaillés dans le guide du subnetting et du CIDR.
Le seuil du /24 : pourquoi vous ne pouvez pas descendre plus bas publiquement
Le /24 est le plus petit bloc IPv4 que le système de routage mondial transporte de manière fiable, ce qui en fait le minimum pratique pour un espace d’adressage annoncé publiquement — quel que soit le faible nombre d’adresses dont vous avez réellement besoin.
La raison relève davantage d’une convention de routage que d’une loi technique absolue. Afin de maintenir la table de routage mondiale à une taille gérable, la plupart des réseaux filtrent les annonces de préfixes plus longs — donc plus petits — qu’un /24. Si vous annoncez un /25 ou un /26, une grande partie d’Internet n’acceptera tout simplement pas la route, et cet espace sera inaccessible depuis de nombreuses régions du monde. Comme nous l’expliquons dans notre guide sur le fonctionnement de BGP, un bloc d’adresses ne devient joignable que lorsqu’il est annoncé et accepté — et les annonces plus petites qu’un /24 sont largement rejetées.
Les conséquences pratiques pour le dimensionnement sont les suivantes :
-
- Un /24 est le point d’entrée pour un espace public routable indépendamment. Même si vous n’avez besoin que de 30 ou 60 adresses publiques mais souhaitez annoncer votre propre bloc, vous devez tout de même travailler avec un /24.
-
- Les besoins inférieurs à un /24 sont généralement satisfaits autrement. Si vous avez réellement besoin de seulement quelques adresses publiques et n’avez pas besoin d’annoncer votre propre bloc, des adresses attribuées par un fournisseur depuis un bloc plus large sont souvent plus adaptées que l’acquisition de votre propre /24.
-
- Louer un /24 et n’en utiliser qu’une partie est courant et logique. De nombreuses entreprises louent un /24 complet comme unité minimale, utilisent uniquement ce dont elles ont besoin immédiatement et conservent le reste comme marge de croissance disponible.
Combien d’adresses vos services utilisent-ils réellement ?
Un dimensionnement précis commence par le comptage des adresses publiques réellement nécessaires à chaque service — un nombre souvent inférieur aux attentes, car de nombreux services peuvent partager des adresses ou fonctionner derrière un petit nombre de points de terminaison publics. Voici des indications réalistes par catégorie :
-
- Hébergement web. L’hébergement web moderne utilise efficacement les adresses — de nombreux sites peuvent partager une seule IP publique grâce à l’hébergement virtuel basé sur les noms et aux reverse proxies. Des adresses publiques séparées sont surtout nécessaires lorsqu’un site ou service doit spécifiquement disposer de sa propre adresse, par exemple pour certaines configurations SSL, des exigences d’isolation ou une réputation propre au service. Une infrastructure hébergeant des centaines de sites peut donc nécessiter bien moins de centaines d’adresses.
-
- Serveurs de messagerie. La messagerie est particulièrement sensible aux adresses : chaque serveur d’envoi souhaite généralement disposer de sa propre adresse publique propre, avec un DNS inversé correctement configuré. Les grands expéditeurs peuvent également séparer différents flux, comme les e-mails transactionnels et marketing, entre plusieurs adresses afin de gérer leur réputation. Il faut donc compter soigneusement ici — les adresses utilisées pour la messagerie sont peu nombreuses, mais chacune est importante.
-
- Services VPN. Les fournisseurs de VPN peuvent être parmi les plus gros consommateurs d’adresses, avec des pools nécessaires pour les points de terminaison et, selon le modèle de service, pour les adresses depuis lesquelles les utilisateurs semblent se connecter. Le dimensionnement dépend ici directement de la conception du service et du nombre d’utilisateurs.
-
- Plateformes SaaS et multi-tenant. Elles sont généralement efficaces au niveau des adresses publiques — de nombreux tenants peuvent fonctionner derrière un nombre limité de points de terminaison publics et d’équilibreurs de charge, l’isolation étant gérée au niveau logiciel plutôt que par l’attribution d’une adresse à chaque tenant.
-
- Équilibreurs de charge et passerelles. Chaque point d’entrée public consomme une adresse, mais leur nombre est généralement faible — l’objectif même d’un équilibreur de charge est de placer de nombreux systèmes backend derrière une ou quelques adresses publiques.
-
- Serveurs DNS. Ils nécessitent peu d’adresses publiques, mais celles-ci sont importantes ; les opérateurs souhaitent souvent les placer sur un espace stable et bénéficiant d’une bonne réputation.
-
- Staging, développement et capacité de réserve. Les déploiements réels nécessitent également quelques adresses pour les environnements hors production et une marge opérationnelle — un volume modeste, mais qu’il vaut mieux compter plutôt que d’oublier.
La leçon récurrente est que la consommation d’adresses publiques est généralement déterminée par quelques services particulièrement gourmands en adresses, comme la messagerie, les points de terminaison VPN et les services isolés, plutôt que par le simple nombre de serveurs. Une infrastructure bien conçue peut placer de nombreux systèmes derrière relativement peu d’adresses publiques.
Prévoir la croissance sans surprovisionner
Dimensionnez votre espace pour une croissance raisonnable à court terme afin de ne pas devoir renuméroter ou acquérir davantage d’adresses tous les quelques mois — mais évitez de surprovisionner un espace que vous ne pouvez ni utiliser ni justifier, car les adresses inutilisées ont un coût et, dans certains contextes, peuvent nécessiter une justification d’utilisation.
Le problème comporte deux aspects :
Un dimensionnement trop faible signifie que vous manquerez d’espace et devrez ajouter un nouveau bloc ou renuméroter, ce qui peut être perturbant — renuméroter des services de production est précisément le type de modification coûteuse et sujette aux erreurs qu’une bonne planification d’infrastructure cherche à éviter. Un bloc sans marge vous y confrontera plus rapidement.
Un dimensionnement excessif présente également de véritables inconvénients. Vous payez pour des adresses que vous n’utilisez pas, que ce soit sous forme de frais de location ou de capital immobilisé dans un achat ; de grandes quantités d’espace inutilisé nécessitent toujours une gouvernance et une surveillance afin d’éviter de devenir une cible de détournement, comme expliqué dans notre guide sur le détournement BGP ; et dans les situations nécessitant une justification auprès d’un registre, conserver beaucoup plus d’espace que vous n’en utilisez peut être difficile à défendre. L’utilisation est donc un véritable facteur de décision, et pas simplement une ligne de coût.
Une approche équilibrée consiste à dimensionner votre espace selon vos besoins actuels, auxquels vous ajoutez la croissance que vous pouvez concrètement prévoir sur votre horizon de planification, généralement les 12 à 24 prochains mois, puis à arrondir à la taille de bloc routable supérieure. Cela signifie généralement choisir un bloc dans lequel l’utilisation actuelle occupe confortablement la partie basse, tout en laissant la partie supérieure disponible pour la croissance — sans passer directement deux tailles au-dessus « au cas où ».
Un cadre simple de dimensionnement
Transformez les besoins de vos services en taille de bloc en cinq étapes :
-
- Inventoriez vos services exposés publiquement. Répertoriez tout ce qui nécessite une adresse publique : front-ends web, serveurs de messagerie, points de terminaison VPN, équilibreurs de charge, DNS et tout service nécessitant sa propre adresse.
-
- Comptez de manière réaliste les adresses nécessaires à chaque service. Appliquez les principes ci-dessus — partagez lorsque cela est approprié et attribuez des adresses dédiées lorsqu’un service en a réellement besoin, notamment pour la messagerie. Additionnez ensuite le total.
-
- Ajoutez une marge de croissance. Ajoutez les besoins en adresses que vous pouvez concrètement prévoir sur votre horizon de planification. Soyez réaliste — prévoyez une croissance probable, et non simplement souhaitée.
-
- Arrondissez à une taille de bloc routable. Prenez votre total actuel + croissance, puis arrondissez au bloc le plus proche dans le tableau : /24 jusqu’à environ ~256 adresses, /23 jusqu’à environ ~512, /22 jusqu’à environ ~1,024, et ainsi de suite.
-
- Appliquez le seuil du /24. Si le résultat est inférieur à un /24 et que vous souhaitez disposer d’un espace routable indépendamment, un /24 reste la taille appropriée. Si vous n’avez besoin que de quelques adresses et n’avez pas besoin d’annoncer votre propre bloc, envisagez plutôt un espace attribué par votre fournisseur.
Le résultat est une taille de bloc que vous pouvez justifier : suffisamment grande pour couvrir votre utilisation réelle et votre croissance prévisible, avec le plus petit bloc routable comme seuil minimum, sans excès d’espace difficile à défendre.
Exemples pratiques
Les exemples suivants sont uniquement illustratifs et ne représentent pas de véritables entreprises. Ils montrent comment appliquer le cadre en pratique.
Exemple 1 — Petite startup d’hébergement. Une nouvelle entreprise d’hébergement dessert environ 200 sites web, principalement en hébergement partagé basé sur les noms derrière deux reverse proxies, exploite deux serveurs de messagerie, une paire de serveurs DNS et quelques points de terminaison applicatifs équilibrés. Après mutualisation, le besoin réaliste en adresses publiques peut n’être que de 20 à 40 adresses, et non 200. Même avec une marge de croissance généreuse, cela tient facilement dans un /24 — qui constitue également le minimum routable, ce qui en fait le choix évident, avec la majorité du bloc encore disponible pour la croissance.
Exemple 2 — Fournisseur VPN en croissance. Un service VPN dont la base d’utilisateurs augmente a besoin de pools d’adresses de terminaison dans plusieurs régions et prévoit une croissance continue. Le besoin actuel est d’environ 400 adresses, avec une expansion clairement planifiée. Un /24 (256) est déjà insuffisant ; le choix logique est un /23 (512) aujourd’hui, ou éventuellement un /22 (1,024) si la croissance prévisible est suffisamment importante pour le justifier — évitant ainsi une renumérotation à court terme.
Exemple 3 — Plateforme SaaS multi-région. Une entreprise SaaS exploite une infrastructure multi-tenant efficace derrière des équilibreurs de charge dans plusieurs régions, avec des besoins modestes en messagerie et DNS. Malgré un grand nombre de clients, son empreinte d’adresses publiques reste faible — peut-être 60 à 100 adresses. Un /24 devrait probablement suffire, sauf si l’isolation régionale ou les projets d’expansion la conduisent vers un /23.
Le schéma est le même dans les trois cas : le nombre brut de clients ou de sites est un mauvais indicateur des besoins en adresses. Une conception efficace permet à la plupart des opérations de rester dans un /24 ou /23, tandis que les modèles réellement gourmands en adresses, comme les pools de points de terminaison VPN, nécessitent des blocs plus importants.
La taille du bloc influence-t-elle le choix entre achat et location ?
Oui — la taille dont vous avez besoin, le degré de certitude concernant ce besoin et votre trajectoire de croissance influencent tous le choix entre location et achat. Le dimensionnement et le mode d’acquisition sont des décisions liées :
-
- Les besoins incertains, plus petits ou en croissance favorisent la location. Si vous ne savez pas encore exactement combien d’adresses vous utiliserez, prévoyez de vous développer ou souhaitez commencer avec un /24 avant d’augmenter progressivement, la location permet d’adapter l’espace à vos besoins au fil du temps sans engagement initial important ni complexité liée à l’achat puis à la revente d’espace. Vous pouvez louer un /24 aujourd’hui et augmenter votre capacité lorsque votre utilisation le justifie.
-
- Des besoins importants, stables et à long terme peuvent justifier l’étude d’un achat. Une entreprise disposant d’un besoin bien compris, durable et important peut comparer l’économie d’un achat avec celle d’une location sur son horizon de planification.
-
- Le modèle « louer un /24 et n’en utiliser qu’une partie ». Comme /24 constitue le seuil routable, louer un /24 et n’en utiliser qu’une partie au départ est une méthode d’entrée courante et logique — vous obtenez immédiatement un espace routable avec une marge de croissance intégrée.
Pour la plupart des entreprises qui dimensionnent leur premier bloc ou agrandissent leur empreinte actuelle, la location d’adresses IP permet d’adapter l’espace aux besoins réels tout en conservant une marge de croissance, tandis que celles ayant des besoins importants et stables peuvent comparer l’économie d’un choix consistant à acheter des adresses IPv4 directement. Le cadre de dimensionnement ci-dessus alimente directement cette décision : une fois que vous savez combien d’espace vous devez utiliser et à quel point ce besoin est certain, le choix entre location et achat devient beaucoup plus clair.
Liste de contrôle pratique pour le dimensionnement
-
- Inventoriez tous les services qui nécessitent une adresse publique.
-
- Comptez de manière réaliste les adresses nécessaires par service — partagez lorsqu’il est approprié de le faire et utilisez des adresses dédiées lorsque c’est nécessaire, notamment pour la messagerie.
-
- Calculez votre besoin réel actuel.
-
- Ajoutez la croissance concrète et prévisible sur votre horizon de planification.
-
- Arrondissez à la taille de bloc routable la plus proche (/24, /23, /22, /21, /20).
-
- Appliquez le seuil du /24 — c’est le minimum pour un espace routable indépendamment.
-
- Pour les besoins inférieurs à un /24 sans annonce indépendante, envisagez plutôt un espace attribué par votre fournisseur.
-
- Tenez compte des adresses réservées par sous-réseau si vous prévoyez de diviser le bloc en interne.
-
- Évitez le surprovisionnement — prenez en compte le coût et, lorsque cela s’applique, la justification de l’utilisation.
-
- Utilisez le besoin ainsi calculé pour orienter votre décision entre location et achat.
Note pratique de i.lease
Les erreurs de dimensionnement les plus courantes relèvent de deux pièges opposés. Le premier consiste à dimensionner instinctivement à partir du mauvais indicateur — compter les sites web, les clients ou les serveurs et supposer que chacun a besoin de sa propre adresse publique, ce qui surestime fortement les besoins de la plupart des infrastructures efficaces en matière d’adressage. Le second consiste à sous-dimensionner pour réduire les coûts, puis à manquer d’espace quelques mois plus tard, forçant une renumérotation ou une recherche urgente d’adresses supplémentaires au pire moment. Ces deux erreurs proviennent de l’omission d’une étape simple : compter réellement ce que vos services consomment et ajouter une marge honnête.
Lorsqu’il est correctement effectué, le dimensionnement n’est pas compliqué, et bien le faire présente des avantages dans les deux sens : vous évitez de payer pour un espace que vous ne pouvez pas utiliser et vous évitez les perturbations liées au dépassement de la capacité de votre bloc. Cela clarifie également le mode d’acquisition — une entreprise qui sait qu’elle a besoin d’un /24 aujourd’hui et prévoit d’atteindre un /23 dans deux ans se trouve dans une situation très différente d’une entreprise ayant besoin d’un /20 stable indéfiniment, et ces deux scénarios orientent vers des choix différents entre location et achat. Le principal enseignement pratique est de dimensionner à partir de la consommation réelle des services plutôt que du nombre de clients, de respecter le seuil routable du /24, de laisser une marge de croissance raisonnable et de laisser ce chiffre guider la manière dont vous obtenez l’espace. Cela transforme la question « de combien ai-je besoin ? » d’une simple estimation en une décision que vous pouvez défendre.
Conclusion
Le dimensionnement IPv4 repose finalement sur trois éléments : le seuil du /24 qui fixe votre minimum pratique, la consommation réelle d’adresses de vos services et une marge suffisante pour croître sans surprovisionnement. Les tailles de blocs évoluent par puissances de deux — un /24 contient 256 adresses, un /23 en contient 512, un /22 en contient 1,024, et ainsi de suite — et la bonne taille est celle qui peut accueillir confortablement votre utilisation actuelle et votre croissance prévisible, arrondie à la taille supérieure avec /24 comme minimum. La discipline essentielle consiste à compter les besoins réels des services plutôt que les nombres de sites ou de clients, car une infrastructure bien conçue permet à de nombreux systèmes de fonctionner derrière relativement peu d’adresses publiques.
Ce besoin calculé ne vous indique pas seulement quel bloc demander — il rend également toutes les décisions suivantes plus précises, notamment le choix entre location et achat. Les besoins incertains, plus petits ou en croissance favorisent la flexibilité de la location, souvent en commençant par un /24 puis en augmentant à mesure que l’utilisation le justifie ; des besoins importants, stables et à long terme justifient davantage l’étude d’un achat. Dans tous les cas, le travail commence de la même manière : inventoriez vos services, comptez honnêtement, ajoutez une croissance raisonnable, arrondissez vers le haut et appliquez le seuil du /24. En procédant ainsi, vous disposerez exactement de l’espace dont votre infrastructure a besoin — sans renumérotation forcée due à un manque de capacité, ni excédent inutilisé — tout en ayant une réponse claire et défendable à la question initiale.
À lire également
Pourquoi choisir i.Lease pour la location d'adresses IPv4 ?
i.Lease aide les entreprises à acheter, vendre et louer des adresses IPv4 en privilégiant la continuité d'activité. Au lieu de considérer l'IPv4 comme une simple location mensuelle, i.Lease met l'accent sur la transparence de la source, la prise en charge du routage, la responsabilité du renouvellement, la réputation IP irréprochable et la fiabilité opérationnelle.
Louez un bloc IPv4 maintenantFoire aux questions
Un bloc /24 (256 adresses) est le plus petit bloc accepté de manière fiable par le système de routage mondial. La plupart des réseaux filtrent les annonces pour les préfixes inférieurs à /24 ; un bloc /25 ou inférieur serait donc inaccessible depuis une grande partie d’Internet. Cela fait de /24 le minimum pratique pour un espace public routable indépendamment.
Un bloc /24 contient 256 adresses au total. Lorsqu’il est subdivisé en sous-réseaux, un petit nombre d’adresses sont généralement réservées (une adresse réseau et une adresse de diffusion par sous-réseau), et certaines plateformes cloud réservent des adresses supplémentaires. Par conséquent, le nombre d’adresses utilisables par les hôtes est légèrement inférieur selon la manière dont le sous-réseau est créé.
Un bloc /22 contient 1 024 adresses, soit l’équivalent de quatre blocs /24. En notation CIDR, plus le nombre après la barre oblique est petit, plus le bloc est grand ; ainsi, un bloc /22 est plus grand qu’un bloc /23 (512) et bien plus grand qu’un bloc /24 (256). Il convient généralement aux entreprises d’hébergement, de VPN ou de SaaS de taille moyenne.
Cela varie considérablement selon le modèle de service et la base d’utilisateurs. Les fournisseurs de VPN peuvent être de gros consommateurs d’adresses, nécessitant des pools pour les points de terminaison et, selon la conception, pour les adresses d’origine apparente des utilisateurs ; ainsi, la taille du pool est proportionnelle au nombre de régions, de points de terminaison et d’utilisateurs, tendant souvent vers un /23, un /22 ou plus.
Si vous souhaitez disposer de votre propre bloc routable indépendamment, oui : /24 est le minimum routable, même pour 50 adresses. Si vous n’avez besoin que de quelques adresses publiques et que vous n’avez pas besoin d’annoncer votre propre bloc, les adresses attribuées par votre fournisseur au sein de son allocation plus large sont souvent plus adaptées que l’acquisition de votre propre bloc /24.
Une approche raisonnable consiste à dimensionner les installations en fonction des besoins actuels, en tenant compte de la croissance concrètement prévisible sur votre horizon de planification (généralement 12 à 24 mois), puis à arrondir à la tranche supérieure. Visez une croissance réelle et prévisible plutôt qu’un surdimensionnement illusoire, car ce dernier engendre des coûts et, dans certains cas, nécessite des justifications.
Le prix dépend de plusieurs facteurs, notamment la taille du bloc, la région d’enregistrement, la demande du marché et le fait que vous louiez ou achetiez. Les blocs plus importants et certaines régions peuvent engendrer des coûts par adresse différents ; il est donc préférable de comparer les offres en fonction de la taille et de la source choisies plutôt que de se baser sur un tarif fixe.
Un /23 contient 512 adresses (deux /24) et un /22 contient 1 024 adresses (quatre /24) — un /22 est deux fois plus grand qu’un /23. Choisissez un /23 lorsque vos besoins actuels et futurs tiennent dans environ 512 adresses, et un /22 lorsqu’ils approchent ou dépassent ce nombre, jusqu’à environ 1 024.
NAS signifie Network Attached Storage, ou stockage en réseau. Il s’agit d’un dispositif de stockage dédié qui se connecte à Read more
Un botnet est un réseau d’ordinateurs ou d’appareils compromis exécutant un logiciel malveillant qui permet à un seul opérateur de Read more
Une Lettre d’Autorisation (LOA) est un document officiel dans lequel le titulaire enregistré d’un bloc d’adresses IP autorise une autre Read more
