STAD : définition juridique et preuves d’intrusion

Un STAD, ou système de traitement automatisé de données, est le système informatique protégé par les articles 323-1 et suivants du Code pénal. Pour qualifier une intrusion, il faut décrire le système atteint, les opérations réalisées et le caractère frauduleux des faits. La présence d’un ordinateur ne suffit pas à démontrer une infraction.

Définition du STAD : identifier un système qui traite des données

Le Code pénal emploie la notion sans en donner une définition technique générale. Pour préparer un dossier, on peut décrire le STAD comme un ensemble de moyens informatiques réalisant un traitement automatisé de données : application, serveur, stockage, comptes et interfaces qui permettent ce fonctionnement. Cette description de travail doit correspondre au système réellement concerné. Source : Code pénal, Art. 323-1 à 323-3.

Un portail documentaire, une messagerie ou une application métier peuvent ainsi être analysés à partir de leur fonctionnement concret. Évitez les raccourcis tels que « tout objet connecté constitue nécessairement un STAD » : décrivez ce qu’il reçoit, traite, conserve et transmet, puis le périmètre auquel l’auteur des faits a accédé.

Une définition souvent reproduite associe unités de traitement, mémoires, logiciels, données et liaisons concourant à un résultat déterminé, avec des dispositifs de sécurité. Il s’agit d’une proposition parlementaire qui n’a pas été retenue dans le Code pénal, comme le rappelle le rapport sénatorial sur la confiance dans l’économie numérique, commentaire de l’article 33. Il serait donc incorrect de la citer comme une définition légale actuelle ou d’en déduire mécaniquement qu’un défaut de protection exclut toute infraction.

En pratique, distinguez le système de son contenu. Un document imprimé peut reproduire une donnée issue d’une application ; il n’est pas pour autant le système qui l’a traitée. À l’inverse, une application hébergée chez un prestataire reste à décrire même si l’entreprise ne possède aucun serveur dans ses locaux. Le dossier doit rendre compréhensible la fonction de chaque composant, sans exiger du lecteur qu’il connaisse l’architecture informatique.

La protection pénale ne se limite pas aux données personnelles. L’article 323-3 vise aussi des données techniques ou commerciales. La qualification d’une cyberattaque et les peines applicables doivent ensuite être examinées séparément.

Accès, maintien et atteinte aux données : séparer les faits

Les articles 323-1 à 323-3 ne désignent pas une seule infraction appelée « piratage ». L’Art. 323-1 vise l’accès ou le maintien frauduleux dans tout ou partie du système. L’Art. 323-2 concerne l’entrave ou le fait de fausser son fonctionnement. L’Art. 323-3 vise notamment l’extraction, la reproduction, la transmission, la suppression ou la modification frauduleuses des données. Textes en vigueur consultés le 27 septembre 2026.

Cette distinction change le dossier à réunir. Une trace de connexion ne démontre pas, à elle seule, une extraction. Un serveur indisponible ne prouve pas davantage une entrave volontaire : une panne peut avoir d’autres causes. Il faut rapprocher les opérations observées des autorisations et des circonstances, puis examiner les éléments propres à chaque qualification.

À titre de repère, l’accès ou le maintien frauduleux de l’Art. 323-1, premier alinéa, expose une personne physique à trois ans d’emprisonnement et 100 000 € d’amende. Il s’agit du maximum prévu pour cette qualification simple, pas d’une sanction automatiquement prononcée après chaque incident. Les conséquences sur les données ou le fonctionnement, ainsi que certains systèmes visés, peuvent modifier le régime applicable. Le guide consacré aux infractions développe ces distinctions ; ici, l’objectif est d’identifier correctement le système et les faits.

Système accessible et accès autorisé : deux questions différentes

