Gestion des accès et des secrets : la faille de sécurité que votre startup crée en grandissant, sans s'en rendre compte

Un ancien développeur freelance, parti depuis quatre mois, a encore les clés de votre base de production. Personne ne l’a fait exprès. Personne ne s’en souvient, d’ailleurs. C’est exactement le problème.

Dans une startup early-stage, la sécurité des accès n’est pas un sujet — c’est un impensé. On partage un compte admin, on colle une clé API Stripe dans un fichier de config, on ajoute le nouveau dev à « tout » parce que c’est plus rapide, et on passe à autre chose. Ça marche à trois. Ça devient une bombe à retardement à quinze. Et le jour où un client grand compte, un investisseur en due diligence ou un auditeur RGPD pose la question « qui a accès à quoi, et comment le prouvez-vous ? », vous découvrez que vous n’avez pas de réponse.

Le vrai risque n’est pas le hacker de film, c’est l’entropie

Quand on parle de sécurité en startup, l’imaginaire collectif convoque l’attaque sophistiquée, le pirate encapuchonné, la faille zero-day. Cette image est trompeuse. La grande majorité des incidents qui touchent des jeunes entreprises ne viennent pas d’une attaque ciblée mais d’une accumulation de négligences banales : une clé secrète poussée par erreur dans un dépôt GitHub public, un accès administrateur laissé à un prestataire parti depuis des mois, un mot de passe partagé sur un Slack, un token de production qui traîne dans l’historique de commandes d’un laptop volé.

Le point commun de tous ces incidents, c’est qu’ils ne sont la faute de personne en particulier. Ils sont le produit de l’entropie : à chaque nouvelle personne, chaque nouvel outil, chaque nouveau service branché, la surface d’exposition grandit un peu, sans que quiconque tienne le fil. Personne ne décide « laissons cet ancien freelance accéder à la prod ». C’est juste que révoquer un accès demande un effort actif, et que cet effort n’est jamais priorisé tant qu’il ne fait pas mal.

Le résultat est un système que personne ne comprend entièrement. Demandez à n’importe quel fondateur d’une startup de dix personnes de lister, sans regarder, tous les endroits où se trouve une copie de sa clé API de paiement. Il ne saura pas. Ce « il ne saura pas » est précisément la vulnérabilité.

Deux dettes distinctes : les accès humains et les secrets machines

Il faut séparer deux problèmes qu’on confond souvent, parce qu’ils ne se traitent pas de la même manière.

Le premier, ce sont les accès humains : qui, dans votre équipe et parmi vos prestataires, peut se connecter à quoi. La console AWS, le compte Stripe, la base de données, l’outil d’analytics, le CRM, l’espace admin. Ici, le sujet est organisationnel autant que technique. La question centrale n’est pas « comment sécuriser », mais « comment garder à jour la liste de qui a le droit d’entrer, au fur et à mesure que les gens arrivent, changent de rôle et partent ».

Le second, ce sont les secrets machines : les clés API, tokens, mots de passe de base de données, certificats que votre code utilise pour parler aux autres services. Ici, le problème est technique : où sont stockés ces secrets, qui peut les lire, et que se passe-t-il quand il faut en changer un.

Ces deux dettes évoluent différemment. La dette d’accès humain explose au moment des départs — c’est un problème d’offboarding. La dette de secrets explose au moment où un secret fuite ou expire — et là, si vous avez copié la même clé à douze endroits, la rotation devient un cauchemar qui bloque la moitié de votre stack. Traiter l’un ne règle pas l’autre.

Le point de bascule : l’offboarding

S’il y a un seul moment à instrumenter en priorité, c’est le départ d’une personne. Tant que tout le monde est là, un accès mal calibré est un risque théorique. Le jour où quelqu’un part — surtout dans une rupture tendue, ou pour rejoindre un concurrent — chaque accès non révoqué devient un risque réel et immédiat.

Le problème, c’est que l’offboarding technique est éclaté sur une dizaine de systèmes qui ne communiquent pas. Retirer quelqu’un de votre outil RH ne le retire pas d’AWS, de GitHub, de Notion, du CRM ou de la base de données. Sans checklist explicite, on en oublie toujours un. Et l’accès qu’on oublie est, par définition, celui dont on ne se souvient pas — donc potentiellement le plus sensible.

Ce que change une due diligence ou un deal B2B

Ce sujet, longtemps repoussé comme du « nice to have », devient soudain critique à deux moments très concrets de la vie d’une startup, et ce sont deux moments où l’argent est en jeu.

