Édition Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Configurer AI-DLC 2.11.0 pour attendre l’approbation du plan de code

> Un guide fondé uniquement sur la documentation et lié à une version précise pour activer et vérifier l’approbation humaine du plan d’AI-DLC 2.11.0 avant la génération de code.

By BIG CHANGE Editorial

Published: 2026-10-15T18:54:16.360Z
Updated: 2026-10-15T18:54:16.360Z
Canonical: https://bigchange.ai/blog/aidlc-2-11-plan-approval-guide

![Conceptual charcoal illustration of one developer reading abstract plan-like lines on an unbranded desktop monitor while the keyboard sits untouched.](https://bigchange.ai/api/media/file/aidlc-human-plan-review-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual AI-DLC interface, user session or observed test result is depicted.

AI-DLC 2.11.0 peut arrêter un workflow Codex CLI avant la génération de code afin qu’un développeur puisse lire le plan proposé et l’approuver. Ce guide suit la [version v2.11.0 du 8 octobre 2026](https://github.com/awslabs/aidlc-workflows/releases/tag/v2.11.0) et ses instructions versionnées concernant [Codex CLI](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md), le [profil de workflow](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/workflow-profiles.md) et [Plan Approval](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/13-customization.md#plan-approval). BIG CHANGE a examiné ces documents et la référence des commandes associée à ce tag. Nous n’avons ni installé ni exécuté AI-DLC ; toutes les étapes ci-dessous reposent uniquement sur la documentation.

Ce guide s’adresse à un développeur disposant d’un projet Git qui souhaite examiner un plan de code avant qu’un assistant de programmation IA ne génère des fichiers. Le résultat attendu est une question Plan Approval qui désigne le plan, permet au développeur de demander des modifications et laisse la compilation en attente de sa réponse. AI-DLC comporte encore des vérifications ultérieures ; cette étape de validation concerne précisément le plan de code.

## Avant de commencer

Le [guide Codex associé au tag](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md) exige Codex CLI 0.145.0 ou une version ultérieure, un dépôt Git pour les hooks du projet et un fournisseur de modèles configuré. La version native d’AI-DLC ne nécessite ni Bun ni Node.js. Utilisez un projet dont vous êtes autorisé à envoyer le code et le plan à votre fournisseur de modèles configuré. Examinez séparément les conditions de traitement des données et de facturation de ce fournisseur ; le dépôt AI-DLC ne précise pas de tarif unique d’utilisation d’un fournisseur pour ce workflow.

Préparez une tâche de développement concrète comme donnée d’entrée. Ce parcours utilise le profil **Feature**, car la documentation de v2.11.0 indique que Plan Approval est activé pour Feature. **Express** et **Proof of concept** démarrent avec Plan Approval désactivé, même si une personne peut demander l’examen d’un plan particulier. Le profil compte davantage que l’idée générale selon laquelle chaque exécution d’AI-DLC marquera une pause.

## 1. Installer et vérifier la version précise

Sous macOS, Linux ou WSL, la version v2.11.0 fournit cette commande d’installation propre à cette version :

```bash
curl -fsSL https://github.com/awslabs/aidlc-workflows/releases/download/v2.11.0/install.sh | sh -s -- --version 2.11.0
```

La version fournit également un [programme d’installation Windows propre à cette version](https://github.com/awslabs/aidlc-workflows/releases/tag/v2.11.0) pour PowerShell. Examinez le programme d’installation et choisissez la procédure adaptée à votre machine avant de l’exécuter. Vérifiez ensuite la version installée et l’environnement depuis votre projet :

```bash
aidlc --version
aidlc doctor
codex --version
```

La commande `aidlc --version` doit indiquer 2.11.0. `aidlc doctor` signale les problèmes de configuration et d’exécution, tandis que `codex --version` permet de vérifier la version minimale de Codex CLI. Si la version installée diffère, arrêtez-vous ici et utilisez les instructions d’installation ou de mise à jour de la version v2.11.0 ; les étapes ci-dessous sont liées à cette version.

## 2. Configurer Codex et autoriser les hooks du projet

Depuis la racine du projet Git, suivez la [procédure de configuration Codex associée au tag](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md#install) :

```bash
aidlc config --harness codex
aidlc doctor
codex
```

Codex demande si vous faites confiance aux hooks du projet. Examinez le projet et les hooks générés avant de sélectionner **Trust all and continue (Tout autoriser et continuer)**. Le guide associé au tag indique qu’une boîte de dialogue déjà fermée peut être rouverte avec `/hooks`, puis `t` et Échap. Exécutez `$aidlc --doctor` dans Codex après avoir accordé cette autorisation. Si les hooks ne s’exécutent pas, suivez la procédure de rétablissement de la confiance du guide d’intégration ; une installation réussie ne prouve pas à elle seule que les hooks du projet sont actifs. Le fournisseur de modèles et ses identifiants sont configurés dans les paramètres utilisateur de Codex et ne sont pas fournis par AI-DLC.

## 3. Démarrer un workflow Feature et examiner ses paramètres

Exécutez d’abord `$aidlc --status` dans Codex et vérifiez qu’aucun workflow n’est actif. La [référence des commandes associée au tag](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md) indique qu’une commande de portée seule poursuit le travail existant lorsqu’un workflow est actif. Pour ce parcours, utilisez un projet sans workflow actif.

Dans ce projet Codex configuré, saisissez `$aidlc feature` et répondez à la demande décrivant la tâche à réaliser. L’entrée doit décrire la fonctionnalité et ses contraintes ; le plan final est généré à partir de ce travail. Avant la création du plan de code, examinez les réglages effectifs à l’aide de la [référence des commandes v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md) :

```text
$aidlc --status
$aidlc config get plan-approval
$aidlc config get guard-policy
```

Repérez Plan Approval **on (activé)** et la source indiquée pour ce réglage. S’il est désactivé pour cette intention, `$aidlc --plan-approval on` active la question pour le prochain plan. Un réglage au niveau de la machine peut imposer sa désactivation, et une règle de mémoire d’équipe peut exiger son activation ; la ligne d’état indique la valeur effective. Pour ce parcours, réglez Guard Policy sur strict avec `$aidlc --guard-policy strict` si vous souhaitez aussi qu’un plan déjà approuvé, ou ses instructions de test, doive être approuvé de nouveau après modification. L’activation de Plan Approval contrôle la première question ; Guard Policy contrôle ce qui se produit après la modification d’un plan approuvé.

## 4. Examiner le plan de code à l’étape de validation

Poursuivez le workflow jusqu’à ce que Code Generation dispose d’un plan prêt. Avec Plan Approval activé, le moteur v2.11.0 présente le résumé et le chemin du plan, avec notamment les choix **Approve Plan (Approuver le plan)**, **Request Changes (Demander des modifications)** ou **I'll edit the files (Je modifierai les fichiers)**. Ouvrez le fichier `code-generation-plan.md` indiqué et lisez les fichiers proposés, leur séquence et les instructions de test. Examinez toutes les commandes, les accès aux données du projet et les actions susceptibles de modifier le dépôt avant d’approuver.

Choisissez **Request Changes (Demander des modifications)** si le plan nécessite une autre implémentation ou un autre test. Si vous modifiez vous-même les fichiers, utilisez la voie **I'll edit the files (Je modifierai les fichiers)** du moteur au lieu de considérer une modification comme une approbation. Seule votre réponse autorise le plan ; un modèle ne peut pas l’approuver à votre place. Lorsque cette validation est activée, la génération de code attend cette réponse. Les notes de version indiquent qu’un examen, un réglage, un commit ou une autre demande autorisée peut être effectué pendant que la compilation attend.

## 5. Approuver, vérifier la trace et gérer un plan modifié

Lorsque le plan convient, répondez **Approve Plan (Approuver le plan)** à la question ouverte. Le moteur enregistre l’approbation pour ce plan et reprend la compilation selon son processus normal `next`. Selon les notes de version, un plan approuvé et inchangé reste mémorisé après la compression du contexte de la conversation ou sa mise en attente. La [référence des commandes associée au tag](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md#read-earlier-questions-and-the-audit-timeline) décrit la commande en lecture seule `aidlc engine audit history` permettant d’examiner la chronologie enregistrée, et `$aidlc --status` indique la position du workflow. Ces traces, ainsi que l’apparition visible de la validation avant le code généré, permettent de vérifier le résultat.

Si le plan ou ses instructions de test changent avant la compilation, Guard Policy en mode strict demande une nouvelle approbation. En mode relaxed ou off, le changement est signalé et enregistré, mais le workflow peut continuer sans nouvelle approbation obligatoire. Les documents associés au tag distinguent aussi les changements de fichiers source sans rapport avec le plan après l’approbation : ces changements sont signalés, tandis que l’approbation reste liée au plan et aux instructions de test. La personne peut demander « revenir au plan approuvé » pour restaurer le plan précédent avant la compilation. Un plan inchangé ne devrait pas susciter une deuxième question simplement parce que le contexte de la conversation a été compressé.

## Si la pause n’apparaît pas

Lisez d’abord `$aidlc --status` et `$aidlc config get plan-approval`. Vérifiez la portée sélectionnée, le réglage effectif et sa source. Express et Proof of concept sont désactivés par défaut ; activez Plan Approval pour cette intention ou démarrez un workflow Feature si son cycle complet convient à la tâche. Si la configuration ou les hooks semblent défaillants, exécutez `aidlc doctor` et suivez la procédure de [rétablissement de l’intégration Codex](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md#refresh-and-version-skew). Vérifiez une éventuelle différence de version avant de modifier l’environnement d’exécution d’un projet actif. Ne supposez pas que l’absence de question prouve qu’une approbation a été enregistrée : lorsque le réglage est désactivé, AI-DLC écrit une ligne `PLAN_APPROVAL_SKIPPED`, que les documents associés au tag distinguent explicitement d’une approbation humaine.

## Le grand changement

- AI-DLC 2.11.0 place la question sur le plan dans son moteur, qui enregistre la décision et conserve un plan approuvé inchangé lors d’une session mise en attente ou dont le contexte a été compressé.
- Pour une exécution Feature dans Codex CLI, le développeur peut vérifier le réglage effectif de Plan Approval, lire le plan avant la génération de code et demander des modifications à l’étape de validation.
- Une nouvelle approbation après modification du plan dépend de Guard Policy. Le développeur peut choisir strict pour imposer un nouvel arrêt lorsque le plan ou les instructions de test changent.

### Sources et lectures complémentaires

- [Version AI-DLC 2.11.0](https://github.com/awslabs/aidlc-workflows/releases/tag/v2.11.0) — version datée, programmes d’installation liés à cette version et comportement annoncé de Plan Approval. Les notes de version décrivent la fonctionnalité ; elles ne démontrent pas que BIG CHANGE a exécuté ce guide.
- [Guide Codex CLI de v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md) — prérequis concernant la version de Codex, Git et le fournisseur, configuration du projet, confiance accordée aux hooks et invocation.
- [Profils de workflow de v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/workflow-profiles.md) — réglages par défaut des profils et distinction entre Feature et Express/Proof of concept.
- [Plan Approval et Guard Policy de v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/13-customization.md#plan-approval) — première étape d’approbation, traces d’approbation ignorée et comportement lorsqu’un plan approuvé change.
- [Référence des commandes de v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md) — commandes d’état, de configuration et d’historique d’audit.

## Sources

- [Version AI-DLC 2.11.0](https://github.com/awslabs/aidlc-workflows/releases/tag/v2.11.0) — Programmes d’installation liés à cette version et description par le projet de Plan Approval dans le moteur ; aucune exécution par BIG CHANGE.
- [README d’AI-DLC de v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/README.md) — Présentation de l’intégration et de la configuration dans le tag de la version du 8 octobre. Le programme d’installation générique de la dernière version n’est volontairement pas utilisé.
- [Guide AI-DLC pour Codex CLI de v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md) — Prérequis Codex, configuration du projet, confiance accordée aux hooks et rétablissement en cas de différence de version dans le tag du 8 octobre.
- [Profils de workflow AI-DLC de v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/workflow-profiles.md) — Comportement des portées Feature, Express et Proof of concept et réglages d’approbation par défaut dans le tag du 8 octobre.
- [Plan Approval et Guard Policy d’AI-DLC de v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/13-customization.md) — Question sur le plan, trace d’approbation ignorée et nouvelle approbation après modification du plan ou des instructions de test dans le tag du 8 octobre.
- [Référence des commandes CLI d’AI-DLC de v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md) — Commandes de version, d’état, de configuration et d’historique d’audit dans le tag du 8 octobre ; aucune commande exécutée par BIG CHANGE.