ICS/SCADA : Pentest d'Environnements Industriels en 2026

Le ICS SCADA pentest environnements industriels est l'une des disciplines les plus exigeantes de la cybersécurité offensive. La convergence IT/OT accélérée depuis 2020 — remote access COVID, cloud ICS, intégration ERP-SCADA — a exposé des systèmes conçus pour fonctionner en vase clos à des menaces réseau qu'ils n'ont jamais été pensés pour affronter. Les protocoles industriels comme Modbus ou DNP3 n'ont pas de mécanisme d'authentification natif. Les automates programmables (PLC) Siemens S7 ou Allen-Bradley tournent sur des firmwares vieux de dix ans. Les interfaces homme-machine (HMI) Windows XP sont encore courantes dans des usines de production actives. Face à des incidents comme Stuxnet (2010), TRITON (2017), et l'attaque de Colonial Pipeline (2021), la pression réglementaire s'intensifie : NERC CIP aux États-Unis, guide ANSSI en France, directive NIS2 en Europe. Les red teams spécialisées OT sont en forte demande, mais les professionnels compétents se comptent en centaines à l'échelle mondiale. Ce guide est un point de départ pour construire cette compétence rare.

Architecture ICS/OT : le modèle de Purdue revisité en 2026

Le modèle de Purdue (ISA-99, années 1990) reste la référence conceptuelle pour comprendre la hiérarchie des systèmes industriels, même si la réalité 2026 le déborde largement. Il définit cinq niveaux :

Niveau 0 — Le terrain physique : capteurs, actionneurs, moteurs, vannes. C'est le monde physique que les ICS contrôlent. Une anomalie ici se traduit directement par un événement physique.

Niveau 1 — Les automates (PLC/RTU) : ils lisent les capteurs (niveau 0) et actionnent les équipements selon une logique programmée. Siemens S7-300/400/1500, Allen-Bradley ControlLogix, Schneider Modicon — ce sont les cibles les plus critiques d'un test d'intrusion OT.

Niveau 2 — Le superviseur (SCADA/HMI) : les interfaces opérateur qui visualisent l'état du processus et permettent d'intervenir. WinCC (Siemens), iFIX (GE), Wonderware (AVEVA) sont les solutions dominantes. Ces postes tournent souvent sous Windows 7 ou Windows Server 2008 — non patchés, souvent sans antivirus "pour ne pas perturber le process".

Niveau 3 — Gestion de production : MES (Manufacturing Execution System), historiens de données. C'est la zone d'interface entre l'OT et l'IT.

Niveau 4/5 — Réseau d'entreprise IT classique : ERP, Active Directory, email. La convergence IT/OT s'opère typiquement via une DMZ entre les niveaux 3 et 4 — quand elle existe.

En pratique 2026, cette segmentation est souvent théorique. L'accès VPN COVID a percé des tunnels directs vers les niveaux 1 et 2. Les mises à jour de firmware via USB clé, les connexions TeamViewer des intégrateurs, les synchronisations ERP-SCADA mal segmentées — autant de vecteurs qui effacent les frontières propres du modèle de Purdue. Pour le pentesteur OT, la première étape est de cartographier la réalité, pas le schéma théorique affiché dans la salle des machines.

Protocoles industriels et leurs vulnérabilités : Modbus, DNP3, IEC 61850, PROFINET

Comprendre les protocoles est non-négociable avant de toucher un réseau OT. Chacun a sa syntaxe, ses mécanismes (ou leur absence), et ses vulnérabilités spécifiques.

Modbus TCP — Le protocole industriel le plus répandu au monde, conçu en 1979 par Modicon. Aucun mécanisme d'authentification, aucun chiffrement, aucune intégrité de message. N'importe qui sur le réseau OT peut envoyer des commandes Modbus à un PLC. Port TCP/502. L'attaque la plus directe : sniffing du trafic légitime, puis replay ou modification des valeurs de registres.

DNP3 — Protocole populaire dans les secteurs de l'eau et de l'énergie (SCADA de distribution). Authentification optionnelle via Secure Authentication v5 (SAv5) — rarement activée sur le terrain. Vulnérable aux attaques de replay et aux injections de commandes. Port TCP/UDP 20000.

