Chapitre 1Modélisation des menaces des pipelines agentiques

Chaque génération de testeurs de sécurité a été confrontée à une lacune de l'automatisation. Les scripts nous ont rendus plus rapides, les frameworks nous ont rendus plus organisés, mais aucun de ces systèmes et outils ne pouvait penser et agir de façon autonome. Puis les grands modèles de langage sont arrivés. Du jour au lendemain, les testeurs ont eu accès à des agents IA : des moteurs de raisonnement capables de prioriser des scans, de réécrire des charges utiles et de résumer des résultats en temps réel. Pourtant, sans systèmes structurés en place, ces agents IA peuvent devenir chaotiques et produire des idées sans responsabilité ni reproductibilité. Ce livre est écrit pour les praticiens de la sécurité offensive : les personnes dont le métier consiste à penser comme des programmes de divulgation, les red teamers embauchés pour simuler le comportement d'un adversaire, les testeurs d'intrusion menant des évaluations autorisées, et les chercheurs en sécurité qui étudient comment les systèmes échouent afin de les rendre plus solides.

Black Hat AI est écrit pour les professionnels de la sécurité offensive : chasseurs de bugs, red teamers, testeurs d'intrusion et chercheurs en sécurité qui savent déjà utiliser des outils, mais veulent les utiliser avec plus de précision, à plus grande échelle et avec une meilleure intention. Ce livre n'est pas un catalogue d'outils de hacking. C'est un guide sur la façon dont l'information circule au cours d'une mission de sécurité offensive, et sur la façon dont l'IA peut améliorer considérablement ce processus sans remplacer le jugement humain.

Au cœur de cette approche se trouvent les artefacts : les sorties structurées produites par des outils tels que les scans de ports, les sondes HTTP, les résultats d'énumération et les observations comportementales. Les artefacts sont l'information qui permet d'utiliser les outils avec précision. Traités comme des objets de première classe, les artefacts peuvent être acheminés délibérément depuis la reconnaissance initiale vers des tactiques plus profondes et plus risquées.

Tout au long du livre, l'IA est utilisée comme aide à la décision, et non comme une automatisation devenue incontrôlable. Les outils réalisent toujours l'exécution. Les humains définissent toujours les objectifs et approuvent les escalades. Les pipelines régissent la circulation de l'information. Les agents assistent en interprétant les résultats, en priorisant l'effort et en réduisant la charge cognitive. Si vous chaînez déjà des outils entre eux pendant vos missions, ce livre vous semblera familier. Si vous avez déjà souhaité pouvoir le faire de façon plus délibérée, plus scalable et avec plus de discernement, ce livre vous montre comment l'IA rend cela possible.

1.1 La sécurité offensive

La sécurité offensive permet à des professionnels de tenter de compromettre des systèmes, des applications et des réseaux afin d'identifier des faiblesses. Elle simule des attaques réelles pour identifier les vulnérabilités des systèmes logiciels avant que des acteurs malveillants ne puissent les exploiter. Cela inclut les tests d'intrusion, le red teaming, les évaluations de vulnérabilités et le hacking éthique, qui aident les organisations à identifier et traiter les menaces de façon proactive. Les équipes de sécurité défensive (aussi appelées défenseurs) corrigent ensuite ces vulnérabilités et améliorent les processus.

Les opérations offensives se nourrissent d'adaptabilité. Les surfaces d'attaque évoluent quotidiennement, les technologies évoluent plus vite que les scanners statiques ne peuvent suivre, et le volume de données submerge même les analystes expérimentés. L'IA introduit le raisonnement contextuel : la capacité de comprendre ce qu'un résultat signifie, et pas seulement qu'il existe. En reconnaissance, elle peut corréler des signaux faibles sur des centaines d'actifs ; pendant l'exploitation, elle peut proposer un changement de stratégie lorsqu'une charge utile échoue. Pour les défenseurs, étudier ce comportement aide à anticiper la façon dont les adversaires assistés par IA opéreront.

1.1.1 Les workflows traditionnels de sécurité offensive

Le pipeline classique de test d'intrusion suit une séquence linéaire : collecte de données → évaluation des vulnérabilités → notation du risque → planification du chemin d'attaque → décision ou transfert. Cette approche est déterministe et pilotée manuellement ; elle est dépourvue des composants de rétroaction et de raisonnement qu'introduit l'IA.

1.1.2 Bonnes pratiques de la sécurité offensive

