Cybersécurité web PME 2026 : les protections essentielles

Imaginez la scène.

Lundi matin, 8 h 17.

Votre responsable commercial vous appelle :

« Le site ne fonctionne plus. »

Vous ouvrez la page d’accueil.

À la place de votre site apparaît une erreur serveur.

Vous essayez ensuite d’accéder à l’administration.

Mot de passe incorrect.

Vous tentez l’hébergeur.

Même problème.

Quelques minutes plus tard, un membre de l’équipe vous indique qu’il ne peut plus accéder à la messagerie utilisée pour administrer les différents comptes de l’entreprise.

À 8 h 43, vous découvrez finalement qu’une règle de redirection inconnue a été ajoutée au domaine.

À 9 h 10, vous réalisez que les sauvegardes automatiques étaient stockées sur le même serveur.

À 10 h 30, un client vous transmet une capture d’un email frauduleux envoyé depuis votre adresse.

À midi, la question n’est plus :

« Comment remettre le site en ligne ? »

Mais :

« Jusqu’où l’attaquant est-il allé ? »

Cette situation n’a rien d’un scénario réservé aux grands groupes.

En 2025, Cybermalveillance.gouv.fr a accompagné plus de 500 000 victimes, soit une hausse de 20 % par rapport à l’année précédente.

Pour les entreprises et associations, le piratage de compte est devenu le premier motif d’assistance, représentant 21 % des parcours recensés.

Les violations de données ont également fortement progressé et les informations compromises alimentent ensuite des campagnes d’hameçonnage, des fraudes au virement ou de nouvelles prises de contrôle de comptes.

En parallèle, le rapport DBIR 2026 de Verizon observe à l’échelle internationale que 31 % des violations analysées commencent désormais par l’exploitation d’une vulnérabilité logicielle, tandis que les rançongiciels interviennent dans une part importante des compromissions étudiées.

Les attaquants ne cherchent donc pas uniquement un employé suffisamment distrait pour cliquer sur un email.

Ils cherchent aussi :

• un logiciel non mis à jour ;
• un plugin abandonné ;
• une API mal protégée ;
• un serveur mal configuré ;
• une clé exposée ;
• un compte administrateur sans MFA ;
• un accès prestataire oublié ;
• une sauvegarde connectée au même environnement ;
• une dépendance compromise.

Et en 2026, l’automatisation facilite encore cette recherche.

Un attaquant n’a pas besoin de connaître votre PME.

Il peut simplement scanner Internet.

Votre site peut devenir une cible parce qu’il correspond à un critère technique exploitable.

C’est probablement le concept le plus important à comprendre :

une PME n’est pas nécessairement attaquée parce qu’elle est importante ; elle peut être attaquée simplement parce qu’elle est accessible.

Le 7 septembre 2026, l’ANSSI a d’ailleurs publié les premières fiches pratiques liées au Référentiel Français de Cybersécurité, structurées notamment autour de quatre piliers : défense, protection, gouvernance et résilience.

Cette logique est intéressante même pour une entreprise qui n’est pas directement concernée par une réglementation spécifique.

La cybersécurité ne consiste pas uniquement à empêcher une intrusion.

Elle consiste également à :

réduire la probabilité qu’elle réussisse, limiter ce qu’un attaquant peut faire s’il entre, détecter suffisamment vite l’incident et être capable de reconstruire proprement.

Dans ce guide, nous allons appliquer cette logique au cas très concret d’une PME possédant :

• un site web ;
• un hébergement ou VPS ;
• une base de données ;
• des comptes administrateurs ;
• des formulaires ;
• des services cloud ;
• un domaine ;
• des prestataires ;
• parfois une application métier ou un e-commerce.

Pas besoin de disposer d’un SOC de 30 personnes.

Il faut surtout sécuriser les bons éléments dans le bon ordre.

1) Votre site web n’est qu’une partie du problème

Lorsque l’on parle de sécurité web, beaucoup d’entreprises imaginent immédiatement :

• injection SQL ;
• virus ;
• pare-feu ;
• hacker devant un terminal.

La réalité est généralement plus large.

Prenons une entreprise possédant un site WordPress.

Son site dépend peut-être :

• de WordPress ;
• de dix plugins ;
• d’un thème ;
• d’un serveur web ;
• de PHP ;
• de MySQL ;
• d’un compte d’hébergement ;
• d’un registrar ;
• d’un CDN ;
• de Cloudflare ;
• d’un compte Google ;
• d’un SMTP ;
• d’un outil de sauvegarde ;
• d’un CRM ;
• d’un formulaire connecté à Zapier ou Make ;
• d’un prestataire de paiement ;
• de plusieurs administrateurs.

La surface d’attaque réelle est donc bien plus grande que :

https://monsite.fr

Une chaîne est aussi fragile que son maillon le plus faible

Votre application peut être parfaitement développée.

Mais si la messagerie permettant de réinitialiser le mot de passe administrateur est compromise, l’attaquant contourne une partie de cette sécurité.

Même problème si :

• le registrar n’a pas de MFA ;
• la clé SSH d’un ancien prestataire fonctionne toujours ;
• une sauvegarde contient les mots de passe en clair ;
• une variable d’environnement a été publiée sur GitHub ;
• un compte développeur possède encore les droits administrateur six mois après son départ.

Commencez donc par cartographier

Listez tous les éléments permettant de contrôler ou modifier votre présence numérique.

Par exemple :

Cette simple cartographie révèle souvent des surprises.

« Ah, ce compte OVH est encore lié à l’adresse Gmail personnelle de l’ancien dirigeant. »

Ou :

« Personne ne sait qui possède l’accès au compte Cloudflare. »

Ou encore :

« Le développeur externe utilise toujours le même compte root. »

Avant de chercher une technologie sophistiquée, corrigez cela.

2) Le premier périmètre à protéger : l’identité

La sécurité informatique moderne dépend énormément de l’identité.

Qui est connecté ?

Avec quel compte ?

À quoi ce compte a-t-il accès ?

Pendant combien de temps ?

Et comment prouve-t-il réellement son identité ?

Le rapport de Cybermalveillance.gouv.fr sur 2025 place précisément le piratage de compte en tête des menaces observées chez les professionnels.

Ce n’est pas surprenant.

Un compte compromis peut parfois donner davantage de pouvoir qu’une vulnérabilité technique.

Prenons une messagerie professionnelle

Si un attaquant prend le contrôle de :

direction@entreprise.fr

il peut potentiellement :

• réinitialiser d’autres mots de passe ;
• accéder au CRM ;
• récupérer des factures ;
• observer des échanges commerciaux ;
• modifier un RIB ;
• envoyer des demandes frauduleuses ;
• usurper l’identité du dirigeant.

Votre email est donc parfois une clé maîtresse de votre entreprise.

Activez la MFA

L’ANSSI place le renforcement de l’authentification parmi ses mesures cyber préventives prioritaires.

La MFA doit être activée en priorité sur :

• messagerie ;
• registrar ;
• DNS ;
• hébergeur ;
• cloud ;
• GitHub / GitLab ;
• CMS ;
• CRM ;
• gestionnaire de sauvegarde ;
• outil de paiement ;
• comptes publicitaires ;
• VPN ;
• accès administrateurs.

Toutes les MFA ne se valent pas

Par ordre croissant de robustesse selon le contexte, on retrouve généralement :

1. code reçu par SMS ;
2. code OTP généré par une application ;
3. notification sécurisée ;
4. passkey ;
5. clé de sécurité physique compatible FIDO2/WebAuthn.

Le SMS reste souvent préférable à l’absence totale de second facteur.

Mais pour des accès particulièrement sensibles, une méthode résistante au phishing est préférable.

Attention à la récupération du compte

Vous activez une clé physique.

Excellent.

Puis le service propose :

« Mot de passe oublié ? Envoyer un code à contact@gmail.com. »

Si cette adresse est faible, vous avez créé une porte de secours beaucoup moins sécurisée que l’entrée principale.

Vérifiez donc également :

• emails de récupération ;
• téléphone ;
• codes de secours ;
• appareils autorisés ;
• sessions existantes.

3) Un mot de passe unique reste indispensable

La MFA ne signifie pas :

les mots de passe ne comptent plus.

Un problème extrêmement courant reste la réutilisation.

Même mot de passe pour :

• WordPress ;
• LinkedIn ;
• logiciel de facturation ;
• outil marketing ;
• compte personnel.

Puis l’un de ces services subit une fuite.

Les attaquants testent automatiquement le couple :

email + mot de passe

sur d’autres plateformes.

C’est le credential stuffing.

Utilisez un gestionnaire de mots de passe

Il permet de créer :

• un secret différent pour chaque service ;
• long ;
• aléatoire ;
• impossible à mémoriser.

Exemple :

J$4muR!5t9pQ#28vAKx7

Vous n’avez aucune raison de mémoriser cette chaîne.

Le gestionnaire le fait pour vous.

