# Lagune > Security-Driven Hardening pour toute base de code Lagune est un workflow de Security-Driven Hardening (SDH) open source et exclusivement défensif. Il aide votre agent IA à durcir n'importe quelle base de code, dans n'importe quel langage et à tout moment : la phase charter fixe les règles de sécurité avant que vous développiez, la commande universelle /lagune durcit le travail au fil de l'écriture, et le flux Blue Team en cinq phases détecte ce que fait réellement votre système et pilote les correctifs qui comptent dans ce contexte. Ses commandes s'installent dans votre agent avec la CLI skills, sans clé d'API. --- # Installation : durcissement de la sécurité pour tout agent IA > Installez Lagune dans n'importe quel projet, comme plugin si votre agent le permet ou avec la CLI skills ailleurs, puis choisissez les spécialisations de sécurité qui lui conviennent. Canonique: https://lagune.ai/fr-FR/docs Langue: fr-FR Original: https://lagune.ai/docs Dernière mise à jour: 2026-11-03 **Lagune** aide votre agent IA à rendre un projet plus sûr. Vous le pointez vers votre code, et l'agent comprend ce que fait réellement votre système, puis vous guide dans le travail de sécurité qui compte pour lui. **Lagune** est le premier projet de la méthodologie [Security-Driven Hardening (SDH)](https://lagune.ai/fr-FR/docs/references/paper). **Soutenez l'open source** Vous aimez **Lagune** ? [Donnez-nous une ⭐ sur **GitHub**](https://github.com/wellwelwel/lagune) ## Choisissez votre agent - [Claude Code](https://lagune.ai/fr-FR/docs/install/claude-code): L'outil de programmation agentique d'Anthropic - [Codex](https://lagune.ai/fr-FR/docs/install/codex): L'agent de programmation d'OpenAI - [Cursor](https://lagune.ai/fr-FR/docs/install/cursor): L'éditeur de code IA - [GitHub Copilot](https://lagune.ai/fr-FR/docs/install/github-copilot-cli): Le binôme de programmation IA de GitHub - [Gemini CLI](https://lagune.ai/fr-FR/docs/install/gemini-cli): L'agent de terminal open source de Google - [Antigravity](https://lagune.ai/fr-FR/docs/install/antigravity-cli): La plateforme de développement agentique de Google - [OpenCode](https://lagune.ai/fr-FR/docs/install/opencode): L'agent de programmation open source - [Devin for Terminal](https://lagune.ai/fr-FR/docs/install/devin-cli): L'agent de terminal de Cognition - [Factory Droid](https://lagune.ai/fr-FR/docs/install/factory-droid): L'agent de développement logiciel de Factory - [Grok Build](https://lagune.ai/fr-FR/docs/install/grok-build): L'agent de programmation de xAI - [Qwen Code](https://lagune.ai/fr-FR/docs/install/qwen-code): L'agent de programmation de Qwen pour le terminal - [Kimi Code](https://lagune.ai/fr-FR/docs/install/kimi-code): L'agent de programmation de Moonshot AI - [Muse Code](https://lagune.ai/fr-FR/docs/install/muse-code): L'agent de programmation de Meta - [Pi](https://lagune.ai/fr-FR/docs/install/pi): Un agent de programmation minimaliste pour le terminal - [Hermes Agent](https://lagune.ai/fr-FR/docs/install/hermes-agent): L'agent open source de Nous Research - [Universel](https://lagune.ai/fr-FR/docs/install/universal): Cline, Kiro CLI, Windsurf, Zed et 66 autres **Info** - **Lagune** tourne sur **Node.js** en coulisses, mais vous utilisez le langage que vous voulez. - Pour fonctionner entièrement hors ligne, installez **Lagune** dans votre projet avec `npm i -D lagune@0.16.0`. ## Catégories Les connaissances de sécurité de **Lagune** se présentent sous forme de [**spécialisations**](https://lagune.ai/fr-FR/docs/catalog), regroupées en [**catégories**](https://lagune.ai/fr-FR/docs/categories). - **OWASP** (`owasp`): Durcir contre les risques de sécurité applicative suivis par l'OWASP : injection, contrôle d'accès défaillant, authentification et défaillances cryptographiques - **Infrastructure** (`infra`): Durcir la configuration des conteneurs, des workloads et du serverless : Dockerfile, Compose, sécurité des Pods, IAM et déclencheurs FaaS - **IA / LLM** (`ai`): Durcir les intégrations d'IA et de LLM contre l'injection de prompt et le câblage risqué d'outils, d'agents, de recherche documentaire et de MCP - **Lovable** (`lovable`): Durcir les applications Supabase générées par IA (Lovable et similaires) : lacunes RLS, clés service_role divulguées et valeurs par défaut non sûres - **JavaScript** (`javascript`): Durcir JavaScript et ses runtimes contre la RCE par eval et child_process, le path traversal et la pollution de prototype - **Python** (`python`): Durcir Python contre la RCE par désérialisation pickle et YAML, le parcours via str.format et la pollution de classe - **Rust** (`rust`): Durcir Rust contre les API unsafe non sound, le mauvais usage de transmute, les dépassements d'entier et le comportement indéfini à la frontière FFI - **Java** (`java`): Durcir Java contre les chaînes de gadgets de désérialisation ObjectInputStream qui aboutissent à l'exécution de code à distance - **Ruby** (`ruby`): Durcir Ruby contre les chaînes de gadgets de désérialisation Marshal.load et YAML qui mènent à l'exécution de code à distance - **PHP** (`php`): Durcir PHP contre le contournement d'authentification par type juggling, les chaînes de gadgets d'injection d'objets et les configurations par défaut non sûres - **Go** (`go`): Durcir Go contre les bugs d'interface nil typée, les data races entre goroutines et la concurrence risquée sur les chemins de sécurité - **C / C++** (`c-cpp`): Durcir le C et le C++ contre les bugs de chaîne de format, les dépassements de tampon et les écritures hors limites qui permettent l'exécution de code - **.NET** (`dotnet`): Durcir .NET et C# contre la RCE par désérialisation BinaryFormatter et les contournements d'encodeur qui mènent au XSS Exécutez `npx lagune write add --categories` avec les clés des catégories que vous choisissez. **Astuce** Un projet commence avec `owasp`, et [`/lagune-charter`](https://lagune.ai/fr-FR/docs/commands/charter) ajoute les catégories que justifie sa lecture du projet. ## Prérequis Vous devez avoir [**Node.js (LTS)**](https://nodejs.org/en/download/package-manager) installé sur votre système. ## Affichez un badge ✨ Vous utilisez **Lagune** ? Ajoutez-en un à votre **README** : **Deux tons** ![Secured By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Secured%20By&labelColor=303952) ```md [![Secured By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Secured%20By&labelColor=303952)](https://lagune.ai) ``` ![Security Powered By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security%20Powered%20By&labelColor=303952) ```md [![Security Powered By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security%20Powered%20By&labelColor=303952)](https://lagune.ai) ``` ![Security-Driven Hardening with Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security-Driven%20Hardening&labelColor=303952) ```md [![Security-Driven Hardening with Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security-Driven%20Hardening&labelColor=303952)](https://lagune.ai) ``` **Uni** ![Secured By Lagune](https://img.shields.io/badge/Secured%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white) ```md [![Secured By Lagune](https://img.shields.io/badge/Secured%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai) ``` ![Security Powered By Lagune](https://img.shields.io/badge/Security%20Powered%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white) ```md [![Security Powered By Lagune](https://img.shields.io/badge/Security%20Powered%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai) ``` ![Security-Driven Hardening](https://img.shields.io/badge/Security--Driven%20Hardening-2f7bff?logo=springsecurity&logoColor=white) ```md [![Security-Driven Hardening](https://img.shields.io/badge/Security--Driven%20Hardening-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai) ``` ## Étape suivante Découvrez ce que fait chacun des [**Skills**](https://lagune.ai/fr-FR/docs/get-started/commands) de **Lagune**. ## Questions fréquentes ### Qu'est-ce que Lagune ? Lagune est un workflow de sécurité open source et exclusivement défensif qui aide votre agent IA à durcir n'importe quelle base de code. Vous le pointez vers votre code, il détecte ce que fait réellement votre système, puis il guide les correctifs de sécurité qui comptent dans ce contexte. ### Comment installer Lagune ? Choisissez votre agent : Claude Code, GitHub Copilot CLI, Muse Code, Antigravity CLI, Cursor, Kimi Code, OpenCode, Codex CLI, Factory Droid, Grok Build, Devin CLI et Hermes Agent installent Lagune comme plugin, Gemini CLI et Qwen Code comme extension, Pi comme paquet, et tout autre agent avec npx skills add wellwelwel/lagune. Il fonctionne aussi bien dans un nouveau projet que dans un projet existant. ### Lagune a-t-il besoin d'une clé d'API ? Non. Il passe par votre propre agent IA, donc aucune clé d'API n'est nécessaire. ### Quels sont les prérequis ? Vous devez avoir Node.js (LTS) installé sur votre système. ### Quels langages de programmation Lagune prend-il en charge ? Tous. Lagune tourne sur Node.js en coulisses, mais il audite et durcit des projets écrits dans n'importe quel langage de programmation. ### Qu'est-ce que Lagune ajoute à mon projet ? Un répertoire .lagune/ qui contient l'état de sécurité de votre projet, créé par la première commande qui écrit. La CLI skills installe aussi les commandes slash dans le projet, où votre agent les lit, alors qu'un plugin les garde dans l'agent. ### Comment mettre à jour Lagune ? De la même façon que vous l'avez installé. La page d'installation de chaque agent explique comment y mettre à jour Lagune, et la CLI skills le met à jour avec npx skills update. Vos principes de sécurité, les artefacts des phases et vos propres spécialisations restent intacts. ### Quelles spécialisations un projet utilise-t-il ? Les spécialisations intégrées de ses catégories, plus les siennes. La phase charter enregistre les catégories que justifie sa lecture du projet, et npx lagune write add --categories les modifie. ### Dois-je finir de développer avant de sécuriser mon projet ? Non. La commande /lagune durcit le travail au fil de l'écriture : elle accepte n'importe quel prompt, construit ce que vous avez demandé et le durcit avec des valeurs par défaut sûres, en suivant vos principes de sécurité. Le flux Blue Team en cinq phases audite ce qui existe déjà. ### Lagune peut-il auditer un projet existant ? Oui. Le flux Blue Team en cinq phases audite ce qui existe déjà : charter fixe vos règles de sécurité, detect cartographie ce que fait le système et où se trouvent les risques, plan note chaque constat et l'associe à un correctif, harden applique les correctifs, et verify prouve qu'ils sont efficaces et les clôture. ### Quelle différence entre utiliser Lagune et demander simplement à l'agent de cartographier les vulnérabilités et les failles de sécurité ? Un agent qui lit seul trouve ce qui ressemble à une vulnérabilité et passe sur ce qui ressemble à une mesure de protection. Une liste d'adresses bloquées donne l'impression que quelqu'un a déjà traité le risque, donc personne ne vérifie qu'elle en oublie la plupart, et le code part en production. Lagune inverse ce réflexe : une protection déjà présente dans le code est présumée non prouvée tant qu'elle n'a pas été vérifiée, chaque spécialisation du catalogue reçoit un verdict explicite, et verify se demande si le risque a disparu, pas si une mesure est en place. Chaque constat reste aussi un seul élément suivi d'une exécution à l'autre, ce qui permet de prouver sa clôture et de le retirer, là où une simple demande vous donne un rapport différent à chaque fois, sans rien à comparer. ### Quelle différence entre développer avec Lagune et demander simplement à l'agent d'écrire du code sécurisé ? Demander du code sécurisé laisse à l'agent le soin de définir ce qui est sécurisé, et suppose que vous savez quoi demander. L'exigence se trouve souvent déjà dans votre demande sans que ni vous ni lui ne la voyiez : demander une page qui affiche les cours auxquels un utilisateur a accès énonce une règle d'autorisation, et une vérification jamais écrite ne laisse rien à remarquer dans le code. La commande /lagune charge vos principes de sécurité et les spécialisations qui correspondent à ce qui va être construit avant que la première ligne soit écrite, puis relit le résultat à la lumière de la défense utilisée. La forme sûre coûte rarement plus que la forme risquée, donc ce qui décide du résultat, c'est de savoir laquelle choisir, et c'est précisément ce qui arrive en amont. ### Lagune fait-il du DAST (Dynamic Application Security Testing) ou teste-t-il mon application en cours d'exécution ? Non. Lagune lit le code et n'exécute jamais votre système ni ne lui envoie de requêtes forgées. Verify confirme qu'une mesure de protection est présente et correcte dans le code source, ce qui est une autre question que de savoir si elle résiste à une attaque sur une cible en production, donc "impossible à déterminer à partir du code" est un verdict légitime plutôt qu'une validation silencieuse. Le DAST répond à la question de l'exécution et Lagune à celle du code source, donc aucun ne remplace l'autre. Même la commande facultative prove respecte cette limite : ses tests vérifient le comportement sûr, jamais un payload d'attaque. ### Lagune remplace-t-il un pentest (test d'intrusion) ? Non, absolument pas ! Un pentest est une mission autorisée où un professionnel exerce son jugement contre votre système en production, en enchaînant les constats et en sondant la logique métier qu'aucune règle par surface ne décrit. Les constats d'un pentest peuvent entrer dans le flux Blue Team de Lagune, pour que detect consigne ces préoccupations, afin que ce qu'un professionnel signale soit planifié, durci et vérifié. ## Politique de sécurité Consultez le fichier [SECURITY.md](https://github.com/wellwelwel/lagune/blob/main/SECURITY.md). ## Licence **Lagune** est distribué sous [Apache License 2.0](https://github.com/wellwelwel/lagune/blob/main/LICENSE). Copyright © 2026-aujourd'hui [Weslley Araújo](https://github.com/wellwelwel) et [contributeurs](https://github.com/wellwelwel/lagune/graphs/contributors). --- # Installer Lagune comme plugin sur Antigravity CLI > Installez Lagune comme plugin sur Antigravity CLI, gardez-le à jour et autorisez son moteur dès le départ. Canonique: https://lagune.ai/fr-FR/docs/install/antigravity-cli Langue: fr-FR Original: https://lagune.ai/docs/install/antigravity-cli Dernière mise à jour: 2026-11-03 Installez le plugin depuis votre terminal : ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Mise à jour Pour mettre à jour **Lagune**, installez-le de nouveau : ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Commandes Tapez les commandes sous le nom du plugin, comme `/lagune:lagune-charter` pour `/lagune-charter`. --- **Autorisations** Le moteur passe par deux outils : `lagune_read` ne fait que lire votre projet, et `lagune_write` n'écrit que dans `.lagune/`. Une commande envoyée comme premier message d'une session s'exécute avant qu'ils soient chargés, et passe donc par **npx**. Pour autoriser les outils et **npx** dès le départ, ajoutez ces règles à `~/.gemini/antigravity-cli/settings.json` : ```json { "permissions": { "allow": [ "mcp(lagune_lagune/lagune_read)", "mcp(lagune_lagune/lagune_write)", "command(regex:npx --yes lagune@[0-9.]+)" ] } } ``` ## Questions fréquentes ### Comment installer Lagune sur Antigravity CLI ? Exécutez agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity. ### Comment mettre à jour Lagune sur Antigravity CLI ? Exécutez de nouveau agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity. ### Comment exécuter les commandes de Lagune sur Antigravity CLI ? Tapez-les sous le nom du plugin, comme /lagune:lagune-charter. ### Antigravity CLI peut-il exécuter Lagune sans demander d'autorisation ? Oui. Autorisez mcp(lagune_lagune/lagune_read), mcp(lagune_lagune/lagune_write) et command(regex:npx --yes lagune@[0-9.]+) dans les paramètres d'Antigravity CLI. La règle npx couvre une commande envoyée comme premier message d'une session. --- # Installer Lagune comme plugin sur Claude Code > Installez Lagune comme plugin sur Claude Code, dans le terminal, l'extension ou l'application de bureau, gardez-le à jour et autorisez son moteur dès le départ. Canonique: https://lagune.ai/fr-FR/docs/install/claude-code Langue: fr-FR Original: https://lagune.ai/docs/install/claude-code Dernière mise à jour: 2026-11-03 **Terminal** Installez le plugin depuis votre terminal : ```bash claude plugin install lagune --marketplace wellwelwel/lagune ``` Ou depuis une session **Claude Code** : ```text /plugin marketplace add wellwelwel/lagune /plugin install lagune@lagune ``` **Extension** - Tapez `/plugin` et sélectionnez **Manage plugins**. - Ajoutez `wellwelwel/lagune` dans l'onglet **Marketplaces**. - Installez `lagune` dans l'onglet **Plugins**. **Bureau** - Installez **Lagune** depuis le terminal ou l'extension, en choisissant **Install for you** dans l'extension. - Démarrez une nouvelle session dans l'application de bureau, qui charge les plugins que vous installez pour vous-même. ## Mise à jour **Terminal** Pour mettre à jour **Lagune**, exécutez : ```bash claude plugin marketplace update lagune claude plugin update lagune@lagune ``` Pour le garder à jour, sélectionnez **Enable auto-update** pour la marketplace `lagune` dans `/plugin`. **Extension** - Tapez `/plugin` et sélectionnez **Manage plugins**. - Ouvrez l'onglet **Marketplaces**. - Sélectionnez l'icône d'actualisation sur `lagune`. **Bureau** - Mettez à jour **Lagune** depuis le terminal ou l'extension. - Démarrez une nouvelle session dans l'application de bureau. ## Commandes Tapez les commandes par leur nom, comme `/lagune-charter`, ou sous le nom du plugin, comme `/lagune:lagune-charter`. --- **Autorisations** Le moteur passe par deux outils : `lagune_read` ne fait que lire votre projet, et `lagune_write` n'écrit que dans `.lagune/`. Pour les autoriser dès le départ, ajoutez ces règles à `.claude/settings.json` pour un seul projet, ou à `~/.claude/settings.json` pour tous : ```json { "permissions": { "allow": [ "mcp__plugin_lagune_lagune__lagune_read", "mcp__plugin_lagune_lagune__lagune_write" ] } } ``` Quand le moteur passe par **npx**, comme avec **skills.sh**, autorisez `Bash(npx --yes lagune@*)`. Avec le sandbox activé, ajoutez aussi `registry.npmjs.org` à `sandbox.network.allowedDomains`. ## Questions fréquentes ### Comment installer Lagune sur Claude Code ? Exécutez claude plugin install lagune --marketplace wellwelwel/lagune. Dans une session ou dans l'extension, ajoutez la marketplace wellwelwel/lagune depuis le gestionnaire de plugins et installez lagune. L'application de bureau le charge dès que vous l'installez pour vous-même dans le terminal ou l'extension. ### Comment mettre à jour Lagune sur Claude Code ? Exécutez claude plugin marketplace update lagune, puis claude plugin update lagune@lagune, ou sélectionnez Enable auto-update pour la marketplace lagune dans /plugin. Dans l'extension, ouvrez Manage plugins depuis /plugin et sélectionnez l'icône d'actualisation sur la marketplace lagune. L'application de bureau charge la mise à jour à sa prochaine session. ### Comment exécuter les commandes de Lagune sur Claude Code ? Tapez-les par leur nom, comme /lagune-charter, ou sous le nom du plugin, comme /lagune:lagune-charter. ### Claude Code peut-il exécuter Lagune sans demander d'autorisation ? Oui. Autorisez mcp__plugin_lagune_lagune__lagune_read et mcp__plugin_lagune_lagune__lagune_write dans les paramètres de Claude Code, plus Bash(npx --yes lagune@*) quand le moteur passe par npx. --- # Installer Lagune comme plugin sur Codex CLI > Installez Lagune comme plugin sur Codex CLI, gardez-le à jour et exécutez son moteur dans le sandbox. Canonique: https://lagune.ai/fr-FR/docs/install/codex Langue: fr-FR Original: https://lagune.ai/docs/install/codex Dernière mise à jour: 2026-11-03 Installez le plugin depuis votre terminal : ```bash codex plugin marketplace add wellwelwel/lagune codex plugin add lagune@lagune ``` ## Mise à jour Pour mettre à jour **Lagune**, exécutez : ```bash codex plugin marketplace upgrade lagune ``` ## Commandes Tapez `$` et la commande sous le nom du plugin, suivie de votre demande, comme `$lagune:lagune-charter` pour `/lagune-charter`. Taper `$` liste les commandes, et en choisir une insère son nom complet. --- **Autorisations** Le sandbox de **Codex** n'a pas d'accès réseau. Installez le moteur dans votre projet depuis votre propre terminal, une fois puis après chaque mise à jour : ```bash npm i -D lagune@0.16.0 ``` ## Questions fréquentes ### Comment installer Lagune sur Codex CLI ? Exécutez codex plugin marketplace add wellwelwel/lagune, puis codex plugin add lagune@lagune. ### Comment mettre à jour Lagune sur Codex CLI ? Exécutez codex plugin marketplace upgrade lagune. ### Comment exécuter les commandes de Lagune sur Codex CLI ? Tapez $ et la commande sous le nom du plugin, suivie de votre demande, comme $lagune:lagune-charter. ### Lagune fonctionne-t-il dans le sandbox de Codex ? Oui, une fois le moteur installé dans votre projet avec npm i -D lagune@0.16.0 depuis votre propre terminal, une fois puis après chaque mise à jour. --- # Installer Lagune comme plugin sur Cursor > Installez Lagune comme plugin sur Cursor et la Cursor CLI, gardez-le à jour et autorisez son moteur dès le départ. Canonique: https://lagune.ai/fr-FR/docs/install/cursor Langue: fr-FR Original: https://lagune.ai/docs/install/cursor Dernière mise à jour: 2026-11-03 **Cursor** - Ouvrez **Customize**. - Sélectionnez **From GitHub Repository** et saisissez `https://github.com/wellwelwel/lagune`. - Sélectionnez **Install** sur **Lagune** et choisissez une portée projet ou utilisateur. **Cursor CLI** - Ajoutez la marketplace depuis votre terminal : ```bash agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Tapez `/plugins` dans une session `agent`. - Installez **Lagune**. Si **Lagune** est déjà installé dans **Claude Code**, la **Cursor CLI** le charge depuis là. ## Mise à jour **Cursor** - Ouvrez **Customize**. - Sélectionnez **Refresh** sur la marketplace `lagune`. **Cursor CLI** - Remplacez la marketplace depuis votre terminal : ```bash agent plugin marketplace remove lagune agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Tapez `/plugins` dans une session `agent`. - Réinstallez **Lagune**. ## Commandes Tapez les commandes par leur nom, comme `/lagune-charter`. --- **Autorisations** Dans **Cursor**, les commandes exécutent le moteur via **npx**, ce que le mode Auto-review par défaut autorise sans demander. Dans la **Cursor CLI**, le moteur passe par deux outils : `lagune_read` ne fait que lire votre projet, et `lagune_write` n'écrit que dans `.lagune/`. Pour les autoriser dès le départ, ajoutez ces règles à `.cursor/cli.json` pour un seul projet, ou à `~/.cursor/cli-config.json` pour tous : ```json { "permissions": { "allow": [ "Mcp(plugin-lagune-lagune:lagune_read)", "Mcp(plugin-lagune-lagune:lagune_write)" ] } } ``` Quand le moteur passe par **npx**, comme avec **skills.sh**, autorisez `Shell(npx:--yes lagune@*)`. ## Questions fréquentes ### Comment installer Lagune sur Cursor ? Dans Cursor, ouvrez Customize, sélectionnez From GitHub Repository, saisissez https://github.com/wellwelwel/lagune et installez Lagune. Dans la Cursor CLI, exécutez agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor, puis installez Lagune depuis /plugins. ### Comment mettre à jour Lagune sur Cursor ? Dans Cursor, sélectionnez Refresh sur la marketplace lagune dans Customize. Dans la Cursor CLI, supprimez la marketplace lagune, ajoutez-la de nouveau, puis réinstallez Lagune depuis /plugins. ### Comment exécuter les commandes de Lagune sur Cursor ? Tapez-les par leur nom, comme /lagune-charter. ### Cursor peut-il exécuter Lagune sans demander d'autorisation ? Oui. Le mode Auto-review par défaut de Cursor l'autorise déjà. Dans la Cursor CLI, autorisez Mcp(plugin-lagune-lagune:lagune_read) et Mcp(plugin-lagune-lagune:lagune_write), plus Shell(npx:--yes lagune@*) quand le moteur passe par npx. --- # Installer Lagune comme plugin sur Devin CLI > Installez Lagune comme plugin sur Devin CLI, et gardez-le à jour. Canonique: https://lagune.ai/fr-FR/docs/install/devin-cli Langue: fr-FR Original: https://lagune.ai/docs/install/devin-cli Dernière mise à jour: 2026-11-03 Connectez-vous à **Devin**, puis installez le plugin depuis votre terminal : ```bash devin auth login devin plugins install wellwelwel/lagune ``` ## Mise à jour Pour mettre à jour **Lagune**, exécutez : ```bash devin plugins update lagune ``` ## Commandes Tapez les commandes sous le nom du plugin, comme `/lagune:lagune-charter` pour `/lagune-charter`. Le menu `/` les liste aussi. ## Questions fréquentes ### Comment installer Lagune sur Devin CLI ? Connectez-vous avec devin auth login, puis exécutez devin plugins install wellwelwel/lagune. ### Comment mettre à jour Lagune sur Devin CLI ? Exécutez devin plugins update lagune. ### Comment exécuter les commandes de Lagune sur Devin CLI ? Tapez-les sous le nom du plugin, comme /lagune:lagune-charter. Le menu / les liste aussi. --- # Installer Lagune comme plugin sur Factory Droid > Installez Lagune comme plugin sur Factory Droid, gardez-le à jour et autorisez les outils de son moteur. Canonique: https://lagune.ai/fr-FR/docs/install/factory-droid Langue: fr-FR Original: https://lagune.ai/docs/install/factory-droid Dernière mise à jour: 2026-11-03 Installez le plugin depuis votre terminal : ```bash droid plugin marketplace add wellwelwel/lagune droid plugin install lagune@lagune ``` ## Mise à jour Pour mettre à jour **Lagune**, exécutez : ```bash droid plugin marketplace update lagune droid plugin update lagune@lagune ``` ## Commandes Tapez les commandes par leur nom, comme `/lagune-charter`. --- **Autorisations** Le moteur passe par deux outils : `lagune_read` ne fait que lire votre projet, et `lagune_write` n'écrit que dans `.lagune/`. Quand **Factory Droid** le demande, choisissez de toujours autoriser chacun d'eux. Il le redemande après avoir synchronisé un nouveau commit de la marketplace `lagune`, ce qu'il peut faire au démarrage. ## Questions fréquentes ### Comment installer Lagune sur Factory Droid ? Exécutez droid plugin marketplace add wellwelwel/lagune, puis droid plugin install lagune@lagune. ### Comment mettre à jour Lagune sur Factory Droid ? Exécutez droid plugin marketplace update lagune, puis droid plugin update lagune@lagune. ### Comment exécuter les commandes de Lagune sur Factory Droid ? Tapez-les par leur nom, comme /lagune-charter. ### Factory Droid peut-il exécuter Lagune sans demander d'autorisation ? Oui. Choisissez de toujours autoriser lagune_read et lagune_write quand Factory Droid le demande. Il le redemande après avoir synchronisé un nouveau commit de la marketplace lagune. --- # Installer Lagune comme extension sur Gemini CLI > Installez Lagune comme extension sur Gemini CLI, gardez-le à jour et autorisez son moteur dès le départ. Canonique: https://lagune.ai/fr-FR/docs/install/gemini-cli Langue: fr-FR Original: https://lagune.ai/docs/install/gemini-cli Dernière mise à jour: 2026-11-03 Installez l'extension depuis votre terminal : ```bash gemini extensions install https://github.com/wellwelwel/lagune ``` ## Mise à jour Pour mettre à jour **Lagune**, exécutez : ```bash gemini extensions update lagune ``` Pour le garder à jour, installez-le avec `--auto-update`. ## Commandes Tapez les commandes sous le nom de l'extension, comme `/lagune:lagune-charter` pour `/lagune-charter`. --- **Autorisations** Le moteur passe par deux outils : `lagune_read` ne fait que lire votre projet, et `lagune_write` n'écrit que dans `.lagune/`. **Gemini CLI** ne les démarre que dans un dossier de confiance. Pour les autoriser dès le départ, enregistrez cette règle dans `~/.gemini/policies/lagune.toml` : ```toml [[rule]] mcpName = "lagune" toolName = ["lagune_read", "lagune_write"] decision = "allow" priority = 100 ``` Quand le moteur passe par **npx**, comme avec **skills.sh**, ajoutez cette règle au même fichier : ```toml [[rule]] toolName = "run_shell_command" commandRegex = 'npx --yes lagune@\d+\.\d+\.\d+\s' decision = "allow" priority = 100 ``` ## Questions fréquentes ### Comment installer Lagune sur Gemini CLI ? Exécutez gemini extensions install https://github.com/wellwelwel/lagune. ### Comment mettre à jour Lagune sur Gemini CLI ? Exécutez gemini extensions update lagune, ou installez l'extension avec --auto-update. ### Comment exécuter les commandes de Lagune sur Gemini CLI ? Tapez-les sous le nom de l'extension, comme /lagune:lagune-charter. ### Gemini CLI peut-il exécuter Lagune sans demander d'autorisation ? Oui. Ajoutez une règle de politique qui autorise les outils lagune_read et lagune_write du serveur lagune, plus une pour run_shell_command avec npx --yes lagune@ et une version quand le moteur passe par npx. --- # Installer Lagune comme plugin sur GitHub Copilot CLI > Installez Lagune comme plugin sur GitHub Copilot CLI, et gardez-le à jour. Canonique: https://lagune.ai/fr-FR/docs/install/github-copilot-cli Langue: fr-FR Original: https://lagune.ai/docs/install/github-copilot-cli Dernière mise à jour: 2026-11-03 Installez le plugin depuis votre terminal : ```bash copilot plugin marketplace add wellwelwel/lagune copilot plugin install lagune@lagune ``` Dans un éditeur, installez **Lagune** pour **GitHub Copilot** avec [**skills.sh**](https://lagune.ai/fr-FR/docs/install/universal). ## Mise à jour Pour mettre à jour **Lagune**, exécutez : ```bash copilot plugin marketplace update lagune copilot plugin update lagune@lagune ``` ## Commandes Tapez les commandes par leur nom, comme `/lagune-charter`. ## Questions fréquentes ### Comment installer Lagune sur GitHub Copilot CLI ? Exécutez copilot plugin marketplace add wellwelwel/lagune, puis copilot plugin install lagune@lagune. ### Comment mettre à jour Lagune sur GitHub Copilot CLI ? Exécutez copilot plugin marketplace update lagune, puis copilot plugin update lagune@lagune. ### Comment exécuter les commandes de Lagune sur GitHub Copilot CLI ? Tapez-les par leur nom, comme /lagune-charter. ### Puis-je utiliser Lagune avec GitHub Copilot dans VS Code ? Oui. Dans VS Code ou un autre éditeur, installez Lagune avec skills.sh plutôt qu'avec le plugin. --- # Installer Lagune comme plugin sur Grok Build > Installez Lagune comme plugin sur Grok Build, gardez-le à jour et autorisez son moteur dès le départ. Canonique: https://lagune.ai/fr-FR/docs/install/grok-build Langue: fr-FR Original: https://lagune.ai/docs/install/grok-build Dernière mise à jour: 2026-11-03 Installez le plugin depuis votre terminal : ```bash grok plugin install wellwelwel/lagune@plugin-grok --trust ``` ## Mise à jour Pour mettre à jour **Lagune**, exécutez : ```bash grok plugin update lagune ``` ## Commandes Tapez les commandes par leur nom, comme `/lagune-charter`, ou sous le nom du plugin, comme `/lagune:lagune-charter`. --- **Autorisations** Le moteur passe par deux outils : `lagune_read` ne fait que lire votre projet, et `lagune_write` n'écrit que dans `.lagune/`. Pour les autoriser dès le départ, ajoutez ces règles à `~/.grok/config.toml` : ```toml [permission] allow = ["MCPTool(lagune__lagune_read)", "MCPTool(lagune__lagune_write)"] ``` Quand le moteur passe par **npx**, comme avec **skills.sh**, autorisez `Bash(npx --yes lagune@*)`. ## Questions fréquentes ### Comment installer Lagune sur Grok Build ? Exécutez grok plugin install wellwelwel/lagune@plugin-grok --trust. ### Comment mettre à jour Lagune sur Grok Build ? Exécutez grok plugin update lagune. ### Comment exécuter les commandes de Lagune sur Grok Build ? Tapez-les par leur nom, comme /lagune-charter, ou sous le nom du plugin, comme /lagune:lagune-charter. ### Grok Build peut-il exécuter Lagune sans demander d'autorisation ? Oui. Autorisez MCPTool(lagune__lagune_read) et MCPTool(lagune__lagune_write) dans la configuration de Grok Build, plus Bash(npx --yes lagune@*) quand le moteur passe par npx. --- # Installer Lagune comme plugin sur Hermes Agent > Installez Lagune comme plugin sur Hermes Agent, et gardez-le à jour. Canonique: https://lagune.ai/fr-FR/docs/install/hermes-agent Langue: fr-FR Original: https://lagune.ai/docs/install/hermes-agent Dernière mise à jour: 2026-11-03 Installez le plugin depuis votre terminal : ```bash hermes plugins install wellwelwel/lagune --enable ``` - Quand **Hermes Agent** vous demande de confirmer un plugin extérieur à son catalogue, **confirmez-le**. - Quand il propose d'installer les dépendances **Node.js** du dépôt, **refusez**. ## Mise à jour Pour mettre à jour **Lagune**, exécutez : ```bash hermes plugins update lagune ``` ## Commandes Tapez les commandes sous le nom du plugin, comme `/lagune:lagune-charter` pour `/lagune-charter` et `/lagune:lagune` pour `/lagune`. ## Questions fréquentes ### Comment installer Lagune sur Hermes Agent ? Exécutez hermes plugins install wellwelwel/lagune --enable. Confirmez le plugin quand il vous le demande, et refusez d'installer les dépendances Node.js du dépôt. ### Comment mettre à jour Lagune sur Hermes Agent ? Exécutez hermes plugins update lagune. ### Comment exécuter les commandes de Lagune sur Hermes Agent ? Tapez-les sous le nom du plugin, comme /lagune:lagune-charter et /lagune:lagune. --- # Installer Lagune comme plugin sur Kimi Code > Installez Lagune comme plugin sur Kimi Code, et gardez-le à jour. Canonique: https://lagune.ai/fr-FR/docs/install/kimi-code Langue: fr-FR Original: https://lagune.ai/docs/install/kimi-code Dernière mise à jour: 2026-11-03 Installez le plugin depuis une session **Kimi Code**, choisissez **Trust and install**, puis démarrez une nouvelle session pour le charger : ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Mise à jour Pour mettre à jour **Lagune**, installez-le de nouveau : ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Commandes Tapez les commandes sous le nom du plugin, comme `/lagune:lagune-charter` pour `/lagune-charter`. Le menu `/` les liste sous la forme `/skill:lagune:lagune-charter`, qui fonctionne aussi. ## Questions fréquentes ### Comment installer Lagune sur Kimi Code ? Dans une session Kimi Code, exécutez /plugins install https://github.com/wellwelwel/lagune, choisissez Trust and install, puis exécutez /new. ### Comment mettre à jour Lagune sur Kimi Code ? Exécutez de nouveau /plugins install https://github.com/wellwelwel/lagune, puis /new. ### Comment exécuter les commandes de Lagune sur Kimi Code ? Tapez-les sous le nom du plugin, comme /lagune:lagune-charter, ou comme les liste le menu /, comme /skill:lagune:lagune-charter. --- # Installer Lagune comme plugin sur Muse Code > Installez Lagune comme plugin sur Muse Code, gardez-le à jour et exécutez son moteur dans le sandbox. Canonique: https://lagune.ai/fr-FR/docs/install/muse-code Langue: fr-FR Original: https://lagune.ai/docs/install/muse-code Dernière mise à jour: 2026-11-03 Installez le plugin depuis votre terminal : ```bash muse plugins marketplace add lagune wellwelwel/lagune muse plugins install lagune@lagune ``` ## Mise à jour Pour mettre à jour **Lagune**, actualisez la marketplace et réinstallez le plugin : ```bash muse plugins marketplace update lagune muse plugins remove lagune muse plugins install lagune@lagune ``` ## Commandes Tapez les commandes par leur nom, comme `/lagune-charter`, ou sous le nom du plugin, comme `/lagune:lagune-charter`. --- **Autorisations** Le sandbox de **Muse Code** ne peut pas télécharger le moteur. Installez-le dans votre projet depuis votre propre terminal, une fois puis après chaque mise à jour : ```bash npm i -D lagune@0.16.0 ``` ## Questions fréquentes ### Comment installer Lagune sur Muse Code ? Exécutez muse plugins marketplace add lagune wellwelwel/lagune, puis muse plugins install lagune@lagune. ### Comment mettre à jour Lagune sur Muse Code ? Exécutez muse plugins marketplace update lagune, puis réinstallez avec muse plugins remove lagune et muse plugins install lagune@lagune. ### Comment exécuter les commandes de Lagune sur Muse Code ? Tapez-les par leur nom, comme /lagune-charter, ou sous le nom du plugin, comme /lagune:lagune-charter. ### Lagune fonctionne-t-il dans le sandbox de Muse Code ? Oui, une fois le moteur installé dans votre projet avec npm i -D lagune@0.16.0 depuis votre propre terminal, une fois puis après chaque mise à jour. --- # Installer Lagune comme plugin sur OpenCode > Installez Lagune comme plugin sur OpenCode 1.x et 2.x, et gardez-le à jour. Canonique: https://lagune.ai/fr-FR/docs/install/opencode Langue: fr-FR Original: https://lagune.ai/docs/install/opencode Dernière mise à jour: 2026-11-03 **OpenCode 2.x** Installez le plugin depuis votre terminal : ```bash opencode plugin add lagune ``` Ou ajoutez-le à la liste `plugins` de `opencode.json` : ```json { "plugins": ["lagune"] } ``` **OpenCode 1.x** Installez le plugin dans votre projet depuis votre terminal, ou ajoutez `-g` pour l'installer dans tous vos projets : ```bash opencode plugin lagune ``` Ou ajoutez-le à la liste `plugin` de `opencode.json` : ```json { "plugin": ["lagune"] } ``` ## Mise à jour **OpenCode 2.x** Pour mettre à jour **Lagune**, exécutez : ```bash opencode plugin update lagune opencode reload ``` **OpenCode 1.x** Pour mettre à jour **Lagune**, installez la nouvelle version par-dessus l'ancienne, en ajoutant `-g` si vous l'avez installé pour tous vos projets : ```bash opencode plugin lagune@0.16.0 --force ``` ## Commandes **OpenCode 2.x** Tapez `@` et choisissez la commande, comme `@lagune-charter`, puis écrivez votre demande dans le même message. **OpenCode 1.x** Tapez les commandes par leur nom, comme `/lagune-charter`. Elles sont listées sous `/skills`, pas dans le menu `/`. --- **Autorisations** Le moteur passe par deux outils : `lagune_read` ne fait que lire votre projet, et `lagune_write` n'écrit que dans `.lagune/`. **OpenCode** les exécute sans demander. ## Questions fréquentes ### Comment installer Lagune sur OpenCode ? Sur OpenCode 2.x, exécutez opencode plugin add lagune. Sur OpenCode 1.x, exécutez opencode plugin lagune, en ajoutant -g pour l'installer dans tous vos projets. ### Comment mettre à jour Lagune sur OpenCode ? Sur OpenCode 2.x, exécutez opencode plugin update lagune, puis opencode reload. Sur OpenCode 1.x, exécutez opencode plugin lagune@0.16.0 --force. ### Comment exécuter les commandes de Lagune sur OpenCode ? Sur OpenCode 2.x, tapez @ et choisissez la commande, comme @lagune-charter, puis écrivez votre demande dans le même message. Sur OpenCode 1.x, tapez-les par leur nom, comme /lagune-charter, ou trouvez-les sous /skills. ### OpenCode demande-t-il l'autorisation avant d'exécuter Lagune ? Non. OpenCode exécute les deux outils du moteur, lagune_read et lagune_write, sans demander. --- # Installer Lagune comme paquet sur Pi > Installez Lagune comme paquet sur Pi, depuis npm ou depuis GitHub, et gardez-le à jour. Canonique: https://lagune.ai/fr-FR/docs/install/pi Langue: fr-FR Original: https://lagune.ai/docs/install/pi Dernière mise à jour: 2026-11-03 **npm** Installez le paquet depuis votre terminal : ```bash pi install npm:lagune ``` **GitHub** Installez le dernier commit depuis **GitHub**, qui exécute le moteur via **npx** : ```bash pi install git:github.com/wellwelwel/lagune ``` ## Mise à jour **npm** Pour mettre à jour **Lagune**, exécutez : ```bash pi update npm:lagune ``` **GitHub** Pour mettre à jour **Lagune**, exécutez : ```bash pi update git:github.com/wellwelwel/lagune ``` `pi update --extensions` met à jour tous les paquets que vous avez installés, alors que `pi update` seul ne met à jour que **Pi**. ## Commandes Tapez les commandes avec le préfixe `skill:`, comme `/skill:lagune-charter` pour `/lagune-charter`. ## Questions fréquentes ### Comment installer Lagune sur Pi ? Exécutez pi install npm:lagune, ou pi install git:github.com/wellwelwel/lagune pour le dernier commit depuis GitHub. ### Comment mettre à jour Lagune sur Pi ? Exécutez pi update npm:lagune, ou pi update git:github.com/wellwelwel/lagune pour une installation depuis GitHub. pi update --extensions met à jour tous les paquets que vous avez installés. ### Comment exécuter les commandes de Lagune sur Pi ? Tapez-les avec le préfixe skill:, comme /skill:lagune-charter. --- # Installer Lagune comme extension sur Qwen Code > Installez Lagune comme extension sur Qwen Code, gardez-le à jour et autorisez son moteur dès le départ. Canonique: https://lagune.ai/fr-FR/docs/install/qwen-code Langue: fr-FR Original: https://lagune.ai/docs/install/qwen-code Dernière mise à jour: 2026-11-03 Installez l'extension depuis votre terminal : ```bash qwen extensions install lagune ``` ## Mise à jour Pour mettre à jour **Lagune**, exécutez : ```bash qwen extensions update lagune ``` Pour le garder à jour, installez-le avec `--auto-update`. ## Commandes Tapez les commandes sous le nom de l'extension, comme `/lagune:lagune-charter` pour `/lagune-charter`. --- **Autorisations** Le moteur passe par deux outils : `lagune_read` ne fait que lire votre projet, et `lagune_write` n'écrit que dans `.lagune/`. Pour les autoriser dès le départ, ajoutez ces règles à `.qwen/settings.json` pour un seul projet, ou à `~/.qwen/settings.json` pour tous : ```json { "permissions": { "allow": ["mcp__lagune__lagune_read", "mcp__lagune__lagune_write"] } } ``` Quand le moteur passe par **npx**, comme avec **skills.sh**, autorisez `Shell(npx --yes lagune@*)`. ## Questions fréquentes ### Comment installer Lagune sur Qwen Code ? Exécutez qwen extensions install lagune. ### Comment mettre à jour Lagune sur Qwen Code ? Exécutez qwen extensions update lagune, ou installez l'extension avec --auto-update. ### Comment exécuter les commandes de Lagune sur Qwen Code ? Tapez-les sous le nom de l'extension, comme /lagune:lagune-charter. ### Qwen Code peut-il exécuter Lagune sans demander d'autorisation ? Oui. Autorisez mcp__lagune__lagune_read et mcp__lagune__lagune_write dans les paramètres de Qwen Code, plus Shell(npx --yes lagune@*) quand le moteur passe par npx. --- # Installer Lagune dans tout agent avec skills.sh > Installez Lagune dans n'importe quel agent IA avec la CLI skills, et gardez-le à jour. Canonique: https://lagune.ai/fr-FR/docs/install/universal Langue: fr-FR Original: https://lagune.ai/docs/install/universal Dernière mise à jour: 2026-11-03 **Terminal** Installez les commandes de **Lagune** depuis votre terminal avec [**skills.sh**](https://www.skills.sh/wellwelwel/lagune) : ```bash npx skills add wellwelwel/lagune ``` **Prompt** Collez ce prompt dans votre agent : ```md Exécute `npx --yes skills add wellwelwel/lagune` et suis dès maintenant les instructions du skill généré. Lis toute la sortie, en la redirigeant d'abord vers un fichier temporaire si nécessaire. Résous les chemins relatifs à partir du répertoire de fichiers annexes qu'elle indique. ``` ## Mise à jour **Terminal** Pour mettre à jour **Lagune**, exécutez : ```bash npx skills update ``` **Prompt** Pour mettre à jour **Lagune**, collez ce prompt dans votre agent : ```md Exécute `npx --yes skills update -y` et lis toute la sortie, en la redirigeant d'abord vers un fichier temporaire si nécessaire. ``` --- **Une seule voie par agent** Installez **Lagune** avec **skills.sh** ou avec son **plugin**, jamais les deux. **Autorisations** Les commandes exécutent le moteur sous la forme `npx --yes lagune@0.16.0`, et la [page d'installation de chaque agent](https://lagune.ai/fr-FR/docs) indique la règle qui l'autorise dès le départ. Dans un sandbox sans accès réseau, installez le moteur dans votre projet depuis votre propre terminal, une fois puis après chaque mise à jour : ```bash npm i -D lagune@0.16.0 ``` ## Questions fréquentes ### Comment installer Lagune dans n'importe quel agent IA ? Exécutez npx skills add wellwelwel/lagune dans votre projet, ou collez le prompt d'installation dans votre agent. ### Comment mettre à jour Lagune installé avec la CLI skills ? Exécutez npx skills update, ou collez le prompt de mise à jour dans votre agent. ### Puis-je installer Lagune à la fois avec la CLI skills et avec un plugin ? Non. Avec les deux, l'agent liste chaque commande deux fois, ou utilise une copie et masque l'autre. --- # Skills de sécurité pour agents IA > Les skills que votre agent IA débloque avec Lagune : auditer un projet existant ou sécuriser le nouveau travail pendant que vous développez, le tout encadré par les principes de sécurité. Canonique: https://lagune.ai/fr-FR/docs/get-started/commands Langue: fr-FR Original: https://lagune.ai/docs/get-started/commands Dernière mise à jour: 2026-11-03 Une fois **Lagune** [installé](https://lagune.ai/fr-FR/docs), votre agent **IA** débloque un ensemble de skills. Il y a deux façons de les utiliser, toutes deux encadrées par la **charter** : sécuriser le nouveau travail pendant que vous le construisez, ou lancer l'audit complet d'un projet. **⌨️ Construction / développement** Inutile de finir votre travail avant de le sécuriser. Utilisez [**`/lagune`**](https://lagune.ai/fr-FR/docs/commands/lagune) pour le travail que vous écrivez **en ce moment** : | Skill | Ce qu'il fait pour vous | | --------------------------------------------- | ------------------------------------------------------------------------------------------ | | [**/lagune-charter**](https://lagune.ai/fr-FR/docs/commands/charter) | Fixe les règles de sécurité de votre projet, la base sur laquelle `/lagune` construit | | [**/lagune**](https://lagune.ai/fr-FR/docs/commands/lagune) | Construit ce que vous demandez et le durcit au fil de l'écriture, en suivant vos principes | **Utilisez-le à tout moment** [**`/lagune`**](https://lagune.ai/fr-FR/docs/commands/lagune) respecte vos principes de sécurité à chaque exécution. Il accepte n'importe quel prompt, construit ce que vous avez demandé et le durcit avec des valeurs par défaut sûres au fur et à mesure, pas plus tard. --- #### Skills spéciaux | Skill | Ce qu'il fait | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/fr-FR/docs/commands/specialize) | Enseigne à **Lagune** une nouvelle spécialisation de sécurité à partir d'articles, d'exploits ou de sujets | **🔬 Audit : flux Blue Team** Le **flux Blue Team** complet : comprendre ce que fait un projet, cartographier ses risques et les clôturer. Chaque phase s'appuie sur la précédente, il suffit donc de suivre la liste de haut en bas : | # | Skill | Ce qu'il fait pour vous | | --- | --------------------------------------------- | --------------------------------------------------------------------------------------------------- | | 1 | [**/lagune-charter**](https://lagune.ai/fr-FR/docs/commands/charter) | Fixe les règles de sécurité de votre projet, proposées pour vous ou façonnées par ce que vous dites | | 2 | [**/lagune-detect**](https://lagune.ai/fr-FR/docs/commands/detect) | Lit votre code et cartographie ce que fait votre système et où se trouvent les risques | | 3 | [**/lagune-plan**](https://lagune.ai/fr-FR/docs/commands/plan) | Transforme ce que detect a trouvé en plan de défense, avec un correctif pour chaque constat | | 4 | [**/lagune-harden**](https://lagune.ai/fr-FR/docs/commands/harden) | Applique à votre code les correctifs du plan, en toute sécurité et un par un | | 5 | [**/lagune-verify**](https://lagune.ai/fr-FR/docs/commands/verify) | Prouve que chaque correctif appliqué est efficace et clôture ceux qui passent la preuve | --- #### Skills spéciaux | Skill | Ce qu'il fait | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | [**/lagune-specialize**](https://lagune.ai/fr-FR/docs/commands/specialize) | Enseigne à **Lagune** une nouvelle spécialisation de sécurité à partir d'articles, d'exploits ou de sujets | | [**/lagune-prove**](https://lagune.ai/fr-FR/docs/commands/prove) | Transforme chaque constat détecté en preuve exécutable et exclusivement défensive, pour la divulgation responsable | --- #### Skills internes | Skill | Ce qu'il fait | | ------------------------------------------- | ------------------------------------- | | [**/lagune-repair**](https://lagune.ai/fr-FR/docs/commands/repair) | Répare le suivi interne de **Lagune** | **Astuce** La sécurité n'est pas un coût, c'est un investissement : ce que vous y mettez en amont, vous l'économisez bien des fois en incidents que vous n'aurez jamais 🙋🏻‍♂️ ## Questions fréquentes ### Quels skills Lagune ajoute-t-il ? /lagune pour durcir le travail pendant que vous le construisez, et le flux d'audit Blue Team en cinq phases : /lagune-charter, /lagune-detect, /lagune-plan, /lagune-harden, /lagune-verify. Plus /lagune-specialize et /lagune-prove. ### Qu'est-ce que le flux Blue Team de Lagune ? Un audit en cinq phases : charter (fixer les règles), detect (cartographier les risques), plan (noter les constats et planifier les correctifs), harden (appliquer les correctifs), verify (prouver qu'ils sont efficaces et les clôturer). ### Quelle différence entre /lagune et le flux d'audit ? /lagune sécurise le nouveau travail pendant que vous l'écrivez, sans flux à suivre. Le flux d'audit exécute les cinq phases dans l'ordre sur un projet existant. --- # Tableau de bord > Consultez les principes de sécurité, les constats et le catalogue de votre projet dans une vue locale en direct, qui s'ouvre avec une seule commande. Canonique: https://lagune.ai/fr-FR/docs/get-started/dashboard Langue: fr-FR Original: https://lagune.ai/docs/get-started/dashboard Dernière mise à jour: 2026-11-03 Exécutez **Lagune** directement, sans sous-commande, pour obtenir une vue interactive et en direct de `.lagune/`. Il sert un tableau de bord et l'ouvre sur un port aléatoire : ```bash npx lagune ``` - [x] **Live Reload** - [x] **Privé** et **local** - [x] Affiche tout ce que contient `.lagune/`, dès les premiers principes de sécurité - [x] **Gérez** les catégories du projet directement depuis votre navigateur - [x] Aucun `node_modules` ni `package.json` n'est nécessaire 📦 ![Principes de sécurité dans le tableau de bord de Lagune](https://lagune.ai/img/dashboard/02.webp) ![Constats dans le tableau de bord de Lagune](https://lagune.ai/img/dashboard/03.webp) ![Quêtes annexes dans le tableau de bord de Lagune](https://lagune.ai/img/dashboard/04.webp) ![Détail d](https://lagune.ai/img/dashboard/05.webp) ![Catalogue dans le tableau de bord de Lagune](https://lagune.ai/img/dashboard/06.webp) **Astuce** - 🚪 Utilisez `--port` pour choisir un port précis. - ⏏️ Appuyez sur `Ctrl+C` pour l'arrêter. ## Questions fréquentes ### Comment ouvrir le tableau de bord de Lagune ? Exécutez npx lagune sans sous-commande à la racine de votre projet. Il sert une vue en direct de .lagune/ sur un port aléatoire et l'ouvre dans votre navigateur. ### Le tableau de bord est-il privé ? Oui. Il tourne uniquement sur votre propre machine, à une adresse locale qu'aucun autre ordinateur ne peut atteindre. ### Puis-je modifier mon projet depuis le tableau de bord ? Seulement ses catégories, depuis votre navigateur. Tout le reste de ce qu'affiche le tableau de bord est en lecture seule. --- # /lagune: sécuriser le code pendant que votre IA l'écrit > Construisez ce que vous demandez et durcissez-le au fil de l'écriture, en suivant vos principes de sécurité, sans flux à suivre. Canonique: https://lagune.ai/fr-FR/docs/commands/lagune Langue: fr-FR Original: https://lagune.ai/docs/commands/lagune Dernière mise à jour: 2026-11-03 ⌨️ Faites le travail demandé, sécurisé au fil de l'écriture. **`/lagune`** accepte n'importe quel prompt, à n'importe quelle étape, construit ce que vous vouliez et le durcit avec des valeurs par défaut sûres avant de vous le rendre. ## Utilisation Ajoutez **`/lagune`** à n'importe quel prompt, et décrivez le travail comme vous le feriez d'habitude. **📘 Instructions de l** ```md # Les instructions de mon projet pour les agents ## Sécurité - Utilise le skill `/lagune` chaque fois que tu construis ou modifies du code, pour renforcer la sécurité par défaut. ``` - Par exemple : **AGENTS.md**, **CLAUDE.md**, **.github/copilot-instructions.md**, **.cursorrules**, etc. **💬 Une fonctionnalité** ```prompt /lagune permets aux utilisateurs d'envoyer une photo personnalisée sur leur profil. ``` **💬 Une correction** ```prompt /lagune il ne se passe rien quand l'utilisateur envoie le formulaire. Cherche d'où ça peut venir et corrige-le. ``` **💬 Une refactorisation** ```prompt /lagune découple et améliore la logique du payload ``` **Charter facultative, mais mieux avec** **`/lagune`** fonctionne avec ou sans principes de sécurité. S'ils existent, les règles propres à votre projet façonnent chaque construction. Définissez-les une fois pour toutes avec [`/lagune-charter`](https://lagune.ai/fr-FR/docs/commands/charter). ## Fonctionnement Il enveloppe le travail en trois temps, sans rien écrire dans Lagune : 1. Il charge vos principes de sécurité, s'ils existent, et ceux-ci gouvernent toute la construction. Sinon, il s'appuie sur une base sûre par défaut. 2. Il liste le [catalogue](https://lagune.ai/fr-FR/docs/catalog) de votre projet et ne charge que les spécialisations que touche votre travail, les mêmes connaissances à la demande que celles du flux d'audit. 3. Il applique la défense pendant l'écriture du code, puis relit son propre résultat pour confirmer que les mesures de protection sont réellement efficaces avant de vous rendre le travail. Le résultat, c'est du code fonctionnel dans votre projet, sûr dès la première ligne. **Utilisez-le à tout moment** Pas de detect, pas de plan, pas de nettoyage après coup. **`/lagune`** convient aussi bien à un projet tout juste créé qu'à une modification sur une base de code mature, et il durcit le travail au fur et à mesure, pas plus tard. ## Ce qu'il ne fait pas - Il n'écrit rien dans le répertoire `.lagune`, ni artefact ni suivi : la seule chose qu'il produit, c'est le code durci que vous avez demandé. - Il n'affaiblit jamais une règle pour satisfaire un prompt : si votre demande enfreint un de vos principes de sécurité, il s'arrête et vous prévient d'abord, au lieu de la construire directement de façon risquée. ## Questions fréquentes ### Que fait /lagune ? Il accepte n'importe quel prompt, à n'importe quelle étape, construit ce que vous avez demandé et le durcit avec des valeurs par défaut sûres avant de vous le rendre. La défense est appliquée pendant l'écriture du code, pas plus tard. ### Ai-je besoin de principes de sécurité pour utiliser /lagune ? Non. Il fonctionne avec ou sans. Avec des principes de sécurité, les règles propres à votre projet façonnent chaque construction. Sans eux, il s'appuie sur une base sûre par défaut. ### Quelle différence entre /lagune et le flux Blue Team ? /lagune sécurise le nouveau travail pendant que vous l'écrivez, sans flux à suivre. Le flux Blue Team exécute les cinq phases d'audit dans l'ordre sur un projet existant. ### /lagune suit-il les constats ou écrit-il des artefacts ? Non. Il n'écrit rien dans le répertoire .lagune, ni artefact ni suivi. La seule chose qu'il produit, c'est le code durci que vous avez demandé. ### Comment faire en sorte que mon agent utilise /lagune automatiquement ? Ajoutez au fichier d'instructions de votre agent (AGENTS.md, CLAUDE.md, .cursorrules, etc.) une instruction lui demandant d'utiliser le skill /lagune chaque fois qu'il construit ou modifie du code. --- # /lagune-charter: définir vos principes de sécurité > Établissez les principes de sécurité de votre projet, les règles que respecte chaque phase suivante, et enregistrez les catégories de spécialisations que justifie sa lecture. Canonique: https://lagune.ai/fr-FR/docs/commands/charter Langue: fr-FR Original: https://lagune.ai/docs/commands/charter Dernière mise à jour: 2026-11-03 🧬 Dites à **Lagune** ce qu'est votre projet, et il le transforme en règles de sécurité (ou, sans description, il les déduit du projet seul). La charter est la couche de gouvernance : un ensemble de principes axés sur la sécurité que chaque phase suivante doit respecter. Voyez-la comme la vérification à la compilation de la posture de sécurité de votre projet. ## Utilisation **Décrire le projet** ```prompt /lagune-charter Mon projet est une boutique en ligne qui vend des jeux vidéo. Les clients ajoutent des produits à un panier et paient par carte bancaire ou par boleto. Ils peuvent voir leurs commandes et le statut de chacune. ``` **Laisser Lagune proposer** ```prompt /lagune-charter ``` > _Je vois une bibliothèque de paiement, un système de connexion et un modèle de commande lié à un client. On dirait une boutique en ligne qui vend quelque chose. Les clients paient et suivent leurs propres commandes..._ ☁️ ## Ce qu'il en déduit **Lagune** prend votre description ou votre **PRD** comme direction et en déduit les implications pour la sécurité, puis lit le projet pour aller plus loin que ce que vous avez nommé. Par exemple : - Un panier qui contient des commandes implique une **base de données** : - ex. `"Où se trouvent les données ?"`, `"Qui peut y accéder ?"`, `"Est-ce qu'elles fuient ?"`. - Des clients qui voient leurs propres commandes impliquent une forme de **connexion ou de contrôle d'accès** : - ex. `"Un client peut-il accéder aux commandes d'un autre ?"`, `"Les sessions sont-elles protégées ?"`. - Accepter les paiements par carte et par boleto implique **de l'argent et des données sensibles** : - ex. `"Les données de carte sont-elles stockées ?"`, `"Les paiements sont-ils vérifiés ?"`. Votre description et le projet se complètent : votre description fixe l'intention, et la lecture des dépendances, du README et de la configuration fait ressortir ce que vous n'avez pas mentionné. Si un point important reste flou, **Lagune** pose une question courte et simple plutôt que de deviner. À partir de là, **Lagune** construit un ensemble de règles de sécurité sur mesure pour le projet, que vous pouvez relire et ajuster quand vous le souhaitez. **Tirer le meilleur parti** - Vous pouvez aussi définir vos propres règles de sécurité pour le projet. - Plus vous donnez de détails pertinents, meilleur est le rapport final : - Expliquez le projet, son fonctionnement et ce qui se passe en coulisses. - Qui est l'utilisateur final ? Que peuvent faire les utilisateurs, et que ne peuvent-ils pas faire ? - Les détails de comportement valent autant que les détails techniques. - La mémoire de la charter se trouve dans `.lagune/memory/charter.md`. ## Les catégories qu'il enregistre Les spécialisations, ces connaissances de sécurité que les phases suivantes chargent à la demande, rejoignent le [catalogue](https://lagune.ai/fr-FR/docs/catalog) de votre projet par [catégorie](https://lagune.ai/fr-FR/docs/categories). Tant que votre projet n'a aucune catégorie enregistrée, la charter enregistre chacune de celles que justifie sa lecture, comme le langage de votre projet, des appels à un LLM ou des conteneurs, et les nomme dans son résumé. Une fois des catégories enregistrées, la charter les laisse telles quelles et se contente de nommer une catégorie que votre projet n'utilise pas encore. Modifiez-les vous-même à tout moment : ```bash npx lagune write add --categories python npx lagune write remove --categories python ``` ## Étape suivante Les règles fixées, cartographiez ce que fait réellement votre système : [`/lagune-detect`](https://lagune.ai/fr-FR/docs/commands/detect). ## Questions fréquentes ### Qu'est-ce que la charter dans Lagune ? La charter est la couche de gouvernance de Lagune, un ensemble de principes axés sur la sécurité que chaque phase suivante doit respecter. Voyez-la comme la vérification à la compilation de la posture de sécurité de votre projet. ### Où la charter est-elle stockée ? Dans .lagune/memory/charter.md. ### Puis-je écrire mes propres règles dans la charter ? Oui. Lagune propose des règles à partir de votre description et de votre code, et vous pouvez les reformuler, les supprimer, en ajouter ou réduire leur portée. ### La charter choisit-elle mes catégories de spécialisations ? Seulement tant qu'aucune n'est enregistrée. Elle enregistre alors chaque catégorie que justifie sa lecture, comme votre langage ou des appels à un LLM. Une fois des catégories enregistrées, elle ne les modifie jamais. --- # /lagune-detect: cartographier votre système et ses risques > Lisez votre code et cartographiez ce que fait votre système et où se trouvent les risques. Canonique: https://lagune.ai/fr-FR/docs/commands/detect Langue: fr-FR Original: https://lagune.ai/docs/commands/detect Dernière mise à jour: 2026-11-03 🔬 Découvrez ce que fait vraiment votre système et où se trouvent les risques. Detect lit le code et ne consigne que ce qu'il trouve réellement, avec les éléments de preuve dont les phases suivantes ont besoin. Sa règle directrice est la détection, pas l'invention. ## Utilisation **Analyse complète** ```prompt /lagune-detect ``` **Indiquer des chemins** ```prompt /lagune-detect src/routes/ src/auth.ts ``` **Décrire une préoccupation** ```prompt /lagune-detect assure-toi que les données des clients ne sont jamais exposées ``` ## Ce qu'il cartographie **Lagune** lit le code et cartographie ce qu'il trouve. Chaque constat indique ce qu'il est, pourquoi il compte et l'élément de preuve. Par exemple : - **Envoi de fichiers**, le système accepte des fichiers envoyés par les utilisateurs : - _Pourquoi c'est important :_ un fichier déguisé en image peut cacher du code malveillant. - _Élément de preuve :_ le handler `POST /upload` fait confiance au type MIME envoyé par le client, sans vérifier le type réel du fichier. - **Connexion et sessions**, les utilisateurs se connectent pour accéder à leur compte : - _Pourquoi c'est important :_ une gestion de session fragile permet à un compte d'en prendre un autre. - _Élément de preuve :_ la logique d'émission des sessions, où les sessions sont émises sans expiration. Au passage, detect donne à chaque spécialisation du [catalogue](https://lagune.ai/fr-FR/docs/catalog) de votre projet un verdict face au code, applique celles dont le contexte est présent et les consigne sous **Applied specializations**, la liste que harden et verify réutilisent. Vous disposez alors d'une cartographie claire de ce que fait votre système et de l'endroit où se trouvent les risques, prête pour les étapes suivantes. **Astuce** - Le relancer met la cartographie à jour : les constats résolus disparaissent, les nouveaux apparaissent. - La cartographie se trouve dans `.lagune/memory/detect.md`. ## Étape suivante Transformez la cartographie en plan : [`/lagune-plan`](https://lagune.ai/fr-FR/docs/commands/plan). ## Questions fréquentes ### Que fait /lagune-detect ? Il lit votre code et cartographie ce que fait votre système et où se trouvent les risques, en ne consignant que ce qu'il trouve réellement. Sa règle est la détection, pas l'invention. ### Qu'est-ce qu'un constat dans Lagune ? Un constat est un risque détecté, qui indique ce qu'il est, pourquoi il compte et l'élément de preuve dans le code. C'est l'unité suivie que plan, harden et verify reprennent. ### Où la cartographie est-elle stockée ? Dans .lagune/memory/detect.md. ### Quelles spécialisations detect utilise-t-il ? Chacune de celles du catalogue de votre projet reçoit un verdict face au code. Detect applique celles dont le contexte est présent et les consigne sous Applied specializations. --- # /lagune-plan: noter les constats et planifier les correctifs > Transformez ce que detect a trouvé en plan de défense, en évaluant chaque constat avec une catégorie et un score CVSS v4.0, et en l'associant à un correctif. Canonique: https://lagune.ai/fr-FR/docs/commands/plan Langue: fr-FR Original: https://lagune.ai/docs/commands/plan Dernière mise à jour: 2026-11-03 🛡️ Transformez ce que detect a trouvé en plan de défense : évaluez chaque constat avec une catégorie et un score CVSS v4.0, puis associez-le au correctif à appliquer. ## Utilisation **Tout planifier** ```prompt /lagune-plan ``` **Indiquer des chemins** ```prompt /lagune-plan src/routes/upload.ts ``` **Cibler une inquiétude** ```prompt /lagune-plan là où des données sensibles pourraient fuiter ``` ## Fonctionnement Cette phase prend la suite de detect. Detect a déjà trouvé ce que fait votre système et le risque que porte chaque élément, donc le plan ne répète pas le risque : il évalue sa gravité et décide de ce qu'il faut faire. Plan ne lit jamais le code, ce qui oblige chaque correctif à pointer vers quelque chose que detect a réellement détecté. Il évalue chaque constat avec la méthode CVSS v4.0 : une catégorie, un vecteur CVSS v4.0 raisonné à partir de ce que detect et la charter ont capturé et noté par le [hook `cvss`](https://lagune.ai/fr-FR/docs/hooks/cvss), et la tranche de priorité où tombe ce score. Chaque correctif indique aussi le principe de sécurité qu'il fait respecter. Par exemple : - **Envoi de fichiers** (priorité : **Critical**) - _Catégorie :_ envoi de fichiers sans restriction (CWE-434). - _CVSS :_ CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (9.3, Critical). - _Pourquoi cette priorité :_ n'importe qui peut atteindre l'envoi depuis Internet, et il se trouve sur le serveur qui stocke les fichiers des clients. - _Fait respecter :_ III. Toute entrée est non fiable tant qu'elle n'a pas été validée. - _Correctif :_ vérifier le type réel et la taille du fichier, le renommer à l'enregistrement et stocker les fichiers envoyés là où ils ne peuvent pas être exécutés comme du code. Vous disposez alors d'une liste de correctifs évalués et priorisés, chacun lié à un constat et prêt à être appliqué par la phase suivante. Le score est calculé, jamais estimé : le vecteur porte l'exposition et les enjeux du projet sous forme de métriques Environmental, et n'importe qui peut le coller dans le calculateur de FIRST ou du NVD pour retrouver le même score. **Astuce** - Il s'appuie entièrement sur detect. Si un fichier ou une inquiétude n'a jamais été cartographié, il vous demande d'abord d'exécuter `/lagune-detect` dessus. - Le relancer met le plan à jour : les correctifs terminés disparaissent, les nouveaux apparaissent. - Le plan de défense se trouve dans `.lagune/memory/plan.md`. **Dépend de detect** Plan travaille uniquement à partir de ce que [`/lagune-detect`](https://lagune.ai/fr-FR/docs/commands/detect) a déjà cartographié, donc exécutez detect d'abord. ## Étape suivante Appliquez le plan : [`/lagune-harden`](https://lagune.ai/fr-FR/docs/commands/harden). ## Questions fréquentes ### Comment Lagune priorise-t-il les vulnérabilités ? /lagune-plan évalue chaque constat avec une catégorie et un score CVSS v4.0 calculé par le hook cvss, puis l'associe au correctif à appliquer. ### Lagune utilise-t-il CVSS v4.0 ? Oui. Chaque constat reçoit un vecteur et un score CVSS v4.0, calculés par le hook cvss avec la même arithmétique que le calculateur de FIRST, donc n'importe qui peut y coller le vecteur et retrouver le score. ### Le plan lit-il mon code ? Non. Plan ne lit jamais le code, ce qui oblige chaque correctif à pointer vers quelque chose que detect a réellement détecté. --- # /lagune-harden: appliquer les correctifs de sécurité à votre code > Appliquez à votre code les correctifs du plan, en toute sécurité et un par un. Canonique: https://lagune.ai/fr-FR/docs/commands/harden Langue: fr-FR Original: https://lagune.ai/docs/commands/harden Dernière mise à jour: 2026-11-03 🔧 Appliquez à votre code les correctifs du plan, en toute sécurité et un par un. ## Utilisation **Tout appliquer** ```prompt /lagune-harden ``` **Indiquer des chemins** ```prompt /lagune-harden src/routes/upload.ts ``` **Par priorité** ```prompt /lagune-harden gravité critique et élevée ``` ## Fonctionnement Le plan a déjà décidé de chaque correctif, donc harden se contente de l'appliquer. Comme c'est la seule phase qui touche à votre code, elle avance prudemment : elle applique un correctif à la fois pour que chaque modification reste facile à relire, et n'affaiblit jamais une mesure de protection pour faire entrer un correctif. Par exemple, le correctif de l'envoi de fichiers : - **Envoi de fichiers** (statut : **Applied**) - _Ce qui a changé :_ vérifie le type réel et la taille du fichier, rejette tout ce qui est inattendu, le renomme à l'enregistrement et le stocke là où il ne peut pas être exécuté comme du code. - _Où :_ la fonction `handleUpload`, ainsi que l'utilitaire de stockage qu'elle appelle. Si un correctif ne peut pas être appliqué entièrement, harden fait ce qu'il peut sans risque et marque le reste **Partial** ou **Blocked**, en le laissant ouvert. **Appliqué ne veut pas dire vérifié** Applied ne veut pas encore dire prouvé. C'est le rôle de [verify](https://lagune.ai/fr-FR/docs/commands/verify). **Astuce** - Il s'appuie entièrement sur le plan. Si un correctif ou un fichier n'a jamais été planifié, il vous demande d'abord d'exécuter `/lagune-plan` dessus. - Le relancer met le registre en cohérence : les modifications annulées disparaissent, les correctifs nouvellement appliqués apparaissent. - Le registre de durcissement se trouve dans `.lagune/memory/harden.md`. **Dépend de plan et modifie votre code** Harden s'appuie sur [`/lagune-plan`](https://lagune.ai/fr-FR/docs/commands/plan). C'est la seule phase qui modifie votre code. ## Étape suivante Prouvez que chaque correctif est efficace : [`/lagune-verify`](https://lagune.ai/fr-FR/docs/commands/verify). ## Questions fréquentes ### /lagune-harden modifie-t-il mon code ? Oui. C'est la seule phase qui touche à votre code, en appliquant les correctifs du plan un par un. ### Que signifient Applied, Partial et Blocked ? Ce sont les statuts que Lagune enregistre pour chaque correctif. Applied signifie que le correctif a été fait, Partial qu'il ne l'a été qu'en partie, Blocked qu'il n'a pas pu être appliqué. Applied ne veut pas encore dire prouvé. ### Lagune applique-t-il les correctifs sans demander ? C'est votre agent et le mode d'autorisation dans lequel vous l'exécutez qui décident si une modification demande votre accord, pas Lagune, qui n'ajoute aucune étape de confirmation propre. Il n'affaiblit pourtant jamais une mesure de protection pour satisfaire un correctif, et si un correctif entrait en conflit avec une règle de vos principes de sécurité, il s'arrête et vous prévient d'abord. --- # /lagune-verify: prouver que les mesures de sécurité sont efficaces > Prouvez que chaque correctif appliqué est efficace, puis clôturez ceux qui passent la preuve. Canonique: https://lagune.ai/fr-FR/docs/commands/verify Langue: fr-FR Original: https://lagune.ai/docs/commands/verify Dernière mise à jour: 2026-11-03 ⚖️ Prouvez que chaque correctif appliqué est efficace, en lisant le code et en le confrontant à ce que harden a consigné, puis clôturez ceux qui passent la preuve. ## Utilisation **Tout vérifier** ```prompt /lagune-verify ``` **Indiquer des chemins** ```prompt /lagune-verify src/routes/upload.ts ``` **Par priorité** ```prompt /lagune-verify gravité critique et élevée ``` ## Fonctionnement Il lit le code à chaque endroit consigné par harden et confirme qu'il correspond vraiment à ce qui est affirmé. La preuve, c'est cette confrontation du code avec le registre. Chaque mesure de protection reçoit l'un de trois verdicts : | Verdict | Signification | | ---------------------------- | ----------------------------------------------------------- | | ✅ Risk closed | Le code fait exactement ce qu'affirme le registre. | | ❌ Risk not closed | La mesure est encore ouverte. Verify vous renvoie à harden. | | ❓ Cannot tell from the code | L'élément de preuve n'est pas visible dans le code seul. | Un risque dont la clôture est prouvée est ensuite retiré de la chaîne, avec votre confirmation. Par exemple : - **Envoi de fichiers** (verdict : **✅ Risk closed**) - _Comment c'est prouvé :_ lecture du handler d'envoi, qui détecte le type réel du fichier à partir de son contenu, impose une taille maximale et refuse tout le reste, exactement comme l'affirme le registre. - _Élément de preuve :_ la fonction `handleUpload`, qui détecte le type réel du fichier à partir de son contenu. Si le risque n'est pas clôturé, verify le dit clairement et vous renvoie à [`/lagune-harden`](https://lagune.ai/fr-FR/docs/commands/harden), puisque le correctif est encore ouvert. **Astuce** - Il s'appuie entièrement sur le registre de durcissement. - Il ne lit votre code que pour le juger, et n'affaiblit jamais une mesure de protection ni ne réécrit le code pour faire passer un verdict. - Le relancer met les verdicts en cohérence : ceux qui sont périmés disparaissent, et un risque qui n'est plus clôturé est de nouveau signalé. - Quand la clôture d'un risque est prouvée, il demande une fois, puis retire ce constat de toute la chaîne (detect, plan, harden et le suivi). - Il n'écrit aucun rapport propre : chaque verdict se trouve dans le bloc de sa mesure dans `.lagune/memory/harden.md`, où harden le lit à l'exécution suivante. **Dépend de harden** Verify s'appuie sur [`/lagune-harden`](https://lagune.ai/fr-FR/docs/commands/harden). ## Le cycle se referme Quand tout ce qui est dans le périmètre a été retiré, le cycle est au repos. Il ne se rouvre que lorsque le code change. La sécurité peut être clôturée, donc le flux a un état final, pas une boucle sans fin. ## Questions fréquentes ### Comment Lagune vérifie-t-il un correctif ? /lagune-verify lit le code et le confronte à ce que harden a consigné, puis rend l'un de trois verdicts : Risk closed, Risk not closed ou Cannot tell from the code. ### Qu'est-ce que le retrait d'un constat ? Quand verify prouve qu'un risque est clôturé, le constat est retiré : supprimé de toute la chaîne, avec votre confirmation, pour qu'il cesse d'être retraité. ### Le travail de sécurité peut-il un jour être terminé ? Oui. Avec le SDH, la sécurité peut être clôturée : un constat dont la clôture est prouvée est retiré, donc le flux a un état final, pas une boucle sans fin. --- # Catégories > Les catégories de spécialisations qu'un projet Lagune peut utiliser, de l'OWASP au durcissement propre à JavaScript, Python, Go et Rust, et comment les modifier. Canonique: https://lagune.ai/fr-FR/docs/categories Langue: fr-FR Original: https://lagune.ai/docs/categories Dernière mise à jour: 2026-11-03 **Lagune** regroupe ses [**spécialisations**](https://lagune.ai/fr-FR/docs/catalog) intégrées en **13 catégories**. Les catégories qu'utilise un projet déterminent quelles spécialisations intégrées rejoignent son [**catalogue**](https://lagune.ai/fr-FR/docs/catalog), et elles se répartissent en deux : ce que fait le système, et le langage dans lequel il est écrit. Tant qu'aucune catégorie n'est enregistrée, un projet utilise seulement `owasp`. [`/lagune-charter`](https://lagune.ai/fr-FR/docs/commands/charter) enregistre chaque catégorie que justifie sa lecture du projet, et vous pouvez les modifier vous-même à tout moment. ## Ce que fait le système | Catégorie | Clé | Ce qu'elle durcit | | -------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | OWASP | `owasp` | Les risques de sécurité applicative suivis par l'OWASP : injection, contrôle d'accès défaillant, authentification et défaillances cryptographiques | | Infrastructure | `infra` | La configuration des conteneurs, des workloads et du serverless : Dockerfile, Compose, sécurité des Pods, IAM et déclencheurs FaaS | | IA / LLM | `ai` | Les intégrations d'IA et de LLM, contre l'injection de prompt et le câblage risqué d'outils, d'agents, de recherche documentaire et de MCP | | Lovable | `lovable` | Les applications Supabase générées par IA (Lovable et similaires) : lacunes RLS, clés `service_role` divulguées et valeurs par défaut non sûres | ## Le langage dans lequel il est écrit | Catégorie | Clé | Ce qu'elle durcit | | ---------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | | JavaScript | `javascript` | La RCE par `eval` et `child_process`, le path traversal et la pollution de prototype, dans tous ses runtimes | | Python | `python` | La RCE par désérialisation `pickle` et YAML, le parcours via `str.format` et la pollution de classe | | Rust | `rust` | Les API `unsafe` non sound, le mauvais usage de `transmute`, les dépassements d'entier et le comportement indéfini à la frontière FFI | | C / C++ | `c-cpp` | Les bugs de chaîne de format, les dépassements de tampon et les écritures hors limites qui permettent l'exécution de code | | PHP | `php` | Le contournement d'authentification par type juggling, les chaînes de gadgets d'injection d'objets et les configurations par défaut non sûres | | Go | `go` | Les bugs d'interface nil typée, les data races entre goroutines et la concurrence risquée sur les chemins de sécurité | | Java | `java` | Les chaînes de gadgets de désérialisation `ObjectInputStream` qui aboutissent à l'exécution de code à distance | | Ruby | `ruby` | Les chaînes de gadgets de désérialisation `Marshal.load` et YAML qui mènent à l'exécution de code à distance | | .NET / C# | `dotnet` | La RCE par désérialisation `BinaryFormatter` et les contournements d'encodeur qui mènent au XSS | **Astuce** **Lagune** est indépendant du langage : tout le flux lit le langage dans lequel votre projet est écrit, quel qu'il soit, et ces catégories ne font qu'ajouter de la profondeur sur les pièges propres à un langage. ## Ajouter et retirer à tout moment Une catégorie est un point de départ, pas un engagement. Utilisez ce qui convient au projet aujourd'hui et modifiez-le à tout moment par clé, avec `write add` et `write remove`. `--categories` sans valeur ouvre un sélecteur interactif dans un terminal (espace pour cocher, entrée pour confirmer, rien pour passer). En dehors d'un terminal, passez les catégories après l'option. **Ajouter** ```bash npx lagune write add --categories # interactive npx lagune write add --categories owasp npx lagune write add --categories owasp rust ``` **Retirer** ```bash npx lagune write remove --categories # interactive npx lagune write remove --categories owasp npx lagune write remove --categories owasp rust ``` Le premier `write add` ou `write remove` part de `owasp`, donc retirer toutes les catégories laisse une liste vide, jamais la valeur par défaut. Chaque modification est enregistrée dans `.lagune/configs.json`, pour que toute l'équipe travaille avec le même ensemble. ## Voir ce qu'utilise un projet `read list --categories` affiche chaque catégorie et indique si le projet l'utilise : ```bash npx lagune read list --categories # Categories # • owasp [used] Harden against the application security risks OWASP tracks # • javascript [available] Harden JavaScript and its runtimes # • php [available] Harden PHP against type-juggling auth bypass # • go [available] Harden Go against typed-nil interface bugs # ... # # No category is recorded yet, so this project uses the default: owasp. ``` Consultez le [**Catalogue**](https://lagune.ai/fr-FR/docs/catalog) pour savoir quelles spécialisations porte chaque catégorie. Vos propres spécialisations, écrites avec [`/lagune-specialize`](https://lagune.ai/fr-FR/docs/commands/specialize), rejoignent le catalogue quelles que soient les catégories. ## Questions fréquentes ### Comment ajouter une catégorie ? Passez la clé de la catégorie à --categories, par exemple npx lagune write add --categories javascript. Tant qu'aucune catégorie n'est enregistrée, la charter enregistre aussi celles que justifie sa lecture du projet. ### Puis-je utiliser plus d'une catégorie ? Oui. Listez-les sur la même ligne, l'une après l'autre. ### Quelle catégorie un projet doit-il utiliser ? Commencez par owasp, la valeur par défaut, puis ajoutez celle de votre langage ou de votre stack. Les spécialisations ne se chargent qu'à la demande, donc une catégorie ne coûte rien tant qu'une phase n'a pas besoin de l'une de ses spécialisations. --- # Catalogue : spécialisations de sécurité à la demande > Comment les spécialisations du catalogue de votre projet sont chargées, à la demande par une phase, et directement par vous. Canonique: https://lagune.ai/fr-FR/docs/catalog Langue: fr-FR Original: https://lagune.ai/docs/catalog Dernière mise à jour: 2026-11-03 🧠 Les spécialisations de **Lagune** sont des modules de connaissances en sécurité ciblés et indépendants du langage, qui ne se chargent qu'à la demande, jamais par défaut. Ce ne sont pas des commandes. Le catalogue de votre projet est l'ensemble qu'il utilise : les spécialisations intégrées de ses [catégories](https://lagune.ai/fr-FR/docs/categories) plus les siennes. Les phases detect et verify y font appel pendant leur exécution, et vous pouvez en charger une directement à tout moment. **Vue d** *La vue d'ensemble interactive du catalogue se trouve sur la page web. Toutes les spécialisations intégrées figurent dans le tableau ci-dessous.* **Fonctionnement** ## L'utiliser vous-même Pour utiliser une spécialisation directement, demandez à votre agent de la charger avec `read catalog ` et écrivez la tâche dans le même prompt. Les connaissances s'appliquent alors à ce que vous avez demandé. Cela fonctionne dans n'importe quel prompt, même sans rapport avec le flux de **Lagune**. Par exemple, un prompt libre et direct pour générer une collection de **RegExp** sûres en **Python** : ```prompt Charge la spécialisation regex avec `npx lagune read catalog regex`, puis crée une collection d'expressions régulières dans @src/utils/regex.py pour valider les e-mails et les noms d'utilisateur. ``` Cela utilise un hook déterministe pour tester chaque **RegExp** contre le **ReDoS**, garde celles qui sont sûres et produit quelque chose comme : ```python import re EMAIL = re.compile(r"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$") USERNAME = re.compile(r"^[a-zA-Z0-9_]{3,20}$") def is_email(value: str) -> bool: return EMAIL.match(value) is not None def is_username(value: str) -> bool: return USERNAME.match(value) is not None ``` **Essayez le vérificateur de ReDoS** Testez vous-même un motif sur [**devina.io/redos-checker**](https://devina.io/redos-checker). ## Les spécialisations intégrées Les spécialisations intégrées sont regroupées en [**catégories**](https://lagune.ai/fr-FR/docs/categories). Voici l'ensemble livré avec **Lagune** : | Spécialisation | Catégorie | Objet | | --------------------- | --------------------------- | -------------------------------------------------------------------------------------------------- | | `regex` | `owasp` | **ReDoS :** motifs qui explosent face à une entrée forgée. | | `network` | `owasp` | **SSRF et redirections :** destinations de requête ou de redirection fournies par l'utilisateur. | | `interpreter` | `owasp`, `lovable` | **Injection de code :** `eval`, inclusion dynamique, dispatch par nom. | | `sql` | `owasp` | **Bases de données relationnelles :** injection, appels ORM bruts, privilèges, portée du moteur. | | `path` | `owasp` | **Chemins du système de fichiers :** traversal, octet nul, flux NTFS, planting. | | `upload` | `owasp` | **Envoi de fichiers :** type et signature, contenu malveillant, stockage, limites. | | `access-control` | `owasp`, `lovable` | **Authentification, autorisation, session :** IDOR, mass assignment, locataires, sessions. | | `credential-endpoint` | `owasp`, `lovable` | **Devinette et bots :** force brute, password spraying, credential stuffing, limitation de débit. | | `federation` | `owasp` | **Confiance dans les jetons :** OAuth/OIDC, SAML, validation des JWT, connexion par QR code. | | `http-request` | `owasp` | **Provenance des requêtes :** CSRF, mauvaise configuration CORS, IP client usurpée. | | `transport` | `owasp` | **Sécurité du canal :** configuration TLS, HTTPS ou texte clair, HSTS, pinning. | | `crypto` | `owasp`, `lovable` | **Cryptographie au repos :** algorithmes faibles ou maison, CSPRNG, gestion des clés. | | `secrets` | `owasp`, `lovable` | **Identifiants codés en dur :** clés, jetons, mots de passe écrits en clair dans le code source. | | `api-endpoint` | `owasp` | **Surfaces hors REST :** GraphQL, gRPC, autorisation WebSocket, DoS, schéma. | | `payment` | `owasp`, `lovable` | **Parcours de paiement :** vérifier la passerelle côté serveur, callbacks signés, idempotence. | | `xml` | `owasp` | **Analyse XML :** XXE, entités externes, expansion billion laughs. | | `csv` | `owasp` | **Injection de formules :** cellules de tableur qui commencent par `=`/`+`/`-`/`@`. | | `container` | `owasp`, `infra` | **Configuration des conteneurs :** root, capabilities, montage du socket, durcissement de l'image. | | `infra` | `infra` | **Infrastructure as code :** Terraform, Dockerfile, GitHub Actions. | | `serverless` | `owasp`, `infra`, `lovable` | **Fonctions FaaS :** IAM au moindre privilège, entrées d'événements, contexte, secrets. | | `llm` | `ai`, `lovable` | **Risques de l'IA et des LLM :** injection de prompt, agentivité, RAG, MCP, sortie. | | `supabase` | `lovable` | **Backend Supabase :** RLS désactivé par défaut, politiques mal générées par l'IA, modèle de clés. | | `browser` | `javascript`, `lovable` | **Risques côté client :** XSS, CSP, framing, stockage, etc. | | `javascript` | `javascript` | **Risques propres au langage :** RCE, pollution de prototype, etc. | | `python` | `python` | **Risques propres au langage :** RCE via `pickle`, pollution de classe, `-O`, etc. | | `rust` | `rust` | **Soundness de `unsafe` :** UB déclenché par du code sûr, `transmute`, dépassements. | | `java` | `java` | **Désérialisation et code mobile :** chaînes `readObject`, détournement d'objets. | | `ruby` | `ruby` | **Désérialisation et `open` :** reconstitution via `Marshal`/YAML, particularité des pipes. | | `php` | `php` | **Type juggling et `unserialize` :** magic hashes, chaînes POP. | | `go` | `go` | **Nil typé et data races :** `nil != nil`, goroutines à mémoire partagée. | | `c-cpp` | `c-cpp` | **Chaînes de format :** `printf(user_input)`, write-what-where via `%n`. | | `dotnet` | `dotnet` | **Risques propres à la plateforme :** RCE via `BinaryFormatter`, `@Html.Raw`, failles des enums. | La plupart des connaissances intégrées sont condensées à partir de l'OWASP. Consultez [**Sources OWASP**](https://lagune.ai/fr-FR/docs/references/owasp-sources) pour la correspondance complète entre chaque spécialisation et ses pages canoniques d'attaques et de Cheat Sheets de l'OWASP. Quelques modules propres à une stack s'appuient plutôt sur la documentation de l'éditeur : `supabase`, par exemple, provient de la documentation de Supabase et de la CVE-2025-48757. ## Vos propres spécialisations Les spécialisations intégrées s'enrichissent d'un fichier de connaissances et d'une ligne d'index, jamais d'une nouvelle commande. Vous ajoutez les vôtres de la même façon, avec [`/lagune-specialize`](https://lagune.ai/fr-FR/docs/commands/specialize) : pointez-le vers un article ou un sujet et il condense une nouvelle spécialisation dans votre projet, le fichier sous `.lagune/catalog/` et son entrée dans `.lagune/configs.json`. Les vôtres sont toujours dans le catalogue, quelles que soient ses catégories, et l'une des vôtres masque une spécialisation intégrée du même nom. **En interne, Lagune charge les spécialisations automatiquement, à la demande** Quand la phase detect ou verify rencontre un contexte couvert par une spécialisation, elle charge elle-même cette spécialisation avec `read catalog `. Cela se fait automatiquement, dans le cadre de la phase. Vous n'avez rien à faire à la main pour que cela fonctionne. ## Découvrir ce qui est disponible Pour lister le catalogue de votre projet depuis le terminal, une spécialisation par ligne avec ses tags : ```bash npx lagune read catalog # regex: Regular Expression [required] # network: Requests, Webhook, URL Fetch, Socket, IMDS, Redirect # interpreter: Evaluator, Sink, Shell, Dynamic Execution # ... ``` Une spécialisation `[required]` s'applique toujours, quel que soit le travail. Les spécialisations intégrées que contient la liste dépendent des [**catégories**](https://lagune.ai/fr-FR/docs/categories) de votre projet. **Les spécialisations ne sont pas chargées par défaut** Les connaissances pertinentes sont chargées pour ce qu'est réellement le projet, au lieu d'exécuter toutes les vérifications par défaut. ## Questions fréquentes ### Qu'est-ce qu'une spécialisation de Lagune ? Un module de connaissances en sécurité ciblé et indépendant du langage, qui ne se charge qu'à la demande, jamais par défaut. Ce n'est pas une commande comme les skills de l'agent. ### Qu'est-ce que le catalogue d'un projet ? Les spécialisations qu'utilise le projet : les intégrées de ses catégories plus les siennes. Tant qu'aucune catégorie n'est enregistrée, il utilise seulement OWASP. ### Les spécialisations sont-elles chargées par défaut ? Non. Elles ne se chargent qu'à la demande, pour ce qu'est réellement le projet. ### Comment charger directement une spécialisation ? Dans le même prompt que la tâche, demandez à votre agent d'exécuter npx lagune read catalog . --- # /lagune-specialize: créer une spécialisation de sécurité en langage courant > Condensez une source ou un sujet de sécurité que vous lui donnez en une nouvelle spécialisation chargée à la demande. Canonique: https://lagune.ai/fr-FR/docs/commands/specialize Langue: fr-FR Original: https://lagune.ai/docs/commands/specialize Dernière mise à jour: 2026-11-03 🎓 Apprenez à **Lagune** une nouvelle spécialisation, à partir d'une source ou d'un sujet que vous lui donnez. Il lit le contenu et le condense en une spécialisation ciblée et exclusivement défensive, construite exactement comme les [spécialisations intégrées](https://lagune.ai/fr-FR/docs/catalog), pour que les phases detect et verify la chargent ensuite comme n'importe quelle autre. Il ne fait qu'auditer et expliquer : il n'écrit jamais d'entrées d'attaque ni d'exploits, et ne touche jamais à votre code. **À partir d** ```prompt # Un lien ou une référence : Lagune en tire la défense /lagune-specialize https://owasp.org/www-community/attacks/SQL_Injection ``` **À partir d** ```prompt # Une attaque comme source : la spécialisation reste la défense /lagune-specialize "' OR 1=1 -- injecte du SQL dans le texte de la requête" ``` **À partir d** ```prompt # Ou nomme simplement ce qu'il faut couvrir /lagune-specialize injection SQL ``` **Une attaque peut être la source, jamais le résultat** Le pointer vers une attaque ne pose pas de problème quand l'objectif est de s'en défendre : la description d'un exploit est un matériau d'étude qu'il condense en défense. La spécialisation qu'il produit audite et explique toujours, elle ne produit jamais d'exploit fonctionnel, de payload ni de technique de contournement. ## Ce qu'il écrit Le résultat, ce sont deux fichiers dans votre projet, commités et relisibles à côté de votre code : - La spécialisation dans `.lagune/catalog/.md`, construite comme les [spécialisations intégrées](https://lagune.ai/fr-FR/docs/catalog). - Son entrée dans `.lagune/configs.json`, où votre projet indexe ses propres spécialisations pour que le catalogue les fusionne avec les intégrées. Il liste ensuite le catalogue pour confirmer que la nouvelle entrée y figure. Vos propres spécialisations sont toujours dans le catalogue, quelles que soient ses catégories. Vous n'ajoutez jamais de commande et ne touchez jamais au paquet : une nouvelle spécialité, c'est un fichier de connaissances plus une entrée d'index, écrits dans votre propre projet. ## Affiner, jamais écraser Spécialiser un nom qui existe déjà, qu'il s'agisse d'une spécialisation intégrée comme `regex` ou d'une que vous avez créée auparavant, **met en cohérence** le fichier actuel au lieu de le remplacer. Il lit ce qui s'y trouve, y intègre les nouvelles connaissances, garde ce qui reste valable et réécrit ce qui a changé. Rien n'est jeté sans avoir été lu. Une spécialisation à vous masque une spécialisation intégrée du même nom, ce qui vous permet d'affiner une intégrée pour votre propre projet sans la perdre. **Astuce** - La nouvelle spécialisation se charge exactement comme une intégrée : les phases detect et verify la prennent à la demande, ou chargez-la vous-même avec `npx lagune read catalog ` et confiez-lui une tâche. - Quand le contenu a une origine identifiable (un article, un auteur, un lien, une norme), la spécialisation la crédite. Un simple sujet ne porte aucune source. **Remarque** **Il ne s'exécute que quand vous l'appelez :** l'agent ne le lance jamais de lui-même. ## Questions fréquentes ### Comment ajouter une spécialisation de sécurité personnalisée ? Exécutez /lagune-specialize avec une source ou un sujet. Il le condense en une spécialisation exclusivement défensive, écrite dans .lagune/catalog/.md avec son entrée dans .lagune/configs.json. ### Lagune peut-il apprendre à partir de la description d'un exploit ? Oui, comme source, jamais comme résultat. Une attaque peut être la source, jamais le produit. Specialize n'écrit jamais d'entrées d'attaque ni d'exploits. ### Specialize écrase-t-il les spécialisations intégrées ? Non. Il affine, il n'écrase jamais. --- # /lagune-prove: preuve de concept exclusivement défensive > Transformez chaque constat détecté en preuve de concept (PoC) exécutable et exclusivement défensive, accompagnée d'un avis de sécurité pour la divulgation responsable. Canonique: https://lagune.ai/fr-FR/docs/commands/prove Langue: fr-FR Original: https://lagune.ai/docs/commands/prove Dernière mise à jour: 2026-11-03 🧪 Transformez chaque constat détecté en élément de preuve exécutable et exclusivement défensif, pour la divulgation responsable. Pour chaque constat que contient la cartographie, il écrit un avis de sécurité autonome et un test qui vérifie le **chemin sûr** : le test échoue tant que le problème existe et passe une fois le code corrigé. **Astuce** Les tests de **Lagune** vivent isolés sous `.lagune/`, à l'écart de votre propre suite. ## Utilisation **Tous les constats** ```prompt /lagune-prove ``` **Un constat précis** Consultez les constats déjà suivis, par nom : ```prompt npx lagune read list --findings # Findings # ... # • SQL injection in user lookup # ... ``` ```prompt # Puis prouve l'un d'eux /lagune-prove SQL injection in user lookup ``` ## Fonctionnement Il lit le code source vers lequel pointe chaque constat et écrit un répertoire par constat prouvé sous `.lagune/proofs/`, qui contient exactement deux fichiers : | Fichier | Ce que c'est | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | `report.test.mjs` (ou `.cjs`) | Le test. Il s'exécute avec Poku si votre projet l'utilise déjà, sinon avec le runner natif de Node.js, donc il n'a besoin de rien d'installé. | | `report.md` | Un avis de sécurité autonome : gravité, impact, comment reproduire et commande d'exécution, lisible seul. | Les preuves sont toujours en JavaScript, donc elles restent portables quel que soit le langage de votre projet. Un index `README.md` relie toutes les preuves et donne une seule commande pour toutes les exécuter. **Astuce** - Il est **facultatif et autonome** : il ne fait pas partie des cinq phases ni de la chaîne de suivi. - Il n'écrit que dans `.lagune/proofs/` et ne touche jamais aux artefacts des phases ni à votre code, qu'il se contente de lire. - Un constat dont le test ne reproduit pas le problème n'obtient pas de preuve, et il vous demande d'exécuter [`/lagune-detect`](https://lagune.ai/fr-FR/docs/commands/detect) sur cet endroit pour remettre les choses en cohérence. - Le relancer met les preuves en cohérence : le répertoire d'un constat disparu ou qui ne se reproduit plus est supprimé. **Remarque** **Il ne s'exécute que quand vous l'appelez :** l'agent ne le lance jamais de lui-même. **S'appuie sur detect** Prove lit la cartographie produite par [`/lagune-detect`](https://lagune.ai/fr-FR/docs/commands/detect), donc exécutez detect d'abord. ## Exclusivement défensif, et autorisé Avant de générer quoi que ce soit, il confirme que vous êtes autorisé à tester la cible, et il refuse toute demande d'exploit fonctionnel, de payload d'attaque ou de contournement de la détection. Une preuve démontre le comportement sûr, elle n'émet jamais d'entrée d'attaque. ## De la preuve à la divulgation Les deux fichiers de chaque constat prouvé vont ensemble dans un **GitHub Gist privé** pour signaler la vulnérabilité. Ce sont des éléments de preuve d'un problème actif et non divulgué, donc un `.gitignore` dans `.lagune/proofs/` les tient à l'écart de chaque commit : ne les partagez que par ce Gist tant que les mainteneurs ne l'ont pas résolu. Clôturer un constat dans la chaîne de **Lagune** reste le travail de [`/lagune-harden`](https://lagune.ai/fr-FR/docs/commands/harden) et [`/lagune-verify`](https://lagune.ai/fr-FR/docs/commands/verify) : prove produit des éléments de preuve, il ne clôture rien. ## Questions fréquentes ### Lagune génère-t-il des exploits ? Non. /lagune-prove écrit des éléments de preuve exclusivement défensifs : un test qui vérifie le chemin sûr, donc il échoue tant que le problème existe et passe une fois le code corrigé, plus un avis de sécurité pour la divulgation responsable. ### Que produit prove ? Deux fichiers par constat : un test (report.test.mjs ou .cjs) et un avis de sécurité (report.md). ### Comment divulguer de façon responsable un bug trouvé par Lagune ? Prove écrit un avis de sécurité autonome que vous pouvez partager par un canal privé, comme un GitHub Gist privé, dans le respect de la divulgation responsable. --- # Hook agent : détecter les boucles d'agent sans limite > Analysez une base de code à la recherche d'appels d'agent ou de LLM sans limite d'étapes ni de temps, ou évaluez un seul appel, en ligne de commande. Canonique: https://lagune.ai/fr-FR/docs/hooks/agent Langue: fr-FR Original: https://lagune.ai/docs/hooks/agent Dernière mise à jour: 2026-11-03 Le hook `agent` signale les **runtimes d'agent qui bouclent sans limite de tours, de budget ni de temps**, la faille d'autonomie incontrôlée qui transforme une entrée forgée en coût illimité ou en escalade par injection de prompt. Il est **adapté au langage** et couvre les deux écosystèmes de frameworks d'agents : **JavaScript** (le runtime `query` du SDK d'agent de **Claude**) et **Python** (**LangChain**, **LangGraph**, **CrewAI**, **OpenAI Agents**). C'est le moteur déterministe derrière la [spécialisation `llm`](https://lagune.ai/fr-FR/docs/catalog), que vous pouvez exécuter vous-même en mode **scan** ou **check**. ## Exécution **Analyser la base de code** ```bash npx lagune read agent # scans the whole project npx lagune read agent --dir src/ai # scans a directory npx lagune read agent --file chat.ts # scans a single file ``` **Vérifier un appel** ```bash npx lagune read agent --lang javascript --pattern 'query({ prompt })' # => uncapped npx lagune read agent --lang javascript --pattern 'query({ prompt, options: { maxTurns: 5 } })' # => safe npx lagune read agent --lang python --pattern 'AgentExecutor(agent=a, max_iterations=None)' # => uncapped ``` Chaque ligne sous **Uncapped agent loops found** correspond, dans un fichier qui importe un SDK d'agent, soit au runtime `query` du SDK d'agent de Claude appelé sans limite de tours, de budget ni de temps (JavaScript, illimité par défaut), soit à la suppression explicite de la limite par défaut d'un framework, comme `max_iterations=None` / `max_turns=None` (Python, limité par défaut). Dans les deux cas, le hook se termine avec un code non nul. `generateText`/`streamText` du Vercel AI SDK se limitent par défaut à une seule étape (`stopWhen: stepCountIs(1)`), donc un appel nu ne peut pas y boucler et n'est pas signalé, et un `db.query(...)` ordinaire n'est jamais pris pour un appel d'agent. Une analyse propre affiche `no uncapped agent loops found`. ## Lire le verdict | Verdict | Signification | | ---------- | ------------------------------------------------------------------------------------------------------------------- | | `uncapped` | Un appel au runtime `query` sans limite (JS), ou une suppression explicite de la limite (`=None`, Py). | | `safe` | Un appel `query` qui fixe une limite, une génération en une seule étape ou un appel de framework limité par défaut. | | `invalid` | L'extrait ne contient aucun appel d'agent reconnaissable à juger. | ### Options de la CLI | Option | Valeur | Description | | ----------- | ------------------ | ------------------------------------------------------------------------------- | | `--pattern` | un extrait de code | Vérifie un appel. Répétez-la pour en vérifier plusieurs, un verdict par ligne. | | `--lang` | un langage | Requise avec `--pattern` : `javascript` ou `python`. | | `--dir` | un répertoire | Limite l'analyse à un répertoire. Peut être répétée et combinée avec `--file`. | | `--file` | un fichier | Limite l'analyse à un seul fichier. Peut être répétée et combinée avec `--dir`. | Sans option, il analyse tout le projet. `--pattern` exige `--lang` et ne peut pas être combinée avec `--dir` ou `--file`. **Au mieux, pas de façon exhaustive** Une boucle d'agent écrite à la main, dans n'importe quel langage, échappe à une analyse statique. Considérez ceci comme un socle solide, pas comme un inventaire complet. **Astuce** Le hook ne tranche que la limite : le périmètre des capacités, le mélange de niveaux de confiance et l'autorisation relèvent du jugement que couvre toujours la [spécialisation `llm`](https://lagune.ai/fr-FR/docs/catalog). ## Questions fréquentes ### Pourquoi limiter une boucle d'agent ? Un agent sans limite peut être entraîné dans une récursion, un coût ou une escalade par injection de prompt sans fin. Fixer maxTurns/maxBudgetUsd/stopWhen/signal le borne, et le hook agent signale un appel au runtime query qui n'en fixe aucun. --- # Hook cors : auditer les origines CORS > Analysez le code source à la recherche d'une liste d'origines CORS contournable, ou évaluez une seule valeur d'origine face à un accès trop permissif, en ligne de commande. Canonique: https://lagune.ai/fr-FR/docs/hooks/cors Langue: fr-FR Original: https://lagune.ai/docs/hooks/cors Dernière mise à jour: 2026-11-03 Le hook `cors` est le moteur déterministe derrière la [spécialisation `http-request`](https://lagune.ai/fr-FR/docs/catalog), et vous pouvez l'exécuter vous-même. Il fonctionne en deux modes depuis une seule commande : une **analyse** qui parcourt le code source à la recherche d'une **liste d'origines autorisées contournable** (une regex de validation d'hôte qu'un hôte attaquant parvient à franchir), et une **évaluation** qui classe une seule valeur d'**origine CORS** en `wildcard`, `null` ou `safe`. ## Analyser une base de code Sans option, il analyse tout le projet. **Tout le projet** ```bash npx lagune read cors ``` **Un répertoire** ```bash npx lagune read cors --dir src/server ``` **Un seul fichier** ```bash npx lagune read cors --file internal/auth/origin.go ``` Il liste chaque liste d'origines contournable sous un seul en-tête, regroupée par fichier. Un validateur d'hôte dont le `.+`/`.*` se trouve dans le segment d'autorité avant le suffixe de l'hôte de confiance (`^https?://.+\.trusted\.com`) laisse passer un hôte attaquant comme `your-site.com.attacker.com`. ```text Origin-allowlist patterns with a greedy wildcard (bypassable, review): internal/auth/origin.go ^https?://.+\.trusted\.com ``` C'est une piste à examiner, pas un constat clos : savoir si la regex protège une vraie décision de confiance ne peut pas se trancher à partir du texte, donc une analyse ne change jamais le code de sortie. Lisez chacune et confirmez que la liste compare par égalité stricte. Quand rien n'est trouvé, il affiche une seule ligne. ```bash npx lagune read cors --dir src/clean # => no bypassable origin allowlist found ``` ## Évaluer une origine Passez chaque origine avec `--origin`. Le hook affiche un mot par origine et se termine avec un code non nul dès qu'il y a un `wildcard` ou un `null`. **Une origine** ```bash npx lagune read cors --origin '*' # => wildcard npx lagune read cors --origin 'null' # => null npx lagune read cors --origin 'https://app.example.com' # => safe ``` **Plusieurs origines** Répétez `--origin` pour évaluer toute une liste d'autorisation en un seul appel, un verdict par ligne, dans l'ordre. ```bash npx lagune read cors \ --origin 'https://app.example.com' \ --origin '*' \ --origin 'null' # => safe # => wildcard # => null ``` | Verdict | Signification | | ---------- | --------------------------------------------------------------------------------------------------------------------- | | `safe` | Ni `*`, ni `null`, ni un glob `*`. Cela ne garantit pas une origine bien formée. | | `wildcard` | `*`, ou un glob de sous-domaine, d'hôte ou de port : n'importe quel site (ou un large ensemble) peut lire la réponse. | | `null` | L'origine `null`, que les iframes en sandbox et les redirections peuvent forger. | Seul `safe` vaut autorisation, et `--origin` est un oracle de valeur : il juge la valeur, pas le handler, donc confirmez le handler avec la spécialisation `http-request`. ### Options de la CLI | Option | Valeur | Description | | ---------- | ------------- | --------------------------------------------------------------------------------- | | `--origin` | une origine | Évalue une valeur d'origine. Répétez-la pour en évaluer plusieurs, une par ligne. | | `--dir` | un répertoire | Limite l'analyse à un répertoire. Peut être répétée et combinée avec `--file`. | | `--file` | un fichier | Limite l'analyse à un seul fichier. Peut être répétée et combinée avec `--dir`. | Sans option, il analyse tout le projet. `--origin` correspond au mode d'évaluation et ne peut pas être combinée avec `--dir` ou `--file`. **Ce qu'il ne couvre pas** L'analyse lit la forme de la **regex contournable**, et `--origin` évalue des **valeurs** d'origine. Deux motifs au niveau du code restent hors de portée : la réflexion de l'`Origin` de la requête (le serveur renvoie l'`Origin` reçue, ou l'associe aux identifiants) et une liste permissive par `endsWith` ou par sous-chaîne. Repérez-les dans le code et traitez-les comme le décrit la [spécialisation `http-request`](https://lagune.ai/fr-FR/docs/catalog). ## Questions fréquentes ### Pourquoi une origine CORS null est-elle dangereuse ? Les iframes en sandbox et certaines redirections envoient Origin: null, donc une liste d'autorisation qui fait confiance à null donne à ces contextes un accès en lecture. Le hook cors la signale avec le wildcard. ### Comment repérer une liste d'origines CORS contournable ? Exécutez npx lagune read cors sur la base de code. Il signale une regex de validation d'hôte dont le wildcard gourmand se trouve avant le suffixe de confiance, ce qui laisse passer un hôte attaquant comme your-site.com.attacker.com. --- # Hook crypto : détecter la cryptographie faible > Analysez une base de code à la recherche de primitives cryptographiques faibles, ou évaluez un seul extrait, en ligne de commande. Canonique: https://lagune.ai/fr-FR/docs/hooks/crypto Langue: fr-FR Original: https://lagune.ai/docs/hooks/crypto Dernière mise à jour: 2026-11-03 Le hook `crypto` signale les **primitives cryptographiques faibles** à l'endroit de l'appel : un chiffrement obsolète, un mode non sûr ou une empreinte cassée. Il est **adapté au langage** et lit chaque fichier selon ses propres règles, donc une construction Python n'est jamais signalée dans un fichier Rust. C'est le moteur déterministe derrière la [spécialisation `crypto`](https://lagune.ai/fr-FR/docs/catalog), que vous pouvez exécuter vous-même en mode **scan** ou **check**. ## Exécution **Analyser la base de code** ```bash npx lagune read crypto # scans the whole project npx lagune read crypto --dir src # scans a directory npx lagune read crypto --file hash.ts # scans a single file ``` **Vérifier un extrait** ```bash npx lagune read crypto --lang javascript --pattern 'createCipher("aes-256-cbc", k)' # => weak npx lagune read crypto --lang python --pattern 'hashlib.md5(data)' # => review npx lagune read crypto --lang go --pattern 'sha256.Sum256(data)' # => safe ``` L'analyse affiche jusqu'à deux sections. **Weak cryptography found** est l'ensemble des constats (DES/3DES/RC4/Blowfish/RC2, mode ECB) : chacun est une primitive de chiffrement cassée, donc le hook se termine avec un code non nul. **Cryptography to review manually** est un ensemble de pistes qu'il ne peut pas juger seul : une empreinte MD5/SHA-1 (cassée pour un usage de sécurité, mais légitime comme simple somme de contrôle, c'est donc l'intention qui tranche), un générateur aléatoire non cryptographique dans un contexte de sécurité, ou une comparaison sensible aux attaques temporelles. Une analyse propre affiche `no weak cryptography found`. ## Lire le verdict | Verdict | Signification | | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | `weak` | L'extrait utilise une primitive de chiffrement cassée (DES/3DES, RC4, Blowfish, RC2 ou mode ECB). | | `review` | Une primitive dont le risque dépend de l'intention : une empreinte MD5/SHA-1, ou un générateur aléatoire non cryptographique dans un contexte de sécurité. | | `safe` | L'extrait utilise de la cryptographie, et aucune primitive faible n'a été trouvée. | | `invalid` | L'extrait ne contient aucune construction cryptographique reconnaissable à juger. | ### Options de la CLI | Option | Valeur | Description | | ----------- | ------------------ | --------------------------------------------------------------------------------------------------- | | `--pattern` | un extrait de code | Vérifie un extrait. Répétez-la pour en vérifier plusieurs, un verdict par ligne. | | `--lang` | un langage | Requise avec `--pattern` : javascript, python, go, java, kotlin, php, ruby, rust, csharp, c ou cpp. | | `--dir` | un répertoire | Limite l'analyse à un répertoire. Peut être répétée et combinée avec `--file`. | | `--file` | un fichier | Limite l'analyse à un seul fichier. Peut être répétée et combinée avec `--dir`. | Sans option, il analyse tout le projet. `--pattern` exige `--lang` et ne peut pas être combinée avec `--dir` ou `--file`. ### Langages pris en charge L'analyse lit ces langages, selon l'extension du fichier, chacun confronté à ses propres API cryptographiques. | Langage | Chiffrements faibles (constat) et empreintes ou générateurs aléatoires (à examiner) | | --------------------------- | ----------------------------------------------------------------------------------------------------------- | | **JavaScript / TypeScript** | `createCipher`, `CryptoJS.DES/RC4`, quoted `*-ecb`; MD5/SHA-1 `createHash`/`subtle.digest`; `Math.random()` | | **Python** | pycryptodome `DES/ARC4/Blowfish.new`, `algorithms.TripleDES`, `MODE_ECB`; `hashlib.md5/sha1`; `random.*` | | **Go** | `des.NewCipher`, `rc4.NewCipher`, `blowfish.NewCipher`, `NewECBEncrypter`; `md5/sha1.Sum`; `math/rand` | | **Java / Kotlin** | `Cipher.getInstance("DES"/…/ECB")`; `MessageDigest.getInstance("MD5")`, `HmacMD5`; `java.util.Random` | | **PHP** | `openssl_encrypt("des-…"/"…-ecb")`, `mcrypt_*`; `md5()`/`sha1()`, `hash("md5", …)`; `rand()`/`mt_rand()` | | **Ruby** | `OpenSSL::Cipher.new("des-…")`, `:ECB`; `Digest::MD5/SHA1`; `rand()`/`Random` | | **Rust** | `Rc4::`, `Blowfish::`, `des::`, `ecb::`; `Md5::`, `Sha1::`, `Hmac`; `SmallRng`/`XorShiftRng` | | **C#** | `DES/TripleDES/RC2.Create`, `CipherMode.ECB`; `MD5/SHA1.Create`, `HMACMD5`; `new Random()` | | **C / C++** | OpenSSL `DES_*`/`RC4`/`EVP_des_*`, `EVP_*_ecb`; `MD5()`/`SHA1()`, `EVP_md5`; `rand()`/`random()` | **Au mieux, pas de façon exhaustive** Il lit le code source comme du texte, donc une primitive assemblée à l'exécution, cachée derrière un alias ou écrite sous une forme qu'il ne reconnaît pas peut lui échapper. Considérez le tableau comme un point de départ solide, pas comme un inventaire complet. **Astuce** Le hook garantit le socle (ces constructions existent) : la gestion des clés, la réutilisation des IV et le padding RSA relèvent du jugement que couvre toujours la [spécialisation `crypto`](https://lagune.ai/fr-FR/docs/catalog). ## Questions fréquentes ### Comment analyser une base de code à la recherche de cryptographie faible ? Exécutez le hook crypto sans option. Les chiffrements cassés et le mode ECB sont des constats qui terminent avec un code non nul. Une empreinte MD5/SHA-1 est une piste à examiner, puisqu'elle est cassée pour un usage de sécurité mais légitime comme simple somme de contrôle. ### Le hook crypto signale-t-il Math.random() ? Seulement comme piste à examiner dans un contexte de sécurité, jamais comme constat automatique, puisque l'aléatoire est légitime pour du jitter ou l'ordre d'affichage d'une interface. --- # Hook cvss : noter un vecteur CVSS v4.0 > Notez un ou plusieurs vecteurs CVSS v4.0 en ligne de commande, avec la même arithmétique que le calculateur de FIRST, et relisez chacun en langage courant. Canonique: https://lagune.ai/fr-FR/docs/hooks/cvss Langue: fr-FR Original: https://lagune.ai/docs/hooks/cvss Dernière mise à jour: 2026-11-03 Le hook `cvss` note un **vecteur CVSS v4.0** et affiche son score et sa tranche de gravité, l'évaluation que [`/lagune-plan`](https://lagune.ai/fr-FR/docs/commands/plan) écrit sur chaque correctif et [`/lagune-prove`](https://lagune.ai/fr-FR/docs/commands/prove) sur chaque avis de sécurité. C'est le moteur déterministe derrière ces évaluations, avec la même arithmétique que le [calculateur de FIRST](https://www.first.org/cvss/calculator/4.0), et vous pouvez l'exécuter vous-même. ## Exécution Passez chaque vecteur avec `--vector`. Le hook affiche une ligne par vecteur : son score et sa tranche. **Un vecteur** ```bash npx lagune read cvss --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N' # => 9.3, Critical ``` **Plusieurs vecteurs** Répétez `--vector` pour en noter plusieurs à la fois, une ligne chacun, dans l'ordre. ```bash npx lagune read cvss \ --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N' \ --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A' # => 9.3, Critical # => 8.7, High ``` **En langage courant** Ajoutez `--explain` pour relire chaque métrique en langage courant. Quand des métriques Threat ou Environmental modifient le score, le score Base seul apparaît en premier. ```bash npx lagune read cvss --explain --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A' # => 8.7, High # => Base metrics alone: 9.3, Critical # => Attack Vector: Network, modified to Adjacent # => Attack Complexity: Low # => ... ``` ## Lire le résultat | Tranche | Score | | ---------- | ---------- | | `None` | 0.0 | | `Low` | 0.1 à 3.9 | | `Medium` | 4.0 à 6.9 | | `High` | 7.0 à 8.9 | | `Critical` | 9.0 à 10.0 | Un vecteur avec seulement des métriques Base note la faille elle-même, en supposant le pire : toutes les exigences de sécurité à High et la faille exploitée dans la nature. Les métriques Environmental (`MAV` et les autres métriques modifiées, plus `CR`, `IR` et `AR`) l'ajustent pour un déploiement donné, et la métrique Threat (`E`) selon ce que l'on sait de son exploitation. Un vecteur invalide affiche `invalid vector:` et ce qui ne va pas, et le hook se termine avec un code non nul. ### Options de la CLI | Option | Valeur | Description | | ----------- | --------------------- | ----------------------------------------------------------------------------------------- | | `--vector` | un vecteur `CVSS:4.0` | Note un vecteur. Répétez-la pour en noter plusieurs, une ligne par vecteur, dans l'ordre. | | `--explain` | | Ajoute chaque métrique en langage courant sous chaque ligne d'évaluation. | Au moins un `--vector` est requis. Le vecteur n'est jamais un argument positionnel nu, donc il ne peut pas être confondu avec une option. **Pourquoi une valeur d'option** Chaque vecteur est passé comme valeur d'option, jamais interpolé dans la commande. Une valeur contenant des guillemets ou des backticks reste inerte et ne peut rien injecter dans le shell. Entourez-la toujours de guillemets simples pour que votre shell ne l'interprète pas d'abord. **Ce qu'il ne couvre pas** Seulement CVSS v4.0 : un vecteur v2.0, v3.0 ou v3.1 est rejeté au lieu d'être noté, puisque **Lagune** évalue chaque constat en v4.0. **Astuce** La validation de la phase plan refait cette même arithmétique sur chaque ligne CVSS, donc un score qui s'est écarté de son vecteur est repéré avant que le plan soit accepté. ## Questions fréquentes ### Comment Lagune calcule-t-il un score CVSS ? Le hook cvss suit le calculateur de référence de FIRST pour CVSS v4.0, donc un vecteur obtient exactement le même score que sur le site de FIRST. ### Puis-je noter un vecteur CVSS v3.1 avec ? Non. Lagune évalue chaque constat en CVSS v4.0, et le hook rejette toute autre version au lieu de la noter. ### À quoi sert l'option --explain ? Elle relit chaque métrique en langage courant et affiche le score Base à côté du score global, pour que chacun voie ce que dit le vecteur et comment le contexte du projet l'a modifié. --- # Hook infra : détecter les erreurs de configuration IaC > Analysez Terraform, les Dockerfiles et GitHub Actions à la recherche d'erreurs de configuration, ou évaluez un seul extrait, en ligne de commande. Canonique: https://lagune.ai/fr-FR/docs/hooks/infra Langue: fr-FR Original: https://lagune.ai/docs/hooks/infra Dernière mise à jour: 2026-11-03 Le hook `infra` signale les **erreurs de configuration de l'infrastructure as code** qu'il est possible de trancher à partir du fichier : un réseau ouvert au monde entier, une autorisation générique, un secret dans un manifeste, un conteneur root, une valeur non fiable dans un shell de CI. Il ne lit que les fichiers IaC (`.tf`/`.tf.json`/`.hcl`, `Dockerfile*`, `.github/workflows/**`). C'est le moteur déterministe derrière la [spécialisation `infra`](https://lagune.ai/fr-FR/docs/catalog), en mode **scan** ou **check**. ## Exécution **Analyser la base de code** ```bash npx lagune read infra # scans every IaC file npx lagune read infra --dir infra # scans a directory npx lagune read infra --file Dockerfile # scans a single file ``` **Vérifier un extrait** Passez l'extrait avec `--pattern` et son type avec `--kind` (`terraform`, `dockerfile` ou `github-actions`). ```bash npx lagune read infra --kind terraform --pattern 'actions = ["*"]' # => iam-wildcard npx lagune read infra --kind dockerfile --pattern 'FROM node:20' # => mutable-tag ``` L'analyse affiche jusqu'à deux sections. **Infrastructure risks found** se termine avec un code non nul et contient les défauts tranchables (un ingress `0.0.0.0/0` sur un port sensible, une déclaration IAM générique, un secret dans un manifeste, `encrypted = false`, un module git non épinglé, une image qui s'exécute explicitement en root, un `curl | sh`, une injection de script en CI, `permissions: write-all`). **Infrastructure hardening advisories** ne change pas le code de sortie (un tag de base mutable, une action épinglée par tag). Une analyse propre affiche `no infrastructure risks found`. ## Lire le verdict Le mode check affiche le tag de plus haute gravité qu'il a reconnu (par exemple `public-ingress`, `iam-wildcard`, `root-user`, `curl-pipe`, `script-injection`, `write-all`), un tag d'avertissement (`mutable-tag`, `unpinned-action`), ou `safe`. Seul un tag de gravité constat produit un code de sortie non nul. ### Options de la CLI | Option | Valeur | Description | | ----------- | ----------------------------------------------- | ------------------------------------------------------------------------------- | | `--pattern` | un extrait | Vérifie un extrait. Exige `--kind`. Répétez-la pour en vérifier plusieurs. | | `--kind` | `terraform` \| `dockerfile` \| `github-actions` | Le type selon lequel l'extrait est jugé. | | `--dir` | un répertoire | Limite l'analyse à un répertoire. Peut être répétée et combinée avec `--file`. | | `--file` | un fichier | Limite l'analyse à un seul fichier. Peut être répétée et combinée avec `--dir`. | Sans option, il analyse tous les fichiers IaC du projet. `--pattern` ne peut pas être combinée avec `--dir` ou `--file`. **Astuce** Le hook repère les cas flagrants et tranchables : l'absence de chiffrement, l'exposition via `pull_request_target` et le bon périmètre IAM relèvent du jugement que couvre toujours la [spécialisation `infra`](https://lagune.ai/fr-FR/docs/catalog). ## Questions fréquentes ### Quels fichiers d'infrastructure le hook infra lit-il ? Terraform/HCL (.tf, .tf.json, .hcl), les Dockerfiles, et le YAML des workflows et des actions GitHub Actions sous .github/. Il atteint ces fichiers même si les analyseurs de code source les ignorent. --- # Hook interpreter : signaler les sinks d'exécution dynamique de code > Analysez une base de code à la recherche de sinks d'exécution dynamique de code dans plusieurs langages, ou évaluez un seul extrait, en ligne de commande. Canonique: https://lagune.ai/fr-FR/docs/hooks/interpreter Langue: fr-FR Original: https://lagune.ai/docs/hooks/interpreter Dernière mise à jour: 2026-11-03 Le hook `interpreter` signale les **sinks d'exécution dynamique de code** : les constructions qui transforment des données en code exécuté ou les confient à un shell, d'`eval` à la désérialisation native. Il est adapté au langage et lit chaque fichier selon ses propres règles. C'est le moteur déterministe derrière la [spécialisation `interpreter`](https://lagune.ai/fr-FR/docs/catalog), que vous pouvez exécuter vous-même en mode **scan** ou **check**. ## Exécution **Analyser la base de code** ```bash npx lagune read interpreter # scans the whole project npx lagune read interpreter --dir src # scans a directory npx lagune read interpreter --file app.py # scans a single file ``` **Vérifier un extrait** ```bash npx lagune read interpreter --lang javascript --pattern 'eval(x)' # => careful npx lagune read interpreter --lang python --pattern 'json.loads(x)' # => safe ``` Ces sinks sont à double usage : une analyse statique ne peut pas trancher si une entrée influencée par un attaquant en atteint un, donc chaque correspondance est un **point de vigilance à examiner**, jamais un constat confirmé. L'analyse affiche une seule section **Dynamic-execution sinks to review**, regroupée par fichier. Une analyse propre affiche `no dynamic-execution sinks found`. **Lisez le code signalé, ne l'exécutez jamais !** Raisonnez sur chaque sink de façon **statique**, en traçant si une entrée non fiable l'atteint. N'exécutez jamais et ne passez jamais à `eval` le code signalé, ni le code distant ou récupéré à l'exécution qu'il charge, pour "tester" ce qu'il fait. ## Lire le verdict | Verdict | Signification | | --------- | ------------------------------------------------------------------------------------------------------------------- | | `careful` | L'extrait contient un sink d'exécution dynamique pour son langage. Examinez-le en le lisant, jamais en l'exécutant. | | `safe` | Aucun sink d'exécution dynamique n'a été trouvé pour le langage indiqué. | ### Options de la CLI | Option | Valeur | Description | | ----------- | ------------------ | --------------------------------------------------------------------------------------------------- | | `--pattern` | un extrait de code | Vérifie un extrait. Répétez-la pour en vérifier plusieurs, un verdict par ligne. | | `--lang` | un langage | Requise avec `--pattern` : javascript, python, php, ruby, java, kotlin, go, rust, c, cpp ou csharp. | | `--dir` | un répertoire | Limite l'analyse à un répertoire. Peut être répétée et combinée avec `--file`. | | `--file` | un fichier | Limite l'analyse à un seul fichier. Peut être répétée et combinée avec `--dir`. | Sans option, il analyse tout le projet. `--pattern` exige `--lang` et ne peut pas être combinée avec `--dir` ou `--file`. ### Langages pris en charge L'analyse lit ces langages, selon l'extension du fichier, chacun confronté à son propre ensemble de sinks d'exécution dynamique. | # | Langage | Extensions | Sinks signalés | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 1 | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` | `eval()`, constructeur Function, `setTimeout`/`setInterval` avec un corps en chaîne, module `vm`, exec de `child_process`, `require()` dynamique, `import()` dynamique | | 2 | **Python** | `.py`, `.pyi` | `eval`/`exec`, `__import__()`, `os.system`/`os.popen`, `subprocess` `shell=True`, `pickle.load`/`loads`, `yaml.load` (non sûr) | | 3 | **Ruby** | `.rb` | famille eval (`instance_eval`/`class_eval`/`module_eval`/`eval`), `system`/`exec`, backticks ou `%x`, `Kernel#open` / `IO.popen`/`read`/`binread` / `Open3`, `Process.spawn`, `Marshal.load` | | 4 | **Go** | `.go` | `exec.Command`/`exec.CommandContext`, `plugin.Open` | | 5 | **PHP** | `.php` | `eval()`, `assert()` sur une chaîne, `create_function()`, exécution shell (`system`/`exec`/`shell_exec`/`passthru`/`popen`/`proc_open`), `call_user_func`/`call_user_func_array`, `include`/`require` avec un chemin calculé à l'exécution | | 6 | **Rust** | `.rs` | `Command::new`, `process::Command` | | 7 | **Java** | `.java` | `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 8 | **Kotlin** | `.kt`, `.kts` | Les sinks de la JVM : `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 9 | **C#** | `.cs` | `Process.Start` / `new Process`, `BinaryFormatter`, `Assembly.Load` | | 10 | **C** | `.c`, `.h` | `system()`, `popen()`, la famille `exec*` (`execl`, `execve`, `execvp`, …) | | 11 | **C++** | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx` | `system()`, `popen()`, la famille `exec*` (`execl`, `execve`, `execvp`, …) | **Au mieux, pas de façon exhaustive** Il lit le code source comme du texte, donc un sink assemblé à l'exécution, caché derrière un alias ou écrit sous une forme qu'il ne reconnaît pas peut lui échapper. Considérez le tableau comme un point de départ solide, pas comme un inventaire complet. **Astuce** Le hook garantit le socle (ces sinks existent, et à tel endroit) : savoir si une valeur non fiable en atteint réellement un relève du jugement que couvre la [spécialisation `interpreter`](https://lagune.ai/fr-FR/docs/catalog). ## Questions fréquentes ### Le hook interpreter confirme-t-il une vulnérabilité ? Non. Il signale les sinks d'exécution dynamique comme des points de vigilance à examiner, jamais comme des constats confirmés, parce qu'une analyse statique ne peut pas trancher si une entrée influencée par un attaquant atteint le sink. ### Quels langages le hook interpreter couvre-t-il ? Il lit les langages du tableau Langages pris en charge, selon l'extension du fichier, chacun confronté à son propre ensemble de sinks. Les autres langages ne produisent aucun sink. --- # Hook jwt : détecter une vérification JWT sans algorithme épinglé > Analysez une base de code à la recherche de vérifications JWT sans algorithme épinglé, ou évaluez un seul appel, en ligne de commande. Canonique: https://lagune.ai/fr-FR/docs/hooks/jwt Langue: fr-FR Original: https://lagune.ai/docs/hooks/jwt Dernière mise à jour: 2026-11-03 Le hook `jwt` signale les **vérifications JWT sans algorithme épinglé**, la faille de confusion d'algorithme où le vérificateur fait confiance à l'en-tête `alg` du jeton lui-même, ainsi que la **vérification entièrement désactivée**. Il est **adapté au langage** et lit chaque fichier selon sa propre bibliothèque JWT. C'est le moteur déterministe derrière la [spécialisation `federation`](https://lagune.ai/fr-FR/docs/catalog), que vous pouvez exécuter vous-même en mode **scan** ou **check**. ## Exécution **Analyser la base de code** ```bash npx lagune read jwt # scans the whole project npx lagune read jwt --dir src # scans a directory npx lagune read jwt --file auth.ts # scans a single file ``` **Vérifier un appel** ```bash npx lagune read jwt --lang javascript --pattern 'jwt.verify(token, secret)' # => unpinned npx lagune read jwt --lang python --pattern 'jwt.decode(t, k, options={"verify_signature": False})' # => unpinned npx lagune read jwt --lang python --pattern 'jwt.decode(t, k, algorithms=["HS256"])' # => safe ``` Chaque ligne sous **Unpinned JWT verification found** est un appel de vérification qui ne fixe aucune liste `algorithms` autorisée (là où la bibliothèque en exige une), qui en accepte une non sûre (`none`, ou un algorithme asymétrique mélangé à HMAC), ou qui désactive purement et simplement la vérification de signature, et fait donc confiance au `alg` du jeton lui-même. C'est une exposition confirmée, donc le hook se termine avec un code non nul. Une analyse propre affiche `no unpinned JWT verification found`. ## Lire le verdict | Verdict | Signification | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | `unpinned` | Un appel de vérification sans liste d'algorithmes autorisés (là où il en faut une), avec une liste non sûre, ou avec la vérification désactivée. | | `safe` | Un appel de vérification qui épingle une liste d'algorithmes saine, ou dont la bibliothèque l'épingle implicitement. | | `invalid` | L'extrait ne contient aucun appel de vérification reconnaissable à juger. | ### Options de la CLI | Option | Valeur | Description | | ----------- | ------------------ | ------------------------------------------------------------------------------------------- | | `--pattern` | un extrait de code | Vérifie un appel. Répétez-la pour en vérifier plusieurs, un verdict par ligne. | | `--lang` | un langage | Requise avec `--pattern` : javascript, python, go, java, kotlin, php, ruby, rust ou csharp. | | `--dir` | un répertoire | Limite l'analyse à un répertoire. Peut être répétée et combinée avec `--file`. | | `--file` | un fichier | Limite l'analyse à un seul fichier. Peut être répétée et combinée avec `--dir`. | Sans option, il analyse tout le projet. `--pattern` exige `--lang` et ne peut pas être combinée avec `--dir` ou `--file`. ### Langages pris en charge L'analyse lit ces bibliothèques, selon l'extension du fichier. Comme certaines épinglent l'algorithme implicitement (l'absence de liste explicite est alors saine), la règle "pas de liste ⇒ unpinned" ne s'applique que là où la bibliothèque attend une liste explicite, donc un appel correctement configuré n'est jamais signalé. | Langage | Bibliothèque | Signale l'absence de liste comme unpinned ? | Signale toujours | | --------------------------- | ----------------------- | --------------------------------------------------------------- | ----------------------------------------------- | | **JavaScript / TypeScript** | jsonwebtoken, jose | Oui | `none`, mélange asymétrique+HMAC | | **Python** | PyJWT, python-jose | Oui (PyJWT l'exige, python-jose a `algorithms=None` par défaut) | `none`, `verify_signature: False` | | **Go** | golang-jwt | Oui (pas de `WithValidMethods`) | `none`, `ParseUnverified` | | **Ruby** | ruby-jwt | Oui | `none`, `verify = false` | | **Java / Kotlin** | jjwt, nimbus | Non (déduit de la clé) | `none`, un parseur non signé ou `unsecured` | | **PHP** | firebase/php-jwt | Non (`Key` porte l'algorithme) | `none` | | **Rust** | jsonwebtoken | Non (`Validation` en exige une) | `none`, `insecure_disable_signature_validation` | | **C#** | Microsoft.IdentityModel | Non (paramètres sur plusieurs lignes) | `none`, `RequireSignedTokens = false` | **Astuce** Le hook ne tranche que l'épinglage de l'algorithme : les vérifications des claims, des clés et du flux relèvent du jugement que couvre toujours la [spécialisation `federation`](https://lagune.ai/fr-FR/docs/catalog). ## Questions fréquentes ### Qu'est-ce que la confusion d'algorithme JWT ? Un vérificateur qui lit l'algorithme dans l'en-tête du jeton permet à un attaquant de remplacer RS256 par HS256 et de signer avec la clé publique. Épingler dans le code une liste d'algorithmes saine l'empêche, et le hook jwt signale un appel de vérification qui n'en fixe aucune ou en fixe une non sûre. --- # Hook network : évaluer des URL face au SSRF > Évaluez une ou plusieurs destinations de requête face au SSRF, directement en ligne de commande. Canonique: https://lagune.ai/fr-FR/docs/hooks/network Langue: fr-FR Original: https://lagune.ai/docs/hooks/network Dernière mise à jour: 2026-11-03 Le hook `network` détermine si une destination de requête côté serveur est à l'abri du **SSRF** (une requête qui peut être dirigée vers des services internes, des métadonnées cloud ou des hôtes privés). C'est le moteur déterministe derrière la [spécialisation `network`](https://lagune.ai/fr-FR/docs/catalog), et vous pouvez l'exécuter vous-même. ## Exécution Passez chaque destination avec `--url`. Le hook affiche un mot par destination, à lire dans le tableau ci-dessous. **Une destination** ```bash npx lagune read network --url 'http://example.com/' # => safe npx lagune read network --url 'http://0x7f000001/' # => private-target ``` **Plusieurs destinations** Répétez `--url` pour évaluer toute une liste d'autorisation ou de blocage en un seul appel, un verdict par ligne, dans l'ordre. ```bash npx lagune read network \ --url 'http://example.com/' \ --url 'http://[::1]/' \ --url 'http://allowed.com@evil.example/' # => safe # => private-target # => parser-divergent ``` Il résout l'hôte comme le fait le réseau, donc les formes encodées d'une adresse interne ne passent pas entre les mailles : hexadécimal, octal, décimal sans points, forme abrégée, IPv6 et IPv4 mappé en IPv6 donnent tous `private-target`. Et là où un validateur approximatif et le vrai client HTTP liraient des hôtes différents, le verdict est `parser-divergent`. ## Lire le verdict | Verdict | Signification | | ------------------ | ------------------------------------------------------------------------------------------------------- | | `safe` | La destination se connecte à un hôte public, et un validateur approximatif lirait le même hôte. | | `private-target` | L'hôte se résout en une adresse privée, de loopback, link-local, non spécifiée ou de métadonnées cloud. | | `parser-divergent` | Un validateur textuel approximatif lirait un autre hôte réel que celui auquel se connecte le client. | | `invalid url` | La chaîne ne s'analyse pas comme une URL, donc il n'y a rien à récupérer. | Seul `safe` vaut autorisation. Traitez `private-target`, `parser-divergent` et `invalid url` comme un blocage. ### Options de la CLI | Option | Valeur | Description | | ------- | ------------------ | ------------------------------------------------------------------------------------- | | `--url` | une URL ou un hôte | Vérifie une destination. Répétez-la pour en vérifier plusieurs, un verdict par ligne. | Au moins un `--url` est requis. La destination n'est jamais un argument positionnel nu, donc elle ne peut pas être confondue avec une option. **Pourquoi une valeur d'option** Chaque destination est passée comme valeur d'option, jamais interpolée dans la commande. Une valeur contenant des guillemets ou des backticks reste inerte et ne peut rien injecter dans le shell. Entourez-la toujours de guillemets simples pour que votre shell ne l'interprète pas d'abord. **Ce qu'il ne couvre pas** Le hook est pur et ne résout jamais le DNS, donc deux failles d'exécution sont hors périmètre : le **DNS rebinding** (un nom qui se résout en adresse publique lors de la vérification et en adresse interne lors de la requête) et les **chaînes de redirection** (un premier saut qui passe, puis redirige vers l'intérieur). Fermez-les en résolvant une seule fois et en vous connectant à l'adresse validée, et en refusant les redirections. Il rattache les noms de loopback réservés (`localhost` et la famille `.localhost`) à l'interne sans résolution, mais tout autre nom DNS donne `safe`, car affirmer qu'il se résout vers l'intérieur exigerait une résolution : c'est la liste d'autorisation qui les protège, et c'est elle que ce vérificateur valide. **Astuce** C'est la même vérification que la [spécialisation `network`](https://lagune.ai/fr-FR/docs/catalog) exécute pour prouver qu'un filtre de destinations est efficace. ## Questions fréquentes ### Comment tester une URL face au SSRF ? Exécutez le hook network. Il évalue une destination de requête et renvoie safe, private-target, parser-divergent ou invalid url. Seul safe vaut autorisation. ### Qu'est-ce qu'une URL parser-divergent ? Une URL que des analyseurs différents lisent différemment, un contournement classique du SSRF. Le hook network la signale au lieu de l'autoriser. --- # Hook regex : détecter les motifs vulnérables au ReDoS > Analysez une base de code à la recherche de regex exposées au ReDoS, ou évaluez un seul motif, en ligne de commande. Canonique: https://lagune.ai/fr-FR/docs/hooks/regex Langue: fr-FR Original: https://lagune.ai/docs/hooks/regex Dernière mise à jour: 2026-11-03 Le hook `regex` est le moteur déterministe de sûreté des regex qu'exécute la [spécialisation `regex`](https://lagune.ai/fr-FR/docs/catalog), et vous pouvez l'exécuter vous-même. Il fonctionne en deux modes depuis une seule commande : une **analyse** qui parcourt une base de code à la recherche de motifs exposés au **ReDoS** et de motifs construits à l'exécution, et une **vérification** qui évalue un seul motif que vous lui donnez. ## Analyser une base de code Sans option, il analyse tout le projet. `--dir` limite l'analyse à un répertoire, `--file` à un seul fichier. Les deux peuvent être répétées et se combinent en un seul rapport, où chaque fichier n'apparaît qu'une fois même quand plusieurs cibles le couvrent. **Tout le projet** ```bash npx lagune read regex ``` **Un répertoire** ```bash npx lagune read regex --dir src/services ``` **Un seul fichier** ```bash npx lagune read regex --file bin/import.pl ``` **Plusieurs cibles** ```bash npx lagune read regex --dir core --dir workers --file Sources/App/Router.swift ``` **Avec une limite** `--limit` fixe le seuil de ReDoS de l'analyse (25 par défaut), la même limite que prend le mode check. Une limite plus basse est plus stricte. ```bash npx lagune read regex --dir src/services --limit 15 ``` La sortie est du texte brut dont les en-têtes indiquent comment lire chaque section. Une section n'apparaît que si elle contient des résultats. ```text Vulnerable regular expressions found: cmd/server/main.go ([a-z]+)+$ (exponential, search) Dynamically built regular expressions (review manually by simulating a constructed regex): app/payments.php crates/parser/lexer.rs lib/validate.py Static regex wrapped in a constructor (use a literal instead): config/token.rb ``` Quand rien n'est trouvé, il affiche une seule ligne. ```bash npx lagune read regex --dir src/clean # => no unsafe patterns found ``` ### Lire les sections | Section | Signification | | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Vulnerable regular expressions found` | Motifs exposés au ReDoS, regroupés par fichier avec chaque motif en retrait en dessous, suivi entre parenthèses de la raison pour laquelle il n'est pas sûr et, s'il en a, de sa portée et de ses flags. Chaque ligne est non sûre, donc le verdict n'est pas répété. | | `Regular expressions the analysis could not settle (review manually)` | Motifs que l'analyse n'a pas pu trancher dans sa limite de travail, listés de la même façon. | | `Dynamically built regular expressions (review manually by simulating a constructed regex)` | Fichiers qui construisent une regex à partir d'une variable, d'une concaténation ou d'une interpolation. | | `Static regex wrapped in a constructor (use a literal instead)` | Fichiers qui passent un simple littéral de chaîne à un constructeur de regex là où un littéral de regex est plus simple et évite une compilation à l'exécution. | La première section est un constat de sécurité. La deuxième et la troisième ne sont pas des constats en soi : elles pointent vers du code qu'une vérification statique ne peut pas trancher, donc elles demandent une lecture humaine. La quatrième est une suggestion de clarté, pas un constat de sécurité. ### Options de la CLI | Option | Valeur | Description | | ----------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------- | | `--pattern` | la source d'une regex | Vérifie un motif. Répétez-la pour en vérifier plusieurs, un verdict par motif, dans l'ordre. | | `--flags` | des flags de regex | Vérifie chaque `--pattern` avec ces flags, comme `im`. S'applique uniquement au mode check. | | `--dir` | un répertoire | Limite l'analyse à un répertoire. Peut être répétée et combinée avec `--file`. | | `--file` | un fichier | Limite l'analyse à un seul fichier. Peut être répétée et combinée avec `--dir`. | | `--limit` | un entier positif ou nul | Fixe la limite de répétition du ReDoS (25 par défaut). S'applique aux deux modes. Une limite plus basse est plus stricte. | Sans option, il analyse tout le projet. `--pattern` correspond au mode check et ne peut pas être combinée avec `--dir` ou `--file`. ### Langages pris en charge L'analyse lit ces langages, selon l'extension du fichier, chacun selon ses propres règles, donc un motif d'un langage n'est jamais testé selon les règles d'un autre. Tout le reste est ignoré plutôt qu'analysé avec les mauvaises règles. | # | Langage | Extensions | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | | 1 | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` | | 2 | **Python** | `.py`, `.pyi` | | 3 | **Ruby** | `.rb` | | 4 | **Go** | `.go` | | 5 | **PHP** | `.php` | | 6 | **Rust** | `.rs` | | 7 | **Java** | `.java` | | 8 | **C#** | `.cs` | | 9 | **C** | `.c`, `.h` | | 10 | **C++** | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx` | | 11 | **Kotlin** | `.kt`, `.kts` | | 12 | **Swift** | `.swift` | | 13 | **Scala** | `.scala`, `.sc` | | 14 | **Dart** | `.dart` | | 15 | **PowerShell** | `.ps1`, `.psm1`, `.psd1` | | 16 | **Elixir** | `.ex`, `.exs` | | 17 | **Objective-C** | `.m`, `.mm` | | 18 | **R** | `.r` | | 19 | **Julia** | `.jl` | | 20 | **Clojure** | `.clj`, `.cljs`, `.cljc`, `.edn` | | 21 | **Crystal** | `.cr` | | 22 | **Nim** | `.nim`, `.nims` | | 23 | **V** | `.v` | | 24 | **D** | `.d` | | 25 | **Perl** | `.pl`, `.pm` | **Au mieux, pas de façon exhaustive** Il lit le code source comme du texte, donc il ne peut pas juger un motif assemblé à l'exécution, et un motif réparti sur plusieurs lignes, caché derrière un alias ou écrit sous une forme qu'il ne reconnaît pas peut lui échapper. Considérez les sections comme un point de départ solide, pas comme un inventaire complet, et continuez à lire le code pour ce qu'elles ne peuvent pas atteindre. ## Vérifier un seul motif Passez `--pattern` avec la source du motif pour l'évaluer. Le hook affiche un mot : `safe`, `unsafe`, `undetermined` quand l'analyse atteint sa limite de travail avant de trancher, ou `invalid regex`. Répétez `--pattern` pour en évaluer plusieurs à la fois, un verdict par motif, dans l'ordre. **Un motif** ```bash npx lagune read regex --pattern '(a+)+$' # => unsafe npx lagune read regex --pattern '^[a-z0-9_]{3,20}$' # => safe ``` **Plusieurs motifs** ```bash npx lagune read regex --pattern '(a+)+$' --pattern '^[a-z]+$' # => unsafe # => safe ``` **Avec des flags** `--flags` vérifie chaque `--pattern` de l'appel avec les flags avec lesquels il s'exécute, puisqu'un flag change les caractères que reconnaît un motif. ```bash npx lagune read regex --pattern '^(?:a|A)+$' # => safe npx lagune read regex --pattern '^(?:a|A)+$' --flags 'i' # => unsafe ``` **Avec une limite** `--limit` fixe la limite de répétition (25 par défaut) et s'applique à chaque `--pattern` de l'appel. Une limite plus basse est plus stricte. ```bash npx lagune read regex --pattern 'a?a?a?' --limit 2 # => unsafe ``` **Pourquoi un argument entre guillemets** Chaque motif est passé comme valeur d'option, jamais interpolé dans la commande. Une valeur contenant des guillemets ou des backticks reste inerte et ne peut rien injecter dans le shell. Entourez toujours le motif de guillemets simples pour que votre shell ne l'interprète pas d'abord. **Astuce** C'est le même moteur qu'exécute la [spécialisation `regex`](https://lagune.ai/fr-FR/docs/catalog) : l'analyse ouvre une passe ReDoS, la vérification confirme un motif qu'elle fait ressortir. ## Questions fréquentes ### Comment vérifier une regex face au ReDoS depuis la CLI ? Exécutez npx lagune read regex --pattern ''. Il renvoie safe, unsafe, undetermined ou invalid regex. ### Comment analyser tout un projet à la recherche de regex non sûres ? Exécutez le hook regex en mode scan sur la base de code. Il signale les motifs exposés au ReDoS dans 25 langages pris en charge. --- # Hook secrets : détecter les secrets codés en dur > Analysez une base de code en ligne de commande à la recherche d'identifiants codés en dur. Canonique: https://lagune.ai/fr-FR/docs/hooks/secrets Langue: fr-FR Original: https://lagune.ai/docs/hooks/secrets Dernière mise à jour: 2026-11-03 Le hook `secrets` signale les **identifiants compilés dans le code source** au lieu d'être lus depuis l'environnement. Il se fonde sur la **provenance** (un littéral face à une lecture de l'environnement), pas sur le contenu de la valeur, donc il n'a besoin d'aucun catalogue exhaustif de préfixes de fournisseurs et ne produit presque aucun faux positif. C'est le moteur déterministe derrière la [spécialisation `secrets`](https://lagune.ai/fr-FR/docs/catalog). Les signatures de format des fournisseurs, les identifiants dans les chaînes de connexion et un littéral lié à un identifiant au nom de secret sont **indépendants du langage** : la même chaîne se lit de la même façon dans n'importe quel fichier. Les deux heuristiques qui dépendent de la syntaxe, une lecture de l'environnement avec une valeur par défaut codée en dur et un secret qui aboutit dans un sink de journalisation, sont **adaptées au langage** : un `console.log` JavaScript n'est jamais lu dans un fichier Rust, et le `os.getenv("X", "default")` de Python est reconnu en tant que tel. ## Exécution ```bash npx lagune read secrets # scans the whole project npx lagune read secrets --dir src # scans a directory npx lagune read secrets --file config.ts # scans a single file ``` L'analyse affiche jusqu'à deux sections. **Hardcoded secrets found** est l'ensemble des constats (une valeur par défaut codée en dur pour une variable d'environnement au nom de secret, un identifiant intégré dans une chaîne de connexion, ou une valeur qui correspond à un format de fournisseur répertorié), donc le hook se termine avec un code non nul. **Secret handling to review manually** est un ensemble de pistes : un simple littéral lié à un identifiant au nom de secret (sa provenance est déterminable, mais pas le fait que la valeur soit un vrai secret), et une valeur au nom de secret qui aboutit dans un sink de journalisation ou de réponse. Une analyse propre affiche `no hardcoded secrets found`. ### Options de la CLI | Option | Valeur | Description | | -------- | ------------- | ------------------------------------------------------------------------------- | | `--dir` | un répertoire | Limite l'analyse à un répertoire. Peut être répétée et combinée avec `--file`. | | `--file` | un fichier | Limite l'analyse à un seul fichier. Peut être répétée et combinée avec `--dir`. | Sans option, il analyse tout le projet. ### Langages couverts Le constat de valeur par défaut d'environnement et la piste de sink de journalisation lisent un ensemble de formes propre à chaque langage, donc ils couvrent les langages ci-dessous et restent silencieux ailleurs. Les trois autres signaux s'exécutent sur **tous** les fichiers. | Signal | Langages | | ------------------------------------ | ------------------------------------------------------------------------------- | | Valeur par défaut d'environnement | JavaScript/TypeScript, Python, Ruby, PHP, Kotlin, Java, Go (`cmp.Or`), Rust, C# | | Sink de journalisation ou de réponse | JavaScript/TypeScript, Python, Ruby, PHP, Java, Kotlin, Go, Rust, C, C++, C# | **Est-ce un problème de politique d'usage ?** Non. Détecter le format d'un secret pour avertir qu'il a été commité est un outil défensif standard, la même opération que réalisent gitleaks, trufflehog et la push protection de GitHub. Le hook embarque des signatures de détection (des **formats** publics de jetons), jamais un secret réel, et il audite et explique au lieu d'exfiltrer. ## Questions fréquentes ### Comment le hook secrets évite-t-il les faux positifs ? Il se fonde sur la provenance, pas sur le contenu de la valeur. Les formats à haut niveau de confiance (jetons de fournisseurs, valeurs par défaut d'environnement, chaînes de connexion) sont des constats qui terminent avec un code non nul. Un simple littéral lié à un identifiant au nom de secret est une piste à confirmer, et le même identifiant lu depuis process.env n'est pas signalé du tout. --- # Exemples de prompts Lagune : automatiser le flux Blue Team > Des prompts Lagune prêts à copier : une analyse en lecture seule, le flux Blue Team complet et un audit Zero Trust, ainsi qu'une détection limitée à un commit, au diff d'une branche ou d'une PR, ou à un incident réel. Canonique: https://lagune.ai/fr-FR/docs/examples/prompts Langue: fr-FR Original: https://lagune.ai/docs/examples/prompts Dernière mise à jour: 2026-11-03 Des prompts Lagune prêts à copier, à coller directement dans votre agent IA. ## 💧 Analyse superficielle Un passage en lecture seule qui lit le code de lui-même et signale chaque faille avec un correctif, sans exécuter le flux Blue Team ni écrire dans le suivi de Lagune. **Astuce** Fonctionne mieux en mode planification et avec des principes de sécurité (`/lagune-charter`) définis. **🪼 Par défaut** | Aspect | Compromis | Niveau | | -------------------------- | -------------------------------------------------------------------- | ------------------- | | **Effort** | Un seul agent analyse et rend compte, sans sous-agents. | 1/5 | | **Temps** | Rapide. Un seul passage en lecture seule, rien n'est appliqué. | 2/5 | | **Consommation de tokens** | Modérée, partagée. Toute l'analyse se déroule dans un seul contexte. | 2/5 | ```md /lagune Tu es un chercheur en cybersécurité doté d'une expertise approfondie en sécurité défensive, et tu utilises Lagune pour gagner en connaissances et en précision. Analyse le workspace de toi-même et associe chaque faille trouvée à un correctif concret. Il s'agit d'un passage autonome, pas du flux Blue Team : n'exécute ni detect, ni plan, ni harden, ni verify, et n'écris rien dans le suivi de Lagune. À la fin, liste chaque faille trouvée, chacune avec sa gravité et un correctif concret. ``` **🐬 Multi-agents** | Aspect | Compromis | Niveau | | -------------------------- | -------------------------------------------------------------------------------------- | ------------------- | | **Effort** | Un sous-agent par fichier, proportionnel à la taille de votre base de code. | 2/5 | | **Temps** | En parallèle par fichier, puis fusionné en un seul rapport. Toujours en lecture seule. | 3/5 | | **Consommation de tokens** | Plus élevée, mais isolée. Chaque sous-agent analyse dans son propre contexte. | 3/5 | ````md /lagune Tu es un orchestrateur en cybersécurité qui utilise Lagune pour énumérer, lancer un sous-agent par chemin et fusionner leurs rapports (tout le contenu est lu par les sous-agents). Tu dois déléguer la tâche à des sous-agents selon la taille du projet actuel : plus la base de code est grande, plus il faut lancer de sous-agents, tous en parallèle, en donnant à chacun le prompt ci-dessous : ```prompt /lagune Tu es un chercheur en cybersécurité doté d'une expertise approfondie en sécurité défensive, et tu utilises Lagune pour gagner en connaissances et en précision. Analyse de toi-même et associe chaque faille trouvée à un correctif concret. Il s'agit d'un passage autonome, pas du flux Blue Team : n'exécute ni detect, ni plan, ni harden, ni verify, et n'écris rien dans le suivi de Lagune. À la fin, liste chaque faille de , chacune avec sa gravité et un correctif concret. ``` À la fin, fusionne tous les rapports des sous-agents en une seule liste priorisée de failles et de correctifs. ```` **Avertissement** Une analyse rapide est un prompt unique, large et sans périmètre, donc certains agents sont plus susceptibles de le refuser ou de l'écourter. Si le vôtre résiste, exécutez plutôt le **flux Blue Team** complet ci-dessous : ses phases ciblées, étape par étape, risquent beaucoup moins d'être bloquées. --- ## 🌊 Flux d'audit Blue Team automatique Exécute le [flux complet des commandes](https://lagune.ai/fr-FR/docs/get-started/commands) de bout en bout, sans s'arrêter pour demander quoi que ce soit. **🪼 Par défaut** | Aspect | Compromis | Niveau | | -------------------------- | -------------------------------------------------------------------------------------------------------------------- | ------------------- | | **Effort** | Un seul agent, sans sous-agents, quelle que soit la taille de la base de code. | 3/5 | | **Temps** | Moyen, mais moins approfondi sur les grandes bases de code. Chaque commande s'exécute une fois, l'une après l'autre. | 4/5 | | **Consommation de tokens** | Plus faible, mais moins isolée. Toutes les commandes partagent le même contexte. | 4/5 | ```md Exécute les commandes suivantes, une par une : `/lagune-charter`, `/lagune-detect`, `/lagune-plan`, `/lagune-harden` et `/lagune-verify`. ## Boucle Quand `/lagune-verify` rejette un ou plusieurs correctifs, répète `/lagune-harden` puis `/lagune-verify` jusqu'à ce que tous les constats soient correctement résolus. ## Important - Ne fais pas de pause, ne pose pas de questions : en cas de doute, fais tout en mode "complet". ``` **🐋 Multi-agents (analyse approfondie)** | Aspect | Compromis | Niveau | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------- | ------------------- | | **Effort** | Le nombre de sous-agents est proportionnel à la taille de votre base de code. | 5/5 | | **Temps** | Plus long, mais plus approfondi. Lance plusieurs sous-agents pour détecter, planifier et durcir les constats en parallèle. | 5/5 | | **Consommation de tokens** | Plus élevée, mais plus sûre. Chaque sous-agent a son propre contexte isolé, sans biais. | 5/5 | ````md Exécute les commandes suivantes en confiant chacune à un sous-agent, une à la fois (sans backticks, juste la commande) : Prompt du sous-agent 1 : `/lagune-charter` Prompt du sous-agent 2 : `/lagune-detect` Prompt du sous-agent 3 : `/lagune-plan` Prompt du sous-agent 4 : `/lagune-harden` Prompt du sous-agent 5 : `/lagune-verify` Dans les commandes `/lagune-detect`, `/lagune-plan`, `/lagune-harden` et `/lagune-verify`, tu dois déléguer la tâche à des sous-agents selon la taille du projet actuel : plus la base de code est grande, plus il faut lancer de sous-agents. Par exemple : ```prompt /lagune-detect ``` ```prompt /lagune-plan ``` ```prompt /lagune-harden ``` ```prompt /lagune-verify ``` - Plusieurs agents sur la même commande doivent être lancés en parallèle. - Une fois tous les sous-agents `/lagune-detect` terminés, exécute : ```prompt /lagune-detect fusionne les constats équivalents. Ne cherche pas de nouveaux constats et n'analyse pas de nouveau la base de code. ``` ## Boucle Quand `/lagune-verify` rejette un ou plusieurs correctifs, répète `/lagune-harden` puis `/lagune-verify` jusqu'à ce que tous les constats soient correctement résolus. ## Important - Ne fais pas de pause, ne pose pas de questions : en cas de doute, fais tout en mode "complet". ```` --- ## 🪄 Détection ciblée Pointez [`/lagune-detect`](https://lagune.ai/fr-FR/docs/commands/detect) vers une partie de votre projet plutôt que vers l'ensemble. Décrivez le périmètre en langage courant (un commit, une pull request ou une situation réelle) et il ne cartographie que les constats de sécurité pertinents à cet endroit. **Astuce** Tout ce qu'il détecte ici est un constat normal, donc vous pouvez le faire passer directement dans `/lagune-plan`, `/lagune-harden` et `/lagune-verify`, limités à ces seuls éléments. **📌 Depuis un commit** Offrez à un nouveau lot de commits son propre passage de sécurité, limité à ce qu'ils ont modifié, par exemple : ```prompt /lagune-detect Limite la détection à tout ce qui a changé depuis le commit `a1b2c3d`. ``` **🔀 Diff d** Faites la revue de sécurité d'une pull request avant sa fusion, limitée à son diff, par exemple : ```prompt /lagune-detect Limite la détection aux modifications que cette branche introduit par rapport à `main`. ``` **⛑️ Après un incident** Décrivez ce qui s'est passé avec vos propres mots. Lagune lit la situation, pas une option, et la transforme en recherche ciblée, par exemple : ```prompt /lagune-detect Notre site a subi une fuite de données il y a quelques semaines. Je ne sais pas exactement comment c'est arrivé, et j'ai peur qu'une faille soit encore ouverte et puisse de nouveau faire fuiter des données. Parcours le code attentivement, concentre-toi sur tous les endroits où des données sensibles sont lues, stockées ou exposées, et cartographie tout ce qui pourrait encore servir de porte de sortie. Traite cela comme un incident réel, pas comme un exercice. ``` --- ## 🚨 Audit Zero Trust Considère tout le workspace et chaque dépendance comme hostiles : il traque les interpréteurs, les appels réseau, les payloads encodés et le code caché dans des endroits improbables pour échapper aux scanners, puis conclut par un verdict go ou no-go sur la sûreté d'utilisation du projet. Les prompts chargent directement les spécialisations sur lesquelles repose cet audit, quelles que soient les catégories de votre projet. Pour le reste du catalogue que `/lagune` fait correspondre, assurez-vous que le projet utilise **OWASP**, **IA / LLM** et la catégorie de sa stack (par ex. **JavaScript**, **Python**, etc.) : ```bash npx lagune write add --categories owasp ai javascript ``` **Danger** Soyez prudent lorsque vous exécutez des projets de sources non fiables dans votre environnement local. Utilisez un environnement isolé, comme un **sandbox** (recommandé), une **VM** ou équivalent, pour empêcher du code malveillant d'affecter votre système. **🪼 Par défaut** | Aspect | Compromis | Niveau | | -------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------- | | **Effort** | Un seul agent parcourt tout le workspace, sans sous-agents. | 2/5 | | **Temps** | Moyen. Un seul agent passe en revue le code et ses dépendances l'un après l'autre. | 3/5 | | **Consommation de tokens** | Modérée, mais partagée. Les spécialisations, le code et les dépendances se chargent tous dans un seul contexte. | 3/5 | ```md /lagune Tu es un chercheur en cybersécurité doté d'une expertise approfondie en sécurité défensive zero trust, et tu utilises Lagune pour gagner en connaissances et en précision. Cartographie tout le workspace comme une source non fiable et un périmètre potentiellement malveillant. Chaque interpréteur, fetch, base64 et autre élément du même genre doit être traité comme une menace potentielle. Étends ton analyse aux dépendances et sous-dépendances : un projet peut essayer de cacher du code malveillant dans un endroit improbable pour échapper aux scanners. Spécialisations obligatoires (charge-les une à une avec `npx lagune read catalog `) : - interpreter - secrets - llm - path Pour être clair : chaque vulnérabilité cartographiée doit être traitée comme une menace potentielle, sans exception. À la fin, donne un verdict sur le fait que le projet soit sûr et digne de confiance pour que je l'utilise, ou non. ``` **🐋 Multi-agents (analyse approfondie)** | Aspect | Compromis | Niveau | | -------------------------- | ------------------------------------------------------------------------------------------------------------- | ------------------- | | **Effort** | Un sous-agent par fichier, proportionnel à la taille de votre base de code. | 5/5 | | **Temps** | Plus long, mais plus approfondi. Les fichiers sont parcourus en parallèle, puis fusionnés en un seul verdict. | 4/5 | | **Consommation de tokens** | La plus élevée, mais la plus sûre. Chaque sous-agent lit les spécialisations dans son propre contexte isolé. | 5/5 | ````md /lagune Tu es un orchestrateur en cybersécurité qui utilise Lagune pour énumérer, lancer un sous-agent par fichier et générer des rapports (tout le contenu est lu par les sous-agents). Lance un sous-agent par fichier, tous en parallèle, en donnant à chacun le prompt ci-dessous, limité à son fichier : ```prompt /lagune Tu es un chercheur en cybersécurité doté d'une expertise approfondie en sécurité défensive zero trust, et tu utilises Lagune pour gagner en connaissances et en précision. Traite comme une source non fiable et un périmètre potentiellement malveillant. Chaque interpréteur, fetch, base64 et autre élément du même genre doit être traité comme une menace potentielle. Étends l'analyse à tout ce que importe, y compris les dépendances et sous-dépendances, où du code malveillant peut se cacher pour échapper aux scanners. Spécialisations obligatoires pour chaque sous-agent (charge-les une à une avec `npx lagune read catalog `) : - interpreter - secrets - llm - path Pour être clair : chaque vulnérabilité cartographiée doit être traitée comme une menace potentielle, sans exception. À la fin, donne un verdict sur le fait que le projet soit sûr et digne de confiance pour que je l'utilise, ou non. ``` À la fin, fusionne tous les rapports des sous-agents en un seul verdict final. ```` --- # Security-Driven Hardening : une convention pour l'ère du développement assisté par IA > La méthodologie Security-Driven Hardening (SDH) : une convention Blue Team adaptée au contexte pour auditer et durcir les logiciels développés avec l'IA ou en vibe coding. Canonique: https://lagune.ai/fr-FR/docs/references/paper Langue: fr-FR Original: https://lagune.ai/docs/references/paper Dernière mise à jour: 2026-11-03 - **Weslley Araújo** - **Article méthodologique, 2026.** --- ## Résumé Le Security-Driven Hardening (SDH) est une méthodologie de sécurité structurée, pilotée par IA et exclusivement défensive, pensée pour une époque où les logiciels sont de plus en plus écrits par des agents IA et par des personnes qui ne sont pas spécialistes de la sécurité. Au lieu de dérouler une checklist générique, le SDH détecte d'abord ce que fait réellement un système (connexion, envoi de fichiers, paiements, exposition de données, etc.), puis pilote le travail de sécurité propre à ce contexte. Il est gouverné par des principes sûrs par défaut, entièrement tourné vers la défense, et formulé en langage courant pour que tout utilisateur puisse agir en conséquence. Ce document soutient que le SDH est une convention qui manquait, et non un outil isolé. Les connaissances de sécurité résident dans la méthodologie et ses spécialisations à la demande, une base sur laquelle chaque utilisateur peut construire, ce qui lui permet de servir un débutant et un expert par le même flux. Deux propriétés le distinguent des approches spec-first antérieures `[1]`. Le SDH est **indépendant de l'état** : il s'adapte à un répertoire vide, à un projet en cours, à une seule pull request ou à une vaste base de code héritée, dans n'importe quelle stack. Et le SDH est **clôturable** : un risque dont la clôture est vérifiée est retiré de tout le flux, si bien que ce constat atteint un état stable et n'est rouvert que lorsque le code change. Le SDH ne remplace ni les professionnels de la sécurité ni les outils Blue Team spécialisés. Il prolonge les connaissances propres du développeur, et plus un développeur comprend la sécurité, plus il peut le piloter. **Lagune** en est l'implémentation de référence, et il prouve que la méthodologie est réalisable et portable. Le SDH est proposé comme une convention que d'autres peuvent adopter. > **Mots-clés** > > développement assisté par IA, sécurité logicielle, sécurité défensive, spec-driven development, durcissement de la sécurité, workflows pilotés par agent, clôturabilité, sécurité adaptée au contexte, connaissances à la demande, outillage indépendant de l'agent. --- ## I. Introduction : la brèche de sécurité ouverte par le développement assisté par IA Les logiciels sont de plus en plus livrés par des personnes, et par des agents IA, incapables de reconnaître de façon fiable un motif non sûr : un secret divulgué, une vérification d'autorisation manquante, une requête injectable. Ce ne sont pas des risques exotiques. Ils figurent parmi les classes de risques qui dominent les incidents réels, documentées depuis des années dans des références publiques `[6]`, `[7]`, et des études récentes indiquent qu'une part significative du code généré par IA est livrée avec exactement ce type de défauts `[8]`. Les assistants de programmation IA ont aggravé la situation en permettant à des non-développeurs de livrer de vrais logiciels, mais la brèche dépasse un seul public. La plupart des projets ne bénéficient jamais d'un passage de sécurité propre à ce qu'ils font réellement. L'écosystème se fragilise à chaque décision prématurée du type "ça marche, on livre". Les conseils de sécurité génériques ne comblent pas cette brèche. Une checklist statique n'est pas propre à ce que fait un système : elle submerge un petit projet d'éléments sans rapport et passe malgré tout à côté du risque qui compte pour ce projet précis. Le problème n'est pas un manque de connaissances en sécurité dans le monde. Le problème est de faire correspondre les bonnes connaissances au système qui se trouve réellement devant l'utilisateur, et de le faire pour quelqu'un qui ne sait peut-être pas quoi demander. Le SDH y répond par une seule inversion : **les connaissances de sécurité résident dans la spécification et ses spécialisations à la demande, une base sur laquelle chaque utilisateur peut construire**. La méthodologie détecte le contexte, trie les risques que porte ce contexte et guide les correctifs, si bien qu'un développeur et un non-développeur sont servis par le même flux. Les constats et les recommandations restent en langage courant, pour être exploitables quel que soit le niveau technique du lecteur. L'expert n'en est pas bridé, mais amplifié, une dualité que nous développons en `§VI`. > **Idée clé** > > **L'inversion centrale :** les connaissances de sécurité résident dans la spécification et ses spécialisations à la demande, une base sur laquelle chaque utilisateur peut construire. La méthodologie apprend ce que fait le système et y fait correspondre le travail de sécurité, et elle prolonge tout ce que l'utilisateur sait déjà. Prenons un développeur qui dit à un assistant IA : "mon application permet aux utilisateurs d'envoyer une photo de profil." Sans passage de sécurité, l'assistant produit du code fonctionnel qui fait discrètement confiance à tout ce qu'envoie le client : le type de fichier déclaré, le nom du fichier, la taille. L'envoi est livré, et un fichier déguisé en image peut contenir du code, un nom forgé peut sortir du chemin de stockage, un fichier surdimensionné peut épuiser le serveur. Rien de tout cela n'est visible dans une démo, donc c'est livré. Le même code passé par le SDH se comporte autrement. Il détecte que le système accepte des fichiers venant de l'extérieur (détection), le traduit en risques que porte un envoi de fichiers (tri), propose de vérifier le type réel et la taille du fichier, de le renommer à l'enregistrement et de le stocker là où du code ne peut pas s'exécuter (remédiation), puis lit le résultat et confirme que chaque mesure de protection est réellement efficace (vérification). Le développeur n'a jamais eu besoin de connaître l'expression "envoi de fichiers sans restriction". La méthodologie l'a fournie à sa place. Ce document apporte les contributions suivantes : - Une définition précise du SDH en tant que méthodologie, indépendante de toute implémentation, avec ses principes de conception (`§III`). - Un cycle de vie défensif en cinq phases dans lequel la séparation des responsabilités est elle-même la contribution : la détection n'invente jamais, la planification ne lit jamais le code, une seule phase modifie le code, et la vérification n'assouplit jamais son jugement (`§IV`). - La **clôturabilité** comme position méthodologique : un constat individuel a un état final, pas une boucle sans fin (`§V`). - La dualité **prolongateur des connaissances du développeur** : un même flux qui protège le débutant et amplifie l'expert (`§VI`). - Les **spécialisations non invocables et le prompt à la demande** : des connaissances de sécurité ciblées que l'agent charge quand le contexte du projet l'exige, jamais par défaut (`§VII`). - L'**indépendance de l'état** et l'**adaptativité non autoritaire** : le SDH convient à n'importe quel état de développement et s'adapte au scénario au lieu d'imposer un périmètre fixe (`§VIII`). - Un **mode préventif** : la même défense exécutée pendant la construction du travail ordinaire, pour que le code arrive sûr par défaut et que les phases aient moins à corriger (`§IX`). - Une comparaison dédiée avec le Spec-Driven Development, la lignée dont le SDH est issu avant de s'en écarter (`§X`). - Les disciplines d'ingénierie qui permettent à la méthodologie de survivre aux refactorisations et de rester indépendante de tout agent : le suivi par identité de nom (`§XI`) et un support indépendant de l'agent (`§XII`). --- ## II. Contexte et travaux connexes Le SDH s'appuie sur des travaux antérieurs. Il hérite d'une structure éprouvée du développement spec-first piloté par agent `[1]`, `[2]`, `[3]` : des modèles, des commandes slash qu'un agent consomme, un document de gouvernance et un agent qui exécute les phases. Il réimplémente cette structure dans un but défensif. La filiation est délibérée, et l'un des principes de travail du SDH la nomme directement : construire le workflow à partir d'une structure éprouvée, puis l'orienter vers la sécurité. Le SDH n'est pas une checklist statique de recommandations génériques. Une checklist sait beaucoup de choses sur la sécurité en général et rien sur le projet qui se trouve devant elle. Le SDH inverse cette priorité. Il consacre son premier effort à la détection, à apprendre ce que fait le système, et seulement ensuite il va chercher les connaissances que la détection rend pertinentes. Le SDH ne remplace pas non plus les spécialistes de la sécurité ni les outils Blue Team spécialisés. Il prolonge les connaissances du développeur (`§VI`). Une équipe dotée d'une fonction de sécurité dédiée doit la conserver. Le SDH donne à cette équipe un support structuré, et à une équipe qui n'en a pas, une base défendable. Le SDH se place aussi à côté des scanners de sécurité déterministes (analyse statique, linters) `[4]`, `[5]`. Ces outils sont précieux justement parce qu'ils sont déterministes et reproductibles. Le SDH repose surtout sur le raisonnement de l'agent, ce qui échange un déterminisme strict contre l'adaptation au contexte. La méthodologie ne prétend pas le contraire. Là où le déterminisme compte, elle intègre un moteur déterministe au sein du raisonnement (`§VII`) : l'agent décide si une entrée mérite d'être vérifiée, et un programme déterministe décide si cette entrée est dangereuse. L'antériorité la plus directe est le Spec-Driven Development (SDD), la famille de méthodologies spec-first qui fait avancer une construction à partir d'une spécification exécutable. Nous traitons le SDD comme une classe. Sa formulation la plus claire en tant que méthodologie de praticien est le rapport de Piskala `[1]`, et sa boîte à outils pilotée par agent la plus visible est Spec Kit de GitHub `[2]`, avec OpenSpec `[3]` comme second outil de la même famille. Ce sont les références canoniques de la comparaison en `§X`. --- ## III. Le SDH : définition et principes de conception Le **Security-Driven Hardening** est une méthodologie de sécurité structurée et pilotée par IA qui rend une base de code plus sûre en conduisant le travail à partir d'une spécification qu'exécute l'agent, plutôt qu'à partir de correctifs ponctuels. Son nom s'inspire des **Blue Teams**, les défenseurs en sécurité. Le SDH porte sur la défense, le durcissement et la vérification, jamais sur l'attaque. > **Définition** > > **Security-Driven Hardening (SDH) :** une méthodologie de sécurité structurée, pilotée par IA et exclusivement défensive, qui détecte d'abord ce que fait réellement un système, puis pilote le travail de sécurité propre à ce contexte, gouvernée par des principes sûrs par défaut et formulée en langage courant. Le SDH se définit par un ensemble de principes contraignants. Chacun est une règle, et chacun confère une garantie précise à l'utilisateur. | Principe | La règle | Ce qu'il garantit à l'utilisateur | | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Sûr par défaut, en langage courant, pour tous à égalité | Chaque valeur par défaut, chaque message et chaque correctif est sûr d'emblée et compréhensible par tout lecteur, développeur ou non. Aucun profil d'utilisateur n'est privilégié. | Un débutant reçoit une base sûre sans la demander, et lit le résultat dans ses propres termes. | | Le contexte plutôt que le générique | Chaque phase part du contexte détecté par detect et agit sur ce que fait réellement le système. | Les recommandations correspondent au projet, pas à une checklist. Les connaissances de sécurité résident dans la spécification et ses spécialisations à la demande, et prolongent tout ce qu'apporte l'utilisateur. | | La souplesse plutôt que la rigidité | Les principes, exigences et recommandations sont des points de départ. L'utilisateur peut reformuler, supprimer, ajouter ou réduire la portée de n'importe quoi. | La méthodologie s'adapte au projet et à l'utilisateur, et ne se montre jamais plus stricte que ce que l'utilisateur souhaite. La souplesse n'affaiblit jamais la base sûre par défaut. | | Mettre en cohérence, jamais seulement ajouter | Les artefacts sont des documents vivants, pas des journaux. Chaque exécution revérifie chaque entrée : garder ce qui tient, réécrire ce qui a changé, supprimer ce qui ne s'applique plus. | Le registre reflète toujours le présent, donc il ne se dégrade jamais en backlog périmé. | | Exclusivement défensif | Le SDH audite, durcit et vérifie. Il ne produit jamais d'outils offensifs, d'exploits à usage malveillant ni de contournement de la détection à des fins nuisibles. | La méthodologie ne peut pas être transformée en arme. Le contenu à double usage n'apparaît que dans un cadre clairement défensif. | | Spec-first, piloté par agent, orienté vers la sécurité | Le workflow est construit à partir de modèles, de commandes, de principes de sécurité qui gouvernent et d'un agent qui exécute les phases. | Une structure de développement éprouvée, réaffectée pour que l'agent accomplisse le travail de sécurité de fond. | **Tableau 1.** Les principes de conception du SDH et la garantie que chacun confère à l'utilisateur. Ces principes ne sont pas décoratifs. Ce sont les contraintes que chaque phase ci-dessous doit respecter, et la discussion en `§XV` y revient pour marquer les limites de la méthodologie. La suite du document développe neuf piliers nommés. Ce sont les éléments qu'un lecteur doit pouvoir garder en tête, et ceux qu'une autre équipe réimplémenterait pour affirmer qu'elle pratique le SDH. | Pilier | Ce qu'il apporte | Section | | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | L'inversion adaptée au contexte | Les connaissances de sécurité résident dans la spécification et ses spécialisations à la demande, donc un débutant et un expert partagent un même flux. | `§I`, `§VI` | | Le cycle de vie défensif en cinq phases | La séparation des responsabilités : politique, détection, tri, remédiation, vérification, chacune avec une seule mission. | `§IV` | | La clôturabilité | Un constat a un état final, pas une boucle sans fin. Le travail clôturé est retiré. | `§V` | | La dualité prolongateur des connaissances du développeur | Un même flux qui protège le débutant et amplifie l'expert, sans jamais remplacer ni l'un ni l'autre. | `§VI` | | Le prompt à la demande, des connaissances non invocables | Les connaissances de sécurité pertinentes sont chargées pour ce qu'est le projet, jamais par défaut. | `§VII` | | L'indépendance de l'état et l'adaptativité non autoritaire | Convient à n'importe quel état de développement dans n'importe quelle stack, et s'adapte au scénario au lieu d'imposer un périmètre. | `§VIII` | | Le mode préventif | La même défense s'exécute pendant la construction du nouveau travail, pour que le code arrive sûr par défaut. | `§IX` | | Le suivi par identité de nom | Un constat reste un seul élément d'une phase à l'autre, et un renommage ne casse le lien qu'à un seul endroit. | `§XI` | | Le support indépendant de l'agent | La valeur de sécurité est écrite une seule fois et ne dépend d'aucun agent ni d'aucune stack. | `§XII` | **Tableau 2.** Les neuf piliers nommés du SDH et l'endroit où chacun est développé. --- ## IV. Le flux Blue Team en 5 phases Le SDH structure le travail en un cycle de vie défensif en cinq phases (figure 1). Chaque phase est orientée vers la défense, chacune s'appuie sur la précédente, et les phases suivent l'activité réelle d'une Blue Team : établir une politique, détecter, trier, remédier, vérifier. ```mermaid flowchart TB charter["1 · charter (politique)
lit : le projet, et la description de l'utilisateur si elle est fournie
écrit : les principes de sécurité
chaque principe porte le risque qu'il prévient, en langage courant"] detect["2 · detect (détection)
lit : le code de l'utilisateur
écrit : la cartographie
détection, pas invention : ne consigner que ce que le code étaye"] plan["3 · plan (tri)
lit : la cartographie, jamais le code
écrit : le plan de défense
chaque correctif pointe vers quelque chose que detect a réellement cartographié"] harden["4 · harden (remédiation)
lit : le plan de défense, et le code qu'il touche
écrit : le code, et le registre de durcissement
la seule phase qui modifie le code, un correctif à la fois, la plus petite modification efficace"] verify["5 · verify (vérification)
lit : le code, et le registre de durcissement
écrit : chaque verdict ouvert dans le registre de durcissement
la confrontation du code avec le registre, de façon statique, jamais adoucie"] charter --> detect --> plan --> harden --> verify verify -.->|"rejeté : travail rouvert pour harden,
réappliqué selon la raison consignée"| harden verify -.->|"clôture : retire ce qu'il a prouvé clôturé
de toute la chaîne,
une ligne dans l'historique"| detect ``` **Figure 1.** Le flux en cinq phases : ce que lit chaque phase, ce qu'elle écrit et son invariant structurant. Verify déclenche les deux retours : une mesure rejetée rouvre harden, et un constat dont la clôture est prouvée est retiré de la chaîne, avec une ligne dans l'historique. La séparation des responsabilités est la contribution. Comme chaque phase a une seule mission, un mode de défaillance reste confiné à un seul endroit, et le lecteur peut se fier à ce qu'affirme chaque artefact. > **Idée clé** > > **Appliqué ne veut pas dire vérifié :** harden consigne qu'un correctif a été appliqué. Verify le vérifie en confrontant le code à ce registre, et le verdict n'est jamais adouci pour correspondre au registre. Une mesure de protection peut être présente dans le code et laisser malgré tout le risque atteignable, et le verdict honnête est alors "risque non clôturé". ### charter (politique) La phase charter établit les principes de sécurité du projet, les règles que chaque phase suivante doit respecter. C'est la couche de gouvernance, une sorte de vérification à la compilation de la posture de sécurité du projet. Chaque principe a un nom clair, une règle non négociable qui peut être vérifiée dans le code, et une ligne `Why:` qui énonce le risque qu'il prévient, pas seulement le correctif. La phase charter lit toujours le projet lui-même (ses manifestes, sa structure et ses dépendances), et la description de l'utilisateur, quand elle est fournie, donne une direction que la lecture élargit ensuite au-delà de ce que l'utilisateur a nommé. Sans description, le projet est la seule source. Les deux se complètent au lieu de se concurrencer, et la phase charter consigne la politique que le projet doit respecter, pas l'état de son code. Un non-développeur doit pouvoir la lire et comprendre à la fois la règle et le risque. ### detect (détection) Detect lit le code et cartographie ce que fait réellement le système qui pèse sur la sécurité. Sa consigne directrice est "la détection, pas l'invention" : ne consigner que ce que le code étaye, avec les éléments de preuve dont les phases suivantes ont besoin. Detect est neutre. Il ne force pas ses constats à cadrer avec les principes de sécurité, car confronter les risques aux règles de la charter est le travail de la phase plan. Chaque constat comporte trois parties : ce qu'il est (description en langage courant), pourquoi il compte (le risque, pas seulement le fait) et l'élément de preuve (la fonction ou la route où il se trouve). L'élément de preuve ne contient aucun chemin de fichier. Le chemin ne se trouve que dans la carte de suivi (`§XI`), donc le texte ne contient jamais un chemin susceptible de devenir obsolète. ### plan (tri) Plan transforme chaque constat en correctif, nommé par sa classe de risque (en citant les références établies, CWE et OWASP, quand elles le fondent) et rattaché au principe de sécurité que le correctif fait respecter. La priorité (Critical, High, Medium, Low) n'est pas un choix libre : plan évalue chaque constat avec la méthode CVSS v4.0 Base et Environmental, donc la tranche est le score exprimé en mots, justifiée par une ligne en langage courant sur l'exposition et les enjeux, et deux exécutions aboutissent au même ordre. Le vecteur est l'ancrage précis pour un expert, la tranche et sa justification sont la même évaluation que n'importe qui peut suivre. Plan travaille uniquement à partir de la cartographie et ne lit jamais le code. C'est une contrainte délibérée, pas une limitation : elle oblige chaque correctif à pointer vers quelque chose que detect a réellement détecté. Si un périmètre n'a jamais été cartographié, plan s'arrête et renvoie l'utilisateur vers detect au lieu de deviner. ### harden (remédiation) Harden est la seule phase qui modifie le code, donc elle avance avec prudence. Savoir si une modification demande l'accord de l'utilisateur relève de l'agent et du mode d'autorisation dans lequel il s'exécute, donc harden n'ajoute aucune étape de confirmation propre. Elle applique un correctif à la fois, les dépendances d'abord, puis la priorité la plus élevée, pour que chaque modification reste petite, relisible et facile à annuler. Elle n'affaiblit jamais une mesure de protection existante pour faire entrer un nouveau correctif, et elle n'enfreint jamais un principe de sécurité. Si un correctif entrait en conflit avec un principe, harden s'arrête et fait apparaître le conflit au lieu de l'appliquer. Chaque bloc est consigné comme Applied, Partial ou Blocked. "Appliqué ne veut pas encore dire vérifié", et c'est la question que traite la phase suivante. ### verify (vérification) Verify vérifie chaque mesure appliquée en lisant le code et en le confrontant à ce que harden a consigné. La vérification est cette confrontation du code avec le registre, et elle est statique : elle confirme qu'une mesure est présente et correcte dans le code, pas qu'elle résiste à une attaque sur un système en fonctionnement. Ce contrôle à l'exécution, celui qui lance des attaques réelles ou simulées contre le système en production, est hors périmètre par conception. Verify rend l'un de trois verdicts : risque clôturé, risque non clôturé, ou impossible à déterminer à partir du code. Il ne produit aucun artefact propre : harden et verify partagent le registre de durcissement, harden possédant ce qui a été fait et verify le verdict et sa raison, et aucun n'écrit jamais dans les champs de l'autre. Une mesure rejetée est du travail rouvert pour harden, dont l'exécution suivante fait primer le verdict sur sa propre lecture du code et réapplique le correctif sur l'écart exact que nomme la raison. Verify fait confiance au code plutôt qu'au registre, car un registre peut affirmer plus que ce que le code tient. Il est en lecture seule sur le code de l'utilisateur, et il n'adoucit jamais un verdict pour qu'il corresponde au registre. Une mesure peut être présente et laisser malgré tout le risque atteignable par un autre chemin, et dans ce cas le verdict honnête est "risque non clôturé". Si, en lisant, verify remarque un problème de sécurité que la cartographie n'a jamais couvert, il n'invente pas de verdict pour lui, puisque la détection est le travail de detect : il signale le problème et renvoie l'utilisateur vers detect, pour que le constat entre par le même flux au lieu de le contourner. > **Fil conducteur : l'envoi de fichiers.** Un seul constat montre la colonne vertébrale de bout en bout. > > - **detect** le trouve : le système accepte des fichiers des utilisateurs, et le handler d'envoi fait confiance au type MIME envoyé par le client sans vérifier le type réel du fichier. _Pourquoi c'est important :_ un fichier déguisé en image peut cacher du code malveillant. > - **plan** décide du correctif, priorité **Critical**, en faisant respecter le principe "Toute entrée est non fiable tant qu'elle n'a pas été validée" : vérifier le type réel et la taille du fichier, le renommer à l'enregistrement et stocker les fichiers envoyés là où ils ne peuvent pas être exécutés comme du code. > - **harden** l'applique, statut **Applied** : le handler détecte désormais le type réel à partir du contenu, impose une taille maximale, rejette tout ce qui est inattendu, renomme à l'enregistrement et stocke là où du code ne peut pas s'exécuter. > - **verify** lit le handler, le confronte au registre et rend **risque clôturé** : le code fait exactement ce qu'affirme le registre. > > Le même nom de constat traverse la cartographie, le plan et le registre de durcissement, et verify agit sur ce registre sous le même nom : un verdict ouvert est écrit dans le bloc du constat, et un constat dont la clôture est prouvée est retiré (`§V`). Ce nom partagé est son identité (`§XI`). --- ## V. Clôturabilité : un constat a un état final La plupart des outils de sécurité laissent l'utilisateur avec un backlog qui ne fait que grossir. Le SDH adopte une position différente : **un constat est clôturable, donc il a un état final au lieu de vivre dans un backlog sans fin** (figure 2). Cela découle directement du principe de mise en cohérence. > **Définition** > > **Clôturabilité :** un risque dont la clôture est vérifiée est retiré de tout le flux, si bien que ce constat atteint un état stable et n'est rouvert que lorsque le code change. Un constat a un état final, même si le programme de sécurité lui-même reste continu. Les artefacts du SDH sont des documents vivants, pas des journaux. Chaque fois qu'une phase est relancée, elle revérifie chaque entrée existante par rapport à la réalité actuelle et fait l'une de trois choses : garder ce qui tient encore, réécrire ce qui a changé ou supprimer ce qui ne s'applique plus. Un constat que le code montre désormais résolu est simplement supprimé. Le registre de travail reflète le présent, pas le passé. La clôture est cette même mise en cohérence arrivée à son terme. Quand verify vérifie qu'un risque est clôturé, il retire le constat de tout le flux : la cartographie, le plan, le registre de durcissement et la carte de suivi. C'est pourquoi verify est la seule phase qui écrit dans les artefacts des autres phases : c'est la phase qui boucle la boucle. Au moment où le constat quitte la chaîne, le retrait le condense en une courte entrée d'un historique qui vit en dehors de la chaîne de travail et n'est jamais retraité. C'est la frontière entre disparaître et être clôturé : un constat que la mise en cohérence a supprimé parce qu'il avait cessé d'être vrai ne laisse rien derrière lui, alors qu'un constat dont la clôture est prouvée gagne sa ligne dans l'historique. Un constat retiré est ensuite absent de chaque artefact de travail, et cette absence est attendue, ce n'est pas une chaîne cassée. ```mermaid stateDiagram-v2 direction TB [*] --> OPEN: detect détecte OPEN --> Plan: plan Plan --> Harden: harden Harden --> Verify: verify Verify --> StoodDown: risque clôturé StoodDown --> SETTLED SETTLED --> OPEN: un changement du code rouvre un constat Plan: plan Harden: harden Verify: verify StoodDown: RETIRÉ · une ligne dans l'historique ``` **Figure 2.** La machine à états de la clôturabilité. Un constat passe de OPEN à RETIRÉ puis à SETTLED, et ne se rouvre que lorsque le code change. Quand tout ce qui est dans le périmètre a été retiré, le cycle est au repos, et cet état a une forme concrète : un artefact dont le dernier constat a été clôturé est supprimé en entier, donc une chaîne entièrement clôturée ne laisse que les principes de sécurité et l'historique, la politique et la preuve. Le cycle n'est rouvert que lorsque le code change. La méthodologie donne à chaque constat une fin définie, ce qu'un backlog sans fin ne peut justement pas offrir. --- ## VI. La dualité prolongateur des connaissances du développeur Le SDH ne remplace pas les personnes, et il ne remplace pas les outils Blue Team spécialisés. Il **prolonge les connaissances propres du développeur**. Plus un développeur comprend la sécurité, plus il peut piloter le flux avec précision, et plus il gagne en autonomie. Un développeur qui en comprend peu reçoit malgré tout un résultat sûr, parce que le mode automatique le protège. L'inversion de `§I`, selon laquelle les connaissances de sécurité résident dans la spécification, s'applique dans les deux sens. Pour le débutant, c'est une protection : il n'a pas besoin de savoir quoi demander, parce que la spécification propose. Pour l'expert, c'est une amplification : la même spécification lui permet d'orienter le flux avec précision au lieu de se battre contre une checklist figée. Chaque phase porte cette dualité dans son propre fonctionnement (figure 3). Exécutée sans entrée, elle agit sur tout le périmètre à la place de l'utilisateur. Avec une direction, la même phase se restreint exactement à ce que l'utilisateur lui a désigné. ```mermaid flowchart TB inversion["une inversion, deux directions :
les connaissances de sécurité résident dans la spécification"] inversion --> auto["mode automatique (sans entrée)
la phase propose et agit
sur tout le périmètre"] inversion --> directed["mode dirigé (avec entrée)
la phase se restreint exactement
à ce que l'utilisateur a désigné"] auto --> novice["le débutant, protégé :
un résultat sûr sans
savoir quoi demander"] directed --> expert["l'expert, amplifié :
le flux orienté avec précision,
pas une checklist figée"] novice -.-> phases["les mêmes cinq phases servent les deux :
charter · detect · plan · harden · verify"] expert -.-> phases ``` **Figure 3.** La dualité prolongateur des connaissances du développeur. Une seule inversion sert deux publics : le mode automatique protège le débutant et le mode dirigé amplifie l'expert, par les mêmes cinq phases. Les spécialisations à la demande (`§VII`) rendent cette dualité explicite dans leur propre texte. Chacune indique à l'agent que ses connaissances "prolongent ton jugement" et qu'il doit continuer à raisonner au-delà de ce qu'apporte la spécialisation. Les connaissances sont un plancher, pas un plafond. C'est ce qui sert les deux publics dans l'équilibre voulu par le document : la communauté des développeurs gagne un instrument substantiel, et le praticien Blue Team un support structuré qui ne prétend pas faire son travail à sa place. --- ## VII. Spécialisations non invocables et prompt à la demande C'est le motif le plus novateur de la méthodologie. Le SDH porte des connaissances de sécurité ciblées sous forme de spécialisations qui se chargent **uniquement à la demande**, et c'est l'agent lui-même qui décide lesquelles charger en les confrontant au contexte du projet. Nous appelons cela le **prompt à la demande** : un moyen pour l'agent de choisir quelles connaissances activer selon le périmètre du projet dans lequel il se trouve, au lieu d'exécuter toutes les vérifications par défaut. Les spécialisations évoluent, et chacune peut changer ou être remplacée à tout moment. La contribution est le motif, pas les spécialisations elles-mêmes. > **Définition** > > **Prompt à la demande :** l'agent choisit quelles connaissances de sécurité activer en les confrontant au périmètre du projet qui se trouve devant lui, si bien que les connaissances pertinentes sont chargées pour ce qu'est réellement le projet, au lieu d'exécuter toutes les vérifications par défaut. > **Définition** > > **Spécialisation non invocable :** une unité de connaissances de sécurité ciblée et indépendante du langage pour un contexte donné, comme l'envoi de fichiers ou le code qui s'exécute dans le navigateur. Elle audite et explique, ne réécrit jamais de code et ne produit jamais d'entrée d'attaque. Ce n'est pas une commande : elle se charge quand le contexte qu'elle couvre est dans le périmètre, ou quand un prompt la demande par son nom. Chaque spécialisation nomme les formes plus sûres pour les risques qu'elle couvre et indique à l'agent comment traiter un constat dans chaque phase qui l'utilise : comment le juger à la détection, comment appliquer son correctif sans risque à la remédiation et comment le prouver à la vérification. Son trait distinctif est qu'une spécialisation est **non invocable à elle seule** : ce n'est pas une commande, et au sein du flux, c'est une correspondance qui la charge. La phase de détection liste le catalogue une fois, confronte le contexte du projet à ce que couvre chaque entrée et ne charge que les spécialisations dont le contexte est présent dans le périmètre. Les phases suivantes réutilisent cette liste au lieu de la refaire, donc une seule correspondance sert toute la chaîne, et le mode préventif (`§IX`) applique la même correspondance au travail sur le point d'être construit. Une spécialisation dont le contexte est absent est écartée, et l'écart est aussi justifié que le chargement : chaque entrée du catalogue reçoit un verdict explicite, appliquée ou écartée avec la raison lue dans le code, pour qu'un vague sentiment de non-pertinence ne tienne jamais lieu d'absence. N'en trouver aucune applicable est un résultat valable. Le catalogue est une donnée, et le faire grandir, c'est un fichier de connaissances plus une ligne de catalogue, jamais une nouvelle commande. Les spécialisations intégrées sont regroupées en catégories, comme l'OWASP, un langage ou les intégrations d'IA, et le catalogue qu'utilise un projet contient les intégrées des catégories qu'il a choisies plus ses propres spécialisations. Le projet consigne ce choix avec le reste de son état, donc toute une équipe utilise le même catalogue. C'est le même principe d'adaptation au contexte que celui des phases, appliqué aux connaissances : les connaissances pertinentes sont chargées pour ce qu'est réellement le projet, au lieu d'exécuter toutes les vérifications par défaut. La même propriété permet à l'utilisateur, et pas seulement au mainteneur, de faire grandir le catalogue : une source ou un sujet de sécurité fourni par l'utilisateur est condensé en une nouvelle spécialisation qui appartient au projet, rejoint son catalogue quelles que soient les catégories et se charge exactement comme une intégrée, en remplaçant l'intégrée du même nom. Rédiger une spécialisation est en soi exclusivement défensif et respecte la même limite que celle que font respecter les spécialisations : la description d'une attaque peut être la source, mais la spécialisation qui en résulte audite et explique, elle n'émet jamais d'exploit fonctionnel. Ainsi, l'inversion de `§I`, selon laquelle l'intelligence réside dans la spécification, s'étend au catalogue lui-même, que l'utilisateur peut approfondir pour son propre contexte sans écrire de code. Un court exemple illustre le prompt à la demande. Detect lit un dossier de code qui s'exécute dans le navigateur. Il trouve ce contexte dans le catalogue, charge la spécialisation qui le couvre et fait ressortir un constat côté client par les étapes normales de detect. Les spécialisations dont le contexte est absent de ce périmètre ne correspondent pas, donc elles ne se chargent jamais, et chacune est consignée comme écartée. C'est le projet qui a déterminé les connaissances pertinentes, pas une configuration figée. Le déterminisme apparaît précisément là où il compte. Une spécialisation peut porter un vérificateur déterministe, pas seulement du texte : là où une classe de risques dispose d'une procédure de décision nette, un petit programme rend un verdict fixe pour une entrée donnée, par exemple un court ensemble de mots comme `safe`, `unsafe` ou `invalid input`. Certaines classes de risques sont décidables de façon déterministe exactement de cette manière, avec un ensemble de travaux antérieurs derrière la procédure de décision `[9]`, `[10]`, `[11]`. Le vérificateur évalue soit des candidats fournis par l'agent, soit analyse lui-même le périmètre pour les trouver, et dans les deux cas c'est le vérificateur, pas l'agent, qui rend le verdict. Une spécialisation suffisamment universelle peut être marquée comme requise dans le catalogue : elle est alors toujours appliquée, et son vérificateur s'exécute sur tout le périmètre. C'est le seul cas où des connaissances se chargent sans correspondance de contexte, et il est déclaré dans les données du catalogue, jamais décidé par l'agent sur le moment. C'est là que le SDH ancre le raisonnement de l'agent dans quelque chose de reproductible, sans prétendre que tout le flux est déterministe. Enfin, les spécialisations sont **détachables**. Comme les connaissances se suffisent à elles-mêmes, un utilisateur peut en exécuter une directement dans un prompt qui n'a rien à voir avec le flux complet du SDH, et garder ainsi la sécurité aux côtés du développement ordinaire. Une spécialisation dotée d'un vérificateur déterministe peut, par exemple, filtrer chaque candidat produit pendant le développement ordinaire et ne garder que ceux qui sont sûrs. Ce caractère détachable explique en partie pourquoi le SDH s'adapte à tant de situations, ce qui est le sujet de `§VIII`, et son expression la plus complète est le mode préventif (`§IX`), où les mêmes connaissances protègent le développement ordinaire de bout en bout. --- ## VIII. Indépendance de l'état et adaptativité non autoritaire Deux propriétés distinguent le SDH des méthodologies de spécification rigides. ### Indépendance de l'état > **Définition** > > **Indépendance de l'état :** la méthodologie ne dépend pas de l'état du développement. Elle convient à un répertoire vide, à un projet en cours, à une seule pull request ou à une vaste base de code héritée, dans n'importe quelle stack, parce qu'elle découvre le point de départ en le lisant. Chaque phase fonctionne de la même façon, que le projet soit tout neuf ou existe déjà. La phase charter déduit des principes de tout le code présent. Detect cartographie tout le code qui s'y trouve, même s'il y en a très peu. Il n'y a aucun point de départ supposé. ### Adaptativité non autoritaire > **Définition** > > **Adaptativité non autoritaire :** la méthodologie s'adapte au scénario au lieu d'imposer un périmètre fixe que l'utilisateur doit suivre. Quand l'utilisateur ne sait pas quoi dire, elle lit l'environnement dans lequel elle a été invoquée, génère du contexte et pose les questions qui orientent ce qu'elle fait ensuite. Le mode de proposition de la phase charter en est l'exemple le plus clair : le SDH déduit des principes de sécurité sûrs par défaut en analysant le projet, en ne posant de question à l'utilisateur que lorsqu'un manque change réellement le résultat, puis les écrit et présente chaque principe en langage courant avec le risque qu'il prévient. Les principes de sécurité sont un document vivant que l'utilisateur retravaille en relançant la phase, pas un contrat soumis à une demande d'approbation, donc ils n'exigent jamais que l'utilisateur sache quoi demander. Cette adaptativité se manifeste par une sensibilité à la forme de l'entrée : la même phase lit ce qu'on lui a donné et choisit un mode (figure 4). Un fichier dans le prompt, un constat de la liste, une inquiétude, une mission ciblée sur un point faible connu, ou une demande d'analyse exhaustive : chacun répond au besoin de l'utilisateur, parce que le flux est non autoritaire par conception. Rien de tout cela n'affaiblit la base sûre par défaut. La souplesse façonne la manière dont la base est appliquée, elle ne l'abaisse jamais. ```mermaid flowchart TB shape["la phase lit la forme
de ce qu'on lui a donné"] shape --> none["aucune entrée"] shape --> paths["un ou plusieurs chemins"] shape --> concern["une préoccupation décrite"] shape --> finding["un constat nommé"] shape --> band["une tranche de priorité"] none --> auto["le mode automatique :
proposer, ou analyser
tout le périmètre"] paths --> focus["se concentrer uniquement sur
ces fichiers ou répertoires"] concern --> scoped["se limiter à
cette préoccupation"] finding --> item["agir sur ce seul
élément suivi"] band --> priority["agir uniquement sur Critical,
High, Medium ou Low"] ``` **Figure 4.** L'adaptativité non autoritaire. La même phase lit la forme de son entrée et choisit un mode, donc le périmètre appartient toujours à l'utilisateur, il n'est jamais imposé. --- ## IX. Le mode préventif universel : la même défense pendant la construction du travail Le SDH porte un mode complémentaire : le développement ordinaire, mené avec la même défense active pendant l'écriture du code. L'utilisateur demande le travail lui-même, une page de connexion, un envoi de fichiers, un endpoint, et la méthodologie protège la construction au moment où elle se fait, si bien que le résultat est sûr par défaut dès qu'il arrive, plutôt qu'après une passe de durcissement ultérieure. > **Définition** > > **Le mode préventif :** le développement ordinaire exécuté sous la couche de gouvernance et les connaissances du SDH. Les principes de sécurité encadrent la construction, les spécialisations pertinentes pour ce qui va être créé se chargent à la demande, et le résultat est confronté exactement à la défense utilisée avant que le travail soit déclaré terminé. Ce mode réutilise chaque élément que les phases portent déjà, pointé vers du code qui n'existe pas encore. La détection du contexte passe du code à l'intention : l'agent raisonne sur ce qu'il s'apprête à construire et sur les frontières que traverse ce travail (une connexion implique des identifiants, une session et des entrées venues de l'extérieur), et c'est à ce raisonnement que le catalogue de connaissances est confronté. Le prompt à la demande (`§VII`) se généralise ici : le contexte peut être détecté dans le plan du code, pas seulement dans du code existant. Les principes de sécurité gouvernent comme toujours, et une demande qui enfreindrait un principe est signalée comme un conflit, jamais construite. La défense est appliquée au fil de l'écriture, au moment où chaque partie est écrite, en validant à la frontière et en choisissant la construction sûre dès le départ, si bien qu'une version fonctionnelle mais non sûre n'existe jamais et n'a pas à être corrigée. Le mode se termine là où verify commence. Avant que le travail soit déclaré terminé, celui qui construit confronte son propre résultat à la défense qu'il a utilisée : la mesure doit se trouver sur le chemin du risque, pas à côté, elle doit être complète, et là où une spécialisation porte un vérificateur déterministe, le verdict du vérificateur prime sur la propre lecture de l'agent. Un écart trouvé à ce stade est comblé dans le cadre du même travail, parce que finir le travail, c'est le finir de façon sécurisée. Ce que le mode refuse est aussi délibéré que ce qu'il fait. Il ne construit que ce qui a été demandé et n'audite rien autour : auditer l'existant relève des phases. Il n'écrit aucun artefact et ne suit aucun constat, parce qu'un constat est un risque détecté dans l'existant, et que le but de ce mode est que la version non sûre n'arrive jamais. Les deux directions se complètent : les phases clôturent ce qui est déjà là (`§V`), et le mode préventif empêche le nouveau travail de le rouvrir. Une chaîne au repos reste au repos non parce que le développement s'est arrêté, mais parce que ce qui est construit pendant ce repos est construit défendu. --- ## X. Security-Driven Hardening face au Spec-Driven Development Le Security-Driven Hardening (SDH) est né du socle du Spec-Driven Development (SDD) avant de s'en écarter nettement. L'héritage structurel est réel et assumé : spec-first, piloté par agent, un document de gouvernance et un ensemble de commandes par phase qu'exécute l'agent. Le SDH réutilise délibérément cette structure. Ce qui diffère, ce sont le but, le modèle d'autorité, l'état supposé et la condition de fin. Nous traitons le SDD comme une classe, en prenant le rapport de Piskala `[1]` comme formulation canonique de la méthodologie, Spec Kit de GitHub `[2]` comme boîte à outils canonique pour agents, et OpenSpec `[3]` comme second outil de la même famille. Le SDD renverse le développement traditionnel en rendant les spécifications exécutables : la spécification génère directement une implémentation fonctionnelle au lieu de simplement la guider `[1]`. Son ensemble de phases fait avancer une construction `[2]` (établir les principes de gouvernance, spécifier ce qu'il faut construire, planifier la stack technique, découper le plan en tâches, puis implémenter). Son document de gouvernance, une constitution de principes, est la pièce fondatrice que l'agent doit respecter tout du long. C'est le cœur de la différence. L'autorité du SDD va de la spécification vers la construction, et l'implémentation est censée la suivre. Le SDH inverse presque chaque axe de ce contrat (tableau 3). > **Idée clé** > > **La différence centrale :** l'autorité du SDD va de la spécification vers la construction, et l'implémentation est censée la suivre. Le SDH est non autoritaire et va dans l'autre sens, vers l'intérieur à partir du contexte détecté du système, en durcissant ce qui est déjà là. | Axe | SDD | SDH | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Objectif | Livrer des fonctionnalités. La spécification devient une implémentation fonctionnelle. | Durcir ce qui existe ou est en cours de construction. Chaque phase est orientée vers la défense. | | Modèle d'autorité | Autoritaire. La spécification et la constitution enferment la construction dans un périmètre qu'elle doit suivre. | Non autoritaire. Le SDH s'adapte au scénario, et l'utilisateur peut reformuler, supprimer ou réduire la portée. | | État supposé | Une construction qui avance à partir d'une spécification. | Indépendant de l'état : répertoire vide, projet en cours, une seule PR ou code hérité. | | Condition de fin | Se termine quand la fonctionnalité est construite. | Clôturable. Un constat atteint un état stable et n'est rouvert que lorsque le code change. | | Document de gouvernance | Une constitution de principes que l'agent doit respecter. | Des principes de sécurité formulés en termes de risques (chacun porte une ligne `Why:`), explicitement pas un contrat figé. | | Comment les connaissances grandissent | Ajouter une commande (ou étendre l'ensemble des phases). | Ajouter une spécialisation non invocable que l'agent charge à la demande : un fichier plus une ligne de catalogue, sans nouvelle commande. | | Qui il sert | Quelqu'un qui construit et fait avancer une fonctionnalité. | Tout utilisateur, développeur ou non, servi par le même flux. | | Ce qui modifie le code | La phase d'implémentation génère la construction. | Seule la phase harden modifie le code, un correctif à la fois. | **Tableau 3.** Le SDD face au SDH sur huit axes. Une structure empruntée, un contrat inversé. Pour être juste envers cette filiation : le SDD est une antériorité éprouvée, et le SDH lui doit la structure sur laquelle il repose. L'écart n'est pas une critique du SDD, qui résout bien un autre problème (faire avancer une construction). Le SDH reprend la même mécanique éprouvée et l'oriente vers la défense, l'adaptativité et la clôture. OpenSpec `[3]`, organisé autour de propositions de changement, de listes de tâches et de spécifications par changement, confirme le motif : la famille fait avancer une construction à partir d'une spécification, là où le SDH durcit un système vers l'intérieur à partir de son contexte détecté. Même le mode préventif du SDH (`§IX`), le seul endroit où il accompagne une construction qui avance, conserve le contrat inversé : il gouverne la manière dont le travail est construit et ne décide jamais de ce qu'il faut construire. --- ## XI. Rigueur d'ingénierie : la discipline du suivi La discipline "mettre en cohérence, jamais seulement ajouter" (`§V`) a besoin d'un socle qui survive aux refactorisations. Un constat doit rester un seul élément dans chaque phase qui le touche, et un fichier renommé ou déplacé ne doit pas casser la chaîne. Le SDH résout ce problème avec l'**identité par le nom** et des **chemins conservés uniquement dans le suivi**. > **Définition** > > **Identité par le nom :** l'identité d'un constat est son nom, écrit à l'identique dans chaque artefact. Le texte porte le nom, jamais un chemin. Les chemins de fichiers ne se trouvent que dans la carte de suivi, donc un renommage ou un fichier déplacé ne casse le lien qu'à un seul endroit. Chaque constat de detect est un élément suivi. Son identité est son **nom**, le titre de section, écrit à l'identique dans la cartographie, le plan et le registre de durcissement. Les phases suivantes réutilisent ce nom tel quel lorsqu'elles agissent sur le même élément, et verify écrit son verdict dans le registre de durcissement sous ce même nom. La carte de suivi ne contient que du suivi, une entrée par élément : ```json { "name": "File uploads", "paths": ["src/routes/upload.ts"] } ``` La carte n'enregistre ni texte, ni annotation, ni identifiant distinct, ni phase. Les artefacts rédigés portent la formulation, et la carte ne porte que l'identité et les chemins. Les chemins de fichiers sont la seule donnée volatile, et ils ne se trouvent qu'ici. Un renommage ou un fichier déplacé ne peut casser le lien qu'à un seul endroit, jamais dans deux copies divergentes. ```mermaid flowchart TB detect["la cartographie"] --> name plan["le plan de défense"] --> name harden["le registre de durcissement
verify y écrit son verdict"] --> name name["nom = "File uploads"
le texte porte le nom, jamais un chemin"] name -.-> tracking tracking["la carte de suivi
{ name: "File uploads",
paths: ["src/routes/upload.ts"] }
le chemin ne se trouve qu'ici, donc un renommage ne corrige que cette entrée"] ``` **Figure 5.** Le convoyeur d'identité. Un même nom de constat traverse chaque artefact, tandis que son chemin ne se trouve que dans la carte de suivi, donc un renommage se corrige à un seul endroit. Deux actes entretiennent la carte dans le flux normal, et un troisième se tient à part, comme maintenance. **Track** est un enregistrement additif : une phase signale les constats qu'elle a écrits, et le moteur enregistre les nouveaux et suit un chemin renommé pour les autres, en classant chacun comme nouveau, déplacé ou inchangé. Il ne supprime jamais rien que la phase n'ait pas signalé. **Untrack** retire les constats que verify a clôturés : en une seule passe déterministe, il condense chacun en son entrée d'historique, supprime toute sa section des artefacts, efface un artefact dont le dernier constat a disparu et supprime son entrée de suivi, si bien que l'agent ne fait rien de tout cela à la main. Là où la passe déterministe ne peut pas aller sans risque, un nom retiré encore cité dans le texte d'un autre constat, il signale l'endroit à l'agent au lieu de deviner une modification. Ce sont ces deux actes que les phases appellent pendant leur exécution. **Repair** est l'acte de maintenance : une phase lui délègue automatiquement le travail quand sa propre mise en cohérence trouve le suivi incohérent (un chemin enregistré qui n'existe plus), et sinon il s'exécute à la demande. Il réaligne toute la carte d'un coup, en lisant chaque artefact et le code actuel, en corrigeant les chemins de chaque élément et en faisant ressortir ce qu'il ne peut pas trancher seul : un orphelin (un élément suivi qu'aucun artefact ne nomme plus) ou un candidat au renommage (un élément dont les chemins correspondent à un autre nom signalé). Repair est de la maintenance, pas une sixième phase. Il ne touche ni au code de l'utilisateur ni aux artefacts rédigés, seulement au suivi. Il lit le code source de l'utilisateur pour une seule raison, connaître le nouveau chemin d'un fichier renommé, et il ne rédige jamais de contenu de sécurité. L'humain est l'arbitre final sur la seule question que le moteur refuse de deviner : un élément disparu a-t-il été résolu ou simplement renommé ? Mieux vaut demander que deviner, car un élément supprimé à tort casse la chaîne. La méthodologie s'applique à elle-même sa propre discipline de défense. Les moteurs déterministes sont invoqués comme des programmes en ligne de commande, et chaque entrée est passée comme un argument de processus distinct, ce qui la rend inerte : une valeur contenant des guillemets ou des backticks ne peut jamais s'injecter dans la commande. Une vérification inconnue échoue au lieu de répondre, donc une vérification mal orthographiée ne passe jamais pour un résultat propre. Le SDH n'exempte pas sa propre plomberie du principe de sûreté par défaut. --- ## XII. Le support : une architecture indépendante de l'agent comme preuve de portabilité Pour que le SDH soit une convention que d'autres adoptent, il ne doit être lié ni à un agent ni à une stack, donc son support sépare trois responsabilités (figure 6). Lagune prouve que c'est réalisable. **La valeur de sécurité** est écrite une seule fois et ne sait rien de l'agent qui l'exécute : les instructions des phases et les modèles qu'elles remplissent, le catalogue de connaissances et les moteurs déterministes. **La distribution** est mince : sa seule mission est d'apporter cette valeur à un agent donné, sous la forme et à l'endroit qu'il attend, et elle ne porte aucune logique de sécurité propre. **L'état du projet** appartient au projet : les principes de sécurité, les artefacts des phases, la carte de suivi, les catégories qu'il a choisies et ses propres spécialisations, commités et relisibles comme n'importe quelle autre partie de son code. ```mermaid flowchart TB value["la valeur de sécurité, écrite une seule fois
instructions des phases · modèles · catalogue de connaissances · moteurs déterministes
ne sait rien de l'agent qui l'exécute"] delivery["la distribution
apporte cette valeur à chaque agent sous la forme qu'il attend
ne porte aucune logique de sécurité"] agent["l'agent
exécute les phases"] project["l'état du projet
commité avec son code
principes de sécurité · artefacts des phases · suivi · catégories · spécialisations propres"] value --> delivery --> agent agent -->|"lit et écrit"| project ``` **Figure 6.** Le support indépendant de l'agent. La valeur de sécurité est écrite une seule fois, une distribution mince l'apporte à chaque agent, et l'état reste celui du projet. Comme la distribution ne porte aucune logique de sécurité, la façon dont elle est construite ne change rien au SDH. Un support peut construire lui-même la distribution ou la confier à un écosystème qui distribue déjà des skills d'agent, comme le fait l'implémentation de référence, et les phases, leurs artefacts et leurs garanties restent les mêmes. Rien de tout cela n'est propre à un langage ou à un runtime non plus. L'implémentation de référence se trouve écrite dans une stack donnée, mais la méthodologie est la frontière entre ces responsabilités, pas la chaîne d'outils qui les construit. La même conception pourrait être réimplémentée dans un tout autre langage sans changer ce qu'est le SDH. --- ## XIII. Cas pratique : le SDH de bout en bout > **Cas pratique** > > **Durcissement défensif d'une surface d'envoi de fichiers et d'administration.** > **Contexte :** une petite application qui accepte des fichiers envoyés par les utilisateurs et les liste sur une page d'administration. > **Schéma :** charter → detect (avec des connaissances à la demande activées par le contexte) → plan → harden → verify, avec une clôture et un véritable échec. > **Résultat (capacité) :** un risque dont la clôture est vérifiée, retiré de toute la chaîne, et une mesure vérifiée comme _non_ clôturée, renvoyée vers harden. Le verdict reflète le code, pas le registre. _Ceci est un exemple illustratif du fonctionnement de la méthodologie, pas une étude mesurée sur le terrain, et il ne rapporte aucune métrique d'efficacité._ Un parcours continu montre la méthodologie en action, et pas seulement ses parties. Nous prolongeons le fil de l'envoi de fichiers de `§IV` avec une activation de connaissances à la demande et une clôture, et nous incluons un véritable échec. 1. **charter** propose le principe "Toute entrée est non fiable tant qu'elle n'a pas été validée", avec son risque en langage courant : une entrée non vérifiée est le moyen le plus courant de casser un système. 2. **detect** analyse la route d'envoi et la petite page d'administration qui liste les fichiers envoyés. Il détecte le constat sur l'envoi (le handler fait confiance au type MIME du client). La page d'administration s'exécute dans le navigateur, un contexte que reconnaît le prompt à la demande (`§VII`), donc detect charge la spécialisation de ce contexte et fait ressortir un second constat : un endroit où un nom de fichier est écrit dans la page sous forme de balisage plutôt que de texte, si bien qu'un nom forgé peut s'exécuter comme script dans le navigateur du visiteur. Les spécialisations dont le contexte est absent de ce périmètre ne se chargent jamais, et chaque écart est consigné avec l'absence lue dans le code. 3. **plan** attribue au correctif de l'envoi la priorité Critical, rattachée au principe : vérifier le type réel et la taille du fichier, renommer à l'enregistrement, stocker là où du code ne peut pas s'exécuter. Il attribue au second correctif la priorité High : afficher le nom de fichier comme du texte, pas comme du balisage. 4. **harden** applique d'abord le correctif de l'envoi (priorité la plus élevée) et le consigne Applied, puis le second, Applied. 5. **verify** lit chaque endroit et confronte le code au registre. La mesure sur l'envoi est efficace : le handler détecte le type réel à partir du contenu, impose une taille maximale et refuse le reste. Verdict : risque clôturé. Verify retire le constat de l'envoi de toute la chaîne, et son résumé condensé rejoint l'historique. Le véritable échec suit. Supposons que le second correctif de harden ait ajouté un utilitaire sûr d'affichage en texte, mais laissé l'ancien appel qui écrit du balisage encore atteignable par un autre chemin de code. Verify lit la page, voit l'utilitaire sûr, et voit aussi que le chemin non sûr est toujours actif. La mesure est présente, mais le risque n'est pas clôturé. Verify refuse d'adoucir le verdict pour qu'il corresponde au registre. Il rend "risque non clôturé", consigne l'écart et renvoie vers harden. Une mesure qui ne traite pas entièrement le risque n'est pas une validation. C'est le caractère de la méthodologie en un seul exemple : une détection adaptée au contexte, des correctifs priorisés et rattachés à des principes, une application prudente, et une vérification qui rapporte l'état réel du code, quel que soit le registre. --- ## XIV. Quand utiliser le SDH, et ses limites Le SDH est rarement disproportionné comme peut l'être un processus lourd, parce qu'il est indépendant de l'état et clôturable : il se réduit à un seul fichier et à une seule préoccupation, et il atteint un état stable au lieu de laisser une charge permanente. Sa limite n'est pas la taille du projet, c'est la **profondeur d'assurance**. ```mermaid flowchart TB q1{"Le code fait-il quoi que ce soit qui touche à la sécurité ?
(entrées, authentification, données, secrets, appels externes)"} q1 -->|non| little["Le SDH apporte peu ici."] q1 -->|oui| q2{"Exécutez le SDH. Y a-t-il une exigence de conformité,
ou une fonction de sécurité dédiée ?"} q2 -->|non| baseline["Le SDH est une base défendable."] q2 -->|oui| carrier["Le SDH est le support structuré :
il appuie la revue et l'audit des experts,
il ne les remplace pas."] ``` **Figure 7.** Quand utiliser le SDH. Le critère est d'abord la pertinence pour la sécurité, puis la profondeur d'assurance, jamais la taille du projet. Là où le SDH atteint sa limite : les comportements qui n'apparaissent qu'à l'exécution du système (verify lit le code, il n'exécute pas le système), les risques qui dépendent d'une configuration ou d'un environnement que l'agent ne peut pas lire, et les contextes à fort enjeu où une revue d'expert est requise quoi qu'il arrive. Dans chacun de ces cas, le SDH apporte encore de la valeur comme premier passage structuré, mais c'est un plancher, pas un plafond. > **Idée clé** > > **La limite :** la limite du SDH est la profondeur d'assurance, pas la taille du projet. Il peut servir de base défendable presque partout, et il appuie la revue d'experts là où les enjeux l'exigent, mais il ne remplace ni les tests d'un système en fonctionnement ni le jugement d'un professionnel de la sécurité. --- ## XV. Discussion : positionnement, limites et ce que le SDH ne prétend pas Le SDH est précis sur ses limites. ### Il prolonge, il ne remplace pas Le SDH ne remplace ni les professionnels de la sécurité ni les outils Blue Team spécialisés. Il prolonge les connaissances du développeur (`§VI`). Une affirmation mesurée est la bonne : bien appliqué, le SDH **peut** clôturer efficacement de vrais risques, en particulier pour des projets qui n'auraient sinon aucun passage de sécurité. Ce n'est pas une garantie, et ce n'est pas un substitut à une revue d'expert là où les enjeux l'exigent. ### Exclusivement défensif, par construction Le SDH audite, durcit et vérifie. Il ne produit jamais d'outils offensifs, d'exploits ni de contournement de la détection à des fins nuisibles. Le contenu de sécurité à double usage n'est acceptable que dans un cadre clairement défensif et autorisé. C'est une limite stricte, pas une préférence. ### Une vérification de fond, pas de façade Verify vérifie en lisant le code et en le confrontant au registre, pas en exécutant le système. C'est une vérification statique : elle confirme qu'une mesure est présente et correcte dans le code, et elle ne prouve pas que la mesure résiste à une attaque à l'exécution. Ainsi, "impossible à déterminer à partir du code" est un verdict légitime, pas un échec dissimulé derrière une validation. Quand l'élément de preuve n'est pas dans le code (il dépend de la configuration, ou d'un chemin que l'agent ne peut pas lire), le SDH le dit au lieu de deviner. ### Un déterminisme circonscrit, et nommé L'essentiel du SDH repose sur le raisonnement de l'agent, ce qui permet son adaptation au contexte. Le déterminisme est réservé aux moteurs déterministes : les vérificateurs qu'une spécialisation peut porter (`§VII`) et le moteur de suivi (`§XI`). Le document ne brouille pas cette frontière. Là où un résultat est déterministe, c'est le résultat d'un programme. Là où il est raisonné, c'est la lecture du code par l'agent, avec l'utilisateur comme arbitre final. ### Coût et échelle Une analyse complète consomme beaucoup de tokens. Les modes manuels (`§VI`, `§VIII`) existent en partie pour garder le coût proportionnel à la préoccupation. ### L'utilisateur est l'arbitre final Le SDH demande à l'humain de trancher entre renommé et résolu, et l'approbation de ses modifications du code reste là où l'utilisateur gouverne déjà son agent, dans le mode d'autorisation où il l'exécute. La méthodologie propose et vérifie. Elle ne passe pas outre la personne. ### Objections et réponses Un sceptique de bonne foi soulèvera plusieurs objections. Les plus substantielles méritent d'être posées dans leurs propres termes. **"N'est-ce pas juste un analyseur statique avec un LLM greffé dessus ?"** Non. Un analyseur statique exécute toutes ses règles par défaut. Le SDH détecte d'abord ce qu'est le système, puis va chercher les connaissances pertinentes (`§II`, `§VII`), et il n'_intègre_ un vérificateur déterministe que là où une classe de risques dispose d'une procédure de décision nette. Le raisonnement part du contexte, le déterminisme est ciblé. **"N'est-ce pas juste une checklist de sécurité ?"** Non. Le SDH inverse la checklist : la détection vient d'abord, et les connaissances sont chargées pour ce que fait réellement le projet (`§II`, `§VII`). **"N'est-ce pas juste du SDD rebaptisé pour la sécurité ?"** Non. Le SDH emprunte la structure du SDD et inverse son contrat : l'autorité, l'état supposé, la condition de fin et le public servi diffèrent tous (`§X`). Même mécanique, direction opposée. **"Une méthode raisonnée par IA n'invente-t-elle pas simplement des constats ?"** La conception contraint l'invention au lieu de compter sur le bon comportement du modèle. Detect ne consigne que ce que le code étaye ("la détection, pas l'invention", `§IV`), verify confronte le code au registre et peut répondre "impossible à déterminer à partir du code" (`§XV`), des vérificateurs déterministes ancrent les cas décidables (`§VII`), et l'utilisateur est l'arbitre final. Cela ne rend pas l'agent infaillible, cela rend ses affirmations vérifiables. Une remarque sur le positionnement. Le SDH est défini ici indépendamment de son implémentation de référence. Les cinq phases, les principes de sécurité formulés en termes de risques, la règle "mettre en cohérence, jamais seulement ajouter" et sa clôturabilité, les connaissances chargées par prompt à la demande, le mode préventif, le suivi par identité de nom et la limite exclusivement défensive constituent la méthodologie. Une autre équipe pourrait les implémenter dans une autre stack et un autre écosystème d'agents, et le résultat serait toujours du SDH. Lagune en est la preuve, pas la définition. --- ## XVI. Les écueils, et comment le SDH les évite structurellement Les méthodologies de cette famille partagent un ensemble connu de modes de défaillance. La réponse du SDH à la plupart d'entre eux est structurelle, intégrée au flux plutôt que laissée à la discipline. | Écueil | La défaillance | La réponse structurelle du SDH | | ----------------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Spécification qui pourrit, backlog périmé | Les artefacts accumulent des entrées mortes auxquelles plus personne ne se fie | Mettre en cohérence, jamais seulement ajouter (`§V`) : chaque exécution revérifie chaque entrée et supprime ce qui est résolu | | Fausse confiance, validation trompeuse | On suppose qu'une mesure présente clôture le risque | Verify confronte le code au registre, donc "risque non clôturé" et "impossible à déterminer" sont des verdicts à part entière (`§IV`, `§XV`) | | Avalanche de checklists | Des éléments génériques masquent le seul risque qui compte | Le contexte plutôt que le générique, avec un prompt à la demande qui ne charge que ce que le périmètre exige (`§VII`) | | Dépendance à un outil | La méthode est soudée à un seul éditeur ou agent | Un support indépendant de l'agent : la valeur de sécurité est écrite une seule fois, et sa distribution à chaque agent ne porte aucune logique de sécurité (`§XII`) | | La boucle sans fin | Le backlog ne se ferme jamais, le travail n'est jamais au repos | La clôturabilité et l'état de repos (`§V`) | **Tableau 4.** Les écueils connus de cette famille de méthodologies et la réponse structurelle du SDH à chacun. Nommer l'écueil et désigner le mécanisme, c'est tout l'intérêt : ce ne sont pas des avertissements à la prudence, ce sont des propriétés du flux. --- ## XVII. Travaux futurs La méthodologie et son implémentation de référence ont des prochaines étapes claires. - **Faire grandir le catalogue de connaissances :** Chaque ajout garde la forme de `§VII` : un fichier de connaissances et une ligne de catalogue, sans nouvelle commande. La voie côté utilisateur existe déjà : l'utilisateur condense ses propres spécialisations à la demande. Davantage de langages, de runtimes et de classes de risques intégrés, chacun rejoignant une catégorie, constituent la direction côté mainteneur, et les spécialisations sont appelées à évoluer. - **Davantage de vérificateurs déterministes :** Là où une classe de risques dispose d'une procédure de décision nette, une spécialisation peut porter un vérificateur déterministe qui ancre le raisonnement de l'agent dans un verdict reproductible. L'étendre à davantage de classes de risques est une direction naturelle. - **Évaluation empirique :** La question ouverte la plus importante est l'efficacité mesurée : la qualité des clôtures et les taux de faux verdicts sur de vraies bases de code. Une étude des résultats de sécurité du SDH relève des travaux futurs, et les affirmations de ce document sont circonscrites en conséquence. --- ## XVIII. Conclusion Le développement assisté par IA a ouvert une brèche de sécurité que les checklists génériques ne peuvent pas combler, parce que le risque qui compte est propre à ce que fait réellement un système, et que la personne qui le livre ne sait peut-être pas quoi demander. Le SDH comble cette brèche avec un flux adapté au contexte, exclusivement défensif et clôturable, dans lequel les connaissances de sécurité résident dans la méthodologie et ses spécialisations à la demande, une base sur laquelle chaque utilisateur peut construire. Il détecte le contexte réel du système, trie les risques que porte ce contexte, applique les correctifs avec prudence et vérifie chacun, puis retire ce qu'il a clôturé pour que chaque constat atteigne un état final. La même défense s'exécute aussi de façon préventive pendant la construction du nouveau travail, pour que ce que le flux clôture reste clôturé. Il s'adapte à n'importe quel état de développement dans n'importe quelle stack, et il prolonge les connaissances du développeur au lieu de remplacer les personnes et les outils qui font déjà ce travail. Lagune en est la preuve, mais la contribution est la convention. Le SDH est proposé comme le flux de sécurité essentiel de l'ère du développement avec l'IA, pour que d'autres l'adoptent, l'affinent et l'implémentent dans leurs propres stacks. --- ## Références **[1]** D. B. Piskala, "Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants," arXiv preprint arXiv:2602.00180v1 [cs.SE], Jan. 2026. (Submitted to AIWare 2026.) [Online]. Available: https://arxiv.org/abs/2602.00180 **[2]** GitHub, "Spec Kit: Toolkit for Spec-Driven Development." [Online]. Available: https://github.com/github/spec-kit. Accessed: 2026. **[3]** Fission AI, "OpenSpec: Spec-Driven Development for AI Coding Assistants." [Online]. Available: https://github.com/Fission-AI/OpenSpec. Accessed: 2026. **[4]** B. Chess and G. McGraw, "Static Analysis for Security," IEEE Security & Privacy, vol. 2, no. 6, pp. 76-79, 2004, doi: 10.1109/MSP.2004.111. **[5]** OWASP Foundation, "Source Code Analysis Tools." [Online]. Available: https://owasp.org/www-community/Source_Code_Analysis_Tools. Accessed: 2026. **[6]** OWASP Foundation, "OWASP Top 10:2021." [Online]. Available: https://owasp.org/Top10/. Accessed: 2026. **[7]** MITRE, "Common Weakness Enumeration (CWE)." [Online]. Available: https://cwe.mitre.org/. Accessed: 2026. **[8]** N. Perry, M. Srivastava, D. Kumar, and D. Boneh, "Do Users Write More Insecure Code with AI Assistants?," in Proc. ACM SIGSAC Conf. on Computer and Communications Security (CCS '23), 2023, pp. 2785-2799, doi: 10.1145/3576915.3623157. [Online]. Available: https://arxiv.org/abs/2211.03622 **[9]** J. Davis and contributors, "safe-regex: Detect Possibly Catastrophic, Exponential-Time Regular Expressions." [Online]. Available: https://github.com/davisjam/safe-regex. Accessed: 2026. **[10]** D. Soshnikov, "regexp-tree: Regular Expressions Processor in JavaScript." [Online]. Available: https://github.com/DmitrySoshnikov/regexp-tree. Accessed: 2026. **[11]** T. Jenkinson, "redos-detector: A CLI and Library to Score How Vulnerable a Regex Pattern Is to ReDoS Attacks." [Online]. Available: https://github.com/tjenkinson/redos-detector. Accessed: 2026. --- ## Annexe A : les principes, mot pour mot 1. **Sûr par défaut, en langage courant, pour tous à égalité :** Chaque valeur par défaut, chaque message et chaque correctif doit être sûr d'emblée et compréhensible par tout utilisateur, développeur ou non. Aucun profil d'utilisateur n'est privilégié par rapport à un autre. 2. **Le contexte plutôt que le générique :** Chaque phase doit partir du contexte détecté par detect et agir sur ce que fait réellement le système. Préférez les recommandations propres à ce contexte aux checklists génériques. Les connaissances de sécurité résident dans la spécification et ses spécialisations à la demande, et prolongent tout ce qu'apporte l'utilisateur. 3. **La souplesse plutôt que la rigidité :** Le SDH s'adapte au projet et à l'utilisateur. Les principes, exigences et recommandations sont des points de départ, pas un contrat figé. Laissez l'utilisateur reformuler, supprimer, ajouter ou réduire la portée de n'importe quoi. La souplesse n'affaiblit jamais la base sûre par défaut, elle permet seulement à l'utilisateur de façonner la manière dont elle s'applique. 4. **Mettre en cohérence, jamais seulement ajouter :** Les artefacts sont des documents vivants, pas des journaux. Quand une phase est relancée, mettez chaque entrée existante en cohérence avec la réalité actuelle : gardez ce qui tient encore, réécrivez ce qui a changé et supprimez ce qui ne s'applique plus. La clôture est cette même mise en cohérence arrivée à son terme. 5. **Exclusivement défensif :** Le SDH audite, durcit et vérifie. Il ne produit jamais d'outils offensifs, d'exploits à usage malveillant ni de contournement de la détection à des fins nuisibles. Le contenu de sécurité à double usage n'est acceptable que dans un cadre clairement défensif et autorisé. 6. **Spec-first, piloté par agent, orienté vers la sécurité :** Construisez le workflow à partir d'une structure éprouvée : des modèles, des commandes, des principes de sécurité qui gouvernent et un agent qui exécute les phases. Réimplémentez cette structure dans un but défensif. --- # Glossaire Lagune : SDH, charter, constats et mesures de protection > Les définitions, en langage courant, de chaque terme de Lagune et du Security-Driven Hardening : SDH, charter, detect, constat, mesure de protection, harden, verify, retrait, clôture, spécialisations, catégories et catalogue. Canonique: https://lagune.ai/fr-FR/docs/references/glossary Langue: fr-FR Original: https://lagune.ai/docs/references/glossary Dernière mise à jour: 2026-11-03 Chaque terme structurant de Lagune et de la méthodologie Security-Driven Hardening, défini une seule fois, en langage courant. ### Security-Driven Hardening (SDH) La méthodologie que met en œuvre Lagune : une convention Blue Team adaptée au contexte, qui détecte le contexte d'un système, trie les risques que porte ce contexte et guide les correctifs. Les connaissances de sécurité se trouvent dans la spécification et ses spécialisations à la demande, donc un développeur et un non-développeur sont servis par le même flux. ### Lagune L'implémentation de référence du SDH : neuf commandes d'agent, chacune avec le modèle qu'elle remplit, qu'un agent IA exécute pour durcir une base de code. Chaque agent les installe avec son propre installateur de plugins ou avec [**skills.sh**](https://www.skills.sh/wellwelwel/lagune), comme l'indique la [page d'installation](https://lagune.ai/fr-FR/docs), et elles exécutent le moteur de Lagune pour chaque étape déterministe. ### Charter La couche de gouvernance de Lagune : un ensemble de principes axés sur la sécurité que chaque phase suivante doit respecter. Voyez-la comme la vérification à la compilation de la posture de sécurité d'un projet. Elle est stockée dans `.lagune/memory/charter.md`. ### Flux de développement La commande universelle `/lagune`, qui durcit le travail au fil de l'écriture. Elle accepte n'importe quel prompt, à n'importe quelle étape, construit ce que vous avez demandé et le durcit avec des valeurs par défaut sûres avant de vous le rendre, en suivant la charter quand elle existe. Elle n'écrit rien dans le suivi de Lagune, donc son seul produit est le code durci. Avec la charter (avant) et le flux Blue Team (après), c'est ainsi que Lagune protège pendant le développement. ### Flux Blue Team L'audit en cinq phases au cœur de Lagune : charter, detect, plan, harden, verify. Chaque phase s'appuie sur la précédente. La "Blue Team" est la tradition de sécurité des défenseurs, par opposition à la Red Team offensive. ### Constat Un risque détecté. Chaque constat indique ce qu'il est, pourquoi il compte et l'élément de preuve dans le code. Un constat est l'unique unité suivie que plan, harden et verify reprennent, identifiée par son nom dans chaque artefact. ### Mesure de protection Une mesure de sécurité appliquée pour fermer un risque. Harden applique les mesures de protection, verify prouve qu'elles sont efficaces. Lagune n'affaiblit jamais une mesure de protection pour satisfaire un prompt. ### Detect La phase qui lit le code et cartographie ce que fait le système et où se trouvent les risques. Sa règle directrice est la détection, pas l'invention : elle ne consigne que ce que le code étaye. ### Harden La seule phase qui touche à votre code. Elle applique les correctifs du plan un par un et consigne chacun comme Applied, Partial ou Blocked. Applied ne veut pas encore dire prouvé. ### Verify La phase qui prouve que chaque correctif appliqué est efficace, en lisant le code et en le confrontant à ce que harden a consigné. Elle rend l'un de trois verdicts : Risk closed, Risk not closed ou Cannot tell from the code. ### Retrait Quand verify prouve qu'un risque est clôturé, le constat est retiré : supprimé de toute la chaîne, avec votre confirmation, pour qu'il cesse d'être retraité. ### Clôture La propriété selon laquelle le travail de sécurité a un état final. Comme un constat dont la clôture est prouvée est retiré, le flux peut arriver au repos, et ne se rouvre que lorsque le code change. Avec le SDH, la sécurité peut être clôturée, ce n'est pas une boucle sans fin. ### Moteur Le paquet `lagune` sur **npm**, que les commandes exécutent via `npx` pour chaque étape déterministe : les hooks, le catalogue et les catégories. ### Spécialisation Un module de connaissances en sécurité ciblé et indépendant du langage, qui ne se charge qu'à la demande, jamais par défaut. Une spécialisation n'est pas une commande. Chargez-en une dans n'importe quel prompt avec `read catalog ` du moteur, par exemple `npx lagune read catalog regex`. ### Catégorie Un groupe nommé de spécialisations intégrées, de `owasp` à celles propres à un langage comme `javascript`, `python`, `go` et `rust`. Les catégories qu'utilise un projet, enregistrées dans `.lagune/configs.json`, déterminent quelles spécialisations intégrées rejoignent son catalogue. Tant qu'aucune n'est enregistrée, le projet utilise seulement `owasp`. ### Catalogue L'ensemble des spécialisations qu'utilise un projet : les intégrées de ses catégories plus les siennes, écrites avec `/lagune-specialize`. `read catalog` du moteur le liste, et les phases le confrontent au code. ### Prompt à la demande Le principe selon lequel les connaissances de sécurité pertinentes sont chargées pour ce qu'est réellement le projet, au lieu d'exécuter toutes les vérifications par défaut. ### Identité par le nom Le modèle de suivi de Lagune : le nom de chaque constat, écrit à l'identique comme titre de section dans chaque artefact, est son identité dans toute la chaîne. La carte de suivi (`.lagune/tracking.json`) ne contient que du suivi, jamais de texte rédigé. ## Questions fréquentes ### Qu'est-ce que le Security-Driven Hardening (SDH) ? Le SDH est une méthodologie de sécurité Blue Team adaptée au contexte. Elle détecte le contexte d'un système, trie les risques que porte ce contexte et guide les correctifs, en gardant chaque constat en langage courant. Lagune en est l'implémentation de référence. ### Qu'est-ce que la charter dans Lagune ? La charter est la couche de gouvernance de Lagune, un ensemble de principes axés sur la sécurité que chaque phase suivante doit respecter. Elle est stockée dans .lagune/memory/charter.md. ### Que signifie retirer un constat ? Quand verify prouve qu'un risque est clôturé, le constat est retiré : supprimé de toute la chaîne avec votre confirmation, pour qu'il cesse d'être retraité. --- # Schéma des configs > Le JSON Schema des configs d'un projet Lagune, pour l'autocomplétion et la validation dans votre éditeur, qui suit la version actuelle de Lagune ou est épinglé à une version. Canonique: https://lagune.ai/fr-FR/docs/references/configs-schema Langue: fr-FR Original: https://lagune.ai/docs/references/configs-schema Dernière mise à jour: 2026-11-03 `.lagune/configs.json` enregistre les [**catégories**](https://lagune.ai/fr-FR/docs/categories) qu'utilise un projet et indexe ses propres [**spécialisations**](https://lagune.ai/fr-FR/docs/catalog). Son JSON Schema permet à votre éditeur d'autocompléter chaque champ et de signaler une faute de frappe ou une catégorie inconnue pendant que vous modifiez le fichier. ## Le schéma actuel Chaque fois que **Lagune** écrit le fichier sans y trouver de `$schema`, il fait pointer le fichier vers le schéma actuel : ```json { "$schema": "https://lagune.ai/schemas/configs.json", "categories": ["owasp", "javascript"] } ``` Cette adresse suit toujours la version actuelle de **Lagune**. Un fichier écrit avant **Lagune** 0.16.0 la reçoit à sa prochaine modification, et chaque phase le signale d'ici là. ## Épingler une version Chaque version de **Lagune** à partir de la 0.16.0 embarque le schéma tel qu'il était dans cette version, publié sur **npm** et servi par **jsDelivr**. Pour en épingler une, indiquez la version après `lagune@` dans l'adresse de `$schema` : ```json { "$schema": "https://cdn.jsdelivr.net/npm/lagune@0.16.0/schemas/configs.json" } ``` La version accepte n'importe quelle plage semver : | Version | Schéma | | ------------------ | --------------------------------- | | `0.16.0` | Celui de la 0.16.0 | | `0.16.x` ou `0.16` | Celui de la dernière version 0.16 | | `0.x` ou `0` | Celui de la dernière version 0.x | | `latest` | Celui de la dernière version | ## Questions fréquentes ### Lagune a-t-il besoin du schéma ? Non. Le schéma ne sert qu'à votre éditeur, et Lagune lit le fichier de la même façon avec ou sans $schema. ### Lagune écrasera-t-il un schéma épinglé ? Non. Lagune n'écrit $schema que si le fichier n'en a pas, et garde toute adresse que vous avez définie. ### Quand épingler une version ? Quand le projet utilise une version précise de Lagune, pour que votre éditeur valide le fichier selon ce qu'accepte cette version. --- # Lagune vs Deepsec : deux approches de la sécurité pilotées par IA, côte à côte > Une comparaison de référence entre Lagune et Deepsec de Vercel, sur leur fonctionnement, leur cycle de vie, la détection, le coût, les constats et la clôture. Canonique: https://lagune.ai/fr-FR/docs/references/deepsec Langue: fr-FR Original: https://lagune.ai/docs/references/deepsec Dernière mise à jour: 2026-11-03 [Lagune](https://github.com/wellwelwel/lagune) et [Deepsec](https://github.com/vercel-labs/deepsec) (`v2.2.1`) sont deux réponses défensives au même problème : la sécurité à l'ère du développement assisté par IA. Leur prémisse, leur début, leur milieu et leur fin, ainsi que la façon dont chacun se présente à l'utilisateur, divergent par conception, même là où leurs mécanismes se recoupent. **Astuce** Lagune s'inspire-t-il de Deepsec ? Non, Lagune a été écrit à partir de zéro et s'inspire du Spec-Driven Development et du Security Hardening. Les deux projets ont été développés indépendamment, et cette comparaison vise à aider les utilisateurs à comprendre leurs différences. ## En un coup d'œil | Aspect | Lagune | Deepsec | | ------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Nature | Une méthodologie (SDH) avec une implémentation de référence | Un produit : un scanner de vulnérabilités piloté par agent | | Centre de gravité | Des principes de sécurité et des connaissances à la demande guident l'agent, en s'appuyant sur des hooks déterministes | Un large filet de regex alimente une investigation obligatoire par IA | | Ce qu'il produit | Du code durci, des preuves et une chaîne de constats suivis | Un rapport de constats triés et classés par gravité | | Touche à votre code | Oui : `harden` modifie votre code | Non : uniquement de l'analyse statique, il émet des constats et des recommandations écrites | | Exécution | Tourne sur l'agent et le modèle que vous utilisez déjà, quel que soit le niveau | Fait tourner son propre pipeline de modèles, un modèle de pointe par défaut | | Prise en main | Une installation de plugin ou `npx skills add`, puis pilotage en langage courant, sans nouvel outil à mettre en place | Mettre en place un workspace `.deepsec/`, installer les dépendances et ajouter une clé de modèle | ## Fonctionnement Lagune est centré sur l'agent : l'agent pilote, charge à la demande les connaissances adaptées à ce qu'est le code, et délègue aux hooks déterministes la part qu'il est possible de trancher. Deepsec est centré sur le déterminisme : une analyse large signale des candidats qui indiquent à un modèle obligatoire ce qu'il doit investiguer et juger. | Aspect | Lagune | Deepsec | | --------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | Ordre | Les principes de sécurité et les connaissances retenues guident l'agent, qui délègue aux hooks et juge le reste | Les matchers signalent des candidats, le modèle investigue et juge chacun | | Rôle du déterminisme | Des hooks multilangages qui rendent un verdict ou orientent l'agent, combinés aux connaissances des catégories | Des matchers qui signalent des candidats que le modèle obligatoire juge | | Flux de développement | `/lagune` construit de façon sécurisée, au fil de l'écriture du code | Il relit le code, il ne l'écrit pas | | Flux d'audit | `charter` → `detect` → `plan` → `harden` → `verify` | `scan` → `process` → `triage` → `revalidate` → `report` | | Le rôle de l'IA | Raisonner à partir des connaissances, appliquer le correctif et prouver qu'il est efficace | Investiguer chaque candidat et rapporter les constats | ## Cycle de vie Lagune intervient avant, pendant et après l'écriture du code. Deepsec relit un dépôt une fois le code écrit. | Moment | Lagune | Deepsec | | ------------------------ | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | Avant que le code existe | `charter` établit une politique de sécurité à partir de l'intention exprimée | Part du code existant : `init` a besoin d'un répertoire | | Pendant le développement | `/lagune` construit de façon sûre par défaut, sans laisser d'artefact | Relit après le développement, pas pendant | | Sur du code existant | `detect` → `plan` → `harden` → `verify` | `scan` → `process`, le flux principal | | Revue continue | Relancer les phases par périmètre, pas de contrôle de CI prêt à l'emploi | Nouvelle analyse incrémentale, `process --diff` comme contrôle de sortie en CI | ## Couche de détection Les deux couches déterministes sont de nature opposée : l'une tranche, l'autre signale. | Aspect | Lagune | Deepsec | | ------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | Regroupement | Hooks et spécialisations, regroupés en catégories | Matchers par motif ou par framework | | Sortie | Verdict littéral (finding / review / advisory) plus une étiquette de classement | Candidat sans verdict (slug, lignes, extrait, motif reconnu) | | Réglage | Précision : prise en compte des commentaires, garde-fous sur les placeholders et les fenêtres | Rappel : filets larges, l'IA élimine ensuite les faux positifs | | Profondeur | Plus profond sur les classes communes | Plus large, moins profond sur les classes communes | | Faux positifs | Maintenus bas à la source, puis jugés en contexte | Générés en excès volontairement, réduits par une passe `revalidate` | ## Connaissances et jugement Les deux portent des connaissances de sécurité que les regex ne peuvent pas porter. Ils diffèrent sur l'endroit où elles se trouvent et sur qui peut les façonner. | Aspect | Lagune | Deepsec | | ----------------------- | ------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------- | | Forme | Des modules Markdown modifiables, dont plusieurs s'appuient sur un hook déterministe | Un prompt court et des points d'attention par technologie, qui s'appuient sur les connaissances du modèle | | Sélection | Retenus selon le code, chargés seulement quand leur contexte est présent | Injectés dans chaque lot d'IA, plus les points d'attention de la technologie détectée | | Qui les rédige | L'utilisateur modifie les modules et en ajoute avec `specialize` | Le mainteneur possède le prompt, l'utilisateur remplit un `INFO.md` | | Où se situe le jugement | Les hooks tranchent leur socle, l'agent juge le reste à partir des connaissances | Centralisé : un seul processeur d'IA juge chaque candidat | | Réutilisation | Un même module guide `detect` et `verify` | Un seul prompt pilote l'unique étape `process` | ## Constats et clôture C'est sur ce que devient un constat une fois résolu qu'ils divergent le plus. | Aspect | Lagune | Deepsec | | ---------------------- | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Gravité | Un score CVSS v4.0, ajusté selon l'exposition et les enjeux | Une gravité estimée par l'IA, plus un tri P0 / P1 / P2 selon l'exploitabilité et l'impact | | Verdicts | Risk closed, not closed ou cannot tell from the code | true-positive, false-positive, fixed, uncertain, accepted-risk, duplicate | | Persistance | La chaîne de travail se met en cohérence, les constats clôturés sont condensés dans un historique | Des enregistrements par fichier en ajout seul, rien n'est supprimé | | État final | Clôturable : un constat prouvé est retiré, la chaîne peut arriver au repos | Chaque constat est conservé pour de bon, masqué des vues une fois résolu | | Détail de l'historique | Un résumé compact de ce qu'était le risque | Toute la trace des verdicts, y compris la façon dont il a été corrigé | ## Coût | Aspect | Lagune | Deepsec | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Socle déterministe | Gratuit : les hooks tournent sans IA et sans clé, et émettent déjà des verdicts | Gratuit : `scan` tourne sans IA, mais n'émet aucun verdict par lui-même | | Facture type | Intégrée à un agent que vous utilisez déjà, jusqu'à 0 $ avec un modèle local, au prix de l'abonnement que vous avez déjà, ou par itération en usage via API | [Environ 25 $ à 1 200 $ par exécution pour 100 à 2 000 fichiers, davantage à grande échelle](https://github.com/vercel-labs/deepsec/blob/f75a16803ec5250938bacfe41571d929e8564f45/docs/getting-started.md#run-the-ai-investigation) | | Option la moins chère | N'importe quel modèle, y compris un modèle local gratuit, boucle le cycle | Des offres payantes moins chères existent, mais les constats exigent l'étape d'IA payante | ## Extensibilité et gouvernance Chacun ouvre la couche que l'autre garde fermée. | Aspect | Lagune | Deepsec | | -------------------- | ---------------------------------------------------- | ----------------------------------------------------------------------- | | Ce que vous étendez | Modifier des modules, ou en ajouter via `specialize` | Ajouter des matchers, des agents, des notificateurs et des responsables | | Couche de politique | La charter gouverne chaque phase et est versionnée | La configuration est opérationnelle (matchers, modèles, chemins) | | Remplacement par nom | Un module affiné masque la spécialisation intégrée | En cas de collision de slug de matcher, le vôtre l'emporte | ## Interfaces Deepsec produit des livrables pour une organisation de sécurité. Lagune affiche une vue en direct pour la personne qui l'exécute. | Aspect | Lagune | Deepsec | | ------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | Interface humaine | Un tableau de bord local en direct de toute la chaîne, en langage courant | Des fichiers de rapport, d'export, de métriques et de commentaires de PR, plus un site de documentation | | Responsabilité | Fait ressortir les fichiers et les spécialisations appliquées | Propose une personne à qui attribuer le constat : astreinte, manager ou auteur du commit | | Preuve reproductible | `prove` écrit des tests exécutables et un avis de divulgation | Reste statique par conception, il n'exécute jamais la cible | | Autoprotection de l'outil | Durcit une API d'écriture locale sur le tableau de bord | Durcit sa propre exécution d'IA face au code cible non fiable | ## Échelle et déploiement | Aspect | Lagune | Deepsec | | ----------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------ | | Installation | Neuf commandes via le plugin de votre agent ou la CLI skills, rien n'est généré | Un workspace `.deepsec/` avec son propre paquet et ses dépendances | | Sens de l'échelle | Se limite à n'importe quelle partie, un contexte, d'un fichier à tout le projet | Parcourt des dépôts entiers, jusqu'aux grands monorepos | | Distribution | Uniquement local, le seul serveur écoute sur le loopback | Répartition facultative sur des VM de travail Vercel Sandbox | ## Expérience utilisateur Comment chacun accueille la personne qui l'exécute : ce que demande la première exécution, et comment l'opérateur l'oriente. ### Prise en main Lagune passe par l'agent déjà ouvert. Deepsec met d'abord en place son propre workspace et son accès aux modèles. | Aspect | Lagune | Deepsec | | ---------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | Première commande | L'installation du plugin ou `npx skills add wellwelwel/lagune`, puis `/lagune-*` dans l'agent | `npx deepsec init`, puis `cd .deepsec`, `pnpm install`, `scan`, `process` | | Identifiants pour l'exécuter | Pas de clé à part, il utilise votre agent actuel | Une clé de modèle (par ex. AI Gateway, un jeton OIDC Vercel de 12 heures ou un jeton Anthropic) | ### Le piloter Les deux acceptent qu'on les oriente. Lagune lit la forme de l'entrée à chaque phase. Deepsec restreint l'ensemble de fichiers sur lequel s'exécute la même investigation. | Aspect | Lagune | Deepsec | | ----------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------- | | Tout le projet | Une phase sans entrée analyse tout le périmètre | `scan` et `process` parcourent le dépôt | | Une partie | N'importe quelle phase se limite à des fichiers ou répertoires donnés | `--files`, `--files-from` ou `--diff` restreignent l'exécution | | Une préoccupation | Une phase se limite à une inquiétude décrite | Le prompt d'investigation est figé | | Une tranche de priorité | `harden` et `verify` se limitent à Critical, High, Medium ou Low | Les constats sont étiquetés après l'exécution | | Une seule valeur | Un hook évalue directement un extrait, un motif ou une URL (`--pattern`, `--url`) | L'unité de travail est le fichier | ## Questions fréquentes ### En quoi Lagune diffère-t-il de Deepsec ? Lagune est centré sur l'agent et intervient avant, pendant et après l'écriture du code : il fixe une politique avant le code, durcit au fil du développement, et audite, durcit et vérifie le code déjà écrit. Deepsec est centré sur le déterminisme : une large analyse par regex alimente une investigation obligatoire par un modèle de pointe, qui relit le code existant et rapporte des constats, sans le modifier. ### Peut-on utiliser l'un ou l'autre gratuitement ? Tout le flux de Lagune peut tourner pour 0 $ avec un modèle local gratuit, et ses hooks déterministes émettent des verdicts sans aucune IA. L'analyse de Deepsec est gratuite mais n'émet aucun verdict, donc tout constat exige son étape d'IA payante. ### L'un ou l'autre modifie-t-il mon code ? Lagune, oui : harden applique des correctifs à votre code. Deepsec, non : il ne fait que de l'analyse statique et émet des constats et des recommandations écrites qu'une personne ou un agent applique séparément. --- # Sources OWASP > D'où viennent les connaissances des spécialisations OWASP intégrées, mises en correspondance avec les pages canoniques d'attaques et de Cheat Sheets de l'OWASP. Canonique: https://lagune.ai/fr-FR/docs/references/owasp-sources Langue: fr-FR Original: https://lagune.ai/docs/references/owasp-sources Dernière mise à jour: 2026-11-03 Ce document met en correspondance chaque **attaque** (`www-community`) et chaque **Cheat Sheet** (`CheatSheetSeries`) de l'OWASP avec une catégorie de sécurité, chacune liée à sa page publique canonique. Au sein d'une catégorie, les éléments équivalents partagent une seule ligne de la checklist : les attaques et les cheat sheets qui traitent le même risque sont listées ensemble, séparées par des virgules. Les éléments sans équivalent direct ont leur propre ligne. - Le mérite revient à l'OWASP. Les attaques se trouvent sur `https://owasp.org/www-community/attacks/` et les cheat sheets sur `https://cheatsheetseries.owasp.org/cheatsheets/.html`. --- ## 1. Injection (générique) - [x] [Code Injection](https://owasp.org/www-community/attacks/Code_Injection), [Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html), [Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_in_Java_Cheat_Sheet.html) (interpreter) - [x] [Direct Dynamic Code Evaluation (Eval Injection)](https://owasp.org/www-community/attacks/Direct_Dynamic_Code_Evaluation_Eval_Injection) (interpreter) - [x] [Function Injection](https://owasp.org/www-community/attacks/Function_Injection) (interpreter) - [x] [Resource Injection](https://owasp.org/www-community/attacks/Resource_Injection) (network) - [x] [Special Element Injection](https://owasp.org/www-community/attacks/Special_Element_Injection) (interpreter) - [x] [Custom Special Character Injection](https://owasp.org/www-community/attacks/Custom_Special_Character_Injection) (interpreter) - [x] [Comment Injection Attack](https://owasp.org/www-community/attacks/Comment_Injection_Attack) (interpreter) - [x] [Parameter Delimiter](https://owasp.org/www-community/attacks/Parameter_Delimiter) (interpreter) - [x] [Server-Side Includes (SSI) Injection](https://owasp.org/www-community/attacks/Server-Side_Includes_%28SSI%29_Injection) (interpreter) - [x] [Input Validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html), [Bean Validation](https://cheatsheetseries.owasp.org/cheatsheets/Bean_Validation_Cheat_Sheet.html) (interpreter) --- ## 2. Injection SQL et en base de données - [x] [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection), [SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html), [Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) (sql) - [x] [Blind SQL Injection](https://owasp.org/www-community/attacks/Blind_SQL_Injection) (sql) - [x] [SQL Injection Bypassing WAF](https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF) (sql) - [x] [RSQL Injection](https://owasp.org/www-community/attacks/RSQL_Injection) (interpreter) - [x] [Database Security](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html) (sql) - [x] [NoSQL Security](https://cheatsheetseries.owasp.org/cheatsheets/NoSQL_Security_Cheat_Sheet.html) (interpreter) --- ## 3. Injection de commandes du système - [x] [Command Injection](https://owasp.org/www-community/attacks/Command_Injection), [OS Command Injection Defense](https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html) (interpreter) --- ## 4. Injection LDAP, XPath et XML - [x] [LDAP Injection](https://owasp.org/www-community/attacks/LDAP_Injection), [LDAP Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html) (interpreter) - [x] [XPATH Injection](https://owasp.org/www-community/attacks/XPATH_Injection) (interpreter) - [x] [Blind XPath Injection](https://owasp.org/www-community/attacks/Blind_XPath_Injection) (interpreter) - [x] [XML External Entity (XXE) Prevention](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html), [XML Security](https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html) (xml) --- ## 5. Cross-Site Scripting (XSS) - [x] [Cross Site Scripting (XSS)](https://owasp.org/www-community/attacks/Cross-site-Scripting-%28XSS%29), [Cross Site Scripting Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html), [XSS Filter Evasion](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) (browser) - [x] [DOM Based XSS](https://owasp.org/www-community/attacks/DOM_Based_XSS), [DOM based XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html), [DOM Clobbering Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html) (browser) - [x] [Reflected DOM Injection](https://owasp.org/www-community/attacks/Reflected_DOM_Injection) (browser) - [x] [XSS in Converting File Content to Text](https://owasp.org/www-community/attacks/XSS_in_Converting_File_Content_to_Text) (browser) - [x] [XSS in subtitle](https://owasp.org/www-community/attacks/Xss_in_subtitle) (browser) - [x] [Cross Frame Scripting](https://owasp.org/www-community/attacks/Cross_Frame_Scripting) (browser) - [x] [Cross Site Tracing](https://owasp.org/www-community/attacks/Cross_Site_Tracing) (browser) - [x] [Content Security Policy](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) (browser) --- ## 6. Cross-Site Request Forgery (CSRF) et clickjacking - [x] [Cross Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/cross-site-request-forgery), [XSRF](https://owasp.org/www-community/attacks/XSRF), [Cross-Site Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) (http-request) - [x] [Clickjacking](https://owasp.org/www-community/attacks/Clickjacking), [Clickjacking Defense](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html) (browser) - [x] [Cross Site History Manipulation (XSHM)](https://owasp.org/www-community/attacks/Cross_Site_History_Manipulation_%28XSHM%29) (browser) - [x] [Form action hijacking](https://owasp.org/www-community/attacks/Form_action_hijacking) (network) - [x] [Reverse Tabnabbing](https://owasp.org/www-community/attacks/Reverse_Tabnabbing) (browser) --- ## 7. Redirections et transferts - [x] [Open Redirect](https://owasp.org/www-community/attacks/open_redirect), [Unvalidated Redirects and Forwards](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html) (network) - [x] [Execution After Redirect (EAR)](https://owasp.org/www-community/attacks/Execution_After_Redirect_%28EAR%29) (browser) --- ## 8. Contrôle d'accès et autorisation - [x] [Insecure Direct Object Reference (IDOR)](https://owasp.org/www-community/attacks/insecure_direct_object_reference), [Insecure Direct Object Reference Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html) (access-control) - [x] [Forced browsing](https://owasp.org/www-community/attacks/Forced_browsing) (access-control) - [x] [Web Parameter Tampering](https://owasp.org/www-community/attacks/Web_Parameter_Tampering) (access-control) - [x] [Setting Manipulation](https://owasp.org/www-community/attacks/Setting_Manipulation) (access-control) - [x] [Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) (access-control) - [x] [Transaction Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html) (access-control) - [x] [Mass Assignment](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html) (access-control) - [x] [Multi-Tenant Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html) (access-control) --- ## 9. Authentification et identifiants - [x] [Brute Force Attack](https://owasp.org/www-community/attacks/Brute_force_attack), [Password Spraying Attack](https://owasp.org/www-community/attacks/Password_Spraying_Attack), [Bot Management and Anti-Automation](https://cheatsheetseries.owasp.org/cheatsheets/Bot_Management_and_Anti-Automation_Cheat_Sheet.html) (credential-endpoint) - [x] [Credential stuffing](https://owasp.org/www-community/attacks/Credential_stuffing), [Credential Stuffing Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) (credential-endpoint) - [x] [Qrljacking](https://owasp.org/www-community/attacks/Qrljacking) (federation) - [x] [Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html), [Multifactor Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html) (access-control) - [x] [Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) (access-control) - [x] [Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html), [Choosing and Using Security Questions](https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html) (access-control) - [x] [Email Validation and Verification in Identity Systems](https://cheatsheetseries.owasp.org/cheatsheets/Email_Validation_and_Verification_Cheat_Sheet.html) (access-control) --- ## 10. Gestion des sessions - [x] [Session fixation](https://owasp.org/www-community/attacks/Session_fixation), [Session hijacking attack](https://owasp.org/www-community/attacks/Session_hijacking_attack), [Session Prediction](https://owasp.org/www-community/attacks/Session_Prediction), [Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) (access-control) - [x] [Cookie Theft Mitigation](https://cheatsheetseries.owasp.org/cheatsheets/Cookie_Theft_Mitigation_Cheat_Sheet.html) (access-control) --- ## 11. Fédération d'identité (OAuth / SAML / JWT) - [x] [OAuth 2.0 Protocol](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html) (federation) - [x] [SAML Security](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html) (federation) - [x] [JSON Web Token for Java](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) (federation) --- ## 12. Cryptographie et sécurité du transport - [x] [Cryptanalysis](https://owasp.org/www-community/attacks/Cryptanalysis), [Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html), [Key Management](https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html) (crypto) - [x] [Manipulator-in-the-Middle (MITM)](https://owasp.org/www-community/attacks/Man-in-the-middle_attack), [Transport Layer Security](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) (transport) - [x] [HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) (transport) - [x] [Pinning](https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html) (transport) --- ## 13. Server-Side Request Forgery (SSRF) - [x] [Server Side Request Forgery](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery), [Server-Side Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) (network) --- ## 14. Path traversal et manipulation de fichiers - [x] [Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) (path) - [x] [Binary Planting](https://owasp.org/www-community/attacks/Binary_planting) (path) - [x] [Windows ::DATA Alternate Data Stream](https://owasp.org/www-community/attacks/Windows_DATA_alternate_data_stream) (path) - [x] [Embedding Null Code](https://owasp.org/www-community/attacks/Embedding_Null_Code) (path) - [x] [File Upload](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) (upload) --- ## 15. Abus du protocole HTTP (en-têtes, cache, splitting) - [x] [HTTP Response Splitting](https://owasp.org/www-community/attacks/HTTP_Response_Splitting), [Cross-User Defacement](https://owasp.org/www-community/attacks/Cross-User_Defacement) (interpreter) - [x] [HTTP Security Response Headers](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html) (réparti entre browser, transport, http-request et access-control) - [x] [Cache Poisoning](https://owasp.org/www-community/attacks/Cache_Poisoning) (interpreter) - [x] [IP Spoofing via HTTP Headers](https://owasp.org/www-community/attacks/ip_spoofing_via_http_headers) (http-request) --- ## 16. Encodage et usurpation de contenu - [x] [Unicode Encoding](https://owasp.org/www-community/attacks/Unicode_Encoding) (interpreter) - [x] [Double Encoding](https://owasp.org/www-community/Double_Encoding) (interpreter) - [x] [Content Spoofing](https://owasp.org/www-community/attacks/Content_Spoofing) (browser) --- ## 17. Injection dans les CSV et les tableurs - [x] [CSV Injection](https://owasp.org/www-community/attacks/CSV_Injection) (csv) --- ## 18. CORS (Cross-Origin Resource Sharing) - [x] [CORS OriginHeaderScrutiny](https://owasp.org/www-community/attacks/CORS_OriginHeaderScrutiny) (http-request) - [x] [CORS RequestPreflightScrutiny](https://owasp.org/www-community/attacks/CORS_RequestPreflightScrutiny) (http-request) --- ## 19. Déni de service - [x] [Regular expression Denial of Service (ReDoS)](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) (regex) --- ## 20. Sûreté mémoire et code natif - [x] [Buffer Overflow Attack](https://owasp.org/www-community/attacks/Buffer_overflow_attack), [Buffer Overflow via Environment Variables](https://owasp.org/www-community/attacks/Buffer_Overflow_via_Environment_Variables) (c-cpp) - [x] [Format string attack](https://owasp.org/www-community/attacks/Format_string_attack) (c-cpp) --- ## 21. Code mobile et exécution de code non fiable - [x] [Mobile code invoking untrusted mobile code](https://owasp.org/www-community/attacks/Mobile_code_invoking_untrusted_mobile_code) (interpreter) - [x] [Mobile code non-final public field](https://owasp.org/www-community/attacks/Mobile_code_non-final_public_field) (java) - [x] [Mobile code object hijack](https://owasp.org/www-community/attacks/Mobile_code_object_hijack) (java) --- ## 22. Désérialisation - [x] [Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) (réparti entre python, ruby, php, java et dotnet) --- ## 23. Malwares et menaces côté client - [x] [Man-in-the-browser attack](https://owasp.org/www-community/attacks/Man-in-the-browser_attack), [Browser Extension Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Browser_Extension_Vulnerabilities_Cheat_Sheet.html) (browser) - [x] [Third Party JavaScript Management](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html) (browser) --- ## 24. Journalisation, répudiation et gestion des erreurs - [x] [Log Injection](https://owasp.org/www-community/attacks/Log_Injection), [Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html), [Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html) (interpreter) - [x] [Repudiation Attack](https://owasp.org/www-community/attacks/Repudiation_Attack) (interpreter) --- ## 25. Logique métier et abus de fonctionnalités La logique métier et l'abus de fonctionnalités n'ont pas de surface de code unique qu'une spécialisation par surface puisse défendre : la défense relève d'une conception propre à l'application, le même raisonnement que guide la modélisation des menaces du projet. Déplacé vers "Hors périmètre". --- ## 26. Sécurité de l'IA, des LLM et des agents - [x] [Prompt Injection](https://owasp.org/www-community/attacks/prompt-injection), [LLM Prompt Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) (llm) - [x] [MCP Tool Poisoning](https://owasp.org/www-community/attacks/MCP_Tool_Poisoning), [MCP (Model Context Protocol) Security](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) (llm) - [x] [HITL Dialog Forging (Lies-in-the-Loop)](https://owasp.org/www-community/attacks/lies-in-the-loop) (llm) - [x] [AI Agent Security](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html), [Secure Coding with AI](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html) (llm) - [x] [Retrieval-Augmented Generation (RAG) Security](https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html) (llm) - [x] [Secure AI/ML Model Ops](https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html) (llm) - [x] [AML and Sanctions Compliance for AI Agent Payments](https://cheatsheetseries.owasp.org/cheatsheets/AML_Sanctions_AI_Agent_Payments_Cheat_Sheet.html) (llm) --- ## 27. Pollution de prototype et fuites intersites - [x] [Prototype Pollution Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html) (javascript) - [x] [Cross-site leaks (XS-Leaks)](https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet.html) (browser) --- ## 28. Frameworks et plateformes de langages - [x] [Django Security](https://cheatsheetseries.owasp.org/cheatsheets/Django_Security_Cheat_Sheet.html), [Django REST Framework](https://cheatsheetseries.owasp.org/cheatsheets/Django_REST_Framework_Cheat_Sheet.html) (python) - [x] [Ruby on Rails](https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheat_Sheet.html) (ruby) - [x] [Laravel](https://cheatsheetseries.owasp.org/cheatsheets/Laravel_Cheat_Sheet.html) (php) - [x] [Symfony](https://cheatsheetseries.owasp.org/cheatsheets/Symfony_Cheat_Sheet.html) (php) - [x] [Java Security](https://cheatsheetseries.owasp.org/cheatsheets/Java_Security_Cheat_Sheet.html) (java) - [x] [DotNet Security](https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html) (dotnet) - [x] [NodeJS Security](https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html) (javascript) - [x] [PHP Configuration](https://cheatsheetseries.owasp.org/cheatsheets/PHP_Configuration_Cheat_Sheet.html) (php) --- ## 29. Front-end web et navigateur - [x] [HTML5 Security](https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html) (browser) - [x] [AJAX Security](https://cheatsheetseries.owasp.org/cheatsheets/AJAX_Security_Cheat_Sheet.html) (browser) - [x] [Securing Cascading Style Sheets](https://cheatsheetseries.owasp.org/cheatsheets/Securing_Cascading_Style_Sheets_Cheat_Sheet.html) (réparti entre access-control et browser) --- ## 30. API et services - [x] [GraphQL](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html) (api-endpoint) - [x] [gRPC Security](https://cheatsheetseries.owasp.org/cheatsheets/gRPC_Security_Cheat_Sheet.html) (api-endpoint) - [x] [WebSocket Security](https://cheatsheetseries.owasp.org/cheatsheets/WebSocket_Security_Cheat_Sheet.html) (api-endpoint) --- ## 31. Cloud, conteneurs et infrastructure La configuration des conteneurs et des workloads est de la configuration as code que le développeur livre avec l'application (`Dockerfile`, Compose, `securityContext` des Pods), une vraie surface que `harden` corrige et que `verify` prouve, donc elle est dans le périmètre. L'administration des clusters (RBAC, etcd, serveur d'API, admission, segmentation réseau) relève de l'opérateur et reste hors périmètre. - [x] [Docker Security](https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html), [Node.js Docker](https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker_Cheat_Sheet.html) (container) - [x] [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (container : la partie workloads et Pods. L'administration des clusters reste hors périmètre) - [x] [Serverless / FaaS Security](https://cheatsheetseries.owasp.org/cheatsheets/Serverless_FaaS_Security_Cheat_Sheet.html) (serverless) --- ## 32. Chaîne d'approvisionnement et CI/CD - [x] [NPM Security](https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html) (interpreter) - [x] [Dependency Graph & SBOM Best Practices](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html), [Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) (interpreter) --- ## 33. Secrets et configuration La gestion des secrets est opérationnelle : coffres-forts, CI/CD, configuration cloud, rotation. Le seul aspect au niveau du code (un secret codé en dur dans le code source) relève d'une analyse déterministe, pas d'une spécialisation de risque. Déplacé vers "Hors périmètre". --- ## 34. Processus, conception et gouvernance La protection de la vie privée des utilisateurs relève de la politique et de la conception (minimisation des données, transparence, conservation), pas d'une surface de code qu'une spécialisation défend. Déplacé vers "Hors périmètre". --- ## 35. Paiements et conformité - [x] [Secure Integration of Third-Party Payment Gateways](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Payment_Gateway_Integration_Cheat_Sheet.html) (payment) --- ## 36. Embarqué, IoT et domaines spécialisés La sécurité automobile et celle des drones sont des domaines de systèmes embarqués (bus CAN, firmware OTA, intégrité des capteurs et des radios, accès physique), pas le code source d'application web ou d'API qu'audite Lagune. Déplacé vers "Hors périmètre". --- ## Hors périmètre (aucune surface de code) Ce ne sont pas des terrains de spécialisation et ils n'ont pas de case à cocher : il s'agit de gouvernance, de processus, de durcissement opérationnel ou d'usage de frameworks sans surface de code unique qu'une spécialisation par surface puisse défendre. Leur valeur pour la sécurité est réelle, mais elle réside dans les processus et l'architecture (ou, pour un framework, dans le skill propre à ce langage), pas dans une défense que ce catalogue fournit. Listés pour référence, pas comme travail à faire. - [Authorization Regression Testing](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Regression_Testing_Cheat_Sheet.html), [Authorization Testing Automation](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html) - [JAAS](https://cheatsheetseries.owasp.org/cheatsheets/JAAS_Cheat_Sheet.html) - [Denial of Service](https://owasp.org/www-community/attacks/Denial_of_Service), [Denial of Service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) - [HTTP/2 Reset Attack](https://owasp.org/www-community/attacks/HTTP2_Reset_Attack) - [Traffic flood](https://owasp.org/www-community/attacks/Traffic_flood) - [Web Service Amplification Attack](https://owasp.org/www-community/attacks/web_service_amplificaiton) (amplification SOAP/WS-Addressing, une variante opérationnelle de DoS sans surface de code) - [Cash Overflow](https://owasp.org/www-community/attacks/Cash_Overflow) - [Spyware](https://owasp.org/www-community/attacks/Spyware), [Trojan Horse](https://owasp.org/www-community/attacks/Trojan_Horse) (malware visant l'utilisateur final, pas une surface de code du projet audité. L'aspect de diffusion dans le navigateur relève de `browser`) - [REST Security](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html), [REST Assessment](https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html) - [Web Service Security](https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html) - [Cloud Architecture Security](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet.html) (conception et compromis : IAM ou URL signées, VPC publics ou privés, frontières de confiance, responsabilité partagée. Contrairement à `container`, aucune configuration concrète ne peut y être vérifiée par une spécialisation) - [Infrastructure as Code Security](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) (malgré son nom, il s'agit du processus SDLC et de l'outillage pour _gérer_ l'IaC : plugins d'IDE, analyse statique, analyse d'images, CI/CD, signature. Il ne propose aucun passage d'un motif non sûr à une forme sûre dans un fichier Terraform/CloudFormation) - [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (_uniquement la partie administration des clusters_ : RBAC, etcd, serveur d'API, admission. La partie workloads et Pods est dans le périmètre, sous `container`) - [Network Segmentation](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html) (architecture réseau et politique de pare-feu) - [Subdomain Takeover Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html) (cycle de vie et surveillance du DNS, pas du code) - [Secrets Management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) (coffres-forts, CI/CD, rotation. L'aspect du secret codé en dur relève d'une analyse déterministe, pas d'une spécialisation de risque) - [C-Based Toolchain Hardening](https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.html) (options du compilateur, de l'éditeur de liens et du build, sans sink dans le code source) - [Microservices Security](https://cheatsheetseries.owasp.org/cheatsheets/Microservices_Security_Cheat_Sheet.html), [Microservices based Security Arch Doc](https://cheatsheetseries.owasp.org/cheatsheets/Microservices_based_Security_Arch_Doc_Cheat_Sheet.html) - [Zero Trust Architecture](https://cheatsheetseries.owasp.org/cheatsheets/Zero_Trust_Architecture_Cheat_Sheet.html) - [CI/CD Security](https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html), [GitHub Actions Security](https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html) - [Software Supply Chain Security](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html) - [Error Handling](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html), [Full Path Disclosure](https://owasp.org/www-community/attacks/Full_Path_Disclosure) (configuration globale du gestionnaire d'erreurs selon la stack. La fuite est la même divulgation que régit déjà la gestion des erreurs) - [Abuse of Functionality](https://owasp.org/www-community/attacks/Abuse_of_Functionality), [Business Logic Security](https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html), [Abuse Case _(historique)_](https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html) (conception propre à l'application, aucun sink de code unique) - [User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) (minimisation des données, transparence, politique de conservation) - [Top 10 Automotive Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Automotive_Security_Cheat_Sheet.html), [Drone Security](https://cheatsheetseries.owasp.org/cheatsheets/Drone_Security_Cheat_Sheet.html) (domaines de systèmes embarqués : bus CAN, firmware OTA, intégrité des capteurs et des radios, pas du code source web ou d'API) - [Mobile Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet.html) (durcissement des plateformes Android/iOS : stockage, biométrie, pinning, données personnelles. Il n'a pas de surface de code unique, et l'aspect du chargement de code non fiable est passé à `interpreter`) - [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html), [Threat Modeling _(page communautaire)_](https://owasp.org/www-community/Threat_Modeling) - [Attack Surface Analysis](https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html) - [Secure Product Design](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) - [Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) - [Virtual Patching](https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html) - [Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html) - [Legacy Application Management](https://cheatsheetseries.owasp.org/cheatsheets/Legacy_Application_Management_Cheat_Sheet.html) - [Security Terminology](https://cheatsheetseries.owasp.org/cheatsheets/Security_Terminology_Cheat_Sheet.html) --- # /lagune-repair: réparer le suivi des constats > Réparez la chaîne quand un renommage ou un fichier déplacé perturbe le suivi de Lagune. Canonique: https://lagune.ai/fr-FR/docs/commands/repair Langue: fr-FR Original: https://lagune.ai/docs/commands/repair Dernière mise à jour: 2026-11-03 🧰 Réparez la chaîne quand un renommage ou un fichier déplacé la perturbe. **Maintenance interne, pas une phase de sécurité** Repair n'est pas une sixième phase du flux linéaire. Son rôle est de garder le suivi cohérent. ```prompt # Il ne prend aucune entrée : il répare toujours toute la chaîne /lagune-repair ``` ## Fonctionnement Chaque constat de detect est un élément suivi que plan, harden et verify reprennent, chacun agissant dessus et le rapportant de nouveau par son nom. Ce nom, écrit à l'identique comme titre de section dans chaque artefact, est son identité de bout en bout. La seule donnée volatile que stocke le suivi, ce sont les chemins de fichiers vers lesquels pointe l'élément. Ces chemins ne se trouvent nulle part ailleurs, donc un renommage ou un fichier déplacé ne peut casser le lien qu'à cet endroit, jamais dans deux copies divergentes. Quand cela arrive, repair corrige la carte (`.lagune/tracking.json`) pour que l'identité survive au renommage. Il lit les artefacts et la carte de suivi, ne lit votre code source que pour connaître le nouveau chemin d'un fichier renommé, et ne rédige jamais de contenu de sécurité. Dans le même passage, il vérifie chaque artefact de la mémoire par rapport à son modèle et signale ce qui a dérivé, en renvoyant chaque écart vers la phase qui le corrige. **Astuce** - Il ne touche ni à votre code ni aux artefacts rédigés, seulement au suivi. - Vous l'exécutez rarement à la main. Quand une phase remarque que la chaîne est incohérente, elle exécute repair pour vous et continue. - Le suivi qu'il entretient se trouve dans `.lagune/tracking.json`, un état interne que vous ne modifiez jamais à la main. --- # Migrate : passer un projet Lagune à manifeste aux skills et aux plugins > Passez un projet Lagune à manifeste au Lagune fondé sur les skills, en gardant vos principes de sécurité, vos artefacts, votre suivi et vos propres spécialisations. Canonique: https://lagune.ai/fr-FR/docs/commands/migrate Langue: fr-FR Original: https://lagune.ai/docs/commands/migrate Dernière mise à jour: 2026-11-03 🔀 Passez un projet **Lagune** à manifeste au **Lagune** fondé sur les skills, en gardant tout ce que vous avez écrit. **Avis d'obsolescence** Un projet avec un manifeste continue de fonctionner tel quel jusqu'à la `v1.x` : `npx lagune` confie `init`, `pull`, `update`, `add`, `remove`, `list` et le tableau de bord à `lagune@0.15.0`, la dernière version à manifeste. ## Migrer 1. Assurez-vous que votre travail en cours est commité, puis exécutez migrate depuis la racine du projet : ```bash npx lagune migrate ``` 2. Commitez séparément ce qu'il a modifié, pour que la migration reste une seule modification relisible. 3. Installez les commandes pour votre agent, comme l'indique la [page d'installation](https://lagune.ai/fr-FR/docs). 4. Si le projet a déjà un artefact detect, plan ou harden, demandez à [`/lagune-repair`](https://lagune.ai/fr-FR/docs/commands/repair) de mettre en cohérence les anciennes références qu'ils contiennent, ainsi que celles de vos propres spécialisations : ```prompt /lagune-repair Mets en cohérence les spécialisations appliquées (anciennement sub-skills) dans les artefacts sous `.lagune/memory/` (`detect.md`, `plan.md` et `harden.md`) avec les noms que liste le nouveau catalogue, et réécris chaque appel que mes propres spécialisations dans `.lagune/catalog/` font aux anciens hooks de `.lagune/hooks/` en un appel à l'outil `lagune_read` ou `lagune_write`. ``` ## Ce qui change | Avant | Après | | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | `.lagune/templates/`, `.lagune/hooks/` et `.lagune/specializations.md` | Supprimés : chaque skill porte son modèle, et le moteur exécute les hooks | | Les copies des spécialisations intégrées dans `.lagune/skills/` | Supprimées : le moteur sert les intégrées | | Vos propres spécialisations dans `.lagune/skills/` | Déplacées dans `.lagune/catalog/` | | `.lagune/skills.json`, l'index de vos propres spécialisations | Fusionné dans `.lagune/configs.json` | | Les catégories du manifeste | Enregistrées dans `.lagune/configs.json` | | Les anciennes commandes d'agent, comme `/lagune.detect` | Supprimées : [installer **Lagune**](https://lagune.ai/fr-FR/docs) apporte les nouvelles, comme `/lagune-detect` | | Le bloc **Lagune** dans `.gitignore` | Supprimé, avec le fichier s'il ne contenait rien d'autre | | `.lagune/proofs/`, ignoré par ce bloc | Tenu à l'écart des commits par son propre `.gitignore` | | `.lagune/manifest.json` | Supprimé, en dernier | Votre travail de sécurité reste tel quel : les principes de sécurité, l'artefact produit par chaque phase et la carte de suivi avec les chemins vers lesquels pointe chaque constat. ## Questions fréquentes ### Dois-je migrer ? Oui. Les projets à manifeste sont obsolètes et ne fonctionnent que jusqu'à la v1.x, donc exécutez npx lagune migrate pour migrer le vôtre. ### Que garde migrate ? Vos principes de sécurité, chaque artefact des phases, la carte de suivi, vos catégories et vos propres spécialisations. Les spécialisations passent dans .lagune/catalog/, et leur index rejoint vos catégories dans .lagune/configs.json. ### Quand installer les nouvelles commandes ? Après migrate, comme l'indique la page d'installation pour votre agent. Les installer avant fonctionne aussi, puisque migrate garde le nouveau /lagune. ### Un coéquipier a déjà migré. Que dois-je exécuter ? Récupérez la migration avec un pull, puis exécutez npx lagune migrate une fois. Il supprime ce que le Lagune à manifeste a laissé dans votre clone, que le contrôle de version n'a jamais transporté, et tient vos preuves à l'écart des commits.