Une sécurité offensive efficace exige de la discipline et de la structure, afin que nos tests apportent de la valeur sans causer de dommages ni de complications juridiques. Nous décrivons les sept bonnes pratiques qui aident les équipes de sécurité offensive (red teams et testeurs d'intrusion, par exemple) à maintenir leur professionnalisme et à maximiser leur impact.

1. Périmètre autorisé uniquement. Ne lancez jamais de tests ni d'expériences contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation écrite explicite. Un consentement verbal ne suffit pas — obtenez-le par écrit.
2. Aucun dommage en production. N'exécutez pas de charges utiles destructrices ou intrusives contre des systèmes de production. Utilisez des bacs à sable, des réseaux isolés ou des environnements de test explicites.
3. Respectez la loi. Les lois locales, nationales et internationales s'appliquent. Vous êtes responsable de votre conformité. L'ignorance n'est pas une excuse.
4. Supervision humaine. Une revue humaine est requise pour toute action susceptible d'entraîner une perte de données, une interruption de service ou une atteinte à la vie privée. N'exécutez pas d'expériences à haut risque sans surveillance.
5. Protégez les données sensibles. Masquez, caviardez ou évitez de capturer des données personnelles. Si vous collectez de la télémétrie sensible pendant vos tests, sécurisez-la et supprimez-la dès qu'elle n'est plus nécessaire.
6. Documentez tout : journalisez les prompts, les décisions de l'agent, les actions entreprises et les résultats. Des journaux bien tenus sont votre meilleure protection — technique comme juridique.
7. Divulgation responsable. Si vous découvrez une vraie vulnérabilité, suivez un processus de divulgation responsable et laissez au propriétaire un délai raisonnable pour la corriger avant de publier vos résultats.

C'est pourquoi les testeurs offensifs d'aujourd'hui ont besoin de pipelines d'agents IA : des chaînes structurées d'agents intelligents qui combinent raisonnement et répétabilité. Ces pipelines transforment l'exploration créative en expériences contrôlées et mesurables. C'est ainsi que l'on passe de prompts astucieux à des systèmes fiables — et c'est ainsi que les défenseurs peuvent reproduire cette même intelligence en toute sécurité pour renforcer la préparation de leurs équipes.

1.1.3 Pourquoi les outils seuls ne suffisent plus

Pendant des décennies, la sécurité offensive a progressé grâce à de meilleurs outils. Les scanners sont devenus plus rapides, les frameworks plus complets et le scripting plus souple. Chaque génération d'améliorations a réduit l'effort manuel et augmenté la couverture. Pourtant, malgré ces progrès, la plupart des praticiens expérimentés constatent le même problème persistant : l'outillage a bien mieux fait passer à l'échelle l'exécution que la compréhension.

Les environnements de sécurité modernes génèrent des volumes de sorties écrasants. Les outils de reconnaissance énumèrent des milliers d'actifs. Les scanners renvoient des centaines, voire des milliers de résultats. Journaux, en-têtes, certificats et métadonnées s'accumulent plus vite qu'un humain ne peut raisonnablement les interpréter. Le facteur limitant n'est plus l'accès à l'information ni la capacité d'exécuter des tests, mais bien la charge cognitive que représente le fait de décider ce qui compte, quoi faire ensuite, et pourquoi.

L'automatisation traditionnelle excelle dans les actions répétables. Elle exécute des commandes, applique des règles et produit des sorties. Ce qu'elle ne fait pas, c'est raisonner sur l'ensemble des résultats, adapter sa stratégie au contexte, ou expliquer comment une action en a influencé une autre. En conséquence, les opérateurs humains se retrouvent contraints d'endosser le rôle d'orchestrateurs : coudre manuellement ensemble des outils disparates, relancer des tests, réévaluer des priorités et maintenir un état mental tout au long de workflows longs et fragmentés.

Ce n'est pas un échec des outils individuels. La plupart des organisations disposent déjà d'un outillage de sécurité très capable. La vraie limite tient à la coordination. Les outils agissent isolément, tandis que les humains fournissent la logique de liaison. À mesure que les environnements se complexifient et que les surfaces d'attaque deviennent plus dynamiques, la coordination manuelle devient fragile, inconstante et difficile à auditer. Le problème n'est donc pas un manque de capacités. C'est l'absence d'un système intelligent capable de guider les outils existants de manière cohérente, constante et avec une intention traçable.

1.2 Les grands modèles de langage (LLM) comme outils de sécurité

Les grands modèles de langage (LLM, large language models) sont des systèmes d'IA entraînés sur d'immenses corpus de données textuelles pour comprendre et générer du langage humain. Les LLM sont entraînés avec des réseaux de neurones profonds, des modèles contenant des milliards de paramètres et capables d'apprendre des motifs complexes. Ces modèles lisent des exemples textuels de partout — Internet, livres, articles et toute autre information textuelle — afin d'apprendre les régularités statistiques du langage.

Pendant l'entraînement, le modèle apprend que certains éléments de texte appelés tokens ont tendance à en suivre d'autres. On peut voir les tokens comme des unités fonctionnelles de langage : caractères, mots, phrases, voire paragraphes. Les LLM apprennent comment les phrases sont structurées et comment les concepts se relient les uns aux autres à partir de l'agencement des tokens. Une fois l'entraînement terminé, le modèle peut prédire et générer le prochain token le plus probable d'après les probabilités apprises.

En résumé, les LLM ne « comprennent » pas le texte : ils prédisent le token suivant à partir du contexte. À grande échelle, cet acte simple devient puissant : le modèle peut résumer des journaux, réécrire du code ou décrire une surface d'attaque en langage naturel.

En sécurité offensive, un testeur peut injecter la sortie brute de scanners ou d'API dans un LLM et obtenir en quelques secondes une analyse raisonnée et structurée. C'est toute la différence entre collecter des données et les interpréter.

Aussi puissants soient-ils, les LLM ont des limites dont il faut être conscient. En raison de leur nature probabiliste, ils peuvent halluciner : un modèle de langage génère alors une information qui paraît assurée et plausible, mais qui est factuellement fausse ou inventée. De plus, les sorties des LLM sont non déterministes (les mêmes données d'entrée peuvent produire des réponses différentes), ce qui n'est pas idéal dans des situations à fort enjeu comme la sécurité, où les menaces doivent toujours être signalées et détectées. Enfin, l'entraînement de modèles d'IA exige un examen attentif, car les écueils sont nombreux — le plus courant étant que les modèles ont tendance à mémoriser ou à surapprendre des données d'entraînement mal curées ou mal nettoyées. En résumé, nous devons traiter chaque LLM comme une API de raisonnement stochastique — puissante mais faillible — et toujours garder un humain dans la boucle.

Les LLM font passer l'automatisation de « exécute ceci » à « explique cela ». Leur force est le contexte, pas le code. Maniés avec précaution, ils deviennent des composants de raisonnement au sein de systèmes plus larges. Nous verrons ensuite comment les pipelines apportent à ces systèmes structure et sécurité.

1.2.1 L'intelligence comme composant

Les tests de sécurité ont toujours cherché un équilibre entre vitesse et compréhension. Les outils de sécurité traditionnels accélèrent l'exécution des tâches routinières, mais ils manquent de restitution intelligente et de discernement. Les applications de sécurité par IA les plus récentes génèrent des analyses hautement contextualisées, mais nécessitent des contrôles humains supplémentaires sur leurs sorties. En sécurité offensive, cette structure sépare le chaos créatif de l'expérimentation contrôlée. Les workflows d'hier étaient centrés sur le développeur, avec des outils en ligne de commande comme les tâches cron et les boucles bash. Les outils d'aujourd'hui sont des agents conscients du contexte qui s'adaptent ; ceux de demain seront des pipelines d'agents IA à grande échelle orchestrant reconnaissance, exploitation et reporting, à l'image de la façon dont de vrais adversaires apprennent de leurs retours d'expérience.

Imaginez remplacer un scanner de sous-domaines par force brute par un pipeline qui infère les conventions de nommage (comme api-v2 ou dev-login), élague les candidats impossibles et fait pivoter votre stratégie de sécurité lorsque les réponses changent. Le testeur passe moins de temps à trier du bruit et plus de temps à valider les résultats qui comptent.

1.3 Les agents IA : un raisonnement qui agit

Les LLM sont de puissants moteurs de raisonnement, mais par défaut ils sont passifs : ils répondent quand on les sollicite et s'arrêtent une fois terminé. Un agent IA ajoute le composant manquant qui les rend bien plus puissants : les agents peuvent raisonner automatiquement sur des problèmes complexes, établir un plan d'action et agir en fonction de ce qu'il convient de faire ensuite. Concrètement, les agents transforment le raisonnement en action. Ils ne se contentent pas de décrire des motifs — ils poursuivent des objectifs.

1.3.1 Qu'est-ce qu'un agent IA ?

Un agent est une entité logicielle légère qui combine un modèle de raisonnement (tel qu'un LLM) avec des composants supplémentaires : outils, mémoire et objectifs. Un LLM génère du texte à partir d'un prompt. Un agent étend cela en planifiant des actions à partir de ce texte. Il reçoit un objectif (« cartographier la surface d'attaque »), utilise le modèle pour raisonner sur les étapes possibles, appelle des outils ou des scripts externes, évalue ce qui se produit, et boucle jusqu'à ce que l'objectif soit atteint ou qu'une limite soit atteinte. En bref : les LLM génèrent des réponses ; les agents génèrent des comportements.

Un système d'agent IA s'appuie sur un grand modèle de langage en y ajoutant l'orchestration — la logique qui détermine l'étape suivante. Le modèle fournit le raisonnement et la génération de langage, mais l'orchestration lui donne une direction. Autour de ce noyau gravitent trois composants clés : les outils, qui permettent à l'agent d'entreprendre de vraies actions ; la mémoire, qui lui permet de se souvenir de ce qui s'est passé ; et la base de connaissances, qui ancre son raisonnement dans des faits. Ensemble, ces éléments transforment un LLM statique en un résolveur de problèmes actif. Un LLM répond à des prompts. Un agent répond à des objectifs.

1.3.2 Pourquoi les agents comptent en sécurité offensive

Illustrons comment les agents IA peuvent renforcer et faciliter la sécurité offensive. Le test d'intrusion simule une cyberattaque sur un système, un réseau ou une application afin d'identifier des vulnérabilités exploitables. Traditionnellement, c'est le testeur d'intrusion qui écrit l'ensemble des scripts conçus pour casser le système et y identifier les vulnérabilités à corriger. Comme pour toute base de code, la difficulté du test d'intrusion tient à ce que le test manuel est un processus lent qui repose sur des professionnels de la sécurité pour écrire des exploits. De plus, il est impossible d'explorer tous les vecteurs d'attaque, surtout compte tenu des autres tâches qu'un professionnel de la sécurité doit gérer au quotidien. Enfin, ces tests traditionnels offrent un instantané de l'état actuel du système, alors que l'environnement change constamment à mesure que du nouveau code est déployé et que de nouvelles versions de bibliothèques sortent.

Un agent IA peut automatiser ces points de douleur, permettant aux professionnels de la sécurité d'écrire rapidement des tests, d'explorer dynamiquement de nouveaux exploits et de répondre aux menaces émergentes sans intervention humaine. Par exemple, un professionnel de la sécurité peut créer un agent de reconnaissance qui lit les journaux système et réseau, raisonne sur les motifs de nommage, prédit les points de terminaison d'administration probables et affine ses propres requêtes à la volée.

L'une des principales forces des agents IA est leur capacité à réagir dynamiquement aux changements de leur environnement. Par exemple, en reconnaissance, l'énumération d'hôtes est le processus d'identification et de collecte d'informations sur les hôtes actifs d'un réseau. En scannant la surface d'attaque, vous pouvez découvrir de nouveaux chemins d'attaque. Les agents IA peuvent être appliqués à l'énumération d'hôtes en cours d'opération, en prenant en temps réel des décisions qui exigeraient autrement un jugement humain. Par exemple, l'agent IA peut détecter automatiquement qu'une nouvelle cible du réseau utilise le framework Laravel et basculer instantanément vers des charges utiles ou des motifs de recherche visant les points de terminaison spécifiques à Laravel. L'agent peut signaler ce point sans attendre qu'un opérateur humain remarque le motif, et il peut être configuré avec des actions de suivi : soit résoudre automatiquement le problème, soit impliquer un humain dans la boucle pour une validation manuelle.

Les agents IA peuvent aider les équipes offensives à corréler des indicateurs, à adapter des charges utiles et à faire persister des stratégies d'une mission à l'autre — réduisant le bruit, accélérant la découverte et mettant au jour des surfaces d'attaque logiques qui resteraient invisibles aux outils conventionnels. Pour les défenseurs, étudier le comportement des agents peut aider les équipes à élaborer des stratégies pour atténuer la manière dont les adversaires assistés par IA opéreront dans la nature.

1.3.3 Un workflow agentique de sécurité offensive

Lorsqu'un agent IA est intégré au workflow, les étapes de reconnaissance et de test d'intrusion deviennent partie d'une boucle de rétroaction adaptative. L'agent initie des tâches, trie les résultats et affine dynamiquement sa stratégie — illustrant comment l'intelligence transforme des procédures statiques en un processus continu et conscient du contexte.

1.4 Les pipelines : des systèmes de routage de l'information

Dans le travail concret de sécurité offensive, l'information avance toujours. La reconnaissance initiale produit des résultats bruts, qui sont réduits, filtrés et enrichis à mesure que les tests progressent. Les ports mènent aux services. Les services mènent aux points de terminaison. Les points de terminaison mènent à des interactions plus profondes.

Ce flux existe déjà dans toutes les missions.

Ce que ce livre appelle un pipeline n'est que la formalisation de ce flux d'information.

Un pipeline définit comment les artefacts — les sorties structurées des outils — passent d'une étape de test à la suivante. Il ne réalise ni scan, ni fuzzing, ni exploitation. Il détermine quelle information est autorisée à avancer, et sous quelles conditions. Les pipelines ne remplacent pas les outils. Ils acheminent la sortie des outils vers l'avant, de façon contrôlée.

1.4.1 Le pipeline comme principe organisateur

Si l'agent IA est l'ouvrier, le pipeline est l'atelier. Un pipeline est simplement une façon structurée de chaîner des composants fonctionnels de sorte que chacun alimente le suivant. Par exemple, le test d'intrusion se compose des phases distinctes suivantes, qui s'alimentent mutuellement : reconnaissance (collecte de renseignement), scan et énumération, analyse des vulnérabilités, exploitation de la vulnérabilité, analyse post-exploitation, reporting, remédiation et re-test.

Les pipelines présentent plusieurs avantages clés par rapport aux scripts ad hoc lancés manuellement :

• Ce sont des automatisations qui augmentent la vitesse et l'efficacité de livraison du logiciel.
• Les pipelines standardisent le processus, apportant cohérence et fiabilité.
• Les pipelines sont scalables et peuvent servir à tester des centaines de systèmes simultanément.
• Les pipelines sont économiques, précisément parce qu'ils sont scalables et automatisables.
• Ils peuvent s'exécuter sur des planifications ou des déclencheurs, ce qui permet une surveillance continue.
• Les pipelines sont une forme de documentation déclarative.
• Les pipelines peuvent être programmés pour générer automatiquement journaux et rapports.

Dans le contexte des agents IA, les pipelines définissent l'ordre des opérations, les contrôles qualité et les chemins de rétroaction qui transforment une intelligence individuelle en résultats répétables. Les pipelines font de l'expérimentation IA de l'ingénierie, et non de l'improvisation.

En sécurité offensive, cette discipline est essentielle. Un agent de reconnaissance peut identifier 100 cibles potentielles, mais un pipeline garantit que ces résultats traversent des étapes de validation avant le début des tests. Chaque étape — admission, raisonnement, action, évaluation et reporting — est journalisée, mesurée et revue. Quand quelque chose se passe mal, vous pouvez le tracer ; quand quelque chose fonctionne, vous pouvez le reproduire.

Avec les pipelines, chaque expérience devient un récit contrôlé : une simulation d'attaque que l'on peut auditer, ajuster et dont on peut tirer des enseignements. C'est ainsi que nous transformons l'exploration créative en recherche de sécurité responsable et fondée sur les données.

Composants clés d'un pipeline de sécurité par IA

Tout pipeline de sécurité par IA suit un principe simple : la structure prime sur la spontanéité. Tandis que les agents assurent le raisonnement et la décision, le pipeline définit comment ce raisonnement circule dans un système contrôlé. Voyez-le comme une carte de votre workflow piloté par IA — depuis l'admission des données brutes jusqu'au renseignement actionnable.

Un pipeline bien conçu accomplit les tâches suivantes de façon fiable :

1. Il collecte des entrées provenant de sources de confiance (outils, journaux, API).
2. Il interprète le contexte à l'aide d'un LLM ou d'un agent.
3. Il agit en exécutant un outil ou un script contrôlé.
4. Il évalue les résultats au regard de règles définies ou de contrôles de sécurité.
5. Il restitue les résultats dans un format structuré et partageable.

Chaque étape alimente la suivante, formant une boucle que vous pouvez surveiller, mettre en pause ou rejouer. Entre les étapes se trouvent des portes de décision — les contrôles humains ou programmatiques qui déterminent si l'étape suivante doit se poursuivre. Une porte peut par exemple exiger une approbation humaine avant de lancer un scan réseau. Ces portes sont essentielles en sécurité offensive, car elles maintiennent l'automatisation éthique et contenue. Garder un humain dans la boucle est une porte vitale pour éviter que les systèmes d'IA ne s'emballent avec des décisions potentiellement dommageables, et cela garantit que les humains restent actifs dans le jugement, l'éthique et la responsabilité de leur architecture logicielle.

1.4.2 De l'autonomie à l'architecture

Un agent isolé peut accomplir des prouesses impressionnantes : analyser des résultats, lancer des outils, affiner des recherches. Mais sans structure, son autonomie peut devenir imprévisible. Les pipelines apportent cette structure. Ils définissent comment les agents se connectent, quelles données ils se transmettent, et comment chaque décision est journalisée et revue. En sécurité offensive, cette organisation est critique : elle maintient l'expérimentation reproductible, mesurable et éthique. Un pipeline bien conçu garantit que chaque agent agit dans le périmètre approuvé, respecte les portes de sécurité définies et produit des artefacts auditables a posteriori.

1.4.3 Pourquoi les pipelines comptent

En définissant les pipelines comme des systèmes de routage de l'information, nous obtenons trois résultats :

• Clarté — les outils exécutent, les pipelines acheminent, les agents interprètent.
• Scalabilité — les décisions n'exigent plus une attention humaine continue.
• Responsabilité — chaque décision de routage est traçable jusqu'à un artefact.

Plus important encore, ce modèle préserve le rôle du praticien. Les humains définissent les objectifs et approuvent les escalades. Les pipelines garantissent que l'information avance délibérément. Les agents assistent le raisonnement — ils ne détiennent pas l'autorité. Il ne s'agit pas d'une automatisation qui remplace l'expertise. Il s'agit de l'expertise exprimée sous forme de structure.

1.5 Les artefacts permettent une décision précise en sécurité offensive

On décrit souvent la sécurité offensive en termes d'outils, mais les outils seuls ne contiennent pas l'information qui est transmise pour prendre les décisions importantes. Toute mission efficace produit des artefacts : ports ouverts, sous-domaines résolus, en-têtes de réponse, défis d'authentification, messages d'erreur et différences comportementales. Ces artefacts ne sont pas le produit du test. Ils sont les entrées de ce qui vient ensuite.

1.5.1 L'artefact comme unité de circulation

L'objet central qui circule dans un pipeline est l'artefact. Un artefact est l'enregistrement durable de ce qu'un outil a observé : ports ouverts, sous-domaines résolus, métadonnées de réponse HTTP, points de terminaison découverts, comportements d'authentification. Les artefacts ne sont pas des interprétations. Ce sont des preuves.

Dans les workflows traditionnels, les artefacts sont informels. Ils vivent dans la sortie du terminal, des captures d'écran, des notes ou la mémoire. Le praticien les interprète mentalement et décide de la suite.

Les pipelines rendent ce processus explicite. Les artefacts sont structurés, enregistrés et transmis intentionnellement. Ils deviennent les entrées de l'étape de test suivante — que cette étape soit un autre outil, un agent IA ou un point de décision humain. En traitant les artefacts comme des objets de première classe, les pipelines séparent la circulation de l'information de la prise de décision.

1.5.2 Où l'intelligence entre dans le système

Les outils produisent des artefacts. Les pipelines déplacent les artefacts. L'intelligence entre en jeu lorsque des décisions sont prises quant aux artefacts qui comptent.

Un agent consomme deux entrées :

• L'intention humaine (ce que l'opérateur cherche à accomplir)
• Les artefacts produits par les outils

Sur cette base, l'agent propose des décisions : quels artefacts doivent avancer, lesquels doivent être dépriorisés, et lesquels justifient une escalade. Le pipeline applique ensuite ces décisions en n'acheminant vers l'avant que les artefacts sélectionnés.

1.6 En quoi cela vous concerne

Tout ce que nous avons abordé — LLM, agents et pipelines — n'a rien de théorique. Cela remodèle déjà la façon de travailler des professionnels de la cybersécurité. Que vous soyez chasseur de bugs indépendant, membre d'une red team ou d'une purple team, ou RSSI supervisant la défense d'une entreprise, les pipelines d'agents IA changent l'efficacité, la précision et la répétabilité de ce que vous faites.

1.6.1 Chasseurs de bugs indépendants et freelances

Pour les chercheurs solitaires, le temps est la ressource la plus limitée. Les pipelines agissent comme un multiplicateur de force personnel — automatisant le triage des données, la reconnaissance de motifs et la rédaction de rapports pour que vous puissiez vous concentrer sur la créativité et l'analyse. Un testeur seul peut désormais traiter des milliers de résultats de scan, les regrouper par exploitabilité et générer des comptes rendus de qualité professionnelle en quelques minutes. Le bénéfice est simple : plus de soumissions validées et des résultats de meilleure qualité, sans s'épuiser sur du tri manuel.

1.6.2 Testeurs d'intrusion et red teams

Chaque mission génère des montagnes de sorties — journaux de scan, charges utiles, captures d'écran et notes — qui souvent disparaissent après le test. Les pipelines capturent ce travail sous forme de playbooks réutilisables. Le testeur suivant peut rejouer ou étendre le workflow au lieu de repartir de zéro. Avec le temps, ces pipelines cumulés forment une bibliothèque évolutive de tactiques qui met à l'échelle la connaissance de l'équipe et améliore la cohérence entre missions.

1.6.3 Purple teams et ingénieurs de détection

Les données offensives sont de l'or pour les défenseurs, et les pipelines les rendent exploitables. Lorsqu'un pipeline de red team découvre un point de terminaison exposé ou une mauvaise configuration, ses journaux font aussi office de télémétrie pour le réglage défensif. Les blue teams peuvent injecter ces traces dans des SIEM, entraîner des détecteurs d'anomalies ou valider une logique de détection contre un comportement d'attaque réel. En bref, les pipelines referment la boucle de rétroaction : l'offense apprend de la défense, et la défense se durcit grâce à l'offense.

1.6.4 Blue teams et analystes SOC

Nul besoin d'exécuter des exploits en direct pour bénéficier des pipelines IA. En rejouant des exécutions enregistrées dans un bac à sable, les analystes peuvent observer sans risque le comportement de l'attaquant, valider la couverture des alertes et répéter les procédures de réponse à incident. Les pipelines transforment des résultats ponctuels de red team en exercices d'entraînement continus, renforçant détection et réponse à chaque cycle.

1.6.5 RSSI et responsables sécurité

Du point de vue de la direction, les pipelines apportent visibilité et responsabilité. Au lieu de vous appuyer sur des rapports anecdotiques, vous obtenez des données mesurables et répétables sur la façon dont votre organisation teste, se défend et s'améliore dans le temps. Chaque exécution de pipeline produit une preuve documentée du périmètre, des contrôles et des résultats — quelque chose que des auditeurs, des dirigeants et des conseils d'administration peuvent comprendre. Les pipelines IA transforment l'expérimentation créative en une pratique de sécurité auditable.

1.7 Résumé

Chapitre 2Construire votre premier agent IA

Au chapitre 1, nous avons présenté les agents IA et les pipelines qui apportent raisonnement, contrôle et responsabilité aux workflows de sécurité offensive. Nous avons montré pourquoi de simples scripts et des appels ponctuels à un LLM se brisent dans des environnements dynamiques, et pourquoi la structure devient cruciale dès lors que l'automatisation se met à prendre des décisions. Ce chapitre passe de la théorie à la construction, en bâtissant un véritable agent IA depuis zéro.

L'objectif n'est pas de construire une démo astucieuse ni un système de production : nous illustrons comment le fait d'envelopper un grand modèle de langage dans un petit ensemble de composants explicites (messages, outils et artefacts) transforme une génération de texte réactive en une boucle de décision contrôlée que l'on peut inspecter, rejouer et défendre.

Nous commencerons par établir un modèle mental clair du fonctionnement des agents et par tracer des frontières nettes entre agents, scripts et outils. Nous montrerons comment construire un agent en Python sans framework d'IA. Une fois cette fondation posée, nous appliquerons des frameworks tels que LangChain et AutoGen. Le chapitre se conclut par les schémas de gouvernance qui garantissent que le comportement de l'agent reste sûr et défendable lors de missions réelles.

2.1 Les limites de l'automatisation par scripts

Les professionnels de la sécurité automatisent des tâches depuis des décennies à l'aide de scripts, de tâches cron et d'outils ponctuels, qui ont rendu le travail plus rapide et plus répétable. Mais ces outils partagent une limite fondamentale : ils exigent que les humains soient les principaux décideurs.

Un script permet à un programmeur d'écrire un ensemble prédéfini d'instructions que l'ordinateur peut suivre pour exécuter une tâche donnée. Les scripts s'appuient couramment sur un état de fichiers fixe, écrit par le programmeur, pour accéder aux données et autres artefacts. Lorsque l'environnement change (le système de fichiers, par exemple), les scripts peuvent échouer purement et simplement ou produire des sorties incorrectes. À terme, ces bugs dans vos scripts élargissent la surface d'attaque exploitable, devenant un passif pour votre système et pour votre organisation.

Les grands modèles de langage (LLM) possèdent les capacités de raisonnement nécessaires pour résoudre ces problèmes dynamiques. Un LLM peut résumer la sortie d'un scan, signaler des anomalies ou suggérer les étapes suivantes. Cependant, un LLM seul ne suffit pas : les modèles de type chatbot sont entraînés uniquement à répondre à des prompts. À eux seuls, les chatbots ne peuvent pas faire persister leur état ni leur mémoire entre différentes actions, ne peuvent pas réagir aux changements de leur environnement, et ne peuvent pas expliquer ni justifier pourquoi une décision particulière a été prise. Dans des contextes de sécurité, où les enjeux sont considérables, ce type de raisonnement non structuré est un passif.

2.2 Qu'est-ce qu'un agent ?

Un agent est un système capable de prendre des décisions contrôlées sans intervention humaine. Le modèle d'agent reçoit une entrée, décide de la suite, invoque une action, observe le résultat et consigne ce qui s'est passé. Les agents renforcent les professionnels de la sécurité. Ils permettent l'exécution autonome de tâches, savent réagir dans des environnements dynamiques et peuvent fonctionner 24 h/24, 7 j/7. Ensemble, les agents sont essentiels à la protection des systèmes logiciels modernes, exposés aux attaques malveillantes. La figure 2.1 illustre les différences entre scripts et agents IA.

La distinction entre script et agent IA compte parce que les workflows de sécurité offensive ne sont pas linéaires. Pour la tâche de reconnaissance que nous implémentons, la reconnaissance alimente le triage et le triage alimente la priorisation. Les échecs imposent une réévaluation. L'automatisation sans raisonnement devient fragile. Un moteur de raisonnement dépourvu de portes de contrôle, où les humains peuvent intervenir quand les choses tournent mal, est dangereux.

Pour les testeurs d'intrusion, les chasseurs de bugs et les opérateurs de red team, le facteur limitant est rarement un outil logiciel de plus. C'est le volume : une seule mission peut générer des centaines ou des milliers de points de terminaison, de paramètres, d'en-têtes et de réponses. Les scripts peuvent collecter toutes ces données, mais ils ne peuvent pas vous dire où concentrer vos efforts.

Un agent ne remplace pas l'intuition et le jugement humains : il les augmente. Un agent transforme un travail exploratoire en un workflow que l'on peut revoir, rejouer et défendre, en enregistrant les actions de l'agent — les étapes entreprises, les outils utilisés et les réponses observées.

Maintenant que nous avons distingué un script d'un agent IA, plongeons dans le fonctionnement d'un agent. La section suivante décompose l'agent en cinq composants essentiels : les messages, les outils, la mémoire, le contrôleur et les artefacts qui constituent la boucle agentique.

2.3 Anatomie d'un agent

Un agent est une boucle structurée qui relie cinq composants centraux, permettant aux agents d'accomplir des tâches complexes incluant raisonnement, action, observation, réflexion et enregistrement. La figure 2.1 présente une représentation schématique d'une boucle agentique unique. En itérant sur ces composants, les agents peuvent accomplir des tâches jusqu'ici réservées aux humains.

2.3.1 Les composants fondamentaux

Les agents IA se composent de cinq éléments clés résumés dans le tableau 2.1 : messages, outils, mémoire, contrôleurs d'agent et artefacts. Nous les décrivons plus en détail ci-dessous.

Les messages sont une unité structurée de communication au sein d'une conversation entre l'utilisateur et le LLM. Ce sont les briques qui forment un prompt, c'est-à-dire l'entrée que vous envoyez à un modèle d'IA pour obtenir une réponse. Il s'agit généralement d'une question ou d'une commande, du type « Liste 5 poèmes écrits par Emily Dickinson ». Dans les interactions tour par tour (les chatbots, par exemple), le prompt est habituellement un message unique. Les agents, eux, construisent typiquement un prompt à partir de plusieurs messages qui fonctionnent ensemble.

Nous avons évoqué les différences entre LLM et agents : les LLM ne peuvent que répondre à de simples messages, alors que les agents peuvent interagir avec le monde extérieur. Les outils permettent aux LLM non seulement de converser, mais aussi d'interagir avec le monde extérieur. Ils consistent en fonctions personnalisées, appels d'API ou requêtes de base de données que l'agent doit exécuter pour accomplir une tâche donnée. C'est important pour plusieurs raisons : par exemple, pour récupérer une information en temps réel, un agent a besoin d'un accès à Internet, puisque les LLM sont limités aux connaissances acquises pendant l'entraînement. Ou encore, si vous voulez qu'un LLM réalise une opération mathématique, les outils sont précieux car les LLM sont connus pour halluciner, en particulier sur des questions de raisonnement mathématique. Les outils sont des instruments spécialisés que l'agent peut saisir et utiliser au besoin, lorsqu'il ne peut pas résoudre la tâche par le seul raisonnement.

Comme décrit dans la section précédente, un agent est un pipeline qui reçoit des messages, détermine quand utiliser des outils, accède à la mémoire et produit des réponses. Il suit une boucle de raisonnement : comprendre la demande, déterminer quelles informations ou actions sont nécessaires, appeler les outils appropriés, synthétiser les résultats et répondre de façon adéquate à la demande de l'utilisateur. C'est un décideur qui orchestre et coordonne tous les composants pour accomplir efficacement les tâches.

Les agents sont puissants parce qu'ils tiennent aussi compte des interactions passées. La mémoire est la façon dont ils retiennent l'information d'une interaction à l'autre. Sans composant de mémoire, chaque conversation repartirait de zéro, sans contexte. Imaginez devoir copier-coller une conversation précédente pour obtenir une réponse pertinente — c'est une expérience utilisateur épouvantable ! La mémoire peut être à court terme (les N derniers messages de la conversation, par exemple) ou à long terme : des faits issus de sessions passées, stockés dans un conteneur particulier appelé base de données vectorielle. La mémoire est essentielle car elle fait qu'un agent ressemble à un assistant personnalisé à mesure que vous l'utilisez.

Enfin, les agents peuvent créer des artefacts, les sorties tangibles du modèle. Cela inclut documents, fichiers de code, rapports et graphiques. Les artefacts sont typiquement formatés, enregistrés, et peuvent être téléchargés ou retravaillés par un humain (ou un autre LLM). Ensemble, ces composants forment la base d'un workflow d'agent IA moderne.

2.3.2 La boucle d'agent ReAct

La figure 2.3 montre comment ces composants agentiques fondamentaux se combinent pour résoudre la requête de l'utilisateur selon le framework agentique ReAct (Reasoning and Action). ReAct comporte trois étapes principales, exécutées en boucle jusqu'à ce que le problème de l'utilisateur soit résolu.

• Raisonnement (Reasoning) : le LLM engage un processus de pensée qui comprend planification, prise de décision et réflexion stratégique avant d'agir.
• Action : le modèle interagit avec le monde extérieur, en utilisant aussi bien des fonctions personnalisées que des appels d'API ou des accès à des bases de données ; et
• Observation : le modèle perçoit et interprète les résultats ou retours de ses actions.

L'implémentation ReAct originale n'utilisait que la boucle Raisonnement, Action et Observation, ce qui limitait ses performances dans les applications réelles. Depuis, des processus supplémentaires ont été introduits et intégrés au workflow pour améliorer significativement les performances générales d'un agent, notamment :

• Réflexion : le modèle réalise une évaluation métacognitive de sa propre performance, ce qui peut orienter ses étapes suivantes.
• Enregistrement : les informations, le contexte, les enseignements, les journaux et les sorties du modèle produits pendant la session sont stockés pour référence et décision ultérieures.

Bien qu'elle paraisse simple, ReAct est puissante parce qu'elle permet aux LLM d'agir comme des agents autonomes. La composante de raisonnement ancre les actions dans la réalité et aide à prévenir les hallucinations. De plus, la boucle est souple : elle permet à l'agent IA d'ajuster son plan en fonction de ce qu'il découvre. Surtout, le processus de décision agentique est transparent, ce qui permet à l'utilisateur de comprendre comment le modèle est parvenu à ses conclusions.

2.3.3 Le périmètre et la responsabilité d'un agent

Une question clé se pose : pourquoi tout cela est-il important ? Pourquoi compliquer un simple appel d'API à un LLM avec tous ces composants supplémentaires ? Des systèmes d'automatisation simples comme les LLM savent répondre à des prompts (par exemple « Dis-moi quelle est la capitale du Kansas »), mais un LLM seul ne peut pas raisonner sur des requêtes utilisateur complexes, comme des problèmes de raisonnement mathématique. Dans des applications critiques comme la cybersécurité, à forts enjeux et avec des conséquences juridiques et opérationnelles, nous devons pouvoir avoir confiance dans la façon dont les modèles parviennent à leurs décisions.

En reliant un LLM à des éléments supplémentaires comme les messages, les outils, la mémoire et les artefacts, vous rendez le comportement d'un agent IA observable. Nous pouvons stocker le raisonnement du LLM sous forme d'artefact et visualiser les étapes qu'il a suivies pour parvenir à sa conclusion. Cette visibilité sur le processus de raisonnement nous permet de l'affiner et d'y installer des mécanismes de contrôle avec intervention humaine.

La transparence du processus de raisonnement permet aux testeurs de sécurité d'utiliser l'IA en toute sécurité : chaque décision, chaque action, chaque résultat est journalisé comme artefact via des outils de télémétrie, qui collectent, transmettent et analysent automatiquement les données. Par exemple, les équipes peuvent utiliser un outil comme LangSmith pour gérer journaux, métriques et traces de LLM, et suivre les événements afin d'améliorer le débogage et l'audit.

Les agents individuels conviennent bien à des tâches de sécurité délimitées telles que la reconnaissance, le triage ou l'analyse. À mesure que les systèmes se complexifient, les artefacts gagnent en importance. Lorsque plusieurs agents sont chaînés, les artefacts servent d'interface entre les étapes — un schéma exploré plus avant au chapitre 3.

Tout aussi important, un agent se définit par ce qu'il n'est pas. Les agents ne sont pas des systèmes autonomes livrés à eux-mêmes, et ils ne remplacent pas les outils ni les scripts. Ils ne créent pas de nouvelles capacités. Ils coordonnent des capacités existantes par un raisonnement contrôlé, des actions explicites et des résultats enregistrés.

2.4 La spécification d'agent minimale

Cette section traduit en code les concepts d'agent présentés plus haut. Nous définissons une spécification d'agent minimale : le plus petit ensemble d'interfaces et de structures de données qu'un agent doit prendre en charge pour être portable, testable et sûr.

Voyez cette spécification comme un contrat d'API. Tous les agents de ce livre, quel que soit le framework, s'y conforment. En définissant les agents en termes de messages explicites, d'invocations d'outils, d'observations et d'artefacts enregistrés, le comportement de l'agent reste cohérent, auditable et défendable.

La spécification est délibérément agnostique du framework. Vous pouvez remplacer n'importe quelle bibliothèque d'IA, les workflows environnants tiennent toujours. Le contrat définit ce qu'un agent doit faire et enregistrer, pas la manière dont un framework implémente ces comportements.

À ce stade, vous disposez déjà de tout ce qu'il faut pour construire un agent fonctionnel. Dans la section suivante, nous assemblons la plus petite implémentation possible satisfaisant cette spécification. Elle utilise exactement deux outils, fait passer un unique artefact de l'un à l'autre, puis s'arrête. Pas de mémoire, pas d'optimisation, pas d'abstraction propre à un framework. L'objectif n'est pas l'intelligence — c'est la clarté.

2.5 Construire l'agent minimal

Jusqu'ici, nous avons décrit les agents de façon conceptuelle : en quoi ils diffèrent des scripts et comment leurs composants s'articulent. Cette section montre la plus petite implémentation possible qui satisfasse le modèle d'agent défini plus haut.

Dans la lecture de code ci-dessous, nous implémentons un agent très simple, sans mémoire, sans optimisation et sans accès réseau. L'objectif est de rendre explicites les mécanismes de l'agentivité.

Cet agent fait exactement cinq choses :

1. Décider quel outil exécuter
2. Exécuter le premier outil
3. Enregistrer le résultat comme artefact
4. Passer cet artefact à un second outil
5. S'arrêter

2.5.1 Ce que fait cet agent

L'agent traite un petit fragment de texte en entrée et produit un court artefact de synthèse :

• L'outil A extrait les URL du texte d'entrée
• L'outil B résume les URL extraites
• L'agent contrôle l'ordre d'exécution et enregistre chaque étape

Toutes les entrées sont locales et déterministes. Aucun appel réseau en direct n'est effectué.

2.5.2 Messages et observations

Un composant central d'un agent est le message, le moyen par lequel l'utilisateur et le LLM communiquent. Le rôle d'un message définit qui parle dans la conversation. Il existe quatre rôles standard dans la plupart des frameworks d'IA :

• System : un message système contient les instructions et le contexte de l'agent, y compris les connaissances de fond, la définition des contraintes et le paramétrage du comportement de l'agent.
• User : l'entrée fournie par l'humain, contenant couramment questions, commandes et demandes.
• Agent : les réponses générées par l'IA, incluant ses pensées, raisonnements et actions. Elles peuvent aussi contenir d'autres métadonnées, comme des appels d'outils, des analyses ou des réponses finales.
• Tool : les résultats de l'exécution d'outils. Ils peuvent inclure les sorties de systèmes externes (API, bases de données, outils personnalisés) et les observations que l'agent utilise pour raisonner.

Nous définissons les classes Message et Observation dans le listing 2.1. La classe Message stocke l'information qui transite dans l'agent : le rôle, le contenu, l'horodatage du message généré et des métadonnées additionnelles. La classe Observation capture ce qui s'est produit après une action et inclut des informations telles que le nom de l'outil, les entrées/sorties du modèle, les codes d'erreur le cas échéant, et d'autres informations clés pour la supervision du modèle et le traçage d'erreurs.

from pydantic import BaseModel, Field
from datetime import datetime
from typing import Optional, Dict, Any

class Message(BaseModel):
    role: str                # "system", "user", "agent", "tool"
    content: str             # texte en langage naturel
    timestamp: datetime = Field(default_factory=datetime.utcnow)
    meta: Optional[Dict[str, Any]] = None

class Observation(BaseModel):
    tool_name: str
    input: Dict[str, Any]
    output: Dict[str, Any]
    success: bool
    error: Optional[str] = None
    timestamp: datetime = Field(default_factory=datetime.utcnow)

2.5.3 Les outils

Les outils sont la manière dont un agent interagit avec le monde ; ils vont d'une fonction personnalisée que vous avez écrite (un analyseur d'expressions régulières, par exemple) à un appel d'API vers un service externe (un scanner de vulnérabilités, par exemple).

Dans le listing 2.2, nous définissons un schéma pour la classe de base Tool, qui inclut des métadonnées comme le nom et la description de l'outil, ainsi qu'une méthode .invoke() utilisable pour exécuter n'importe quelle fonction, invoquer une API ou accomplir toute autre tâche.

class Tool:
    name: str
    description: str

    def invoke(self, input: Dict[str, Any]) -> Dict[str, Any]:
        """Run the tool and return structured output."""
        raise NotImplementedError

2.5.4 Outil A : extraire les URL

Dans le listing 2.3, nous définissons un outil qui parcourt le texte d'entrée et en extrait tout ce qui ressemble à une URL. L'outil héritera de la méthode d'invocation définie dans la classe de base Tool.

import re

class ExtractUrlsTool(Tool):
    name = "extract_urls"

    def invoke(self, input: dict) -> dict:
        urls = re.findall(r"https?://[^\s]+", input["text"])
        return {"urls": urls}

Cet outil accomplit une tâche unique et n'a aucune conscience du contexte d'exécution. Il ne décide ni quand il s'exécute, ni comment sa sortie sera utilisée.

2.5.5 Outil B : résumer les URL

Dans le listing 2.4, le second outil consomme l'artefact produit par le premier et génère un court résumé.

class SummarizeUrlsTool(Tool):
    name = "summarize_urls"

    def invoke(self, input: dict) -> dict:
        return {
            "count": len(input["urls"]),
            "summary": f"Found {len(input['urls'])} URLs."
        }

Comme le premier outil, il consomme une entrée structurée et produit une sortie structurée sans rien savoir du comportement en amont ou en aval.

2.5.6 Artefacts et journalisation

Chaque exécution d'agent produit des données, des plans, des actions, des résultats et des réflexions. Nous traitons ces sorties comme des artefacts, et nous les enregistrerons au format JSONL (un objet JSON par ligne). Dans le listing 2.5, nous définissons la classe de journalisation d'artefacts qui enregistre toutes les sorties du modèle dans le journal JSONL. Le fichier de journal sera stocké dans le répertoire run_dir. Les nouvelles traces y seront ajoutées comme nouvelles lignes. La journalisation des artefacts est importante parce qu'elle fournit une piste d'audit pour votre agent et vous permet de prouver exactement ce que votre agent a fait au cours d'une tâche de sécurité donnée (un test d'intrusion, par exemple). Les journaux sont indispensables aux évaluations comme au débogage. De plus, du point de vue de la conformité et de la protection juridique, les journaux démontrent que votre agent est resté dans le périmètre du projet de test de sécurité.

import json, uuid, os

class ArtifactLogger:
    def __init__(self, run_dir="runs"):
        os.makedirs(run_dir, exist_ok=True)
        self.file = open(f"{run_dir}/{uuid.uuid4()}.jsonl", "w", encoding="utf8")

    def write(self, record: dict):
        json.dump(record, self.file)
        self.file.write("\n")
        self.file.flush()

Nous pouvons maintenant voir comment réunir ces composants en une spécification fonctionnelle qui unifie messages, outils et artefacts en une seule boucle répétable.

2.5.7 La boucle d'agent minimale

Un agent est responsable de décider l'ordre d'exécution et d'enregistrer les résultats. Le listing 2.6 définit une classe d'agent minimale qui utilise les deux outils que nous avons écrits pour extraire et résumer des URL.

class MinimalAgent:
    def __init__(self, tools, logger):
        self.tools = {tool.name: tool for tool in tools}
        self.logger = logger

    def run(self, text: str):
        plan = "extract_urls"
        observation_1 = self.tools[plan].invoke({"text": text})
        self.logger.write({
            "tool": plan,
            "input": {"text": text},
            "output": observation_1
        })

        plan = "summarize_urls"
        observation_2 = self.tools[plan].invoke(observation_1)
        self.logger.write({
            "tool": plan,
            "input": observation_1,
            "output": observation_2
        })

        return observation_2

Voilà toute la boucle. Pas de rappels, pas d'état implicite, pas de comportement géré par un framework. Uniquement des décisions explicites, des actions, des observations et des résultats enregistrés.

2.5.8 Tout assembler

À ce stade, nous pouvons exécuter l'agent, comme le montre le listing 2.7. Nous utiliserons la classe ArtifactLogger pour capturer les artefacts produits par le modèle. Nous instancierons également un agent minimal qui exécutera nos deux outils.

logger = ArtifactLogger()
agent = MinimalAgent(
    tools=[ExtractUrlsTool(), SummarizeUrlsTool()],
    logger=logger
)

result = agent.run(
    "Check https://example.com and https://admin.example.com/login"
)

print(result)

Ce petit ensemble de règles est tout ce dont vous avez besoin pour construire des agents interopérables. Tout le reste — abstractions de frameworks, orchestration sophistiquée, magasins de mémoire — vient se poser au-dessus de cette couche.

Dans la section suivante, nous appliquerons des dispositifs de sécurité et de gouvernance à notre agent pour nous assurer de ne rien casser.

2.6 Sécurité et gouvernance

À ce stade, votre agent sait raisonner, agir et réfléchir sans supervision humaine constante. Cette autonomie est précisément ce qui le rend utile — et ce qui le rend dangereux s'il n'est pas encadré. En sécurité offensive, l'automatisation doit toujours opérer à l'intérieur de limites clairement définies. Un agent bien conçu ne se contente pas de fonctionner : il sait où il n'a pas le droit de fonctionner.

Cette section transforme les idées éthiques du chapitre 1 en contrôles techniques : portes de sécurité, bacs à sable, journalisation et auditabilité. Ces concepts ne visent pas à ajouter de la lourdeur bureaucratique ; ce sont des principes d'ingénierie éprouvés qui transforment des scripts astucieux en systèmes dignes de confiance.

2.6.1 Pourquoi la sécurité importe

Les outils et techniques de sécurité offensive sont à double usage : les mêmes compétences qui servent à identifier des vulnérabilités peuvent être instrumentalisées à des fins malveillantes. La seule chose qui sépare un testeur d'intrusion d'un cybercriminel, c'est l'autorisation et l'intention. Une gouvernance stricte est indispensable pour éviter de franchir les frontières éthiques et légales.

Ces compétences et ces dangers sont amplifiés par l'automatisation. La même capacité de raisonnement qui aide un agent peut le conduire à tester hors de son périmètre autorisé, à mal interpréter des frontières réseau ou à exécuter des commandes destructrices sur la base de malentendus. Cela crée des risques opérationnels pouvant entraîner des dommages non intentionnels sur des systèmes de production, y compris l'exécution accidentelle d'une action destructrice et des interruptions de service affectant des infrastructures critiques. Il existe aussi des risques éthiques et juridiques : sans autorisation adéquate ou en traitant des données sensibles de façon non sécurisée, les activités de sécurité offensive constituent une infraction informatique au regard du Computer Fraud and Abuse Act (CFAA) américain.

Sans garde-fous, un agent IA pourrait :

• Déclencher des scans agressifs sur des hôtes de production en pleine journée ouvrée (ajoutant une latence inutile et dégradant l'expérience utilisateur),
• Exfiltrer des données confidentielles ne faisant pas partie du périmètre de la mission,
• Générer des charges utiles qui violent votre accord de test ou des conditions d'utilisation,
• Pivoter vers des réseaux explicitement marqués comme hors périmètre.

Les mécanismes de gouvernance agissent comme des disjoncteurs entre la créativité et ses conséquences. Ils servent à limiter ce qu'un agent peut exécuter sans vérification. Les sections suivantes exposent des approches concrètes pour garantir que les agents IA opèrent en toute sécurité dans nos systèmes.

2.6.2 Construire des portes de sécurité

Comme nous l'avons brièvement évoqué au chapitre 1, une porte (gate) est tout point de contrôle qui impose une revue ou des conditions avant qu'une étape ne se poursuive. Les portes peuvent être manuelles (nécessitant une intervention humaine) ou automatisées (règles bloquant les opérations dangereuses, ou autres LLM jugeant si une opération est dangereuse).

Dans le listing 2.8, nous implémentons une porte de sécurité simple qui fait deux choses : 1) elle empêche automatiquement l'agent de toucher à une infrastructure critique si la cible contient l'une des chaînes suivantes : « prod », « payment » ou « core-db » ; 2) pour toutes les autres cibles, elle met l'exécution en pause et demande à l'opérateur une approbation explicite avant de continuer.

