NGFW : définition, fonctions et critères de choix en 2026

Un NGFW (Next-Generation Firewall, ou pare-feu nouvelle génération) est un pare-feu réseau qui autorise ou bloque un flux non plus seulement selon les adresses IP et les ports, mais selon l'application réellement utilisée, l'utilisateur authentifié et le contenu inspecté. Il réunit dans un même moteur le filtrage à états, la prévention d'intrusion (IPS), l'identification applicative et, selon les modèles, le déchiffrement TLS et le filtrage d'URL. Le concept a été formalisé par Gartner en octobre 2009. En 2026, presque tous les pare-feux d'entreprise revendiquent ce label, ce qui complique la comparaison : deux équipements « NGFW » peuvent offrir des niveaux de visibilité et de performance très différents. Ce guide détaille la définition, les fonctions réelles, les différences avec un pare-feu classique, un UTM ou un WAF, puis une méthode de sélection fondée sur des critères vérifiables. Pour les options open source, notre comparatif OPNsense vs pfSense 2026 complète utilement cette lecture.

NGFW : définition et origine du pare-feu nouvelle génération

La note de recherche « Defining the Next-Generation Firewall », publiée par John Pescatore et Greg Young chez Gartner en octobre 2009, part d'un constat simple : le filtrage par port et protocole des pare-feux de première génération ne suffit plus, parce qu'une part croissante des usages transite par HTTP et HTTPS. Un pare-feu qui autorise le port 443 autorise de fait une multitude d'applications différentes, légitimes ou malveillantes, sans pouvoir les distinguer.