IEC 61850 — Standard des sous-stations électriques. Les messages GOOSE (Generic Object Oriented Substation Event) transitent en multicast Ethernet sans chiffrement — interception et replay possibles sur le LAN OT. Port 102 (MMS).

PROFINET — Protocole Siemens sur Ethernet standard. Expose des fonctions de découverte (DCP Discovery) exploitables pour la reconnaissance. Présent sur les réseaux Ethernet industriels avec les PLCs S7.

OPC-UA — Le protocole le mieux sécurisé : authentification certificat, chiffrement TLS, modèle d'information structuré. Reste cependant complexe à configurer correctement — les mauvaises configurations de certificats ou les modes d'authentification anonyme sont courants.

Outils de reconnaissance ICS : comment cartographier sans perturber le processus ?

La reconnaissance en milieu OT est fondamentalement différente du pentest IT classique : un scan Nmap agressif peut saturer un switch industriel bas de gamme et provoquer une perte de communication PLC — c'est un incident opérationnel, pas un artefact bénin. La règle d'or est passive first.

Grassmarlin (outil NSA/CISA open source) effectue une cartographie passive par analyse du trafic réseau capturé (PCAP ou interface live). Il identifie les hôtes ICS, les protocoles utilisés, et génère une carte topologique sans envoyer un seul paquet. C'est l'outil de prédilection pour la phase de découverte initiale.

Les scripts Nmap pour ICS doivent être utilisés avec une extrême prudence, uniquement sur des systèmes confirmés hors production ou avec accord OT explicite :

# Scripts Nmap pour protocoles ICS
# ATTENTION : utiliser uniquement sur lab ou avec autorisation OT formelle

# Détection Modbus (port 502)
nmap -p 502 --script modbus-discover 192.168.1.0/24

# Détection S7 Siemens (port 102)
nmap -p 102 --script s7-info 192.168.1.100

# Détection DNP3 (port 20000)
nmap -p 20000 --script dnp3-info 192.168.2.0/24

# Scan doux — timing T2, pas de SYN scan agressif
nmap -sV -T2 -p 102,502,4840,20000,44818 --open 192.168.100.0/24

# JAMAIS : nmap -A, -T4, -T5, ou --script=all sur un réseau OT de production

Pour la recherche de systèmes ICS exposés sur Internet (Shodan est un outil de reconnaissance passive légal sur les IPs publiques) :

# Shodan CLI — reconnaissance passive sur IPs publiques
# Remplacer par votre clé API Shodan

# Automates Modbus exposés
shodan search "port:502" --fields ip_str,port,org,country

# S7 Siemens exposés
shodan search "port:102 Siemens" --fields ip_str,port,org,country

# DNP3 exposés (souvent des RTU de sous-stations)
shodan search "port:20000 dnp3" --fields ip_str,port,org,country

# HMI WinCC exposées (interface web)
shodan search "WinCC" --fields ip_str,port,org,country

# Interfaces SCADA avec login
shodan search "title:SCADA login" --fields ip_str,port,org,country

La veille automatisée de threat intelligence intègre souvent des flux Shodan pour identifier les ICS de ses clients exposés involontairement sur Internet — une pratique défensive directement applicable au contexte OT.

Quelles sont les vulnérabilités les plus communes dans les environnements ICS ?

Les failles les plus fréquemment trouvées lors de pentests OT ne sont généralement pas des exploits sophistiqués — elles relèvent de lacunes de configuration élémentaires que la culture "si ça marche, on ne touche pas" a perpétuées pendant des années.

Credentials par défaut : les PLCs Siemens S7-300 livrent avec un mot de passe CPU vide. Les HMI WinCC ont souvent des comptes "SIEMENS" ou "Administrator" avec des mots de passe d'usine. Les interfaces web des RTU DNP3 utilisent admin/admin. Dans 80 % des audits OT, au moins un système est accessible avec des credentials par défaut.

Firmware non mis à jour : la contrainte de disponibilité 24/7 rend les mises à jour firmware risquées — elles nécessitent un arrêt programmé. Résultat : des PLCs avec des firmwares de 2015, des HMI sous Windows 7 sans patch de sécurité depuis 2019. Les CVEs de Siemens, Schneider, et Rockwell non patchées se comptent en dizaines sur ces systèmes.