def safety_gate(action: str, context: dict) -> bool:
    """Return True if action is approved to proceed."""
    prohibited_hosts = ["prod", "payment", "core-db"]
    if any(p in context.get("target", "") for p in prohibited_hosts):
        print(f"[Gate] Blocked unsafe target: {context['target']}")
        return False
    confirm = input(f"[Gate] Approve '{action}' on {context['target']}? (y/n): ")
    return confirm.lower().startswith("y")

Nous vous recommandons d'intégrer cette vérification dans votre méthode act() ou dans votre boucle de pipeline, afin que toute commande à haut risque passe par une revue humaine.

2.6.3 Bac à sable et isolation

Même les actions approuvées doivent s'exécuter dans un environnement contrôlé. Le bac à sable (sandboxing) consiste à exécuter du code dans un environnement isolé qui restreint l'accès au reste du système. C'est un lieu où mener des expériences tout en limitant l'accès au système global.

Les agents IA génèrent et exécutent automatiquement du code que vous n'avez pas personnellement relu, ce qui peut provoquer plusieurs effets de bord non désirés et dangereux. Le bac à sable garantit que ces erreurs se produisent dans un environnement confiné. C'est l'ultime ligne de défense quand les portes de sécurité et l'approbation humaine ne suffisent pas. La figure 2.4 illustre visuellement comment le bac à sable constitue un conteneur distinct du reste du système.

Les stratégies courantes d'isolation incluent :

• Conteneurisation : l'agent doit disposer d'un environnement isolé dans Docker ou Podman, avec des limites réseau, des quotas de ressources et des restrictions de système de fichiers. Il peut y installer des outils, exécuter des exploits et générer des charges utiles sans accéder ni affecter le vrai système de fichiers ou le vrai réseau.
• Isolation de processus : un agent ne doit pas avoir un accès total à tout — nous devons abandonner les privilèges et faire en sorte que l'agent utilise des comptes utilisateur restreints aux permissions limitées.
• Simulation hors ligne : nous devons pouvoir rejouer la logique d'attaque sur des données synthétiques ou enregistrées avant de l'exécuter contre des cibles réelles. Cela permet de vérifier la chaîne de raisonnement de l'agent.

2.6.4 Une journalisation complète

Les agents IA raisonnent sur ce qu'ils font, choisissent des outils et exécutent des commandes automatiquement. Si quelque chose tourne mal (ou même si tout se passe bien), vous devez savoir ce que l'agent a décidé de faire, pourquoi il a fait ce choix, quand cela s'est produit, et si cela a réussi ou échoué. Cela nous aide à prouver que nous sommes restés dans les limites autorisées.

Comme défini à la section 2.2.5, votre schéma ArtifactLogger précise les arguments d'entrée et de sortie capturés. Nous pouvons l'étendre pour capturer des métadonnées qui facilitent le rejeu et la reddition de comptes, comme le montre le listing 2.9.

record = {
    "run_id": run_id,
    "agent": "triage",
    "stage": "recon",
    "timestamp": timestamp,
    "input": input_data,
    "output": output_data,
    "approved_by": user_email,
    "status": "success"
}
logger.write(record)

Des journaux de ce type transforment des expériences en preuves. Si quelque chose tourne mal, vous pouvez reconstituer exactement ce qui a été décidé, par qui, et pourquoi.

De bonnes données offensives font de bonnes données défensives. Des journaux complets rendent toute l'organisation plus sûre.

2.6.5 Politiques opérationnelles

Avant toute mission, formalisez ces règles :

• Périmètre autorisé uniquement — définissez par écrit les cibles, les fenêtres temporelles et les actions interdites.
• Revue humaine obligatoire. Chaque exécution d'agent doit comporter au moins une porte d'approbation.
• Minimisation des données — les agents ne doivent jamais collecter ni stocker de données personnelles inutiles.
• Suppression à la clôture — purgez les artefacts après la mission, sauf si l'audit l'exige.
• Divulgation responsable — signalez les vulnérabilités en privé et dans les délais convenus.

Ces politiques rendent possible une innovation responsable.

2.6.6 Mettre en place des coupe-circuits

Parfois, la réponse la plus sûre consiste à arrêter l'action immédiatement. Nous devons intégrer des coupe-circuits (kill switches) qui empêchent nos agents de causer davantage de dommages. Le listing 2.10 implémente un coupe-circuit global qui s'exécute en arrière-plan et surveille en continu une commande d'abandon manuel, vous permettant d'interrompre immédiatement toutes les opérations des agents en cas de problème.

import threading, time

class KillSwitch:
    def __init__(self):
        self.active = False
    def monitor(self):
        while True:
            cmd = input("[KillSwitch] Type 'STOP' to abort: ")
            if cmd.strip().upper() == "STOP":
                self.active = True
                print("[KillSwitch] Aborting all agents.")
                break

Remarques :

• Le drapeau active est un signal partagé que tous les agents peuvent vérifier. Passer active=True déclenche un arrêt d'urgence.
• La méthode monitor attend en continu une saisie clavier. Lorsque vous tapez « STOP », elle passe active à True et arrête l'agent.
• Nous utilisons la bibliothèque threading pour exécuter le processus en arrière-plan, ce qui permet à l'agent de travailler normalement pendant que le coupe-circuit écoute silencieusement la commande d'abandon.

