Le bon de livraison
Le livreur a besoin du nom, de l'adresse et d'un numéro pour appeler. Il n'a pas besoin du numéro de CIN ni de l'historique des achats. On imprime seulement ce qui lui sert.
M08 · B. Assurer la confidentialité des données
Protéger les données des utilisateurs dans l'application
Les règles concrètes de protection des données utilisateurs dans le code - ne renvoyer que les champs utiles, masquer, pseudonymiser, ne jamais journaliser de secrets, limiter la conservation - et ce que l'obfuscation du code source protège... ou ne protège pas.
1Situer
La loi dit quoi protéger ; le code dit comment. Une API qui renvoie un SELECT * entier, un fichier journal qui garde les mots de passe tapés, un numéro de téléphone affiché en clair sur un bon de livraison : ce sont les fuites les plus fréquentes, et elles se corrigent en quelques lignes.
2Comprendre
Dans la base, la ligne d'une cliente contient tout : nom, téléphone, CIN, hachage du mot de passe.
1 / 4
Les règles de protection dans le code
Les règles qui reviennent dans tous les projets :
- Minimiser : ne collecter et ne stocker que ce qui sert (leçon B.1).
- Ne renvoyer que les champs utiles : listes de colonnes explicites, objets de réponse construits à la main.
- Masquer à l’affichage :
06******78,**** 4821. - Pseudonymiser pour les statistiques et les tests : remplacer les noms par des identifiants.
- Protéger les secrets : mots de passe hachés, données sensibles chiffrées (leçon B.4), clés hors du code.
- Ne jamais journaliser de secrets.
- Limiter la conservation : purges et anonymisation automatiques.
- Copies de travail : jamais la vraie base clients sur le PC d’un développeur ou dans un environnement de test.
L’obfuscation du code source
// avant
function prixTTC(prix) { return prix * 1.2; }
// après obfuscation (exemple)
var _0x1a=function(_0x2b){return _0x2b*0x6/0x5;};
L’obfuscation protège un peu la propriété intellectuelle (rendre la copie d’un algorithme plus coûteuse). Elle ne protège pas un secret : le navigateur doit exécuter le code, donc on peut toujours l’observer, le dérouler et lire ce qu’il envoie dans l’onglet Réseau.
Le ticket de carte bancaire
Sur le ticket de caisse, le numéro de carte apparaît sous la forme **** **** **** 4821 : assez pour que le client reconnaisse sa carte, trop peu pour qu'un voleur s'en serve. C'est le masquage.
Publicité
3Manipuler
L'API du compte client renvoie trop d'informations et la page de connexion garde les mots de passe dans son journal. Corrigez les deux (compte d'essai : amina.benali@mail.ma / Atlas2025).
La page s'affichera ici.
Le navigateur demandera /api/client.php?id=1 au serveur, qui exécutera le PHP et renverra du HTML.
Entre le navigateur et le serveur aucun échange pour l'instant
Consignes 0 / 3
- L'API ne renvoie plus le hachage du mot de passe ni la CIN
- Le téléphone est masqué : 06******78
- Le journal garde l'e-mail et le résultat, jamais le mot de passe
4Pratiquer
Exercice 1 · Masquer un e-mail
Écrivez masquerEmail('amina.benali@mail.ma') qui renvoie 'a***********@mail.ma' (première lettre, des étoiles, puis le domaine).
Voir le corrigé
<?php function masquerEmail(string $email): string { [$nom, $domaine] = explode('@', $email, 2) + [1 => '']; return mb_substr($nom, 0, 1) . str_repeat('*', max(mb_strlen($nom) - 1, 0)) . '@' . $domaine; } echo masquerEmail('amina.benali@mail.ma'); // a***********@mail.ma
Exercice 2 · Purger les vieux comptes
Les comptes sans aucune commande depuis 3 ans doivent être anonymisés (prénom « Ancien », nom « client », e-mail et téléphone vidés). Écrivez la requête SQL.
Voir le corrigé
UPDATE clients SET prenom = 'Ancien', nom = 'client', email = NULL WHERE date_inscription < CURDATE() - INTERVAL 3 YEAR AND id NOT IN ( SELECT client_id FROM commandes WHERE date_commande >= CURDATE() - INTERVAL 3 YEAR );
Publicité