{"id":1240,"date":"2026-03-25T12:20:07","date_gmt":"2026-03-25T12:20:07","guid":{"rendered":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/"},"modified":"2026-03-25T12:20:07","modified_gmt":"2026-03-25T12:20:07","slug":"user-story-acceptance-criteria-definition-done","status":"publish","type":"post","link":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/","title":{"rendered":"Analyse approfondie d’une histoire utilisateur : comprendre les crit\u00e8res d’acceptation et la d\u00e9finition de termin\u00e9"},"content":{"rendered":"

Dans le paysage du d\u00e9veloppement agile, la clart\u00e9 est la monnaie du succ\u00e8s. Lorsqu’une \u00e9quipe commence un travail sur une nouvelle fonctionnalit\u00e9, la fondation r\u00e9side dans l’histoire utilisateur. Toutefois, une histoire utilisateur n’est qu’un simple indicateur de conversation. Pour transformer cette conversation en un produit fonctionnel, deux \u00e9l\u00e9ments essentiels sont requis : les crit\u00e8res d’acceptation et la d\u00e9finition de termin\u00e9. Ces concepts agissent comme des rep\u00e8res qui garantissent la qualit\u00e9, l’alignement et la pr\u00e9visibilit\u00e9.<\/p>\n

De nombreuses \u00e9quipes peinent \u00e0 distinguer ces deux concepts. Parfois, elles les traitent comme identiques, ce qui entra\u00eene de la confusion lors des tests ou du d\u00e9ploiement. \u00c0 d’autres moments, elles les n\u00e9gligent compl\u00e8tement, ce qui entra\u00eene une extension du p\u00e9rim\u00e8tre ou des fonctionnalit\u00e9s incompl\u00e8tes qui parviennent en production. Ce guide explore les m\u00e9canismes, le but et la mise en \u0153uvre des crit\u00e8res d’acceptation et de la d\u00e9finition de termin\u00e9 afin d’aider votre \u00e9quipe \u00e0 livrer de la valeur de mani\u00e8re coh\u00e9rente.<\/p>\n

\n
\"Hand-drawn<\/figure>\n<\/div>\n

Qu’est-ce qu’une histoire utilisateur ? \ud83d\udcdd<\/h2>\n

Avant de d\u00e9tailler les composants d’une histoire, il est essentiel de rappeler ce qu’est r\u00e9ellement une histoire utilisateur. Dans les cadres agiles, une histoire utilisateur est une br\u00e8ve description simple d’une fonctionnalit\u00e9, formul\u00e9e du point de vue de la personne qui souhaite la nouvelle capacit\u00e9. Elle suit g\u00e9n\u00e9ralement le format suivant :<\/p>\n

    \n
  • En tant que<\/strong> [type d’utilisateur],<\/li>\n
  • Je veux<\/strong> [un objectif],<\/li>\n
  • Afin que<\/strong> [un avantage].<\/li>\n<\/ul>\n

    Ce format se concentre sur le valeur<\/em>fournie \u00e0 l’utilisateur, plut\u00f4t que sur la mise en \u0153uvre technique. Toutefois, ce format seul ne suffit pas \u00e0 guider le d\u00e9veloppement. Il ne pr\u00e9cise pas les limites du travail ni les normes requises pour la finalisation. C’est l\u00e0 que les crit\u00e8res d’acceptation et la d\u00e9finition de termin\u00e9 interviennent.<\/p>\n

    Crit\u00e8res d’acceptation (CA) : les conditions de finalisation \u2705<\/h2>\n

    Les crit\u00e8res d’acceptation sont un ensemble de conditions qu’une histoire utilisateur doit satisfaire pour \u00eatre consid\u00e9r\u00e9e comme compl\u00e8te du point de vue du propri\u00e9taire produit. Ils d\u00e9finissent les limites de l’histoire et fournissent une compr\u00e9hension claire de ce que doit \u00eatre le produit final.<\/p>\n

    Le but des crit\u00e8res d’acceptation<\/h3>\n

    Les crit\u00e8res d’acceptation remplissent plusieurs fonctions au cours du cycle de d\u00e9veloppement :<\/p>\n

      \n
    • Clarification :<\/strong> Ils \u00e9liminent l’ambigu\u00eft\u00e9. Si un d\u00e9veloppeur demande : \u00ab Le bouton doit-il devenir vert ou bleu au survol ? \u00bb, les CA doivent r\u00e9pondre \u00e0 cette question.<\/li>\n
    • Tests :<\/strong> Ils agissent comme des cas de test. Les ing\u00e9nieurs QA utilisent ces conditions pour valider la fonctionnalit\u00e9.<\/li>\n
    • Accord :<\/strong> Ils garantissent que le propri\u00e9taire produit et l’\u00e9quipe de d\u00e9veloppement sont d’accord sur ce qui constitue \u00ab termin\u00e9 \u00bb pour cette histoire sp\u00e9cifique.<\/li>\n<\/ul>\n

      Caract\u00e9ristiques des bons crit\u00e8res d’acceptation<\/h3>\n

      Les crit\u00e8res d’acceptation efficaces sont pr\u00e9cis, mesurables et sans ambigu\u00eft\u00e9. \u00c9vitez les termes vagues comme \u00ab convivial \u00bb ou \u00ab rapide \u00bb sans d\u00e9finir de m\u00e9triques. Pr\u00e9cisez plut\u00f4t des comportements exacts.<\/p>\n

        \n
      • Atomiques :<\/strong> Chaque crit\u00e8re doit traiter d’un seul besoin.<\/li>\n
      • Testables :<\/strong> Il doit \u00eatre possible de v\u00e9rifier le crit\u00e8re en obtenant un r\u00e9sultat \u00ab succ\u00e8s \u00bb ou \u00ab \u00e9chec \u00bb.<\/li>\n
      • Ind\u00e9pendant :<\/strong>Les crit\u00e8res ne doivent pas d\u00e9pendre d’histoires externes pour \u00eatre valid\u00e9s.<\/li>\n
      • Relevant :<\/strong>Concentrez-vous sur la valeur pour l’utilisateur, et non sur la structure interne du code.<\/li>\n<\/ul>\n

        Exemples de crit\u00e8res d’acceptation<\/h3>\n

        Pensez \u00e0 une histoire concernant l’ajout d’une fonctionnalit\u00e9 \u00ab Mot de passe oubli\u00e9 \u00bb. Voici \u00e0 quoi pourraient ressembler les crit\u00e8res d’acceptation :<\/p>\n

          \n
        • \u00c9tant donn\u00e9 que l’utilisateur est sur la page de connexion,
          Lorsqu’ils cliquent sur le lien \u00ab Mot de passe oubli\u00e9 \u00bb,
          Alors ils sont redirig\u00e9s vers la page de r\u00e9cup\u00e9ration du mot de passe.<\/li>\n
        • \u00c9tant donn\u00e9 que l’utilisateur saisit un e-mail valide,
          Lorsqu’ils soumettent le formulaire,
          Alors un message de confirmation est affich\u00e9.<\/li>\n
        • \u00c9tant donn\u00e9 que l’utilisateur saisit un e-mail non valide,
          Lorsqu’ils soumettent le formulaire,
          Alors un message d’erreur indique que le format de l’e-mail est incorrect.<\/li>\n<\/ul>\n

          Ces exemples suivent la structure \u00c9tant donn\u00e9\/Quand\/Alors<\/strong> structure (souvent associ\u00e9e \u00e0 la syntaxe Gherkin), qui favorise la clart\u00e9 et s’aligne avec les cadres de test automatis\u00e9.<\/p>\n

          D\u00e9finition de termin\u00e9 (DoD) : la porte de qualit\u00e9 \ud83d\udea7<\/h2>\n

          Alors que les crit\u00e8res d’acceptation sont sp\u00e9cifiques \u00e0 une seule histoire utilisateur, la D\u00e9finition de termin\u00e9 est une norme globale appliqu\u00e9e \u00e0tous<\/em> les travaux au sein d’un sprint ou d’une version. Elle repr\u00e9sente la liste de contr\u00f4le des exigences qui doivent \u00eatre remplies pour qu’une avanc\u00e9e de travail soit consid\u00e9r\u00e9e comme potentiellement livrable.<\/p>\n

          Le but de la D\u00e9finition de termin\u00e9<\/h3>\n

          La DoD agit comme une porte de qualit\u00e9. Elle garantit que la dette technique ne s’accumule pas et que le produit reste toujours dans un \u00e9tat livrable. Si une histoire remplit ses crit\u00e8res d’acceptation mais ne satisfait pas la D\u00e9finition de termin\u00e9, elle ne peut pas \u00eatre marqu\u00e9e comme termin\u00e9e.<\/p>\n

          Les \u00e9l\u00e9ments courants trouv\u00e9s dans une D\u00e9finition de termin\u00e9 incluent :<\/p>\n

            \n
          • Revue de code :<\/strong>Tout le code doit \u00eatre revu par au moins un pair.<\/li>\n
          • Tests unitaires :<\/strong>Les tests automatis\u00e9s doivent passer avec une couverture \u00e0 100 % pour la nouvelle logique.<\/li>\n
          • Documentation :<\/strong> La documentation de l’API ou les guides utilisateurs sont mis \u00e0 jour.<\/li>\n
          • Performances :<\/strong> La fonctionnalit\u00e9 respecte les exigences minimales de temps de chargement.<\/li>\n
          • Accessibilit\u00e9 :<\/strong> La fonctionnalit\u00e9 respecte les lignes directrices WCAG.<\/li>\n
          • S\u00e9curit\u00e9 :<\/strong> Aucune vuln\u00e9rabilit\u00e9 connue n’est introduite.<\/li>\n<\/ul>\n

            Pourquoi le DoD compte<\/h3>\n

            Sans une D\u00e9finition de Fait, les \u00e9quipes tombent souvent dans le pi\u00e8ge du \u00ab techniquement termin\u00e9 mais pas r\u00e9ellement pr\u00eat \u00bb. Une fonctionnalit\u00e9 peut fonctionner comme pr\u00e9vu selon les Crit\u00e8res d’Acceptation, mais elle pourrait avoir endommag\u00e9 une autre partie du syst\u00e8me, manquer de documentation ad\u00e9quate ou introduire des risques de s\u00e9curit\u00e9. Le DoD pr\u00e9vient cela en imposant une base de qualit\u00e9 sur l’ensemble du backlog.<\/p>\n

            Crit\u00e8res d’Acceptation vs. D\u00e9finition de Fait : Les principales diff\u00e9rences \ud83c\udd9a<\/h2>\n

            La confusion survient souvent parce que les deux concepts traitent de la \u00ab compl\u00e9tude \u00bb. Toutefois, leur port\u00e9e et leur responsabilit\u00e9 diff\u00e8rent consid\u00e9rablement. Comprendre cette distinction \u00e9vite les malentendus entre les d\u00e9veloppeurs, les testeurs et les product owners.<\/p>\n\n\n\n\n\n\n\n\n\n
            Fonctionnalit\u00e9<\/th>\nCrit\u00e8res d’Acceptation<\/th>\nD\u00e9finition de Fait<\/th>\n<\/tr>\n<\/thead>\n
            Port\u00e9e<\/strong><\/td>\nSp\u00e9cifique \u00e0 une seule Story Utilisateur<\/td>\nGlobale pour toute l’\u00e9quipe ou le projet<\/td>\n<\/tr>\n
            Responsabilit\u00e9<\/strong><\/td>\nProduct Owner et \u00c9quipe de D\u00e9veloppement<\/td>\nToute l’\u00e9quipe de d\u00e9veloppement<\/td>\n<\/tr>\n
            Flexibilit\u00e9<\/strong><\/td>\nModifications par histoire selon les exigences<\/td>\nStable, bien qu’elle puisse \u00eatre mise \u00e0 jour au fil du temps<\/td>\n<\/tr>\n
            Objectif<\/strong><\/td>\nD\u00e9finit les exigences fonctionnelles<\/td>\nD\u00e9finit les normes de qualit\u00e9 et non fonctionnelles<\/td>\n<\/tr>\n
            V\u00e9rification<\/strong><\/td>\nTests fonctionnels par rapport aux besoins des utilisateurs<\/td>\nV\u00e9rification technique et processus<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

            Imaginez les Crit\u00e8res d’Acceptation comme la destination d’un voyage sp\u00e9cifique, tandis que la D\u00e9finition de Fait est la v\u00e9rification de s\u00e9curit\u00e9 requise pour chaque v\u00e9hicule sur la route.<\/p>\n

            Comment r\u00e9diger des crit\u00e8res d’acceptation efficaces \ud83d\udcdd<\/h2>\n

            R\u00e9diger les crit\u00e8res d’acceptation est une d\u00e9marche collaborative. Il ne doit pas \u00eatre fait en isolation par le propri\u00e9taire produit. La meilleure pratique implique le concept des \u00ab Trois Amis \u00bb, o\u00f9 le propri\u00e9taire produit, un d\u00e9veloppeur et un testeur collaborent t\u00f4t dans le processus de r\u00e9vision.<\/p>\n

            \u00c9tape 1 : Identifier l’objectif de l’utilisateur<\/h3>\n

            Commencez par reformuler la proposition de valeur. Quel probl\u00e8me l’utilisateur r\u00e9sout-il ? Cela garantit que les crit\u00e8res restent centr\u00e9s sur l’exp\u00e9rience utilisateur plut\u00f4t que sur les d\u00e9tails techniques.<\/p>\n

            \u00c9tape 2 : D\u00e9finir des sc\u00e9narios positifs et n\u00e9gatifs<\/h3>\n

            Ne r\u00e9digez pas uniquement le parcours id\u00e9al. Pensez \u00e0 ce qui se produit lorsque les choses tournent mal.<\/p>\n

              \n
            • Parcours id\u00e9al :<\/strong> L’utilisateur effectue l’action exactement comme pr\u00e9vu.<\/li>\n
            • Cas limites :<\/strong> Que se passe-t-il avec des caract\u00e8res sp\u00e9ciaux, des donn\u00e9es manquantes ou des connexions lentes ?<\/li>\n
            • Parcours n\u00e9gatif :<\/strong> Comment le syst\u00e8me g\u00e8re-t-il les entr\u00e9es non valides de mani\u00e8re \u00e9l\u00e9gante ?<\/li>\n<\/ul>\n

              \u00c9tape 3 : Utiliser un langage clair<\/h3>\n

              \u00c9vitez le jargon autant que possible. Si des termes techniques sont n\u00e9cessaires, assurez-vous qu’ils sont d\u00e9finis. Utilisez le style actif. Par exemple, \u00ab Le syst\u00e8me doit valider\u2026 \u00bb est moins clair que \u00ab L’utilisateur re\u00e7oit un message d’erreur\u2026 \u00bb.<\/p>\n

              \u00c9tape 4 : Prioriser<\/h3>\n

              Si une histoire est importante, divisez-la. Les crit\u00e8res d’acceptation doivent \u00eatre r\u00e9alisables dans le sprint. Si les crit\u00e8res impliquent un travail qui ne peut pas \u00eatre termin\u00e9 dans le sprint, l’histoire doit \u00eatre divis\u00e9e.<\/p>\n

              Comment \u00e9tablir une d\u00e9finition du fait robuste \ud83d\udee0\ufe0f<\/h2>\n

              La d\u00e9finition du fait n’est pas un document statique. Elle \u00e9volue avec la maturit\u00e9 de l’\u00e9quipe et les changements technologiques. Elle doit \u00eatre visible de tous, souvent affich\u00e9e sur un tableau physique ou num\u00e9rique.<\/p>\n

              \u00c9tape 1 : Consulter l’\u00e9quipe<\/h3>\n

              La DoD appartient \u00e0 l’\u00e9quipe qui r\u00e9alise le travail. Les d\u00e9veloppeurs, les testeurs et les concepteurs doivent contribuer \u00e0 la liste. Si un d\u00e9veloppeur ajoute une exigence, il est plus susceptible de s’y tenir.<\/p>\n

              \u00c9tape 2 : Cat\u00e9goriser les exigences<\/h3>\n

              Regroupez les \u00e9l\u00e9ments de la DoD en cat\u00e9gories logiques pour rendre la liste de contr\u00f4le g\u00e9rable.<\/p>\n

                \n
              • Qualit\u00e9 du code :<\/strong> Le linting a r\u00e9ussi, aucune alerte, la revue par les pairs est termin\u00e9e.<\/li>\n
              • Tests :<\/strong> Des tests unitaires ont \u00e9t\u00e9 \u00e9crits, les tests d’int\u00e9gration ont r\u00e9ussi, les tests manuels ont \u00e9t\u00e9 valid\u00e9s.<\/li>\n
              • D\u00e9ploiement :<\/strong> D\u00e9ploy\u00e9 en pr\u00e9-production, les tests de fum\u00e9e ont r\u00e9ussi.<\/li>\n
              • Documentation :<\/strong> Le fichier Readme a \u00e9t\u00e9 mis \u00e0 jour, les documents de l’API sont synchronis\u00e9s.<\/li>\n<\/ul>\n

                \u00c9tape 3 : Faites-en une fin obligatoire<\/h3>\n

                Si une histoire ne r\u00e9pond pas au CDA, elle ne peut pas \u00eatre cl\u00f4tur\u00e9e. Cela exige de la discipline. Il est tentant de dire : \u00ab Nous corrigerons la documentation plus tard \u00bb, mais cela cr\u00e9e une dette technique. L\u2019histoire reste dans \u00ab En cours \u00bb jusqu\u2019\u00e0 ce que le CDA soit respect\u00e9.<\/p>\n

                \u00c9tape 4 : Revue et am\u00e9lioration<\/h3>\n

                Pendant les r\u00e9trospectives, demandez \u00e0 l\u2019\u00e9quipe : \u00ab Le CDA a-t-il d\u00e9tect\u00e9 des probl\u00e8mes ? \u00bb ou \u00ab Y a-t-il une exigence que nous oublions constamment ? \u00bb Mettez \u00e0 jour le CDA en fonction de ces retours.<\/p>\n

                Erreurs courantes \u00e0 \u00e9viter \u26a0\ufe0f<\/h2>\n

                M\u00eame les \u00e9quipes exp\u00e9riment\u00e9es font des erreurs lors de la mise en \u0153uvre de ces pratiques. \u00catre conscient des pi\u00e8ges courants peut \u00e9pargner beaucoup de temps et de frustration.<\/p>\n

                1. Crit\u00e8res d\u2019acceptation vagues<\/h3>\n

                \u00c9crire des crit\u00e8res comme \u00ab Le syst\u00e8me doit \u00eatre s\u00e9curis\u00e9 \u00bb est inutile. Ce n\u2019est pas testable. Pr\u00e9cisez plut\u00f4t : \u00ab Le syst\u00e8me doit exiger une authentification \u00e0 deux facteurs pour les comptes d\u2019administrateur. \u00bb<\/p>\n

                2. Le CDA comme simple v\u00e9rification de cases<\/h3>\n

                Si l\u2019\u00e9quipe coche la case du CDA sans effectivement accomplir le travail (par exemple, en sautant la revue de code), le CDA perd tout sens. Le CDA doit \u00eatre respect\u00e9, pas simplement lu.<\/p>\n

                3. Surcharger le CDA<\/h3>\n

                Un CDA comprenant 50 \u00e9l\u00e9ments devient \u00e9crasant. Concentrez-vous sur les seuils essentiels de qualit\u00e9. Si une exigence est rarement viol\u00e9e, elle pourrait \u00eatre une recommandation plut\u00f4t qu\u2019un \u00e9l\u00e9ment obligatoire du CDA.<\/p>\n

                4. Ignorer les exigences non fonctionnelles<\/h3>\n

                Les \u00e9quipes se concentrent souvent fortement sur les AC (fonctionnels) et n\u00e9gligent le CDA (non fonctionnels). La performance, la s\u00e9curit\u00e9 et l\u2019accessibilit\u00e9 font partie du CDA, pas des AC. Les n\u00e9gliger conduit \u00e0 des fonctionnalit\u00e9s qui fonctionnent mais sont lentes ou dangereuses.<\/p>\n

                5. Cr\u00e9er un CDA sans l\u2019adh\u00e9sion de l\u2019\u00e9quipe<\/h3>\n

                Si le Product Owner \u00e9tablit le CDA sans l\u2019avis des d\u00e9veloppeurs, l\u2019\u00e9quipe peut y r\u00e9sister. Le CDA doit \u00eatre un accord partag\u00e9.<\/p>\n

                Int\u00e9gration dans le flux de travail \ud83d\udd04<\/h2>\n

                Les crit\u00e8res d\u2019acceptation et la d\u00e9finition de fin doivent \u00eatre int\u00e9gr\u00e9s \u00e0 chaque \u00e9tape du cycle de d\u00e9veloppement, et non seulement \u00e0 la fin.<\/p>\n

                Phase de r\u00e9vision<\/h3>\n

                Pendant la r\u00e9vision du backlog, le Product Owner r\u00e9dige les crit\u00e8res d\u2019acceptation. L\u2019\u00e9quipe les examine pour s\u2019assurer qu\u2019ils sont testables et r\u00e9alisables. Les questions sont pos\u00e9es et r\u00e9pondues ici, et non pendant le sprint.<\/p>\n

                Planification du sprint<\/h3>\n

                Lors de l\u2019engagement sur les histoires, l\u2019\u00e9quipe v\u00e9rifie que les crit\u00e8res d\u2019acceptation sont clairs. S\u2019ils ne le sont pas, l\u2019histoire n\u2019est pas pr\u00eate pour le sprint.<\/p>\n

                Phase de d\u00e9veloppement<\/h3>\n

                Les d\u00e9veloppeurs \u00e9crivent du code pour r\u00e9pondre aux AC. En m\u00eame temps, ils s\u2019assurent de respecter le CDA (par exemple, en \u00e9crivant des tests, en demandant des revues).<\/p>\n

                Phase de test<\/h3>\n

                Les ing\u00e9nieurs QA v\u00e9rifient les AC par rapport \u00e0 la fonctionnalit\u00e9 construite. Ils v\u00e9rifient \u00e9galement le CDA (par exemple, en consultant les rapports de couverture de code, des analyses d\u2019accessibilit\u00e9).<\/p>\n

                Revue et cl\u00f4ture<\/h3>\n

                Avant de d\u00e9placer une histoire vers \u00ab Termin\u00e9 \u00bb, l\u2019\u00e9quipe confirme que les AC et le CDA sont tous deux satisfaits. Sinon, elle retourne dans la file d\u2019attente.<\/p>\n

                Mesurer le succ\u00e8s \ud83d\udcca<\/h2>\n

                Comment savoir si vos crit\u00e8res d\u2019acceptation et votre d\u00e9finition de fin fonctionnent ? Suivez les indicateurs au fil du temps.<\/p>\n

                  \n
                • Taux de d\u00e9faut :<\/strong>Les bogues trouv\u00e9s en production diminuent-ils ? Un bon crit\u00e8re de fin de d\u00e9veloppement devrait d\u00e9tecter les probl\u00e8mes avant le lancement.<\/li>\n
                • Taux de rejet :<\/strong>Les histoires sont-elles fr\u00e9quemment rejet\u00e9es par le Product Owner ? Cela indique une d\u00e9finition insuffisante des crit\u00e8res d’acceptation.<\/li>\n
                • Stabilit\u00e9 de la vitesse :<\/strong>La vitesse de l’\u00e9quipe reste-t-elle constante ? Si les histoires sont fr\u00e9quemment renvoy\u00e9es pour des \u00e9l\u00e9ments manquants du crit\u00e8re de fin de d\u00e9veloppement, la vitesse va fluctuer.<\/li>\n
                • Fr\u00e9quence du d\u00e9ploiement :<\/strong>Un crit\u00e8re de fin de d\u00e9veloppement clair permet-il des d\u00e9ploiements plus fluides et plus fr\u00e9quents ?<\/li>\n<\/ul>\n

                  Questions fr\u00e9quemment pos\u00e9es \u2753<\/h2>\n

                  Voici les questions courantes pos\u00e9es par les \u00e9quipes lors de la mise en \u0153uvre de ces normes.<\/p>\n

                  Q : Les crit\u00e8res d’acceptation peuvent-ils \u00e9voluer pendant une it\u00e9ration ?<\/h3>\n

                  R : Id\u00e9alement, non. Si les crit\u00e8res d’acceptation \u00e9voluent de mani\u00e8re significative, cela peut indiquer que l’histoire n’a pas \u00e9t\u00e9 suffisamment comprise lors de la phase de pr\u00e9paration. Des clarifications mineures sont acceptables, mais des changements majeurs de port\u00e9e doivent entra\u00eener une nouvelle histoire ou un ajustement de la port\u00e9e de l’it\u00e9ration.<\/p>\n

                  Q : Chaque histoire doit-elle avoir une d\u00e9finition de fin unique ?<\/h3>\n

                  R : Non. Le crit\u00e8re de fin de d\u00e9veloppement est global. Toutefois, certaines histoires techniques peuvent avoir des exigences suppl\u00e9mentaires ajout\u00e9es \u00e0 la liste de contr\u00f4le pour cet \u00e9l\u00e9ment sp\u00e9cifique, mais le crit\u00e8re de fin de base s’applique \u00e0 toutes les histoires.<\/p>\n

                  Q : Que faire si l’\u00e9quipe ne s’accorde pas sur le crit\u00e8re de fin de d\u00e9veloppement ?<\/h3>\n

                  R : Facilitez une discussion. L’objectif est d’atteindre un consensus. Si un d\u00e9veloppeur insiste sur une exigence que le testeur conteste, discutez du risque. Si le risque est faible, supprimez-la. Si le risque est \u00e9lev\u00e9, gardez-la.<\/p>\n

                  Q : \u00c0 quel point les crit\u00e8res d’acceptation doivent-ils \u00eatre d\u00e9taill\u00e9s ?<\/h3>\n

                  R : Suffisamment d\u00e9taill\u00e9s pour \u00eatre testables. Si un ing\u00e9nieur de test peut r\u00e9diger directement un cas de test \u00e0 partir des crit\u00e8res d’acceptation, ils sont suffisamment d\u00e9taill\u00e9s. S’ils doivent poser des questions, il faut ajouter plus de d\u00e9tails.<\/p>\n

                  Q : Le test automatis\u00e9 peut-il remplacer le test manuel dans le crit\u00e8re de fin de d\u00e9veloppement ?<\/h3>\n

                  R : Cela d\u00e9pend. Pour la logique critique, oui. Pour l’exp\u00e9rience utilisateur ou les \u00e9l\u00e9ments visuels, une validation manuelle peut encore \u00eatre n\u00e9cessaire. Le crit\u00e8re de fin de d\u00e9veloppement doit refl\u00e9ter la meilleure pratique en mati\u00e8re d’assurance qualit\u00e9.<\/p>\n

                  Pens\u00e9es finales sur la qualit\u00e9 et l’alignement \ud83c\udf1f<\/h2>\n

                  Mettre en \u0153uvre les crit\u00e8res d’acceptation et le crit\u00e8re de fin de d\u00e9veloppement ne s’agit pas de bureaucratie ; c’est une question de respect. C’est le respect de l’utilisateur qui attend une fonctionnalit\u00e9 op\u00e9rationnelle, le respect du d\u00e9veloppeur qui souhaite des exigences claires, et le respect du product owner qui a besoin de confiance dans la livraison.<\/p>\n

                  Lorsque ces deux concepts sont utilis\u00e9s correctement, ils cr\u00e9ent un langage commun pour l’\u00e9quipe. Ils r\u00e9duisent la n\u00e9cessit\u00e9 de r\u00e9unions constantes de clarification. Ils emp\u00eachent l’accumulation de dette technique. Et surtout, ils garantissent que chaque histoire achev\u00e9e ajoute une v\u00e9ritable valeur au produit.<\/p>\n

                  Commencez petit. D\u00e9finissez un crit\u00e8re de fin de d\u00e9veloppement basique. R\u00e9digez des crit\u00e8res d’acceptation clairs pour votre prochaine histoire. R\u00e9visez-les lors de votre prochaine r\u00e9trospective. Au fil du temps, ces pratiques deviendront naturelles, ancr\u00e9es dans la culture de votre \u00e9quipe. Le r\u00e9sultat est un flux constant de logiciels de haute qualit\u00e9 qui r\u00e9pondent aux besoins des utilisateurs.<\/p>\n","protected":false},"excerpt":{"rendered":"

                  Dans le paysage du d\u00e9veloppement agile, la clart\u00e9 est la monnaie du succ\u00e8s. Lorsqu’une \u00e9quipe commence un travail sur une nouvelle fonctionnalit\u00e9, la fondation r\u00e9side dans l’histoire utilisateur. Toutefois, une…<\/p>\n","protected":false},"author":1,"featured_media":1241,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_yoast_wpseo_title":"Guide des crit\u00e8res d'acceptation des histoires utilisateur et du crit\u00e8re de fin de d\u00e9veloppement \ud83d\udcdd","_yoast_wpseo_metadesc":"Apprenez \u00e0 r\u00e9diger des crit\u00e8res d'acceptation clairs et un crit\u00e8re de fin de d\u00e9veloppement pour les histoires utilisateur. Am\u00e9liorez la qualit\u00e9, r\u00e9duisez les reprises de travail et alignez les \u00e9quipes dans les projets agiles.","fifu_image_url":"","fifu_image_alt":"","footnotes":""},"categories":[47],"tags":[43,46],"class_list":["post-1240","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-user-story","tag-academic","tag-user-story"],"yoast_head":"\nGuide des crit\u00e8res d'acceptation des histoires utilisateur et du crit\u00e8re de fin de d\u00e9veloppement \ud83d\udcdd<\/title>\n<meta name=\"description\" content=\"Apprenez \u00e0 r\u00e9diger des crit\u00e8res d'acceptation clairs et un crit\u00e8re de fin de d\u00e9veloppement pour les histoires utilisateur. Am\u00e9liorez la qualit\u00e9, r\u00e9duisez les reprises de travail et alignez les \u00e9quipes dans les projets agiles.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Guide des crit\u00e8res d'acceptation des histoires utilisateur et du crit\u00e8re de fin de d\u00e9veloppement \ud83d\udcdd\" \/>\n<meta property=\"og:description\" content=\"Apprenez \u00e0 r\u00e9diger des crit\u00e8res d'acceptation clairs et un crit\u00e8re de fin de d\u00e9veloppement pour les histoires utilisateur. Am\u00e9liorez la qualit\u00e9, r\u00e9duisez les reprises de travail et alignez les \u00e9quipes dans les projets agiles.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/\" \/>\n<meta property=\"og:site_name\" content=\"Method Post French | Your Daily Guide to AI & Software Solutions\" \/>\n<meta property=\"article:published_time\" content=\"2026-03-25T12:20:07+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.method-post.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/03\/agile-user-story-acceptance-criteria-definition-done-infographic-childs-drawing.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1664\" \/>\n\t<meta property=\"og:image:height\" content=\"928\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"vpadmin\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"\u00c9crit par\" \/>\n\t<meta name=\"twitter:data1\" content=\"vpadmin\" \/>\n\t<meta name=\"twitter:label2\" content=\"Dur\u00e9e de lecture estim\u00e9e\" \/>\n\t<meta name=\"twitter:data2\" content=\"14 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/\"},\"author\":{\"name\":\"vpadmin\",\"@id\":\"https:\/\/www.method-post.com\/fr\/#\/schema\/person\/c45282b4509328baa27563996f83263e\"},\"headline\":\"Analyse approfondie d’une histoire utilisateur : comprendre les crit\u00e8res d’acceptation et la d\u00e9finition de termin\u00e9\",\"datePublished\":\"2026-03-25T12:20:07+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/\"},\"wordCount\":2929,\"publisher\":{\"@id\":\"https:\/\/www.method-post.com\/fr\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.method-post.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/03\/agile-user-story-acceptance-criteria-definition-done-infographic-childs-drawing.jpg\",\"keywords\":[\"academic\",\"user story\"],\"articleSection\":[\"User Story\"],\"inLanguage\":\"fr-FR\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/\",\"url\":\"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/\",\"name\":\"Guide des crit\u00e8res d'acceptation des histoires utilisateur et du crit\u00e8re de fin de d\u00e9veloppement \ud83d\udcdd\",\"isPartOf\":{\"@id\":\"https:\/\/www.method-post.com\/fr\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.method-post.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/03\/agile-user-story-acceptance-criteria-definition-done-infographic-childs-drawing.jpg\",\"datePublished\":\"2026-03-25T12:20:07+00:00\",\"description\":\"Apprenez \u00e0 r\u00e9diger des crit\u00e8res d'acceptation clairs et un crit\u00e8re de fin de d\u00e9veloppement pour les histoires utilisateur. Am\u00e9liorez la qualit\u00e9, r\u00e9duisez les reprises de travail et alignez les \u00e9quipes dans les projets agiles.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/#breadcrumb\"},\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/#primaryimage\",\"url\":\"https:\/\/www.method-post.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/03\/agile-user-story-acceptance-criteria-definition-done-infographic-childs-drawing.jpg\",\"contentUrl\":\"https:\/\/www.method-post.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/03\/agile-user-story-acceptance-criteria-definition-done-infographic-childs-drawing.jpg\",\"width\":1664,\"height\":928},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.method-post.com\/fr\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Analyse approfondie d’une histoire utilisateur : comprendre les crit\u00e8res d’acceptation et la d\u00e9finition de termin\u00e9\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.method-post.com\/fr\/#website\",\"url\":\"https:\/\/www.method-post.com\/fr\/\",\"name\":\"Method Post French | Your Daily Guide to AI & Software Solutions\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/www.method-post.com\/fr\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.method-post.com\/fr\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"fr-FR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.method-post.com\/fr\/#organization\",\"name\":\"Method Post French | Your Daily Guide to AI & Software Solutions\",\"url\":\"https:\/\/www.method-post.com\/fr\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\/\/www.method-post.com\/fr\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.method-post.com\/fr\/wp-content\/uploads\/sites\/6\/2025\/02\/logo-big.png\",\"contentUrl\":\"https:\/\/www.method-post.com\/fr\/wp-content\/uploads\/sites\/6\/2025\/02\/logo-big.png\",\"width\":117,\"height\":71,\"caption\":\"Method Post French | Your Daily Guide to AI & Software Solutions\"},\"image\":{\"@id\":\"https:\/\/www.method-post.com\/fr\/#\/schema\/logo\/image\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.method-post.com\/fr\/#\/schema\/person\/c45282b4509328baa27563996f83263e\",\"name\":\"vpadmin\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\/\/www.method-post.com\/fr\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g\",\"caption\":\"vpadmin\"},\"sameAs\":[\"https:\/\/www.method-post.com\"],\"url\":\"https:\/\/www.method-post.com\/fr\/author\/vpadmin\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Guide des crit\u00e8res d'acceptation des histoires utilisateur et du crit\u00e8re de fin de d\u00e9veloppement \ud83d\udcdd","description":"Apprenez \u00e0 r\u00e9diger des crit\u00e8res d'acceptation clairs et un crit\u00e8re de fin de d\u00e9veloppement pour les histoires utilisateur. Am\u00e9liorez la qualit\u00e9, r\u00e9duisez les reprises de travail et alignez les \u00e9quipes dans les projets agiles.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/","og_locale":"fr_FR","og_type":"article","og_title":"Guide des crit\u00e8res d'acceptation des histoires utilisateur et du crit\u00e8re de fin de d\u00e9veloppement \ud83d\udcdd","og_description":"Apprenez \u00e0 r\u00e9diger des crit\u00e8res d'acceptation clairs et un crit\u00e8re de fin de d\u00e9veloppement pour les histoires utilisateur. Am\u00e9liorez la qualit\u00e9, r\u00e9duisez les reprises de travail et alignez les \u00e9quipes dans les projets agiles.","og_url":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/","og_site_name":"Method Post French | Your Daily Guide to AI & Software Solutions","article_published_time":"2026-03-25T12:20:07+00:00","og_image":[{"width":1664,"height":928,"url":"https:\/\/www.method-post.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/03\/agile-user-story-acceptance-criteria-definition-done-infographic-childs-drawing.jpg","type":"image\/jpeg"}],"author":"vpadmin","twitter_card":"summary_large_image","twitter_misc":{"\u00c9crit par":"vpadmin","Dur\u00e9e de lecture estim\u00e9e":"14 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/#article","isPartOf":{"@id":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/"},"author":{"name":"vpadmin","@id":"https:\/\/www.method-post.com\/fr\/#\/schema\/person\/c45282b4509328baa27563996f83263e"},"headline":"Analyse approfondie d’une histoire utilisateur : comprendre les crit\u00e8res d’acceptation et la d\u00e9finition de termin\u00e9","datePublished":"2026-03-25T12:20:07+00:00","mainEntityOfPage":{"@id":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/"},"wordCount":2929,"publisher":{"@id":"https:\/\/www.method-post.com\/fr\/#organization"},"image":{"@id":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/#primaryimage"},"thumbnailUrl":"https:\/\/www.method-post.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/03\/agile-user-story-acceptance-criteria-definition-done-infographic-childs-drawing.jpg","keywords":["academic","user story"],"articleSection":["User Story"],"inLanguage":"fr-FR"},{"@type":"WebPage","@id":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/","url":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/","name":"Guide des crit\u00e8res d'acceptation des histoires utilisateur et du crit\u00e8re de fin de d\u00e9veloppement \ud83d\udcdd","isPartOf":{"@id":"https:\/\/www.method-post.com\/fr\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/#primaryimage"},"image":{"@id":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/#primaryimage"},"thumbnailUrl":"https:\/\/www.method-post.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/03\/agile-user-story-acceptance-criteria-definition-done-infographic-childs-drawing.jpg","datePublished":"2026-03-25T12:20:07+00:00","description":"Apprenez \u00e0 r\u00e9diger des crit\u00e8res d'acceptation clairs et un crit\u00e8re de fin de d\u00e9veloppement pour les histoires utilisateur. Am\u00e9liorez la qualit\u00e9, r\u00e9duisez les reprises de travail et alignez les \u00e9quipes dans les projets agiles.","breadcrumb":{"@id":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/"]}]},{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/#primaryimage","url":"https:\/\/www.method-post.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/03\/agile-user-story-acceptance-criteria-definition-done-infographic-childs-drawing.jpg","contentUrl":"https:\/\/www.method-post.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/03\/agile-user-story-acceptance-criteria-definition-done-infographic-childs-drawing.jpg","width":1664,"height":928},{"@type":"BreadcrumbList","@id":"https:\/\/www.method-post.com\/fr\/user-story-acceptance-criteria-definition-done\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.method-post.com\/fr\/"},{"@type":"ListItem","position":2,"name":"Analyse approfondie d’une histoire utilisateur : comprendre les crit\u00e8res d’acceptation et la d\u00e9finition de termin\u00e9"}]},{"@type":"WebSite","@id":"https:\/\/www.method-post.com\/fr\/#website","url":"https:\/\/www.method-post.com\/fr\/","name":"Method Post French | Your Daily Guide to AI & Software Solutions","description":"","publisher":{"@id":"https:\/\/www.method-post.com\/fr\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.method-post.com\/fr\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"fr-FR"},{"@type":"Organization","@id":"https:\/\/www.method-post.com\/fr\/#organization","name":"Method Post French | Your Daily Guide to AI & Software Solutions","url":"https:\/\/www.method-post.com\/fr\/","logo":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/www.method-post.com\/fr\/#\/schema\/logo\/image\/","url":"https:\/\/www.method-post.com\/fr\/wp-content\/uploads\/sites\/6\/2025\/02\/logo-big.png","contentUrl":"https:\/\/www.method-post.com\/fr\/wp-content\/uploads\/sites\/6\/2025\/02\/logo-big.png","width":117,"height":71,"caption":"Method Post French | Your Daily Guide to AI & Software Solutions"},"image":{"@id":"https:\/\/www.method-post.com\/fr\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/www.method-post.com\/fr\/#\/schema\/person\/c45282b4509328baa27563996f83263e","name":"vpadmin","image":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/www.method-post.com\/fr\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g","caption":"vpadmin"},"sameAs":["https:\/\/www.method-post.com"],"url":"https:\/\/www.method-post.com\/fr\/author\/vpadmin\/"}]}},"_links":{"self":[{"href":"https:\/\/www.method-post.com\/fr\/wp-json\/wp\/v2\/posts\/1240","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.method-post.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.method-post.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.method-post.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.method-post.com\/fr\/wp-json\/wp\/v2\/comments?post=1240"}],"version-history":[{"count":0,"href":"https:\/\/www.method-post.com\/fr\/wp-json\/wp\/v2\/posts\/1240\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.method-post.com\/fr\/wp-json\/wp\/v2\/media\/1241"}],"wp:attachment":[{"href":"https:\/\/www.method-post.com\/fr\/wp-json\/wp\/v2\/media?parent=1240"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.method-post.com\/fr\/wp-json\/wp\/v2\/categories?post=1240"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.method-post.com\/fr\/wp-json\/wp\/v2\/tags?post=1240"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}