Pour une entreprise

Préférez un gestionnaire permettant :

• comptes professionnels séparés ;
• coffres partagés ;
• retrait immédiat d’un collaborateur ;
• journalisation ;
• MFA ;
• contrôle des droits.

Évitez :

passwords-equipe.xlsx

sur Google Drive.

Ou :

mdp serveur = Toto2026!

dans Slack.

Cela arrive encore beaucoup trop souvent.

4) Supprimez les comptes que personne n’utilise

Une PME embauche.

Elle crée :

• un email ;
• un compte CMS ;
• un accès GitHub ;
• un compte Notion ;
• un accès serveur ;
• un compte CRM.

La personne quitte l’entreprise.

L’email est supprimé.

Mais les autres accès restent.

Un an plus tard, personne ne se souvient qu’ils existent.

Créez une procédure d’arrivée et de départ

À l’arrivée :

• créer des comptes nominatifs ;
• attribuer uniquement les droits nécessaires ;
• activer la MFA ;
• enregistrer le matériel ;
• expliquer les règles.

Au départ :

• suspendre les comptes ;
• révoquer les sessions ;
• supprimer les clés SSH ;
• révoquer les tokens API ;
• modifier les secrets partagés ;
• transférer les ressources ;
• vérifier les accès tiers.

Cette procédure doit également concerner les prestataires.

Un freelance n’a probablement pas besoin d’un accès administrateur permanent pendant cinq ans.

5) Le principe du moindre privilège

Votre stagiaire marketing doit-il pouvoir :

• installer un plugin ?
• modifier les DNS ?
• supprimer les sauvegardes ?
• créer un administrateur ?

Probablement pas.

Chaque compte doit posséder uniquement les droits dont il a besoin

C’est le principe du moindre privilège.

Exemple WordPress :

• auteur ;
• éditeur ;
• administrateur.

Si une personne publie des articles, elle n’a pas besoin d’être administrateur.

Exemple GitHub :

un développeur peut contribuer à un dépôt sans nécessairement posséder tous les droits de l’organisation.

Exemple serveur :

l’application n’a normalement pas besoin de fonctionner sous root.

Pourquoi ?

Parce que vous devez toujours supposer qu’un compte peut un jour être compromis.

La bonne question devient :

Si ce compte tombe entre de mauvaises mains, jusqu’où l’attaquant peut-il aller ?

6) Le contrôle d’accès reste le risque n°1 des applications web

L’OWASP Top 10 2025 classe Broken Access Control en première position.

Ce problème ne correspond pas uniquement à :

quelqu’un a volé un mot de passe.

Il concerne surtout une application qui autorise une action qu’elle devrait interdire.

Exemple classique

Un utilisateur consulte :

/app/invoices/281

Il change l’URL :

/app/invoices/282

Et découvre la facture d’un autre client.

Le système a vérifié :

L’utilisateur est-il connecté ?

Mais pas :

Cette facture appartient-elle réellement à cet utilisateur ?

Autre exemple

Un utilisateur standard appelle directement :

DELETE /api/users/42

L’interface ne présente jamais ce bouton.

Mais l’API n’effectue pas la vérification du rôle.

L’utilisateur peut donc réaliser une action administrateur.

Le front-end n’est jamais votre barrière de sécurité

Cacher un bouton React avec :

{
  user.isAdmin && <DeleteButton />;
}

ne suffit pas.

La vérification doit être réalisée côté serveur.

Toujours.

7) Une autorisation doit être vérifiée à chaque action sensible

Pour chaque requête importante, posez trois questions :

1. Qui êtes-vous ?

Authentification.

2. Avez-vous le droit d’effectuer cette action ?

Autorisation.

3. Avez-vous le droit de l’effectuer sur CETTE ressource ?

Contrôle d’objet.

Pour un SaaS multi-tenant :

Utilisateur
→ appartient à Organisation A
→ consulte Produit 42
→ Produit 42 doit appartenir à Organisation A

Ne faites pas :

SELECT * FROM products WHERE id = 42

Puis affichez le résultat.

Faites plutôt conceptuellement :

SELECT * FROM products
WHERE id = 42
AND organization_id = currentOrganization

Le contrôle doit être inhérent à la récupération de la donnée.

8) Les mauvaises configurations passent en deuxième position dans l’OWASP 2025

L’édition 2025 de l’OWASP Top 10 classe Security Misconfiguration en deuxième position.

C’est extrêmement pertinent pour les PME.

Une compromission ne nécessite pas toujours une faille complexe.

Parfois, il suffit d’une mauvaise configuration.

Exemples

• interface admin publique inutilement ;
• port de base de données exposé ;
• bucket cloud public ;
• mode debug actif ;
• erreurs détaillées en production ;
• compte par défaut ;
• directory listing ;
• CORS trop permissif ;
• headers de sécurité absents ;
• permissions système excessives ;
• panneau de monitoring accessible sans authentification.

Le mode debug

Un message utile en développement :

DatabaseException:
password=...
host=...
query=...
stack trace...

peut devenir une fuite d’information en production.

Un utilisateur doit voir :

Une erreur est survenue.

Votre système de logging, lui, peut conserver les informations techniques nécessaires.

9) Ne laissez pas votre base de données ouverte sur Internet

Une architecture courante :

Internet
   ↓
Nginx
   ↓
Application
   ↓
PostgreSQL

La base n’a généralement aucune raison d’être accessible directement depuis tout Internet.

Idéalement :

Internet
   ↓
Ports 80 / 443
   ↓
Application
   ↓
Réseau privé
   ↓
PostgreSQL

Si un accès distant est nécessaire

Limitez-le :

• VPN ;
• tunnel SSH ;
• IP autorisée ;
• réseau privé ;
• bastion.

Et utilisez :

• compte nominatif ;
• chiffrement ;
• authentification robuste ;
• logs.

Ne laissez pas :

0.0.0.0/0 → PostgreSQL 5432

par confort.

10) Un VPS n’est pas sécurisé simplement parce qu’il fonctionne

Vous commandez un VPS.

Vous installez :

nginx
node
postgresql

Le site répond.

Le projet est terminé ?

Non.

Un serveur en production nécessite également

• mises à jour système ;
• firewall ;
• SSH sécurisé ;
• comptes séparés ;
• services minimum ;
• journalisation ;
• sauvegardes ;
• supervision ;
• rotation des logs ;
• protection des secrets ;
• stratégie de restauration.

Évitez le login SSH root direct

Créez un utilisateur d’administration.

Utilisez une clé SSH.

Limitez ou désactivez :

• connexion root directe ;
• authentification SSH par mot de passe lorsqu’elle n’est pas nécessaire.

Firewall

N’exposez que ce qui doit l’être.

Typiquement :

22   SSH — idéalement restreint
80   HTTP
443  HTTPS

Pas :

3000
5432
6379
8080
9000

simplement parce que les services utilisent ces ports localement.

11) Ne mettez jamais vos secrets dans le dépôt Git

Un développeur ajoute :

DATABASE_URL=postgresql://...
STRIPE_SECRET_KEY=...
SMTP_PASSWORD=...
OPENAI_API_KEY=...

Puis :

git add .
git commit
git push

Quelques secondes plus tard, le secret est dans l’historique Git.

Même s’il supprime ensuite le fichier.

.gitignore ne protège pas un secret déjà commité

Vous devez :

1. considérer le secret comme compromis ;
2. le révoquer ;
3. générer un nouveau secret ;
4. nettoyer l’historique lorsque nécessaire ;
5. vérifier les accès.

Ne vous contentez pas de supprimer la ligne.

Utilisez

• variables d’environnement ;
• secrets CI/CD ;
• secret manager ;
• droits minimum ;
• rotation régulière selon la criticité.

12) Séparez développement, staging et production

Mauvaise architecture :

Même base
Même compte admin
Même bucket
Même token
Même secret

pour :

• local ;
• staging ;
• production.

Une compromission du staging devient alors une compromission de production.

Préférez

Développement

données fictives ou anonymisées.

Staging

infrastructure séparée.

Production

secrets spécifiques.

Ne clonez pas automatiquement les données clients en local

Un développeur travaillant depuis un ordinateur portable n’a probablement pas besoin d’un dump complet contenant :

• noms ;
• emails ;
• numéros ;
• commandes ;
• adresses ;
• tokens.

Utilisez des données synthétiques ou anonymisées lorsque possible.

13) Les dépendances deviennent une priorité

L’OWASP Top 10 2025 place les Software Supply Chain Failures en troisième position.

C’est un changement particulièrement important.

Une application moderne contient énormément de code que votre équipe n’a pas écrit.

Un projet JavaScript peut dépendre de :

• Next.js ;
• React ;
• Prisma ;
• Zod ;
• date-fns ;
• dizaines de packages directs ;
• centaines de dépendances transitives.

Laravel possède son propre écosystème Composer.

WordPress ajoute des plugins.

