Article d'utilité publique

Introduction

En liminaire, nous vous invitons à consulter notre politique de gestion des cookies qui relate, de manière accessible à tous, l’enjeu des cookies dans le cadre du Règlement Général sur la Protection des Données (Rgpd). Celle-ci, accompagnée de cet article, vous aidera à mieux appréhender l'envers des subtilités sur un sujet législatif des plus importants dans l'univers des produits numériques.

Aussi, certains termes ou abréviations étant déjà définis dans notre politique, nous ne les répéterons pas ici.

Nous souhaitons faire de cet article un modèle de réflexion à automatiser dans vos processus de développement numérique, que vous soyez simplement développeur en apprentissage (nous sommes tous en éternel apprentissage !) ou garant de la mise en place d’un produit numérique. Ce "guide" est également parfaitement accessible à un public non averti et désireux de découvrir cet univers.

Chez PureKréa, nous respectons nos utilisateurs. Soucieux d’un web plus sain et moins intrusif sur la vie privée, nous nous efforçons d’appliquer le Rgpd dans une logique de terrain, et non de manière purement théorique ou juridique.

Sécurité VS conformité

En tant que développeurs, nous cherchons à sécuriser nos sites et applications web, généralement avec les meilleurs outils disponibles. Pourtant, dans un contexte européen, les outils nous permettant de mettre en application ces protections se heurtent bien souvent au Rgpd, notamment lorsqu’ils impliquent des services provenant d’autres pays (on parle couramment de "services tiers" dans le jargon pour désigner tout service ou produit externe, c’est-à-dire qui ne nous appartient pas directement, mais auquel nous faisons appel).

En fonction des priorités techniques, nous sommes forcés de nous engager dans une voie plutôt qu’une autre, d'utiliser des services plutôt que d'autres, et, à ce stade, que tout coïncide miraculeusement avec la sécurité, l’expérience utilisateur et la conformité juridique, cela relève du miracle. Simplement parce que chaque outil lié à la sécurité a ses avantages et son lot d’inconvénients.

Si nous visons une sécurité maximale (ce qui revient souvent à "sur-sécuriser" plus qu’autre chose), nous nous heurterons sans attendre aux contraintes tarifaires, qui montent relativement vite, ainsi qu’à certaines contraintes propres au Rgpd.

Si nous visons le côté économique, nous trouverons facilement des solutions gratuites, mais elles se heurteront fortement aux contraintes de Rgpd, principalement parce que les produits gratuits existants, efficaces à la fois en termes d’installation et de fonction, sont en majorité américains.

Ce paradoxe est rencontré dans la carrière d'absolument tous les développeurs soucieux de fournir un travail excellent. Cela engendre de la frustration, de la tension, qu'il faut savoir gérer, parce que nous nous "frottons" ici à la frontière de ce qui est légal ou non sur un territoire.

Oui, encore aujourd’hui, les États-Unis dominent le marché en ce qui concerne la sécurisation des infrastructures web. Les Américains offrent des produits en plus grand nombre, simples à implémenter, plus robustes, bien documentés, mais leur inconvénient est qu’ils collectent généralement des données personnelles.

Entendons-nous bien : la grande majorité des produits proposés au public, peu importe leur origine, collecte des données personnelles. L’adresse IP, par exemple, est généralement requise pour assurer un minimum de sécurité. Mais le fait qu’ils soient hors du territoire européen est une première contrainte pour un développeur, car cette collecte de données hors de l'Union Européenne implique dans certains cas le consentement explicite de l’utilisateur – ce qu’on veut, dans l’idéal, éviter d’avoir à faire pour maximiser l’expérience utilisateur.

L’intérêt légitime comme levier ?

Le Rgpd prévoit une exception : si les données sont collectées uniquement à des fins de sécurité (pour prévenir les attaques par exemple), le traitement peut être fondé sur l’intérêt légitime, et donc nous n'avons pas besoin du consentement de l'utilisateur.

Mais là encore, cette subtilité n’est pas si "binaire", et est à prendre avec des pincettes, car si l’exemption de consentement est bien là pour ce motif, le simple fait que vous fassiez appel à des services tiers pour ces traitements, fait que vous faites appel à un "sous-traitant". Et cela déclenche une série d’obligations.

Même dans un but strictement sécuritaire, vous devez signer une sorte de "contrat de sous-traitance" que l’on nomme couramment, un Data Processing Agreement, ou "Addendum" (Dpa).

Ce Dpa est un document cadré juridiquement parlant. Il doit comprendre des informations clés et évidentes, telles que :

