Les obligations de sécurité qui s'appliquent déjà à vous en tant que développeur indépendant

Il existe une croyance tenace chez les développeurs indépendants selon laquelle la réglementation en matière de sécurité et de confidentialité ne concernerait que les entreprises — que les obligations commenceraient au moment où l'on se constitue en société, où l'on embauche un DPO, ou où l'on signe un contrat avec une grande entreprise. C'est faux, et cela l'est depuis des années. Si vous êtes freelance ou développeur indépendant et que vous manipulez des données clients, plusieurs obligations s'appliquent déjà à vous aujourd'hui, personnellement, à votre taille actuelle. Cet article passe en revue ce qu'elles sont, nomme les réglementations dont elles proviennent, et se termine par la question pratique qui compte vraiment : qu'est-ce qui est concrètement exposé sur vos comptes en ce moment ?

Cet article ne vous dira à aucun moment qu'une loi vous obligerait à acheter un outil de sécurité. Aucune ne le fait. Ce que la loi exige réellement, c'est que vous sachiez ce que vous faites des données que vous traitez et que vous les sécurisiez de manière appropriée — et le point de départ honnête pour cela consiste à savoir quels accès existent sur les comptes où réside le travail de vos clients.

Selon le RGPD, un freelance qui traite des données clients est un sous-traitant — avec des obligations directes

Si un client dans l'UE (ou un client dont les utilisateurs se trouvent dans l'UE) vous confie des données personnelles — une base de données utilisateurs à migrer, un système de production à déboguer, un export à analyser — vous agissez presque toujours en tant que sous-traitant au sens du RGPD, et dans certaines missions (lorsque vous décidez de ce qui est collecté et pourquoi) en tant que responsable du traitement. Aucun de ces statuts n'exige d'être une société. Les définitions de l'article 4 du RGPD s'appliquent à « une personne physique ou morale » — une personne munie d'un ordinateur portable est concernée.

Ce statut entraîne des obligations directes et personnelles :

• L'article 28 exige que votre traitement pour le compte d'un client soit régi par un contrat — le contrat de sous-traitance de données que vos clients grands comptes n'arrêtent pas de vous envoyer n'est pas du théâtre bureaucratique ; c'est une exigence légale pour vous deux, et il vous engage sur des mesures de sécurité précises.
• L'article 32 vous impose de mettre en œuvre des « mesures techniques et organisationnelles appropriées » pour sécuriser les données personnelles que vous traitez — appropriées au risque, ce qui inclut le contrôle de qui et de quoi peut y accéder.
• L'article 33 exige qu'un sous-traitant notifie le responsable du traitement « dans les meilleurs délais » après avoir pris connaissance d'une violation de données à caractère personnel — ce qui présuppose que vous soyez en mesure d'en prendre connaissance.
• L'article 82 donne aux personnes concernées le droit d'obtenir réparation auprès des sous-traitants pour le dommage causé par un traitement qui enfreint le règlement, et l'article 83 appuie l'ensemble du dispositif par des amendes administratives pouvant atteindre, pour les infractions les plus graves, jusqu'à vingt millions d'euros ou quatre pour cent du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu.

Personne ne suggère que la première action d'une autorité de contrôle contre un freelance serait le maximum légal. Le propos est plus simple : ces obligations sont réelles, elles s'appliquent directement à vous, et « je ne suis qu'une seule personne » n'est reconnu comme exemption nulle part dans le texte du règlement.

L'AI Act européen ajoute des obligations pour les déployeurs de systèmes d'IA

Si le travail que vous réalisez pour vos clients inclut désormais l'intégration d'IA dans des produits — un assistant dans l'application d'un client, un agent IA automatisant un flux de travail, un modèle prenant des décisions qui affectent des personnes — l'AI Act européen vous concerne. Le règlement ne régule pas uniquement les entreprises qui entraînent des modèles ; il impose des obligations aux déployeurs — ceux qui utilisent des systèmes d'IA sous leur propre autorité dans un contexte professionnel.

L'article 26 énonce les obligations des déployeurs pour les systèmes d'IA à haut risque, notamment l'utilisation des systèmes conformément à leur notice d'utilisation, la garantie d'une surveillance humaine appropriée, et le suivi du fonctionnement. L'article 4 impose aux fournisseurs comme aux déployeurs de veiller à un niveau suffisant de culture en matière d'IA chez les personnes qui exploitent ces systèmes pour leur compte. Et l'article 99 appuie le dispositif par des amendes administratives en cas de non-conformité. Les obligations applicables à une mission donnée dépendent de ce que fait le système et de la catégorie de risque dont il relève — mais « je me suis contenté de l'intégrer, je ne l'ai pas conçu » est précisément le rôle pour lequel la catégorie des déployeurs a été écrite.

Il y a ici une ironie pratique que nous observons constamment dans la gouvernance des agents IA : les développeurs indépendants sont parmi les plus gros adopteurs d'agents de codage IA et de bots d'automatisation — et les moins susceptibles de disposer d'un inventaire de ce que ces agents peuvent atteindre. Si un agent IA peut pousser du code vers chacun de vos dépôts, c'est un fait qui concerne votre posture de sécurité, que quelque régulateur ne pose jamais la question ou non.

Vos clients grands comptes sont déjà réglementés — et leurs obligations retombent sur vous