Absence de segmentation réseau : le VLAN OT "plat" — tous les PLCs, HMI et postes de supervision sur le même segment — est encore la norme dans les PME industrielles. Un poste de supervision compromis a un accès direct à tous les automates sans firewall intermédiaire.

Accès VPN mal sécurisés : les accès de téléassistance des intégrateurs (Siemens TeleService, accès TeamViewer) sont souvent permanents, avec des credentials partagés entre techniciens. Ces tunnels contournent toute la segmentation théorique du modèle de Purdue.

Méthodologie de pentest ICS : phases et précautions

Un pentest ICS suit une structure en phases, mais avec des règles d'engagement radicalement différentes du pentest IT. La première différence : l'équipe OT (opérateurs, ingénieurs process) doit être impliquée à chaque étape — pas comme observateurs, mais comme gardiens du processus. Ils ont l'autorité d'arrêter le test à tout moment si un risque opérationnel est identifié.

Phase 1 — Passive recon et cartographie : analyse PCAP avec Grassmarlin, entretiens avec les équipes OT, collecte de la documentation d'architecture. Aucun trafic actif vers les systèmes de production. Objectif : comprendre la topologie, identifier les assets critiques, définir précisément les zones testables.

Phase 2 — Scan discret sur périmètre autorisé : uniquement sur les segments validés, avec des timings Nmap T1 ou T2, et en présence d'un ingénieur OT. Identification des services exposés, des versions de firmware, des protocols actifs.

Phase 3 — Analyse des vulnérabilités : croisement des findings avec les CVEs connues (NVD, CISA ICS-CERT advisories). Pas d'exploitation active — évaluation théorique de l'exploitabilité et de l'impact.

Phase 4 — Exploitation contrôlée (lab uniquement ou fenêtre maintenance) : sur un jumeau numérique, un environnement de lab, ou pendant une fenêtre de maintenance planifiée et supervisée. Les règles absolues : jamais modifier les setpoints, jamais éteindre un PLC en production, jamais écrire dans les sorties digitales d'un équipement actif.

La comparaison avec le hardware hacking via JTAG/SWD/UART pour l'analyse firmware est utile pour les phases d'analyse des PLCs et RTUs hors ligne — une technique complémentaire applicable en phase de lab.

Lecture passive Modbus avec Python : exemple de code sécurisé

La lecture des registres Modbus en mode passif — écoute sans écriture — est la seule opération acceptable sur un PLC en production, et uniquement dans un contexte d'audit contractuel. Le script suivant effectue une lecture (holding registers) sans aucune écriture :

#!/usr/bin/env python3
"""
Lecture passive de registres Modbus TCP — audit uniquement.
NE PAS utiliser sans autorisation écrite du propriétaire du système.
Aucune écriture dans ce script.
"""
from pymodbus.client import ModbusTcpClient
import logging

logging.basicConfig(level=logging.WARNING)

def audit_modbus_passive(host: str, port: int = 502, unit_id: int = 1):
    """Lire (lecture seule) les registres Modbus d'un PLC pour audit."""
    client = ModbusTcpClient(host=host, port=port, timeout=5)

    if not client.connect():
        print(f"[!] Connexion échouée à {host}:{port}")
        return

    print(f"[+] Connecté à {host}:{port} — unit_id={unit_id}")

    try:
        # Lecture Holding Registers (FC3) — registres de configuration
        result = client.read_holding_registers(address=0, count=10, slave=unit_id)
        if not result.isError():
            print(f"[+] Holding Registers [0-9] : {result.registers}")
        else:
            print(f"[-] Erreur lecture holding registers : {result}")

        # Lecture Input Registers (FC4) — valeurs process en temps réel
        result = client.read_input_registers(address=0, count=10, slave=unit_id)
        if not result.isError():
            print(f"[+] Input Registers [0-9] : {result.registers}")

        # Lecture Coils (FC1) — états digitaux (lecture seule ici)
        result = client.read_coils(address=0, count=8, slave=unit_id)
        if not result.isError():
            print(f"[+] Coils [0-7] : {result.bits[:8]}")

    except Exception as e:
        print(f"[!] Exception : {e}")
    finally:
        client.close()
        print("[+] Connexion fermée proprement.")

if __name__ == "__main__":
    # Remplacer par l'IP du PLC dans le périmètre de test autorisé
    audit_modbus_passive("192.168.100.10", port=502, unit_id=1)

