Quand l'automatisation tombe en panne : reprendre la main

La dépendance à l’automatisation est devenue une dépendance critique. La résilience ne consiste pas à automatiser toujours plus - elle consiste à savoir encore agir sans.

Depuis quatre semaines, ce trimestre chante les louanges de la machine. Le SOC augmenté par l’IA (024), l’IA offensive comme industrialisateur des attaques (025), la détection et la réponse automatisées (026), le test offensif permanent (027). Un fil cohérent : l’intelligence au service de la résilience.

Il manque un contrepoint. Le voici.

Car derrière chaque playbook qui s’exécute en trois secondes, chaque poste isolé automatiquement, chaque alerte triée par un modèle, se cache une hypothèse tacite : que la machine sera là. Toujours. Disponible, fiable, non compromise.

Et si elle ne l’est pas ?

On a passé une décennie à déléguer à l’automatisation nos gestes les plus répétitifs. On a rarement demandé ce qu’il resterait le jour où elle s’arrêterait. C’est pourtant une question de résilience de premier ordre - la même, au fond, que celle du cloud (002) : non pas l’absence de dépendance, mais la conscience de ses dépendances.

La vraie question n’est pas de savoir si l’automatisation tombera un jour. C’est de savoir si nous saurons encore reprendre la main quand elle tombera.

1. Le paradoxe qu’on a préféré oublier

Nous l’avons croisé à l’épisode 026, sous le nom de Bainbridge. En 1983, la psychologue Lisanne Bainbridge formule les « ironies de l’automatisation ». Son constat, écrit quarante ans avant nos SOAR, reste d’une actualité gênante.

L’automatisation prend en charge le routinier. Elle laisse à l’humain… l’exceptionnel. C’est-à-dire précisément les situations les plus rares, les plus complexes, les plus stressantes. Celles où l’on a le plus besoin de compétence.

• Première ironie : plus on automatise, plus l’intervention humaine résiduelle devient critique.

• Seconde ironie : cette intervention, on ne s’y entraîne plus - puisque la machine fait le quotidien à notre place.

On a donc conçu des systèmes qui réclament un opérateur d’exception, tout en le privant des occasions de le devenir. La panne, quand elle survient, tombe sur des équipes désentraînées.

L’automatisation ne supprime pas le besoin de compétence humaine. Elle le déplace vers le moment le plus difficile : la panne.

2. La dépendance à l’automatisation, nouvelle dépendance critique

À l’épisode 002, nous avions posé une règle : le cloud n’est pas un problème ; l’inconscience de sa dépendance au cloud en est un. Cette logique s’applique, mot pour mot, à l’automatisation.

Regardez la pile dont dépend un SOC moderne :

• des playbooks SOAR qui orchestrent la réponse,

• un EDR qui isole les postes tout seul,

• un moteur d’IA qui trie et priorise les alertes,

• des remédiations déclenchées sans aucune main humaine.

Chacune de ces briques est un point de dépendance. Et aucune n’est infaillible : un orchestrateur tombe, un connecteur casse, une licence expire, un playbook peut être empoisonné, un modèle peut halluciner. Le SIEM cloud lui-même peut devenir indisponible au pire moment.

Le jour où cette couche s’effondre, l’organisation ne perd pas un outil. Elle perd sa capacité d’agir - si elle n’a rien gardé d’autre.

Automatiser sans savoir faire sans, ce n’est pas gagner en résilience. C’est déplacer sa fragilité d’un cran vers le haut.

3. La compétence qui ne s’exerce pas disparaît

C’est ici que le sujet rejoint la résilience humaine, explorée à l’épisode 012. Nous y ajoutons une dimension : la compétence.

Une compétence n’est pas un acquis. C’est un muscle. Elle s’atrophie si elle ne travaille pas. L’aviation l’a appris dans la douleur : à force de voler au pilote automatique, certains équipages ont perdu les réflexes du pilotage manuel - au point que l’incapacité à reprendre les commandes a figuré parmi les causes premières de plusieurs accidents.

Le SOC n’échappe pas à la règle. Un analyste qui n’a jamais fait qu’appuyer sur « exécuter le playbook » saura-t-il trier une alerte à partir d’un log brut ? Mener une investigation sans la console qui fait tout à sa place ? Reconstruire une chronologie à la main ?

Le contexte aggrave le risque. Le dernier panorama ENISA sur les investissements (NIS Investments 2025) montre un basculement net : les organisations réallouent leurs moyens de l’humain vers la technologie et les services externalisés, tandis que le déficit de talents se creuse et qu’un tiers seulement prévoit de recruter. On automatise pendant qu’on amincit la couche humaine. Le pire moment pour perdre le geste.

Une capacité qu’on ne teste jamais n’est pas une capacité. C’est une supposition.

4. Reprendre la main : l’équivalent cyber de l’exercice de crise

Bonne nouvelle : on sait faire. Depuis longtemps.

Personne n’improvise une gestion de crise. On l’entraîne, encore et encore, par des exercices. C’est toute la logique du guide de l’ANSSI sur les exercices de gestion de crise cyber : les réflexes se construisent exercice après exercice, pour être prêts le jour où l’attaque survient.

La reprise manuelle relève exactement de la même discipline. Elle est l’exercice de crise de la couche automatisée.

Le NIST le formalise depuis quinze ans. Son guide de planification de la continuité (SP 800-34) inscrit noir sur blanc le recours à des « méthodes manuelles » comme mesure intérimaire de reprise - et impose que ces plans soient testés, éprouvés, entraînés. Documenter un mode dégradé sans jamais l’exécuter ne vaut rien.

Concrètement :

