Conformité réglementaire numérique pour développeur·euses

Les 5 cadres à connaître

• RGPD (règlement UE 2016/679) : Protection des données personnelles. En application depuis 2018. Le plus connu et le plus quotidien pour un·e dev.
• RGAA / EAA : Accessibilité numérique. Le RGAA (référentiel français, version 4.1.2) opérationnalise la directive européenne EAA. Applicable aux sites publics et au secteur privé depuis juin 2025.
• NIS2 / CRA (directives UE 2022/2555 et règlement 2024/2847) : Cybersécurité. NIS2 cible les organisations des secteurs essentiels ; CRA cible les fabricants de produits numériques.
• RGESN 2024 (Référentiel Général d'Éco-conception des Services Numériques) : 78 critères pour réduire l'empreinte environnementale du numérique.
• AI Act (règlement UE 2024/1689) : Intelligence artificielle. Premier cadre juridique mondial sur l'IA, avec une approche par les niveaux de risque.

Règlement vs directive : une distinction clé

Un règlement européen (RGPD, AI Act, CRA) s'applique directement dans tous les États membres sans transposition. Une directive (NIS2, EAA) fixe des objectifs que chaque État transpose dans sa législation nationale : en France, avec un délai et parfois des spécificités locales.

À quoi ça sert pour un·e dev ?

• Ne pas ignorer une obligation qui s'applique à ton projet (et créer une dette de conformité).
• Savoir à qui parler quand un cas dépasse tes compétences : DPO pour le RGPD, RSSI pour NIS2, expert·e accessibilité pour le RGAA, DPO+RSSI pour l'AI Act.
• Traduire une exigence réglementaire en spécification technique dans ton backlog, plutôt que de la laisser au service juridique.
• Éviter le surclassement (mettre "haut risque AI Act" ou "données sensibles RGPD" sur tout) qui génère du coût sans valeur.

RGPD : responsable de traitement vs sous-traitant

• Responsable de traitement : l'entité qui détermine les finalités et les moyens du traitement de données personnelles. C'est l'entreprise qui "décide pourquoi et comment" les données sont traitées. Obligations : registre des traitements, politique de confidentialité, réponse aux droits des personnes, AIPD si nécessaire.
• Sous-traitant : l'entité qui traite des données pour le compte du responsable. Typiquement un prestataire SaaS (Stripe, Resend, SendGrid, Heroku...). Obligation principale : contrat de sous-traitance conforme art. 28 RGPD.
• Cas fréquent dev : ton entreprise est responsable de traitement pour ses propres données clients. Elle est sous-traitante si elle héberge les données d'un client B2B. Elle peut être les deux en même temps.

AI Act : fournisseur vs déployeur

• Fournisseur (provider) : celui qui développe ou fait développer un système d'IA et le met sur le marché ou le met en service sous son nom. Obligations lourdes si haut risque (art. 16 AI Act).
• Déployeur (deployer) : celui qui utilise un système d'IA sous sa propre autorité dans un cadre professionnel. Obligations plus légères (art. 26 AI Act). Utiliser l'API GPT-4o dans ton produit = déployeur.
• Cumul possible : si tu développes un modèle en interne et tu l'utilises dans tes propres produits, tu es fournisseur ET déployeur en même temps.

NIS2 : entité essentielle vs entité importante

NIS2 ne s'applique qu'à certains secteurs (énergie, transports, banques, infrastructure numérique, santé...) et selon des seuils de taille. Les entités essentielles (grands acteurs des secteurs critiques) ont des obligations plus strictes que les entités importantes. Si tu travailles dans une start-up SaaS de 20 personnes dans le secteur RH, tu n'es probablement pas concerné·e par NIS2, mais si tu travailles pour un fournisseur cloud ou une banque, tu l'es.

Ce qu'est une donnée personnelle (et ce qui surprend)

• Donnée personnelle (art. 4 RGPD) : toute information qui permet d'identifier directement ou indirectement une personne physique. Pas besoin de nom : une adresse IP, un cookie ID, une empreinte navigateur suffisent.
• Une adresse IP est une donnée personnelle : CJUE, arrêt Breyer, 2016. Tes logs applicatifs qui enregistrent les IP sont donc des traitements RGPD.
• Données sensibles (art. 9) : santé, origine ethnique, opinions politiques, données biométriques, données génétiques. Base légale plus restrictive, AIPD souvent obligatoire.
• Pseudonymisation ≠ anonymisation : remplacer un email par un hash SHA-256 = pseudonymisation (RGPD s'applique toujours). Supprimer tout lien avec la personne = anonymisation (RGPD ne s'applique plus).

Les 6 bases légales : choisir la bonne

Tout traitement de données personnelles doit reposer sur une base légale (art. 6 RGPD). Choisir la mauvaise base, c'est le traitement entier qui est illicite.

• Exécution du contrat (art. 6.1.b) : traitement nécessaire pour fournir le service que l'utilisateur a commandé. Base naturelle pour les données de commande, de compte, de livraison.
• Obligation légale (art. 6.1.c) : factures (10 ans), données pour la LCB-FT dans les banques. Pas de choix : la loi impose le traitement.
• Intérêt légitime (art. 6.1.f) : sécurité du site, prévention de la fraude, logs techniques. Nécessite un test de balance (ton intérêt ne doit pas l'emporter sur les droits de la personne).
• Consentement (art. 6.1.a) : la base la plus connue mais pas la plus utilisée. Cookies non essentiels, newsletters, profiling marketing. Le consentement doit être libre, spécifique, éclairé, univoque et révocable.
• Mission de service public (art. 6.1.e) et sauvegarde des intérêts vitaux (art. 6.1.d) : rares dans un contexte dev classique.

Minimisation et durées de conservation

• Principe de minimisation (art. 5.1.c) : ne collecter que les données strictement nécessaires à la finalité. Si tu n'as pas besoin de la date de naissance, ne la demande pas.
• Durées de conservation : les données ne peuvent pas être gardées indéfiniment. Exemples courants : données clients actifs (durée du contrat + 3 ans pour les actions commerciales), factures (10 ans comptable), logs techniques (6-12 mois recommandés CNIL), candidatures non retenues (2 ans max).
• Implémentation technique : prévoir dès la conception des jobs de purge automatique, des soft-deletes avec date d'expiration, et une traçabilité des suppressions.
• Droits des personnes : droit d'accès, rectification, effacement ("droit à l'oubli"), portabilité, opposition. Prévoir des endpoints ou des processus internes pour y répondre dans les 30 jours.

TP 2.1 — Cartographier un schéma DB et choisir les bases légales

Contexte. TalentFlow est un SaaS RH qui gère le recrutement, la paie et la formation d'entreprises clientes. Voici les tables de la base :

-- TalentFlow — schéma simplifié
CREATE TABLE employees (
  id UUID PRIMARY KEY,
  full_name TEXT NOT NULL,
  email TEXT UNIQUE NOT NULL,
  birth_date DATE,
  national_id TEXT,          -- numéro de sécu
  bank_iban TEXT,
  salary DECIMAL(10,2),
  disability_status BOOLEAN, -- RQTH
  manager_id UUID REFERENCES employees(id),
  hired_at DATE,
  created_at TIMESTAMP DEFAULT now()
);

CREATE TABLE candidates (
  id UUID PRIMARY KEY,
  full_name TEXT NOT NULL,
  email TEXT NOT NULL,
  cv_url TEXT,
  linkedin_url TEXT,
  applied_at TIMESTAMP,
  status TEXT  -- 'pending','rejected','hired'
);

CREATE TABLE training_sessions (
  id UUID PRIMARY KEY,
  employee_id UUID REFERENCES employees(id),
  course_title TEXT,
  score INTEGER,       -- note obtenue
  completed_at DATE
);

CREATE TABLE payslips (
  id UUID PRIMARY KEY,
  employee_id UUID REFERENCES employees(id),
  gross_salary DECIMAL(10,2),
  net_salary DECIMAL(10,2),
  month DATE,
  pdf_url TEXT
);

Corrigé progressif TP 2.1

TP 2.2 — Implémenter les mesures de minimisation SQL

-- Palier 3 — Squelette à compléter

-- 1. Purger les candidats rejetés de plus de 2 ans
DELETE FROM candidates
WHERE status = 'rejected'
  AND applied_at < /* À compléter */;

-- 2. Pseudonymiser les employés partis il y a plus de 5 ans
UPDATE employees
SET
  full_name  = /* hash de full_name */,
  email      = /* hash de email */,
  national_id = NULL,
  bank_iban   = NULL,
  birth_date  = NULL
WHERE /* condition sur hired_at ou date de départ */;

-- 3. Soft-delete des fiches de paie avec expiration
ALTER TABLE payslips ADD COLUMN IF NOT EXISTS deleted_at  TIMESTAMP;
ALTER TABLE payslips ADD COLUMN IF NOT EXISTS expires_at  DATE;

-- Marquer une fiche comme supprimée logiquement
UPDATE payslips
SET deleted_at = now(),
    expires_at = /* 10 ans après la date de la fiche */
WHERE id = $1;

-- Palier 4 — Solution complète commentée

-- 1. Purger les candidats rejetés de plus de 2 ans
-- Selon recommandation CNIL : 2 ans max après dernier contact
DELETE FROM candidates
WHERE status = 'rejected'
  AND applied_at < NOW() - INTERVAL '2 years';

-- 2. Pseudonymiser les employés partis il y a plus de 5 ans
-- On hache les identifiants directs, on supprime les données sensibles
-- SHA-256 est irréversible sans la donnée originale (contrairement à MD5)
UPDATE employees
SET
  full_name   = encode(digest(full_name, 'sha256'), 'hex'),
  email       = encode(digest(email, 'sha256'), 'hex'),
  national_id = NULL,   -- suppression totale, pas de besoin ultérieur
  bank_iban   = NULL,   -- idem
  birth_date  = NULL    -- idem
WHERE hired_at < NOW() - INTERVAL '5 years'
  AND manager_id IS NULL; -- ex-employés sans successeurs actifs

-- 3. Soft-delete des fiches de paie avec expiration légale
-- On ne supprime pas immédiatement (obligation comptable 10 ans)
-- On marque la date de suppression logique et la date d'expiration réelle
UPDATE payslips
SET deleted_at = NOW(),
    expires_at = (month + INTERVAL '10 years')::DATE
WHERE id = $1;

-- Job de purge physique à scheduler (ex: cron quotidien)
DELETE FROM payslips
WHERE expires_at IS NOT NULL
  AND expires_at < CURRENT_DATE;

Notification d'incident : RGPD 72h

En cas de violation de données personnelles (fuite, ransomware, accès non autorisé), le responsable de traitement doit notifier la CNIL dans les 72 heures après avoir pris connaissance de l'incident (art. 33 RGPD). Si le risque pour les personnes est élevé, il faut aussi les informer directement (art. 34). Le sous-traitant notifie son responsable de traitement sans délai.

Niveau 1 : Risque inacceptable (interdit)

Pratiques interdites sur le territoire de l'Union (art. 5). Liste limitée et précise :

• Notation sociale par les autorités publiques (pas le secteur privé)
• Manipulation subliminale ou exploitation des vulnérabilités (âge, handicap, situation économique)
• Scraping massif et indiscriminé d'images faciales sur internet
• Identification biométrique en temps réel dans l'espace public par les autorités (hors exceptions terrorisme, crimes graves)
• Reconnaissance des émotions sur le lieu de travail et dans l'éducation (hors usages médicaux/sécurité)

Niveau 2 : Haut risque (obligations strictes)

Un système est haut risque dans deux cas :

• Annexe I : composant de sécurité d'un produit déjà réglementé (dispositif médical, machine, jouet, équipement radio…). Application au 2 août 2027.
• Annexe III : usages dans des domaines sensibles. C'est ici que se jouent la majorité des cas dev :

• Biométrie : identification à distance, catégorisation, reconnaissance d'émotions
• Infrastructures critiques : trafic routier, eau, gaz, électricité
• Éducation : admission, évaluation des résultats, surveillance d'examens
• Emploi et RH : tri des CV, évaluation des candidats, surveillance des employés, décisions de licenciement
• Accès aux services essentiels : scoring de crédit, prestations sociales, assurance santé/vie
• Application du droit : profilage par les autorités
• Migration, asile, contrôle des frontières
• Administration de la justice

Si ton système entre dans ces catégories, il déclenche un ensemble d'obligations lourdes (documentation technique, gestion des risques, contrôle humain, journalisation, marquage CE, enregistrement dans la base UE…). Les obligations diffèrent selon que tu es fournisseur (art. 16) ou déployeur (art. 26).

Niveau 3 : Risque limité (transparence obligatoire)

Ni interdit ni haut risque, mais obligation d'information (art. 50). Quatre cas :

• Chatbots : informer clairement que l'utilisateur interagit avec une IA
• Deepfakes : indiquer quand un contenu audio/vidéo a été manipulé pour ressembler à des personnes réelles
• Reconnaissance des émotions ou catégorisation biométrique : informer les personnes exposées
• Contenu généré par IA (texte, image, audio, vidéo) : marquage technique permettant la détection (watermarking)

Niveau 4 : Risque minimal (libre)

Tout ce qui ne tombe pas dans les trois catégories précédentes. Exemples : filtres anti-spam, recommandations de produits standard, IA dans les jeux vidéo, optimisation interne de tri. Pas d'obligation spécifique AI Act, mais le RGPD s'applique toujours si données personnelles.

L'arbre de décision

[Système d'IA à classer]
          │
          ▼
┌──────────────────────────────────┐
│ 1. Pratique interdite (art. 5) ? │
└──────────────┬───────────────────┘
               │
        ┌──────┴──────┐
        OUI          NON
         │            │
         ▼            ▼
    INACCEPTABLE   ┌──────────────────────────────┐
    → interdit     │ 2. Cas annexe I ou III ?      │
                   └──────────────┬───────────────┘
                                  │
                           ┌──────┴──────┐
                           OUI          NON
                            │            │
                            ▼            ▼
                       HAUT RISQUE  ┌───────────────────────────┐
                       → art. 16/26 │ 3. Cas art. 50 ?          │
                                    │  (chatbot, deepfake,       │
                                    │   contenu généré…)        │
                                    └──────────────┬────────────┘
                                                   │
                                            ┌──────┴──────┐
                                            OUI          NON
                                             │            │
                                             ▼            ▼
                                      RISQUE LIMITÉ   RISQUE MINIMAL
                                      → transparence  → bonnes pratiques

Étape 1 : Tester les pratiques interdites (art. 5)

Lis l'art. 5. Si une pratique interdite s'applique, c'est terminé : système interdit, tu remontes l'alerte. En pratique, dans la grande majorité des cas dev courants, cette étape est négative.

Étape 2 : Tester le haut risque (annexe I et III)

Deux questions :

• Le système est-il un composant de sécurité d'un produit listé en annexe I ?
• Le système est-il utilisé dans un cas listé à l'annexe III ? (lire attentivement la formulation : elle est précise)

Étape 3 : Tester la transparence (art. 50)

Quatre cas principaux : interaction humain/chatbot → information explicite ; deepfake ou contenu manipulé → marquage ; reconnaissance d'émotions ou classification biométrique → information ; contenu synthétique généré → watermarking technique.

Étape 4 : Risque minimal par défaut

Si rien ne s'applique : risque minimal. Pas d'obligation AI Act stricte. Revérifie quand même le RGPD si données personnelles impliquées.

Exemple pas-à-pas : chatbot GPT-4o

1. Art. 5 interdit ? Non : pas de notation sociale par autorité, pas de manipulation subliminale. → Non inacceptable.
2. Annexe III haut risque ? Non : "support client" n'est pas listé. → Non haut risque.
3. Art. 50 ? Oui : "système destiné à interagir directement avec des personnes physiques". → Obligation d'information.
4. Conclusion : risque limité. Obligation : informer clairement l'utilisateur qu'il parle à une IA.

Exemple pas-à-pas : scoring de candidats RH

1. Art. 5 interdit ? Non : la notation sociale interdite vise les autorités publiques, pas le secteur privé.
2. Annexe III haut risque ? Oui : point 4.a : "emploi, gestion des travailleurs, accès à l'emploi indépendant : systèmes destinés à être utilisés pour le recrutement ou la sélection de personnes physiques". → Haut risque.
3. Conclusion : haut risque. Obligations lourdes (documentation, contrôle humain, journalisation…). Et AIPD RGPD obligatoire en plus.

Les 4 pièges classiques de classification

• Piège du surclassement : "Dans le doute, on met haut risque." Mauvaise idée. Le haut risque a un coût de conformité significatif. Classer factuellement, documenter le raisonnement.
• Piège du sous-classement : "C'est juste un algo d'aide à la décision." Si l'output influence significativement une décision sur une personne (recrutement, crédit), tu es haut risque : même si la décision finale est humaine.
• Confusion fournisseur/déployeur : utiliser l'API GPT-4o = déployeur (art. 26), pas fournisseur (art. 16). Obligations très différentes. Si tu fine-tunes et redistribues, tu deviens fournisseur.
• Oublier l'articulation RGPD : haut risque AI Act + données personnelles = AIPD RGPD obligatoire (art. 35 RGPD). Et art. 22 RGPD si décision individuelle automatisée (droits spécifiques : intervention humaine, contestation, explication).

Le cadre réglementaire : RGAA, EAA, WCAG

• WCAG 2.1 niveau AA : norme internationale de référence (W3C). 78 critères de succès organisés en 4 principes : Perceptible, Utilisable, Compréhensible, Robuste.
• RGAA 4.1.2 : référentiel français qui opérationnalise les WCAG en 106 critères vérifiables. C'est le texte de référence pour les obligations françaises.
• EN 301 549 : norme européenne qui harmonise les exigences d'accessibilité. L'EAA l'utilise comme référence technique.
• EAA (directive 2019/882) : transposée en France par décret 2023-931. Depuis le 28 juin 2025, les entreprises privées qui commercialisent des produits et services numériques aux consommateurs en Europe sont soumises à des obligations d'accessibilité : y compris les PME sous certaines conditions.

Auditer avec les outils automatisés

Les outils automatisés détectent environ 20% des non-conformités RGAA au maximum. Indispensables mais très insuffisants : les 80% restants nécessitent un test manuel et un test au lecteur d'écran.

• Lighthouse (intégré dans Chrome DevTools → onglet Lighthouse) : audit automatique, donne un score 0-100 et liste les erreurs. Pratique pour un premier état des lieux.
• axe DevTools (extension Chrome/Firefox) : plus précis que Lighthouse sur l'accessibilité, indique les violations avec leur impact (critical, serious, moderate, minor).
• WAVE (extension ou wave.webaim.org) : visualise les problèmes directement sur la page avec des icônes. Très lisible pour montrer les erreurs à un·e client·e.
• Colour Contrast Analyser : vérifier les ratios de contraste (niveau AA : 4.5:1 pour le texte normal, 3:1 pour le grand texte et les éléments non-textuels).

Test manuel indispensable : la navigation clavier

• Tab : passer d'un élément interactif au suivant. Tous les liens, boutons, champs et contrôles doivent être atteignables au clavier.
• Shift+Tab : revenir en arrière. L'ordre de focus doit être logique (correspondre à l'ordre visuel).
• Entrée / Espace : activer un bouton ou lien. Un composant custom (div cliquable) doit répondre aux mêmes touches.
• Focus visible : le composant actif doit avoir un indicateur visuel clair. Ne jamais écrire outline: none sans le remplacer par un style de focus custom.
• Pas de piège clavier : il doit toujours être possible de quitter un composant (modale, menu déroulant) avec Échap ou Tab.

Les corrections les plus fréquentes

• Images sans alternative textuelle : tout <img> doit avoir un attribut alt. Si l'image est décorative : alt="". Si elle porte du sens : alt="description précise".
• Formulaires sans labels : chaque champ doit avoir un <label for="id-du-champ"> associé : pas juste un placeholder (il disparaît à la saisie).
• Contrastes insuffisants : texte gris clair sur fond blanc, texte blanc sur fond bleu clair : les combinaisons pièges. Vérifier systématiquement avec le Colour Contrast Analyser.
• Titres non hiérarchiques : la structure des <h1> à <h6> doit être logique et ne pas sauter de niveaux. Un <h3> ne peut pas être le premier titre de page.
• ARIA mal utilisé : ajouter role="button" sur une <div> sans gérer le focus, les événements clavier et tabindex="0" = problème. Règle : utiliser d'abord les éléments HTML natifs (<button>, <a>), ARIA en dernier recours.
• Liens génériques : "Cliquez ici" ou "En savoir plus" sans contexte sont incompréhensibles pour un lecteur d'écran. Le texte du lien doit décrire la destination.

Intégrer axe dans la CI : ne pas attendre la livraison

Lancer axe manuellement avant chaque commit est utile. L'intégrer dans la CI (GitHub Actions, GitLab CI…) est indispensable : ça bloque la PR si une violation critique est introduite, sans dépendre de la vigilance de chacun·e.

# .github/workflows/accessibility.yml
name: Accessibility CI

on: [push, pull_request]

jobs:
  axe:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: npm ci

      - name: Build
        run: npm run build

      - name: Start server
        run: npm start &
        env:
          PORT: 3000

      - name: Wait for server
        run: npx wait-on http://localhost:3000

      - name: Run axe accessibility tests
        uses: cypress-io/github-action@v6
        with:
          command: npx axe http://localhost:3000 --exit

Pour une intégration plus fine dans les tests Playwright ou Cypress :

// tests/accessibility.spec.ts (Playwright)
import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("home page has no critical accessibility violations", async ({ page }) => {
  await page.goto("/");

  const results = await new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa"])  // RGAA niveau A et AA
    .analyze();

  // Affiche les violations dans le rapport de test
  expect(results.violations).toEqual([]);
});

TP 4.1 — Auditer un composant HTML avec axe DevTools

<!-- formulaire-contact.html — à auditer -->
<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Contact</title>
  <style>
    .btn { background: #aaa; color: #bbb; padding: 8px 16px; border: none; }
    input { outline: none; }
  </style>
</head>
<body>
  <img src="logo.png">

  <div onclick="openMenu()" style="cursor:pointer">Menu</div>

  <form>
    <input type="text" placeholder="Votre nom">
    <input type="email" placeholder="Votre email">
    <textarea placeholder="Votre message"></textarea>
    <button class="btn">Envoyer</button>
  </form>

  <a href="/mentions">En savoir plus</a>
  <a href="/confidentialite">En savoir plus</a>
</body>
</html>

TP 4.2 — Corriger les non-conformités dans le code

<!DOCTYPE html>
<html lang="fr">
<head>
  <meta charset="UTF-8">
  <title>Contact — FormTech</title>
  <style>
    /* Contraste AA : #1a1a1a sur #4a7c59 = ratio 5.2:1 */
    .btn { background: #4a7c59; color: #ffffff; padding: 8px 16px; border: none; cursor: pointer; }
    .btn:focus { outline: 2px solid #1a1a1a; outline-offset: 2px; }

    /* Focus visible sur tous les éléments interactifs */
    input:focus, textarea:focus { outline: 2px solid #4a7c59; outline-offset: 2px; }

    /* Masquage accessible des labels si besoin visuel */
    label { display: block; margin-bottom: 4px; font-weight: 600; }
  </style>
</head>
<body>
  <!-- RGAA 1.1 : alt présent et descriptif -->
  <img src="logo.png" alt="Logo FormTech">

  <!-- RGAA 7.1 : bouton natif plutôt que div cliquable -->
  <button type="button" aria-expanded="false" aria-controls="main-menu">
    Menu
  </button>
  <nav id="main-menu" hidden><!-- contenu du menu --></nav>

  <form>
    <!-- RGAA 11.1 : label explicitement associé à chaque champ -->
    <label for="nom">Votre nom</label>
    <input type="text" id="nom" name="nom" autocomplete="name">

    <label for="email">Votre email</label>
    <input type="email" id="email" name="email" autocomplete="email">

    <label for="message">Votre message</label>
    <textarea id="message" name="message"></textarea>

    <!-- RGAA 3.3 : contraste corrigé -->
    <button type="submit" class="btn">Envoyer</button>
  </form>

  <!-- RGAA 6.1 : intitulés de liens descriptifs et distincts -->
  <a href="/mentions">Mentions légales</a>
  <a href="/confidentialite">Politique de confidentialité</a>
</body>
</html>

OWASP Top 10 simplifié : les 5 failles à connaître en priorité

• A01 : Broken Access Control (numéro 1 depuis 2021) : un utilisateur accède à des données ou des fonctions auxquelles il ne devrait pas avoir accès. Exemples : IDOR (Insecure Direct Object Reference) en modifiant un ID dans l'URL, accès à des routes admin sans vérification de rôle. Correction : vérifier les droits côté serveur à chaque requête, ne pas faire confiance aux paramètres côté client.
• A02 : Cryptographic Failures : données sensibles transmises ou stockées sans chiffrement adéquat. Exemples : mots de passe en MD5 ou SHA-1, cookies de session sans flag Secure et HttpOnly, données personnelles en clair dans la base. Correction : bcrypt/Argon2 pour les mots de passe, TLS partout, chiffrement au repos pour les données sensibles.
• A03 : Injection : données non fiables interprétées comme du code. SQL injection, LDAP injection, commandes shell. Correction : requêtes paramétrées (prepared statements), jamais de concaténation de chaîne avec des inputs utilisateurs.
• A05 : Security Misconfiguration : configuration par défaut non sécurisée, headers HTTP manquants, comptes de debug actifs en prod. Correction : désactiver ce qui n'est pas utilisé, configurer Content-Security-Policy, X-Frame-Options, Referrer-Policy, supprimer les routes de debug.
• A06 : Vulnerable and Outdated Components : dépendances npm/pip/maven avec vulnérabilités connues. Correction : npm audit en CI, Dependabot, politique de mise à jour régulière.

NIS2 : qui est concerné et quelles obligations

• Périmètre : NIS2 s'applique aux organisations des secteurs listés aux annexes I et II (énergie, transports, banques, infrastructure numérique, santé, eau, services numériques...). Deux seuils : entités essentielles (grandes organisations des secteurs critiques) et entités importantes (taille intermédiaire ou secteurs moins critiques).
• Les 10 mesures obligatoires (art. 21) : politiques de sécurité, gestion des incidents, continuité d'activité, sécurité de la chaîne d'approvisionnement, acquisition et maintenance sécurisées des systèmes, évaluation des mesures, formation, cryptographie, sécurité des ressources humaines, authentification multi-facteur.
• Transposition française : la loi Résilience est attendue pour 2026. L'ANSSI publie le ReCyF (Référentiel Cyber France) comme guide opérationnel.

Notification d'incident : qui notifie quoi, quand, à qui

Incident détecté
      │
      ▼
┌─────────────────────────────────────────┐
│ Des données personnelles sont exposées ? │
└──────────────┬──────────────────────────┘
               │
        ┌──────┴──────┐
        OUI          NON
         │            │
         ▼            │
  CNIL dans les 72h   │
  (art. 33 RGPD)      │
  Si risque élevé :   │
  informer les        │
  personnes (art. 34) │
               │      │
               └──────┘
                      │
                      ▼
      ┌───────────────────────────────────┐
      │ Entité NIS2 (essentielle ou       │
      │ importante) ?                     │
      └───────────────┬───────────────────┘
                      │
               ┌──────┴──────┐
               OUI          NON
                │            │
                ▼            ▼
        CSIRT dans 24h    Pas d'obligation
        (alerte préliminaire)  NIS2
        + 72h (notification)
        + 1 mois (rapport final)
                │
                ▼
      ┌───────────────────────────────────┐
      │ Vulnérabilité dans un produit     │
      │ commercialisé couvert par le CRA ?│
      └───────────────┬───────────────────┘
                      │
               ┌──────┴──────┐
               OUI          NON
                │
                ▼
        ENISA dans 24h
        + 72h (notification)
        + 14 jours (rapport)

Récapitulatif des délais

• RGPD : violation de données personnelles : CNIL dans les 72h (art. 33). Personnes concernées si risque élevé (art. 34) : sans délai injustifié.
• NIS2 : incident significatif : CSIRT dans les 24h (alerte préliminaire), puis 72h (notification complète), puis 1 mois (rapport final).
• CRA : vulnérabilité activement exploitée : ENISA dans les 24h (early warning), puis 72h (notification), puis 14 jours (rapport complet).

TP 5.1 — Analyser un endpoint API et construire l'arbre de notification

// Partie A — endpoint Node.js/Express à auditer
// Contexte : API de gestion de commandes e-commerce

app.get("/orders/:orderId", async (req, res) => {
  const { orderId } = req.params;

  // Récupérer la commande
  const query = `SELECT * FROM orders WHERE id = ${orderId}`;
  const result = await db.query(query);

  if (!result.rows.length) {
    return res.status(404).send("Not found");
  }

  const order = result.rows[0];

  // Log pour débogage en prod
  console.log("Order fetched:", JSON.stringify(order));

  return res.json(order);
});

app.post("/orders", async (req, res) => {
  const { userId, items, promoCode } = req.body;

  // Vérifier le code promo
  const promo = await db.query(
    `SELECT * FROM promos WHERE code = '${promoCode}'`
  );

  // Créer la commande (tous les utilisateurs peuvent créer pour n'importe quel userId)
  await db.query(
    "INSERT INTO orders (user_id, items, promo_id) VALUES ($1, $2, $3)",
    [userId, JSON.stringify(items), promo.rows[0]?.id]
  );

  res.status(201).json({ success: true });
});

Le cadre : loi REEN et RGESN 2024

• Loi REEN (2021) : Réduction de l'Empreinte Environnementale du Numérique. L'art. 25 impose une déclaration d'écoconception pour les services publics numériques : pas encore pour le privé, mais c'est la direction réglementaire.
• RGESN 2024 : publié par l'ARCEP le 17 mai 2024. 78 critères organisés en 8 thématiques. 3 niveaux de priorité (haute, moyenne, basse). C'est le texte opérationnel de référence en France.
• Eco Index (GreenIT.fr) : outil d'évaluation de l'empreinte d'une page web. Donne une note A-G similaire aux étiquettes énergétiques.

Les 5 leviers techniques prioritaires

• Optimisation des médias : les images et vidéos représentent 70-80% du poids d'une page. Utiliser WebP/AVIF plutôt que JPEG/PNG, dimensionner les images à la taille d'affichage réelle, lazy loading (loading="lazy"), éviter l'autoplay vidéo.
• Minimisation des requêtes réseau : chaque requête HTTP a un coût énergétique. Regrouper les ressources, utiliser le cache efficacement (Cache-Control, ETag), supprimer les trackers et analytics non essentiels.
• Sobriété fonctionnelle : la fonctionnalité la plus sobre est celle qu'on ne développe pas. Challenger chaque feature : est-ce vraiment utilisé ? Le RGESN encourage à mesurer l'utilisation réelle avant de maintenir.
• Terminaux supportés : supporter les navigateurs et appareils anciens pendant longtemps permet de prolonger la durée de vie du matériel. Évaluer les impacts de la dette technique sous cet angle.
• Polices web : les custom fonts ont un coût de chargement. font-display: swap, sous-ensembles (subsetting), préférer les polices système quand c'est possible.

Analyse du cycle de vie simplifiée (ACV)

L'ACV d'un service numérique identifie les phases les plus impactantes : fabrication des terminaux (représente souvent 70-80% de l'impact total sur la durée de vie), utilisation côté utilisateur (terminal, réseau), utilisation côté serveur (datacenter). Cette hiérarchie a une implication pratique : prolonger la durée de vie des terminaux (en supportant les appareils anciens) est souvent plus impactant que d'optimiser ton serveur.

TP 6.1 — Appliquer les leviers RGESN à une page fictive

<!-- page-accueil.html — à auditer RGESN -->
<!DOCTYPE html>
<html>
<head>
  <!-- 3 polices Google Fonts chargées -->
  <link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Roboto:wght@100;300;400;500;700;900&family=Open+Sans:wght@300;400;600;700&family=Lato:wght@300;400;700&display=block">

  <!-- Tag manager + analytics + chatbot -->
  <script src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXX"></script>
  <script src="https://analytics.example.com/tracker.js"></script>
  <script src="https://cdn.chatbot.io/widget.js"></script>
  <script src="https://cdn.ab-testing.io/sdk.js"></script>
</head>
<body>
  <!-- Hero avec vidéo en autoplay -->
  <video autoplay loop muted playsinline>
    <source src="hero-video-4k.mp4" type="video/mp4">
  </video>

  <!-- 12 images JPEG non optimisées, chargées toutes en même temps -->
  <div class="gallery">
    <img src="photo-team-1-original.jpg" width="1920" height="1080" style="width:300px">
    <img src="photo-team-2-original.jpg" width="1920" height="1080" style="width:300px">
    <!-- ... 10 autres images identiques ... -->
  </div>

  <!-- Carrousel qui précharge 20 slides en mémoire -->
  <div id="testimonials"></div>
  <script>
    // Fetch de 20 témoignages au chargement, même si l'utilisateur ne scrolle pas
    fetch('/api/testimonials?limit=20').then(r => r.json()).then(renderAll);
  </script>
</body>
</html>

La méthode d'audit multi-cadre

1. Cartographier le produit : type de données traitées, fonctionnalités IA, public cible, secteur d'activité, taille de l'entreprise. Cette fiche de départ détermine quels cadres s'appliquent.
2. Appliquer les critères d'entrée de chaque cadre : RGPD (données personnelles ?), EAA (produit/service numérique au public ?), NIS2 (secteur critique ? seuils de taille ?), AI Act (système d'IA ? quel niveau de risque ?), RGESN (service public ? ou démarche volontaire ?).
3. Pour chaque cadre applicable, lister les obligations par rôle (responsable de traitement, déployeur AI…). Ne pas chercher l'exhaustivité : identifier les 5-10 obligations majeures de chaque cadre.
4. Prioriser par risque : occurrence × impact × niveau de sanction. Une faille RGPD sur des données de santé (données sensibles, AIPD obligatoire) prime sur un contraste insuffisant en RGAA (important mais moins sanctionné).
5. Produire un plan de mise en conformité : 3 colonnes : obligation, action technique, délai. Classer par priorité. Inclure les hypothèses faites et les points à valider avec le DPO/RSSI.

Grille d'audit type

## Audit de conformité : [Nom du produit]
**Date** : [date]  **Auditeur·rice** : [nom]

### 1. Identité du produit
- Type : [e-commerce / SaaS B2B / app mobile / site vitrine...]
- Données traitées : [personnelles ? sensibles ? financières ?]
- Fonctions IA : [oui/non : description]
- Public : [B2C / B2B / service public]
- Entreprise : [taille, secteur]

### 2. Cadres applicables
| Cadre | Applicable | Raison |
|-------|-----------|--------|
| RGPD  | OUI       | traite des données personnelles |
| EAA   | OUI       | produit numérique au public, >10 sal. |
| NIS2  | NON       | secteur non listé en annexe I/II |
| AI Act| OUI       | moteur de recommandation (risque limité) |
| RGESN | VOL.      | démarche volontaire |

### 3. Non-conformités identifiées
| Priorité | Cadre | Obligation | Non-conformité | Action | Délai |
|----------|-------|-----------|----------------|--------|-------|
| CRITIQUE | RGPD  | Art. 13-14 | Aucune politique de confidentialité | Rédiger + publier | 2 semaines |
| HAUTE    | RGPD  | Art. 6 | Base légale cookies analytics non documentée | Audit + DPA si besoin | 1 mois |
| HAUTE    | EAA   | RGAA A | Images sans alt sur 12 produits | Ajouter alt programmatiquement | 1 semaine |
| MOYENNE  | AI Act| Art. 50 §1 | Chatbot sans mention "assistant IA" | Modifier UI | 3 jours |
| BASSE    | RGESN | 4.x | Images JPEG non convertis en WebP | Config build | 1 semaine |

### 4. Hypothèses et points à valider
- [ ] Vérifier avec le DPO si l'AIPD est requise pour le moteur de reco
- [ ] Confirmer la base légale retenue pour les analytics avec le DPO
- [ ] Vérifier si l'entreprise dépasse les seuils NIS2 pour les services cloud

Les articulations à ne pas manquer

• Haut risque AI Act + données personnelles → AIPD RGPD obligatoire. Les deux s'appliquent en même temps. Le DPO doit être impliqué.
• Incident de sécurité → RGPD art. 33 + potentiellement NIS2. Créer un arbre de décision interne avant que l'incident arrive (voir chapitre Cybersécurité).
• RGAA + RGPD sur les formulaires : un formulaire doit être accessible ET gérer correctement le consentement pour les données collectées.
• RGESN + RGPD sur les données d'usage : les analytics qu'on voudrait garder pour améliorer l'éco-conception sont eux-mêmes des données personnelles sous RGPD. Trouver la base légale et minimiser.

TP 7.1 — Audit multi-cadre : MediConnect SaaS

Contexte — MediConnect SaaS. Une startup française (18 salariés, 3,2 M€ de CA) édite une plateforme web de gestion de dossiers médicaux pour des cabinets de médecins généralistes. La plateforme :

• Stocke les dossiers patients : nom, prénom, date de naissance, numéro de sécu, antécédents médicaux, ordonnances
• Intègre un module IA qui analyse les symptômes saisis par le médecin et propose un diagnostic différentiel
• Est accessible via une interface web publique (compte médecin requis)
• Utilise Google Analytics et un chatbot IA de support client
• A subi une fuite de données il y a 6 mois (200 dossiers exposés, notifiée à la CNIL)