Dans l’arrêt du 20 mai 2015, n° 14-81.336, la Cour de cassation examine des documents accessibles à la suite d’une défaillance technique de l’extranet de l’ANSES. L’accès frauduleux initial n’avait pas été retenu. Le maintien frauduleux et le vol ont toutefois été confirmés : l’intéressé avait compris que le système était normalement protégé, puis poursuivi ses opérations et récupéré les données. Source : Cass. crim., 20 mai 2015, n° 14-81.336.

Cet arrêt ne transforme pas tout téléchargement public en infraction. Il montre pourquoi la chronologie et la connaissance du défaut d’autorisation comptent. Une absence de mot de passe à un instant donné ne constitue pas, à elle seule, une permission d’exploiter le système.

Pour un test d’intrusion autorisé, le dossier doit donc préciser les systèmes, les opérations permises, la période et les personnes habilitées à autoriser la mission. Une autorisation sur une application ne couvre pas automatiquement les autres services de son hébergeur.

Un identifiant qui fonctionne n’est pas une autorisation permanente

Dans une autre affaire, un code avait été remis pour une période d’essai d’une base de renseignements commerciaux. Son utilisation avait ensuite continué pendant plus de deux ans, sans nouvelle saisie nécessaire à chaque connexion. La Cour de cassation a censuré, dans ses seules dispositions civiles, l’arrêt qui avait écarté les demandes de la partie civile : les constatations sur la durée d’utilisation et la restriction aux personnes autorisées n’avaient pas reçu leurs conséquences légales. Cass. crim., 3 octobre 2007, n° 07-81.045.

Pour l’entreprise, la conséquence pratique est double. Elle doit désactiver les accès devenus inutiles ; elle doit également conserver les documents précisant la durée et la portée des droits accordés. L’oubli technique et l’autorisation juridique sont des faits différents. Pour l’utilisateur, une connexion encore possible après la fin connue d’un essai ne constitue pas un renouvellement implicite sur lequel compter.

Cas pratique : un compte de maintenance utilisé après la mission

Exemple entièrement hypothétique. Une PME industrielle utilise un portail de plans techniques. Une application gère les versions, une base associe les plans aux commandes et un espace de stockage conserve les fichiers. Un prestataire reçoit un compte nominatif pour corriger un module de recherche jusqu’au 31 août, sans droit contractuel d’exporter les dossiers clients. La fin de mission lui est confirmée par écrit.

Le 2 septembre, la responsable informatique constate un export depuis ce compte, resté actif par erreur. Elle ne conclut pas immédiatement que l’ancien intervenant en est l’auteur. Le compte peut avoir été utilisé par un tiers ; une tâche planifiée doit aussi être exclue. Elle ferme l’accès inutile, préserve les traces disponibles et note les modifications effectuées. La protection du système ne doit pas attendre la résolution complète de l’enquête.

Le portail traite automatiquement les recherches et les versions : la fiche décrit ce fonctionnement plutôt que d’inscrire seulement « serveur piraté ». L’export est rapproché d’une connexion, du compte, de son périmètre et du document de fin de mission. Une consultation après échéance appelle un examen de l’accès ou du maintien ; l’export appelle aussi celui des opérations sur les données. Ces pistes ne constituent pas une déclaration de culpabilité.

La fiche transmise au juriste et aux enquêteurs

Voici le dossier rempli du scénario. Les références sont fictives ; elles illustrent les pièces à rapprocher, pas une intrusion réellement traitée pour cet article.

Le premier export de journaux contient seulement les noms de fichiers, sans horodatage précis. La responsable ne complète pas les heures de mémoire. Elle conserve cette extraction initiale, demande les traces détaillées disponibles au prestataire d’hébergement et documente leur provenance. Si certaines traces ont déjà disparu, cette limite figure dans le dossier : l’absence d’événement conservé ne prouve pas l’absence d’opération.

Le rapprochement confirme ensuite, dans l’hypothèse, la réalisation de l’export et exclut une tâche programmée. Il ne suffit toujours pas à attribuer personnellement l’opération. Le dossier transmis sépare donc le fait technique confirmé de l’hypothèse d’auteur. La direction peut déposer plainte contre X et remettre les pièces sans inventer une certitude sur l’identité. La qualification finale et l’attribution doivent être établies dans le cadre approprié.

