Quand vous dirigez seul votre entreprise, un plan de réponse aux incidents doit vous indiquer quoi faire lorsqu'un rapport de sécurité arrive : consigner les faits, déterminer qui peut vous aider, choisir la prochaine action et fixer un moment pour refaire le point. Gardez cette première page accessible hors ligne, avec des liens vers les procédures détaillées. Puis testez-la avec un rapport fictif.

Le 2 novembre 2026, le NIST a publié [Small Business Cybersecurity: Non-Employer Firms](https://csrc.nist.gov/pubs/cswp/50/small-business-cybersecurity-non-employer-firms/final), un guide destiné aux entreprises dont les propriétaires sont les seules personnes rémunérées. Sa présence sur [Hacker News](https://news.ycombinator.com/item?id=50340619) invite à poser une question concrète : si quelqu'un vous signale un problème ce soir, pourrez-vous commencer à réagir sans inventer votre procédure sur le moment ?

Vous n'avez pas besoin d'une grande équipe de sécurité pour écrire la réponse. Vous devez toutefois connaître les limites de vos compétences et savoir quelle aide est réellement joignable.

## Prévoyez un plan utilisable quand vos outils habituels sont indisponibles

Cette première page est une aide à la décision, pas un manuel de sécurité complet. Elle doit vous orienter vers vos contacts et procédures, même si votre e-mail professionnel ou votre compte habituel de stockage documentaire est inaccessible.

Le [nouveau guide du NIST](https://www.nist.gov/news-events/news/2026/11/self-employed-solopreneur-nist-has-cybersecurity-guide-just-you) présente la cybersécurité dans un langage accessible. Pour chaque action, il propose une façon de commencer et des pistes pour progresser à mesure que l'entreprise grandit. Le format d'une page ci-dessous est notre adaptation éditoriale pour une petite entreprise logicielle dirigée par son fondateur. Le NIST n'impose ni ce format, ni un délai de réponse précis, ni une plateforme de divulgation des vulnérabilités.

Commencez par un seul service. Choisissez le produit dont vos clients dépendent plutôt que de documenter tous vos appareils. Conservez une copie hors ligne dans un endroit sûr. Indiquez comment accéder aux ressources, sans y inscrire de mots de passe ni de codes de récupération.

| Rubrique | Rédigez une réponse exploitable |
|---|---|
| Service et responsable des décisions | Nom du produit, votre nom, contact de remplacement en votre absence et pouvoirs accordés à cette personne |
| Quels événements déclenchent le plan ? | Exemples propres au service : soupçon d'accès non autorisé, exposition de données clients ou perte d'un compte essentiel |
| Réception des rapports | Contact de sécurité surveillé, personne chargée de le consulter et autre canal pour les messages urgents |
| Emplacement des preuves | Emplacement à accès restreint pour le rapport, les horodatages, journaux, captures d'écran et actions entreprises |
| Aide joignable | Assistance de l'hébergeur, spécialiste technique et contacts juridiques ou d'assurance pertinents ; coordonnées vérifiées |
| Première décision | Qui évalue si le préjudice se poursuit, où se trouve la procédure du système concerné et qui peut autoriser les mesures d'endiguement |
| Communications | Qui répond à la personne à l'origine du rapport, où figurent les obligations contractuelles ou autres de notification et heure du prochain point |
| Reprise et bilan | Emplacement de la procédure de reprise, vérifications de son efficacité et date du bilan de l'incident |

Un nom seul ne vous permettra pas d’agir. Si votre contact technique est indépendant, vérifiez qu'il a accepté de vous aider, ses disponibilités et les accès nécessaires. N'attendez pas un incident pour découvrir qu'« appeler quelqu'un de technique » revient à chercher un inconnu.

## Distinguez le rapport reçu de la décision de traiter un incident

Un rapport de sécurité contient des informations à évaluer. Il peut décrire une vraie vulnérabilité, un malentendu ou des indices de compromission en cours. Votre première réponse doit en accuser réception sans prétendre avoir déjà tranché.

Utilisez ce tableau comme point de départ pour vos procédures. Il s'agit de notre exemple opérationnel, pas d'une échelle de sévérité du NIST.

| Ce que vous savez actuellement | Prochaine décision utile | Éléments à consigner |
|---|---|---|
| Le rapport est trop vague pour être évalué | Demander la fonctionnalité touchée, le moment des faits et des indications permettant une reproduction sans risque | Questions posées, responsable, prochain examen |
| Une faiblesse semble reproductible, sans indice d'exploitation à ce stade | Confier l'enquête à une personne et décider d'éventuelles restrictions temporaires | Preuves, service touché, inconnues restantes |
| Des indices montrent un accès non autorisé ou une exposition qui se poursuit | Activer le plan et contacter le spécialiste capable d'aider à évaluer les mesures d'endiguement | Motif de l'escalade, personnes contactées, actions autorisées |
| Le problème n'a pas été reproduit ou semble résulter d'une erreur | Expliquer le constat actuel et les preuves supplémentaires susceptibles de le modifier | Vérifications effectuées et incertitudes restantes |

Ne demandez pas à la personne qui signale le problème de recueillir davantage de données clients pour le prouver. Utilisez vos propres comptes de test autorisés. Faites appel à un spécialiste qualifié si l'enquête risque d'exposer d'autres données ou d'interrompre le service.

Une première réponse peut être courte : « Nous avons reçu votre rapport et examinons la fonctionnalité concernée. Merci de ne pas consulter ni envoyer d'autres données clients. Nous vous donnerons des nouvelles avant [heure et fuseau horaire]. » Choisissez une échéance que vous pourrez tenir, même si le prochain message indique simplement que l'enquête continue.

Pour définir séparément un canal public de signalement et son périmètre, consultez notre [guide du programme de divulgation des vulnérabilités](/blog/how-to-set-up-vulnerability-disclosure-program). Le plan de réponse décrit ce que vous faites après avoir reçu un rapport par ce canal.

## Répétez avec un rapport fictif avant d'en recevoir un vrai

Un exercice doit révéler les contacts et décisions manquants sans modifier les systèmes en production. Déroulez un scénario fictif, notez les blocages et corrigez le plan.

Le [guide pour les petites entreprises](https://www.cyber.gov.au/publication/small-business-cyber-security-handbook/implement-and-test-cyber-security-incident-response-plans) de l'Australian Signals Directorate recommande des exercices simples, la vérification des délais de réponse et des décisions, puis l'amélioration des plans à partir des résultats. L'exercice SaaS suivant est notre proposition pour appliquer ce principe.

Imaginez ce message d'une personne signalant une vulnérabilité : « Cette URL me permet d'accéder au fichier exporté d'un autre client. » Aucun vrai fichier ni aucune donnée client n'est nécessaire. Identifiez clairement l'exercice et ne le faites pas passer par les canaux publics de signalement.

1. **Retrouvez la page.** Supposez que votre e-mail professionnel soit inaccessible. Pouvez-vous retrouver le plan hors ligne et vos contacts d'assistance ?
2. **Créez une fiche d'exercice.** Notez l'heure d'arrivée du message fictif, ce qu'il affirme, les inconnues et la personne responsable de la prochaine décision.
3. **Rédigez l'accusé de réception.** Annoncez le prochain point sans affirmer qu'une violation de données est confirmée ou qu'un correctif est achevé.
4. **Choisissez à qui transmettre le problème.** Identifiez qui peut examiner les journaux d'accès pertinents et qui pourrait restreindre la fonctionnalité d'export concernée. Décrivez l'action sans l'exécuter en production.
5. **Retrouvez la procédure de reprise.** Identifiez les accès nécessaires et les vérifications permettant d'établir que le service peut reprendre sans danger.
6. **Consignez les lacunes.** Remplacez « vérifier les journaux » par leur emplacement réel et leur mode d'accès. Remplacez « contacter l'hébergeur » par le canal d'assistance vérifié.

Fixez une durée compatible avec votre journée. L'objectif est d'améliorer le plan ; terminer vite ne prouve pas que vous êtes prêt. Si vous ne pouvez nommer personne capable d'évaluer l'exposition signalée, c'est un résultat utile : organisez cette aide avant de compter sur le plan.

## Tenez un relevé factuel pendant la réponse et la reprise

Séparez ce que vous savez de ce que vous supposez. Toute action importante doit avoir une heure, un responsable et une justification, afin de pouvoir expliquer l'évolution de votre compréhension.

Les [recommandations de réponse de CSWP 50](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.50.pdf) demandent de documenter le moment de la détection, les journaux et captures d'écran pertinents ainsi que les actions entreprises. Elles abordent aussi les exercices, la conservation hors ligne des contacts importants et la vérification de l'intégrité des sauvegardes avant la reprise. Servez-vous de ces points pour tester votre première page et les procédures auxquelles elle renvoie.

Pour le rapport fictif sur l'export, une entrée pourrait être : « 14:10 UTC : rapport reçu. La personne affirme pouvoir accéder à un fichier d'un autre client. Problème pas encore reproduit. Responsable : fondateur. Prochaine action : le spécialiste technique examine les autorisations d'export et les journaux d'accès disponibles. » Une entrée ultérieure peut corriger l'hypothèse de travail sans réécrire la précédente.

Le déploiement d'un correctif, la remise en service et la vérification de la résolution répondent à des questions différentes. Déterminez les contrôles nécessaires pour votre service et qui peut les réaliser. Si vous utilisez une sauvegarde, suivez votre procédure de reprise et validez le service restauré avant de considérer la reprise comme achevée.

Repérez aussi à l'avance les obligations de notification qui s'appliquent à votre entreprise. Le guide ne fixe pas de délai légal universel et un rapport de vulnérabilité ne suffit pas à établir qu'il faut avertir les clients. Notez où sont documentées vos obligations contractuelles et celles propres à votre juridiction, ainsi que la personne à consulter.

## Utilisez Kit pour coordonner les rapports en complément du plan

Un processus de traitement des rapports peut réunir responsabilités, échanges et avancement. Votre plan hors ligne doit toujours couvrir les contacts d'assistance, la reprise des systèmes et les décisions prises hors de ce processus.

Le module Sécurité de Kit permet d'attribuer les rapports, de correspondre avec les chercheurs, d'ajouter des notes internes et de consulter la chronologie d'un rapport. Son cycle de traitement distingue l'enquête et la résolution de la vérification du correctif. Ces fonctions peuvent vous aider à faire avancer un rapport de vulnérabilité pendant son examen ; elles ne déterminent pas si un incident a eu lieu et ne rétablissent pas votre infrastructure.

Si vous utilisez déjà Kit, répétez avec une fiche clairement identifiée comme exercice et vérifiez que vous retrouvez le responsable, les échanges et la prochaine action. Limitez l'accès aux pièces sensibles aux personnes qui en ont besoin. Consultez les [fonctions de sécurité](/security/features) pour décider si elles conviennent à votre traitement des rapports.

Commencez par la page utilisable ce soir : un contact joignable, un emplacement pour les preuves, un responsable des décisions et l'heure du prochain point. Testez-la avec le rapport fictif, corrigez une lacune et enregistrez la copie hors ligne révisée.