118 lines
4.5 KiB
Markdown
118 lines
4.5 KiB
Markdown
---
|
||
title: "Prévention des conflits entre agents"
|
||
description: Comment l'architecture empêche les conflits lorsque plusieurs agents implémentent un système
|
||
sidebar:
|
||
order: 4
|
||
---
|
||
|
||
Lorsque plusieurs agents IA implémentent différentes parties d'un système, ils peuvent prendre des décisions techniques contradictoires. La documentation d'architecture prévient cela en établissant des standards partagés.
|
||
|
||
## Types de conflits courants
|
||
|
||
### Conflits de style d'API
|
||
|
||
Sans architecture :
|
||
- L'agent A utilise REST avec `/users/{id}`
|
||
- L'agent B utilise des mutations GraphQL
|
||
- Résultat : Patterns d'API incohérents, consommateurs confus
|
||
|
||
Avec architecture :
|
||
- L'ADR[^1] spécifie : « Utiliser GraphQL pour toute communication client-serveur »
|
||
- Tous les agents suivent le même pattern
|
||
|
||
### Conflits de conception de base de données
|
||
|
||
Sans architecture :
|
||
- L'agent A utilise des noms de colonnes en snake_case
|
||
- L'agent B utilise des noms de colonnes en camelCase
|
||
- Résultat : Schéma incohérent, requêtes illisibles
|
||
|
||
Avec architecture :
|
||
- Un document de standards spécifie les conventions de nommage
|
||
- Tous les agents suivent les mêmes patterns
|
||
|
||
### Conflits de gestion d'état
|
||
|
||
Sans architecture :
|
||
- L'agent A utilise Redux pour l'état global
|
||
- L'agent B utilise React Context
|
||
- Résultat : Multiples approches de gestion d'état, complexité
|
||
|
||
Avec architecture :
|
||
- L'ADR spécifie l'approche de gestion d'état
|
||
- Tous les agents implémentent de manière cohérente
|
||
|
||
## Comment l'architecture prévient les conflits
|
||
|
||
### 1. Décisions explicites via les ADR[^1]
|
||
|
||
Chaque choix technologique significatif est documenté avec :
|
||
- Contexte (pourquoi cette décision est importante)
|
||
- Options considérées (quelles alternatives existent)
|
||
- Décision (ce qui a été choisi)
|
||
- Justification (pourquoi cela a-t-il été choisi)
|
||
- Conséquences (compromis acceptés)
|
||
|
||
### 2. Guidance spécifique aux FR/NFR[^2]
|
||
|
||
L'architecture associe chaque exigence fonctionnelle à une approche technique :
|
||
- FR-001 : Gestion des utilisateurs → Mutations GraphQL
|
||
- FR-002 : Application mobile → Requêtes optimisées
|
||
|
||
### 3. Standards et conventions
|
||
|
||
Documentation explicite de :
|
||
- La structure des répertoires
|
||
- Les conventions de nommage
|
||
- L'organisation du code
|
||
- Les patterns de test
|
||
|
||
## L'architecture comme contexte partagé
|
||
|
||
Considérez l'architecture comme le contexte partagé que tous les agents lisent avant d'implémenter :
|
||
|
||
```text
|
||
PRD : "Que construire"
|
||
↓
|
||
Architecture : "Comment le construire"
|
||
↓
|
||
L'agent A lit l'architecture → implémente l'Epic 1
|
||
L'agent B lit l'architecture → implémente l'Epic 2
|
||
L'agent C lit l'architecture → implémente l'Epic 3
|
||
↓
|
||
Résultat : Implémentation cohérente
|
||
```
|
||
|
||
## Sujets clés des ADR
|
||
|
||
Décisions courantes qui préviennent les conflits :
|
||
|
||
| Sujet | Exemple de décision |
|
||
| ---------------- | -------------------------------------------- |
|
||
| Style d'API | GraphQL vs REST vs gRPC |
|
||
| Base de données | PostgreSQL vs MongoDB |
|
||
| Authentification | JWT vs Sessions |
|
||
| Gestion d'état | Redux vs Context vs Zustand |
|
||
| Styling | CSS Modules vs Tailwind vs Styled Components |
|
||
| Tests | Jest + Playwright vs Vitest + Cypress |
|
||
|
||
## Anti-patterns à éviter
|
||
|
||
:::caution[Erreurs courantes]
|
||
- **Décisions implicites** — « On décidera du style d'API au fur et à mesure » mène à l'incohérence
|
||
- **Sur-documentation** — Documenter chaque choix mineur cause une paralysie analytique
|
||
- **Architecture obsolète** — Les documents écrits une fois et jamais mis à jour poussent les agents à suivre des patterns dépassés
|
||
:::
|
||
|
||
:::tip[Approche correcte]
|
||
- Documenter les décisions qui traversent les frontières des epics
|
||
- Se concentrer sur les zones sujettes aux conflits
|
||
- Mettre à jour l'architecture au fur et à mesure des apprentissages
|
||
- Utiliser `bmad-correct-course` pour les changements significatifs
|
||
:::
|
||
|
||
## Glossaire
|
||
|
||
[^1]: ADR (Architecture Decision Record) : document qui consigne une décision d’architecture, son contexte, les options envisagées, le choix retenu et ses conséquences, afin d’assurer la traçabilité et la compréhension des décisions techniques dans le temps.
|
||
[^2]: FR / NFR (Functional / Non-Functional Requirement) : exigences décrivant respectivement **ce que le système doit faire** (fonctionnalités, comportements attendus) et **comment il doit le faire** (contraintes de performance, sécurité, fiabilité, ergonomie, etc.).
|