Le Portugal crée un cadre légal pour protéger la recherche en cybersécurité : signalement rapide des failles, respect du RGPD, et interdiction des méthodes agressives.
TL;DR : L’essentiel
- Le Portugal modifie sa loi sur la cybercriminalité pour soustraire certains actes à la sanction pénale, lorsque l’objectif unique consiste à identifier une vulnérabilité et à renforcer la sécurité.
- La protection n’existe qu’au prix de contraintes cumulatives : absence de gain économique hors rémunération normale, actions strictement nécessaires, et obligation de signaler sans délai au propriétaire, au détenteur de données et au CNCS.
- Le texte encadre aussi la manière de tester : aucun dommage, aucune perturbation de service, aucune altération ou suppression de données, et interdiction explicite de techniques comme DoS/DDoS, hameçonnage, vol de mots de passe, ingénierie sociale ou déploiement de malware.
- Les données collectées durant l’investigation doivent rester confidentielles et être supprimées dans les dix jours après correction, afin d’éviter qu’un test défensif ne devienne une nouvelle source de risque.
Pendant longtemps, tester un système sans autorisation exposait un chercheur à des poursuites, même lorsque l’objectif était de signaler une faille. Le Portugal change la règle du jeu : une exemption pénale apparaît, mais seulement si le test reste limité, sans dommage, et s’accompagne d’un signalement immédiat.
Une exception pénale taillée pour la recherche en sécurité
Concrètement, le sujet porte sur une mise à jour de la loi portugaise sur la cybercriminalité : un nouveau décret de loi (Decree Law 125/2025) ajoute l’« Article 8.º-A », dédié aux actes non punissables dans l’intérêt public de la cybersécurité. Il crée un cadre de « refuge légal » pour la recherche menée de bonne foi : des gestes pouvant relever d’un accès non autorisé ou d’une interception de données ne sont plus poursuivis si l’objectif unique est d’identifier une vulnérabilité et de la signaler pour renforcer la sécurité.
Deux notions juridiques sont au cœur du texte. « Accès illégitime » : entrer dans un système sans autorisation. « Interception illégitime » : capter des communications ou des données qui circulent. Un test de sécurité peut toucher ces zones, par exemple en prouvant qu’une application expose des données, qu’un service accepte une requête inattendue, ou qu’une configuration laisse fuiter des informations.
L'essentiel Cybersécurité, IA & Tech
Rejoignez la communauté. 3 fois par semaine, recevez l'analyse des tendances par Marc Barbezat. Pas de spam, juste de l'info.
Avant la réforme, cette zone grise pouvait décourager la recherche : peur de poursuites, tests stoppés trop tôt, correctifs retardés. La loi ne supprime pas ces délits ; elle ouvre une exception encadrée quand l’objectif est de signaler une faille et d’améliorer la sécurité, dans les limites de l’article 8.º-A.
La mesure est rapportée et détaillée par BleepingComputer, qui insiste sur un point central : la protection est conditionnelle. La loi n’offre pas un blanc-seing. Elle exige une finalité défensive, l’absence de bénéfice indu, une limitation stricte des actions, l’absence de dommage et un processus de signalement immédiat, tout en imposant un traitement des données compatible avec le cadre de protection des données personnelles.
Cette approche transforme la relation entre organisations et chercheurs. Les entreprises, prestataires et opérateurs de services numériques obtiennent un cadre qui encourage la remontée de failles plutôt que leur silence. Les chercheurs, de leur côté, gagnent un espace juridique, mais seulement s’ils adoptent une discipline de travail : documentation, minimisation, communication et confidentialité.
Article 8-A (traduction fournie via Google)
Actes non punissables en raison de l'intérêt public pour la cybersécurité.
1er - Les actes susceptibles de constituer les délits d'accès illégitime et d'interception illégitime, tels que prévus respectivement aux articles 6 et 7, ne sont pas punissables si les circonstances suivantes sont cumulativement vérifiées :
a) L’agent agit dans le seul but d’identifier l’existence de vulnérabilités dans les systèmes d’information, les produits et les services des technologies de l’information et de la communication, qui n’ont pas été créés par lui-même ou par un tiers dont il dépend, et dans le but de contribuer à la sécurité du cyberespace par leur divulgation ;
b) L’agent n’agit pas dans le but d’obtenir un avantage économique ou une promesse d’avantage économique découlant de son action, sans préjudice de la rémunération qu’il obtient en contrepartie de son activité professionnelle ;
(c) L’agent doit immédiatement, après son action, communiquer toute vulnérabilité identifiée au propriétaire ou à la personne désignée par lui pour gérer le système d’information, le produit ou le service de technologies de l’information et de la communication, au détenteur de toutes les données obtenues et qui sont protégées en vertu de la législation applicable en matière de protection des données personnelles, à savoir le Règlement général sur la protection des données (RGPD), approuvé par le Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016, la loi n° 26/2016 du 22 août, telle que modifiée, la loi n° 58/2019 du 8 août et la loi n° 59/2019 du 8 août ;
d) Les actions de l’agent doivent être proportionnées à leurs objectifs et strictement limitées à ceux-ci, se contentant des actions nécessaires à l’identification des vulnérabilités et ne causant pas :
i) Une perturbation ou une interruption dans le fonctionnement du système ou du service en question ;
ii) La suppression ou la détérioration des données informatiques ou leur copie non autorisée ;
iii) Tout effet nuisible, dommageable ou préjudiciable sur la personne ou l’entité concernée, directement ou indirectement, ou sur des tiers, à l’exclusion des effets correspondant à l’accès illégitime ou à l’interception illégitime elle-même, tels que prévus aux articles 6 et 7, ainsi que ceux qui résulteraient déjà, avec une forte probabilité, de la vulnérabilité détectée ou de son exploitation ;
(e) Les actions de l’agent ne constituent pas une violation des données personnelles protégées par la législation applicable en matière de protection des données personnelles, notamment le Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016, la loi n° 58/2019 du 8 août et la loi n° 59/2019 du 8 août.
2e - La communication prévue au point c du paragraphe précédent doit également être faite à l'autorité nationale de cybersécurité, qui la transmet à la police judiciaire lorsqu'elle a une pertinence pénale.
3 - Afin de déterminer la proportionnalité des actions de l'agent, il sera tenu compte de la nécessité de ces actions pour détecter la vulnérabilité et de la nécessité, pour l'intérêt de contribuer à la cybersécurité, de l'étendue des systèmes informatiques ou des données consultés et/ou copiés, l'utilisation des pratiques suivantes étant expressément interdites :
a) Mécanismes de déni de service (DoS) ou de déni de service distribué (DDoS) ;
b) L’ingénierie sociale, définie comme l’acte de tromper les responsables ou les utilisateurs des systèmes d’information en vue d’obtenir des informations sensibles ou confidentielles ;
c) « Hameçonnage » et ses variantes ;
d) Vol ou dérobé de mots de passe ou d’autres informations sensibles ;
e) Suppression ou altération volontaire de données informatiques ;
f) Dommages intentionnels causés au système d’information ;
g) Installation et distribution de logiciels malveillants.
4 - Sans préjudice des règles applicables en matière de protection des données, les données informatiques communiquées au propriétaire ou à la personne chargée de la gestion du système d'information, du produit et du service des technologies de l'information et de la communication, ou à l'autorité nationale de cybersécurité, doivent être supprimées dans les 10 jours suivant la correction de la vulnérabilité, et leur confidentialité doit être garantie tout au long de la procédure.
5e - Les actes commis avec le consentement du propriétaire ou de l'administrateur d'un système d'information, d'un produit ou d'un service de technologies de l'information et de la communication ne sont pas punissables de la même manière, sans préjudice de l'obligation de notifier à l'autorité nationale de coordination chargée de répondre aux incidents de cybersécurité toute vulnérabilité identifiée, conformément aux dispositions du régime juridique de la cybersécurité.
L’article 8.º-A fonctionne comme une règle simple : un test peut être toléré s’il sert uniquement à trouver une faille et à la signaler, sans dégâts et sans méthodes offensives. Le « droit à tester » n’existe pas ; il s’agit d’une exception encadrée, à respecter au mot près.
Des garde-fous techniques et opérationnels qui changent la pratique
Le premier verrou est l’intention : l’action doit viser l’identification de vulnérabilités et leur divulgation pour améliorer la cybersécurité, et non un objectif personnel ou opportuniste. Le texte exclut aussi les vulnérabilités créées par l’auteur ou un tiers dont il dépend.
Le deuxième verrou porte sur l’argent : une rémunération normale liée au travail reste admise, mais pas l’avantage tiré de l’acte lui-même. L’esprit est de séparer la recherche et l’audit légitimes d’une logique de pression, de rançon ou de transaction ambiguë.
Le point le plus concret est l’obligation de signaler immédiatement la vulnérabilité : au propriétaire (ou gestionnaire du système), au détenteur des données concernées lorsque des données personnelles sont en jeu, et au CNCS, qui peut transmettre à la police judiciaire si un aspect pénal apparaît.
Le test doit ensuite rester minimal et proportionné : uniquement ce qui est nécessaire pour prouver la faille, sans interruption de service, sans suppression ni détérioration de données, et sans effets nuisibles pour l’organisation, les personnes concernées ou des tiers. La logique est simple : démontrer l’existence du risque sans créer de dommage supplémentaire.
La frontière est matérialisée par une liste d’interdictions : pas de DoS/DDoS, pas d’ingénierie sociale, pas d’hameçonnage, pas de vol de mots de passe, pas d’altération volontaire, pas de dommages intentionnels, pas de malware. Enfin, les données obtenues doivent rester confidentielles et être supprimées dans les dix jours suivant la correction de la vulnérabilité.
Une tendance internationale… et ses zones grises
Les extraits placent le Portugal dans une tendance plus large, avec des repères déjà cités ailleurs. En Allemagne, un projet de modernisation du droit pénal informatique porté par le ministère fédéral de la Justice est consultable sur le site officiel du Bundesministerium der Justiz (BMJ) et dans le texte du Referentenentwurf (PDF). Aux États-Unis, le DOJ a indiqué en mai 2022 que la recherche de bonne foi ne devait pas être poursuivie sous le CFAA, comme l’expose son communiqué officiel ; l’orientation s’inscrit dans le cadre décrit par le Justice Manual. Au Royaume-Uni, l’idée d’une défense légale pour la recherche est évoquée, et cette dynamique est relayée par Hackread.
Le cadre reste toutefois exigeant sur deux points pratiques. D’abord, la « proportionnalité » : s’arrêter dès que la preuve est suffisante, car la frontière entre test minimal et dépassement peut se jouer sur quelques actions de trop. Ensuite, l’absence de perturbation : même un test limité peut produire des effets de bord, ce qui impose de calibrer la méthode et de pouvoir démontrer une intention non nuisible.
Pour les organisations, le gain attendu est clair : encourager la remontée de failles plutôt que le silence. La contrepartie est opérationnelle : si la notification doit partir vite et vers plusieurs acteurs, la capacité à recevoir, qualifier et corriger rapidement devient un élément central de maîtrise, tout comme la gestion stricte des données consultées durant le test.
Au final, la réforme portugaise trace un compromis net : protéger la recherche utile, tout en interdisant explicitement les méthodes agressives et en verrouillant le traitement des données. Le mouvement décrit dans les extraits va dans le même sens : rendre la découverte de vulnérabilités plus praticable, mais sous conditions strictes et traçables.
Cette veille vous est utile ?
Offrez un café pour soutenir le serveur (et le rédacteur).