Huit étaient classées graves.
La réaction habituelle, c'est la panique ou l'indifférence. Nous avons fait autre chose : mesurer chaque alerte contre ce qui roule vraiment chez nous.
Nos agents ont recoupé les quatorze avec la base réelle : combien d'utilisateurs il y a, quels flux sont actifs, quels composants chacun utilise. Le résultat :
1. Une seule nous exposait vraiment ce jour-là.
2. Une autre dépendait d'un connecteur essayé une fois et sans trafic depuis trente jours.
3. Les autres exigeaient des fonctions que nous n'utilisons pas.
C'est là que le jugement humain est entré en jeu. Le connecteur que personne n'utilisait a été désactivé le jour même. C'est la surface la moins chère à fermer. Et même si une seule alerte nous concernait, nous avons décidé de mettre à jour quand même.
Les agents ont préparé la mise à jour :
1. Douze changements de base de données revus un par un.
2. Une sauvegarde complète, restaurée dans une copie pour prouver qu'elle fonctionnait.
3. Un plan de retour arrière prêt.
La coupure a duré moins de deux minutes, sans aucune exécution en cours et avec les mêmes flux et identifiants qu'avant, vérifiés un par un.
Nous avons aussi trouvé une faille chez nous : notre filtre ne laissait passer que les alertes graves, et les quatre moyennes ne sont jamais arrivées au canal. Les filtres aussi se révisent.
Ce que nous appliquons aujourd'hui sur chaque infrastructure que nous exploitons :
1. Une alerte se mesure contre ce qui roule, pas contre son étiquette.
2. Ce qui ne sert pas se désactive.
3. On met à jour quand même, avec une sauvegarde testée avant.
4. Les filtres d'alertes s'auditent comme n'importe quel autre système.
Quatorze alertes, ce ne sont pas quatorze incendies. Mais il faut regarder les quatorze pour savoir laquelle est l'incendie.