Méthodologies

    Camin Pulse maîtrise neuf cadres méthodologiques agiles, produit et IA. On les utilise quand ils résolvent un problème, jamais par dogmatisme. Voici quand chacun s'applique, ce qu'il livre, et les pièges à éviter.

    ScrumKanbanSAFe (Scaled Agile Framework)LeSS (Large-Scale Scrum)LeanProduct DiscoveryProduct DeliveryProduct Management & OKRIA générative en entreprise

    Scrum

    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.

    Kanban

    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.

    LeSS (Large-Scale Scrum)

    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 ».

    Lean

    É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 ».

    Product Discovery

    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.

    Product Delivery

    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.

    Product Management & OKR

    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.
    FAQ

    Questions fréquentes sur les méthodologies

    Scrum pour une équipe produit de 5 à 9 personnes avec un périmètre clair. Kanban pour un flux continu et beaucoup de variabilité (support, ops). SAFe pour 50+ personnes réparties en plusieurs équipes alignées sur un même produit. Le choix dépend de la taille, du contexte et de la maturité — jamais d'une préférence dogmatique.

    Une transformation agile structurante prend 6 à 18 mois selon la taille de l'organisation. Les premiers résultats visibles (rituels, cadence, indicateurs) arrivent en 4 à 8 semaines. La bascule culturelle complète demande plusieurs cycles trimestriels.

    Le Product Discovery est l'ensemble des pratiques qui permettent de valider qu'on construit la bonne chose avant de la construire : interviews utilisateurs, tests d'hypothèses, prototypes, opportunity solution tree. Il se mène en continu, en parallèle de la delivery.

    Une équipe produit se structure autour de trois rôles : Product Manager (vision et priorisation), Tech Lead ou Engineering Manager (excellence technique), et un cluster de développeurs et UX/UI. Pour un produit complexe, on ajoute un Product Designer dédié et un Data Analyst.

    En quatre étapes : (1) cartographier les cas d'usage à fort ROI, (2) lancer un POC RAG sur des données internes anonymisées, (3) formaliser la politique d'usage (CNIL, AI Act), (4) former les équipes. Compter 6 à 12 semaines pour le premier cas d'usage en production.

    Scrum impose des sprints de durée fixe et des rôles définis. Kanban est un flux continu avec limites de WIP. Scrum convient aux équipes produit avec périmètre stable ; Kanban convient aux flux variables (support, run, demandes ad hoc).

    SAFe (Scaled Agile Framework) est un cadre de mise à l'échelle de l'agilité pour 50 à 500+ personnes. Il introduit le concept d'Agile Release Train et de PI Planning trimestriel. Pertinent pour grands programmes ou environnements régulés ; sur-dimensionné en dessous de 30 personnes.

    Le Lean apporte une lecture flux de valeur : on cartographie le chemin de l'idée jusqu'à la production, on identifie les gaspillages (attentes, retouches, handoffs) et on les supprime. C'est ce qui rend une transformation agile durable.

    Quelle méthodologie pour votre contexte ?

    30 minutes avec Rémy Buffetto pour faire le tri sans dogmatisme.

    Qui est Rémy BuffettoÉtudes de cas