Quand un service ralentit, qu’un partage réseau devient inaccessible ou que plusieurs utilisateurs n’arrivent plus à se connecter, le premier réflexe est souvent le même : chercher une panne.
C’est logique. Dans beaucoup d’entreprises, la majorité des incidents du quotidien sont effectivement techniques : certificat expiré, mise à jour ratée, quota atteint, coupure réseau, problème côté fournisseur. Mais parfois, les symptômes ressemblent à une panne alors qu’ils cachent tout autre chose.
Et c’est là que les erreurs commencent.
Une panne se traite avec des gestes techniques classiques.
Une attaque, elle, demande autre chose : isoler, observer, préserver les traces et éviter d’aggraver la situation.
Le vrai danger, ce n’est donc pas seulement de subir un incident. C’est de le qualifier trop tard — ou de le traiter comme une panne alors qu’il s’agit déjà d’une compromission.
Pourquoi la confusion reste fréquente
La confusion persiste parce que les signes se ressemblent souvent au départ.
Un service qui ne répond plus, un compte bloqué, un serveur qui rame, une application inaccessible : tout cela peut venir d’une défaillance classique… ou d’une activité malveillante. Les environnements hybrides compliquent encore les choses. Un incident SaaS, une erreur de configuration locale ou un comportement anormal sur un poste peuvent produire des symptômes presque identiques vus de l’utilisateur.
Autre difficulté : les attaques ne sont plus toujours bruyantes. Beaucoup d’entre elles progressent discrètement, avec peu de signes visibles au début. Elles s’installent, testent des accès, déplacent des données ou préparent une escalade avant que le vrai impact ne devienne évident.
C’est précisément pour cela qu’un mauvais diagnostic dans les premières minutes peut coûter très cher.
Les signaux qui doivent faire penser à une cyberattaque
Certains signes ne prouvent pas à eux seuls qu’il s’agit d’une attaque, mais ils doivent clairement faire lever le doute.
Par exemple :
- des fichiers chiffrés ou des extensions inhabituelles ;
- une note de rançon ;
- des pics de connexions sortantes anormales ;
- des demandes MFA répétées sans raison ;
- des comptes qui changent soudainement de niveau de privilège ;
- des outils de sécurité désactivés ou silencieux ;
- de nouvelles tâches planifiées inconnues ;
- des journaux coupés ou manquants ;
- des sauvegardes ciblées ou des instantanés supprimés ;
- plusieurs alertes cohérentes remontées en même temps sur des sources différentes.
Pris séparément, un signal peut tromper.
Pris ensemble, ils changent complètement la lecture.
Les signaux qui orientent plutôt vers une panne
À l’inverse, certains éléments vont davantage dans le sens d’un incident technique classique.
On pense par exemple à :
- un changement planifié juste avant le problème ;
- un crash applicatif reproductible ;
- un quota saturé ;
- un certificat expiré ;
- un incident reconnu chez un fournisseur ;
- une panne matérielle identifiée ;
- une erreur de configuration bien documentée ;
- une saturation système cohérente avec une forte charge attendue ;
- l’absence totale d’activité suspecte côté comptes et journaux ;
- des outils de sécurité qui remontent un état normal et complet.
Le mot important ici, c’est cohérence.
Une panne laisse souvent derrière elle une cause technique plus claire et plus reproductible. Une attaque, elle, crée plus souvent un faisceau d’indices incohérents ou inhabituels.
L’arbre de décision le plus utile
Dans les premières minutes, il ne faut pas chercher à tout comprendre.
Il faut avancer dans le bon ordre.
1. Isoler et observer
Si un poste ou un serveur paraît suspect, on limite son exposition au réseau sans l’éteindre ni le redémarrer. On gèle les actions non nécessaires, on note l’heure, on garde les éléments visibles et on évite les gestes irréversibles.
2. Qualifier rapidement
On regarde ensuite ce qui peut aider à trancher :
- journaux d’authentification ;
- alertes de sécurité ;
- connexions sortantes inhabituelles ;
- apparition de nouveaux comptes ou privilèges ;
- arrêt ou silence soudain d’un agent de sécurité.
3. Décider
Si plusieurs indicateurs de compromission sont présents, il vaut mieux traiter l’incident comme une attaque. Si tout pointe vers une cause technique claire, documentée et reproductible, l’hypothèse de panne devient plus solide.
Et s’il reste un doute ?
La règle la plus prudente reste la même : traiter comme une attaque jusqu’à preuve du contraire.
Les 10 premières minutes : le bon protocole
Quand un incident paraît suspect, les dix premières minutes ne servent pas à résoudre le problème. Elles servent à ne pas le rendre pire.
Les bons réflexes sont les suivants :
- isoler le périmètre touché ;
- interdire les redémarrages improvisés ;
- noter l’heure, le poste, l’utilisateur et les symptômes ;
- conserver les écrans, messages et premiers éléments visibles ;
- préserver les journaux utiles ;
- prévenir le bon interlocuteur ;
- éviter les communications dispersées ;
- vérifier si d’autres systèmes sont touchés ;
- sécuriser les sauvegardes hors ligne ;
- ouvrir officiellement l’incident et tracer les actions.
Ce protocole paraît simple. C’est justement ce qui le rend utile.
Ce que beaucoup d’équipes font encore trop vite
Dans le doute, certaines réactions reviennent souvent :
- redémarrer “pour voir” ;
- supprimer les fichiers suspects ;
- restaurer trop tôt ;
- communiquer trop largement sans validation ;
- laisser plusieurs personnes agir en parallèle sans coordination.
Ces gestes partent souvent d’une bonne intention. Pourtant, ils peuvent détruire des indices, compliquer l’analyse ou accélérer la propagation.
Dans ce type de situation, aller vite ne veut pas dire agir dans tous les sens.
Cela veut dire faire peu de choses, mais dans le bon ordre.
Pourquoi MTTD et MTTR comptent vraiment
Deux indicateurs résument bien la différence entre une organisation qui subit et une organisation qui garde la main :
- MTTD : le temps nécessaire pour détecter qu’il se passe quelque chose d’anormal ;
- MTTR : le temps nécessaire pour répondre puis revenir à un état stable.
Une PME ne réduit pas ces délais en ajoutant simplement des outils. Elle les réduit surtout avec :
- des procédures claires ;
- une surveillance cohérente ;
- des points d’escalade connus ;
- des gestes standardisés ;
- un minimum d’entraînement.
Quand les équipes savent quoi faire, le doute dure moins longtemps et la réaction devient plus propre.
Gouvernance, preuves et suite de l’incident
Une fois le premier tri fait, il faut garder une trace.
Un incident bien géré repose sur :
- un journal des décisions ;
- des captures ou exports utiles ;
- les horaires clés ;
- les systèmes concernés ;
- les actions réalisées.
Cela sert à trois choses : mieux piloter la suite, faciliter le retour d’expérience et préparer les obligations éventuelles si des données personnelles ou des services critiques sont concernés.
Un incident sans traces devient vite confus.
Et un incident confus se reproduit plus facilement.
Conclusion
Face à un doute, la meilleure erreur à éviter est celle-ci : traiter trop vite un incident comme une panne ordinaire.
Une panne supporte l’investigation.
Une attaque, elle, profite du temps qu’on lui laisse.
Le bon réflexe est donc simple : observer, isoler, qualifier vite et garder les preuves. Ce n’est pas spectaculaire, mais c’est souvent ce qui évite qu’un problème local se transforme en vraie crise.
Au fond, la règle la plus utile reste la même :
si vous hésitez entre panne et attaque, partez du principe qu’il peut s’agir d’une attaque jusqu’à ce que les faits prouvent le contraire.