Pour la capture passive du trafic Modbus sur le réseau sans connexion directe aux PLCs :

#!/usr/bin/env python3
"""
Capture passive de trafic Modbus TCP avec Scapy.
Analyse uniquement — aucune injection de trafic.
Nécessite accès à un port mirroring (SPAN) ou un TAP réseau.
"""
from scapy.all import sniff, TCP, Raw
import struct

MODBUS_PORT = 502

def parse_modbus_packet(payload: bytes):
    """Parser basique de paquet Modbus TCP."""
    if len(payload) < 8:
        return None

    transaction_id = struct.unpack('>H', payload[0:2])[0]
    protocol_id = struct.unpack('>H', payload[2:4])[0]
    length = struct.unpack('>H', payload[4:6])[0]
    unit_id = payload[6]
    function_code = payload[7]

    fc_names = {
        1: 'Read Coils', 2: 'Read Discrete Inputs',
        3: 'Read Holding Registers', 4: 'Read Input Registers',
        5: 'Write Single Coil', 6: 'Write Single Register',
        15: 'Write Multiple Coils', 16: 'Write Multiple Registers'
    }
    fc_name = fc_names.get(function_code, f'FC {function_code}')

    # Alerter sur les fonctions d'écriture
    is_write = function_code in (5, 6, 15, 16)
    flag = " [ECRITURE!]" if is_write else ""

    return f"TxID={transaction_id} UnitID={unit_id} FC={fc_name}{flag}"

def process_packet(pkt):
    if pkt.haslayer(TCP) and pkt.haslayer(Raw):
        if pkt[TCP].dport == MODBUS_PORT or pkt[TCP].sport == MODBUS_PORT:
            result = parse_modbus_packet(bytes(pkt[Raw]))
            if result:
                src = pkt[0][1].src
                dst = pkt[0][1].dst
                print(f"  {src} -> {dst} | {result}")

print("[*] Capture passive Modbus démarrée — Ctrl+C pour arrêter")
print("[*] LECTURE SEULE — aucun paquet injecté")
# Capturer sur interface réseau (remplacer eth0 par l'interface miroir)
sniff(iface="eth0", filter=f"tcp port {MODBUS_PORT}", prn=process_packet, store=0)

Conformité NERC CIP et référentiel ANSSI : cadres réglementaires

La CISA (Cybersecurity and Infrastructure Security Agency) publie les ICS-CERT advisories — indispensables pour connaître les CVEs actives sur les équipements industriels. Le NIST SP 800-82 Rev3 (Guide to OT Security) est le document de référence américain pour la sécurité OT, applicable en dehors du contexte NERC.

NERC CIP (North American Electric Reliability Corporation Critical Infrastructure Protection) s'applique aux opérateurs du réseau électrique nord-américain. Ses standards pertinents pour le pentest :

• CIP-005 (Electronic Security Perimeter) : définit les périmètres de sécurité électronique, les accès autorisés et les contrôles de sécurité des accès distants. Un pentest doit vérifier l'étanchéité de ces périmètres.
• CIP-007 (Systems Security Management) : gestion des ports et services, gestion des correctifs, gestion des comptes. Les findings sur credentials par défaut et firmware non patché s'y rattachent directement.

