Rôles des agents

Coroid n'utilise pas un seul agent polyvalent. Chaque étape du processus allant de la description à pull request est prise en charge par un agent ayant une mission précise et un ensemble d'outils délibérément restreints.

Ces restrictions sont essentielles : un agent incapable d'écrire du code ne pourra pas accidentellement écrire du code.

Les rôles#

Rôle	Étape	Peut modifier votre code
Architecte	Spécification et plan	Non
Développeur	Construction	Oui
QA	Vérifier	Non
Réviseur	Révision	Non
Testeur web	Vérifier les flux navigateur	Non
Explorateur	Recherche, à n'importe quelle étape	Non
Analyseur de dépendances	Analyse	Non

Les quatre premiers sont les agents de livraison que vous observez sur chaque tâche. En mode standard, ils s'exécutent dans cet ordre :

Architecte → Développeur → QA → Réviseur

En mode Coordinateur, le coordinateur définit l'ordre d'exécution de la tâche. Ces deux modes sont décrits ci-dessous.

Un seul rôle — le développeur — est autorisé à modifier les fichiers de votre dépôt. Tous les autres agents se contentent de lire, d'exécuter des tâches, de générer des rapports ou de créer des actions complémentaires.

Deux modes d'exécution d'une tâche#

Une tâche s'exécute selon l'un de ces deux modes. Son AI profile et votre déploiement déterminent le mode utilisé.

Mode coordinateur. L'architecte ne remet pas simplement son plan et s'en va. Il reste sur la tâche en tant que coordinateur. Après la phase de planification, le coordinateur transmet ses instructions au développeur et attend son rapport. Ensuite, il demande au service de contrôle qualité de vérifier ce qui a été développé, puis au réviseur de procéder à la révision des éléments validés par le contrôle qualité. Après chaque rapport, le coordinateur décide de la suite : renvoyer les constatations au développeur, répondre à une question, réviser le plan ou clôturer la tâche. La refonte constitue une étape supplémentaire pour le coordinateur, et non une nouvelle exécution.

Mode standard. La plateforme fait passer la tâche par les quatre agents dans un ordre fixe ; tout contrôle échoué la renvoie au développeur. Certains travaux suivent toujours ce fonctionnement, comme la résolution d’un conflit de fusion, et le mode standard est la solution de repli lorsque le mode coordinateur n’est pas disponible.

Dans les deux modes, les mêmes agents effectuent le travail, sous les mêmes restrictions et en passant par les mêmes étapes de validation. La différence réside dans la personne qui détermine l'étape suivante : la plateforme en mode standard, ou le coordinateur en mode Coordinateur.

Le coordinateur#

Le coordinateur est l’agent de planification associé à la tâche. Il lit votre base de code et ne peut pas la modifier ; toutes ses actions relèvent donc de l’orientation.

Rôle du coordinateur#

• Établit des plans. Le coordinateur explore le dépôt de code, puis enregistre le plan avec les critères d'acceptation qui déterminent si le travail a été mené à bien.
• Délègue des tâches. Le coordinateur collabore avec un seul agent à la fois. Ses instructions précisent l'objectif à atteindre, les critères d'acceptation nécessitant une attention particulière et, lorsqu'il renvoie le travail, les corrections exactes à apporter. Pendant que l'agent travaille, le coordinateur attend sans consommer de temps de calcul du modèle.
• Répond aux questions. Un agent confronté à une décision peut interroger le coordinateur. Le coordinateur répond avec la décision et la raison. Il ne laisse pas la question en attente d'une intervention humaine.
• Réagit. Lorsque le contrôle qualité échoue ou que le réviseur demande des modifications, le coordinateur transmet les correctifs au développeur, et le contrôle qualité vérifie la nouvelle version.
• Clôture la tâche. Le coordinateur finalise la tâche, ou la fait échouer en indiquant la raison.

Ce que le coordinateur ne peut pas faire#

Le coordinateur oriente ; il ne juge pas. La plateforme applique ces limites, si bien qu'elles ne dépendent pas de la décision du coordinateur :