2.6.7 Sécurité et gouvernance : synthèse

• Les portes de sécurité imposent une revue et empêchent les actions non autorisées.
• Le bac à sable isole les outils et limite les dommages.
• Des journaux complets assurent la traçabilité et alimentent l'analyse défensive.
• Les politiques opérationnelles formalisent les limites éthiques.
• Les coupe-circuits garantissent le contrôle humain, même dans des systèmes automatisés.

Vous avez construit un agent responsable qui réfléchit avant d'agir. Voyons-le maintenant fonctionner de bout en bout en construisant un agent de triage dans la section suivante.

2.7 L'agent de triage

Vous avez construit toutes les pièces : messages, outils, mémoire, adaptateurs et portes de sécurité. Il est temps de les relier en un agent de triage capable de lire des données de reconnaissance, de raisonner sur ce qui compte et de produire un résumé hiérarchisé tout en restant dans les limites éthiques. La figure 2.5 montre ce que nous comptons construire au terme de ce projet de synthèse.

2.7.1 Qu'est-ce que le triage ?

Lancer un outil de reconnaissance comme nmap contre une cible est simple. Le plus dur vient après, quand vous fixez des pages de sortie en essayant de déterminer ce qui compte.

Même un petit périmètre de bug bounty génère beaucoup de bruit : des dizaines d'hôtes, des ports courants, des bannières de service répétitives et, enfouis là-dedans, quelques détails qui comptent. À ce stade, le goulot d'étranglement n'est pas votre outillage ; c'est votre attention. C'est là que les agents deviennent utiles.

Pour nos besoins, l'agent ne scanne, ne sonde ni n'exploite jamais aucune ressource réseau. Toute la reconnaissance a déjà été réalisée avec des outils que vous connaissez et en qui vous avez confiance. L'agent intervient après la reconnaissance. Il travaille entièrement sur des fichiers de sortie enregistrés, et sa mission est simple : passer en revue les résultats de reconnaissance et vous aider à décider où porter votre attention en premier.

Pour les chasseurs de bug bounty, cela compte. Le temps passé à faire défiler du bruit est du temps qui n'est pas consacré à valider de vraies découvertes. Un agent IA ne remplace ni votre compétence ni votre jugement. Il supprime la friction de la partie la moins rentable de votre workflow, pour que vous puissiez vous concentrer sur ce qui paie vraiment.

2.7.2 La sortie de nmap

Voyons à quoi ressemblent des sorties de reconnaissance typiques. Supposons que vous ayez déjà identifié un ensemble de noms d'hôtes exposés publiquement et que vous les ayez scannés avec nmap pour une découverte de services basique. Le trafic réseau a déjà eu lieu.

Le listing 2.11 est une représentation simplifiée et lisible par un humain de la sortie de nmap :

Host: api.example.com
  80/tcp   open http    Apache httpd 2.4.41
  443/tcp  open https   Apache httpd 2.4.41
  8443/tcp open https   Jetty 9.4.18

Host: admin.example.com
  22/tcp   open ssh     OpenSSH 7.2p2
  443/tcp  open https   nginx 1.18.0

Host: files.example.com
  21/tcp   open ftp     vsftpd 3.0.3
  80/tcp   open http    nginx 1.14.2

Host: legacy.example.com
  23/tcp   open telnet
  80/tcp   open http    Apache httpd 2.2.34

Rien ici ne paraît inhabituel au premier coup d'œil. L'essentiel est familier — et c'est exactement le problème. À mesure que les périmètres grandissent, les sorties deviennent répétitives. Les ports 80 et 443 apparaissent partout. Les serveurs web se confondent. Les chaînes de version cessent de signifier quoi que ce soit. Les détails qui comptent — ports inhabituels, services hérités, interfaces d'administration exposées — se noient dans le bruit.

C'est là qu'un agent IA aide. L'agent n'a pas besoin de comprendre comment fonctionne nmap ni comment le scan a été configuré. Il traite simplement la sortie comme un document et répond à une question étroite : « Quels hôtes ou services se démarquent suffisamment pour justifier une investigation supplémentaire ? » Pas d'exploitation. Pas de scan. Aucune hypothèse sur ce qui vient ensuite.

2.7.3 Périmètre décisionnel et contraintes de l'agent

La mission de l'agent n'est pas de trouver des vulnérabilités. Cette attente est irréaliste et vous prépare à la déception. L'agent a un rôle bien plus pratique : réduire le bruit et faire remonter les signaux pour que vous puissiez décider plus vite et avec plus de constance.

En pratique, l'agent accomplit un petit nombre de tâches bien définies :

• Signaler les expositions inhabituelles. Les services et ports qui n'apparaissent pas partout. HTTPS sur 443 est attendu. Une interface d'administration sur 8443 ou un service hérité sur 21 ou 23 ne l'est pas.
• Repérer les combinaisons étranges. Détecter les couples de services qui n'ont rien à faire ensemble, comme un FTP public à côté d'une application web, ou un SSH exposé sur un hôte qui semble par ailleurs ne servir que du trafic web.
• Regrouper les hôtes similaires. Grouper les hôtes ayant des piles de services identiques pour éviter les tests redondants et faire ressortir plus facilement les valeurs aberrantes.
• Faire remonter les signaux d'alerte. Mettre en évidence les protocoles hérités, les logiciels en fin de vie et les services qui ne devraient pas être exposés sur Internet. Ce sont des choses que les testeurs expérimentés reconnaissent instinctivement. L'agent rend cet instinct explicite et répétable.

L'agent fonctionne comme un filtre et réduit les résultats à une courte liste d'hôtes méritant votre attention. Il laisse aussi une trace claire de la manière dont il est parvenu à ces conclusions. Cette séparation maintient le workflow sûr, cadré et défendable, tout en apportant de la valeur au point précis où la plupart des chasseurs de bugs perdent du temps : la première passe sur des données de reconnaissance bruitées.

2.7.4 Les artefacts de triage

Après avoir examiné vos données de reconnaissance, l'agent produit quelque chose de nouveau : un résumé de triage hiérarchisé. Cet artefact n'est ni un rapport ni une liste de vulnérabilités : c'est un résumé de triage priorisé, conçu pour une revue rapide. À partir de la sortie nmap précédente, un exemple de résumé pourrait ressembler à ce que montre le listing 2.12.

Résultats à fort intérêt :

1. legacy.example.com
   - Telnet (23/tcp) exposé publiquement
   - Apache httpd 2.2.34 (fin de vie)
   Raison : plusieurs services hérités sur un hôte public

2. files.example.com
   - FTP (21/tcp) exposé aux côtés de HTTP
   Raison : service FTP public associé à un serveur web

3. api.example.com
   - Service HTTPS sur 8443/tcp (Jetty 9.4.18)
   Raison : interface d'administration ou de gestion non standard

Résultats à faible intérêt :

- admin.example.com
  - SSH (22/tcp) et HTTPS (443/tcp)
  Raison : combinaison de services courante, sans anomalie immédiate

C'est la sortie que l'agent est optimisé pour produire : concise, tranchée et facile à exploiter. Pas de spéculation sur les exploits, pas de correspondance CVE, pas de notation de gravité. Chaque élément comporte une brève explication de la raison de son signalement. Cela vous permet d'être d'accord, en désaccord, ou de creuser davantage. Le raisonnement est conservé, si bien que lorsque vous revenez sur cette mission quelques jours plus tard, vous n'avez pas à reconstituer votre pensée de mémoire.

Pour les chasseurs individuels, cela change la façon dont le travail commence. Au lieu de relire des sorties de scan brutes, vous démarrez avec une liste ciblée des cibles les plus prometteuses. Pour les équipes, l'artefact peut servir de référence partagée. Les décisions de triage sont transparentes : chacun peut voir ce qui a été signalé et pourquoi, ce qui facilite les transferts et la collaboration. La figure 2.6 résume l'agent que nous avons construit.

2.7.5 Bénéfices pratiques et contraintes de sécurité

Pour les chasseurs de bugs, le goulot d'étranglement de la reconnaissance est rarement l'outillage ; c'est le temps et l'attention nécessaires pour transformer des sorties brutes en décisions. Les scans se terminent vite. Le triage, non. Ce workflow répond directement à cet écart.

L'agent n'automatise pas l'exploitation et ne remplace pas votre jugement. Il prend en charge la partie la plus répétitive du processus : la première passe sur les données de reconnaissance. L'agent applique le même raisonnement qu'un testeur expérimenté : signaler les anomalies, regrouper les hôtes similaires et faire remonter les valeurs aberrantes. Mais il peut le faire de façon constante et sans fatigue.

Cette constance compte. Quand on travaille sur de larges périmètres ou qu'on avance vite, il est facile de rater quelque chose d'évident ou de passer trop de temps à courir après des cibles à faible valeur. L'agent ne résout pas cela en étant plus intelligent ; il le résout en étant prévisible. Chaque décision est enregistrée et chaque signalement est expliqué.

Cette approche évite aussi les écueils du prétendu « scan piloté par l'IA ». L'agent ne touche jamais au réseau, n'élargit jamais le périmètre et ne sonde jamais les cibles. Tout ce qu'il voit, ce sont des données que vous avez déjà collectées. Tout ce qu'il produit est un artefact que vous pouvez inspecter, partager ou jeter. Pour les chasseurs de bugs débutants, ce type d'agent agit comme une fonction de forçage : il rend explicite le raisonnement derrière le triage de reconnaissance. Avec le temps, ce retour affûte l'intuition au lieu de la remplacer.

L'agent ne trouve pas de bugs, n'écrit pas de rapports et ne prend pas de décisions irréversibles. Il raccourcit la distance entre « le scan est terminé » et « voici ce qui mérite d'être testé ensuite ». C'est le rôle approprié de l'automatisation en sécurité offensive, et il pose les fondations des workflows multi-agents présentés au chapitre suivant.

2.8 Résumé

Chapitre 3Pipelines multi-agents et orchestration

Au chapitre précédent, nous avons établi la définition d'un agent IA : une entité de décision qui raisonne, agit via des outils et enregistre son comportement sous forme d'artefacts. Nous avons créé un agent de triage opérant dans un périmètre clairement défini. Mais les vrais workflows de sécurité offensive s'arrêtent rarement à un seul point de décision. La reconnaissance alimente le triage. Le triage alimente la priorisation. La priorisation alimente les tests, le reporting ou l'escalade. Chaque étape produit des artefacts qui déterminent la suite. Tenter de comprimer ce processus dans un unique agent « intelligent » aboutit à des systèmes fragiles, à un comportement opaque et à des défaillances difficiles à diagnostiquer ou à défendre.

Nous traitons les pipelines multi-agents comme un problème de systèmes. Plusieurs petits agents spécialisés sont composés en un workflow contrôlé. Les artefacts forment l'interface entre les étapes. L'orchestration gouverne l'ordre d'exécution, les dépendances et la gestion des échecs. L'approbation humaine et les portes de sécurité restent des composants explicites du système. L'objectif n'est pas une IA qui en fait plus, mais un système qui en fait moins à chaque étape, avec plus de clarté et de responsabilité au global.

Ce chapitre définit les schémas utilisés pour construire des pipelines multi-agents de façon sûre et prévisible : où les workflows mono-agent se brisent, comment les artefacts permettent un couplage lâche, et comment l'orchestration impose le contrôle sans loger de l'intelligence là où elle n'a rien à faire. Tout du long, l'accent est mis sur la défendabilité. Les systèmes multi-agents sont traités comme des workflows de production, pas comme des expériences. Chaque point de décision est observable. Chaque transition laisse une trace. Les échecs sont attendus et anticipés par la conception.

À la fin de ce chapitre, vous disposerez d'un modèle architectural concret pour composer des agents en pipelines qui passent à l'échelle sur des workflows de sécurité offensive complexes, sans sacrifier le contrôle du périmètre, l'auditabilité ni la supervision humaine.

3.1 Pourquoi des systèmes multi-agents ?

Les agents uniques fonctionnent bien lorsque le problème posé est étroitement délimité. Des tâches comme résumer une sortie de reconnaissance, trier des résultats de scan, classifier des points de terminaison ou rédiger un rapport préliminaire s'inscrivent naturellement dans une seule boucle ReAct. Les vrais workflows de sécurité offensive n'ont pas cette forme. Un test d'intrusion, une mission de red team ou une investigation de bug bounty se déroulent en plusieurs étapes dépendantes. La reconnaissance produit des observations brutes. Ces observations doivent être interprétées, filtrées et priorisées. La priorisation détermine où l'effort sera porté ensuite. Les décisions prises tôt affectent tout ce qui suit : ce qui est testé, ce qui est rapporté, et quelles preuves pourront être défendues plus tard. Si nous créons des agents IA pour chaque étape (reconnaissance, triage, reporting…), nous devons coordonner et orchestrer leurs interactions afin qu'ils fonctionnent comme une équipe cohérente (figure 3.1).

C'est là qu'interviennent les pipelines multi-agents. Rappelez-vous, au chapitre 1, qu'un pipeline connecte plusieurs composants pour les faire fonctionner comme un système unique et cohérent. Les pipelines multi-agents font exactement cela : ils définissent comment les données circulent entre différents agents et systèmes, quand chaque étape s'exécute, et quels contrôles de sécurité interviennent entre les deux. Les pipelines apportent à nos agents autonomes une structure, transformant l'intelligence individuelle en un workflow prévisible et scalable. À la fin de ce chapitre, vous saurez concevoir efficacement des systèmes multi-agents : comment faire circuler des artefacts entre agents, ajouter de l'orchestration pour chorégraphier leurs mouvements, garantir la robustesse par la gestion d'erreurs, et intégrer sécurité et résilience directement dans vos workflows. Cela vous permettra de passer d'un agent spécialisé unique à une équipe disciplinée d'agents IA.

3.2 Modèle mental multi-agent

Commençons notre modèle mental multi-agent par un sujet abordé au chapitre 2 : le pipeline. Rappelez-vous que, pour un agent unique, notre agent ReAct itérait sur les étapes de raisonnement, action, observation, réflexion et enregistrement, jusqu'à converger vers la bonne solution.

Les systèmes multi-agents se composent de nombreux agents individuels, chacun capable de mener son propre pipeline de raisonnement, comme le montre la figure 3.2. L'essentiel est de comprendre comment plusieurs agents sont organisés et reliés. Les modèles stockent leurs sorties sous forme d'artefacts, qui peuvent être persistés comme fichiers physiques ou transmis sous forme de bits d'un agent à un autre. Dans les deux cas, l'idée centrale est que les sorties d'un modèle deviennent les entrées d'un autre.

Une autre idée centrale est la possibilité de relier différents agents de manières spécifiques qui font émerger des fonctionnalités distinctes. Le système multi-agent le plus simple est celui où les agents sont chaînés séquentiellement. C'est comme le jeu du téléphone arabe : une personne transmet un message à une autre, et ainsi de suite jusqu'à ce que la dernière le dise à voix haute. Si c'est pratique, on peut transmettre l'information selon d'autres motifs. On peut par exemple créer des branches, où le message d'un agent est routé vers un autre selon une condition donnée. On peut aussi transmettre le même message à plusieurs agents simultanément, leur faire produire des sorties différentes, puis fusionner leurs réponses individuelles en une réponse unique et cohérente. Vous pouvez expérimenter diverses structures multi-agents pour bâtir des applications très complexes.

Maintenant que nous comprenons comment les agents peuvent être chaînés, examinons les différentes topologies qu'ils peuvent adopter et l'influence de ces choix sur leur coopération.

3.3 Les artefacts comme interfaces entre agents

Au chapitre 1, nous avons introduit les artefacts comme des enregistrements structurés décrivant les réponses du modèle. Les artefacts contiennent aussi des métadonnées relatives à l'exécution d'un agent : ce que l'agent a fait, ce qu'il a reçu et ce qu'il a produit à une étape donnée (figure 3.3).

Les artefacts sont le tissu conjonctif de tout pipeline : ils préservent le contexte, garantissent la traçabilité et permettent aux exécutions interrompues de reprendre exactement là où elles se sont arrêtées. Ils sont l'interface entre agents.

À retenir : les artefacts doivent contenir suffisamment d'informations pour donner le contexte de la tâche du modèle et des indices sur l'endroit où des erreurs ont pu survenir. Un exemple d'artefact est un fichier de journal, qui nous permet de déboguer notre système. Dans l'exemple fourni, chaque ligne du journal capture une décision complète : les données entrantes, l'action entreprise par l'agent, et le fait que la décision ait réussi ou non.

Pour nos besoins, les agents ne s'appelleront pas directement entre eux, ne partageront pas d'état en mémoire et ne se transmettront pas d'objets propres à un framework. Chaque agent produit des artefacts que les agents en aval consomment. Ce choix de conception est délibéré. Il impose la séparation, préserve la clarté et prévient les défaillances de coordination qui deviennent difficiles à détecter à mesure que les systèmes grandissent.

Lorsque les agents s'appellent directement entre eux, l'ordre d'exécution devient implicite, l'état fuit d'une préoccupation à l'autre, les échecs se propagent silencieusement et l'auditabilité se dégrade. Dans les workflows de sécurité offensive, ces défaillances sont inacceptables. Une décision de triage ne doit pas dépendre d'une hypothèse de reconnaissance non documentée. Un agent de reporting ne doit pas hériter à son insu d'un choix de priorisation non revu.

Les artefacts marquent la fin de la responsabilité d'un agent et le début de celle d'un autre. Tout ce qu'un agent sait doit provenir des artefacts qu'il consomme. Tout ce qu'il apporte doit être exprimé dans les artefacts qu'il produit. Rien d'autre n'a le droit de circuler entre agents. Penser les artefacts comme de simples « journaux » sous-estime leur rôle. Dans un pipeline multi-agent, un artefact fonctionne comme un contrat. Il définit quelles données sont disponibles en aval, comment elles sont structurées, quelles hypothèses sont sûres, et quelle provenance peut être tracée.

Un agent de reconnaissance peut découvrir des hôtes et des métadonnées. Un agent de triage consomme cet artefact et produit des décisions de priorisation. Un agent de reporting consomme l'artefact de triage et produit une sortie narrative. Chaque artefact conserve un sens stable même lorsque les implémentations évoluent. Les agents en aval sont protégés des changements en amont tant que le contrat d'artefact reste intact.

3.4 Provenance, rejeu et auditabilité des artefacts

Les artefacts sont durables et contiennent des sorties persistantes, ce qui permet au pipeline agentique de se mettre en pause à n'importe quelle étape. Par exemple, une sortie de reconnaissance peut être revue avant que le triage ne commence. Une décision de triage peut être corrigée sans relancer la reconnaissance. Un rapport peut être régénéré à partir d'artefacts antérieurs sans répéter les étapes précédentes.

Garder un humain dans la boucle est une exigence de sécurité, et les artefacts sont essentiels pour que les humains puissent auditer la sûreté des agents. Dans les missions réelles, l'état et les hypothèses que nous formons sur nos applications changent. Le périmètre se clarifie, des résultats sont contestés. Les artefacts permettent de rejouer les pipelines. Le pipeline agentique peut être ré-exécuté depuis un artefact connu pour tester des stratégies alternatives ou valider des correctifs. Pour les défenseurs, le rejeu transforme les simulations offensives en matériel d'entraînement. Pour les auditeurs, il fournit une piste d'exécution vérifiable.

