En bref
- La cybersécurité pour startups se traite dès la conception du produit, pas après la première alerte ou le premier client perdu.
- Le guide publié par l’ANSSI et la Mission French Tech découpe le parcours entrepreneurial en 13 sujets concrets, du savoir-faire au passage à l’échelle.
- Les accès aux outils, le code source, les secrets techniques, les sauvegardes et les déploiements méritent des règles écrites dès les premiers mois.
- Une petite équipe ne doit pas empiler les logiciels de sécurité. Elle doit réduire les droits, documenter ses usages et tester sa capacité à revenir en arrière.
Cybersécurité pour startups dès l’idéation : protéger le savoir-faire avant de vendre
Un dépôt GitHub public créé trop vite, une clé API collée dans un fichier .env envoyé par e-mail, un prototype hébergé sur un compte personnel : les fuites démarrent souvent avant même la première facture. Dans une jeune entreprise, le produit, les maquettes, les données de test et les choix techniques forment déjà une part du capital.
Le guide de cybersécurité publié par l’ANSSI avec la Mission French Tech suit cette logique. Il ne présente pas la sécurité informatique comme un chantier isolé réservé au jour où l’équipe recrute un RSSI, mais comme une discipline liée à chaque décision du parcours entrepreneurial, de l’idée au passage à l’échelle.
Une startup du numérique développe un produit ou un service fondé sur les technologies de l’information, avec une ambition de croissance rapide et une activité encore instable. Cette instabilité change tout. Les outils changent, les prestataires changent, les personnes arrivent et partent, tandis que les accès s’accumulent dans Google Workspace, GitHub, Notion, Stripe, AWS, OVHcloud ou Vercel.
La première mesure utile consiste à dresser une carte des actifs. Pas un document de conformité de 80 pages. Un tableau partagé qui indique où se trouvent le code, les noms de domaine, les comptes publicitaires, la base clients, les sauvegardes, les clés de paiement et les contrats fournisseurs.
Chaque ligne doit avoir un propriétaire interne, même dans une équipe de trois personnes. Si le nom de domaine est enregistré avec l’adresse personnelle d’un ancien associé ou si le compte Apple Developer appartient à un freelance, l’entreprise peut perdre l’accès à un élément bloquant au pire moment.
Réduire les accès plutôt que multiplier les outils
Le principe du moindre privilège veut dire qu’une personne reçoit uniquement les droits nécessaires à sa mission. Un intégrateur qui modifie les pages d’un site WordPress n’a pas besoin d’un compte administrateur sur la facturation AWS. Un stagiaire chargé d’une campagne LinkedIn n’a pas à consulter les exports complets de clients.
Cette séparation réduit les dégâts en cas de compte piraté. Elle réduit aussi les erreurs ordinaires, comme la suppression d’un environnement de production depuis une console cloud ouverte trop largement. Un compte administrateur utilisé chaque jour pour lire ses e-mails finit tôt ou tard dans une fuite de mots de passe ou une tentative de phishing.
Les fondateurs peuvent démarrer avec un gestionnaire de mots de passe d’équipe comme Bitwarden, 1Password ou Proton Pass. L’intérêt ne se limite pas au stockage : les coffres partagés permettent de retirer un accès proprement lors d’un départ, sans faire circuler un mot de passe commun dans Slack.
La double authentification doit être active sur les comptes qui peuvent bloquer l’activité. Les priorités sont le registraire du nom de domaine, les boîtes e-mail, les outils cloud, GitHub ou GitLab, les plateformes de paiement et le back-office e-commerce. Une application TOTP comme Aegis, 2FAS ou Google Authenticator reste plus robuste que le SMS face au détournement de numéro.
- Le nom de domaine doit être enregistré au nom de l’entreprise et protégé par une double authentification.
- Les comptes administrateurs doivent être séparés des comptes utilisés au quotidien.
- Les secrets doivent vivre dans un coffre ou un gestionnaire dédié, jamais dans Notion, Trello ou un dépôt Git.
- Les départs doivent déclencher une révocation immédiate des accès, pas une vérification reportée au mois suivant.
La protection des données commence aussi par une règle souvent ignorée : les bases de production ne doivent pas finir sur les ordinateurs personnels pour “tester vite”. Une copie contenant des adresses, des numéros de téléphone, des commandes ou des mots de passe hachés peut être exfiltrée par un malware ou synchronisée dans un cloud personnel.
Des données anonymisées ou générées suffisent pour la plupart des tests. Si un extrait réel est indispensable pour diagnostiquer une anomalie, il faut limiter sa taille, le chiffrer, fixer une date de suppression et savoir qui l’a reçu.
La gestion des risques n’a rien d’abstrait à ce stade. Une startup qui protège ses accès fondateurs et son code évite de découvrir, lors d’une levée de fonds ou d’une migration urgente, que personne ne sait récupérer le compte qui détient le produit.
Sécuriser le développement logiciel et les composants tiers sans casser la vitesse de livraison
Le code source concentre la valeur technique d’une startup. Il porte les règles métier, les connecteurs de paiement, les algorithmes, les configurations cloud et parfois des données clients. Un dépôt compromis ne menace pas seulement la propriété intellectuelle : il peut injecter une porte dérobée dans le produit livré.
Les attaques contre la chaîne d’approvisionnement logicielle visent précisément ce chemin. Un package npm malveillant, une dépendance Python abandonnée, un token GitHub volé ou un pipeline CI/CD mal configuré suffit à contaminer une livraison. Les vulnérabilités ne viennent donc pas uniquement d’un pirate qui attaque le site public.
Le réflexe “on corrigera après le MVP” tient rarement face à la réalité. Après le lancement, les dépendances augmentent, le nombre de branches augmente, les intégrations SaaS augmentent. Revenir sur des droits GitHub ouverts à toute l’équipe devient alors un chantier pénible, parce que chacun dépend déjà de permissions trop larges.
Organiser GitHub, GitLab et les secrets techniques
Un dépôt privé n’est pas une garantie. Les accès doivent être nominatifs, la double authentification doit être imposée et les droits d’écriture sur la branche principale doivent être restreints. Sur GitHub, les règles de protection de branche permettent d’exiger une pull request validée avant fusion.
La relecture par un pair ne sert pas seulement à repérer une variable mal nommée. Elle permet de détecter une route d’administration ouverte, une vérification d’autorisation oubliée, une requête SQL construite à la main ou un jeton exposé dans le code. Dans une petite équipe, un second regard vaut largement mieux qu’une revue automatique absente.
Les commits signés donnent une preuve technique de l’origine des modifications. Ils ne remplacent pas la revue, mais ils limitent le risque de voir un changement injecté avec une identité usurpée. GitHub affiche cette vérification dans l’historique des commits lorsque la signature est correctement configurée.
Les clés API, mots de passe et certificats ne doivent jamais être versionnés en clair. Les variables de dépôt GitHub Actions, GitLab CI/CD Variables, AWS Secrets Manager, Doppler ou HashiCorp Vault servent à injecter les secrets au moment du déploiement. Un fichier .env local doit être ignoré par Git avec un .gitignore vérifié.
Un secret déjà publié ne disparaît pas parce que le commit est supprimé. Il faut le révoquer chez le fournisseur, en générer un nouveau, puis nettoyer l’historique si nécessaire. La bonne réaction prend quelques minutes si la clé a une portée limitée ; elle devient coûteuse si elle donne des droits d’administrateur sur toute l’infrastructure.
Gérer les dépendances sans installer à l’aveugle
Une dépendance tierce apporte du code maintenu par quelqu’un d’autre dans le produit. WordPress fournit un exemple très visible : un plugin abandonné peut conserver une faille connue, même si le thème et le cœur de WordPress sont à jour. Le même problème existe avec npm, Composer, pip, Docker Hub ou les extensions de navigateur.
Chaque dépendance doit avoir une raison d’être. Installer un package pour une fonction de dix lignes de code ou ajouter cinq plugins WordPress pour modifier un formulaire crée de la dette technique et une surface d’attaque. Pour un site WordPress, vérifier la date de mise à jour, les versions PHP supportées, le nombre d’installations actives et le suivi des correctifs évite des surprises.
| Contrôle | Où l’appliquer | Risque réduit |
|---|---|---|
| Protection de branche | GitHub ou GitLab, dépôt principal | Fusion directe d’un code non revu |
| Scan de dépendances | Pipeline CI, Dependabot ou outil SCA | Bibliothèque avec faille publique |
| Secrets centralisés | Variables CI/CD ou coffre dédié | Clé exposée dans un commit |
| Données de test anonymisées | Environnements locaux et préproduction | Fuite de données de production |
Les analyses automatisées de dépendances détectent les versions concernées par des CVE, c’est-à-dire des vulnérabilités référencées publiquement. Dependabot sur GitHub, Renovate ou Snyk peuvent ouvrir des propositions de mise à jour. Ces outils n’installent pas une sécurité magique : une mise à jour majeure peut casser une API, donc chaque correctif doit passer dans un environnement de test.
La formation des développeurs doit coller au langage et à l’architecture utilisés. Une équipe Node.js doit travailler les injections, la validation des entrées et la gestion des tokens JWT. Une équipe WordPress doit apprendre à contrôler les capacités utilisateur, échapper les sorties et éviter les appels directs à la base de données.
Le développement sécurisé ne ralentit pas une équipe qui l’intègre dans ses rituels. Il évite surtout le déploiement du vendredi soir qui transforme une mise à jour de dépendance oubliée en incident client le lundi matin.
Cybersécurité des déploiements : contrôler ce qui atteint la production
Le passage du code vers la production est un point de rupture fréquent. Le produit fonctionne en local, les tests passent, puis une variable d’environnement manque, un bucket cloud est rendu public ou un compte de déploiement possède des droits capables de supprimer toute l’infrastructure.
Le guide ANSSI et French Tech insiste sur cette phase, car elle mêle code, hébergement, automatisation et fournisseurs externes. Une erreur de configuration peut avoir un effet immédiat sur les clients. Une base rendue accessible, un fichier de sauvegarde laissé dans un répertoire web ou une mise à jour non vérifiée peuvent exposer des informations en quelques minutes.
Construire un pipeline CI/CD avec des séparations nettes
CI/CD désigne l’intégration continue et le déploiement continu. Concrètement, un outil comme GitHub Actions, GitLab CI, Jenkins ou CircleCI lance des tests après chaque modification, construit une version du logiciel puis la déploie selon des règles définies. L’automatisation réduit les manipulations manuelles, source classique d’erreurs.
Les environnements doivent être distincts. Le développement sert aux essais. La préproduction reproduit les réglages utiles pour vérifier une version. La production héberge les clients. Utiliser une seule base et un seul serveur “pour aller vite” mélange les risques et rend les incidents difficiles à comprendre.
Une startup SaaS peut garder un environnement de préproduction plus petit que la production pour maîtriser ses coûts. Il doit toutefois utiliser des variables différentes, des comptes distincts et des données non réelles. L’objectif n’est pas de reproduire chaque détail à l’euro près, mais d’éviter qu’un test écrase une table utilisée par les clients.
Les artefacts construits doivent être identifiables et signés quand l’architecture le permet. Un artefact est le fichier livré par le pipeline : image Docker, archive, binaire ou package. Associer ce fichier à un commit précis permet de savoir exactement quelle version tourne en production et de revenir à une version précédente.
Le retour en arrière ne doit pas rester une phrase dans un ticket Jira. Il faut tester une restauration ou un rollback sur une version récente. Sur Kubernetes, cela passe souvent par une stratégie de déploiement documentée. Sur WordPress, cela implique une sauvegarde de fichiers et de base, puis un test de restauration sur un environnement isolé.
Journaliser pour enquêter au lieu de deviner
Les journaux enregistrent les actions utiles à une enquête : connexion d’un administrateur, changement de droit, création d’une clé, échec répété d’authentification, déploiement d’une version. Sans traces, l’équipe passe des heures à reconstruire un incident avec des souvenirs et des captures Slack.
Les logs doivent être protégés contre la modification et conservés assez longtemps pour être exploités. La durée dépend des données traitées, des obligations contractuelles et du niveau de risque. Une application qui gère des paiements ou des dossiers sensibles ne se traite pas comme une landing page hébergée sur un CDN.
La révision des droits d’administration tous les six mois donne un rythme concret. Dans une startup, la croissance est rapide et les permissions temporaires deviennent permanentes par oubli. Une personne qui a aidé à lancer une migration peut conserver un accès AWS, Vercel ou Cloudflare longtemps après la fin de sa mission.
- Le pipeline lance les tests et les analyses de code avant la construction.
- La version déployée porte un identifiant lié au commit validé.
- Les comptes de déploiement possèdent les droits minimums sur la cible.
- Le retour vers la version précédente est testé avant qu’un incident ne l’impose.
Une infrastructure cloud demande aussi une surveillance des configurations. Un groupe de sécurité AWS qui ouvre un port d’administration à tout Internet, une base MongoDB sans contrôle d’accès ou un stockage objet public ne relève pas d’une attaque sophistiquée. Ce sont des erreurs de paramétrage que des robots détectent en continu.
Les outils de gestion d’infrastructure comme Terraform ou Pulumi permettent de versionner les réglages cloud. Ils ne dispensent pas de les relire. Ils rendent en revanche les changements traçables et reproductibles, ce qui évite le serveur configuré manuellement dont personne ne connaît les règles.
La sécurité des déploiements se joue dans la répétition : même pipeline, mêmes contrôles, mêmes droits limités, plutôt qu’une procédure improvisée parce qu’un client attend une correction urgente.
Protection des données et hébergement : choisir selon le produit, pas selon une promotion
Un hébergeur à bas prix peut convenir à une page vitrine avec peu de trafic. Il devient un mauvais choix quand une application traite des données de santé, des documents RH, des informations de paiement ou des milliers de comptes utilisateurs. L’hébergement fait partie de la sécurité informatique parce qu’il détermine les sauvegardes, les accès, la localisation et la capacité à réagir.
La première distinction porte sur les responsabilités. Avec un hébergement mutualisé WordPress, le prestataire gère une part de l’infrastructure, mais la mise à jour du CMS, du thème, des extensions et des comptes administrateurs reste souvent du côté du client. Avec AWS, Scaleway, Google Cloud ou Azure, l’entreprise contrôle plus finement son architecture, donc elle porte aussi davantage de réglages.
Un serveur cloud n’est pas automatiquement plus sûr qu’un mutualisé. Une machine virtuelle Ubuntu laissée sans mises à jour, avec SSH ouvert au monde entier et un mot de passe faible, crée un risque supérieur à un WordPress correctement maintenu chez o2switch ou Infomaniak. Le choix dépend du niveau de personnalisation, du volume et des compétences disponibles.
Définir les données avant de définir la stack
La protection des données commence par un inventaire précis. Une liste d’e-mails utilisée pour une newsletter, des adresses de livraison, des pièces d’identité pour vérifier un compte et des données de santé n’exposent pas l’entreprise au même niveau de risque. Les conserver toutes “au cas où” alourdit la responsabilité sans créer de valeur.
Le RGPD impose notamment de limiter la collecte à ce qui est nécessaire, de sécuriser les traitements et d’encadrer les sous-traitants. Une startup qui utilise Stripe, Brevo, HubSpot, Intercom, Google Analytics ou un outil d’IA générative doit savoir quelles données transitent par ces services et dans quelles conditions.
Les sauvegardes sont le test de maturité le plus concret. Elles doivent être automatiques, chiffrées si elles contiennent des données personnelles, séparées de l’environnement principal et restaurables. Une sauvegarde qui n’a jamais été restaurée est une hypothèse, pas une garantie.
| Situation | Choix cohérent | Point de contrôle |
|---|---|---|
| Site WordPress vitrine | Hébergement managé ou mutualisé sérieux | Mises à jour, sauvegardes, comptes admin |
| Boutique de plusieurs centaines de commandes | WooCommerce managé ou stack e-commerce suivie | Paiement, journaux, sauvegardes quotidiennes |
| SaaS avec API et données clients | Cloud avec environnements séparés | IAM, chiffrement, réseau, supervision |
| Données très sensibles | Architecture validée avec expertise dédiée | Accès, traçabilité, exigences sectorielles |
Les prix doivent être lus avec la même rigueur que les droits d’accès. Une offre d’hébergement affichée à quelques euros mensuels TTC la première année peut remonter au renouvellement, tandis qu’un cloud facturé à l’usage varie avec le stockage, la bande passante, les sauvegardes et les services managés. Un budget sécurité réaliste inclut ces coûts, pas seulement le serveur de départ.
Le chiffrement doit être présent en transit avec HTTPS et au repos lorsque le fournisseur le propose pour les volumes, bases et sauvegardes. HTTPS n’empêche pas une fuite de base de données. Il protège la communication entre le navigateur et le serveur contre l’interception, ce qui reste indispensable pour un formulaire, un espace client ou un paiement.
Les certificats Let’s Encrypt sont adaptés à beaucoup de projets, à condition que leur renouvellement soit automatisé et surveillé. Un certificat expiré provoque des alertes navigateur immédiates, puis une perte de confiance. Ce type de panne est rarement spectaculaire techniquement, mais il bloque une vente aussi sûrement qu’une indisponibilité serveur.
Une startup qui traite ses fournisseurs comme une extension de son système d’information évite les angles morts. Les offres ne se comparent pas uniquement sur le stockage ou la RAM, mais sur les accès, les contrats, les sauvegardes et la capacité réelle à récupérer après un incident.
Les équipes qui suivent les tendances numériques de février 2026 voient passer de nouveaux outils à un rythme rapide. Chaque nouvel outil connecté à la base clients ou au compte e-mail doit pourtant être évalué comme une nouvelle porte d’entrée, pas comme une case de plus dans une stack.
Gestion des risques lors d’une levée de fonds, du travail collaboratif et du passage à l’échelle
Le passage à l’échelle change la nature du risque. Les premiers mois reposent souvent sur des échanges directs et des comptes partagés par facilité. Après une levée de fonds, un recrutement accéléré ou l’arrivée de gros clients, cette organisation devient une dette : davantage de terminaux, davantage de prestataires, davantage de données et davantage d’exigences contractuelles.
Le guide de l’ANSSI identifie 13 enjeux le long de la vie d’une startup. La sécurisation du travail collaboratif, l’hébergement, l’industrialisation du produit et la levée de fonds ne sont pas des sujets séparés. Ils se rejoignent au même endroit : l’entreprise doit démontrer qu’elle sait protéger ses actifs et continuer à fonctionner en cas d’incident.
Préparer une levée de fonds sans exposer le dossier
Une data room regroupe prévisions financières, contrats, documents juridiques, informations commerciales et parfois détails techniques. La partager avec un lien public ou un compte générique revient à perdre toute maîtrise sur sa diffusion. Les accès doivent être nominatifs, limités dans le temps et retirés dès que les discussions s’arrêtent.
Le niveau de détail technique doit être calibré. Présenter l’architecture, les mesures de protection et la roadmap rassure un investisseur. Publier des clés, des adresses IP d’administration, des exports clients ou des procédures de secours complètes dans un dossier partagé n’apporte rien à la négociation.
Les investisseurs et les grands comptes posent fréquemment des questions de sécurité lors de leur audit. Ils demandent où résident les données, comment les accès sont gérés, si les sauvegardes sont testées, comment l’entreprise réagit à un incident ou si des sous-traitants ont accès aux informations. Préparer ces réponses au fil de l’eau coûte moins cher que les reconstruire dans l’urgence.
Encadrer les usages quotidiens avec des règles praticables
Le travail hybride multiplie les contextes. Un ordinateur portable utilisé dans un train, un partage d’écran pendant une démonstration, un compte Slack connecté sur un navigateur personnel ou un fichier client téléchargé sur un disque local peuvent créer une fuite sans attaque ciblée.
Une charte de sécurité courte peut fixer les règles utiles : verrouillage automatique des postes, chiffrement des disques, mises à jour, interdiction de partager les comptes, signalement immédiat d’un e-mail suspect ou d’un appareil perdu. Le document doit correspondre aux outils réels de l’équipe. Une règle impossible à suivre sera ignorée dès la première semaine.
Les postes de travail doivent être administrés progressivement. Microsoft Intune, Jamf pour macOS ou des solutions de gestion de terminaux permettent d’imposer le chiffrement, les mises à jour et un verrouillage. Pour une équipe réduite, commencer par des comptes nominatifs, un gestionnaire de mots de passe et la double authentification apporte déjà un gain concret.
Un exercice d’incident rend la gestion des risques tangible. L’équipe peut simuler la compromission d’une boîte e-mail, l’exposition d’une clé API ou le chiffrement d’un ordinateur par rançongiciel. Il faut alors déterminer qui coupe les accès, qui contacte l’hébergeur, qui vérifie les sauvegardes et qui informe les clients concernés.
Les attaques par rançongiciel touchent aussi les petites structures parce qu’elles disposent rarement d’une équipe dédiée disponible la nuit. La meilleure réponse ne consiste pas à acheter un pare-feu au hasard. Elle repose sur des sauvegardes isolées, des mises à jour, des droits réduits, une détection des comportements anormaux et une procédure connue de tous.
La culture interne se construit par des exemples courts. Un faux e-mail de renouvellement Microsoft 365 qui demande de ressaisir un mot de passe doit être signalé, pas transféré en privé avec la phrase “ça semble bizarre”. Une alerte précoce permet de vérifier les connexions et de révoquer une session avant que le compte ne serve à piéger le reste de l’équipe.
Des formats de sensibilisation moins scolaires peuvent aider, comme les approches présentées autour de la cybersécurité ludique. Le jeu ne remplace pas les contrôles techniques, mais il donne des repères mémorables sur le phishing, les mots de passe et les réflexes face à un incident.
Le guide essentiel fourni par l’ANSSI et la Mission French Tech sert surtout à poser les bonnes décisions au bon moment. Une startup qui documente ses accès, teste ses restaurations et contrôle ses livraisons construit une sécurité compatible avec l’entrepreneuriat, au lieu de devoir reconstruire toute sa base technique sous la pression d’un audit ou d’une attaque.
Par quoi commencer la cybersécurité dans une startup de moins de dix personnes ?
Commence par les comptes qui peuvent arrêter l’activité : messagerie, nom de domaine, dépôt de code, cloud et paiement. Active la double authentification, utilise un gestionnaire de mots de passe, retire les comptes partagés et vérifie que les sauvegardes peuvent être restaurées.
Faut-il un RSSI dès la création de la startup ?
Non. Une petite équipe peut attribuer la coordination du sujet à un fondateur ou à un CTO, avec des règles écrites et des contrôles réguliers. Dès que le produit traite des données sensibles, sert de grands comptes ou subit des contraintes réglementaires fortes, un accompagnement spécialisé devient pertinent.
Pourquoi séparer développement, préproduction et production ?
Cette séparation empêche un test ou une modification de code de toucher directement les clients et leurs données. Elle permet aussi de vérifier les mises à jour, les configurations et les retours en arrière avant une mise en ligne.
Une sauvegarde cloud suffit-elle contre un rançongiciel ?
Non, si le rançongiciel peut aussi chiffrer ou supprimer la sauvegarde synchronisée. Il faut conserver des copies séparées, limiter les droits d’accès et tester une restauration sur un environnement isolé.