Votre sécurité dépend donc aussi de fournisseurs tiers

Il faut connaître :

• vos dépendances ;
• leurs versions ;
• leur état de maintenance ;
• les vulnérabilités connues ;
• leur provenance.

Automatisez une partie du suivi

Selon votre stack :

npm audit

ou :

composer audit

et des outils comme :

• Dependabot ;
• Renovate ;
• scanners SCA ;
• alertes GitHub.

Mais attention :

« 52 vulnerabilities found »

ne signifie pas automatiquement :

« votre site est piraté ».

Chaque vulnérabilité doit être contextualisée.

14) Mettre à jour vite, mais pas aveuglément

Deux erreurs opposées existent.

Erreur 1

Ne jamais mettre à jour.

Erreur 2

Déployer automatiquement toute nouvelle version critique en production sans test.

Une bonne stratégie utilise :

• inventaire ;
• priorisation ;
• staging ;
• tests ;
• fenêtre de déploiement ;
• rollback.

Lorsqu’une vulnérabilité critique est publiée

Demandez :

1. Utilisons-nous réellement le composant ?
2. Quelle version ?
3. Le code vulnérable est-il exposé ?
4. Existe-t-il un correctif ?
5. Existe-t-il une mitigation temporaire ?
6. Peut-on détecter une exploitation ?
7. Quelle vitesse de patch est nécessaire ?

La réponse peut parfois être :

mise à jour immédiate.

Et parfois :

package présent uniquement dans le tooling de développement, fonction vulnérable jamais utilisée.

Le risque est contextuel.

15) Un plugin WordPress inutile est une surface d’attaque inutile

Votre site utilise :

37 plugins.

Mais seuls 18 sont réellement nécessaires.

Les autres :

• sont désactivés ;
• ont été installés pour tester ;
• remplacent une fonctionnalité aujourd’hui native ;
• ne sont plus maintenus.

Chaque extension supplémentaire ajoute :

• du code ;
• une dépendance ;
• une configuration ;
• une possibilité de vulnérabilité.

Nettoyez

Supprimez réellement :

• plugins inutiles ;
• thèmes inutiles ;
• comptes inutiles.

Ne vous contentez pas de désactiver.

Vérifiez également

• date de dernière mise à jour ;
• compatibilité ;
• réputation de l’éditeur ;
• historique de vulnérabilités ;
• nombre d’installations pertinentes.

Un plugin abandonné depuis trois ans doit vous poser question.

16) HTTPS est indispensable, mais ne sécurise pas votre application

Le cadenas signifie principalement :

la connexion entre le navigateur et le serveur est chiffrée et le certificat correspond au domaine.

Il ne signifie pas :

• application sans faille ;
• entreprise de confiance ;
• absence de malware ;
• formulaire sécurisé ;
• paiement légitime.

Un site de phishing peut parfaitement utiliser HTTPS.

Malgré cela, HTTPS reste indispensable

Tout le trafic doit être chiffré.

Évitez :

http://

pour les interfaces internes ou d’administration.

Utilisez :

• TLS moderne ;
• renouvellement automatique ;
• redirection HTTP → HTTPS.

17) Les headers de sécurité sont utiles, mais ce ne sont pas des talismans

Certaines protections navigateur peuvent réduire différents risques.

Par exemple :

• Content-Security-Policy ;
• Strict-Transport-Security ;
• X-Content-Type-Options ;
• Referrer-Policy ;
• Permissions-Policy.

CSP

Une Content Security Policy correctement construite peut notamment limiter les sources autorisées à exécuter du JavaScript.

Mais :

script-src * 'unsafe-inline' 'unsafe-eval'

réduit fortement son intérêt.

Commencez progressivement

Déployez éventuellement la CSP en mode report-only.

Analysez.

Corrigez les dépendances.

Puis durcissez.

Une politique copiée depuis Stack Overflow sans comprendre les ressources utilisées risque surtout de casser votre site.

18) L’injection existe toujours

L’OWASP Top 10 2025 conserve les injections parmi les risques majeurs.

L’exemple classique est SQL.

Mauvais :

const query = "SELECT * FROM users WHERE email = '" + email + "'";

Meilleur :

utiliser des requêtes paramétrées ou l’ORM correctement.

Mais l’injection ne concerne pas uniquement SQL

On rencontre également :

• commandes système ;
• LDAP ;
• templates ;
• NoSQL ;
• expressions ;
• prompts dans certains contextes IA.

Le principe est le même :

ne mélangez pas directement une donnée utilisateur non fiable et une instruction interprétée.

19) Valider une donnée ne signifie pas seulement vérifier son format

Prenons :

{
  "price": -5000
}

Techniquement :

c’est un nombre.

Mais votre logique métier autorise-t-elle un prix négatif ?

Il existe plusieurs niveaux

Syntaxique

Est-ce un email valide ?

Type

Est-ce un entier ?

Métier

Cette valeur est-elle autorisée ?

Autorisation

Cet utilisateur peut-il la modifier ?

Exemple

Un formulaire accepte :

role = ADMIN

Vous avez validé :

role appartient bien à l’enum.

Mais vous avez oublié :

un utilisateur standard ne devrait jamais pouvoir modifier son propre rôle.

20) Les uploads de fichiers doivent être traités comme hostiles

Votre formulaire permet d’envoyer :

devis.pdf

Très pratique.

Mais qu’acceptez-vous réellement ?

Un attaquant peut essayer :

• fichier exécutable ;
• SVG contenant du script ;
• document malveillant ;
• fichier énorme ;
• extension trompeuse ;
• nom de fichier manipulé.

Bonnes pratiques

• limiter la taille ;
• limiter les formats ;
• vérifier le type réel ;
• renommer côté serveur ;
• stocker hors du répertoire exécutable ;
• scanner si le contexte le justifie ;
• ne jamais faire confiance au nom fourni.

Mauvais :

/uploads/<?php system($_GET["cmd"]); ?>.php

puis serveur configuré pour exécuter du PHP dans ce dossier.

Vous comprenez le problème.

21) Le formulaire de contact peut devenir une infrastructure d’attaque

Même un simple formulaire mérite des protections.

Risques :

• spam ;
• flood ;
• injection ;
• abus SMTP ;
• stockage de contenu malveillant ;
• consommation de ressources.

Ajoutez selon le besoin

• validation serveur ;
• rate limiting ;
• protection anti-bot ;
• taille maximale ;
• normalisation ;
• monitoring.

Attention au CAPTCHA

Un CAPTCHA peut réduire certains abus.

Mais ce n’est pas une stratégie de sécurité complète.

Il peut également :

• nuire à l’accessibilité ;
• diminuer la conversion ;
• être contourné.

Utilisez-le lorsque nécessaire, pas automatiquement.

22) Le rate limiting est souvent sous-estimé

Un endpoint :

POST /api/login

sans limite peut subir :

• brute force ;
• credential stuffing.

Un endpoint :

POST /api/send-reset-password

peut être utilisé pour envoyer des milliers d’emails.

Un endpoint IA peut générer une facture énorme.

Limitez selon

• IP ;
• utilisateur ;
• organisation ;
• endpoint ;
• fenêtre temporelle.

Exemple conceptuel :

5 tentatives de connexion / minute / compte

Mais adaptez.

Une limite trop stricte peut bloquer vos utilisateurs légitimes.

23) Attention aux API : elles deviennent souvent votre vrai produit

Dans une application moderne :

React / Next.js
        ↓
       API
        ↓
    Services
        ↓
    Database

L’interface peut être très sécurisée visuellement.

Mais si l’API accepte tout, le système reste vulnérable.

Auditez notamment

• authentification ;
• autorisation ;
• validation ;
• pagination ;
• rate limit ;
• exposition des données ;
• CORS ;
• erreurs ;
• logs.

Ne renvoyez pas un objet utilisateur complet par facilité

Exemple :

{
  "id": 12,
  "name": "Martin",
  "email": "...",
  "passwordHash": "...",
  "resetToken": "...",
  "internalNotes": "..."
}

Puis masquer certains champs dans le front.

La donnée sensible a déjà quitté le serveur.

Sélectionnez uniquement ce qui est nécessaire.

24) Les clés API doivent avoir le moins de pouvoir possible

Une même clé Stripe ou cloud utilisée partout augmente le rayon d’impact.

Lorsque le fournisseur le permet :

• créez des clés par usage ;
• limitez les permissions ;
• séparez staging et production ;
• documentez le propriétaire ;
• révoquez les clés inutilisées.

Rotation

Ne signifie pas nécessairement :

tout changer tous les sept jours.

Cela signifie surtout disposer d’une capacité à :

• identifier ;
• révoquer ;
• remplacer ;
• propager correctement.

Lorsqu’un secret fuite, vous devez pouvoir réagir rapidement.

25) Sécurisez votre pipeline CI/CD

Votre pipeline de déploiement peut posséder :

• clé SSH ;
• token cloud ;
• secrets ;
• droit de pousser en production.