Pour que les artefacts fonctionnent de façon fiable, ils doivent être structurés délibérément, car les agents doivent pouvoir analyser, valider et raisonner sur leurs entrées de manière cohérente. La discipline des artefacts est concrète : champs explicites, horodatages, justification enregistrée et stockage en ajout seul. Les décisions et leur justification doivent être consignées aux côtés des résultats, et la provenance doit être traçable. JSONL est un choix courant parce qu'il équilibre lisibilité humaine et traitement machine, mais le format importe moins que la discipline. Si un agent en aval ne peut pas expliquer d'où provient une information, l'artefact est insuffisant.

Dans les systèmes non structurés, les agents prennent des décisions internes qui ne quittent jamais le modèle. Des sorties apparaissent, mais le chemin de raisonnement est opaque. Dans les domaines à fort enjeu, c'est dangereux. En forçant toute communication inter-agents à passer par des artefacts, les décisions sont externalisées, le raisonnement devient inspectable et les hypothèses peuvent être contestées. Si un agent de triage déprioritise un hôte, ce choix doit apparaître dans l'artefact qu'il produit. Rien ne se passe « dans la tête de l'agent » sans laisser de trace.

3.5 Orchestration des agents et contrôle de l'exécution

Les systèmes multi-agents ressemblent à toute autre entité socialement construite. Un courant sous-jacent guide les agents dans leur auto-organisation en vue d'atteindre certains objectifs. On l'appelle l'orchestrateur, sujet de cette section.

3.5.1 Ce que fait l'orchestrateur

Un orchestrateur est le chef d'orchestre de votre symphonie d'agents : c'est le coordinateur central qui gère plusieurs agents IA en dirigeant leurs interactions, leurs workflows et leurs tâches. Les fonctions essentielles d'un orchestrateur sont :

• Décomposition et routage des tâches : l'orchestrateur découpe les tâches en sous-éléments plus petits et les route vers les bons agents.
• Gestion de l'état : il maintient l'état du workflow, en suivant ce qui est terminé, en cours et en attente.
• Coordination des agents : il détermine quel agent s'exécute quand et quelles données transmettre, évitant ainsi les conflits.
• Logique de décision : elle détermine l'ordre d'exécution, si les tâches doivent s'exécuter séquentiellement ou en parallèle, et comment réagir en cas d'échec ou de besoin d'approbation.

En bref, un orchestrateur transforme une collection d'agents autonomes en un système coordonné et prévisible. Il est indispensable pour bâtir des workflows multi-agents complexes exigeant coordination et coopération. Dans les workflows de sécurité offensive, l'ordre d'exécution n'est pas arbitraire. La reconnaissance doit s'achever avant que le triage ne commence. Le triage doit s'achever avant que la priorisation n'informe la planification de l'exploitation. Le reporting doit attendre que les résultats pertinents soient collectés et justifiés. Exécuter ces étapes dans le désordre, ou les faire se chevaucher sans coordination, produit des résultats trompeurs. Un agent d'exploitation agissant sur des données de triage incomplètes gaspille l'effort. Un agent de reporting consommant des artefacts partiels omet du contexte. Ces défaillances sont subtiles et faciles à manquer.

Au plus simple, l'orchestration est linéaire : un agent s'exécute après que le précédent s'est terminé avec succès (figure 3.4). À mesure que les systèmes se complexifient, l'orchestration peut inclure des branchements, des reprises ou une exécution conditionnelle. Quelle que soit la complexité, le principe reste le même : le flux d'exécution est explicite, externe et inspectable.

3.5.2 Pourquoi avons-nous besoin d'un orchestrateur ?

Pourquoi avons-nous besoin d'un orchestrateur, au fond ? Après tout, cela implique un appel d'API supplémentaire vers un autre agent qui jouera le rôle de manager. Même si l'on peut avoir l'impression d'ajouter de la bureaucratie inutile dans notre système agentique, cette architecture centralisée présente des avantages : 1) une prise de décision rationalisée par l'orchestrateur, et 2) des chemins de communication simplifiés, où les agents exécutants rendent directement compte à l'orchestrateur pour décider. Avec ce choix de conception, nos agents spécialisés se concentrent sur le raisonnement et l'action dans leur rôle propre, plutôt que sur la coordination avec les autres.

3.6 État partagé et frontières de la mémoire

Les vrais workflows de sécurité offensive n'existent pas dans une seule fenêtre d'exécution. La reconnaissance peut avoir lieu des jours avant le triage. Le triage peut être repris lorsque de nouveaux renseignements émergent. Le reporting peut nécessiter de réexaminer des hypothèses anciennes bien après l'arrêt des agents. Prendre en charge cette continuité exige que l'agent « se souvienne » de ce qui a été exécuté auparavant.

Précisons que les agents ne deviennent pas « plus intelligents » parce qu'ils ont de la mémoire : ils ne forment ni croyances ni intuition, et ne raisonnent pas sur le passé à moins qu'il ne leur soit présenté explicitement. La mémoire agentique existe pour préserver un état, et elle n'est nécessaire que lorsque plusieurs agents doivent se coordonner dans la durée.

En pratique, la mémoire se construit par-dessus les artefacts (figure 3.5). Les artefacts font persister décisions, observations et justifications. Les couches de mémoire organisent, résument ou indexent les artefacts pour qu'ils puissent être réutilisés dans le temps et entre les étapes. Un artefact de reconnaissance peut être résumé pour le triage. Un artefact de triage peut devenir un état faisant autorité pour le reporting. Cela préserve l'auditabilité tout en permettant aux systèmes de passer à l'échelle.

Pour que la mémoire fonctionne correctement, elle doit être structurée délibérément. Des blocs de texte libre ne suffisent pas. Les agents en aval doivent pouvoir analyser, valider et raisonner sur l'état de façon cohérente. Une conception de mémoire efficace privilégie les champs explicites, les horodatages, les identifiants de source, les justifications enregistrées et les structures en ajout seul. JSONL est un choix courant parce qu'il équilibre lisibilité humaine et traitement machine, mais le format précis importe moins que la discipline.

3.7 Portes de sécurité et contrôle des autorisations

Au chapitre 2, nous avons abordé les portes de sécurité pour agents uniques. L'automatisation en sécurité offensive est intrinsèquement à double usage. Les mêmes workflows qui simulent un comportement adverse peuvent, s'ils sont mal employés, franchir des frontières d'autorisation, provoquer des perturbations opérationnelles ou créer une exposition juridique. Ce n'est pas hypothétique ; c'est une préoccupation courante dans les missions professionnelles.

Dans cette section, nous verrons comment appliquer des portes de sécurité aux systèmes multi-agents.

3.7.1 Appliquer des portes de sécurité dans les systèmes multi-agents

À mesure que les systèmes d'agents gagnent en capacités, le coût d'une mauvaise décision augmente. Une cible mal classée, un hôte hors périmètre ou une escalade non voulue peuvent se propager rapidement dans un pipeline automatisé. Sans contrôles explicites, ces défaillances peuvent ne pas être détectées avant que les dégâts ne soient faits. C'est pourquoi les portes de sécurité sont appliquées après chaque étape agentique, comme le montre la figure 3.6.

Une erreur de conception courante consiste à enfouir la logique de sécurité dans les agents, en demandant par exemple à un modèle de décider si une action est sûre, dans le périmètre ou autorisée. Cela échoue pour deux raisons :

1. D'abord, cela place l'application de la politique à l'intérieur d'un système probabiliste. Les grands modèles de langage savent raisonner, mais ils sont non déterministes, ce qui ne permet pas d'appliquer des politiques à 100 %.
2. Ensuite, cela brouille la responsabilité. Si un agent « décide » de continuer, on ne sait plus qui a approuvé l'action, ni au titre de quelle autorité.

À ce jour, les agents ne peuvent pas s'imposer à eux-mêmes garde-fous et mécanismes de sécurité. Les portes de sécurité doivent vivre en dehors des agents.

3.7.2 L'humain dans la boucle

L'implication humaine est une exigence. Les humains apportent un contexte qui ne peut pas être inféré de façon fiable à partir des seules données ou des autres agents. Il nous incombe de rester dans le périmètre de la mission, de respecter la tolérance au risque propre au client, de rester dans les contraintes légales et d'exercer un jugement opérationnel sain. Les portes de sécurité définissent où le jugement humain entre dans le pipeline.

Plutôt que de retirer les humains de la boucle, les systèmes multi-agents formalisent leur rôle. Ils précisent quand une revue est requise, quelles informations doivent être présentées et comment l'approbation est enregistrée. Cette conception crée des preuves défendables. Lorsqu'un pipeline franchit une porte, l'enregistrement montre qui a approuvé, quand, et sur la base de quel artefact.

Vous avez désormais créé un système d'orchestration discipliné et conscient des politiques. Nous allons maintenant nous attaquer à ce qui se passe quand les choses tournent mal : comment rendre vos pipelines résilients grâce à la gestion d'erreurs, à la reprise et aux points de contrôle.

3.8 Gestion des erreurs et résilience

Nous avons passé en revue les bonnes pratiques du développement agentique, de la prédéfinition des schémas à la journalisation de toutes les actions à des fins d'audit. Si cela aide certainement à prévenir les problèmes lorsque des applications agentiques sont déployées en production, même un pipeline parfaitement conçu peut trébucher de temps à autre. Les API tombent. Les appels d'API vers un LLM peuvent expirer. Un outil peut occasionnellement retourner un format inattendu que le schéma défini ne couvre pas.

Lorsqu'on envisage des applications de qualité production, nous devons évaluer leur robustesse. Un bon orchestrateur ne plante pas ; il doit se rétablir avec élégance. Cela signifie que même si votre application rencontre une erreur, il doit exister un plan B — appeler une autre API, ou signaler à l'utilisateur qu'une erreur s'est produite pour une raison précise. Ces sorties élégantes font partie d'une bonne expérience utilisateur avec les applications agentiques et contribuent à asseoir la confiance.

La résilience transforme votre pipeline d'une automatisation fragile en une expérience maîtrisée à laquelle vous pouvez vous fier dans des opérations de sécurité réelles. Dans cette section, nous couvrirons les bonnes pratiques permettant à votre application agentique de résister aux erreurs et d'encaisser tout ce qu'on lui envoie.

3.8.1 Logique de reprise et repli exponentiel

Les agents IA effectuent constamment des appels réseau vers des API externes, divers points de terminaison, des bases de données et d'autres services. Parfois, ces appels échouent en raison de :

• Limites de débit : trop de requêtes en peu de temps
• Problèmes serveur temporaires (erreurs 503)
• Délais réseau dépassés
• Surcharge d'API aux heures de pointe
• Aléas transitoires de l'infrastructure cloud (autrement dit, le hasard)

La plupart des erreurs transitoires se résolvent d'elles-mêmes, mais sans reprise, votre pipeline agentique plante et le workflow entier échoue à cause d'un simple hoquet. Plutôt que d'échouer immédiatement, votre architecture devrait réessayer quelques fois avec des délais croissants, pour voir si un appel d'API peut aboutir. Ce procédé est appelé repli exponentiel (exponential backoff) : le temps d'attente augmente progressivement entre chaque tentative.

Le listing 3.1 montre du pseudo-code de repli exponentiel, où le temps d'attente double à chaque erreur rencontrée. La première fois, nous attendrons 2 secondes, puis 4 secondes, puis 8 secondes, laissant aux API ou services réseau le temps de se rétablir. Nous réessayons trois fois avant d'abandonner.

import time

def retry_stage(stage, artifact, retries=3):
    for attempt in range(retries):
        try:
            return stage.run(artifact)
        except Exception as e:
            wait = 2 ** attempt
            print(f"[Error] {e} — retrying in {wait}s")
            time.sleep(wait)
    raise RuntimeError(f"Stage {stage.name} failed after {retries} retries.")

3.8.2 Points de contrôle

Les points de contrôle (checkpoints) sont les points de sauvegarde de votre workflow d'IA : ils enregistrent la progression entre les étapes pour qu'un orchestrateur puisse reprendre après une interruption sans refaire le travail déjà accompli, vous faisant gagner du temps et de l'argent.

Le listing 3.2 montre un exemple d'exécution avec point de contrôle, en pseudo-code : si un fichier JSONL portant le nom de l'étape existe déjà, vous chargez l'artefact en mémoire et l'utilisez pour exécuter l'agent à cette étape. En cas de succès, vous enregistrez le nouvel artefact résultant.

def safe_run(stage, artifact):
    checkpoint = f"/runs/{stage.name}.jsonl"
    if os.path.exists(checkpoint):
        print(f"[Resume] Using saved checkpoint for {stage.name}")
        return load_artifact(checkpoint)
    result = stage.run(artifact)
    save_artifact(result, checkpoint)
    return result

Si le pipeline s'arrête à mi-parcours, le relancer charge le dernier artefact enregistré et poursuit à partir de là.

3.8.3 Classes d'erreurs et stratégies d'atténuation

Toutes les défaillances ne méritent pas la même réponse. Certains types d'erreurs se prêtent à une reprise, tandis que d'autres devraient être ignorés, mis en pause ou stoppés net. Le tableau 3.1 présente les erreurs courantes et les actions que votre orchestrateur devrait entreprendre en aval.

3.8.4 Supervision, métriques et alertes

Les systèmes de supervision vous informent de l'état de votre système agentique, ce qui vous permet d'identifier et de traiter les problèmes avant qu'ils ne tournent au désastre. C'est d'autant plus important que les agents peuvent sembler fonctionner alors qu'ils échouent.

Il existe quatre domaines centraux qu'il convient de superviser et pour lesquels établir des alertes :

1. Erreurs et défaillances de base : comptez combien d'opérations échouent et catégorisez-les par type d'erreur. Mesurer les taux d'erreur par type ou par agent, et suivre les motifs d'erreur, fournit des indications pour le dépannage et le débogage de problèmes systématiques.
2. Coûts et consommation de tokens : suivez en temps réel combien vous dépensez en appels d'API. Des métriques comme le nombre de tokens par requête ou le coût par agent peuvent révéler des inefficacités à optimiser pour éviter de brûler inutilement votre budget.
3. Qualité et exactitude de l'agent : mesurez la qualité des réponses de votre agent par rapport à un étalon de référence. Des métriques comme le taux d'hallucination, le taux de hors-sujet ou les retours utilisateurs aident à garantir que votre agent offre la meilleure expérience possible.
4. Performance et rapidité de l'agent : mesurez le temps nécessaire à un agent individuel ou à un workflow d'agents pour accomplir une tâche. Le temps de réponse moyen et le débit (requêtes par minute) indiquent où se situent les goulots d'étranglement. Comme les utilisateurs attendent des réponses rapides, il est important d'y remédier pour ne pas dégrader l'expérience.

Il existe diverses manières d'implémenter des alertes, ce qui nous permet d'agir de façon appropriée lorsque des problèmes surviennent. Une méthode simple consiste à ajouter des points d'ancrage légers pour observer la santé du pipeline. Le listing 3.3 montre un simple compteur d'erreurs qui envoie une alerte si plus de 5 erreurs surviennent pour un appel d'API donné.

if error_count > 5:
    send_alert(f"Pipeline {run_id} failing repeatedly")

Avec un peu de configuration supplémentaire, ces alertes peuvent être publiées sur les canaux Slack de votre équipe, sur des adresses e-mail ou sur des tableaux de bord SIEM (Security Information and Event Management). Il est également important d'attribuer une gravité aux alertes. Une seule mauvaise réponse d'agent en environnement de recette peut ne pas exiger d'attention immédiate, mais des coûts qui explosent de façon incontrôlée à cause d'un acteur malveillant en production, c'est une alerte rouge. Enfin, ces métriques, journaux et autres artefacts doivent être conservés pour des analyses ultérieures. Ils deviennent une télémétrie précieuse pour l'analytique défensive et peuvent révéler des aspects importants de notre système agentique, par exemple comment l'agent se comporte sous forte charge.

3.8.5 Bâtir la confiance dans les agents IA par la résilience

Les systèmes d'IA sont des machines probabilistes ; de ce fait […] se propager aux autres étapes.

Lorsque votre orchestrateur traite les problèmes de cette manière, l'automatisation cesse d'être un passif pour devenir un workflow scientifique contrôlé. Les orchestrateurs rendent les pipelines sûrs à exécuter, faciles à expliquer et répétables, pour les red teams comme pour les blue teams.

Votre pipeline peut désormais survivre à des modes de défaillance catastrophiques, et nous disposons des outils pour garantir que votre système multi-agent encaisse tout ce qu'on lui envoie. Vous allez maintenant apprendre à rendre visible son fonctionnement interne : transformer journaux et artefacts en visualisations claires et en pistes d'audit qui racontent l'histoire de ce qui s'est passé, quand et pourquoi.

3.9 Visualisation des métriques et audit des agents IA

À ce stade, votre pipeline multi-agent peut fonctionner avec plusieurs structures de contrôle, se remettre de divers modes de défaillance et respecter les limites définies dans nos politiques de gouvernance. Cependant, puisque les agents agissent de façon autonome et accomplissent une large gamme de tâches — du raisonnement sur des problèmes complexes à l'appel de divers outils, API et autres agents — nous avons besoin d'un moyen de suivre leurs processus et de garantir qu'ils exécutent correctement nos instructions.

L'étape suivante dans la création de systèmes multi-agents efficaces consiste à rendre visible la trace, de l'entrée de l'utilisateur au résultat final. Un pipeline bien instrumenté raconte une histoire : ce qui s'est passé, quand et pourquoi. Disposer d'un moyen de visualiser le processus d'un agent permet un débogage rapide, permet aux équipes de sécurité de repérer anomalies et autres problèmes, et démontre la conformité aux auditeurs.

3.9.1 Générer des traces simples

Une trace enregistre le parcours complet d'une requête ou d'un processus au travers d'un système. Une trace se compose de spans, unités de travail individuelles constituées de :

• Une fonction ou opération spécifique
• Des horodatages de début et de fin
• Les données d'entrée/sortie
• Les métadonnées associées à l'étape
• Les relations parent-enfant avec les autres spans de la trace

Les traces sont puissantes parce qu'elles offrent une visibilité de bout en bout sur les chaînes d'agents individuelles, sur la façon dont les agents collaborent, et révèlent ce que fait l'agent. Une manière de visualiser une trace passe par les artefacts que nous avons construits tout au long du parcours. Puisque nous journalisons déjà chaque étape et chaque horodatage, nous pouvons les résumer en pseudo-code, comme le montre le listing 3.4.

import json, glob

def summarize_run(run_dir):
    for path in sorted(glob.glob(f"{run_dir}/*.jsonl")):
        with open(path) as f:
            for line in f:
                rec = json.loads(line)
                print(f"{rec['timestamp']} | {rec['stage']} | success={rec['success']}")

# Exemple de sortie
# 2025-03-01 10:03 | recon | success=True
# 2025-03-01 10:04 | triage | success=True
# 2025-03-01 10:05 | report | success=True

3.9.2 Vues sous forme de graphes

La trace ci-dessus est informative, mais les représentations visuelles, comme les graphes, sont plus faciles à interpréter. En plus d'afficher les métadonnées pertinentes stockées avec chaque artefact, vous pouvez convertir votre liste d'étapes en un diagramme Mermaid ou Graphviz illustrant le flux de contrôle. Le listing 3.5 fournit du pseudo-code pour créer un organigramme Mermaid, visualisable dans n'importe quel IDE ou via des commandes supplémentaires.

def export_mermaid(stages):
    print("flowchart LR")
    for i, stage in enumerate(stages):
        nxt = stages[i+1].name if i+1 < len(stages) else "END"
        print(f"    {stage.name} --> {nxt}")

# Sortie
# flowchart LR
#     Recon --> Triage
#     Triage --> Report
#     Report --> END

3.9.3 Corréler artefacts et journaux

