Pare-feu informatique : définition, types et critères de choix

Un pare-feu informatique (en anglais firewall) est un dispositif matériel, logiciel ou cloud qui contrôle les communications entre des zones de confiance différentes et n'autorise que les flux explicitement prévus par une politique de filtrage. Il protège aussi bien un poste de travail isolé qu'un réseau d'entreprise multisite ou une infrastructure hébergée dans le cloud. Son efficacité dépend pourtant moins de la marque choisie que de la qualité des règles, du durcissement de l'équipement et de la supervision de ses journaux. En 2026, les équipements de bordure figurent parmi les cibles favorites des attaquants : bien choisir son type de pare-feu et l'administrer avec rigueur est donc une décision structurante. Les sections suivantes couvrent la définition, le fonctionnement, les grandes familles (filtrage de paquets, pare-feu à états, proxy applicatif, NGFW, WAF, pare-feu d'hôte, pare-feu cloud), leurs limites et une matrice de choix. Pour la mise en pratique sur une solution open source, consultez notre guide d'installation et de configuration d'OPNsense.

Pare-feu informatique : définition et rôle dans un système d'information

Le guide NIST SP 800-41 révision 1 décrit les pare-feux comme des équipements ou des programmes qui contrôlent le trafic entre des réseaux ou des hôtes n'ayant pas le même niveau de sécurité. Cette définition, publiée par l'institut américain de normalisation, reste la référence : un pare-feu n'est pas un produit précis, mais une fonction de contrôle placée à la frontière entre deux niveaux de confiance.

Le terme vient du bâtiment : un mur coupe-feu empêche un incendie de se propager d'une pièce à l'autre. Transposé au réseau, le pare-feu limite la propagation d'une attaque d'une zone vers une autre. Cette image rappelle un point essentiel : il ne rend pas une zone invulnérable, il contient les dégâts et ralentit la progression de l'adversaire.

Dans un système d'information, un pare-feu remplit trois missions complémentaires. Il filtre en n'autorisant que les échanges nécessaires au métier. Il cloisonne en séparant les populations de machines (utilisateurs, serveurs, administration, invités, systèmes industriels). Il trace enfin les flux acceptés et refusés, ce qui alimente la détection d'incidents et les enquêtes après une compromission.

Pare-feu, routeur et antivirus : trois rôles distincts

Un routeur achemine les paquets vers leur destination ; un pare-feu décide si ces paquets ont le droit de passer. Un antivirus ou un EDR (détection et réponse sur les terminaux) analyse les fichiers et les comportements sur une machine. Ces fonctions se recoupent parfois dans un même boîtier, mais elles répondent à des menaces différentes et ne se substituent pas les unes aux autres.

Comment fonctionne un pare-feu : règles, états et journalisation

Le fonctionnement d'un pare-feu repose sur une base de règles. Chaque règle associe des critères (adresse source, adresse de destination, protocole, port, interface, sens du flux) à une action : autoriser, rejeter avec un message d'erreur, ou ignorer silencieusement le paquet. La plupart des solutions évaluent les règles de haut en bas et appliquent la première qui correspond, d'où l'importance de leur ordre.

Le suivi d'état des connexions

Un pare-feu à états conserve en mémoire une table des connexions établies. Lorsqu'un poste interne ouvre une session vers un serveur web, la réponse de ce serveur est reconnue comme appartenant à une connexion légitime et acceptée sans règle supplémentaire. Ce suivi d'état réduit le nombre de règles et bloque les paquets qui prétendent appartenir à une session inexistante.

La traduction d'adresses et les fonctions annexes

Beaucoup de pare-feux assurent aussi la traduction d'adresses (NAT, Network Address Translation), qui permet à des machines en adressage privé de sortir sur Internet avec une adresse publique. Ils hébergent souvent un concentrateur VPN (réseau privé virtuel), un relais DNS ou un portail captif. Chaque fonction ajoutée élargit cependant la surface d'attaque de l'équipement et doit être justifiée.

La journalisation, mémoire du pare-feu

