[{"data":1,"prerenderedAt":9551},["ShallowReactive",2],{"search-api":-1,"listing-tag-agile-page-1":3},[4,489,1158,1806,2252,2693,3065,3450,3798,6587],{"_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":17,"readingTime":18,"body":23,"_type":483,"_id":484,"_source":485,"_file":486,"_stem":487,"_extension":488},"\u002Ffr\u002Fpratiques-agiles\u002Freduire-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],"agile","covers\u002Farticles\u002Freduire-work-in-progress.jpg",{"text":19,"minutes":20,"time":21,"words":22},"9 min read",8.18,490800,1636,{"type":24,"children":25,"toc":474},"root",[26,34,39,44,49,54,58,65,70,79,84,89,106,123,140,145,148,154,159,169,179,189,215,228,231,237,247,257,262,282,292,302,312,315,321,331,349,359,362,368,373,378,383,386,392,407,420,433,446,459,462],{"type":27,"tag":28,"props":29,"children":30},"element","p",{},[31],{"type":32,"value":33},"text","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":27,"tag":28,"props":35,"children":36},{},[37],{"type":32,"value":38},"Il y en avait 22.",{"type":27,"tag":28,"props":40,"children":41},{},[42],{"type":32,"value":43},"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":27,"tag":28,"props":45,"children":46},{},[47],{"type":32,"value":48},"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":27,"tag":28,"props":50,"children":51},{},[52],{"type":32,"value":53},"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":27,"tag":55,"props":56,"children":57},"hr",{},[],{"type":27,"tag":59,"props":60,"children":62},"h2",{"id":61},"la-loi-de-little-la-démonstration-mathématique",[63],{"type":32,"value":64},"La loi de Little : la démonstration mathématique",{"type":27,"tag":28,"props":66,"children":67},{},[68],{"type":32,"value":69},"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":27,"tag":28,"props":71,"children":72},{},[73],{"type":27,"tag":74,"props":75,"children":76},"strong",{},[77],{"type":32,"value":78},"Lead Time = Work In Progress \u002F Throughput",{"type":27,"tag":28,"props":80,"children":81},{},[82],{"type":32,"value":83},"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":27,"tag":28,"props":85,"children":86},{},[87],{"type":32,"value":88},"La démonstration chiffrée est implacable.",{"type":27,"tag":28,"props":90,"children":91},{},[92,97,99,104],{"type":27,"tag":74,"props":93,"children":94},{},[95],{"type":32,"value":96},"Scénario A : WIP illimité",{"type":32,"value":98}," : équipe de 5 développeurs, 15 stories en cours (3 par développeur), throughput de 10 stories par semaine. Lead Time moyen : 15 \u002F 10 = ",{"type":27,"tag":74,"props":100,"children":101},{},[102],{"type":32,"value":103},"1,5 semaine",{"type":32,"value":105},".",{"type":27,"tag":28,"props":107,"children":108},{},[109,114,116,121],{"type":27,"tag":74,"props":110,"children":111},{},[112],{"type":32,"value":113},"Scénario B : WIP limité à 8",{"type":32,"value":115}," : même équipe, même throughput, 8 stories en cours. Lead Time moyen : 8 \u002F 10 = ",{"type":27,"tag":74,"props":117,"children":118},{},[119],{"type":32,"value":120},"0,8 semaine",{"type":32,"value":122}," (−47%).",{"type":27,"tag":28,"props":124,"children":125},{},[126,131,133,138],{"type":27,"tag":74,"props":127,"children":128},{},[129],{"type":32,"value":130},"Scénario C : WIP limité à 5",{"type":32,"value":132}," : 5 stories en cours (1 par développeur). Lead Time moyen : 5 \u002F 10 = ",{"type":27,"tag":74,"props":134,"children":135},{},[136],{"type":32,"value":137},"0,5 semaine",{"type":32,"value":139}," (−67%).",{"type":27,"tag":28,"props":141,"children":142},{},[143],{"type":32,"value":144},"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":27,"tag":55,"props":146,"children":147},{},[],{"type":27,"tag":59,"props":149,"children":151},{"id":150},"pourquoi-le-wip-augmente-naturellement",[152],{"type":32,"value":153},"Pourquoi le WIP augmente naturellement",{"type":27,"tag":28,"props":155,"children":156},{},[157],{"type":32,"value":158},"Dans la plupart des équipes, le WIP augmente sans décision consciente. Les mécanismes sont structurels.",{"type":27,"tag":28,"props":160,"children":161},{},[162,167],{"type":27,"tag":74,"props":163,"children":164},{},[165],{"type":32,"value":166},"Le multitâche comme norme.",{"type":32,"value":168}," 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":27,"tag":28,"props":170,"children":171},{},[172,177],{"type":27,"tag":74,"props":173,"children":174},{},[175],{"type":32,"value":176},"La peur du \"slack\".",{"type":32,"value":178}," 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":27,"tag":28,"props":180,"children":181},{},[182,187],{"type":27,"tag":74,"props":183,"children":184},{},[185],{"type":32,"value":186},"Les dépendances non résolues.",{"type":32,"value":188}," 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":27,"tag":28,"props":190,"children":191},{},[192,205,207,213],{"type":27,"tag":74,"props":193,"children":194},{},[195,197,204],{"type":32,"value":196},"Le ",{"type":27,"tag":198,"props":199,"children":201},"a",{"href":200},"\u002Ffr\u002Fpratiques-agiles\u002Fanti-patterns-backlog",[202],{"type":32,"value":203},"backlog infini",{"type":32,"value":105},{"type":32,"value":206}," 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":27,"tag":198,"props":208,"children":210},{"href":209},"\u002Ffr\u002Fpratiques-agiles\u002Fsprint-planning-efficace",[211],{"type":32,"value":212},"sprint planning",{"type":32,"value":214}," qui génère du WIP excessif.",{"type":27,"tag":216,"props":217,"children":222},"cta",{"cta":218,"href":219,"title":220,"type":221},"Révéler les angles morts de mon équipe →","https:\u002F\u002Fapp.kamanga.fr\u002Fforms\u002Fdiscovery-call","Votre vélocité semble correcte, mais vos stories mettent des semaines à sortir ?","call",[223],{"type":27,"tag":28,"props":224,"children":225},{},[226],{"type":32,"value":227},"Un WIP qui dérive ne se lit pas dans la vélocité : il se cache dans le multitâche silencieux, les PR qui stagnent en review, les dépendances qui bloquent sans alerter. En 30 minutes de diagnostic ciblé sur votre équipe, je révèle ce que vos métriques actuelles ne capturent pas et je priorise avec vous les 2-3 leviers de flux qui réduiront vraiment votre lead time.",{"type":27,"tag":55,"props":229,"children":230},{},[],{"type":27,"tag":59,"props":232,"children":234},{"id":233},"le-protocole-dimplémentation-en-5-étapes",[235],{"type":32,"value":236},"Le protocole d'implémentation en 5 étapes",{"type":27,"tag":28,"props":238,"children":239},{},[240,245],{"type":27,"tag":74,"props":241,"children":242},{},[243],{"type":32,"value":244},"Étape 1 : Mesurer le WIP actuel.",{"type":32,"value":246}," 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":27,"tag":28,"props":248,"children":249},{},[250,255],{"type":27,"tag":74,"props":251,"children":252},{},[253],{"type":32,"value":254},"Étape 2 : Définir les limites initiales.",{"type":32,"value":256}," 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":27,"tag":28,"props":258,"children":259},{},[260],{"type":32,"value":261},"La limite s'applique par colonne du board Kanban, pas au total :",{"type":27,"tag":263,"props":264,"children":265},"ul",{},[266,272,277],{"type":27,"tag":267,"props":268,"children":269},"li",{},[270],{"type":32,"value":271},"\"In Progress\" : limite = N développeurs",{"type":27,"tag":267,"props":273,"children":274},{},[275],{"type":32,"value":276},"\"In Review\" : limite = N\u002F2",{"type":27,"tag":267,"props":278,"children":279},{},[280],{"type":32,"value":281},"\"In Testing\" : limite = N\u002F3",{"type":27,"tag":28,"props":283,"children":284},{},[285,290],{"type":27,"tag":74,"props":286,"children":287},{},[288],{"type":32,"value":289},"Étape 3 : Rendre la limite visible et automatique.",{"type":32,"value":291}," 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":27,"tag":28,"props":293,"children":294},{},[295,300],{"type":27,"tag":74,"props":296,"children":297},{},[298],{"type":32,"value":299},"Étape 4 : Créer la règle \"finir avant de commencer\".",{"type":32,"value":301}," 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":27,"tag":28,"props":303,"children":304},{},[305,310],{"type":27,"tag":74,"props":306,"children":307},{},[308],{"type":32,"value":309},"Étape 5 : Ajuster la limite après 4 sprints.",{"type":32,"value":311}," 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":27,"tag":55,"props":313,"children":314},{},[],{"type":27,"tag":59,"props":316,"children":318},{"id":317},"les-résistances-et-comment-les-adresser",[319],{"type":32,"value":320},"Les résistances et comment les adresser",{"type":27,"tag":28,"props":322,"children":323},{},[324,329],{"type":27,"tag":74,"props":325,"children":326},{},[327],{"type":32,"value":328},"\"Je suis bloqué, je dois bien commencer autre chose.\"",{"type":32,"value":330}," 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":27,"tag":28,"props":332,"children":333},{},[334,339,341,347],{"type":27,"tag":74,"props":335,"children":336},{},[337],{"type":32,"value":338},"\"Le business veut des estimations et une limite WIP les rend impossibles.\"",{"type":32,"value":340}," 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":27,"tag":198,"props":342,"children":344},{"href":343},"\u002Ffr\u002Fpratiques-agiles\u002Fstory-points-estimation-agile-alternative",[345],{"type":32,"value":346},"throughput",{"type":32,"value":348}," 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":27,"tag":28,"props":350,"children":351},{},[352,357],{"type":27,"tag":74,"props":353,"children":354},{},[355],{"type":32,"value":356},"\"Mes développeurs vont s'ennuyer en attendant.\"",{"type":32,"value":358}," 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":27,"tag":55,"props":360,"children":361},{},[],{"type":27,"tag":59,"props":363,"children":365},{"id":364},"ce-que-ça-a-changé",[366],{"type":32,"value":367},"Ce que ça a changé",{"type":27,"tag":28,"props":369,"children":370},{},[371],{"type":32,"value":372},"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":27,"tag":28,"props":374,"children":375},{},[376],{"type":32,"value":377},"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":27,"tag":28,"props":379,"children":380},{},[381],{"type":32,"value":382},"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":27,"tag":55,"props":384,"children":385},{},[],{"type":27,"tag":59,"props":387,"children":389},{"id":388},"faq-sur-les-limites-de-wip",[390],{"type":32,"value":391},"FAQ sur les limites de WIP",{"type":27,"tag":393,"props":394,"children":395},"details",{},[396,402],{"type":27,"tag":397,"props":398,"children":399},"summary",{},[400],{"type":32,"value":401},"1. Les limites de WIP s'appliquent-elles en Scrum comme en Kanban ?",{"type":27,"tag":28,"props":403,"children":404},{},[405],{"type":32,"value":406},"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":27,"tag":393,"props":408,"children":409},{},[410,415],{"type":27,"tag":397,"props":411,"children":412},{},[413],{"type":32,"value":414},"2. Comment gérer les urgences qui obligent à dépasser la limite WIP ?",{"type":27,"tag":28,"props":416,"children":417},{},[418],{"type":32,"value":419},"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":27,"tag":393,"props":421,"children":422},{},[423,428],{"type":27,"tag":397,"props":424,"children":425},{},[426],{"type":32,"value":427},"3. Quelle est la limite WIP optimale ?",{"type":27,"tag":28,"props":429,"children":430},{},[431],{"type":32,"value":432},"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":27,"tag":393,"props":434,"children":435},{},[436,441],{"type":27,"tag":397,"props":437,"children":438},{},[439],{"type":32,"value":440},"4. Comment les limites WIP interagissent-elles avec les bugs urgents ?",{"type":27,"tag":28,"props":442,"children":443},{},[444],{"type":32,"value":445},"Les bugs urgents (P1\u002FP0) 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":27,"tag":393,"props":447,"children":448},{},[449,454],{"type":27,"tag":397,"props":450,"children":451},{},[452],{"type":32,"value":453},"5. Comment convaincre le management que moins de WIP n'est pas moins de travail ?",{"type":27,"tag":28,"props":455,"children":456},{},[457],{"type":32,"value":458},"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":27,"tag":55,"props":460,"children":461},{},[],{"type":27,"tag":216,"props":463,"children":468},{"cta":464,"href":465,"title":466,"type":467},"Télécharger le guide gratuit →","\u002Fmes-ressources","Ressource gratuite : Guide Lead Time -50% en 90 jours","resource",[469],{"type":27,"tag":28,"props":470,"children":471},{},[472],{"type":32,"value":473},"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":475,"depth":475,"links":476},2,[477,478,479,480,481,482],{"id":61,"depth":475,"text":64},{"id":150,"depth":475,"text":153},{"id":233,"depth":475,"text":236},{"id":317,"depth":475,"text":320},{"id":364,"depth":475,"text":367},{"id":388,"depth":475,"text":391},"markdown","content:fr:pratiques-agiles:reduire-work-in-progress-velocite.md","content","fr\u002Fpratiques-agiles\u002Freduire-work-in-progress-velocite.md","fr\u002Fpratiques-agiles\u002Freduire-work-in-progress-velocite","md",{"_path":490,"_dir":491,"_draft":7,"_partial":7,"_locale":8,"title":492,"description":493,"id":494,"date":495,"listed":13,"nocomments":7,"hidden":7,"categories":496,"tags":497,"cover":500,"readingTime":501,"body":506,"_type":483,"_id":1155,"_source":485,"_file":1156,"_stem":1157,"_extension":488},"\u002Ffr\u002Fmanagement\u002Fengineering-culture-rituels","management","Engineering culture : les 6 rituels qui font la différence","La culture ne se proclame pas, elle se construit par des rituels répétés. Les 6 pratiques concrètes qui construisent une culture d'excellence technique sur 12 mois.",29,"2026-03-11",[491],[498,16,499],"software-craftsmanship","leadership","covers\u002Farticles\u002Fengineering-culture-rituels.jpg",{"text":502,"minutes":503,"time":504,"words":505},"10 min read",9.325,559500,1865,{"type":24,"children":507,"toc":1145},[508,513,518,538,543,546,552,562,567,575,603,613,616,622,631,636,644,667,677,687,696,699,705,714,719,727,750,758,781,791,794,800,809,814,822,845,855,865,868,874,883,896,906,916,926,929,935,944,949,959,984,987,993,1003,1011,1034,1044,1049,1052,1058,1079,1092,1105,1118,1131,1134],{"type":27,"tag":28,"props":509,"children":510},{},[511],{"type":32,"value":512},"Dans un client dans le secteur financier où j'accompagnais l'équipe engineering, les valeurs d'entreprise affichaient \"excellence technique\" et \"partage de connaissance\" sur tous les murs. La réalité : chaque développeur gardait sa connaissance pour lui comme un avantage concurrentiel interne, les post-mortems cherchaient des coupables, et personne ne proposait de sujets pour les tech talks parce que personne n'avait jamais vu de tech talk se tenir.",{"type":27,"tag":28,"props":514,"children":515},{},[516],{"type":32,"value":517},"La culture n'était pas mauvaise parce que les valeurs étaient mauvaises. La culture était mauvaise parce qu'il n'y avait aucun rituel pour les incarner.",{"type":27,"tag":28,"props":519,"children":520},{},[521,523,529,531,536],{"type":32,"value":522},"Patrick Lencioni dans ",{"type":27,"tag":524,"props":525,"children":526},"em",{},[527],{"type":32,"value":528},"The Five Dysfunctions of a Team",{"type":32,"value":530}," et les recherches DORA sur l'état du DevOps convergent vers la même conclusion : ",{"type":27,"tag":74,"props":532,"children":533},{},[534],{"type":32,"value":535},"la performance d'une équipe engineering est davantage fonction de sa culture que de ses outils ou de ses processus",{"type":32,"value":537},". Dans les 100 000 réponses analysées par le programme DORA chaque année, les équipes elite performers ont toutes en commun des pratiques culturelles spécifiques, pas des valeurs affichées. Des actes répétés.",{"type":27,"tag":28,"props":539,"children":540},{},[541],{"type":32,"value":542},"Voici les 6 rituels que j'ai implémentés et observés changer des équipes.",{"type":27,"tag":55,"props":544,"children":545},{},[],{"type":27,"tag":59,"props":547,"children":549},{"id":548},"rituel-1-le-post-mortem-blameless",[550],{"type":32,"value":551},"Rituel 1 : Le post-mortem blameless",{"type":27,"tag":28,"props":553,"children":554},{},[555,560],{"type":27,"tag":74,"props":556,"children":557},{},[558],{"type":32,"value":559},"Ce qu'il construit :",{"type":32,"value":561}," une culture de l'apprentissage collectif et de la sécurité psychologique.",{"type":27,"tag":28,"props":563,"children":564},{},[565],{"type":32,"value":566},"Après chaque incident en production significatif, l'équipe se réunit dans les 48 heures pour une analyse structurée. L'objectif n'est pas de trouver un coupable : c'est de comprendre le système qui a rendu l'incident possible.",{"type":27,"tag":28,"props":568,"children":569},{},[570],{"type":27,"tag":74,"props":571,"children":572},{},[573],{"type":32,"value":574},"Format que j'utilise :",{"type":27,"tag":263,"props":576,"children":577},{},[578,583,588,593,598],{"type":27,"tag":267,"props":579,"children":580},{},[581],{"type":32,"value":582},"45 à 60 minutes maximum",{"type":27,"tag":267,"props":584,"children":585},{},[586],{"type":32,"value":587},"Chronologie des événements (pas des personnes)",{"type":27,"tag":267,"props":589,"children":590},{},[591],{"type":32,"value":592},"5 Pourquoi pour remonter à la cause racine",{"type":27,"tag":267,"props":594,"children":595},{},[596],{"type":32,"value":597},"Actions correctives sur le système (process, monitoring, test), jamais \"être plus vigilant\"",{"type":27,"tag":267,"props":599,"children":600},{},[601],{"type":32,"value":602},"Document partagé avec toute l'équipe",{"type":27,"tag":28,"props":604,"children":605},{},[606,611],{"type":27,"tag":74,"props":607,"children":608},{},[609],{"type":32,"value":610},"Ce que le \"blameless\" change concrètement :",{"type":32,"value":612}," quand les incidents sont des opportunités d'apprentissage sans conséquence sur la carrière des personnes, les développeurs signalent les incidents plus tôt, cherchent plus profondément les causes racines, et implémentent des corrections systémiques. La règle absolue : pas de \"c'est la faute de X\". Si quelqu'un a fait une erreur, la question est \"pourquoi le système a-t-il rendu cette erreur possible ?\"",{"type":27,"tag":55,"props":614,"children":615},{},[],{"type":27,"tag":59,"props":617,"children":619},{"id":618},"rituel-2-la-tech-talk-mensuelle",[620],{"type":32,"value":621},"Rituel 2 : La Tech Talk mensuelle",{"type":27,"tag":28,"props":623,"children":624},{},[625,629],{"type":27,"tag":74,"props":626,"children":627},{},[628],{"type":32,"value":559},{"type":32,"value":630}," une culture du partage de connaissance et de la curiosité intellectuelle.",{"type":27,"tag":28,"props":632,"children":633},{},[634],{"type":32,"value":635},"Une fois par mois, un membre de l'équipe présente pendant 30 minutes un sujet technique, pas nécessairement lié au projet en cours. Une technologie qu'il explore, un problème qu'il a résolu, un livre qu'il a lu, une conférence qu'il a regardée.",{"type":27,"tag":28,"props":637,"children":638},{},[639],{"type":27,"tag":74,"props":640,"children":641},{},[642],{"type":32,"value":643},"Pourquoi ce rituel fonctionne :",{"type":27,"tag":263,"props":645,"children":646},{},[647,652,657,662],{"type":27,"tag":267,"props":648,"children":649},{},[650],{"type":32,"value":651},"Il valorise l'apprentissage continu comme norme culturelle, pas comme hobby personnel",{"type":27,"tag":267,"props":653,"children":654},{},[655],{"type":32,"value":656},"Il expose l'équipe à des perspectives qu'elle n'aurait pas explorées",{"type":27,"tag":267,"props":658,"children":659},{},[660],{"type":32,"value":661},"Il développe les compétences de communication technique des présentateurs",{"type":27,"tag":267,"props":663,"children":664},{},[665],{"type":32,"value":666},"Il crée des conversations qui durent au-delà de la session",{"type":27,"tag":28,"props":668,"children":669},{},[670,675],{"type":27,"tag":74,"props":671,"children":672},{},[673],{"type":32,"value":674},"Comment je l'instaure :",{"type":32,"value":676}," je présente en premier. Cela enlève la pression du \"qui va se lancer\" et montre que c'est un espace sans jugement. Après 2 à 3 sessions, une rotation naturelle s'installe. Je ne force jamais : le volontariat maintient la qualité.",{"type":27,"tag":28,"props":678,"children":679},{},[680,685],{"type":27,"tag":74,"props":681,"children":682},{},[683],{"type":32,"value":684},"Le seuil de qualité que j'impose :",{"type":32,"value":686}," pas besoin d'être expert pour présenter. \"J'ai exploré X cette semaine, voici ce que j'ai trouvé intéressant, voici les questions que je n'ai pas encore résolues\" est une Tech Talk de qualité. Parfois meilleure que la présentation d'un expert, parce qu'elle montre le processus d'apprentissage.",{"type":27,"tag":216,"props":688,"children":690},{"cta":218,"href":219,"title":689,"type":221},"Vos valeurs affichent l'excellence technique, mais savez-vous ce que vos rituels disent vraiment de votre culture ?",[691],{"type":27,"tag":28,"props":692,"children":693},{},[694],{"type":32,"value":695},"La vraie culture d'une équipe ne se lit pas dans ses valeurs affichées : elle se révèle dans ses post-mortems, ses silences en retro, et la connaissance que chacun garde pour soi. En 30 minutes de diagnostic, je vous aide à cartographier l'écart entre la culture que vous croyez avoir et celle que vos rituels produisent réellement, puis à prioriser les 2 à 3 leviers qui changeront vraiment la donne.",{"type":27,"tag":55,"props":697,"children":698},{},[],{"type":27,"tag":59,"props":700,"children":702},{"id":701},"rituel-3-la-session-de-code-review-collective",[703],{"type":32,"value":704},"Rituel 3 : La session de code review collective",{"type":27,"tag":28,"props":706,"children":707},{},[708,712],{"type":27,"tag":74,"props":709,"children":710},{},[711],{"type":32,"value":559},{"type":32,"value":713}," des standards techniques partagés et une culture de feedback constructif.",{"type":27,"tag":28,"props":715,"children":716},{},[717],{"type":32,"value":718},"Toutes les 2 semaines, l'équipe passe 45 minutes à reviewer ensemble une PR récente, soit un changement intéressant sur le plan technique, soit une PR qui a suscité des discussions en review asynchrone.",{"type":27,"tag":28,"props":720,"children":721},{},[722],{"type":27,"tag":74,"props":723,"children":724},{},[725],{"type":32,"value":726},"Ce que ce rituel apprend concrètement :",{"type":27,"tag":263,"props":728,"children":729},{},[730,735,740,745],{"type":27,"tag":267,"props":731,"children":732},{},[733],{"type":32,"value":734},"Comment les seniors pensent quand ils reviewent du code",{"type":27,"tag":267,"props":736,"children":737},{},[738],{"type":32,"value":739},"Les standards non écrits que les seniors appliquent intuitivement",{"type":27,"tag":267,"props":741,"children":742},{},[743],{"type":32,"value":744},"Comment donner du feedback constructif (en observant les seniors le faire)",{"type":27,"tag":267,"props":746,"children":747},{},[748],{"type":32,"value":749},"Les patterns à éviter dans cette base de code spécifique",{"type":27,"tag":28,"props":751,"children":752},{},[753],{"type":27,"tag":74,"props":754,"children":755},{},[756],{"type":32,"value":757},"Format :",{"type":27,"tag":263,"props":759,"children":760},{},[761,766,771,776],{"type":27,"tag":267,"props":762,"children":763},{},[764],{"type":32,"value":765},"L'auteur présente le contexte (2 min)",{"type":27,"tag":267,"props":767,"children":768},{},[769],{"type":32,"value":770},"Review collective en temps réel sur un écran partagé (30 min)",{"type":27,"tag":267,"props":772,"children":773},{},[774],{"type":32,"value":775},"Discussion des trade-offs et décisions (10 min)",{"type":27,"tag":267,"props":777,"children":778},{},[779],{"type":32,"value":780},"Synthèse des enseignements (5 min)",{"type":27,"tag":28,"props":782,"children":783},{},[784,789],{"type":27,"tag":74,"props":785,"children":786},{},[787],{"type":32,"value":788},"Ce que j'observe systématiquement :",{"type":32,"value":790}," les développeurs juniors exposés à des sessions de review collective progressent significativement plus vite sur la qualité du code que ceux qui reçoivent uniquement des reviews asynchrones. La différence n'est pas dans le contenu du feedback : c'est dans la visibilité du raisonnement du reviewer.",{"type":27,"tag":55,"props":792,"children":793},{},[],{"type":27,"tag":59,"props":795,"children":797},{"id":796},"rituel-4-lengineering-retrospective-trimestrielle",[798],{"type":32,"value":799},"Rituel 4 : L'Engineering Retrospective trimestrielle",{"type":27,"tag":28,"props":801,"children":802},{},[803,807],{"type":27,"tag":74,"props":804,"children":805},{},[806],{"type":32,"value":559},{"type":32,"value":808}," une culture d'amélioration continue de l'engineering lui-même, séparée de la rétrospective produit.",{"type":27,"tag":28,"props":810,"children":811},{},[812],{"type":32,"value":813},"Une fois par trimestre, l'équipe consacre 2 heures à évaluer l'état de l'engineering, pas la delivery produit (c'est la rétro Scrum), mais les pratiques techniques elles-mêmes.",{"type":27,"tag":28,"props":815,"children":816},{},[817],{"type":27,"tag":74,"props":818,"children":819},{},[820],{"type":32,"value":821},"Questions que j'utilise :",{"type":27,"tag":263,"props":823,"children":824},{},[825,830,835,840],{"type":27,"tag":267,"props":826,"children":827},{},[828],{"type":32,"value":829},"Quelles pratiques techniques avons-nous améliorées ce trimestre ?",{"type":27,"tag":267,"props":831,"children":832},{},[833],{"type":32,"value":834},"Quelle partie de notre codebase nous ralentit le plus ?",{"type":27,"tag":267,"props":836,"children":837},{},[838],{"type":32,"value":839},"Quelle compétence technique manque à l'équipe ?",{"type":27,"tag":267,"props":841,"children":842},{},[843],{"type":32,"value":844},"Si on refaisait l'architecture de X aujourd'hui, on ferait quoi différemment ?",{"type":27,"tag":28,"props":846,"children":847},{},[848,853],{"type":27,"tag":74,"props":849,"children":850},{},[851],{"type":32,"value":852},"Pourquoi la séparation de la rétro produit est essentielle :",{"type":32,"value":854}," dans une rétro Scrum classique, les préoccupations produit dominent (fonctionnalités en retard, bugs business, pression du sprint). Les sujets techniques sont traités superficiellement ou pas du tout. La rétro engineering dédiée crée l'espace pour des discussions profondes sur la dette technique, les pratiques, et les compétences.",{"type":27,"tag":28,"props":856,"children":857},{},[858,863],{"type":27,"tag":74,"props":859,"children":860},{},[861],{"type":32,"value":862},"Livrable :",{"type":32,"value":864}," 3 actions d'amélioration technique priorisées pour le prochain trimestre. Trackées comme des stories dans le backlog, pas des intentions qui disparaissent dans un document Wiki.",{"type":27,"tag":55,"props":866,"children":867},{},[],{"type":27,"tag":59,"props":869,"children":871},{"id":870},"rituel-5-le-pair-programming-de-découverte",[872],{"type":32,"value":873},"Rituel 5 : Le Pair Programming de découverte",{"type":27,"tag":28,"props":875,"children":876},{},[877,881],{"type":27,"tag":74,"props":878,"children":879},{},[880],{"type":32,"value":559},{"type":32,"value":882}," une culture de collaboration et de transfert de connaissance horizontal.",{"type":27,"tag":28,"props":884,"children":885},{},[886,888,894],{"type":32,"value":887},"2 heures par semaine, 2 développeurs travaillent ensemble sur un problème, pas nécessairement pour aller plus vite, mais pour apprendre l'un de l'autre. Le ",{"type":27,"tag":198,"props":889,"children":891},{"href":890},"\u002Ffr\u002Fdette-technique\u002Fpair-programming-roi-conditions",[892],{"type":32,"value":893},"ROI du pair programming",{"type":32,"value":895}," est documenté : 15% de défauts en moins sur les tâches complexes.",{"type":27,"tag":28,"props":897,"children":898},{},[899,904],{"type":27,"tag":74,"props":900,"children":901},{},[902],{"type":32,"value":903},"La différence avec le pair programming utilitaire :",{"type":32,"value":905}," ce pair programming est intentionnellement hétérogène (junior + senior, frontend + backend, nouveau + vieux dans l'équipe) et vise le transfert de connaissance autant que le code produit.",{"type":27,"tag":28,"props":907,"children":908},{},[909,914],{"type":27,"tag":74,"props":910,"children":911},{},[912],{"type":32,"value":913},"Rotation :",{"type":32,"value":915}," une nouvelle paire chaque semaine. Sur une équipe de 8, chaque développeur travaille avec un collègue différent toutes les 4 semaines. En 6 mois, chaque développeur a travaillé avec chaque autre membre de l'équipe au moins une fois.",{"type":27,"tag":28,"props":917,"children":918},{},[919,924],{"type":27,"tag":74,"props":920,"children":921},{},[922],{"type":32,"value":923},"Ce que ce rituel prévient :",{"type":32,"value":925}," le knowledge siloing (seul X connaît ce service), l'isolement des développeurs juniors, et les tensions entre les sous-groupes de l'équipe. Dans cette organisation, ce rituel seul a réduit le bus factor sur les services critiques de 1 à 3 en moins de 6 mois.",{"type":27,"tag":55,"props":927,"children":928},{},[],{"type":27,"tag":59,"props":930,"children":932},{"id":931},"rituel-6-le-craft-backlog-visible",[933],{"type":32,"value":934},"Rituel 6 : Le Craft Backlog visible",{"type":27,"tag":28,"props":936,"children":937},{},[938,942],{"type":27,"tag":74,"props":939,"children":940},{},[941],{"type":32,"value":559},{"type":32,"value":943}," une culture de la qualité et de la viabilité à long terme du code.",{"type":27,"tag":28,"props":945,"children":946},{},[947],{"type":32,"value":948},"Un backlog visible dédié aux améliorations techniques : remboursement de dette technique, refactoring, mise à jour des dépendances, amélioration de la couverture de tests. Pas dans le backlog produit. Dans un backlog séparé, visible de tout le monde y compris du management.",{"type":27,"tag":28,"props":950,"children":951},{},[952,957],{"type":27,"tag":74,"props":953,"children":954},{},[955],{"type":32,"value":956},"Pourquoi la visibilité est clé :",{"type":32,"value":958}," la dette technique invisible n'est pas prioritarisée. La dette technique visible avec un impact estimé (en temps de développement supplémentaire et en risque business) peut être défendue auprès du leadership.",{"type":27,"tag":28,"props":960,"children":961},{},[962,967,969,975,977,982],{"type":27,"tag":74,"props":963,"children":964},{},[965],{"type":32,"value":966},"La règle du 20% :",{"type":32,"value":968}," 20% de la capacité de chaque sprint est allouée au craft backlog. Pour obtenir ce budget, consultez le guide pour ",{"type":27,"tag":198,"props":970,"children":972},{"href":971},"\u002Ffr\u002Fdette-technique\u002Fprogramme-refactoring-approuve-business",[973],{"type":32,"value":974},"faire approuver un programme de refactoring par le business",{"type":32,"value":976},". Non-négociable, comme l'investissement dans la sécurité ou les tests. Cette règle doit être défendue par le manager et le CTO auprès du business. Will Larson décrit ce principe dans ",{"type":27,"tag":524,"props":978,"children":979},{},[980],{"type":32,"value":981},"An Elegant Puzzle",{"type":32,"value":983}," : le travail de maintenance du système n'est pas un coût, c'est la condition de la vélocité future.",{"type":27,"tag":55,"props":985,"children":986},{},[],{"type":27,"tag":59,"props":988,"children":990},{"id":989},"comment-implémenter-les-6-rituels-sans-créer-de-surcharge",[991],{"type":32,"value":992},"Comment implémenter les 6 rituels sans créer de surcharge",{"type":27,"tag":28,"props":994,"children":995},{},[996,1001],{"type":27,"tag":74,"props":997,"children":998},{},[999],{"type":32,"value":1000},"Démarrer par 2, pas 6.",{"type":32,"value":1002}," Implémenter tous les rituels simultanément crée une charge d'organisation excessive et dilue l'attention. Je commence par les 2 rituels les plus adaptés à la situation actuelle de l'équipe.",{"type":27,"tag":28,"props":1004,"children":1005},{},[1006],{"type":27,"tag":74,"props":1007,"children":1008},{},[1009],{"type":32,"value":1010},"Mes recommandations par situation :",{"type":27,"tag":263,"props":1012,"children":1013},{},[1014,1019,1024,1029],{"type":27,"tag":267,"props":1015,"children":1016},{},[1017],{"type":32,"value":1018},"Équipe avec peu de sécurité psychologique → Post-mortem blameless + Pair programming de découverte",{"type":27,"tag":267,"props":1020,"children":1021},{},[1022],{"type":32,"value":1023},"Équipe avec fort knowledge siloing → Pair programming de découverte + Tech Talk mensuelle",{"type":27,"tag":267,"props":1025,"children":1026},{},[1027],{"type":32,"value":1028},"Équipe avec culture de qualité faible → Code review collective + Craft Backlog visible",{"type":27,"tag":267,"props":1030,"children":1031},{},[1032],{"type":32,"value":1033},"Équipe en forte croissance → Tech Talk mensuelle + Pair programming de découverte",{"type":27,"tag":28,"props":1035,"children":1036},{},[1037,1042],{"type":27,"tag":74,"props":1038,"children":1039},{},[1040],{"type":32,"value":1041},"Le timing réaliste :",{"type":32,"value":1043}," les rituels prennent 3 à 6 mois pour s'ancrer dans la culture. La première session est souvent maladroite. La cinquième est naturelle. La vingtième fait partie de l'identité de l'équipe.",{"type":27,"tag":28,"props":1045,"children":1046},{},[1047],{"type":32,"value":1048},"Dans ce client, après 12 mois d'implémentation progressive des 6 rituels, les signaux culturels avaient radicalement changé : les incidents étaient signalés plus tôt, la documentation avait augmenté spontanément, et 3 développeurs avaient présenté à des conférences externes, quelque chose qui n'était jamais arrivé avant. La culture ne s'était pas transformée parce qu'on avait changé les valeurs affichées. Elle s'était transformée parce qu'on avait changé les comportements répétés chaque semaine.",{"type":27,"tag":55,"props":1050,"children":1051},{},[],{"type":27,"tag":59,"props":1053,"children":1055},{"id":1054},"faq-sur-les-rituels-de-culture-engineering",[1056],{"type":32,"value":1057},"FAQ sur les rituels de culture engineering",{"type":27,"tag":393,"props":1059,"children":1060},{},[1061,1066],{"type":27,"tag":397,"props":1062,"children":1063},{},[1064],{"type":32,"value":1065},"Comment maintenir les rituels quand l'équipe est sous pression de delivery ?",{"type":27,"tag":28,"props":1067,"children":1068},{},[1069,1071,1077],{"type":32,"value":1070},"C'est précisément sous pression que les rituels sont le plus importants, et le plus menacés. Ma règle : certains rituels sont compressibles (la Tech Talk peut passer à 20 min), aucun n'est supprimable. Un post-mortem annulé envoie le message que l'apprentissage n'est pas prioritaire. La solution : prévoir des formats compressés pour les périodes de pression, pas des annulations. Consultez le ",{"type":27,"tag":198,"props":1072,"children":1074},{"href":1073},"\u002Ffr\u002Fpratiques-agiles\u002Fretrospective-agile-format-efficace",[1075],{"type":32,"value":1076},"format de rétrospective en 5 étapes",{"type":32,"value":1078}," qui génère vraiment du changement. L'habitude survit aux compressions. Elle ne survit pas aux suppressions répétées.",{"type":27,"tag":393,"props":1080,"children":1081},{},[1082,1087],{"type":27,"tag":397,"props":1083,"children":1084},{},[1085],{"type":32,"value":1086},"Ces rituels fonctionnent-ils en équipe distribuée ou full remote ?",{"type":27,"tag":28,"props":1088,"children":1089},{},[1090],{"type":32,"value":1091},"Oui, avec adaptation. Le post-mortem et la review collective fonctionnent en visioconférence. La Tech Talk est souvent plus accessible en remote (enregistrement possible). Le pair programming de découverte nécessite des outils adaptés (Live Share dans VSCode, Tuple). La rétro engineering se fait sur Miro ou Mural. Le craft backlog est naturellement digital. Le pair programming est le seul rituel qui perd en efficacité remote : compenser par des sessions plus courtes mais plus fréquentes.",{"type":27,"tag":393,"props":1093,"children":1094},{},[1095,1100],{"type":27,"tag":397,"props":1096,"children":1097},{},[1098],{"type":32,"value":1099},"Comment mesurer l'impact des rituels sur la culture ?",{"type":27,"tag":28,"props":1101,"children":1102},{},[1103],{"type":32,"value":1104},"Les métriques proxy que j'utilise : fréquence de signalement des incidents (hausse → meilleure sécurité psychologique), nombre de PR commentées par les juniors (hausse → moins de peur du feedback), rotation des knowledge owners sur le codebase (hausse → moins de siloing), nombre de sujets proposés pour les Tech Talks (hausse → curiosité intellectuelle). Ces proxy suffisent pour évaluer la direction.",{"type":27,"tag":393,"props":1106,"children":1107},{},[1108,1113],{"type":27,"tag":397,"props":1109,"children":1110},{},[1111],{"type":32,"value":1112},"Faut-il impliquer le management dans les rituels ?",{"type":27,"tag":28,"props":1114,"children":1115},{},[1116],{"type":32,"value":1117},"La présence du management aux post-mortems blameless est importante : elle signale que la direction soutient la culture d'apprentissage sans recherche de coupable. Pour les Tech Talks et les reviews collectives, la présence est optionnelle, mais l'intérêt démontré (regarder l'enregistrement, commenter) est un signal fort. Le management ne devrait jamais animer les rituels : c'est à l'équipe de se les approprier.",{"type":27,"tag":393,"props":1119,"children":1120},{},[1121,1126],{"type":27,"tag":397,"props":1122,"children":1123},{},[1124],{"type":32,"value":1125},"Que faire si les rituels ne \"prennent pas\" après 3 mois ?",{"type":27,"tag":28,"props":1127,"children":1128},{},[1129],{"type":32,"value":1130},"Trois diagnostics possibles. Le rituel n'adresse pas un problème réel de l'équipe : remplacer par un rituel plus adapté. La facilitation est insuffisante : investir dans la formation du facilitateur ou faire appel à un externe pour les premières sessions. Il y a un problème de sécurité psychologique plus profond (peur de s'exprimer, culture punitive) : les rituels ne peuvent pas fonctionner sans un niveau minimal de confiance. Résoudre d'abord le problème structurel.",{"type":27,"tag":55,"props":1132,"children":1133},{},[],{"type":27,"tag":216,"props":1135,"children":1139},{"cta":1136,"href":1137,"title":1138,"type":467},"Faire mon auto-évaluation →","\u002Fema","Ressource gratuite : Engineering Maturity Self-Assessment",[1140],{"type":27,"tag":28,"props":1141,"children":1142},{},[1143],{"type":32,"value":1144},"L'Engineering Maturity Self-Assessment couvre le domaine Culture Engineering : évaluez la maturité culturelle de votre équipe sur les rituels techniques, les pratiques de collaboration, et l'amélioration continue. Score et recommandations en 10 minutes.",{"title":8,"searchDepth":475,"depth":475,"links":1146},[1147,1148,1149,1150,1151,1152,1153,1154],{"id":548,"depth":475,"text":551},{"id":618,"depth":475,"text":621},{"id":701,"depth":475,"text":704},{"id":796,"depth":475,"text":799},{"id":870,"depth":475,"text":873},{"id":931,"depth":475,"text":934},{"id":989,"depth":475,"text":992},{"id":1054,"depth":475,"text":1057},"content:fr:management:engineering-culture-rituels.md","fr\u002Fmanagement\u002Fengineering-culture-rituels.md","fr\u002Fmanagement\u002Fengineering-culture-rituels",{"_path":1159,"_dir":1160,"_draft":7,"_partial":7,"_locale":8,"title":1161,"description":1162,"id":1163,"date":1164,"listed":13,"nocomments":7,"hidden":7,"categories":1165,"tags":1166,"cover":1168,"readingTime":1169,"body":1174,"_type":483,"_id":1803,"_source":485,"_file":1804,"_stem":1805,"_extension":488},"\u002Ffr\u002Fdette-technique\u002Fdefinition-of-done-qualite","dette-technique","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",[1160],[1167,16],"qualite","covers\u002Farticles\u002Fdefinition-of-done-qualite.jpg",{"text":1170,"minutes":1171,"time":1172,"words":1173},"8 min read",7.71,462600,1542,{"type":24,"children":1175,"toc":1793},[1176,1181,1189,1194,1197,1203,1221,1224,1230,1247,1252,1262,1280,1285,1295,1298,1304,1319,1324,1334,1344,1362,1372,1382,1392,1402,1411,1414,1425,1428,1434,1439,1449,1459,1469,1479,1488,1491,1497,1502,1512,1530,1543,1552,1555,1561,1570,1573,1579,1684,1687,1699,1702,1708,1721,1734,1755,1768,1781,1784],{"type":27,"tag":28,"props":1177,"children":1178},{},[1179],{"type":32,"value":1180},"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":27,"tag":28,"props":1182,"children":1183},{},[1184],{"type":27,"tag":74,"props":1185,"children":1186},{},[1187],{"type":32,"value":1188},"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":27,"tag":28,"props":1190,"children":1191},{},[1192],{"type":32,"value":1193},"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":27,"tag":55,"props":1195,"children":1196},{},[],{"type":27,"tag":59,"props":1198,"children":1200},{"id":1199},"avant-de-commencer-les-prérequis",[1201],{"type":32,"value":1202},"Avant de commencer : les prérequis",{"type":27,"tag":263,"props":1204,"children":1205},{},[1206,1211,1216],{"type":27,"tag":267,"props":1207,"children":1208},{},[1209],{"type":32,"value":1210},"L'équipe a déjà une DoD existante (même minimale ou informelle) à partir de laquelle progresser",{"type":27,"tag":267,"props":1212,"children":1213},{},[1214],{"type":32,"value":1215},"Le Product Owner et le Tech Lead sont impliqués dans la redéfinition",{"type":27,"tag":267,"props":1217,"children":1218},{},[1219],{"type":32,"value":1220},"L'équipe a accès aux métriques de base : taux de bugs de prod, lead time, incidents récents",{"type":27,"tag":55,"props":1222,"children":1223},{},[],{"type":27,"tag":59,"props":1225,"children":1227},{"id":1226},"étape-1-auditer-la-dod-actuelle-ou-son-absence",[1228],{"type":32,"value":1229},"Étape 1 : Auditer la DoD actuelle (ou son absence)",{"type":27,"tag":28,"props":1231,"children":1232},{},[1233,1238,1240,1245],{"type":27,"tag":74,"props":1234,"children":1235},{},[1236],{"type":32,"value":1237},"Durée estimée",{"type":32,"value":1239}," : 2 heures en atelier équipe\n",{"type":27,"tag":74,"props":1241,"children":1242},{},[1243],{"type":32,"value":1244},"Qui",{"type":32,"value":1246}," : Toute l'équipe de développement + PO + Scrum Master",{"type":27,"tag":28,"props":1248,"children":1249},{},[1250],{"type":32,"value":1251},"Avant de construire une nouvelle DoD, comprendre pourquoi l'actuelle ne fonctionne pas.",{"type":27,"tag":28,"props":1253,"children":1254},{},[1255,1260],{"type":27,"tag":74,"props":1256,"children":1257},{},[1258],{"type":32,"value":1259},"Questions à poser en atelier",{"type":32,"value":1261}," :",{"type":27,"tag":263,"props":1263,"children":1264},{},[1265,1270,1275],{"type":27,"tag":267,"props":1266,"children":1267},{},[1268],{"type":32,"value":1269},"\"Quand considérez-vous qu'une story est vraiment terminée ?\" Recueillir les réponses individuelles avant la discussion.",{"type":27,"tag":267,"props":1271,"children":1272},{},[1273],{"type":32,"value":1274},"\"Citez un bug récent de prod : quelle étape de la DoD aurait dû le détecter ?\"",{"type":27,"tag":267,"props":1276,"children":1277},{},[1278],{"type":32,"value":1279},"\"Y a-t-il des items de notre DoD actuelle que personne ne vérifie vraiment ?\"",{"type":27,"tag":28,"props":1281,"children":1282},{},[1283],{"type":32,"value":1284},"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":27,"tag":28,"props":1286,"children":1287},{},[1288,1293],{"type":27,"tag":74,"props":1289,"children":1290},{},[1291],{"type":32,"value":1292},"Résultat attendu",{"type":32,"value":1294}," : une liste de ce qui fonctionne, ce qui est contourné, et ce qui manque.",{"type":27,"tag":55,"props":1296,"children":1297},{},[],{"type":27,"tag":59,"props":1299,"children":1301},{"id":1300},"étape-2-les-7-critères-non-négociables-dune-dod-solide",[1302],{"type":32,"value":1303},"Étape 2 : Les 7 critères non-négociables d'une DoD solide",{"type":27,"tag":28,"props":1305,"children":1306},{},[1307,1311,1313,1317],{"type":27,"tag":74,"props":1308,"children":1309},{},[1310],{"type":32,"value":1237},{"type":32,"value":1312}," : 1 heure de discussion\n",{"type":27,"tag":74,"props":1314,"children":1315},{},[1316],{"type":32,"value":1244},{"type":32,"value":1318}," : Tech Lead + PO",{"type":27,"tag":28,"props":1320,"children":1321},{},[1322],{"type":32,"value":1323},"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":27,"tag":28,"props":1325,"children":1326},{},[1327,1332],{"type":27,"tag":74,"props":1328,"children":1329},{},[1330],{"type":32,"value":1331},"1. Code reviewé par au moins un pair",{"type":32,"value":1333},"\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":27,"tag":28,"props":1335,"children":1336},{},[1337,1342],{"type":27,"tag":74,"props":1338,"children":1339},{},[1340],{"type":32,"value":1341},"2. Tests automatisés écrits ou mis à jour",{"type":32,"value":1343},"\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":27,"tag":28,"props":1345,"children":1346},{},[1347,1360],{"type":27,"tag":74,"props":1348,"children":1349},{},[1350,1352,1358],{"type":32,"value":1351},"3. ",{"type":27,"tag":198,"props":1353,"children":1355},{"href":1354},"\u002Ffr\u002Fpratiques-agiles\u002Fcontinuous-integration-fondamentaux",[1356],{"type":32,"value":1357},"Build CI",{"type":32,"value":1359}," vert sur la branche",{"type":32,"value":1361},"\nÉvident mais souvent contourné \"pour gagner du temps\". Un build rouge = story non terminée, sans exception.",{"type":27,"tag":28,"props":1363,"children":1364},{},[1365,1370],{"type":27,"tag":74,"props":1366,"children":1367},{},[1368],{"type":32,"value":1369},"4. Critères d'acceptation vérifiés et documentés",{"type":32,"value":1371},"\nChaque critère d'acceptation de la story doit avoir été testé manuellement ou automatiquement. Le résultat est documenté dans le ticket.",{"type":27,"tag":28,"props":1373,"children":1374},{},[1375,1380],{"type":27,"tag":74,"props":1376,"children":1377},{},[1378],{"type":32,"value":1379},"5. Pas de régression identifiée sur les scénarios existants",{"type":32,"value":1381},"\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":27,"tag":28,"props":1383,"children":1384},{},[1385,1390],{"type":27,"tag":74,"props":1386,"children":1387},{},[1388],{"type":32,"value":1389},"6. Documentation mise à jour si applicable",{"type":32,"value":1391},"\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":27,"tag":28,"props":1393,"children":1394},{},[1395,1400],{"type":27,"tag":74,"props":1396,"children":1397},{},[1398],{"type":32,"value":1399},"7. Déployable en environnement de staging sans intervention manuelle",{"type":32,"value":1401},"\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":27,"tag":28,"props":1403,"children":1404},{},[1405,1409],{"type":27,"tag":74,"props":1406,"children":1407},{},[1408],{"type":32,"value":1292},{"type":32,"value":1410}," : une DoD de 7 items précis et actionnables.",{"type":27,"tag":55,"props":1412,"children":1413},{},[],{"type":27,"tag":216,"props":1415,"children":1419},{"cta":1416,"href":1417,"title":1418,"type":221},"Coder comme un senior →","https:\u002F\u002Fapp.kamanga.fr\u002Fforms\u002Fmentoring","Vous voulez savoir reconnaître le code qui n'est pas vraiment terminé, avant de le merger ?",[1420],{"type":27,"tag":28,"props":1421,"children":1422},{},[1423],{"type":32,"value":1424},"Juger si une PR est réellement \"Done\", ça ne se déduit pas d'une checklist : ça s'apprend à l'oeil, sur du vrai code. En mentoring 1:1, je relis vos PR avec vous et je vous montre ce qui manque (tests qui ne testent rien, cas limites oubliés, régressions silencieuses). Vous repartez avec le réflexe de voir ce qu'une DoD ne capture pas.",{"type":27,"tag":55,"props":1426,"children":1427},{},[],{"type":27,"tag":59,"props":1429,"children":1431},{"id":1430},"étape-3-lintégrer-dans-le-workflow-sans-friction",[1432],{"type":32,"value":1433},"Étape 3 : L'intégrer dans le workflow sans friction",{"type":27,"tag":28,"props":1435,"children":1436},{},[1437],{"type":32,"value":1438},"Une DoD que personne ne consulte n'existe pas. Elle doit être au bon endroit, au bon moment.",{"type":27,"tag":28,"props":1440,"children":1441},{},[1442,1447],{"type":27,"tag":74,"props":1443,"children":1444},{},[1445],{"type":32,"value":1446},"Dans Jira\u002FLinear",{"type":32,"value":1448}," : 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":27,"tag":28,"props":1450,"children":1451},{},[1452,1457],{"type":27,"tag":74,"props":1453,"children":1454},{},[1455],{"type":32,"value":1456},"Dans GitHub\u002FGitLab",{"type":32,"value":1458}," : 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":27,"tag":28,"props":1460,"children":1461},{},[1462,1467],{"type":27,"tag":74,"props":1463,"children":1464},{},[1465],{"type":32,"value":1466},"Dans le sprint review",{"type":32,"value":1468}," : 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":27,"tag":28,"props":1470,"children":1471},{},[1472,1477],{"type":27,"tag":74,"props":1473,"children":1474},{},[1475],{"type":32,"value":1476},"L'erreur à éviter",{"type":32,"value":1478}," : 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":27,"tag":28,"props":1480,"children":1481},{},[1482,1486],{"type":27,"tag":74,"props":1483,"children":1484},{},[1485],{"type":32,"value":1292},{"type":32,"value":1487}," : la DoD est intégrée dans les templates Jira et GitHub. Elle est visible au bon moment dans le workflow.",{"type":27,"tag":55,"props":1489,"children":1490},{},[],{"type":27,"tag":59,"props":1492,"children":1494},{"id":1493},"étape-4-la-faire-évoluer-chaque-trimestre",[1495],{"type":32,"value":1496},"Étape 4 : La faire évoluer chaque trimestre",{"type":27,"tag":28,"props":1498,"children":1499},{},[1500],{"type":32,"value":1501},"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":27,"tag":28,"props":1503,"children":1504},{},[1505,1510],{"type":27,"tag":74,"props":1506,"children":1507},{},[1508],{"type":32,"value":1509},"Rituel recommandé",{"type":32,"value":1511}," : une session de 1 heure par trimestre, en même temps que le trimestrial planning, pour réviser la DoD :",{"type":27,"tag":263,"props":1513,"children":1514},{},[1515,1520,1525],{"type":27,"tag":267,"props":1516,"children":1517},{},[1518],{"type":32,"value":1519},"Quels items sont systématiquement respectés ? (→ potentiellement automatisables dans la CI)",{"type":27,"tag":267,"props":1521,"children":1522},{},[1523],{"type":32,"value":1524},"Quels items sont régulièrement contournés ? (→ soit les supprimer, soit identifier pourquoi et lever le blocage)",{"type":27,"tag":267,"props":1526,"children":1527},{},[1528],{"type":32,"value":1529},"Quels items manquent compte tenu des problèmes rencontrés ce trimestre ?",{"type":27,"tag":28,"props":1531,"children":1532},{},[1533,1535,1541],{"type":32,"value":1534},"L'objectif à 12-18 mois : une DoD qui contient des items d'un ",{"type":27,"tag":198,"props":1536,"children":1538},{"href":1537},"\u002Ffr\u002Fdette-technique\u002Fintroduction-maturite-engineering-5-niveaux",[1539],{"type":32,"value":1540},"niveau 3 de maturité engineering",{"type":32,"value":1542}," : les standards de qualité sont ancrés dans les pratiques de l'équipe, pas seulement dans un document.",{"type":27,"tag":28,"props":1544,"children":1545},{},[1546,1550],{"type":27,"tag":74,"props":1547,"children":1548},{},[1549],{"type":32,"value":1292},{"type":32,"value":1551}," : une DoD vivante, révisée trimestriellement, qui progresse avec le niveau de maturité de l'équipe.",{"type":27,"tag":55,"props":1553,"children":1554},{},[],{"type":27,"tag":59,"props":1556,"children":1558},{"id":1557},"le-piège-à-éviter",[1559],{"type":32,"value":1560},"Le piège à éviter",{"type":27,"tag":1562,"props":1563,"children":1564},"blockquote",{},[1565],{"type":27,"tag":28,"props":1566,"children":1567},{},[1568],{"type":32,"value":1569},"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":27,"tag":55,"props":1571,"children":1572},{},[],{"type":27,"tag":59,"props":1574,"children":1576},{"id":1575},"en-résumé",[1577],{"type":32,"value":1578},"En résumé",{"type":27,"tag":1580,"props":1581,"children":1582},"table",{},[1583,1607],{"type":27,"tag":1584,"props":1585,"children":1586},"thead",{},[1587],{"type":27,"tag":1588,"props":1589,"children":1590},"tr",{},[1591,1597,1602],{"type":27,"tag":1592,"props":1593,"children":1594},"th",{},[1595],{"type":32,"value":1596},"Étape",{"type":27,"tag":1592,"props":1598,"children":1599},{},[1600],{"type":32,"value":1601},"Action",{"type":27,"tag":1592,"props":1603,"children":1604},{},[1605],{"type":32,"value":1606},"Résultat",{"type":27,"tag":1608,"props":1609,"children":1610},"tbody",{},[1611,1630,1648,1666],{"type":27,"tag":1588,"props":1612,"children":1613},{},[1614,1620,1625],{"type":27,"tag":1615,"props":1616,"children":1617},"td",{},[1618],{"type":32,"value":1619},"1",{"type":27,"tag":1615,"props":1621,"children":1622},{},[1623],{"type":32,"value":1624},"Auditer la DoD actuelle en atelier",{"type":27,"tag":1615,"props":1626,"children":1627},{},[1628],{"type":32,"value":1629},"Identifier les items fantômes et les manques",{"type":27,"tag":1588,"props":1631,"children":1632},{},[1633,1638,1643],{"type":27,"tag":1615,"props":1634,"children":1635},{},[1636],{"type":32,"value":1637},"2",{"type":27,"tag":1615,"props":1639,"children":1640},{},[1641],{"type":32,"value":1642},"Définir les 7 critères non-négociables",{"type":27,"tag":1615,"props":1644,"children":1645},{},[1646],{"type":32,"value":1647},"DoD précise et actionnable",{"type":27,"tag":1588,"props":1649,"children":1650},{},[1651,1656,1661],{"type":27,"tag":1615,"props":1652,"children":1653},{},[1654],{"type":32,"value":1655},"3",{"type":27,"tag":1615,"props":1657,"children":1658},{},[1659],{"type":32,"value":1660},"Intégrer dans Jira et GitHub",{"type":27,"tag":1615,"props":1662,"children":1663},{},[1664],{"type":32,"value":1665},"DoD consultée au bon moment dans le workflow",{"type":27,"tag":1588,"props":1667,"children":1668},{},[1669,1674,1679],{"type":27,"tag":1615,"props":1670,"children":1671},{},[1672],{"type":32,"value":1673},"4",{"type":27,"tag":1615,"props":1675,"children":1676},{},[1677],{"type":32,"value":1678},"Réviser chaque trimestre",{"type":27,"tag":1615,"props":1680,"children":1681},{},[1682],{"type":32,"value":1683},"DoD qui progresse avec la maturité de l'équipe",{"type":27,"tag":55,"props":1685,"children":1686},{},[],{"type":27,"tag":216,"props":1688,"children":1693},{"cta":1689,"href":1690,"title":1691,"type":1692},"Les 100 pratiques que l'IA n'enseigne pas →","https:\u002F\u002Fkamanga.fr\u002Freferentiel-craft","Une DoD solide, c'est une pratique parmi 100 autres qui font le code propre","product",[1694],{"type":27,"tag":28,"props":1695,"children":1696},{},[1697],{"type":32,"value":1698},"Définir une Definition of Done qui tient vraiment, c'est un seul réflexe de craft parmi beaucoup d'autres. Le Craft Bundle réunit les 100 pratiques que j'applique au quotidien pour coder propre, de la revue de code au découpage de stories, celles que l'IA ne vous apprendra jamais parce qu'elle ne les a jamais vues protéger une mise en prod.",{"type":27,"tag":55,"props":1700,"children":1701},{},[],{"type":27,"tag":59,"props":1703,"children":1705},{"id":1704},"faq-sur-la-definition-of-done",[1706],{"type":32,"value":1707},"FAQ sur la Definition of Done",{"type":27,"tag":393,"props":1709,"children":1710},{},[1711,1716],{"type":27,"tag":397,"props":1712,"children":1713},{},[1714],{"type":32,"value":1715},"1. Quelle est la différence entre la DoD et les critères d'acceptation ?",{"type":27,"tag":28,"props":1717,"children":1718},{},[1719],{"type":32,"value":1720},"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":27,"tag":393,"props":1722,"children":1723},{},[1724,1729],{"type":27,"tag":397,"props":1725,"children":1726},{},[1727],{"type":32,"value":1728},"2. La DoD doit-elle être la même pour tous les types de stories ?",{"type":27,"tag":28,"props":1730,"children":1731},{},[1732],{"type":32,"value":1733},"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":27,"tag":393,"props":1735,"children":1736},{},[1737,1742],{"type":27,"tag":397,"props":1738,"children":1739},{},[1740],{"type":32,"value":1741},"3. Comment gérer la résistance de l'équipe à une DoD plus stricte ?",{"type":27,"tag":28,"props":1743,"children":1744},{},[1745,1747,1753],{"type":32,"value":1746},"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":27,"tag":198,"props":1748,"children":1750},{"href":1749},"\u002Ffr\u002Fpratiques-agiles\u002Fdefinition-of-ready-bugs-sprint",[1751],{"type":32,"value":1752},"Definition of Ready absente",{"type":32,"value":1754},", 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":27,"tag":393,"props":1756,"children":1757},{},[1758,1763],{"type":27,"tag":397,"props":1759,"children":1760},{},[1761],{"type":32,"value":1762},"4. Faut-il une DoD différente par équipe dans une organisation avec plusieurs équipes ?",{"type":27,"tag":28,"props":1764,"children":1765},{},[1766],{"type":32,"value":1767},"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":27,"tag":393,"props":1769,"children":1770},{},[1771,1776],{"type":27,"tag":397,"props":1772,"children":1773},{},[1774],{"type":32,"value":1775},"5. Comment mesurer si la DoD améliore réellement la qualité ?",{"type":27,"tag":28,"props":1777,"children":1778},{},[1779],{"type":32,"value":1780},"Trois métriques à suivre avant\u002Faprè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":27,"tag":55,"props":1782,"children":1783},{},[],{"type":27,"tag":216,"props":1785,"children":1787},{"cta":1786,"href":465,"title":1138,"type":467},"Accéder à l'assessment gratuit →",[1788],{"type":27,"tag":28,"props":1789,"children":1790},{},[1791],{"type":32,"value":1792},"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":475,"depth":475,"links":1794},[1795,1796,1797,1798,1799,1800,1801,1802],{"id":1199,"depth":475,"text":1202},{"id":1226,"depth":475,"text":1229},{"id":1300,"depth":475,"text":1303},{"id":1430,"depth":475,"text":1433},{"id":1493,"depth":475,"text":1496},{"id":1557,"depth":475,"text":1560},{"id":1575,"depth":475,"text":1578},{"id":1704,"depth":475,"text":1707},"content:fr:dette-technique:definition-of-done-qualite.md","fr\u002Fdette-technique\u002Fdefinition-of-done-qualite.md","fr\u002Fdette-technique\u002Fdefinition-of-done-qualite",{"_path":343,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":1807,"description":1808,"id":1809,"date":1810,"listed":13,"nocomments":7,"hidden":7,"categories":1811,"tags":1812,"cover":1813,"readingTime":1814,"body":1818,"_type":483,"_id":2249,"_source":485,"_file":2250,"_stem":2251,"_extension":488},"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],[16],"covers\u002Farticles\u002Fstory-points-alternative.jpg",{"text":1170,"minutes":1815,"time":1816,"words":1817},7.635,458100,1527,{"type":24,"children":1819,"toc":2240},[1820,1825,1830,1835,1840,1845,1848,1854,1859,1864,1869,1874,1879,1882,1888,1898,1908,1918,1927,1930,1936,1941,1946,1989,1994,1999,2002,2008,2019,2024,2029,2034,2037,2043,2048,2058,2068,2078,2083,2086,2092,2105,2118,2128,2138,2148,2151,2157,2170,2183,2203,2216,2229,2232],{"type":27,"tag":28,"props":1821,"children":1822},{},[1823],{"type":32,"value":1824},"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":27,"tag":28,"props":1826,"children":1827},{},[1828],{"type":32,"value":1829},"Personne n'avait compris la story. Tout le monde avait suivi le senior.",{"type":27,"tag":28,"props":1831,"children":1832},{},[1833],{"type":32,"value":1834},"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":27,"tag":28,"props":1836,"children":1837},{},[1838],{"type":32,"value":1839},"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":27,"tag":28,"props":1841,"children":1842},{},[1843],{"type":32,"value":1844},"Vingt-cinq ans de terrain m'ont donné le même constat.",{"type":27,"tag":55,"props":1846,"children":1847},{},[],{"type":27,"tag":59,"props":1849,"children":1851},{"id":1850},"ce-que-les-story-points-mesurent-vraiment",[1852],{"type":32,"value":1853},"Ce que les story points mesurent vraiment",{"type":27,"tag":28,"props":1855,"children":1856},{},[1857],{"type":32,"value":1858},"Officiellement : la complexité relative d'une User Story, indépendante du temps.",{"type":27,"tag":28,"props":1860,"children":1861},{},[1862],{"type":32,"value":1863},"En pratique : l'effort perçu, filtré par les dynamiques politiques de l'équipe.",{"type":27,"tag":28,"props":1865,"children":1866},{},[1867],{"type":32,"value":1868},"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":27,"tag":28,"props":1870,"children":1871},{},[1872],{"type":32,"value":1873},"À 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":27,"tag":28,"props":1875,"children":1876},{},[1877],{"type":32,"value":1878},"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":27,"tag":55,"props":1880,"children":1881},{},[],{"type":27,"tag":59,"props":1883,"children":1885},{"id":1884},"les-3-pathologies-créées-par-les-story-points",[1886],{"type":32,"value":1887},"Les 3 pathologies créées par les story points",{"type":27,"tag":28,"props":1889,"children":1890},{},[1891,1896],{"type":27,"tag":74,"props":1892,"children":1893},{},[1894],{"type":32,"value":1895},"Pathologie 1 : La durée des sessions de planning.",{"type":32,"value":1897}," 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":27,"tag":28,"props":1899,"children":1900},{},[1901,1906],{"type":27,"tag":74,"props":1902,"children":1903},{},[1904],{"type":32,"value":1905},"Pathologie 2 : La comparaison entre équipes.",{"type":32,"value":1907}," \"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":27,"tag":28,"props":1909,"children":1910},{},[1911,1916],{"type":27,"tag":74,"props":1912,"children":1913},{},[1914],{"type":32,"value":1915},"Pathologie 3 : La dette d'estimation.",{"type":32,"value":1917}," 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":27,"tag":216,"props":1919,"children":1921},{"cta":218,"href":219,"title":1920,"type":221},"Votre vélocité monte, mais voyez-vous vraiment ce que vos estimations cachent dans votre delivery ?",[1922],{"type":27,"tag":28,"props":1923,"children":1924},{},[1925],{"type":32,"value":1926},"Une courbe de vélocité ne dit rien du gaming des estimations, des plannings poker qui s'alignent sur le senior, ni de l'écart réel entre points livrés et valeur produite. En 30 minutes de diagnostic ciblé sur votre équipe, je vous aide à révéler ces angles morts que vos métriques ne capturent pas et à prioriser les 2-3 leviers qui rendront votre planification à nouveau fiable.",{"type":27,"tag":55,"props":1928,"children":1929},{},[],{"type":27,"tag":59,"props":1931,"children":1933},{"id":1932},"lalternative-1-le-sizing-t-shirt",[1934],{"type":32,"value":1935},"L'alternative 1 : le sizing T-shirt",{"type":27,"tag":28,"props":1937,"children":1938},{},[1939],{"type":32,"value":1940},"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":27,"tag":28,"props":1942,"children":1943},{},[1944],{"type":32,"value":1945},"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":27,"tag":263,"props":1947,"children":1948},{},[1949,1959,1969,1979],{"type":27,"tag":267,"props":1950,"children":1951},{},[1952,1957],{"type":27,"tag":74,"props":1953,"children":1954},{},[1955],{"type":32,"value":1956},"S",{"type":32,"value":1958}," : terminable en moins d'un jour de développement",{"type":27,"tag":267,"props":1960,"children":1961},{},[1962,1967],{"type":27,"tag":74,"props":1963,"children":1964},{},[1965],{"type":32,"value":1966},"M",{"type":32,"value":1968}," : terminable en 1 à 3 jours",{"type":27,"tag":267,"props":1970,"children":1971},{},[1972,1977],{"type":27,"tag":74,"props":1973,"children":1974},{},[1975],{"type":32,"value":1976},"L",{"type":32,"value":1978}," : terminable en 1 semaine",{"type":27,"tag":267,"props":1980,"children":1981},{},[1982,1987],{"type":27,"tag":74,"props":1983,"children":1984},{},[1985],{"type":32,"value":1986},"XL",{"type":32,"value":1988}," : trop grande pour un sprint, doit être découpée avant d'entrer en sprint planning",{"type":27,"tag":28,"props":1990,"children":1991},{},[1992],{"type":32,"value":1993},"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":27,"tag":28,"props":1995,"children":1996},{},[1997],{"type":32,"value":1998},"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":27,"tag":55,"props":2000,"children":2001},{},[],{"type":27,"tag":59,"props":2003,"children":2005},{"id":2004},"lalternative-2-le-throughput-et-le-mouvement-noestimates",[2006],{"type":32,"value":2007},"L'alternative 2 : le throughput et le mouvement #NoEstimates",{"type":27,"tag":28,"props":2009,"children":2010},{},[2011,2013,2017],{"type":32,"value":2012},"Le mouvement #NoEstimates (Vasco Duarte, Woody Zuill) propose une approche encore plus radicale : arrêter d'estimer et mesurer la capacité à travers le ",{"type":27,"tag":74,"props":2014,"children":2015},{},[2016],{"type":32,"value":346},{"type":32,"value":2018},", c'est-à-dire le nombre de stories terminées par sprint, quelle que soit leur taille.",{"type":27,"tag":28,"props":2020,"children":2021},{},[2022],{"type":32,"value":2023},"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":27,"tag":28,"props":2025,"children":2026},{},[2027],{"type":32,"value":2028},"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":27,"tag":28,"props":2030,"children":2031},{},[2032],{"type":32,"value":2033},"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":27,"tag":55,"props":2035,"children":2036},{},[],{"type":27,"tag":59,"props":2038,"children":2040},{"id":2039},"comment-faire-la-transition-sans-casser-la-confiance-du-business",[2041],{"type":32,"value":2042},"Comment faire la transition sans casser la confiance du business",{"type":27,"tag":28,"props":2044,"children":2045},{},[2046],{"type":32,"value":2047},"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":27,"tag":28,"props":2049,"children":2050},{},[2051,2056],{"type":27,"tag":74,"props":2052,"children":2053},{},[2054],{"type":32,"value":2055},"Sprints 1-2",{"type":32,"value":2057}," : 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":27,"tag":28,"props":2059,"children":2060},{},[2061,2066],{"type":27,"tag":74,"props":2062,"children":2063},{},[2064],{"type":32,"value":2065},"Sprints 3-4",{"type":32,"value":2067}," : passer en sizing T-shirt uniquement. Montrer que la planification capacitaire reste fiable. Partager les données avec le management.",{"type":27,"tag":28,"props":2069,"children":2070},{},[2071,2076],{"type":27,"tag":74,"props":2072,"children":2073},{},[2074],{"type":32,"value":2075},"Sprints 5 et suivants",{"type":32,"value":2077}," : si l'équipe est prête et les stories sont uniformément petites, explorer le throughput comme seule métrique.",{"type":27,"tag":28,"props":2079,"children":2080},{},[2081],{"type":32,"value":2082},"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":27,"tag":55,"props":2084,"children":2085},{},[],{"type":27,"tag":59,"props":2087,"children":2089},{"id":2088},"les-métriques-qui-remplacent-avantageusement-la-vélocité",[2090],{"type":32,"value":2091},"Les métriques qui remplacent avantageusement la vélocité",{"type":27,"tag":28,"props":2093,"children":2094},{},[2095,2097,2103],{"type":32,"value":2096},"Les ",{"type":27,"tag":198,"props":2098,"children":2100},{"href":2099},"\u002Ffr\u002Fmanagement\u002Fmetriques-management-developpeurs-motivation",[2101],{"type":32,"value":2102},"recherches DORA",{"type":32,"value":2104}," (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":27,"tag":28,"props":2106,"children":2107},{},[2108,2116],{"type":27,"tag":74,"props":2109,"children":2110},{},[2111],{"type":27,"tag":198,"props":2112,"children":2113},{"href":5},[2114],{"type":32,"value":2115},"Cycle Time",{"type":32,"value":2117}," : temps entre le début du développement et le merge. Mesure la fluidité du workflow.",{"type":27,"tag":28,"props":2119,"children":2120},{},[2121,2126],{"type":27,"tag":74,"props":2122,"children":2123},{},[2124],{"type":32,"value":2125},"Throughput",{"type":32,"value":2127}," : nombre de stories terminées par sprint. Mesure la capacité réelle de livraison.",{"type":27,"tag":28,"props":2129,"children":2130},{},[2131,2136],{"type":27,"tag":74,"props":2132,"children":2133},{},[2134],{"type":32,"value":2135},"Flow Efficiency",{"type":32,"value":2137}," : pourcentage du cycle time où la story est activement travaillée versus en attente. Révèle les goulots d'étranglement invisibles.",{"type":27,"tag":28,"props":2139,"children":2140},{},[2141,2146],{"type":27,"tag":74,"props":2142,"children":2143},{},[2144],{"type":32,"value":2145},"Work Item Age",{"type":32,"value":2147}," : âge des stories en cours. Un item vieux de 3 sprints est un signal d'alerte qui mérite investigation.",{"type":27,"tag":55,"props":2149,"children":2150},{},[],{"type":27,"tag":59,"props":2152,"children":2154},{"id":2153},"faq-sur-lestimation-agile",[2155],{"type":32,"value":2156},"FAQ sur l'estimation agile",{"type":27,"tag":393,"props":2158,"children":2159},{},[2160,2165],{"type":27,"tag":397,"props":2161,"children":2162},{},[2163],{"type":32,"value":2164},"1. Peut-on abandonner les story points si le management les utilise pour les planifications budgétaires ?",{"type":27,"tag":28,"props":2166,"children":2167},{},[2168],{"type":32,"value":2169},"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":27,"tag":393,"props":2171,"children":2172},{},[2173,2178],{"type":27,"tag":397,"props":2174,"children":2175},{},[2176],{"type":32,"value":2177},"2. Le sizing T-shirt n'est-il pas trop imprécis pour planifier ?",{"type":27,"tag":28,"props":2179,"children":2180},{},[2181],{"type":32,"value":2182},"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":27,"tag":393,"props":2184,"children":2185},{},[2186,2191],{"type":27,"tag":397,"props":2187,"children":2188},{},[2189],{"type":32,"value":2190},"3. Comment gérer les stories très différentes en taille avec le sizing T-shirt ?",{"type":27,"tag":28,"props":2192,"children":2193},{},[2194,2196,2201],{"type":32,"value":2195},"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":27,"tag":198,"props":2197,"children":2198},{"href":200},[2199],{"type":32,"value":2200},"backlog sain",{"type":32,"value":2202}," 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":27,"tag":393,"props":2204,"children":2205},{},[2206,2211],{"type":27,"tag":397,"props":2207,"children":2208},{},[2209],{"type":32,"value":2210},"4. Les story points sont-ils utiles pour l'estimation initiale d'un projet ?",{"type":27,"tag":28,"props":2212,"children":2213},{},[2214],{"type":32,"value":2215},"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":27,"tag":393,"props":2217,"children":2218},{},[2219,2224],{"type":27,"tag":397,"props":2220,"children":2221},{},[2222],{"type":32,"value":2223},"5. Que faire quand les développeurs seniors refusent d'abandonner les story points ?",{"type":27,"tag":28,"props":2225,"children":2226},{},[2227],{"type":32,"value":2228},"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":27,"tag":55,"props":2230,"children":2231},{},[],{"type":27,"tag":216,"props":2233,"children":2234},{"cta":464,"href":465,"title":466,"type":467},[2235],{"type":27,"tag":28,"props":2236,"children":2237},{},[2238],{"type":32,"value":2239},"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":475,"depth":475,"links":2241},[2242,2243,2244,2245,2246,2247,2248],{"id":1850,"depth":475,"text":1853},{"id":1884,"depth":475,"text":1887},{"id":1932,"depth":475,"text":1935},{"id":2004,"depth":475,"text":2007},{"id":2039,"depth":475,"text":2042},{"id":2088,"depth":475,"text":2091},{"id":2153,"depth":475,"text":2156},"content:fr:pratiques-agiles:story-points-estimation-agile-alternative.md","fr\u002Fpratiques-agiles\u002Fstory-points-estimation-agile-alternative.md","fr\u002Fpratiques-agiles\u002Fstory-points-estimation-agile-alternative",{"_path":200,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":2253,"description":2254,"id":2255,"date":2256,"listed":13,"nocomments":7,"hidden":7,"categories":2257,"tags":2258,"cover":2260,"readingTime":2261,"body":2265,"_type":483,"_id":2690,"_source":485,"_file":2691,"_stem":2692,"_extension":488},"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.",17,"2026-02-11",[6],[16,2259],"clean-code","covers\u002Farticles\u002Fanti-patterns-backlog.jpg",{"text":1170,"minutes":2262,"time":2263,"words":2264},7.61,456600,1522,{"type":24,"children":2266,"toc":2681},[2267,2272,2277,2282,2287,2292,2295,2301,2311,2327,2337,2342,2345,2351,2360,2369,2378,2381,2387,2396,2405,2414,2447,2452,2461,2464,2470,2479,2488,2497,2502,2505,2511,2520,2529,2538,2543,2546,2552,2562,2572,2589,2592,2598,2618,2631,2644,2657,2670,2673],{"type":27,"tag":28,"props":2268,"children":2269},{},[2270],{"type":32,"value":2271},"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":27,"tag":28,"props":2273,"children":2274},{},[2275],{"type":32,"value":2276},"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":27,"tag":28,"props":2278,"children":2279},{},[2280],{"type":32,"value":2281},"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":27,"tag":28,"props":2283,"children":2284},{},[2285],{"type":32,"value":2286},"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":27,"tag":28,"props":2288,"children":2289},{},[2290],{"type":32,"value":2291},"Voici les 5 anti-patterns responsables de 90% des backlogs inutilisables, et la méthode de sortie.",{"type":27,"tag":55,"props":2293,"children":2294},{},[],{"type":27,"tag":59,"props":2296,"children":2298},{"id":2297},"anti-pattern-1-le-backlog-aspirateur",[2299],{"type":32,"value":2300},"Anti-pattern 1 : Le backlog aspirateur",{"type":27,"tag":28,"props":2302,"children":2303},{},[2304,2309],{"type":27,"tag":74,"props":2305,"children":2306},{},[2307],{"type":32,"value":2308},"Symptôme",{"type":32,"value":2310}," : 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":27,"tag":28,"props":2312,"children":2313},{},[2314,2319,2321,2325],{"type":27,"tag":74,"props":2315,"children":2316},{},[2317],{"type":32,"value":2318},"Coût",{"type":32,"value":2320}," : un backlog aspirateur génère une charge cognitive invisible. Chaque session de ",{"type":27,"tag":198,"props":2322,"children":2323},{"href":209},[2324],{"type":32,"value":212},{"type":32,"value":2326}," 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":27,"tag":28,"props":2328,"children":2329},{},[2330,2335],{"type":27,"tag":74,"props":2331,"children":2332},{},[2333],{"type":32,"value":2334},"Sortie",{"type":32,"value":2336}," : 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":27,"tag":28,"props":2338,"children":2339},{},[2340],{"type":32,"value":2341},"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":27,"tag":55,"props":2343,"children":2344},{},[],{"type":27,"tag":59,"props":2346,"children":2348},{"id":2347},"anti-pattern-2-les-stories-sans-critères-dacceptation",[2349],{"type":32,"value":2350},"Anti-pattern 2 : Les stories sans critères d'acceptation",{"type":27,"tag":28,"props":2352,"children":2353},{},[2354,2358],{"type":27,"tag":74,"props":2355,"children":2356},{},[2357],{"type":32,"value":2308},{"type":32,"value":2359}," : 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":27,"tag":28,"props":2361,"children":2362},{},[2363,2367],{"type":27,"tag":74,"props":2364,"children":2365},{},[2366],{"type":32,"value":2318},{"type":32,"value":2368}," : 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":27,"tag":28,"props":2370,"children":2371},{},[2372,2376],{"type":27,"tag":74,"props":2373,"children":2374},{},[2375],{"type":32,"value":2334},{"type":32,"value":2377}," : 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":27,"tag":55,"props":2379,"children":2380},{},[],{"type":27,"tag":59,"props":2382,"children":2384},{"id":2383},"anti-pattern-3-labsence-de-priorisation-explicite",[2385],{"type":32,"value":2386},"Anti-pattern 3 : L'absence de priorisation explicite",{"type":27,"tag":28,"props":2388,"children":2389},{},[2390,2394],{"type":27,"tag":74,"props":2391,"children":2392},{},[2393],{"type":32,"value":2308},{"type":32,"value":2395}," : 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":27,"tag":28,"props":2397,"children":2398},{},[2399,2403],{"type":27,"tag":74,"props":2400,"children":2401},{},[2402],{"type":32,"value":2318},{"type":32,"value":2404}," : 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":27,"tag":28,"props":2406,"children":2407},{},[2408,2412],{"type":27,"tag":74,"props":2409,"children":2410},{},[2411],{"type":32,"value":2334},{"type":32,"value":2413}," : priorisation explicite par une méthode cohérente. La méthode importe moins que la cohérence :",{"type":27,"tag":263,"props":2415,"children":2416},{},[2417,2427,2437],{"type":27,"tag":267,"props":2418,"children":2419},{},[2420,2425],{"type":27,"tag":74,"props":2421,"children":2422},{},[2423],{"type":32,"value":2424},"RICE",{"type":32,"value":2426}," (Reach × Impact × Confidence \u002F Effort) : chiffré, comparable",{"type":27,"tag":267,"props":2428,"children":2429},{},[2430,2435],{"type":27,"tag":74,"props":2431,"children":2432},{},[2433],{"type":32,"value":2434},"MoSCoW",{"type":32,"value":2436}," (Must\u002FShould\u002FCould\u002FWon't) : simple, rapide",{"type":27,"tag":267,"props":2438,"children":2439},{},[2440,2445],{"type":27,"tag":74,"props":2441,"children":2442},{},[2443],{"type":32,"value":2444},"Weighted Shortest Job First",{"type":32,"value":2446}," : ratio valeur\u002Feffort, utilisé dans SAFe",{"type":27,"tag":28,"props":2448,"children":2449},{},[2450],{"type":32,"value":2451},"Ce qui compte : la priorité est visible dans l'outil et mise à jour au moins une fois par sprint.",{"type":27,"tag":216,"props":2453,"children":2455},{"cta":218,"href":219,"title":2454,"type":221},"Votre backlog gonfle, mais voyez-vous vraiment ce qu'il révèle sur votre delivery ?",[2456],{"type":27,"tag":28,"props":2457,"children":2458},{},[2459],{"type":32,"value":2460},"Un backlog qui dérape est rarement le vrai problème : c'est le symptôme d'un product discovery absent, d'une priorisation floue ou d'une tension PO\u002Féquipe que vos métriques de vélocité ne montrent pas. En 30 minutes de diagnostic ciblé sur votre équipe, je vous aide à cartographier ces angles morts et à prioriser les 2-3 leviers qui assainiront durablement votre flux de delivery.",{"type":27,"tag":55,"props":2462,"children":2463},{},[],{"type":27,"tag":59,"props":2465,"children":2467},{"id":2466},"anti-pattern-4-les-epics-zombies",[2468],{"type":32,"value":2469},"Anti-pattern 4 : Les epics zombies",{"type":27,"tag":28,"props":2471,"children":2472},{},[2473,2477],{"type":27,"tag":74,"props":2474,"children":2475},{},[2476],{"type":32,"value":2308},{"type":32,"value":2478}," : 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":27,"tag":28,"props":2480,"children":2481},{},[2482,2486],{"type":27,"tag":74,"props":2483,"children":2484},{},[2485],{"type":32,"value":2318},{"type":32,"value":2487}," : 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":27,"tag":28,"props":2489,"children":2490},{},[2491,2495],{"type":27,"tag":74,"props":2492,"children":2493},{},[2494],{"type":32,"value":2334},{"type":32,"value":2496}," : 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":27,"tag":28,"props":2498,"children":2499},{},[2500],{"type":32,"value":2501},"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":27,"tag":55,"props":2503,"children":2504},{},[],{"type":27,"tag":59,"props":2506,"children":2508},{"id":2507},"anti-pattern-5-le-backlog-comme-outil-de-micro-management",[2509],{"type":32,"value":2510},"Anti-pattern 5 : Le backlog comme outil de micro-management",{"type":27,"tag":28,"props":2512,"children":2513},{},[2514,2518],{"type":27,"tag":74,"props":2515,"children":2516},{},[2517],{"type":32,"value":2308},{"type":32,"value":2519}," : 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":27,"tag":28,"props":2521,"children":2522},{},[2523,2527],{"type":27,"tag":74,"props":2524,"children":2525},{},[2526],{"type":32,"value":2318},{"type":32,"value":2528}," : 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":27,"tag":28,"props":2530,"children":2531},{},[2532,2536],{"type":27,"tag":74,"props":2533,"children":2534},{},[2535],{"type":32,"value":2334},{"type":32,"value":2537}," : 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":27,"tag":28,"props":2539,"children":2540},{},[2541],{"type":32,"value":2542},"Ce n'était jamais un problème de confiance individuelle. C'était un problème de système de pilotage inadapté.",{"type":27,"tag":55,"props":2544,"children":2545},{},[],{"type":27,"tag":59,"props":2547,"children":2549},{"id":2548},"la-méthode-backlog-détox-en-3-sessions-de-2h",[2550],{"type":32,"value":2551},"La méthode \"backlog détox\" en 3 sessions de 2h",{"type":27,"tag":28,"props":2553,"children":2554},{},[2555,2560],{"type":27,"tag":74,"props":2556,"children":2557},{},[2558],{"type":32,"value":2559},"Session 1 : Le tri brutal",{"type":32,"value":2561}," (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":27,"tag":28,"props":2563,"children":2564},{},[2565,2570],{"type":27,"tag":74,"props":2566,"children":2567},{},[2568],{"type":32,"value":2569},"Session 2 : La priorisation",{"type":32,"value":2571}," (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":27,"tag":28,"props":2573,"children":2574},{},[2575,2580,2582,2587],{"type":27,"tag":74,"props":2576,"children":2577},{},[2578],{"type":32,"value":2579},"Session 3 : La DoR",{"type":32,"value":2581}," (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":27,"tag":198,"props":2583,"children":2584},{"href":1749},[2585],{"type":32,"value":2586},"Definition of Ready",{"type":32,"value":2588},". 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":27,"tag":55,"props":2590,"children":2591},{},[],{"type":27,"tag":59,"props":2593,"children":2595},{"id":2594},"faq-sur-le-backlog-agile",[2596],{"type":32,"value":2597},"FAQ sur le backlog Agile",{"type":27,"tag":393,"props":2599,"children":2600},{},[2601,2606],{"type":27,"tag":397,"props":2602,"children":2603},{},[2604],{"type":32,"value":2605},"1. Quelle taille maximale devrait avoir un backlog ?",{"type":27,"tag":28,"props":2607,"children":2608},{},[2609,2611,2616],{"type":32,"value":2610},"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":27,"tag":198,"props":2612,"children":2613},{"href":5},[2614],{"type":32,"value":2615},"Work In Progress",{"type":32,"value":2617}," 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":27,"tag":393,"props":2619,"children":2620},{},[2621,2626],{"type":27,"tag":397,"props":2622,"children":2623},{},[2624],{"type":32,"value":2625},"2. Qui est responsable du nettoyage du backlog ?",{"type":27,"tag":28,"props":2627,"children":2628},{},[2629],{"type":32,"value":2630},"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":27,"tag":393,"props":2632,"children":2633},{},[2634,2639],{"type":27,"tag":397,"props":2635,"children":2636},{},[2637],{"type":32,"value":2638},"3. Comment convaincre un PO de supprimer des items qu'il a créés ?",{"type":27,"tag":28,"props":2640,"children":2641},{},[2642],{"type":32,"value":2643},"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":27,"tag":393,"props":2645,"children":2646},{},[2647,2652],{"type":27,"tag":397,"props":2648,"children":2649},{},[2650],{"type":32,"value":2651},"4. Faut-il un outil différent pour les \"idées futures\" séparées du backlog ?",{"type":27,"tag":28,"props":2653,"children":2654},{},[2655],{"type":32,"value":2656},"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":27,"tag":393,"props":2658,"children":2659},{},[2660,2665],{"type":27,"tag":397,"props":2661,"children":2662},{},[2663],{"type":32,"value":2664},"5. À quelle fréquence faut-il faire un backlog détox ?",{"type":27,"tag":28,"props":2666,"children":2667},{},[2668],{"type":32,"value":2669},"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":27,"tag":55,"props":2671,"children":2672},{},[],{"type":27,"tag":216,"props":2674,"children":2675},{"cta":464,"href":465,"title":466,"type":467},[2676],{"type":27,"tag":28,"props":2677,"children":2678},{},[2679],{"type":32,"value":2680},"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":475,"depth":475,"links":2682},[2683,2684,2685,2686,2687,2688,2689],{"id":2297,"depth":475,"text":2300},{"id":2347,"depth":475,"text":2350},{"id":2383,"depth":475,"text":2386},{"id":2466,"depth":475,"text":2469},{"id":2507,"depth":475,"text":2510},{"id":2548,"depth":475,"text":2551},{"id":2594,"depth":475,"text":2597},"content:fr:pratiques-agiles:anti-patterns-backlog.md","fr\u002Fpratiques-agiles\u002Fanti-patterns-backlog.md","fr\u002Fpratiques-agiles\u002Fanti-patterns-backlog",{"_path":1073,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":2694,"description":2695,"id":2696,"date":2697,"listed":13,"nocomments":7,"hidden":7,"categories":2698,"tags":2699,"cover":2700,"readingTime":2701,"body":2706,"_type":483,"_id":3062,"_source":485,"_file":3063,"_stem":3064,"_extension":488},"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",[6],[16],"covers\u002Farticles\u002Fretrospective-agile-format.jpg",{"text":2702,"minutes":2703,"time":2704,"words":2705},"7 min read",6.51,390600,1302,{"type":24,"children":2707,"toc":3056},[2708,2713,2718,2723,2728,2733,2736,2742,2747,2752,2757,2762,2765,2771,2779,2791,2796,2804,2809,2814,2819,2828,2831,2839,2844,2849,2880,2899,2907,2912,2917,2922,2930,2935,2947,2950,2956,2961,2966,2971,2974,2980,2993,3006,3019,3032,3045,3048],{"type":27,"tag":28,"props":2709,"children":2710},{},[2711],{"type":32,"value":2712},"\"Communication\", \"Documentation\", \"Tests.\"",{"type":27,"tag":28,"props":2714,"children":2715},{},[2716],{"type":32,"value":2717},"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":27,"tag":28,"props":2719,"children":2720},{},[2721],{"type":32,"value":2722},"Deux ans. Les mêmes items. Aucun changement.",{"type":27,"tag":28,"props":2724,"children":2725},{},[2726],{"type":32,"value":2727},"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":27,"tag":28,"props":2729,"children":2730},{},[2731],{"type":32,"value":2732},"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":27,"tag":55,"props":2734,"children":2735},{},[],{"type":27,"tag":59,"props":2737,"children":2739},{"id":2738},"pourquoi-les-rétros-classiques-naméliorent-rien",[2740],{"type":32,"value":2741},"Pourquoi les rétros classiques n'améliorent rien",{"type":27,"tag":28,"props":2743,"children":2744},{},[2745],{"type":32,"value":2746},"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":27,"tag":28,"props":2748,"children":2749},{},[2750],{"type":32,"value":2751},"Il n'y a pas de mémoire. Pas de continuité. Pas de suivi.",{"type":27,"tag":28,"props":2753,"children":2754},{},[2755],{"type":32,"value":2756},"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":27,"tag":28,"props":2758,"children":2759},{},[2760],{"type":32,"value":2761},"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":27,"tag":55,"props":2763,"children":2764},{},[],{"type":27,"tag":59,"props":2766,"children":2768},{"id":2767},"le-format-en-5-étapes",[2769],{"type":32,"value":2770},"Le format en 5 étapes",{"type":27,"tag":28,"props":2772,"children":2773},{},[2774],{"type":27,"tag":74,"props":2775,"children":2776},{},[2777],{"type":32,"value":2778},"Étape 1 : Préparer les données (15 min avant la rétro)",{"type":27,"tag":28,"props":2780,"children":2781},{},[2782,2784,2789],{"type":32,"value":2783},"La rétrospective commence par des faits, pas par des opinions. Le facilitateur prépare un tableau de bord simple du sprint : ",{"type":27,"tag":198,"props":2785,"children":2786},{"href":343},[2787],{"type":32,"value":2788},"vélocité",{"type":32,"value":2790}," 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":27,"tag":28,"props":2792,"children":2793},{},[2794],{"type":32,"value":2795},"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":27,"tag":28,"props":2797,"children":2798},{},[2799],{"type":27,"tag":74,"props":2800,"children":2801},{},[2802],{"type":32,"value":2803},"Étape 2 : Identifier les patterns sur 3 sprints (15 min)",{"type":27,"tag":28,"props":2805,"children":2806},{},[2807],{"type":32,"value":2808},"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":27,"tag":28,"props":2810,"children":2811},{},[2812],{"type":32,"value":2813},"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":27,"tag":28,"props":2815,"children":2816},{},[2817],{"type":32,"value":2818},"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":27,"tag":216,"props":2820,"children":2822},{"cta":218,"href":219,"title":2821,"type":221},"Vos rétros produisent des post-its depuis des mois, mais voyez-vous ce qu'elles ne disent pas sur votre équipe ?",[2823],{"type":27,"tag":28,"props":2824,"children":2825},{},[2826],{"type":32,"value":2827},"Une rétro qui tourne en rond n'est jamais le vrai problème : c'est le symptôme d'angles morts que vos métriques de delivery ne capturent pas (temps non alloué à l'amélioration, sujets trop sensibles pour le groupe, décisions sans soutien du management). En 30 minutes de diagnostic ciblé sur votre équipe, je cartographie ces angles morts et je priorise avec vous les 2-3 leviers qui débloqueront vraiment votre amélioration continue.",{"type":27,"tag":55,"props":2829,"children":2830},{},[],{"type":27,"tag":28,"props":2832,"children":2833},{},[2834],{"type":27,"tag":74,"props":2835,"children":2836},{},[2837],{"type":32,"value":2838},"Étape 3 : Voter sur 1 seul problème à résoudre (20 min)",{"type":27,"tag":28,"props":2840,"children":2841},{},[2842],{"type":32,"value":2843},"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":27,"tag":28,"props":2845,"children":2846},{},[2847],{"type":32,"value":2848},"Le format qui fonctionne :",{"type":27,"tag":2850,"props":2851,"children":2852},"ol",{},[2853,2858,2863,2868],{"type":27,"tag":267,"props":2854,"children":2855},{},[2856],{"type":32,"value":2857},"Chaque membre de l'équipe écrit 2 à 3 problèmes observés ce sprint",{"type":27,"tag":267,"props":2859,"children":2860},{},[2861],{"type":32,"value":2862},"Regrouper les items similaires (5 minutes)",{"type":27,"tag":267,"props":2864,"children":2865},{},[2866],{"type":32,"value":2867},"Vote à points : chaque membre dispose de 3 votes à distribuer librement",{"type":27,"tag":267,"props":2869,"children":2870},{},[2871,2873,2878],{"type":32,"value":2872},"Sélectionner le ",{"type":27,"tag":74,"props":2874,"children":2875},{},[2876],{"type":32,"value":2877},"1 seul item",{"type":32,"value":2879}," avec le plus de votes pour être traité ce sprint",{"type":27,"tag":28,"props":2881,"children":2882},{},[2883,2885,2890,2892,2897],{"type":32,"value":2884},"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":27,"tag":198,"props":2886,"children":2887},{"href":490},[2888],{"type":32,"value":2889},"6 rituels",{"type":32,"value":2891}," qui construisent une culture d'excellence technique. Mike Cohn l'explique dans ",{"type":27,"tag":524,"props":2893,"children":2894},{},[2895],{"type":32,"value":2896},"Succeeding with Agile",{"type":32,"value":2898}," : 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":27,"tag":28,"props":2900,"children":2901},{},[2902],{"type":27,"tag":74,"props":2903,"children":2904},{},[2905],{"type":32,"value":2906},"Étape 4 : Définir une action SMART avec un owner (15 min)",{"type":27,"tag":28,"props":2908,"children":2909},{},[2910],{"type":32,"value":2911},"Pour le problème sélectionné, définir une action qui respecte les critères SMART : spécifique, mesurable, actionnable, réaliste, temporelle.",{"type":27,"tag":28,"props":2913,"children":2914},{},[2915],{"type":32,"value":2916},"\"Améliorer la communication\" ne passe pas. \"Écrire les critères d'acceptation de 100% des stories du prochain sprint en affinage\" passe.",{"type":27,"tag":28,"props":2918,"children":2919},{},[2920],{"type":32,"value":2921},"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":27,"tag":28,"props":2923,"children":2924},{},[2925],{"type":27,"tag":74,"props":2926,"children":2927},{},[2928],{"type":32,"value":2929},"Étape 5 : Fermer le cycle à la rétro suivante (5 min)",{"type":27,"tag":28,"props":2931,"children":2932},{},[2933],{"type":32,"value":2934},"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":27,"tag":28,"props":2936,"children":2937},{},[2938,2940,2945],{"type":32,"value":2939},"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":27,"tag":198,"props":2941,"children":2942},{"href":2099},[2943],{"type":32,"value":2944},"métriques DORA",{"type":32,"value":2946}," pour ancrer ces discussions dans des données factuelles, du PDCA de Deming à l'inspect & adapt de Scrum.",{"type":27,"tag":55,"props":2948,"children":2949},{},[],{"type":27,"tag":59,"props":2951,"children":2953},{"id":2952},"ce-qui-change-réellement",[2954],{"type":32,"value":2955},"Ce qui change réellement",{"type":27,"tag":28,"props":2957,"children":2958},{},[2959],{"type":32,"value":2960},"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":27,"tag":28,"props":2962,"children":2963},{},[2964],{"type":32,"value":2965},"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":27,"tag":28,"props":2967,"children":2968},{},[2969],{"type":32,"value":2970},"Ce n'était jamais un problème d'engagement de l'équipe. C'était un problème de système.",{"type":27,"tag":55,"props":2972,"children":2973},{},[],{"type":27,"tag":59,"props":2975,"children":2977},{"id":2976},"faq-sur-la-rétrospective-agile",[2978],{"type":32,"value":2979},"FAQ sur la rétrospective Agile",{"type":27,"tag":393,"props":2981,"children":2982},{},[2983,2988],{"type":27,"tag":397,"props":2984,"children":2985},{},[2986],{"type":32,"value":2987},"1. Faut-il varier le format de rétrospective chaque sprint ?",{"type":27,"tag":28,"props":2989,"children":2990},{},[2991],{"type":32,"value":2992},"La variation de format (Start\u002FStop\u002FContinue, Mad\u002FSad\u002FGlad, 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":27,"tag":393,"props":2994,"children":2995},{},[2996,3001],{"type":27,"tag":397,"props":2997,"children":2998},{},[2999],{"type":32,"value":3000},"2. Comment rendre une rétrospective safe quand l'équipe ne se fait pas confiance ?",{"type":27,"tag":28,"props":3002,"children":3003},{},[3004],{"type":32,"value":3005},"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":27,"tag":393,"props":3007,"children":3008},{},[3009,3014],{"type":27,"tag":397,"props":3010,"children":3011},{},[3012],{"type":32,"value":3013},"3. Comment gérer un manager qui assiste aux rétros et inhibe les retours honnêtes ?",{"type":27,"tag":28,"props":3015,"children":3016},{},[3017],{"type":32,"value":3018},"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":27,"tag":393,"props":3020,"children":3021},{},[3022,3027],{"type":27,"tag":397,"props":3023,"children":3024},{},[3025],{"type":32,"value":3026},"4. Quelle est la durée idéale d'une rétrospective pour un sprint de 2 semaines ?",{"type":27,"tag":28,"props":3028,"children":3029},{},[3030],{"type":32,"value":3031},"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":27,"tag":393,"props":3033,"children":3034},{},[3035,3040],{"type":27,"tag":397,"props":3036,"children":3037},{},[3038],{"type":32,"value":3039},"5. Que faire si les sujets les plus importants sont trop sensibles pour être traités en groupe ?",{"type":27,"tag":28,"props":3041,"children":3042},{},[3043],{"type":32,"value":3044},"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":27,"tag":55,"props":3046,"children":3047},{},[],{"type":27,"tag":216,"props":3049,"children":3050},{"cta":464,"href":465,"title":466,"type":467},[3051],{"type":27,"tag":28,"props":3052,"children":3053},{},[3054],{"type":32,"value":3055},"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":475,"depth":475,"links":3057},[3058,3059,3060,3061],{"id":2738,"depth":475,"text":2741},{"id":2767,"depth":475,"text":2770},{"id":2952,"depth":475,"text":2955},{"id":2976,"depth":475,"text":2979},"content:fr:pratiques-agiles:retrospective-agile-format-efficace.md","fr\u002Fpratiques-agiles\u002Fretrospective-agile-format-efficace.md","fr\u002Fpratiques-agiles\u002Fretrospective-agile-format-efficace",{"_path":1749,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":3066,"description":3067,"id":3068,"date":3069,"listed":13,"nocomments":7,"hidden":7,"categories":3070,"tags":3071,"cover":3072,"readingTime":3073,"body":3077,"_type":483,"_id":3447,"_source":485,"_file":3448,"_stem":3449,"_extension":488},"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.",7,"2026-01-19",[6],[1167,16],"covers\u002Farticles\u002Fdefinition-of-ready.jpg",{"text":1170,"minutes":3074,"time":3075,"words":3076},7.045,422700,1409,{"type":24,"children":3078,"toc":3439},[3079,3084,3089,3094,3099,3102,3108,3113,3118,3123,3128,3131,3137,3142,3152,3162,3172,3182,3192,3197,3206,3209,3215,3220,3225,3248,3259,3264,3267,3273,3278,3283,3288,3308,3313,3316,3322,3327,3337,3347,3350,3356,3376,3389,3402,3415,3428,3431],{"type":27,"tag":28,"props":3080,"children":3081},{},[3082],{"type":32,"value":3083},"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":27,"tag":28,"props":3085,"children":3086},{},[3087],{"type":32,"value":3088},"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":27,"tag":28,"props":3090,"children":3091},{},[3092],{"type":32,"value":3093},"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":27,"tag":28,"props":3095,"children":3096},{},[3097],{"type":32,"value":3098},"La Definition of Ready est le filtre qui arrête ces bugs avant qu'ils coûtent.",{"type":27,"tag":55,"props":3100,"children":3101},{},[],{"type":27,"tag":59,"props":3103,"children":3105},{"id":3104},"ce-que-la-dor-résout-vraiment",[3106],{"type":32,"value":3107},"Ce que la DoR résout vraiment",{"type":27,"tag":28,"props":3109,"children":3110},{},[3111],{"type":32,"value":3112},"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":27,"tag":28,"props":3114,"children":3115},{},[3116],{"type":32,"value":3117},"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":27,"tag":28,"props":3119,"children":3120},{},[3121],{"type":32,"value":3122},"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":27,"tag":28,"props":3124,"children":3125},{},[3126],{"type":32,"value":3127},"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":27,"tag":55,"props":3129,"children":3130},{},[],{"type":27,"tag":59,"props":3132,"children":3134},{"id":3133},"les-5-critères-de-la-dor",[3135],{"type":32,"value":3136},"Les 5 critères de la DoR",{"type":27,"tag":28,"props":3138,"children":3139},{},[3140],{"type":32,"value":3141},"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":27,"tag":28,"props":3143,"children":3144},{},[3145,3150],{"type":27,"tag":74,"props":3146,"children":3147},{},[3148],{"type":32,"value":3149},"Critère 1 : L'objectif business est clair.",{"type":32,"value":3151}," \"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":27,"tag":28,"props":3153,"children":3154},{},[3155,3160],{"type":27,"tag":74,"props":3156,"children":3157},{},[3158],{"type":32,"value":3159},"Critère 2 : Les critères d'acceptation sont écrits.",{"type":32,"value":3161}," Au moins 3 scénarios Gherkin (Given\u002FWhen\u002FThen) 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":27,"tag":28,"props":3163,"children":3164},{},[3165,3170],{"type":27,"tag":74,"props":3166,"children":3167},{},[3168],{"type":32,"value":3169},"Critère 3 : Les dépendances sont identifiées.",{"type":32,"value":3171}," 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":27,"tag":28,"props":3173,"children":3174},{},[3175,3180],{"type":27,"tag":74,"props":3176,"children":3177},{},[3178],{"type":32,"value":3179},"Critère 4 : La story est estimable.",{"type":32,"value":3181}," 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":27,"tag":28,"props":3183,"children":3184},{},[3185,3190],{"type":27,"tag":74,"props":3186,"children":3187},{},[3188],{"type":32,"value":3189},"Critère 5 : La story est indépendante et livrable.",{"type":32,"value":3191}," 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":27,"tag":28,"props":3193,"children":3194},{},[3195],{"type":32,"value":3196},"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":27,"tag":216,"props":3198,"children":3200},{"cta":218,"href":219,"title":3199,"type":221},"Vous suivez votre vélocité, mais voyez-vous d'où viennent vraiment les bugs de vos sprints ?",[3201],{"type":27,"tag":28,"props":3202,"children":3203},{},[3204],{"type":32,"value":3205},"Vos métriques de delivery comptent les stories livrées, pas les ambiguïtés qui entrent en sprint et explosent en bugs trois semaines plus tard. En 30 minutes de diagnostic, j'examine votre processus d'affinage et d'entrée en sprint avec vous pour faire remonter les angles morts que vos dashboards ne captent pas. Vous repartez avec les 2-3 leviers prioritaires qui réduiront concrètement les bugs de vos équipes.",{"type":27,"tag":55,"props":3207,"children":3208},{},[],{"type":27,"tag":59,"props":3210,"children":3212},{"id":3211},"le-rituel-de-validation-avant-le-sprint-planning",[3213],{"type":32,"value":3214},"Le rituel de validation avant le sprint planning",{"type":27,"tag":28,"props":3216,"children":3217},{},[3218],{"type":32,"value":3219},"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":27,"tag":28,"props":3221,"children":3222},{},[3223],{"type":32,"value":3224},"Le résultat est binaire :",{"type":27,"tag":263,"props":3226,"children":3227},{},[3228,3238],{"type":27,"tag":267,"props":3229,"children":3230},{},[3231,3236],{"type":27,"tag":74,"props":3232,"children":3233},{},[3234],{"type":32,"value":3235},"Story prête",{"type":32,"value":3237}," : tous les critères sont satisfaits → elle peut entrer en sprint planning",{"type":27,"tag":267,"props":3239,"children":3240},{},[3241,3246],{"type":27,"tag":74,"props":3242,"children":3243},{},[3244],{"type":32,"value":3245},"Story non-prête",{"type":32,"value":3247}," : au moins un critère manque → elle est exclue avec une note expliquant ce qui manque",{"type":27,"tag":28,"props":3249,"children":3250},{},[3251,3253,3257],{"type":32,"value":3252},"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":27,"tag":198,"props":3254,"children":3255},{"href":209},[3256],{"type":32,"value":212},{"type":32,"value":3258}," est passé de 3h30 à 1h45 en deux sprints.",{"type":27,"tag":28,"props":3260,"children":3261},{},[3262],{"type":32,"value":3263},"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":27,"tag":55,"props":3265,"children":3266},{},[],{"type":27,"tag":59,"props":3268,"children":3270},{"id":3269},"gérer-la-pression-de-remplir-le-sprint-malgré-tout",[3271],{"type":32,"value":3272},"Gérer la pression de \"remplir le sprint malgré tout\"",{"type":27,"tag":28,"props":3274,"children":3275},{},[3276],{"type":32,"value":3277},"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":27,"tag":28,"props":3279,"children":3280},{},[3281],{"type":32,"value":3282},"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":27,"tag":28,"props":3284,"children":3285},{},[3286],{"type":32,"value":3287},"Si le sprint n'a pas assez de stories \"DoR-validées\" pour remplir la capacité de l'équipe, deux options valables :",{"type":27,"tag":2850,"props":3289,"children":3290},{},[3291,3303],{"type":27,"tag":267,"props":3292,"children":3293},{},[3294,3296,3301],{"type":32,"value":3295},"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":27,"tag":198,"props":3297,"children":3298},{"href":200},[3299],{"type":32,"value":3300},"backlog craft bien entretenu",{"type":32,"value":3302},")",{"type":27,"tag":267,"props":3304,"children":3305},{},[3306],{"type":32,"value":3307},"Réduire le périmètre du sprint plutôt que d'accepter des stories non-prêtes",{"type":27,"tag":28,"props":3309,"children":3310},{},[3311],{"type":32,"value":3312},"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":27,"tag":55,"props":3314,"children":3315},{},[],{"type":27,"tag":59,"props":3317,"children":3319},{"id":3318},"les-métriques-qui-mesurent-limpact",[3320],{"type":32,"value":3321},"Les métriques qui mesurent l'impact",{"type":27,"tag":28,"props":3323,"children":3324},{},[3325],{"type":32,"value":3326},"Deux métriques permettent de mesurer l'impact de la DoR sur la durée.",{"type":27,"tag":28,"props":3328,"children":3329},{},[3330,3335],{"type":27,"tag":74,"props":3331,"children":3332},{},[3333],{"type":32,"value":3334},"Taux de stories refusées au sprint planning",{"type":32,"value":3336}," : 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":27,"tag":28,"props":3338,"children":3339},{},[3340,3345],{"type":27,"tag":74,"props":3341,"children":3342},{},[3343],{"type":32,"value":3344},"Taux d'acceptation des stories en fin de sprint",{"type":32,"value":3346}," : 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":27,"tag":55,"props":3348,"children":3349},{},[],{"type":27,"tag":59,"props":3351,"children":3353},{"id":3352},"faq-sur-la-definition-of-ready",[3354],{"type":32,"value":3355},"FAQ sur la Definition of Ready",{"type":27,"tag":393,"props":3357,"children":3358},{},[3359,3364],{"type":27,"tag":397,"props":3360,"children":3361},{},[3362],{"type":32,"value":3363},"1. Quelle est la différence entre la DoR et la Definition of Done ?",{"type":27,"tag":28,"props":3365,"children":3366},{},[3367,3369,3374],{"type":32,"value":3368},"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":27,"tag":198,"props":3370,"children":3371},{"href":1159},[3372],{"type":32,"value":3373},"DoD",{"type":32,"value":3375}," 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":27,"tag":393,"props":3377,"children":3378},{},[3379,3384],{"type":27,"tag":397,"props":3380,"children":3381},{},[3382],{"type":32,"value":3383},"2. La DoR s'applique-t-elle aussi aux stories techniques (refactoring, infrastructure) ?",{"type":27,"tag":28,"props":3385,"children":3386},{},[3387],{"type":32,"value":3388},"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":27,"tag":393,"props":3390,"children":3391},{},[3392,3397],{"type":27,"tag":397,"props":3393,"children":3394},{},[3395],{"type":32,"value":3396},"3. Que faire si le PO résiste à rédiger des critères d'acceptation détaillés ?",{"type":27,"tag":28,"props":3398,"children":3399},{},[3400],{"type":32,"value":3401},"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":27,"tag":393,"props":3403,"children":3404},{},[3405,3410],{"type":27,"tag":397,"props":3406,"children":3407},{},[3408],{"type":32,"value":3409},"4. Comment combiner DoR et agilité dans un contexte de startup avec des requirements qui changent vite ?",{"type":27,"tag":28,"props":3411,"children":3412},{},[3413],{"type":32,"value":3414},"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":27,"tag":393,"props":3416,"children":3417},{},[3418,3423],{"type":27,"tag":397,"props":3419,"children":3420},{},[3421],{"type":32,"value":3422},"5. Quelle est la taille idéale d'une DoR ?",{"type":27,"tag":28,"props":3424,"children":3425},{},[3426],{"type":32,"value":3427},"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":27,"tag":55,"props":3429,"children":3430},{},[],{"type":27,"tag":216,"props":3432,"children":3433},{"cta":464,"href":465,"title":466,"type":467},[3434],{"type":27,"tag":28,"props":3435,"children":3436},{},[3437],{"type":32,"value":3438},"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":475,"depth":475,"links":3440},[3441,3442,3443,3444,3445,3446],{"id":3104,"depth":475,"text":3107},{"id":3133,"depth":475,"text":3136},{"id":3211,"depth":475,"text":3214},{"id":3269,"depth":475,"text":3272},{"id":3318,"depth":475,"text":3321},{"id":3352,"depth":475,"text":3355},"content:fr:pratiques-agiles:definition-of-ready-bugs-sprint.md","fr\u002Fpratiques-agiles\u002Fdefinition-of-ready-bugs-sprint.md","fr\u002Fpratiques-agiles\u002Fdefinition-of-ready-bugs-sprint",{"_path":209,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":3451,"description":3452,"id":475,"date":3453,"listed":13,"nocomments":7,"hidden":7,"categories":3454,"tags":3455,"cover":3456,"readingTime":3457,"body":3461,"_type":483,"_id":3795,"_source":485,"_file":3796,"_stem":3797,"_extension":488},"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],[16],"covers\u002Farticles\u002Fsprint-planning-efficace.jpg",{"text":2702,"minutes":3458,"time":3459,"words":3460},6.695,401700,1339,{"type":24,"children":3462,"toc":3788},[3463,3468,3473,3485,3490,3493,3499,3504,3514,3524,3534,3544,3549,3552,3558,3563,3568,3578,3589,3594,3603,3606,3612,3617,3634,3651,3661,3671,3676,3679,3685,3690,3695,3703,3706,3712,3725,3738,3751,3764,3777,3780],{"type":27,"tag":28,"props":3464,"children":3465},{},[3466],{"type":32,"value":3467},"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":27,"tag":28,"props":3469,"children":3470},{},[3471],{"type":32,"value":3472},"Ce n'était pas une exception. C'était la norme.",{"type":27,"tag":28,"props":3474,"children":3475},{},[3476,3478,3483],{"type":32,"value":3477},"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":27,"tag":198,"props":3479,"children":3480},{"href":5},[3481],{"type":32,"value":3482},"lead time",{"type":32,"value":3484}," é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":27,"tag":28,"props":3486,"children":3487},{},[3488],{"type":32,"value":3489},"Voici les 4 erreurs structurelles que je vois se répéter, et les corrections qui fonctionnent terrain.",{"type":27,"tag":55,"props":3491,"children":3492},{},[],{"type":27,"tag":59,"props":3494,"children":3496},{"id":3495},"les-4-symptômes-dun-sprint-planning-dysfonctionnel",[3497],{"type":32,"value":3498},"Les 4 symptômes d'un sprint planning dysfonctionnel",{"type":27,"tag":28,"props":3500,"children":3501},{},[3502],{"type":32,"value":3503},"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":27,"tag":28,"props":3505,"children":3506},{},[3507,3512],{"type":27,"tag":74,"props":3508,"children":3509},{},[3510],{"type":32,"value":3511},"Symptôme 1 : La durée dépasse 2 heures pour un sprint de 2 semaines.",{"type":32,"value":3513}," 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":27,"tag":28,"props":3515,"children":3516},{},[3517,3522],{"type":27,"tag":74,"props":3518,"children":3519},{},[3520],{"type":32,"value":3521},"Symptôme 2 : Les discussions portent sur l'estimation, pas sur la compréhension.",{"type":32,"value":3523}," 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":27,"tag":28,"props":3525,"children":3526},{},[3527,3532],{"type":27,"tag":74,"props":3528,"children":3529},{},[3530],{"type":32,"value":3531},"Symptôme 3 : Des stories entrent en sprint sans critères d'acceptation.",{"type":32,"value":3533}," 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":27,"tag":28,"props":3535,"children":3536},{},[3537,3542],{"type":27,"tag":74,"props":3538,"children":3539},{},[3540],{"type":32,"value":3541},"Symptôme 4 : Le scope change pendant le sprint.",{"type":32,"value":3543}," 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":27,"tag":28,"props":3545,"children":3546},{},[3547],{"type":32,"value":3548},"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":27,"tag":55,"props":3550,"children":3551},{},[],{"type":27,"tag":59,"props":3553,"children":3555},{"id":3554},"la-cause-racine-les-stories-non-affinées",[3556],{"type":32,"value":3557},"La cause racine : les stories non-affinées",{"type":27,"tag":28,"props":3559,"children":3560},{},[3561],{"type":32,"value":3562},"La cause racine de 80% des sprint plannings qui échouent est simple : les stories arrivent en sprint planning sans avoir été affinées.",{"type":27,"tag":28,"props":3564,"children":3565},{},[3566],{"type":32,"value":3567},"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":27,"tag":28,"props":3569,"children":3570},{},[3571,3576],{"type":27,"tag":74,"props":3572,"children":3573},{},[3574],{"type":32,"value":3575},"La correction",{"type":32,"value":3577}," : des sessions d'affinage dédiées, 2 fois par semaine, 45 minutes, obligatoires pour les stories candidates au prochain sprint.",{"type":27,"tag":28,"props":3579,"children":3580},{},[3581,3583,3587],{"type":32,"value":3582},"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":27,"tag":198,"props":3584,"children":3585},{"href":1749},[3586],{"type":32,"value":2586},{"type":32,"value":3588},". 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":27,"tag":28,"props":3590,"children":3591},{},[3592],{"type":32,"value":3593},"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":27,"tag":216,"props":3595,"children":3597},{"cta":218,"href":219,"title":3596,"type":221},"Vos sprints dérapent, mais voyez-vous vraiment ce qui se joue avant le planning ?",[3598],{"type":27,"tag":28,"props":3599,"children":3600},{},[3601],{"type":32,"value":3602},"Un sprint planning qui déraille ne se lit pas dans votre vélocité : il se révèle dans l'affinage bâclé, les critères d'acceptation absents, la tension PO\u002Féquipe que personne ne nomme. En 30 minutes de diagnostic ciblé sur votre équipe, je vous aide à cartographier ce que vos métriques de delivery ne capturent pas et à prioriser les 2-3 leviers qui stabiliseront vraiment vos sprints.",{"type":27,"tag":55,"props":3604,"children":3605},{},[],{"type":27,"tag":59,"props":3607,"children":3609},{"id":3608},"le-format-en-4-blocs-qui-tient-en-3-heures",[3610],{"type":32,"value":3611},"Le format en 4 blocs qui tient en 3 heures",{"type":27,"tag":28,"props":3613,"children":3614},{},[3615],{"type":32,"value":3616},"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":27,"tag":28,"props":3618,"children":3619},{},[3620,3625,3627,3632],{"type":27,"tag":74,"props":3621,"children":3622},{},[3623],{"type":32,"value":3624},"Bloc 1 (45 min) : Contexte et objectif du sprint.",{"type":32,"value":3626}," 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":27,"tag":524,"props":3628,"children":3629},{},[3630],{"type":32,"value":3631},"Scrum: The Art of Doing Twice the Work in Half the Time",{"type":32,"value":3633}," : 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":27,"tag":28,"props":3635,"children":3636},{},[3637,3642,3644,3649],{"type":27,"tag":74,"props":3638,"children":3639},{},[3640],{"type":32,"value":3641},"Bloc 2 (45 min) : Sélection des stories.",{"type":32,"value":3643}," 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":27,"tag":198,"props":3645,"children":3646},{"href":200},[3647],{"type":32,"value":3648},"backlog mal entretenu",{"type":32,"value":3650}," est la cause principale d'un planning qui dérive.",{"type":27,"tag":28,"props":3652,"children":3653},{},[3654,3659],{"type":27,"tag":74,"props":3655,"children":3656},{},[3657],{"type":32,"value":3658},"Bloc 3 (45 min) : Découpage en tâches.",{"type":32,"value":3660}," 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":27,"tag":28,"props":3662,"children":3663},{},[3664,3669],{"type":27,"tag":74,"props":3665,"children":3666},{},[3667],{"type":32,"value":3668},"Bloc 4 (45 min) : Vérification de capacité et engagement.",{"type":32,"value":3670}," 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":27,"tag":28,"props":3672,"children":3673},{},[3674],{"type":32,"value":3675},"Résultat : un planning de 3 heures maximum, un backlog de sprint réaliste, et un engagement que l'équipe peut tenir.",{"type":27,"tag":55,"props":3677,"children":3678},{},[],{"type":27,"tag":59,"props":3680,"children":3682},{"id":3681},"ce-que-ça-change-économiquement",[3683],{"type":32,"value":3684},"Ce que ça change économiquement",{"type":27,"tag":28,"props":3686,"children":3687},{},[3688],{"type":32,"value":3689},"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":27,"tag":28,"props":3691,"children":3692},{},[3693],{"type":32,"value":3694},"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":27,"tag":1562,"props":3696,"children":3697},{},[3698],{"type":27,"tag":28,"props":3699,"children":3700},{},[3701],{"type":32,"value":3702},"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":27,"tag":55,"props":3704,"children":3705},{},[],{"type":27,"tag":59,"props":3707,"children":3709},{"id":3708},"faq-sur-le-sprint-planning",[3710],{"type":32,"value":3711},"FAQ sur le sprint planning",{"type":27,"tag":393,"props":3713,"children":3714},{},[3715,3720],{"type":27,"tag":397,"props":3716,"children":3717},{},[3718],{"type":32,"value":3719},"1. Quelle est la durée idéale d'un sprint planning pour une équipe de 8 personnes ?",{"type":27,"tag":28,"props":3721,"children":3722},{},[3723],{"type":32,"value":3724},"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":27,"tag":393,"props":3726,"children":3727},{},[3728,3733],{"type":27,"tag":397,"props":3729,"children":3730},{},[3731],{"type":32,"value":3732},"2. Doit-on estimer toutes les stories en sprint planning ?",{"type":27,"tag":28,"props":3734,"children":3735},{},[3736],{"type":32,"value":3737},"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":27,"tag":393,"props":3739,"children":3740},{},[3741,3746],{"type":27,"tag":397,"props":3742,"children":3743},{},[3744],{"type":32,"value":3745},"3. Que faire si le PO arrive au planning avec un backlog non-priorisé ?",{"type":27,"tag":28,"props":3747,"children":3748},{},[3749],{"type":32,"value":3750},"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":27,"tag":393,"props":3752,"children":3753},{},[3754,3759],{"type":27,"tag":397,"props":3755,"children":3756},{},[3757],{"type":32,"value":3758},"4. Comment gérer les dépendances entre équipes dans le sprint planning ?",{"type":27,"tag":28,"props":3760,"children":3761},{},[3762],{"type":32,"value":3763},"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":27,"tag":393,"props":3765,"children":3766},{},[3767,3772],{"type":27,"tag":397,"props":3768,"children":3769},{},[3770],{"type":32,"value":3771},"5. Supprimer les story points résout-il les problèmes de sprint planning ?",{"type":27,"tag":28,"props":3773,"children":3774},{},[3775],{"type":32,"value":3776},"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":27,"tag":55,"props":3778,"children":3779},{},[],{"type":27,"tag":216,"props":3781,"children":3782},{"cta":464,"href":465,"title":466,"type":467},[3783],{"type":27,"tag":28,"props":3784,"children":3785},{},[3786],{"type":32,"value":3787},"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":475,"depth":475,"links":3789},[3790,3791,3792,3793,3794],{"id":3495,"depth":475,"text":3498},{"id":3554,"depth":475,"text":3557},{"id":3608,"depth":475,"text":3611},{"id":3681,"depth":475,"text":3684},{"id":3708,"depth":475,"text":3711},"content:fr:pratiques-agiles:sprint-planning-efficace.md","fr\u002Fpratiques-agiles\u002Fsprint-planning-efficace.md","fr\u002Fpratiques-agiles\u002Fsprint-planning-efficace",{"_path":3799,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":3800,"description":3801,"id":3802,"date":3803,"listed":13,"nocomments":7,"hidden":7,"categories":3804,"tags":3805,"cover":3806,"readingTime":3807,"body":3812,"_type":483,"_id":6584,"_source":485,"_file":6585,"_stem":6586,"_extension":488},"\u002Ffr\u002Fpratiques-agiles\u002Fadopter-behaviour-driven-development-bdd-guide-agile","Adopter le BDD, Guide complet pour des équipes agiles | Méthodologie et Outils","Découvrez comment adopter le Behaviour-Driven Development (BDD) pour améliorer la collaboration, automatiser vos tests et aligner votre équipe Agile sur les besoins métiers. Guide pratique, outils, et exemples concrets inclus.",59,"2024-12-06",[6],[16,498],"covers\u002Farticles\u002Fadopter-behaviour-driven-development-bdd-guide-agile.jpg",{"text":3808,"minutes":3809,"time":3810,"words":3811},"15 min read",14.82,889200,2964,{"type":24,"children":3813,"toc":6530},[3814,3823,3828,3833,3838,3847,3852,3862,3888,3893,3902,3907,3940,3949,3982,3991,4000,4005,4008,4017,4022,4033,4084,4097,4100,4109,4121,4130,4135,4168,4173,4230,4242,4245,4254,4259,4269,4309,4312,4319,4352,4361,4366,4369,4378,4383,4392,4410,4419,4432,4435,4444,4449,4457,4475,4484,4497,4500,4509,4514,4522,4540,4549,4562,4565,4574,4579,4587,4592,4601,4606,4615,4620,4623,4631,4654,4663,4668,4671,4680,4685,4713,4725,4728,4737,4746,4787,4796,4841,4846,4849,4858,4867,4923,4932,4979,4984,4987,4996,5039,5042,5050,5055,5064,5069,5072,5081,5090,5123,5132,5162,5171,5201,5210,5240,5243,5252,5261,5274,5283,5296,5305,5318,5327,5340,5343,5352,5357,5366,5412,5421,5695,5698,5706,5724,5733,5738,5741,5750,5797,5800,5809,5847,5850,5859,5912,5917,5920,5929,5967,5970,5979,6027,6030,6038,6061,6070,6075,6078,6087,6092,6101,6134,6137,6146,6151,6159,6192,6195,6204,6209,6217,6230,6233,6242,6247,6255,6273,6276,6285,6290,6298,6311,6314,6323,6328,6336,6349,6352,6360,6383,6392,6397,6428,6474,6487,6500,6508,6513,6516,6524],{"type":27,"tag":59,"props":3815,"children":3817},{"id":3816},"introduction-adopter-le-behaviour-driven-development-bdd",[3818],{"type":27,"tag":74,"props":3819,"children":3820},{},[3821],{"type":32,"value":3822},"Introduction : Adopter le Behaviour-Driven Development (BDD)",{"type":27,"tag":28,"props":3824,"children":3825},{},[3826],{"type":32,"value":3827},"Lors d'un audit récent chez un client dans le secteur bancaire, j'ai pris en flagrant délit le symptôme classique : 47 user stories en backlog, et pas une seule sur laquelle dev, QA et PO étaient vraiment d'accord sur le comportement attendu. Les tests passaient. Le métier renvoyait des bugs après chaque livraison. Personne ne mentait, tout le monde lisait la même story et y voyait une fonctionnalité différente.",{"type":27,"tag":28,"props":3829,"children":3830},{},[3831],{"type":32,"value":3832},"Le Behaviour-Driven Development (BDD) règle ce problème de fond. Pas en ajoutant un outil ou une cérémonie supplémentaire, mais en forçant la conversation à se tenir avant que le code n'existe, et en transformant ce qui en sort en spécification exécutable.",{"type":27,"tag":28,"props":3834,"children":3835},{},[3836],{"type":32,"value":3837},"Ce guide couvre les fondamentaux, les outils, la rédaction de scénarios Gherkin, l'automatisation et les obstacles que je rencontre systématiquement en mission.",{"type":27,"tag":59,"props":3839,"children":3841},{"id":3840},"quest-ce-que-le-behaviour-driven-development-bdd",[3842],{"type":27,"tag":74,"props":3843,"children":3844},{},[3845],{"type":32,"value":3846},"Qu’est-ce que le Behaviour-Driven Development (BDD) ?",{"type":27,"tag":28,"props":3848,"children":3849},{},[3850],{"type":32,"value":3851},"Le BDD est une méthodologie Agile qui aligne dev, QA et métier autour d'un seul artefact : le comportement attendu du logiciel, décrit en langage naturel. C'est une extension du TDD, mais le centre de gravité se déplace : on parle d'usage, plus de structure de code.",{"type":27,"tag":3853,"props":3854,"children":3856},"h3",{"id":3855},"origines-et-objectifs-du-bdd",[3857],{"type":27,"tag":74,"props":3858,"children":3859},{},[3860],{"type":32,"value":3861},"Origines et objectifs du BDD",{"type":27,"tag":28,"props":3863,"children":3864},{},[3865,3867,3872,3874,3879,3881,3886],{"type":32,"value":3866},"Dan North a formalisé le BDD au milieu des années 2000 pour régler un problème concret du TDD : les tests unitaires existaient, mais personne au métier n'aurait pu les lire ni les valider. Le BDD ramène la conversation sur le ",{"type":27,"tag":74,"props":3868,"children":3869},{},[3870],{"type":32,"value":3871},"\"quoi\"",{"type":32,"value":3873}," (quel comportement attend-on) avant le ",{"type":27,"tag":74,"props":3875,"children":3876},{},[3877],{"type":32,"value":3878},"\"comment\"",{"type":32,"value":3880},". L'ouvrage ",{"type":27,"tag":524,"props":3882,"children":3883},{},[3884],{"type":32,"value":3885},"Specification by Example",{"type":32,"value":3887}," de Gojko Adzic reste la référence que je recommande systématiquement : il montre comment les exemples concrets deviennent le langage commun entre métier et technique.",{"type":27,"tag":28,"props":3889,"children":3890},{},[3891],{"type":32,"value":3892},"Conséquence directe : les scénarios sont lisibles par le PO, exécutables par la CI, et servent de documentation vivante. Trois usages dans un seul artefact.",{"type":27,"tag":3853,"props":3894,"children":3896},{"id":3895},"différences-entre-bdd-tdd-et-atdd",[3897],{"type":27,"tag":74,"props":3898,"children":3899},{},[3900],{"type":32,"value":3901},"Différences entre BDD, TDD et ATDD",{"type":27,"tag":28,"props":3903,"children":3904},{},[3905],{"type":32,"value":3906},"Trois approches souvent confondues :",{"type":27,"tag":263,"props":3908,"children":3909},{},[3910,3920,3930],{"type":27,"tag":267,"props":3911,"children":3912},{},[3913,3918],{"type":27,"tag":74,"props":3914,"children":3915},{},[3916],{"type":32,"value":3917},"TDD (Test-Driven Development)",{"type":32,"value":3919}," : tests unitaires avant le code, focus technique. Le développeur écrit pour lui-même.",{"type":27,"tag":267,"props":3921,"children":3922},{},[3923,3928],{"type":27,"tag":74,"props":3924,"children":3925},{},[3926],{"type":32,"value":3927},"ATDD (Acceptance Test-Driven Development)",{"type":32,"value":3929}," : tests d'acceptation pour valider les exigences métier. Le métier voit, mais ne rédige pas.",{"type":27,"tag":267,"props":3931,"children":3932},{},[3933,3938],{"type":27,"tag":74,"props":3934,"children":3935},{},[3936],{"type":32,"value":3937},"BDD",{"type":32,"value":3939}," : étend l'ATDD avec des scénarios en langage naturel (Gherkin), co-rédigés par métier et technique. Le PO peut écrire un scénario sans coder.",{"type":27,"tag":3853,"props":3941,"children":3943},{"id":3942},"bénéfices-principaux-du-bdd",[3944],{"type":27,"tag":74,"props":3945,"children":3946},{},[3947],{"type":32,"value":3948},"Bénéfices principaux du BDD",{"type":27,"tag":2850,"props":3950,"children":3951},{},[3952,3962,3972],{"type":27,"tag":267,"props":3953,"children":3954},{},[3955,3960],{"type":27,"tag":74,"props":3956,"children":3957},{},[3958],{"type":32,"value":3959},"Collaboration forcée en amont",{"type":32,"value":3961}," : les Three Amigos (PO, dev, QA) doivent se mettre d'accord avant qu'une ligne de code soit écrite.",{"type":27,"tag":267,"props":3963,"children":3964},{},[3965,3970],{"type":27,"tag":74,"props":3966,"children":3967},{},[3968],{"type":32,"value":3969},"Alignement métier",{"type":32,"value":3971}," : les scénarios décrivent les attentes avec une précision qui ne laisse pas de place à l'interprétation.",{"type":27,"tag":267,"props":3973,"children":3974},{},[3975,3980],{"type":27,"tag":74,"props":3976,"children":3977},{},[3978],{"type":32,"value":3979},"Tests automatisés vivants",{"type":32,"value":3981}," : chaque scénario devient un test exécuté à chaque commit. Pas de drift entre spec et code.",{"type":27,"tag":216,"props":3983,"children":3985},{"cta":218,"href":219,"title":3984,"type":221},"Tes features passent les tests mais ratent les attentes métier, et tu ne sais pas où la conversation déraille ?",[3986],{"type":27,"tag":28,"props":3987,"children":3988},{},[3989],{"type":32,"value":3990},"L'écart entre ce que ton équipe code et ce que le métier attend ne se lit pas dans un taux de couverture : il se joue dans les stories ambiguës, les Three Amigos qui n'ont jamais lieu, les specs que personne ne relit. En 30 minutes de diagnostic, j'analyse comment ton équipe transforme un besoin en comportement livré, je te montre les angles morts que tes métriques ne capturent pas, et on priorise les 2-3 leviers qui réduiront vraiment le rework.",{"type":27,"tag":59,"props":3992,"children":3994},{"id":3993},"les-piliers-du-bdd-comprendre-définir-automatiser",[3995],{"type":27,"tag":74,"props":3996,"children":3997},{},[3998],{"type":32,"value":3999},"Les piliers du BDD : Comprendre, Définir, Automatiser",{"type":27,"tag":28,"props":4001,"children":4002},{},[4003],{"type":32,"value":4004},"Trois étapes structurent le BDD. Skipper une seule fait s'effondrer l'édifice : un scénario non discuté n'a aucune valeur, un scénario non automatisé devient obsolète en deux sprints.",{"type":27,"tag":55,"props":4006,"children":4007},{},[],{"type":27,"tag":3853,"props":4009,"children":4011},{"id":4010},"_1-comprendre-clarifier-les-besoins-grâce-à-la-collaboration",[4012],{"type":27,"tag":74,"props":4013,"children":4014},{},[4015],{"type":32,"value":4016},"1. Comprendre : Clarifier les besoins grâce à la collaboration",{"type":27,"tag":28,"props":4018,"children":4019},{},[4020],{"type":32,"value":4021},"L'étape de compréhension repose sur un dialogue actif entre PO, devs, testeurs, et parfois utilisateurs finaux.",{"type":27,"tag":4023,"props":4024,"children":4026},"h4",{"id":4025},"outils-et-pratiques-clés",[4027,4032],{"type":27,"tag":74,"props":4028,"children":4029},{},[4030],{"type":32,"value":4031},"Outils et pratiques clés",{"type":32,"value":1261},{"type":27,"tag":263,"props":4034,"children":4035},{},[4036,4046,4056],{"type":27,"tag":267,"props":4037,"children":4038},{},[4039,4044],{"type":27,"tag":74,"props":4040,"children":4041},{},[4042],{"type":32,"value":4043},"Workshops collaboratifs",{"type":32,"value":4045}," : aligner métier et technique avant que le développement ne démarre.",{"type":27,"tag":267,"props":4047,"children":4048},{},[4049,4054],{"type":27,"tag":74,"props":4050,"children":4051},{},[4052],{"type":32,"value":4053},"Méthode des \"Three Amigos\"",{"type":32,"value":4055}," : un PO, un dev et un testeur examinent chaque user story ensemble pour identifier les comportements attendus et écarter les ambiguïtés.",{"type":27,"tag":267,"props":4057,"children":4058},{},[4059,4064,4066],{"type":27,"tag":74,"props":4060,"children":4061},{},[4062],{"type":32,"value":4063},"Trois questions à poser systématiquement",{"type":32,"value":4065}," :\n",{"type":27,"tag":263,"props":4067,"children":4068},{},[4069,4074,4079],{"type":27,"tag":267,"props":4070,"children":4071},{},[4072],{"type":32,"value":4073},"Que doit faire le logiciel dans ce cas précis ?",{"type":27,"tag":267,"props":4075,"children":4076},{},[4077],{"type":32,"value":4078},"Quels comportements sont prioritaires ?",{"type":27,"tag":267,"props":4080,"children":4081},{},[4082],{"type":32,"value":4083},"Quels sont les critères de succès ?",{"type":27,"tag":1562,"props":4085,"children":4086},{},[4087],{"type":27,"tag":28,"props":4088,"children":4089},{},[4090,4095],{"type":27,"tag":74,"props":4091,"children":4092},{},[4093],{"type":32,"value":4094},"Objectif",{"type":32,"value":4096}," : aboutir à une compréhension commune avant de rédiger quoi que ce soit.",{"type":27,"tag":55,"props":4098,"children":4099},{},[],{"type":27,"tag":3853,"props":4101,"children":4103},{"id":4102},"_2-définir-rédiger-des-scénarios-en-langage-naturel-gherkin",[4104],{"type":27,"tag":74,"props":4105,"children":4106},{},[4107],{"type":32,"value":4108},"2. Définir : Rédiger des scénarios en langage naturel (Gherkin)",{"type":27,"tag":28,"props":4110,"children":4111},{},[4112,4114,4119],{"type":32,"value":4113},"Une fois les besoins clarifiés, on formalise les comportements attendus sous forme de ",{"type":27,"tag":74,"props":4115,"children":4116},{},[4117],{"type":32,"value":4118},"scénarios BDD",{"type":32,"value":4120},", dans un langage lisible par tous. Gherkin est le standard de facto.",{"type":27,"tag":4023,"props":4122,"children":4124},{"id":4123},"structure-dun-scénario-gherkin",[4125],{"type":27,"tag":74,"props":4126,"children":4127},{},[4128],{"type":32,"value":4129},"Structure d’un scénario Gherkin :",{"type":27,"tag":28,"props":4131,"children":4132},{},[4133],{"type":32,"value":4134},"Chaque scénario tient en trois étapes :",{"type":27,"tag":263,"props":4136,"children":4137},{},[4138,4148,4158],{"type":27,"tag":267,"props":4139,"children":4140},{},[4141,4146],{"type":27,"tag":74,"props":4142,"children":4143},{},[4144],{"type":32,"value":4145},"Given",{"type":32,"value":4147}," : le contexte initial ou les prérequis.",{"type":27,"tag":267,"props":4149,"children":4150},{},[4151,4156],{"type":27,"tag":74,"props":4152,"children":4153},{},[4154],{"type":32,"value":4155},"When",{"type":32,"value":4157}," : l'action ou l'événement déclencheur.",{"type":27,"tag":267,"props":4159,"children":4160},{},[4161,4166],{"type":27,"tag":74,"props":4162,"children":4163},{},[4164],{"type":32,"value":4165},"Then",{"type":32,"value":4167}," : le résultat attendu.",{"type":27,"tag":28,"props":4169,"children":4170},{},[4171],{"type":32,"value":4172},"Exemple simple pour un scénario d’authentification :",{"type":27,"tag":4174,"props":4175,"children":4179},"pre",{"className":4176,"code":4177,"language":4178,"meta":8,"style":8},"language-gherkin shiki shiki-themes catppuccin-frappe github-dark","Feature: Authentification utilisateur  \n  Scenario: Connexion réussie  \n    Given l'utilisateur est sur la page de connexion  \n    When il saisit un identifiant valide et un mot de passe valide  \n    Then il est redirigé vers son tableau de bord  \n","gherkin",[4180],{"type":27,"tag":4181,"props":4182,"children":4183},"code",{"__ignoreMap":8},[4184,4195,4203,4212,4221],{"type":27,"tag":4185,"props":4186,"children":4189},"span",{"class":4187,"line":4188},"line",1,[4190],{"type":27,"tag":4185,"props":4191,"children":4192},{},[4193],{"type":32,"value":4194},"Feature: Authentification utilisateur  \n",{"type":27,"tag":4185,"props":4196,"children":4197},{"class":4187,"line":475},[4198],{"type":27,"tag":4185,"props":4199,"children":4200},{},[4201],{"type":32,"value":4202},"  Scenario: Connexion réussie  \n",{"type":27,"tag":4185,"props":4204,"children":4206},{"class":4187,"line":4205},3,[4207],{"type":27,"tag":4185,"props":4208,"children":4209},{},[4210],{"type":32,"value":4211},"    Given l'utilisateur est sur la page de connexion  \n",{"type":27,"tag":4185,"props":4213,"children":4215},{"class":4187,"line":4214},4,[4216],{"type":27,"tag":4185,"props":4217,"children":4218},{},[4219],{"type":32,"value":4220},"    When il saisit un identifiant valide et un mot de passe valide  \n",{"type":27,"tag":4185,"props":4222,"children":4224},{"class":4187,"line":4223},5,[4225],{"type":27,"tag":4185,"props":4226,"children":4227},{},[4228],{"type":32,"value":4229},"    Then il est redirigé vers son tableau de bord\n",{"type":27,"tag":1562,"props":4231,"children":4232},{},[4233],{"type":27,"tag":28,"props":4234,"children":4235},{},[4236,4240],{"type":27,"tag":74,"props":4237,"children":4238},{},[4239],{"type":32,"value":4094},{"type":32,"value":4241}," : produire des scénarios clairs qui décrivent les comportements métier sans jargon technique.",{"type":27,"tag":55,"props":4243,"children":4244},{},[],{"type":27,"tag":3853,"props":4246,"children":4248},{"id":4247},"_3-automatiser-transformer-les-scénarios-en-tests-automatisés",[4249],{"type":27,"tag":74,"props":4250,"children":4251},{},[4252],{"type":32,"value":4253},"3. Automatiser : Transformer les scénarios en tests automatisés",{"type":27,"tag":28,"props":4255,"children":4256},{},[4257],{"type":32,"value":4258},"Sans automatisation, les scénarios deviennent du texte mort. Cucumber, SpecFlow ou Behave exécutent les scénarios Gherkin comme tests, et garantissent que les comportements spécifiés tiennent à chaque commit.",{"type":27,"tag":4260,"props":4261,"children":4263},"h5",{"id":4262},"étapes-de-lautomatisation",[4264],{"type":27,"tag":74,"props":4265,"children":4266},{},[4267],{"type":32,"value":4268},"Étapes de l’automatisation :",{"type":27,"tag":2850,"props":4270,"children":4271},{},[4272,4282,4299],{"type":27,"tag":267,"props":4273,"children":4274},{},[4275,4280],{"type":27,"tag":74,"props":4276,"children":4277},{},[4278],{"type":32,"value":4279},"Implémenter chaque étape (Given, When, Then)",{"type":32,"value":4281}," avec un step definition qui reproduit l'action ou vérifie le résultat.",{"type":27,"tag":267,"props":4283,"children":4284},{},[4285,4290,4292,4297],{"type":27,"tag":74,"props":4286,"children":4287},{},[4288],{"type":32,"value":4289},"Exécuter les tests",{"type":32,"value":4291}," dans un ",{"type":27,"tag":198,"props":4293,"children":4294},{"href":1354},[4295],{"type":32,"value":4296},"pipeline CI\u002FCD",{"type":32,"value":4298}," pour détecter les régressions dès le commit.",{"type":27,"tag":267,"props":4300,"children":4301},{},[4302,4307],{"type":27,"tag":74,"props":4303,"children":4304},{},[4305],{"type":32,"value":4306},"Maintenir les scénarios",{"type":32,"value":4308}," au fil des évolutions du logiciel. Sinon ils deviennent du bruit en deux mois.",{"type":27,"tag":55,"props":4310,"children":4311},{},[],{"type":27,"tag":3853,"props":4313,"children":4314},{"id":1575},[4315],{"type":27,"tag":74,"props":4316,"children":4317},{},[4318],{"type":32,"value":1578},{"type":27,"tag":263,"props":4320,"children":4321},{},[4322,4332,4342],{"type":27,"tag":267,"props":4323,"children":4324},{},[4325,4330],{"type":27,"tag":74,"props":4326,"children":4327},{},[4328],{"type":32,"value":4329},"Comprendre",{"type":32,"value":4331}," : aligner toute l'équipe sur la même vision des comportements attendus.",{"type":27,"tag":267,"props":4333,"children":4334},{},[4335,4340],{"type":27,"tag":74,"props":4336,"children":4337},{},[4338],{"type":32,"value":4339},"Définir",{"type":32,"value":4341}," : formaliser ces comportements en scénarios lisibles et exécutables.",{"type":27,"tag":267,"props":4343,"children":4344},{},[4345,4350],{"type":27,"tag":74,"props":4346,"children":4347},{},[4348],{"type":32,"value":4349},"Automatiser",{"type":32,"value":4351}," : transformer les scénarios en tests joués à chaque itération.",{"type":27,"tag":59,"props":4353,"children":4355},{"id":4354},"rôle-des-parties-prenantes-dans-le-bdd",[4356],{"type":27,"tag":74,"props":4357,"children":4358},{},[4359],{"type":32,"value":4360},"Rôle des parties prenantes dans le BDD",{"type":27,"tag":28,"props":4362,"children":4363},{},[4364],{"type":32,"value":4365},"Le BDD ne fonctionne que si les trois rôles principaux jouent vraiment leur partition. Quand le PO délègue la rédaction des scénarios au dev, ou que le QA arrive en fin de sprint, on retombe dans le mode classique : specs en silo, bugs après livraison.",{"type":27,"tag":55,"props":4367,"children":4368},{},[],{"type":27,"tag":3853,"props":4370,"children":4372},{"id":4371},"_1-product-owner-le-garant-des-besoins-métiers",[4373],{"type":27,"tag":74,"props":4374,"children":4375},{},[4376],{"type":32,"value":4377},"1. Product Owner : Le garant des besoins métiers",{"type":27,"tag":28,"props":4379,"children":4380},{},[4381],{"type":32,"value":4382},"Le PO porte la voix du métier dans la salle.",{"type":27,"tag":4023,"props":4384,"children":4386},{"id":4385},"rôles-spécifiques",[4387],{"type":27,"tag":74,"props":4388,"children":4389},{},[4390],{"type":32,"value":4391},"Rôles spécifiques :",{"type":27,"tag":263,"props":4393,"children":4394},{},[4395,4400,4405],{"type":27,"tag":267,"props":4396,"children":4397},{},[4398],{"type":32,"value":4399},"Définir l'objectif métier derrière chaque user story.",{"type":27,"tag":267,"props":4401,"children":4402},{},[4403],{"type":32,"value":4404},"Participer aux discussions sur les scénarios pour s'assurer qu'ils reflètent les vrais besoins.",{"type":27,"tag":267,"props":4406,"children":4407},{},[4408],{"type":32,"value":4409},"Prioriser les scénarios selon leur valeur métier.",{"type":27,"tag":4023,"props":4411,"children":4413},{"id":4412},"pratiques-utiles-pour-les-po",[4414],{"type":27,"tag":74,"props":4415,"children":4416},{},[4417],{"type":32,"value":4418},"Pratiques utiles pour les PO :",{"type":27,"tag":263,"props":4420,"children":4421},{},[4422,4427],{"type":27,"tag":267,"props":4423,"children":4424},{},[4425],{"type":32,"value":4426},"Apporter des exemples concrets en atelier, pas des cas abstraits.",{"type":27,"tag":267,"props":4428,"children":4429},{},[4430],{"type":32,"value":4431},"Valider chaque scénario avant qu'il ne parte en automatisation.",{"type":27,"tag":55,"props":4433,"children":4434},{},[],{"type":27,"tag":3853,"props":4436,"children":4438},{"id":4437},"_2-développeurs-les-artisans-des-tests-automatisés",[4439],{"type":27,"tag":74,"props":4440,"children":4441},{},[4442],{"type":32,"value":4443},"2. Développeurs : Les artisans des tests automatisés",{"type":27,"tag":28,"props":4445,"children":4446},{},[4447],{"type":32,"value":4448},"Les développeurs traduisent les scénarios en tests exécutables et les intègrent dans le pipeline.",{"type":27,"tag":4023,"props":4450,"children":4452},{"id":4451},"rôles-spécifiques-1",[4453],{"type":27,"tag":74,"props":4454,"children":4455},{},[4456],{"type":32,"value":4391},{"type":27,"tag":263,"props":4458,"children":4459},{},[4460,4465,4470],{"type":27,"tag":267,"props":4461,"children":4462},{},[4463],{"type":32,"value":4464},"Collaborer avec PO et QA pour saisir l'intention derrière le comportement.",{"type":27,"tag":267,"props":4466,"children":4467},{},[4468],{"type":32,"value":4469},"Implémenter les step definitions (Given, When, Then).",{"type":27,"tag":267,"props":4471,"children":4472},{},[4473],{"type":32,"value":4474},"Garder les scénarios alignés sur le code en cas d'évolution.",{"type":27,"tag":4023,"props":4476,"children":4478},{"id":4477},"pratiques-utiles-pour-les-développeurs",[4479],{"type":27,"tag":74,"props":4480,"children":4481},{},[4482],{"type":32,"value":4483},"Pratiques utiles pour les développeurs :",{"type":27,"tag":263,"props":4485,"children":4486},{},[4487,4492],{"type":27,"tag":267,"props":4488,"children":4489},{},[4490],{"type":32,"value":4491},"Pair-tester avec le QA lors de l'écriture des step definitions.",{"type":27,"tag":267,"props":4493,"children":4494},{},[4495],{"type":32,"value":4496},"Câbler les tests BDD dans la CI dès le premier scénario, pas après.",{"type":27,"tag":55,"props":4498,"children":4499},{},[],{"type":27,"tag":3853,"props":4501,"children":4503},{"id":4502},"_3-testeursqa-les-gardiens-de-la-qualité",[4504],{"type":27,"tag":74,"props":4505,"children":4506},{},[4507],{"type":32,"value":4508},"3. Testeurs\u002FQA : Les gardiens de la qualité",{"type":27,"tag":28,"props":4510,"children":4511},{},[4512],{"type":32,"value":4513},"Le QA traque les cas que ni le PO ni le dev n'avaient anticipés.",{"type":27,"tag":4023,"props":4515,"children":4517},{"id":4516},"rôles-spécifiques-2",[4518],{"type":27,"tag":74,"props":4519,"children":4520},{},[4521],{"type":32,"value":4391},{"type":27,"tag":263,"props":4523,"children":4524},{},[4525,4530,4535],{"type":27,"tag":267,"props":4526,"children":4527},{},[4528],{"type":32,"value":4529},"Identifier les cas limites et comportements inattendus.",{"type":27,"tag":267,"props":4531,"children":4532},{},[4533],{"type":32,"value":4534},"Pousser dans la conversation les critères non fonctionnels (perf, sécurité).",{"type":27,"tag":267,"props":4536,"children":4537},{},[4538],{"type":32,"value":4539},"Compléter par des tests manuels exploratoires quand l'automatisation n'a pas de sens.",{"type":27,"tag":4023,"props":4541,"children":4543},{"id":4542},"pratiques-utiles-pour-les-testeurs",[4544],{"type":27,"tag":74,"props":4545,"children":4546},{},[4547],{"type":32,"value":4548},"Pratiques utiles pour les testeurs :",{"type":27,"tag":263,"props":4550,"children":4551},{},[4552,4557],{"type":27,"tag":267,"props":4553,"children":4554},{},[4555],{"type":32,"value":4556},"Organiser des revues régulières des scénarios avec PO et devs.",{"type":27,"tag":267,"props":4558,"children":4559},{},[4560],{"type":32,"value":4561},"Analyser les résultats CI pour détecter les drifts précocement.",{"type":27,"tag":55,"props":4563,"children":4564},{},[],{"type":27,"tag":3853,"props":4566,"children":4568},{"id":4567},"_4-collaboration-le-ciment-du-bdd",[4569],{"type":27,"tag":74,"props":4570,"children":4571},{},[4572],{"type":32,"value":4573},"4. Collaboration : Le ciment du BDD",{"type":27,"tag":28,"props":4575,"children":4576},{},[4577],{"type":32,"value":4578},"Le BDD se joue dans la discussion, pas dans le document. Trois pratiques font la différence :",{"type":27,"tag":4023,"props":4580,"children":4582},{"id":4581},"workshops-collaboratifs",[4583],{"type":27,"tag":74,"props":4584,"children":4585},{},[4586],{"type":32,"value":4043},{"type":27,"tag":28,"props":4588,"children":4589},{},[4590],{"type":32,"value":4591},"Co-construire les scénarios en réunissant PO, dev et QA autour d'un même tableau.",{"type":27,"tag":4023,"props":4593,"children":4595},{"id":4594},"méthode-des-three-amigos",[4596],{"type":27,"tag":74,"props":4597,"children":4598},{},[4599],{"type":32,"value":4600},"Méthode des Three Amigos",{"type":27,"tag":28,"props":4602,"children":4603},{},[4604],{"type":32,"value":4605},"Trois personnes, une user story, une demi-heure : on en sort avec les scénarios clés.",{"type":27,"tag":4023,"props":4607,"children":4609},{"id":4608},"outils-collaboratifs",[4610],{"type":27,"tag":74,"props":4611,"children":4612},{},[4613],{"type":32,"value":4614},"Outils collaboratifs",{"type":27,"tag":28,"props":4616,"children":4617},{},[4618],{"type":32,"value":4619},"Jira, Confluence, Xray pour Jira : centraliser la rédaction et la validation des scénarios là où l'équipe travaille déjà.",{"type":27,"tag":55,"props":4621,"children":4622},{},[],{"type":27,"tag":3853,"props":4624,"children":4626},{"id":4625},"en-résumé-1",[4627],{"type":27,"tag":74,"props":4628,"children":4629},{},[4630],{"type":32,"value":1578},{"type":27,"tag":263,"props":4632,"children":4633},{},[4634,4639,4644,4649],{"type":27,"tag":267,"props":4635,"children":4636},{},[4637],{"type":32,"value":4638},"Le PO garantit que les scénarios reflètent les besoins métiers.",{"type":27,"tag":267,"props":4640,"children":4641},{},[4642],{"type":32,"value":4643},"Les développeurs traduisent ces scénarios en tests automatisés.",{"type":27,"tag":267,"props":4645,"children":4646},{},[4647],{"type":32,"value":4648},"Les QA s'assurent que chaque scénario couvre les cas critiques.",{"type":27,"tag":267,"props":4650,"children":4651},{},[4652],{"type":32,"value":4653},"Les workshops et Three Amigos donnent la cohérence et l'alignement.",{"type":27,"tag":59,"props":4655,"children":4657},{"id":4656},"comment-rédiger-des-scénarios-bdd-en-gherkin",[4658],{"type":27,"tag":74,"props":4659,"children":4660},{},[4661],{"type":32,"value":4662},"Comment rédiger des scénarios BDD en Gherkin",{"type":27,"tag":28,"props":4664,"children":4665},{},[4666],{"type":32,"value":4667},"Gherkin offre une structure simple pour décrire les comportements attendus. Voici les bases, avec des exemples graduels.",{"type":27,"tag":55,"props":4669,"children":4670},{},[],{"type":27,"tag":3853,"props":4672,"children":4674},{"id":4673},"les-principes-fondamentaux-de-gherkin",[4675],{"type":27,"tag":74,"props":4676,"children":4677},{},[4678],{"type":32,"value":4679},"Les principes fondamentaux de Gherkin",{"type":27,"tag":28,"props":4681,"children":4682},{},[4683],{"type":32,"value":4684},"Trois mots-clés principaux pour décrire un scénario :",{"type":27,"tag":263,"props":4686,"children":4687},{},[4688,4697,4705],{"type":27,"tag":267,"props":4689,"children":4690},{},[4691,4695],{"type":27,"tag":74,"props":4692,"children":4693},{},[4694],{"type":32,"value":4145},{"type":32,"value":4696}," : le contexte ou les conditions initiales.",{"type":27,"tag":267,"props":4698,"children":4699},{},[4700,4704],{"type":27,"tag":74,"props":4701,"children":4702},{},[4703],{"type":32,"value":4155},{"type":32,"value":4157},{"type":27,"tag":267,"props":4706,"children":4707},{},[4708,4712],{"type":27,"tag":74,"props":4709,"children":4710},{},[4711],{"type":32,"value":4165},{"type":32,"value":4167},{"type":27,"tag":28,"props":4714,"children":4715},{},[4716,4718,4723],{"type":32,"value":4717},"Chaque scénario s'inscrit dans une ",{"type":27,"tag":74,"props":4719,"children":4720},{},[4721],{"type":32,"value":4722},"feature",{"type":32,"value":4724}," qui regroupe les cas d'utilisation d'une même fonctionnalité. Règle d'or : un scénario doit tenir sur un écran et rester lisible par un non-technicien.",{"type":27,"tag":55,"props":4726,"children":4727},{},[],{"type":27,"tag":3853,"props":4729,"children":4731},{"id":4730},"exemples-simples",[4732],{"type":27,"tag":74,"props":4733,"children":4734},{},[4735],{"type":32,"value":4736},"Exemples simples",{"type":27,"tag":4023,"props":4738,"children":4740},{"id":4739},"scénario-1-connexion-réussie",[4741],{"type":27,"tag":74,"props":4742,"children":4743},{},[4744],{"type":32,"value":4745},"Scénario 1 : Connexion réussie",{"type":27,"tag":4174,"props":4747,"children":4748},{"className":4176,"code":4177,"language":4178,"meta":8,"style":8},[4749],{"type":27,"tag":4181,"props":4750,"children":4751},{"__ignoreMap":8},[4752,4759,4766,4773,4780],{"type":27,"tag":4185,"props":4753,"children":4754},{"class":4187,"line":4188},[4755],{"type":27,"tag":4185,"props":4756,"children":4757},{},[4758],{"type":32,"value":4194},{"type":27,"tag":4185,"props":4760,"children":4761},{"class":4187,"line":475},[4762],{"type":27,"tag":4185,"props":4763,"children":4764},{},[4765],{"type":32,"value":4202},{"type":27,"tag":4185,"props":4767,"children":4768},{"class":4187,"line":4205},[4769],{"type":27,"tag":4185,"props":4770,"children":4771},{},[4772],{"type":32,"value":4211},{"type":27,"tag":4185,"props":4774,"children":4775},{"class":4187,"line":4214},[4776],{"type":27,"tag":4185,"props":4777,"children":4778},{},[4779],{"type":32,"value":4220},{"type":27,"tag":4185,"props":4781,"children":4782},{"class":4187,"line":4223},[4783],{"type":27,"tag":4185,"props":4784,"children":4785},{},[4786],{"type":32,"value":4229},{"type":27,"tag":4023,"props":4788,"children":4790},{"id":4789},"scénario-2-échec-de-connexion",[4791],{"type":27,"tag":74,"props":4792,"children":4793},{},[4794],{"type":32,"value":4795},"Scénario 2 : Échec de connexion",{"type":27,"tag":4174,"props":4797,"children":4799},{"className":4176,"code":4798,"language":4178,"meta":8,"style":8},"Feature: Authentification utilisateur  \n  Scenario: Échec de connexion avec un mot de passe incorrect  \n    Given l'utilisateur est sur la page de connexion  \n    When il saisit un identifiant valide et un mot de passe incorrect  \n    Then un message d'erreur \"Mot de passe incorrect\" est affiché  \n",[4800],{"type":27,"tag":4181,"props":4801,"children":4802},{"__ignoreMap":8},[4803,4810,4818,4825,4833],{"type":27,"tag":4185,"props":4804,"children":4805},{"class":4187,"line":4188},[4806],{"type":27,"tag":4185,"props":4807,"children":4808},{},[4809],{"type":32,"value":4194},{"type":27,"tag":4185,"props":4811,"children":4812},{"class":4187,"line":475},[4813],{"type":27,"tag":4185,"props":4814,"children":4815},{},[4816],{"type":32,"value":4817},"  Scenario: Échec de connexion avec un mot de passe incorrect  \n",{"type":27,"tag":4185,"props":4819,"children":4820},{"class":4187,"line":4205},[4821],{"type":27,"tag":4185,"props":4822,"children":4823},{},[4824],{"type":32,"value":4211},{"type":27,"tag":4185,"props":4826,"children":4827},{"class":4187,"line":4214},[4828],{"type":27,"tag":4185,"props":4829,"children":4830},{},[4831],{"type":32,"value":4832},"    When il saisit un identifiant valide et un mot de passe incorrect  \n",{"type":27,"tag":4185,"props":4834,"children":4835},{"class":4187,"line":4223},[4836],{"type":27,"tag":4185,"props":4837,"children":4838},{},[4839],{"type":32,"value":4840},"    Then un message d'erreur \"Mot de passe incorrect\" est affiché\n",{"type":27,"tag":28,"props":4842,"children":4843},{},[4844],{"type":32,"value":4845},"Deux scénarios, deux comportements distincts, un par cas. C'est tout l'esprit du format.",{"type":27,"tag":55,"props":4847,"children":4848},{},[],{"type":27,"tag":3853,"props":4850,"children":4852},{"id":4851},"exemples-avancés",[4853],{"type":27,"tag":74,"props":4854,"children":4855},{},[4856],{"type":32,"value":4857},"Exemples avancés",{"type":27,"tag":4023,"props":4859,"children":4861},{"id":4860},"gestion-derreurs",[4862],{"type":27,"tag":74,"props":4863,"children":4864},{},[4865],{"type":32,"value":4866},"Gestion d’erreurs",{"type":27,"tag":4174,"props":4868,"children":4870},{"className":4176,"code":4869,"language":4178,"meta":8,"style":8},"Feature: Envoi de formulaire  \n  Scenario: Champ obligatoire non rempli  \n    Given l'utilisateur est sur la page d'inscription  \n    When il soumet le formulaire sans remplir le champ \"email\"  \n    Then un message d'erreur \"Veuillez renseigner un email\" est affiché  \n    And le formulaire reste affiché avec les autres données déjà saisies  \n",[4871],{"type":27,"tag":4181,"props":4872,"children":4873},{"__ignoreMap":8},[4874,4882,4890,4898,4906,4914],{"type":27,"tag":4185,"props":4875,"children":4876},{"class":4187,"line":4188},[4877],{"type":27,"tag":4185,"props":4878,"children":4879},{},[4880],{"type":32,"value":4881},"Feature: Envoi de formulaire  \n",{"type":27,"tag":4185,"props":4883,"children":4884},{"class":4187,"line":475},[4885],{"type":27,"tag":4185,"props":4886,"children":4887},{},[4888],{"type":32,"value":4889},"  Scenario: Champ obligatoire non rempli  \n",{"type":27,"tag":4185,"props":4891,"children":4892},{"class":4187,"line":4205},[4893],{"type":27,"tag":4185,"props":4894,"children":4895},{},[4896],{"type":32,"value":4897},"    Given l'utilisateur est sur la page d'inscription  \n",{"type":27,"tag":4185,"props":4899,"children":4900},{"class":4187,"line":4214},[4901],{"type":27,"tag":4185,"props":4902,"children":4903},{},[4904],{"type":32,"value":4905},"    When il soumet le formulaire sans remplir le champ \"email\"  \n",{"type":27,"tag":4185,"props":4907,"children":4908},{"class":4187,"line":4223},[4909],{"type":27,"tag":4185,"props":4910,"children":4911},{},[4912],{"type":32,"value":4913},"    Then un message d'erreur \"Veuillez renseigner un email\" est affiché  \n",{"type":27,"tag":4185,"props":4915,"children":4917},{"class":4187,"line":4916},6,[4918],{"type":27,"tag":4185,"props":4919,"children":4920},{},[4921],{"type":32,"value":4922},"    And le formulaire reste affiché avec les autres données déjà saisies\n",{"type":27,"tag":4023,"props":4924,"children":4926},{"id":4925},"scénario-non-fonctionnel-performance",[4927],{"type":27,"tag":74,"props":4928,"children":4929},{},[4930],{"type":32,"value":4931},"Scénario non fonctionnel : Performance",{"type":27,"tag":4174,"props":4933,"children":4935},{"className":4176,"code":4934,"language":4178,"meta":8,"style":8},"Feature: Recherche produit  \n  Scenario: Temps de réponse de la recherche  \n    Given un utilisateur effectue une recherche pour un produit populaire  \n    When il soumet la recherche  \n    Then les résultats doivent s’afficher en moins de 2 secondes  \n",[4936],{"type":27,"tag":4181,"props":4937,"children":4938},{"__ignoreMap":8},[4939,4947,4955,4963,4971],{"type":27,"tag":4185,"props":4940,"children":4941},{"class":4187,"line":4188},[4942],{"type":27,"tag":4185,"props":4943,"children":4944},{},[4945],{"type":32,"value":4946},"Feature: Recherche produit  \n",{"type":27,"tag":4185,"props":4948,"children":4949},{"class":4187,"line":475},[4950],{"type":27,"tag":4185,"props":4951,"children":4952},{},[4953],{"type":32,"value":4954},"  Scenario: Temps de réponse de la recherche  \n",{"type":27,"tag":4185,"props":4956,"children":4957},{"class":4187,"line":4205},[4958],{"type":27,"tag":4185,"props":4959,"children":4960},{},[4961],{"type":32,"value":4962},"    Given un utilisateur effectue une recherche pour un produit populaire  \n",{"type":27,"tag":4185,"props":4964,"children":4965},{"class":4187,"line":4214},[4966],{"type":27,"tag":4185,"props":4967,"children":4968},{},[4969],{"type":32,"value":4970},"    When il soumet la recherche  \n",{"type":27,"tag":4185,"props":4972,"children":4973},{"class":4187,"line":4223},[4974],{"type":27,"tag":4185,"props":4975,"children":4976},{},[4977],{"type":32,"value":4978},"    Then les résultats doivent s’afficher en moins de 2 secondes\n",{"type":27,"tag":28,"props":4980,"children":4981},{},[4982],{"type":32,"value":4983},"Le BDD ne se limite pas aux happy paths : messages d'erreur, contraintes de performance, contrats d'API, tout comportement observable peut entrer dans un scénario.",{"type":27,"tag":55,"props":4985,"children":4986},{},[],{"type":27,"tag":3853,"props":4988,"children":4990},{"id":4989},"bonnes-pratiques-pour-écrire-des-scénarios-gherkin",[4991],{"type":27,"tag":74,"props":4992,"children":4993},{},[4994],{"type":32,"value":4995},"Bonnes pratiques pour écrire des scénarios Gherkin",{"type":27,"tag":2850,"props":4997,"children":4998},{},[4999,5009,5019,5029],{"type":27,"tag":267,"props":5000,"children":5001},{},[5002,5007],{"type":27,"tag":74,"props":5003,"children":5004},{},[5005],{"type":32,"value":5006},"Concision",{"type":32,"value":5008}," : un scénario, un comportement. Si tu te retrouves avec sept étapes When\u002FThen enchaînées, découpe.",{"type":27,"tag":267,"props":5010,"children":5011},{},[5012,5017],{"type":27,"tag":74,"props":5013,"children":5014},{},[5015],{"type":32,"value":5016},"Lisibilité",{"type":32,"value":5018}," : zéro jargon technique. Si le PO ne comprend pas, le scénario est raté.",{"type":27,"tag":267,"props":5020,"children":5021},{},[5022,5027],{"type":27,"tag":74,"props":5023,"children":5024},{},[5025],{"type":32,"value":5026},"Structure",{"type":32,"value":5028}," : groupe les scénarios d'une même fonctionnalité dans la même feature.",{"type":27,"tag":267,"props":5030,"children":5031},{},[5032,5037],{"type":27,"tag":74,"props":5033,"children":5034},{},[5035],{"type":32,"value":5036},"Validation amont",{"type":32,"value":5038}," : fais relire au PO et au QA avant l'automatisation. Pas après.",{"type":27,"tag":55,"props":5040,"children":5041},{},[],{"type":27,"tag":3853,"props":5043,"children":5045},{"id":5044},"en-résumé-2",[5046],{"type":27,"tag":74,"props":5047,"children":5048},{},[5049],{"type":32,"value":1578},{"type":27,"tag":28,"props":5051,"children":5052},{},[5053],{"type":32,"value":5054},"Gherkin formalise des comportements observables. Les scénarios simples couvrent les cas nominaux, les scénarios avancés captent les cas limites et les exigences non fonctionnelles.",{"type":27,"tag":59,"props":5056,"children":5058},{"id":5057},"automatiser-les-scénarios-bdd-outils-et-stratégies",[5059],{"type":27,"tag":74,"props":5060,"children":5061},{},[5062],{"type":32,"value":5063},"Automatiser les scénarios BDD : Outils et stratégies",{"type":27,"tag":28,"props":5065,"children":5066},{},[5067],{"type":32,"value":5068},"Un scénario non automatisé devient obsolète en deux sprints. L'automatisation transforme la spec en garde-fou actif. Voici les outils que je vois tourner en mission et les stratégies pour les brancher dans un workflow Agile sans tout casser.",{"type":27,"tag":55,"props":5070,"children":5071},{},[],{"type":27,"tag":3853,"props":5073,"children":5075},{"id":5074},"les-outils-populaires-pour-automatiser-les-scénarios-bdd",[5076],{"type":27,"tag":74,"props":5077,"children":5078},{},[5079],{"type":32,"value":5080},"Les outils populaires pour automatiser les scénarios BDD",{"type":27,"tag":4023,"props":5082,"children":5084},{"id":5083},"_1-cucumber",[5085],{"type":27,"tag":74,"props":5086,"children":5087},{},[5088],{"type":32,"value":5089},"1. Cucumber",{"type":27,"tag":263,"props":5091,"children":5092},{},[5093,5103,5113],{"type":27,"tag":267,"props":5094,"children":5095},{},[5096,5101],{"type":27,"tag":74,"props":5097,"children":5098},{},[5099],{"type":32,"value":5100},"Description",{"type":32,"value":5102}," : l'outil de référence pour Gherkin, supporte Java, Ruby, JavaScript et plus.",{"type":27,"tag":267,"props":5104,"children":5105},{},[5106,5111],{"type":27,"tag":74,"props":5107,"children":5108},{},[5109],{"type":32,"value":5110},"Avantages",{"type":32,"value":5112}," : lisibilité pour les non-techniciens, énorme communauté, intégration immédiate avec Selenium ou Playwright.",{"type":27,"tag":267,"props":5114,"children":5115},{},[5116,5121],{"type":27,"tag":74,"props":5117,"children":5118},{},[5119],{"type":32,"value":5120},"Cas d’usage",{"type":32,"value":5122}," : équipes web polyglottes, gros projets avec écosystème Java\u002FJS.",{"type":27,"tag":4023,"props":5124,"children":5126},{"id":5125},"_2-specflow",[5127],{"type":27,"tag":74,"props":5128,"children":5129},{},[5130],{"type":32,"value":5131},"2. SpecFlow",{"type":27,"tag":263,"props":5133,"children":5134},{},[5135,5144,5153],{"type":27,"tag":267,"props":5136,"children":5137},{},[5138,5142],{"type":27,"tag":74,"props":5139,"children":5140},{},[5141],{"type":32,"value":5100},{"type":32,"value":5143}," : équivalent .NET de Cucumber, intégré à l'écosystème Microsoft.",{"type":27,"tag":267,"props":5145,"children":5146},{},[5147,5151],{"type":27,"tag":74,"props":5148,"children":5149},{},[5150],{"type":32,"value":5110},{"type":32,"value":5152}," : support natif Visual Studio et Azure DevOps.",{"type":27,"tag":267,"props":5154,"children":5155},{},[5156,5160],{"type":27,"tag":74,"props":5157,"children":5158},{},[5159],{"type":32,"value":5120},{"type":32,"value":5161}," : projets .NET, équipes déjà sur la stack Microsoft.",{"type":27,"tag":4023,"props":5163,"children":5165},{"id":5164},"_3-behave",[5166],{"type":27,"tag":74,"props":5167,"children":5168},{},[5169],{"type":32,"value":5170},"3. Behave",{"type":27,"tag":263,"props":5172,"children":5173},{},[5174,5183,5192],{"type":27,"tag":267,"props":5175,"children":5176},{},[5177,5181],{"type":27,"tag":74,"props":5178,"children":5179},{},[5180],{"type":32,"value":5100},{"type":32,"value":5182}," : solution Python pour Gherkin.",{"type":27,"tag":267,"props":5184,"children":5185},{},[5186,5190],{"type":27,"tag":74,"props":5187,"children":5188},{},[5189],{"type":32,"value":5110},{"type":32,"value":5191}," : simple, lisible, écosystème Python complet.",{"type":27,"tag":267,"props":5193,"children":5194},{},[5195,5199],{"type":27,"tag":74,"props":5196,"children":5197},{},[5198],{"type":32,"value":5120},{"type":32,"value":5200}," : projets data, IA, ou backend Python.",{"type":27,"tag":4023,"props":5202,"children":5204},{"id":5203},"_4-jbehave",[5205],{"type":27,"tag":74,"props":5206,"children":5207},{},[5208],{"type":32,"value":5209},"4. JBehave",{"type":27,"tag":263,"props":5211,"children":5212},{},[5213,5222,5231],{"type":27,"tag":267,"props":5214,"children":5215},{},[5216,5220],{"type":27,"tag":74,"props":5217,"children":5218},{},[5219],{"type":32,"value":5100},{"type":32,"value":5221}," : alternative Java à Cucumber, plus configurable sur la structure des tests.",{"type":27,"tag":267,"props":5223,"children":5224},{},[5225,5229],{"type":27,"tag":74,"props":5226,"children":5227},{},[5228],{"type":32,"value":5110},{"type":32,"value":5230}," : très flexible, adapté aux projets complexes.",{"type":27,"tag":267,"props":5232,"children":5233},{},[5234,5238],{"type":27,"tag":74,"props":5235,"children":5236},{},[5237],{"type":32,"value":5120},{"type":32,"value":5239}," : projets Java avec besoin de personnalisation profonde des workflows.",{"type":27,"tag":55,"props":5241,"children":5242},{},[],{"type":27,"tag":3853,"props":5244,"children":5246},{"id":5245},"stratégies-pour-intégrer-lautomatisation-dans-le-pipeline-cicd",[5247],{"type":27,"tag":74,"props":5248,"children":5249},{},[5250],{"type":32,"value":5251},"Stratégies pour intégrer l’automatisation dans le pipeline CI\u002FCD",{"type":27,"tag":4023,"props":5253,"children":5255},{"id":5254},"_1-approche-incrémentale",[5256],{"type":27,"tag":74,"props":5257,"children":5258},{},[5259],{"type":32,"value":5260},"1. Approche incrémentale",{"type":27,"tag":263,"props":5262,"children":5263},{},[5264,5269],{"type":27,"tag":267,"props":5265,"children":5266},{},[5267],{"type":32,"value":5268},"Commencer par les scénarios critiques sur les fonctionnalités à plus forte valeur métier.",{"type":27,"tag":267,"props":5270,"children":5271},{},[5272],{"type":32,"value":5273},"Étendre la couverture au fil des sprints, à mesure que l'équipe monte en compétence sur l'outil choisi.",{"type":27,"tag":4023,"props":5275,"children":5277},{"id":5276},"_2-tests-dans-le-pipeline-cicd",[5278],{"type":27,"tag":74,"props":5279,"children":5280},{},[5281],{"type":32,"value":5282},"2. Tests dans le pipeline CI\u002FCD",{"type":27,"tag":263,"props":5284,"children":5285},{},[5286,5291],{"type":27,"tag":267,"props":5287,"children":5288},{},[5289],{"type":32,"value":5290},"Configurer Jenkins, GitLab CI ou Azure DevOps pour exécuter les scénarios à chaque commit.",{"type":27,"tag":267,"props":5292,"children":5293},{},[5294],{"type":32,"value":5295},"Exploiter les rapports générés automatiquement pour tracker les régressions sur la durée.",{"type":27,"tag":4023,"props":5297,"children":5299},{"id":5298},"_3-synchronisation-scénarioscode",[5300],{"type":27,"tag":74,"props":5301,"children":5302},{},[5303],{"type":32,"value":5304},"3. Synchronisation scénarios\u002Fcode",{"type":27,"tag":263,"props":5306,"children":5307},{},[5308,5313],{"type":27,"tag":267,"props":5309,"children":5310},{},[5311],{"type":32,"value":5312},"Revoir les scénarios à chaque évolution du produit. Ne pas attendre la régression pour découvrir le drift.",{"type":27,"tag":267,"props":5314,"children":5315},{},[5316],{"type":32,"value":5317},"Supprimer sans état d'âme les tests obsolètes : ils empoisonnent la CI plus qu'ils ne protègent.",{"type":27,"tag":4023,"props":5319,"children":5321},{"id":5320},"_4-cibler-le-non-fonctionnel",[5322],{"type":27,"tag":74,"props":5323,"children":5324},{},[5325],{"type":32,"value":5326},"4. Cibler le non-fonctionnel",{"type":27,"tag":263,"props":5328,"children":5329},{},[5330,5335],{"type":27,"tag":267,"props":5331,"children":5332},{},[5333],{"type":32,"value":5334},"Écrire des scénarios pour les contraintes de performance (temps de réponse) et de sécurité.",{"type":27,"tag":267,"props":5336,"children":5337},{},[5338],{"type":32,"value":5339},"Outiller avec Gatling, JMeter ou OWASP ZAP pour automatiser ces vérifications.",{"type":27,"tag":55,"props":5341,"children":5342},{},[],{"type":27,"tag":3853,"props":5344,"children":5346},{"id":5345},"étape-pratique-exemple-dautomatisation-avec-cucumber",[5347],{"type":27,"tag":74,"props":5348,"children":5349},{},[5350],{"type":32,"value":5351},"Étape pratique : Exemple d’automatisation avec Cucumber",{"type":27,"tag":28,"props":5353,"children":5354},{},[5355],{"type":32,"value":5356},"Voici un exemple de fichier Gherkin automatisé avec Cucumber pour une recherche produit :",{"type":27,"tag":4023,"props":5358,"children":5360},{"id":5359},"scénario-en-gherkin",[5361],{"type":27,"tag":74,"props":5362,"children":5363},{},[5364],{"type":32,"value":5365},"Scénario en Gherkin",{"type":27,"tag":4174,"props":5367,"children":5369},{"className":4176,"code":5368,"language":4178,"meta":8,"style":8},"Feature: Recherche produit  \n  Scenario: Trouver un produit par son nom  \n    Given le catalogue contient un produit nommé \"Laptop\"  \n    When l'utilisateur recherche \"Laptop\"  \n    Then le résultat contient \"Laptop\"  \n",[5370],{"type":27,"tag":4181,"props":5371,"children":5372},{"__ignoreMap":8},[5373,5380,5388,5396,5404],{"type":27,"tag":4185,"props":5374,"children":5375},{"class":4187,"line":4188},[5376],{"type":27,"tag":4185,"props":5377,"children":5378},{},[5379],{"type":32,"value":4946},{"type":27,"tag":4185,"props":5381,"children":5382},{"class":4187,"line":475},[5383],{"type":27,"tag":4185,"props":5384,"children":5385},{},[5386],{"type":32,"value":5387},"  Scenario: Trouver un produit par son nom  \n",{"type":27,"tag":4185,"props":5389,"children":5390},{"class":4187,"line":4205},[5391],{"type":27,"tag":4185,"props":5392,"children":5393},{},[5394],{"type":32,"value":5395},"    Given le catalogue contient un produit nommé \"Laptop\"  \n",{"type":27,"tag":4185,"props":5397,"children":5398},{"class":4187,"line":4214},[5399],{"type":27,"tag":4185,"props":5400,"children":5401},{},[5402],{"type":32,"value":5403},"    When l'utilisateur recherche \"Laptop\"  \n",{"type":27,"tag":4185,"props":5405,"children":5406},{"class":4187,"line":4223},[5407],{"type":27,"tag":4185,"props":5408,"children":5409},{},[5410],{"type":32,"value":5411},"    Then le résultat contient \"Laptop\"\n",{"type":27,"tag":4023,"props":5413,"children":5415},{"id":5414},"code-java-correspondant",[5416],{"type":27,"tag":74,"props":5417,"children":5418},{},[5419],{"type":32,"value":5420},"Code Java correspondant",{"type":27,"tag":4174,"props":5422,"children":5426},{"className":5423,"code":5424,"language":5425,"meta":8,"style":8},"language-java shiki shiki-themes catppuccin-frappe github-dark","@Given(\"le catalogue contient un produit nommé {string}\")\npublic void ajouterProduitDansCatalogue(String produit) {\n    \u002F\u002F Code pour ajouter un produit fictif au catalogue\n}\n\n@When(\"l'utilisateur recherche {string}\")\npublic void effectuerRecherche(String recherche) {\n    \u002F\u002F Code pour simuler une recherche produit\n}\n\n@Then(\"le résultat contient {string}\")\npublic void verifierResultatRecherche(String produit) {\n    \u002F\u002F Code pour vérifier que le produit est dans les résultats\n}\n","java",[5427],{"type":27,"tag":4181,"props":5428,"children":5429},{"__ignoreMap":8},[5430,5461,5506,5515,5523,5531,5555,5592,5601,5609,5617,5642,5678,5687],{"type":27,"tag":4185,"props":5431,"children":5432},{"class":4187,"line":4188},[5433,5439,5444,5450,5456],{"type":27,"tag":4185,"props":5434,"children":5436},{"style":5435},"--shiki-default:#EF9F76;--shiki-dark:#E1E4E8",[5437],{"type":32,"value":5438},"@",{"type":27,"tag":4185,"props":5440,"children":5442},{"style":5441},"--shiki-default:#EF9F76;--shiki-dark:#F97583",[5443],{"type":32,"value":4145},{"type":27,"tag":4185,"props":5445,"children":5447},{"style":5446},"--shiki-default:#949CBB;--shiki-dark:#E1E4E8",[5448],{"type":32,"value":5449},"(",{"type":27,"tag":4185,"props":5451,"children":5453},{"style":5452},"--shiki-default:#A6D189;--shiki-dark:#9ECBFF",[5454],{"type":32,"value":5455},"\"le catalogue contient un produit nommé {string}\"",{"type":27,"tag":4185,"props":5457,"children":5458},{"style":5446},[5459],{"type":32,"value":5460},")\n",{"type":27,"tag":4185,"props":5462,"children":5463},{"class":4187,"line":475},[5464,5470,5475,5481,5485,5491,5497,5501],{"type":27,"tag":4185,"props":5465,"children":5467},{"style":5466},"--shiki-default:#CA9EE6;--shiki-dark:#F97583",[5468],{"type":32,"value":5469},"public",{"type":27,"tag":4185,"props":5471,"children":5472},{"style":5466},[5473],{"type":32,"value":5474}," void",{"type":27,"tag":4185,"props":5476,"children":5478},{"style":5477},"--shiki-default:#8CAAEE;--shiki-default-font-style:italic;--shiki-dark:#B392F0;--shiki-dark-font-style:inherit",[5479],{"type":32,"value":5480}," ajouterProduitDansCatalogue",{"type":27,"tag":4185,"props":5482,"children":5483},{"style":5446},[5484],{"type":32,"value":5449},{"type":27,"tag":4185,"props":5486,"children":5488},{"style":5487},"--shiki-default:#CA9EE6;--shiki-dark:#E1E4E8",[5489],{"type":32,"value":5490},"String",{"type":27,"tag":4185,"props":5492,"children":5494},{"style":5493},"--shiki-default:#C6D0F5;--shiki-dark:#E1E4E8",[5495],{"type":32,"value":5496}," produit",{"type":27,"tag":4185,"props":5498,"children":5499},{"style":5446},[5500],{"type":32,"value":3302},{"type":27,"tag":4185,"props":5502,"children":5503},{"style":5446},[5504],{"type":32,"value":5505}," {\n",{"type":27,"tag":4185,"props":5507,"children":5508},{"class":4187,"line":4205},[5509],{"type":27,"tag":4185,"props":5510,"children":5512},{"style":5511},"--shiki-default:#737994;--shiki-default-font-style:italic;--shiki-dark:#6A737D;--shiki-dark-font-style:inherit",[5513],{"type":32,"value":5514},"    \u002F\u002F Code pour ajouter un produit fictif au catalogue\n",{"type":27,"tag":4185,"props":5516,"children":5517},{"class":4187,"line":4214},[5518],{"type":27,"tag":4185,"props":5519,"children":5520},{"style":5446},[5521],{"type":32,"value":5522},"}\n",{"type":27,"tag":4185,"props":5524,"children":5525},{"class":4187,"line":4223},[5526],{"type":27,"tag":4185,"props":5527,"children":5528},{"emptyLinePlaceholder":13},[5529],{"type":32,"value":5530},"\n",{"type":27,"tag":4185,"props":5532,"children":5533},{"class":4187,"line":4916},[5534,5538,5542,5546,5551],{"type":27,"tag":4185,"props":5535,"children":5536},{"style":5435},[5537],{"type":32,"value":5438},{"type":27,"tag":4185,"props":5539,"children":5540},{"style":5441},[5541],{"type":32,"value":4155},{"type":27,"tag":4185,"props":5543,"children":5544},{"style":5446},[5545],{"type":32,"value":5449},{"type":27,"tag":4185,"props":5547,"children":5548},{"style":5452},[5549],{"type":32,"value":5550},"\"l'utilisateur recherche {string}\"",{"type":27,"tag":4185,"props":5552,"children":5553},{"style":5446},[5554],{"type":32,"value":5460},{"type":27,"tag":4185,"props":5556,"children":5557},{"class":4187,"line":3068},[5558,5562,5566,5571,5575,5579,5584,5588],{"type":27,"tag":4185,"props":5559,"children":5560},{"style":5466},[5561],{"type":32,"value":5469},{"type":27,"tag":4185,"props":5563,"children":5564},{"style":5466},[5565],{"type":32,"value":5474},{"type":27,"tag":4185,"props":5567,"children":5568},{"style":5477},[5569],{"type":32,"value":5570}," effectuerRecherche",{"type":27,"tag":4185,"props":5572,"children":5573},{"style":5446},[5574],{"type":32,"value":5449},{"type":27,"tag":4185,"props":5576,"children":5577},{"style":5487},[5578],{"type":32,"value":5490},{"type":27,"tag":4185,"props":5580,"children":5581},{"style":5493},[5582],{"type":32,"value":5583}," recherche",{"type":27,"tag":4185,"props":5585,"children":5586},{"style":5446},[5587],{"type":32,"value":3302},{"type":27,"tag":4185,"props":5589,"children":5590},{"style":5446},[5591],{"type":32,"value":5505},{"type":27,"tag":4185,"props":5593,"children":5595},{"class":4187,"line":5594},8,[5596],{"type":27,"tag":4185,"props":5597,"children":5598},{"style":5511},[5599],{"type":32,"value":5600},"    \u002F\u002F Code pour simuler une recherche produit\n",{"type":27,"tag":4185,"props":5602,"children":5604},{"class":4187,"line":5603},9,[5605],{"type":27,"tag":4185,"props":5606,"children":5607},{"style":5446},[5608],{"type":32,"value":5522},{"type":27,"tag":4185,"props":5610,"children":5612},{"class":4187,"line":5611},10,[5613],{"type":27,"tag":4185,"props":5614,"children":5615},{"emptyLinePlaceholder":13},[5616],{"type":32,"value":5530},{"type":27,"tag":4185,"props":5618,"children":5620},{"class":4187,"line":5619},11,[5621,5625,5629,5633,5638],{"type":27,"tag":4185,"props":5622,"children":5623},{"style":5435},[5624],{"type":32,"value":5438},{"type":27,"tag":4185,"props":5626,"children":5627},{"style":5441},[5628],{"type":32,"value":4165},{"type":27,"tag":4185,"props":5630,"children":5631},{"style":5446},[5632],{"type":32,"value":5449},{"type":27,"tag":4185,"props":5634,"children":5635},{"style":5452},[5636],{"type":32,"value":5637},"\"le résultat contient {string}\"",{"type":27,"tag":4185,"props":5639,"children":5640},{"style":5446},[5641],{"type":32,"value":5460},{"type":27,"tag":4185,"props":5643,"children":5644},{"class":4187,"line":2696},[5645,5649,5653,5658,5662,5666,5670,5674],{"type":27,"tag":4185,"props":5646,"children":5647},{"style":5466},[5648],{"type":32,"value":5469},{"type":27,"tag":4185,"props":5650,"children":5651},{"style":5466},[5652],{"type":32,"value":5474},{"type":27,"tag":4185,"props":5654,"children":5655},{"style":5477},[5656],{"type":32,"value":5657}," verifierResultatRecherche",{"type":27,"tag":4185,"props":5659,"children":5660},{"style":5446},[5661],{"type":32,"value":5449},{"type":27,"tag":4185,"props":5663,"children":5664},{"style":5487},[5665],{"type":32,"value":5490},{"type":27,"tag":4185,"props":5667,"children":5668},{"style":5493},[5669],{"type":32,"value":5496},{"type":27,"tag":4185,"props":5671,"children":5672},{"style":5446},[5673],{"type":32,"value":3302},{"type":27,"tag":4185,"props":5675,"children":5676},{"style":5446},[5677],{"type":32,"value":5505},{"type":27,"tag":4185,"props":5679,"children":5681},{"class":4187,"line":5680},13,[5682],{"type":27,"tag":4185,"props":5683,"children":5684},{"style":5511},[5685],{"type":32,"value":5686},"    \u002F\u002F Code pour vérifier que le produit est dans les résultats\n",{"type":27,"tag":4185,"props":5688,"children":5690},{"class":4187,"line":5689},14,[5691],{"type":27,"tag":4185,"props":5692,"children":5693},{"style":5446},[5694],{"type":32,"value":5522},{"type":27,"tag":55,"props":5696,"children":5697},{},[],{"type":27,"tag":3853,"props":5699,"children":5701},{"id":5700},"en-résumé-3",[5702],{"type":27,"tag":74,"props":5703,"children":5704},{},[5705],{"type":32,"value":1578},{"type":27,"tag":263,"props":5707,"children":5708},{},[5709,5714,5719],{"type":27,"tag":267,"props":5710,"children":5711},{},[5712],{"type":32,"value":5713},"Cucumber, SpecFlow, Behave ou JBehave transforment vos scénarios Gherkin en tests exécutables.",{"type":27,"tag":267,"props":5715,"children":5716},{},[5717],{"type":32,"value":5718},"L'intégration CI garantit l'exécution à chaque commit. Sans ça, le BDD reste théorique.",{"type":27,"tag":267,"props":5720,"children":5721},{},[5722],{"type":32,"value":5723},"Une stratégie progressive, alignée sur les priorités métier, donne le meilleur ROI.",{"type":27,"tag":59,"props":5725,"children":5727},{"id":5726},"les-défis-du-bdd-et-comment-les-surmonter",[5728],{"type":27,"tag":74,"props":5729,"children":5730},{},[5731],{"type":32,"value":5732},"Les défis du BDD et comment les surmonter",{"type":27,"tag":28,"props":5734,"children":5735},{},[5736],{"type":32,"value":5737},"Le BDD bute systématiquement sur les mêmes obstacles en mission. Voici les cinq que je rencontre tous les six mois, et la façon dont je les ai vus se résoudre.",{"type":27,"tag":55,"props":5739,"children":5740},{},[],{"type":27,"tag":3853,"props":5742,"children":5744},{"id":5743},"_1-scénarios-trop-vagues-ou-trop-détaillés",[5745],{"type":27,"tag":74,"props":5746,"children":5747},{},[5748],{"type":32,"value":5749},"1. Scénarios trop vagues ou trop détaillés",{"type":27,"tag":263,"props":5751,"children":5752},{},[5753,5763],{"type":27,"tag":267,"props":5754,"children":5755},{},[5756,5761],{"type":27,"tag":74,"props":5757,"children":5758},{},[5759],{"type":32,"value":5760},"Problème",{"type":32,"value":5762}," : un scénario flou n'est pas exécutable, un scénario surchargé de détails techniques ne se relit pas.",{"type":27,"tag":267,"props":5764,"children":5765},{},[5766,5771,5772],{"type":27,"tag":74,"props":5767,"children":5768},{},[5769],{"type":32,"value":5770},"Solution",{"type":32,"value":4065},{"type":27,"tag":263,"props":5773,"children":5774},{},[5775,5780,5785],{"type":27,"tag":267,"props":5776,"children":5777},{},[5778],{"type":32,"value":5779},"Critères SMART (Spécifiques, Mesurables, Acceptables, Réalistes, Temporels) pour la rédaction.",{"type":27,"tag":267,"props":5781,"children":5782},{},[5783],{"type":32,"value":5784},"Validation par toutes les parties prenantes, PO en tête.",{"type":27,"tag":267,"props":5786,"children":5787},{},[5788,5790,5795],{"type":32,"value":5789},"Un scénario = ",{"type":27,"tag":74,"props":5791,"children":5792},{},[5793],{"type":32,"value":5794},"un seul comportement",{"type":32,"value":5796},". Pas deux, pas trois.",{"type":27,"tag":55,"props":5798,"children":5799},{},[],{"type":27,"tag":3853,"props":5801,"children":5803},{"id":5802},"_2-déconnexion-entre-scénarios-et-tests-automatisés",[5804],{"type":27,"tag":74,"props":5805,"children":5806},{},[5807],{"type":32,"value":5808},"2. Déconnexion entre scénarios et tests automatisés",{"type":27,"tag":263,"props":5810,"children":5811},{},[5812,5821],{"type":27,"tag":267,"props":5813,"children":5814},{},[5815,5819],{"type":27,"tag":74,"props":5816,"children":5817},{},[5818],{"type":32,"value":5760},{"type":32,"value":5820}," : le code évolue plus vite que les scénarios, et le drift s'installe.",{"type":27,"tag":267,"props":5822,"children":5823},{},[5824,5828,5829],{"type":27,"tag":74,"props":5825,"children":5826},{},[5827],{"type":32,"value":5770},{"type":32,"value":4065},{"type":27,"tag":263,"props":5830,"children":5831},{},[5832,5837,5842],{"type":27,"tag":267,"props":5833,"children":5834},{},[5835],{"type":32,"value":5836},"Revue régulière des scénarios et des tests associés.",{"type":27,"tag":267,"props":5838,"children":5839},{},[5840],{"type":32,"value":5841},"Cucumber Reports (ou équivalent) pour tracker l'état des tests Gherkin.",{"type":27,"tag":267,"props":5843,"children":5844},{},[5845],{"type":32,"value":5846},"Scénarios traités comme artefacts vivants, révisés à chaque changement métier ou code.",{"type":27,"tag":55,"props":5848,"children":5849},{},[],{"type":27,"tag":3853,"props":5851,"children":5853},{"id":5852},"_3-résistance-au-changement-dans-les-équipes",[5854],{"type":27,"tag":74,"props":5855,"children":5856},{},[5857],{"type":32,"value":5858},"3. Résistance au changement dans les équipes",{"type":27,"tag":263,"props":5860,"children":5861},{},[5862,5871],{"type":27,"tag":267,"props":5863,"children":5864},{},[5865,5869],{"type":27,"tag":74,"props":5866,"children":5867},{},[5868],{"type":32,"value":5760},{"type":32,"value":5870}," : courbe d'apprentissage, temps initial de rédaction perçu comme un coût mort.",{"type":27,"tag":267,"props":5872,"children":5873},{},[5874,5878,5879],{"type":27,"tag":74,"props":5875,"children":5876},{},[5877],{"type":32,"value":5770},{"type":32,"value":4065},{"type":27,"tag":263,"props":5880,"children":5881},{},[5882,5892,5902],{"type":27,"tag":267,"props":5883,"children":5884},{},[5885,5890],{"type":27,"tag":74,"props":5886,"children":5887},{},[5888],{"type":32,"value":5889},"Formation",{"type":32,"value":5891}," : ateliers avec exemples concrets, pas de slides théoriques.",{"type":27,"tag":267,"props":5893,"children":5894},{},[5895,5900],{"type":27,"tag":74,"props":5896,"children":5897},{},[5898],{"type":32,"value":5899},"Adoption progressive",{"type":32,"value":5901}," : un workflow critique d'abord, le reste ensuite.",{"type":27,"tag":267,"props":5903,"children":5904},{},[5905,5910],{"type":27,"tag":74,"props":5906,"children":5907},{},[5908],{"type":32,"value":5909},"Sponsoring leaders",{"type":32,"value":5911}," : sans soutien managérial, le BDD meurt au troisième sprint.",{"type":27,"tag":28,"props":5913,"children":5914},{},[5915],{"type":32,"value":5916},"J'ai accompagné des équipes dans le bancaire et l'assurance qui ont mis plusieurs mois à dépasser cette résistance. Ce qui a débloqué la situation à chaque fois : un seul workflow critique en pilote, scénarios rédigés en atelier avec le métier, résultats concrets visibles dès le premier sprint. Le reste a suivi tout seul.",{"type":27,"tag":55,"props":5918,"children":5919},{},[],{"type":27,"tag":3853,"props":5921,"children":5923},{"id":5922},"_4-difficulté-à-aligner-les-parties-prenantes",[5924],{"type":27,"tag":74,"props":5925,"children":5926},{},[5927],{"type":32,"value":5928},"4. Difficulté à aligner les parties prenantes",{"type":27,"tag":263,"props":5930,"children":5931},{},[5932,5941],{"type":27,"tag":267,"props":5933,"children":5934},{},[5935,5939],{"type":27,"tag":74,"props":5936,"children":5937},{},[5938],{"type":32,"value":5760},{"type":32,"value":5940}," : métier et technique parlent deux langues, et la qualité des scénarios en pâtit.",{"type":27,"tag":267,"props":5942,"children":5943},{},[5944,5948,5949],{"type":27,"tag":74,"props":5945,"children":5946},{},[5947],{"type":32,"value":5770},{"type":32,"value":4065},{"type":27,"tag":263,"props":5950,"children":5951},{},[5952,5962],{"type":27,"tag":267,"props":5953,"children":5954},{},[5955,5960],{"type":27,"tag":74,"props":5956,"children":5957},{},[5958],{"type":32,"value":5959},"Three Amigos",{"type":32,"value":5961}," systématiques sur les stories complexes.",{"type":27,"tag":267,"props":5963,"children":5964},{},[5965],{"type":32,"value":5966},"Outils visuels (Confluence, miroirs de processus) pour rendre les scénarios accessibles à tous.",{"type":27,"tag":55,"props":5968,"children":5969},{},[],{"type":27,"tag":3853,"props":5971,"children":5973},{"id":5972},"_5-maintenance-des-scénarios-dans-le-temps",[5974],{"type":27,"tag":74,"props":5975,"children":5976},{},[5977],{"type":32,"value":5978},"5. Maintenance des scénarios dans le temps",{"type":27,"tag":263,"props":5980,"children":5981},{},[5982,5991],{"type":27,"tag":267,"props":5983,"children":5984},{},[5985,5989],{"type":27,"tag":74,"props":5986,"children":5987},{},[5988],{"type":32,"value":5760},{"type":32,"value":5990}," : si les features bougent vite, les scénarios deviennent obsolètes, et les tests cassent sans raison fonctionnelle.",{"type":27,"tag":267,"props":5992,"children":5993},{},[5994,5998,5999],{"type":27,"tag":74,"props":5995,"children":5996},{},[5997],{"type":32,"value":5770},{"type":32,"value":4065},{"type":27,"tag":263,"props":6000,"children":6001},{},[6002,6007,6022],{"type":27,"tag":267,"props":6003,"children":6004},{},[6005],{"type":32,"value":6006},"Un responsable maintenance par sprint, nominativement.",{"type":27,"tag":267,"props":6008,"children":6009},{},[6010,6012,6020],{"type":32,"value":6011},"Mise à jour des scénarios dans la ",{"type":27,"tag":74,"props":6013,"children":6014},{},[6015],{"type":27,"tag":198,"props":6016,"children":6017},{"href":1159},[6018],{"type":32,"value":6019},"Definition of Done",{"type":32,"value":6021}," (DoD).",{"type":27,"tag":267,"props":6023,"children":6024},{},[6025],{"type":32,"value":6026},"Nettoyage régulier des scénarios morts.",{"type":27,"tag":55,"props":6028,"children":6029},{},[],{"type":27,"tag":3853,"props":6031,"children":6033},{"id":6032},"en-résumé-4",[6034],{"type":27,"tag":74,"props":6035,"children":6036},{},[6037],{"type":32,"value":1578},{"type":27,"tag":263,"props":6039,"children":6040},{},[6041,6046,6051,6056],{"type":27,"tag":267,"props":6042,"children":6043},{},[6044],{"type":32,"value":6045},"Scénarios clairs et ciblés, un comportement à la fois.",{"type":27,"tag":267,"props":6047,"children":6048},{},[6049],{"type":32,"value":6050},"Alignement scénarios\u002Ftests\u002Fcode via revues régulières.",{"type":27,"tag":267,"props":6052,"children":6053},{},[6054],{"type":32,"value":6055},"Adoption progressive avec sponsoring managérial pour casser la résistance.",{"type":27,"tag":267,"props":6057,"children":6058},{},[6059],{"type":32,"value":6060},"Three Amigos et ateliers pour souder métier et technique.",{"type":27,"tag":59,"props":6062,"children":6064},{"id":6063},"bonnes-pratiques-pour-intégrer-le-bdd-durablement",[6065],{"type":27,"tag":74,"props":6066,"children":6067},{},[6068],{"type":32,"value":6069},"Bonnes pratiques pour intégrer le BDD durablement",{"type":27,"tag":28,"props":6071,"children":6072},{},[6073],{"type":32,"value":6074},"Le BDD survit dans la durée à trois conditions : une culture qui force le dialogue, des scénarios traités comme du code vivant, et une discipline d'adoption progressive. Voici les habitudes qui font la différence sur 12-24 mois.",{"type":27,"tag":55,"props":6076,"children":6077},{},[],{"type":27,"tag":3853,"props":6079,"children":6081},{"id":6080},"_1-créer-une-culture-collaborative",[6082],{"type":27,"tag":74,"props":6083,"children":6084},{},[6085],{"type":32,"value":6086},"1. Créer une culture collaborative",{"type":27,"tag":28,"props":6088,"children":6089},{},[6090],{"type":32,"value":6091},"Le BDD ne fonctionne que si les conversations ont lieu.",{"type":27,"tag":4023,"props":6093,"children":6095},{"id":6094},"actions-clés",[6096],{"type":27,"tag":74,"props":6097,"children":6098},{},[6099],{"type":32,"value":6100},"Actions clés :",{"type":27,"tag":263,"props":6102,"children":6103},{},[6104,6114,6124],{"type":27,"tag":267,"props":6105,"children":6106},{},[6107,6112],{"type":27,"tag":74,"props":6108,"children":6109},{},[6110],{"type":32,"value":6111},"Ateliers Three Amigos réguliers",{"type":32,"value":6113}," pour discuter des stories et co-rédiger les scénarios.",{"type":27,"tag":267,"props":6115,"children":6116},{},[6117,6122],{"type":27,"tag":74,"props":6118,"children":6119},{},[6120],{"type":32,"value":6121},"Transparence",{"type":32,"value":6123}," : scénarios publiés sur une plateforme accessible (Jira, Confluence).",{"type":27,"tag":267,"props":6125,"children":6126},{},[6127,6132],{"type":27,"tag":74,"props":6128,"children":6129},{},[6130],{"type":32,"value":6131},"Formation continue",{"type":32,"value":6133}," des équipes pour qu'elles partagent un vocabulaire commun.",{"type":27,"tag":55,"props":6135,"children":6136},{},[],{"type":27,"tag":3853,"props":6138,"children":6140},{"id":6139},"_2-documenter-les-scénarios-comme-des-artefacts-vivants",[6141],{"type":27,"tag":74,"props":6142,"children":6143},{},[6144],{"type":32,"value":6145},"2. Documenter les scénarios comme des artefacts vivants",{"type":27,"tag":28,"props":6147,"children":6148},{},[6149],{"type":32,"value":6150},"Un scénario n'est pas un document Word qu'on archive. C'est un test qui tourne en CI.",{"type":27,"tag":4023,"props":6152,"children":6154},{"id":6153},"actions-clés-1",[6155],{"type":27,"tag":74,"props":6156,"children":6157},{},[6158],{"type":32,"value":6100},{"type":27,"tag":263,"props":6160,"children":6161},{},[6162,6172,6182],{"type":27,"tag":267,"props":6163,"children":6164},{},[6165,6170],{"type":27,"tag":74,"props":6166,"children":6167},{},[6168],{"type":32,"value":6169},"Revisiter les scénarios à chaque sprint",{"type":32,"value":6171}," pour les garder alignés.",{"type":27,"tag":267,"props":6173,"children":6174},{},[6175,6180],{"type":27,"tag":74,"props":6176,"children":6177},{},[6178],{"type":32,"value":6179},"Pas de duplication",{"type":32,"value":6181}," : un comportement = un scénario.",{"type":27,"tag":267,"props":6183,"children":6184},{},[6185,6190],{"type":27,"tag":74,"props":6186,"children":6187},{},[6188],{"type":32,"value":6189},"Outils intégrés",{"type":32,"value":6191}," (Xray, TestRail) pour centraliser documentation et résultats.",{"type":27,"tag":55,"props":6193,"children":6194},{},[],{"type":27,"tag":3853,"props":6196,"children":6198},{"id":6197},"_3-intégrer-les-scénarios-dans-la-definition-of-done-dod",[6199],{"type":27,"tag":74,"props":6200,"children":6201},{},[6202],{"type":32,"value":6203},"3. Intégrer les scénarios dans la Definition of Done (DoD)",{"type":27,"tag":28,"props":6205,"children":6206},{},[6207],{"type":32,"value":6208},"Le BDD doit faire partie du contrat de fin de story, sinon il disparaît au premier rush.",{"type":27,"tag":4023,"props":6210,"children":6212},{"id":6211},"actions-clés-2",[6213],{"type":27,"tag":74,"props":6214,"children":6215},{},[6216],{"type":32,"value":6100},{"type":27,"tag":263,"props":6218,"children":6219},{},[6220,6225],{"type":27,"tag":267,"props":6221,"children":6222},{},[6223],{"type":32,"value":6224},"Règle DoD : chaque user story a des scénarios rédigés et validés.",{"type":27,"tag":267,"props":6226,"children":6227},{},[6228],{"type":32,"value":6229},"Tous les scénarios critiques sont automatisés avant clôture de l'itération.",{"type":27,"tag":55,"props":6231,"children":6232},{},[],{"type":27,"tag":3853,"props":6234,"children":6236},{"id":6235},"_4-réviser-et-mettre-à-jour-régulièrement-les-scénarios",[6237],{"type":27,"tag":74,"props":6238,"children":6239},{},[6240],{"type":32,"value":6241},"4. Réviser et mettre à jour régulièrement les scénarios",{"type":27,"tag":28,"props":6243,"children":6244},{},[6245],{"type":32,"value":6246},"Un scénario obsolète casse les tests sans raison fonctionnelle. C'est le pire signal qu'on puisse envoyer à l'équipe.",{"type":27,"tag":4023,"props":6248,"children":6250},{"id":6249},"actions-clés-3",[6251],{"type":27,"tag":74,"props":6252,"children":6253},{},[6254],{"type":32,"value":6100},{"type":27,"tag":263,"props":6256,"children":6257},{},[6258,6263,6268],{"type":27,"tag":267,"props":6259,"children":6260},{},[6261],{"type":32,"value":6262},"Revue trimestrielle des scénarios existants.",{"type":27,"tag":267,"props":6264,"children":6265},{},[6266],{"type":32,"value":6267},"Suppression des scénarios morts ou peu pertinents.",{"type":27,"tag":267,"props":6269,"children":6270},{},[6271],{"type":32,"value":6272},"Mise à jour dès qu'une fonctionnalité bouge.",{"type":27,"tag":55,"props":6274,"children":6275},{},[],{"type":27,"tag":3853,"props":6277,"children":6279},{"id":6278},"_5-aligner-le-bdd-avec-les-objectifs-stratégiques",[6280],{"type":27,"tag":74,"props":6281,"children":6282},{},[6283],{"type":32,"value":6284},"5. Aligner le BDD avec les objectifs stratégiques",{"type":27,"tag":28,"props":6286,"children":6287},{},[6288],{"type":32,"value":6289},"Le BDD doit servir le métier, pas l'inverse.",{"type":27,"tag":4023,"props":6291,"children":6293},{"id":6292},"actions-clés-4",[6294],{"type":27,"tag":74,"props":6295,"children":6296},{},[6297],{"type":32,"value":6100},{"type":27,"tag":263,"props":6299,"children":6300},{},[6301,6306],{"type":27,"tag":267,"props":6302,"children":6303},{},[6304],{"type":32,"value":6305},"Concentrer l'effort sur les fonctionnalités critiques pour l'utilisateur.",{"type":27,"tag":267,"props":6307,"children":6308},{},[6309],{"type":32,"value":6310},"Tracker quelques métriques (bugs en prod, temps de cycle, taux de rework) pour démontrer la valeur.",{"type":27,"tag":55,"props":6312,"children":6313},{},[],{"type":27,"tag":3853,"props":6315,"children":6317},{"id":6316},"_6-encourager-une-adoption-progressive",[6318],{"type":27,"tag":74,"props":6319,"children":6320},{},[6321],{"type":32,"value":6322},"6. Encourager une adoption progressive",{"type":27,"tag":28,"props":6324,"children":6325},{},[6326],{"type":32,"value":6327},"Pas besoin de tout convertir d'un coup. Une approche graduelle évite la résistance et permet la montée en compétences.",{"type":27,"tag":4023,"props":6329,"children":6331},{"id":6330},"actions-clés-5",[6332],{"type":27,"tag":74,"props":6333,"children":6334},{},[6335],{"type":32,"value":6100},{"type":27,"tag":263,"props":6337,"children":6338},{},[6339,6344],{"type":27,"tag":267,"props":6340,"children":6341},{},[6342],{"type":32,"value":6343},"Lancer le BDD sur un projet pilote avant de l'étendre.",{"type":27,"tag":267,"props":6345,"children":6346},{},[6347],{"type":32,"value":6348},"Partager les succès pour embarquer les autres équipes par capillarité.",{"type":27,"tag":55,"props":6350,"children":6351},{},[],{"type":27,"tag":3853,"props":6353,"children":6355},{"id":6354},"en-résumé-5",[6356],{"type":27,"tag":74,"props":6357,"children":6358},{},[6359],{"type":32,"value":1578},{"type":27,"tag":263,"props":6361,"children":6362},{},[6363,6368,6373,6378],{"type":27,"tag":267,"props":6364,"children":6365},{},[6366],{"type":32,"value":6367},"Culture collaborative et transparente : sans dialogue, pas de BDD.",{"type":27,"tag":267,"props":6369,"children":6370},{},[6371],{"type":32,"value":6372},"Scénarios vivants, mis à jour en continu.",{"type":27,"tag":267,"props":6374,"children":6375},{},[6376],{"type":32,"value":6377},"Intégration dans la DoD pour ancrer la pratique.",{"type":27,"tag":267,"props":6379,"children":6380},{},[6381],{"type":32,"value":6382},"Adoption progressive avec pilote, partage de résultats, puis extension.",{"type":27,"tag":59,"props":6384,"children":6386},{"id":6385},"faq-réponses-aux-questions-fréquentes-sur-le-bdd",[6387],{"type":27,"tag":74,"props":6388,"children":6389},{},[6390],{"type":32,"value":6391},"FAQ : Réponses aux questions fréquentes sur le BDD",{"type":27,"tag":28,"props":6393,"children":6394},{},[6395],{"type":32,"value":6396},"Les questions qui reviennent systématiquement en mission, avec des réponses qui permettent de passer à l'action.",{"type":27,"tag":393,"props":6398,"children":6399},{},[6400,6405,6410,6423],{"type":27,"tag":397,"props":6401,"children":6402},{},[6403],{"type":32,"value":6404},"1. Combien de temps faut-il pour adopter le BDD dans une équipe ?",{"type":27,"tag":28,"props":6406,"children":6407},{},[6408],{"type":32,"value":6409},"Ça dépend de la taille et de la motivation.",{"type":27,"tag":263,"props":6411,"children":6412},{},[6413,6418],{"type":27,"tag":267,"props":6414,"children":6415},{},[6416],{"type":32,"value":6417},"Petite équipe motivée : 2 à 4 sprints pour la première version stable des scénarios automatisés.",{"type":27,"tag":267,"props":6419,"children":6420},{},[6421],{"type":32,"value":6422},"Organisation plus large : plusieurs mois, surtout si la culture doit bouger en parallèle.",{"type":27,"tag":28,"props":6424,"children":6425},{},[6426],{"type":32,"value":6427},"Mon conseil : commencer par un projet pilote sur un workflow critique. C'est toujours le chemin le plus court.",{"type":27,"tag":393,"props":6429,"children":6430},{},[6431,6436,6441],{"type":27,"tag":397,"props":6432,"children":6433},{},[6434],{"type":32,"value":6435},"2. Que faire si mon équipe résiste à adopter le BDD ?",{"type":27,"tag":28,"props":6437,"children":6438},{},[6439],{"type":32,"value":6440},"Trois leviers qui marchent :",{"type":27,"tag":263,"props":6442,"children":6443},{},[6444,6454,6464],{"type":27,"tag":267,"props":6445,"children":6446},{},[6447,6452],{"type":27,"tag":74,"props":6448,"children":6449},{},[6450],{"type":32,"value":6451},"Démonstration concrète",{"type":32,"value":6453}," : un atelier d'une heure sur une vraie story, scénarios écrits sur place. Pas de théorie.",{"type":27,"tag":267,"props":6455,"children":6456},{},[6457,6462],{"type":27,"tag":74,"props":6458,"children":6459},{},[6460],{"type":32,"value":6461},"Pilote ciblé",{"type":32,"value":6463}," : une fonctionnalité clé, des résultats visibles au premier sprint.",{"type":27,"tag":267,"props":6465,"children":6466},{},[6467,6472],{"type":27,"tag":74,"props":6468,"children":6469},{},[6470],{"type":32,"value":6471},"Sponsoring leadership",{"type":32,"value":6473}," : sans soutien managérial explicite, le BDD ne survit pas au troisième sprint.",{"type":27,"tag":393,"props":6475,"children":6476},{},[6477,6482],{"type":27,"tag":397,"props":6478,"children":6479},{},[6480],{"type":32,"value":6481},"3. Le BDD est-il pertinent pour les tests non fonctionnels ?",{"type":27,"tag":28,"props":6483,"children":6484},{},[6485],{"type":32,"value":6486},"Oui, et c'est sous-utilisé. On peut écrire un scénario qui décrit un temps de réponse maximal, l'automatiser avec Gatling ou JMeter, et le faire tourner en CI au même titre qu'un test fonctionnel. La sécurité (OWASP ZAP) entre dans la même logique.",{"type":27,"tag":393,"props":6488,"children":6489},{},[6490,6495],{"type":27,"tag":397,"props":6491,"children":6492},{},[6493],{"type":32,"value":6494},"4. Faut-il rédiger des scénarios BDD pour toutes les user stories ?",{"type":27,"tag":28,"props":6496,"children":6497},{},[6498],{"type":32,"value":6499},"Non. Concentrer l'effort sur les stories à forte valeur métier ou à comportement complexe. Les stories simples (CRUD basique, fixes mineurs) se contentent de tests unitaires classiques. Sur-utiliser le BDD le décrédibilise.",{"type":27,"tag":3853,"props":6501,"children":6503},{"id":6502},"en-résumé-6",[6504],{"type":27,"tag":74,"props":6505,"children":6506},{},[6507],{"type":32,"value":1578},{"type":27,"tag":28,"props":6509,"children":6510},{},[6511],{"type":32,"value":6512},"Le BDD s'adapte au contexte. Commencer petit, ancrer le dialogue entre PO\u002Fdev\u002FQA, automatiser ce qui peut l'être. Le reste suit.",{"type":27,"tag":55,"props":6514,"children":6515},{},[],{"type":27,"tag":216,"props":6517,"children":6518},{"cta":464,"href":465,"title":466,"type":467},[6519],{"type":27,"tag":28,"props":6520,"children":6521},{},[6522],{"type":32,"value":6523},"Le framework 4 phases appliqué dans 12 équipes engineering. Le BDD est une des clés pour réduire le lead time. Découvrez comment combiner collaboration, automatisation et delivery pour livrer deux fois plus vite.",{"type":27,"tag":6525,"props":6526,"children":6527},"style",{},[6528],{"type":32,"value":6529},"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":475,"depth":475,"links":6531},[6532,6533,6538,6544,6551,6558,6564,6572,6581],{"id":3816,"depth":475,"text":3822},{"id":3840,"depth":475,"text":3846,"children":6534},[6535,6536,6537],{"id":3855,"depth":4205,"text":3861},{"id":3895,"depth":4205,"text":3901},{"id":3942,"depth":4205,"text":3948},{"id":3993,"depth":475,"text":3999,"children":6539},[6540,6541,6542,6543],{"id":4010,"depth":4205,"text":4016},{"id":4102,"depth":4205,"text":4108},{"id":4247,"depth":4205,"text":4253},{"id":1575,"depth":4205,"text":1578},{"id":4354,"depth":475,"text":4360,"children":6545},[6546,6547,6548,6549,6550],{"id":4371,"depth":4205,"text":4377},{"id":4437,"depth":4205,"text":4443},{"id":4502,"depth":4205,"text":4508},{"id":4567,"depth":4205,"text":4573},{"id":4625,"depth":4205,"text":1578},{"id":4656,"depth":475,"text":4662,"children":6552},[6553,6554,6555,6556,6557],{"id":4673,"depth":4205,"text":4679},{"id":4730,"depth":4205,"text":4736},{"id":4851,"depth":4205,"text":4857},{"id":4989,"depth":4205,"text":4995},{"id":5044,"depth":4205,"text":1578},{"id":5057,"depth":475,"text":5063,"children":6559},[6560,6561,6562,6563],{"id":5074,"depth":4205,"text":5080},{"id":5245,"depth":4205,"text":5251},{"id":5345,"depth":4205,"text":5351},{"id":5700,"depth":4205,"text":1578},{"id":5726,"depth":475,"text":5732,"children":6565},[6566,6567,6568,6569,6570,6571],{"id":5743,"depth":4205,"text":5749},{"id":5802,"depth":4205,"text":5808},{"id":5852,"depth":4205,"text":5858},{"id":5922,"depth":4205,"text":5928},{"id":5972,"depth":4205,"text":5978},{"id":6032,"depth":4205,"text":1578},{"id":6063,"depth":475,"text":6069,"children":6573},[6574,6575,6576,6577,6578,6579,6580],{"id":6080,"depth":4205,"text":6086},{"id":6139,"depth":4205,"text":6145},{"id":6197,"depth":4205,"text":6203},{"id":6235,"depth":4205,"text":6241},{"id":6278,"depth":4205,"text":6284},{"id":6316,"depth":4205,"text":6322},{"id":6354,"depth":4205,"text":1578},{"id":6385,"depth":475,"text":6391,"children":6582},[6583],{"id":6502,"depth":4205,"text":1578},"content:fr:pratiques-agiles:adopter-behaviour-driven-development-bdd-guide-agile.md","fr\u002Fpratiques-agiles\u002Fadopter-behaviour-driven-development-bdd-guide-agile.md","fr\u002Fpratiques-agiles\u002Fadopter-behaviour-driven-development-bdd-guide-agile",{"_path":6588,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":6589,"description":6590,"id":6591,"date":6592,"listed":13,"nocomments":7,"hidden":7,"categories":6593,"tags":6594,"cover":6595,"readingTime":6596,"body":6601,"_type":483,"_id":9548,"_source":485,"_file":9549,"_stem":9550,"_extension":488},"\u002Ffr\u002Fpratiques-agiles\u002Fuser-stories-vs-requirements-guide-complet","Pourquoi les user stories ne sont pas des requirements et comment bien les gérer ?","Découvrez pourquoi il est essentiel de partir des requirements pour écrire vos user stories, comment les structurer efficacement, et éviter les erreurs courantes.",60,"2024-11-21",[6],[16,498],"covers\u002Farticles\u002Fuser-stories-vs-requirements.jpg",{"text":6597,"minutes":6598,"time":6599,"words":6600},"17 min read",16.5,990000,3300,{"type":24,"children":6602,"toc":9496},[6603,6608,6620,6625,6630,6639,6644,6647,6656,6681,6686,6717,6725,6756,6761,6794,6797,6806,6811,6816,6859,6867,6882,6887,6920,6923,6932,7072,7082,7091,7096,7099,7108,7120,7127,7142,7147,7150,7159,7164,7169,7222,7229,7244,7247,7256,7261,7268,7283,7286,7295,7300,7307,7322,7325,7334,7339,7347,7386,7389,7398,7431,7440,7449,7454,7457,7466,7478,7486,7518,7521,7530,7535,7543,7589,7592,7601,7609,7624,7632,7663,7671,7710,7713,7722,7727,7760,7765,7768,7777,7800,7809,7814,7824,7828,7850,7855,7865,7875,7885,7894,7899,7910,7919,7924,7932,7947,7952,7960,7975,7980,7988,8003,8008,8016,8031,8036,8044,8059,8064,8072,8087,8092,8102,8111,8116,8119,8128,8133,8141,8171,8179,8256,8259,8268,8278,8288,8298,8301,8310,8315,8323,8338,8345,8461,8464,8473,8516,8519,8528,8561,8570,8575,8578,8587,8592,8700,8705,8708,8717,8722,8726,8776,8844,8847,8856,8861,8894,8904,8907,8916,8949,8953,8982,8985,8994,9030,9039,9044,9047,9056,9061,9071,9074,9083,9118,9135,9138,9147,9152,9161,9176,9179,9188,9193,9202,9205,9214,9219,9228,9231,9240,9245,9254,9257,9266,9271,9280,9283,9292,9297,9306,9315,9320,9331,9340,9345,9380,9411,9424,9455,9481,9484,9492],{"type":27,"tag":28,"props":6604,"children":6605},{},[6606],{"type":32,"value":6607},"J'accompagnais une équipe d'une grande banque française il y a quelques années. Six mois de développement, un backlog rempli de user stories rédigées au cordeau, des sprints qui tournaient. Sur le papier, tout allait bien. Sauf que personne n'avait formalisé les exigences réglementaires en amont. Résultat : à la veille d'une revue de conformité, on s'est rendu compte qu'aucune contrainte RGPD ni aucun contrôle KYC n'avait été tracé. Deux sprints entiers de rattrapage pour réintégrer ce qui aurait dû être posé dès le départ.",{"type":27,"tag":28,"props":6609,"children":6610},{},[6611,6613,6618],{"type":32,"value":6612},"Cette équipe avait pris au mot un slogan qu'on entend partout : ",{"type":27,"tag":524,"props":6614,"children":6615},{},[6616],{"type":32,"value":6617},"les user stories remplacent les requirements",{"type":32,"value":6619},". C'est faux. Et c'est précisément ce que cet article démonte.",{"type":27,"tag":28,"props":6621,"children":6622},{},[6623],{"type":32,"value":6624},"Les user stories captent un besoin utilisateur à un instant T. Les requirements définissent la vision durable du produit, incluant tout ce qu'un utilisateur ne formule jamais : performance, sécurité, conformité, contraintes d'intégration. Confondre les deux, ou se passer du second, expose à des oublis structurels qui coûtent cher en fin de course.",{"type":27,"tag":28,"props":6626,"children":6627},{},[6628],{"type":32,"value":6629},"Au programme : la distinction fondamentale entre les deux artefacts, pourquoi les requirements doivent précéder les stories, comment les structurer, et les erreurs que je vois revenir sprint après sprint en mission.",{"type":27,"tag":59,"props":6631,"children":6633},{"id":6632},"les-différences-fondamentales-entre-user-stories-et-requirements",[6634],{"type":27,"tag":74,"props":6635,"children":6636},{},[6637],{"type":32,"value":6638},"Les différences fondamentales entre user stories et requirements",{"type":27,"tag":28,"props":6640,"children":6641},{},[6642],{"type":32,"value":6643},"User stories et requirements ne s'opposent pas : ils opèrent à deux niveaux différents. Confondre les deux, ou utiliser l'un comme substitut de l'autre, génère des trous structurels que personne ne voit avant la mise en prod.",{"type":27,"tag":55,"props":6645,"children":6646},{},[],{"type":27,"tag":3853,"props":6648,"children":6650},{"id":6649},"_1-user-stories-des-artefacts-centrés-sur-lutilisateur",[6651],{"type":27,"tag":74,"props":6652,"children":6653},{},[6654],{"type":32,"value":6655},"1. User stories : Des artefacts centrés sur l’utilisateur",{"type":27,"tag":28,"props":6657,"children":6658},{},[6659,6661,6665,6667,6672,6674,6679],{"type":32,"value":6660},"Une user story capte un besoin du point de vue utilisateur. Elle répond au ",{"type":27,"tag":74,"props":6662,"children":6663},{},[6664],{"type":32,"value":3871},{"type":32,"value":6666}," et au ",{"type":27,"tag":74,"props":6668,"children":6669},{},[6670],{"type":32,"value":6671},"\"pourquoi\"",{"type":32,"value":6673},", sans entrer dans le technique. Mike Cohn a formalisé ce format dans ",{"type":27,"tag":524,"props":6675,"children":6676},{},[6677],{"type":32,"value":6678},"User Stories Applied",{"type":32,"value":6680},", l'ouvrage de référence que je recommande à tout PO que j'accompagne.",{"type":27,"tag":28,"props":6682,"children":6683},{},[6684],{"type":32,"value":6685},"Format classique :",{"type":27,"tag":4174,"props":6687,"children":6689},{"className":4176,"code":6688,"language":4178,"meta":8,"style":8},"En tant que [type d'utilisateur],  \nJe veux [action ou fonctionnalité],  \nAfin de [objectif ou bénéfice].  \n",[6690],{"type":27,"tag":4181,"props":6691,"children":6692},{"__ignoreMap":8},[6693,6701,6709],{"type":27,"tag":4185,"props":6694,"children":6695},{"class":4187,"line":4188},[6696],{"type":27,"tag":4185,"props":6697,"children":6698},{},[6699],{"type":32,"value":6700},"En tant que [type d'utilisateur],  \n",{"type":27,"tag":4185,"props":6702,"children":6703},{"class":4187,"line":475},[6704],{"type":27,"tag":4185,"props":6705,"children":6706},{},[6707],{"type":32,"value":6708},"Je veux [action ou fonctionnalité],  \n",{"type":27,"tag":4185,"props":6710,"children":6711},{"class":4187,"line":4205},[6712],{"type":27,"tag":4185,"props":6713,"children":6714},{},[6715],{"type":32,"value":6716},"Afin de [objectif ou bénéfice].\n",{"type":27,"tag":28,"props":6718,"children":6719},{},[6720],{"type":27,"tag":74,"props":6721,"children":6722},{},[6723],{"type":32,"value":6724},"Exemple :",{"type":27,"tag":4174,"props":6726,"children":6728},{"className":4176,"code":6727,"language":4178,"meta":8,"style":8},"En tant qu’utilisateur inscrit,  \nJe veux pouvoir réinitialiser mon mot de passe,  \nAfin de retrouver l’accès à mon compte sans assistance.  \n",[6729],{"type":27,"tag":4181,"props":6730,"children":6731},{"__ignoreMap":8},[6732,6740,6748],{"type":27,"tag":4185,"props":6733,"children":6734},{"class":4187,"line":4188},[6735],{"type":27,"tag":4185,"props":6736,"children":6737},{},[6738],{"type":32,"value":6739},"En tant qu’utilisateur inscrit,  \n",{"type":27,"tag":4185,"props":6741,"children":6742},{"class":4187,"line":475},[6743],{"type":27,"tag":4185,"props":6744,"children":6745},{},[6746],{"type":32,"value":6747},"Je veux pouvoir réinitialiser mon mot de passe,  \n",{"type":27,"tag":4185,"props":6749,"children":6750},{"class":4187,"line":4205},[6751],{"type":27,"tag":4185,"props":6752,"children":6753},{},[6754],{"type":32,"value":6755},"Afin de retrouver l’accès à mon compte sans assistance.\n",{"type":27,"tag":28,"props":6757,"children":6758},{},[6759],{"type":32,"value":6760},"Trois caractéristiques :",{"type":27,"tag":263,"props":6762,"children":6763},{},[6764,6774,6784],{"type":27,"tag":267,"props":6765,"children":6766},{},[6767,6772],{"type":27,"tag":74,"props":6768,"children":6769},{},[6770],{"type":32,"value":6771},"Simple et compréhensible",{"type":32,"value":6773}," par toutes les parties prenantes.",{"type":27,"tag":267,"props":6775,"children":6776},{},[6777,6782],{"type":27,"tag":74,"props":6778,"children":6779},{},[6780],{"type":32,"value":6781},"Évolutive",{"type":32,"value":6783}," : on raffine au fil des sprints.",{"type":27,"tag":267,"props":6785,"children":6786},{},[6787,6792],{"type":27,"tag":74,"props":6788,"children":6789},{},[6790],{"type":32,"value":6791},"Jetable",{"type":32,"value":6793}," : une fois livrée, la story disparaît du backlog actif.",{"type":27,"tag":55,"props":6795,"children":6796},{},[],{"type":27,"tag":3853,"props":6798,"children":6800},{"id":6799},"_2-requirements-une-documentation-durable-et-détaillée",[6801],{"type":27,"tag":74,"props":6802,"children":6803},{},[6804],{"type":32,"value":6805},"2. Requirements : Une documentation durable et détaillée",{"type":27,"tag":28,"props":6807,"children":6808},{},[6809],{"type":32,"value":6810},"Les requirements décrivent les besoins métier, techniques et organisationnels dans leur globalité. Contrairement aux stories, ils ne se limitent pas au point de vue utilisateur : ils capturent aussi les contraintes que l'utilisateur ne formule jamais (sécurité, performance, conformité légale).",{"type":27,"tag":28,"props":6812,"children":6813},{},[6814],{"type":32,"value":6815},"Quatre catégories :",{"type":27,"tag":263,"props":6817,"children":6818},{},[6819,6829,6839,6849],{"type":27,"tag":267,"props":6820,"children":6821},{},[6822,6827],{"type":27,"tag":74,"props":6823,"children":6824},{},[6825],{"type":32,"value":6826},"Fonctionnels",{"type":32,"value":6828}," : ce que le système doit faire.",{"type":27,"tag":267,"props":6830,"children":6831},{},[6832,6837],{"type":27,"tag":74,"props":6833,"children":6834},{},[6835],{"type":32,"value":6836},"Non fonctionnels (NFR)",{"type":32,"value":6838}," : performance, sécurité, scalabilité, accessibilité.",{"type":27,"tag":267,"props":6840,"children":6841},{},[6842,6847],{"type":27,"tag":74,"props":6843,"children":6844},{},[6845],{"type":32,"value":6846},"Contraintes techniques",{"type":32,"value":6848}," : technologies imposées, intégrations tierces.",{"type":27,"tag":267,"props":6850,"children":6851},{},[6852,6857],{"type":27,"tag":74,"props":6853,"children":6854},{},[6855],{"type":32,"value":6856},"Règlementaires",{"type":32,"value":6858}," : conformité aux normes ou lois (RGPD, PCI-DSS, etc.).",{"type":27,"tag":28,"props":6860,"children":6861},{},[6862],{"type":27,"tag":74,"props":6863,"children":6864},{},[6865],{"type":32,"value":6866},"Exemple (NFR) :",{"type":27,"tag":4174,"props":6868,"children":6870},{"className":4176,"code":6869,"language":4178,"meta":8,"style":8},"Le système doit être capable de gérer 10 000 connexions simultanées avec un temps de réponse inférieur à 3 secondes.  \n",[6871],{"type":27,"tag":4181,"props":6872,"children":6873},{"__ignoreMap":8},[6874],{"type":27,"tag":4185,"props":6875,"children":6876},{"class":4187,"line":4188},[6877],{"type":27,"tag":4185,"props":6878,"children":6879},{},[6880],{"type":32,"value":6881},"Le système doit être capable de gérer 10 000 connexions simultanées avec un temps de réponse inférieur à 3 secondes.\n",{"type":27,"tag":28,"props":6883,"children":6884},{},[6885],{"type":32,"value":6886},"Trois caractéristiques en miroir :",{"type":27,"tag":263,"props":6888,"children":6889},{},[6890,6900,6910],{"type":27,"tag":267,"props":6891,"children":6892},{},[6893,6898],{"type":27,"tag":74,"props":6894,"children":6895},{},[6896],{"type":32,"value":6897},"Précis et complet",{"type":32,"value":6899}," : base stable pour la conception.",{"type":27,"tag":267,"props":6901,"children":6902},{},[6903,6908],{"type":27,"tag":74,"props":6904,"children":6905},{},[6906],{"type":32,"value":6907},"Durable",{"type":32,"value":6909}," : reste valable après la livraison.",{"type":27,"tag":267,"props":6911,"children":6912},{},[6913,6918],{"type":27,"tag":74,"props":6914,"children":6915},{},[6916],{"type":32,"value":6917},"Traçable",{"type":32,"value":6919}," : référence dans tout le cycle de vie du produit.",{"type":27,"tag":55,"props":6921,"children":6922},{},[],{"type":27,"tag":3853,"props":6924,"children":6926},{"id":6925},"_3-résumé-des-différences",[6927],{"type":27,"tag":74,"props":6928,"children":6929},{},[6930],{"type":32,"value":6931},"3. Résumé des différences",{"type":27,"tag":1580,"props":6933,"children":6934},{},[6935,6965],{"type":27,"tag":1584,"props":6936,"children":6937},{},[6938],{"type":27,"tag":1588,"props":6939,"children":6940},{},[6941,6949,6957],{"type":27,"tag":1592,"props":6942,"children":6943},{},[6944],{"type":27,"tag":74,"props":6945,"children":6946},{},[6947],{"type":32,"value":6948},"Aspect",{"type":27,"tag":1592,"props":6950,"children":6951},{},[6952],{"type":27,"tag":74,"props":6953,"children":6954},{},[6955],{"type":32,"value":6956},"User Stories",{"type":27,"tag":1592,"props":6958,"children":6959},{},[6960],{"type":27,"tag":74,"props":6961,"children":6962},{},[6963],{"type":32,"value":6964},"Requirements",{"type":27,"tag":1608,"props":6966,"children":6967},{},[6968,6989,7009,7030,7051],{"type":27,"tag":1588,"props":6969,"children":6970},{},[6971,6979,6984],{"type":27,"tag":1615,"props":6972,"children":6973},{},[6974],{"type":27,"tag":74,"props":6975,"children":6976},{},[6977],{"type":32,"value":6978},"Point de vue",{"type":27,"tag":1615,"props":6980,"children":6981},{},[6982],{"type":32,"value":6983},"Utilisateur",{"type":27,"tag":1615,"props":6985,"children":6986},{},[6987],{"type":32,"value":6988},"Métier et technique",{"type":27,"tag":1588,"props":6990,"children":6991},{},[6992,6999,7004],{"type":27,"tag":1615,"props":6993,"children":6994},{},[6995],{"type":27,"tag":74,"props":6996,"children":6997},{},[6998],{"type":32,"value":4094},{"type":27,"tag":1615,"props":7000,"children":7001},{},[7002],{"type":32,"value":7003},"Capturer un besoin utilisateur",{"type":27,"tag":1615,"props":7005,"children":7006},{},[7007],{"type":32,"value":7008},"Capturer des besoins détaillés et durables",{"type":27,"tag":1588,"props":7010,"children":7011},{},[7012,7020,7025],{"type":27,"tag":1615,"props":7013,"children":7014},{},[7015],{"type":27,"tag":74,"props":7016,"children":7017},{},[7018],{"type":32,"value":7019},"Détail",{"type":27,"tag":1615,"props":7021,"children":7022},{},[7023],{"type":32,"value":7024},"Général, laisse place à l’interprétation",{"type":27,"tag":1615,"props":7026,"children":7027},{},[7028],{"type":32,"value":7029},"Exhaustif et précis",{"type":27,"tag":1588,"props":7031,"children":7032},{},[7033,7041,7046],{"type":27,"tag":1615,"props":7034,"children":7035},{},[7036],{"type":27,"tag":74,"props":7037,"children":7038},{},[7039],{"type":32,"value":7040},"Évolutivité",{"type":27,"tag":1615,"props":7042,"children":7043},{},[7044],{"type":32,"value":7045},"Remplaçables, jetables",{"type":27,"tag":1615,"props":7047,"children":7048},{},[7049],{"type":32,"value":7050},"Vivants, adaptés en continu",{"type":27,"tag":1588,"props":7052,"children":7053},{},[7054,7062,7067],{"type":27,"tag":1615,"props":7055,"children":7056},{},[7057],{"type":27,"tag":74,"props":7058,"children":7059},{},[7060],{"type":32,"value":7061},"Type d’information",{"type":27,"tag":1615,"props":7063,"children":7064},{},[7065],{"type":32,"value":7066},"Fonctionnalités spécifiques",{"type":27,"tag":1615,"props":7068,"children":7069},{},[7070],{"type":32,"value":7071},"Fonctionnel, non fonctionnel, technique",{"type":27,"tag":28,"props":7073,"children":7074},{},[7075,7080],{"type":27,"tag":74,"props":7076,"children":7077},{},[7078],{"type":32,"value":7079},"Piège courant",{"type":32,"value":7081}," : partir uniquement des user stories pour définir les besoins. Vision court-termiste, et oublis structurels sur la performance, la sécurité, la conformité.",{"type":27,"tag":59,"props":7083,"children":7085},{"id":7084},"les-types-de-requirements-à-connaître",[7086],{"type":27,"tag":74,"props":7087,"children":7088},{},[7089],{"type":32,"value":7090},"Les types de requirements à connaître",{"type":27,"tag":28,"props":7092,"children":7093},{},[7094],{"type":32,"value":7095},"Tous les besoins n'ont pas le même statut. Les regrouper en catégories évite les oublis structurels et oriente correctement la priorisation.",{"type":27,"tag":55,"props":7097,"children":7098},{},[],{"type":27,"tag":3853,"props":7100,"children":7102},{"id":7101},"_1-les-requirements-fonctionnels",[7103],{"type":27,"tag":74,"props":7104,"children":7105},{},[7106],{"type":32,"value":7107},"1. Les requirements fonctionnels",{"type":27,"tag":28,"props":7109,"children":7110},{},[7111,7113,7118],{"type":32,"value":7112},"Décrivent ",{"type":27,"tag":74,"props":7114,"children":7115},{},[7116],{"type":32,"value":7117},"ce que le système doit faire",{"type":32,"value":7119}," pour répondre aux besoins métier.",{"type":27,"tag":28,"props":7121,"children":7122},{},[7123],{"type":27,"tag":74,"props":7124,"children":7125},{},[7126],{"type":32,"value":6724},{"type":27,"tag":4174,"props":7128,"children":7130},{"className":4176,"code":7129,"language":4178,"meta":8,"style":8},"Le système doit permettre aux utilisateurs inscrits de télécharger une facture mensuelle au format PDF.  \n",[7131],{"type":27,"tag":4181,"props":7132,"children":7133},{"__ignoreMap":8},[7134],{"type":27,"tag":4185,"props":7135,"children":7136},{"class":4187,"line":4188},[7137],{"type":27,"tag":4185,"props":7138,"children":7139},{},[7140],{"type":32,"value":7141},"Le système doit permettre aux utilisateurs inscrits de télécharger une facture mensuelle au format PDF.\n",{"type":27,"tag":28,"props":7143,"children":7144},{},[7145],{"type":32,"value":7146},"Centrés sur le \"quoi\", sans préjuger du \"comment\".",{"type":27,"tag":55,"props":7148,"children":7149},{},[],{"type":27,"tag":3853,"props":7151,"children":7153},{"id":7152},"_2-les-requirements-non-fonctionnels-nfr",[7154],{"type":27,"tag":74,"props":7155,"children":7156},{},[7157],{"type":32,"value":7158},"2. Les requirements non fonctionnels (NFR)",{"type":27,"tag":28,"props":7160,"children":7161},{},[7162],{"type":32,"value":7163},"Définissent les qualités attendues : performance, sécurité, scalabilité, accessibilité, maintenabilité. Ce sont des contraintes transversales, souvent invisibles tant que tout va bien, fatales quand elles sont oubliées.",{"type":27,"tag":28,"props":7165,"children":7166},{},[7167],{"type":32,"value":7168},"Catégories types :",{"type":27,"tag":263,"props":7170,"children":7171},{},[7172,7182,7192,7202,7212],{"type":27,"tag":267,"props":7173,"children":7174},{},[7175,7180],{"type":27,"tag":74,"props":7176,"children":7177},{},[7178],{"type":32,"value":7179},"Performance",{"type":32,"value":7181}," : temps de réponse, volume supporté.",{"type":27,"tag":267,"props":7183,"children":7184},{},[7185,7190],{"type":27,"tag":74,"props":7186,"children":7187},{},[7188],{"type":32,"value":7189},"Sécurité",{"type":32,"value":7191}," : confidentialité, contrôle d'accès, protection contre les attaques.",{"type":27,"tag":267,"props":7193,"children":7194},{},[7195,7200],{"type":27,"tag":74,"props":7196,"children":7197},{},[7198],{"type":32,"value":7199},"Scalabilité",{"type":32,"value":7201}," : montée en charge.",{"type":27,"tag":267,"props":7203,"children":7204},{},[7205,7210],{"type":27,"tag":74,"props":7206,"children":7207},{},[7208],{"type":32,"value":7209},"Accessibilité",{"type":32,"value":7211}," : conformité WCAG.",{"type":27,"tag":267,"props":7213,"children":7214},{},[7215,7220],{"type":27,"tag":74,"props":7216,"children":7217},{},[7218],{"type":32,"value":7219},"Maintenabilité",{"type":32,"value":7221}," : facilité d'évolution du code.",{"type":27,"tag":28,"props":7223,"children":7224},{},[7225],{"type":27,"tag":74,"props":7226,"children":7227},{},[7228],{"type":32,"value":6724},{"type":27,"tag":4174,"props":7230,"children":7232},{"className":4176,"code":7231,"language":4178,"meta":8,"style":8},"Le système doit pouvoir gérer 5000 requêtes par seconde avec un temps de réponse inférieur à 200 ms.  \n",[7233],{"type":27,"tag":4181,"props":7234,"children":7235},{"__ignoreMap":8},[7236],{"type":27,"tag":4185,"props":7237,"children":7238},{"class":4187,"line":4188},[7239],{"type":27,"tag":4185,"props":7240,"children":7241},{},[7242],{"type":32,"value":7243},"Le système doit pouvoir gérer 5000 requêtes par seconde avec un temps de réponse inférieur à 200 ms.\n",{"type":27,"tag":55,"props":7245,"children":7246},{},[],{"type":27,"tag":3853,"props":7248,"children":7250},{"id":7249},"_3-les-contraintes-techniques",[7251],{"type":27,"tag":74,"props":7252,"children":7253},{},[7254],{"type":32,"value":7255},"3. Les contraintes techniques",{"type":27,"tag":28,"props":7257,"children":7258},{},[7259],{"type":32,"value":7260},"Imposent des choix technologiques ou des intégrations.",{"type":27,"tag":28,"props":7262,"children":7263},{},[7264],{"type":27,"tag":74,"props":7265,"children":7266},{},[7267],{"type":32,"value":6724},{"type":27,"tag":4174,"props":7269,"children":7271},{"className":4176,"code":7270,"language":4178,"meta":8,"style":8},"Le système doit s'intégrer avec le service d'authentification OAuth 2.0 pour la gestion des connexions utilisateurs.  \n",[7272],{"type":27,"tag":4181,"props":7273,"children":7274},{"__ignoreMap":8},[7275],{"type":27,"tag":4185,"props":7276,"children":7277},{"class":4187,"line":4188},[7278],{"type":27,"tag":4185,"props":7279,"children":7280},{},[7281],{"type":32,"value":7282},"Le système doit s'intégrer avec le service d'authentification OAuth 2.0 pour la gestion des connexions utilisateurs.\n",{"type":27,"tag":55,"props":7284,"children":7285},{},[],{"type":27,"tag":3853,"props":7287,"children":7289},{"id":7288},"_4-les-exigences-règlementaires",[7290],{"type":27,"tag":74,"props":7291,"children":7292},{},[7293],{"type":32,"value":7294},"4. Les exigences règlementaires",{"type":27,"tag":28,"props":7296,"children":7297},{},[7298],{"type":32,"value":7299},"Conformité aux lois et normes (RGPD, PCI-DSS, HIPAA, etc.).",{"type":27,"tag":28,"props":7301,"children":7302},{},[7303],{"type":27,"tag":74,"props":7304,"children":7305},{},[7306],{"type":32,"value":6724},{"type":27,"tag":4174,"props":7308,"children":7310},{"className":4176,"code":7309,"language":4178,"meta":8,"style":8},"Toutes les données utilisateur doivent être anonymisées avant d’être stockées pour des analyses statistiques.  \n",[7311],{"type":27,"tag":4181,"props":7312,"children":7313},{"__ignoreMap":8},[7314],{"type":27,"tag":4185,"props":7315,"children":7316},{"class":4187,"line":4188},[7317],{"type":27,"tag":4185,"props":7318,"children":7319},{},[7320],{"type":32,"value":7321},"Toutes les données utilisateur doivent être anonymisées avant d’être stockées pour des analyses statistiques.\n",{"type":27,"tag":55,"props":7323,"children":7324},{},[],{"type":27,"tag":3853,"props":7326,"children":7328},{"id":7327},"_5-les-critères-dacceptation-un-pont-entre-requirements-et-user-stories",[7329],{"type":27,"tag":74,"props":7330,"children":7331},{},[7332],{"type":32,"value":7333},"5. Les critères d’acceptation : Un pont entre requirements et user stories",{"type":27,"tag":28,"props":7335,"children":7336},{},[7337],{"type":32,"value":7338},"Les critères d'acceptation traduisent un besoin en conditions testables. Ils valident qu'une user story ou un requirement est satisfait.",{"type":27,"tag":28,"props":7340,"children":7341},{},[7342],{"type":27,"tag":74,"props":7343,"children":7344},{},[7345],{"type":32,"value":7346},"Exemple pour une user story :",{"type":27,"tag":4174,"props":7348,"children":7350},{"className":4176,"code":7349,"language":4178,"meta":8,"style":8},"Scénario : Réinitialisation du mot de passe  \nÉtant donné un utilisateur inscrit,  \nLorsqu'il demande à réinitialiser son mot de passe,  \nAlors il doit recevoir un email contenant un lien valable 24 heures.  \n",[7351],{"type":27,"tag":4181,"props":7352,"children":7353},{"__ignoreMap":8},[7354,7362,7370,7378],{"type":27,"tag":4185,"props":7355,"children":7356},{"class":4187,"line":4188},[7357],{"type":27,"tag":4185,"props":7358,"children":7359},{},[7360],{"type":32,"value":7361},"Scénario : Réinitialisation du mot de passe  \n",{"type":27,"tag":4185,"props":7363,"children":7364},{"class":4187,"line":475},[7365],{"type":27,"tag":4185,"props":7366,"children":7367},{},[7368],{"type":32,"value":7369},"Étant donné un utilisateur inscrit,  \n",{"type":27,"tag":4185,"props":7371,"children":7372},{"class":4187,"line":4205},[7373],{"type":27,"tag":4185,"props":7374,"children":7375},{},[7376],{"type":32,"value":7377},"Lorsqu'il demande à réinitialiser son mot de passe,  \n",{"type":27,"tag":4185,"props":7379,"children":7380},{"class":4187,"line":4214},[7381],{"type":27,"tag":4185,"props":7382,"children":7383},{},[7384],{"type":32,"value":7385},"Alors il doit recevoir un email contenant un lien valable 24 heures.\n",{"type":27,"tag":55,"props":7387,"children":7388},{},[],{"type":27,"tag":3853,"props":7390,"children":7392},{"id":7391},"_6-pourquoi-cette-catégorisation-compte",[7393],{"type":27,"tag":74,"props":7394,"children":7395},{},[7396],{"type":32,"value":7397},"6. Pourquoi cette catégorisation compte",{"type":27,"tag":263,"props":7399,"children":7400},{},[7401,7411,7421],{"type":27,"tag":267,"props":7402,"children":7403},{},[7404,7409],{"type":27,"tag":74,"props":7405,"children":7406},{},[7407],{"type":32,"value":7408},"Couverture complète",{"type":32,"value":7410}," : pas d'oubli sur la perf, la sécurité ou la conformité.",{"type":27,"tag":267,"props":7412,"children":7413},{},[7414,7419],{"type":27,"tag":74,"props":7415,"children":7416},{},[7417],{"type":32,"value":7418},"Priorisation lisible",{"type":32,"value":7420}," : chaque catégorie peut être triée selon sa valeur métier.",{"type":27,"tag":267,"props":7422,"children":7423},{},[7424,7429],{"type":27,"tag":74,"props":7425,"children":7426},{},[7427],{"type":32,"value":7428},"Traçabilité",{"type":32,"value":7430}," : les NFR survivent aux user stories qui les portent.",{"type":27,"tag":216,"props":7432,"children":7434},{"cta":218,"href":219,"title":7433,"type":221},"Vos sprints livrent, mais vous ne voyez pas ce qui manque vraiment dans le besoin ?",[7435],{"type":27,"tag":28,"props":7436,"children":7437},{},[7438],{"type":32,"value":7439},"Les trous structurels (NFR oubliés, requirements implicites, conformité jamais tracée) ne se lisent pas dans un burndown : ils se révèlent dans la façon dont votre équipe écrit et relie ses stories. En 30 minutes de diagnostic, je vous aide à cartographier ce que vos métriques de delivery ne capturent pas et à prioriser les 2-3 leviers qui sécuriseront vraiment votre backlog.",{"type":27,"tag":59,"props":7441,"children":7443},{"id":7442},"pourquoi-partir-des-requirements-pour-écrire-des-user-stories",[7444],{"type":27,"tag":74,"props":7445,"children":7446},{},[7447],{"type":32,"value":7448},"Pourquoi partir des requirements pour écrire des user stories ?",{"type":27,"tag":28,"props":7450,"children":7451},{},[7452],{"type":32,"value":7453},"Commencer par les requirements paraît contre-intuitif quand on a baigné dans le mantra Agile \"specs légères, itère vite\". Pourtant, c'est ce qui garantit la pérennité du backlog. Sans cette étape, on construit sur du sable.",{"type":27,"tag":55,"props":7455,"children":7456},{},[],{"type":27,"tag":3853,"props":7458,"children":7460},{"id":7459},"_1-les-requirements-une-base-solide-pour-tout-projet",[7461],{"type":27,"tag":74,"props":7462,"children":7463},{},[7464],{"type":32,"value":7465},"1. Les requirements : Une base solide pour tout projet",{"type":27,"tag":28,"props":7467,"children":7468},{},[7469,7471,7476],{"type":32,"value":7470},"Les requirements capturent la ",{"type":27,"tag":74,"props":7472,"children":7473},{},[7474],{"type":32,"value":7475},"vision globale",{"type":32,"value":7477}," : besoins métier, contraintes techniques, objectifs long terme.",{"type":27,"tag":28,"props":7479,"children":7480},{},[7481],{"type":27,"tag":74,"props":7482,"children":7483},{},[7484],{"type":32,"value":7485},"Ce que ça apporte :",{"type":27,"tag":263,"props":7487,"children":7488},{},[7489,7499,7509],{"type":27,"tag":267,"props":7490,"children":7491},{},[7492,7497],{"type":27,"tag":74,"props":7493,"children":7494},{},[7495],{"type":32,"value":7496},"Vision claire",{"type":32,"value":7498}," : objectifs produit et résultats attendus, formalisés.",{"type":27,"tag":267,"props":7500,"children":7501},{},[7502,7507],{"type":27,"tag":74,"props":7503,"children":7504},{},[7505],{"type":32,"value":7506},"Couverture exhaustive",{"type":32,"value":7508}," : performance, sécurité, conformité, ce que les user stories ratent.",{"type":27,"tag":267,"props":7510,"children":7511},{},[7512,7516],{"type":27,"tag":74,"props":7513,"children":7514},{},[7515],{"type":32,"value":7428},{"type":32,"value":7517}," : pour chaque fonctionnalité, on sait pourquoi elle existe.",{"type":27,"tag":55,"props":7519,"children":7520},{},[],{"type":27,"tag":3853,"props":7522,"children":7524},{"id":7523},"_2-les-user-stories-une-traduction-actionnable-des-requirements",[7525],{"type":27,"tag":74,"props":7526,"children":7527},{},[7528],{"type":32,"value":7529},"2. Les user stories : Une traduction actionnable des requirements",{"type":27,"tag":28,"props":7531,"children":7532},{},[7533],{"type":32,"value":7534},"Les user stories sont un outil de communication pour l'équipe de développement. Elles dérivent des requirements et les traduisent en fonctionnalités actionnables.",{"type":27,"tag":28,"props":7536,"children":7537},{},[7538],{"type":27,"tag":74,"props":7539,"children":7540},{},[7541],{"type":32,"value":7542},"Conséquences positives :",{"type":27,"tag":263,"props":7544,"children":7545},{},[7546,7556,7579],{"type":27,"tag":267,"props":7547,"children":7548},{},[7549,7554],{"type":27,"tag":74,"props":7550,"children":7551},{},[7552],{"type":32,"value":7553},"Alignement direct",{"type":32,"value":7555}," : chaque story se rattache à un requirement identifié.",{"type":27,"tag":267,"props":7557,"children":7558},{},[7559,7564,7566,7571,7573,7578],{"type":27,"tag":74,"props":7560,"children":7561},{},[7562],{"type":32,"value":7563},"Contexte riche",{"type":32,"value":7565}," : les devs savent ",{"type":27,"tag":524,"props":7567,"children":7568},{},[7569],{"type":32,"value":7570},"quoi faire",{"type":32,"value":7572}," et ",{"type":27,"tag":524,"props":7574,"children":7575},{},[7576],{"type":32,"value":7577},"pourquoi",{"type":32,"value":105},{"type":27,"tag":267,"props":7580,"children":7581},{},[7582,7587],{"type":27,"tag":74,"props":7583,"children":7584},{},[7585],{"type":32,"value":7586},"Backlog évolutif",{"type":32,"value":7588}," : un requirement bouge, les stories suivent sans perte de cohérence.",{"type":27,"tag":55,"props":7590,"children":7591},{},[],{"type":27,"tag":3853,"props":7593,"children":7595},{"id":7594},"_3-exemple-concret-du-requirement-à-la-user-story",[7596],{"type":27,"tag":74,"props":7597,"children":7598},{},[7599],{"type":32,"value":7600},"3. Exemple concret : Du requirement à la user story",{"type":27,"tag":28,"props":7602,"children":7603},{},[7604],{"type":27,"tag":74,"props":7605,"children":7606},{},[7607],{"type":32,"value":7608},"Requirement :",{"type":27,"tag":4174,"props":7610,"children":7612},{"className":4176,"code":7611,"language":4178,"meta":8,"style":8},"Le système doit permettre aux utilisateurs de visualiser en temps réel l’état de leur commande (préparation, expédition, livraison).  \n",[7613],{"type":27,"tag":4181,"props":7614,"children":7615},{"__ignoreMap":8},[7616],{"type":27,"tag":4185,"props":7617,"children":7618},{"class":4187,"line":4188},[7619],{"type":27,"tag":4185,"props":7620,"children":7621},{},[7622],{"type":32,"value":7623},"Le système doit permettre aux utilisateurs de visualiser en temps réel l’état de leur commande (préparation, expédition, livraison).\n",{"type":27,"tag":28,"props":7625,"children":7626},{},[7627],{"type":27,"tag":74,"props":7628,"children":7629},{},[7630],{"type":32,"value":7631},"User Story dérivée :",{"type":27,"tag":4174,"props":7633,"children":7635},{"className":4176,"code":7634,"language":4178,"meta":8,"style":8},"En tant que client,  \nJe veux voir l’état actuel de ma commande,  \nAfin de savoir quand la recevoir.  \n",[7636],{"type":27,"tag":4181,"props":7637,"children":7638},{"__ignoreMap":8},[7639,7647,7655],{"type":27,"tag":4185,"props":7640,"children":7641},{"class":4187,"line":4188},[7642],{"type":27,"tag":4185,"props":7643,"children":7644},{},[7645],{"type":32,"value":7646},"En tant que client,  \n",{"type":27,"tag":4185,"props":7648,"children":7649},{"class":4187,"line":475},[7650],{"type":27,"tag":4185,"props":7651,"children":7652},{},[7653],{"type":32,"value":7654},"Je veux voir l’état actuel de ma commande,  \n",{"type":27,"tag":4185,"props":7656,"children":7657},{"class":4187,"line":4205},[7658],{"type":27,"tag":4185,"props":7659,"children":7660},{},[7661],{"type":32,"value":7662},"Afin de savoir quand la recevoir.\n",{"type":27,"tag":28,"props":7664,"children":7665},{},[7666],{"type":27,"tag":74,"props":7667,"children":7668},{},[7669],{"type":32,"value":7670},"Critères d’acceptation associés :",{"type":27,"tag":4174,"props":7672,"children":7674},{"className":4176,"code":7673,"language":4178,"meta":8,"style":8},"Scénario : Visualisation de l’état de commande  \nÉtant donné un client ayant passé une commande,  \nLorsqu’il se connecte à son compte,  \nAlors il doit voir un tableau de suivi avec les étapes actuelles de la commande.  \n",[7675],{"type":27,"tag":4181,"props":7676,"children":7677},{"__ignoreMap":8},[7678,7686,7694,7702],{"type":27,"tag":4185,"props":7679,"children":7680},{"class":4187,"line":4188},[7681],{"type":27,"tag":4185,"props":7682,"children":7683},{},[7684],{"type":32,"value":7685},"Scénario : Visualisation de l’état de commande  \n",{"type":27,"tag":4185,"props":7687,"children":7688},{"class":4187,"line":475},[7689],{"type":27,"tag":4185,"props":7690,"children":7691},{},[7692],{"type":32,"value":7693},"Étant donné un client ayant passé une commande,  \n",{"type":27,"tag":4185,"props":7695,"children":7696},{"class":4187,"line":4205},[7697],{"type":27,"tag":4185,"props":7698,"children":7699},{},[7700],{"type":32,"value":7701},"Lorsqu’il se connecte à son compte,  \n",{"type":27,"tag":4185,"props":7703,"children":7704},{"class":4187,"line":4214},[7705],{"type":27,"tag":4185,"props":7706,"children":7707},{},[7708],{"type":32,"value":7709},"Alors il doit voir un tableau de suivi avec les étapes actuelles de la commande.\n",{"type":27,"tag":55,"props":7711,"children":7712},{},[],{"type":27,"tag":3853,"props":7714,"children":7716},{"id":7715},"_4-les-risques-dune-approche-inversée-user-stories-avant-requirements",[7717],{"type":27,"tag":74,"props":7718,"children":7719},{},[7720],{"type":32,"value":7721},"4. Les risques d’une approche inversée (user stories avant requirements)",{"type":27,"tag":28,"props":7723,"children":7724},{},[7725],{"type":32,"value":7726},"Partir directement des user stories produit un backlog :",{"type":27,"tag":263,"props":7728,"children":7729},{},[7730,7740,7750],{"type":27,"tag":267,"props":7731,"children":7732},{},[7733,7738],{"type":27,"tag":74,"props":7734,"children":7735},{},[7736],{"type":32,"value":7737},"Fragmenté",{"type":32,"value":7739}," : stories sans contexte global, incohérences inévitables.",{"type":27,"tag":267,"props":7741,"children":7742},{},[7743,7748],{"type":27,"tag":74,"props":7744,"children":7745},{},[7746],{"type":32,"value":7747},"Incomplet",{"type":32,"value":7749}," : sécurité, performance, conformité, les grands oubliés.",{"type":27,"tag":267,"props":7751,"children":7752},{},[7753,7758],{"type":27,"tag":74,"props":7754,"children":7755},{},[7756],{"type":32,"value":7757},"Rigide",{"type":32,"value":7759}," : mise à jour difficile quand les besoins évoluent.",{"type":27,"tag":28,"props":7761,"children":7762},{},[7763],{"type":32,"value":7764},"Le cas bancaire que j'ai cité en intro illustre exactement ça : six mois de stories sans requirements, et tous les contrôles réglementaires absents du backlog. Deux sprints de rattrapage qu'on aurait pu économiser avec une journée de formalisation amont.",{"type":27,"tag":55,"props":7766,"children":7767},{},[],{"type":27,"tag":3853,"props":7769,"children":7771},{"id":7770},"_5-synthèse",[7772],{"type":27,"tag":74,"props":7773,"children":7774},{},[7775],{"type":32,"value":7776},"5. Synthèse",{"type":27,"tag":263,"props":7778,"children":7779},{},[7780,7790],{"type":27,"tag":267,"props":7781,"children":7782},{},[7783,7788],{"type":27,"tag":74,"props":7784,"children":7785},{},[7786],{"type":32,"value":7787},"Requirements = vision globale",{"type":32,"value":7789},", alignement et compréhension métier.",{"type":27,"tag":267,"props":7791,"children":7792},{},[7793,7798],{"type":27,"tag":74,"props":7794,"children":7795},{},[7796],{"type":32,"value":7797},"User Stories = action détaillée",{"type":32,"value":7799},", prêtes à être planifiées et priorisées.",{"type":27,"tag":59,"props":7801,"children":7803},{"id":7802},"les-pièges-de-lapproche-user-stories-dabord",[7804],{"type":27,"tag":74,"props":7805,"children":7806},{},[7807],{"type":32,"value":7808},"Les pièges de l'approche \"user stories d'abord\"",{"type":27,"tag":28,"props":7810,"children":7811},{},[7812],{"type":32,"value":7813},"Beaucoup d'équipes Agile démarrent par les stories en pensant \"extraire les requirements plus tard\". Ça paraît pragmatique. C'est en réalité ce qui produit les backlogs les plus chaotiques que je vois en mission. Quatre symptômes systématiques :",{"type":27,"tag":28,"props":7815,"children":7816},{},[7817,7822],{"type":27,"tag":74,"props":7818,"children":7819},{},[7820],{"type":32,"value":7821},"1. Focus sur le \"comment\", perte du \"pourquoi\"",{"type":32,"value":7823},"\nUne story décrit une action utilisateur. Sans requirement amont, le \"pourquoi\" reste implicite, et avec lui les contraintes invisibles comme la sécurité ou la conformité.",{"type":27,"tag":28,"props":7825,"children":7826},{},[7827],{"type":32,"value":6724},{"type":27,"tag":4174,"props":7829,"children":7831},{"className":4176,"code":7830,"language":4178,"meta":8,"style":8},"En tant que client,  \nJe veux recevoir un email de confirmation après avoir passé commande.  \n",[7832],{"type":27,"tag":4181,"props":7833,"children":7834},{"__ignoreMap":8},[7835,7842],{"type":27,"tag":4185,"props":7836,"children":7837},{"class":4187,"line":4188},[7838],{"type":27,"tag":4185,"props":7839,"children":7840},{},[7841],{"type":32,"value":7646},{"type":27,"tag":4185,"props":7843,"children":7844},{"class":4187,"line":475},[7845],{"type":27,"tag":4185,"props":7846,"children":7847},{},[7848],{"type":32,"value":7849},"Je veux recevoir un email de confirmation après avoir passé commande.\n",{"type":27,"tag":28,"props":7851,"children":7852},{},[7853],{"type":32,"value":7854},"Ce qui n'apparaît nulle part : gestion du SPF\u002FDKIM, comportement en cas d'échec d'envoi, traitement RGPD du contenu de l'email. Trois oublis qui finiront en bug post-prod.",{"type":27,"tag":28,"props":7856,"children":7857},{},[7858,7863],{"type":27,"tag":74,"props":7859,"children":7860},{},[7861],{"type":32,"value":7862},"2. Documentation à durée de vie courte",{"type":32,"value":7864},"\nUne story est jetable par nature. Si elle porte seule la spec, l'information disparaît quand la story est livrée. Plus de justification, plus de traçabilité, dette organisationnelle assurée.",{"type":27,"tag":28,"props":7866,"children":7867},{},[7868,7873],{"type":27,"tag":74,"props":7869,"children":7870},{},[7871],{"type":32,"value":7872},"3. Obsolescence en cascade",{"type":32,"value":7874},"\nLes stories bougent à chaque sprint. Si un requirement implicite repose sur une story modifiée trois sprints plus tard, la cohérence se perd silencieusement.",{"type":27,"tag":28,"props":7876,"children":7877},{},[7878,7883],{"type":27,"tag":74,"props":7879,"children":7880},{},[7881],{"type":32,"value":7882},"4. Backlog fragmenté",{"type":32,"value":7884},"\nChaque story devient un bloc isolé. Les dépendances ne sont pas tracées. Le moindre changement déclenche une réécriture en cascade. Paradoxalement, on perd en agilité dans un cadre censé la favoriser.",{"type":27,"tag":3853,"props":7886,"children":7888},{"id":7887},"le-pattern-récurrent-en-mission",[7889],{"type":27,"tag":74,"props":7890,"children":7891},{},[7892],{"type":32,"value":7893},"Le pattern récurrent en mission",{"type":27,"tag":28,"props":7895,"children":7896},{},[7897],{"type":32,"value":7898},"Sur les missions où ce démarrage \"stories-first\" est en place, je vois invariablement la même trajectoire sur 4-6 sprints : départ rapide, ajouts urgents au sprint 2 pour combler les trous sécurité, explosion du backlog au sprint 3 avec redondances et contradictions, dépendances invisibles découvertes au sprint 4, stories initiales obsolètes au sprint 5, et au sprint 6 un produit incohérent avec des trous critiques sur des NFR jamais formulés (pics de trafic, conformité, scalabilité).",{"type":27,"tag":28,"props":7900,"children":7901},{},[7902,7904,7909],{"type":32,"value":7903},"C'est exactement ce que j'ai documenté chez le client bancaire cité en intro. Et c'est pour ça que la suite de cet article repose sur le principe inverse : ",{"type":27,"tag":74,"props":7905,"children":7906},{},[7907],{"type":32,"value":7908},"requirements d'abord, stories dérivées",{"type":32,"value":105},{"type":27,"tag":59,"props":7911,"children":7913},{"id":7912},"lapproche-requirements-dabord-exemple-de-progression",[7914],{"type":27,"tag":74,"props":7915,"children":7916},{},[7917],{"type":32,"value":7918},"L'approche \"requirements d'abord\" : exemple de progression",{"type":27,"tag":28,"props":7920,"children":7921},{},[7922],{"type":32,"value":7923},"Voici comment se déroule un développement quand les requirements précèdent les stories, sur un cas concret de suivi de commandes e-commerce.",{"type":27,"tag":28,"props":7925,"children":7926},{},[7927],{"type":27,"tag":74,"props":7928,"children":7929},{},[7930],{"type":32,"value":7931},"Sprint 1 - Requirement fondateur :",{"type":27,"tag":4174,"props":7933,"children":7935},{"className":4176,"code":7934,"language":4178,"meta":8,"style":8},"Le système doit permettre aux clients de suivre leurs commandes, avec un statut détaillé pour chaque étape : \"Préparation\", \"Expédition\", \"Livraison\".  \n",[7936],{"type":27,"tag":4181,"props":7937,"children":7938},{"__ignoreMap":8},[7939],{"type":27,"tag":4185,"props":7940,"children":7941},{"class":4187,"line":4188},[7942],{"type":27,"tag":4185,"props":7943,"children":7944},{},[7945],{"type":32,"value":7946},"Le système doit permettre aux clients de suivre leurs commandes, avec un statut détaillé pour chaque étape : \"Préparation\", \"Expédition\", \"Livraison\".\n",{"type":27,"tag":28,"props":7948,"children":7949},{},[7950],{"type":32,"value":7951},"Stories dérivées : visualisation client + interface admin de mise à jour. Les dépendances (UI dépend de l'API) sont identifiées dès le début.",{"type":27,"tag":28,"props":7953,"children":7954},{},[7955],{"type":27,"tag":74,"props":7956,"children":7957},{},[7958],{"type":32,"value":7959},"Sprint 2 - Ajout d'un NFR :",{"type":27,"tag":4174,"props":7961,"children":7963},{"className":4176,"code":7962,"language":4178,"meta":8,"style":8},"Le système doit mettre à jour le statut des commandes en moins de 5 secondes après l’action de l’administrateur.  \n",[7964],{"type":27,"tag":4181,"props":7965,"children":7966},{"__ignoreMap":8},[7967],{"type":27,"tag":4185,"props":7968,"children":7969},{"class":4187,"line":4188},[7970],{"type":27,"tag":4185,"props":7971,"children":7972},{},[7973],{"type":32,"value":7974},"Le système doit mettre à jour le statut des commandes en moins de 5 secondes après l’action de l’administrateur.\n",{"type":27,"tag":28,"props":7976,"children":7977},{},[7978],{"type":32,"value":7979},"Le NFR oriente les choix techniques (cache, optimisation requêtes) sans casser les stories existantes.",{"type":27,"tag":28,"props":7981,"children":7982},{},[7983],{"type":27,"tag":74,"props":7984,"children":7985},{},[7986],{"type":32,"value":7987},"Sprint 3 - Évolution métier :",{"type":27,"tag":4174,"props":7989,"children":7991},{"className":4176,"code":7990,"language":4178,"meta":8,"style":8},"Le système doit envoyer une notification par email au client pour chaque changement de statut.  \n",[7992],{"type":27,"tag":4181,"props":7993,"children":7994},{"__ignoreMap":8},[7995],{"type":27,"tag":4185,"props":7996,"children":7997},{"class":4187,"line":4188},[7998],{"type":27,"tag":4185,"props":7999,"children":8000},{},[8001],{"type":32,"value":8002},"Le système doit envoyer une notification par email au client pour chaque changement de statut.\n",{"type":27,"tag":28,"props":8004,"children":8005},{},[8006],{"type":32,"value":8007},"Nouveau requirement → nouvelles stories, sans toucher au reste du backlog.",{"type":27,"tag":28,"props":8009,"children":8010},{},[8011],{"type":27,"tag":74,"props":8012,"children":8013},{},[8014],{"type":32,"value":8015},"Sprint 4 - Renforcement perf :",{"type":27,"tag":4174,"props":8017,"children":8019},{"className":4176,"code":8018,"language":4178,"meta":8,"style":8},"Le système doit être capable de traiter 10 000 commandes simultanées avec un temps de réponse inférieur à 3 secondes.  \n",[8020],{"type":27,"tag":4181,"props":8021,"children":8022},{"__ignoreMap":8},[8023],{"type":27,"tag":4185,"props":8024,"children":8025},{"class":4187,"line":4188},[8026],{"type":27,"tag":4185,"props":8027,"children":8028},{},[8029],{"type":32,"value":8030},"Le système doit être capable de traiter 10 000 commandes simultanées avec un temps de réponse inférieur à 3 secondes.\n",{"type":27,"tag":28,"props":8032,"children":8033},{},[8034],{"type":32,"value":8035},"Stories techniques (optimisation BDD) et tests de charge ajoutés sans rework des stories métier.",{"type":27,"tag":28,"props":8037,"children":8038},{},[8039],{"type":27,"tag":74,"props":8040,"children":8041},{},[8042],{"type":32,"value":8043},"Sprint 5 - Sécurité formalisée :",{"type":27,"tag":4174,"props":8045,"children":8047},{"className":4176,"code":8046,"language":4178,"meta":8,"style":8},"Les notifications par email doivent être envoyées uniquement aux utilisateurs authentifiés, avec un lien unique valable 24 heures.  \n",[8048],{"type":27,"tag":4181,"props":8049,"children":8050},{"__ignoreMap":8},[8051],{"type":27,"tag":4185,"props":8052,"children":8053},{"class":4187,"line":4188},[8054],{"type":27,"tag":4185,"props":8055,"children":8056},{},[8057],{"type":32,"value":8058},"Les notifications par email doivent être envoyées uniquement aux utilisateurs authentifiés, avec un lien unique valable 24 heures.\n",{"type":27,"tag":28,"props":8060,"children":8061},{},[8062],{"type":32,"value":8063},"Tokens uniques, expiration, conformité RGPD validées par tests automatisés en CI.",{"type":27,"tag":28,"props":8065,"children":8066},{},[8067],{"type":27,"tag":74,"props":8068,"children":8069},{},[8070],{"type":32,"value":8071},"Sprint 6 - Personnalisation :",{"type":27,"tag":4174,"props":8073,"children":8075},{"className":4176,"code":8074,"language":4178,"meta":8,"style":8},"Le système doit permettre aux clients de choisir les notifications qu’ils souhaitent recevoir.  \n",[8076],{"type":27,"tag":4181,"props":8077,"children":8078},{"__ignoreMap":8},[8079],{"type":27,"tag":4185,"props":8080,"children":8081},{"class":4187,"line":4188},[8082],{"type":27,"tag":4185,"props":8083,"children":8084},{},[8085],{"type":32,"value":8086},"Le système doit permettre aux clients de choisir les notifications qu’ils souhaitent recevoir.\n",{"type":27,"tag":28,"props":8088,"children":8089},{},[8090],{"type":32,"value":8091},"Le backlog reste lisible, les stories obsolètes sont archivées proprement.",{"type":27,"tag":28,"props":8093,"children":8094},{},[8095,8100],{"type":27,"tag":74,"props":8096,"children":8097},{},[8098],{"type":32,"value":8099},"Différence clé avec l'approche inverse",{"type":32,"value":8101}," : chaque évolution s'inscrit dans la continuité du requirement parent. Pas de rework massif, pas de trous structurels, traçabilité conservée du début à la fin.",{"type":27,"tag":59,"props":8103,"children":8105},{"id":8104},"les-critères-dacceptation-leur-rôle-et-leur-importance",[8106],{"type":27,"tag":74,"props":8107,"children":8108},{},[8109],{"type":32,"value":8110},"Les critères d’acceptation, leur rôle et leur importance",{"type":27,"tag":28,"props":8112,"children":8113},{},[8114],{"type":32,"value":8115},"Sans critères d'acceptation clairs, la phrase \"mais ce n'était pas prévu comme ça\" devient le mantra des revues de sprint. Ce sont eux qui transforment une intention floue en condition testable.",{"type":27,"tag":55,"props":8117,"children":8118},{},[],{"type":27,"tag":3853,"props":8120,"children":8122},{"id":8121},"_1-quest-ce-quun-critère-dacceptation",[8123],{"type":27,"tag":74,"props":8124,"children":8125},{},[8126],{"type":32,"value":8127},"1. Qu’est-ce qu’un critère d’acceptation ?",{"type":27,"tag":28,"props":8129,"children":8130},{},[8131],{"type":32,"value":8132},"Une règle testable qui décrit le comportement attendu d'une fonctionnalité pour qu'elle soit acceptée.",{"type":27,"tag":28,"props":8134,"children":8135},{},[8136],{"type":27,"tag":74,"props":8137,"children":8138},{},[8139],{"type":32,"value":8140},"Exemple lié à une user story :",{"type":27,"tag":4174,"props":8142,"children":8144},{"className":4176,"code":8143,"language":4178,"meta":8,"style":8},"En tant que client,  \nJe veux recevoir un email de confirmation après avoir passé une commande,  \nAfin de m’assurer que ma commande a bien été prise en compte.  \n",[8145],{"type":27,"tag":4181,"props":8146,"children":8147},{"__ignoreMap":8},[8148,8155,8163],{"type":27,"tag":4185,"props":8149,"children":8150},{"class":4187,"line":4188},[8151],{"type":27,"tag":4185,"props":8152,"children":8153},{},[8154],{"type":32,"value":7646},{"type":27,"tag":4185,"props":8156,"children":8157},{"class":4187,"line":475},[8158],{"type":27,"tag":4185,"props":8159,"children":8160},{},[8161],{"type":32,"value":8162},"Je veux recevoir un email de confirmation après avoir passé une commande,  \n",{"type":27,"tag":4185,"props":8164,"children":8165},{"class":4187,"line":4205},[8166],{"type":27,"tag":4185,"props":8167,"children":8168},{},[8169],{"type":32,"value":8170},"Afin de m’assurer que ma commande a bien été prise en compte.\n",{"type":27,"tag":28,"props":8172,"children":8173},{},[8174],{"type":27,"tag":74,"props":8175,"children":8176},{},[8177],{"type":32,"value":8178},"Critères d’acceptation :",{"type":27,"tag":4174,"props":8180,"children":8182},{"className":4176,"code":8181,"language":4178,"meta":8,"style":8},"Scénario : Confirmation de commande  \nÉtant donné un client ayant passé une commande,  \nLorsqu’il termine le processus de paiement,  \nAlors il reçoit un email contenant les détails de sa commande.  \n\nScénario : Absence d’email pour une commande non validée  \nÉtant donné un client ayant ajouté des articles à son panier,  \nLorsqu’il abandonne son paiement,  \nAlors aucun email de confirmation n’est envoyé.  \n",[8183],{"type":27,"tag":4181,"props":8184,"children":8185},{"__ignoreMap":8},[8186,8194,8201,8209,8217,8224,8232,8240,8248],{"type":27,"tag":4185,"props":8187,"children":8188},{"class":4187,"line":4188},[8189],{"type":27,"tag":4185,"props":8190,"children":8191},{},[8192],{"type":32,"value":8193},"Scénario : Confirmation de commande  \n",{"type":27,"tag":4185,"props":8195,"children":8196},{"class":4187,"line":475},[8197],{"type":27,"tag":4185,"props":8198,"children":8199},{},[8200],{"type":32,"value":7693},{"type":27,"tag":4185,"props":8202,"children":8203},{"class":4187,"line":4205},[8204],{"type":27,"tag":4185,"props":8205,"children":8206},{},[8207],{"type":32,"value":8208},"Lorsqu’il termine le processus de paiement,  \n",{"type":27,"tag":4185,"props":8210,"children":8211},{"class":4187,"line":4214},[8212],{"type":27,"tag":4185,"props":8213,"children":8214},{},[8215],{"type":32,"value":8216},"Alors il reçoit un email contenant les détails de sa commande.  \n",{"type":27,"tag":4185,"props":8218,"children":8219},{"class":4187,"line":4223},[8220],{"type":27,"tag":4185,"props":8221,"children":8222},{"emptyLinePlaceholder":13},[8223],{"type":32,"value":5530},{"type":27,"tag":4185,"props":8225,"children":8226},{"class":4187,"line":4916},[8227],{"type":27,"tag":4185,"props":8228,"children":8229},{},[8230],{"type":32,"value":8231},"Scénario : Absence d’email pour une commande non validée  \n",{"type":27,"tag":4185,"props":8233,"children":8234},{"class":4187,"line":3068},[8235],{"type":27,"tag":4185,"props":8236,"children":8237},{},[8238],{"type":32,"value":8239},"Étant donné un client ayant ajouté des articles à son panier,  \n",{"type":27,"tag":4185,"props":8241,"children":8242},{"class":4187,"line":5594},[8243],{"type":27,"tag":4185,"props":8244,"children":8245},{},[8246],{"type":32,"value":8247},"Lorsqu’il abandonne son paiement,  \n",{"type":27,"tag":4185,"props":8249,"children":8250},{"class":4187,"line":5603},[8251],{"type":27,"tag":4185,"props":8252,"children":8253},{},[8254],{"type":32,"value":8255},"Alors aucun email de confirmation n’est envoyé.\n",{"type":27,"tag":55,"props":8257,"children":8258},{},[],{"type":27,"tag":3853,"props":8260,"children":8262},{"id":8261},"_2-trois-rôles-structurants",[8263],{"type":27,"tag":74,"props":8264,"children":8265},{},[8266],{"type":32,"value":8267},"2. Trois rôles structurants",{"type":27,"tag":28,"props":8269,"children":8270},{},[8271,8276],{"type":27,"tag":74,"props":8272,"children":8273},{},[8274],{"type":32,"value":8275},"a) Clarifier les attentes",{"type":32,"value":8277}," : transformer une idée générale en condition précise, réduire les malentendus entre PO, dev et QA.",{"type":27,"tag":28,"props":8279,"children":8280},{},[8281,8286],{"type":27,"tag":74,"props":8282,"children":8283},{},[8284],{"type":32,"value":8285},"b) Guider les tests",{"type":32,"value":8287}," : QA et automatisation s'appuient directement dessus. Un critère = un test.",{"type":27,"tag":28,"props":8289,"children":8290},{},[8291,8296],{"type":27,"tag":74,"props":8292,"children":8293},{},[8294],{"type":32,"value":8295},"c) Définir le \"Done\"",{"type":32,"value":8297}," : sans critère, le \"fini\" devient subjectif. Avec critère, le statut est binaire.",{"type":27,"tag":55,"props":8299,"children":8300},{},[],{"type":27,"tag":3853,"props":8302,"children":8304},{"id":8303},"_3-critères-dacceptation-pour-les-requirements-notamment-nfr",[8305],{"type":27,"tag":74,"props":8306,"children":8307},{},[8308],{"type":32,"value":8309},"3. Critères d’acceptation pour les requirements (notamment NFR)",{"type":27,"tag":28,"props":8311,"children":8312},{},[8313],{"type":32,"value":8314},"Les critères d'acceptation ne se limitent pas aux user stories. Ils sont indispensables pour valider les NFR, qui sans eux restent des intentions invérifiables.",{"type":27,"tag":28,"props":8316,"children":8317},{},[8318],{"type":27,"tag":74,"props":8319,"children":8320},{},[8321],{"type":32,"value":8322},"Requirement (NFR) :",{"type":27,"tag":4174,"props":8324,"children":8326},{"className":4176,"code":8325,"language":4178,"meta":8,"style":8},"Le système doit traiter 10 000 requêtes simultanées avec un temps de réponse inférieur à 3 secondes.  \n",[8327],{"type":27,"tag":4181,"props":8328,"children":8329},{"__ignoreMap":8},[8330],{"type":27,"tag":4185,"props":8331,"children":8332},{"class":4187,"line":4188},[8333],{"type":27,"tag":4185,"props":8334,"children":8335},{},[8336],{"type":32,"value":8337},"Le système doit traiter 10 000 requêtes simultanées avec un temps de réponse inférieur à 3 secondes.\n",{"type":27,"tag":28,"props":8339,"children":8340},{},[8341],{"type":27,"tag":74,"props":8342,"children":8343},{},[8344],{"type":32,"value":7670},{"type":27,"tag":4174,"props":8346,"children":8348},{"className":4176,"code":8347,"language":4178,"meta":8,"style":8},"Scénario : Charge normale  \nÉtant donné 1 000 utilisateurs connectés,  \nLorsqu’ils effectuent des requêtes en parallèle,  \nAlors le temps de réponse moyen doit être inférieur à 3 secondes.  \n\nScénario : Charge maximale  \nÉtant donné 10 000 utilisateurs connectés simultanément,  \nLorsqu’ils effectuent des requêtes en parallèle,  \nAlors le système doit maintenir un temps de réponse inférieur à 3 secondes.  \n\nScénario : Gestion des pics de charge  \nÉtant donné un pic soudain à 15 000 utilisateurs connectés,  \nLorsqu’ils effectuent des requêtes,  \nAlors le système doit répartir la charge et garantir la continuité de service.  \n",[8349],{"type":27,"tag":4181,"props":8350,"children":8351},{"__ignoreMap":8},[8352,8360,8368,8376,8384,8391,8399,8407,8414,8422,8429,8437,8445,8453],{"type":27,"tag":4185,"props":8353,"children":8354},{"class":4187,"line":4188},[8355],{"type":27,"tag":4185,"props":8356,"children":8357},{},[8358],{"type":32,"value":8359},"Scénario : Charge normale  \n",{"type":27,"tag":4185,"props":8361,"children":8362},{"class":4187,"line":475},[8363],{"type":27,"tag":4185,"props":8364,"children":8365},{},[8366],{"type":32,"value":8367},"Étant donné 1 000 utilisateurs connectés,  \n",{"type":27,"tag":4185,"props":8369,"children":8370},{"class":4187,"line":4205},[8371],{"type":27,"tag":4185,"props":8372,"children":8373},{},[8374],{"type":32,"value":8375},"Lorsqu’ils effectuent des requêtes en parallèle,  \n",{"type":27,"tag":4185,"props":8377,"children":8378},{"class":4187,"line":4214},[8379],{"type":27,"tag":4185,"props":8380,"children":8381},{},[8382],{"type":32,"value":8383},"Alors le temps de réponse moyen doit être inférieur à 3 secondes.  \n",{"type":27,"tag":4185,"props":8385,"children":8386},{"class":4187,"line":4223},[8387],{"type":27,"tag":4185,"props":8388,"children":8389},{"emptyLinePlaceholder":13},[8390],{"type":32,"value":5530},{"type":27,"tag":4185,"props":8392,"children":8393},{"class":4187,"line":4916},[8394],{"type":27,"tag":4185,"props":8395,"children":8396},{},[8397],{"type":32,"value":8398},"Scénario : Charge maximale  \n",{"type":27,"tag":4185,"props":8400,"children":8401},{"class":4187,"line":3068},[8402],{"type":27,"tag":4185,"props":8403,"children":8404},{},[8405],{"type":32,"value":8406},"Étant donné 10 000 utilisateurs connectés simultanément,  \n",{"type":27,"tag":4185,"props":8408,"children":8409},{"class":4187,"line":5594},[8410],{"type":27,"tag":4185,"props":8411,"children":8412},{},[8413],{"type":32,"value":8375},{"type":27,"tag":4185,"props":8415,"children":8416},{"class":4187,"line":5603},[8417],{"type":27,"tag":4185,"props":8418,"children":8419},{},[8420],{"type":32,"value":8421},"Alors le système doit maintenir un temps de réponse inférieur à 3 secondes.  \n",{"type":27,"tag":4185,"props":8423,"children":8424},{"class":4187,"line":5611},[8425],{"type":27,"tag":4185,"props":8426,"children":8427},{"emptyLinePlaceholder":13},[8428],{"type":32,"value":5530},{"type":27,"tag":4185,"props":8430,"children":8431},{"class":4187,"line":5619},[8432],{"type":27,"tag":4185,"props":8433,"children":8434},{},[8435],{"type":32,"value":8436},"Scénario : Gestion des pics de charge  \n",{"type":27,"tag":4185,"props":8438,"children":8439},{"class":4187,"line":2696},[8440],{"type":27,"tag":4185,"props":8441,"children":8442},{},[8443],{"type":32,"value":8444},"Étant donné un pic soudain à 15 000 utilisateurs connectés,  \n",{"type":27,"tag":4185,"props":8446,"children":8447},{"class":4187,"line":5680},[8448],{"type":27,"tag":4185,"props":8449,"children":8450},{},[8451],{"type":32,"value":8452},"Lorsqu’ils effectuent des requêtes,  \n",{"type":27,"tag":4185,"props":8454,"children":8455},{"class":4187,"line":5689},[8456],{"type":27,"tag":4185,"props":8457,"children":8458},{},[8459],{"type":32,"value":8460},"Alors le système doit répartir la charge et garantir la continuité de service.\n",{"type":27,"tag":55,"props":8462,"children":8463},{},[],{"type":27,"tag":3853,"props":8465,"children":8467},{"id":8466},"_4-quatre-règles-pour-écrire-de-bons-critères",[8468],{"type":27,"tag":74,"props":8469,"children":8470},{},[8471],{"type":32,"value":8472},"4. Quatre règles pour écrire de bons critères",{"type":27,"tag":263,"props":8474,"children":8475},{},[8476,8486,8496,8506],{"type":27,"tag":267,"props":8477,"children":8478},{},[8479,8484],{"type":27,"tag":74,"props":8480,"children":8481},{},[8482],{"type":32,"value":8483},"Précis et testable",{"type":32,"value":8485}," : \"interface conviviale\" est inutile. \"Chargement \u003C 2s sur réseau 4G\" est exploitable.",{"type":27,"tag":267,"props":8487,"children":8488},{},[8489,8494],{"type":27,"tag":74,"props":8490,"children":8491},{},[8492],{"type":32,"value":8493},"Format Given\u002FWhen\u002FThen",{"type":32,"value":8495}," ou langage naturel accessible à tous.",{"type":27,"tag":267,"props":8497,"children":8498},{},[8499,8504],{"type":27,"tag":74,"props":8500,"children":8501},{},[8502],{"type":32,"value":8503},"Un cas par critère",{"type":32,"value":8505}," : pas de critères-fourre-tout qui mélangent plusieurs conditions.",{"type":27,"tag":267,"props":8507,"children":8508},{},[8509,8514],{"type":27,"tag":74,"props":8510,"children":8511},{},[8512],{"type":32,"value":8513},"Co-rédigés",{"type":32,"value":8515}," : PO, dev et QA dans la même conversation.",{"type":27,"tag":55,"props":8517,"children":8518},{},[],{"type":27,"tag":3853,"props":8520,"children":8522},{"id":8521},"_5-pièges-à-éviter",[8523],{"type":27,"tag":74,"props":8524,"children":8525},{},[8526],{"type":32,"value":8527},"5. Pièges à éviter",{"type":27,"tag":263,"props":8529,"children":8530},{},[8531,8541,8551],{"type":27,"tag":267,"props":8532,"children":8533},{},[8534,8539],{"type":27,"tag":74,"props":8535,"children":8536},{},[8537],{"type":32,"value":8538},"Critères vagues",{"type":32,"value":8540}," (\"doit fonctionner correctement\") : aucune valeur.",{"type":27,"tag":267,"props":8542,"children":8543},{},[8544,8549],{"type":27,"tag":74,"props":8545,"children":8546},{},[8547],{"type":32,"value":8548},"Trop nombreux",{"type":32,"value":8550}," : si vous avez 15 critères sur une story, c'est qu'il y en a deux ou trois cachées dedans. Découpez.",{"type":27,"tag":267,"props":8552,"children":8553},{},[8554,8559],{"type":27,"tag":74,"props":8555,"children":8556},{},[8557],{"type":32,"value":8558},"Manque de collaboration",{"type":32,"value":8560}," : critères écrits dans un coin par le PO seul = critères qui ratent leur cible.",{"type":27,"tag":59,"props":8562,"children":8564},{"id":8563},"stratégies-pour-écrire-et-référencer-efficacement-requirements-et-user-stories",[8565],{"type":27,"tag":74,"props":8566,"children":8567},{},[8568],{"type":32,"value":8569},"Stratégies pour écrire et référencer efficacement requirements et user stories",{"type":27,"tag":28,"props":8571,"children":8572},{},[8573],{"type":32,"value":8574},"Une fois les artefacts définis, il faut les structurer pour éviter les doublons, tracer les dépendances et faciliter les évolutions. Voici les pratiques que j'applique systématiquement.",{"type":27,"tag":55,"props":8576,"children":8577},{},[],{"type":27,"tag":3853,"props":8579,"children":8581},{"id":8580},"_1-structurer-les-requirements-par-catégories",[8582],{"type":27,"tag":74,"props":8583,"children":8584},{},[8585],{"type":32,"value":8586},"1. Structurer les requirements par catégories",{"type":27,"tag":28,"props":8588,"children":8589},{},[8590],{"type":32,"value":8591},"Quatre catégories dès le départ du projet : fonctionnels, non fonctionnels, techniques, règlementaires. Chacune adresse un type de risque différent.",{"type":27,"tag":1580,"props":8593,"children":8594},{},[8595,8625],{"type":27,"tag":1584,"props":8596,"children":8597},{},[8598],{"type":27,"tag":1588,"props":8599,"children":8600},{},[8601,8609,8617],{"type":27,"tag":1592,"props":8602,"children":8603},{},[8604],{"type":27,"tag":74,"props":8605,"children":8606},{},[8607],{"type":32,"value":8608},"ID",{"type":27,"tag":1592,"props":8610,"children":8611},{},[8612],{"type":27,"tag":74,"props":8613,"children":8614},{},[8615],{"type":32,"value":8616},"Type",{"type":27,"tag":1592,"props":8618,"children":8619},{},[8620],{"type":27,"tag":74,"props":8621,"children":8622},{},[8623],{"type":32,"value":8624},"Requirement",{"type":27,"tag":1608,"props":8626,"children":8627},{},[8628,8646,8664,8682],{"type":27,"tag":1588,"props":8629,"children":8630},{},[8631,8636,8641],{"type":27,"tag":1615,"props":8632,"children":8633},{},[8634],{"type":32,"value":8635},"RQ-F-001",{"type":27,"tag":1615,"props":8637,"children":8638},{},[8639],{"type":32,"value":8640},"Fonctionnel",{"type":27,"tag":1615,"props":8642,"children":8643},{},[8644],{"type":32,"value":8645},"Le système doit permettre aux clients de créer un compte.",{"type":27,"tag":1588,"props":8647,"children":8648},{},[8649,8654,8659],{"type":27,"tag":1615,"props":8650,"children":8651},{},[8652],{"type":32,"value":8653},"RQ-NFR-002",{"type":27,"tag":1615,"props":8655,"children":8656},{},[8657],{"type":32,"value":8658},"Non fonctionnel",{"type":27,"tag":1615,"props":8660,"children":8661},{},[8662],{"type":32,"value":8663},"Le temps de réponse doit être inférieur à 2 secondes.",{"type":27,"tag":1588,"props":8665,"children":8666},{},[8667,8672,8677],{"type":27,"tag":1615,"props":8668,"children":8669},{},[8670],{"type":32,"value":8671},"RQ-TECH-003",{"type":27,"tag":1615,"props":8673,"children":8674},{},[8675],{"type":32,"value":8676},"Technique",{"type":27,"tag":1615,"props":8678,"children":8679},{},[8680],{"type":32,"value":8681},"Le système doit intégrer une authentification OAuth 2.0.",{"type":27,"tag":1588,"props":8683,"children":8684},{},[8685,8690,8695],{"type":27,"tag":1615,"props":8686,"children":8687},{},[8688],{"type":32,"value":8689},"RQ-REG-004",{"type":27,"tag":1615,"props":8691,"children":8692},{},[8693],{"type":32,"value":8694},"Réglementaire",{"type":27,"tag":1615,"props":8696,"children":8697},{},[8698],{"type":32,"value":8699},"Les données utilisateur doivent être conformes au RGPD.",{"type":27,"tag":28,"props":8701,"children":8702},{},[8703],{"type":32,"value":8704},"Chaque requirement se décline ensuite en user stories actionnables, avec un lien hiérarchique explicite.",{"type":27,"tag":55,"props":8706,"children":8707},{},[],{"type":27,"tag":3853,"props":8709,"children":8711},{"id":8710},"_2-référencement-par-identifiants-uniques",[8712],{"type":27,"tag":74,"props":8713,"children":8714},{},[8715],{"type":32,"value":8716},"2. Référencement par identifiants uniques",{"type":27,"tag":28,"props":8718,"children":8719},{},[8720],{"type":32,"value":8721},"Trois bénéfices : traçabilité (story → requirement d'origine), priorisation (regrouper par besoin), collaboration (vocabulaire commun entre équipes).",{"type":27,"tag":28,"props":8723,"children":8724},{},[8725],{"type":32,"value":574},{"type":27,"tag":263,"props":8727,"children":8728},{},[8729,8753],{"type":27,"tag":267,"props":8730,"children":8731},{},[8732,8736,8738,8744,8746,8751],{"type":27,"tag":74,"props":8733,"children":8734},{},[8735],{"type":32,"value":8624},{"type":32,"value":8737}," : ",{"type":27,"tag":4181,"props":8739,"children":8741},{"className":8740},[],[8742],{"type":32,"value":8743},"RQ-[Type]-[Numéro]",{"type":32,"value":8745}," (ex : ",{"type":27,"tag":4181,"props":8747,"children":8749},{"className":8748},[],[8750],{"type":32,"value":8635},{"type":32,"value":8752},").",{"type":27,"tag":267,"props":8754,"children":8755},{},[8756,8761,8762,8768,8769,8775],{"type":27,"tag":74,"props":8757,"children":8758},{},[8759],{"type":32,"value":8760},"User Story",{"type":32,"value":8737},{"type":27,"tag":4181,"props":8763,"children":8765},{"className":8764},[],[8766],{"type":32,"value":8767},"US-[Numéro requirement]-[Sous-numéro]",{"type":32,"value":8745},{"type":27,"tag":4181,"props":8770,"children":8772},{"className":8771},[],[8773],{"type":32,"value":8774},"US-001-1",{"type":32,"value":8752},{"type":27,"tag":1580,"props":8777,"children":8778},{},[8779,8808],{"type":27,"tag":1584,"props":8780,"children":8781},{},[8782],{"type":27,"tag":1588,"props":8783,"children":8784},{},[8785,8793,8800],{"type":27,"tag":1592,"props":8786,"children":8787},{},[8788],{"type":27,"tag":74,"props":8789,"children":8790},{},[8791],{"type":32,"value":8792},"ID Requirement",{"type":27,"tag":1592,"props":8794,"children":8795},{},[8796],{"type":27,"tag":74,"props":8797,"children":8798},{},[8799],{"type":32,"value":8624},{"type":27,"tag":1592,"props":8801,"children":8802},{},[8803],{"type":27,"tag":74,"props":8804,"children":8805},{},[8806],{"type":32,"value":8807},"User Stories associées",{"type":27,"tag":1608,"props":8809,"children":8810},{},[8811,8828],{"type":27,"tag":1588,"props":8812,"children":8813},{},[8814,8818,8823],{"type":27,"tag":1615,"props":8815,"children":8816},{},[8817],{"type":32,"value":8635},{"type":27,"tag":1615,"props":8819,"children":8820},{},[8821],{"type":32,"value":8822},"Le système doit permettre aux clients de suivre leurs commandes.",{"type":27,"tag":1615,"props":8824,"children":8825},{},[8826],{"type":32,"value":8827},"US-001-1, US-001-2",{"type":27,"tag":1588,"props":8829,"children":8830},{},[8831,8835,8839],{"type":27,"tag":1615,"props":8832,"children":8833},{},[8834],{"type":32,"value":8653},{"type":27,"tag":1615,"props":8836,"children":8837},{},[8838],{"type":32,"value":8663},{"type":27,"tag":1615,"props":8840,"children":8841},{},[8842],{"type":32,"value":8843},"US-002-1, US-002-2 (tests de charge)",{"type":27,"tag":55,"props":8845,"children":8846},{},[],{"type":27,"tag":3853,"props":8848,"children":8850},{"id":8849},"_3-outils-selon-le-contexte",[8851],{"type":27,"tag":74,"props":8852,"children":8853},{},[8854],{"type":32,"value":8855},"3. Outils selon le contexte",{"type":27,"tag":28,"props":8857,"children":8858},{},[8859],{"type":32,"value":8860},"Trois familles d'outils, à panacher selon les besoins :",{"type":27,"tag":263,"props":8862,"children":8863},{},[8864,8874,8884],{"type":27,"tag":267,"props":8865,"children":8866},{},[8867,8872],{"type":27,"tag":74,"props":8868,"children":8869},{},[8870],{"type":32,"value":8871},"Gestion de backlog Agile",{"type":32,"value":8873}," : Jira (le plus répandu, écosystème immense), Azure DevOps (intégration native CI\u002FCD), ALM Octane (méthodologies hybrides Agile\u002FWaterfall, projets complexes), Quality Center (secteurs réglementés, traçabilité poussée).",{"type":27,"tag":267,"props":8875,"children":8876},{},[8877,8882],{"type":27,"tag":74,"props":8878,"children":8879},{},[8880],{"type":32,"value":8881},"Traçabilité des tests",{"type":32,"value":8883}," : TestRail pour structurer les cas, Zephyr quand on est déjà sur Jira.",{"type":27,"tag":267,"props":8885,"children":8886},{},[8887,8892],{"type":27,"tag":74,"props":8888,"children":8889},{},[8890],{"type":32,"value":8891},"Documentation centralisée",{"type":32,"value":8893}," : Confluence (couplé à Jira), Notion (plus flexible, écosystèmes Notion-first).",{"type":27,"tag":28,"props":8895,"children":8896},{},[8897,8902],{"type":27,"tag":74,"props":8898,"children":8899},{},[8900],{"type":32,"value":8901},"Combo qui marche bien en environnement réglementé",{"type":32,"value":8903}," : ALM Octane pour les requirements, TestRail pour les tests, Confluence pour la doc transverse. Traçabilité bout-en-bout, du besoin métier au test automatisé.",{"type":27,"tag":55,"props":8905,"children":8906},{},[],{"type":27,"tag":3853,"props":8908,"children":8910},{"id":8909},"_4-gérer-les-dépendances",[8911],{"type":27,"tag":74,"props":8912,"children":8913},{},[8914],{"type":32,"value":8915},"4. Gérer les dépendances",{"type":27,"tag":263,"props":8917,"children":8918},{},[8919,8929,8939],{"type":27,"tag":267,"props":8920,"children":8921},{},[8922,8927],{"type":27,"tag":74,"props":8923,"children":8924},{},[8925],{"type":32,"value":8926},"Identifier en amont",{"type":32,"value":8928}," : repérer les stories bloquantes avant le sprint planning, pas pendant.",{"type":27,"tag":267,"props":8930,"children":8931},{},[8932,8937],{"type":27,"tag":74,"props":8933,"children":8934},{},[8935],{"type":32,"value":8936},"Prioriser les bloquantes",{"type":32,"value":8938}," : elles partent en premier, point.",{"type":27,"tag":267,"props":8940,"children":8941},{},[8942,8947],{"type":27,"tag":74,"props":8943,"children":8944},{},[8945],{"type":32,"value":8946},"Visualiser",{"type":32,"value":8948}," : un simple arbre suffit dans la plupart des cas.",{"type":27,"tag":28,"props":8950,"children":8951},{},[8952],{"type":32,"value":6724},{"type":27,"tag":263,"props":8954,"children":8955},{},[8956],{"type":27,"tag":267,"props":8957,"children":8958},{},[8959,8961],{"type":32,"value":8960},"RQ-F-001 (Suivi des commandes)\n",{"type":27,"tag":263,"props":8962,"children":8963},{},[8964,8969],{"type":27,"tag":267,"props":8965,"children":8966},{},[8967],{"type":32,"value":8968},"US-001-1 (Récapitulatif des commandes)",{"type":27,"tag":267,"props":8970,"children":8971},{},[8972,8974],{"type":32,"value":8973},"US-001-2 (Statut d'une commande)\n",{"type":27,"tag":263,"props":8975,"children":8976},{},[8977],{"type":27,"tag":267,"props":8978,"children":8979},{},[8980],{"type":32,"value":8981},"Bloquée par : US-001-3 (Mise à jour du statut par l'admin).",{"type":27,"tag":55,"props":8983,"children":8984},{},[],{"type":27,"tag":3853,"props":8986,"children":8988},{"id":8987},"_5-bonnes-pratiques-résiduelles",[8989],{"type":27,"tag":74,"props":8990,"children":8991},{},[8992],{"type":32,"value":8993},"5. Bonnes pratiques résiduelles",{"type":27,"tag":263,"props":8995,"children":8996},{},[8997,9007,9017],{"type":27,"tag":267,"props":8998,"children":8999},{},[9000,9005],{"type":27,"tag":74,"props":9001,"children":9002},{},[9003],{"type":32,"value":9004},"Revoir les requirements régulièrement",{"type":32,"value":9006}," : ils bougent avec le projet, planifier des revues.",{"type":27,"tag":267,"props":9008,"children":9009},{},[9010,9015],{"type":27,"tag":74,"props":9011,"children":9012},{},[9013],{"type":32,"value":9014},"Pas de granularité excessive",{"type":32,"value":9016}," : regrouper les besoins similaires, ne pas atomiser le backlog.",{"type":27,"tag":267,"props":9018,"children":9019},{},[9020,9028],{"type":27,"tag":74,"props":9021,"children":9022},{},[9023],{"type":27,"tag":198,"props":9024,"children":9025},{"href":200},[9026],{"type":32,"value":9027},"Backlog propre",{"type":32,"value":9029}," : archiver les stories obsolètes, garder la traçabilité des versions.",{"type":27,"tag":59,"props":9031,"children":9033},{"id":9032},"les-erreurs-courantes-et-comment-les-éviter",[9034],{"type":27,"tag":74,"props":9035,"children":9036},{},[9037],{"type":32,"value":9038},"Les erreurs courantes et comment les éviter",{"type":27,"tag":28,"props":9040,"children":9041},{},[9042],{"type":32,"value":9043},"Huit pièges que je vois revenir presque à chaque audit. Ce ne sont pas des erreurs de novices : elles touchent aussi des équipes expérimentées qui ont perdu le réflexe.",{"type":27,"tag":55,"props":9045,"children":9046},{},[],{"type":27,"tag":3853,"props":9048,"children":9050},{"id":9049},"_1-stories-sans-requirements-amont",[9051],{"type":27,"tag":74,"props":9052,"children":9053},{},[9054],{"type":32,"value":9055},"1. Stories sans requirements amont",{"type":27,"tag":28,"props":9057,"children":9058},{},[9059],{"type":32,"value":9060},"Démarrer directement par les stories. Conséquence : backlog désorganisé, trous critiques sur perf et sécurité, priorisation aléatoire.",{"type":27,"tag":28,"props":9062,"children":9063},{},[9064,9069],{"type":27,"tag":74,"props":9065,"children":9066},{},[9067],{"type":32,"value":9068},"Antidote",{"type":32,"value":9070}," : documenter les requirements fonctionnels et non fonctionnels dès le sprint 0. Lier chaque story à un requirement parent.",{"type":27,"tag":55,"props":9072,"children":9073},{},[],{"type":27,"tag":3853,"props":9075,"children":9077},{"id":9076},"_2-stories-trop-vagues-ou-trop-détaillées",[9078],{"type":27,"tag":74,"props":9079,"children":9080},{},[9081],{"type":32,"value":9082},"2. Stories trop vagues ou trop détaillées",{"type":27,"tag":263,"props":9084,"children":9085},{},[9086,9102],{"type":27,"tag":267,"props":9087,"children":9088},{},[9089,9094,9095,9100],{"type":27,"tag":74,"props":9090,"children":9091},{},[9092],{"type":32,"value":9093},"Trop vague",{"type":32,"value":8737},{"type":27,"tag":524,"props":9096,"children":9097},{},[9098],{"type":32,"value":9099},"\"En tant qu'utilisateur, je veux une interface conviviale.\"",{"type":32,"value":9101}," → ingérable.",{"type":27,"tag":267,"props":9103,"children":9104},{},[9105,9110,9111,9116],{"type":27,"tag":74,"props":9106,"children":9107},{},[9108],{"type":32,"value":9109},"Trop détaillée",{"type":32,"value":8737},{"type":27,"tag":524,"props":9112,"children":9113},{},[9114],{"type":32,"value":9115},"\"Je veux un bouton vert avec une bordure de 2px.\"",{"type":32,"value":9117}," → tue l'initiative technique.",{"type":27,"tag":28,"props":9119,"children":9120},{},[9121,9125,9127,9133],{"type":27,"tag":74,"props":9122,"children":9123},{},[9124],{"type":32,"value":9068},{"type":32,"value":9126}," : format standardisé ",{"type":27,"tag":4181,"props":9128,"children":9130},{"className":9129},[],[9131],{"type":32,"value":9132},"En tant que \u002F Je veux \u002F Afin de",{"type":32,"value":9134},", critères d'acceptation pour clarifier sans sur-spécifier.",{"type":27,"tag":55,"props":9136,"children":9137},{},[],{"type":27,"tag":3853,"props":9139,"children":9141},{"id":9140},"_3-oubli-des-nfr",[9142],{"type":27,"tag":74,"props":9143,"children":9144},{},[9145],{"type":32,"value":9146},"3. Oubli des NFR",{"type":27,"tag":28,"props":9148,"children":9149},{},[9150],{"type":32,"value":9151},"Performance, sécurité, conformité : invisibles dans les démos, fatales en prod.",{"type":27,"tag":28,"props":9153,"children":9154},{},[9155,9159],{"type":27,"tag":74,"props":9156,"children":9157},{},[9158],{"type":32,"value":9068},{"type":32,"value":9160}," : section dédiée aux NFR dans la doc, critères d'acceptation testables.",{"type":27,"tag":4174,"props":9162,"children":9164},{"className":4176,"code":9163,"language":4178,"meta":8,"style":8},"Le système doit répondre à 90% des requêtes API en moins de 1 seconde sous une charge normale.  \n",[9165],{"type":27,"tag":4181,"props":9166,"children":9167},{"__ignoreMap":8},[9168],{"type":27,"tag":4185,"props":9169,"children":9170},{"class":4187,"line":4188},[9171],{"type":27,"tag":4185,"props":9172,"children":9173},{},[9174],{"type":32,"value":9175},"Le système doit répondre à 90% des requêtes API en moins de 1 seconde sous une charge normale.\n",{"type":27,"tag":55,"props":9177,"children":9178},{},[],{"type":27,"tag":3853,"props":9180,"children":9182},{"id":9181},"_4-collaboration-interdisciplinaire-négligée",[9183],{"type":27,"tag":74,"props":9184,"children":9185},{},[9186],{"type":32,"value":9187},"4. Collaboration interdisciplinaire négligée",{"type":27,"tag":28,"props":9189,"children":9190},{},[9191],{"type":32,"value":9192},"Stories rédigées par le PO en silo, validation après coup.",{"type":27,"tag":28,"props":9194,"children":9195},{},[9196,9200],{"type":27,"tag":74,"props":9197,"children":9198},{},[9199],{"type":32,"value":9068},{"type":32,"value":9201}," : ateliers de co-rédaction (Three Amigos), validation des critères avec toutes les parties prenantes avant finalisation.",{"type":27,"tag":55,"props":9203,"children":9204},{},[],{"type":27,"tag":3853,"props":9206,"children":9208},{"id":9207},"_5-artefacts-redondants-ou-contradictoires",[9209],{"type":27,"tag":74,"props":9210,"children":9211},{},[9212],{"type":32,"value":9213},"5. Artefacts redondants ou contradictoires",{"type":27,"tag":28,"props":9215,"children":9216},{},[9217],{"type":32,"value":9218},"Deux stories pour le même besoin, ou stories qui se contredisent (ex : \"m'inscrire par email\" vs \"m'inscrire uniquement via Google\").",{"type":27,"tag":28,"props":9220,"children":9221},{},[9222,9226],{"type":27,"tag":74,"props":9223,"children":9224},{},[9225],{"type":32,"value":9068},{"type":32,"value":9227}," : backlog centralisé, revue régulière, outils de suivi de dépendances.",{"type":27,"tag":55,"props":9229,"children":9230},{},[],{"type":27,"tag":3853,"props":9232,"children":9234},{"id":9233},"_6-évolutions-des-requirements-mal-gérées",[9235],{"type":27,"tag":74,"props":9236,"children":9237},{},[9238],{"type":32,"value":9239},"6. Évolutions des requirements mal gérées",{"type":27,"tag":28,"props":9241,"children":9242},{},[9243],{"type":32,"value":9244},"Un besoin métier bouge, les stories restent figées. Les artefacts se désynchronisent silencieusement.",{"type":27,"tag":28,"props":9246,"children":9247},{},[9248,9252],{"type":27,"tag":74,"props":9249,"children":9250},{},[9251],{"type":32,"value":9068},{"type":32,"value":9253}," : processus de gestion du changement (revue hebdo), liens forts entre stories et requirements parents.",{"type":27,"tag":55,"props":9255,"children":9256},{},[],{"type":27,"tag":3853,"props":9258,"children":9260},{"id":9259},"_7-retours-utilisateurs-ignorés",[9261],{"type":27,"tag":74,"props":9262,"children":9263},{},[9264],{"type":32,"value":9265},"7. Retours utilisateurs ignorés",{"type":27,"tag":28,"props":9267,"children":9268},{},[9269],{"type":32,"value":9270},"Stories figées, pas de boucle de feedback. Le produit livré rate sa cible.",{"type":27,"tag":28,"props":9272,"children":9273},{},[9274,9278],{"type":27,"tag":74,"props":9275,"children":9276},{},[9277],{"type":32,"value":9068},{"type":32,"value":9279}," : démos régulières avec les utilisateurs finaux, intégration directe des retours dans le cycle d'évolution.",{"type":27,"tag":55,"props":9281,"children":9282},{},[],{"type":27,"tag":3853,"props":9284,"children":9286},{"id":9285},"_8-outils-sous-exploités",[9287],{"type":27,"tag":74,"props":9288,"children":9289},{},[9290],{"type":32,"value":9291},"8. Outils sous-exploités",{"type":27,"tag":28,"props":9293,"children":9294},{},[9295],{"type":32,"value":9296},"ALM Octane, Jira, Quality Center : utilisés à 10% de leurs capacités, traçabilité faible, dépendances gérées à la main.",{"type":27,"tag":28,"props":9298,"children":9299},{},[9300,9304],{"type":27,"tag":74,"props":9301,"children":9302},{},[9303],{"type":32,"value":9068},{"type":32,"value":9305}," : formation sur l'outil choisi, configuration de liens automatisés entre requirements \u002F stories \u002F tests.",{"type":27,"tag":59,"props":9307,"children":9309},{"id":9308},"conclusion",[9310],{"type":27,"tag":74,"props":9311,"children":9312},{},[9313],{"type":32,"value":9314},"Conclusion",{"type":27,"tag":28,"props":9316,"children":9317},{},[9318],{"type":32,"value":9319},"User stories et requirements ne s'opposent pas, mais ils ne se substituent pas non plus. Les premières captent un besoin utilisateur à un instant T. Les seconds définissent la vision durable du produit. Inverser l'ordre, démarrer par les stories en espérant en extraire les requirements, produit invariablement des backlogs fragmentés et des trous structurels qui se paient cash en fin de cycle.",{"type":27,"tag":28,"props":9321,"children":9322},{},[9323,9325,9329],{"type":32,"value":9324},"Pour aller plus loin sur la qualité d'entrée des stories en sprint, une ",{"type":27,"tag":198,"props":9326,"children":9327},{"href":1749},[9328],{"type":32,"value":2586},{"type":32,"value":9330}," bien posée est un complément indispensable. Et pour ancrer la collaboration métier\u002Ftechnique sur le comportement attendu, le Behaviour-Driven Development (BDD) prend le relais. C'est l'objet du prochain article : \"Adopter le Behaviour-Driven Development (BDD) : Guide complet pour des équipes agiles\".",{"type":27,"tag":59,"props":9332,"children":9334},{"id":9333},"faq-vos-questions-mes-réponses",[9335],{"type":27,"tag":74,"props":9336,"children":9337},{},[9338],{"type":32,"value":9339},"FAQ - Vos questions, mes réponses",{"type":27,"tag":28,"props":9341,"children":9342},{},[9343],{"type":32,"value":9344},"Cinq questions qui reviennent systématiquement sur le terrain.",{"type":27,"tag":393,"props":9346,"children":9347},{},[9348,9353,9375],{"type":27,"tag":397,"props":9349,"children":9350},{},[9351],{"type":32,"value":9352},"1. Quelle est la différence entre un epic et un requirement ?",{"type":27,"tag":263,"props":9354,"children":9355},{},[9356,9366],{"type":27,"tag":267,"props":9357,"children":9358},{},[9359,9364],{"type":27,"tag":74,"props":9360,"children":9361},{},[9362],{"type":32,"value":9363},"Epic",{"type":32,"value":9365}," : conteneur Agile qui regroupe des user stories autour d'un objectif fonctionnel commun. Vit dans le backlog, jetable.",{"type":27,"tag":267,"props":9367,"children":9368},{},[9369,9373],{"type":27,"tag":74,"props":9370,"children":9371},{},[9372],{"type":32,"value":8624},{"type":32,"value":9374}," : artefact pérenne qui décrit un besoin (fonctionnel, NFR, technique, règlementaire). Vit hors du backlog, sert de référence durable.",{"type":27,"tag":28,"props":9376,"children":9377},{},[9378],{"type":32,"value":9379},"Un epic peut être la traduction Agile d'un requirement, mais ce n'est pas la même chose.",{"type":27,"tag":393,"props":9381,"children":9382},{},[9383,9388,9393],{"type":27,"tag":397,"props":9384,"children":9385},{},[9386],{"type":32,"value":9387},"2. Comment gérer les NFR dans un projet Agile ?",{"type":27,"tag":28,"props":9389,"children":9390},{},[9391],{"type":32,"value":9392},"Trois leviers à combiner :",{"type":27,"tag":263,"props":9394,"children":9395},{},[9396,9401,9406],{"type":27,"tag":267,"props":9397,"children":9398},{},[9399],{"type":32,"value":9400},"Les intégrer dans les critères d'acceptation des stories métier (ex : \"doit s'afficher en \u003C 2s\").",{"type":27,"tag":267,"props":9402,"children":9403},{},[9404],{"type":32,"value":9405},"Créer des stories techniques dédiées aux NFR critiques (tests de charge, hardening sécurité).",{"type":27,"tag":267,"props":9407,"children":9408},{},[9409],{"type":32,"value":9410},"Les tester en continu, dans la CI, pour détecter les régressions sprint après sprint.",{"type":27,"tag":393,"props":9412,"children":9413},{},[9414,9419],{"type":27,"tag":397,"props":9415,"children":9416},{},[9417],{"type":32,"value":9418},"3. Est-il possible de travailler sans requirements dans un petit projet ?",{"type":27,"tag":28,"props":9420,"children":9421},{},[9422],{"type":32,"value":9423},"Sur un projet jetable de 2 semaines, oui. Sur tout projet destiné à vivre plus de quelques mois, c'est un pari risqué. Même un document léger d'une page (vision, contraintes clés, NFR) évite la moitié des dérives que je vois en mission.",{"type":27,"tag":393,"props":9425,"children":9426},{},[9427,9432,9437],{"type":27,"tag":397,"props":9428,"children":9429},{},[9430],{"type":32,"value":9431},"4. Comment éviter un backlog surchargé ?",{"type":27,"tag":28,"props":9433,"children":9434},{},[9435],{"type":32,"value":9436},"Trois disciplines :",{"type":27,"tag":263,"props":9438,"children":9439},{},[9440,9445,9450],{"type":27,"tag":267,"props":9441,"children":9442},{},[9443],{"type":32,"value":9444},"Archivage régulier des stories obsolètes (au moins une fois par sprint).",{"type":27,"tag":267,"props":9446,"children":9447},{},[9448],{"type":32,"value":9449},"Priorisation stricte selon la valeur métier : pas plus de 2 mois de travail au-dessus de la ligne de visibilité.",{"type":27,"tag":267,"props":9451,"children":9452},{},[9453],{"type":32,"value":9454},"Revue du backlog en rétrospective pour identifier le mort-vivant.",{"type":27,"tag":393,"props":9456,"children":9457},{},[9458,9463],{"type":27,"tag":397,"props":9459,"children":9460},{},[9461],{"type":32,"value":9462},"5. Comment gérer les dépendances entre stories ?",{"type":27,"tag":263,"props":9464,"children":9465},{},[9466,9471,9476],{"type":27,"tag":267,"props":9467,"children":9468},{},[9469],{"type":32,"value":9470},"Identifier au refinement, pas au sprint planning.",{"type":27,"tag":267,"props":9472,"children":9473},{},[9474],{"type":32,"value":9475},"Visualiser dans l'outil (Jira liens \"blocked by\", arborescence d'epic).",{"type":27,"tag":267,"props":9477,"children":9478},{},[9479],{"type":32,"value":9480},"Prioriser les bloquantes en premier, toujours. Sinon le sprint dérape.",{"type":27,"tag":55,"props":9482,"children":9483},{},[],{"type":27,"tag":216,"props":9485,"children":9486},{"cta":464,"href":465,"title":466,"type":467},[9487],{"type":27,"tag":28,"props":9488,"children":9489},{},[9490],{"type":32,"value":9491},"Le framework 4 phases appliqué dans 12 équipes engineering. Des requirements clairs aux user stories bien structurées : découvrez comment une meilleure définition du besoin réduit le lead time de 50% en 90 jours.",{"type":27,"tag":6525,"props":9493,"children":9494},{},[9495],{"type":32,"value":6529},{"title":8,"searchDepth":475,"depth":475,"links":9497},[9498,9503,9511,9518,9521,9522,9529,9536,9546,9547],{"id":6632,"depth":475,"text":6638,"children":9499},[9500,9501,9502],{"id":6649,"depth":4205,"text":6655},{"id":6799,"depth":4205,"text":6805},{"id":6925,"depth":4205,"text":6931},{"id":7084,"depth":475,"text":7090,"children":9504},[9505,9506,9507,9508,9509,9510],{"id":7101,"depth":4205,"text":7107},{"id":7152,"depth":4205,"text":7158},{"id":7249,"depth":4205,"text":7255},{"id":7288,"depth":4205,"text":7294},{"id":7327,"depth":4205,"text":7333},{"id":7391,"depth":4205,"text":7397},{"id":7442,"depth":475,"text":7448,"children":9512},[9513,9514,9515,9516,9517],{"id":7459,"depth":4205,"text":7465},{"id":7523,"depth":4205,"text":7529},{"id":7594,"depth":4205,"text":7600},{"id":7715,"depth":4205,"text":7721},{"id":7770,"depth":4205,"text":7776},{"id":7802,"depth":475,"text":7808,"children":9519},[9520],{"id":7887,"depth":4205,"text":7893},{"id":7912,"depth":475,"text":7918},{"id":8104,"depth":475,"text":8110,"children":9523},[9524,9525,9526,9527,9528],{"id":8121,"depth":4205,"text":8127},{"id":8261,"depth":4205,"text":8267},{"id":8303,"depth":4205,"text":8309},{"id":8466,"depth":4205,"text":8472},{"id":8521,"depth":4205,"text":8527},{"id":8563,"depth":475,"text":8569,"children":9530},[9531,9532,9533,9534,9535],{"id":8580,"depth":4205,"text":8586},{"id":8710,"depth":4205,"text":8716},{"id":8849,"depth":4205,"text":8855},{"id":8909,"depth":4205,"text":8915},{"id":8987,"depth":4205,"text":8993},{"id":9032,"depth":475,"text":9038,"children":9537},[9538,9539,9540,9541,9542,9543,9544,9545],{"id":9049,"depth":4205,"text":9055},{"id":9076,"depth":4205,"text":9082},{"id":9140,"depth":4205,"text":9146},{"id":9181,"depth":4205,"text":9187},{"id":9207,"depth":4205,"text":9213},{"id":9233,"depth":4205,"text":9239},{"id":9259,"depth":4205,"text":9265},{"id":9285,"depth":4205,"text":9291},{"id":9308,"depth":475,"text":9314},{"id":9333,"depth":475,"text":9339},"content:fr:pratiques-agiles:user-stories-vs-requirements-guide-complet.md","fr\u002Fpratiques-agiles\u002Fuser-stories-vs-requirements-guide-complet.md","fr\u002Fpratiques-agiles\u002Fuser-stories-vs-requirements-guide-complet",1784113936361]