Si les journaux portent à eux seuls une masse d'informations, il peut être difficile de parcourir de longues traces. Associer les journaux aux données d'artefacts, à l'aide d'outils de visualisation supplémentaires comme des schémas et des graphes, peut aider à identifier les causes racines des défaillances dans les systèmes multi-agents. Ce stockage persistant permet à l'équipe de rejouer rétrospectivement la piste d'audit. La figure 3.7 illustre ce concept.

3.9.4 La défense par la transparence

Un pipeline de red team transparent peut aussi servir de jeu de données d'entraînement pour améliorer et personnaliser des modèles d'IA spécialisés en sécurité. Des points de données tels que journaux de sécurité, politiques de sécurité, rapports de réponse à incident et résultats de tests de sécurité alimentent des modèles d'IA qui renforcent la logique de détection, les modèles de détection d'anomalies et la préparation à la réponse à incident.

Pour les responsables sécurité, tous ces éléments textuels et graphiques deviennent des preuves de conformité lors d'un audit et attestent que chaque action autonome s'est déroulée dans le périmètre et sous gouvernance.

3.9.5 Conseils pratiques de visualisation

• Automatisez la génération des diagrammes après chaque exécution pour que la documentation reste à jour.
• Stockez les sorties comme artefacts (trace.txt, graph.mmd) aux côtés des journaux JSONL.
• Annotez les résultats avec les métriques clés : durée totale d'exécution, erreurs et issues des portes.

Pour une exploration plus riche, nous recommandons d'intégrer des outils de tableau de bord dédiés. Grafana est une plateforme d'observabilité open source conçue pour la supervision de données temporelles. Dans un pipeline agentique, vous pouvez pointer Grafana vers votre magasin de journaux pour bâtir des tableaux de bord temps réel suivant le débit des agents, les taux d'erreur et l'issue des portes au fil des exécutions. Un autre outil est Streamlit, un framework Python qui transforme des scripts en applications web interactives avec très peu de code. Streamlit convient bien à la construction de panneaux de contrôle légers où un chef d'équipe peut filtrer les exécutions par date, inspecter les traces d'agents individuels et creuser des décisions précises. Enfin, les notebooks Jupyter offrent un environnement narratif, cellule par cellule, pour l'analyse exploratoire. Ils sont idéaux pour les analyses approfondies post-mission, où l'on veut charger un journal JSONL, calculer des statistiques de synthèse et afficher des visualisations en ligne dans un seul document. Chaque outil occupe une niche différente : Grafana pour la supervision continue, Streamlit pour des tableaux de bord opérationnels partageables, et Jupyter pour l'investigation ponctuelle.

Les pipelines transparents jettent un pont entre red teams et blue teams, en convertissant l'automatisation brute en intelligence explicable. Lorsque vous pouvez visualiser non seulement ce que vos agents ont fait, mais aussi pourquoi et sous quelle politique, vous atteignez la pleine maturité opérationnelle. La visibilité étant acquise, vous êtes prêt pour le projet de synthèse du chapitre, où vous créerez un pipeline multi-agent complet reliant les agents Recon, Triage et Report en un workflow de sécurité offensive de bout en bout.

3.10 Le pipeline multi-agent de reconnaissance

Nous avons présenté isolément les composants d'un système multi-agent : agents, artefacts, orchestration, portes de sécurité et état partagé. Cette section montre comment ces composants s'assemblent en un pipeline unique et cohérent.

3.10.1 Vue d'ensemble du pipeline

Le pipeline de référence se compose de trois agents coordonnés par un orchestrateur externe, avec des artefacts, des portes de sécurité et un état partagé explicites :

• ReconNormalizeAgent — normalise les données de reconnaissance brutes
• TriageAgent — priorise les résultats et enregistre la justification
• ReportAgent — synthétise une sortie lisible par un humain

Chaque agent obéit à la spécification d'agent minimale. Aucun agent n'a connaissance de l'orchestration, des portes de sécurité ou de la mémoire. Ces préoccupations restent externes.

3.10.2 ReconNormalizeAgent

Le premier agent normalise l'entrée. Il ne note pas, ne priorise pas et ne recommande pas d'actions. Sa seule responsabilité est de convertir une sortie de reconnaissance brute en un schéma d'artefact prévisible.

Artefact d'entrée :

input/recon_raw.jsonl

Artefact de sortie :

runs/<run_id>/recon_normalized.jsonl

Chaque enregistrement inclut l'hôte, le chemin, le statut, le titre, les signaux dérivés et un horodatage, comme le montre le pseudo-code du listing 3.6.

class ReconNormalizeAgent:
    def run(self, raw_records):
        for r in raw_records:
            yield {
                "host": r["host"],
                "path": r.get("path", "/"),
                "status": r["status"],
                "title": r.get("title", ""),
                "signals": infer_signals(r),
                "ts": now()
            }

À cette frontière, l'orchestration vérifie la validité de l'artefact et applique les contraintes de périmètre. Les enregistrements hors périmètre sont exclus et consignés comme décisions de porte.

3.10.3 TriageAgent

Le deuxième agent consomme l'artefact normalisé et applique une logique de priorisation, sans exploitation, sans scan et sans interaction en direct.

Artefact d'entrée :

recon_normalized.jsonl

Artefact de sortie :

runs/<run_id>/triage.jsonl

Chaque enregistrement inclut la priorité, la justification, des références aux preuves et un horodatage, comme le montre le pseudo-code du listing 3.7.

class TriageAgent:
    def run(self, normalized_records):
        for r in normalized_records:
            priority, reasons = score(r)
            yield {
                "host": r["host"],
                "priority": priority,
                "reasons": reasons,
                "evidence_refs": r["signals"],
                "ts": now()
            }

Avant de poursuivre, le pipeline s'arrête à une porte d'intervention humaine. Le relecteur inspecte l'artefact de triage et le contexte de périmètre. L'approbation ou le refus est enregistré comme artefact de porte.

3.10.4 ReportAgent

Le dernier agent consomme l'artefact de triage et produit une sortie destinée à la consommation humaine.

Artefact d'entrée :

triage.jsonl

Sorties :

runs/<run_id>/report.md
runs/<run_id>/report.jsonl

class ReportAgent:
    def run(self, triage_records):
        report = []
        for r in triage_records:
            if r["priority"] == "high":
                report.append(format_section(r))
        return render_markdown(report)

Les étapes suivantes suggérées sont clairement signalées comme nécessitant une approbation. Avec un pipeline concret en place, la question restante n'est plus de savoir comment le système fonctionne, mais comment il échoue. La section suivante examine les modes de défaillance courants des systèmes multi-agents et les choix de conception qui les empêchent de devenir catastrophiques.

3.11 Modes de défaillance des systèmes multi-agents

Jusqu'ici, nous avons décrit une architecture disciplinée pour les pipelines multi-agents et, sur le papier, cette architecture est robuste. En pratique, de tels systèmes échouent quand même.

La défaillance n'est pas la preuve que l'architecture est mauvaise ; c'est la preuve qu'elle est utilisée. La différence entre un système fragile et un système robuste ne tient pas à l'existence de défaillances, mais au fait qu'elles soient visibles, circonscrites et récupérables. Cette section examine les modes de défaillance courants des pipelines multi-agents et les leçons de conception qu'ils révèlent.

3.11.1 La dérive silencieuse des artefacts

Les artefacts sont l'interface entre agents. Lorsque la structure d'un artefact change de façon inattendue à cause d'un agent, les agents en aval peuvent continuer à travailler sur des entrées incorrectes, provoquant des erreurs en cascade.

Cette défaillance paraît souvent anodine. Un champ est ajouté. Un nom change. Le sens d'un signal se déplace légèrement. Rien ne plante. Le pipeline continue de tourner, mais cela peut ouvrir la voie à une dégradation des résultats. Les rapports restent plausibles. Les priorités semblent subtilement fausses. Des classes entières de résultats disparaissent sans explication. La dérive silencieuse des artefacts est dangereuse parce qu'elle se déguise en succès.

Traiter les artefacts comme des contrats, et non comme des objets de commodité, prévient cette défaillance. Le versionnage de schéma, la validation explicite et l'enregistrement des métadonnées de schéma aux côtés des données garantissent que les changements cassants remontent immédiatement. Si un agent ne peut pas analyser un artefact avec certitude, il doit échouer bruyamment plutôt que de poursuivre en silence.

3.11.2 L'orchestration cachée à l'intérieur des agents

Une autre défaillance courante survient lorsque la logique d'orchestration fuit dans les agents. Un agent se met à décider si un autre agent doit s'exécuter, réessayer ou s'arrêter. Le flux de contrôle s'enfouit dans le raisonnement.

Cela arrive rarement d'un coup. Une condition est ajoutée « juste cette fois ». Une reprise est déclenchée en interne plutôt que par l'orchestrateur. Avec le temps, l'ordre d'exécution devient implicite et fragmenté. Il en résulte un système difficile à raisonner. Les défaillances se propagent de façon imprévisible. Redémarrer depuis un état connu devient impossible parce que la logique de contrôle est dispersée.

L'orchestration doit rester externe, déterministe et volontairement ennuyeuse. Les agents ne doivent jamais décider de l'ordre d'exécution. Lorsqu'un agent semble avoir besoin de cette autorité, c'est généralement le signe que les frontières du pipeline sont floues.

3.11.3 Les portes de sécurité traitées comme des formalités

Les portes de sécurité perdent leur efficacité lorsqu'elles sont traitées comme de simples tampons. Tôt dans le développement d'un pipeline, des étapes d'approbation sont souvent ajoutées avec de bonnes intentions, avant d'être contournées « pour aller plus vite ». Avec le temps, l'habitude se normalise. Les portes existent, mais plus personne n'examine sérieusement ce qui les traverse. Ce n'est pas une défaillance de l'outillage. C'est une défaillance du processus de travail.

Une porte de sécurité qui ne bloque jamais rien est pire que pas de porte du tout. Les portes efficaces présentent une information concise et pertinente pour la décision, et n'apparaissent que là où un jugement est requis. Si une porte devient bruyante ou pesante, les équipes la contourneront. Si elle n'exige jamais de décision, elle ne fait pas son travail.

3.11.4 L'accumulation de mémoire sans correction

La mémoire permet la continuité, mais elle engendre aussi de la fragilité lorsqu'elle est traitée comme une vérité immuable. Les pipelines qui ne font qu'accumuler de la mémoire (résumés, état en cache, conclusions historiques) finissent par dériver loin de la réalité. Les données de reconnaissance deviennent obsolètes. Les hypothèses se figent. Le contexte change, mais pas le système.

Cette défaillance se manifeste subtilement. Les agents paraissent constants, mais constamment faux. La mémoire doit être conçue pour la correction, pas seulement pour la rétention. Ancrer la mémoire dans les artefacts permet de régénérer les résumés, de réexaminer les hypothèses et de rejouer les pipelines avec des entrées à jour. La mémoire doit toujours être dérivée, jamais faire autorité.

3.11.5 Les agents surchargés

Un dernier mode de défaillance survient lorsque la pression de « simplifier » conduit à demander trop de choses aux agents. Un agent qui normalise les données, priorise les résultats, applique la politique et génère des rapports peut sembler efficace, mais il devient fragile. Le raisonnement s'emmêle. Les défaillances deviennent difficiles à isoler. Les artefacts perdent leur sens parce que les préoccupations sont mélangées.

Cette défaillance est particulièrement tentante lorsque les systèmes fonctionnent bien au départ. La complexité s'installe par le succès.

Quand un agent assume plus d'une responsabilité, la bonne réponse est de scinder le pipeline, pas d'étendre l'agent.

Au chapitre suivant, vous mettrez ces compétences d'orchestration en pratique en construisant un pipeline de RECONNAISSANCE piloté par l'IA : automatiser la collecte, l'enrichissement et l'analyse de données tout en restant fermement dans les limites éthiques et légales.

3.12 Résumé

Chapitre 4Agents de reconnaissance passive

En sécurité offensive, la reconnaissance est le point de départ de toute opération — et souvent l'endroit où elle se gagne ou se perd. Avant d'exploiter une cible, ou même de concevoir une charge utile, vous devez cartographier le terrain. Dans les missions de reconnaissance traditionnelles, cette cartographie mêle de façon dispersée des recherches manuelles d'adresses IP et de domaines, l'usage d'outils en ligne de commande pour naviguer dans les systèmes, et l'écriture de scripts ponctuels pour des tâches précises. Chaque exécution manuelle laisse derrière elle une traînée de notes ad hoc et de captures d'écran, ce qui rend difficile de retracer vos pas. Sans systèmes établis et automatisés capables de surveiller vos systèmes de façon complète et de laisser des artefacts consultables, lorsque quelqu'un demande « d'où vient cet hôte ? », il n'y a pas de réponse claire.

Cette confusion et cette absence de processus de revue changent dès lors que vous traitez la reconnaissance comme un pipeline automatisé. Plus puissant encore, établir un pipeline de reconnaissance assisté par IA transforme des commandes isolées et ponctuelles en un workflow répétable, avec des étapes explicites, des sorties structurées et des portes de sécurité avec humain dans la boucle. Chaque étape de la reconnaissance — énumération, résolution, sondage léger et synthèse — devrait émettre un artefact indiquant ce que vous avez fait, ce que vous avez observé et quand. Trianguler et chaîner tous ces artefacts vous permet de reconstruire une piste d'audit vérifiable de l'opération.

Conformément à la philosophie BlackHat AI, le rôle de l'IA n'est pas de remplacer votre jugement de professionnel de la cybersécurité. Les outils et systèmes d'IA sont plutôt conçus pour soutenir votre raisonnement, faciliter les processus manuels et augmenter les tâches humaines. Par exemple, un modèle de langage peut proposer quels sous-domaines essayer, expliquer des anomalies d'en-têtes et autres indicateurs précoces d'un intergiciel défensif (le fingerprinting complet de WAF est abordé au chapitre 5), ou résumer ce qu'il a appris. Dans tous les cas, il est essentiel de souligner que des humains surveillent en permanence et garantissent que l'IA opère dans les limites que vous avez définies. Les humains gardent la main sur l'exécution en tant que superviseurs et décideurs d'escalade. Dans le même temps, l'agent IA contribue à construire le contexte nécessaire à l'exécution des tâches redondantes et à en garantir la constance.

Dans ce chapitre, vous construirez un pipeline de reconnaissance passive minimal et auditable, qui se comporte comme un analyste junior : il planifie, agit, observe et enregistre, sans toucher à la logique applicative en direct. À la fin du chapitre, vous saurez construire des systèmes défensifs automatisés capables de fournir une évaluation approfondie de la posture de sécurité, d'analyser la surface d'attaque de votre organisation, de mener des exercices de modélisation des menaces, et bien plus encore.

Le pipeline de reconnaissance passive que vous construirez à la fin de ce chapitre va :

1. Générer un petit ensemble de noms d'hôtes candidats pour un domaine racine.
2. Les résoudre à l'aide du DNS passif.
3. Envoyer une unique requête HEAD sûre pour collecter les en-têtes de réponse.
4. Capturer des métadonnées TLS légères (ALPN et SAN).
5. Ajouter chaque observation dans un artefact versionné recon.jsonl que vous pourrez rejouer ou étendre plus tard.

C'est un programme compact, mais il démontrera une approche extensible vers des systèmes multi-agents plus vastes, avec des étapes modulaires, des garde-fous stricts et des composants d'explicabilité. Nous ferons en sorte que chaque observation soit liée à un horodatage et à une justification, ce qui vous permettra de mettre en pause, d'auditer ou de poursuivre le processus à tout moment.

4.1 Pourquoi un agent de reconnaissance IA ?

La reconnaissance (recon) porte sur la découverte : plus précisément, la collecte d'informations sur un système cible, un réseau ou une organisation. Elle inclut la cartographie des sous-domaines, le catalogage des ports ou l'inspection des certificats TLS.

Il existe deux types de reconnaissance : la reconnaissance passive et la reconnaissance active. En reconnaissance passive, vous cherchez à collecter des informations sans interagir directement avec la cible. Cela inclut tout, de la lecture du site web d'une entreprise à la consultation de bases de données de fuites, en passant par la vérification des enregistrements WHOIS. Vous ne contactez pas directement le système cible, ce qui signifie que votre activité est indétectable et repose sur des informations publiquement disponibles.

À l'inverse, la reconnaissance active implique d'interagir directement avec les systèmes cibles. Vous exécutez un scan de vulnérabilités, vous parcourez une application web, vous cartographiez le réseau cible. Ces interactions directes sont détectables (le système cible journalisera probablement votre activité) et présentent un risque plus élevé, car une activité anormale peut déclencher pare-feu et alertes. Surtout, nous devons nous assurer d'être correctement cadrés pour mener de la reconnaissance active car, sans autorisation, ces activités peuvent être illégales. Dans les deux cas de figure, vous collectez de petits fragments de vérité sur une cible et vous tentez de les transformer en discernement — révéler un exploit dans le système ou identifier une menace. Ce qui a changé à l'ère de l'IA, c'est la façon dont nous organisons ces découvertes et dont nous accélérons l'action et la remédiation.

Un testeur d'intrusion typique mènerait une session de reconnaissance avec plusieurs terminaux ouverts, chacun exécutant un outil différent. La méthode traditionnelle consiste à lancer dig ou nslookup (ne vous inquiétez pas si vous ne connaissez pas ces commandes Bash — elles ne sont pas déterminantes ici) et peut-être à identifier une ou deux requêtes web anormales. Vous copieriez-colleriez manuellement les résultats dans un fichier texte. Après une heure, vous disposez de nombreuses informations sur la session, mais il vous reste énormément de travail : analyser manuellement chaque ligne pour déterminer si vous avez réussi. De plus, il n'existe aucun suivi de lignage de ce que vous avez fait, ce qui signifie que votre processus n'est pas répétable. Tout cela pourrait n'être qu'un coup de chance ! Et sans processus en place (comme un pipeline CI/CD de scripts), il n'y a pas de moyen simple de relancer seulement les parties qui comptent. Ce processus manuel fonctionne, mais il est fragile — et il existe des outils permettant de créer des systèmes mieux structurés et plus répétables.

Un agent de reconnaissance IA remplace tout ce chaos par des étapes explicites et des artefacts persistants consultables manuellement. Ces composants font partie d'un décideur autonome qui agira sur la base des informations dont il dispose et fera sa meilleure hypothèse sur ce qu'il convient de faire ensuite. Si cela paraît inquiétant, c'est en réalité très proche de la façon dont les humains opèrent.

Voyez cet agent de reconnaissance passive comme un tapis roulant de reconnaissance, illustré à la figure 4.1. Chaque étape accomplit une tâche petite et bien définie, transmet sa sortie à la suivante et enregistre les événements dans un journal durable. Si l'exécution s'arrête à mi-chemin, vous pouvez reprendre exactement là où elle s'est interrompue. Si un analyste conteste un résultat, l'artefact indique quelle commande, quels paramètres et quel moment l'ont produit.

Dans ce livre, les pipelines imposent aussi sécurité et responsabilité. Chaque étape traverse des portes : fenêtres temporelles, contrôles d'approbation ou filtres de périmètre. L'IA peut proposer des actions, mais les humains décident lesquelles exécuter. Cet équilibre — de l'autonomie à l'intérieur de limites — est ce qui rend l'IA précieuse pour la sécurité offensive plutôt que dangereuse.

Cet état d'esprit est la fondation des systèmes multi-agents que vous construirez plus loin dans le livre. Avant de câbler ensemble de plus grandes chaînes d'agents, vous devez comprendre à quoi ressemble un agent unique, propre et répétable. Dans la section suivante, nous construirons un flux agentique unique produisant un seul artefact de reconnaissance.