Sans journaux, un pare-feu bloque mais ne raconte rien. Les événements de connexion acceptée ou refusée, les changements de configuration et les authentifications d'administrateurs doivent être envoyés vers un serveur de collecte, idéalement un SIEM (système de gestion des informations et des événements de sécurité). Ces traces permettent de repérer un balayage de ports, une exfiltration ou une modification de règle suspecte.

Les grands types de pare-feu, du filtrage de paquets à l'inspection applicative

Le guide du NIST classe les pare-feux informatiques selon la couche réseau qu'ils savent interpréter. Plus un pare-feu inspecte haut dans la pile TCP/IP, plus il comprend finement le trafic, mais plus il consomme de ressources et plus son code est complexe. Les familles suivantes coexistent aujourd'hui dans la plupart des architectures.

Le filtrage de paquets sans état

Le filtrage sans état (stateless) examine chaque paquet isolément, à partir de ses en-têtes : adresses IP, protocole, ports. Il est rapide et peu coûteux, ce qui explique sa présence dans les listes de contrôle d'accès des routeurs et commutateurs. Il ne sait pas en revanche si un paquet appartient à une connexion légitime, ce qui impose des règles symétriques plus permissives.

Le pare-feu à états

Le pare-feu à états (stateful) mémorise les sessions ouvertes et accepte automatiquement les réponses qui leur correspondent. C'est le socle de la quasi-totalité des pare-feux d'entreprise, des solutions open source comme OPNsense ou pfSense et des pare-feux intégrés aux systèmes d'exploitation. Il offre un bon équilibre entre performance et sécurité, mais il ne voit pas le contenu applicatif des échanges autorisés.

La passerelle applicative ou proxy

Une passerelle applicative (proxy) termine la connexion du client et en ouvre une nouvelle vers le serveur. Elle peut ainsi vérifier la conformité du protocole, authentifier les utilisateurs et filtrer des contenus. Les proxys web sortants restent courants pour contrôler la navigation. Leur contrepartie est une latence accrue et un paramétrage par protocole.

Inspection avancée : pare-feu de nouvelle génération et pare-feu applicatif web

Au-delà du filtrage par adresses et par ports, deux familles analysent le contenu applicatif des échanges. Elles répondent à un constat simple : la majorité des usages passent aujourd'hui par quelques ports web, si bien qu'un pare-feu limité aux en-têtes ne distingue plus une application métier d'un service de partage de fichiers non autorisé.

Le pare-feu de nouvelle génération

Un pare-feu de nouvelle génération (NGFW, Next-Generation Firewall) combine le filtrage à états avec l'identification des applications, la prise en compte de l'identité des utilisateurs, la prévention d'intrusion et souvent l'inspection du trafic chiffré TLS. Il permet d'écrire des règles du type « le service comptable peut utiliser telle application ». Sa richesse fonctionnelle exige en contrepartie davantage de compétences d'administration.

Le pare-feu applicatif web

Le pare-feu applicatif web (WAF, Web Application Firewall) se place devant un site ou une API et analyse les requêtes HTTP pour bloquer les injections, les scripts intersites et d'autres attaques décrites par le projet OWASP Top 10. Il protège une application précise et ne remplace pas le pare-feu réseau, qui reste nécessaire pour tous les autres protocoles.

Pare-feu réseau ou pare-feu d'hôte : où placer le filtrage ?

Le guide NIST rappelle que la plupart des pare-feux étaient autrefois installés en périphérie du réseau, et que cette position ne voit souvent pas les attaques circulant d'une machine interne à une autre. Les architectures actuelles multiplient donc les points de filtrage : en bordure, entre les zones internes et sur chaque hôte.

Le pare-feu réseau, en bordure et à l'intérieur

Le pare-feu réseau protège un ensemble de machines. En bordure, il sépare Internet du réseau interne et d'une éventuelle zone démilitarisée (DMZ) hébergeant les services exposés. À l'intérieur, il cloisonne les postes, les serveurs, l'administration ou les systèmes industriels. Cette segmentation interne limite les déplacements latéraux d'un attaquant qui aurait compromis un premier poste.

Le pare-feu d'hôte sur les postes et les serveurs

