Pourquoi une méthode ?
Après plus de quinze ans à livrer des projets logiciels — du site vitrine au CRM sur mesure — j'ai observé un schéma récurrent : les projets échouent rarement pour des raisons techniques. Ils échouent parce que le développement commence avant que le problème métier soit clairement défini. La méthode BMAD (Business → Model → Architecture → Development) impose une progression disciplinée qui garantit que chaque phase repose sur les fondations solides de la précédente.
Phase B : Business — Comprendre le vrai problème
Avant d'écrire la moindre ligne de code, il faut comprendre le pourquoi. Qui sont les utilisateurs ? Quels processus métier le logiciel doit-il supporter ? Quelles sont les contraintes réglementaires, budgétaires, temporelles ?
En pratique, cette phase produit trois livrables :
- Business Requirements Document (BRD) : objectifs, KPIs, contraintes
- User Stories priorisées : avec critères d'acceptation vérifiables
- Matrice des risques : techniques, métier, organisationnels
# Exemple de User Story structurée
story: US-042
role: "Responsable commercial"
action: "Exporter les leads qualifiés du dernier trimestre en CSV"
benefit: "Alimenter le reporting Power BI sans intervention technique"
acceptance_criteria:
- "Le fichier contient les colonnes : nom, email, score, date_qualification"
- "Les leads avec score < 50 sont exclus"
- "L'export se termine en moins de 5 secondes pour 10 000 leads"
priority: must_have
sprint: 3Cette rigueur initiale évite le syndrome du « on verra en cours de route » qui transforme les projets en marches de la mort.
Phase M : Model — Structurer les données et les flux
Une fois le métier compris, on modélise. Les entités, leurs relations, les flux de données, les états possibles. C'est ici que le diagramme entité-relation, les diagrammes de séquence et les machines à états prennent tout leur sens.
// Modélisation d'un Lead avec des états explicites
final class Lead
{
public function __construct(
public readonly int $id,
public readonly string $name,
public readonly string $email,
private LeadStatus $status = LeadStatus::New,
private int $score = 0,
private readonly DateTimeImmutable $createdAt = new DateTimeImmutable(),
) {}
public function qualify(int $score): void
{
if ($score < 0 || $score > 100) {
throw new DomainException('Score must be between 0 and 100');
}
$this->score = $score;
$this->status = $score >= 50
? LeadStatus::Qualified
: LeadStatus::Disqualified;
}
public function canBeContacted(): bool
{
return $this->status === LeadStatus::Qualified
&& $this->score >= 70;
}
}
enum LeadStatus: string
{
case New = 'new';
case Qualified = 'qualified';
case Disqualified = 'disqualified';
case Converted = 'converted';
}Le modèle devient le contrat entre l'équipe technique et le métier. Si le modèle est faux, tout ce qui suit sera faux aussi.
Phase A : Architecture — Les décisions structurantes
L'architecture répond aux questions « comment » sans entrer dans l'implémentation. Choix de la stack technique, patterns applicatifs, stratégie de déploiement, topologie réseau. C'est ici qu'on décide si on part sur un monolithe modulaire ou des microservices, si on utilise un ORM ou du SQL natif, si on déploie sur Kubernetes ou un simple VPS.
Un Architecture Decision Record (ADR) documente chaque choix significatif :
# ADR-003 : Stratégie de cache pour le catalogue produits
## Contexte
Le catalogue contient 50 000 références avec mise à jour quotidienne.
Les pages catalogue représentent 70% du trafic.
## Décision
Cache HTTP (Varnish) avec invalidation par tags.
Cache applicatif (Redis) pour les agrégations (filtres, compteurs).
Pas de cache de requête MySQL (invalidation trop complexe).
## Conséquences
+ TTFB catalogue < 100ms (vs 800ms sans cache)
+ Scalabilité horizontale via ajout de nœuds Varnish
- Complexité d'invalidation lors des imports catalogue
- Dépendance infrastructure Redis (monitoring requis)Phase D : Development — Exécuter avec discipline
Ce n'est qu'en phase D qu'on écrit du code. Et parce que les trois phases précédentes ont été rigoureusement exécutées, le développement est fluide : les User Stories sont claires, le modèle est validé, l'architecture est documentée.
En phase D, les pratiques suivantes sont non négociables :
- Tests d'abord : chaque User Story a ses tests d'acceptation avant l'implémentation
- CI/CD dès le jour 1 : pipeline automatisé avec linting, tests, analyse statique
- Code review systématique : chaque merge request est relue par au moins un pair
- Déploiements fréquents : livrer en continu réduit le risque par déploiement
# Pipeline CI/CD minimaliste mais efficace
stages:
- lint
- test
- security
- deploy
php-stan:
stage: lint
script:
- vendor/bin/phpstan analyse src --level=max
phpunit:
stage: test
script:
- vendor/bin/phpunit --coverage-text --min=80
dependency-check:
stage: security
script:
- composer audit
- vendor/bin/psalm --taint-analysisBMAD en pratique : retour d'expérience
Sur mon dernier projet CRM (12 modules, 18 mois de développement), la méthode BMAD a permis de livrer dans les délais avec un taux de bugs en production inférieur à 2 par sprint. La phase Business a duré 6 semaines — un investissement qui a évité des mois de corrections ultérieures. Les ADR ont servi de référence tout au long du projet, évitant les débats récurrents sur des décisions déjà prises.
Conclusion
La méthode BMAD n'est pas une invention révolutionnaire. C'est la formalisation de pratiques éprouvées : comprendre avant de modéliser, modéliser avant d'architecturer, architecturer avant de coder. Sa force réside dans sa discipline : chaque phase a ses livrables, ses critères de sortie, et ses validations. Dans un contexte où la pression pour « coder d'abord » est constante, BMAD offre un cadre pour résister à cette tentation et livrer des logiciels qui résolvent vraiment le problème posé.