Agents SOC IA vs. SOAR : Qu’est-ce qui a réellement changé ?

Agents SOC IA vs. SOAR : Qu’est-ce qui a réellement changé ?

Deux affirmations ont dominé le marketing des opérations de sécurité (SecOps) ces deux dernières années, et elles se contredisent. 

• Premièrement : SOAR est mort et remplacé par des agents SOC IA. 
• La seconde : les agents SOC IA ne sont que des SOAR auxquels on a ajouté un modèle de langage. 

Les deux ont tort, et c'est dans cet écart que de nombreux budgets d'évaluation sont mal dépensés. 

Le cycle de vie des technologies émergentes de Gartner pour 2024 prévoyait que SOAR deviendrait obsolète avant de se stabiliser, ce qui a conforté la première affirmation. Cependant, la structure du marché et les besoins des clients sont deux choses distinctes, et seule l'une a disparu. La suite de cet article s'appuie sur des données probantes, retraçant l'histoire de SOAR : son impact, les changements opérés par les acteurs du secteur, leurs points faibles, et l'architecture à deux niveaux vers laquelle convergent de plus en plus les déploiements en production.

Ce que le marché a bien compris concernant le déclin de SOAR 

SOAR excellait dans un domaine : l’encodage des procédures connues en flux de travail exécutables. Décrivez la procédure suivie par votre équipe pour un courriel d’hameçonnage signalé (analyse, suppression des pièces jointes, vérification de l’URL, recherche d’autres destinataires, mise en quarantaine, notification) et SOAR l’exécutait à l’identique, à la vitesse de la machine, dix mille fois par jour, avec un journal de chaque étape.

Ses atouts étaient le déterminisme, la reproductibilité et la traçabilité. Une même entrée produisait le même résultat. On pouvait ainsi démontrer précisément à un auditeur le déroulement des opérations et leurs raisons.

Leurs limites étaient rédhibitoires. Les playbooks ne traitaient que des situations anticipées par leurs auteurs. Leur élaboration et leur maintenance exigeaient un effort d'ingénierie et une structuration des flux de données que la plupart des équipes sous-estimaient. La critique de Gartner portait principalement sur cette charge de maintenance, ainsi que sur la consolidation du marché et les coûts. De plus, un playbook ne pouvait exercer de jugement. Face à l'ambiguïté, il ne prenait de décisions que selon des conditions préalablement définies. 

Il en a résulté une répartition de la charge de travail que tout participant à un audit d'outils SOC reconnaîtra. Les équipes automatisaient la part bien comprise et répétitive de leurs alertes, mais restaient submergées par le reste, ambigu, ces alertes qui nécessitaient l'intervention d'un analyste. Les playbooks géraient le volume d'alertes. L'analyse, quant à elle, restait humaine.

Quels agents en fait modifié 

Les agents SOC IA traitent les alertes restantes selon une approche fondamentalement différente de celle de SOAR, et non par de simples modifications incrémentales. Un agent ne suit pas un chemin prédéfini ; il construit le sien. Il analyse l’alerte, détermine les preuves susceptibles de la confirmer ou de l’infirmer, interroge les systèmes pour obtenir ces preuves, ajuste son approche au fur et à mesure des résultats et rend un verdict accompagné d’une justification écrite. 

Les manuels de jeu décrivent la procédure. Les agents font une approximation du jugement.

Il s'agit d'une véritable évolution des capacités, et non d'un simple changement d'image. L'automatisation déterministe ne permettait pas d'analyser de manière structurée les alertes nouvelles et ambiguës. C'est désormais partiellement possible. L'idée qu'il suffise d'un SOAR avec un LLM ne résiste pas à l'épreuve du terrain.

Quels agents n'ont pas changé

Le jugement a un prix. Les agents fonctionnent par probabilités. Menez deux fois la même enquête et vous obtiendrez des pistes différentes et, parfois, des conclusions différentes. Ils peuvent se tromper en toute confiance.

Une boucle de raisonnement LLM est également inadaptée aux tâches déjà déterministes. Aucun responsable de la sécurité ne souhaite un modèle improvisant une séquence de confinement, une étape de préservation des preuves ou une chaîne de notification aux autorités de réglementation. Ces procédures doivent s'exécuter avec exactitude, systématiquement et avec justification.

Voilà pourquoi le discours de remplacement échoue. L'exécution déterministe, les processus rigoureux, l'infrastructure d'intégration et l'audit sont restés indispensables. Au contraire, ils le sont devenus davantage, car un système probabiliste est désormais au cœur du système et requiert précisément ces propriétés.

Point de convergence des déploiements SOAR et SOC IA 

En production, les deux fonctionnalités se composent en couches.

• Couche 1, raisonnement de l'agent : Triage, enquête, verdict, recommandation. La zone intermédiaire ambiguë.
• Couche 2, exécution déterministe : Quelles actions sont autorisées à quel niveau d'autonomie ? Quelles actions requièrent une approbation humaine ? Comment le confinement est-il mis en œuvre ? Quelles informations sont consignées ? Que se passe-t-il lorsque la confiance de l'agent diminue ? Les recommandations d'évaluation de Gartner pour 2026 vont dans le même sens, préconisant des garde-fous obligatoires pour les actions à fort impact et une escalade automatique en cas d'ambiguïté.

On pourrait parler d'agents protégés par des garde-fous. La couche de raisonnement est probabiliste, contrairement à la couche d'autorisation et d'exécution. Les équipes qui déploient des agents sans cette seconde couche se fient à l'autorégulation du modèle, et une simple invite ne constitue pas un contrôle. Celles qui restent fidèles à une approche SOAR pure continuent de rémunérer des analystes pour un travail de première analyse que les machines peuvent désormais prendre en charge.

Quelles sont les implications pour l'évaluation de l'automatisation des SOC ? 

La question de l'architecture SoC d'IA se transforme en quatre questions d'achat, et elles segmentent le marché plus rapidement que n'importe quelle matrice de fonctionnalités :

1. Est-il possible de retracer le verdict d'un agent jusqu'aux preuves qu'il a examinées, et de reproduire ce parcours pour un auditeur ?
2. Où se trouvent les autorisations d'action : dans l'invite ou dans une couche de stratégie appliquée en dehors du modèle ?
3. Que se passe-t-il lorsque la confiance est faible, et qui définit ce seuil ?
4. La couche d'exécution déterministe du fournisseur était-elle antérieure à l'IA, ou est-elle arrivée comme une surcouche après coup ?

Cette dernière question est celle que les acheteurs omettent. Les fournisseurs qui considèrent l'orchestration comme une solution héritée finissent par livrer des agents impossibles à auditer. Ceux qui la considèrent comme un module complémentaire se contentent d'un bouton de synthèse. Chez Swimlane, nous avons continué d'investir dans la couche d'exécution plutôt que de la remplacer, car nous savons qu'une autonomie gérable nécessite les deux et que la partie déterministe est bien plus difficile à intégrer a posteriori.

En résumé : qu'est-il arrivé au marché SOAR ? 

Le marché SOAR autonome a disparu, absorbé par des plateformes plus vastes, comme l'avait prédit Gartner. La discipline, elle, a perduré. L'orchestration, l'exécution déterministe et l'audit sont devenus les fondements qui permettent de maîtriser l'autonomie des agents.

Ce qui a changé, c'est la répartition des tâches. Les machines effectuent une première analyse, et les humains les pilotent. Le système qui assure ce pilotage est rarement visible lors de la démonstration, et c'est lui qui détermine si le système survivra au contrôle de l'auditeur.