D'après la documentation Microsoft du Pare-feu Windows, ce pare-feu d'hôte est inclus et activé par défaut dans toutes les éditions de Windows. Par défaut, il bloque le trafic entrant non sollicité qui ne correspond à aucune règle et laisse passer le trafic sortant. Il applique trois profils, domaine, privé et public, ce dernier étant attribué aux réseaux non identifiés.

Microsoft déconseille de désactiver ce pare-feu, même lorsqu'un produit tiers est installé, et recommande, si une désactivation s'impose, d'agir sur les profils plutôt que d'arrêter le service. En entreprise, la configuration se pilote de façon centralisée, par exemple en suivant notre méthode pour configurer le pare-feu Windows Defender avec Intune. Sous Linux, nftables succède à iptables ; macOS propose un pare-feu applicatif à vérifier dans ses réglages.

Pare-feu cloud, boîtier ou machine virtuelle : choisir le mode de déploiement

Une même fonction de pare-feu peut être livrée sous plusieurs formes : équipement physique, logiciel, appliance virtuelle ou service hébergé par un fournisseur. Ce mode de déploiement influe sur les performances, sur la répartition des responsabilités et sur la capacité à protéger des utilisateurs qui ne passent plus par le réseau de l'entreprise.

Le pare-feu cloud et le FWaaS

Dans le cloud public, des groupes de sécurité et des pare-feux natifs filtrent les flux entre machines virtuelles. Pour les utilisateurs nomades et les sites distants, le pare-feu en tant que service (FWaaS, Firewall as a Service) applique la politique depuis le réseau du fournisseur. Il s'intègre souvent dans une offre SASE ou SSE, qui associe accès réseau, filtrage web et contrôle d'accès fondé sur l'identité.

Boîtier matériel, logiciel ou machine virtuelle ?

Un boîtier matériel offre des performances prévisibles et des accélérateurs dédiés. Une appliance virtuelle s'intègre aux hyperviseurs et au cloud, au prix d'une dépendance aux ressources de l'hôte. Une distribution logicielle installée sur un serveur standard réduit les coûts de licence, mais transfère à l'équipe interne la responsabilité du matériel, des mises à jour et du support.

Les limites d'un pare-feu : ce qu'il ne bloque pas

Un pare-feu applique des règles ; il ne juge pas l'intention de l'utilisateur. Tout ce qui emprunte un flux autorisé passe, y compris une attaque. Connaître ces angles morts permet de dimensionner les autres couches de la défense en profondeur plutôt que de surestimer la protection offerte par le seul filtrage réseau.

• Les flux légitimes détournés : un courriel d'hameçonnage ou un téléchargement piégé arrive par des ports ouverts pour le métier.
• Les identifiants volés : un attaquant connecté au VPN avec un compte valide est traité comme un utilisateur autorisé.
• Le trafic chiffré : sans inspection TLS, le contenu des sessions HTTPS reste opaque, et cette inspection pose des questions de confidentialité.
• Les menaces internes : deux machines d'un même segment communiquent sans traverser le pare-feu réseau.
• Les erreurs de configuration : une règle trop large ou oubliée annule le bénéfice de toutes les autres.
• Les vulnérabilités du pare-feu lui-même : un équipement non corrigé peut devenir le point d'entrée de l'attaque.

Ces limites expliquent pourquoi le pare-feu doit être associé à la gestion des identités avec authentification multifacteur, à la protection des terminaux, au filtrage de la messagerie et à la sauvegarde. Dans une stratégie de sécurité informatique, pare-feu, contrôle des identités et sauvegarde forment un tout : le filtrage reste un rempart indispensable, à condition de ne pas le considérer comme l'unique ligne de défense.

Pourquoi les pare-feux sont devenus une cible prioritaire en 2026

Un pare-feu exposé à Internet est par nature joignable par n'importe qui. S'il présente une faille, l'attaquant obtient un point d'appui privilégié au cœur du réseau, sur un équipement rarement surveillé avec la même attention qu'un serveur. Les rapports publiés depuis 2025 confirment que cette catégorie de produits attire de plus en plus les groupes offensifs.