Il est donc extrêmement intéressant pour un attaquant.

Protégez

• comptes GitHub/GitLab avec MFA ;
• branches principales ;
• pull requests ;
• secrets ;
• runners ;
• actions tierces ;
• environnements de production.

Évitez

push sur main
→ déploiement production

avec aucun contrôle sur un projet critique.

Ajoutez selon les besoins :

• review obligatoire ;
• CI ;
• tests ;
• environnement protégé ;
• validation manuelle pour production.

26) Les dépendances CI/CD sont également des dépendances

Votre fichier :

uses: third-party/action@main

signifie potentiellement :

exécuter du code provenant d’un tiers dans un environnement possédant des secrets.

Préférez lorsque pertinent :

• actions reconnues ;
• versions précises ;
• commits épinglés ;
• permissions minimales.

La chaîne d’approvisionnement ne s’arrête pas au package.json.

27) Le domaine est l’un de vos actifs numériques les plus critiques

Imaginez qu’un attaquant contrôle votre DNS.

Il peut potentiellement :

• rediriger votre site ;
• modifier les MX ;
• détourner certains sous-domaines ;
• perturber vos services.

Sécurisez le registrar

MFA.

Compte nominatif.

Email de récupération robuste.

Verrouillage de transfert.

Contacts à jour.

DNSSEC

Lorsqu’il est correctement configuré et adapté à votre environnement, DNSSEC permet d’ajouter une validation cryptographique des réponses DNS.

Mais une mauvaise migration DNSSEC peut également provoquer une indisponibilité.

Documentez avant de modifier.

28) L’email mérite sa propre stratégie

Votre domaine est :

entreprise.fr

Vous envoyez des emails.

Configurez correctement :

• SPF ;
• DKIM ;
• DMARC.

Pourquoi ?

Réduire la capacité de tiers à usurper facilement votre domaine dans certaines situations.

DMARC

Ne passez pas nécessairement immédiatement à :

p=reject

si vous ignorez tous les services qui envoient des emails au nom de votre domaine.

Commencez par inventorier :

• Google Workspace ;
• Microsoft 365 ;
• CRM ;
• newsletter ;
• facturation ;
• support ;
• application.

Puis surveillez les rapports et durcissez progressivement.

29) Vos sauvegardes sont votre assurance technique

Un ransomware chiffre votre serveur.

Vous répondez :

Pas grave, on a des sauvegardes.

Puis vous découvrez que le ransomware a également chiffré :

/backups

Parce que le disque de sauvegarde était monté en permanence.

Vous n’aviez pas réellement une stratégie de sauvegarde.

Vous aviez une copie supplémentaire accessible depuis le système compromis.

La règle 3-2-1

L’ANSSI recommande notamment :

3 copies des données

La production + deux sauvegardes.

2 supports distincts

Pour éviter un même point de défaillance.

1 copie hors ligne

Déconnectée du système d’information.

30) Une sauvegarde non testée n’est qu’une hypothèse

Vous recevez chaque nuit :

Backup successful.

Très bien.

Avez-vous déjà restauré ?

Les sauvegardes échouent parfois silencieusement

Exemples :

• fichiers présents mais base absente ;
• dump SQL corrompu ;
• clé de chiffrement perdue ;
• version incompatible ;
• média inaccessible ;
• sauvegarde partielle ;
• accès perdu.

Testez la restauration

Par exemple chaque trimestre pour une PME classique, ou plus souvent selon la criticité.

Mesurez :

RPO — Recovery Point Objective

Combien de données pouvez-vous perdre ?

RTO — Recovery Time Objective

Combien de temps pouvez-vous rester indisponible ?

Exemple

RPO :

24 heures.

RTO :

4 heures.

Cela signifie :

nous acceptons au maximum 24 heures de perte de données et nous visons une restauration en moins de quatre heures.

Une sauvegarde quotidienne peut répondre au premier objectif.

Mais si sa restauration nécessite deux jours, elle ne répond pas au second.

31) Sauvegardez plus que la base de données

Pour restaurer un service, vous pouvez avoir besoin de :

• base ;
• uploads ;
• fichiers ;
• variables ;
• configuration serveur ;
• DNS ;
• règles firewall ;
• cron ;
• certificats ;
• configuration reverse proxy.

Infrastructure as Code

Lorsque pertinent, conserver une partie de la configuration sous forme de code permet de reconstruire plus rapidement.

Mais attention :

configuration versionnée

ne signifie pas :

secrets versionnés.

32) Les sauvegardes doivent aussi être protégées contre vous

Un administrateur compromis peut tenter de supprimer les sauvegardes.

Utilisez lorsque possible :

• immutabilité ;
• verrouillage ;
• rétention ;
• compte séparé ;
• MFA.

Le compte qui administre votre application ne devrait idéalement pas posséder automatiquement la capacité de supprimer toutes les sauvegardes.

33) La supervision est ce qui transforme une attaque invisible en incident détectable

Vous pouvez avoir :

• firewall ;
• MFA ;
• WAF ;
• sauvegardes.

Aucun système n’est infaillible.

Il vous faut savoir lorsqu’un comportement anormal se produit.

L’ANSSI inclut justement l’amélioration de la supervision parmi ses mesures préventives prioritaires.

Surveillez au minimum

Disponibilité

Le site répond-il ?

Erreurs

Hausse brutale des 500 ?

Authentification

Nombre inhabituel d’échecs ?

Comptes admin

Nouvelle création ?

Serveur

CPU, RAM, disque.

Base

Connexions anormales.

Déploiements

Qui a déployé quoi et quand ?

Certificats

Expiration.

Backups

Succès ou échec.

34) Les logs doivent répondre à une question

Accumuler 800 Go de logs sans jamais les consulter ne sert pas à grand-chose.

Un bon log doit permettre de comprendre :

• quoi ;
• quand ;
• qui ;
• d’où ;
• avec quel résultat.

Exemple

Mauvais :

Error

Meilleur :

2026-09-21T13:22:14Z
AUTH_FAILURE
user_id=742
ip=203.0.113.12
method=password
reason=invalid_credentials

Mais attention aux données sensibles

Ne loguez pas :

• mot de passe ;
• numéro de carte complet ;
• token ;
• secret ;
• cookie de session.

Un système de logs peut lui-même devenir une fuite de données.

35) Créez des alertes réellement exploitables

Si votre monitoring envoie 600 alertes par jour, personne ne les lit.

C’est le syndrome :

tout est urgent donc rien ne l’est.

Créez des niveaux.

Critique

• production indisponible ;
• backup en échec plusieurs fois ;
• espace disque presque plein ;
• tentative de connexion admin inhabituelle ;
• certificat proche expiration critique.

Attention

• hausse d’erreurs ;
• latence ;
• pic de consommation.

Information

• déploiement effectué ;
• tâche terminée.

Une alerte doit idéalement répondre à :

Qui doit agir ?

Sous combien de temps ?

Quelle première vérification effectuer ?

36) Le WAF est utile, mais ce n’est pas une armure magique

Un Web Application Firewall peut filtrer :

• certains patterns d’attaque ;
• bots ;
• scans ;
• requêtes malveillantes connues.

C’est utile.

Particulièrement pour les services exposés à Internet.

Mais imaginez :

Votre endpoint :

GET /api/customer/42

renvoie les données du client 42 à n’importe quel utilisateur connecté.

Le WAF ne sait pas nécessairement que :

l’utilisateur 17 ne doit pas accéder au client 42.

C’est une faille logique.

Elle doit être corrigée dans l’application.

Défense en profondeur

Votre sécurité peut comprendre :

CDN / Anti-DDoS
      ↓
WAF
      ↓
Reverse Proxy
      ↓
Application
      ↓
Contrôles d’autorisation
      ↓
Database

Aucune couche ne remplace les autres.

37) Un antivirus ne protège pas un serveur mal configuré

Même logique.

L’antivirus peut détecter certaines menaces.

Mais il ne corrige pas :

database accessible avec mot de passe admin/admin

ou :

S3 bucket public

La cybersécurité moderne repose sur plusieurs couches :

• prévention ;
• réduction des privilèges ;
• segmentation ;
• détection ;
• sauvegarde ;
• réponse.

38) Le facteur humain ne se résume pas à « former les employés »

Oui, la sensibilisation est importante.

Mais dire :

l’humain est le maillon faible

est une manière paresseuse de penser la sécurité.

Un bon système suppose qu’un humain peut :

• cliquer ;
• se tromper ;
• être fatigué ;
• être manipulé.

Puis limite l’impact.

Exemple

Un employé saisit son mot de passe sur une fausse page.

Sans MFA :

compte compromis.

Avec MFA OTP :

attaque plus difficile, mais certaines méthodes peuvent contourner.

Avec passkey résistante au phishing :

risque fortement réduit dans ce scénario.

Le système doit aider l’utilisateur

