ADE : cadrer le travail d’un agent IA jusqu’à la pull request

Une demande trop large pour commencer à coder

« Améliore la recherche du catalogue » laisse beaucoup de décisions ouvertes à un agent IA. Faut-il accélérer la réponse, ajouter des filtres ou changer l’affichage ? Une PR peut contenir du code correct et rester difficile à accepter si personne n’a défini le résultat attendu.

Je développe AI Delivery Engine, ou ADE, pour rendre explicites ces étapes de préparation et de validation. Son socle local regroupe le contexte du dépôt et des règles de revue. Le workflow documenté précise ensuite le passage d’une demande à une modification que l’équipe peut examiner. L’outil d’assistance au développement reste choisi par l’équipe.

Préparer un premier dépôt

Pour essayer le socle local, la documentation prévoit Node.js 22 ou une version ultérieure. Depuis la racine d’un projet, les commandes suivantes installent ADE comme dépendance de développement, créent sa configuration, génèrent le contexte et lancent la revue déterministe.

npm install -D @alelouet/ai-delivery-engine
npx ade init
npx ade context generate
npx ade review

Cette séquence modifie le projet : il faut relire les fichiers créés et le changement de dépendances. Elle présente le démarrage documenté d’ADE, sans constituer un résultat de test sur votre application. Le socle fonctionne sans clé d’API de modèle. La génération du contexte et la revue déterministe ne font pas appel implicitement à un fournisseur d’IA.

Avant de confier une tâche à un agent, adaptez ade.config.json aux chemins du dépôt et à ses fichiers sensibles. Les règles de travail communes ont aussi leur place dans AGENTS.md. Le contexte généré aide à transmettre la structure du projet ; les critères d’acceptation restent à écrire pour la demande précise.

Écrire ce qui rend la tâche acceptable

Reprenons une recherche de catalogue fictive. L’équipe confirme que le besoin concerne la conservation des filtres lors du passage à la page suivante. On peut alors préparer une tâche limitée, accompagnée de cas que le développeur et le relecteur pourront reproduire.

Objectif
Conserver le filtre de catégorie dans les liens de pagination.

Critères d’acceptation
- La page suivante conserve la catégorie sélectionnée.
- Changer de catégorie revient à la première page.
- Une URL partagée retrouve le filtre et la page demandés.

Hors périmètre
Pas de changement du moteur de recherche ni de nouvelle interface.

Vérification attendue
Tests des URL et parcours manuel avec retour arrière.

Ce texte est un exemple de cadrage à discuter. Il ne représente pas à lui seul le format structuré d’un handoff ADE. Dans le workflow GitHub documenté, ADE planifie d’abord la demande ; le développement s’appuie sur un handoff d’implémentation validé, qui fixe notamment le périmètre et les critères d’acceptation. Si une décision produit manque, elle doit être résolue avant d’élargir le travail.

Prévoir les contrôles et comprendre ce qu’ils couvrent

Une fois le changement réalisé, npx ade review --staged permet de cibler les modifications préparées pour le commit. La revue vérifie notamment la configuration, la fraîcheur du contexte et les règles applicables. Les outils du projet peuvent être exécutés avec l’option --run-tools lorsqu’ils sont configurés dans ADE.

Pour la pagination fictive, il faut encore choisir un test qui détecte réellement la perte du filtre et parcourir l’interface. Un rapport de règles sans erreur ne suffit pas à démontrer que la navigation convient à l’utilisateur. Les commandes de test et de build restent celles du dépôt, à configurer ou à lancer explicitement selon le workflow retenu.

Le workflow de livraison ADE prévoit aussi des revues spécialisées selon les profils configurés, puis des corrections bornées si nécessaire. Le choix de ces profils dépend du projet. Une modification de droits d’accès appelle des vérifications différentes de celles d’un article ou d’un lien de pagination.

Laisser une décision lisible dans la PR

La PR doit permettre de relier le comportement attendu au changement livré. Dans notre exemple, son auteur peut expliquer quel lien perdait le filtre, montrer le nouveau comportement et indiquer les contrôles exécutés. Un point non vérifié doit rester visible pour le relecteur.

La création de la PR dépend de l’intégration : en mode local, le développeur suit les règles Git du dépôt ; dans ADE Control Plane, l’orchestrateur possède les opérations Git et GitHub. Le workflow conserve une revue humaine et une décision explicite de fusion. Installer la CLI seule ne met pas en place toute cette orchestration.

Pour évaluer ADE, choisissez une prochaine tâche courte et gardez sa trace jusqu’à la revue. Le relecteur peut-il retrouver le périmètre accepté et les preuves de validation sans relancer toute la conversation avec l’agent ? Cette question donne un critère concret pour décider ce qu’il faut conserver ou ajuster dans le processus.

Sources et liens utiles

• ADE : présentation et démarrage, consultés le 19 octobre 2026
• ADE : référence CLI, revue et exécution des outils configurés
• ADE : workflow GitHub, handoff et revue humaine
• ADE : package npm
• Sur ce site : la conception du projet AI Delivery Engine
• Dans le Journal : préparer une pull request facile à relire