Gartner fixait un socle minimal : fonctionnement en ligne, y compris en mode transparent (bump-in-the-wire), conservation des fonctions classiques (filtrage de paquets, traduction d'adresses NAT, inspection à états, VPN), IPS intégré plutôt que simplement juxtaposé, reconnaissance des applications indépendamment du port, et exploitation d'informations extérieures au pare-feu, comme l'annuaire ou des listes de réputation. Ce cahier des charges reste la meilleure grille pour juger un produit.

Le cadre général du filtrage, lui, est décrit par le guide NIST SP 800-41 Rev. 1 sur les pare-feux et leur politique, qui définit un pare-feu comme un dispositif contrôlant les flux entre réseaux ou hôtes de niveaux de sécurité différents. Quand on cherche une « NGFW definition » opérationnelle, trois questions suffisent : l'équipement sait-il quelle application circule, pour quel utilisateur, et avec quel contenu ?

Les fonctions clés d'un firewall NGFW

Un firewall NGFW empile plusieurs moteurs d'analyse autour d'une table d'états classique. Chaque éditeur leur donne un nom commercial différent, mais les briques sont comparables d'un produit à l'autre. Les connaître permet de lire une fiche technique sans confondre une fonction réellement intégrée au moteur avec une option vendue sous licence séparée ou déportée dans le cloud de l'éditeur.

Identification et contrôle des applications

Le moteur de contrôle applicatif classe chaque session à partir de signatures, de décodeurs de protocoles et d'heuristiques comportementales, quel que soit le port utilisé. La politique peut alors autoriser une messagerie collaborative tout en bloquant son transfert de fichiers, ou interdire les outils d'anonymisation. Cette granularité est le premier bénéfice d'un NGFW, à condition que la base applicative soit mise à jour fréquemment par l'éditeur.

Identification des utilisateurs

Le pare-feu associe une adresse IP à une identité grâce à l'annuaire (Active Directory, Entra ID, LDAP), à RADIUS, à un portail captif ou à un agent. Les règles s'écrivent ensuite par groupe métier plutôt que par sous-réseau. Cette fonction réduit la dépendance au plan d'adressage, mais elle ajoute une dépendance forte à l'annuaire, qui devient un composant critique de la chaîne de filtrage.

Prévention d'intrusion intégrée

L'IPS (Intrusion Prevention System) inspecte le contenu des sessions autorisées pour y repérer des exploitations de vulnérabilités, des communications de logiciels malveillants ou des anomalies protocolaires. Intégré au NGFW, il partage le contexte applicatif et utilisateur, ce qui limite les faux positifs. Il permet aussi un « patch virtuel » temporaire d'un serveur vulnérable en attendant le correctif définitif.

Inspection TLS, filtrage URL et renseignement sur les menaces

La plupart des modèles ajoutent le déchiffrement TLS, le filtrage par catégories d'URL, la réputation d'adresses et de domaines, le filtrage DNS et parfois l'analyse de fichiers en bac à sable. Ces services sont généralement facturés sous forme d'abonnements annuels. Leur efficacité dépend de la fraîcheur des flux de renseignement, ce qui crée une dépendance durable envers l'éditeur et pèse sur le coût total.

Comment un pare-feu nouvelle génération traite un flux

Comprendre l'ordre de traitement aide à écrire des règles efficaces et à interpréter les journaux. La séquence ci-dessous est générique : l'ordre exact varie selon les éditeurs, mais la logique reste la même. Un point mérite attention : l'application n'est pas connue au premier paquet, car le moteur a besoin de quelques échanges pour la reconnaître avec certitude.

1. Réception du paquet, contrôles anti-usurpation et normalisation (fragments, options IP).
2. Recherche d'une session existante dans la table d'états ; si elle existe, le contexte déjà calculé est réutilisé.
3. Évaluation d'une première politique sur les zones, adresses et ports, puis traduction d'adresses (NAT).
4. Identification de l'application et de l'utilisateur ; la règle applicable peut changer à ce moment.
5. Décision de déchiffrement TLS selon la catégorie de destination et les exclusions prévues.
6. Inspection de contenu : signatures de prévention d'intrusion (IPS), antivirus réseau, filtrage d'URL et de fichiers.
7. Action finale (autoriser, bloquer, limiter, réinitialiser) et journalisation enrichie.

Les architectures dites « à passe unique » (single-pass) analysent le flux une seule fois et partagent le résultat entre moteurs, alors que d'autres chaînent des modules successifs. Cette différence de conception explique pourquoi le débit annoncé « pare-feu seul » peut chuter fortement une fois toutes les protections activées. Seul un test dans des conditions réalistes permet de mesurer l'écart.

NGFW, pare-feu stateful, UTM et WAF : quelles différences ?

Les termes sont souvent mélangés dans les appels d'offres, qui parlent indifféremment de « NGFW firewall », d'UTM ou de pare-feu applicatif. Pourtant, ces familles ne répondent pas au même besoin. Le tableau suivant compare quatre familles sur les critères qui comptent pour une décision d'architecture, en restant volontairement générique, car les gammes commerciales se recouvrent de plus en plus.

La distinction entre NGFW et UTM (Unified Threat Management) tient surtout à l'histoire : l'UTM agrège des fonctions destinées aux petites structures, tandis que le NGFW place l'identification applicative au cœur du moteur. Gartner précisait dès 2009 qu'un NGFW n'est ni un UTM, ni une passerelle web, ni une passerelle de messagerie. Le WAF (Web Application Firewall) reste complémentaire : il protège une application web publiée, pas les postes de travail.

Inspection TLS : gagner en visibilité sans créer de nouveaux risques

Sans déchiffrement TLS (Transport Layer Security), un NGFW ne voit que des métadonnées : adresses, nom de serveur annoncé (SNI), empreintes de la négociation TLS et réputation des destinations. TLS 1.3 chiffre déjà le certificat du serveur. Depuis mars 2026, la RFC 9849 sur Encrypted Client Hello (ECH) normalise aussi le chiffrement du message d'ouverture, y compris le SNI et la liste ALPN. Un filtrage d'URL fondé uniquement sur le SNI perd donc progressivement en fiabilité.

Le déchiffrement fonctionne comme un mandataire : le NGFW termine la session du client avec un certificat émis par une autorité interne, puis ouvre une seconde session vers le serveur. Dans sa fiche de 2019 sur l'inspection TLS, la NSA recommande de déchiffrer une seule fois, de protéger strictement l'autorité de certification embarquée, d'éviter toute dégradation des versions et suites cryptographiques et de séparer les rôles d'administration et d'audit.

Le cadre juridique compte autant que la technique. La CNIL a publié ses bonnes pratiques sur l'analyse des flux HTTPS : information précise des salariés, liste blanche de sites non analysés, minimisation des traces conservées et protection des alertes, avec une durée de conservation de six mois au maximum. Exclure les catégories sensibles, comme la santé ou la banque, relève du même esprit de proportionnalité.

Le protocole QUIC, qui porte HTTP/3 sur UDP, constitue l'autre angle mort. De nombreux équipements ne savent pas l'inspecter finement ; une pratique répandue consiste à bloquer QUIC en sortie pour forcer le repli des navigateurs vers TCP et TLS, que le NGFW sait traiter. Cette mesure doit être testée sur les applications métier avant d'être généralisée.

Le NGFW, lui-même cible prioritaire des attaquants

Un pare-feu exposé sur Internet publie souvent un portail de réseau privé virtuel (VPN), une interface d'administration ou des services d'authentification. Ces surfaces sont devenues un vecteur d'accès initial privilégié, comme le détaille notre analyse sur les équipements réseau de périmètre devenus la cible n°1 des APT, ces groupes d'attaquants persistants souvent liés à des États. Un NGFW mal maintenu peut ainsi devenir la porte d'entrée qu'il était censé fermer.

Ces chiffres rappellent qu'un NGFW est d'abord un système informatique, avec son propre système d'exploitation, ses services web et ses vulnérabilités. Le scénario d'un pare-feu compromis puis utilisé pour déployer un rançongiciel n'a rien de théorique, comme le montre notre retour sur les appliances réseau utilisées comme accès initial ransomware. Le durcissement doit être traité avec la même rigueur que la politique de filtrage.

• Interface d'administration jamais exposée sur Internet, accessible uniquement depuis un réseau d'administration dédié.
• Authentification multifacteur pour les administrateurs et pour les utilisateurs du VPN, comptes nominatifs et revue des droits.
• Abonnement aux avis de sécurité de l'éditeur et du CERT-FR, avec un délai cible de correction exprimé en jours.
• Export des journaux système et de configuration vers un SIEM (corrélation des événements de sécurité) externe, afin de détecter une modification non autorisée.
• Désactivation des services non utilisés (portail SSL, API, SNMP en clair) et sauvegarde chiffrée de la configuration.

Bien choisir un NGFW en 2026 : les critères décisifs

Choisir un pare-feu nouvelle génération revient à arbitrer entre performance, profondeur d'inspection, facilité d'exploitation et contraintes réglementaires. Les classements d'analystes donnent une vue du marché, mais ils ne disent rien de l'adéquation à vos flux. Les critères ci-dessous sont mesurables ou vérifiables avant achat, ce qui permet de construire une grille d'évaluation défendable en comité.

Performance mesurée avec toutes les protections actives

La RFC 9411, publiée en mars 2023, définit une méthodologie de test des NGFW et des IPS de nouvelle génération (NGIPS) qui remplace l'ancienne RFC 3511. Elle mesure le débit avec un mélange de trafic applicatif, les connexions par seconde, la latence des transactions et le nombre de sessions simultanées, en HTTP et en HTTPS. Exigez des résultats obtenus avec IPS, contrôle applicatif et déchiffrement TLS activés, sur un profil proche du vôtre.

Qualité de détection et réactivité de l'éditeur

Interrogez la fréquence de mise à jour des signatures, la transparence de l'équipe de réponse aux vulnérabilités (PSIRT), l'historique des failles critiques et les délais de correction constatés. Un éditeur qui publie des avis détaillés et des indicateurs de compromission facilite votre travail de détection. Un éditeur opaque vous laisse découvrir seul les incidents, souvent trop tard.

Administration, automatisation et intégration au SOC

Une console centralisée, une API documentée et la prise en charge d'outils d'automatisation (Ansible, Terraform) réduisent les erreurs de configuration. Vérifiez aussi le format des journaux (syslog, CEF, JSON), leur richesse en contexte applicatif et utilisateur, et la facilité d'intégration avec le SIEM ou le SOC. Un NGFW dont les journaux restent inexploités n'apporte qu'une fraction de sa valeur.

Exigences françaises : qualification et diversité technologique

Le guide ANSSI-PA-044 sur le choix des pare-feux en zone exposée à Internet recommande des produits qualifiés, au niveau élémentaire, standard ou renforcé. Il préconise aussi au moins deux pare-feux en cascade et privilégie des technologies différentes, pour qu'une même vulnérabilité ou erreur de configuration ne compromette pas les deux barrières.

Coût total de possession

Le prix du matériel ne représente qu'une partie de la dépense. Il faut ajouter les abonnements de sécurité, le support, le renouvellement matériel, la haute disponibilité, la formation et le temps d'exploitation. Comparez les offres sur cinq ans, abonnements inclus, et vérifiez ce qui cesse de fonctionner à l'expiration d'une licence : certaines protections s'arrêtent net, d'autres ne reçoivent simplement plus de mises à jour.

Où placer un NGFW dans l'architecture réseau

Le positionnement historique reste la passerelle Internet, mais un NGFW apporte souvent davantage en segmentation interne : entre postes et serveurs, vers l'administration, vers les environnements industriels ou entre zones d'un datacenter. C'est là que l'identification applicative et utilisateur limite les mouvements latéraux, en interdisant par exemple les protocoles d'administration à distance hors des postes d'administration.

Le guide ANSSI-PA-044 introduit une nuance utile : pour une passerelle Internet, il recommande de dédier les pare-feux externe et interne au filtrage, et de placer les autres fonctions (détection d'intrusion, filtrage de contenu, relais applicatifs) dans la DMZ. Dans une architecture sensible, le NGFW tout-en-un prend donc plutôt place en pare-feu interne, en DMZ ou en segmentation, derrière un pare-feu externe d'une autre technologie.

Dans les environnements virtualisés et cloud, le NGFW prend la forme d'une appliance virtuelle ou d'un service managé. Les plateformes de virtualisation offrent aussi leurs propres pare-feux distribués, comme le montre notre guide sur le SDN de Proxmox VE 9 et ses zones, VNets et pare-feux. L'ANSSI déconseille toutefois de virtualiser les pare-feux d'une passerelle Internet, a fortiori lorsqu'elle protège un SI sensible.

NGFW open source : ce qu'OPNsense permet réellement

La documentation d'OPNsense le reconnaît : les pare-feux open source fonctionnent nativement en couche 4, sur les adresses et les ports. Pour se rapprocher d'un NGFW, on combine deux briques. Suricata, intégré en mode IPS en ligne, apporte la détection par signatures, comme l'explique notre fiche sur Suricata, IDS/IPS open source multi-thread. Le greffon tiers Zenarmor ajoute le contrôle applicatif, le filtrage web et l'intégration à l'annuaire.

Cette combinaison convient bien à une PME ou à un laboratoire, à condition d'accepter ses limites : l'édition gratuite de Zenarmor est restreinte en nombre de politiques et en fonctions avancées, et l'exploitation de Suricata demande du réglage. Le déploiement de base est décrit dans notre guide d'installation et de configuration d'OPNsense. L'exemple suivant illustre la logique « application plutôt que port » avec des règles Suricata de détection.

# Règles de laboratoire : identifier l'application, pas le port
alert ssh $HOME_NET any -> $EXTERNAL_NET !22 (msg:"LAB - SSH sortant sur port non standard"; flow:established,to_server; classtype:policy-violation; sid:9000001; rev:1;)
alert tls $HOME_NET any -> $EXTERNAL_NET !443 (msg:"LAB - TLS sortant hors 443"; flow:established,to_server; classtype:policy-violation; sid:9000002; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET 443 (msg:"LAB - Port 443 sans TLS"; flow:established,to_server; app-layer-protocol:!tls; classtype:policy-violation; sid:9000003; rev:1;)

La première règle signale un flux SSH sortant vers un autre port que 22, la deuxième un flux TLS hors du port 443, la troisième un flux sur le port 443 dont le protocole détecté n'est pas TLS. Ces règles déclenchent des alertes, pas des blocages : en production, on commence toujours en détection pour mesurer les faux positifs. Les identifiants au-delà de 9000000 sont réservés ici à un usage local.

Déployer un NGFW sans casser la production

La migration d'un pare-feu classique vers un NGFW échoue rarement pour des raisons techniques ; elle échoue par excès d'ambition. Activer d'emblée le contrôle applicatif, l'IPS en blocage et le déchiffrement provoque des coupures, puis des exceptions larges qui annulent le bénéfice attendu. Une démarche progressive, en six étapes, limite ce risque et produit une politique documentée.

1. Observer : placer le NGFW en mode audit ou miroir pour inventorier les applications et utilisateurs réels pendant plusieurs semaines.
2. Reprendre l'existant : importer la politique actuelle, supprimer les règles inutilisées et documenter le propriétaire de chaque règle.
3. Convertir : remplacer règle par règle les autorisations par port par des autorisations par application et par groupe d'utilisateurs.
4. Activer l'IPS en détection, analyser les alertes, puis passer en prévention profil par profil, en commençant par les serveurs exposés.
5. Déchiffrer progressivement : d'abord une population pilote, avec les exclusions juridiques et techniques définies à l'avance.
6. Réviser : revue trimestrielle des règles, des exceptions et des journaux, avec un indicateur de règles sans trafic.

Retour terrain : Cas typique rencontré en mission — lors de la migration d'un pare-feu à états vers un NGFW, la phase d'observation révèle presque toujours des usages ignorés : outils de prise en main à distance installés par des prestataires, stockage cloud personnel, logiciels métier sur des ports non documentés. Le déchiffrement TLS bute ensuite sur les applications qui épinglent leur certificat et sur des équipements qui ne reconnaissent pas l'autorité de certification interne. La parade : des exclusions validées avec les métiers et le délégué à la protection des données, puis une extension par vagues.

Limites du NGFW et place dans une stratégie Zero Trust

Un NGFW ne voit que ce qui traverse le réseau qu'il contrôle. Il ignore ce qui se passe sur un poste, une session chiffrée qu'il ne déchiffre pas, ou un service cloud joint directement depuis un portable en télétravail. Les attaquants exploitent ces angles morts en dissimulant leurs communications dans des protocoles applicatifs courants, une technique référencée par MITRE ATT&CK sous l'identifiant T1071.

Il ne détecte pas non plus une bibliothèque compromise téléchargée depuis un dépôt légitime, scénario développé dans notre article sur la menace de la supply chain open source. Un NGFW est un point d'application de la politique, pas une stratégie de sécurité à lui seul : il doit être combiné à l'EDR (détection et réponse sur les terminaux), à la gestion des identités, à la journalisation centralisée et à la gestion des vulnérabilités.

Le marché évolue vers des offres hybrides : appliances, instances virtuelles et pare-feu en tant que service (FWaaS) pilotés depuis une même console. Gartner a d'ailleurs publié en août 2025 un premier Magic Quadrant consacré aux « hybrid mesh firewalls ». Dans une approche Zero Trust, le NGFW reste un point de contrôle utile pour segmenter et journaliser, mais la décision d'accès s'appuie aussi sur l'identité et l'état du terminal.

À lire aussi : les fondamentaux du pare-feu informatique ; le placement du NGFW en bordure de DMZ ; la fin de vie du Cisco ASA ; le deep packet inspection (DPI).

Questions fréquentes

Conclusion

Un NGFW apporte une visibilité que le filtrage par port ne peut plus offrir, à condition d'être choisi sur des mesures réalistes, déployé progressivement et maintenu comme un actif exposé. En 2026, le chiffrement de bout en bout et l'intérêt des attaquants pour les équipements de bordure imposent de penser déchiffrement, durcissement et journalisation dès la conception. Pour comparer les alternatives open source, consultez notre comparatif complet OPNsense vs pfSense.