L'IA n'a pas remplacé notre équipe de sécurité, elle l'a démultipliée

Pendant des années, l'hypothèse en sécurité a été simple : des programmes de détection et de réponse matures nécessitaient un SOC (Security Operations Center). Une équipe d'analystes devant un mur d'écrans, attendant qu'une alerte se déclenche.

Ce modèle avait du sens tant que la seule façon de faire évoluer le jugement humain était d'embaucher davantage de personnes.

La version honnête de l'IA dans le SOC

La conversation sur l'IA en sécurité relève surtout, à l'heure actuelle, du bruit des fournisseurs. Chaque outil promet de régler un silo du SOC. Triage. Enrichment. Threat intel. En achetez-en suffisamment, et vous venez simplement de reconstruire la même pile fragmentée, avec un badge IA sur chaque brique.

Ce que personne ne dit assez fort, c'est ceci : il n'est pas nécessaire d'acheter son chemin vers une sécurité assistée par IA. Une petite équipe, technique et motivée, peut développer ces capacités en interne, avec une intégration plus étroite, un meilleur contexte et bien plus de contrôle qu'aucun produit fournisseur ne pourra offrir.

Chez Webflow, nous avons passé l'année écoulée à intégrer l'IA dans nos workflows de détection et de réponse. Pas comme pilote. Pas comme démonstration. En production, activement affinée, et toujours en évolution. Et la chose la plus importante que nous ayons apprise est celle-ci :

L'IA n'a pas changé à quoi ressemble une bonne sécurité. Elle a changé ce qu'une équipe peut accomplir.

Ce que nous avons réellement construit

Le programme de détection et de réponse en sécurité de Webflow est piloté par des ingénieurs. Il n'y a pas de SOC. Il n'y a pas d'analystes dédiés se relayant en rotation. Il y a une petite équipe d'ingénieurs sécurité responsable de tout le cycle de vie : rédiger et tester les détections, répondre aux incidents et améliorer le système au fil du temps. Pendant longtemps, cela impliquait une priorisation sans concession, car il est tout simplement impossible d'enquêter sur tout. On fait des compromis.

L'IA a fait bouger ces compromis de deux façons concrètes.

1. Un triage qui ne part pas de zéro

Chaque alerte commençait autrefois de la même façon : ouvrir le ticket, récupérer le contexte, vérifier le propriétaire de l'actif, corréler l'activité récente, poser une première évaluation de gravité. Le travail n'est pas difficile, mais il prend du temps. Se connecter à plusieurs plateformes pour valider des journaux sur plusieurs systèmes, avant même que la véritable enquête ne commence.

Honnêtement, l'IA nous a forcé la main sur ce point. Lorsque nous avons constaté une augmentation de 200 % des détections en un seul trimestre, il est devenu clair que l'ancien modèle, chaque alerte repartant de zéro, chaque triage effectué manuellement, ne tiendrait pas. Nous avons dû repenser le workflow, pas seulement ajouter de la capacité.

Nous utilisons désormais l'IA pour effectuer le travail d'assemblage avant même qu'un ingénieur ne regarde une alerte. Au moment où un humain intervient, le ticket dispose déjà d'un contexte enrichi, de signaux historiques pertinents et d'une évaluation préliminaire de gravité. Et pour les alertes où nous avons une confiance élevée qu'il s'agit d'un faux positif, nous avons construit des mécanismes de clôture automatique qui gèrent la résolution entièrement sans intervention humaine. Ce n'est pas un raccourci. C'est une décision architecturale délibérée, construite sur des mois de calibrage et de validation. Nous savons exactement quels schémas d'alerte franchissent le seuil de la clôture automatique, et nous révisons ce critère régulièrement à mesure que notre environnement évolue. Ces petits changements ont fait gagner à notre équipe 504 heures sur un seul trimestre. 

L'ingénieur continue de prendre chaque décision de jugement qui compte. L'IA gère la préparation et retire entièrement du tableau les faux positifs évidents.

Ce que nous avons observé en pratique : un triage plus rapide, moins de fatigue liée aux changements de contexte, et des enquêtes de meilleure qualité, parce que les ingénieurs partent d'une image plus complète plutôt que de la construire de zéro sous pression.