Le guide ANSSI sur la maîtrise du risque numérique par les systèmes industriels est le référentiel français. Il définit quatre niveaux de maturité en sécurité OT et fournit des recommandations priorisées : segmentation réseau, gestion des accès distants, durcissement des postes de supervision, gestion des mises à jour. Les entreprises françaises opérant des OIV (Opérateurs d'Importance Vitale) sont soumises à des obligations spécifiques définies par la LPM (Loi de Programmation Militaire) — les audits de sécurité OT y sont obligatoires.

Détection et monitoring OT : IDS industriels et intégration SIEM

Le monitoring des réseaux OT est fondamentalement différent du monitoring IT : les outils doivent comprendre les protocoles industriels, être capables de détecter des anomalies de comportement (un PLC qui reçoit des commandes d'écriture en dehors de la fenêtre de maintenance), et ne doivent jamais impacter la disponibilité.

Les solutions commerciales leaders : Claroty, Dragos, et Nozomi Networks fonctionnent toutes en mode passif (miroir de port ou TAP) et décodent nativement les protocoles industriels. Elles intègrent des signatures pour les CVEs connues des équipements industriels et des modèles de comportement basés sur l'apprentissage.

Pour les équipes qui souhaitent une approche open source, Suricata avec des règles ICS est une alternative viable. Exemple de règle de détection d'écritures Modbus anormales :

# Règle Suricata — détection d'écriture Modbus TCP (FC5, FC6, FC15, FC16)
# A placer dans /etc/suricata/rules/ics-modbus.rules

# Write Single Coil (FC5)
alert tcp any any -> any 502 (
  msg:"ICS Modbus Write Single Coil détecté";
  flow:established,to_server;
  content:"|00 00 00 06|";
  depth:6;
  offset:2;
  byte_test:1,=,5,7;
  threshold: type both, track by_src, count 3, seconds 60;
  classtype:policy-violation;
  sid:9000001; rev:1;
)

# Write Multiple Registers (FC16) — souvent utilisé pour modifier setpoints
alert tcp any any -> any 502 (
  msg:"ICS Modbus Write Multiple Registers (setpoints potentiels)";
  flow:established,to_server;
  byte_test:1,=,16,7;
  threshold: type both, track by_src, count 1, seconds 60;
  classtype:attempted-admin;
  sid:9000002; rev:1;
)

# Connexion Modbus depuis hôte IT (hors segment OT attendu)
# Adapter 10.0.0.0/8 au VLAN IT réel de l'organisation
alert tcp 10.0.0.0/8 any -> 192.168.100.0/24 502 (
  msg:"ICS Modbus connexion depuis segment IT vers segment OT";
  flow:established;
  classtype:policy-violation;
  sid:9000003; rev:1;
)

L'intégration de ces alertes dans un SIEM (Splunk, Elastic) avec des playbooks de réponse automatisés est le niveau de maturité suivant. Le guide forensics Windows expert offre des techniques complémentaires applicables aux postes HMI Windows dans le cadre d'une investigation post-incident OT.

Quelles leçons tirer des incidents Stuxnet, TRITON et Colonial Pipeline ?

L'histoire des cyberattaques OT fournit les meilleurs enseignements sur les techniques réelles et les impacts possibles.

Stuxnet (2010) ciblait les centrifugeuses d'enrichissement d'uranium iraniennes via des automates Siemens S7-315. Sa sophistication : propagation via clé USB, exploitation de quatre zero-days Windows, ciblage précis par fréquence de rotation des moteurs, modification subtile des vitesses pour endommager physiquement les centrifugeuses tout en affichant des valeurs normales sur les HMI. Leçon : un attaquant avancé peut opérer des mois sans être détecté sur un réseau OT non monitoré.

TRITON/TRISIS (2017) visait un Safety Instrumented System (SIS) dans une usine pétrochimique saoudienne. L'objectif présumé : désactiver les systèmes de sécurité qui auraient dû déclencher un arrêt d'urgence, permettant ensuite de provoquer un accident physique. C'est la première attaque connue visant explicitement à tuer des personnes. Leçon : les SIS ne sont plus des air gaps — leur connectivité réseau croissante les expose.

Colonial Pipeline (2021) était une attaque ransomware sur le SI corporate, pas sur les ICS directement. Mais la décision d'arrêt préventif des pipelines (par crainte de propagation vers l'OT) a causé une pénurie de carburant sur la côte Est américaine. Leçon : même sans compromettre directement les ICS, une attaque IT qui crée de l'incertitude sur l'intégrité OT peut avoir des effets opérationnels massifs. La convergence IT/OT crée des cascades de risques.

L'article sur l'IA pour le red teaming avec agents autonomes en 2026 explore comment les techniques d'IA appliquées à l'offensive pourraient évoluer dans les environnements OT dans les prochaines années — une tendance à surveiller de près.

NIST SP 800-82 et ENISA : référentiels internationaux pour la sécurité OT

Le NIST SP 800-82 Rev3 est la référence américaine la plus complète pour la sécurité des OT. Sa révision 3 (2023) intègre la convergence IT/OT, les architectures cloud ICS, et aligne ses contrôles avec le NIST Cybersecurity Framework. Pour un pentest OT, il fournit un cadre d'évaluation structuré : identification des assets, protection des périmètres, détection des anomalies, réponse et récupération.

L'ENISA (Agence européenne pour la cybersécurité) publie régulièrement des rapports sur la sécurité des ICS en Europe, incluant des statistiques d'incidents et des recommandations sectorielles (énergie, eau, transports). La directive NIS2 (2022) impose des obligations de sécurité renforcées aux opérateurs d'infrastructure critique dans l'UE — les systèmes OT des secteurs listés (énergie, eau, transport) sont explicitement dans le scope.

L'investigation post-incident sur les systèmes OT nécessite des compétences forensics adaptées. Le guide cloud forensics pour AWS et Azure est pertinent pour les architectures ICS hybrides où les données de supervision remontent dans le cloud.

Questions fréquentes sur le pentest ICS/SCADA

Peut-on faire un pentest ICS sur un environnement de production actif ?

La reconnaissance passive (capture trafic, Grassmarlin) est généralement acceptable avec accord OT. Les scans actifs et toute exploitation sont réservés aux environnements de lab, aux jumeaux numériques, ou aux fenêtres de maintenance planifiées avec supervision OT sur site. La règle absolue : si une action peut interrompre un processus, elle est interdite en production sans validation formelle de l'équipe OT et de la direction opérationnelle. Documentez tout par écrit avant de commencer.

Quels prérequis pour se spécialiser en sécurité OT ?

Une base solide en réseau (TCP/IP, VLAN, routage) et en Linux est indispensable. La connaissance des protocoles industriels s'acquiert par la pratique sur des équipements de lab (des PLCs Siemens S7 d'occasion ou des Raspberry Pi avec PLC émulé). Les certifications GICSP (GIAC Industrial Cyber Security Professional) et la formation ICS410 SANS sont les références du marché. Une immersion chez un intégrateur industriel ou un contact avec des équipes OT est irremplaçable — comprendre les contraintes opérationnelles avant de tester est fondamental.

