[{"data":1,"prerenderedAt":3373},["ShallowReactive",2],{"search-api":-1,"listing-cat-pratiques-agiles-page-1":3},[4,498,1343,1797,2244,2626,3017],{"_path":5,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":9,"description":10,"id":11,"date":12,"listed":13,"nocomments":7,"hidden":7,"categories":14,"tags":15,"--cover":20,"readingTime":21,"body":26,"_type":492,"_id":493,"_source":494,"_file":495,"_stem":496,"_extension":497},"/fr/pratiques-agiles/reduire-work-in-progress-velocite","pratiques-agiles",false,"","Limiter le Work In Progress : le levier le plus sous-estimé","La loi de Little appliquée à l'engineering : réduire le WIP est plus efficace que d'accélérer les développeurs. La démonstration et le protocole de mise en œuvre.",32,"2026-03-18",true,[6],[16,17,18,19],"Work In Progress","WIP","Kanban","Flow","covers/articles/reduire-work-in-progress.jpg",{"text":22,"minutes":23,"time":24,"words":25},"9 min read",8.105,486300,1621,{"type":27,"children":28,"toc":483},"root",[29,37,43,48,53,58,63,67,74,79,88,93,98,115,132,149,154,157,163,168,178,188,198,224,237,240,246,256,266,271,291,301,311,321,324,330,340,358,368,371,377,382,387,392,395,401,416,429,442,455,468,471],{"type":30,"tag":31,"props":32,"children":34},"element","h1",{"id":33},"limiter-le-work-in-progress-le-levier-le-plus-sous-estimé",[35],{"type":36,"value":9},"text",{"type":30,"tag":38,"props":39,"children":40},"p",{},[41],{"type":36,"value":42},"J'accompagnais une équipe produit de 8 développeurs chez un client dans le secteur financier. Ils me demandaient comment livrer plus vite. Je leur ai demandé de compter le nombre de stories \"In Progress\" sur leur board.",{"type":30,"tag":38,"props":44,"children":45},{},[46],{"type":36,"value":47},"Il y en avait 22.",{"type":30,"tag":38,"props":49,"children":50},{},[51],{"type":36,"value":52},"22 stories pour 8 développeurs. Chaque développeur avait en moyenne 2,75 sujets en cours simultanément. Certains jonglaient entre 4 contextes différents dans la même journée.",{"type":30,"tag":38,"props":54,"children":55},{},[56],{"type":36,"value":57},"J'ai posé la question suivante : \"Quelle est la dernière fois qu'une story est allée de 'To Do' à 'Done' en moins de 3 jours ?\" Silence. L'un d'eux a vérifié Jira. La réponse était : 6 semaines auparavant.",{"type":30,"tag":38,"props":59,"children":60},{},[61],{"type":36,"value":62},"La solution que je leur ai proposée n'était pas d'embaucher, ni de changer de framework, ni d'adopter une nouvelle méthodologie. C'était de réduire le nombre de choses en cours simultanément. Ça semblait trop simple. C'était la bonne réponse.",{"type":30,"tag":64,"props":65,"children":66},"hr",{},[],{"type":30,"tag":68,"props":69,"children":71},"h2",{"id":70},"la-loi-de-little-la-démonstration-mathématique",[72],{"type":36,"value":73},"La loi de Little : la démonstration mathématique",{"type":30,"tag":38,"props":75,"children":76},{},[77],{"type":36,"value":78},"La loi de Little, formulée par le mathématicien John Dutton Converse Little en 1961, s'applique à tout système de flux (file d'attente bancaire, réseau logistique, ou équipe de développement logiciel).",{"type":30,"tag":38,"props":80,"children":81},{},[82],{"type":30,"tag":83,"props":84,"children":85},"strong",{},[86],{"type":36,"value":87},"Lead Time = Work In Progress / Throughput",{"type":30,"tag":38,"props":89,"children":90},{},[91],{"type":36,"value":92},"Traduction pour l'engineering : si votre équipe livre 10 stories par semaine (throughput) et a 30 stories en cours simultanément (WIP), le lead time moyen est de 3 semaines. Pour réduire le lead time à 1 semaine sans changer le throughput : réduire le WIP à 10 stories.",{"type":30,"tag":38,"props":94,"children":95},{},[96],{"type":36,"value":97},"La démonstration chiffrée est implacable.",{"type":30,"tag":38,"props":99,"children":100},{},[101,106,108,113],{"type":30,"tag":83,"props":102,"children":103},{},[104],{"type":36,"value":105},"Scénario A : WIP illimité",{"type":36,"value":107}," : équipe de 5 développeurs, 15 stories en cours (3 par développeur), throughput de 10 stories par semaine. Lead Time moyen : 15 / 10 = ",{"type":30,"tag":83,"props":109,"children":110},{},[111],{"type":36,"value":112},"1,5 semaine",{"type":36,"value":114},".",{"type":30,"tag":38,"props":116,"children":117},{},[118,123,125,130],{"type":30,"tag":83,"props":119,"children":120},{},[121],{"type":36,"value":122},"Scénario B : WIP limité à 8",{"type":36,"value":124}," : même équipe, même throughput, 8 stories en cours. Lead Time moyen : 8 / 10 = ",{"type":30,"tag":83,"props":126,"children":127},{},[128],{"type":36,"value":129},"0,8 semaine",{"type":36,"value":131}," (−47%).",{"type":30,"tag":38,"props":133,"children":134},{},[135,140,142,147],{"type":30,"tag":83,"props":136,"children":137},{},[138],{"type":36,"value":139},"Scénario C : WIP limité à 5",{"type":36,"value":141}," : 5 stories en cours (1 par développeur). Lead Time moyen : 5 / 10 = ",{"type":30,"tag":83,"props":143,"children":144},{},[145],{"type":36,"value":146},"0,5 semaine",{"type":36,"value":148}," (−67%).",{"type":30,"tag":38,"props":150,"children":151},{},[152],{"type":36,"value":153},"En réduisant le WIP de 15 à 5, le lead time est divisé par 3, sans changer une ligne de code, sans recruter, sans changer de framework. C'est contre-intuitif dans une culture qui valorise l'occupation maximale. C'est pourtant ce que la théorie des contraintes de Goldratt et les principes Kanban enseignent depuis des décennies.",{"type":30,"tag":64,"props":155,"children":156},{},[],{"type":30,"tag":68,"props":158,"children":160},{"id":159},"pourquoi-le-wip-augmente-naturellement",[161],{"type":36,"value":162},"Pourquoi le WIP augmente naturellement",{"type":30,"tag":38,"props":164,"children":165},{},[166],{"type":36,"value":167},"Dans la plupart des équipes, le WIP augmente sans décision consciente. Les mécanismes sont structurels.",{"type":30,"tag":38,"props":169,"children":170},{},[171,176],{"type":30,"tag":83,"props":172,"children":173},{},[174],{"type":36,"value":175},"Le multitâche comme norme.",{"type":36,"value":177}," Un développeur bloqué sur une story en attend le feedback, démarre une deuxième story, est interrompu pour une troisième urgence. Sans règle explicite, 3 stories en parallèle par développeur devient la norme, et personne ne la remet en question.",{"type":30,"tag":38,"props":179,"children":180},{},[181,186],{"type":30,"tag":83,"props":182,"children":183},{},[184],{"type":36,"value":185},"La peur du \"slack\".",{"type":36,"value":187}," Un développeur qui n'a rien en cours est perçu comme improductif. Résultat : chacun s'assigne une nouvelle story plutôt que d'aider un collègue à terminer. Le système optimise l'occupation individuelle au détriment du flux collectif.",{"type":30,"tag":38,"props":189,"children":190},{},[191,196],{"type":30,"tag":83,"props":192,"children":193},{},[194],{"type":36,"value":195},"Les dépendances non résolues.",{"type":36,"value":197}," Une story en attente d'une décision produit, d'une clarification métier, ou d'une PR de review contribue au WIP sans avancer. Elle bloque la colonne sans produire de valeur.",{"type":30,"tag":38,"props":199,"children":200},{},[201,214,216,222],{"type":30,"tag":83,"props":202,"children":203},{},[204,206,213],{"type":36,"value":205},"Le ",{"type":30,"tag":207,"props":208,"children":210},"a",{"href":209},"/fr/pratiques-agiles/anti-patterns-backlog",[211],{"type":36,"value":212},"backlog infini",{"type":36,"value":114},{"type":36,"value":215}," Si le backlog a 200 stories priorisées et qu'il n'y a pas de limite explicite, l'équipe accepte plus qu'elle ne peut faire. C'est le ",{"type":30,"tag":207,"props":217,"children":219},{"href":218},"/fr/pratiques-agiles/sprint-planning-efficace",[220],{"type":36,"value":221},"sprint planning",{"type":36,"value":223}," qui génère du WIP excessif.",{"type":30,"tag":225,"props":226,"children":231},"cta",{"cta":227,"href":228,"title":229,"type":230},"Réserver mon diagnostic gratuit →","https://app.kamanga.fr/forms/discovery-call","Votre lead time dépasse 3 semaines et vous cherchez les bons leviers pour le réduire ?","call",[232],{"type":30,"tag":38,"props":233,"children":234},{},[235],{"type":36,"value":236},"Identifier les bonnes limites de WIP pour votre équipe nécessite une analyse du flux actuel. En 30 minutes, je calcule votre lead time théorique, j'identifie les goulots d'étranglement, et je définis avec vous les limites de WIP adaptées à votre contexte.",{"type":30,"tag":64,"props":238,"children":239},{},[],{"type":30,"tag":68,"props":241,"children":243},{"id":242},"le-protocole-dimplémentation-en-5-étapes",[244],{"type":36,"value":245},"Le protocole d'implémentation en 5 étapes",{"type":30,"tag":38,"props":247,"children":248},{},[249,254],{"type":30,"tag":83,"props":250,"children":251},{},[252],{"type":36,"value":253},"Étape 1 : Mesurer le WIP actuel.",{"type":36,"value":255}," Avant d'imposer une limite, mesurer l'état réel. Pendant 2 semaines, poser ces questions en daily standup : combien de stories chaque développeur a-t-il en cours aujourd'hui ? Combien de stories sont en cours depuis plus de 5 jours ? Quel est le nombre total de stories \"In Progress\" sur le board ? Calculer la moyenne. C'est le WIP de départ.",{"type":30,"tag":38,"props":257,"children":258},{},[259,264],{"type":30,"tag":83,"props":260,"children":261},{},[262],{"type":36,"value":263},"Étape 2 : Définir les limites initiales.",{"type":36,"value":265}," Règle pratique de départ : limite WIP = nombre de développeurs × 1,5. Pour une équipe de 6 : limite WIP = 9. C'est plus restrictif que l'état naturel (souvent 2 à 3 fois le nombre de développeurs) mais pas encore au niveau optimal.",{"type":30,"tag":38,"props":267,"children":268},{},[269],{"type":36,"value":270},"La limite s'applique par colonne du board Kanban, pas au total :",{"type":30,"tag":272,"props":273,"children":274},"ul",{},[275,281,286],{"type":30,"tag":276,"props":277,"children":278},"li",{},[279],{"type":36,"value":280},"\"In Progress\" : limite = N développeurs",{"type":30,"tag":276,"props":282,"children":283},{},[284],{"type":36,"value":285},"\"In Review\" : limite = N/2",{"type":30,"tag":276,"props":287,"children":288},{},[289],{"type":36,"value":290},"\"In Testing\" : limite = N/3",{"type":30,"tag":38,"props":292,"children":293},{},[294,299],{"type":30,"tag":83,"props":295,"children":296},{},[297],{"type":36,"value":298},"Étape 3 : Rendre la limite visible et automatique.",{"type":36,"value":300}," Sur Jira, configurer le \"Work In Progress Limit\" sur chaque colonne du board. Jira affiche une alerte visuelle (colonne en rouge) quand la limite est atteinte. La règle doit être visible passivement, pas nécessiter une vérification active.",{"type":30,"tag":38,"props":302,"children":303},{},[304,309],{"type":30,"tag":83,"props":305,"children":306},{},[307],{"type":36,"value":308},"Étape 4 : Créer la règle \"finir avant de commencer\".",{"type":36,"value":310}," Quand la limite WIP est atteinte, avant d'ouvrir une nouvelle story : fermer une story en cours. Ce qui implique concrètement d'aider un collègue à débloquer sa story, de prioriser les code reviews en attente (qui bloquent les stories en review), ou de diviser une grande story bloquée en sous-stories terminables.",{"type":30,"tag":38,"props":312,"children":313},{},[314,319],{"type":30,"tag":83,"props":315,"children":316},{},[317],{"type":36,"value":318},"Étape 5 : Ajuster la limite après 4 sprints.",{"type":36,"value":320}," La limite initiale n'est pas la limite optimale. Si le board n'atteint jamais la limite : trop haute, la réduire de 20%. Si la limite bloque constamment le flux : peut-être trop basse, ou signal d'un goulot d'étranglement à résoudre autrement.",{"type":30,"tag":64,"props":322,"children":323},{},[],{"type":30,"tag":68,"props":325,"children":327},{"id":326},"les-résistances-et-comment-les-adresser",[328],{"type":36,"value":329},"Les résistances et comment les adresser",{"type":30,"tag":38,"props":331,"children":332},{},[333,338],{"type":30,"tag":83,"props":334,"children":335},{},[336],{"type":36,"value":337},"\"Je suis bloqué, je dois bien commencer autre chose.\"",{"type":36,"value":339}," Cette résistance est légitime. Ma réponse : le blocage est l'information importante, pas le contournement. Un développeur bloqué doit d'abord chercher à débloquer : escalader la dépendance, poser la question dans Slack, demander de l'aide. Ce n'est qu'après 2 heures de blocage sans perspective de résolution que commencer une autre story est acceptable. Et ce dépassement doit être visible sur le board.",{"type":30,"tag":38,"props":341,"children":342},{},[343,348,350,356],{"type":30,"tag":83,"props":344,"children":345},{},[346],{"type":36,"value":347},"\"Le business veut des estimations et une limite WIP les rend impossibles.\"",{"type":36,"value":349}," Faux. Avec une limite WIP et la loi de Little, les prédictions sont plus précises, pas moins. \"Nous avons X stories en cours et Y en backlog. Avec notre ",{"type":30,"tag":207,"props":351,"children":353},{"href":352},"/fr/pratiques-agiles/story-points-estimation-agile-alternative",[354],{"type":36,"value":355},"throughput",{"type":36,"value":357}," de 10 stories par semaine et une limite WIP de 8, la feature Z sera livrée dans cet intervalle de confiance.\" C'est plus précis qu'une vélocité en story points qui dérive avec le temps.",{"type":30,"tag":38,"props":359,"children":360},{},[361,366],{"type":30,"tag":83,"props":362,"children":363},{},[364],{"type":36,"value":365},"\"Mes développeurs vont s'ennuyer en attendant.\"",{"type":36,"value":367}," Les développeurs ne s'ennuient jamais : ils ont du backlog et de la dette technique. La vraie question est : qu'est-ce qui est plus précieux, commencer une nouvelle story ou aider à terminer les stories en cours ? La réponse est presque toujours la deuxième option. Finir une story livrée au client vaut plus que démarrer une story qui attendra 3 semaines dans la file.",{"type":30,"tag":64,"props":369,"children":370},{},[],{"type":30,"tag":68,"props":372,"children":374},{"id":373},"ce-que-ça-a-changé",[375],{"type":36,"value":376},"Ce que ça a changé",{"type":30,"tag":38,"props":378,"children":379},{},[380],{"type":36,"value":381},"Dans l'équipe de 8 développeurs mentionnée en introduction, le WIP moyen était de 22 stories simultanées. Après implémentation des limites WIP à 10 et de la règle \"finir avant de commencer\", le WIP a baissé à 9 en 6 semaines. Le lead time moyen est passé de 18 jours à 7 jours. Le nombre de stories livrées par sprint n'a pas changé, mais leur délai de livraison a été divisé par 2,5.",{"type":30,"tag":38,"props":383,"children":384},{},[385],{"type":36,"value":386},"Les métriques à suivre pour mesurer l'impact : WIP moyen hebdomadaire (la tendance doit baisser), age du WIP en jours (les stories vieilles de plus de 2 sprints sont des signaux d'alerte), et distribution du lead time par story (une distribution qui se resserre indique un flux qui se normalise).",{"type":30,"tag":38,"props":388,"children":389},{},[390],{"type":36,"value":391},"Ce n'était jamais un problème de personnes. C'était un problème de système, et le système a changé quand les règles ont changé.",{"type":30,"tag":64,"props":393,"children":394},{},[],{"type":30,"tag":68,"props":396,"children":398},{"id":397},"faq-sur-les-limites-de-wip",[399],{"type":36,"value":400},"FAQ sur les limites de WIP",{"type":30,"tag":402,"props":403,"children":404},"details",{},[405,411],{"type":30,"tag":406,"props":407,"children":408},"summary",{},[409],{"type":36,"value":410},"1. Les limites de WIP s'appliquent-elles en Scrum comme en Kanban ?",{"type":30,"tag":38,"props":412,"children":413},{},[414],{"type":36,"value":415},"Oui. En Kanban, les limites WIP sont un principe fondamental. En Scrum, elles s'appliquent au niveau du sprint board. La différence est que Scrum permet de remplir le sprint à 100% de la capacité théorique, ce qui crée du WIP élevé. En ajoutant une limite explicite (ex: max 2 stories par développeur simultanément), l'équipe Scrum bénéficie des mêmes avantages de flux que Kanban.",{"type":30,"tag":402,"props":417,"children":418},{},[419,424],{"type":30,"tag":406,"props":420,"children":421},{},[422],{"type":36,"value":423},"2. Comment gérer les urgences qui obligent à dépasser la limite WIP ?",{"type":30,"tag":38,"props":425,"children":426},{},[427],{"type":36,"value":428},"Les urgences existent et peuvent justifier de dépasser temporairement la limite. La règle : chaque dépassement est une décision consciente et visible, la colonne du board vire au rouge. Après chaque urgence, analyser en rétro : était-ce vraiment une urgence ? Aurait-on pu l'anticiper ? Les équipes qui dépassent la limite pour urgence chaque semaine ont un problème de priorisation, pas de WIP.",{"type":30,"tag":402,"props":430,"children":431},{},[432,437],{"type":30,"tag":406,"props":433,"children":434},{},[435],{"type":36,"value":436},"3. Quelle est la limite WIP optimale ?",{"type":30,"tag":38,"props":438,"children":439},{},[440],{"type":36,"value":441},"Il n'y a pas de réponse universelle : elle dépend de la taille d'équipe, de la complexité des stories, et du niveau d'interdépendances. La règle empirique est de commencer à 1,5 fois le nombre de développeurs et d'ajuster vers le bas jusqu'à trouver la valeur où le lead time se stabilise sans créer de goulot d'étranglement. En pratique, la plupart des équipes trouvent leur optimum entre 1 et 2 fois le nombre de développeurs.",{"type":30,"tag":402,"props":443,"children":444},{},[445,450],{"type":30,"tag":406,"props":446,"children":447},{},[448],{"type":36,"value":449},"4. Comment les limites WIP interagissent-elles avec les bugs urgents ?",{"type":30,"tag":38,"props":451,"children":452},{},[453],{"type":36,"value":454},"Les bugs urgents (P1/P0) sont traités comme des interruptions explicites. Un bug P1 peut entrer en cours sans respecter la limite WIP, mais il doit être la priorité absolue jusqu'à sa résolution. Le développeur qui prend un bug P1 stationne sa story en cours dans une colonne \"On Hold\". Le WIP réel ne dépasse pas la limite : il y a une substitution consciente et visible.",{"type":30,"tag":402,"props":456,"children":457},{},[458,463],{"type":30,"tag":406,"props":459,"children":460},{},[461],{"type":36,"value":462},"5. Comment convaincre le management que moins de WIP n'est pas moins de travail ?",{"type":30,"tag":38,"props":464,"children":465},{},[466],{"type":36,"value":467},"Par la démonstration chiffrée de la loi de Little. Montrer le calcul : avec un WIP de 20 et un throughput de 10 stories par semaine, le lead time est de 2 semaines. Avec un WIP de 10, le lead time est de 1 semaine. Même throughput, deux fois plus de réactivité pour le business. Le business valorise la rapidité de livraison : les limites WIP la produisent sans recruter.",{"type":30,"tag":64,"props":469,"children":470},{},[],{"type":30,"tag":225,"props":472,"children":477},{"cta":473,"href":474,"title":475,"type":476},"Télécharger le guide gratuit →","/mes-ressources","Ressource gratuite : Guide Lead Time -50% en 90 jours","resource",[478],{"type":30,"tag":38,"props":479,"children":480},{},[481],{"type":36,"value":482},"Le guide complet pour réduire votre lead time en 90 jours inclut un chapitre détaillé sur l'implémentation des limites WIP, les métriques de suivi, et les benchmarks par taille d'équipe, avec les données issues de mes accompagnements terrain.",{"title":8,"searchDepth":484,"depth":484,"links":485},2,[486,487,488,489,490,491],{"id":70,"depth":484,"text":73},{"id":159,"depth":484,"text":162},{"id":242,"depth":484,"text":245},{"id":326,"depth":484,"text":329},{"id":373,"depth":484,"text":376},{"id":397,"depth":484,"text":400},"markdown","content:fr:pratiques-agiles:reduire-work-in-progress-velocite.md","content","fr/pratiques-agiles/reduire-work-in-progress-velocite.md","fr/pratiques-agiles/reduire-work-in-progress-velocite","md",{"_path":499,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":500,"description":501,"id":502,"date":503,"listed":13,"nocomments":7,"hidden":7,"categories":504,"tags":505,"--cover":510,"readingTime":511,"body":515,"_type":492,"_id":1340,"_source":494,"_file":1341,"_stem":1342,"_extension":497},"/fr/pratiques-agiles/continuous-integration-fondamentaux","Continuous Integration : les 5 fondamentaux non-négociables","Avoir Jenkins ou GitHub Actions n'est pas faire de la CI. La vraie CI implique des pratiques humaines que l'outil seul ne peut pas imposer.",27,"2026-03-06",[6],[506,507,508,509],"Continuous Integration","CI/CD","Pipeline","Qualité","covers/articles/continuous-integration-fondamentaux.jpg",{"text":22,"minutes":512,"time":513,"words":514},8.17,490200,1634,{"type":27,"children":516,"toc":1330},[517,522,527,532,537,542,547,550,556,561,571,581,591,596,599,605,610,615,620,762,767,770,776,781,786,791,1076,1085,1088,1094,1099,1104,1109,1114,1117,1123,1128,1133,1138,1141,1147,1160,1165,1202,1207,1210,1216,1221,1226,1239,1242,1248,1261,1274,1287,1300,1313,1316,1324],{"type":30,"tag":31,"props":518,"children":520},{"id":519},"continuous-integration-les-5-fondamentaux-non-négociables",[521],{"type":36,"value":500},{"type":30,"tag":38,"props":523,"children":524},{},[525],{"type":36,"value":526},"Dans un client dans l'édition logicielle que j'accompagnais (15 développeurs, produit financier B2B), le pipeline CI durait 28 minutes. Les branches vivaient en moyenne 4 jours avant d'être mergées. L'équipe avait GitHub Actions configuré depuis 18 mois. Elle pensait pratiquer la Continuous Integration.",{"type":30,"tag":38,"props":528,"children":529},{},[530],{"type":36,"value":531},"Elle pratiquait le contraire.",{"type":30,"tag":38,"props":533,"children":534},{},[535],{"type":36,"value":536},"Les merges de longues branches généraient des conflits quotidiens. Les builds rouges duraient parfois 6 heures avant d'être corrigés. Et les développeurs avaient arrêté de regarder les alertes du pipeline depuis longtemps : trop de faux positifs, trop de délai entre le commit et le feedback.",{"type":30,"tag":38,"props":538,"children":539},{},[540],{"type":36,"value":541},"La Continuous Integration est une discipline humaine autant qu'une infrastructure technique. La plupart des équipes ont l'outil, et pratiquent le contraire de la CI sans le savoir.",{"type":30,"tag":38,"props":543,"children":544},{},[545],{"type":36,"value":546},"La définition originale vient de Kent Beck (Extreme Programming, 1999) et Martin Fowler : intégrer ses changements dans la branche principale plusieurs fois par jour. Pas une fois par semaine lors de la \"merge PR\". Plusieurs fois par jour. Selon les recherches DORA, les équipes qui pratiquent la vraie CI ont un lead time 4 fois inférieur et un taux d'échec de déploiement 3 fois plus bas. Ce n'est pas l'outil qui fait la différence : c'est la discipline.",{"type":30,"tag":64,"props":548,"children":549},{},[],{"type":30,"tag":68,"props":551,"children":553},{"id":552},"ce-que-la-ci-nest-pas",[554],{"type":36,"value":555},"Ce que la CI n'est pas",{"type":30,"tag":38,"props":557,"children":558},{},[559],{"type":36,"value":560},"Trois confusions fréquentes méritent d'être clarifiées avant d'aller plus loin.",{"type":30,"tag":38,"props":562,"children":563},{},[564,569],{"type":30,"tag":83,"props":565,"children":566},{},[567],{"type":36,"value":568},"La CI n'est pas un pipeline de build automatisé.",{"type":36,"value":570}," Lancer des tests automatiquement à chaque push n'est pas de la CI si les branches durent 2 semaines avant d'être mergées. L'automatisation sans intégration fréquente, c'est du quality assurance sur des changements isolés.",{"type":30,"tag":38,"props":572,"children":573},{},[574,579],{"type":30,"tag":83,"props":575,"children":576},{},[577],{"type":36,"value":578},"La CI n'est pas un gating de qualité.",{"type":36,"value":580}," Utiliser le pipeline pour bloquer les PRs avec des tests qui échouent est utile, mais c'est de l'assurance qualité, pas de la CI au sens strict.",{"type":30,"tag":38,"props":582,"children":583},{},[584,589],{"type":30,"tag":83,"props":585,"children":586},{},[587],{"type":36,"value":588},"La CI n'est pas une histoire de fréquence de déploiement.",{"type":36,"value":590}," Déployer souvent (CD) est différent d'intégrer souvent (CI). On peut déployer une fois par jour depuis une branche de longue durée : ce n'est pas de la CI.",{"type":30,"tag":38,"props":592,"children":593},{},[594],{"type":36,"value":595},"La définition précise de Martin Fowler : \"Continuous Integration is a practice where members of a team merge their work frequently, usually each person merges at least daily.\" L'accent est sur la fréquence d'intégration, pas sur l'automatisation.",{"type":30,"tag":64,"props":597,"children":598},{},[],{"type":30,"tag":68,"props":600,"children":602},{"id":601},"fondamental-1-intégrer-dans-le-trunk-au-moins-une-fois-par-jour",[603],{"type":36,"value":604},"Fondamental 1 : Intégrer dans le trunk au moins une fois par jour",{"type":30,"tag":38,"props":606,"children":607},{},[608],{"type":36,"value":609},"Chaque développeur intègre son code dans la branche principale (main, master, trunk) au moins une fois toutes les 24 heures.",{"type":30,"tag":38,"props":611,"children":612},{},[613],{"type":36,"value":614},"Ce qui rend cela difficile : ça suppose que chaque commit soit dans un état qui ne casse pas la branche principale. Ce qui implique des feature flags pour les fonctionnalités incomplètes, et une culture de \"never break the trunk\".",{"type":30,"tag":38,"props":616,"children":617},{},[618],{"type":36,"value":619},"Les feature flags permettent d'intégrer du code incomplet sans l'exposer aux utilisateurs. C'est le mécanisme qui rend la CI viable pour des fonctionnalités qui prennent plus d'une journée :",{"type":30,"tag":621,"props":622,"children":626},"pre",{"className":623,"code":624,"language":625,"meta":8,"style":8},"language-python shiki shiki-themes catppuccin-frappe github-dark","# La fonctionnalité n'est pas terminée mais le code est intégré\nif feature_flags.is_enabled('new_checkout_flow', user):\n    return new_checkout_flow(request)\nelse:\n    return legacy_checkout_flow(request)\n","python",[627],{"type":30,"tag":628,"props":629,"children":630},"code",{"__ignoreMap":8},[631,643,695,723,737],{"type":30,"tag":632,"props":633,"children":636},"span",{"class":634,"line":635},"line",1,[637],{"type":30,"tag":632,"props":638,"children":640},{"style":639},"--shiki-default:#737994;--shiki-default-font-style:italic;--shiki-dark:#6A737D;--shiki-dark-font-style:inherit",[641],{"type":36,"value":642},"# La fonctionnalité n'est pas terminée mais le code est intégré\n",{"type":30,"tag":632,"props":644,"children":645},{"class":634,"line":484},[646,652,658,663,669,674,680,685,690],{"type":30,"tag":632,"props":647,"children":649},{"style":648},"--shiki-default:#CA9EE6;--shiki-dark:#F97583",[650],{"type":36,"value":651},"if",{"type":30,"tag":632,"props":653,"children":655},{"style":654},"--shiki-default:#C6D0F5;--shiki-dark:#E1E4E8",[656],{"type":36,"value":657}," feature_flags",{"type":30,"tag":632,"props":659,"children":661},{"style":660},"--shiki-default:#949CBB;--shiki-dark:#E1E4E8",[662],{"type":36,"value":114},{"type":30,"tag":632,"props":664,"children":666},{"style":665},"--shiki-default:#8CAAEE;--shiki-dark:#E1E4E8",[667],{"type":36,"value":668},"is_enabled",{"type":30,"tag":632,"props":670,"children":671},{"style":660},[672],{"type":36,"value":673},"(",{"type":30,"tag":632,"props":675,"children":677},{"style":676},"--shiki-default:#A6D189;--shiki-dark:#9ECBFF",[678],{"type":36,"value":679},"'new_checkout_flow'",{"type":30,"tag":632,"props":681,"children":682},{"style":660},[683],{"type":36,"value":684},",",{"type":30,"tag":632,"props":686,"children":687},{"style":654},[688],{"type":36,"value":689}," user",{"type":30,"tag":632,"props":691,"children":692},{"style":660},[693],{"type":36,"value":694},"):\n",{"type":30,"tag":632,"props":696,"children":698},{"class":634,"line":697},3,[699,704,709,713,718],{"type":30,"tag":632,"props":700,"children":701},{"style":648},[702],{"type":36,"value":703},"    return",{"type":30,"tag":632,"props":705,"children":706},{"style":665},[707],{"type":36,"value":708}," new_checkout_flow",{"type":30,"tag":632,"props":710,"children":711},{"style":660},[712],{"type":36,"value":673},{"type":30,"tag":632,"props":714,"children":715},{"style":654},[716],{"type":36,"value":717},"request",{"type":30,"tag":632,"props":719,"children":720},{"style":660},[721],{"type":36,"value":722},")\n",{"type":30,"tag":632,"props":724,"children":726},{"class":634,"line":725},4,[727,732],{"type":30,"tag":632,"props":728,"children":729},{"style":648},[730],{"type":36,"value":731},"else",{"type":30,"tag":632,"props":733,"children":734},{"style":660},[735],{"type":36,"value":736},":\n",{"type":30,"tag":632,"props":738,"children":740},{"class":634,"line":739},5,[741,745,750,754,758],{"type":30,"tag":632,"props":742,"children":743},{"style":648},[744],{"type":36,"value":703},{"type":30,"tag":632,"props":746,"children":747},{"style":665},[748],{"type":36,"value":749}," legacy_checkout_flow",{"type":30,"tag":632,"props":751,"children":752},{"style":660},[753],{"type":36,"value":673},{"type":30,"tag":632,"props":755,"children":756},{"style":654},[757],{"type":36,"value":717},{"type":30,"tag":632,"props":759,"children":760},{"style":660},[761],{"type":36,"value":722},{"type":30,"tag":38,"props":763,"children":764},{},[765],{"type":36,"value":766},"Le signal d'alerte est simple : si vos branches vivent plus de 2 jours, vous ne pratiquez pas la CI : vous faites du \"integrate when done.\"",{"type":30,"tag":64,"props":768,"children":769},{},[],{"type":30,"tag":68,"props":771,"children":773},{"id":772},"fondamental-2-le-pipeline-de-build-doit-passer-en-moins-de-10-minutes",[774],{"type":36,"value":775},"Fondamental 2 : Le pipeline de build doit passer en moins de 10 minutes",{"type":30,"tag":38,"props":777,"children":778},{},[779],{"type":36,"value":780},"Si le feedback du pipeline prend plus de 10 minutes, les développeurs arrêtent d'attendre le résultat avant de passer à la tâche suivante. Le feedback loop se rompt.",{"type":30,"tag":38,"props":782,"children":783},{},[784],{"type":36,"value":785},"Cette règle vient des recherches sur la productivité des développeurs : au-delà de 10 minutes, le développeur a changé de contexte mental. Quand le pipeline échoue 15 minutes plus tard, le coût de retour au contexte est élevé.",{"type":30,"tag":38,"props":787,"children":788},{},[789],{"type":36,"value":790},"Pour maintenir un pipeline sous 10 minutes : tests unitaires en parallèle, tests d'intégration sélectifs basés sur les changements, cache agressif des dépendances, et séparation en stages, avec un fast feedback en moins de 5 minutes et un slow feedback déclenché séparément.",{"type":30,"tag":621,"props":792,"children":796},{"className":793,"code":794,"language":795,"meta":8,"style":8},"language-yaml shiki shiki-themes catppuccin-frappe github-dark","# GitHub Actions — jobs parallèles\njobs:\n  unit-tests:\n    runs-on: ubuntu-latest\n    steps:\n      - run: npm run test:unit    # \u003C 3 min\n\n  lint-typecheck:\n    runs-on: ubuntu-latest\n    steps:\n      - run: npm run lint && npm run typecheck    # \u003C 2 min\n\n  integration-tests:\n    needs: [unit-tests]    # Seulement si les unit tests passent\n    runs-on: ubuntu-latest\n    steps:\n      - run: npm run test:integration    # \u003C 10 min\n","yaml",[797],{"type":30,"tag":628,"props":798,"children":799},{"__ignoreMap":8},[800,808,822,834,852,864,892,901,914,930,942,968,976,989,1022,1038,1050],{"type":30,"tag":632,"props":801,"children":802},{"class":634,"line":635},[803],{"type":30,"tag":632,"props":804,"children":805},{"style":639},[806],{"type":36,"value":807},"# GitHub Actions — jobs parallèles\n",{"type":30,"tag":632,"props":809,"children":810},{"class":634,"line":484},[811,817],{"type":30,"tag":632,"props":812,"children":814},{"style":813},"--shiki-default:#8CAAEE;--shiki-dark:#85E89D",[815],{"type":36,"value":816},"jobs",{"type":30,"tag":632,"props":818,"children":820},{"style":819},"--shiki-default:#81C8BE;--shiki-dark:#E1E4E8",[821],{"type":36,"value":736},{"type":30,"tag":632,"props":823,"children":824},{"class":634,"line":697},[825,830],{"type":30,"tag":632,"props":826,"children":827},{"style":813},[828],{"type":36,"value":829},"  unit-tests",{"type":30,"tag":632,"props":831,"children":832},{"style":819},[833],{"type":36,"value":736},{"type":30,"tag":632,"props":835,"children":836},{"class":634,"line":725},[837,842,847],{"type":30,"tag":632,"props":838,"children":839},{"style":813},[840],{"type":36,"value":841},"    runs-on",{"type":30,"tag":632,"props":843,"children":844},{"style":819},[845],{"type":36,"value":846},":",{"type":30,"tag":632,"props":848,"children":849},{"style":676},[850],{"type":36,"value":851}," ubuntu-latest\n",{"type":30,"tag":632,"props":853,"children":854},{"class":634,"line":739},[855,860],{"type":30,"tag":632,"props":856,"children":857},{"style":813},[858],{"type":36,"value":859},"    steps",{"type":30,"tag":632,"props":861,"children":862},{"style":819},[863],{"type":36,"value":736},{"type":30,"tag":632,"props":865,"children":867},{"class":634,"line":866},6,[868,873,878,882,887],{"type":30,"tag":632,"props":869,"children":870},{"style":660},[871],{"type":36,"value":872},"      -",{"type":30,"tag":632,"props":874,"children":875},{"style":813},[876],{"type":36,"value":877}," run",{"type":30,"tag":632,"props":879,"children":880},{"style":819},[881],{"type":36,"value":846},{"type":30,"tag":632,"props":883,"children":884},{"style":676},[885],{"type":36,"value":886}," npm run test:unit",{"type":30,"tag":632,"props":888,"children":889},{"style":639},[890],{"type":36,"value":891},"    # \u003C 3 min\n",{"type":30,"tag":632,"props":893,"children":895},{"class":634,"line":894},7,[896],{"type":30,"tag":632,"props":897,"children":898},{"emptyLinePlaceholder":13},[899],{"type":36,"value":900},"\n",{"type":30,"tag":632,"props":902,"children":904},{"class":634,"line":903},8,[905,910],{"type":30,"tag":632,"props":906,"children":907},{"style":813},[908],{"type":36,"value":909},"  lint-typecheck",{"type":30,"tag":632,"props":911,"children":912},{"style":819},[913],{"type":36,"value":736},{"type":30,"tag":632,"props":915,"children":917},{"class":634,"line":916},9,[918,922,926],{"type":30,"tag":632,"props":919,"children":920},{"style":813},[921],{"type":36,"value":841},{"type":30,"tag":632,"props":923,"children":924},{"style":819},[925],{"type":36,"value":846},{"type":30,"tag":632,"props":927,"children":928},{"style":676},[929],{"type":36,"value":851},{"type":30,"tag":632,"props":931,"children":933},{"class":634,"line":932},10,[934,938],{"type":30,"tag":632,"props":935,"children":936},{"style":813},[937],{"type":36,"value":859},{"type":30,"tag":632,"props":939,"children":940},{"style":819},[941],{"type":36,"value":736},{"type":30,"tag":632,"props":943,"children":945},{"class":634,"line":944},11,[946,950,954,958,963],{"type":30,"tag":632,"props":947,"children":948},{"style":660},[949],{"type":36,"value":872},{"type":30,"tag":632,"props":951,"children":952},{"style":813},[953],{"type":36,"value":877},{"type":30,"tag":632,"props":955,"children":956},{"style":819},[957],{"type":36,"value":846},{"type":30,"tag":632,"props":959,"children":960},{"style":676},[961],{"type":36,"value":962}," npm run lint && npm run typecheck",{"type":30,"tag":632,"props":964,"children":965},{"style":639},[966],{"type":36,"value":967},"    # \u003C 2 min\n",{"type":30,"tag":632,"props":969,"children":971},{"class":634,"line":970},12,[972],{"type":30,"tag":632,"props":973,"children":974},{"emptyLinePlaceholder":13},[975],{"type":36,"value":900},{"type":30,"tag":632,"props":977,"children":979},{"class":634,"line":978},13,[980,985],{"type":30,"tag":632,"props":981,"children":982},{"style":813},[983],{"type":36,"value":984},"  integration-tests",{"type":30,"tag":632,"props":986,"children":987},{"style":819},[988],{"type":36,"value":736},{"type":30,"tag":632,"props":990,"children":992},{"class":634,"line":991},14,[993,998,1002,1007,1012,1017],{"type":30,"tag":632,"props":994,"children":995},{"style":813},[996],{"type":36,"value":997},"    needs",{"type":30,"tag":632,"props":999,"children":1000},{"style":819},[1001],{"type":36,"value":846},{"type":30,"tag":632,"props":1003,"children":1004},{"style":660},[1005],{"type":36,"value":1006}," [",{"type":30,"tag":632,"props":1008,"children":1009},{"style":676},[1010],{"type":36,"value":1011},"unit-tests",{"type":30,"tag":632,"props":1013,"children":1014},{"style":660},[1015],{"type":36,"value":1016},"]",{"type":30,"tag":632,"props":1018,"children":1019},{"style":639},[1020],{"type":36,"value":1021},"    # Seulement si les unit tests passent\n",{"type":30,"tag":632,"props":1023,"children":1025},{"class":634,"line":1024},15,[1026,1030,1034],{"type":30,"tag":632,"props":1027,"children":1028},{"style":813},[1029],{"type":36,"value":841},{"type":30,"tag":632,"props":1031,"children":1032},{"style":819},[1033],{"type":36,"value":846},{"type":30,"tag":632,"props":1035,"children":1036},{"style":676},[1037],{"type":36,"value":851},{"type":30,"tag":632,"props":1039,"children":1041},{"class":634,"line":1040},16,[1042,1046],{"type":30,"tag":632,"props":1043,"children":1044},{"style":813},[1045],{"type":36,"value":859},{"type":30,"tag":632,"props":1047,"children":1048},{"style":819},[1049],{"type":36,"value":736},{"type":30,"tag":632,"props":1051,"children":1053},{"class":634,"line":1052},17,[1054,1058,1062,1066,1071],{"type":30,"tag":632,"props":1055,"children":1056},{"style":660},[1057],{"type":36,"value":872},{"type":30,"tag":632,"props":1059,"children":1060},{"style":813},[1061],{"type":36,"value":877},{"type":30,"tag":632,"props":1063,"children":1064},{"style":819},[1065],{"type":36,"value":846},{"type":30,"tag":632,"props":1067,"children":1068},{"style":676},[1069],{"type":36,"value":1070}," npm run test:integration",{"type":30,"tag":632,"props":1072,"children":1073},{"style":639},[1074],{"type":36,"value":1075},"    # \u003C 10 min\n",{"type":30,"tag":225,"props":1077,"children":1079},{"cta":227,"href":228,"title":1078,"type":230},"Votre pipeline CI dépasse les 15 minutes et les développeurs ont arrêté de le surveiller ?",[1080],{"type":30,"tag":38,"props":1081,"children":1082},{},[1083],{"type":36,"value":1084},"Un pipeline qui dérive vers 20-30 minutes nécessite un audit de la structure des tests et des stages. En 30 minutes, j'identifie les goulots d'étranglement et je vous donne une stratégie de réduction à moins de 10 minutes, applicable dès le sprint suivant.",{"type":30,"tag":64,"props":1086,"children":1087},{},[],{"type":30,"tag":68,"props":1089,"children":1091},{"id":1090},"fondamental-3-les-tests-cassés-sont-la-priorité-absolue",[1092],{"type":36,"value":1093},"Fondamental 3 : Les tests cassés sont la priorité absolue",{"type":30,"tag":38,"props":1095,"children":1096},{},[1097],{"type":36,"value":1098},"Quand le pipeline est rouge, réparer le trunk est la priorité numéro un de toute l'équipe, avant les nouvelles features, avant les code reviews en attente, avant les réunions.",{"type":30,"tag":38,"props":1100,"children":1101},{},[1102],{"type":36,"value":1103},"Cette règle s'appelle le \"stop the line\", empruntée au Toyota Production System (Jidoka). Dans le TPS, quand un problème est détecté sur la ligne de production, la ligne s'arrête jusqu'à ce que le problème soit résolu. En CI, le trunk cassé est la ligne arrêtée.",{"type":30,"tag":38,"props":1105,"children":1106},{},[1107],{"type":36,"value":1108},"En pratique : pipeline rouge → alerte immédiate à toute l'équipe via Slack et dashboard. La personne qui a cassé le trunk a 10 minutes pour proposer un fix ou reverter. Si pas de fix en 10 minutes : revert automatique ou manuel. Pas de nouveaux commits sur trunk tant qu'il est rouge.",{"type":30,"tag":38,"props":1110,"children":1111},{},[1112],{"type":36,"value":1113},"Ce qui arrive sans cette règle : les builds cassés s'accumulent, les développeurs ignorent les alertes, et le pipeline devient du décor plutôt qu'un signal utile. J'ai vu des équipes avec un pipeline rouge depuis 3 semaines : tout le monde avait arrêté de regarder.",{"type":30,"tag":64,"props":1115,"children":1116},{},[],{"type":30,"tag":68,"props":1118,"children":1120},{"id":1119},"fondamental-4-tout-le-monde-voit-létat-du-pipeline",[1121],{"type":36,"value":1122},"Fondamental 4 : Tout le monde voit l'état du pipeline",{"type":30,"tag":38,"props":1124,"children":1125},{},[1126],{"type":36,"value":1127},"L'état du pipeline doit être visible passivement par toute l'équipe, pas seulement quand quelqu'un pense à aller le vérifier.",{"type":30,"tag":38,"props":1129,"children":1130},{},[1131],{"type":36,"value":1132},"Les mécanismes de visibilité : dashboard de build sur un écran visible dans l'espace de travail, notification Slack dans le canal de l'équipe (pas seulement à la personne qui a pushé), badge de statut sur le README du repo, statut visible dans l'IDE.",{"type":30,"tag":38,"props":1134,"children":1135},{},[1136],{"type":36,"value":1137},"La différence entre \"notification opt-in\" et \"visibilité passive\" est fondamentale : si le développeur doit aller chercher l'information, il ne le fera pas systématiquement. La visibilité passive crée une conscience collective de l'état de la CI sans effort individuel.",{"type":30,"tag":64,"props":1139,"children":1140},{},[],{"type":30,"tag":68,"props":1142,"children":1144},{"id":1143},"fondamental-5-les-tests-sont-la-définition-de-trunk-en-bonne-santé",[1145],{"type":36,"value":1146},"Fondamental 5 : Les tests sont la définition de \"trunk en bonne santé\"",{"type":30,"tag":38,"props":1148,"children":1149},{},[1150,1152,1158],{"type":36,"value":1151},"Les tests automatisés définissent ce que \"trunk en bonne santé\" signifie : intégrez ce critère dans votre ",{"type":30,"tag":207,"props":1153,"children":1155},{"href":1154},"/fr/dette-technique/definition-of-done-qualite",[1156],{"type":36,"value":1157},"Definition of Done",{"type":36,"value":1159},". Si un comportement n'est pas testé, la CI ne peut pas le protéger.",{"type":30,"tag":38,"props":1161,"children":1162},{},[1163],{"type":36,"value":1164},"La pyramide de tests en CI définit la structure optimale :",{"type":30,"tag":272,"props":1166,"children":1167},{},[1168,1178,1192],{"type":30,"tag":276,"props":1169,"children":1170},{},[1171,1176],{"type":30,"tag":83,"props":1172,"children":1173},{},[1174],{"type":36,"value":1175},"Tests unitaires",{"type":36,"value":1177}," (70-80% des tests) : rapides, sans dépendances externes. Feedback en moins de 2 minutes.",{"type":30,"tag":276,"props":1179,"children":1180},{},[1181,1190],{"type":30,"tag":83,"props":1182,"children":1183},{},[1184],{"type":30,"tag":207,"props":1185,"children":1187},{"href":1186},"/fr/dette-technique/tests-integration-legacy-pieges",[1188],{"type":36,"value":1189},"Tests d'intégration",{"type":36,"value":1191}," (15-20% des tests) : avec base de données ou services externes. Feedback en moins de 8 minutes.",{"type":30,"tag":276,"props":1193,"children":1194},{},[1195,1200],{"type":30,"tag":83,"props":1196,"children":1197},{},[1198],{"type":36,"value":1199},"Tests end-to-end",{"type":36,"value":1201}," (5-10% des tests) : sur les flux critiques uniquement. Déclenchés moins fréquemment.",{"type":30,"tag":38,"props":1203,"children":1204},{},[1205],{"type":36,"value":1206},"Un pipeline vert ne garantit pas que le logiciel est correct : il garantit qu'il est cohérent avec ses tests. La qualité des tests détermine la qualité du signal.",{"type":30,"tag":64,"props":1208,"children":1209},{},[],{"type":30,"tag":68,"props":1211,"children":1213},{"id":1212},"ce-que-ça-change-concrètement",[1214],{"type":36,"value":1215},"Ce que ça change concrètement",{"type":30,"tag":38,"props":1217,"children":1218},{},[1219],{"type":36,"value":1220},"Dans l'équipe mentionnée en introduction, après 6 semaines de travail sur les 5 fondamentaux (parallélisation des tests, feature flags systématiques, règle du stop the line, dashboard visible, refonte de la pyramide de tests), le résultat était mesurable. Le pipeline est passé de 28 minutes à 8 minutes. La durée des branches est passée de 4 jours à 18 heures. Le lead time de delivery a baissé de 40%.",{"type":30,"tag":38,"props":1222,"children":1223},{},[1224],{"type":36,"value":1225},"Aucun recrutement. Aucun changement de framework. Seulement des pratiques humaines appliquées avec discipline.",{"type":30,"tag":38,"props":1227,"children":1228},{},[1229,1231,1237],{"type":36,"value":1230},"Les métriques de maturité CI à suivre (ces indicateurs font partie des ",{"type":30,"tag":207,"props":1232,"children":1234},{"href":1233},"/fr/management/metriques-management-developpeurs-motivation",[1235],{"type":36,"value":1236},"4 métriques DORA",{"type":36,"value":1238},") : fréquence d'intégration par développeur (cible : plus de 2 fois par jour), MTTR du pipeline en cas de rupture (cible : moins de 30 minutes), durée du pipeline en p95 (cible : moins de 10 minutes), taux de flakiness des tests (cible : moins de 5%).",{"type":30,"tag":64,"props":1240,"children":1241},{},[],{"type":30,"tag":68,"props":1243,"children":1245},{"id":1244},"faq-sur-la-continuous-integration",[1246],{"type":36,"value":1247},"FAQ sur la Continuous Integration",{"type":30,"tag":402,"props":1249,"children":1250},{},[1251,1256],{"type":30,"tag":406,"props":1252,"children":1253},{},[1254],{"type":36,"value":1255},"1. Quelle est la différence entre CI et CD (Continuous Delivery / Deployment) ?",{"type":30,"tag":38,"props":1257,"children":1258},{},[1259],{"type":36,"value":1260},"La CI est l'intégration fréquente du code dans le trunk avec vérification automatique. La CD (Delivery) est la capacité à déployer n'importe quel commit en production de façon fiable à tout moment. La CD (Deployment) est le déploiement automatique de chaque commit qui passe la CI. La CI est un prérequis à la CD. On peut pratiquer la CI sans CD, mais pas l'inverse de façon viable.",{"type":30,"tag":402,"props":1262,"children":1263},{},[1264,1269],{"type":30,"tag":406,"props":1265,"children":1266},{},[1267],{"type":36,"value":1268},"2. Comment convaincre une équipe de passer des feature branches longues aux intégrations quotidiennes ?",{"type":30,"tag":38,"props":1270,"children":1271},{},[1272],{"type":36,"value":1273},"Par la data. Calculer le temps moyen passé à résoudre les conflits de merge sur les 3 derniers mois. Dans la plupart des équipes avec des branches de 1-2 semaines, les merge conflicts représentent 10 à 15% du temps de développement. Proposer un pilote de 4 sprints avec des branches courtes et feature flags, et mesurer. Le résultat parle de lui-même.",{"type":30,"tag":402,"props":1275,"children":1276},{},[1277,1282],{"type":30,"tag":406,"props":1278,"children":1279},{},[1280],{"type":36,"value":1281},"3. Les feature flags créent-ils une dette technique ?",{"type":30,"tag":38,"props":1283,"children":1284},{},[1285],{"type":36,"value":1286},"Oui, si mal gérés. Un feature flag non supprimé après le lancement de la feature est de la dette. La règle : chaque feature flag a une date d'expiration définie au moment de sa création. Un linter ou un test automatique vérifie que les flags expirés sont supprimés. En pratique, un backlog dédié à la suppression des flags (2 à 3 par sprint) suffit pour maintenir le stock sous contrôle.",{"type":30,"tag":402,"props":1288,"children":1289},{},[1290,1295],{"type":30,"tag":406,"props":1291,"children":1292},{},[1293],{"type":36,"value":1294},"4. Comment gérer la CI dans un monorepo avec de nombreux services ?",{"type":30,"tag":38,"props":1296,"children":1297},{},[1298],{"type":36,"value":1299},"Avec des pipelines sélectifs basés sur les changements. Les outils comme Nx pour JavaScript/TypeScript, Bazel pour les environnements multi-langages, ou les \"path filters\" dans GitHub Actions permettent de ne lancer que les tests des services impactés par les changements. Cela maintient un pipeline sous 10 minutes même dans un monorepo de 20 services.",{"type":30,"tag":402,"props":1301,"children":1302},{},[1303,1308],{"type":30,"tag":406,"props":1304,"children":1305},{},[1306],{"type":36,"value":1307},"5. Que faire quand les tests sont trop lents pour permettre une intégration quotidienne ?",{"type":30,"tag":38,"props":1309,"children":1310},{},[1311],{"type":36,"value":1312},"C'est le signal pour revoir la pyramide de tests. Audit en 3 étapes : identifier les 20% de tests les plus lents qui représentent 80% du temps, évaluer si ces tests d'intégration pourraient être remplacés par des tests unitaires avec mocks, puis déplacer les tests lents dans un stage séparé déclenché toutes les 2 heures. Le pipeline fast feedback reste sous 10 minutes, le reste se vérifie en continu.",{"type":30,"tag":64,"props":1314,"children":1315},{},[],{"type":30,"tag":225,"props":1317,"children":1318},{"cta":473,"href":474,"title":475,"type":476},[1319],{"type":30,"tag":38,"props":1320,"children":1321},{},[1322],{"type":36,"value":1323},"Le guide complet pour réduire votre lead time en 90 jours inclut un chapitre sur l'optimisation du pipeline CI/CD et les pratiques d'intégration qui font la différence sur la fréquence de delivery, avec les métriques DORA à suivre.",{"type":30,"tag":1325,"props":1326,"children":1327},"style",{},[1328],{"type":36,"value":1329},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":8,"searchDepth":484,"depth":484,"links":1331},[1332,1333,1334,1335,1336,1337,1338,1339],{"id":552,"depth":484,"text":555},{"id":601,"depth":484,"text":604},{"id":772,"depth":484,"text":775},{"id":1090,"depth":484,"text":1093},{"id":1119,"depth":484,"text":1122},{"id":1143,"depth":484,"text":1146},{"id":1212,"depth":484,"text":1215},{"id":1244,"depth":484,"text":1247},"content:fr:pratiques-agiles:continuous-integration-fondamentaux.md","fr/pratiques-agiles/continuous-integration-fondamentaux.md","fr/pratiques-agiles/continuous-integration-fondamentaux",{"_path":352,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":1344,"description":1345,"id":1346,"date":1347,"listed":13,"nocomments":7,"hidden":7,"categories":1348,"tags":1349,"--cover":1353,"readingTime":1354,"body":1359,"_type":492,"_id":1794,"_source":494,"_file":1795,"_stem":1796,"_extension":497},"Estimation agile : pourquoi les story points sont une mauvaise idée","Les story points mesurent l'effort perçu et créent des jeux politiques. Les alternatives que les équipes d'élite utilisent — et comment faire la transition.",22,"2026-02-23",[6],[1350,1351,1352],"Story Points","Estimation","No Estimates","covers/articles/story-points-alternative.jpg",{"text":1355,"minutes":1356,"time":1357,"words":1358},"8 min read",7.565,453900,1513,{"type":27,"children":1360,"toc":1785},[1361,1366,1371,1376,1381,1386,1391,1394,1400,1405,1410,1415,1420,1425,1428,1434,1444,1454,1464,1473,1476,1482,1487,1492,1535,1540,1545,1548,1554,1565,1570,1575,1580,1583,1589,1594,1604,1614,1624,1629,1632,1638,1650,1663,1673,1683,1693,1696,1702,1715,1728,1748,1761,1774,1777],{"type":30,"tag":31,"props":1362,"children":1364},{"id":1363},"estimation-agile-pourquoi-les-story-points-sont-une-mauvaise-idée",[1365],{"type":36,"value":1344},{"type":30,"tag":38,"props":1367,"children":1368},{},[1369],{"type":36,"value":1370},"J'étais en coaching d'une équipe dans une grande institution financière. Lors du sprint planning, un développeur senior a dit \"13\" pour une story. Silence. Puis, progressivement, tous les autres ont voté 13 aussi. La story a été estimée à 13 points en 90 secondes.",{"type":30,"tag":38,"props":1372,"children":1373},{},[1374],{"type":36,"value":1375},"Personne n'avait compris la story. Tout le monde avait suivi le senior.",{"type":30,"tag":38,"props":1377,"children":1378},{},[1379],{"type":36,"value":1380},"La semaine suivante, le management a demandé à l'équipe d'augmenter sa vélocité de 20%. L'équipe a obligé, en estimant les stories plus bas. La vélocité a augmenté. La valeur livrée n'a pas changé.",{"type":30,"tag":38,"props":1382,"children":1383},{},[1384],{"type":36,"value":1385},"Ron Jeffries, l'un des inventeurs du planning poker et des story points, a publié en 2019 un article titré \"Story Points Revisited\" dans lequel il regrette leur création. \"I think story points are mostly harmful,\" écrit-il. Pas parce que la complexité ne mérite pas d'être estimée, mais parce que la façon dont la plupart des équipes utilisent les story points crée plus de problèmes qu'elle n'en résout.",{"type":30,"tag":38,"props":1387,"children":1388},{},[1389],{"type":36,"value":1390},"Vingt-cinq ans de terrain m'ont donné le même constat.",{"type":30,"tag":64,"props":1392,"children":1393},{},[],{"type":30,"tag":68,"props":1395,"children":1397},{"id":1396},"ce-que-les-story-points-mesurent-vraiment",[1398],{"type":36,"value":1399},"Ce que les story points mesurent vraiment",{"type":30,"tag":38,"props":1401,"children":1402},{},[1403],{"type":36,"value":1404},"Officiellement : la complexité relative d'une User Story, indépendante du temps.",{"type":30,"tag":38,"props":1406,"children":1407},{},[1408],{"type":36,"value":1409},"En pratique : l'effort perçu, filtré par les dynamiques politiques de l'équipe.",{"type":30,"tag":38,"props":1411,"children":1412},{},[1413],{"type":36,"value":1414},"La dérive se produit en 3 étapes invariables. L'équipe estime une story à 8 points parce qu'elle est complexe. Le management observe que l'équipe fait 30 story points par sprint. Le trimestre suivant, l'objectif est de \"faire 35 story points par sprint.\"",{"type":30,"tag":38,"props":1416,"children":1417},{},[1418],{"type":36,"value":1419},"À l'étape 3, les story points ne mesurent plus la complexité : ils mesurent une pression de production. Les développeurs le savent et ajustent leurs estimations en conséquence. La vélocité monte. La valeur livrée ne change pas.",{"type":30,"tag":38,"props":1421,"children":1422},{},[1423],{"type":36,"value":1424},"Dans toute équipe qui utilise les story points depuis plus de 6 mois avec une pression sur la vélocité, des patterns de gaming émergent. L'inflation des estimations pour \"se couvrir\" : tout devient 5 ou 8, jamais 1 ou 2. La déflation pour \"montrer de la vélocité\" : accepter plus de stories au sprint planning qu'on ne peut en faire. Et la négociation politique lors du planning poker : le senior dit 13, tout le monde s'aligne sur 13.",{"type":30,"tag":64,"props":1426,"children":1427},{},[],{"type":30,"tag":68,"props":1429,"children":1431},{"id":1430},"les-3-pathologies-créées-par-les-story-points",[1432],{"type":36,"value":1433},"Les 3 pathologies créées par les story points",{"type":30,"tag":38,"props":1435,"children":1436},{},[1437,1442],{"type":30,"tag":83,"props":1438,"children":1439},{},[1440],{"type":36,"value":1441},"Pathologie 1 : La durée des sessions de planning.",{"type":36,"value":1443}," Le planning poker crée des discussions de 20 à 45 minutes par story sur des questions d'estimation abstraite. Ces discussions ne créent pas de valeur : elles consomment du temps qui pourrait être utilisé à comprendre le métier ou à lever les ambiguïtés réelles. J'ai mesuré dans une équipe de 8 personnes : 180 minutes par sprint consacrées à l'estimation. Soit 78 heures-personne par trimestre pour produire un chiffre que personne ne croit.",{"type":30,"tag":38,"props":1445,"children":1446},{},[1447,1452],{"type":30,"tag":83,"props":1448,"children":1449},{},[1450],{"type":36,"value":1451},"Pathologie 2 : La comparaison entre équipes.",{"type":36,"value":1453}," \"L'équipe A fait 40 points par sprint et l'équipe B en fait 25.\" Cette comparaison est absurde : les story points de deux équipes différentes ne mesurent pas la même chose. Mais le management qui a accès à ces données les compare inévitablement. J'ai vu cette comparaison détruire la collaboration entre deux équipes qui travaillaient pourtant sur la même base de code.",{"type":30,"tag":38,"props":1455,"children":1456},{},[1457,1462],{"type":30,"tag":83,"props":1458,"children":1459},{},[1460],{"type":36,"value":1461},"Pathologie 3 : La dette d'estimation.",{"type":36,"value":1463}," Quand le contexte change (nouvelle technologie, départ d'un senior, changement de stack), la calibration des story points devient invalide. L'équipe passe plusieurs sprints avec une vélocité erratique, et le management interprète ça comme un problème de productivité. C'est un problème de métrique inadaptée, pas de performance.",{"type":30,"tag":225,"props":1465,"children":1467},{"cta":227,"href":228,"title":1466,"type":230},"Votre planning poker est devenu une source de friction sans apporter de valeur réelle à la planification ?",[1468],{"type":30,"tag":38,"props":1469,"children":1470},{},[1471],{"type":36,"value":1472},"La transition vers des alternatives aux story points nécessite un accompagnement pour ne pas perdre la confiance du business dans la planification. En 30 minutes, je définis avec vous la stratégie de transition adaptée à votre contexte et à votre management.",{"type":30,"tag":64,"props":1474,"children":1475},{},[],{"type":30,"tag":68,"props":1477,"children":1479},{"id":1478},"lalternative-1-le-sizing-t-shirt",[1480],{"type":36,"value":1481},"L'alternative 1 : le sizing T-shirt",{"type":30,"tag":38,"props":1483,"children":1484},{},[1485],{"type":36,"value":1486},"Le sizing T-shirt remplace les valeurs numériques par des tailles (S, M, L, XL). L'avantage fondamental : il est impossible de faire de la fausse précision avec des tailles. \"Ceci est une story M\" ne peut pas être transformé en \"notre vélocité est de 35 tailles-M par sprint.\"",{"type":30,"tag":38,"props":1488,"children":1489},{},[1490],{"type":36,"value":1491},"La définition des tailles en termes de cycle time attendu (pas d'effort, de durée réelle) est ce qui rend la méthode concrète :",{"type":30,"tag":272,"props":1493,"children":1494},{},[1495,1505,1515,1525],{"type":30,"tag":276,"props":1496,"children":1497},{},[1498,1503],{"type":30,"tag":83,"props":1499,"children":1500},{},[1501],{"type":36,"value":1502},"S",{"type":36,"value":1504}," : terminable en moins d'un jour de développement",{"type":30,"tag":276,"props":1506,"children":1507},{},[1508,1513],{"type":30,"tag":83,"props":1509,"children":1510},{},[1511],{"type":36,"value":1512},"M",{"type":36,"value":1514}," : terminable en 1 à 3 jours",{"type":30,"tag":276,"props":1516,"children":1517},{},[1518,1523],{"type":30,"tag":83,"props":1519,"children":1520},{},[1521],{"type":36,"value":1522},"L",{"type":36,"value":1524}," : terminable en 1 semaine",{"type":30,"tag":276,"props":1526,"children":1527},{},[1528,1533],{"type":30,"tag":83,"props":1529,"children":1530},{},[1531],{"type":36,"value":1532},"XL",{"type":36,"value":1534}," : trop grande pour un sprint, doit être découpée avant d'entrer en sprint planning",{"type":30,"tag":38,"props":1536,"children":1537},{},[1538],{"type":36,"value":1539},"La règle est non-négociable : toute story XL ne peut pas entrer en sprint. Elle doit être découpée en stories S, M, ou L.",{"type":30,"tag":38,"props":1541,"children":1542},{},[1543],{"type":36,"value":1544},"Ce que le business voit : le nombre de stories terminées par sprint et leur distribution par taille. Pas une vélocité abstraite, mais un throughput concret.",{"type":30,"tag":64,"props":1546,"children":1547},{},[],{"type":30,"tag":68,"props":1549,"children":1551},{"id":1550},"lalternative-2-le-throughput-et-le-mouvement-noestimates",[1552],{"type":36,"value":1553},"L'alternative 2 : le throughput et le mouvement #NoEstimates",{"type":30,"tag":38,"props":1555,"children":1556},{},[1557,1559,1563],{"type":36,"value":1558},"Le mouvement #NoEstimates (Vasco Duarte, Woody Zuill) propose une approche encore plus radicale : arrêter d'estimer et mesurer la capacité à travers le ",{"type":30,"tag":83,"props":1560,"children":1561},{},[1562],{"type":36,"value":355},{"type":36,"value":1564},", c'est-à-dire le nombre de stories terminées par sprint, quelle que soit leur taille.",{"type":30,"tag":38,"props":1566,"children":1567},{},[1568],{"type":36,"value":1569},"L'hypothèse fondamentale : si les stories sont suffisamment petites et uniformes (toutes inférieures ou égales à 3 jours), la loi des grands nombres s'applique. La variance se lisse sur 3 à 6 sprints et le throughput devient un prédicteur fiable de la capacité future.",{"type":30,"tag":38,"props":1571,"children":1572},{},[1573],{"type":36,"value":1574},"Ce que le business entend : \"Avec 15 stories par sprint en moyenne sur les 6 derniers sprints, il nous faudra environ 3 sprints pour terminer les 40 stories restantes de la fonctionnalité X.\" C'est plus précis qu'une prédiction basée sur des story points qui dérivent.",{"type":30,"tag":38,"props":1576,"children":1577},{},[1578],{"type":36,"value":1579},"Le prérequis est strict : que les stories soient uniformément petites. C'est la condition que beaucoup d'équipes ne respectent pas, et c'est pourquoi elles ne peuvent pas adopter #NoEstimates directement. Le sizing T-shirt est souvent une étape intermédiaire nécessaire.",{"type":30,"tag":64,"props":1581,"children":1582},{},[],{"type":30,"tag":68,"props":1584,"children":1586},{"id":1585},"comment-faire-la-transition-sans-casser-la-confiance-du-business",[1587],{"type":36,"value":1588},"Comment faire la transition sans casser la confiance du business",{"type":30,"tag":38,"props":1590,"children":1591},{},[1592],{"type":36,"value":1593},"Le business a souvent été \"vendu\" les story points comme un outil de prédictibilité. La transition doit être gérée avec transparence, pas imposée.",{"type":30,"tag":38,"props":1595,"children":1596},{},[1597,1602],{"type":30,"tag":83,"props":1598,"children":1599},{},[1600],{"type":36,"value":1601},"Sprints 1-2",{"type":36,"value":1603}," : présenter les deux méthodes en parallèle. Continuer à estimer en story points tout en calculant le throughput. Montrer que les deux donnent les mêmes prédictions sur 3 sprints. Rassurer sur la continuité de la prédictibilité.",{"type":30,"tag":38,"props":1605,"children":1606},{},[1607,1612],{"type":30,"tag":83,"props":1608,"children":1609},{},[1610],{"type":36,"value":1611},"Sprints 3-4",{"type":36,"value":1613}," : passer en sizing T-shirt uniquement. Montrer que la planification capacitaire reste fiable. Partager les données avec le management.",{"type":30,"tag":38,"props":1615,"children":1616},{},[1617,1622],{"type":30,"tag":83,"props":1618,"children":1619},{},[1620],{"type":36,"value":1621},"Sprints 5 et suivants",{"type":36,"value":1623}," : si l'équipe est prête et les stories sont uniformément petites, explorer le throughput comme seule métrique.",{"type":30,"tag":38,"props":1625,"children":1626},{},[1627],{"type":36,"value":1628},"L'argument décisif : les données. Sur les 6 derniers mois, quelle est la corrélation entre la vélocité en points et la valeur livrée ? Dans la plupart des équipes, cette corrélation est faible. Ce fait, présenté objectivement, démontre que les story points ne mesurent pas ce qu'on prétend qu'ils mesurent.",{"type":30,"tag":64,"props":1630,"children":1631},{},[],{"type":30,"tag":68,"props":1633,"children":1635},{"id":1634},"les-métriques-qui-remplacent-avantageusement-la-vélocité",[1636],{"type":36,"value":1637},"Les métriques qui remplacent avantageusement la vélocité",{"type":30,"tag":38,"props":1639,"children":1640},{},[1641,1643,1648],{"type":36,"value":1642},"Les ",{"type":30,"tag":207,"props":1644,"children":1645},{"href":1233},[1646],{"type":36,"value":1647},"recherches DORA",{"type":36,"value":1649}," (DevOps Research and Assessment) sont claires : les équipes avec les meilleures performances de delivery n'utilisent généralement pas les story points. Elles mesurent le flux.",{"type":30,"tag":38,"props":1651,"children":1652},{},[1653,1661],{"type":30,"tag":83,"props":1654,"children":1655},{},[1656],{"type":30,"tag":207,"props":1657,"children":1658},{"href":5},[1659],{"type":36,"value":1660},"Cycle Time",{"type":36,"value":1662}," : temps entre le début du développement et le merge. Mesure la fluidité du workflow.",{"type":30,"tag":38,"props":1664,"children":1665},{},[1666,1671],{"type":30,"tag":83,"props":1667,"children":1668},{},[1669],{"type":36,"value":1670},"Throughput",{"type":36,"value":1672}," : nombre de stories terminées par sprint. Mesure la capacité réelle de livraison.",{"type":30,"tag":38,"props":1674,"children":1675},{},[1676,1681],{"type":30,"tag":83,"props":1677,"children":1678},{},[1679],{"type":36,"value":1680},"Flow Efficiency",{"type":36,"value":1682}," : pourcentage du cycle time où la story est activement travaillée versus en attente. Révèle les goulots d'étranglement invisibles.",{"type":30,"tag":38,"props":1684,"children":1685},{},[1686,1691],{"type":30,"tag":83,"props":1687,"children":1688},{},[1689],{"type":36,"value":1690},"Work Item Age",{"type":36,"value":1692}," : âge des stories en cours. Un item vieux de 3 sprints est un signal d'alerte qui mérite investigation.",{"type":30,"tag":64,"props":1694,"children":1695},{},[],{"type":30,"tag":68,"props":1697,"children":1699},{"id":1698},"faq-sur-lestimation-agile",[1700],{"type":36,"value":1701},"FAQ sur l'estimation agile",{"type":30,"tag":402,"props":1703,"children":1704},{},[1705,1710],{"type":30,"tag":406,"props":1706,"children":1707},{},[1708],{"type":36,"value":1709},"1. Peut-on abandonner les story points si le management les utilise pour les planifications budgétaires ?",{"type":30,"tag":38,"props":1711,"children":1712},{},[1713],{"type":36,"value":1714},"Oui, avec une transition transparente. Le management a besoin de prédictibilité, pas de story points spécifiquement. Montrer que le throughput avec des intervalles de confiance basés sur 6 sprints de données est plus fiable pour les prédictions à 3-6 mois que la vélocité en points, qui dérive systématiquement. Proposer une période de validation en parallèle avant le switch complet.",{"type":30,"tag":402,"props":1716,"children":1717},{},[1718,1723],{"type":30,"tag":406,"props":1719,"children":1720},{},[1721],{"type":36,"value":1722},"2. Le sizing T-shirt n'est-il pas trop imprécis pour planifier ?",{"type":30,"tag":38,"props":1724,"children":1725},{},[1726],{"type":36,"value":1727},"C'est exactement la bonne précision. L'estimation en story points donne une fausse précision : 8 points n'est pas plus précis que L, c'est juste plus abstraitement précis. Le sizing T-shirt force à accepter l'incertitude naturelle de l'estimation et à planifier avec des intervalles de confiance plutôt que des prédictions ponctuelles illusoires.",{"type":30,"tag":402,"props":1729,"children":1730},{},[1731,1736],{"type":30,"tag":406,"props":1732,"children":1733},{},[1734],{"type":36,"value":1735},"3. Comment gérer les stories très différentes en taille avec le sizing T-shirt ?",{"type":30,"tag":38,"props":1737,"children":1738},{},[1739,1741,1746],{"type":36,"value":1740},"En appliquant la règle de découpage : toute story XL est découpée avant d'entrer en sprint. C'est le prérequis de la méthode. Un ",{"type":30,"tag":207,"props":1742,"children":1743},{"href":209},[1744],{"type":36,"value":1745},"backlog sain",{"type":36,"value":1747}," contient essentiellement des stories S et M prêtes à développer. Si une story ne peut pas être découpée en stories M ou L, c'est un signal que la story est mal définie, pas que la méthode ne fonctionne pas.",{"type":30,"tag":402,"props":1749,"children":1750},{},[1751,1756],{"type":30,"tag":406,"props":1752,"children":1753},{},[1754],{"type":36,"value":1755},"4. Les story points sont-ils utiles pour l'estimation initiale d'un projet ?",{"type":30,"tag":38,"props":1757,"children":1758},{},[1759],{"type":36,"value":1760},"Pour une estimation de haut niveau d'un nouveau projet (scope discovery, appel d'offres), les story points peuvent avoir leur utilité, pas pour le sprint planning quotidien, mais pour donner un ordre de grandeur du périmètre. Dans ce cas, utiliser des T-shirt sizes sur les epics ou features plutôt que sur les stories individuelles donne un résultat équivalent avec moins de friction.",{"type":30,"tag":402,"props":1762,"children":1763},{},[1764,1769],{"type":30,"tag":406,"props":1765,"children":1766},{},[1767],{"type":36,"value":1768},"5. Que faire quand les développeurs seniors refusent d'abandonner les story points ?",{"type":30,"tag":38,"props":1770,"children":1771},{},[1772],{"type":36,"value":1773},"Ne pas forcer. Commencer par un pilote volontaire sur un sprint, en mesurant le temps passé en estimation et en comparant la qualité des prédictions. Le résultat de l'expérience parle mieux que l'argument de principe. Les développeurs qui résistent le plus au changement deviennent souvent les défenseurs les plus convaincus une fois qu'ils ont mesuré le gain de temps.",{"type":30,"tag":64,"props":1775,"children":1776},{},[],{"type":30,"tag":225,"props":1778,"children":1779},{"cta":473,"href":474,"title":475,"type":476},[1780],{"type":30,"tag":38,"props":1781,"children":1782},{},[1783],{"type":36,"value":1784},"Le guide complet pour réduire votre lead time en 90 jours inclut une section sur les métriques de flow (cycle time, throughput, WIP) qui remplacent avantageusement la vélocité en story points avec plus de précision prédictive.",{"title":8,"searchDepth":484,"depth":484,"links":1786},[1787,1788,1789,1790,1791,1792,1793],{"id":1396,"depth":484,"text":1399},{"id":1430,"depth":484,"text":1433},{"id":1478,"depth":484,"text":1481},{"id":1550,"depth":484,"text":1553},{"id":1585,"depth":484,"text":1588},{"id":1634,"depth":484,"text":1637},{"id":1698,"depth":484,"text":1701},"content:fr:pratiques-agiles:story-points-estimation-agile-alternative.md","fr/pratiques-agiles/story-points-estimation-agile-alternative.md","fr/pratiques-agiles/story-points-estimation-agile-alternative",{"_path":209,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":1798,"description":1799,"id":1052,"date":1800,"listed":13,"nocomments":7,"hidden":7,"categories":1801,"tags":1802,"--cover":1806,"readingTime":1807,"body":1811,"_type":492,"_id":2241,"_source":494,"_file":2242,"_stem":2243,"_extension":497},"Les anti-patterns du backlog : comment en sortir","Un backlog de 400 items n'est pas un outil de planification : c'est un cimetière de bonnes intentions. Les 5 anti-patterns et la méthode pour retrouver un backlog utilisable.","2026-02-11",[6],[1803,1804,1805],"Backlog","Anti-patterns","Product Management","covers/articles/anti-patterns-backlog.jpg",{"text":1355,"minutes":1808,"time":1809,"words":1810},7.525,451500,1505,{"type":27,"children":1812,"toc":2232},[1813,1818,1823,1828,1833,1838,1843,1846,1852,1862,1878,1888,1893,1896,1902,1911,1920,1929,1932,1938,1947,1956,1965,1998,2003,2012,2015,2021,2030,2039,2048,2053,2056,2062,2071,2080,2089,2094,2097,2103,2113,2123,2141,2144,2150,2169,2182,2195,2208,2221,2224],{"type":30,"tag":31,"props":1814,"children":1816},{"id":1815},"les-anti-patterns-du-backlog-comment-en-sortir",[1817],{"type":36,"value":1798},{"type":30,"tag":38,"props":1819,"children":1820},{},[1821],{"type":36,"value":1822},"J'ai ouvert le Jira d'une équipe bancaire que j'accompagnais pour un diagnostic de delivery. 847 tickets. Les plus anciens dataient de 3 ans. Le PO m'a dit : \"On garde tout, on sait jamais.\"",{"type":30,"tag":38,"props":1824,"children":1825},{},[1826],{"type":36,"value":1827},"J'ai ensuite demandé combien d'items avaient été développés parmi ceux créés il y a plus de 6 mois. La réponse : moins de 8%.",{"type":30,"tag":38,"props":1829,"children":1830},{},[1831],{"type":36,"value":1832},"92% de ce backlog ne serait jamais traité. Mais il existait. Il occupait de l'espace cognitif à chaque session de planning, chaque affinage, chaque conversation sur les priorités. C'est le paradoxe du backlog aspirateur : plus il grossit, moins il est utile, et plus il coûte.",{"type":30,"tag":38,"props":1834,"children":1835},{},[1836],{"type":36,"value":1837},"La promesse du backlog est simple : tout ce qu'on veut faire est documenté, priorisé, et prêt à être planifié. La réalité dans 80% des équipes que j'accompagne : le backlog grossit plus vite qu'il ne se vide, personne ne le lit entièrement, et les vrais sujets urgents se trouvent dans des messages Slack plutôt que dans Jira.",{"type":30,"tag":38,"props":1839,"children":1840},{},[1841],{"type":36,"value":1842},"Voici les 5 anti-patterns responsables de 90% des backlogs inutilisables, et la méthode de sortie.",{"type":30,"tag":64,"props":1844,"children":1845},{},[],{"type":30,"tag":68,"props":1847,"children":1849},{"id":1848},"anti-pattern-1-le-backlog-aspirateur",[1850],{"type":36,"value":1851},"Anti-pattern 1 : Le backlog aspirateur",{"type":30,"tag":38,"props":1853,"children":1854},{},[1855,1860],{"type":30,"tag":83,"props":1856,"children":1857},{},[1858],{"type":36,"value":1859},"Symptôme",{"type":36,"value":1861}," : tout ce qui est mentionné lors d'une réunion, d'une conversation Slack, ou d'un email devient un ticket. Le volume augmente de 10 à 20 items par semaine. Les tickets créés ne sont jamais fermés sauf quand ils sont développés.",{"type":30,"tag":38,"props":1863,"children":1864},{},[1865,1870,1872,1876],{"type":30,"tag":83,"props":1866,"children":1867},{},[1868],{"type":36,"value":1869},"Coût",{"type":36,"value":1871}," : un backlog aspirateur génère une charge cognitive invisible. Chaque session de ",{"type":30,"tag":207,"props":1873,"children":1874},{"href":218},[1875],{"type":36,"value":221},{"type":36,"value":1877}," ou d'affinage nécessite de parcourir des centaines d'items pour trouver les 5 à 10 pertinents pour le prochain sprint. En termes de temps : 2 à 4 heures par semaine de chasse aux items pertinents sur un backlog de 400 items.",{"type":30,"tag":38,"props":1879,"children":1880},{},[1881,1886],{"type":30,"tag":83,"props":1882,"children":1883},{},[1884],{"type":36,"value":1885},"Sortie",{"type":36,"value":1887}," : instaurer un critère d'entrée dans le backlog. Un item n'entre dans le backlog que si le PO l'a validé comme pertinent, s'il a une valeur business identifiable, et s'il sera probablement traité dans les 3 prochains mois.",{"type":30,"tag":38,"props":1889,"children":1890},{},[1891],{"type":36,"value":1892},"Les idées \"peut-être un jour\" vont dans un document séparé (Notion, Confluence, même un Google Sheets), non accessible dans le backlog de sprint. La frontière entre \"backlog de travail\" et \"liste d'idées\" est l'une des distinctions les plus importantes qu'une équipe peut établir.",{"type":30,"tag":64,"props":1894,"children":1895},{},[],{"type":30,"tag":68,"props":1897,"children":1899},{"id":1898},"anti-pattern-2-les-stories-sans-critères-dacceptation",[1900],{"type":36,"value":1901},"Anti-pattern 2 : Les stories sans critères d'acceptation",{"type":30,"tag":38,"props":1903,"children":1904},{},[1905,1909],{"type":30,"tag":83,"props":1906,"children":1907},{},[1908],{"type":36,"value":1859},{"type":36,"value":1910}," : des tickets avec un titre, parfois une description vague, et aucun critère d'acceptation. \"Améliorer le dashboard.\" \"Corriger les problèmes de performance.\" Aucune mesure de succès.",{"type":30,"tag":38,"props":1912,"children":1913},{},[1914,1918],{"type":30,"tag":83,"props":1915,"children":1916},{},[1917],{"type":36,"value":1869},{"type":36,"value":1919}," : une story sans critères d'acceptation entre en sprint et génère des aller-retours entre le développeur et le PO pendant le sprint. En moyenne, 3 à 5 interruptions par story floue, à 30 minutes chacune. Sur un sprint avec 4 stories floues : 6 à 10 heures perdues, sans compter le contexte-switching.",{"type":30,"tag":38,"props":1921,"children":1922},{},[1923,1927],{"type":30,"tag":83,"props":1924,"children":1925},{},[1926],{"type":36,"value":1885},{"type":36,"value":1928}," : appliquer la règle \"if it's not testable, it's not ready\". Chaque story qui ne peut pas être vérifiée par un test (automatique ou manuel) est retirée du backlog jusqu'à ce que ses critères d'acceptation soient définis. Le PO est responsable de cette définition.",{"type":30,"tag":64,"props":1930,"children":1931},{},[],{"type":30,"tag":68,"props":1933,"children":1935},{"id":1934},"anti-pattern-3-labsence-de-priorisation-explicite",[1936],{"type":36,"value":1937},"Anti-pattern 3 : L'absence de priorisation explicite",{"type":30,"tag":38,"props":1939,"children":1940},{},[1941,1945],{"type":30,"tag":83,"props":1942,"children":1943},{},[1944],{"type":36,"value":1859},{"type":36,"value":1946}," : le backlog est trié par date de création, alphabétiquement, ou pas du tout. La priorité de chaque item est \"implicite\", connue du PO mais pas visible dans l'outil.",{"type":30,"tag":38,"props":1948,"children":1949},{},[1950,1954],{"type":30,"tag":83,"props":1951,"children":1952},{},[1953],{"type":36,"value":1869},{"type":36,"value":1955}," : lors de chaque sprint planning, la question \"par quoi on commence ?\" déclenche une discussion de 30 à 60 minutes. Le résultat dépend de qui est le plus vocal dans la salle, pas de la valeur business réelle. C'est une forme de prise de décision politique déguisée en planification.",{"type":30,"tag":38,"props":1957,"children":1958},{},[1959,1963],{"type":30,"tag":83,"props":1960,"children":1961},{},[1962],{"type":36,"value":1885},{"type":36,"value":1964}," : priorisation explicite par une méthode cohérente. La méthode importe moins que la cohérence :",{"type":30,"tag":272,"props":1966,"children":1967},{},[1968,1978,1988],{"type":30,"tag":276,"props":1969,"children":1970},{},[1971,1976],{"type":30,"tag":83,"props":1972,"children":1973},{},[1974],{"type":36,"value":1975},"RICE",{"type":36,"value":1977}," (Reach × Impact × Confidence / Effort) : chiffré, comparable",{"type":30,"tag":276,"props":1979,"children":1980},{},[1981,1986],{"type":30,"tag":83,"props":1982,"children":1983},{},[1984],{"type":36,"value":1985},"MoSCoW",{"type":36,"value":1987}," (Must/Should/Could/Won't) : simple, rapide",{"type":30,"tag":276,"props":1989,"children":1990},{},[1991,1996],{"type":30,"tag":83,"props":1992,"children":1993},{},[1994],{"type":36,"value":1995},"Weighted Shortest Job First",{"type":36,"value":1997}," : ratio valeur/effort, utilisé dans SAFe",{"type":30,"tag":38,"props":1999,"children":2000},{},[2001],{"type":36,"value":2002},"Ce qui compte : la priorité est visible dans l'outil et mise à jour au moins une fois par sprint.",{"type":30,"tag":225,"props":2004,"children":2006},{"cta":227,"href":228,"title":2005,"type":230},"Votre sprint planning dure trop longtemps parce qu'il faut chercher les priorités dans un backlog illisible ?",[2007],{"type":30,"tag":38,"props":2008,"children":2009},{},[2010],{"type":36,"value":2011},"Un backlog dysfonctionnel est souvent le symptôme d'un processus de product discovery manquant ou d'une tension PO/équipe non résolue. En 30 minutes, j'identifie la cause racine et vous donne le plan de \"backlog détox\" adapté à votre contexte.",{"type":30,"tag":64,"props":2013,"children":2014},{},[],{"type":30,"tag":68,"props":2016,"children":2018},{"id":2017},"anti-pattern-4-les-epics-zombies",[2019],{"type":36,"value":2020},"Anti-pattern 4 : Les epics zombies",{"type":30,"tag":38,"props":2022,"children":2023},{},[2024,2028],{"type":30,"tag":83,"props":2025,"children":2026},{},[2027],{"type":36,"value":1859},{"type":36,"value":2029}," : des epics créées il y a 12, 18, 24 mois, toujours \"en cours\", avec 3 stories terminées sur 20. Elles ne sont pas fermées parce que \"on va y revenir un jour.\"",{"type":30,"tag":38,"props":2031,"children":2032},{},[2033,2037],{"type":30,"tag":83,"props":2034,"children":2035},{},[2036],{"type":36,"value":1869},{"type":36,"value":2038}," : les epics zombies créent une illusion de planification. Les items sous ces epics apparaissent dans les recherches et les rapports, gonflant artificiellement le backlog et perturbant les métriques de vélocité. Plus insidieux : elles occupent mentalement le PO et l'équipe dans des discussions de planification sur des sujets qui ne seront statistiquement jamais développés.",{"type":30,"tag":38,"props":2040,"children":2041},{},[2042,2046],{"type":30,"tag":83,"props":2043,"children":2044},{},[2045],{"type":36,"value":1885},{"type":36,"value":2047}," : lors d'une session de \"backlog détox\", appliquer la règle des 90 jours sur les epics. Une epic qui n'a pas eu de story développée dans les 90 jours est soit fermée avec les stories non-terminées marquées \"won't do\", soit réarchivée dans un document de vision produit, soit continuée uniquement si une décision consciente est prise de l'inclure dans la roadmap des 3 prochains mois.",{"type":30,"tag":38,"props":2049,"children":2050},{},[2051],{"type":36,"value":2052},"Dans l'équipe bancaire mentionnée en introduction, la suppression des epics zombies a réduit le backlog de 847 à 312 items en une session de 2 heures. La clarté retrouvée a été immédiate.",{"type":30,"tag":64,"props":2054,"children":2055},{},[],{"type":30,"tag":68,"props":2057,"children":2059},{"id":2058},"anti-pattern-5-le-backlog-comme-outil-de-micro-management",[2060],{"type":36,"value":2061},"Anti-pattern 5 : Le backlog comme outil de micro-management",{"type":30,"tag":38,"props":2063,"children":2064},{},[2065,2069],{"type":30,"tag":83,"props":2066,"children":2067},{},[2068],{"type":36,"value":1859},{"type":36,"value":2070}," : des tickets créés par des managers avec des descriptions de solutions techniques plutôt que de problèmes à résoudre. Ou des tickets de suivi créés pour chaque sous-tâche d'un développement, utilisés pour monitorer l'avancement heure par heure.",{"type":30,"tag":38,"props":2072,"children":2073},{},[2074,2078],{"type":30,"tag":83,"props":2075,"children":2076},{},[2077],{"type":36,"value":1869},{"type":36,"value":2079}," : les développeurs passent plus de temps à mettre à jour les tickets qu'à développer. La création de tickets devient une activité à part entière, et la qualité du code baisse parce que le focus est sur les sous-tâches visibles, pas sur la livraison de valeur.",{"type":30,"tag":38,"props":2081,"children":2082},{},[2083,2087],{"type":30,"tag":83,"props":2084,"children":2085},{},[2086],{"type":36,"value":1885},{"type":36,"value":2088}," : distinguer les tickets de valeur (ce qu'on cherche à accomplir pour l'utilisateur) des tâches techniques (comment on va l'accomplir). Les tâches techniques sont gérées par le développeur dans sa branche Git, pas dans Jira. Le manager voit l'avancement de la story, pas des sous-tâches.",{"type":30,"tag":38,"props":2090,"children":2091},{},[2092],{"type":36,"value":2093},"Ce n'était jamais un problème de confiance individuelle. C'était un problème de système de pilotage inadapté.",{"type":30,"tag":64,"props":2095,"children":2096},{},[],{"type":30,"tag":68,"props":2098,"children":2100},{"id":2099},"la-méthode-backlog-détox-en-3-sessions-de-2h",[2101],{"type":36,"value":2102},"La méthode \"backlog détox\" en 3 sessions de 2h",{"type":30,"tag":38,"props":2104,"children":2105},{},[2106,2111],{"type":30,"tag":83,"props":2107,"children":2108},{},[2109],{"type":36,"value":2110},"Session 1 : Le tri brutal",{"type":36,"value":2112}," (PO + Tech Lead) : parcourir tous les items avec une règle binaire : ce ticket sera-t-il développé dans les 3 prochains mois ? Si non, archiver sans remords. Un ticket archivé peut toujours être réactivé. Résultat attendu : réduction de 40 à 60% du backlog.",{"type":30,"tag":38,"props":2114,"children":2115},{},[2116,2121],{"type":30,"tag":83,"props":2117,"children":2118},{},[2119],{"type":36,"value":2120},"Session 2 : La priorisation",{"type":36,"value":2122}," (PO + équipe) : sur les items conservés, appliquer une méthode de priorisation explicite. Trier le backlog par priorité décroissante. Résultat attendu : un backlog où les 20 premiers items sont les 20 items les plus importants.",{"type":30,"tag":38,"props":2124,"children":2125},{},[2126,2131,2133,2139],{"type":30,"tag":83,"props":2127,"children":2128},{},[2129],{"type":36,"value":2130},"Session 3 : La DoR",{"type":36,"value":2132}," (PO + Tech Lead) : pour les 15 à 20 premiers items (ceux qui pourraient entrer dans les 2 prochains sprints), vérifier que chaque item respecte la ",{"type":30,"tag":207,"props":2134,"children":2136},{"href":2135},"/fr/pratiques-agiles/definition-of-ready-bugs-sprint",[2137],{"type":36,"value":2138},"Definition of Ready",{"type":36,"value":2140},". Les items qui ne la respectent pas sont enrichis ou reportés. Résultat attendu : un backlog actionnable, priorisé, avec les premiers items \"DoR-validés\".",{"type":30,"tag":64,"props":2142,"children":2143},{},[],{"type":30,"tag":68,"props":2145,"children":2147},{"id":2146},"faq-sur-le-backlog-agile",[2148],{"type":36,"value":2149},"FAQ sur le backlog Agile",{"type":30,"tag":402,"props":2151,"children":2152},{},[2153,2158],{"type":30,"tag":406,"props":2154,"children":2155},{},[2156],{"type":36,"value":2157},"1. Quelle taille maximale devrait avoir un backlog ?",{"type":30,"tag":38,"props":2159,"children":2160},{},[2161,2163,2167],{"type":36,"value":2162},"Il n'y a pas de règle universelle, mais un backlog utilisable devrait contenir 2 à 3 mois de travail maximum pour les items priorisés. Un backlog surchargé augmente mécaniquement le ",{"type":30,"tag":207,"props":2164,"children":2165},{"href":5},[2166],{"type":36,"value":16},{"type":36,"value":2168}," et allonge le lead time. Au-delà, la priorisation devient abstraite et les items du bas ne seront statistiquement jamais développés. Pour une équipe qui livre 20 à 30 story points par sprint, cela représente 80 à 120 items priorisés, avec un volume illimité d'idées dans une liste séparée \"future\".",{"type":30,"tag":402,"props":2170,"children":2171},{},[2172,2177],{"type":30,"tag":406,"props":2173,"children":2174},{},[2175],{"type":36,"value":2176},"2. Qui est responsable du nettoyage du backlog ?",{"type":30,"tag":38,"props":2178,"children":2179},{},[2180],{"type":36,"value":2181},"Le PO est responsable de la santé du backlog, mais le nettoyage est un travail collectif. Le PO décide quoi garder et quoi archiver, mais l'équipe et le Tech Lead valident que les items conservés sont techniquement réalistes et suffisamment détaillés. Un backlog propre est le résultat d'une collaboration, pas d'un seul rôle.",{"type":30,"tag":402,"props":2183,"children":2184},{},[2185,2190],{"type":30,"tag":406,"props":2186,"children":2187},{},[2188],{"type":36,"value":2189},"3. Comment convaincre un PO de supprimer des items qu'il a créés ?",{"type":30,"tag":38,"props":2191,"children":2192},{},[2193],{"type":36,"value":2194},"Utiliser les données. Dans les 6 derniers mois, combien d'items vieux de plus de 6 mois ont été développés ? En général, moins de 10%. Montrer que les 90% restants génèrent du bruit sans produire de valeur. L'argument qui fonctionne : \"Un backlog propre nous permet de nous concentrer sur les 20 items qui comptent vraiment. Les 380 autres nous distraient de ces 20.\"",{"type":30,"tag":402,"props":2196,"children":2197},{},[2198,2203],{"type":30,"tag":406,"props":2199,"children":2200},{},[2201],{"type":36,"value":2202},"4. Faut-il un outil différent pour les \"idées futures\" séparées du backlog ?",{"type":30,"tag":38,"props":2204,"children":2205},{},[2206],{"type":36,"value":2207},"Pas nécessairement. Une section ou un label différent dans le même outil suffit. L'important est la séparation visuelle et fonctionnelle : les items \"futures\" n'apparaissent pas dans le sprint planning, ne sont pas inclus dans les métriques de vélocité, et ne nécessitent pas de DoR. Confluence, Notion, ou un simple Google Sheets fonctionnent très bien pour cette liste d'idées.",{"type":30,"tag":402,"props":2209,"children":2210},{},[2211,2216],{"type":30,"tag":406,"props":2212,"children":2213},{},[2214],{"type":36,"value":2215},"5. À quelle fréquence faut-il faire un backlog détox ?",{"type":30,"tag":38,"props":2217,"children":2218},{},[2219],{"type":36,"value":2220},"Une session initiale de détox (les 3 sessions de 2h décrites ci-dessus), puis une maintenance hebdomadaire de 30 minutes en affinage suffit pour maintenir le backlog sain. Sans maintenance régulière, le backlog reviendra à son état précédent en 3 à 4 mois : les mécanismes d'accumulation sont structurels, pas accidentels.",{"type":30,"tag":64,"props":2222,"children":2223},{},[],{"type":30,"tag":225,"props":2225,"children":2226},{"cta":473,"href":474,"title":475,"type":476},[2227],{"type":30,"tag":38,"props":2228,"children":2229},{},[2230],{"type":36,"value":2231},"Le framework pour réduire votre lead time en 90 jours inclut une section complète sur l'optimisation du backlog et des processus de priorisation, avec les templates de session de backlog détox prêts à l'emploi.",{"title":8,"searchDepth":484,"depth":484,"links":2233},[2234,2235,2236,2237,2238,2239,2240],{"id":1848,"depth":484,"text":1851},{"id":1898,"depth":484,"text":1901},{"id":1934,"depth":484,"text":1937},{"id":2017,"depth":484,"text":2020},{"id":2058,"depth":484,"text":2061},{"id":2099,"depth":484,"text":2102},{"id":2146,"depth":484,"text":2149},"content:fr:pratiques-agiles:anti-patterns-backlog.md","fr/pratiques-agiles/anti-patterns-backlog.md","fr/pratiques-agiles/anti-patterns-backlog",{"_path":2245,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":2246,"description":2247,"id":970,"date":2248,"listed":13,"nocomments":7,"hidden":7,"categories":2249,"tags":2250,"--cover":2254,"readingTime":2255,"body":2260,"_type":492,"_id":2623,"_source":494,"_file":2624,"_stem":2625,"_extension":497},"/fr/pratiques-agiles/retrospective-agile-format-efficace","Rétrospective Agile : le format qui génère vraiment du changement","80% des rétrospectives produisent les mêmes items depuis 6 mois sans impact. Le format en 5 étapes qui crée de vraies décisions et un suivi réel.","2026-01-30",[6],[2251,2252,2253],"Rétrospective","Agile","Amélioration Continue","covers/articles/retrospective-agile-format.jpg",{"text":2256,"minutes":2257,"time":2258,"words":2259},"7 min read",6.465,387900,1293,{"type":27,"children":2261,"toc":2617},[2262,2267,2272,2277,2282,2287,2292,2295,2301,2306,2311,2316,2321,2324,2330,2338,2350,2355,2363,2368,2373,2378,2387,2390,2398,2403,2408,2439,2460,2468,2473,2478,2483,2491,2496,2508,2511,2517,2522,2527,2532,2535,2541,2554,2567,2580,2593,2606,2609],{"type":30,"tag":31,"props":2263,"children":2265},{"id":2264},"rétrospective-agile-le-format-qui-génère-vraiment-du-changement",[2266],{"type":36,"value":2246},{"type":30,"tag":38,"props":2268,"children":2269},{},[2270],{"type":36,"value":2271},"\"Communication\", \"Documentation\", \"Tests.\"",{"type":30,"tag":38,"props":2273,"children":2274},{},[2275],{"type":36,"value":2276},"Ces 3 items sont apparus dans la rétro d'une équipe que j'accompagnais dans le secteur bancaire. Je leur ai demandé depuis combien de temps ils revenaient. Un développeur a souri : \"Depuis qu'on a commencé les rétros. Il y a deux ans.\"",{"type":30,"tag":38,"props":2278,"children":2279},{},[2280],{"type":36,"value":2281},"Deux ans. Les mêmes items. Aucun changement.",{"type":30,"tag":38,"props":2283,"children":2284},{},[2285],{"type":36,"value":2286},"Ce n'est pas une anecdote isolée. C'est le pattern le plus fréquent que j'observe dans les équipes Agile : une rétro qui tourne en rond depuis des mois, produit des post-its, et ne change rien. Non par mauvaise volonté, mais parce que le format lui-même est cassé.",{"type":30,"tag":38,"props":2288,"children":2289},{},[2290],{"type":36,"value":2291},"La rétrospective est l'outil le plus puissant de Scrum. C'est aussi le plus mal utilisé. Quand elle fonctionne, c'est le moteur de l'amélioration continue. Quand elle échoue, c'est une heure de thérapie collective qui produit des post-its et aucun changement. La différence tient à quelques choix structurels, pas à l'intention ou à la motivation de l'équipe.",{"type":30,"tag":64,"props":2293,"children":2294},{},[],{"type":30,"tag":68,"props":2296,"children":2298},{"id":2297},"pourquoi-les-rétros-classiques-naméliorent-rien",[2299],{"type":36,"value":2300},"Pourquoi les rétros classiques n'améliorent rien",{"type":30,"tag":38,"props":2302,"children":2303},{},[2304],{"type":36,"value":2305},"La plupart des rétrospectives suivent le même format : collecter des \"went well\" et \"needs improvement\", voter sur les items, définir des actions. Ce format a un défaut fondamental : il traite tous les sprints comme des événements isolés.",{"type":30,"tag":38,"props":2307,"children":2308},{},[2309],{"type":36,"value":2310},"Il n'y a pas de mémoire. Pas de continuité. Pas de suivi.",{"type":30,"tag":38,"props":2312,"children":2313},{},[2314],{"type":36,"value":2315},"J'ai calculé dans une équipe de 7 personnes que j'accompagnais chez un acteur des médias : 180 heures de rétros sur 12 mois. 15 items d'amélioration documentés. 2 mis en œuvre réellement. Coût par amélioration implémentée : 90 heures d'équipe.",{"type":30,"tag":38,"props":2317,"children":2318},{},[2319],{"type":36,"value":2320},"Le problème n'était pas l'équipe. C'était l'absence de trois éléments : les données, la continuité, et la discipline d'un seul item par sprint.",{"type":30,"tag":64,"props":2322,"children":2323},{},[],{"type":30,"tag":68,"props":2325,"children":2327},{"id":2326},"le-format-en-5-étapes",[2328],{"type":36,"value":2329},"Le format en 5 étapes",{"type":30,"tag":38,"props":2331,"children":2332},{},[2333],{"type":30,"tag":83,"props":2334,"children":2335},{},[2336],{"type":36,"value":2337},"Étape 1 : Préparer les données (15 min avant la rétro)",{"type":30,"tag":38,"props":2339,"children":2340},{},[2341,2343,2348],{"type":36,"value":2342},"La rétrospective commence par des faits, pas par des opinions. Le facilitateur prépare un tableau de bord simple du sprint : ",{"type":30,"tag":207,"props":2344,"children":2345},{"href":352},[2346],{"type":36,"value":2347},"vélocité",{"type":36,"value":2349}," réalisée versus vélocité prévue, nombre de stories terminées sur stories engagées, bugs remontés en prod, incidents notables, comparaison avec les 2-3 sprints précédents.",{"type":30,"tag":38,"props":2351,"children":2352},{},[2353],{"type":36,"value":2354},"Ces données ancrent la rétro dans le réel. Elles évitent les discussions \"je sens que ça va moins bien\" versus \"moi je pense que ça va bien\", qui ne produisent rien. Les faits ne blâment personne. Ils permettent à l'équipe de parler du système, pas des personnes.",{"type":30,"tag":38,"props":2356,"children":2357},{},[2358],{"type":30,"tag":83,"props":2359,"children":2360},{},[2361],{"type":36,"value":2362},"Étape 2 : Identifier les patterns sur 3 sprints (15 min)",{"type":30,"tag":38,"props":2364,"children":2365},{},[2366],{"type":36,"value":2367},"Avant de collecter les points de la rétro en cours, afficher les actions décidées lors des 2 rétros précédentes. Ont-elles été implémentées ? Si oui, quel a été l'impact mesurable ? Si non, pourquoi ?",{"type":30,"tag":38,"props":2369,"children":2370},{},[2371],{"type":36,"value":2372},"Cette revue de l'historique est la partie la plus souvent sautée, et la plus importante. Elle transforme la rétro d'un rituel répétitif en processus d'amélioration continue réel.",{"type":30,"tag":38,"props":2374,"children":2375},{},[2376],{"type":36,"value":2377},"Si les mêmes actions reviennent sans être implémentées, le problème est structurel : soit le temps n'est pas alloué, soit la décision n'a pas le soutien du management. Nommer ce problème est plus utile que d'ajouter un nouveau post-it.",{"type":30,"tag":225,"props":2379,"children":2381},{"cta":227,"href":228,"title":2380,"type":230},"Vos rétrospectives tournent en rond depuis des mois sans générer de vraie amélioration ?",[2382],{"type":30,"tag":38,"props":2383,"children":2384},{},[2385],{"type":36,"value":2386},"Une rétrospective qui ne produit pas de changement révèle souvent un problème plus profond : absence de temps alloué à l'amélioration, sujets trop sensibles pour être traités en groupe, ou culture du blame qui inhibe la discussion honnête. En 30 minutes, j'identifie la cause racine et vous donne le plan d'action.",{"type":30,"tag":64,"props":2388,"children":2389},{},[],{"type":30,"tag":38,"props":2391,"children":2392},{},[2393],{"type":30,"tag":83,"props":2394,"children":2395},{},[2396],{"type":36,"value":2397},"Étape 3 : Voter sur 1 seul problème à résoudre (20 min)",{"type":30,"tag":38,"props":2399,"children":2400},{},[2401],{"type":36,"value":2402},"C'est la rupture principale avec le format classique. La plupart des rétros collectent 15 items et tentent de tous les traiter en 30 minutes. Résultat : discussions superficielles et actions vagues qui ne seront jamais tenues.",{"type":30,"tag":38,"props":2404,"children":2405},{},[2406],{"type":36,"value":2407},"Le format qui fonctionne :",{"type":30,"tag":2409,"props":2410,"children":2411},"ol",{},[2412,2417,2422,2427],{"type":30,"tag":276,"props":2413,"children":2414},{},[2415],{"type":36,"value":2416},"Chaque membre de l'équipe écrit 2 à 3 problèmes observés ce sprint",{"type":30,"tag":276,"props":2418,"children":2419},{},[2420],{"type":36,"value":2421},"Regrouper les items similaires (5 minutes)",{"type":30,"tag":276,"props":2423,"children":2424},{},[2425],{"type":36,"value":2426},"Vote à points : chaque membre dispose de 3 votes à distribuer librement",{"type":30,"tag":276,"props":2428,"children":2429},{},[2430,2432,2437],{"type":36,"value":2431},"Sélectionner le ",{"type":30,"tag":83,"props":2433,"children":2434},{},[2435],{"type":36,"value":2436},"1 seul item",{"type":36,"value":2438}," avec le plus de votes pour être traité ce sprint",{"type":30,"tag":38,"props":2440,"children":2441},{},[2442,2444,2450,2452,2458],{"type":36,"value":2443},"L'idée qu'une rétro doit traiter tous les problèmes est une illusion. Un seul problème vraiment résolu vaut 10 actions non-tenues. La rétro est l'un des ",{"type":30,"tag":207,"props":2445,"children":2447},{"href":2446},"/fr/management/engineering-culture-rituels",[2448],{"type":36,"value":2449},"6 rituels",{"type":36,"value":2451}," qui construisent une culture d'excellence technique. Mike Cohn l'explique dans ",{"type":30,"tag":2453,"props":2454,"children":2455},"em",{},[2456],{"type":36,"value":2457},"Succeeding with Agile",{"type":36,"value":2459}," : la qualité de l'amélioration continue ne se mesure pas au nombre d'actions décidées, mais au nombre d'actions implémentées.",{"type":30,"tag":38,"props":2461,"children":2462},{},[2463],{"type":30,"tag":83,"props":2464,"children":2465},{},[2466],{"type":36,"value":2467},"Étape 4 : Définir une action SMART avec un owner (15 min)",{"type":30,"tag":38,"props":2469,"children":2470},{},[2471],{"type":36,"value":2472},"Pour le problème sélectionné, définir une action qui respecte les critères SMART : spécifique, mesurable, actionnable, réaliste, temporelle.",{"type":30,"tag":38,"props":2474,"children":2475},{},[2476],{"type":36,"value":2477},"\"Améliorer la communication\" ne passe pas. \"Écrire les critères d'acceptation de 100% des stories du prochain sprint en affinage\" passe.",{"type":30,"tag":38,"props":2479,"children":2480},{},[2481],{"type":36,"value":2482},"L'owner est la personne qui s'assure que l'action se fait et en rend compte à la prochaine rétro. Ce n'est pas forcément celle qui la réalise : c'est celle qui la garantit.",{"type":30,"tag":38,"props":2484,"children":2485},{},[2486],{"type":30,"tag":83,"props":2487,"children":2488},{},[2489],{"type":36,"value":2490},"Étape 5 : Fermer le cycle à la rétro suivante (5 min)",{"type":30,"tag":38,"props":2492,"children":2493},{},[2494],{"type":36,"value":2495},"L'owner présente en 5 minutes : l'action a-t-elle été implémentée ? Quel est l'impact mesuré ? Si non implémentée, quel était le blocage ?",{"type":30,"tag":38,"props":2497,"children":2498},{},[2499,2501,2506],{"type":36,"value":2500},"Cette étape de clôture est ce qui transforme la rétro en processus d'amélioration réel. Sans elle, les actions restent des intentions. C'est le \"closing the loop\", le principe fondamental de tout système d'amélioration continue, appuyez-vous sur les ",{"type":30,"tag":207,"props":2502,"children":2503},{"href":1233},[2504],{"type":36,"value":2505},"métriques DORA",{"type":36,"value":2507}," pour ancrer ces discussions dans des données factuelles, du PDCA de Deming à l'inspect & adapt de Scrum.",{"type":30,"tag":64,"props":2509,"children":2510},{},[],{"type":30,"tag":68,"props":2512,"children":2514},{"id":2513},"ce-qui-change-réellement",[2515],{"type":36,"value":2516},"Ce qui change réellement",{"type":30,"tag":38,"props":2518,"children":2519},{},[2520],{"type":36,"value":2521},"En appliquant ce format dans une équipe de 6 personnes chez un client dans le secteur financier que j'accompagnais, les résultats après 3 mois étaient clairs : 7 actions définies sur 6 rétros, 6 actions implémentées (versus 2 sur 12 avec l'ancien format). Le taux d'acceptation des stories en fin de sprint est passé de 71% à 89%.",{"type":30,"tag":38,"props":2523,"children":2524},{},[2525],{"type":36,"value":2526},"La durée des rétros n'a pas changé : 75 minutes. Le nombre d'actions par rétro a baissé de 5 à 1. L'impact a été multiplié par 3.",{"type":30,"tag":38,"props":2528,"children":2529},{},[2530],{"type":36,"value":2531},"Ce n'était jamais un problème d'engagement de l'équipe. C'était un problème de système.",{"type":30,"tag":64,"props":2533,"children":2534},{},[],{"type":30,"tag":68,"props":2536,"children":2538},{"id":2537},"faq-sur-la-rétrospective-agile",[2539],{"type":36,"value":2540},"FAQ sur la rétrospective Agile",{"type":30,"tag":402,"props":2542,"children":2543},{},[2544,2549],{"type":30,"tag":406,"props":2545,"children":2546},{},[2547],{"type":36,"value":2548},"1. Faut-il varier le format de rétrospective chaque sprint ?",{"type":30,"tag":38,"props":2550,"children":2551},{},[2552],{"type":36,"value":2553},"La variation de format (Start/Stop/Continue, Mad/Sad/Glad, 4L...) est utile pour maintenir l'engagement. Mais le fond (données réelles, vote, action SMART, suivi) doit rester stable. Varier la forme sans varier le fond ne produit pas plus de résultats. Varier le fond, en particulier traiter un seul problème et exiger un suivi d'impact, produit des résultats même avec un format répétitif.",{"type":30,"tag":402,"props":2555,"children":2556},{},[2557,2562],{"type":30,"tag":406,"props":2558,"children":2559},{},[2560],{"type":36,"value":2561},"2. Comment rendre une rétrospective safe quand l'équipe ne se fait pas confiance ?",{"type":30,"tag":38,"props":2563,"children":2564},{},[2565],{"type":36,"value":2566},"Commencer par des rétros à base de données uniquement : \"voilà ce que les chiffres disent\" plutôt que \"voilà ce que je ressens\". Les données ne blâment personne. Une fois la confiance établie sur les faits, introduire progressivement les retours qualitatifs. Les rétros anonymes (des outils comme Retrium ou EasyRetro permettent les votes anonymes) peuvent aider dans les équipes avec des tensions.",{"type":30,"tag":402,"props":2568,"children":2569},{},[2570,2575],{"type":30,"tag":406,"props":2571,"children":2572},{},[2573],{"type":36,"value":2574},"3. Comment gérer un manager qui assiste aux rétros et inhibe les retours honnêtes ?",{"type":30,"tag":38,"props":2576,"children":2577},{},[2578],{"type":36,"value":2579},"La présence d'un manager hiérarchique dans une rétrospective est rarement bénéfique. C'est une règle Scrum souvent contournée. Si la présence est inévitable, établir des règles explicites : le manager est observateur, pas participant, et les retours ne peuvent pas être utilisés dans les évaluations de performance. Idéalement, démontrer au manager que les meilleures rétros se tiennent sans sa présence : les résultats parlent d'eux-mêmes.",{"type":30,"tag":402,"props":2581,"children":2582},{},[2583,2588],{"type":30,"tag":406,"props":2584,"children":2585},{},[2586],{"type":36,"value":2587},"4. Quelle est la durée idéale d'une rétrospective pour un sprint de 2 semaines ?",{"type":30,"tag":38,"props":2589,"children":2590},{},[2591],{"type":36,"value":2592},"60 à 90 minutes pour une équipe de 5 à 8 personnes. Moins de 60 minutes ne laisse pas assez de temps pour une discussion de qualité. Plus de 90 minutes produit de la fatigue et des discussions qui s'éloignent du sujet. La rigueur du facilitateur sur le timeboxing de chaque étape est la clé pour tenir dans le temps.",{"type":30,"tag":402,"props":2594,"children":2595},{},[2596,2601],{"type":30,"tag":406,"props":2597,"children":2598},{},[2599],{"type":36,"value":2600},"5. Que faire si les sujets les plus importants sont trop sensibles pour être traités en groupe ?",{"type":30,"tag":38,"props":2602,"children":2603},{},[2604],{"type":36,"value":2605},"Ne pas les forcer en rétro collective. Si un problème implique une tension entre deux personnes, une défaillance d'un manager, ou un conflit non-résolu, la rétro en groupe n'est pas le bon format. Ces sujets se traitent en 1-on-1 ou en médiation privée. Une rétro qui force des sujets sensibles en surface crée de la méfiance et des non-dits durables, l'opposé du résultat voulu.",{"type":30,"tag":64,"props":2607,"children":2608},{},[],{"type":30,"tag":225,"props":2610,"children":2611},{"cta":473,"href":474,"title":475,"type":476},[2612],{"type":30,"tag":38,"props":2613,"children":2614},{},[2615],{"type":36,"value":2616},"Le framework complet pour réduire votre lead time en 90 jours, incluant une section dédiée à l'optimisation des cérémonies Agile (rétrospective, sprint planning, affinage) pour qu'elles contribuent à l'accélération plutôt qu'à la ralentir.",{"title":8,"searchDepth":484,"depth":484,"links":2618},[2619,2620,2621,2622],{"id":2297,"depth":484,"text":2300},{"id":2326,"depth":484,"text":2329},{"id":2513,"depth":484,"text":2516},{"id":2537,"depth":484,"text":2540},"content:fr:pratiques-agiles:retrospective-agile-format-efficace.md","fr/pratiques-agiles/retrospective-agile-format-efficace.md","fr/pratiques-agiles/retrospective-agile-format-efficace",{"_path":2135,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":2627,"description":2628,"id":894,"date":2629,"listed":13,"nocomments":7,"hidden":7,"categories":2630,"tags":2631,"--cover":2634,"readingTime":2635,"body":2639,"_type":492,"_id":3014,"_source":494,"_file":3015,"_stem":3016,"_extension":497},"Definition of Ready : l'outil qui réduit les bugs en sprint","Les bugs de sprint viennent rarement du code. Ils viennent de User Stories mal définies qui entrent en sprint. La Definition of Ready est le filtre qui change ça.","2026-01-19",[6],[2138,2632,2633],"User Stories","Qualité Sprint","covers/articles/definition-of-ready.jpg",{"text":2256,"minutes":2636,"time":2637,"words":2638},7.005,420300,1401,{"type":27,"children":2640,"toc":3006},[2641,2646,2651,2656,2661,2666,2669,2675,2680,2685,2690,2695,2698,2704,2709,2719,2729,2739,2749,2759,2764,2773,2776,2782,2787,2792,2815,2826,2831,2834,2840,2845,2850,2855,2875,2880,2883,2889,2894,2904,2914,2917,2923,2943,2956,2969,2982,2995,2998],{"type":30,"tag":31,"props":2642,"children":2644},{"id":2643},"definition-of-ready-loutil-qui-réduit-les-bugs-en-sprint",[2645],{"type":36,"value":2627},{"type":30,"tag":38,"props":2647,"children":2648},{},[2649],{"type":36,"value":2650},"Il y a quelques années, j'accompagnais une équipe de développement dans le secteur des médias. Chaque sprint, des stories revenaient en fin de revue avec le même commentaire du PO : \"Ce n'est pas ce que j'avais demandé.\" Les développeurs étaient frustrés. Le PO était frustré. Et pourtant, chacun avait l'impression d'avoir bien fait son travail.",{"type":30,"tag":38,"props":2652,"children":2653},{},[2654],{"type":36,"value":2655},"J'ai analysé les stories des trois derniers sprints. Aucune n'avait de critères d'acceptation écrits. Aucune. Les développeurs avaient interprété les spécifications. Le PO avait imaginé quelque chose d'autre. Le bug n'était pas dans le code : il était dans la story.",{"type":30,"tag":38,"props":2657,"children":2658},{},[2659],{"type":36,"value":2660},"Ce pattern, je l'ai vu dans toutes les organisations où j'ai travaillé : BNP Paribas, Canal+, Agirc-Arrco. Les bugs de sprint viennent rarement d'un code mal écrit. Ils viennent d'une spécification que tout le monde pensait comprendre, et que chacun avait interprétée différemment.",{"type":30,"tag":38,"props":2662,"children":2663},{},[2664],{"type":36,"value":2665},"La Definition of Ready est le filtre qui arrête ces bugs avant qu'ils coûtent.",{"type":30,"tag":64,"props":2667,"children":2668},{},[],{"type":30,"tag":68,"props":2670,"children":2672},{"id":2671},"ce-que-la-dor-résout-vraiment",[2673],{"type":36,"value":2674},"Ce que la DoR résout vraiment",{"type":30,"tag":38,"props":2676,"children":2677},{},[2678],{"type":36,"value":2679},"Dans les équipes que j'accompagne, 60 à 70% des bugs de sprint trouvent leur origine dans une story mal définie. Pas dans un développeur incompétent. Pas dans une architecture fragile. Dans l'ambiguïté d'une spécification.",{"type":30,"tag":38,"props":2681,"children":2682},{},[2683],{"type":36,"value":2684},"La DoR (Definition of Ready) est le contrat d'entrée en sprint. Elle pose une question simple : \"Cette story est-elle suffisamment claire pour que l'équipe puisse la développer sans devoir s'arrêter pour poser des questions ?\"",{"type":30,"tag":38,"props":2686,"children":2687},{},[2688],{"type":36,"value":2689},"Une story non-prête qui entre en sprint génère en moyenne 3 interruptions pour des clarifications (chacune coûtant 30 minutes de contexte-switching au développeur et 15 minutes au PO). À cela s'ajoute une probabilité de 40% que la story ne soit pas acceptée en fin de sprint, nécessitant un sprint supplémentaire. Coût total : 2 à 5 fois le coût d'une story bien préparée.",{"type":30,"tag":38,"props":2691,"children":2692},{},[2693],{"type":36,"value":2694},"Le calcul est simple. Les critères d'acceptation écrits en affinage prennent 15 minutes. Les aller-retours en cours de sprint coûtent 9 heures. La DoR n'est pas de la bureaucratie : c'est de l'économie.",{"type":30,"tag":64,"props":2696,"children":2697},{},[],{"type":30,"tag":68,"props":2699,"children":2701},{"id":2700},"les-5-critères-de-la-dor",[2702],{"type":36,"value":2703},"Les 5 critères de la DoR",{"type":30,"tag":38,"props":2705,"children":2706},{},[2707],{"type":36,"value":2708},"Une DoR n'est pas universelle : elle doit refléter les problèmes spécifiques de votre équipe. Mais 5 critères sont quasi-universels, et je commence toujours par ceux-là dans les ateliers que j'anime.",{"type":30,"tag":38,"props":2710,"children":2711},{},[2712,2717],{"type":30,"tag":83,"props":2713,"children":2714},{},[2715],{"type":36,"value":2716},"Critère 1 : L'objectif business est clair.",{"type":36,"value":2718}," \"Pourquoi livrons-nous cette story ? Quel problème utilisateur résout-elle ?\" Une story sans objectif business génère des décisions de design arbitraires : les développeurs inventent la valeur qu'ils n'ont pas reçue.",{"type":30,"tag":38,"props":2720,"children":2721},{},[2722,2727],{"type":30,"tag":83,"props":2723,"children":2724},{},[2725],{"type":36,"value":2726},"Critère 2 : Les critères d'acceptation sont écrits.",{"type":36,"value":2728}," Au moins 3 scénarios Gherkin (Given/When/Then) ou une liste de conditions vérifiables. \"L'utilisateur peut se connecter\" n'est pas un critère d'acceptation. \"Étant donné un utilisateur avec un email valide et un mot de passe correct, quand il soumet le formulaire, alors il est redirigé vers le dashboard\" en est un.",{"type":30,"tag":38,"props":2730,"children":2731},{},[2732,2737],{"type":30,"tag":83,"props":2733,"children":2734},{},[2735],{"type":36,"value":2736},"Critère 3 : Les dépendances sont identifiées.",{"type":36,"value":2738}," La story dépend-elle d'une API externe, d'un autre sprint, d'une décision non-prise ? Si oui, ces dépendances sont documentées et leur statut est connu. Une dépendance découverte en sprint crée un blocage non planifié.",{"type":30,"tag":38,"props":2740,"children":2741},{},[2742,2747],{"type":30,"tag":83,"props":2743,"children":2744},{},[2745],{"type":36,"value":2746},"Critère 4 : La story est estimable.",{"type":36,"value":2748}," L'équipe peut donner un ordre de grandeur après avoir lu la story. Si elle ne peut pas estimer, c'est qu'il manque de l'information, pas que l'équipe est incompétente.",{"type":30,"tag":38,"props":2750,"children":2751},{},[2752,2757],{"type":30,"tag":83,"props":2753,"children":2754},{},[2755],{"type":36,"value":2756},"Critère 5 : La story est indépendante et livrable.",{"type":36,"value":2758}," Elle peut être développée sans bloquer sur une autre story du même sprint, et elle produit de la valeur de façon autonome. Les stories qui s'enchaînent sans être livrables séparément créent des cascades de blocages.",{"type":30,"tag":38,"props":2760,"children":2761},{},[2762],{"type":36,"value":2763},"Ces 5 critères s'affichent dans l'espace de travail de l'équipe et s'intègrent dans le template de story Jira ou Linear. Deux heures en atelier suffisent pour les définir collectivement.",{"type":30,"tag":225,"props":2765,"children":2767},{"cta":227,"href":228,"title":2766,"type":230},"Vos sprints finissent avec des stories incomplètes parce que les specs manquaient de clarté ?",[2768],{"type":30,"tag":38,"props":2769,"children":2770},{},[2771],{"type":36,"value":2772},"La DoR seule ne suffit pas si le processus d'affinage est absent ou dysfonctionnel. En 30 minutes, j'identifie les failles de votre processus de préparation du backlog et vous donne un plan de correction concret, celui qui réduira vos bugs de sprint de 50% en 2 mois.",{"type":30,"tag":64,"props":2774,"children":2775},{},[],{"type":30,"tag":68,"props":2777,"children":2779},{"id":2778},"le-rituel-de-validation-avant-le-sprint-planning",[2780],{"type":36,"value":2781},"Le rituel de validation avant le sprint planning",{"type":30,"tag":38,"props":2783,"children":2784},{},[2785],{"type":36,"value":2786},"Deux jours avant chaque sprint planning, le Scrum Master et le PO passent en revue les stories candidates et vérifient chaque critère de la DoR.",{"type":30,"tag":38,"props":2788,"children":2789},{},[2790],{"type":36,"value":2791},"Le résultat est binaire :",{"type":30,"tag":272,"props":2793,"children":2794},{},[2795,2805],{"type":30,"tag":276,"props":2796,"children":2797},{},[2798,2803],{"type":30,"tag":83,"props":2799,"children":2800},{},[2801],{"type":36,"value":2802},"Story prête",{"type":36,"value":2804}," : tous les critères sont satisfaits → elle peut entrer en sprint planning",{"type":30,"tag":276,"props":2806,"children":2807},{},[2808,2813],{"type":30,"tag":83,"props":2809,"children":2810},{},[2811],{"type":36,"value":2812},"Story non-prête",{"type":36,"value":2814}," : au moins un critère manque → elle est exclue avec une note expliquant ce qui manque",{"type":30,"tag":38,"props":2816,"children":2817},{},[2818,2820,2824],{"type":36,"value":2819},"Cette étape prend 30 minutes maximum. Elle évite des heures de discussion pendant le sprint planning sur des stories qui ne sont pas prêtes. Quand j'ai introduit ce rituel dans une équipe Agirc-Arrco, le ",{"type":30,"tag":207,"props":2821,"children":2822},{"href":218},[2823],{"type":36,"value":221},{"type":36,"value":2825}," est passé de 3h30 à 1h45 en deux sprints.",{"type":30,"tag":38,"props":2827,"children":2828},{},[2829],{"type":36,"value":2830},"Le résultat de cette validation est une liste de stories \"DoR-validées\" qui entre au sprint planning, et une liste de stories \"DoR-en-attente\" avec les actions nécessaires pour les préparer au sprint suivant.",{"type":30,"tag":64,"props":2832,"children":2833},{},[],{"type":30,"tag":68,"props":2835,"children":2837},{"id":2836},"gérer-la-pression-de-remplir-le-sprint-malgré-tout",[2838],{"type":36,"value":2839},"Gérer la pression de \"remplir le sprint malgré tout\"",{"type":30,"tag":38,"props":2841,"children":2842},{},[2843],{"type":36,"value":2844},"La résistance principale à la DoR est prévisible : \"On ne peut pas laisser le sprint vide parce que quelques stories ne sont pas prêtes.\"",{"type":30,"tag":38,"props":2846,"children":2847},{},[2848],{"type":36,"value":2849},"Cette pression est compréhensible. Elle est aussi exactement ce qui crée les bugs. \"On verra en cours de sprint\" : c'est le moment où l'ambiguïté devient un bug de production.",{"type":30,"tag":38,"props":2851,"children":2852},{},[2853],{"type":36,"value":2854},"Si le sprint n'a pas assez de stories \"DoR-validées\" pour remplir la capacité de l'équipe, deux options valables :",{"type":30,"tag":2409,"props":2856,"children":2857},{},[2858,2870],{"type":30,"tag":276,"props":2859,"children":2860},{},[2861,2863,2868],{"type":36,"value":2862},"Utiliser la capacité pour des stories techniques (refactoring, réduction de dette technique) qui n'ont pas besoin de spécification fonctionnelle (elles se trouvent dans un ",{"type":30,"tag":207,"props":2864,"children":2865},{"href":209},[2866],{"type":36,"value":2867},"backlog craft bien entretenu",{"type":36,"value":2869},")",{"type":30,"tag":276,"props":2871,"children":2872},{},[2873],{"type":36,"value":2874},"Réduire le périmètre du sprint plutôt que d'accepter des stories non-prêtes",{"type":30,"tag":38,"props":2876,"children":2877},{},[2878],{"type":36,"value":2879},"Un accord d'équipe sur cette règle doit être établi dès l'introduction de la DoR, idéalement en rétro, avec le soutien du Tech Lead et du PO.",{"type":30,"tag":64,"props":2881,"children":2882},{},[],{"type":30,"tag":68,"props":2884,"children":2886},{"id":2885},"les-métriques-qui-mesurent-limpact",[2887],{"type":36,"value":2888},"Les métriques qui mesurent l'impact",{"type":30,"tag":38,"props":2890,"children":2891},{},[2892],{"type":36,"value":2893},"Deux métriques permettent de mesurer l'impact de la DoR sur la durée.",{"type":30,"tag":38,"props":2895,"children":2896},{},[2897,2902],{"type":30,"tag":83,"props":2898,"children":2899},{},[2900],{"type":36,"value":2901},"Taux de stories refusées au sprint planning",{"type":36,"value":2903}," : nombre de stories exclues parce qu'elles ne passaient pas la DoR, divisé par le nombre total de stories candidates. Objectif : descendre à moins de 10% après 3 mois. Un taux élevé révèle un problème en amont dans le processus d'affinage, pas dans la DoR elle-même.",{"type":30,"tag":38,"props":2905,"children":2906},{},[2907,2912],{"type":30,"tag":83,"props":2908,"children":2909},{},[2910],{"type":36,"value":2911},"Taux d'acceptation des stories en fin de sprint",{"type":36,"value":2913}," : nombre de stories acceptées par le PO, divisé par le nombre de stories engagées. Objectif : dépasser 90%. Ce taux augmente significativement dans les 6 à 8 premières semaines après introduction de la DoR quand le processus est bien suivi.",{"type":30,"tag":64,"props":2915,"children":2916},{},[],{"type":30,"tag":68,"props":2918,"children":2920},{"id":2919},"faq-sur-la-definition-of-ready",[2921],{"type":36,"value":2922},"FAQ sur la Definition of Ready",{"type":30,"tag":402,"props":2924,"children":2925},{},[2926,2931],{"type":30,"tag":406,"props":2927,"children":2928},{},[2929],{"type":36,"value":2930},"1. Quelle est la différence entre la DoR et la Definition of Done ?",{"type":30,"tag":38,"props":2932,"children":2933},{},[2934,2936,2941],{"type":36,"value":2935},"La DoR est un critère d'entrée en sprint : elle définit ce qu'une story doit contenir pour être développable. La ",{"type":30,"tag":207,"props":2937,"children":2938},{"href":1154},[2939],{"type":36,"value":2940},"DoD",{"type":36,"value":2942}," est un critère de sortie de sprint : elle définit ce que le code doit respecter pour être considéré terminé. Les deux sont nécessaires et complémentaires. Une DoR sans DoD produit des stories bien spécifiées mais mal développées. Une DoD sans DoR produit du bon code sur de mauvaises spécifications.",{"type":30,"tag":402,"props":2944,"children":2945},{},[2946,2951],{"type":30,"tag":406,"props":2947,"children":2948},{},[2949],{"type":36,"value":2950},"2. La DoR s'applique-t-elle aussi aux stories techniques (refactoring, infrastructure) ?",{"type":30,"tag":38,"props":2952,"children":2953},{},[2954],{"type":36,"value":2955},"Oui, avec des critères adaptés. Pour une story technique, les critères d'acceptation sont remplacés par des critères de succès mesurables : \"la couverture de tests du module X passe de 30% à 60%\", \"le build time est réduit de 8 min à 4 min\". L'objectif business est remplacé par l'impact technique quantifié. L'importance de la DoR est la même : une story technique ambiguë produit du travail mal orienté.",{"type":30,"tag":402,"props":2957,"children":2958},{},[2959,2964],{"type":30,"tag":406,"props":2960,"children":2961},{},[2962],{"type":36,"value":2963},"3. Que faire si le PO résiste à rédiger des critères d'acceptation détaillés ?",{"type":30,"tag":38,"props":2965,"children":2966},{},[2967],{"type":36,"value":2968},"Montrer le coût avec un exemple concret du sprint précédent. \"Cette story a nécessité 3 aller-retours avec toi en cours de sprint parce que le comportement attendu n'était pas spécifié. Chaque aller-retour a coûté 2h au développeur et 1h à toi. Rédiger des critères d'acceptation en affinage prend 15 minutes, et évite 9 heures de friction.\" Le chiffre parle mieux que l'argument de principe.",{"type":30,"tag":402,"props":2970,"children":2971},{},[2972,2977],{"type":30,"tag":406,"props":2973,"children":2974},{},[2975],{"type":36,"value":2976},"4. Comment combiner DoR et agilité dans un contexte de startup avec des requirements qui changent vite ?",{"type":30,"tag":38,"props":2978,"children":2979},{},[2980],{"type":36,"value":2981},"La DoR n'est pas incompatible avec l'agilité rapide : elle est compatible avec une agilité mature. Une startup en phase de discovery peut avoir une DoR allégée : le critère 2 est \"au moins 1 scénario défini\" au lieu de 3. L'essentiel est que l'équipe ne parte pas développer sans une compréhension partagée du \"quoi\" et du \"pourquoi\". Le reste peut rester flexible.",{"type":30,"tag":402,"props":2983,"children":2984},{},[2985,2990],{"type":30,"tag":406,"props":2986,"children":2987},{},[2988],{"type":36,"value":2989},"5. Quelle est la taille idéale d'une DoR ?",{"type":30,"tag":38,"props":2991,"children":2992},{},[2993],{"type":36,"value":2994},"Commencer avec 5 critères. Observer l'impact pendant 2 mois, puis ajouter des critères si des problèmes spécifiques persistent. J'ai vu des équipes créer des DoR de 15 critères qui rendaient chaque story impossible à préparer en moins de 2 heures. Une DoR trop longue devient une barrière bureaucratique, l'inverse du but recherché.",{"type":30,"tag":64,"props":2996,"children":2997},{},[],{"type":30,"tag":225,"props":2999,"children":3000},{"cta":473,"href":474,"title":475,"type":476},[3001],{"type":30,"tag":38,"props":3002,"children":3003},{},[3004],{"type":36,"value":3005},"Le framework complet pour réduire votre lead time de moitié en 90 jours, incluant une section dédiée à l'optimisation du processus d'affinage et à l'implémentation de la Definition of Ready avec les templates prêts à l'emploi.",{"title":8,"searchDepth":484,"depth":484,"links":3007},[3008,3009,3010,3011,3012,3013],{"id":2671,"depth":484,"text":2674},{"id":2700,"depth":484,"text":2703},{"id":2778,"depth":484,"text":2781},{"id":2836,"depth":484,"text":2839},{"id":2885,"depth":484,"text":2888},{"id":2919,"depth":484,"text":2922},"content:fr:pratiques-agiles:definition-of-ready-bugs-sprint.md","fr/pratiques-agiles/definition-of-ready-bugs-sprint.md","fr/pratiques-agiles/definition-of-ready-bugs-sprint",{"_path":218,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":3018,"description":3019,"id":484,"date":3020,"listed":13,"nocomments":7,"hidden":7,"categories":3021,"tags":3022,"--cover":3025,"readingTime":3026,"body":3030,"_type":492,"_id":3370,"_source":494,"_file":3371,"_stem":3372,"_extension":497},"Pourquoi votre sprint planning échoue (et comment le corriger)","Un sprint planning de 4h qui finit en négociation sur les story points n'est pas un sprint planning. Les 4 erreurs structurelles et comment les corriger.","2026-01-07",[6],[3023,3024,2252],"Sprint Planning","Scrum","covers/articles/sprint-planning-efficace.jpg",{"text":2256,"minutes":3027,"time":3028,"words":3029},6.63,397800,1326,{"type":27,"children":3031,"toc":3363},[3032,3037,3042,3047,3059,3064,3067,3073,3078,3088,3098,3108,3118,3123,3126,3132,3137,3142,3152,3163,3168,3177,3180,3186,3191,3208,3225,3235,3245,3250,3253,3259,3264,3269,3278,3281,3287,3300,3313,3326,3339,3352,3355],{"type":30,"tag":31,"props":3033,"children":3035},{"id":3034},"pourquoi-votre-sprint-planning-échoue-et-comment-le-corriger",[3036],{"type":36,"value":3018},{"type":30,"tag":38,"props":3038,"children":3039},{},[3040],{"type":36,"value":3041},"J'ai assisté à un sprint planning qui a duré 5h30. Cinq heures et demie. À la fin, l'équipe avait sélectionné des stories, débattu des estimations, et produit une liste. Elle n'avait aucun engagement collectif sur ce qu'elle allait livrer. Le lendemain, le sprint a commencé exactement comme le précédent : dans la confusion.",{"type":30,"tag":38,"props":3043,"children":3044},{},[3045],{"type":36,"value":3046},"Ce n'était pas une exception. C'était la norme.",{"type":30,"tag":38,"props":3048,"children":3049},{},[3050,3052,3057],{"type":36,"value":3051},"Quand je demande aux équipes que j'accompagne : \"Sortez-vous du sprint planning avec un engagement clair ?\" La réponse honnête est presque toujours non. Il y a un backlog sélectionné, une vélocité estimée, une liste de stories, mais pas un engagement. Un ",{"type":30,"tag":207,"props":3053,"children":3054},{"href":5},[3055],{"type":36,"value":3056},"lead time",{"type":36,"value":3058}," élevé est souvent la conséquence directe d'un sprint planning qui empile trop de sujets. La nuance est cruciale, et c'est elle qui fait la différence entre une équipe qui tient ses sprints et une équipe qui subit ses sprints.",{"type":30,"tag":38,"props":3060,"children":3061},{},[3062],{"type":36,"value":3063},"Voici les 4 erreurs structurelles que je vois se répéter, et les corrections qui fonctionnent terrain.",{"type":30,"tag":64,"props":3065,"children":3066},{},[],{"type":30,"tag":68,"props":3068,"children":3070},{"id":3069},"les-4-symptômes-dun-sprint-planning-dysfonctionnel",[3071],{"type":36,"value":3072},"Les 4 symptômes d'un sprint planning dysfonctionnel",{"type":30,"tag":38,"props":3074,"children":3075},{},[3076],{"type":36,"value":3077},"Le sprint planning révèle l'état de santé d'un système de delivery bien avant que les vrais problèmes remontent. Si votre planning souffre d'au moins deux des symptômes ci-dessous, vous avez un problème structurel, pas un problème de personnes.",{"type":30,"tag":38,"props":3079,"children":3080},{},[3081,3086],{"type":30,"tag":83,"props":3082,"children":3083},{},[3084],{"type":36,"value":3085},"Symptôme 1 : La durée dépasse 2 heures pour un sprint de 2 semaines.",{"type":36,"value":3087}," La règle Scrum est explicite : 2 heures maximum par semaine de sprint. Au-delà, la réunion n'est plus un planning, c'est une session de découverte en retard.",{"type":30,"tag":38,"props":3089,"children":3090},{},[3091,3096],{"type":30,"tag":83,"props":3092,"children":3093},{},[3094],{"type":36,"value":3095},"Symptôme 2 : Les discussions portent sur l'estimation, pas sur la compréhension.",{"type":36,"value":3097}," J'ai vu des équipes passer 40 minutes à se battre sur \"est-ce 5 ou 8 points ?\" sur une story que personne n'avait vraiment lue. Le problème n'était pas l'estimation, c'était l'ambiguïté de la story.",{"type":30,"tag":38,"props":3099,"children":3100},{},[3101,3106],{"type":30,"tag":83,"props":3102,"children":3103},{},[3104],{"type":36,"value":3105},"Symptôme 3 : Des stories entrent en sprint sans critères d'acceptation.",{"type":36,"value":3107}," Ces stories généreront soit des bugs, soit le classique \"ce n'est pas ce que je voulais\" en fin de sprint. J'estime que 60% des bugs de sprint trouvent leur origine ici.",{"type":30,"tag":38,"props":3109,"children":3110},{},[3111,3116],{"type":30,"tag":83,"props":3112,"children":3113},{},[3114],{"type":36,"value":3115},"Symptôme 4 : Le scope change pendant le sprint.",{"type":36,"value":3117}," Si le planning ne génère pas un périmètre stable, l'équipe replanifie en continu. Le sprint devient un Kanban déguisé, et personne n'ose le dire.",{"type":30,"tag":38,"props":3119,"children":3120},{},[3121],{"type":36,"value":3122},"Dans une grande banque où j'intervenais, l'équipe avait un planning hebdomadaire de 3 heures parce que le backlog arrivait non-priorisé et les stories sans critères d'acceptation. Le PO et les développeurs passaient le planning à découvrir ensemble ce qu'il fallait faire. C'est le symptôme le plus coûteux : les clarifications qui auraient dû prendre 2 jours en amont prennent 3 heures en salle, avec toute l'équipe mobilisée.",{"type":30,"tag":64,"props":3124,"children":3125},{},[],{"type":30,"tag":68,"props":3127,"children":3129},{"id":3128},"la-cause-racine-les-stories-non-affinées",[3130],{"type":36,"value":3131},"La cause racine : les stories non-affinées",{"type":30,"tag":38,"props":3133,"children":3134},{},[3135],{"type":36,"value":3136},"La cause racine de 80% des sprint plannings qui échouent est simple : les stories arrivent en sprint planning sans avoir été affinées.",{"type":30,"tag":38,"props":3138,"children":3139},{},[3140],{"type":36,"value":3141},"L'équipe découvre le périmètre, les questions, et les ambiguïtés pendant le planning, au lieu de les avoir résolues pendant les sessions d'affinage (refinement). L'équipe passe son planning à faire de l'affinage en urgence. C'est inefficace structurellement.",{"type":30,"tag":38,"props":3143,"children":3144},{},[3145,3150],{"type":30,"tag":83,"props":3146,"children":3147},{},[3148],{"type":36,"value":3149},"La correction",{"type":36,"value":3151}," : des sessions d'affinage dédiées, 2 fois par semaine, 45 minutes, obligatoires pour les stories candidates au prochain sprint.",{"type":30,"tag":38,"props":3153,"children":3154},{},[3155,3157,3161],{"type":36,"value":3156},"Une story ne peut pas entrer en sprint planning si elle n'a pas passé au moins une session d'affinage. C'est le principe de la ",{"type":30,"tag":207,"props":3158,"children":3159},{"href":2135},[3160],{"type":36,"value":2138},{"type":36,"value":3162},". Le PO présente, l'équipe pose ses questions, les critères d'acceptation sont rédigés en commun. Le sprint planning n'est plus une découverte : c'est une confirmation.",{"type":30,"tag":38,"props":3164,"children":3165},{},[3166],{"type":36,"value":3167},"Résultat attendu : 100% des stories du prochain sprint planning ont été affinées au préalable. Le planning peut alors se tenir en 90 minutes au lieu de 4 heures.",{"type":30,"tag":225,"props":3169,"children":3171},{"cta":227,"href":228,"title":3170,"type":230},"Votre sprint planning est long, tendu, et les sprints finissent rarement comme prévu ?",[3172],{"type":30,"tag":38,"props":3173,"children":3174},{},[3175],{"type":36,"value":3176},"Un sprint planning dysfonctionnel est souvent le symptôme d'un problème de fond : Definition of Ready absente, backlog mal priorisé, ou tension PO/équipe non résolue. En 30 minutes d'appel, je peux identifier la vraie cause et vous donner le plan de correction concret.",{"type":30,"tag":64,"props":3178,"children":3179},{},[],{"type":30,"tag":68,"props":3181,"children":3183},{"id":3182},"le-format-en-4-blocs-qui-tient-en-3-heures",[3184],{"type":36,"value":3185},"Le format en 4 blocs qui tient en 3 heures",{"type":30,"tag":38,"props":3187,"children":3188},{},[3189],{"type":36,"value":3190},"Restructurer le sprint planning en 4 blocs de 45 minutes change radicalement la dynamique. Ce format s'appuie sur les principes Scrum mais introduit une discipline que peu d'équipes appliquent réellement.",{"type":30,"tag":38,"props":3192,"children":3193},{},[3194,3199,3201,3206],{"type":30,"tag":83,"props":3195,"children":3196},{},[3197],{"type":36,"value":3198},"Bloc 1 (45 min) : Contexte et objectif du sprint.",{"type":36,"value":3200}," Le PO présente l'objectif business, pas les stories, l'objectif. L'équipe confirme sa compréhension. Jeff Sutherland, co-créateur de Scrum, insiste sur ce point dans ",{"type":30,"tag":2453,"props":3202,"children":3203},{},[3204],{"type":36,"value":3205},"Scrum: The Art of Doing Twice the Work in Half the Time",{"type":36,"value":3207}," : un sprint sans objectif clair n'a pas de critère de succès. Sans cet objectif, l'équipe livrera des features mais pas nécessairement de la valeur.",{"type":30,"tag":38,"props":3209,"children":3210},{},[3211,3216,3218,3223],{"type":30,"tag":83,"props":3212,"children":3213},{},[3214],{"type":36,"value":3215},"Bloc 2 (45 min) : Sélection des stories.",{"type":36,"value":3217}," L'équipe sélectionne les stories affinées qui atteignent l'objectif. La sélection est basée sur la vélocité historique des 3 derniers sprints, pas sur un engagement héroïque. Les stories non-affinées sont exclues sans discussion : cette règle est non-négociable. Un ",{"type":30,"tag":207,"props":3219,"children":3220},{"href":209},[3221],{"type":36,"value":3222},"backlog mal entretenu",{"type":36,"value":3224}," est la cause principale d'un planning qui dérive.",{"type":30,"tag":38,"props":3226,"children":3227},{},[3228,3233],{"type":30,"tag":83,"props":3229,"children":3230},{},[3231],{"type":36,"value":3232},"Bloc 3 (45 min) : Découpage en tâches.",{"type":36,"value":3234}," Pour les stories sélectionnées, l'équipe identifie les tâches concrètes de développement. Pas d'estimation de story points à cette étape : des tâches de 2 à 8 heures max. Ce découpage révèle les dépendances et les zones d'incertitude que l'estimation abstraite ne capturait pas.",{"type":30,"tag":38,"props":3236,"children":3237},{},[3238,3243],{"type":30,"tag":83,"props":3239,"children":3240},{},[3241],{"type":36,"value":3242},"Bloc 4 (45 min) : Vérification de capacité et engagement.",{"type":36,"value":3244}," L'équipe additionne les tâches et vérifie que la charge est cohérente avec la capacité disponible (congés, réunions, support). L'engagement est collectif et réaliste, pas une promesse individuelle sous pression.",{"type":30,"tag":38,"props":3246,"children":3247},{},[3248],{"type":36,"value":3249},"Résultat : un planning de 3 heures maximum, un backlog de sprint réaliste, et un engagement que l'équipe peut tenir.",{"type":30,"tag":64,"props":3251,"children":3252},{},[],{"type":30,"tag":68,"props":3254,"children":3256},{"id":3255},"ce-que-ça-change-économiquement",[3257],{"type":36,"value":3258},"Ce que ça change économiquement",{"type":30,"tag":38,"props":3260,"children":3261},{},[3262],{"type":36,"value":3263},"Un sprint planning de 5 heures avec une équipe de 7 personnes, c'est 35 heures-personne. Multiplié par 26 sprints par an, c'est 910 heures de coût annuel, pour un rituel qui devrait prendre 3 heures. La différence : 520 heures-personne libérées par an.",{"type":30,"tag":38,"props":3265,"children":3266},{},[3267],{"type":36,"value":3268},"Ce n'était jamais un problème de personnes. C'était un problème de système. Quand les stories arrivent affinées, le planning se tient dans le temps prévu. Quand l'objectif de sprint est clair, l'équipe s'engage sur de la valeur, pas sur une liste de tâches.",{"type":30,"tag":3270,"props":3271,"children":3272},"blockquote",{},[3273],{"type":30,"tag":38,"props":3274,"children":3275},{},[3276],{"type":36,"value":3277},"Un sprint sans objectif clair est une liste de tâches déguisée en engagement. La différence entre les deux se mesure en fin de sprint : avez-vous livré des features, ou avez-vous livré de la valeur ?",{"type":30,"tag":64,"props":3279,"children":3280},{},[],{"type":30,"tag":68,"props":3282,"children":3284},{"id":3283},"faq-sur-le-sprint-planning",[3285],{"type":36,"value":3286},"FAQ sur le sprint planning",{"type":30,"tag":402,"props":3288,"children":3289},{},[3290,3295],{"type":30,"tag":406,"props":3291,"children":3292},{},[3293],{"type":36,"value":3294},"1. Quelle est la durée idéale d'un sprint planning pour une équipe de 8 personnes ?",{"type":30,"tag":38,"props":3296,"children":3297},{},[3298],{"type":36,"value":3299},"Pour un sprint de 2 semaines avec une équipe de 8 personnes, le sprint planning ne devrait pas dépasser 3 heures si les stories sont correctement affinées. La règle Scrum est de 2 heures par semaine de sprint, soit 4 heures maximum. Si vous dépassez régulièrement 4 heures, le problème est structurel : stories non-affinées ou absence de Definition of Ready.",{"type":30,"tag":402,"props":3301,"children":3302},{},[3303,3308],{"type":30,"tag":406,"props":3304,"children":3305},{},[3306],{"type":36,"value":3307},"2. Doit-on estimer toutes les stories en sprint planning ?",{"type":30,"tag":38,"props":3309,"children":3310},{},[3311],{"type":36,"value":3312},"Non. L'estimation en sprint planning devrait être une validation rapide (2-3 minutes par story), pas une estimation initiale. Si une story n'a pas été estimée en affinage, elle n'est pas prête pour le sprint planning. L'estimation détaillée a sa place en affinage, pas en planning.",{"type":30,"tag":402,"props":3314,"children":3315},{},[3316,3321],{"type":30,"tag":406,"props":3317,"children":3318},{},[3319],{"type":36,"value":3320},"3. Que faire si le PO arrive au planning avec un backlog non-priorisé ?",{"type":30,"tag":38,"props":3322,"children":3323},{},[3324],{"type":36,"value":3325},"C'est un symptôme d'un problème de rôle, pas de planning. Le PO est responsable d'avoir un backlog priorisé avant le planning. Si ce n'est pas le cas, annuler le sprint planning et planifier une session de priorisation d'abord. Faire le planning sans backlog priorisé garantit un sprint chaotique, je l'ai vu confirmer dans toutes les équipes où je suis intervenu.",{"type":30,"tag":402,"props":3327,"children":3328},{},[3329,3334],{"type":30,"tag":406,"props":3330,"children":3331},{},[3332],{"type":36,"value":3333},"4. Comment gérer les dépendances entre équipes dans le sprint planning ?",{"type":30,"tag":38,"props":3335,"children":3336},{},[3337],{"type":36,"value":3338},"Les dépendances doivent être identifiées en affinage, pas découvertes en sprint planning. Pour les dépendances connues, les représentants des équipes concernées sont invités à la session d'affinage concernée. En sprint planning, les dépendances non-résolues sont des blockers qui empêchent la story d'entrer en sprint, même si le PO insiste.",{"type":30,"tag":402,"props":3340,"children":3341},{},[3342,3347],{"type":30,"tag":406,"props":3343,"children":3344},{},[3345],{"type":36,"value":3346},"5. Supprimer les story points résout-il les problèmes de sprint planning ?",{"type":30,"tag":38,"props":3348,"children":3349},{},[3350],{"type":36,"value":3351},"Non. Des stories bien affinées s'estiment en 2 minutes quelle que soit la méthode. Des stories mal définies génèrent 30 minutes de débat même avec le sizing T-shirt. Le problème n'est pas l'outil d'estimation : c'est la qualité de l'affinage en amont.",{"type":30,"tag":64,"props":3353,"children":3354},{},[],{"type":30,"tag":225,"props":3356,"children":3357},{"cta":473,"href":474,"title":475,"type":476},[3358],{"type":30,"tag":38,"props":3359,"children":3360},{},[3361],{"type":36,"value":3362},"Le framework complet pour réduire votre lead time de moitié en 90 jours : diagnostic initial, leviers d'action priorisés, et plan de mise en œuvre semaine par semaine. Inclut une section dédiée à l'optimisation du sprint planning et du processus d'affinage.",{"title":8,"searchDepth":484,"depth":484,"links":3364},[3365,3366,3367,3368,3369],{"id":3069,"depth":484,"text":3072},{"id":3128,"depth":484,"text":3131},{"id":3182,"depth":484,"text":3185},{"id":3255,"depth":484,"text":3258},{"id":3283,"depth":484,"text":3286},"content:fr:pratiques-agiles:sprint-planning-efficace.md","fr/pratiques-agiles/sprint-planning-efficace.md","fr/pratiques-agiles/sprint-planning-efficace",1775679735685]