Scrum ou Kanban : comment choisir sur un projet web B2B ?

Scrum convient souvent quand le périmètre évolue encore beaucoup et qu’il faut un rythme de démo et d’arbitrage régulier avec le sponsor. Kanban brille quand le flux est continu (correctifs, évolutions mineures, équipe support) et que l’on veut limiter le travail en cours plutôt que couper le temps en boîtes fixes. Hybrides possibles : Scrum pour la phase produit, Kanban pour la maintenance ; l’important est d’assumer le modèle et de ne pas mélanger les règles sans clarification.

Un client exige un cahier des charges complet avant de passer en Agile : contradiction ?

Non si l’on sépare vision (objectifs, contraintes légales, intégrations) du détail exécutable. Un document de cadrage solide peut coexister avec des itérations : il fixe les garde-fous, le backlog détaille ce qui sera fait sprint par sprint. L’erreur est de croire que « Agile » signifie « on ne sait pas où on va » : il s’agit d’apprendre en chemin avec des limites claires sur budget, conformité et périmètre MVP.

L’Agile réduit-il toujours les coûts par rapport au Cycle en V ?

Pas automatiquement : il réduit souvent le coût des mauvaises directions en les détectant plus tôt, mais expose plus tôt les arbitrages (priorités, dette technique). Le gain se lit plutôt en valeur livrée par unité de temps et en capacité à arrêter ou pivoter sans cérémonie. Sans discipline produit, l’Agile peut coûter autant qu’un cycle rigide — avec plus de réunions en prime.

Qu'est-ce que Méthodologie Agile (Scrum / Kanban) ?

Elle découpe le travail en cycles courts (sprints en Scrum, flux continu en Kanban) avec des livrables potentiellement utilisables à la fin de chaque itération. Le feedback métier et utilisateur est intégré en continu pour ajuster le backlog, plutôt que de figer un cahier des charges unique sur douze mois. Scrum cadre les rôles, cérémonies et artefacts (Product Owner, Scrum Master, backlog, incréments) ; Kanban limite le travail en cours (WIP) et visualise le flux pour fluidifier la livraison. Les deux partagent l’idée d’amélioration continue et de transparence sur l’état réel du produit.

Comment ça marche ?

On maintient un backlog priorisé par le Product Owner (ou équivalent), on sélectionne un sous-ensemble réalisable pour la prochaine itération, on développe et teste, puis on démontre l’incrément aux parties prenantes et on ajuste la suite. En Scrum, la durée du sprint est fixe ; en Kanban, les cartes avancent colonne par colonne avec des limites WIP pour éviter l’engorgement. La définition du « terminé » (Definition of Done) évite que « livré » signifie « presque prêt ». Les rétrospectives servent à corriger le process, pas à rejouer les mêmes frictions en silence.

L'Impact Business

Elle permet de pivoter si le marché ou les priorités changent, de livrer un MVP plus tôt et de réduire le time-to-market sur les fonctionnalités à forte valeur. Les décideurs voient plus tôt un logiciel « vrai » plutôt qu’un document de spécifications ; les risques d’investir six mois dans la mauvaise direction diminuent. En B2B, cela aide à aligner sponsors, métier et équipe tech sur des jalons courts mesurables (démo, adoption, revenus). Attention : l’Agile n’élimine pas le besoin d’arbitrage ni de budget — il les rend visibles plus souvent, ce qui peut déplaire si l’organisation confondait auparavant « plan figé » avec « tranquillité ».

Bonnes pratiques vs Erreurs communes

✅ À faire : Travailler en sprints (ou équivalent avec rythme stable), tenir un backlog visible et priorisé, et communiquer de façon transparente : état du flux, risques, changements de priorité expliqués au sponsor. Documenter ce qui doit survivre au temps (API, règles métier, environnements) sans noyer l’équipe sous des dossiers jamais relus.
❌ À éviter : Confondre « Agile » avec « absence de documentation et d’organisation » : l’Agile remplace la bureaucratie inutile par des artefacts utiles (backlog, critères d’acceptation, historique de décisions), pas par le vide. Sans cadre, on retombe sur du bricolage oral et des dettes cachées.

Prompt IA

Contexte : produit [SaaS B2B / portail client / app métier], persona [rôle utilisateur], objectif sprint [ex. activation d’un flux clé]. À partir de cette epic : « [titre epic] », génère 5 à 8 user stories au format « En tant que… je veux… afin de… », avec critères d’acceptation testables (Given / When / Then) pour chacune. Indique la dépendance technique ou métier si évidente, et propose un ordre de priorisation MoSCoW pour le prochain sprint.