4.2 L'architecture d'agent minimale

Avant de plonger dans le code, définissons ce à quoi ressemble réellement un agent de reconnaissance IA minimal. Nous commencerons par fixer le pipeline minimal viable : ce qui est inclus et ce qui ne l'est pas. Voyez-le comme la version la plus réduite possible d'un workflow intelligent.

4.2.1 Pipelines contre scripts

Un script est un programme qui automatise une tâche unique. Un script agit comme un système autonome et, s'il peut être exécuté seul, il peut aussi être importé comme module dans d'autres scripts. À l'inverse, un pipeline est une série de processus ou d'étapes connectés, où la sortie d'une étape devient l'entrée de la suivante. Les scripts sont les briques des pipelines : les pipelines orchestrent et appellent plusieurs scripts en séquence. L'idée centrale est que les scripts sont les briques de construction de pipelines réalisant une grande variété de tâches essentielles et produisant des résultats variés.

Les pipelines forment la fondation de chaque workflow de sécurité piloté par l'IA dans ce livre. Là où un script de reconnaissance traditionnel se contenterait de récupérer des en-têtes et de les afficher à l'écran, un pipeline enveloppe cette même logique dans une structure qui :

1. Accepte des données d'entrée via une interface d'étape simple.
2. Produit la sortie sous forme d'artefact structuré (généralement en JSON) incluant le contexte de l'étape et des horodatages.
3. Utilise des portes intégrées qui garantissent que les actions sont délibérées et sûres.
4. Accepte les demandes de l'utilisateur de mettre en pause, revoir ou rejouer des étapes sans perdre le contexte.

La différence clé entre un simple pipeline et un agent IA est que les pipelines exigent une intervention humaine. Les pipelines sont fragiles en ce sens qu'un léger changement de l'environnement (le jeu de données d'entrée, la requête utilisateur ou le schéma d'API) peut les casser. L'avantage d'un agent IA est qu'il réagit aux changements de son environnement : il peut raisonner et déterminer la meilleure marche à suivre, invoquer des outils externes pour l'assister, et faire tout cela sans qu'un script ne soit nécessaire.

4.2.2 Les quatre briques pour construire des agents ReAct

Comme nous l'avons vu dans les chapitres précédents, les agents ReAct reposent sur quatre parties réutilisables, résumées dans le tableau 4.1. Voyons comment chacune de ces composantes ReAct s'inscrit spécifiquement dans la reconnaissance passive.

La phase de planification utilise la méthode de la chaîne de pensée pour raisonner sur des problèmes complexes. En reconnaissance passive, la planification détermine la stratégie de reconnaissance à partir des objectifs et de l'état de connaissance actuel de l'agent. Ici, nous devons fournir à l'agent des informations telles que les composants que nous évaluons, les limites que nous avons fixées, les hypothèses que nous testons (par exemple, la menace utilise probablement AWS d'après Y) et des considérations de posture opérationnelle et de sécurité. La phase d'action exécute des techniques de reconnaissance passive spécifiques : interroger des bases WHOIS, vérifier sur GitHub la présence d'identifiants ou de code divulgués, et d'autres activités de reconnaissance. Une fois la tâche exécutée, l'agent analyse les résultats, en extrait des enseignements et met à jour sa compréhension (ou son contexte). Ces enseignements sont éphémères et disparaîtront à la fin de la session. Pour conserver les informations essentielles en vue de sessions futures, nous enregistrons nos découvertes en sauvegardant les sorties et le contexte du modèle dans un artefact, tel qu'un fichier JSON ou une base de données vectorielle. Nous pouvons stocker ces découvertes pour que le modèle puisse les récupérer plus tard (par exemple pour se remémorer un événement de reconnaissance similaire) ou pour l'entraînement de modèles. La figure 4.2 montre ces composants reliés entre eux.

Dans la suite de ce chapitre, nous montrerons comment construire un agent ReAct pour de la reconnaissance active non intrusive, en assemblant des fonctions qui réalisent des tâches comme le sondage HTTPS (listing 4.4) et la recherche d'indices de WAF (listing 4.10). L'agent génère bien des requêtes contre la cible : il est donc actif par définition, et votre adresse IP apparaîtra dans les journaux de la cible. Cela dit, il reste bien en deçà du seuil de déclenchement des défenses, de l'envoi de charges utiles ou de tout impact opérationnel. Les techniques réellement passives (transparence des certificats, Shodan, DNS archivé) se situent en amont de ce travail.

4.2.3 Les artefacts fournissent une mémoire persistante à l'agent

Rappelez-vous que les artefacts sont des sorties persistantes et tangibles (comme des fichiers JSON) que les agents créent et stockent au cours de leurs opérations. En reconnaissance, nous y stockons nos découvertes sur l'hôte, le réseau ou le système que nous explorons.

Par exemple, nous montrons ci-dessous des informations relatives à un hôte que nous évaluons, permettant la collecte de renseignement :

{
    "schema": "recon-v1",
    "host": "api.example.com",
    "a": ["203.0.113.10"],
    "headers": {"server": "cloudflare"},
    "waf_hint": true,
    "tls": {"alpn": ["h2"], "san": ["api.example.com"]},
    "notes": ["status:200", "robots:yes"],
    "ts": "2025-10-28T14:03:11Z"
}

On le voit, nous capturons des informations essentielles sur le système : détails de l'hôte, adresse cible, en-têtes détectés, et plus encore. Nous recommandons de stocker vos découvertes de reconnaissance dans des fichiers JSONL, lisibles par la machine et adaptés aux LLM. Tout au long du livre, nous ferons référence à l'artefact de sortie de l'agent de reconnaissance sous le nom recon.jsonl. Stocker des artefacts JSONL facilite la construction de systèmes de supervision capables de fusionner plusieurs artefacts, d'effectuer des recherches et d'en tirer des enseignements, ou de rejouer des actions d'agent à des fins de débogage et de simulation. Plus tard, vous alimenterez avec ces artefacts des agents IA capables de résumer les résultats et de les préparer pour la priorisation et le reporting en aval.

4.2.4 Les portes de sécurité

Les portes de sécurité sont les points de contrôle décisionnels et les mécanismes de contrôle qui garantissent que les agents opèrent de façon responsable. En reconnaissance, nous devons empêcher nos agents de basculer accidentellement en territoire dangereux (la production, par exemple), illégal ou contraire à l'éthique. Sans portes de sécurité, les agents peuvent réaliser par inadvertance de la reconnaissance active, déclencher des alertes de sécurité qui compromettent l'opération, violer des lois sur la vie privée et causer bien d'autres dommages. Avant que notre agent n'effectue le moindre appel réseau, nous appliquerons deux portes de sécurité :

1. Une porte de fenêtre temporelle qui garantit que les exécutions n'ont lieu que pendant les heures approuvées.
2. Une porte d'approbation (ou d'automatisation) qui confirme l'intention avant l'exécution.

Ces deux portes reflètent les pratiques réelles de red team et d'assurance, et nous les réutiliserons dans les chapitres suivants. En activité de prolongement, vous pourriez construire des portes de reconnaissance supplémentaires et plus élaborées. Quelques idées : des portes de contrôle qualité qui interceptent les erreurs de l'agent avant exécution, des portes de limites éthiques garantissant le respect de la vie privée et des limites d'autorisation, et bien d'autres.

4.2.5 Deux scripts, une seule histoire

Pour garder ce chapitre abordable, nous implémenterons l'agent entier dans un unique fichier appelé recon_pipeline.py, qui contiendra les prompts et la logique centrale de reconnaissance passive. Nous créerons également un petit script auxiliaire (artifacts.py) pour l'écriture du JSONL. Ce choix de conception permet au lecteur de se concentrer sur le flux logique plutôt que sur la mise en place d'une organisation de fichiers plus modulaire mais plus complexe. Vous verrez comment chaque fonction correspond directement à une étape agentique et comment les artefacts sont ajoutés à mesure que l'agent progresse. Cela vous préparera à construire des workflows agentiques plus élaborés, comme l'ajout d'options à vos scripts pour activer ou désactiver des étapes optionnelles (TLS ou découverte de contenu, par exemple).

Nous allons maintenant construire cet agent minimal pas à pas, en commençant par l'assistant d'artefacts, puis en parcourant le script en un seul fichier qui réalise la reconnaissance passive de manière sûre et transparente.

4.3 Construire le pipeline de reconnaissance IA minimal

Maintenant que vous avez vu à quoi ressemble un agent de reconnaissance en théorie, construisons-en un. Parcourons un programme unique et autonome qui exécute chaque étape de l'agent en séquence et enregistre ses résultats sous forme d'artefacts structurés.

4.3.1 Pour commencer

Nous allons d'abord activer notre environnement virtuel Python. Il s'agit d'une copie autonome de Python et des paquets que vous installez pour votre projet. C'est important car nous voulons que les paquets installés pour ces exercices restent confinés. Sinon, si vous installez des paquets avec la bibliothèque Python du système, cela risque de casser d'autres installations et dépendances. Au total, activer un environnement virtuel Python vous évitera bien des maux de tête par la suite !

# Créer un environnement virtuel dont les fichiers sont stockés dans le dossier .venv
python -m venv .venv

# Activer l'environnement virtuel
source .venv/bin/activate
# Windows : .venv\Scripts\activate

# Installer les paquets dans l'environnement virtuel
pip install -r requirements.txt

4.3.2 Commencer par l'assistant d'artefacts

Dans le reste de la base de code, nous progressons vers notre orchestrateur de reconnaissance final (listing 4.10), qui combinera toutes les pièces pour exécuter la reconnaissance passive. Le premier composant de ce pipeline détermine comment l'agent enregistre ses apprentissages. Chaque observation, d'une résolution DNS à un en-tête de réponse, est écrite comme une ligne unique de JSON dans un fichier appelé recon.jsonl.

Le listing 4.1 définit les informations qui seront stockées dans la classe Artifact. Cette classe sera utilisée dans tout le reste du pipeline pour fournir à l'agent IA le contexte de ses découvertes. C'est le cœur de la reconnaissance : consigner nos découvertes et agir en conséquence.

from dataclasses import dataclass, asdict, field
from datetime import datetime, timezone
from typing import Dict, List, Optional
import json
import os

# Le chemin de sortie peut être remplacé via une variable d'environnement
OUT = os.environ.get("RECON_OUT", "recon.jsonl")


@dataclass
class Artifact:
    schema: str = "recon-v1"
    host: str = ""
    a: List[str] = field(default_factory=list)          #A
    cname: Optional[str] = None                         #B
    headers: Dict[str, str] = field(default_factory=dict)   #C
    waf_hint: Optional[bool] = None                     #D
    tls: Optional[Dict] = None                          #E
    notes: List[str] = field(default_factory=list)      #F
    ts: str = ""                                        #G

#A Adresses IPv4/IPv6
#B Nom canonique/principal (au mieux)
#C En-têtes de réponse (assainis)
#D Heuristique fondée sur les en-têtes (pas une empreinte)
#E {"alpn": [...], "san": [...]}
#F Notes libres (statut, robots, erreurs)
#G Horodatage ISO-8601 UTC posé à l'écriture

La classe Artifact est une dataclass conçue pour stocker des données de reconnaissance structurées sur un hôte cible pendant notre procédure de scan ou d'énumération réseau. Comme indiqué plus haut, nous capturons des informations telles que les données liées au DNS, les métadonnées HTTP, les détails TLS et des notes générales. Le champ schema fournit un versionnage du format de données, et chaque artefact reçoit un horodatage UTC à l'écriture.

Enfin, dans le listing 4.2, nous écrirons quelques fonctions supplémentaires qui poseront l'horodatage de chaque artefact (_now_iso()) et écriront le fichier JSONL. La fonction write_jsonl ajoute les artefacts sous forme d'objets JSON délimités par des retours à la ligne dans un fichier de sortie configurable.

def _now_iso() -> str:
    return datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ")


def write_jsonl(artifact: Artifact, out_path: str = OUT) -> None:
    """
    Append one artifact as a single JSON line. If no timestamp is present,
    set a UTC ISO-8601 timestamp.
    """
    if not artifact.ts:
        artifact.ts = _now_iso()
    os.makedirs(os.path.dirname(out_path) or ".", exist_ok=True)
    with open(out_path, "a", encoding="utf-8") as f:
        json.dump(asdict(artifact), f, ensure_ascii=False, separators=(",", ":"))
        f.write("\n")

Il s'agit d'un conteneur portable et sérialisable permettant d'agréger le renseignement sur un hôte à travers plusieurs sondes ou outils. Le format JSONL permet de diffuser facilement les résultats de manière incrémentale, ce qui permet à l'agent IA de les traiter ensuite avec un outillage standard.

Dans les chapitres suivants, vous alimenterez directement vos agents IA avec ces artefacts JSONL à des fins de raisonnement, de regroupement ou de reporting.

4.3.3 Créer le pipeline de reconnaissance passive

Nous avons créé le composant d'artefact qui sera utilisé dans l'orchestrateur de reconnaissance principal (listing 4.10). La fonction combine toutes les étapes (planifier, agir, observer et enregistrer) dans un fichier exécutable unique. Chaque fonction représente une étape et, au final, chaque hôte testé devient une ligne dans recon.jsonl.

Dans cette mécanique, le listing 4.3 nous permet de définir les configurations essentielles à la reconnaissance. Nous commençons par importer des bibliothèques réseau standard, dont :

• socket pour la résolution DNS
• ssl pour l'inspection TLS
• http.client pour émettre des requêtes HTTP

Le tuple SEEDS définit les préfixes de sous-domaines courants que nous sonderons ; il inclut une chaîne vide "" pour le domaine apex, ainsi que des préfixes typiques comme www et api. Le tuple WAF_SIGS contient des fragments d'en-têtes suggérant la présence d'un WAF ou d'un CDN.

import argparse
import http.client
import socket
import ssl
from typing import Tuple, List, Dict, Optional

from artifacts import Artifact, write_jsonl

SEEDS: Tuple[str, ...] = ("", "www", "api", "dev", "staging")
WAF_SIGS: Tuple[str, ...] = (
    "cf-ray", "cloudflare", "x-sucuri-id", "akamai-", "x-akamai",
    "x-waf", "x-cdn", "x-edge", "x-amzn", "aws-alb", "fastly"
)

Avant de pouvoir sonder un domaine cible, nous devons savoir quels hôtes existent réellement. Les deux fonctions auxiliaires du listing 4.4 assurent cette étape de découverte. À partir d'un domaine racine comme example.com, la fonction candidates() génère notre liste de cibles en combinant chaque préfixe de la liste de départ avec le domaine racine. La fonction resolve() effectue les résolutions DNS en utilisant la méthode getaddrinfo() pour récupérer les adresses IPv4 et IPv6. gethostbyname_ex() capture les noms canoniques. Les deux appels sont encadrés par des blocs try/except, car des résolutions en échec sont attendues (pensez aux sous-domaines inexistants). La fonction retourne la liste des adresses IP trouvées, accompagnée de l'enregistrement CNAME — ou une liste vide et None si l'hôte ne se résout pas.

def candidates(root: str) -> List[str]:
    # ex. : ["example.com", "www.example.com", "api.example.com", ...]
    return sorted({(s + "." + root).strip(".") for s in SEEDS})


def resolve(host: str) -> Tuple[List[str], Optional[str]]:
    """Best-effort A/AAAA resolution and a primary name (not a true CNAME)."""
    try:
        infos = socket.getaddrinfo(host, 80, proto=socket.IPPROTO_TCP)
        ips = sorted({ai[4][0] for ai in infos})
    except Exception:
        ips = []
    try:
        primary, _aliases, _ips = socket.gethostbyname_ex(host)
        cname = primary
    except Exception:
        cname = None
    return ips, cname

Dans le listing 4.4, la fonction candidates() utilise une compréhension d'ensemble plutôt qu'une compréhension de liste, et ce choix est délibéré.

Maintenant que nous savons découvrir des noms d'hôtes actifs avec candidates() et resolve(), l'étape suivante consiste à apprendre quelque chose sur chacun d'eux. La fonction https_head() (listing 4.5) émet une requête HEAD légère vers le chemin racine de la cible.

Nous utilisons HEAD plutôt que GET parce que nous n'avons besoin que des en-têtes de réponse. En ne récupérant pas le corps, nous gardons une empreinte de trafic minimale. Nous retournons deux objets :

1. headers : un dictionnaire des noms d'en-têtes en minuscules associés à leurs valeurs ;
2. notes : une liste de notes qui capture le code de statut HTTP.

def https_head(host: str, timeout: int = 4, user_agent: str = "ReconSnap/1.0") -> Tuple[Dict[str, str], List[str]]:
    """Send a safe HTTPS HEAD / and return (headers, notes)."""
    headers: Dict[str, str] = {}
    notes: List[str] = []
    try:
        ctx = ssl.create_default_context()
        conn = http.client.HTTPSConnection(host, 443, context=ctx, timeout=timeout)
        conn.request("HEAD", "/", headers={"User-Agent": user_agent})
        res = conn.getresponse()
        headers = {k.lower(): v for k, v in res.getheaders()}
        notes.append(f"status:{res.status}")
    except Exception as e:
        notes.append(f"error:{type(e).__name__}")
    finally:
        try:
            conn.close()  # type: ignore[has-type]
        except Exception:
            pass
    return headers, notes

Les en-têtes que nous collectons via https_head() ne sont pas de simples métadonnées à stocker. Ils peuvent révéler ce qui se trouve entre nous et la cible. Les pare-feux applicatifs web (WAF) et les réseaux de diffusion de contenu (CDN) laissent souvent des empreintes dans les en-têtes de réponse, et savoir tôt dans un scan qu'ils sont présents change la façon dont nous abordons les étapes suivantes.

La fonction infer_waf() (listing 4.6) parcourt les en-têtes de réponse à la recherche de signatures caractéristiques de WAF et de CDN courants. Si une signature correspond, la fonction retourne True. C'est une heuristique rapide qui nous avertit tôt que notre cible filtre ou surveille peut-être le trafic.

def infer_waf(headers: Dict[str, str]) -> bool:
    """
    Lightweight header heuristic for possible WAF/CDN presence.
    Definitive profiling appears in Chapter 5.
    """
    low = {k.lower(): (v.lower() if isinstance(v, str) else "") for k, v in headers.items()}
    for k, v in low.items():
        for sig in WAF_SIGS:
            if sig in k or sig in v:
                return True
    return False

Notez que la vérification effectuée par infer_waf() est délibérément large. Une correspondance partielle de chaîne, n'importe où dans un nom ou une valeur d'en-tête, suffit à déclencher un résultat positif.

Après avoir cherché WAF et CDN, nous pouvons extraire encore davantage de renseignement de la poignée de main TLS elle-même, sans envoyer la moindre requête HTTP. Lorsqu'un serveur présente son certificat pendant la poignée de main, ce certificat contient des champs qui peuvent être une mine d'or pour la reconnaissance. La fonction tls_peek() (listing 4.7) se connecte au port 443, réalise la poignée de main TLS et en extrait deux informations précieuses :

1. Le résultat ALPN, qui révèle les protocoles pris en charge comme HTTP/2
2. La liste SAN du certificat, qui expose souvent des noms d'hôtes additionnels couverts par le certificat

L'ALPN nous indique quels protocoles de couche applicative le serveur prend en charge, ce qui peut influencer la façon dont nous forgerons les requêtes ultérieures. La liste SAN est plus intéressante encore : les organisations émettent fréquemment un certificat unique couvrant plusieurs sous-domaines ; lire les entrées SAN peut donc révéler des noms d'hôtes que notre sondage DNS aurait manqués.