Le même rapport souligne que les outils EDR (détection et réponse sur les terminaux) ne sont généralement pas conçus pour fonctionner sur ces équipements, ce qui réduit les capacités de surveillance. Une seule vulnérabilité peut en outre suffire à obtenir une exécution de code à distance, sans chaîne d'exploits complexe. Nos analyses des appliances réseau devenues la cible n°1 des attaquants détaillent ces campagnes.

Le 5 février 2026, l'agence américaine CISA a publié la directive opérationnelle BOD 26-02 consacrée aux équipements de bordure en fin de support, catégorie qui inclut explicitement les pare-feux. Les agences fédérales civiles doivent inventorier ces équipements sous trois mois, retirer sous douze mois ceux de la liste CISA arrivés en fin de support, puis tous les équipements de bordure en fin de support sous dix-huit mois.

Cette directive ne s'applique pas aux organisations françaises, mais elle fournit un repère utile : un pare-feu qui ne reçoit plus de correctifs de sécurité doit être traité comme un risque majeur, et non comme une économie. Notre dossier sur les VPN, pare-feux et ADC ciblés par les groupes APT illustre les conséquences de ce retard.

Construire une politique de filtrage lisible et durable

L'ANSSI publie une note technique consacrée à la définition d'une politique de filtrage réseau d'un pare-feu, indépendante de la technologie employée. L'agence y défend un modèle de sécurité positif : tout ce qui n'est pas explicitement autorisé est interdit. Elle propose d'organiser la base de règles en six sections rigoureusement ordonnées.

1. Flux à destination du pare-feu : administration et supervision, depuis des sources précises et peu nombreuses.
2. Flux émis par le pare-feu : envoi des journaux, alertes, sauvegardes de configuration.
3. Règle de protection du pare-feu : tout autre flux vers ses interfaces est ignoré et journalisé.
4. Flux métiers : le cœur de la politique, regroupé par entité ou par service.
5. Règles « antiparasites » : facultatives, pour ne pas journaliser certains bruits connus.
6. Règle d'interdiction finale : tout le reste est refusé et tracé.

La note recommande d'ignorer silencieusement les paquets interdits plutôt que de les rejeter, afin de ne pas renseigner un attaquant sur la présence de l'équipement. Elle préconise aussi de désactiver les flux implicites que certaines solutions ouvrent automatiquement, de vérifier le comportement du pare-feu pendant son démarrage et de tester la politique après chaque mise en œuvre.

Section 1 - Flux vers le pare-feu
  ADM-01  src=GRP_POSTES_ADMIN   dst=FW_IF_ADMIN    svc=ssh,https       action=autoriser  log=oui
  SUP-01  src=SRV_SUPERVISION    dst=FW_IF_ADMIN    svc=snmp            action=autoriser  log=oui
Section 2 - Flux émis par le pare-feu
  LOG-01  src=FW_IF_ADMIN        dst=SRV_SYSLOG     svc=syslog-tls      action=autoriser  log=oui
Section 3 - Protection du pare-feu
  PRT-01  src=toutes             dst=FW_INTERFACES  svc=tous            action=ignorer    log=oui
Section 4 - Flux metiers
  WEB-01  src=LAN_UTILISATEURS   dst=PROXY_WEB      svc=tcp_3128        action=autoriser  log=oui  ticket=CHG-0142
  ERP-01  src=LAN_COMPTABILITE   dst=SRV_ERP        svc=https           action=autoriser  log=oui  ticket=CHG-0097
Section 5 - Antiparasites (facultatif)
  BRD-01  src=LAN_TEST           dst=255.255.255.255 svc=udp_137,udp_138 action=ignorer   log=non
Section 6 - Interdiction finale
  FIN-01  src=toutes             dst=toutes         svc=tous            action=ignorer    log=oui

Cet exemple, neutre vis-à-vis des éditeurs, applique aussi les conventions de forme recommandées : objets nommés selon une règle unique, règles identifiées par un code, référence du ticket de changement en commentaire. Ces détails paraissent secondaires, mais ce sont eux qui permettent à un nouvel administrateur ou à un auditeur de comprendre la politique sans dépendre de la mémoire de son auteur.

