{"id":4328,"date":"2026-04-06T19:27:14","date_gmt":"2026-04-06T19:27:14","guid":{"rendered":"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/"},"modified":"2026-04-06T19:27:14","modified_gmt":"2026-04-06T19:27:14","slug":"use-case-diagram-actors-boundaries-relationships","status":"publish","type":"post","link":"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/","title":{"rendered":"Analyse des composants : comprendre les acteurs, les limites et les relations dans les mod\u00e8les de cas d’utilisation"},"content":{"rendered":"

La mod\u00e9lisation du syst\u00e8me est une \u00e9tape cruciale dans le d\u00e9veloppement logiciel et l’ing\u00e9nierie des exigences. Elle offre une m\u00e9thode structur\u00e9e pour visualiser la mani\u00e8re dont les utilisateurs interagissent avec un syst\u00e8me et les fonctions que celui-ci ex\u00e9cute. Parmi les diff\u00e9rentes techniques de mod\u00e9lisation disponibles, le diagramme de cas d’utilisation se distingue par sa simplicit\u00e9 et son efficacit\u00e9 pour capturer les exigences fonctionnelles. Ce guide propose une analyse d\u00e9taill\u00e9e des trois composants fondamentaux d’un mod\u00e8le de cas d’utilisation : les acteurs, les limites et les relations. En comprenant ces \u00e9l\u00e9ments, les \u00e9quipes peuvent \u00e9tablir des sp\u00e9cifications plus claires qui alignent la mise en \u0153uvre technique sur les besoins des utilisateurs.<\/p>\n

Une mod\u00e9lisation efficace exige une pr\u00e9cision. L’ambigu\u00eft\u00e9 dans les diagrammes conduit souvent \u00e0 des malentendus pendant la phase de d\u00e9veloppement. Cet article explore les m\u00e9canismes de la mod\u00e9lisation des cas d’utilisation sans s’appuyer sur des outils sp\u00e9cifiques ou des plateformes propri\u00e9taires. L’accent reste sur l’application th\u00e9orique et pratique des concepts.<\/p>\n

\n
\"Kawaii<\/figure>\n<\/div>\n

\ud83d\udc65 D\u00e9finition des acteurs dans la mod\u00e9lisation du syst\u00e8me<\/h2>\n

Un acteur repr\u00e9sente un r\u00f4le jou\u00e9 par une entit\u00e9 qui interagit avec le syst\u00e8me. Il est essentiel de comprendre qu’un acteur n’est pas n\u00e9cessairement une personne. Bien que les utilisateurs humains soient les exemples les plus courants, les acteurs peuvent \u00eatre d’autres syst\u00e8mes, des p\u00e9riph\u00e9riques mat\u00e9riels ou m\u00eame des d\u00e9clencheurs bas\u00e9s sur le temps. Identifier les bons acteurs constitue la premi\u00e8re \u00e9tape pour d\u00e9finir le p\u00e9rim\u00e8tre d’interaction.<\/p>\n

Types d’acteurs<\/h3>\n

Les acteurs sont g\u00e9n\u00e9ralement cat\u00e9goris\u00e9s en fonction de leur relation avec le syst\u00e8me et de leur niveau d’interaction. Distinger entre ces types aide \u00e0 organiser le diagramme de mani\u00e8re logique.<\/p>\n

    \n
  • Acteurs principaux :<\/strong> Ce sont les utilisateurs ou les syst\u00e8mes qui initient l’interaction afin d’atteindre un objectif sp\u00e9cifique. Par exemple, dans un syst\u00e8me de vente en ligne, le client est un acteur principal car il d\u00e9clenche le processus d’achat.<\/li>\n
  • Acteurs secondaires :<\/strong> Ces acteurs aident le syst\u00e8me \u00e0 effectuer une fonction, mais ne d\u00e9clenchent pas le cas d’utilisation. Ils fournissent souvent des donn\u00e9es ou des services n\u00e9cessaires au flux principal. Dans l’exemple de la vente, un syst\u00e8me de passerelle de paiement agit comme un acteur secondaire.<\/li>\n
  • Acteurs internes :<\/strong> Parfois appel\u00e9s composants du syst\u00e8me, ces acteurs font partie de l’architecture plus large, mais agissent comme des entit\u00e9s externes par rapport \u00e0 la limite du syst\u00e8me sp\u00e9cifique en cours de mod\u00e9lisation.<\/li>\n
  • Acteurs externes :<\/strong> Ils existent enti\u00e8rement en dehors de la limite du syst\u00e8me. Ils peuvent \u00eatre des services tiers, des organismes r\u00e9gulateurs ou des op\u00e9rateurs humains.<\/li>\n<\/ul>\n

    Lors de la d\u00e9finition des acteurs, il est pr\u00e9f\u00e9rable de se concentrer sur le r\u00f4le<\/em> plut\u00f4t que sur l’individu sp\u00e9cifique. Au lieu d’\u00e9tiqueter un acteur comme \u00ab Jean Dupont \u00bb, il faut le d\u00e9signer comme \u00ab Administrateur \u00bb. Les r\u00f4les restent constants m\u00eame si le personnel change, ce qui garantit que le mod\u00e8le reste valide au fil du temps.<\/p>\n

    \ud83d\udce6 \u00c9tablir les limites du syst\u00e8me<\/h2>\n

    La limite du syst\u00e8me est une bo\u00eete rectangulaire qui englobe tous les cas d’utilisation appartenant au syst\u00e8me en cours d’examen. Elle distingue clairement ce que le syst\u00e8me fait de ce qui se trouve en dehors de son contr\u00f4le. Ce rep\u00e8re visuel est essentiel pour la gestion du p\u00e9rim\u00e8tre.<\/p>\n

    \u00c0 l’int\u00e9rieur vs. \u00c0 l’ext\u00e9rieur<\/h3>\n\n\n\n\n\n\n\n
    \u00c9l\u00e9ment<\/th>\nLocalisation par rapport \u00e0 la limite<\/th>\nResponsabilit\u00e9<\/th>\n<\/tr>\n<\/thead>\n
    Cas d’utilisation<\/td>\n\u00c0 l’int\u00e9rieur<\/td>\nFonctions effectu\u00e9es par le syst\u00e8me<\/td>\n<\/tr>\n
    Acteurs<\/td>\n\u00c0 l’ext\u00e9rieur<\/td>\nEntit\u00e9s interagissant avec le syst\u00e8me<\/td>\n<\/tr>\n
    Relations<\/td>\nCroisement<\/td>\nLignes de communication entre les acteurs et les cas d’utilisation<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    D\u00e9finir la fronti\u00e8re est souvent plus difficile que d’identifier les acteurs. Si la fronti\u00e8re est trop large, le mod\u00e8le devient encombr\u00e9 et perd de sa clart\u00e9. Si elle est trop \u00e9troite, des d\u00e9pendances n\u00e9cessaires peuvent \u00eatre exclues. Une bonne r\u00e8gle g\u00e9n\u00e9rale consiste \u00e0 n’inclure que les fonctions directement contr\u00f4l\u00e9es par les d\u00e9veloppeurs du syst\u00e8me ou les parties prenantes.<\/p>\n

    Contexte du syst\u00e8me<\/h3>\n

    La fronti\u00e8re d\u00e9finit \u00e9galement le contexte du syst\u00e8me. Tout ce qui se trouve \u00e0 l’ext\u00e9rieur de la bo\u00eete est consid\u00e9r\u00e9 comme une d\u00e9pendance externe ou un facteur environnemental. Cette distinction est essentielle lors de l’analyse des points de d\u00e9faillance. Si un acteur secondaire \u00e9choue, le syst\u00e8me \u00e9choue-t-il, ou peut-il g\u00e9rer l’erreur ? La fronti\u00e8re aide \u00e0 r\u00e9pondre \u00e0 ces questions en isolant la logique interne du syst\u00e8me de la variabilit\u00e9 externe.<\/p>\n

    \ud83d\udd17 Mod\u00e9lisation des relations<\/h2>\n

    Les relations relient les acteurs aux cas d’utilisation et les cas d’utilisation entre eux. Ces lignes d\u00e9finissent le flux d’information et de contr\u00f4le. Il existe quatre types standards de relations utilis\u00e9s dans la mod\u00e9lisation des cas d’utilisation. Comprendre les diff\u00e9rences entre eux permet d’\u00e9viter les erreurs logiques dans la conception.<\/p>\n

    1. Association<\/h3>\n

    Une association est une ligne pleine reliant un acteur \u00e0 un cas d’utilisation. Elle indique que l’acteur interagit avec le cas d’utilisation. Il s’agit de la relation la plus basique.<\/p>\n

      \n
    • Direction :<\/strong> Bien qu’elle soit souvent dessin\u00e9e sans fl\u00e8ches, une association peut sugg\u00e9rer une directionnalit\u00e9 en fonction de celui qui initie l’action.<\/li>\n
    • Multiplicit\u00e9 :<\/strong> Un acteur peut \u00eatre associ\u00e9 \u00e0 un ou plusieurs cas d’utilisation. De m\u00eame, un cas d’utilisation peut \u00eatre initi\u00e9 par un ou plusieurs acteurs.<\/li>\n
    • Utilisation :<\/strong> Utilisez-le pour cartographier les interactions principales. Si un utilisateur peut \u00ab Se connecter \u00bb, dessinez une ligne depuis l’acteur Utilisateur jusqu’au cas d’utilisation Se connecter.<\/li>\n<\/ul>\n

      2. G\u00e9n\u00e9ralisation (H\u00e9ritage)<\/h3>\n

      La g\u00e9n\u00e9ralisation repr\u00e9sente une relation \u00ab est-un \u00bb. Elle permet la r\u00e9utilisation du comportement. En mod\u00e9lisation des cas d’utilisation, elle est utilis\u00e9e lorsque un acteur ou un cas d’utilisation est une version sp\u00e9cialis\u00e9e d’un autre.<\/p>\n

        \n
      • G\u00e9n\u00e9ralisation de l’acteur :<\/strong> Si un \u00ab G\u00e9rant \u00bb est un type sp\u00e9cialis\u00e9 d’\u00ab Employ\u00e9 \u00bb, l’acteur G\u00e9rant peut h\u00e9riter des relations de l’acteur Employ\u00e9. Cela r\u00e9duit la redondance.<\/li>\n
      • G\u00e9n\u00e9ralisation du cas d’utilisation :<\/strong> Si \u00ab Payer par carte de cr\u00e9dit \u00bb est une mani\u00e8re sp\u00e9cifique de \u00ab Faire un paiement \u00bb, le cas d’utilisation sp\u00e9cifique h\u00e9rite du comportement du cas g\u00e9n\u00e9ral. Cela est utile lorsque plusieurs variantes d’un processus existent.<\/li>\n<\/ul>\n

        3. Inclure<\/h3>\n

        La relation d’inclusion est utilis\u00e9e pour modulariser le comportement. Elle indique qu’un cas d’utilisation int\u00e8gre le comportement d’un autre cas d’utilisation comme une \u00e9tape obligatoire. Le cas d’utilisation inclus est essentiel pour que le cas d’utilisation de base puisse \u00eatre compl\u00e9t\u00e9.<\/p>\n

          \n
        • Mot-cl\u00e9 :<\/strong> Habituellement indiqu\u00e9 par le mot-cl\u00e9 <<inclure>>.<\/li>\n
        • D\u00e9clencheur :<\/strong> Le cas d’utilisation de base appelle toujours le cas d’utilisation inclus.<\/li>\n
        • Exemple :<\/strong> Le cas d’utilisation \u00ab Passer une commande \u00bb pourrait inclure \u00ab Valider le stock \u00bb. La commande ne peut pas \u00eatre pass\u00e9e sans v\u00e9rifier le stock. Par cons\u00e9quent, la relation est obligatoire.<\/li>\n
        • Avantage :<\/strong> Il favorise la r\u00e9utilisabilit\u00e9. Si \u00ab Valider le stock \u00bb est n\u00e9cessaire pour trois cas d’utilisation diff\u00e9rents, il est d\u00e9fini une seule fois et inclus dans les trois.<\/li>\n<\/ul>\n

          4. \u00c9tendre<\/h3>\n

          La relation d’extension repr\u00e9sente un comportement facultatif. Elle indique qu’un cas d’utilisation de base peut \u00eatre \u00e9tendu par un autre cas d’utilisation sous des conditions sp\u00e9cifiques. Contrairement \u00e0 include, le comportement \u00e9tendu n’est pas requis pour que le cas d’utilisation de base fonctionne.<\/p>\n

            \n
          • Mot-cl\u00e9 :<\/strong> Habituellement indiqu\u00e9 par le mot-cl\u00e9 <<extend>>.<\/li>\n
          • D\u00e9clencheur :<\/strong> L’extension n’a lieu que si une condition sp\u00e9cifique est remplie.<\/li>\n
          • Exemple :<\/strong> Le cas d’utilisation \u00ab Passer une commande \u00bb pourrait \u00eatre \u00e9tendu par \u00ab Appliquer une r\u00e9duction \u00bb. La r\u00e9duction n’est appliqu\u00e9e que si l’utilisateur poss\u00e8de un code promo. La commande peut tout de m\u00eame \u00eatre pass\u00e9e sans la r\u00e9duction.<\/li>\n
          • Direction :<\/strong> Notez que la fl\u00e8che pointe du cas d’utilisation \u00e9tendant vers le cas d’utilisation de base, ce qui est l’inverse de la relation include.<\/li>\n<\/ul>\n

            \ud83d\udcca R\u00e9sum\u00e9 des types de relations<\/h2>\n\n\n\n\n\n\n\n\n
            Relation<\/th>\nDirection de la fl\u00e8che<\/th>\nCondition<\/th>\nCas d’utilisation<\/th>\n<\/tr>\n<\/thead>\n
            Association<\/td>\nAucune \/ Bidirectionnelle<\/td>\nInteraction<\/td>\nL’acteur d\u00e9clenche l’action<\/td>\n<\/tr>\n
            G\u00e9n\u00e9ralisation<\/td>\nDe la base vers la d\u00e9riv\u00e9e<\/td>\nH\u00e9ritage<\/td>\nSp\u00e9cialisation du comportement<\/td>\n<\/tr>\n
            Inclure<\/td>\nDe la base vers inclus<\/td>\nObligatoire<\/td>\nSous-fonction obligatoire<\/td>\n<\/tr>\n
            \u00c9tendre<\/td>\nExtension \u00e0 la base<\/td>\nFacultatif<\/td>\nSous-fonction conditionnelle<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

            \u2705 Meilleures pratiques pour la clart\u00e9<\/h2>\n

            Cr\u00e9er un mod\u00e8le de cas d’utilisation ne consiste pas seulement \u00e0 dessiner des bo\u00eetes et des lignes ; c’est une question de communication. Le diagramme doit \u00eatre compris par les d\u00e9veloppeurs, les parties prenantes et les testeurs. Respecter les meilleures pratiques garantit que le mod\u00e8le reste une r\u00e9f\u00e9rence utile tout au long du cycle de vie du projet.<\/p>\n

              \n
            • Gardez les cas d’utilisation atomiques :<\/strong> Chaque cas d’utilisation doit repr\u00e9senter une unit\u00e9 unique et compl\u00e8te de fonctionnalit\u00e9 du point de vue de l’acteur. \u00c9vitez de combiner des actions non li\u00e9es dans un seul cas d’utilisation. Si un cas d’utilisation devient trop complexe, divisez-le.<\/li>\n
            • Utilisez une nomenclature orient\u00e9e vers l’action :<\/strong> Nommez les cas d’utilisation sous forme de phrases verbe-nom. Par exemple, \u00ab Traiter le remboursement \u00bb est pr\u00e9f\u00e9rable \u00e0 \u00ab Remboursement \u00bb. Cela clarifie l’action qui est effectu\u00e9e.<\/li>\n
            • Limitez le nombre d’acteurs :<\/strong> Un diagramme avec trop d’acteurs devient illisible. Si plusieurs acteurs sont similaires, envisagez d’utiliser une relation de g\u00e9n\u00e9ralisation pour les regrouper.<\/li>\n
            • Concentrez-vous sur les objectifs :<\/strong> Les cas d’utilisation d\u00e9crivent comment un acteur atteint un objectif. \u00c9vitez de mod\u00e9liser les processus internes du syst\u00e8me que l’acteur ne peut pas voir. Restez sur la vue externe du syst\u00e8me.<\/li>\n
            • It\u00e9rez r\u00e9guli\u00e8rement :<\/strong> Les mod\u00e8les de cas d’utilisation sont rarement parfaits d\u00e8s le premier jet. Au fur et \u00e0 mesure que les exigences \u00e9voluent, mettez \u00e0 jour le diagramme. Il doit \u00eatre un document vivant.<\/li>\n<\/ul>\n

              \u26a0\ufe0f Pi\u00e8ges courants \u00e0 \u00e9viter<\/h2>\n

              M\u00eame les mod\u00e9lisateurs exp\u00e9riment\u00e9s peuvent tomber dans des pi\u00e8ges qui r\u00e9duisent la valeur du diagramme. \u00catre conscient des erreurs courantes aide \u00e0 maintenir la qualit\u00e9.<\/p>\n

                \n
              • Confondre Include et Extend :<\/strong> C’est l’erreur la plus fr\u00e9quente. Souvenez-vous : Include est obligatoire (doit se produire), Extend est facultatif (peut se produire). Si vous \u00eates incertain, demandez-vous si le cas d’utilisation de base peut \u00eatre accompli sans le second cas d’utilisation.<\/li>\n
              • Placer les acteurs \u00e0 l’int\u00e9rieur de la fronti\u00e8re :<\/strong> Les acteurs doivent toujours exister \u00e0 l’ext\u00e9rieur de la bo\u00eete du syst\u00e8me. Si un acteur est \u00e0 l’int\u00e9rieur, il est probablement un composant du syst\u00e8me, et non une entit\u00e9 externe.<\/li>\n
              • Fonctionnalit\u00e9s chevauchantes :<\/strong> Si deux cas d’utilisation font exactement la m\u00eame chose, fusionnez-les. La redondance confond le lecteur et complique la maintenance.<\/li>\n
              • Ignorer les exigences non fonctionnelles :<\/strong> Bien que les diagrammes de cas d’utilisation se concentrent sur la fonctionnalit\u00e9, gardez \u00e0 l’esprit que les contraintes (comme les performances ou la s\u00e9curit\u00e9) influencent souvent la conception. Documentez-les s\u00e9par\u00e9ment si elles ne font pas partie du flux.<\/li>\n
              • Descriptions vagues :<\/strong> Ne comptez pas uniquement sur le diagramme. Les cas d’utilisation doivent \u00eatre accompagn\u00e9s de descriptions textuelles qui d\u00e9taillent les pr\u00e9conditions, les postconditions et le d\u00e9roulement principal des \u00e9v\u00e9nements.<\/li>\n<\/ul>\n

                \ud83d\udcdd Consid\u00e9rations finales<\/h2>\n

                La valeur d’un mod\u00e8le de cas d’utilisation r\u00e9side dans sa capacit\u00e9 \u00e0 combler le foss\u00e9 entre les besoins m\u00e9tiers et la mise en \u0153uvre technique. Il sert de contrat entre les parties prenantes et l’\u00e9quipe de d\u00e9veloppement. En d\u00e9finissant soigneusement les acteurs, les fronti\u00e8res et les relations, les \u00e9quipes r\u00e9duisent le risque de malentendus sur les exigences.<\/p>\n

                Souvenez-vous que la mod\u00e9lisation est un outil de r\u00e9flexion, et non seulement un outil de documentation. Le processus de dessin du diagramme r\u00e9v\u00e8le souvent des lacunes logiques ou des exigences manquantes avant m\u00eame qu’un seul code ne soit \u00e9crit. Cette approche proactive permet d’\u00e9conomiser du temps et des ressources \u00e0 long terme.<\/p>\n

                En appliquant ces concepts, concentrez-vous sur la clart\u00e9 et la coh\u00e9rence. Un mod\u00e8le Use Case bien structur\u00e9 est la preuve d’un syst\u00e8me bien compris. Il facilite la communication, guide les efforts de test et assure que le produit final apporte la valeur attendue \u00e0 ses utilisateurs.<\/p>\n

                Affinez continuellement vos diagrammes en fonction des retours. Le d\u00e9veloppement logiciel est it\u00e9ratif, et votre processus de mod\u00e9lisation devrait l’\u00eatre \u00e9galement. En maintenant des standards \u00e9lev\u00e9s dans vos diagrammes, vous contribuez \u00e0 un flux de travail de g\u00e9nie logiciel robuste et fiable.<\/p>\n","protected":false},"excerpt":{"rendered":"

                La mod\u00e9lisation du syst\u00e8me est une \u00e9tape cruciale dans le d\u00e9veloppement logiciel et l’ing\u00e9nierie des exigences. Elle offre une m\u00e9thode structur\u00e9e pour visualiser la mani\u00e8re dont les utilisateurs interagissent avec un syst\u00e8me et les fonctions que celui-ci ex\u00e9cute. Parmi les diff\u00e9rentes techniques de mod\u00e9lisation disponibles, le diagramme de cas d’utilisation se distingue par sa simplicit\u00e9 et son efficacit\u00e9 pour capturer les exigences fonctionnelles. Ce guide propose une analyse d\u00e9taill\u00e9e des trois composants fondamentaux d’un mod\u00e8le de cas d’utilisation : les acteurs, les limites et les relations. En comprenant ces \u00e9l\u00e9ments, les \u00e9quipes peuvent \u00e9tablir des sp\u00e9cifications plus claires qui alignent la mise en \u0153uvre technique sur les besoins des utilisateurs. Une mod\u00e9lisation efficace exige une pr\u00e9cision. L’ambigu\u00eft\u00e9 dans les diagrammes conduit souvent \u00e0 des malentendus pendant la phase de d\u00e9veloppement. Cet article explore les m\u00e9canismes de la mod\u00e9lisation des cas d’utilisation sans s’appuyer sur des outils sp\u00e9cifiques ou des plateformes propri\u00e9taires. L’accent reste sur l’application th\u00e9orique et pratique des concepts. \ud83d\udc65 D\u00e9finition des acteurs dans la mod\u00e9lisation du syst\u00e8me Un acteur repr\u00e9sente un r\u00f4le jou\u00e9 par une entit\u00e9 qui interagit avec le syst\u00e8me. Il est essentiel de comprendre qu’un acteur n’est pas n\u00e9cessairement une personne. Bien que les utilisateurs humains soient les exemples les plus courants, les acteurs peuvent \u00eatre d’autres syst\u00e8mes, des p\u00e9riph\u00e9riques mat\u00e9riels ou m\u00eame des d\u00e9clencheurs bas\u00e9s sur le temps. Identifier les bons acteurs constitue la premi\u00e8re \u00e9tape pour d\u00e9finir le p\u00e9rim\u00e8tre d’interaction. Types d’acteurs Les acteurs sont g\u00e9n\u00e9ralement cat\u00e9goris\u00e9s en fonction de leur relation avec le syst\u00e8me et de leur niveau d’interaction. Distinger entre ces types aide \u00e0 organiser le diagramme de mani\u00e8re logique. Acteurs principaux : Ce sont les utilisateurs ou les syst\u00e8mes qui initient l’interaction afin d’atteindre un objectif sp\u00e9cifique. Par exemple, dans un syst\u00e8me de vente en ligne, le client est un acteur principal car il d\u00e9clenche le processus d’achat. Acteurs secondaires : Ces acteurs aident le syst\u00e8me \u00e0 effectuer une fonction, mais ne d\u00e9clenchent pas le cas d’utilisation. Ils fournissent souvent des donn\u00e9es ou des services n\u00e9cessaires au flux principal. Dans l’exemple de la vente, un syst\u00e8me de passerelle de paiement agit comme un acteur secondaire. Acteurs internes : Parfois appel\u00e9s composants du syst\u00e8me, ces acteurs font partie de l’architecture plus large, mais agissent comme des entit\u00e9s externes par rapport \u00e0 la limite du syst\u00e8me sp\u00e9cifique en cours de mod\u00e9lisation. Acteurs externes : Ils existent enti\u00e8rement en dehors de la limite du syst\u00e8me. Ils peuvent \u00eatre des services tiers, des organismes r\u00e9gulateurs ou des op\u00e9rateurs humains. Lors de la d\u00e9finition des acteurs, il est pr\u00e9f\u00e9rable de se concentrer sur le r\u00f4le plut\u00f4t que sur l’individu sp\u00e9cifique. Au lieu d’\u00e9tiqueter un acteur comme \u00ab Jean Dupont \u00bb, il faut le d\u00e9signer comme \u00ab Administrateur \u00bb. Les r\u00f4les restent constants m\u00eame si le personnel change, ce qui garantit que le mod\u00e8le reste valide au fil du temps. \ud83d\udce6 \u00c9tablir les limites du syst\u00e8me La limite du syst\u00e8me est une bo\u00eete rectangulaire qui englobe tous les cas d’utilisation appartenant au syst\u00e8me en cours d’examen. Elle distingue clairement ce que le syst\u00e8me fait de ce qui se trouve en dehors de son contr\u00f4le. Ce rep\u00e8re visuel est essentiel pour la gestion du p\u00e9rim\u00e8tre. \u00c0 l’int\u00e9rieur vs. \u00c0 l’ext\u00e9rieur \u00c9l\u00e9ment Localisation par rapport \u00e0 la limite Responsabilit\u00e9 Cas d’utilisation \u00c0 l’int\u00e9rieur Fonctions effectu\u00e9es par le syst\u00e8me Acteurs \u00c0 l’ext\u00e9rieur Entit\u00e9s interagissant avec le syst\u00e8me Relations Croisement Lignes de communication entre les acteurs et les cas d’utilisation D\u00e9finir la fronti\u00e8re est souvent plus difficile que d’identifier les acteurs. Si la fronti\u00e8re est trop large, le mod\u00e8le devient encombr\u00e9 et perd de sa clart\u00e9. Si elle est trop \u00e9troite, des d\u00e9pendances n\u00e9cessaires peuvent \u00eatre exclues. Une bonne r\u00e8gle g\u00e9n\u00e9rale consiste \u00e0 n’inclure que les fonctions directement contr\u00f4l\u00e9es par les d\u00e9veloppeurs du syst\u00e8me ou les parties prenantes. Contexte du syst\u00e8me La fronti\u00e8re d\u00e9finit \u00e9galement le contexte du syst\u00e8me. Tout ce qui se trouve \u00e0 l’ext\u00e9rieur de la bo\u00eete est consid\u00e9r\u00e9 comme une d\u00e9pendance externe ou un facteur environnemental. Cette distinction est essentielle lors de l’analyse des points de d\u00e9faillance. Si un acteur secondaire \u00e9choue, le syst\u00e8me \u00e9choue-t-il, ou peut-il g\u00e9rer l’erreur ? La fronti\u00e8re aide \u00e0 r\u00e9pondre \u00e0 ces questions en isolant la logique interne du syst\u00e8me de la variabilit\u00e9 externe. \ud83d\udd17 Mod\u00e9lisation des relations Les relations relient les acteurs aux cas d’utilisation et les cas d’utilisation entre eux. Ces lignes d\u00e9finissent le flux d’information et de contr\u00f4le. Il existe quatre types standards de relations utilis\u00e9s dans la mod\u00e9lisation des cas d’utilisation. Comprendre les diff\u00e9rences entre eux permet d’\u00e9viter les erreurs logiques dans la conception. 1. Association Une association est une ligne pleine reliant un acteur \u00e0 un cas d’utilisation. Elle indique que l’acteur interagit avec le cas d’utilisation. Il s’agit de la relation la plus basique. Direction : Bien qu’elle soit souvent dessin\u00e9e sans fl\u00e8ches, une association peut sugg\u00e9rer une directionnalit\u00e9 en fonction de celui qui initie l’action. Multiplicit\u00e9 : Un acteur peut \u00eatre associ\u00e9 \u00e0 un ou plusieurs cas d’utilisation. De m\u00eame, un cas d’utilisation peut \u00eatre initi\u00e9 par un ou plusieurs acteurs. Utilisation : Utilisez-le pour cartographier les interactions principales. Si un utilisateur peut \u00ab Se connecter \u00bb, dessinez une ligne depuis l’acteur Utilisateur jusqu’au cas d’utilisation Se connecter. 2. G\u00e9n\u00e9ralisation (H\u00e9ritage) La g\u00e9n\u00e9ralisation repr\u00e9sente une relation \u00ab est-un \u00bb. Elle permet la r\u00e9utilisation du comportement. En mod\u00e9lisation des cas d’utilisation, elle est utilis\u00e9e lorsque un acteur ou un cas d’utilisation est une version sp\u00e9cialis\u00e9e d’un autre. G\u00e9n\u00e9ralisation de l’acteur : Si un \u00ab G\u00e9rant \u00bb est un type sp\u00e9cialis\u00e9 d’\u00ab Employ\u00e9 \u00bb, l’acteur G\u00e9rant peut h\u00e9riter des relations de l’acteur Employ\u00e9. Cela r\u00e9duit la redondance. G\u00e9n\u00e9ralisation du cas d’utilisation : Si \u00ab Payer par carte de cr\u00e9dit \u00bb est une mani\u00e8re sp\u00e9cifique de \u00ab Faire un paiement \u00bb, le cas d’utilisation sp\u00e9cifique h\u00e9rite du comportement du cas g\u00e9n\u00e9ral. Cela est utile lorsque plusieurs variantes d’un processus existent. 3. Inclure La relation d’inclusion est utilis\u00e9e pour modulariser le comportement. Elle indique qu’un cas d’utilisation int\u00e8gre le comportement d’un autre cas d’utilisation comme une \u00e9tape obligatoire. Le<\/p>\n","protected":false},"author":1,"featured_media":4329,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[56],"tags":[77,87],"class_list":["post-4328","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uml","tag-academic","tag-use-case-diagram"],"yoast_head":"\nGuide des diagrammes Use Case : Acteurs, Fronti\u00e8res et Relations<\/title>\n<meta name=\"description\" content=\"Plongez en profondeur dans la mod\u00e9lisation Use Case. Apprenez \u00e0 d\u00e9finir les acteurs, les fronti\u00e8res du syst\u00e8me et les types de relations pour une analyse efficace des exigences logicielles.\" \/>\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.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Guide des diagrammes Use Case : Acteurs, Fronti\u00e8res et Relations\" \/>\n<meta property=\"og:description\" content=\"Plongez en profondeur dans la mod\u00e9lisation Use Case. Apprenez \u00e0 d\u00e9finir les acteurs, les fronti\u00e8res du syst\u00e8me et les types de relations pour une analyse efficace des exigences logicielles.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/\" \/>\n<meta property=\"og:site_name\" content=\"Diagrams AI French\" \/>\n<meta property=\"article:published_time\" content=\"2026-04-06T19:27:14+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.diagrams-ai.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/04\/kawaii-use-case-model-infographic-actors-boundaries-relationships.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=\"11 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/use-case-diagram-actors-boundaries-relationships\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/use-case-diagram-actors-boundaries-relationships\\\/\"},\"author\":{\"name\":\"vpadmin\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/#\\\/schema\\\/person\\\/ecc36153eaeb4aeaf895589c93d5de12\"},\"headline\":\"Analyse des composants : comprendre les acteurs, les limites et les relations dans les mod\u00e8les de cas d’utilisation\",\"datePublished\":\"2026-04-06T19:27:14+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/use-case-diagram-actors-boundaries-relationships\\\/\"},\"wordCount\":2239,\"image\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/use-case-diagram-actors-boundaries-relationships\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/wp-content\\\/uploads\\\/sites\\\/6\\\/2026\\\/04\\\/kawaii-use-case-model-infographic-actors-boundaries-relationships.jpg\",\"keywords\":[\"academic\",\"use case diagram\"],\"articleSection\":[\"UML\"],\"inLanguage\":\"fr-FR\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/use-case-diagram-actors-boundaries-relationships\\\/\",\"url\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/use-case-diagram-actors-boundaries-relationships\\\/\",\"name\":\"Guide des diagrammes Use Case : Acteurs, Fronti\u00e8res et Relations\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/use-case-diagram-actors-boundaries-relationships\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/use-case-diagram-actors-boundaries-relationships\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/wp-content\\\/uploads\\\/sites\\\/6\\\/2026\\\/04\\\/kawaii-use-case-model-infographic-actors-boundaries-relationships.jpg\",\"datePublished\":\"2026-04-06T19:27:14+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/#\\\/schema\\\/person\\\/ecc36153eaeb4aeaf895589c93d5de12\"},\"description\":\"Plongez en profondeur dans la mod\u00e9lisation Use Case. Apprenez \u00e0 d\u00e9finir les acteurs, les fronti\u00e8res du syst\u00e8me et les types de relations pour une analyse efficace des exigences logicielles.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/use-case-diagram-actors-boundaries-relationships\\\/#breadcrumb\"},\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/use-case-diagram-actors-boundaries-relationships\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/use-case-diagram-actors-boundaries-relationships\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/wp-content\\\/uploads\\\/sites\\\/6\\\/2026\\\/04\\\/kawaii-use-case-model-infographic-actors-boundaries-relationships.jpg\",\"contentUrl\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/wp-content\\\/uploads\\\/sites\\\/6\\\/2026\\\/04\\\/kawaii-use-case-model-infographic-actors-boundaries-relationships.jpg\",\"width\":1664,\"height\":928},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/use-case-diagram-actors-boundaries-relationships\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Analyse des composants : comprendre les acteurs, les limites et les relations dans les mod\u00e8les de cas d’utilisation\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/#website\",\"url\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/\",\"name\":\"Diagrams AI French\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"fr-FR\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/#\\\/schema\\\/person\\\/ecc36153eaeb4aeaf895589c93d5de12\",\"name\":\"vpadmin\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g\",\"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.diagrams-ai.com\"],\"url\":\"https:\\\/\\\/www.diagrams-ai.com\\\/fr\\\/author\\\/vpadmin\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Guide des diagrammes Use Case : Acteurs, Fronti\u00e8res et Relations","description":"Plongez en profondeur dans la mod\u00e9lisation Use Case. Apprenez \u00e0 d\u00e9finir les acteurs, les fronti\u00e8res du syst\u00e8me et les types de relations pour une analyse efficace des exigences logicielles.","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.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/","og_locale":"fr_FR","og_type":"article","og_title":"Guide des diagrammes Use Case : Acteurs, Fronti\u00e8res et Relations","og_description":"Plongez en profondeur dans la mod\u00e9lisation Use Case. Apprenez \u00e0 d\u00e9finir les acteurs, les fronti\u00e8res du syst\u00e8me et les types de relations pour une analyse efficace des exigences logicielles.","og_url":"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/","og_site_name":"Diagrams AI French","article_published_time":"2026-04-06T19:27:14+00:00","og_image":[{"width":1664,"height":928,"url":"https:\/\/www.diagrams-ai.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/04\/kawaii-use-case-model-infographic-actors-boundaries-relationships.jpg","type":"image\/jpeg"}],"author":"vpadmin","twitter_card":"summary_large_image","twitter_misc":{"\u00c9crit par":"vpadmin","Dur\u00e9e de lecture estim\u00e9e":"11 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/#article","isPartOf":{"@id":"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/"},"author":{"name":"vpadmin","@id":"https:\/\/www.diagrams-ai.com\/fr\/#\/schema\/person\/ecc36153eaeb4aeaf895589c93d5de12"},"headline":"Analyse des composants : comprendre les acteurs, les limites et les relations dans les mod\u00e8les de cas d’utilisation","datePublished":"2026-04-06T19:27:14+00:00","mainEntityOfPage":{"@id":"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/"},"wordCount":2239,"image":{"@id":"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/#primaryimage"},"thumbnailUrl":"https:\/\/www.diagrams-ai.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/04\/kawaii-use-case-model-infographic-actors-boundaries-relationships.jpg","keywords":["academic","use case diagram"],"articleSection":["UML"],"inLanguage":"fr-FR"},{"@type":"WebPage","@id":"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/","url":"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/","name":"Guide des diagrammes Use Case : Acteurs, Fronti\u00e8res et Relations","isPartOf":{"@id":"https:\/\/www.diagrams-ai.com\/fr\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/#primaryimage"},"image":{"@id":"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/#primaryimage"},"thumbnailUrl":"https:\/\/www.diagrams-ai.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/04\/kawaii-use-case-model-infographic-actors-boundaries-relationships.jpg","datePublished":"2026-04-06T19:27:14+00:00","author":{"@id":"https:\/\/www.diagrams-ai.com\/fr\/#\/schema\/person\/ecc36153eaeb4aeaf895589c93d5de12"},"description":"Plongez en profondeur dans la mod\u00e9lisation Use Case. Apprenez \u00e0 d\u00e9finir les acteurs, les fronti\u00e8res du syst\u00e8me et les types de relations pour une analyse efficace des exigences logicielles.","breadcrumb":{"@id":"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/"]}]},{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/#primaryimage","url":"https:\/\/www.diagrams-ai.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/04\/kawaii-use-case-model-infographic-actors-boundaries-relationships.jpg","contentUrl":"https:\/\/www.diagrams-ai.com\/fr\/wp-content\/uploads\/sites\/6\/2026\/04\/kawaii-use-case-model-infographic-actors-boundaries-relationships.jpg","width":1664,"height":928},{"@type":"BreadcrumbList","@id":"https:\/\/www.diagrams-ai.com\/fr\/use-case-diagram-actors-boundaries-relationships\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.diagrams-ai.com\/fr\/"},{"@type":"ListItem","position":2,"name":"Analyse des composants : comprendre les acteurs, les limites et les relations dans les mod\u00e8les de cas d’utilisation"}]},{"@type":"WebSite","@id":"https:\/\/www.diagrams-ai.com\/fr\/#website","url":"https:\/\/www.diagrams-ai.com\/fr\/","name":"Diagrams AI French","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.diagrams-ai.com\/fr\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"fr-FR"},{"@type":"Person","@id":"https:\/\/www.diagrams-ai.com\/fr\/#\/schema\/person\/ecc36153eaeb4aeaf895589c93d5de12","name":"vpadmin","image":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/secure.gravatar.com\/avatar\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g","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.diagrams-ai.com"],"url":"https:\/\/www.diagrams-ai.com\/fr\/author\/vpadmin\/"}]}},"_links":{"self":[{"href":"https:\/\/www.diagrams-ai.com\/fr\/wp-json\/wp\/v2\/posts\/4328","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.diagrams-ai.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.diagrams-ai.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/fr\/wp-json\/wp\/v2\/comments?post=4328"}],"version-history":[{"count":0,"href":"https:\/\/www.diagrams-ai.com\/fr\/wp-json\/wp\/v2\/posts\/4328\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/fr\/wp-json\/wp\/v2\/media\/4329"}],"wp:attachment":[{"href":"https:\/\/www.diagrams-ai.com\/fr\/wp-json\/wp\/v2\/media?parent=4328"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/fr\/wp-json\/wp\/v2\/categories?post=4328"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/fr\/wp-json\/wp\/v2\/tags?post=4328"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}