La sécurité n’est pas uniquement :

ne cliquez jamais.

Elle est aussi :

même si quelqu’un clique, que se passe-t-il ensuite ?

39) Les fraudes au virement nécessitent des procédures métier

Cybermalveillance.gouv.fr constate également une forte présence des fraudes au virement dans les incidents touchant les professionnels.

Le problème ne se résout pas uniquement avec un antivirus.

Créez une procédure

Tout changement de RIB significatif nécessite par exemple :

1. vérification via un deuxième canal ;
2. contact connu ;
3. validation par une seconde personne au-delà d’un seuil.

Si vous recevez :

« Nous avons changé de banque, voici notre nouveau RIB »

n’utilisez pas le numéro indiqué dans cet email pour vérifier.

Utilisez les coordonnées déjà connues.

Même principe pour un dirigeant

Email :

« Je suis en réunion. Fais un virement urgent de 28 000 €. Ne m’appelle pas. »

Votre procédure doit être conçue pour résister à l’autorité et à l’urgence.

40) L’IA augmente la qualité de certaines attaques

IBM indique dans son rapport Cost of a Data Breach 2026 que les attaques assistées par IA progressent fortement à l’échelle mondiale.

Cela ne signifie pas :

une superintelligence va pirater votre PME demain.

L’impact concret est souvent beaucoup plus simple.

L’IA réduit le coût de production de :

• messages de phishing ;
• traductions ;
• personnalisation ;
• deepfakes ;
• scripts ;
• reconnaissance.

Le phishing devient plus crédible

Avant :

Cher client votre compte sera fermer cliquez lien.

Aujourd’hui :

Bonjour Alexandre, Nous avons détecté une anomalie sur votre dernière facture OVH liée au renouvellement de analy.fr. Le prélèvement n’a pas pu être validé. Vous disposez de 24 heures avant suspension du service.

Le message peut contenir :

• votre nom ;
• votre entreprise ;
• votre fournisseur ;
• votre domaine.

Ces informations sont souvent publiques.

La défense doit donc moins dépendre de la détection grammaticale

« Regardez les fautes » est devenu insuffisant.

Apprenez plutôt à vérifier :

• domaine ;
• URL ;
• contexte ;
• demande inhabituelle ;
• urgence ;
• changement financier ;
• méthode d’authentification.

41) Cas pratique : le site WordPress d’une PME

Prenons une PME fictive.

Site :

WordPress.

Chiffre d’affaires :

3 M€.

Le site génère :

70 demandes mensuelles.

Architecture

• hébergement mutualisé ;
• WordPress ;
• 31 plugins ;
• formulaire ;
• SMTP ;
• sauvegardes automatiques.

Faiblesses découvertes

• plugin inutilisé depuis deux ans ;
• deux anciens administrateurs ;
• même mot de passe partagé ;
• aucune MFA ;
• sauvegardes sur le même hébergement ;
• compte registrar lié à une boîte personnelle.

Coût des corrections

Supposons :

15 heures de travail.

À 75 € / heure :

1 125 €.

Ajout d’un service externe de sauvegarde :

30 € / mois.

Incident évité ?

Impossible à promettre.

La cybersécurité n’est pas une assurance mathématique.

Mais l’entreprise élimine plusieurs chemins d’attaque évidents.

Le ROI doit donc être considéré comme :

réduction de probabilité × réduction de l’impact.

Pas :

X euros investis = aucune attaque.

42) Cas pratique : une application Next.js sur VPS

Architecture :

Nginx
↓
Next.js
↓
PostgreSQL

Déploiement via GitHub Actions.

Audit

On découvre :

5432 ouvert publiquement

SSH :

PermitRootLogin yes
PasswordAuthentication yes

Application :

fonctionne sous un utilisateur trop privilégié.

Secrets :

présents dans un ancien commit Git.

Backup :

dump quotidien stocké dans /var/backups.

Priorité

Immédiat

• rotation des secrets ;
• fermeture DB publique ;
• contrôle historique Git ;
• modification SSH ;
• firewall.

Semaine suivante

• compte de déploiement ;
• sauvegarde externe ;
• MFA GitHub ;
• règles de branches ;
• monitoring.

Mois suivant

• procédure de restauration ;
• durcissement ;
• revue des dépendances ;
• audit des autorisations.

Le problème n’était pas une injection SQL sophistiquée.

C’était principalement l’architecture.

43) Cas pratique : SaaS multi-tenant

Votre SaaS possède 200 entreprises clientes.

Chaque entreprise a ses utilisateurs.

Une API :

GET /api/orders/:id

authentifie correctement l’utilisateur.

Mais oublie la vérification du tenant.

Attaque

Client A appelle :

/orders/9211

Puis :

/orders/9212
/orders/9213
/orders/9214

Il récupère potentiellement les commandes d’autres entreprises.

Conséquence

Vous pouvez disposer :

• de MFA ;
• de Cloudflare ;
• d’un SOC ;
• d’un certificat SSL ;
• de backups.

La faille existe quand même.

Correction

Chaque requête métier doit intégrer le périmètre :

order.id = requestedId
AND
order.organizationId = currentOrganizationId

Puis tests automatiques :

un utilisateur d’une organisation A ne peut jamais accéder à une ressource B.

C’est typiquement le genre de contrôle qu’un test fonctionnel de sécurité peut verrouiller durablement.

44) Cas pratique : e-commerce et script tiers

Votre boutique charge :

• analytics ;
• chat ;
• pixels ;
• système d’avis ;
• paiement ;
• A/B testing.

Chaque script exécuté dans le navigateur augmente la complexité.

L’OWASP possède d’ailleurs désormais des travaux spécifiques sur les risques côté client, car les applications modernes intègrent de nombreux scripts et services tiers.

Risque

Un fournisseur tiers compromis peut injecter du code dans votre page.

Dans certains scénarios, cela peut permettre de récupérer :

• données saisies ;
• informations de session ;
• comportement utilisateur.

Mesures

• limiter les scripts ;
• auditer leur nécessité ;
• CSP ;
• SRI lorsque adapté ;
• gestionnaire de tags contrôlé ;
• environnement de paiement isolé ;
• surveillance.

Le marketing doit lui aussi participer à la sécurité.

45) Préparez l’incident avant qu’il arrive

L’une des erreurs les plus coûteuses est de découvrir pendant l’attaque :

personne ne sait quoi faire.

Créez une fiche d’urgence

Elle peut tenir sur deux pages.

Contenu :

Contacts

• dirigeant ;
• CTO / prestataire ;
• hébergeur ;
• assurance cyber ;
• juridique ;
• DPO si applicable.

Accès

• où sont les sauvegardes ?
• qui possède les codes de secours ?
• comment couper un compte ?

Décisions

• qui peut couper la production ?
• qui communique avec les clients ?
• qui contacte l’hébergeur ?

Preuves

• où sont les logs ?
• combien de temps sont-ils conservés ?

46) La première réaction ne doit pas être « tout effacer »

Vous découvrez un serveur compromis.

Réflexe :

rm -rf
reinstall

Vous risquez de détruire des éléments utiles à l’analyse.

Avant de reconstruire, selon la gravité

• documentez ;
• horodatez ;
• préservez les logs ;
• identifiez les accès ;
• isolez si nécessaire ;
• sauvegardez les preuves pertinentes.

Puis reconstruisez à partir d’une source de confiance.

Pourquoi ?

Sinon vous ne saurez peut-être jamais :

• quand l’attaquant est entré ;
• ce qu’il a consulté ;
• s’il possède encore un accès ;
• quelles données sont concernées.

47) Changer le mot de passe ne suffit pas toujours

Un compte a été compromis.

Vous changez le mot de passe.

Terminé ?

Peut-être pas.

L’attaquant peut posséder :

• session active ;
• token ;
• clé API ;
• clé SSH ;
• application OAuth ;
• règle de transfert email ;
• second compte administrateur.

Réponse plus complète

• changer le secret ;
• révoquer toutes les sessions ;
• retirer tokens ;
• vérifier applications connectées ;
• examiner les règles email ;
• vérifier nouveaux comptes ;
• vérifier MFA ;
• revoir les logs.

Pensez :

persistance.

48) En cas de violation de données, le chrono juridique peut démarrer

Le RGPD impose une gestion spécifique des violations de données personnelles.

Lorsqu’une violation présente un risque pour les droits et libertés des personnes, le responsable du traitement doit notifier la CNIL dans les meilleurs délais et, si possible, au plus tard dans les 72 heures après en avoir pris connaissance.

Si le risque est élevé, les personnes concernées peuvent également devoir être informées.

Cela ne signifie pas

toute panne doit être déclarée à la CNIL.

Une violation de données implique une atteinte à :

• confidentialité ;
• intégrité ;
• disponibilité

de données personnelles.

Documentez chaque incident

Même lorsqu’aucune notification n’est nécessaire, le RGPD prévoit une documentation interne des violations.

