{"id":1254,"date":"2026-03-25T17:01:09","date_gmt":"2026-03-25T16:01:09","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/nis2-risk-management-for-software-delivery-2\/"},"modified":"2026-03-26T00:11:04","modified_gmt":"2026-03-25T23:11:04","slug":"nis2-risk-management-for-software-delivery","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/nis2-risk-management-for-software-delivery\/","title":{"rendered":"Gestion des risques NIS2 pour la livraison logicielle"},"content":{"rendered":"<h2>Introduction : La gestion des risques comme obligation l\u00e9gale sous NIS2<\/h2>\n<p>L&rsquo;article 21(1) de la directive NIS2 (Directive 2022\/2555) exige que les entit\u00e9s essentielles et importantes prennent des <strong>mesures techniques, op\u00e9rationnelles et organisationnelles appropri\u00e9es et proportionn\u00e9es<\/strong> pour g\u00e9rer les risques pesant sur la s\u00e9curit\u00e9 des r\u00e9seaux et des syst\u00e8mes d&rsquo;information. Il ne s&rsquo;agit pas d&rsquo;une suggestion \u2014 c&rsquo;est une obligation contraignante assortie d&rsquo;une supervision r\u00e9glementaire.<\/p>\n<p>Pour les organisations qui d\u00e9veloppent et livrent des logiciels, cette obligation s&rsquo;\u00e9tend directement au pipeline de livraison logicielle. Les environnements CI\/CD sont des r\u00e9seaux et syst\u00e8mes d&rsquo;information au sens de NIS2. Ils traitent, stockent et transmettent du code, des identifiants, des configurations et des artefacts de d\u00e9ploiement qui affectent directement la posture de s\u00e9curit\u00e9 des services fournis par votre organisation.<\/p>\n<p>Cet article fournit aux responsables conformit\u00e9 et aux auditeurs un cadre structur\u00e9 pour comprendre comment la gestion des risques NIS2 s&rsquo;applique \u00e0 la livraison logicielle, quels contr\u00f4les doivent \u00eatre en place et quelles preuves rechercher lors des \u00e9valuations.<\/p>\n<h2>Comment la gestion des risques NIS2 s&rsquo;applique \u00e0 la livraison logicielle<\/h2>\n<p>De nombreuses organisations traitent les pipelines de livraison logicielle comme des pr\u00e9occupations purement techniques. Sous NIS2, cela est insuffisant. La directive exige une <strong>approche tous risques<\/strong> de la gestion des risques, ce qui signifie que chaque syst\u00e8me susceptible d&rsquo;affecter la s\u00e9curit\u00e9 de vos services doit \u00eatre couvert \u2014 y compris les syst\u00e8mes qui construisent et d\u00e9ploient vos logiciels.<\/p>\n<p>Les processus de livraison logicielle pr\u00e9sentent des caract\u00e9ristiques de risque sp\u00e9cifiques qui n\u00e9cessitent une attention d\u00e9di\u00e9e :<\/p>\n<ul>\n<li><strong>Concentration \u00e9lev\u00e9e de privil\u00e8ges :<\/strong> Les pipelines d\u00e9tiennent g\u00e9n\u00e9ralement des identifiants avec un acc\u00e8s de niveau production, ce qui en fait des cibles de haute valeur.<\/li>\n<li><strong>Cha\u00eenes d&rsquo;approvisionnement complexes :<\/strong> La livraison moderne d\u00e9pend de d\u00e9pendances tierces, d&rsquo;images de conteneurs et de services externes \u2014 chacun introduisant un risque de cha\u00eene d&rsquo;approvisionnement.<\/li>\n<li><strong>V\u00e9locit\u00e9 de changement rapide :<\/strong> Les d\u00e9ploiements fr\u00e9quents augmentent la fen\u00eatre de surface d&rsquo;attaque et la probabilit\u00e9 de mauvaise configuration.<\/li>\n<li><strong>Port\u00e9e inter-environnements :<\/strong> Un pipeline compromis peut affecter simultan\u00e9ment le d\u00e9veloppement, le staging et la production.<\/li>\n<\/ul>\n<p>Les responsables conformit\u00e9 doivent s&rsquo;assurer que les \u00e9valuations des risques incluent explicitement les syst\u00e8mes de livraison logicielle dans leur p\u00e9rim\u00e8tre, et pas seulement les applications que ces syst\u00e8mes produisent.<\/p>\n<h2>Cadre d&rsquo;\u00e9valuation des risques pour les environnements CI\/CD<\/h2>\n<p>Une \u00e9valuation des risques conforme pour la livraison logicielle doit suivre une m\u00e9thodologie structur\u00e9e en trois phases : identification, analyse et traitement.<\/p>\n<h3>Phase 1 : Identification des risques<\/h3>\n<p>Cataloguer tous les actifs au sein de l&rsquo;environnement de livraison logicielle, y compris l&rsquo;infrastructure des pipelines, les d\u00e9p\u00f4ts de code source, les stockages d&rsquo;artefacts, les syst\u00e8mes de gestion des secrets, les cibles de d\u00e9ploiement et les int\u00e9grations tierces. Pour chaque actif, identifier les menaces potentielles et les vuln\u00e9rabilit\u00e9s sp\u00e9cifiques \u00e0 cette classe d&rsquo;actifs.<\/p>\n<h3>Phase 2 : Analyse des risques<\/h3>\n<p>Pour chaque risque identifi\u00e9, \u00e9valuer la <strong>probabilit\u00e9<\/strong> d&rsquo;occurrence et l&rsquo;<strong>impact<\/strong> en cas de r\u00e9alisation. Utiliser une m\u00e9thodologie de notation coh\u00e9rente (par exemple, des \u00e9chelles qualitatives Faible\/Moyen\/\u00c9lev\u00e9\/Critique) et documenter la justification de chaque notation. Consid\u00e9rer \u00e0 la fois les facteurs techniques (par exemple, exposition, exploitabilit\u00e9) et les facteurs m\u00e9tier (par exemple, cons\u00e9quences r\u00e9glementaires, interruption de service).<\/p>\n<h3>Phase 3 : Traitement des risques<\/h3>\n<p>Pour chaque risque au-dessus du seuil d&rsquo;app\u00e9tit au risque de l&rsquo;organisation, s\u00e9lectionner une option de traitement : <strong>att\u00e9nuer<\/strong> (appliquer des contr\u00f4les), <strong>transf\u00e9rer<\/strong> (par exemple, assurance ou allocation contractuelle), <strong>\u00e9viter<\/strong> (\u00e9liminer l&rsquo;activit\u00e9) ou <strong>accepter<\/strong> (avec justification document\u00e9e et approbation de la direction).<\/p>\n<h2>Cat\u00e9gories de risques et contr\u00f4les pour la livraison logicielle<\/h2>\n<p>Le tableau suivant met en correspondance les cat\u00e9gories de risques courantes dans la livraison logicielle avec leurs facteurs de probabilit\u00e9, facteurs d&rsquo;impact et contr\u00f4les typiques. Les responsables conformit\u00e9 devraient l&rsquo;utiliser comme base et l&rsquo;adapter au contexte sp\u00e9cifique de leur organisation.<\/p>\n<table>\n<thead>\n<tr>\n<th>Cat\u00e9gorie de risque<\/th>\n<th>Facteurs de probabilit\u00e9<\/th>\n<th>Facteurs d&rsquo;impact<\/th>\n<th>Contr\u00f4les typiques<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Int\u00e9grit\u00e9 du pipeline<\/strong><\/td>\n<td>D\u00e9finitions de pipeline non prot\u00e9g\u00e9es ; absence d&rsquo;approbation des changements sur les configurations de pipeline ; pas de v\u00e9rification d&rsquo;int\u00e9grit\u00e9 des sorties de build<\/td>\n<td>Injection de code malveillant en production ; logiciel compromis livr\u00e9 aux clients ; perte de confiance<\/td>\n<td>Pipeline-as-code avec contr\u00f4le de version ; revue obligatoire pour les changements de pipeline ; signature cryptographique des artefacts de build ; attestation de provenance de build<\/td>\n<\/tr>\n<tr>\n<td><strong>Contr\u00f4le d&rsquo;acc\u00e8s<\/strong><\/td>\n<td>Comptes de service sur-privil\u00e9gi\u00e9s ; identifiants partag\u00e9s ; absence de MFA sur l&rsquo;administration du pipeline ; pas de revues d&rsquo;acc\u00e8s r\u00e9guli\u00e8res<\/td>\n<td>D\u00e9ploiements non autoris\u00e9s ; mouvement lat\u00e9ral du pipeline vers la production ; exfiltration de donn\u00e9es via les identifiants du pipeline<\/td>\n<td>Mod\u00e8le d&rsquo;acc\u00e8s au moindre privil\u00e8ge ; comptes de service individuels par pipeline ; application du MFA ; revues d&rsquo;acc\u00e8s trimestrielles ; acc\u00e8s juste-\u00e0-temps pour les op\u00e9rations sensibles<\/td>\n<\/tr>\n<tr>\n<td><strong>Cha\u00eene d&rsquo;approvisionnement<\/strong><\/td>\n<td>D\u00e9pendances tierces non v\u00e9rifi\u00e9es ; pas de v\u00e9rification d&rsquo;int\u00e9grit\u00e9 sur les packages externes ; risques de d\u00e9pendances transitives ; absence d&rsquo;\u00e9valuation des fournisseurs<\/td>\n<td>Introduction de vuln\u00e9rabilit\u00e9s connues ; packages malveillants en production ; non-conformit\u00e9 r\u00e9glementaire pour la gestion de la cha\u00eene d&rsquo;approvisionnement<\/td>\n<td>G\u00e9n\u00e9ration de Software Bill of Materials (SBOM) ; analyse des d\u00e9pendances et workflows d&rsquo;approbation ; d\u00e9p\u00f4ts d&rsquo;artefacts priv\u00e9s ; \u00e9valuations de s\u00e9curit\u00e9 des fournisseurs<\/td>\n<\/tr>\n<tr>\n<td><strong>Exposition des secrets<\/strong><\/td>\n<td>Secrets cod\u00e9s en dur dans le code source ; secrets dans les journaux du pipeline ; secrets non chiffr\u00e9s dans la configuration ; absence de politiques de rotation<\/td>\n<td>Vol d&rsquo;identifiants menant \u00e0 la compromission du syst\u00e8me ; acc\u00e8s non autoris\u00e9 aux syst\u00e8mes de production ; violations de donn\u00e9es<\/td>\n<td>Gestion centralis\u00e9e des secrets ; analyse automatis\u00e9e des secrets ; masquage des journaux ; rotation r\u00e9guli\u00e8re des identifiants ; secrets jamais stock\u00e9s dans les d\u00e9p\u00f4ts<\/td>\n<\/tr>\n<tr>\n<td><strong>D\u00e9ploiement<\/strong><\/td>\n<td>Pas de portes d&rsquo;approbation de d\u00e9ploiement ; manque de capacit\u00e9 de rollback ; tests pr\u00e9-d\u00e9ploiement insuffisants ; pas de piste d&rsquo;audit de d\u00e9ploiement<\/td>\n<td>Versions d\u00e9fectueuses impactant la disponibilit\u00e9 du service ; incapacit\u00e9 \u00e0 r\u00e9cup\u00e9rer apr\u00e8s de mauvais d\u00e9ploiements ; lacunes de conformit\u00e9 dues aux changements non suivis<\/td>\n<td>Portes d&rsquo;approbation obligatoires pour les d\u00e9ploiements en production ; m\u00e9canismes de rollback automatis\u00e9s ; journalisation d&rsquo;audit des d\u00e9ploiements ; politiques de promotion d&rsquo;environnement<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Mod\u00e8le de gouvernance : Propri\u00e9t\u00e9 et responsabilit\u00e9<\/h2>\n<p>NIS2 place la responsabilit\u00e9 ultime sur l&rsquo;<strong>organe de direction<\/strong> (Article 20), ce qui signifie que la gestion des risques pour la livraison logicielle ne peut \u00eatre d\u00e9l\u00e9gu\u00e9e sans structures de responsabilit\u00e9 claires. Le mod\u00e8le RACI suivant fournit un point de d\u00e9part pour que les organisations d\u00e9finissent la propri\u00e9t\u00e9.<\/p>\n<table>\n<thead>\n<tr>\n<th>Activit\u00e9<\/th>\n<th>Organe de direction<\/th>\n<th>CISO \/ \u00c9quipe s\u00e9curit\u00e9<\/th>\n<th>Direction technique<\/th>\n<th>Conformit\u00e9 \/ \u00c9quipe risques<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Approuver l&rsquo;app\u00e9tit au risque pour le CI\/CD<\/td>\n<td><strong>A<\/strong><\/td>\n<td>R<\/td>\n<td>C<\/td>\n<td>C<\/td>\n<\/tr>\n<tr>\n<td>R\u00e9aliser les \u00e9valuations des risques CI\/CD<\/td>\n<td>I<\/td>\n<td><strong>A<\/strong><\/td>\n<td>R<\/td>\n<td>C<\/td>\n<\/tr>\n<tr>\n<td>Mettre en \u0153uvre les contr\u00f4les de s\u00e9curit\u00e9 du pipeline<\/td>\n<td>I<\/td>\n<td>C<\/td>\n<td><strong>A\/R<\/strong><\/td>\n<td>I<\/td>\n<\/tr>\n<tr>\n<td>Surveiller et rapporter le risque r\u00e9siduel<\/td>\n<td>I<\/td>\n<td><strong>A<\/strong><\/td>\n<td>R<\/td>\n<td>R<\/td>\n<\/tr>\n<tr>\n<td>R\u00e9viser et mettre \u00e0 jour le registre des risques<\/td>\n<td>I<\/td>\n<td>R<\/td>\n<td>C<\/td>\n<td><strong>A<\/strong><\/td>\n<\/tr>\n<tr>\n<td>Accepter les risques r\u00e9siduels au-dessus du seuil<\/td>\n<td><strong>A<\/strong><\/td>\n<td>R<\/td>\n<td>C<\/td>\n<td>R<\/td>\n<\/tr>\n<tr>\n<td>Signaler les risques mat\u00e9riels aux r\u00e9gulateurs<\/td>\n<td><strong>A<\/strong><\/td>\n<td>R<\/td>\n<td>I<\/td>\n<td>R<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><em>R = Responsable, A = Redevable, C = Consult\u00e9, I = Inform\u00e9<\/em><\/p>\n<p>Principes de gouvernance cl\u00e9s \u00e0 appliquer :<\/p>\n<ul>\n<li>Les \u00e9valuations des risques pour la livraison logicielle doivent \u00eatre r\u00e9vis\u00e9es au moins <strong>annuellement<\/strong>, ou apr\u00e8s tout changement significatif de l&rsquo;environnement du pipeline.<\/li>\n<li>L&rsquo;acceptation du risque r\u00e9siduel doit \u00eatre document\u00e9e et sign\u00e9e par une personne ayant l&rsquo;autorit\u00e9 appropri\u00e9e \u2014 pas par l&rsquo;\u00e9quipe qui exploite le pipeline.<\/li>\n<li>Le registre des risques doit inclure les risques de livraison logicielle aux c\u00f4t\u00e9s des autres risques op\u00e9rationnels, pas dans un silo s\u00e9par\u00e9.<\/li>\n<\/ul>\n<h2>Ce que les auditeurs doivent v\u00e9rifier<\/h2>\n<p>Lors de l&rsquo;\u00e9valuation de la conformit\u00e9 NIS2 pour la gestion des risques de livraison logicielle, les auditeurs doivent examiner les domaines suivants :<\/p>\n<h3>1. \u00c9valuations des risques document\u00e9es<\/h3>\n<ul>\n<li>Existe-t-il une \u00e9valuation formelle des risques couvrant explicitement les syst\u00e8mes CI\/CD et de livraison logicielle ?<\/li>\n<li>L&rsquo;\u00e9valuation est-elle bas\u00e9e sur une m\u00e9thodologie reconnue (par exemple, ISO 27005, NIST SP 800-30) ?<\/li>\n<li>Identifie-t-elle des risques sp\u00e9cifiques au pipeline \u2014 et pas seulement des risques informatiques g\u00e9n\u00e9riques appliqu\u00e9s sans contexte ?<\/li>\n<li>Le p\u00e9rim\u00e8tre est-il appropri\u00e9 ? (Tous les composants du pipeline, int\u00e9grations et d\u00e9pendances doivent \u00eatre inclus.)<\/li>\n<\/ul>\n<h3>2. Plans de traitement des risques<\/h3>\n<ul>\n<li>Pour chaque risque identifi\u00e9 au-dessus du seuil d&rsquo;app\u00e9tit, existe-t-il un plan de traitement document\u00e9 ?<\/li>\n<li>Les contr\u00f4les sont-ils associ\u00e9s \u00e0 des risques sp\u00e9cifiques, avec une justification claire de l&rsquo;ad\u00e9quation du contr\u00f4le ?<\/li>\n<li>Les plans de traitement sont-ils attribu\u00e9s \u00e0 des propri\u00e9taires nomm\u00e9s avec des dates cibles d&rsquo;ach\u00e8vement ?<\/li>\n<li>Y a-t-il des preuves que les plans de traitement sont effectivement ex\u00e9cut\u00e9s, et pas seulement document\u00e9s ?<\/li>\n<\/ul>\n<h3>3. Acceptation du risque r\u00e9siduel<\/h3>\n<ul>\n<li>Lorsque des risques ont \u00e9t\u00e9 accept\u00e9s plut\u00f4t qu&rsquo;att\u00e9nu\u00e9s, y a-t-il une approbation formelle de la direction appropri\u00e9e ?<\/li>\n<li>La justification de l&rsquo;acceptation est-elle document\u00e9e et d\u00e9fendable ?<\/li>\n<li>Les risques accept\u00e9s font-ils l&rsquo;objet d&rsquo;une revue p\u00e9riodique pour d\u00e9terminer si les conditions ont chang\u00e9 ?<\/li>\n<\/ul>\n<h3>4. Cadence de revue des risques<\/h3>\n<ul>\n<li>Y a-t-il des preuves de revues r\u00e9guli\u00e8res des risques (au minimum annuellement) ?<\/li>\n<li>Les \u00e9valuations des risques sont-elles mises \u00e0 jour lorsque des changements significatifs surviennent (nouveaux outils de pipeline, changements d&rsquo;architecture, nouvelles cibles de d\u00e9ploiement) ?<\/li>\n<li>Existe-t-il une liste d\u00e9finie de d\u00e9clencheurs pour les revues de risques ad hoc ?<\/li>\n<li>Les enregistrements de revue montrent-ils des mises \u00e0 jour significatives, et pas seulement une r\u00e9-approbation du m\u00eame document sans changement ?<\/li>\n<\/ul>\n<h3>Signaux d&rsquo;alerte pour les auditeurs<\/h3>\n<ul>\n<li>\u00c9valuations des risques qui ne listent que des risques g\u00e9n\u00e9riques sans contexte sp\u00e9cifique au pipeline<\/li>\n<li>Aucune preuve d&rsquo;implication ou de connaissance de l&rsquo;organe de direction concernant les risques de livraison logicielle<\/li>\n<li>Registres des risques non mis \u00e0 jour depuis plus de 12 mois<\/li>\n<li>Tous les risques not\u00e9s comme \u00ab Faible \u00bb sans justification<\/li>\n<li>Plans de traitement sans propri\u00e9taire ni date cible<\/li>\n<li>Risque r\u00e9siduel accept\u00e9 par le personnel op\u00e9rationnel plut\u00f4t que par la direction appropri\u00e9e<\/li>\n<\/ul>\n<h2>Ressources connexes<\/h2>\n<p>Pour des orientations compl\u00e9mentaires sur la conformit\u00e9 NIS2 et la gouvernance de la livraison logicielle, consultez :<\/p>\n<ul>\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/nis2\/\">Aper\u00e7u de la conformit\u00e9 NIS2<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/nis2-security-architecture-explained-2\/\">Architecture de s\u00e9curit\u00e9 NIS2 expliqu\u00e9e<\/a><\/li>\n<\/ul>\n<hr\/>\n<h3>Ressources connexes pour les auditeurs<\/h3>\n<ul>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/\">Glossaire<\/a> \u2014 D\u00e9finitions en langage clair des termes techniques<\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/nis2-security-architecture-explained-2\/\">Architecture de s\u00e9curit\u00e9 NIS2<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/executive-audit-briefing-ci-cd-pipelines-in-regulated-environments\/\">Briefing d&rsquo;audit ex\u00e9cutif<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/dual-compliance-architecture-explained\/\">Architecture de double conformit\u00e9<\/a><\/li>\n<\/ul>\n<p><em>Nouveau dans l&rsquo;audit CI\/CD ? Commencez par notre <a href=\"https:\/\/regulated-devsecops.com\/fr\/start-here\/\">Guide de l&rsquo;auditeur<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Introduction : La gestion des risques comme obligation l\u00e9gale sous NIS2 L&rsquo;article 21(1) de la directive NIS2 (Directive 2022\/2555) exige que les entit\u00e9s essentielles et importantes prennent des mesures techniques, op\u00e9rationnelles et organisationnelles appropri\u00e9es et proportionn\u00e9es pour g\u00e9rer les risques pesant sur la s\u00e9curit\u00e9 des r\u00e9seaux et des syst\u00e8mes d&rsquo;information. Il ne s&rsquo;agit pas d&rsquo;une &#8230; <a title=\"Gestion des risques NIS2 pour la livraison logicielle\" class=\"read-more\" href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/nis2-risk-management-for-software-delivery\/\" aria-label=\"En savoir plus sur Gestion des risques NIS2 pour la livraison logicielle\">Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[126,123],"tags":[],"post_folder":[],"class_list":["post-1254","post","type-post","status-publish","format-standard","hentry","category-regulatory-frameworks","category-ci-cd-governance"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts\/1254","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/comments?post=1254"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts\/1254\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/media?parent=1254"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/categories?post=1254"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/tags?post=1254"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/post_folder?post=1254"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}