2. Les LLM comme partenaires d'enquête

Le problème le plus difficile, c'est l'enquête ambiguë, celle où les signaux doivent être assemblés à travers les couches identité, endpoint et application, sans qu'aucun playbook ne s'applique clairement. Quelle que soit l'expérience, les intervenants se demandent souvent : « Que fais-je ensuite ? »

C'est là que nous expérimentons le plus prudemment avec les LLM. Pas pour prendre des décisions, mais pour réduire la charge cognitive pendant un triage complexe : résumer de gros volumes de logs bruts, faire ressortir des incidents passés similaires et leurs playbooks associés, suggérer les prochaines étapes, et rédiger des chronologies initiales qu'un ingénieur valide et complète ensuite. L'humain reste dans la boucle à chaque point de décision significatif. Ce n'est pas une limitation que nous contournons. C'est un principe de conception. L'IA fait ressortir, organise et suggère. Les ingénieurs valident, décident et agissent. Le moment où cette frontière s'estompe est le moment où l'on introduit un risque difficile à auditer, et plus difficile encore à expliquer après coup.

Nous sommes délibérés sur les cas où nous faisons confiance aux résultats de l'IA et ceux où nous les vérifions indépendamment. Cette confiance se gagne progressivement, de la même façon que nous gagnons confiance dans toute nouvelle logique de détection avant de la laisser tourner sans supervision.

3. L'IA dans le processus post-incident

L'une des applications les plus sous-estimées de l'IA en sécurité ne se situe pas du tout dans la phase de détection ou de réponse. Elle se situe dans ce qui se passe après la clôture d'un incident.

L'analyse post-incident fait partie de ces processus dont tout le monde reconnaît la valeur, et dans lesquels presque personne n'investit. Quand on vient de passer des heures ou des jours en mode réponse, s'asseoir pour rédiger une analyse post-incident approfondie est bien la dernière chose pour laquelle on a de l'énergie. Le résultat est généralement une documentation plus mince qu'elle ne devrait l'être, des actions qui ne sont pas suivies, et des leçons qui ne trouvent jamais leur chemin de retour vers les playbooks.

Nous avons commencé à utiliser l'IA pour changer cela.

Une fois un incident clôturé, nous alimentons l'IA avec l'ensemble des preuves issues de la réponse : chaque message du canal de l'incident, les transcriptions de réunions, les notes, les documents de chronologie et les artefacts pertinents. L'IA effectue ensuite le travail de synthèse qui prenait autrefois des heures :

• Passer en revue toutes les communications et documents pour reconstituer une chronologie complète de l'incident.
• Rédiger l'analyse post-incident : ce qui s'est passé, ce que nous avons bien fait, ce que nous avons manqué, et où nous avons eu de la chance.
• Générer des actions avec suffisamment de contexte pour qu'elles soient réellement exploitables, pas de simples rappels vagues.
• Mettre à jour ou créer des playbooks à partir de ce que l'incident a révélé : combler les lacunes, corriger les hypothèses et capturer les cas particuliers qui n'apparaissent que lors d'incidents réels.

Il est facile de rédiger un bilan post-incident qui se concentre sur ce qui s'est mal passé et ce qui s'est bien passé. La chose la plus difficile et la plus précieuse est de capturer les coups de chance, les éléments qui se sont bien déroulés non pas grâce au système mais en dépit de lui. C'est souvent là que se cachent les améliorations les plus importantes. L'IA est étonnamment douée pour les faire ressortir lorsqu'elle dispose du contexte complet des communications de l'incident.

Le résultat est une documentation post-incident plus complète, produite plus rapidement, et qui alimente réellement le système de détection et de réponse plutôt que de dormir dans un dossier. Chaque incident produit un résultat concret : un playbook mis à jour, une lacune signalée, une règle de détection proposée. L'IA fait le travail de fond. Les ingénieurs font la validation et bouclent la boucle. La différence, c'est que rien ne se perd dans l'épuisement qui suit un incident difficile.

La partie que la plupart des contenus sur l'IA en sécurité omettent

