Les freelances et indépendants sont devenus une extension naturelle des entreprises : développement, design, comptabilité, support, marketing, conseil, admin. Ils travaillent vite, à distance, sur leurs propres outils, souvent entre deux missions. Et c’est précisément ce qui crée un angle mort : côté client, on les traite comme “externes”, donc moins intégrés ; côté freelance, on se croit “trop petit pour intéresser”. Résultat : un maillon discret, très utile, mais rarement sécurisé à la hauteur de ce qu’il manipule.
Le problème n’est pas moral, il est structurel : les indépendants sont souvent un point de jonction entre plusieurs organisations, plusieurs comptes, plusieurs environnements cloud, et plusieurs appareils. Une compromission chez eux peut devenir une compromission en chaîne.
Ce qui se passe vraiment : le freelance est un hub d’accès
Un indépendant accumule des accès : messagerie, outils de travail, drives, CRM, environnements de dev, comptes publicitaires, consoles d’admin, API, gestion de projet. Souvent, l’accès est donné “vite fait” : un lien partagé, un compte créé en urgence, un mot de passe transmis par message, une invitation à un espace cloud, une clé API envoyée sans procédure.
Pour un attaquant, c’est une cible rentable. Non pas parce que le freelance a “des secrets d’État”, mais parce qu’il a des portes d’entrée vers des clients. Et parce qu’il est plus probable qu’il travaille sans équipe IT, sans SOC, sans procédures, et avec un empilement d’outils hétérogènes.
Clients : quand la relation de confiance remplace la sécurité
Beaucoup de clients exigent une sécurité forte en interne mais tolèrent des pratiques faibles en externe. On partage des dossiers entiers sans cloisonner, on donne des droits trop larges “pour aller plus vite”, on n’a pas de revue d’accès, on n’impose pas d’authentification forte, on ne retire pas les accès en fin de mission.
Le paradoxe est simple : un client peut être très mature en cybersécurité et quand même se faire compromettre via un prestataire, juste parce que la gouvernance des accès externes n’est pas traitée comme un vrai sujet.
Accès partagés : la pratique la plus toxique
Le partage d’identifiants est encore trop courant : “utilisez le compte générique”, “voici le mot de passe admin”, “connectez-vous avec mon compte et faites la modif”. C’est toxique pour trois raisons.
D’abord, c’est ingérable : vous ne savez plus qui a fait quoi. Ensuite, c’est fragile : une fuite de mot de passe devient une fuite d’organisation. Enfin, c’est juridiquement et contractuellement explosif : vous mélangez les responsabilités et vous transformez un incident en conflit.
Une organisation sérieuse ne donne pas un mot de passe : elle donne un accès. Et un accès doit être nominatif, limité, révocable, traçable.
Stockage cloud personnel : le dérapage invisible
Le cloud personnel est l’un des risques les plus banals : un freelance travaille “comme il sait faire”, donc avec son drive perso, ses outils, ses sauvegardes, ses partages. Tant que tout se passe bien, personne ne s’en rend compte. Jusqu’au jour où un compte est compromis, ou qu’un lien de partage est trop permissif, ou qu’un ancien client retrouve des documents d’un autre.
Ce risque est aggravé par la réutilisation : mêmes comptes pour plusieurs clients, mêmes dossiers, mêmes liens, mêmes habitudes. Un seul incident peut exposer plusieurs missions à la fois.
Responsabilité légale : l’incident devient une affaire de preuve
Quand il y a fuite, la question n’est pas seulement “qui a été attaqué ?”. C’est “qui était responsable de quoi, et qui peut le prouver ?”.
Un freelance peut être sous-traitant au sens du RGPD ou assimilé, et un client peut être responsable de traitement. Selon les contrats, les obligations de sécurité, de notification, et de coopération peuvent être très différentes. Et sans trace d’audit, sans journaux, sans historique de partage, la discussion se transforme en parole contre parole.
Le danger ici n’est pas le droit “en théorie”. C’est la réalité : quand il faut démontrer que vous aviez des mesures raisonnables, vous devez pouvoir montrer des pratiques, pas seulement des intentions.
Réduire le risque : une hygiène minimale qui change tout
Le point n’est pas de transformer un freelance en DSI. Le point est de sécuriser les jonctions.
Cela passe par des mesures simples : comptes séparés par client quand c’est possible, authentification forte partout, gestionnaire de mots de passe, révocation systématique des accès en fin de mission, stockage cloisonné, partage limité, et appareil à jour. Côté client, cela implique de fournir des accès nominatif et limités, d’éviter les comptes génériques, de définir des règles de partage, et de formaliser la fin d’accès.
La sécurité des indépendants est un problème d’écosystème : elle se règle à deux.
Exigence : le vrai test de maturité
Le test n’est pas “avez-vous un freelance compétent”. Le test est : est-ce que vous contrôlez les accès externes aussi sérieusement que les internes ? Si la réponse est non, vous avez créé un maillon faible par design.
Et côté indépendant, la question est : est-ce que vous pouvez prouver que vous cloisonnez, que vous protégez, et que vous retirez les accès ? Si la réponse est non, vous travaillez avec une bombe à retardement — pas seulement technique, mais contractuelle.