Quels sont les risques légaux d'un pentest ICS mal encadré ?

Les risques sont considérables. En France, un test sans mandat écrit précis tombe sous le coup de la loi Godfrain (accès non autorisé à un système informatique). Si le test provoque un incident — arrêt de production, accident — la responsabilité civile et pénale du pentesteur et de son entreprise est directement engagée. Le mandat doit préciser exactement le périmètre, les dates et heures, les techniques autorisées, les personnes désignées côté client. Pour les OIV français, les conditions d'audit sont encadrées réglementairement par l'ANSSI.

Comment monter un lab ICS pour la pratique ?

Les options accessibles : un automate S7-1200 Siemens (~300 €) avec WinCC Runtime Basic, un Raspberry Pi avec OpenPLC Runtime (simulateur PLC open source gratuit), ou ScadaBR (SCADA open source). Des solutions cloud comme GNS3 avec des modules ICS permettent une simulation réseau. Les exercices de la Cyberrange ICS (ENISA, Idaho National Laboratory) fournissent des scénarios pré-configurés pour la pratique. Un lab physique minimaliste coûte 500-1000 € et permet de pratiquer Modbus, DNP3, et les techniques d'audit de firmware.

La directive NIS2 s'applique-t-elle aux PME industrielles ?

NIS2 s'applique aux entités "essentielles" et "importantes" dans les secteurs listés (énergie, eau, transports, santé, etc.). Les seuils : entité "importante" dès 50 salariés et 10 M€ de CA dans un secteur concerné. Une PME de 60 personnes opérant un réseau de distribution d'eau est donc dans le scope NIS2. Les obligations incluent des mesures de gestion des risques, des obligations de notification d'incident, et des audits de sécurité réguliers — ce qui rend le pentest OT obligatoire pour ces acteurs à partir de 2025-2026.

Conclusion

Le pentest ICS/SCADA est une discipline où la compétence technique doit être doublée d'une compréhension profonde des contraintes opérationnelles. Personne ne vous remerciera d'avoir découvert dix vulnérabilités critiques si vous avez provoqué un arrêt de production en les cherchant. La rigueur méthodologique, le travail en équipe avec les opérateurs OT, et le respect absolu des règles d'engagement différencient un audit ICS de qualité d'une opération risquée. Le marché de la sécurité OT est en pleine expansion — la pénurie de profils compétents est réelle, et les rémunérations le reflètent. Investissez dans un lab, formez-vous sur les protocoles, et construisez des relations avec les équipes OT avant de les auditer.