La levée de fonds. En due diligence technique, un investisseur sérieux — ou son conseil tech — va demander comment vous gérez les accès et les secrets. Pas par pédantisme : parce que la manière dont vous traitez ce sujet est un signal de maturité opérationnelle. Une équipe qui sait exactement qui a accès à quoi, qui révoque proprement, qui ne stocke pas ses clés en clair, rassure. Une équipe qui découvre en direct qu’elle ne sait pas, inquiète — et cette inquiétude se paie dans la valorisation ou dans les conditions.

Le deal B2B. Dès que vous vendez à des clients d’une certaine taille, leur équipe sécurité vous envoie un questionnaire. On y trouve invariablement des questions sur la gestion des accès, la rotation des secrets, la traçabilité, la séparation des environnements. Si vous visez une certification type SOC 2 ou une conformité ISO 27001 — souvent exigée pour signer des grands comptes — la gestion des accès est un pilier entier du référentiel. Ce n’est plus une hygiène facultative : c’est une condition d’entrée sur le marché.

Sans oublier le cadre RGPD : si vos accès aux données personnelles ne sont pas maîtrisés et traçables, vous êtes en défaut sur le principe de sécurité et de minimisation, indépendamment de toute fuite.

Ce qu’il faut vraiment faire, selon votre stade

L’erreur symétrique du laxisme, c’est le zèle prématuré : monter un système d’identité d’entreprise avec revues d’accès trimestrielles et provisioning automatisé alors que vous êtes cinq. Vous brûleriez du temps que vous n’avez pas sur un problème que vous n’avez pas encore. Le bon niveau dépend du stade.

Pre-seed / très petite équipe (moins de cinq personnes). Ne construisez rien de lourd. Faites trois choses simples mais non négociables. Un : sortez tous les secrets du code. Aucune clé, aucun mot de passe dans un dépôt Git, même privé — utilisez les variables d’environnement de votre hébergeur et un gestionnaire de secrets basique (le vault intégré de votre cloud, ou même un gestionnaire de mots de passe partagé chiffré pour commencer). Deux : activez l’authentification à deux facteurs partout où c’est possible, en priorité sur les comptes qui touchent à l’argent et à l’infrastructure. Trois : tenez un document unique, ennuyeux mais vital, qui liste chaque service, qui y a accès, et avec quel niveau. Ce simple fichier vaut mieux que n’importe quel outil que vous ne remplirez pas.

Seed (cinq à quinze personnes). C’est le moment de professionnaliser sans sur-ingénierie. Centralisez l’authentification via un fournisseur d’identité (SSO) pour que l’ajout et le retrait d’une personne se fasse à un seul endroit et se propage. Adoptez un vrai gestionnaire de secrets pour vos secrets machines, avec des accès distincts par environnement — la clé de développement ne doit jamais pouvoir toucher la production. Et surtout, écrivez votre checklist d’offboarding : la liste exhaustive des systèmes à couper quand quelqu’un part, transformée en routine déclenchée automatiquement à chaque départ. C’est l’investissement au meilleur rapport risque évité sur effort fourni à ce stade.

Série A et au-delà. Là, le sujet devient une fonction, pas une bricole. Appliquez le principe du moindre privilège — chacun a accès à ce dont il a besoin pour son rôle, rien de plus — via des rôles clairs plutôt que des permissions accordées au cas par cas. Instaurez des revues d’accès périodiques pour purger l’entropie accumulée. Mettez en place la journalisation des accès aux données sensibles, indispensable pour la traçabilité RGPD et pour toute certification. Automatisez la rotation des secrets critiques. À ce stade, vous préparez ou passez probablement une certification : autant que le système soit conçu pour, plutôt que reconstruit dans la douleur trois semaines avant l’audit.

La question à se poser aujourd’hui

Le bon réflexe n’est pas de tout verrouiller demain matin. C’est de mesurer votre exposition réelle avec une question inconfortable : si une personne quittait votre équipe ce soir dans de mauvaises conditions, combien de temps vous faudrait-il pour couper tous ses accès — et êtes-vous certain de n’en oublier aucun ?

Si la réponse est « je ne sais pas », vous n’avez pas un problème de sécurité au sens dramatique du terme. Vous avez une dette d’organisation qui grandit silencieusement à chaque embauche, et qui vous sera présentée, un jour, au pire moment : celui où un investisseur ou un client vous demandera de prouver que vous maîtrisez ce que vous n’avez jamais pris le temps de cartographier.