1. Les verdicts relèvent du contrôle qualité et du réviseur. Seuls le contrôle qualité et le réviseur émettent des verdicts, chacun via son propre résultat. Les instructions du coordinateur n'incluent pas de verdict, et le coordinateur ne peut pas marquer une vérification comme validée.
2. L'achèvement nécessite le respect des étapes de contrôle. Une tâche ne peut être finalisée que lorsque la QA a validé l'exacte version qui sera livrée (ou le code tel qu'il est, si rien n'a changé) et, si la tâche nécessite une révision, lorsque le réviseur a approuvé cette version. Si la branche a été modifiée après l'exécution de la QA, la finalisation est refusée et la nouvelle version est renvoyée à la QA.
3. La reprise de travail est limitée. Chaque agent ne peut être lancé qu'un nombre limité de fois par tâche, et un plan ne peut être révisé que quelques fois. Le nombre d'étapes et la durée totale d'exécution sont également plafonnés. Lorsque cette limite est atteinte, le coordinateur ne peut que clôturer la tâche ou la marquer comme ayant échoué.
4. Le délai d'attente est limité. Chaque attente possède une date limite.

Ainsi, une tâche pilotée par un coordinateur se termine de l'une de ces trois manières : par un pull request à votre approbation ; par la confirmation de la QA que le code réalise déjà ce que demande la tâche, donc qu'il n'y a rien à modifier ; ou par une tâche échouée indiquant la raison de cet échec. Elle ne se termine pas simplement parce que l'agent en charge l'a déclarée terminée.

Les parcours possibles pour un coordinateur#

Le coordinateur choisit comment une tâche atteint les étapes de validation. Les étapes ci-dessus sont identiques sur chaque parcours.

• Le parcours complet. Planifier, construire, vérifier, réviser, finaliser. C'est ainsi qu'une tâche s'exécute sauf si le coordinateur a une raison de suivre un autre parcours.
• Renvoyer le travail en arrière. Lorsque la QA échoue ou que le réviseur demande des modifications, les corrections sont renvoyées au développeur. La nouvelle version doit ensuite passer la QA avant que la tâche puisse être finalisée. La validation de la version précédente ne s'applique pas à la nouvelle version.
• Déjà fait. Le code réalise peut-être déjà ce que demande la tâche. Le coordinateur peut alors demander à la QA de vérifier le code inchangé par rapport aux critères d'acceptation au lieu de construire quoi que ce soit. Lorsque la QA valide et que le réviseur approuve, si une révision est requise, la tâche se finalise sans pull request, car il n'y a rien à fusionner. La validation de la QA constitue le résultat. Ce parcours est clos dès que l'exécution produit elle-même un changement, car la QA validerait sinon du code qui ne correspondra pas à ce qui sera livré.

Deux parcours plus courts sont optionnels. Coroid ne les utilise pas par défaut. Ils modifient le parcours du coordinateur, jamais les étapes de validation :

• Une modification rapide. Pour une petite correction dans un emplacement connu, le coordinateur rédige un plan plus court et donne au développeur une instruction ciblée indiquant les fichiers concernés par la modification. Le développeur travaille dans un budget d'étapes plus restreint, et tout ce qu'il modifie en dehors de ces fichiers est signalé à la QA et au réviseur.
• Une nouvelle vérification plus ciblée. Après une petite correction pour un problème détecté par la QA ou le réviseur, la QA commence à partir de cette constatation et des tests du projet. Elle donne néanmoins son verdict sur la nouvelle version complète.

Lorsqu'une révision est requise#

Par défaut, une tâche exécutée isolément passe toujours par le réviseur. Quel que soit le parcours choisi par le coordinateur, y compris lorsqu'aucune modification n'est nécessaire, la tâche ne peut être finalisée tant que le réviseur n'a pas approuvé la version validée par la QA. La QA effectue toujours la vérification, avec ou sans révision, et une révision ne remplace jamais la validation de la QA. Les tâches faisant partie d'un plan suivent les règles de leur catégorie.

Coroid dispose également d'une politique optionnelle basée sur les risques. Elle n'est pas activée par défaut. Dans ce cadre, une tâche exécutée isolément peut être finalisée sans réviseur si la modification est mineure et courante. Le réviseur reste toutefois requis dans les cas suivants :