• Un « jour sans automatisation » : couper volontairement le SOAR le temps d’un exercice, et traiter les incidents à la main.

• Des runbooks de mode dégradé : la procédure exacte quand l’orchestrateur est indisponible.

• Une rotation des gestes manuels : pour que le savoir-faire ne repose pas sur une seule personne, un seul point de défaillance.

Un mode dégradé qui n’a jamais tourné n’est pas un plan. C’est un espoir.

5. Grille de maturité - la capacité de reprise manuelle

Comme à chaque épisode opérationnel, une grille pour se situer honnêtement - sans complaisance.

On ne vise pas le « tout manuel ». On vise la capacité intacte de basculer quand il le faut.

6. Concevoir pour la panne : la dégradation gracieuse

Un système résilient n’est pas un système qui ne tombe jamais. C’est un système qui tombe bien.

Le NIST, dans son guide sur les systèmes cyber-résilients (SP 800-160 vol. 2), fixe l’objectif : anticiper, résister, se rétablir, s’adapter - et réduire le risque de dépendre de ses ressources numériques. Traduit dans nos SOC, cela signifie concevoir le chemin de repli dès le départ, pas après la panne.

• Une dégradation gracieuse plutôt qu’un effondrement : quand l’automatisation lâche, le système bascule en mode manuel supervisé, pas dans le vide.

• Une commande manuelle prévue par conception : le fameux « bouton rouge », l’override humain, accessible et documenté.

• Un mode dégradé qui n’exige pas la couche perdue : évidence trop souvent oubliée - le repli ne doit pas dépendre de ce qui vient de tomber.

C’est aussi une question de gouvernance. La bonne question pour un COMEX n’est pas « notre SOC est-il automatisé ? ». C’est : « combien de temps tenons-nous sans notre couche d’automatisation - et l’avons-nous vérifié une seule fois ? »

La résilience ne se conçoit pas contre la panne. Elle se conçoit avec elle.

7. Le bon niveau de délégation

Que les choses soient claires : rien de ceci n’est un plaidoyer contre l’automatisation. Revenir au tout-manuel serait absurde, et perdant. L’enjeu n’est pas de déléguer moins. Il est de déléguer lucidement - en gardant, à côté de chaque geste confié à la machine, un humain encore capable de le reprendre.

C’est un arbitrage. Que délègue-t-on ? Jusqu’où ? Que garde-t-on littéralement sous la main ? Ce curseur - entre ce qu’on confie et ce qu’on retient - est le vrai sujet. Il ouvre une question que ce trimestre ne pouvait pas éviter, et que la prochaine chronique regardera en face.

Déléguer n’est pas abdiquer. Encore faut-il l’avoir décidé.

L’Essentiel pour Agir

1. Cartographiez vos dépendances à l’automatisation : listez chaque geste critique aujourd’hui confié à une machine (tri, isolement, remédiation, corrélation) et identifiez, pour chacun, ce qui se passe s’il s’arrête. Une dépendance non cartographiée est une surprise programmée.

2. Documentez ET testez le mode dégradé : écrivez les runbooks de reprise manuelle, puis exécutez-les pour de vrai. Un plan de repli qui n’a jamais tourné ne prouve rien le jour de l’incident.

3. Entraînez la reprise, régulièrement : instaurez un « jour sans automatisation » et faites tourner les gestes manuels dans l’équipe. La compétence se muscle par la répétition, comme un exercice de crise.

Conclusion

L’automatisation est un accélérateur formidable. Elle ne devient un piège que le jour où elle est aussi devenue notre seule option.

Reprendre la main n’est pas un retour en arrière. C’est la preuve qu’on maîtrise encore ce qu’on a confié à la machine. Une capacité qu’on ne peut plus exercer n’est pas une force acquise : c’est une dépendance qu’on ne contrôle plus.

Reste alors le curseur. Jusqu’où déléguer à la machine ce que nous ne saurons peut-être plus reprendre ? C’est la dernière question de ce trimestre. La plus inconfortable, aussi.

Ce n’est pas un statut. C’est une capacité. Et une capacité, ça s’entretient.

Bibliographie

« Lisanne Bainbridge — Ironies of Automation (Automatica, 1983) »

https://www.sciencedirect.com/science/article/abs/pii/0005109883900468

Le texte fondateur du paradoxe : automatiser le routinier laisse à l’humain les seules tâches rares et difficiles, et les compétences non exercées se dégradent. Le socle théorique de tout l’épisode.

« ANSSI — Organiser un exercice de gestion de crise cyber »

https://cyber.gouv.fr/publications/organiser-un-exercice-de-gestion-de-crise-cyber

Guide de référence français sur l’entraînement à la crise : les réflexes se construisent par l’exercice. La reprise manuelle relève exactement de la même discipline.

« NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems »

https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final

Inscrit noir sur blanc le recours à des « méthodes manuelles » comme mesure intérimaire de reprise, et impose de tester, entraîner et maintenir ces plans de continuité.

« NIST SP 800-160 Vol. 2 Rev. 1 — Developing Cyber-Resilient Systems »

https://csrc.nist.gov/pubs/sp/800/160/v2/r1/final

Cadre d’ingénierie de la cyber-résilience - anticiper, résister, se rétablir, s’adapter - et réduire le risque de dépendre de ses ressources numériques : la base de la dégradation gracieuse « by design ».

« ENISA — NIS Investments 2025 »

https://www.enisa.europa.eu/publications/nis-investments-2025

Enquête auprès de 1 080 organisations européennes : bascule des investissements de l’humain vers la technologie et les services, aggravation du déficit de talents. La toile de fond empirique de l’atrophie des compétences.