49) NIS 2 : ne transformez pas le sujet en simple checklist marketing

En septembre 2026, les travaux français autour de NIS 2 et du Référentiel Français de Cybersécurité renforcent la pression vers une gestion plus structurée du risque.

Les nouvelles fiches ReCyF publiées par l’ANSSI sont notamment organisées autour de :

• défense ;
• protection ;
• gouvernance ;
• résilience ;
• obligations NIS 2.

Mais attention

Une PME ne doit pas conclure automatiquement :

nous sommes concernés.

Le périmètre dépend notamment :

• du secteur ;
• de l’activité ;
• de la taille ;
• de certaines caractéristiques juridiques.

Si votre entreprise peut entrer dans le champ, réalisez une analyse spécifique.

Dans tous les cas

Les principes restent intéressants :

• gouverner les identités ;
• sécuriser l’architecture ;
• détecter ;
• prévoir la continuité ;
• organiser la réponse.

La conformité ne devrait jamais être l’unique motivation.

Une entreprise peut être :

conforme sur le papier

et vulnérable dans les faits.

50) Audit de sécurité : par où commencer ?

Vous n’avez pas besoin de commencer par un pentest de trois semaines.

D’abord, vérifiez les fondamentaux.

Niveau 1 — Identités

• MFA ?
• comptes anciens ?
• mots de passe partagés ?
• accès prestataires ?
• recovery sécurisé ?

Niveau 2 — Infrastructure

• services exposés ?
• firewall ?
• versions ?
• comptes root ?
• backups ?

Niveau 3 — Application

• authentification ?
• autorisations ?
• API ?
• validation ?
• uploads ?
• secrets ?

Niveau 4 — Supply chain

• dépendances ?
• CI/CD ?
• packages ?
• actions GitHub ?

Niveau 5 — Détection

• logs ?
• alertes ?
• monitoring ?

Niveau 6 — Résilience

• restauration testée ?
• contacts ?
• plan d’incident ?

Cette progression apporte souvent beaucoup plus de valeur qu’un scan automatique lancé sans contexte.

51) Un scanner n’est pas un audit

Vous lancez un outil.

Résultat :

87 vulnerabilities

Cela semble impressionnant.

Mais :

• certaines sont des faux positifs ;
• certaines n’ont aucun impact ;
• certaines sont critiques ;
• certaines nécessitent une compréhension métier.

Le travail important commence ensuite

Il faut analyser :

Exploitabilité

Peut-on réellement l’exploiter ?

Impact

Que peut obtenir l’attaquant ?

Exposition

Internet ou réseau interne ?

Complexité

Authentification nécessaire ?

Actifs

Quelles données ?

Puis prioriser.

52) Priorisez par risque, pas par peur

Vous avez deux problèmes.

Vulnérabilité A

Score CVSS élevé.

Affecte un service interne inaccessible depuis Internet.

Nécessite un compte administrateur.

Vulnérabilité B

Score légèrement inférieur.

Affecte votre formulaire public.

Exploit sans authentification.

Expose les données clients.

Laquelle corriger en premier ?

Probablement B.

Une priorisation simple

Le score automatique aide.

Il ne remplace pas le contexte.

53) Les cinq priorités ANSSI sont un excellent point de départ

L’ANSSI a déjà synthétisé cinq mesures préventives prioritaires :

1. Renforcer l’authentification

MFA.

2. Accroître la supervision de sécurité

Détecter.

3. Sauvegarder hors ligne les données et applications critiques

Pouvoir reconstruire.

4. Établir une liste priorisée des services numériques critiques

Savoir ce qui compte.

5. Disposer d’un dispositif de gestion de crise

Pouvoir agir.

Pour une PME qui se demande :

Par où commencer ?

Cette liste est remarquablement pragmatique.

54) Identifiez vos services critiques

Listez :

• site ;
• e-commerce ;
• CRM ;
• messagerie ;
• ERP ;
• stockage ;
• application métier ;
• facturation.

Puis posez :

Si ce service tombe pendant quatre heures, que se passe-t-il ?

Puis :

24 heures ?

Puis :

trois jours ?

Classez

Critique

Arrêt de l’activité.

Important

Dégradation sérieuse.

Secondaire

Contournement possible.

Cette classification détermine :

• fréquence des backups ;
• monitoring ;
• RTO ;
• investissement.

55) La sécurité doit être proportionnée

Une boutique de quartier et une fintech ne nécessitent pas exactement le même dispositif.

La cybersécurité ne signifie pas :

appliquer absolument toutes les protections existantes.

Il faut arbitrer selon :

• données ;
• exposition ;
• activité ;
• dépendances ;
• impact ;
• obligations.

Le bon niveau n’est pas zéro risque

Impossible.

Le bon objectif est :

réduire le risque à un niveau acceptable et être préparé lorsque quelque chose échoue.

56) Plan d’action cybersécurité sur 90 jours

Jours 1 à 15 — Inventorier

Listez :

• services ;
• domaines ;
• comptes ;
• administrateurs ;
• serveurs ;
• dépôts ;
• prestataires ;
• sauvegardes.

Identifiez les responsables.

Jours 16 à 30 — Fermer les portes évidentes

Activez la MFA.

Supprimez les comptes inutiles.

Fermez les ports.

Mettez à jour.

Révoquez les secrets exposés.

Contrôlez le registrar.

Jours 31 à 45 — Sécuriser l’application

Revoyez :

• contrôle d’accès ;
• API ;
• validation ;
• uploads ;
• rate limiting ;
• secrets ;
• dépendances.

Jours 46 à 60 — Construire la résilience

Appliquez une vraie stratégie de sauvegarde.

Ajoutez une copie hors ligne ou protégée.

Testez une restauration.

Définissez RPO / RTO.

Jours 61 à 75 — Détecter

Configurez :

• uptime ;
• logs ;
• alertes ;
• erreurs ;
• sauvegardes ;
• connexions inhabituelles.

Jours 76 à 90 — Préparer l’incident

Créez :

• fiche de crise ;
• liste de contacts ;
• procédure d’isolation ;
• procédure de récupération ;
• procédure de notification.

Puis simulez.

« Il est 9 h, GitHub et l’hébergeur sont compromis. Que faisons-nous ? »

Vous découvrirez les trous avant l’attaquant.

57) Checklist — Comptes et identités

• Tous les comptes critiques sont nominatifs.
• MFA activée.
• Gestionnaire de mots de passe.
• Aucun mot de passe partagé.
• Comptes anciens supprimés.
• Accès prestataires revus.
• Méthodes de récupération sécurisées.
• Codes de secours conservés correctement.
• Sessions révoquées lors d’un départ.
• Clés API et tokens inventoriés.

58) Checklist — Serveur

• Système maintenu à jour.
• Firewall actif.
• Ports inutiles fermés.
• SSH par clé.
• Root direct limité.
• Services exécutés sans privilèges excessifs.
• Base non exposée publiquement.
• Logs configurés.
• Espace disque supervisé.
• Certificats surveillés.

59) Checklist — Application web

• Authentification robuste.
• Autorisations côté serveur.
• Contrôle tenant / propriétaire.
• Validation serveur.
• Requêtes paramétrées.
• Uploads contrôlés.
• Rate limiting.
• Gestion sécurisée des sessions.
• Erreurs production neutres.
• Secrets hors du code.
• Headers de sécurité pertinents.
• HTTPS partout.

60) Checklist — Développement

• Branch protection.
• Review des changements sensibles.
• Secrets CI protégés.
• MFA GitHub/GitLab.
• Dépendances surveillées.
• Actions CI tierces contrôlées.
• Staging séparé.
• Données production non copiées inutilement.
• Production déployée via un processus documenté.

61) Checklist — Sauvegardes

• Trois copies.
• Supports ou environnements distincts.
• Une copie hors ligne ou suffisamment isolée.
• Chiffrement lorsque nécessaire.
• Rétention définie.
• Accès séparés.
• Alertes en cas d’échec.
• Test de restauration.
• Procédure documentée.
• RPO défini.
• RTO défini.

62) Checklist — Incident

• Contact technique identifié.
• Contact direction identifié.
• Hébergeur connu.
• Assurance connue.
• DPO/juridique lorsque nécessaire.
• Accès aux backups hors production.
• Logs conservés.
• Procédure de révocation des comptes.
• Process de communication.
• Process CNIL connu.
• Exercice réalisé.

63) Combien investir ?

Il n’existe pas de pourcentage magique.

Une PME doit surtout éviter deux extrêmes.

Zéro investissement

Nous n’avons jamais été attaqués.

C’est un raisonnement similaire à :

Nous n’avons jamais eu d’incendie, supprimons l’assurance.

L’empilement d’outils

Acheter :

• EDR ;
• SIEM ;
• WAF ;
• scanner ;
• SOC ;
• plateforme XDR ;

sans personne pour les configurer correctement n’est pas une stratégie.

Investissez d’abord dans les fondations