L'ANSSI recommande enfin de passer la politique de filtrage en revue au moins une fois par an, idéalement deux fois. Cette revue vérifie l'origine et l'utilité des règles ajoutées, corrige les écarts aux conventions et supprime les règles obsolètes. Une politique courte et comprise vaut mieux qu'une politique exhaustive que plus personne n'ose modifier.

Comment choisir un pare-feu informatique : critères et matrice de décision

Choisir un pare-feu commence par une question simple : quels flux doivent être autorisés, entre quelles zones et pour quels utilisateurs ? Sans cette cartographie, la comparaison des fiches techniques reste théorique. Une fois les besoins connus, les critères suivants permettent de départager des solutions qui affichent souvent des promesses proches.

• Débit réel : comparez le débit annoncé avec les fonctions que vous activerez réellement (prévention d'intrusion, inspection TLS), car les fiches distinguent généralement plusieurs valeurs.
• Sessions et VPN : nombre de connexions simultanées, d'utilisateurs nomades et de tunnels inter-sites à supporter.
• Haute disponibilité : fonctionnement en grappe actif-passif pour éviter qu'une panne coupe l'activité.
• Administration : console centralisée, gestion des objets, historique des modifications, API d'automatisation.
• Journalisation : export standard vers un SIEM, conservation locale, horodatage fiable.
• Cycle de vie : dates de fin de commercialisation et de fin de support publiées, rythme des correctifs, transparence des avis de sécurité de l'éditeur.
• Confiance : pour les entités sensibles, existence d'une qualification ou d'une certification par l'ANSSI.
• Coût complet : matériel, abonnements aux services de sécurité, support, formation et temps d'administration.

Pour une PME qui privilégie l'open source, les deux distributions les plus répandues, fondées sur FreeBSD, sont comparées point par point dans notre article OPNsense vs pfSense : comparatif complet. Les solutions commerciales apportent en général un support contractuel, des abonnements de renseignement sur les menaces et parfois une qualification officielle, au prix de licences récurrentes.

Retour terrain : Cas typique rencontré en mission — je vois régulièrement des PME comparer des pare-feux sur le seul débit affiché en fiche technique. Une fois l'inspection applicative et l'antivirus activés, le modèle choisi sature aux heures de pointe. Les critères décisifs sont ailleurs : débit mesuré fonctions de sécurité actives, réactivité du support local et coût des abonnements sur toute la durée de vie, à comparer avant la signature.

Durcir et superviser son pare-feu au quotidien

Un pare-feu mal administré peut devenir la faiblesse qu'il était censé couvrir. La page de la CISA (agence américaine de cybersécurité) consacrée à la sécurité des équipements de bordure rassemble les mesures de durcissement prioritaires, applicables à tout pare-feu quelle que soit sa marque.

Réduire l'exposition de l'équipement

La première mesure consiste à retirer toute interface d'administration exposée sur Internet et à réserver l'administration à un réseau dédié. Il faut ensuite changer immédiatement les identifiants par défaut, désactiver les services inutiles et imposer une authentification multifacteur résistante à l'hameçonnage pour chaque administrateur. Les comptes doivent être nominatifs afin que chaque action soit attribuable.

Corriger, inventorier et anticiper la fin de support

Les correctifs de l'éditeur doivent être appliqués rapidement, en priorité ceux qui concernent des vulnérabilités déjà exploitées. L'inventaire des pare-feux doit indiquer leur version logicielle et leur date de fin de support, afin de planifier le renouvellement avant qu'ils ne deviennent impossibles à corriger. Une sauvegarde régulière de la configuration permet de restaurer rapidement un équipement compromis ou défaillant.

Surveiller les changements suspects

La CISA recommande de centraliser les journaux dans un SIEM et de comparer régulièrement la configuration à une référence connue. Doivent alerter : un tunnel inconnu, une capture de paquets activée, une route statique ajoutée, un compte ou une méthode d'authentification non prévus, des journaux effacés. Un transfert massif de données depuis le pare-feu vers Internet mérite également une investigation immédiate.

Lorsque l'administration est confiée à un prestataire, ses accès doivent respecter les mêmes règles : comptes nominatifs, authentification forte, traçabilité. Notre guide de sécurisation des outils RMM des infogérants rappelle pourquoi ces accès distants, souvent autorisés à travers le pare-feu, sont eux aussi une cible privilégiée.

Tester et auditer un pare-feu sans prendre de risque

Une politique de filtrage n'est fiable que si son comportement réel a été vérifié. L'ANSSI demande de tester chaque politique une fois implémentée. Ce contrôle consiste à confirmer, depuis chaque zone, que seuls les flux prévus sont accessibles et que les tentatives refusées apparaissent bien dans les journaux.

Côté postes et serveurs, la vérification commence par l'état du pare-feu d'hôte. Sous Windows, quelques commandes PowerShell en lecture seule suffisent à contrôler que les trois profils sont actifs, que le trafic entrant est bloqué par défaut et à lister les règles entrantes autorisées. Sous Linux, la commande de listing de nftables affiche l'ensemble des règles chargées.

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction, LogBlocked

Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow |
  Select-Object DisplayName, Profile |
  Sort-Object DisplayName

sudo nft list ruleset

Un audit complet compare ensuite la politique appliquée à la matrice des flux validée par le métier, examine les règles jamais utilisées, contrôle les comptes d'administration et la version logicielle. Notre guide de l'audit de sécurité informatique en PME décrit comment intégrer cette revue du pare-feu dans une démarche plus large.

Retour terrain : Cas typique rencontré en mission — la revue d'un pare-feu de PME fait ressortir les mêmes écarts : une règle « any-any » ajoutée pour un dépannage et jamais retirée, une administration joignable depuis Internet, aucune règle finale de refus journalisée, ce qui rend les tentatives bloquées invisibles. La correction : règle supprimée après identification des flux réels, administration limitée au réseau dédié, refus final journalisé, expiration imposée à toute règle temporaire.

Particuliers, TPE et PME : les priorités selon votre taille

Pour un particulier, le pare-feu intégré à la box internet et celui du système d'exploitation constituent une base suffisante, à condition de rester actifs et à jour. Il convient d'éviter les redirections de ports inutiles et de désactiver la fonction UPnP (ouverture automatique de ports par les applications) lorsqu'elle ne sert pas. Un logiciel tiers n'apporte pas toujours de bénéfice supplémentaire.

Une TPE gagne à remplacer le simple routeur de son opérateur par un pare-feu à états professionnel, avec un support et des mises à jour garantis, souvent confié à un prestataire. Les priorités sont un accès VPN avec authentification multifacteur pour les nomades, une administration non exposée sur Internet et des journaux conservés hors de l'équipement.

Une PME doit aller plus loin : segmentation interne entre postes, serveurs et administration, haute disponibilité, journaux centralisés et revue annuelle des règles. Pour les entités concernées par la directive européenne NIS 2, la sécurité des réseaux fait partie des mesures de gestion des risques attendues ; le pare-feu documenté et audité devient alors un élément de preuve de conformité.

À lire aussi : l'architecture d'une DMZ ; les pare-feu de nouvelle génération (NGFW) ; le pare-feu sous Linux (nftables).

Questions fréquentes

Conclusion

Le pare-feu informatique reste l'un des fondements de la sécurité d'un système d'information : il réduit la surface d'attaque, cloisonne les zones et trace les tentatives d'intrusion. Aucun type ne couvre seul tous les besoins ; la combinaison d'un pare-feu réseau, de pare-feux d'hôte et, si nécessaire, d'un WAF ou d'un service cloud forme une protection cohérente.

Sa valeur dépend toutefois de choix concrets : un type adapté au contexte, une politique de filtrage positive et documentée, un équipement durci, corrigé et remplacé avant sa fin de support. En 2026, alors que les équipements de bordure sont activement ciblés, un pare-feu non supervisé est un risque, pas une protection. Pour passer à la mise en œuvre, notre tutoriel complet OPNsense constitue un bon point de départ.