• l’objet du traitement ;
• la nature des données concernées ;
• la durée de conservation ;
• les obligations du sous-traitant en matière de sécurité, confidentialité, etc.

Et si ce sous-traitant est basé hors de l'Union Européenne, ce document doit être suivi des Standard Contractual Clauses (Scc), qui sont un autre document juridique comprenant un ensemble de clauses types approuvées par la Commission Européenne. Ces clauses permettent d’encadrer légalement le transfert de données personnelles vers des pays en dehors de l’Union Européenne.

Le problème, c’est que les services gratuits, pourtant largement utilisés, ne proposent pas toujours ces contrats. Et même lorsqu’ils existent, ils sont parfois inaccessibles, incomplets, ou conditionnés à une version payante.

Par exemple, du côté des solutions "anti-spam", certains outils sont réputés comme étant "Rgpd-friendly", en ce sens qu'ils collectent peu d'informations personnelles. Nous avons hCaptcha, mais il s'agit d'un produit américain, or, l'enseigne ne propose pas de Dpa pour les versions gratuites. Il y a également Friendly Captcha, une solution européenne mais dont la version gratuite et le premier tarif (9€ – tarifs 2025) sont extrêmement limités (jusqu'à 1000 requêtes par mois), ce qui le rend complexe d'utilisation dans la réalité pratique d'un site générant un minimum de trafic. C'est à partir de 39€ par mois (tarifs 2025) que nous pouvons avoir une solution offrant jusqu'à 5000 requêtes par mois, ce qui là encore, est rapidement atteint.

Aussi, attention : l'intérêt légitime est bien un levier, et non une carte blanche. Comme expliqué au début de ce chapitre, ce fondement n’est pas automatique, et encore moins inattaquable. Il repose sur un équilibre entre votre intérêt en tant que responsable de traitement, et les droits et libertés fondamentaux de la personne concernée.

Sommes-nous condamnés à payer ?

Ça dépend. Et c’est ici que PureKréa souhaite intervenir, car une confusion persistante s’installe, entretenue par un mélange de peur juridique et de mésinformation.

Aujourd’hui, deux grandes croyances circulent à propos du Rgpd :

• "Si je ne sécurise pas assez, je risque une amende"
• "Si je sur-sécurise avec des services américains, je suis aussi en faute"

Autrement dit, nous avons la sensation d'être coincés et d'être en faute quoi que l'on fasse.

Peut-être aussi que vous avez la volonté de faire les choses de manière respectueuse vis-à-vis de vos utilisateurs, et que vous avez la sensation de "trahir" votre culture d'entreprise en faisant usage des dispositifs réglementaires, un peu comme si, quelque part, devoir les utiliser était un "moindre mal" plutôt qu'une solution.

Mais c'est faux. Le Rgpd n'est pas un piège, c'est un cadre. Et dites-vous bien que si des solutions réglementaires existent pour utiliser des services tiers, c’est bien parce que le Rgpd a été conçu en tenant compte des réalités du développement numérique. Autrement, nous nous isolerions et nous ne serions pas compétitifs.

Quand l’intérêt légitime est-il vraiment valable ?

Pour être certain de faire usage de l'intérêt légitime de la bonne manière, la Commission Nationale de l'Informatique et des Libertés (Cnil) recommande d'effectuer un "balancing test" constitué de trois étapes qui doivent être réunies. Ce test sert à mesurer la proportionnalité entre la finalité et l’impact de l'objectif voulu :

1) L’intérêt poursuivi est-il légitime ?

Un intérêt est considéré comme légitime s’il est :

• Licite (autorisé par la loi, non discriminatoire, etc.) ;
• Clair et bien défini (sert à sécuriser un formulaire, détecter un abus, éviter un spam massif) ;
• Réel, c’est-à-dire qu’il répond à un besoin concret, et non hypothétique.

Exemples proportionnés :