• un réviseur avait déjà commencé à travailler sur la tâche, ou si les règles de révision de votre projet ou le Quality Graph de votre organisation l'exigent ;
• la modification touche à l'authentification, aux sessions, aux permissions, aux secrets ou à la cryptographie, aux migrations de base de données, à la configuration de build et de déploiement, aux fichiers de dépendances, ou au code interagissant avec des services externes ;
• la modification est importante (par défaut, plus de 80 lignes modifiées), ou inclut des fichiers binaires, des liens symboliques ou des sous-modules ;
• Coroid ne peut ni lire la politique ni analyser la modification elle-même. En cas de doute, le réviseur est requis.

Une modification qui ne change rien n'a jamais besoin de réviseur. C'est le code qui prend cette décision, pas le coordinateur, et le coordinateur ne peut pas contourner cette règle. Une ligne à la fin de la description de pull request indique le chemin emprunté et la raison : elle commence par « Réviseur requis » ou « Réviseur non requis ».

Architecte#

Il transforme votre description en spécification, puis la spécification en plan. Il analyse le code existant pour ancrer le plan dans la réalité du projet, mais n'écrit aucun code.

Le résultat de son travail est ce que vous validez avant le démarrage de la compilation. En mode Coordinateur, cet agent poursuit ensuite sa mission en tant que coordinateur.

Développeur#

Effectue le travail : lit le code pertinent, apporte les modifications, rédige ou met à jour les tests, et les exécute localement dans l'espace de travail jusqu'à ce qu'ils soient validés.

Lorsque le Réviseur envoie les constatations en retour, le Développeur est le rôle qui agit en conséquence. En mode Coordinateur, le coordinateur transmet les constatations, avec les corrections à apporter.

QA#

Exécute la vérification indépendamment de l'agent ayant écrit le code — votre suite de tests, les portes de qualité configurées pour le projet, et les critères d'acceptation issus de la spécification.

Le QA rend un verdict. Il ne corrige pas ce qu'il détecte ; les échecs sont renvoyés au Développeur sous forme de retravail.

Réviseur#

Lit la différence finale et produit des constatations, en appliquant les règles de révision que votre organisation a configurées. Les constatations sont soit renvoyées au développeur sous forme de retravail, soit jointes à la pull request pour vous.

Testeur web#

Pilote un navigateur réel sur une prévisualisation en cours d'exécution de votre application afin de vérifier les flux utilisateur de bout en bout. Il est utilisé lorsqu'une affirmation concernant le comportement ne peut être établie uniquement à partir du code.

Explorateur#

Un rôle de recherche en lecture seule. Les autres agents l'utilisent pour obtenir des réponses sur une base de code sans avoir à charger tout le contenu dans leur propre contexte — « où l'authentification est-elle gérée ? », « quelle fonction appelle ceci ? ».

Analyseur de dépendances#

Examine les dépendances et la manière dont les modifications se propagent dans une base de code, y compris entre projets lorsque des dépendances inter-projets sont configurées.

Pourquoi cette séparation est essentielle#

Quatre propriétés découlent de cette répartition du travail :

1. La vérification est indépendante. L'agent qui vérifie le travail n'est pas celui qui l'a rédigé, il n'a donc aucun intérêt personnel dans le résultat.
2. Le rayon d'action des erreurs est limité. Seul le rôle de développeur dispose d'outils pour écrire du code ; ainsi, une défaillance lors de la révision ou de l'analyse ne peut pas corrompre votre dépôt.
3. Chaque rôle utilise un modèle adapté à ses besoins. La planification nécessite une connaissance étendue du monde ; l'écriture de code compilable requiert quant à elle d'autres compétences. AI profile intègre un modèle par rôle pour cette raison précise.
4. L'achèvement d'une tâche est déterminé par les vérifications effectuées, et non par l'agent en charge. En mode coordinateur, l’agent qui pilote la tâche ne peut pas y mettre fin sans les verdicts du contrôle qualité et du réviseur.

Suivant#

Retourner à Comment une tâche devient une pull request pour les étapes auxquelles ces rôles sont associés ou Qu'est-ce que Coroid ? pour une vue d'ensemble plus courte.