L’équipe corrige parallèlement son processus : chaque accès temporaire reçoit une échéance, un responsable de suppression et un contrôle de fermeture. La reprise du portail intervient après vérification des comptes et des sessions encore utilisables. Insérez ces décisions dans votre procédure de gestion des incidents, avec les écarts qui restent ouverts.

Préserver des preuves exploitables sans réécrire l’histoire

Conservez les fichiers disponibles dans leur format d’origine, leurs métadonnées utiles et une copie de travail distincte. Notez qui a collecté chaque pièce, à quel moment et depuis quelle source. Une empreinte numérique permet de comparer l’intégrité de deux copies ; elle ne démontre pas, à elle seule, que leur contenu est exact ni qui a réalisé l’action enregistrée. Ces précautions constituent une méthode de préparation du dossier, pas une garantie d’admissibilité ou de force probante.

Vérifiez aussi les fuseaux horaires et les éventuels décalages d’horloge avant de rapprocher deux événements. Un tableau réordonné manuellement doit rester relié aux traces dont il provient. Si une intervention urgente a modifié le système, consignez-la : masquer cette opération rendrait la chronologie moins fiable.

Enfin, limitez la circulation des pièces. Le dossier peut révéler les données de clients et des informations techniques sensibles. Le remettre aux personnes chargées de l’incident ne justifie pas de diffuser publiquement les fichiers extraits pour démontrer la gravité de l’attaque.

STAD, RGPD et sécurité : des analyses qui se complètent

Le droit pénal vise les actes reprochés à l’auteur de l’atteinte. Le RGPD examine aussi les obligations de l’organisme qui traite des données personnelles : sécurité adaptée au risque selon l’Art. 32(1), documentation des violations selon l’Art. 33(5) et notification lorsque ses conditions sont réunies. Être victime d’une intrusion ne prouve donc ni une conformité parfaite ni un manquement automatique. Source : RGPD, Art. 32 et 33.

Si les fichiers du scénario contiennent des données personnelles, le responsable examine sans attendre les risques pour les personnes. L’Art. 33(1) prévoit la notification à l’autorité compétente dans les meilleurs délais et, si possible, sous 72 heures après la prise de connaissance, sauf violation non susceptible d’engendrer un risque. L’Art. 33(4) permet de transmettre des informations complémentaires de manière échelonnée. Il ne faut donc pas attendre l’identification pénale de l’auteur pour commencer cette analyse.

La fiche du système alimentera utilement la notification d’une violation de données, mais les deux dossiers répondent à des questions différentes. Le mot STAD ne détermine pas à lui seul l’assujettissement à un autre régime de cybersécurité.

Ce qu’il faut retenir

• Décrivez le fonctionnement et le périmètre du système concerné.
• Distinguez l’accessibilité technique de l’autorisation juridique.
• Reconstituez les faits et la connaissance des limites d’accès.
• Traitez séparément l’infraction pénale et les obligations RGPD de la victime.

FAQ

Un STAD doit-il traiter des données personnelles ?

Non. Les articles 323-1 et suivants protègent les systèmes et leurs données sans limiter leur champ aux informations concernant des personnes physiques.

Une faille ouverte autorise-t-elle à télécharger les fichiers ?

Non, l’accessibilité ne suffit pas à établir une autorisation. La décision de 2015 invite notamment à examiner ce que la personne savait et ce qu’elle a fait après avoir compris les restrictions d’accès.

Faut-il connaître l’auteur de l’intrusion pour documenter le système ?

Non. Le dossier peut commencer par les faits techniques établis. L’identité de l’auteur et la qualification définitive peuvent rester à déterminer.

Recevez nos analyses sur la protection des données et la cybersécurité.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.