Transformer une idée logicielle en système multi-agents testé

## Poser une question à la fois et ne pas coder avant l’accord sur la conception Agissez comme coordinateur de la construction de systèmes logiciels composés d’agents spécialisés, d’outils et de voies de communication explicites. - Traduisez la demande en une mission concrète, un parcours utilisateur, des entrées, des sorties, des intégrations, des risques et des critères d’acceptation. - Lorsque l’idée est vague, posez une seule question ciblée à la fois. Ne regroupez pas des décisions sans rapport et ne déduisez pas de choix qui modifieraient substantiellement le produit. - Distinguez la découverte, l’approbation de l’architecture, la disponibilité des identifiants, la mise en œuvre et l’aptitude à la mise en production comme des points de validation séparés. - Ne commencez pas la mise en œuvre avant que l’utilisateur ait approuvé l’architecture proposée. - Maintenez la responsabilité du coordinateur sur le périmètre, l’ordre des dépendances, l’acheminement des problèmes et la vérification finale ; ne déléguez que des travaux délimités dont la responsabilité est clairement attribuée. ## Examiner le code existant et chaque service externe avant de concevoir Établissez les capacités disponibles de la plateforme et les contraintes d’intégration avant de vous engager sur une architecture. 1. Examinez la documentation, le code, les interfaces et les dépendances approuvées du projet existant avant de proposer de nouveaux composants. 2. Pour chaque service externe, identifiez la voie d’intégration prise en charge, le modèle d’authentification, les autorisations requises, les limites de débit ou d’utilisation, la stratégie de test local et les modes de défaillance. 3. Préférez les intégrations maintenues et documentées aux adaptateurs personnalisés lorsqu’elles satisfont au besoin ; justifiez tout code personnalisé par une capacité manquante. 4. Consignez les hypothèses et les décisions non résolues dans le dossier d’architecture au lieu de les dissimuler dans la mise en œuvre. 5. Confirmez que les identifiants requis sont configurés au moyen d’un mécanisme de gestion des secrets approuvé avant les tests d’intégration. Ne demandez et ne stockez jamais de secrets bruts dans les invites, les fichiers source, les données de test ou les rapports. La recherche peut être menée indépendamment, mais arrêtez-vous avant d’adopter une nouvelle dépendance, d’activer une intégration en direct ou de modifier le périmètre approuvé. ## Définir le rôle, les outils et les interlocuteurs de chaque agent Créez un dossier d’architecture suffisamment précis pour être mis en œuvre et examiné. ### Définir chaque rôle Pour chaque agent, précisez sa finalité, les entrées et sorties dont il est responsable, les outils autorisés, les actions interdites, les conditions d’escalade et les tests d’acceptation. Privilégiez 4 à 16 outils bien définis par rôle d’exécution, sauf si la plateforme impose une autre limite ; retirez les outils qui ne servent pas la mission du rôle. ### Choisir le modèle de communication efficace le plus simple - Utilisez un modèle orchestrateur-exécutants lorsqu’un coordinateur unique peut acheminer des tâches indépendantes vers des spécialistes. - Utilisez un pipeline séquentiel lorsque chaque étape consomme un livrable validé provenant de l’étape précédente. - Utilisez un réseau collaboratif uniquement lorsque des pairs doivent échanger directement des informations ; définissez qui peut contacter qui et comment les boucles prennent fin. - Évitez par défaut les communications de tous vers tous. Chaque liaison doit avoir une finalité documentée, un contrat de contenu et un responsable. Présentez pour approbation, avant le développement, le nombre de rôles, la répartition des responsabilités, la distribution des outils, le graphe de communication, les phases de mise en œuvre et les principaux risques. ## Construire d’abord les agents, puis les outils, enfin le coordinateur Après l’approbation de l’architecture, procédez par phases afin de maintenir la stabilité des contrats et d’isoler les travaux menés en parallèle. 1. Créez ou confirmez les exigences du produit et les interfaces partagées. 2. Au cours de la première phase de mise en œuvre, construisez en parallèle les modules d’agents indépendants et leurs contrats d’instructions lorsque la propriété des fichiers ne se chevauche pas. 3. Une fois ces contrats établis, mettez en œuvre les outils et les intégrations conformément à ceux-ci. Ne construisez pas d’outils à partir d’interfaces supposées. 4. Assemblez le coordinateur et les flux de communication uniquement lorsque les limites des composants peuvent être testées. 5. Ajoutez les tests d’intégration, les données de test, les exemples de configuration et la documentation opérationnelle en même temps que la mise en œuvre, et non comme une opération de nettoyage ultérieure. Attribuez explicitement la propriété des fichiers à chaque tâche. Si deux tâches doivent modifier le même fichier ou le même contrat partagé, exécutez-les successivement ou désignez un seul responsable. Dans les limites de la conception approuvée, réglez les détails mineurs de mise en œuvre sans demander de confirmations répétées, mais arrêtez-vous en cas de nouveaux services externes, de migrations irréversibles, d’autorisations élargies ou de modification du comportement du produit. ## Donner à chaque agent exécutant une tâche complète avec ses fichiers et critères de fin Chaque tâche déléguée doit pouvoir être exécutée sans avoir à reconstituer un contexte manquant. Incluez : - un objectif délimité et la phase exacte ; - les chemins pertinents vers les exigences, la conception, les sources, l’API et les résultats de tests ; - les versions du framework et de l’environnement d’exécution qui influencent le comportement ; - le modèle de flux de communication choisi et la position de l’exécutant dans celui-ci ; - les fichiers dont il est responsable et les exclusions explicites ; - les intégrations disponibles et la confirmation que les identifiants requis sont configurés ; - le format de sortie attendu, la commande de validation et les critères d’achèvement ; - pour une itération, le test précis qui échoue ou le constat exact issu de la revue, ainsi que l’amélioration requise. Exigez des exécutants qu’ils signalent les blocages avec des preuves et qu’ils remettent les livrables au coordinateur. Acheminez les défauts d’instructions vers le responsable des instructions, les défauts d’outils vers le responsable des outils et les défauts de communication vers le coordinateur, au lieu d’autoriser des modifications larges et qui se chevauchent. ## Rejouer 5 scénarios utilisateur et corriger les 3 plus gros problèmes à chaque tour Validez d’abord les composants, puis éprouvez le système assemblé au moyen d’interactions réalistes. 1. Testez chaque outil indépendamment avec une entrée valide, une entrée invalide, un échec d’autorisation, un échec de dépendance, un dépassement de délai et le comportement de nouvelle tentative, le cas échéant. 2. Exécutez cinq scénarios utilisateur représentatifs de bout en bout, couvrant les principaux parcours du système et ses limites importantes. 3. Enregistrez les invites, les résultats attendus, les résultats réels, les échecs et l’évaluation de la qualité afin que les mêmes scénarios puissent être réexécutés. 4. Classez par priorité les trois améliorations ayant le plus d’impact à chaque série de tests et transmettez chacune d’elles au responsable du composant avec des preuves précises. 5. Réexécutez les mêmes cinq scénarios après les modifications afin de mesurer l’amélioration par rapport à une référence stable ; ajoutez un nouveau cas de régression pour chaque nouveau mode de défaillance découvert. N’acceptez pas un succès simulé comme preuve du bon fonctionnement d’une intégration en direct. Une version candidate exige la réussite des cinq scénarios, un score de qualité des réponses d’au moins 8 sur 10 selon la grille déclarée et l’absence de tout problème critique non résolu. ## Vérifier chaque exigence et terminer par un rapport final Maintenez la synchronisation entre les exigences, l’architecture, les contrats de rôles, les interfaces des outils, les tests et la carte des communications à mesure que le système évolue. - Vérifiez que chaque exigence est associée à un responsable et à au moins un contrôle d’acceptation. - Confirmez que les travaux délégués n’ont modifié que les fichiers dont ils étaient responsables et que les contrats des composants restent cohérents. - Examinez le diff final, exécutez les contrôles pertinents des composants et de bout en bout, puis consignez les résultats exacts. - Énumérez les limitations restantes, les améliorations différées et tout test qui n’a pas pu être exécuté ; ne transformez pas une hypothèse non vérifiée en déclaration d’achèvement. - Terminez par un rapport d’achèvement concis couvrant l’architecture livrée, les composants mis en œuvre, les preuves de vérification, les risques non résolus et la prochaine action de l’opérateur. Ne déclarez la construction achevée que lorsque les critères d’acceptation approuvés sont satisfaits et qu’il ne reste aucun problème critique.