La directive (UE) 2024/2853 classe les logiciels et les systèmes d’intelligence artificielle comme des « produits » soumis à une responsabilité objective. Cela modifie concrètement le profil de risque des éditeurs de logiciels : en cas de dommage causé par une vulnérabilité, le fabricant est responsable même sans faute, à moins qu’il ne puisse prouver que le défaut n’était pas décelable avec les connaissances techniques disponibles au moment de la mise sur le marché. Le test d’intrusion (penetration test) est l’outil qui produit cette preuve sous une forme documentée et défendable.

Cet article fait partie du mini-guide sur la directive (UE) 2024/2853. Pour une vue d’ensemble, consultez le hub de la directive, ou approfondissez les chapitres sur les produits numériques et la responsabilité des logiciels.

Quand un produit logiciel est-il considéré comme défectueux

La directive définit comme défectueux le produit qui n’offre pas la sécurité à laquelle le public peut légitimement s’attendre, en tenant compte également des exigences de cybersécurité applicables. Pour le logiciel, cela signifie qu’une vulnérabilité exploitable — même si elle n’a pas encore été exploitée — peut suffire à qualifier le produit de défectueux au moment de sa mise en circulation.

Le test d’intrusion, réalisé avant la mise sur le marché et après chaque modification substantielle, permet de documenter que les défenses du produit ont été vérifiées de manière systématique et que les vulnérabilités connues ou raisonnablement identifiables ont été traitées. Sans cette documentation, le fabricant se retrouve à devoir prouver l’absence de défauts sans preuves concrètes.

Charge de la preuve et documentation technique

La directive introduit un mécanisme d’accès aux preuves qui peut obliger le fabricant à produire la documentation technique en cas de litige. Si cette documentation n’existe pas ou est incomplète, le défaut est présumé. Si, en revanche, elle existe et est à jour, le fabricant peut invoquer l’exonération liée à « l’état des connaissances techniques » : au moment de la mise en circulation, le défaut n’était pas décelable avec les méthodes disponibles.

Un rapport de test d’intrusion daté, signé par une équipe indépendante et corrélé aux versions du logiciel testées, est la forme la plus directe de cette documentation. Une analyse automatisée ne suffit pas : il faut une activité manuelle et créative qui simule le comportement d’un attaquant réel.

Responsabilité en cas d’intervention d’un attaquant externe

La directive maintient la responsabilité du fabricant même lorsque le dommage est causé conjointement par le défaut du produit et par l’action d’un tiers — par exemple un attaquant exploitant une vulnérabilité non corrigée. La présence d’un pirate informatique dans la chaîne causale n’exonère pas le producteur.

Le test d’intrusion sert précisément à simuler ce scénario : si une vulnérabilité est identifiable avec des techniques offensives standard, le fabricant ne peut pas soutenir qu’elle était imprévisible. Documenter que le test a été effectué — et que les vulnérabilités apparues ont été corrigées — réduit concrètement l’exposition aux demandes d’indemnisation pour dommages physiques, psychologiques ou destruction de données.

Test d’intrusion ou analyse de vulnérabilités : lequel est nécessaire pour la directive

L’analyse de vulnérabilités (vulnerability assessment) identifie les vulnérabilités connues par le biais de scans automatisés et de comparaisons avec des bases de données publiques. Elle est utile pour le suivi continu, mais ne produit pas les preuves que la directive exige en cas de litige.

Le test d’intrusion ajoute la composante manuelle et offensive : un testeur expert vérifie si les vulnérabilités sont effectivement exploitables dans le contexte spécifique du produit, concatène plusieurs faiblesses pour simuler une attaque réelle et documente le chemin suivi. C’est cette profondeur d’analyse — et sa traçabilité — qui fait du test d’intrusion l’outil adéquat pour répondre aux exigences de preuve prévues par la directive.

Pour les produits logiciels et les applications web, le Web Application Penetration Testing d’ISGroup couvre ce besoin avec des méthodologies OSSTMM et OWASP, des rapports structurés et un support à la remédiation.

Approfondissements utiles

• Guide de la directive (UE) 2024/2853 — le cadre complet sur la responsabilité objective pour les produits, y compris les logiciels et l’IA.
• Produits numériques et directive UE — comment la directive s’applique aux logiciels, applications et composants numériques intégrés.
• Responsabilité du logiciel — analyse des obligations spécifiques pour les fabricants de logiciels.
• Analyse de vulnérabilités et directive UE — quand l’analyse de vulnérabilités suffit et quand le test d’intrusion est nécessaire.

Questions fréquentes

• À quelle fréquence le test d’intrusion doit-il être effectué pour être utile aux fins de la directive ?
• La directive ne fixe pas de périodicité, mais le critère est la modification substantielle : chaque mise à jour qui modifie des fonctionnalités pertinentes pour la sécurité nécessite un nouveau test. Un test effectué sur une version précédente ne couvre pas les vulnérabilités introduites ultérieurement.
• Le test d’intrusion doit-il être effectué par un tiers externe ?
• La directive ne l’impose pas explicitement, mais en cas de litige, un rapport produit par une équipe indépendante a un poids probatoire significativement plus élevé qu’une analyse interne. L’indépendance du testeur renforce la crédibilité de la documentation.
• Le test d’intrusion couvre-t-il également les systèmes d’intelligence artificielle ?
• Oui, dans la mesure où le système d’IA est classé comme produit au sens de la directive. Pour les composants d’IA intégrés dans des logiciels, le test doit inclure les vecteurs d’attaque spécifiques au modèle — tels que l’injection de prompt ou la manipulation des entrées — en plus des vulnérabilités applicatives traditionnelles.
• Que se passe-t-il si le test d’intrusion identifie des vulnérabilités qui ne sont pas corrigées avant la mise sur le marché ?
• Le rapport documente les vulnérabilités connues au moment de la mise sur le marché. Si le fabricant choisit de commercialiser le produit sans corriger ces vulnérabilités, la documentation devient une preuve à sa défaveur : elle démontre que le défaut était connu et n’a pas été traité.

[Callforaction-WAPT-Footer]