def tls_peek(host: str, timeout: int = 4) -> Dict:
    """Peek ALPN and SAN without fetching content."""
    try:
        ctx = ssl.create_default_context()
        with socket.create_connection((host, 443), timeout=timeout) as sock:
            with ctx.wrap_socket(sock, server_hostname=host) as ssock:
                cert = ssock.getpeercert() or {}
                alpn = ssock.selected_alpn_protocol()
        sans = [v for (t, v) in cert.get("subjectAltName", []) if t == "DNS"]
        return {"alpn": [alpn] if alpn else [], "san": sans}
    except Exception:
        return {}

Jusqu'ici, notre reconnaissance est restée aux couches réseau et TLS : résoudre des noms d'hôtes, lire des en-têtes de réponse et inspecter des certificats. Avec la fonction robots_and_sitemap() (listing 4.8), nous montons à la couche applicative et demandons au serveur de parler de lui-même.

Presque tous les serveurs web hébergent un robots.txt et, bien que son public visé soit les robots des moteurs de recherche, il peut confirmer que le serveur sert bien du contenu et contient souvent un plan de site (sitemap). Les sitemaps sont des mines d'or : ils énumèrent les URL que le site souhaite voir indexées, ce qui nous fournit des chemins qu'il faudrait sinon deviner. La limite de lecture de 64 Ko nous évite de télécharger des fichiers anormalement volumineux.

def robots_and_sitemap(host: str, timeout: int = 4, user_agent: str = "ReconSnap/1.0") -> List[str]:
    """
    Optionally retrieve /robots.txt to note presence and capture sitemap hints.
    This is gated behind --content to keep the default run ultra-lightweight.
    """
    notes: List[str] = []
    try:
        ctx = ssl.create_default_context()
        conn = http.client.HTTPSConnection(host, 443, context=ctx, timeout=timeout)
        conn.request("GET", "/robots.txt", headers={"User-Agent": user_agent})
        res = conn.getresponse()
        robots_ok = 200 <= res.status < 400
        notes.append("robots:yes" if robots_ok else "robots:no")
        if robots_ok:
            body = res.read(65536).decode("utf-8", errors="ignore")
            for line in body.splitlines():
                if line.lower().startswith("sitemap:"):
                    notes.append("sitemap:" + line.split(":", 1)[1].strip())
    except Exception:
        notes.append("robots:error")
    finally:
        try:
            conn.close()  # type: ignore[has-type]
        except Exception:
            pass
    return notes

À ce stade, nous avons accumulé un dictionnaire d'en-têtes de réponse bruts issus de https_head(). Avant d'écrire ces en-têtes dans un rapport ou de les enregistrer avec nos résultats, nous devons faire attention à ce que nous conservons. Les en-têtes de réponse peuvent contenir des cookies de session, des jetons d'autorisation et des clés d'API. Ces éléments sont utiles à observer pendant un scan en direct, mais ils deviennent un passif dès lors qu'ils dorment dans un fichier de journal sur disque. La fonction sanitize_headers() (listing 4.9) parcourt le dictionnaire d'en-têtes et remplace les valeurs des clés sensibles (par exemple set-cookie, authorization, x-api-key) par la chaîne [redacted]. Les noms d'en-têtes sont conservés : nous savons donc toujours quels en-têtes le serveur a renvoyés, mais pas les secrets qu'ils transportaient.

def sanitize_headers(headers: Dict[str, str]) -> Dict[str, str]:
    """Remove obviously sensitive header values before persisting."""
    redacted = {}
    for k, v in headers.items():
        lk = k.lower()
        if lk.startswith("set-cookie") or lk in {"authorization", "x-api-key"}:
            redacted[k] = "[redacted]"
        else:
            redacted[k] = v
    return redacted

Nous avons construit toutes les pièces de notre boîte à outils de reconnaissance non intrusive : candidates() et resolve() découvrent les hôtes actifs, https_head() sonde les en-têtes de réponse, infer_waf() signale une éventuelle protection WAF/CDN, tls_peek() extrait des informations de certificat, robots_and_sitemap() récolte des indices de la couche applicative, et sanitize_headers() nettoie les valeurs sensibles avant enregistrement.

La fonction main() (listing 4.10) est l'orchestrateur qui relie ces pièces en un pipeline unique en ligne de commande. Elle analyse les arguments, construit la liste des hôtes candidats, puis boucle sur chaque hôte en exécutant nos fonctions de sondage. Chaque itération regroupe ses découvertes dans un objet Artifact, écrit sur disque via la fonction write_jsonl().

def main() -> None:
    p = argparse.ArgumentParser(description="Passive recon pipeline (single-file, append-only artifacts)")
    p.add_argument("root", help="Root domain, e.g., example.com")
    p.add_argument("--tls", action="store_true", help="Include TLS ALPN/SAN peek")
    p.add_argument("--content", action="store_true", help="Fetch /robots.txt to note sitemap hints")
    p.add_argument("--timeout", type=int, default=4, help="Network timeout seconds (default: 4)")
    p.add_argument("--user-agent", default="ReconSnap/1.0", help="User-Agent for requests")
    args = p.parse_args()

    # Étape 1 — planifier : générer les sous-domaines candidats
    hosts = [args.root] + candidates(args.root)

    # Étapes 2 à 4 — agir/observer/enregistrer, hôte par hôte
    for h in hosts:
        ips, cname = resolve(h)

        raw_headers, notes = https_head(h, timeout=args.timeout, user_agent=args.user_agent)
        safe_headers = sanitize_headers(raw_headers)

        hint = infer_waf(safe_headers) if safe_headers else None
        tls = tls_peek(h, timeout=args.timeout) if args.tls else None

        if args.content:
            notes += robots_and_sitemap(h, timeout=args.timeout, user_agent=args.user_agent)

        art = Artifact(
            host=h,
            a=ips,
            cname=cname,
            headers=safe_headers,
            waf_hint=hint,
            tls=tls,
            notes=notes,
        )
        write_jsonl(art)

    print("[OK] Recon pipeline complete — wrote recon.jsonl")


if __name__ == "__main__":
    main()

Les options --tls et --content sont optionnelles par conception. Elles illustrent comment des étapes peuvent être activées ou désactivées, comme des vannes sur un pipeline de données. Par défaut, le scan reste ultra-léger, mais un utilisateur souhaitant une inspection plus poussée peut y souscrire avec une option.

Avec l'orchestrateur en place, prenez du recul et remarquez ce que nous n'avons pas fait : nous n'avons jamais envoyé de charge utile, jamais sondé de vulnérabilité, jamais tenté d'authentification. Ce pipeline incarne les principes de la reconnaissance non intrusive : recueillir du renseignement par des interactions standard que n'importe quel navigateur ou robot d'indexation pourrait réaliser. Les résolutions DNS, les requêtes HEAD et les inspections de certificats déclenchent rarement des alertes car elles sont indiscernables du trafic ordinaire. Cela dit, nos paquets atteignent bien la cible : ce travail se situe donc à l'extrémité à faible impact de la reconnaissance active, plutôt que dans la catégorie réellement passive.

Cette retenue est ce qui rend le pipeline composable. Chaque fonction est sans état et produit une sortie structurée, ce qui signifie qu'un agent IA peut les invoquer comme des outils et raisonner sur les résultats. Chaque observation est capturée dans un format cohérent et lisible par la machine, que les agents peuvent interroger, filtrer et recouper pour décider quels hôtes méritent une inspection plus poussée.

C'est la fondation du travail de sécurité agentique : créer de petites fonctions composables qui observent sans modifier, et structurer des artefacts qui s'accumulent en bases de connaissances interrogeables.

4.3.4 Plongée dans les résultats de la reconnaissance passive

Exécutons maintenant ce script en invoquant la commande suivante :

python src/recon_pipeline.py example.com --tls --content

En quelques secondes, vous verrez :

[OK] Recon pipeline complete — wrote recon.jsonl

Si tout a fonctionné, un nouveau fichier nommé recon.jsonl apparaît à la racine de votre projet. Ce fichier est le battement de cœur du pipeline.

python src/recon_pipeline.py example.com
python src/recon_pipeline.py example.com --tls
python src/recon_pipeline.py example.com --content

Dans la section suivante, nous examinerons les résultats. Nous verrons comment lire les artefacts comme le récit de votre reconnaissance, et comment ces journaux constituent l'ossature du raisonnement IA dans les chapitres suivants.

4.4 Inspecter vos résultats de reconnaissance

Vous disposez maintenant d'un pipeline de reconnaissance complet et exécutable. Il est temps de le lancer, d'inspecter les artefacts qu'il crée et d'apprendre à lire l'histoire cachée dans ces lignes de JSON.

4.4.1 Consulter les résultats

Pour voir ce que le pipeline a capturé, affichez les dernières lignes avec votre outil JSON préféré :

tail -n 3 recon.jsonl | jq .

Un enregistrement typique ressemble à ceci :

{
    "schema": "recon-v1",
    "host": "api.example.com",
    "a": ["93.184.216.34"],
    "headers": {"server": "ECS (nyb/1D2D)"},
    "waf_hint": false,
    "tls": {"alpn": ["h2"], "san": ["api.example.com"]},
    "notes": ["status:200", "robots:yes"],
    "ts": "2025-10-28T14:03:11Z"
}

Plus loin dans le livre, nous alimenterons des agents IA avec exactement ces journaux pour qu'ils raisonnent dessus. Le modèle n'aura pas à deviner le contexte : il est déjà enregistré dans vos artefacts.

4.4.2 Rechercher des motifs

Avant de plonger dans des analyses plus poussées, il vaut la peine de lancer quelques requêtes rapides pour se faire une idée de ce que le scan a trouvé. Ces commandes en une ligne utilisent grep et jq, des commandes standard présentes sur tout système Linux ou macOS, pour découper les données de manière utile.

L'une des questions les plus élémentaires est : parmi tous les candidats générés, lesquels ont réellement répondu avec un code de statut de succès ?

grep "status:200" recon.jsonl | jq -r '.host'

Cela filtre les enregistrements dont le champ contient un code de statut 200 et affiche le nom d'hôte. Si la plupart des candidats ne renvoient rien, cela suggère que votre liste de départ mérite d'être élargie. En revanche, si vous obtenez des dizaines de candidats, vous disposez d'une riche surface d'attaque à cartographier.

Autre question qui nous intéresse : y a-t-il des hôtes derrière un WAF ou un CDN ? Le savoir tôt nous fait gagner du temps : un hôte derrière un WAF ou un CDN se comportera différemment pendant les tests actifs, et vous devrez peut-être ajuster votre approche.

jq -r 'select(.waf_hint==true) | .host' recon.jsonl

Cela filtre les enregistrements dont le champ waf_hint vaut True et affiche le nom d'hôte.

Enfin, nous pouvons nous intéresser aux technologies serveur utilisées par notre cible. Nous pouvons obtenir une empreinte rapide de la pile technique en extrayant l'ensemble unique des clés d'en-têtes sur l'ensemble des hôtes, ce qui révèle frameworks et infrastructures :

jq -r '.headers | keys[]' recon.jsonl | sort | uniq

Ces requêtes sont des points de départ, pas une analyse exhaustive. L'objectif est de construire une intuition : parcourir la sortie, repérer ce qui détonne, et laisser cela guider la suite de vos recherches.

4.4.3 Nettoyer et préparer la suite

Pour garder votre espace de travail rangé, vous pouvez archiver les anciennes exécutions :

mv recon.jsonl data/recon-$(date +%F).jsonl

Vous disposez maintenant d'un fichier d'artefacts durable contenant les découvertes de votre pipeline : les preuves que vous pouvez tracer, partager ou enrichir.

Dans la section suivante, vous apprendrez à interpréter cet artefact non pas comme de simples données brutes, mais comme une base de connaissances évolutive pour vos agents IA. Au chapitre 5, nous étendrons ce même processus à la reconnaissance active intrusive, couvrant l'énumération approfondie et le fingerprinting actif de WAF, et nous transformerons ces artefacts en une liste de cibles priorisée.

4.5 Lire le pipeline comme une histoire

Quand vous ouvrez votre fichier recon.jsonl, vous ne fixez pas de simples données brutes : vous lisez le récit d'une opération de reconnaissance. Chaque ligne d'artefact enregistre une scène de cette histoire : ce que le pipeline a planifié, ce qu'il a fait, ce qu'il a vu et ce qu'il en a conclu. Prises ensemble, ces lignes décrivent l'intention, le contexte et le résultat — les ingrédients mêmes qu'un analyste (ou un agent IA) utilise pour donner du sens au monde.

4.5.1 Les artefacts comme épisodes de raisonnement

Voyez chaque artefact comme un mini-épisode du processus de raisonnement du pipeline. Visualisons cette séquence à la figure 4.3 :

Chaque étape laisse des traces (adresses IP, en-têtes, codes de statut, horodatages) et, ensemble, elles forment un compte rendu complet de la découverte. Lire l'artefact chronologiquement révèle comment le système a raisonné.

4.5.2 Exemple : suivre la piste

Supposons que ces trois entrées consécutives apparaissent dans votre fichier d'artefacts :

{"host":"dev.acme.example","status":200,"notes":["robots:no"]}
{"host":"cdn.acme.example","status":200,"headers":{"server":"cloudflare"},"waf_true":true}
{"host":"staging.acme.example","status":401,"notes":["robots:yes"]}

Un analyste humain en déduit instantanément :

• Il existe un serveur de développement (dev) exposé sur Internet.
• L'hôte CDN est derrière Cloudflare (probablement une façade de production).
• L'environnement de recette (staging) exige une authentification, mais annonce tout de même un sitemap.

Notez que le champ waf_hint n'est ici qu'un indice fondé sur des motifs d'en-têtes. Il signale qu'une réponse semble filtrée par un intergiciel de protection, mais ce n'est pas une empreinte de WAF définitive.

Un agent IA peut tirer les mêmes conclusions, mais uniquement si les données sont structurées assez clairement pour qu'il puisse raisonner dessus. C'est là tout l'intérêt du format JSONL : chaque champ a un nom et un type cohérents, si bien qu'un agent IA n'a pas à deviner où finit une observation et où commence la suivante. Plus vos artefacts sont propres, plus votre agent IA est intelligent.

Les artefacts structurés n'enregistrent pas seulement ce qui s'est passé. Ils permettent de nouvelles inférences qui n'ont pas été explicitement programmées dans le pipeline. Par exemple, le pipeline que nous avons conçu ne vérifie jamais explicitement si un serveur de développement devrait être accessible publiquement. Mais si l'agent IA remarque que dev.acme.example est accessible publiquement et renvoie un 200 sans robots.txt, il peut le signaler comme un service interne mal configuré. C'est une découverte que vous voudriez investiguer, et le pipeline n'a pas eu besoin d'une règle dédiée pour la faire remonter. Le formatage structuré permet à ces intuitions et à ce raisonnement en aval d'émerger d'eux-mêmes.

Plus loin, au chapitre 5, nous répéterons ce type d'analyse par regroupement avec des empreintes TLS et actives, puis nous transformerons ces groupes en scores de triage quantitatifs. Dans la section suivante, vous prendrez du recul pour considérer sécurité, éthique et périmètre, en apprenant à appliquer aux frontières décisionnelles de vos pipelines de reconnaissance IA le même état d'esprit structuré qui régit la collecte de données.

4.6 Sécurité, périmètre et éthique

Tout pipeline de reconnaissance doit opérer à l'intérieur d'une limite claire de consentement. La différence entre reconnaissance autorisée et scan illégal n'est pas technique ; elle est éthique. Le même pipeline qui aide une équipe de sécurité à cartographier sa surface d'attaque pourrait, entre de mauvaises mains, servir à violer la vie privée ou à perturber des services. C'est pourquoi construire des systèmes de reconnaissance IA de façon responsable relève autant des règles que du code.

4.6.1 Le périmètre définit le champ de bataille

Avant de lancer un pipeline, décidez où il a le droit d'aller. Ce n'est pas qu'une question de politique ; cela fait partie de la conception du système. Vous pouvez coder en dur ou configurer votre pipeline avec un fichier scope.json ou une variable d'environnement listant les domaines, plages d'adresses IP ou zones réseau autorisés.

{
    "allowed": ["acme.example", "staging.acme.example"],
    "forbidden": ["prod.acme.example", "payments.acme.example"]
}

Dans les systèmes plus vastes, l'IA elle-même peut consulter ce fichier avant d'entreprendre la moindre action. Si une cible proposée sort de la liste autorisée, le pipeline la refuse automatiquement et enregistre la décision dans une ligne d'artefact, selon le schéma décrit ci-dessous :

{
"schema": "scope-v1",
"host": "prod.acme.example",
"action": "blocked",
"reason": "outside_scope",
"ts": "2025-10-28T12:10:00Z"
}

4.6.2 Les portes maintiennent les humains dans la boucle

Les pipelines de reconnaissance n'ont pas à s'exécuter de façon autonome. En réalité, les premiers systèmes d'IA fonctionnent mieux lorsqu'ils s'arrêtent de temps en temps pour demander la permission. Votre module gates.py précédent a déjà illustré ce concept. Chaque porte agit comme une mini-vérification éthique avant qu'une action ne quitte votre machine.

4.6.3 Manipuler et stocker les données en toute sécurité

Les artefacts de reconnaissance peuvent contenir des informations sensibles : bannières d'en-têtes, noms d'hôtes internes ou points de terminaison d'API. Traitez votre recon.jsonl comme du renseignement confidentiel.

• Stockez localement. Ne synchronisez jamais d'artefacts de reconnaissance vers des dépôts publics.
• Masquez les secrets. Si votre pipeline capture des jetons ou des identifiants de session dans les en-têtes, assainissez-les avant écriture.
• Faites expirer les données. Archivez ou supprimez les artefacts une fois l'évaluation terminée.

L'extrait de code ci-dessous illustre une méthode rapide et rudimentaire pour caviarder les en-têtes sensibles commençant par set-cookie avant l'écriture en JSONL.

# Exemple : caviarder les en-têtes sensibles avant sauvegarde
safe_headers = {k:v for k,v in headers.items() if not k.lower().startswith("set-cookie")}
write_jsonl(Artifact(host=h, headers=safe_headers))

Cet extrait est minimaliste comparé au listing 4.9, où nous avons adopté une approche plus nuancée avec sanitize_headers(). Les deux stratégies fonctionnent selon vos besoins : la suppression complète laisse un artefact plus petit, tandis que le caviardage préserve le fait que l'en-tête existait. Quelle que soit l'approche retenue, l'essentiel est que l'assainissement ait lieu avant l'appel à write_jsonl(). Une fois que des données sensibles atteignent le disque, il est bien plus difficile de les contenir.

4.6.4 Modèles d'IA et responsabilité

Les agents IA peuvent planifier et interpréter, mais ils ne peuvent pas assumer les conséquences. C'est vous, l'opérateur humain, qui restez responsable de chaque action réalisée par le système. Lorsque vous intégrez des modèles à la reconnaissance, appliquez trois principes simples :

1. L'explicabilité d'abord. Toute suggestion de l'IA doit produire un raisonnement que vous pouvez lire.
2. Moindre privilège. Ne donnez à l'IA que les informations et les permissions dont elle a besoin.
3. Auditez tout. Enregistrez comme artefacts les suggestions de l'IA acceptées et rejetées.

Dans la dernière section de ce chapitre, vous prendrez du recul et résumerez le chemin parcouru, du scripting brut aux pipelines IA auditables, en montrant comment ces fondations vous préparent au travail d'énumération intrusive et de notation du chapitre 5.

4.7 Résumé