# Incidents majeurs : coordination plutôt que chaos · Stilla

> Lors d'un incident majeur, la technologie ne représente que la moitié du problème.

URL: https://stilla.eywo.digital/fr/blog/major-incident-coordination/
Language: fr
Last updated: 2026-10-25

[← Retour au blog](https://stilla.eywo.digital/fr/blog/)

Exploitation20 août 2026Mis à jour 25 octobre 20264 min luÉquipe Eywo

# Incidents majeurs : coordination plutôt que chaos

Lors d'un incident majeur, la technologie ne représente que la moitié du problème. L'autre moitié concerne les informations disponibles et leur actualité. Voici comment transformer les premières minutes en travail coordonné plutôt qu'une recherche d'informations.

Il est mardi après-midi et un service critique cesse de fonctionner. Les téléphones sonnent, le chat se remplit et trois équipes cherchent la cause, chacune dans sa propre couche. Le responsable des opérations essaie de déterminer qui est affecté, le service d'assistance veut savoir quoi dire aux appelants et la direction demande quand cela sera résolu. Personne n'a une vue d'ensemble.

Un incident majeur est un test de stress autant pour les personnes que pour les systèmes. Les ingénieurs travaillent sous pression tout en répondant aux mêmes questions à plusieurs reprises. Les mises à jour externes sont rédigées à la hâte et contredisent souvent les précédentes. Et une fois que c'est terminé, il est difficile de reconstituer ce qui s'est passé et pourquoi.

## Pourquoi le runbook seul ne suffit pas

Nous voyons souvent des organisations avec une procédure d'incident majeur bien écrite. Le problème se situe ailleurs. Lorsque la procédure est nécessaire, les informations requises pour la suivre font défaut :

-   **L'impact est estimé.** Qui sait quels services s'exécutent sur le serveur affecté ? Souvent une seule personne, qui est occupée à autre chose.
-   **Les changements sont reconstitués après coup.** « Quelqu'un a-t-il changé quelque chose ? » est toujours demandé. La réponse vient des e-mails et de la mémoire.
-   **Les fournisseurs sont contactés de manière ad hoc.** Qui détient le contrat, quel délai de réponse il promet et qui appeler sont recherchés dans un dossier partagé.
-   **La communication démarre à partir d'une page blanche.** Différente à chaque fois, rédigée sous pression à chaque fois.

Toutes ces informations existent quelque part dans l'organisation. Il suffit qu'elles ne soient pas à portée de main au moment où cela compte.

## La coordination repose sur des faits partagés

Un incident majeur bien géré a un coordinateur clair, une source unique de vérité et un rythme régulier de mises à jour. Mais le coordinateur a besoin de faits, pas d'estimations : quels services et clients sont affectés, qu'est-ce qui a changé récemment autour des composants affectés, qui est responsable du côté du fournisseur et qui doit être informé. Plus ces informations sont prêtes à l'avance, plus il reste de capacité pour la solution réelle.

## Comment Stilla gère cela

Stilla relie l'incident aux données déjà présentes dans le système. Lorsqu'un incident est signalé contre un élément de la CMDB, il suggère le service affecté, l'impact et l'équipe de résolution. La priorité découle de l'impact et de l'urgence. L'incident peut être marqué comme majeur pour qu'il bénéficie de la gestion qu'il mérite.

Lorsque l'incident démarre dans la supervision, les groupes de gestion d'événements liés en situation en fonction de la topologie de la CMDB, du service et du temps, et montrent la cause probable ainsi que les changements liés. Un incident est créé à partir de la situation en une étape, ou automatiquement. L'équipe démarre à partir d'une situation avec un contexte, et non à partir d'un millier d'alertes distinctes.

Si une partie de la résolution se trouve chez un fournisseur, l'incident peut être escaladé conformément au contrat de service. Le système sait quels éléments le contrat couvre et quel SLA le fournisseur a engagé. Personne ne cherche un contrat pendant que l'horloge tourne.

Les notifications par e-mail et Slack suivent les règles et les modèles. Les bonnes personnes sont informées de l'incident sans un tour de téléphone, et les messages sont cohérents.

L'assistant AI facultatif aide là où le temps est perdu sous pression. Il propose un incident à partir d'une situation, trouve des incidents similaires passés et rédige des communications avec les clients. Ce sont des suggestions, pas des décisions. Une personne décide toujours de ce qui est envoyé et de la manière de procéder.

Après coup, la chronologie complète reste dans la piste d'audit. La revue post-incident repose sur un enregistrement, et non sur la mémoire.

## Calme quand cela compte

Les incidents majeurs ne peuvent pas être exclus. Ce que vous pouvez garantir, c'est que les premières minutes ne soient pas passées à chercher des informations. Lorsque l'impact est connu, les changements sont traçables, le fournisseur est à un clic et la communication est rédigée, les ingénieurs peuvent se concentrer sur la solution et le coordinateur sur les personnes. Et lorsque c'est terminé, tout le monde peut rentrer chez soi en sachant que la réponse était basée sur des faits.

Les incidents majeurs font partie de l'édition Standard ; la corrélation d'événements en situations, l'escalade de fournisseur basée sur le contrat et l'assistant AI sont inclus dans l'édition Business.

**Stilla Business**  
Pour les opérations qui souhaitent connecter la supervision, la sécurité et les fournisseurs.

[Comparer les éditions →](https://stilla.eywo.digital/fr/editions/)

## Plus d'articles

[Exploitation·6 août 2026

### Les SLA mesurés de la bonne façon

Un délai qui s'étend sur les week-ends et les jours fériés, ou qui ignore le temps passé à attendre le client, crée des conflits inutiles. Comment mesurer les SLA pour que les chiffres correspondent à la fois à l'accord et à la réalité.

Standard4 min lu](https://stilla.eywo.digital/fr/blog/sla-measured-right/)[Exploitation·30 juillet 2026

### Bruit de la supervision : des milliers d'alertes à quelques situations

Lorsque la supervision signale tout, elle ne signale finalement rien. Comment transformer un flux d'événements en quelques situations claires avec une cause probable et un impact visible sur les services.

Business4 min lu](https://stilla.eywo.digital/fr/blog/monitoring-noise/)[CMDB·25 octobre 2026

### Le réseau virtuel dans la CMDB : du groupe de ports au commutateur leaf

Entre une machine virtuelle et le réseau physique se trouve une couche que la plupart des CMDB ne voient pas – les commutateurs virtuels, les groupes de ports et les liaisons ascendantes d'hôte. Pourtant, c'est exactement là que l'on décide quels services un changement de réseau affectera.

Standard4 min lu](https://stilla.eywo.digital/fr/blog/virtual-network-in-the-cmdb/)