1. identités ;
2. mises à jour ;
3. backups ;
4. accès ;
5. architecture ;
6. monitoring ;
7. processus.

Puis augmentez progressivement le niveau de sophistication.

64) Sous-traiter ne supprime pas votre responsabilité opérationnelle

Votre agence dit :

Nous gérons l’hébergement.

Très bien.

Demandez :

• où ?
• qui possède le compte ?
• comment sont faites les sauvegardes ?
• qui peut restaurer ?
• quelle MFA ?
• qui reçoit les alertes ?
• que se passe-t-il si la relation s’arrête ?

Évitez la dépendance opaque

Votre entreprise devrait connaître au minimum :

• registrar ;
• hébergeur ;
• comptes propriétaires ;
• sauvegardes ;
• procédure de récupération.

Le prestataire peut administrer.

Il ne devrait pas être le seul à savoir que l’infrastructure existe.

65) Posez ces questions à votre agence web

Accès

Qui possède les comptes critiques ?

Sauvegarde

Où sont stockées les sauvegardes ?

Restauration

Quand avez-vous réalisé le dernier test ?

Maintenance

Qui applique les mises à jour de sécurité ?

Incident

Qui dois-je appeler ?

Logs

Combien de temps sont-ils conservés ?

Départ

Puis-je récupérer l’intégralité de mes données et configurations ?

Ces questions permettent rapidement de distinguer :

« on fait des backups »

de :

une vraie stratégie de résilience.

66) Ce qu’un certificat de sécurité ou un badge ne prouve pas

Vous avez déjà vu :

Site sécurisé.

Avec un cadenas vert dessiné.

Cela ne prouve rien.

Même chose pour :

conforme RGPD.

Ou :

sécurité bancaire.

La confiance ne doit pas être simulée

Une vraie sécurité se démontre davantage par :

• pratiques ;
• transparence ;
• architecture ;
• certifications lorsqu’elles sont réelles ;
• politique ;
• processus.

Évitez les badges inventés.

67) Cybersécurité et performance peuvent aller ensemble

Certaines entreprises imaginent :

plus de sécurité = site plus lent.

Pas nécessairement.

Une bonne architecture peut combiner :

• CDN ;
• cache ;
• WAF ;
• compression ;
• rate limiting ;
• TLS moderne.

Mais chaque couche doit être mesurée

Un script anti-bot lourd.

Un challenge systématique.

Un proxy mal configuré.

Peuvent dégrader l’expérience.

L’objectif reste :

sécurité proportionnée sans rendre le service inutilisable.

68) Cybersécurité et UX peuvent également entrer en conflit

Exemple :

Formulaire demandant un mot de passe :

32 caractères
1 emoji
3 majuscules
4 symboles
changement tous les 7 jours

Vous créez probablement des utilisateurs qui notent leurs mots de passe.

Une bonne sécurité tient compte de l’usage réel.

Même chose avec MFA

Si vous forcez un SMS à chaque clic, les utilisateurs chercheront des contournements.

Protégez fortement les actions sensibles.

Conservez une expérience raisonnable.

69) La meilleure protection est parfois de ne pas stocker la donnée

Votre formulaire demande :

numéro de sécurité sociale

Pourquoi ?

Si vous n’en avez pas besoin :

ne le collectez pas.

Moins de données

signifie :

• moins d’impact en cas de fuite ;
• moins de complexité ;
• moins d’obligations ;
• moins d’attractivité.

La minimisation des données est simultanément :

• bonne pratique RGPD ;
• bonne pratique de sécurité.

70) Chiffrez les données réellement sensibles

Il existe plusieurs niveaux.

En transit

HTTPS / TLS.

Au repos

Disque, base, backup.

Au niveau applicatif

Certains champs extrêmement sensibles peuvent nécessiter une protection supplémentaire.

Mais attention :

chiffrement

n’est pas synonyme de :

sécurité absolue.

Si la clé de chiffrement est stockée juste à côté avec les mêmes permissions, le bénéfice diminue.

La gestion des clés compte autant que l’algorithme.

71) Ne développez pas votre propre cryptographie

À moins d’être spécialiste.

N’inventez pas :

SuperSecureHashV2()

Utilisez :

• bibliothèques reconnues ;
• protocoles éprouvés ;
• primitives standard.

Pour les mots de passe :

utilisez des algorithmes adaptés au stockage de mots de passe.

Pas :

SHA256(password)

brut.

Les frameworks modernes proposent déjà des outils adaptés.

72) Pensez au cycle de vie complet d’une donnée

Question :

Où est stocké l’email du client ?

Réponse :

Dans la base.

Vraiment ?

Il est peut-être également :

• dans le CRM ;
• dans les logs ;
• dans un backup ;
• dans Slack ;
• dans un outil emailing ;
• dans un export CSV ;
• sur l’ordinateur d’un commercial.

Cartographier les données permet d’améliorer

• sécurité ;
• RGPD ;
• suppression ;
• réponse incident.

73) Les exports CSV sont un risque sous-estimé

Votre CRM est sécurisé.

Mais un commercial exporte :

clients-2026.csv

Puis le fichier termine :

• dans Téléchargements ;
• synchronisé vers un cloud personnel ;
• envoyé par email ;
• oublié.

Limitez

• qui peut exporter ;
• quelles données ;
• pourquoi.

Et sensibilisez sur le stockage.

La sécurité d’un SaaS ne protège pas les données une fois sorties.

74) Les appareils personnels élargissent le périmètre

Un salarié consulte :

• CRM ;
• emails ;
• dashboards

depuis son ordinateur personnel.

Vous devez déterminer :

• est-ce autorisé ?
• sous quelles conditions ?
• chiffrement disque ?
• mises à jour ?
• session ?
• perte du matériel ?

Pour les PME

Une politique simple vaut mieux qu’une absence de règle.

Par exemple :

Les accès administrateurs à l’infrastructure ne sont autorisés que depuis les appareils professionnels gérés.

75) Le mobile devient un vecteur important

Les attaquants savent que l’utilisateur est plus vulnérable sur mobile :

• URL moins visible ;
• urgence ;
• SMS ;
• QR code ;
• messageries instantanées.

Le DBIR 2026 souligne d’ailleurs une efficacité accrue de certaines campagnes mobiles par rapport aux environnements traditionnels.

Sensibilisez spécifiquement

Ne dites pas seulement :

attention aux emails.

Incluez :

• SMS ;
• WhatsApp ;
• QR codes ;
• messages LinkedIn ;
• faux appels.

76) La sécurité doit être documentée

Vous configurez parfaitement le serveur.

Puis deux ans plus tard :

personne ne sait pourquoi.

Quelqu’un ouvre :

5432

« pour tester rapidement ».

La documentation protège contre la perte de contexte.

Documentez

• architecture ;
• flux ;
• comptes ;
• backups ;
• déploiement ;
• dépendances critiques ;
• procédures.

Pas besoin de 400 pages.

Un diagramme propre et quelques documents maintenus valent déjà énormément.

77) La documentation sensible doit elle-même être sécurisée

Ne créez pas :

INFRA-PROD.md

public contenant :

• IP ;
• mots de passe ;
• clés ;
• procédures de contournement.

Séparez :

documentation d’architecture

et

secrets.

Les secrets vont dans un gestionnaire sécurisé.

78) Automatisez ce qui est répétitif

Les humains oublient.

Automatisez :

• mises à jour non risquées ;
• renouvellement certificat ;
• backups ;
• tests backup ;
• scans dépendances ;
• alertes ;
• monitoring.

Mais gardez un responsable.

Une tâche cron qui échoue silencieusement pendant trois mois n’est pas une automatisation fiable.

79) Ce qu’un dirigeant doit suivre chaque mois

Pas besoin de lire les logs Nginx.

Demandez un tableau simple :

Cela rend la sécurité pilotable.

80) Les indicateurs utiles ne doivent pas devenir absurdes

KPI :

Nombre de cyberattaques bloquées : 4 827 221.

Impressionnant.

Mais difficile à exploiter.

Un bot qui demande /wp-admin à un site Next.js peut être compté comme attaque.

Préférez

• comptes sans MFA ;
• vulnérabilités critiques dépassant le SLA ;
• backups testés ;
• temps de détection ;
• temps de restauration ;
• comptes dormants ;
• incidents significatifs.

Les KPI doivent guider une décision.

81) Quand faut-il réaliser un pentest ?

Un test d’intrusion devient particulièrement pertinent :

• avant lancement d’une application sensible ;
• après grosse refonte ;
• avant ouverture d’une API critique ;
• après changement architectural ;
• périodiquement selon le risque ;
• à la demande de clients ou contrats.

Mais assurez-vous d’abord des fondamentaux

Payer un pentester pour découvrir :

admin / admin

n’est pas la meilleure utilisation du budget.

Un audit de configuration préalable peut éliminer les problèmes évidents.

82) Un pentest n’est pas une garantie

