Planification, raisonnement et exécution distincts

Dans cette unité, vous allez apprendre :

• Pourquoi la séparation de la planification, de l’exécution et de la validation améliore la fiabilité

• Comprendre la différence entre les flux de travail centrés sur la planification et les flux de travail intégrant planification et exécution.

• Comment appliquer des limites de planification à l’aide des limites de capacité et de l’outil gating

Pourquoi la séparation améliore la fiabilité

Les systèmes d’agent fiables séparent :

• Planification : ce qui sera fait et pourquoi.

• Exécution : modifications concrètes apportées au référentiel.

• Validation : preuve que le résultat répond aux critères de réussite.

Lorsque la planification et l’exécution sont combinées, les réviseurs ne voient que le diff final. Ils perdent la possibilité de valider l’intention tôt, de détecter rapidement les malentendus et de contrôler l’étendue avant l’impact.

Comment la séparation correspond à GitHub

GitHub prend naturellement en charge cette séparation :

• La planification apparaît dans la description d'une pull request, un commentaire de ticket ou un artefact Github/pull_request_template.md.

• L’exécution s’affiche sous forme de validations sur une branche.

• La validation apparaît sous forme de vérifications, d’analyses, d’artefacts et de résultats d'examen.

Comprendre la différence entre un flux de travail axé sur la planification et un flux de travail combiné planification et exécution

Lorsque vous travaillez avec des agents, les équipes doivent décider quand un plan devient visible et quand les modifications du code sont autorisées à commencer. Dans GitHub, la planification et l’exécution peuvent commencer à partir de différents points d’entrée, tels qu’un problème de GitHub (par exemple, l’affectation d’un agent cloud Copilot) ou via l’onglet Agents dans lequel un plan est généré de manière interactive.

Il s’agit de façons distinctes d’interagir avec l’agent, mais elles convergent vers le même modèle de gouvernance : tout le travail est finalement présenté et examiné dans un pull request (PR).

Le choix de conception clé n’est donc pas là où le plan démarre, mais lorsque la validation humaine est requise par rapport aux modifications de code.

Option A : Réaliser une pull request axée sur la planification

Dans cette approche, la planification est terminée et approuvée avant l’introduction de modifications de code.

Fonctionnement dans la pratique :

• Un plan est généré (par exemple, en affectant un agent à un problème de GitHub ou en le créant sous l’onglet Agents).

• L’agent ouvre une pull request qui contient uniquement le plan (aucune modification de code encore).

• Les réviseurs discutent, affinent et approuvent le plan directement dans la demande de tirage.

• Après approbation, l’agent procède à l’implémentation du plan dans les commits de suivi ou une nouvelle pull request.

Cela crée une séparation claire entre l’intention (plan) et l’exécution (code).

Option B : Plan + exécution dans la même requête de tirage

Dans cette approche, la planification et l’exécution sont combinées au sein d’une demande de tirage unique.

Fonctionnement dans la pratique :

• L’agent ouvre un pull request incluant les deux :

  • un plan structuré (dans la description)

  • modifications initiales du code (validations)

• L’agent peut continuer à mettre à jour la pull request au fur et à mesure que le plan évolue.

• Les contrôles standard requis de GitHub, les révisions des CODEOWNERS et les protections de branche empêchent la fusion jusqu'à ce que toutes les exigences soient satisfaites.

Ici, le plan est toujours visible, mais il est présenté aux côtés des changements actifs plutôt qu’avant eux.

Différence clé : minutage de la validation

Les deux options utilisent les mêmes contrôles GitHub. La différence est lorsque ces contrôles sont appliqués par rapport à l’exécution :

• Option A (Plan-first) : La validation humaine se produit avant l’écriture d’un code.

• Option B (Plan + exécution) : Le code est généré immédiatement, mais la validation est toujours requise avant la fusion.

Considérations relatives aux risques

Les deux approches peuvent être sécurisées lorsque GitHub protections sont correctement configurées. La différence réside dans le moment où le risque est introduit dans le système :

• L’option A réduit l’exposition précoce. Étant donné qu’aucun code n’est généré avant l’approbation, les réviseurs valident d’abord l’intention. Cela réduit les modifications inutiles ou dangereuses et est préférable dans les environnements à haut risque (par exemple, les systèmes de production ou les zones sensibles à la sécurité).

• L’option B introduit une exposition antérieure au changement. Le code apparaît dans la demande de tirage avant que le plan soit entièrement validé. Bien que ce code ne puisse pas être fusionné sans approbation, il peut :

  • introduire des modifications inutiles ou incorrectes qui doivent être examinées et rejetées

  • augmenter l’effort du réviseur

  • créer un mauvais alignement temporaire entre le plan et la mise en œuvre

Il est important de noter que ce risque existe au cours de l’étape de la proposition, et non après la fusion. les mécanismes d'application de GitHub empêchent toujours le déploiement du code non sécurisé.

Quand utiliser chaque option

• Utilisez le flux de travail Plan-first lorsque :

  • les changements sont à haut risque ou difficiles à inverser

  • l'alignement sur l'intention est essentiel avant l'exécution

  • vous souhaitez une séparation stricte entre la planification et l’implémentation

• Utilisez le workflow de planification et d’exécution lorsque :

  • la vitesse et l’itération sont plus importantes

  • les changements sont à faible risque ou facilement réversibles

  • les réviseurs sont à l’aise pour évaluer le plan et le code ensemble

À retenir

Le choix ne porte pas sur le fait que le travail est toujours examiné, car il l'est toujours. Le choix est le moment où le système autorise la génération du code par rapport à la validation humaine et le début de la modification dans le flux de travail.

Application des limites de planification grâce aux limites de capacité et à la gestion des outils de gating

1. Limite de capacité (les agents de planification sont en lecture seule) Un agent de planification doit être limité aux outils en lecture seule afin qu’il ne puisse pas modifier les fichiers pendant la planification.
2. Transition explicite (ou transfert) vers un agent d’implémentation. L’exécution ne doit se produire qu’après l’approbation du plan, en utilisant un transfert délibéré.
3. Le contrôle d'accès aux outils dans les orchestrateurs des orchestrations automatisées vous permet de forcer le lancement de la planification sans exécution des outils, puis d'activer les outils uniquement après l'acceptation du plan.
4. Flux de travail « Mode plan » : certaines interfaces prennent en charge une expérience de planification qui génère un artefact de plan et s’interrompt avant l’application des modifications.

Conseils de décision

• Utilisez d’abord le plan pour le travail à haut risque (flux de travail, infrastructure, authentification, production).

• Utilisez le plan + exécution pour le travail à risque moyen/faible, mais conservez les vérifications/révisions requises.

• Traitez les « instructions à ne pas modifier » comme des conseils ; traitez les listes d’autorisation et les portes des outils comme des mécanismes d’application.

Clé à prendre : La séparation crée une occasion de passer en revue l’intention avant d’accepter l’impact.

Ensuite, vous allez appliquer la visibilité et la validation du plan grâce aux portes d’approbation de pull request.