• Prévention des attaques (DDoS (c'est une attaque qui vise à rendre un site web inaccessible en l'inondant de requêtes), force brute (c'est le fait de tenter des milliers, voire des millions de combinaisons par seconde dans le but de trouver un mot de passe)) ;
• Protection d’un formulaire contre les abus (spam, bots) ;
• Maintien de la sécurité ou de la stabilité d’un site.

Ce qui n’est pas un intérêt légitime :

• Bloquer arbitrairement des utilisateurs étrangers ;
• Collecter des données techniques pour une finalité commerciale dissimulée ;
• Réutiliser des données de sécurité à des fins statistiques ou marketing.

Un rappel qui ne "mange pas de pain" : la récolte d'informations personnelles, comme l'adresse mail, pour ensuite l'utiliser automatiquement à des fins de prospection commerciale, notamment pour inscrire une personne à une newsletter, n'est pas légal si cette action n'est pas fondée sur un consentement libre, éclairé et explicite de la personne concernée. Or, beaucoup d'entreprises font usage de cette pratique et se mettent de facto en non-conformité Rgpd.

2) Le traitement est-il nécessaire ?

Vous devez vous poser cette question simple :

• Ai-je réellement besoin de collecter cette donnée pour atteindre mon objectif ?

Ce qui implique de :

• Minimiser les données collectées ;
• Choisir la solution la moins intrusive parmi celles disponibles.

Exemple proportionné :

• Bloquer une adresse IP après plusieurs tentatives échouées de connexion.

3) Les droits et libertés de la personne sont-ils respectés ?

Ici vous devez évaluer l’impact du traitement sur les utilisateurs. Posez-vous cette question :

• L’utilisateur moyen, raisonnablement informé, s’attendrait-il à ce traitement dans ce contexte ?

Ce qui implique :

• D’évaluer le degré d’intrusion (quelles données ? données sensibles ou non ? durée de conservation ?) ;
• De tenir compte des "attentes raisonnables" des utilisateurs (se faire filtrer à l’accès d’un formulaire pour vérifier qu’on est humain est attendu. Être tracé sans le savoir ne l’est pas) ;
• De prévoir des "mesures compensatoires", en cas de traitement un peu plus intrusif (conservation courte des données, aucune corrélation avec d’autres données (ni profilage, ni reciblage), communication claire dans la politique de confidentialité).

Le droit d’opposition : une obligation d’information

Attention, Lorsque vous vous reposez sur l'intérêt légitime pour traiter des données personnelles, vous avez l'obligation d’informer l’utilisateur de son "droit de s’opposer à ce traitement, à tout moment, pour des raisons tenant à sa situation particulière" (article 21 du Rgpd).

Cette information doit être compréhensible par tout utilisateur, même non juriste, et elle doit figurer dans votre politique de confidentialité (c'est l'endroit idéal).

C’est une erreur courante que de penser que l’intérêt légitime dispense d’informer l’utilisateur. Au contraire, c’est précisément parce que vous vous fondez sur cette base que vous devez, en quelque sorte, "équilibrer les droits de chacun". Ne pas mentionner ce droit d’opposition peut constituer une non-conformité.

Il est important de rappeler qu’il s’agit ici d’une obligation d’information. L’utilisateur peut s’opposer au traitement fondé sur l’intérêt légitime, mais le responsable du traitement peut refuser cette opposition si des "motifs légitimes et impérieux, prévalant sur les intérêts, droits et libertés de la personne", justifient de continuer le traitement.

Par exemple, pour des traitements nécessaires à la sécurité du site ou à la prévention des attaques, il est souvent difficile, voire impossible, d’arrêter le traitement pour un utilisateur en particulier sans empiéter sur la protection globale.

Autrement dit, informer l’utilisateur sur son droit d’opposition garantit la transparence exigée par le Rgpd, mais cela ne signifie pas nécessairement qu’il sera toujours possible pour l’utilisateur de bloquer un traitement fondé sur l’intérêt légitime.

Le manque de sécurité : un vrai motif de sanction

Ce point est clair : si votre site n’est pas sécurisé et que cela cause une fuite de données personnelles (par exemple, à cause d’une faille non corrigée, d’une donnée qui devrait être chiffrée mais qui ne l'est pas (stockée "en clair" dit dans le jargon)), vous pouvez être sanctionné.

Mais ce n’est pas automatique. Avant toute chose, l'autorité (en France, la Commission Nationale de l'Informatique et des Libertés (Cnil)) va évaluer :

• Le type des données exposées ;
• Le niveau de négligence ;
• La réactivité du responsable de traitement ;
• Et s’il existait des mesures raisonnables à mettre en place.

Autrement dit, on ne vous reprochera pas de ne pas avoir mis en place un "pare-feu militaire". Mais on peut, pour donner un ordre d'idée, vous reprocher d’avoir laissé un formulaire sans avoir contrôlé la validation des saisies, ou d’avoir exposé une base de données sans mot de passe.

La "sur-sécurisation" mal maîtrisée : un risque tout aussi réel