Même si vous ne touchez jamais à des données personnelles européennes et que vous ne déployez jamais de système d'IA, il existe une troisième source d'obligations de sécurité qui s'applique à presque tous les freelances travaillant avec des entreprises de toute taille : les contrats. Les clients grands comptes opèrent sous des rapports SOC 2, des certifications ISO 27001, des exigences de sous-traitance issues de l'article 28 du RGPD, et des programmes de gestion des fournisseurs que leurs auditeurs vérifient réellement. Ces programmes ne font pas de distinction entre un fournisseur de 500 personnes et un fournisseur d'une seule personne. Un fournisseur est un fournisseur.

C'est pourquoi le questionnaire de sécurité arrive toujours avant le contrat. Votre client est tenu — par son référentiel, son auditeur, ou ses propres clients — de recueillir des preuves de sécurité auprès des personnes à qui il confie des données. Vous y compris. Les freelances capables de répondre de manière crédible (« voici ce qui a accès à mon environnement de développement, voici comment je le contrôle, voici les preuves ») concluent ces contrats plus rapidement que ceux qui improvisent. Nous avons évoqué la version côté entreprise de cette dynamique dans ce que les auditeurs exigent pour la gouvernance de l'IA en 2026 ; la version côté fournisseur atterrit sur votre bureau sous forme de questionnaire.

Ce qu'une violation coûte réellement à un développeur indépendant

Parlons risque, car c'est le cadrage honnête : un incident de sécurité dans un projet client peut entraîner une responsabilité financière directe au titre de la clause d'indemnisation de votre contrat, peut entraîner une responsabilité de sous-traitant au titre de l'article 82 du RGPD si des données personnelles étaient impliquées, et — de manière plus concrète pour un freelance — peut signifier la fin de la relation client et de la référence qui l'accompagnait. Pour un consultant seul, l'actif réputationnel, c'est l'entreprise elle-même. Rien de tout cela n'est une hypothèse exotique ; c'est la chaîne de conséquences ordinaire lorsqu'un identifiant compromis ou une intégration trop permissive se transforme en incident touchant les données d'un client.

Alors, qu'est-ce qui est réellement exposé sur votre compte en ce moment ?

Voici la version inconfortable et précise de la question. Le travail que vous réalisez pour vos clients réside presque certainement sur un compte GitHub personnel. Ce compte a accumulé, au fil des années de projets :

• Des GitHub Apps installées — bots de déploiement, outils de CI, assistants IA — chacune détenant une autorisation que vous avez approuvée une fois et probablement jamais revue. Certaines détiennent des droits d'écriture ou d'administration sur tout ce que vous possédez. Certaines appartiennent à des projets qui se sont terminés en 2024.
• Des clés de déploiement — des identifiants SSH non surveillés qui se trouvent sur des serveurs, certains avec un accès en écriture au dépôt qu'ils étaient censés seulement lire. Si ce serveur est compromis, une clé de déploiement en lecture-écriture devient une voie d'injection de code dans le produit de votre client.
• Des collaborateurs — des personnes que vous avez ajoutées lors d'une collaboration désormais terminée, qui détiennent toujours un accès en écriture, y compris sur des dépôts publics.
• L'exposition des dépôts — savoir lesquels de vos dépôts sont publics, et ce qu'ils contiennent, est en soi une question d'inventaire à laquelle la plupart des développeurs ne peuvent pas répondre de mémoire.

Chacun de ces éléments est lisible par machine via l'API propre de GitHub, ce qui signifie que chacun d'eux est vérifiable — non pas en se fiant à sa mémoire, mais en énumérant ce qui détient réellement un accès aujourd'hui. Cet inventaire est exactement ce que produit désormais le connecteur GitHub de 8200.dev pour les comptes personnels, pas seulement pour les organisations : connectez votre propre identifiant GitHub, et l'analyse répertorie les applications installées et leurs autorisations, les clés de déploiement et si chacune est en lecture seule, les collaborateurs par dépôt, et les constats qui découlent de ce graphe — le bot oublié avec des droits d'administration, la clé de déploiement capable d'écrire, l'application obsolète que personne n'a touchée depuis un an.

Le niveau personnel gratuit exécute l'analyse complète et vous montre les constats les plus sévères ; le niveau personnel payant — au prix d'un abonnement de complétion de code, pas d'un logiciel d'entreprise — débloque la liste complète avec surveillance continue et alertes. Et si vous évoluez vers une agence dotée d'un compte organisation, la même analyse, les mêmes règles et la même piste de preuves évoluent avec vous — c'est le volet organisation du produit, et c'est le même connecteur.

Les obligations décrites ci-dessus s'appliquent à vous, que vous exécutiez ou non une analyse un jour. Ce que l'analyse change, c'est votre capacité à répondre aux questions qu'impliquent ces obligations — ce qui a accès, pourquoi, et ce que vous avez fait de l'accès que personne ne pouvait justifier. Commencez par le niveau gratuit, découvrez ce qui s'est discrètement accumulé sur votre compte, et décidez ensuite — la grille tarifaire est publique, en libre-service, et démarre à zéro.

*Cet article constitue une information générale sur les réglementations qui s'appliquent couramment aux développeurs indépendants ; il ne constitue pas un conseil juridique, et la manière dont chaque réglementation s'applique à votre situation spécifique dépend de faits qu'un outil d'analyse ne peut pas connaître. Pour cela, consultez un avocat.*