Voici ce qui n'est pas dit assez souvent : une réponse assistée par IA n'est jamais meilleure que la fondation sur laquelle elle repose.

Avant de pouvoir tirer de la valeur du triage par IA, il nous fallait :

• Des pipelines de données propres et fiables alimentant notre SIEM, et pas seulement du volume de données, mais des données correctement formatées et normalisées sur lesquelles l'IA peut réellement raisonner de façon utile.
• Un inventaire des actifs bien tenu, afin que l'enrichissement soit exact.
• Une logique de détection suffisamment calibrée pour que l'IA ne fasse pas que traiter du bruit plus vite.
• Des playbooks documentés et un historique des incidents sur lesquels les LLM peuvent raisonner.

Si ces éléments ne sont pas en place, l'IA ne résout pas le problème. Elle l'amplifie. Les détections bruyantes deviennent plus bruyantes encore. Un contexte obsolète est présenté avec assurance. Les faux positifs sont triés plus efficacement, tout droit vers du temps d'ingénierie gaspillé.

Les équipes que nous avons vues peiner avec l'IA en sécurité n'échouent pas parce qu'elles ont choisi le mauvais modèle. Elles échouent parce qu'elles essaient d'utiliser l'IA pour compenser des lacunes fondamentales que l'IA ne peut pas combler.

Ce que « agnostique en matière de modèle » signifie vraiment pour nous

Nous refusons délibérément de nous enfermer sur un seul fournisseur d'IA. Les outils de ce domaine évoluent trop vite pour prendre ce pari, et la capacité sous-jacente compte plus que la marque.

Ce que nous avons découvert, c'est que la bonne question n'est pas « quel modèle ? ». C'est « où le jugement de l'IA apporte-t-il de la valeur, et où a-t-il besoin d'une vérification humaine ? » Cette question doit être tranchée cas par cas, selon le niveau de risque, et honnêtement, selon le type d'incident.

Certaines alertes se prêtent bien au triage automatique assisté par IA. D'autres, tout ce qui touche à un accès privilégié, à des données clients ou à des scénarios de compromission potentielle, sont examinées d'abord par des yeux humains, l'IA jouant un rôle de soutien plutôt que de premier plan. C'est un choix architectural délibéré, pas une lacune que nous prévoyons de combler.

Ce qu'une petite équipe peut réellement accomplir aujourd'hui

Assurer la sécurité d'une entreprise en croissance sans SOC signifiait autrefois accepter un plafond sur ce que l'on pouvait couvrir. On calibrait les détections pour réduire le volume, on automatisait l'évident, et on triait le reste par priorité.

Ce plafond s'est déplacé. Pas parce que l'IA est magique, mais parce qu'elle prend en charge le travail cognitif répétitif suffisamment bien pour que les ingénieurs puissent consacrer plus de temps au travail exigeant en jugement, celui qui a vraiment besoin d'eux.

Un triage plus rapide. Une meilleure qualité d'enquête. Moins de fatigue les jours à fort volume d'alertes. Nous mesurons encore soigneusement l'impact à long terme, mais le signal directionnel est clair.

Une petite équipe de sécurité bien structurée, avec l'IA intégrée dans chaque boucle du cycle de vie de la réponse aux incidents, nous permet d'opérer à un niveau qui aurait nécessité, il y a deux ou trois ans, des effectifs nettement plus importants. Ce n'est pas un argument commercial. C'est ce que nous observons en pratique.

Ce qu'il faut retenir

Vous n'avez pas besoin d'un SOC. Vous avez besoin d'un système, un système avec des données propres, des détections calibrées, des processus documentés et des boucles de rétroaction qui le rendent plus intelligent avec le temps. L'IA ne remplace pas ce système. Elle permet à une petite équipe d'ingénieurs qui se font confiance d'avancer au rythme de l'activité sans avoir besoin d'augmenter les effectifs pour y arriver. Construisez d'abord la fondation. Comprenez votre paysage de menaces avant d'automatiser. Et lorsque vous intégrez l'IA à la boucle, soyez honnête sur les points où elle gagne votre confiance et ceux où elle a encore besoin d'une vérification humaine.

C'est la version de la sécurité assistée par IA qui fonctionne vraiment.