i

Description

Convoyeurs à rouleaux et à bande d'une usine, en courbes bleues enchaînées.

Source

falco (Pixabay) · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Les méthodes agiles et lean (Manifeste, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…)

Vous saurez ce que le Manifeste agile dit vraiment (et ce qu'on lui fait dire) et situer chaque famille : flux (Kanban), ingénierie (XP), lean, découverte produit (Lean startup), cycles à…

En bref

• Vous saurez ce que le Manifeste agile dit vraiment (et ce qu'on lui fait dire) et situer chaque famille : flux (Kanban), ingénierie (XP), lean, découverte produit (Lean startup), cycles à appétit (Shape Up), cadres d'entreprise (SAFe, LeSS, Nexus, Scrum@Scale), culture de livraison (DevOps).
• Vous comprendrez le mécanisme de chacune : pourquoi limiter le travail en cours accélère, pourquoi XP rend le changement bon marché, pourquoi Shape Up supprime le backlog.
• Vous saurez ce qui se transpose à la data et ce qui casse (qualité des sources, historisation, recette sur chiffres).
• Vous aurez un repère honnête sur le modèle Spotify : un instantané, pas un modèle à copier.
• Vous pourrez ensuite arbitrer avec le comparatif et choisir et hybrider.

Sur cette page

1. 1. Le Manifeste agile et ses principes
2. 2. Kanban et gestion du flux
3. 3. Extreme Programming (XP)
4. 4. Scrumban
5. 5. Lean, Toyota et la chasse au gaspillage
6. 6. Lean startup
7. 7. Shape Up
8. 8. DSDM
9. 9. Crystal
10. 10. FDD (Feature-Driven Development)
11. 11. SAFe
12. 12. LeSS
13. 13. Nexus
14. 14. Scrum@Scale
15. 15. Le « modèle Spotify » et ses limites
16. 16. DevOps comme culture
17. 17. Tableau de synthèse
18. 18. Contribution de l'IA
19. 19. Voir aussi

Niveau : 🟢→🔴

1. Le Manifeste agile et ses principes#

🟢 Novice — En février 2001, dix-sept praticiens réunis à Snowbird (Utah) signent le Manifeste pour le développement agile de logiciels. Il tient en quatre valeurs, formulées comme des préférences (« même s'il y a de la valeur dans les éléments de droite, nous valorisons davantage ceux de gauche ») :

Il est accompagné de 12 principes. Ceux qui portent le plus de conséquences pratiques :

• satisfaire le client par des livraisons précoces et continues de logiciel utile ;
• accueillir le changement, même tardif ;
• livrer fréquemment (de quelques semaines à quelques mois, plutôt le plus court) ;
• collaboration quotidienne entre métier et développeurs ;
• bâtir autour de personnes motivées, leur faire confiance ;
• la conversation en face à face est la forme la plus efficace de transmission ;
• le logiciel qui fonctionne est la principale mesure d'avancement ;
• rythme soutenable ; excellence technique et conception soignée augmentent l'agilité ;
• simplicité : l'art de maximiser la quantité de travail non fait ;
• équipes auto-organisées ; rétrospective régulière pour s'ajuster.

🟡 Pratique — Ce que le Manifeste n'est pas : un rejet de la documentation, de la planification ou des contrats (le texte dit « davantage », pas « exclusivement »), ni une méthode. C'est un jeu de valeurs à partir duquel des méthodes ont été construites. Le piège de lecture le plus fréquent est de réduire « agile » à un calendrier de cérémonies : des stand-up sans amélioration du produit sont du théâtre agile.

🔴 Expert — La famille agile se lit selon trois axes qui expliquent les désaccords entre méthodes :

Les échecs d'agilité viennent presque toujours d'un axe négligé : Scrum sans ingénierie (XP) accumule de la dette ; une équipe excellente en ingénierie sans produit livre vite la mauvaise chose ; une organisation qui scale le cadre sans résoudre les dépendances ajoute des couches. Cette lecture structure la suite.

🟡 Volet data — Le Manifeste parle de « logiciel », mais le principe tient pour la donnée : un incrément est un jeu de données fiable et consommable (une table de faits chargée, un modèle sémantique, un rapport validé sur des chiffres connus), pas un script. Voir Scrum et data et la matrice « conduite de projet data ».

2. Kanban et gestion du flux#

🟢 Novice — Kanban (« signal visuel » en japonais) provient du système de production de Toyota (années 1940-50). Appliqué au développement par David J. Anderson (Kanban, 2010) : on visualise le travail sur un tableau en colonnes (À faire → En cours → Vérif → Fait), on limite le travail en cours (WIP) par colonne, et on optimise le flux. Pas de sprint, pas de rôle imposé : on part du processus existant et on l'améliore par petites évolutions.

🟡 Pratique — Les six pratiques de la méthode Kanban : visualiser le flux ; limiter le WIP ; gérer le flux ; rendre les politiques explicites (définition de « fait », règles de priorité) ; mettre en place des boucles de rétroaction ; améliorer en collaboration, évoluer par l'expérience.

La mécanique centrale est la loi de Little (théorème de théorie des files) : en régime stable,

Limiter le WIP raccourcit le délai sans demander de travailler plus vite : on cesse de démarrer pour commencer à terminer. Mesures usuelles : lead time (de la demande à la livraison), cycle time (du début effectif à la fin), débit, âge du travail en cours, diagramme de flux cumulé (CFD). On se sert de percentiles (« 85 % des éléments sont livrés en ≤ 9 jours ») plutôt que de moyennes pour s'engager.

Classes de service : urgent (expédite, limité à un seul à la fois), date fixe, standard, intangible (dette, refonte) — avec des règles explicites pour éviter que l'urgent ne mange tout.

Forces : démarrage sans bouleversement, très adapté au travail de support, de run et de demandes imprévisibles, gain visible de délai, métriques objectives. Faiblesses : pas de cadence de décision intégrée (risque de dérive sans planification), pas d'engagement par itération (certaines directions veulent un « sprint goal »), peu d'aide pour la découverte produit.

🟡 Volet data — Kanban est la méthode naturelle du run data : anomalies de chargement, demandes d'évolution de rapport, corrections de données, droits d'accès. Les files d'attente y sont aléatoires, les tailles très variables.

🧪 Exemple — Une équipe BI de 4 personnes reçoit 15 demandes par semaine et en traite 12 : la file grossit. Avec WIP total plafonné à 8 et classes de service, le lead time au 85ᵉ percentile passe d'environ 5 semaines à 2 semaines en deux mois, sans embauche : la plupart des demandes dormaient « en cours » en attente de recette. (Ordre de grandeur illustratif, pas une mesure.)

3. Extreme Programming (XP)#

🟢 Novice — XP (Kent Beck, fin des années 1990, projet C3 chez Chrysler) est la méthode agile la plus tournée vers la technique. Son idée : si les pratiques qui réduisent le risque sont bonnes, poussons-les à l'extrême. Beaucoup de pratiques « agiles » techniques modernes (TDD, intégration continue, refactoring, petites livraisons) en viennent.

Valeurs (2ᵉ édition, 2004) : communication, simplicité, feedback, courage, respect.

🟡 Pratique — Les pratiques principales :

La mécanique : le TDD (rouge → vert → refactor) produit une suite de tests qui rend le refactoring sûr ; le refactoring maintient la conception simple ; la conception simple rend le changement bon marché. La courbe du coût du changement s'aplatit (voir méthodes prédictives, §13).

Forces : qualité technique élevée, feedback très court, dette maîtrisée. Faiblesses : exigence de discipline, résistance culturelle au binôme, client sur site rarement obtenu, faible couverture de la gouvernance et du contrat.

🟡 Volet data — Les pratiques XP existent, mais le moyen diffère :

• Tests d'abord → tests de données : tests de contraintes (unicité de clé, non-nullité), de réconciliation (totaux source/cible), de règles de gestion sur jeux minimaux et déterministes ; frameworks de tests pour T-SQL (tSQLt) ; tests de mesures DAX sur un modèle de référence.
• Intégration continue → compilation du projet de base de données, déploiement sur une base éphémère, exécution des tests de données, validation du modèle sémantique (voir CI/CD pour la data).
• Refactoring → renommage contrôlé d'objets, découpage de vues, extraction de logique vers une couche commune ; il exige une cartographie des dépendances (qui consomme cette colonne ?), sinon un renommage casse des rapports en aval.
• Binôme → relecture à quatre yeux des requêtes SQL critiques, binôme analyste ↔ développeur sur les règles de calcul.

-- Test de données minimal (idempotence d'un chargement) : rejouer ne doit pas changer le résultat.
EXEC dbo.p_Charger_Ventes @Jour = '2026-09-30';
SELECT SUM(Montant) AS M1, COUNT(*) AS N1 FROM dwh.FACT_Ventes WHERE DateVente = '2026-09-30';
EXEC dbo.p_Charger_Ventes @Jour = '2026-09-30';   -- rejeu
SELECT SUM(Montant) AS M2, COUNT(*) AS N2 FROM dwh.FACT_Ventes WHERE DateVente = '2026-09-30';
-- Attendu : M1 = M2 et N1 = N2 (sinon : chargement non idempotent, doublons).

4. Scrumban#

🟡 Pratique — Scrumban (Corey Ladas, 2008) est un hybride Scrum-Kanban : on conserve la cadence de Scrum (revue, rétrospective, replanification régulière, rôles allégés) et on importe de Kanban le flux continu, la limite de WIP et l'approvisionnement à la demande (on replanifie quand le stock de travail prêt tombe sous un seuil, plutôt qu'à date fixe).

Usages typiques :

• Transition : une équipe en cascade ou en support passe à l'itératif sans grand soir ;
• Équipes mixtes projet + run : le sprint absorbe mal les urgences, le flux continu les absorbe ;
• Équipes très orientées maintenance, où l'engagement par sprint n'a pas de sens.

Forces : souple, évolutif, rendement de flux. Faiblesses : flou — chacun appelle « Scrumban » une chose différente, et l'absence de règles claires peut dériver vers le « Scrum sans engagements ».

🟡 Volet data — C'est l'hybride le plus courant des équipes BI qui font à la fois du projet et du support : une capacité réservée (par exemple 30 %) au flux d'incidents, le reste en itérations. Voir choisir et hybrider.

5. Lean, Toyota et la chasse au gaspillage#

🟢 Novice — Lean est une philosophie de gestion issue du Toyota Production System (Taiichi Ohno, Eiji Toyoda, après-guerre). Principe : créer de la valeur pour le client en éliminant le gaspillage (muda). Les sept gaspillages classiques de production :

Un huitième gaspillage est souvent ajouté : le talent inexploité.

🟡 Pratique — Mary et Tom Poppendieck (Lean Software Development, 2003) ont adapté Lean au logiciel en sept principes : éliminer le gaspillage ; amplifier l'apprentissage ; décider le plus tard possible (au dernier moment responsable) ; livrer le plus vite possible ; responsabiliser l'équipe ; intégrer la qualité dans le produit ; optimiser l'ensemble (vue systémique).

Outils utiles :

• Value Stream Mapping : cartographier le flux de la demande à la livraison, en distinguant temps de travail et temps d'attente. Résultat typique : l'efficacité de flux (temps de valeur / délai total) est basse — de l'ordre de quelques dizaines de pour cent dans un processus à files d'attente, souvent bien moins ; l'essentiel du délai est de l'attente.
• Pull plutôt que push : on tire le travail quand on a de la capacité (Kanban).
• Juste-à-temps : décider/spécifier au plus près de la réalisation.
• Jidoka (« autonomation » : arrêter la ligne au premier défaut) → en data, un chargement qui échoue plutôt que de charger des données non conformes.
• Kaizen : amélioration continue par petits pas (rétrospectives).

Forces : cadre de pensée simple pour diagnostiquer ; compatible avec tout autre cadre. Faiblesses : ce n'est pas une méthode opérationnelle ; la métaphore de l'usine s'applique mal au travail de conception (variabilité intrinsèque : un logiciel n'est pas un produit répété). Il y a un risque d'optimisation locale (maximiser le taux d'occupation de chacun augmente les files) — d'où la règle : viser la fluidité, pas l'occupation.

6. Lean startup#

🟢 Novice — Lean startup (Eric Ries, The Lean Startup, 2011, héritier de Steve Blank et du développement des clients) s'adresse à la découverte : quand on ne sait même pas si le produit trouvera un usage. La boucle Construire → Mesurer → Apprendre vise à valider des hypothèses au moindre coût.

🟡 Pratique — Concepts :

• MVP (minimum viable product) : la plus petite expérience qui permet d'apprendre — pas un produit au rabais, un test ;
• hypothèses de valeur et de croissance à valider ; pivot (changement de stratégie fondé sur l'apprentissage) ou persévérance ;
• comptabilité de l'innovation : des métriques actionnables (taux d'usage, rétention) plutôt que de vanité (nombre de téléchargements) ;
• lots réduits, développement de produit par expérimentation.

Forces : évite de construire ce que personne n'utilise, légitime l'arrêt rapide. Faiblesses : n'apporte pas la manière de construire ; l'expérimentation suppose qu'on puisse mesurer (volume suffisant) et corriger ; le MVP peut être dévoyé en « version bâclée ».

🟡 Volet data — Très utile pour les cas d'usage analytiques incertains (« ce score aidera-t-il vraiment la force de vente ? »). Le MVP n'est pas un entrepôt ni un modèle complet mais :

• un prototype de rapport sur extrait réel, mis dans les mains de 3 utilisateurs ;
• une analyse ponctuelle sur extraction, avant tout chargement industriel ;
• un test de valeur : l'indicateur change-t-il une décision ? mesurer l'usage (journaux de consultation du service Power BI) plutôt que la satisfaction déclarée.

7. Shape Up#

🟡 Pratique — Shape Up (Ryan Singer, Basecamp, 2019) est une méthode de cycles longs à appétit fixe, pensée pour éviter les écueils de Scrum à grande échelle de produit. Principes :

• Cycles de 6 semaines suivis d'une période de refroidissement (cooldown) de 2 semaines (corrections, exploration, dette) ;
• l'appétit (appetite) précède l'estimation : « cela vaut 6 semaines (ou 2) de notre temps » ; le périmètre s'adapte à l'appétit, pas l'inverse (délai fixe, périmètre variable) ;
• le façonnage (shaping) : des seniors définissent le problème, les grandes lignes de la solution, les limites (no-gos) et les risques, sans entrer dans le détail d'exécution ; le résultat est un pitch de quelques pages ;
• le pari (betting table) : un petit comité choisit quels pitches lancer pour le cycle ; pas de backlog persistant (ce qui n'est pas retenu disparaît, il se représentera s'il est important) ;
• équipes autonomes (un designer + un à deux développeurs) qui possèdent le projet de bout en bout ;
• le suivi par hill charts (colline : montée = « inconnu à résoudre », descente = « exécution ») plutôt que par pourcentage ;
• un coupe-circuit (circuit breaker) : si le projet n'est pas terminé en fin de cycle, il n'est pas prolongé automatiquement.

Forces : fin du backlog fourre-tout, réduction du risque de dérive, responsabilisation, calme. Faiblesses : exige des seniors capables de façonner ; exige un contexte de produit (un seul produit, un seul commanditaire) ; peu adapté aux obligations de contrat, à la maintenance de masse, aux dépendances externes.

🟡 Volet data — Adapté aux équipes produit data (plateforme interne, produit de données) qui ont de la latitude. Un « pitch » data inclut : la décision à appuyer, le grain, les sources et leurs risques de qualité, l'historisation voulue, et les no-gos (« pas de temps réel », « pas de refonte du modèle de référence »). Le hill chart convient bien au chantier de raccordement d'une source : la montée est l'exploration de la source (jamais bien connue), la descente le chargement industriel.

8. DSDM#

🟡 Pratique — DSDM (Dynamic Systems Development Method) naît en 1994 au Royaume-Uni d'un consortium d'entreprises pour apporter de la discipline au développement rapide d'applications (RAD). Aujourd'hui maintenue par l'Agile Business Consortium sous le nom de Cadre de projet agile (AgilePF). Particularités :

• Délai et coût fixés, fonctionnalités variables : le périmètre est négocié par priorisation MoSCoW (Must, Should, Could, Won't have) — au plus 60 % de l'effort en Must pour garder une marge de sécurité ;
• timeboxing ; implication des utilisateurs ; livraison fréquente ; test continu ;
• cadre de gouvernance plus formel que Scrum : phases (préfaisabilité, faisabilité, fondations, évolution de la solution, déploiement), rôles définis (sponsor, visionnaire, ambassadeur utilisateur…) ;
• principes dont « focus sur le besoin métier », « livrer à temps », « construire de manière incrémentale à partir de fondations solides ».

DSDM est l'agile des organisations qui veulent du cadre : il s'articule bien avec PRINCE2 (esprit « gestion par étapes ») et avec les contrats « délai et coût fixes ».

Forces : gouvernance explicite, MoSCoW réutilisable partout, rapprochement agile/gestion de projet classique. Faiblesses : vocabulaire propre, adoption modeste en France/dans les petites équipes, documentation un peu lourde.

🟡 Volet data — MoSCoW convient bien à la priorisation d'un lot de rapports/mesures ; la règle « délai et coût fixes » est rassurante pour un commanditaire qui paie un forfait : on garantit la date et le socle essentiel (Must), on sacrifie le Could.

9. Crystal#

🟡 Pratique — Crystal est une famille de méthodes d'Alistair Cockburn (années 1990). Idée : il n'existe pas de méthode unique ; la méthode dépend de la taille de l'équipe et de la criticité du projet. Les « couleurs » (Clear, Yellow, Orange, Red…) montent avec le nombre de personnes ; la variante la plus connue est Crystal Clear (équipes de ~2 à 8 colocalisées). Propriétés : livraison fréquente, communication osmotique (entendre sans interrompre), amélioration par réflexion, sécurité personnelle, focus, accès facile à des utilisateurs experts, environnement technique avec tests automatisés, intégration continue et livraison fréquente.

Forces : insiste sur le facteur humain et sur l'adaptation de la méthode au contexte. Faiblesses : peu outillé, peu adopté comme cadre nommé ; sa contribution est surtout conceptuelle.

🟡 Volet data — La leçon à retenir est « la méthode suit la criticité » : un tableau de bord exploratoire n'appelle pas la même rigueur qu'un état réglementaire. Voir la grille de choix.

10. FDD (Feature-Driven Development)#

🟡 Pratique — FDD (Jeff De Luca et Peter Coad, 1997, projet bancaire à Singapour) est une méthode orientée fonctionnalités et modélisation. Cinq activités :

1. développer un modèle global (modélisation en commun) ;
2. établir la liste des fonctionnalités (features), formulées comme « action + résultat + objet » (ex. calculer le total d'un relevé de linéaire) ;
3. planifier par fonctionnalité ;
4. concevoir par fonctionnalité ;
5. construire par fonctionnalité (cycles courts, 1 à 2 semaines au plus par fonctionnalité).

Particularités : propriété de classe (un développeur responsable de classes), « programmeurs en chef » (chief programmers), rapports de progression par arbre de fonctionnalités (pourcentage d'avancement par jalon pondéré), inspections de code. Convient aux grandes équipes et aux systèmes à forte logique métier, avec une phase de modélisation initiale assumée.

Forces : lisibilité de l'avancement, modélisation claire, passe bien à l'échelle moyenne. Faiblesses : plus directif et plus « concepteur » que les autres agiles ; peu de fer de lance communautaire aujourd'hui.

🟡 Volet data — Surprenamment proche du besoin data : la liste de fonctionnalités se décline en liste de mesures et de vues (« calculer le chiffre d'affaires net d'une enseigne sur une période ») et le modèle global initial est l'équivalent du modèle dimensionnel logique (grain, dimensions conformes). Un avancement par fonctionnalité terminée est plus honnête qu'un pourcentage de tables chargées.

11. SAFe#

🟢 Novice — SAFe (Scaled Agile Framework, Dean Leffingwell, 2011 ; édition 6.0 publiée en mars 2023 ; vérifiez sur le site de Scaled Agile l'édition en vigueur) est le cadre de mise à l'échelle agile le plus déployé dans les grandes organisations. Il coordonne des dizaines d'équipes autour de Trains de livraison agiles (Agile Release Train, ART : 50–125 personnes qui planifient et livrent ensemble).

🟡 Pratique — Éléments structurants :

• PI Planning : événement de 2 jours tous les 8 à 12 semaines (Program Increment) où toutes les équipes du train planifient ensemble, identifient dépendances et risques, et prennent des engagements ;
• couches : équipe → programme (ART) → grand portefeuille (Large Solution) → portefeuille (gestion de flux de valeur, budgets lean) ;
• rôles : Release Train Engineer, Product Management, System Architect, etc. ; flux de valeur opérationnels et de développement ;
• compétences clés (Core Competencies) : agilité d'équipe et technique, DevOps, agilité de l'organisation, etc. ;
• Inspect & Adapt en fin de PI.

Forces : réponse structurée au problème de coordination des dépendances, vocabulaire commun, formation et certification abondantes, accord avec la gouvernance financière d'entreprise. Faiblesses : lourdeur, risque de cascade en cérémonie (PI Planning comme plan annuel déguisé), reproche récurrent de « réintroduire le management classique » ; la méthode demande des changements d'organisation importants que l'on omet souvent en ne gardant que les événements.

🟡 Volet data — Pertinent pour de grandes organisations avec plateforme data partagée et plusieurs équipes produit dépendantes de la plateforme (ingestion, modèles de référence, sécurité). Hors de proportion pour un datamart de 4–10 personnes. Les dépendances typiques à synchroniser : contrats de données entre sources et consommateurs, modèle de référence, fenêtres de chargement.

12. LeSS#

🟡 Pratique — LeSS (Large-Scale Scrum, Craig Larman et Bas Vodde, 2000s) prend le chemin inverse de SAFe : au lieu d'ajouter des couches, retirer de la structure. Principe : « LeSS, c'est Scrum à l'échelle — un seul produit, un seul Product Backlog, un seul Product Owner, plusieurs équipes qui font le même sprint, une seule définition de fait, une seule livraison potentiellement livrable ». Deux versions : LeSS (2 à 8 équipes) et LeSS Huge (au-delà, avec des zones d'exigences et des Area Product Owners). Il insiste sur la simplification organisationnelle (moins de rôles, moins de managers intermédiaires, des équipes de fonctionnalités plutôt que des équipes par composant) et sur la réflexion systémique (descaling).

Forces : cohérence avec les principes agiles, peu de rôles ajoutés. Faiblesses : demande une transformation organisationnelle profonde (structure, management), peu de « livrables » outillés ; adoption plus faible que SAFe dans les directions qui veulent un cadre prêt à l'emploi.

🟡 Volet data — La discipline « une seule équipe de fonctionnalités, tout le flux de bout en bout » correspond aux équipes de produit de données (source → modèle → rapport) plutôt qu'aux équipes en silos « ETL / modélisation / BI ». C'est un argument solide pour les équipes verticales.

13. Nexus#

🟡 Pratique — Nexus (Ken Schwaber et Scrum.org, 2015) est un cadre léger pour faire travailler de 3 à 9 équipes Scrum ensemble sur un seul produit. Il ajoute à Scrum :

• une équipe d'intégration Nexus (NIT) — Product Owner, Scrum Master de Nexus, membres de l'intégration — qui traite les dépendances et garantit l'incrément intégré ;
• un Backlog Nexus unique ; planification de Nexus, revue de sprint de Nexus, rétrospective de Nexus ;
• un objectif de sprint de Nexus et une définition de fait commune ;
• un incrément intégré à chaque sprint.

Forces : minimal, fidèle à Scrum, bien adapté aux équipes Scrum déjà matures. Faiblesses : peu de réponses sur l'organisation et la gouvernance, dépend du Product Owner et de la NIT pour résoudre les dépendances.

🟡 Volet data — Utile quand plusieurs équipes Scrum contribuent à un même entrepôt de données et risquent de se marcher dessus (même schéma, mêmes tables de dimension). L'équipe d'intégration joue le rôle de gardien du modèle de référence et du déploiement unique.

14. Scrum@Scale#

🟡 Pratique — Scrum@Scale (Jeff Sutherland, Scrum Inc., 2014-2018) étend Scrum par un modèle fractal : un « Scrum des Scrums » coordonne plusieurs équipes ; un « Scrum des Scrums des Scrums » coordonne plusieurs de ces groupes, etc. Deux axes indépendants :

• l'axe Scrum Master (« faire les choses correctement » — impediments, performance de l'organisation) : Scrum of Scrums coordonné par un Scrum of Scrums Master ;
• l'axe Product Owner (« faire les bonnes choses » — alignement stratégique) : un MetaScrum de Product Owners qui s'accordent sur les priorités, présidé par un Chief Product Owner.

Forces : modulaire (on adopte les composants utiles), simplicité conceptuelle. Faiblesses : moins prescriptif donc plus dépendant du jugement ; peu de retours d'expérience publics comparé à SAFe.

🟡 Volet data — Un Scrum of Scrums de responsables d'équipes (ingestion, modèle, restitution, sécurité) est la forme la plus légère et la plus réaliste de coordination d'une chaîne de production data de 15–30 personnes.

15. Le « modèle Spotify » et ses limites#

🟢 Novice — En 2012, Henrik Kniberg et Anders Ivarsson publient Scaling Agile @ Spotify, qui décrit l'organisation d'alors : des squads (petites équipes autonomes, comparables à une équipe Scrum), regroupées en tribes, reliées transversalement par des chapters (communautés de métier au sein d'une tribu) et des guilds (communautés d'intérêt à l'échelle de l'entreprise).

🟡 Pratique — Ce qu'il faut savoir pour ne pas se tromper :

• Kniberg l'a lui-même présenté comme un instantané de l'organisation à un moment donné (et non un « modèle » ou un cadre), et a rappelé que l'entreprise continuait de changer ;
• des témoignages d'anciens salariés indiquent que l'organisation réelle ne ressemblait pas à l'idéal du document (dépendances, douleurs de coordination) — ce qui est confirmé par la révision constante de l'organisation chez Spotify ;
• la valeur durable du texte est d'illustrer l'alignement avec autonomie : « aligné, donc autonome » (aligned autonomy), des équipes de bout en bout responsables d'une mission, des communautés pour le partage des pratiques.

Limites quand on le copie :

🟡 Volet data — La partie transférable est l'équipe produit de bout en bout (source jusqu'au rapport) et la communauté de pratiques (guilde des modélisateurs, des développeurs DAX) qui fait circuler les standards — exactement ce que la gouvernance du self-service cherche à obtenir.

16. DevOps comme culture#

🟢 Novice — DevOps (terme popularisé vers 2009 autour de Patrick Debois et des conférences DevOpsDays) vise à supprimer le mur entre ceux qui développent et ceux qui exploitent. Ce n'est ni une méthode de gestion de projet ni un métier : c'est une culture et un ensemble de pratiques qui permettent de livrer vite ET de façon fiable.

🟡 Pratique — Le résumé CALMS : Culture (collaboration, responsabilité partagée), Automatisation (build, test, déploiement), Lean (flux, petits lots), Mesure (métriques, observabilité), Share (partage de connaissance).

La recherche de l'équipe DORA (DevOps Research and Assessment, livre Accelerate de Forsgren, Humble et Kim, 2018, puis rapports annuels State of DevOps) a identifié des mesures de performance de livraison qui corrèlent avec les résultats d'organisation. Les quatre mesures clés :

Le résultat marquant de la recherche DORA est que vitesse et stabilité ne s'opposent pas pour les équipes performantes ; les travaux plus récents de DORA ont affiné la formulation de certaines mesures : le lead time for changes est devenu le change lead time, le temps de rétablissement est devenu le temps de rétablissement après un déploiement en échec (failed deployment recovery time), et une cinquième mesure, le taux de reprises de déploiement non planifiées après incident (deployment rework rate), complète le taux d'échec des changements. Le guide en ligne de DORA regroupe désormais ces mesures en deux familles, le débit (throughput) et l'instabilité (instability).

Pratiques techniques fondatrices : intégration continue, livraison continue, infrastructure en code, supervision et alerte, déploiements progressifs (canary, blue/green), « you build it, you run it ». Détail dans CI/CD.

🟡 Volet data — DataOps est l'application du même esprit à la donnée : pipelines de données testés et versionnés, environnements reproductibles, observabilité des données (fraîcheur, volume, schéma, distribution), rejouabilité. Particularités qui compliquent : les états (une base se migre, un déploiement ne « remplace » pas une table avec ses données), la taille des environnements de test, la donnée de production (confidentialité), et le rejeu historique. Voir CI/CD pour la data et le thème de matrice délais et industrialisation DataOps.

🧪 Exemple (fil rouge) — Datamart livré en kits d'installation versionnés : le passage de 1 kit tous les 3 mois à 1 kit toutes les 3 semaines suppose (1) une base de test reconstruite à partir du kit à chaque changement, (2) un jeu de non-régression automatique, (3) un procès-verbal de livraison généré. Chaque étape manuelle retirée est un gain de fréquence ET de fiabilité.

17. Tableau de synthèse#

Notes /5 — contexte : équipe de 4 à 12 personnes, projet logiciel ou data de 6 à 18 mois, organisation de taille moyenne ; appréciations d'expert (voir NOTATION). Le tableau avec les méthodes prédictives et Scrum est dans le comparatif.

Lecture critique : la facilité d'adoption de Kanban (5/5) est la raison pour laquelle on commence souvent par lui ; le faible 2/5 de XP et de DevOps reflète le coût culturel et d'outillage, non un défaut de la méthode. Aucune approche ne « gagne » partout : ces notes n'ont de sens qu'avec un contexte.

18. Contribution de l'IA#

🤖 IA — L'IA touche surtout l'ingénierie (XP/DevOps) et le flux (analyse des délais).

Exemple de prompt : « Voici le tableau de flux exporté (ID, date de création, début, fin, type). Calcule le lead time et le cycle time au 50ᵉ, 85ᵉ et 95ᵉ percentiles par classe de service et signale les éléments dont l'âge dépasse le 85ᵉ percentile. »

L'IA ne remplace pas l'autonomie de l'équipe, la confiance, l'accès au métier ou la décision d'arrêter un projet. Risque nouveau : le flux de code produit sans compréhension augmente la dette cachée ; la discipline XP (tests, revue, simplicité) devient plus nécessaire, pas moins. Voir IA et conduite de projet.

19. Voir aussi#

• Méthodes prédictives · Comparatif des méthodes · Choisir et hybrider · Méthodes spécifiques à la data.
• Scrum : le cadre · Scrum en pratique · Scrum et data · Fondamentaux · Pièges et bonnes pratiques.
• CI/CD · CI/CD pour la data.
• Outils : Azure DevOps / TFS · Jira et alternatives · métriques et reporting de projet.
• Maturité : équipe et collaboration · amélioration continue · intégration et livraison continues · expérience développeur et flux.
• Glossaire.

✻ Rédigé par Claude Sonnet 5.5