Cadre itératif basé sur des sprints de 1 à 4 semaines, trois rôles (Product Owner, Scrum Master, équipe), cinq événements (planning, daily, review, rétro, refinement).
Quand l'utiliser
Équipe produit de 5 à 9 personnes, périmètre clair, besoin de cadence et de visibilité côté business.
Livrables typiques
- Backlog priorisé et raffiné
- Sprints rythmés avec revue et rétro
- Definition of Done partagée
- Vélocité et burndown comme indicateurs internes (jamais comme objectif)
Pièges classiques
- Scrum cargo-cult : rituels sans contenu, vélocité comme KPI de productivité.
- PO bouche-trou qui retranscrit des specs au lieu d'arbitrer.
Flux continu, limites de Work-in-Progress (WIP), mesure de lead time et throughput. Pas de sprint imposé.
Quand l'utiliser
Équipes support, run, ops, ou produit avec forte variabilité (urgences, incidents, demandes externes).
Livrables typiques
- Tableau Kanban explicite (colonnes = étapes réelles)
- Limites WIP par colonne
- Lead time, cycle time, throughput suivis
- Politiques de classe de service (urgent, standard, dette)
Pièges classiques
- Tableau Kanban = simple Trello, sans WIP : aucune amélioration.
- Ignorer le lead time : on ne sait pas si on accélère.
SAFe (Scaled Agile Framework)
Mise à l'échelle de l'agilité pour 50 à 500+ personnes : Agile Release Trains, PI Planning trimestriels, alignement portfolio → programme → équipe.
Quand l'utiliser
Grands programmes pluri-équipes, environnements régulés (banque, santé, public), besoin d'alignement explicite.
Livrables typiques
- Cadence PI (Program Increment) de 8 à 12 semaines
- PI Planning physique ou distribué
- ART (Agile Release Train) constitués
- Roadmap portfolio reliée aux OKR / objectifs business
Pièges classiques
- Adopter SAFe complet pour 2 équipes : surdimensionné.
- Confondre PI Planning et grand-messe descendante.
Scrum à grande échelle, minimaliste : un seul Product Owner, un seul backlog, plusieurs équipes Scrum synchronisées.
Quand l'utiliser
Organisations qui veulent passer à l'échelle sans empiler les couches managériales.
Livrables typiques
- Backlog produit unique partagé
- Sprint synchronisés entre équipes
- Overall Retrospective inter-équipes
- Composantes / features partagées sans silos
Pièges classiques
- Sous-estimer le coût de coordination d'un PO unique.
- Confondre LeSS avec « Scrum multiplié par N ».
Élimination des gaspillages, flux tiré, amélioration continue (Kaizen), respect des personnes. Origine industrielle (Toyota), applicable au logiciel et au produit.
Quand l'utiliser
Organisations matures qui cherchent à fluidifier le flux de valeur de bout en bout (idée → production).
Livrables typiques
- Value Stream Mapping
- Identification des gaspillages (attente, retouches, surproduction)
- Cycle d'amélioration continue (PDCA)
- Indicateurs de flux (lead time global, qualité)
Pièges classiques
- Réduire Lean à « faire pareil avec moins » au lieu de « livrer plus de valeur avec moins de gâchis ».
Recherche utilisateur continue, tests d'hypothèses, prototypes, opportunity solution tree (Teresa Torres). Réduit le risque de construire la mauvaise chose.
Quand l'utiliser
Avant de coder. À chaque itération, en parallèle de la delivery.
Livrables typiques
- Cartographie des outcomes
- Hypothèses formulées et testées
- Interviews utilisateurs hebdomadaires
- Prototypes (Figma, no-code) avant développement
Pièges classiques
- Discovery one-shot en amont, puis plus rien.
- Confondre validation et confirmation biaisée.
Pratiques d'ingénierie qui rendent l'agilité possible : intégration continue, déploiement continu, trunk-based development, feature flags, observabilité.
Quand l'utiliser
Toujours. La delivery est ce qui rend la discovery actionnable.
Livrables typiques
- Pipeline CI/CD opérationnel
- Tests automatisés (unit, intégration, e2e)
- Déploiements quotidiens (idéalement plusieurs par jour)
- Feature flags pour découpler déploiement et release
Pièges classiques
- Vouloir scaler l'agilité sans investir dans la delivery technique.
- Backlog parfait, mais une release tous les 3 mois.
Stratégie produit, vision, OKR trimestriels, priorisation par opportunité, gouvernance multi-équipes.
Quand l'utiliser
À partir du moment où il y a plus d'idées que de capacité, et plusieurs équipes à aligner.
Livrables typiques
- Vision produit écrite
- OKR trimestriels reliés à la stratégie
- Roadmap par outcomes (pas par features)
- Rituels de priorisation transparents
Pièges classiques
- OKR transformés en KPI commerciaux déguisés.
- Roadmap qui ne décrit que des features sans hypothèses.
IA générative en entreprise
Cartographie des cas d'usage, sprint IA, RAG (Retrieval-Augmented Generation) sur les données internes, conformité CNIL et AI Act, change management.
Quand l'utiliser
Avant de signer un POC vendor. Pour cadrer la stratégie IA d'une PME / ETI sur 12 mois.
Livrables typiques
- Cartographie des cas d'usage prioritaires
- POC RAG sur données internes, sans fuite
- Politique d'usage (data, conformité, sécurité)
- Formation des équipes (prompt, vérification, garde-fous)
Pièges classiques
- Signer un POC IA générique sans cas d'usage clair.
- Mettre les données sensibles dans ChatGPT public sans gouvernance.