Dans le doute, certaines personnes veulent "faire au mieux" : activer toutes les options, multiplier les services, ajouter des protections (par exemple en mettant des Captchas à tout va (c’est sans doute l’un des éléments de sécurité les plus "banalisés", alors que certains d'entre eux peuvent être très intrusifs s’ils sont mal configurés ou utilisés sans réflexion)), etc.

Le problème, c'est que beaucoup de ces solutions collectent des données personnelles (adresse IP, géolocalisation, fingerprinting (c'est un ensemble d'informations sur le navigateur utilisé), etc.). Et si vous ne comprenez pas comment ces données sont traitées, transférées ou stockées, vous vous mettez en non-conformité Rgpd souvent sans même vous en rendre compte.

Cela ne veut pas dire que vous serez automatiquement sanctionné, mais ça crée un risque juridique réel, en particulier si :

• Vous traitez des données personnelles sans base légale claire (consentement, intérêt légitime, etc.), ni transparence dans vos mentions légales ou votre politique de confidentialité ;
• Vous ne proposez aucun paramétrage à l’utilisateur concernant les cookies et autres traceurs ;
• Vous utilisez des services tiers sans vérifier leurs engagements contractuels (DPA, SCC, etc.), ce qui est une erreur extrêmement fréquente.

Ce que dit le Rgpd : une logique d'équilibre

Ce que le Rgpd attend, ce n’est pas la perfection, c’est une démarche cohérente, justifiée et documentée.

Si vous sécurisez un site avec un outil tiers, vous devez :

• Vérifier s’il traite des données personnelles ;
• Déterminer la base légale (souvent l'intérêt légitime, mais ce n'est pas toujours suffisant) ;
• Signer un Dpa si nécessaire (le systématiser dans vos démarches est une vraie valeur ajoutée) ;
• Informer l’utilisateur de manière claire.

Si vous ne sécurisez pas suffisamment un site, vous devez être capable de justifier vos choix techniques.

Aussi, vous n'êtes peut-être pas juriste, mais si vous êtes développeur, voici les principes clés du Rgpd qui vous concernent directement. Chaque traitement que vous implémentez doit pouvoir respecter ces règles :

• Minimisation : collecter le minimum de données nécessaires ;
• Limitation de la finalité : ne pas détourner l’usage initial ;
• Conservation limitée : ne pas garder les données inutilement ;
• Confidentialité : chiffrer, sécuriser, protéger contre les fuites ;
• Transparence : informer l’utilisateur clairement ;
• Loyauté et licéité : toujours s’appuyer sur une base légale valable.

Conclusion

Au 21ème siècle, concevoir un site web peut sembler être un jeu. Le jeu de celui qui ira le plus vite correspond manifestement à la modernité actuelle. C'est bien cet état d'esprit qui explique l’explosion des failles de sécurité et le manque flagrant de conformité.

Vous devez sécuriser votre site, ce n'est pas une option et vous en êtes le responsable. Seulement, aujourd'hui, avoir un espace protégé par mot de passe ne suffit pas. Protéger votre porte d'entrée ne suffit pas. Cela revient à mettre une alarme sur une cabane : ça donne bonne conscience, mais ça ne protège pas. Vous devez consolider vos murs, protéger vos fenêtres, votre toiture, et c'est seulement après que vous pourrez envisager d'agrandir la surface de votre terrain.

En somme, la sécurité d'un site, c'est une démarche globale et stratégique. Souhaitez-vous utiliser telle fonctionnalité parce qu'elle sécurise votre site ? Ou bien parce qu'elle vous évite quelques spams ? D'ailleurs, le "spam zéro" n'existe pas, vous ne l'éviterez que modérément, aussi vaudra-t-il mieux tabler sur un rate limiting (en gros c'est le fait de se protéger contre les requêtes faites en rafales) bien conçu plutôt que sur un Captcha (c'est la fameuse case que vous devez cocher pour "prouver" (en théorie...) que vous êtes un humain) hautement intrusif.

Selon ce que vous souhaitez, la finalité n'est pas la même et vous fait peut-être peser des risques Rgpd inutilement. Chaque outil ajouté, chaque traitement de données effectué, chaque fonctionnalité activée, doit répondre à une finalité claire, et non à une peur ou à un effet de mode.

Il n’y a pas de solution unique. Mais il y a une règle d’or : posez-vous toujours la question de la proportionnalité.

• Pourquoi ce service ?
• Quelles données traite-t-il ?
• Puis-je le justifier légalement ?
• Existe-t-il une alternative moins intrusive ?

En bref : ne sécurisez pas plus, sécurisez mieux. Et surtout, sécurisez consciemment.