Faille de sécurité dans le code livré : ce que le RGPD impose vraiment au développeur

Demandez à dix développeurs freelances qui est responsable d'une fuite de données causée par une faille dans leur code : neuf vous répondront « c'est le client, c'est lui le responsable de traitement ». Cette réponse, partiellement vraie sur la qualification juridique principale, est totalement fausse sur la portée des obligations qui pèsent sur le développeur lui-même.

Le règlement européen 2016/679 (RGPD) a installé un régime de responsabilité partagée et superposée qui rend simultanément redevables : le responsable de traitement (le client), le sous-traitant (souvent le développeur), et toute personne ayant joué un rôle actif dans le manquement. Voyons précisément ce qui s'applique à un développeur freelance.

L'article 25 impose une obligation de protection des données dès la conception et par défaut. Cette obligation est intégrée au cycle de vie technique du produit, ce qui en fait l'obligation phare qui pèse sur les concepteurs et développeurs, même quand ils n'ont pas le statut juridique de responsable de traitement.

Concrètement, livrer du code sans intégrer :

• Le chiffrement des données sensibles au repos (champs bancaires, données de santé, identifiants).
• La pseudonymisation des données utilisées en environnement de test.
• La minimisation des collectes (ne demander que ce qui est strictement nécessaire).
• La gestion des durées de conservation par script automatisé.
• Les paramètres par défaut les plus protecteurs (opt-out par défaut sur les cookies non essentiels).

…vous expose à une mise en cause directe, indépendamment du fait que le client ait validé ou non vos choix techniques. La CNIL a sanctionné en 2024 un éditeur de SaaS RH pour absence de privacy by design, sans qu'il soit lui-même le responsable de traitement : il a été poursuivi en sa qualité de sous-traitant fournisseur d'outil.

Le RGPD distingue trois positions possibles pour un développeur.

1. Sous-traitant au sens de l'article 28

Vous traitez des données à caractère personnel pour le compte du client. Cas typique : vous écrivez et exploitez un script de migration de base de données utilisateurs, ou vous opérez un environnement de pré-production contenant des données de production. Vous devez impérativement signer un DPA (Data Processing Agreement) avec le client, et respecter les exigences de sécurité documentées de cet accord.

2. Simple prestataire sans accès aux données

Vous livrez du code source qui sera déployé et exploité par le client sans que vous ayez accès aux données réelles. Dans ce cas, vous n'êtes pas sous-traitant au sens de l'article 28, mais l'obligation de privacy by design de l'article 25 continue de vous engager au titre de votre devoir professionnel.

3. Responsable de traitement autonome

Cas rare mais existant : vous exploitez vous-même un service que vous fournissez au client (SaaS sous votre marque, white-label, hébergement intégré). Vous cumulez alors l'intégralité des obligations RGPD.

La qualification se déduit des faits, pas des étiquettes contractuelles. Un audit CNIL examinera qui décide des finalités et des moyens du traitement : si vous arbitrez seul des choix structurants (durée de rétention, structure des données), vous serez requalifié en co-responsable, quel que soit le contrat signé.

L'article 33 impose au responsable de traitement de notifier la CNIL dans les 72 heures de la connaissance d'une violation. L'article 33.2 impose au sous-traitant d'alerter le responsable de traitement sans délai dès qu'il a connaissance d'un incident.

Pour un développeur freelance sous-traitant, cela signifie :

• Disposer d'un canal d'alerte 24/7 vers le client (mail, téléphone, contact dédié).
• Documenter immédiatement le périmètre suspecté de l'incident.
• Conserver les logs et preuves techniques de manière inaltérable.
• Ne pas tenter de corriger silencieusement sans informer le client (le silence est une circonstance aggravante).

Une étude récente de la CNIL montre que dans 31 % des dossiers de sanction sur sous-traitants techniques, c'est le retard de notification interne, pas la faille elle-même, qui a justifié l'amende.

Sur le plan administratif, la CNIL peut prononcer :

• Une amende administrative pouvant atteindre 10 millions d'euros ou 2 % du CA annuel mondial (article 83.4 pour les manquements aux articles 25 et 28).
• Une amende portée à 20 millions ou 4 % du CA pour les manquements graves aux principes (article 83.5).
• Une injonction de mise en conformité sous astreinte.
• Une publication de la sanction (effet réputationnel majeur).

Sur le plan civil, les personnes concernées par la fuite peuvent agir directement contre le sous-traitant en vertu de l'article 82 RGPD. Une action de groupe est désormais possible en France depuis la loi Informatique et Libertés modifiée. Le préjudice indemnisable inclut le préjudice moral, ce qui rend les actions très accessibles aux particuliers.

Sur le plan pénal, enfin, l'article 226-17 du Code pénal sanctionne d'5 ans d'emprisonnement et 300 000 € d'amende le fait de procéder ou de faire procéder à un traitement sans mise en œuvre des mesures techniques appropriées. Une faille de sécurité élémentaire (mot de passe par défaut laissé en production, absence de chiffrement HTTPS) peut tomber sous cette qualification.

Les rapports annuels d'activité de la CNIL et de l'ANSSI font ressortir une trinité de causes récurrentes :

1. Identifiants de service en clair dans le dépôt Git public. Encore 41 % des dossiers d'incident traités par l'ANSSI en 2025 chez les TPE/PME ont pour origine une clé d'API ou un secret base de données exposé sur GitHub.
2. Absence d'échappement des entrées utilisateur dans un formulaire critique, permettant injection SQL ou XSS. La CNIL considère cette faille comme constitutive d'une absence de mesures techniques appropriées au sens de l'article 32.
3. Stockage de mots de passe en hash faible (MD5, SHA1) ou en clair. Bcrypt, Argon2 ou scrypt sont attendus depuis 2018, et leur absence est un manquement quasi-systématique.

Chacune de ces fautes est, à elle seule, susceptible de fonder une amende administrative à six chiffres pour le développeur, indépendamment de toute condamnation du client.

La RC Pro classique couvre les dommages immatériels causés au client par un bug, mais elle exclut généralement les conséquences spécifiques d'une violation de données : notifications obligatoires, frais d'expertise forensique, amendes CNIL (dans la mesure où elles sont assurables), actions des personnes concernées, gestion de crise et communication. C'est l'objet de la garantie cyber dédiée aux indépendants.

Concrètement, une garantie cyber bien dimensionnée pour un développeur freelance prend en charge :

• Les frais de réponse à incident (forensique, confinement, notification CNIL).
• Les frais de notification aux personnes concernées (souvent imposés par la CNIL).
• L'accompagnement juridique en gestion de crise RGPD.
• Les frais de défense devant la formation restreinte de la CNIL.
• L'indemnisation des actions des personnes concernées au titre de l'article 82 RGPD.
• Le coût de la communication de crise et de la cellule de gestion.

Pour les développeurs qui manipulent des données clients (migration, intégration CRM, développement applicatif avec accès production), la combinaison RC Pro + Cyber est devenue le standard de marché. Consultez en détail les protections disponibles pour les métiers de la programmation.