[{"data":1,"prerenderedAt":1415},["ShallowReactive",2],{"search-api":-1,"listing-tag-Agile-page-1":3},[4,669,1056],{"_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":19,"readingTime":20,"body":25,"_type":663,"_id":664,"_source":665,"_file":666,"_stem":667,"_extension":668},"/fr/dette-technique/definition-of-done-qualite","dette-technique",false,"","Définir une Definition of Done qui améliore vraiment la qualité","Une DoD vague produit une qualité vague. Comment construire une Definition of Done qui tient ses promesses et s'améliore dans le temps.",26,"2026-03-04",true,[6],[16,17,18],"Definition of Done","Qualité","Agile","covers/articles/definition-of-done-qualite.jpg",{"text":21,"minutes":22,"time":23,"words":24},"8 min read",7.46,447600,1492,{"type":26,"children":27,"toc":652},"root",[28,36,42,51,56,60,67,87,90,96,113,118,128,146,151,161,164,170,185,190,200,210,229,239,249,259,269,278,281,294,297,303,308,318,328,338,348,357,360,366,371,381,399,412,421,424,430,439,442,448,553,556,562,577,590,611,624,637,640],{"type":29,"tag":30,"props":31,"children":33},"element","h1",{"id":32},"définir-une-definition-of-done-qui-améliore-vraiment-la-qualité",[34],{"type":35,"value":9},"text",{"type":29,"tag":37,"props":38,"children":39},"p",{},[40],{"type":35,"value":41},"Je me souviens d'une équipe dans une grande organisation de retraite complémentaire. Ils avaient une DoD, une vraie, écrite, affichée dans la salle. Je leur ai demandé comment elle était utilisée. Le Scrum Master a répondu avec un sourire gêné : \"En théorie, elle est vérifiée avant chaque merge. En pratique, en fin de sprint, on coche tout et on merge pour tenir le sprint.\" J'ai vérifié les métriques : 38% des bugs de prod de l'année précédente étaient apparus dans des stories \"Done\" selon la DoD de l'équipe. Ce n'était pas un problème de personnes. C'était un problème de contrat.",{"type":29,"tag":37,"props":43,"children":44},{},[45],{"type":29,"tag":46,"props":47,"children":48},"strong",{},[49],{"type":35,"value":50},"La DoD la plus fréquente que je rencontre dans les équipes : \"Le code est mergé et testé.\" C'est une description, pas une Definition of Done. Et cette ambiguïté est directement responsable de 30 à 40% des bugs qui atteignent la production.",{"type":29,"tag":37,"props":52,"children":53},{},[54],{"type":35,"value":55},"La Definition of Done est le contrat de qualité de l'équipe. Quand elle est vague, chaque développeur l'interprète différemment. Quand elle est absente, la qualité dépend de la conscience professionnelle individuelle, ce qui est insuffisant pour garantir la cohérence.",{"type":29,"tag":57,"props":58,"children":59},"hr",{},[],{"type":29,"tag":61,"props":62,"children":64},"h2",{"id":63},"avant-de-commencer-les-prérequis",[65],{"type":35,"value":66},"Avant de commencer : les prérequis",{"type":29,"tag":68,"props":69,"children":70},"ul",{},[71,77,82],{"type":29,"tag":72,"props":73,"children":74},"li",{},[75],{"type":35,"value":76},"L'équipe a déjà une DoD existante (même minimale ou informelle) à partir de laquelle progresser",{"type":29,"tag":72,"props":78,"children":79},{},[80],{"type":35,"value":81},"Le Product Owner et le Tech Lead sont impliqués dans la redéfinition",{"type":29,"tag":72,"props":83,"children":84},{},[85],{"type":35,"value":86},"L'équipe a accès aux métriques de base : taux de bugs de prod, lead time, incidents récents",{"type":29,"tag":57,"props":88,"children":89},{},[],{"type":29,"tag":61,"props":91,"children":93},{"id":92},"étape-1-auditer-la-dod-actuelle-ou-son-absence",[94],{"type":35,"value":95},"Étape 1 : Auditer la DoD actuelle (ou son absence)",{"type":29,"tag":37,"props":97,"children":98},{},[99,104,106,111],{"type":29,"tag":46,"props":100,"children":101},{},[102],{"type":35,"value":103},"Durée estimée",{"type":35,"value":105}," : 2 heures en atelier équipe\n",{"type":29,"tag":46,"props":107,"children":108},{},[109],{"type":35,"value":110},"Qui",{"type":35,"value":112}," : Toute l'équipe de développement + PO + Scrum Master",{"type":29,"tag":37,"props":114,"children":115},{},[116],{"type":35,"value":117},"Avant de construire une nouvelle DoD, comprendre pourquoi l'actuelle ne fonctionne pas.",{"type":29,"tag":37,"props":119,"children":120},{},[121,126],{"type":29,"tag":46,"props":122,"children":123},{},[124],{"type":35,"value":125},"Questions à poser en atelier",{"type":35,"value":127}," :",{"type":29,"tag":68,"props":129,"children":130},{},[131,136,141],{"type":29,"tag":72,"props":132,"children":133},{},[134],{"type":35,"value":135},"\"Quand considérez-vous qu'une story est vraiment terminée ?\" Recueillir les réponses individuelles avant la discussion.",{"type":29,"tag":72,"props":137,"children":138},{},[139],{"type":35,"value":140},"\"Citez un bug récent de prod : quelle étape de la DoD aurait dû le détecter ?\"",{"type":29,"tag":72,"props":142,"children":143},{},[144],{"type":35,"value":145},"\"Y a-t-il des items de notre DoD actuelle que personne ne vérifie vraiment ?\"",{"type":29,"tag":37,"props":147,"children":148},{},[149],{"type":35,"value":150},"Le dernier exercice est le plus révélateur. Dans 80% des équipes que j'accompagne, il existe des items \"fantômes\" dans la DoD : des critères formellement présents mais systématiquement contournés, généralement par manque de temps en fin de sprint.",{"type":29,"tag":37,"props":152,"children":153},{},[154,159],{"type":29,"tag":46,"props":155,"children":156},{},[157],{"type":35,"value":158},"Résultat attendu",{"type":35,"value":160}," : une liste de ce qui fonctionne, ce qui est contourné, et ce qui manque.",{"type":29,"tag":57,"props":162,"children":163},{},[],{"type":29,"tag":61,"props":165,"children":167},{"id":166},"étape-2-les-7-critères-non-négociables-dune-dod-solide",[168],{"type":35,"value":169},"Étape 2 : Les 7 critères non-négociables d'une DoD solide",{"type":29,"tag":37,"props":171,"children":172},{},[173,177,179,183],{"type":29,"tag":46,"props":174,"children":175},{},[176],{"type":35,"value":103},{"type":35,"value":178}," : 1 heure de discussion\n",{"type":29,"tag":46,"props":180,"children":181},{},[182],{"type":35,"value":110},{"type":35,"value":184}," : Tech Lead + PO",{"type":29,"tag":37,"props":186,"children":187},{},[188],{"type":35,"value":189},"Ces 7 critères sont le minimum pour une DoD qui protège réellement la qualité. Adaptez le wording à votre contexte, mais ne supprimez pas les catégories.",{"type":29,"tag":37,"props":191,"children":192},{},[193,198],{"type":29,"tag":46,"props":194,"children":195},{},[196],{"type":35,"value":197},"1. Code reviewé par au moins un pair",{"type":35,"value":199},"\nPas \"par le Tech Lead si disponible\". Par n'importe quel pair, avec un retour documenté dans la PR. Spécifier le délai maximum : aucune PR ne reste sans review plus de 24 heures ouvrées.",{"type":29,"tag":37,"props":201,"children":202},{},[203,208],{"type":29,"tag":46,"props":204,"children":205},{},[206],{"type":35,"value":207},"2. Tests automatisés écrits ou mis à jour",{"type":35,"value":209},"\nSpécifier le type : tests unitaires pour la logique, tests d'intégration pour les interactions avec les dépendances. Spécifier le seuil : la couverture du module ne descend pas en dessous du seuil de l'équipe.",{"type":29,"tag":37,"props":211,"children":212},{},[213,227],{"type":29,"tag":46,"props":214,"children":215},{},[216,218,225],{"type":35,"value":217},"3. ",{"type":29,"tag":219,"props":220,"children":222},"a",{"href":221},"/fr/pratiques-agiles/continuous-integration-fondamentaux",[223],{"type":35,"value":224},"Build CI",{"type":35,"value":226}," vert sur la branche",{"type":35,"value":228},"\nÉvident mais souvent contourné \"pour gagner du temps\". Un build rouge = story non terminée, sans exception.",{"type":29,"tag":37,"props":230,"children":231},{},[232,237],{"type":29,"tag":46,"props":233,"children":234},{},[235],{"type":35,"value":236},"4. Critères d'acceptation vérifiés et documentés",{"type":35,"value":238},"\nChaque critère d'acceptation de la story doit avoir été testé manuellement ou automatiquement. Le résultat est documenté dans le ticket.",{"type":29,"tag":37,"props":240,"children":241},{},[242,247],{"type":29,"tag":46,"props":243,"children":244},{},[245],{"type":35,"value":246},"5. Pas de régression identifiée sur les scénarios existants",{"type":35,"value":248},"\nUne suite de tests de régression tourne sur chaque PR. Si elle n'existe pas, c'est un déficit à combler progressivement, mais c'est un objectif de la DoD.",{"type":29,"tag":37,"props":250,"children":251},{},[252,257],{"type":29,"tag":46,"props":253,"children":254},{},[255],{"type":35,"value":256},"6. Documentation mise à jour si applicable",{"type":35,"value":258},"\nPas de documentation pour chaque story. Mais si la story modifie une API publique, un flux d'intégration, ou une règle métier documentée, la documentation est mise à jour dans la même PR.",{"type":29,"tag":37,"props":260,"children":261},{},[262,267],{"type":29,"tag":46,"props":263,"children":264},{},[265],{"type":35,"value":266},"7. Déployable en environnement de staging sans intervention manuelle",{"type":35,"value":268},"\nLa story doit pouvoir être déployée en staging en appuyant sur un bouton. Si un déploiement nécessite des étapes manuelles, c'est une dette technique à documenter et traiter.",{"type":29,"tag":37,"props":270,"children":271},{},[272,276],{"type":29,"tag":46,"props":273,"children":274},{},[275],{"type":35,"value":158},{"type":35,"value":277}," : une DoD de 7 items précis et actionnables.",{"type":29,"tag":57,"props":279,"children":280},{},[],{"type":29,"tag":282,"props":283,"children":288},"cta",{"cta":284,"href":285,"title":286,"type":287},"Réserver mon diagnostic gratuit →","https://app.kamanga.fr/forms/discovery-call","Votre équipe merge du code que tout le monde sait incomplet faute d'une DoD claire ?","call",[289],{"type":29,"tag":37,"props":290,"children":291},{},[292],{"type":35,"value":293},"Vous voyez les patterns se répéter : les bugs arrivent en prod sur des stories \"Done\", les revues de code sont expéditives en fin de sprint, et personne n'ose vraiment bloquer un merge. Ce n'est pas de la mauvaise volonté, c'est l'absence d'un contrat clair. En 30 minutes, on identifie la vraie cause et on définit une DoD réaliste et tenue.",{"type":29,"tag":57,"props":295,"children":296},{},[],{"type":29,"tag":61,"props":298,"children":300},{"id":299},"étape-3-lintégrer-dans-le-workflow-sans-friction",[301],{"type":35,"value":302},"Étape 3 : L'intégrer dans le workflow sans friction",{"type":29,"tag":37,"props":304,"children":305},{},[306],{"type":35,"value":307},"Une DoD que personne ne consulte n'existe pas. Elle doit être au bon endroit, au bon moment.",{"type":29,"tag":37,"props":309,"children":310},{},[311,316],{"type":29,"tag":46,"props":312,"children":313},{},[314],{"type":35,"value":315},"Dans Jira/Linear",{"type":35,"value":317}," : ajouter la DoD comme checklist dans le template de story. Chaque item est coché (et non supprimé) avant de passer au statut \"Done\". L'outil garde une trace.",{"type":29,"tag":37,"props":319,"children":320},{},[321,326],{"type":29,"tag":46,"props":322,"children":323},{},[324],{"type":35,"value":325},"Dans GitHub/GitLab",{"type":35,"value":327}," : créer un template de PR avec les items de la DoD comme checklist. Le développeur les coche au moment de la PR, pas après coup.",{"type":29,"tag":37,"props":329,"children":330},{},[331,336],{"type":29,"tag":46,"props":332,"children":333},{},[334],{"type":35,"value":335},"Dans le sprint review",{"type":35,"value":337}," : le PO valide que les items de la DoD ont été respectés avant d'accepter la story. C'est le moment de fermeture du cycle qualité.",{"type":29,"tag":37,"props":339,"children":340},{},[341,346],{"type":29,"tag":46,"props":342,"children":343},{},[344],{"type":35,"value":345},"L'erreur à éviter",{"type":35,"value":347}," : transformer la DoD en checklist bureaucratique que tout le monde coche sans vérifier. Pour éviter ça, j'inclus des items vérifiables de façon objective (build vert, coverage seuil) plutôt que subjectifs (\"le code est de qualité\").",{"type":29,"tag":37,"props":349,"children":350},{},[351,355],{"type":29,"tag":46,"props":352,"children":353},{},[354],{"type":35,"value":158},{"type":35,"value":356}," : la DoD est intégrée dans les templates Jira et GitHub. Elle est visible au bon moment dans le workflow.",{"type":29,"tag":57,"props":358,"children":359},{},[],{"type":29,"tag":61,"props":361,"children":363},{"id":362},"étape-4-la-faire-évoluer-chaque-trimestre",[364],{"type":35,"value":365},"Étape 4 : La faire évoluer chaque trimestre",{"type":29,"tag":37,"props":367,"children":368},{},[369],{"type":35,"value":370},"Une DoD figée devient rapidement soit trop laxiste (l'équipe a progressé et la DoD ne reflète plus ses standards actuels) soit trop contraignante (les outils ont changé et certains items ne s'appliquent plus).",{"type":29,"tag":37,"props":372,"children":373},{},[374,379],{"type":29,"tag":46,"props":375,"children":376},{},[377],{"type":35,"value":378},"Rituel recommandé",{"type":35,"value":380}," : une session de 1 heure par trimestre, en même temps que le trimestrial planning, pour réviser la DoD :",{"type":29,"tag":68,"props":382,"children":383},{},[384,389,394],{"type":29,"tag":72,"props":385,"children":386},{},[387],{"type":35,"value":388},"Quels items sont systématiquement respectés ? (→ potentiellement automatisables dans la CI)",{"type":29,"tag":72,"props":390,"children":391},{},[392],{"type":35,"value":393},"Quels items sont régulièrement contournés ? (→ soit les supprimer, soit identifier pourquoi et lever le blocage)",{"type":29,"tag":72,"props":395,"children":396},{},[397],{"type":35,"value":398},"Quels items manquent compte tenu des problèmes rencontrés ce trimestre ?",{"type":29,"tag":37,"props":400,"children":401},{},[402,404,410],{"type":35,"value":403},"L'objectif à 12-18 mois : une DoD qui contient des items d'un ",{"type":29,"tag":219,"props":405,"children":407},{"href":406},"/fr/dette-technique/introduction-maturite-engineering-5-niveaux",[408],{"type":35,"value":409},"niveau 3 de maturité engineering",{"type":35,"value":411}," : les standards de qualité sont ancrés dans les pratiques de l'équipe, pas seulement dans un document.",{"type":29,"tag":37,"props":413,"children":414},{},[415,419],{"type":29,"tag":46,"props":416,"children":417},{},[418],{"type":35,"value":158},{"type":35,"value":420}," : une DoD vivante, révisée trimestriellement, qui progresse avec le niveau de maturité de l'équipe.",{"type":29,"tag":57,"props":422,"children":423},{},[],{"type":29,"tag":61,"props":425,"children":427},{"id":426},"le-piège-à-éviter",[428],{"type":35,"value":429},"Le piège à éviter",{"type":29,"tag":431,"props":432,"children":433},"blockquote",{},[434],{"type":29,"tag":37,"props":435,"children":436},{},[437],{"type":35,"value":438},"Ne jamais créer deux niveaux de DoD \"selon le temps disponible\". J'ai vu des équipes définir une \"DoD normale\" et une \"DoD express\" pour les sprints surchargés. Résultat : la DoD express devient la norme, et la DoD normale n'est jamais appliquée. Une seule DoD : si elle n'est pas atteignable, réduire le scope du sprint, pas les standards. C'est la discipline fondamentale d'un système agile sain.",{"type":29,"tag":57,"props":440,"children":441},{},[],{"type":29,"tag":61,"props":443,"children":445},{"id":444},"en-résumé",[446],{"type":35,"value":447},"En résumé",{"type":29,"tag":449,"props":450,"children":451},"table",{},[452,476],{"type":29,"tag":453,"props":454,"children":455},"thead",{},[456],{"type":29,"tag":457,"props":458,"children":459},"tr",{},[460,466,471],{"type":29,"tag":461,"props":462,"children":463},"th",{},[464],{"type":35,"value":465},"Étape",{"type":29,"tag":461,"props":467,"children":468},{},[469],{"type":35,"value":470},"Action",{"type":29,"tag":461,"props":472,"children":473},{},[474],{"type":35,"value":475},"Résultat",{"type":29,"tag":477,"props":478,"children":479},"tbody",{},[480,499,517,535],{"type":29,"tag":457,"props":481,"children":482},{},[483,489,494],{"type":29,"tag":484,"props":485,"children":486},"td",{},[487],{"type":35,"value":488},"1",{"type":29,"tag":484,"props":490,"children":491},{},[492],{"type":35,"value":493},"Auditer la DoD actuelle en atelier",{"type":29,"tag":484,"props":495,"children":496},{},[497],{"type":35,"value":498},"Identifier les items fantômes et les manques",{"type":29,"tag":457,"props":500,"children":501},{},[502,507,512],{"type":29,"tag":484,"props":503,"children":504},{},[505],{"type":35,"value":506},"2",{"type":29,"tag":484,"props":508,"children":509},{},[510],{"type":35,"value":511},"Définir les 7 critères non-négociables",{"type":29,"tag":484,"props":513,"children":514},{},[515],{"type":35,"value":516},"DoD précise et actionnable",{"type":29,"tag":457,"props":518,"children":519},{},[520,525,530],{"type":29,"tag":484,"props":521,"children":522},{},[523],{"type":35,"value":524},"3",{"type":29,"tag":484,"props":526,"children":527},{},[528],{"type":35,"value":529},"Intégrer dans Jira et GitHub",{"type":29,"tag":484,"props":531,"children":532},{},[533],{"type":35,"value":534},"DoD consultée au bon moment dans le workflow",{"type":29,"tag":457,"props":536,"children":537},{},[538,543,548],{"type":29,"tag":484,"props":539,"children":540},{},[541],{"type":35,"value":542},"4",{"type":29,"tag":484,"props":544,"children":545},{},[546],{"type":35,"value":547},"Réviser chaque trimestre",{"type":29,"tag":484,"props":549,"children":550},{},[551],{"type":35,"value":552},"DoD qui progresse avec la maturité de l'équipe",{"type":29,"tag":57,"props":554,"children":555},{},[],{"type":29,"tag":61,"props":557,"children":559},{"id":558},"faq-sur-la-definition-of-done",[560],{"type":35,"value":561},"FAQ sur la Definition of Done",{"type":29,"tag":563,"props":564,"children":565},"details",{},[566,572],{"type":29,"tag":567,"props":568,"children":569},"summary",{},[570],{"type":35,"value":571},"1. Quelle est la différence entre la DoD et les critères d'acceptation ?",{"type":29,"tag":37,"props":573,"children":574},{},[575],{"type":35,"value":576},"Les critères d'acceptation sont spécifiques à une story : ils décrivent ce que cette story particulière doit faire. La DoD est transversale à toutes les stories : elle décrit les standards de qualité qui s'appliquent à toute livraison, quelles que soient les fonctionnalités. Une story peut respecter tous ses critères d'acceptation et ne pas respecter la DoD (ex : pas de tests écrits, code non reviewé).",{"type":29,"tag":563,"props":578,"children":579},{},[580,585],{"type":29,"tag":567,"props":581,"children":582},{},[583],{"type":35,"value":584},"2. La DoD doit-elle être la même pour tous les types de stories ?",{"type":29,"tag":37,"props":586,"children":587},{},[588],{"type":35,"value":589},"Généralement oui, avec des nuances légères. Certains items peuvent être contextuels (la documentation n'est pas mise à jour pour une story de refactoring interne). Mais les items fondamentaux (code reviewé, build vert, tests écrits) s'appliquent à toutes les stories sans exception. Trop d'exceptions crée de l'ambiguïté et ouvre la porte aux contournements.",{"type":29,"tag":563,"props":591,"children":592},{},[593,598],{"type":29,"tag":567,"props":594,"children":595},{},[596],{"type":35,"value":597},"3. Comment gérer la résistance de l'équipe à une DoD plus stricte ?",{"type":29,"tag":37,"props":599,"children":600},{},[601,603,609],{"type":35,"value":602},"La résistance vient généralement de la peur que la DoD crée un blocage en fin de sprint. La réponse est de traiter la cause : si la DoD ne peut pas être respectée dans un sprint, le problème est en amont (stories trop grandes, ",{"type":29,"tag":219,"props":604,"children":606},{"href":605},"/fr/pratiques-agiles/definition-of-ready-bugs-sprint",[607],{"type":35,"value":608},"Definition of Ready absente",{"type":35,"value":610},", capacité surestimée) pas dans la DoD elle-même. Impliquer l'équipe dans la rédaction de la DoD réduit significativement la résistance à son application.",{"type":29,"tag":563,"props":612,"children":613},{},[614,619],{"type":29,"tag":567,"props":615,"children":616},{},[617],{"type":35,"value":618},"4. Faut-il une DoD différente par équipe dans une organisation avec plusieurs équipes ?",{"type":29,"tag":37,"props":620,"children":621},{},[622],{"type":35,"value":623},"Une base commune + des extensions par équipe est la meilleure approche. La base commune garantit un niveau minimum de qualité cohérent à travers l'organisation, particulièrement important pour les composants partagés. Les extensions permettent aux équipes d'adapter aux spécificités de leur contexte (ex : une équipe data peut avoir des items spécifiques sur la validation des schémas).",{"type":29,"tag":563,"props":625,"children":626},{},[627,632],{"type":29,"tag":567,"props":628,"children":629},{},[630],{"type":35,"value":631},"5. Comment mesurer si la DoD améliore réellement la qualité ?",{"type":29,"tag":37,"props":633,"children":634},{},[635],{"type":35,"value":636},"Trois métriques à suivre avant/après l'amélioration de la DoD : le taux de bugs de prod sur les stories \"Done\" (doit baisser), le nombre de réouvertures de tickets (doit baisser), et le temps passé en correction de bugs vs développement de features (doit s'améliorer). Sur les équipes que j'accompagne, une DoD bien appliquée réduit le taux de bugs de prod de 25 à 40% en 3 mois.",{"type":29,"tag":57,"props":638,"children":639},{},[],{"type":29,"tag":282,"props":641,"children":646},{"cta":642,"href":643,"title":644,"type":645},"Accéder à l'assessment gratuit →","/mes-ressources","Ressource gratuite : Engineering Maturity Self-Assessment","resource",[647],{"type":29,"tag":37,"props":648,"children":649},{},[650],{"type":35,"value":651},"L'assessment évalue vos pratiques de qualité, incluant la Definition of Done, les pratiques de tests et de revue de code. Identifiez votre niveau actuel et les 3 actions prioritaires pour progresser.",{"title":8,"searchDepth":653,"depth":653,"links":654},2,[655,656,657,658,659,660,661,662],{"id":63,"depth":653,"text":66},{"id":92,"depth":653,"text":95},{"id":166,"depth":653,"text":169},{"id":299,"depth":653,"text":302},{"id":362,"depth":653,"text":365},{"id":426,"depth":653,"text":429},{"id":444,"depth":653,"text":447},{"id":558,"depth":653,"text":561},"markdown","content:fr:dette-technique:definition-of-done-qualite.md","content","fr/dette-technique/definition-of-done-qualite.md","fr/dette-technique/definition-of-done-qualite","md",{"_path":670,"_dir":671,"_draft":7,"_partial":7,"_locale":8,"title":672,"description":673,"id":674,"date":675,"listed":13,"nocomments":7,"hidden":7,"categories":676,"tags":677,"--cover":680,"readingTime":681,"body":686,"_type":663,"_id":1053,"_source":665,"_file":1054,"_stem":1055,"_extension":668},"/fr/pratiques-agiles/retrospective-agile-format-efficace","pratiques-agiles","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.",12,"2026-01-30",[671],[678,18,679],"Rétrospective","Amélioration Continue","covers/articles/retrospective-agile-format.jpg",{"text":682,"minutes":683,"time":684,"words":685},"7 min read",6.465,387900,1293,{"type":26,"children":687,"toc":1047},[688,693,698,703,708,713,718,721,727,732,737,742,747,750,756,764,777,782,790,795,800,805,814,817,825,830,835,866,887,895,900,905,910,918,923,936,939,945,950,955,960,963,969,982,995,1008,1021,1034,1037],{"type":29,"tag":30,"props":689,"children":691},{"id":690},"rétrospective-agile-le-format-qui-génère-vraiment-du-changement",[692],{"type":35,"value":672},{"type":29,"tag":37,"props":694,"children":695},{},[696],{"type":35,"value":697},"\"Communication\", \"Documentation\", \"Tests.\"",{"type":29,"tag":37,"props":699,"children":700},{},[701],{"type":35,"value":702},"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":29,"tag":37,"props":704,"children":705},{},[706],{"type":35,"value":707},"Deux ans. Les mêmes items. Aucun changement.",{"type":29,"tag":37,"props":709,"children":710},{},[711],{"type":35,"value":712},"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":29,"tag":37,"props":714,"children":715},{},[716],{"type":35,"value":717},"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":29,"tag":57,"props":719,"children":720},{},[],{"type":29,"tag":61,"props":722,"children":724},{"id":723},"pourquoi-les-rétros-classiques-naméliorent-rien",[725],{"type":35,"value":726},"Pourquoi les rétros classiques n'améliorent rien",{"type":29,"tag":37,"props":728,"children":729},{},[730],{"type":35,"value":731},"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":29,"tag":37,"props":733,"children":734},{},[735],{"type":35,"value":736},"Il n'y a pas de mémoire. Pas de continuité. Pas de suivi.",{"type":29,"tag":37,"props":738,"children":739},{},[740],{"type":35,"value":741},"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":29,"tag":37,"props":743,"children":744},{},[745],{"type":35,"value":746},"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":29,"tag":57,"props":748,"children":749},{},[],{"type":29,"tag":61,"props":751,"children":753},{"id":752},"le-format-en-5-étapes",[754],{"type":35,"value":755},"Le format en 5 étapes",{"type":29,"tag":37,"props":757,"children":758},{},[759],{"type":29,"tag":46,"props":760,"children":761},{},[762],{"type":35,"value":763},"Étape 1 : Préparer les données (15 min avant la rétro)",{"type":29,"tag":37,"props":765,"children":766},{},[767,769,775],{"type":35,"value":768},"La rétrospective commence par des faits, pas par des opinions. Le facilitateur prépare un tableau de bord simple du sprint : ",{"type":29,"tag":219,"props":770,"children":772},{"href":771},"/fr/pratiques-agiles/story-points-estimation-agile-alternative",[773],{"type":35,"value":774},"vélocité",{"type":35,"value":776}," 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":29,"tag":37,"props":778,"children":779},{},[780],{"type":35,"value":781},"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":29,"tag":37,"props":783,"children":784},{},[785],{"type":29,"tag":46,"props":786,"children":787},{},[788],{"type":35,"value":789},"Étape 2 : Identifier les patterns sur 3 sprints (15 min)",{"type":29,"tag":37,"props":791,"children":792},{},[793],{"type":35,"value":794},"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":29,"tag":37,"props":796,"children":797},{},[798],{"type":35,"value":799},"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":29,"tag":37,"props":801,"children":802},{},[803],{"type":35,"value":804},"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":29,"tag":282,"props":806,"children":808},{"cta":284,"href":285,"title":807,"type":287},"Vos rétrospectives tournent en rond depuis des mois sans générer de vraie amélioration ?",[809],{"type":29,"tag":37,"props":810,"children":811},{},[812],{"type":35,"value":813},"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":29,"tag":57,"props":815,"children":816},{},[],{"type":29,"tag":37,"props":818,"children":819},{},[820],{"type":29,"tag":46,"props":821,"children":822},{},[823],{"type":35,"value":824},"Étape 3 : Voter sur 1 seul problème à résoudre (20 min)",{"type":29,"tag":37,"props":826,"children":827},{},[828],{"type":35,"value":829},"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":29,"tag":37,"props":831,"children":832},{},[833],{"type":35,"value":834},"Le format qui fonctionne :",{"type":29,"tag":836,"props":837,"children":838},"ol",{},[839,844,849,854],{"type":29,"tag":72,"props":840,"children":841},{},[842],{"type":35,"value":843},"Chaque membre de l'équipe écrit 2 à 3 problèmes observés ce sprint",{"type":29,"tag":72,"props":845,"children":846},{},[847],{"type":35,"value":848},"Regrouper les items similaires (5 minutes)",{"type":29,"tag":72,"props":850,"children":851},{},[852],{"type":35,"value":853},"Vote à points : chaque membre dispose de 3 votes à distribuer librement",{"type":29,"tag":72,"props":855,"children":856},{},[857,859,864],{"type":35,"value":858},"Sélectionner le ",{"type":29,"tag":46,"props":860,"children":861},{},[862],{"type":35,"value":863},"1 seul item",{"type":35,"value":865}," avec le plus de votes pour être traité ce sprint",{"type":29,"tag":37,"props":867,"children":868},{},[869,871,877,879,885],{"type":35,"value":870},"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":29,"tag":219,"props":872,"children":874},{"href":873},"/fr/management/engineering-culture-rituels",[875],{"type":35,"value":876},"6 rituels",{"type":35,"value":878}," qui construisent une culture d'excellence technique. Mike Cohn l'explique dans ",{"type":29,"tag":880,"props":881,"children":882},"em",{},[883],{"type":35,"value":884},"Succeeding with Agile",{"type":35,"value":886}," : 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":29,"tag":37,"props":888,"children":889},{},[890],{"type":29,"tag":46,"props":891,"children":892},{},[893],{"type":35,"value":894},"Étape 4 : Définir une action SMART avec un owner (15 min)",{"type":29,"tag":37,"props":896,"children":897},{},[898],{"type":35,"value":899},"Pour le problème sélectionné, définir une action qui respecte les critères SMART : spécifique, mesurable, actionnable, réaliste, temporelle.",{"type":29,"tag":37,"props":901,"children":902},{},[903],{"type":35,"value":904},"\"Améliorer la communication\" ne passe pas. \"Écrire les critères d'acceptation de 100% des stories du prochain sprint en affinage\" passe.",{"type":29,"tag":37,"props":906,"children":907},{},[908],{"type":35,"value":909},"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":29,"tag":37,"props":911,"children":912},{},[913],{"type":29,"tag":46,"props":914,"children":915},{},[916],{"type":35,"value":917},"Étape 5 : Fermer le cycle à la rétro suivante (5 min)",{"type":29,"tag":37,"props":919,"children":920},{},[921],{"type":35,"value":922},"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":29,"tag":37,"props":924,"children":925},{},[926,928,934],{"type":35,"value":927},"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":29,"tag":219,"props":929,"children":931},{"href":930},"/fr/management/metriques-management-developpeurs-motivation",[932],{"type":35,"value":933},"métriques DORA",{"type":35,"value":935}," pour ancrer ces discussions dans des données factuelles, du PDCA de Deming à l'inspect & adapt de Scrum.",{"type":29,"tag":57,"props":937,"children":938},{},[],{"type":29,"tag":61,"props":940,"children":942},{"id":941},"ce-qui-change-réellement",[943],{"type":35,"value":944},"Ce qui change réellement",{"type":29,"tag":37,"props":946,"children":947},{},[948],{"type":35,"value":949},"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":29,"tag":37,"props":951,"children":952},{},[953],{"type":35,"value":954},"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":29,"tag":37,"props":956,"children":957},{},[958],{"type":35,"value":959},"Ce n'était jamais un problème d'engagement de l'équipe. C'était un problème de système.",{"type":29,"tag":57,"props":961,"children":962},{},[],{"type":29,"tag":61,"props":964,"children":966},{"id":965},"faq-sur-la-rétrospective-agile",[967],{"type":35,"value":968},"FAQ sur la rétrospective Agile",{"type":29,"tag":563,"props":970,"children":971},{},[972,977],{"type":29,"tag":567,"props":973,"children":974},{},[975],{"type":35,"value":976},"1. Faut-il varier le format de rétrospective chaque sprint ?",{"type":29,"tag":37,"props":978,"children":979},{},[980],{"type":35,"value":981},"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":29,"tag":563,"props":983,"children":984},{},[985,990],{"type":29,"tag":567,"props":986,"children":987},{},[988],{"type":35,"value":989},"2. Comment rendre une rétrospective safe quand l'équipe ne se fait pas confiance ?",{"type":29,"tag":37,"props":991,"children":992},{},[993],{"type":35,"value":994},"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":29,"tag":563,"props":996,"children":997},{},[998,1003],{"type":29,"tag":567,"props":999,"children":1000},{},[1001],{"type":35,"value":1002},"3. Comment gérer un manager qui assiste aux rétros et inhibe les retours honnêtes ?",{"type":29,"tag":37,"props":1004,"children":1005},{},[1006],{"type":35,"value":1007},"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":29,"tag":563,"props":1009,"children":1010},{},[1011,1016],{"type":29,"tag":567,"props":1012,"children":1013},{},[1014],{"type":35,"value":1015},"4. Quelle est la durée idéale d'une rétrospective pour un sprint de 2 semaines ?",{"type":29,"tag":37,"props":1017,"children":1018},{},[1019],{"type":35,"value":1020},"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":29,"tag":563,"props":1022,"children":1023},{},[1024,1029],{"type":29,"tag":567,"props":1025,"children":1026},{},[1027],{"type":35,"value":1028},"5. Que faire si les sujets les plus importants sont trop sensibles pour être traités en groupe ?",{"type":29,"tag":37,"props":1030,"children":1031},{},[1032],{"type":35,"value":1033},"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":29,"tag":57,"props":1035,"children":1036},{},[],{"type":29,"tag":282,"props":1038,"children":1041},{"cta":1039,"href":643,"title":1040,"type":645},"Télécharger le guide gratuit →","Ressource gratuite : Guide Lead Time -50% en 90 jours",[1042],{"type":29,"tag":37,"props":1043,"children":1044},{},[1045],{"type":35,"value":1046},"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":653,"depth":653,"links":1048},[1049,1050,1051,1052],{"id":723,"depth":653,"text":726},{"id":752,"depth":653,"text":755},{"id":941,"depth":653,"text":944},{"id":965,"depth":653,"text":968},"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":1057,"_dir":671,"_draft":7,"_partial":7,"_locale":8,"title":1058,"description":1059,"id":653,"date":1060,"listed":13,"nocomments":7,"hidden":7,"categories":1061,"tags":1062,"--cover":1065,"readingTime":1066,"body":1070,"_type":663,"_id":1412,"_source":665,"_file":1413,"_stem":1414,"_extension":668},"/fr/pratiques-agiles/sprint-planning-efficace","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",[671],[1063,1064,18],"Sprint Planning","Scrum","covers/articles/sprint-planning-efficace.jpg",{"text":682,"minutes":1067,"time":1068,"words":1069},6.63,397800,1326,{"type":26,"children":1071,"toc":1405},[1072,1077,1082,1087,1100,1105,1108,1114,1119,1129,1139,1149,1159,1164,1167,1173,1178,1183,1193,1205,1210,1219,1222,1228,1233,1250,1268,1278,1288,1293,1296,1302,1307,1312,1320,1323,1329,1342,1355,1368,1381,1394,1397],{"type":29,"tag":30,"props":1073,"children":1075},{"id":1074},"pourquoi-votre-sprint-planning-échoue-et-comment-le-corriger",[1076],{"type":35,"value":1058},{"type":29,"tag":37,"props":1078,"children":1079},{},[1080],{"type":35,"value":1081},"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":29,"tag":37,"props":1083,"children":1084},{},[1085],{"type":35,"value":1086},"Ce n'était pas une exception. C'était la norme.",{"type":29,"tag":37,"props":1088,"children":1089},{},[1090,1092,1098],{"type":35,"value":1091},"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":29,"tag":219,"props":1093,"children":1095},{"href":1094},"/fr/pratiques-agiles/reduire-work-in-progress-velocite",[1096],{"type":35,"value":1097},"lead time",{"type":35,"value":1099}," é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":29,"tag":37,"props":1101,"children":1102},{},[1103],{"type":35,"value":1104},"Voici les 4 erreurs structurelles que je vois se répéter, et les corrections qui fonctionnent terrain.",{"type":29,"tag":57,"props":1106,"children":1107},{},[],{"type":29,"tag":61,"props":1109,"children":1111},{"id":1110},"les-4-symptômes-dun-sprint-planning-dysfonctionnel",[1112],{"type":35,"value":1113},"Les 4 symptômes d'un sprint planning dysfonctionnel",{"type":29,"tag":37,"props":1115,"children":1116},{},[1117],{"type":35,"value":1118},"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":29,"tag":37,"props":1120,"children":1121},{},[1122,1127],{"type":29,"tag":46,"props":1123,"children":1124},{},[1125],{"type":35,"value":1126},"Symptôme 1 : La durée dépasse 2 heures pour un sprint de 2 semaines.",{"type":35,"value":1128}," 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":29,"tag":37,"props":1130,"children":1131},{},[1132,1137],{"type":29,"tag":46,"props":1133,"children":1134},{},[1135],{"type":35,"value":1136},"Symptôme 2 : Les discussions portent sur l'estimation, pas sur la compréhension.",{"type":35,"value":1138}," 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":29,"tag":37,"props":1140,"children":1141},{},[1142,1147],{"type":29,"tag":46,"props":1143,"children":1144},{},[1145],{"type":35,"value":1146},"Symptôme 3 : Des stories entrent en sprint sans critères d'acceptation.",{"type":35,"value":1148}," 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":29,"tag":37,"props":1150,"children":1151},{},[1152,1157],{"type":29,"tag":46,"props":1153,"children":1154},{},[1155],{"type":35,"value":1156},"Symptôme 4 : Le scope change pendant le sprint.",{"type":35,"value":1158}," 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":29,"tag":37,"props":1160,"children":1161},{},[1162],{"type":35,"value":1163},"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":29,"tag":57,"props":1165,"children":1166},{},[],{"type":29,"tag":61,"props":1168,"children":1170},{"id":1169},"la-cause-racine-les-stories-non-affinées",[1171],{"type":35,"value":1172},"La cause racine : les stories non-affinées",{"type":29,"tag":37,"props":1174,"children":1175},{},[1176],{"type":35,"value":1177},"La cause racine de 80% des sprint plannings qui échouent est simple : les stories arrivent en sprint planning sans avoir été affinées.",{"type":29,"tag":37,"props":1179,"children":1180},{},[1181],{"type":35,"value":1182},"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":29,"tag":37,"props":1184,"children":1185},{},[1186,1191],{"type":29,"tag":46,"props":1187,"children":1188},{},[1189],{"type":35,"value":1190},"La correction",{"type":35,"value":1192}," : des sessions d'affinage dédiées, 2 fois par semaine, 45 minutes, obligatoires pour les stories candidates au prochain sprint.",{"type":29,"tag":37,"props":1194,"children":1195},{},[1196,1198,1203],{"type":35,"value":1197},"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":29,"tag":219,"props":1199,"children":1200},{"href":605},[1201],{"type":35,"value":1202},"Definition of Ready",{"type":35,"value":1204},". 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":29,"tag":37,"props":1206,"children":1207},{},[1208],{"type":35,"value":1209},"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":29,"tag":282,"props":1211,"children":1213},{"cta":284,"href":285,"title":1212,"type":287},"Votre sprint planning est long, tendu, et les sprints finissent rarement comme prévu ?",[1214],{"type":29,"tag":37,"props":1215,"children":1216},{},[1217],{"type":35,"value":1218},"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":29,"tag":57,"props":1220,"children":1221},{},[],{"type":29,"tag":61,"props":1223,"children":1225},{"id":1224},"le-format-en-4-blocs-qui-tient-en-3-heures",[1226],{"type":35,"value":1227},"Le format en 4 blocs qui tient en 3 heures",{"type":29,"tag":37,"props":1229,"children":1230},{},[1231],{"type":35,"value":1232},"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":29,"tag":37,"props":1234,"children":1235},{},[1236,1241,1243,1248],{"type":29,"tag":46,"props":1237,"children":1238},{},[1239],{"type":35,"value":1240},"Bloc 1 (45 min) : Contexte et objectif du sprint.",{"type":35,"value":1242}," 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":29,"tag":880,"props":1244,"children":1245},{},[1246],{"type":35,"value":1247},"Scrum: The Art of Doing Twice the Work in Half the Time",{"type":35,"value":1249}," : 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":29,"tag":37,"props":1251,"children":1252},{},[1253,1258,1260,1266],{"type":29,"tag":46,"props":1254,"children":1255},{},[1256],{"type":35,"value":1257},"Bloc 2 (45 min) : Sélection des stories.",{"type":35,"value":1259}," 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":29,"tag":219,"props":1261,"children":1263},{"href":1262},"/fr/pratiques-agiles/anti-patterns-backlog",[1264],{"type":35,"value":1265},"backlog mal entretenu",{"type":35,"value":1267}," est la cause principale d'un planning qui dérive.",{"type":29,"tag":37,"props":1269,"children":1270},{},[1271,1276],{"type":29,"tag":46,"props":1272,"children":1273},{},[1274],{"type":35,"value":1275},"Bloc 3 (45 min) : Découpage en tâches.",{"type":35,"value":1277}," 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":29,"tag":37,"props":1279,"children":1280},{},[1281,1286],{"type":29,"tag":46,"props":1282,"children":1283},{},[1284],{"type":35,"value":1285},"Bloc 4 (45 min) : Vérification de capacité et engagement.",{"type":35,"value":1287}," 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":29,"tag":37,"props":1289,"children":1290},{},[1291],{"type":35,"value":1292},"Résultat : un planning de 3 heures maximum, un backlog de sprint réaliste, et un engagement que l'équipe peut tenir.",{"type":29,"tag":57,"props":1294,"children":1295},{},[],{"type":29,"tag":61,"props":1297,"children":1299},{"id":1298},"ce-que-ça-change-économiquement",[1300],{"type":35,"value":1301},"Ce que ça change économiquement",{"type":29,"tag":37,"props":1303,"children":1304},{},[1305],{"type":35,"value":1306},"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":29,"tag":37,"props":1308,"children":1309},{},[1310],{"type":35,"value":1311},"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":29,"tag":431,"props":1313,"children":1314},{},[1315],{"type":29,"tag":37,"props":1316,"children":1317},{},[1318],{"type":35,"value":1319},"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":29,"tag":57,"props":1321,"children":1322},{},[],{"type":29,"tag":61,"props":1324,"children":1326},{"id":1325},"faq-sur-le-sprint-planning",[1327],{"type":35,"value":1328},"FAQ sur le sprint planning",{"type":29,"tag":563,"props":1330,"children":1331},{},[1332,1337],{"type":29,"tag":567,"props":1333,"children":1334},{},[1335],{"type":35,"value":1336},"1. Quelle est la durée idéale d'un sprint planning pour une équipe de 8 personnes ?",{"type":29,"tag":37,"props":1338,"children":1339},{},[1340],{"type":35,"value":1341},"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":29,"tag":563,"props":1343,"children":1344},{},[1345,1350],{"type":29,"tag":567,"props":1346,"children":1347},{},[1348],{"type":35,"value":1349},"2. Doit-on estimer toutes les stories en sprint planning ?",{"type":29,"tag":37,"props":1351,"children":1352},{},[1353],{"type":35,"value":1354},"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":29,"tag":563,"props":1356,"children":1357},{},[1358,1363],{"type":29,"tag":567,"props":1359,"children":1360},{},[1361],{"type":35,"value":1362},"3. Que faire si le PO arrive au planning avec un backlog non-priorisé ?",{"type":29,"tag":37,"props":1364,"children":1365},{},[1366],{"type":35,"value":1367},"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":29,"tag":563,"props":1369,"children":1370},{},[1371,1376],{"type":29,"tag":567,"props":1372,"children":1373},{},[1374],{"type":35,"value":1375},"4. Comment gérer les dépendances entre équipes dans le sprint planning ?",{"type":29,"tag":37,"props":1377,"children":1378},{},[1379],{"type":35,"value":1380},"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":29,"tag":563,"props":1382,"children":1383},{},[1384,1389],{"type":29,"tag":567,"props":1385,"children":1386},{},[1387],{"type":35,"value":1388},"5. Supprimer les story points résout-il les problèmes de sprint planning ?",{"type":29,"tag":37,"props":1390,"children":1391},{},[1392],{"type":35,"value":1393},"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":29,"tag":57,"props":1395,"children":1396},{},[],{"type":29,"tag":282,"props":1398,"children":1399},{"cta":1039,"href":643,"title":1040,"type":645},[1400],{"type":29,"tag":37,"props":1401,"children":1402},{},[1403],{"type":35,"value":1404},"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":653,"depth":653,"links":1406},[1407,1408,1409,1410,1411],{"id":1110,"depth":653,"text":1113},{"id":1169,"depth":653,"text":1172},{"id":1224,"depth":653,"text":1227},{"id":1298,"depth":653,"text":1301},{"id":1325,"depth":653,"text":1328},"content:fr:pratiques-agiles:sprint-planning-efficace.md","fr/pratiques-agiles/sprint-planning-efficace.md","fr/pratiques-agiles/sprint-planning-efficace",1775679745463]