Résultat :

aucune vulnérabilité critique trouvée.

Cela signifie :

aucune vulnérabilité critique n’a été identifiée dans le périmètre et pendant la période du test.

Pas :

l’application est inviolable pour toujours.

Une nouvelle version demain peut réintroduire un problème.

La sécurité est continue.

83) Bug bounty : intéressant, mais pas pour tout le monde

Un programme de bug bounty peut être puissant.

Mais lancer publiquement :

attaquez notre application

sans processus interne est une mauvaise idée.

Avant :

• périmètre ;
• règles ;
• canal ;
• triage ;
• responsable ;
• budget ;
• capacité de correction.

Pour une PME classique, un audit ciblé est souvent plus simple pour commencer.

84) Votre assurance cyber ne remplace pas la sécurité

Une assurance peut aider financièrement et fournir un support incident.

Mais les contrats peuvent comporter :

• exclusions ;
• conditions ;
• franchises ;
• obligations de sécurité.

L’assureur peut demander :

• MFA ;
• backups ;
• procédures ;
• EDR.

Déclarez honnêtement votre dispositif.

85) La cybersécurité peut devenir un argument commercial

Dans certains secteurs B2B, les clients commencent à demander :

• où sont les données ?
• comment sont-elles sauvegardées ?
• MFA ?
• chiffrement ?
• hébergement ?
• sous-traitants ?
• plan de continuité ?

Une entreprise capable de répondre clairement inspire davantage confiance.

Sécurité = coût ?

Oui.

Mais également :

• réduction du risque ;
• continuité ;
• crédibilité ;
• avantage commercial.

86) Ce qui change avec l’IA en 2026

L’IA intervient des deux côtés.

Attaque

Elle peut accélérer :

• reconnaissance ;
• personnalisation du phishing ;
• génération de code ;
• traduction ;
• automatisation.

Défense

Elle peut aider :

• corrélation des alertes ;
• détection ;
• analyse ;
• triage ;
• réponse.

IBM observe d’ailleurs dans son étude 2026 des économies moyennes importantes chez les organisations ayant intégré largement l’IA et l’automatisation dans leurs opérations de sécurité.

Mais pour une PME :

acheter de l’IA

n’est pas la première priorité.

Avant cela :

• MFA ;
• backups ;
• mises à jour ;
• logs.

L’IA n’améliore pas une infrastructure dont les fondations sont faibles.

87) Les erreurs à éviter absolument

« Nous sommes trop petits »

Les scans sont automatisés.

« Nous avons HTTPS »

Insuffisant.

« Notre hébergeur s’occupe de tout »

Vérifiez le périmètre.

« Nous avons un backup »

Testez-le.

« Nous avons un firewall »

Et les comptes ?

« Nous changeons le mot de passe tous les mois »

Et la MFA ?

« Notre développeur gère »

Que se passe-t-il s’il n’est pas disponible ?

« Nous n’avons rien à voler »

Vous possédez au minimum :

• comptes ;
• réputation ;
• ressources ;
• clients ;
• infrastructure.

88) À quoi ressemble une PME raisonnablement sécurisée ?

Pas à un bunker.

Mais à une organisation où :

• les comptes sensibles ont une MFA ;
• les mots de passe sont uniques ;
• les droits sont limités ;
• les logiciels sont maintenus ;
• les dépendances sont suivies ;
• les secrets ne sont pas dans le code ;
• les bases ne sont pas inutilement publiques ;
• les backups sont isolés ;
• les restaurations sont testées ;
• les logs existent ;
• les alertes arrivent à quelqu’un ;
• les accès des anciens collaborateurs sont supprimés ;
• une procédure d’incident existe.

Ce n’est pas spectaculaire.

C’est précisément pour cela que cela fonctionne.

89) Le modèle à retenir : prévenir, limiter, détecter, restaurer

Une stratégie simple peut être résumée en quatre verbes.

Prévenir

Réduire la probabilité.

MFA.

Patches.

Durcissement.

Limiter

Réduire l’impact.

Moindre privilège.

Segmentation.

Détecter

Savoir rapidement.

Logs.

Alertes.

Monitoring.

Restaurer

Revenir à une situation saine.

Backup.

Procédure.

Tests.

90) Conclusion

La cybersécurité web n’est plus un sujet réservé aux banques, aux administrations ou aux grandes entreprises.

En 2026, une PME dépend souvent d’un ensemble très dense de services numériques :

• domaine ;
• messagerie ;
• site ;
• cloud ;
• CRM ;
• application métier ;
• paiements ;
• Git ;
• outils SaaS.

Cette interconnexion augmente la productivité.

Mais également le nombre de portes.

Les chiffres observés par Cybermalveillance.gouv.fr montrent que les compromissions de comptes, l’hameçonnage, les fraudes et les violations de données touchent directement les professionnels.

Le DBIR 2026 rappelle de son côté que l’exploitation de vulnérabilités logicielles constitue désormais l’un des principaux moyens d’accès initial observés dans son échantillon international.

Et l’OWASP Top 10 2025 place désormais en tête :

• les contrôles d’accès défaillants ;
• les mauvaises configurations ;
• les problèmes de chaîne d’approvisionnement logicielle.

Ces tendances convergent vers la même conclusion.

La sécurité d’une PME ne dépend pas d’un outil miracle.

Elle dépend d’un ensemble de choix cohérents.

Protégez d’abord vos identités.

Réduisez les droits.

Maintenez vos systèmes.

Contrôlez vos dépendances.

Protégez vos secrets.

Isolez vos données.

Sauvegardez réellement.

Surveillez ce qui compte.

Et surtout :

préparez la restauration avant d’en avoir besoin.

L’objectif n’est pas de rendre votre entreprise impossible à attaquer.

Cet objectif n’existe pas.

L’objectif est de faire en sorte qu’une erreur, une vulnérabilité ou un compte compromis ne puisse pas automatiquement devenir une catastrophe.

"Une bonne cybersécurité ne promet pas qu’aucun incident n’arrivera. Elle évite qu’un incident ordinaire devienne une crise capable d’arrêter l’entreprise." — Alexandre Bornand, AnalyWeb

Sources et références

Les recommandations et tendances présentées dans cet article s’appuient notamment sur les publications suivantes, disponibles à la date de publication :

• ANSSI / MesServicesCyber — Fiches pratiques ReCyF, publiées le 7 septembre 2026 : gestion des identités, architectures sécurisées, protection, gouvernance et résilience.
• ANSSI et Mission French Tech — Guide de cybersécurité à l’usage des start-up du numérique, publié le 26 février 2026.
• Cybermalveillance.gouv.fr — Rapport d’activité et état de la menace 2025, publié en mars 2026.
• Cybermalveillance.gouv.fr — Principales cybermalveillances visant les professionnels en 2025, publié en mai 2026.
• Verizon — Data Breach Investigations Report 2026, données internationales sur les vecteurs d’accès, les vulnérabilités et les rançongiciels.
• IBM — Cost of a Data Breach Report 2026, analyse mondiale du coût des violations de données et de l’évolution des attaques assistées par IA.
• OWASP — Top 10:2025, référentiel des principales catégories de risques applicatifs web.
• ANSSI — Sauvegarde des systèmes d’information, recommandations incluant notamment la règle 3-2-1 et la sauvegarde hors ligne.
• ANSSI — Mesures cyber préventives prioritaires, authentification, supervision, sauvegarde hors ligne, services critiques et gestion de crise.
• CNIL — Violations de données personnelles, règles de documentation, notification et délai maximal de 72 heures lorsque la violation présente un risque.

Les données françaises utilisées sont particulièrement solides ici : Cybermalveillance.gouv.fr rapporte plus de 500 000 victimes assistées en 2025, en hausse de 20 %, et place le piratage de compte en première position pour les entreprises et associations avec 21 % des parcours d’assistance. L’ANSSI a bien publié les fiches ReCyF en pratique le 7 septembre 2026, structurées autour de la défense, de la protection, de la gouvernance et de la résilience.

Côté applications web, l’OWASP Top 10:2025 classe effectivement le contrôle d’accès défaillant en n°1, les mauvaises configurations en n°2 et les défaillances de supply chain logicielle en n°3. Le DBIR 2026 de Verizon rapporte quant à lui que 31 % des violations de son échantillon commencent par l’exploitation d’une vulnérabilité et que les rançongiciels interviennent dans 48 % des violations analysées ; ce sont des données internationales, pas des statistiques spécifiques aux PME françaises.

Pour les mesures concrètes, l’ANSSI recommande bien la MFA, la supervision, les sauvegardes hors ligne, l’identification des services critiques et un dispositif de gestion de crise. Son guide sauvegarde formalise également la règle 3-2-1 avec au moins une copie hors ligne. Enfin, la CNIL rappelle qu’une violation présentant un risque doit être notifiée dans les meilleurs délais et, si possible, dans un maximum de 72 heures après sa constatation.