--- title: Comment interpréter l’exigence de « tests efficaces et réguliers » du Cyber Resilience Act description: "Exigences du Cyber Resilience Act : ce que les tests doivent démontrer. Tests efficaces et réguliers, choix des fabricants et preuves à conserver." image: https://blog.unguess.io/hubfs/Canva%20images/Canva%20Design%20DAHV7yf54O8.png --- [![unguess-logo](https://blog.unguess.io/hs-fs/hubfs/Unguess/unguess-logo.png?width=189&height=31&name=unguess-logo.png)](https://unguess.io/it) - PRODUIT PAR SECTEUR D'ACTIVITÉ - [Retail & Ecommerce](https://unguess.io/fr/services/industry/retail-ecommerce/) - [Biens de consommation à rotation rapide](https://unguess.io/fr/services/industry/biens-de-consommation-a-rotation-rapide/) - [Compagnies](https://unguess.io/fr/services/industry/compagnies/) - [Tourisme et Hôtellerie](https://unguess.io/fr/services/industry/tourisme-et-hotellerie/) - [Services Publics](https://unguess.io/fr/services/industry/services-publics/) - [Santé et Pharma](https://unguess.io/fr/services/industry/sante-et-pharma/) - [Médias et divertissements](https://unguess.io/fr/services/industry/medias-et-divertissements/) - [Automobile](https://unguess.io/fr/services/industry/automobile/) - PRODUIT PAR CAS D'UTILISATION - [Ai Training](https://unguess.io/fr/services/ai-training-testing/) - [Software Quality](https://unguess.io/fr/services/use-case/software-quality/) - [User Experience](https://unguess.io/fr/services/use-case/user-experience/) - [Cyber Security](https://unguess.io/fr/services/use-case/cyber-security/) - [Accessibility](https://unguess.io/fr/services/accessibility/) - [COMMENT ÇA MARCHE](https://unguess.io/fr/comment-ca-marche/) - [NOTRE CROWD](https://unguess.io/fr/notre-crowd/) - ENTERPRISE - [À propos de nous](https://unguess.io/fr/a-propos-de-nous/) - [La vie chez UNGUESS](https://unguess.io/fr/la-vie-chez-unguess/) - [Partenaires](https://unguess.io/fr/partenaires/) - [SHOWCASES](https://unguess.io/fr/showcases/) - [Études de cas](https://unguess.io/fr/showcases/etude-de-cas/) - [Défis UNGUESS](https://unguess.io/fr/showcases/defis-unguess/) - [White Paper](https://unguess.io/fr/showcases/white-paper-fr/) - [Webinar](https://unguess.io/fr/showcases/webinar/) - [BLOG](https://blog.unguess.io?hsLang=fr) - - - - - [PRODUITS](https://unguess.io/fr/services/) - PAR SECTEUR D'ACTIVITÉ - [Retail & Ecommerce](https://unguess.io/fr/services/industry/retail-ecommerce/) - [Biens de consommation à rotation rapide](https://unguess.io/fr/services/industry/biens-de-consommation-a-rotation-rapide/) - [Compagnies](https://unguess.io/fr/services/industry/compagnies/) - [Tourisme et Hôtellerie](https://unguess.io/fr/services/industry/tourisme-et-hotellerie/) - [Services Publics](https://unguess.io/fr/services/industry/services-publics/) - [Santé et Pharma](https://unguess.io/fr/services/industry/sante-et-pharma/) - [Médias et divertissements](https://unguess.io/fr/services/industry/medias-et-divertissements/) - [Automobile](https://unguess.io/fr/services/industry/automobile/) - PAR USE CASE - [Ai Training](https://unguess.io/fr/services/ai-training-testing/) - [User Experience](https://unguess.io/fr/services/use-case/user-experience/) - [Software Quality](https://unguess.io/fr/services/use-case/software-quality/) - [Cyber Security](https://unguess.io/fr/services/use-case/cyber-security/) - [Accessibility](https://unguess.io/fr/services/accessibility-testing/) - [VOIR TOUS LES SERVICES](https://unguess.io/fr/services/) - [FONCTIONNEMENT](https://unguess.io/fr/comment-ca-marche/) - [NOTRE CROWD](https://unguess.io/fr/notre-crowd/) - À PROPOS - [À propos de nous](https://unguess.io/fr/a-propos-de-nous/) - [La vie chez UNGUESS](https://unguess.io/fr/la-vie-chez-unguess/) - [Partenaires](https://unguess.io/fr/partenaires/) - [RESSOURCES](https://unguess.io/fr/showcases/) - [Études de cas](https://unguess.io/fr/showcases/etude-de-cas/) - [Défis UNGUESS](https://unguess.io/fr/showcases/defis-unguess/) - [White Paper](https://unguess.io/fr/showcases/white-paper-fr/) - [BLOG](https://blog.unguess.io?hsLang=fr) - - - - [BOOK A DEMO](https://unguess.io/it/inizia-ora/) [LOG IN](https://app.unguess.io/) Cybersecurity # Comment interpréter l’exigence de « tests efficaces et réguliers » du Cyber Resilience Act Exigences du Cyber Resilience Act : ce que les tests doivent démontrer. Tests efficaces et réguliers, choix des fabricants et preuves à conserver. [Luca Manara](https://blog.unguess.io/fr/author/luca-manara) oct. 8, 2026 --- ## **Points clés à retenir** - Le **Cyber Resilience Act exige des « tests et examens efficaces et réguliers »** de la sécurité des produits (annexe I, partie II), sans imposer de méthode, de fréquence ni de modèle. - Le signalement des vulnérabilités exploitées et des incidents graves est obligatoire depuis le 11 septembre 2026, y compris pour les produits déjà sur le marché. **L’ensemble des exigences s’appliquera à partir du 11 décembre 2027.** - En pratique, **les fabricants doivent tester, corriger** les problèmes identifiés et documenter ces deux activités (annexe VII). - La fréquence des tests doit être adaptée au risque associé au produit et à son rythme d’évolution (article 13), plutôt qu’à un calendrier fixe. - Un historique de tests constitué progressivement dès maintenant est plus facile à défendre qu’un historique reconstitué après coup.   Au cœur du Cyber Resilience Act se trouve une phrase qui influencera les budgets d’ingénierie pendant des années, mais que presque personne, en dehors des équipes chargées de la conformité, n’a lue. L’annexe I, partie II, point 3 exige des fabricants qu’ils réalisent des « tests et examens efficaces et réguliers » de la sécurité de tout produit comportant des éléments numériques. C’est toute la consigne. Aucune méthode précisée. Aucune fréquence définie. Aucun modèle fourni. Les fabricants doivent déterminer ce que cela signifie pour leur propre produit et être en mesure de justifier leur décision. ## Ce que le Cyber Resilience Act exige en matière de tests de sécurité Le **Cyber Resilience Act** (règlement (UE) 2024/2847) est le règlement européen qui fixe des exigences obligatoires de cybersécurité pour les produits matériels et logiciels comportant des éléments numériques mis sur le marché européen, tout au long de leur cycle de vie. En matière de tests, son exigence centrale tient en une ligne de l’annexe I : les fabricants doivent réaliser des tests et examens efficaces et réguliers de la sécurité de leur produit, choisir comment procéder et pouvoir justifier ce choix. Ce que le règlement ne dit pas compte autant que ce qu’il dit. Il n’impose aucun type de test, aucun nombre minimal de tests par an et aucun format de rapport. La responsabilité de définir ce qui est « efficace » et « régulier » incombe entièrement au fabricant. ## Calendrier du Cyber Resilience Act : le signalement est déjà obligatoire Le CRA est entré en vigueur en décembre 2024, mais ses obligations s’appliquent par étapes. La première échéance impérative est désormais passée : depuis le 11 septembre 2026, les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents graves via la plateforme unique de signalement de l’ENISA, selon des délais stricts. Une alerte précoce sous 24 heures, une notification plus complète sous 72 heures et un rapport final dans les 14 jours suivant la mise à disposition d’une correction pour une vulnérabilité exploitée, ou dans un délai d’un mois pour un incident grave. L’ensemble des exigences essentielles de cybersécurité, y compris l’obligation de test décrite ci-dessus, s’appliquera à partir du 11 décembre 2027. Un détail prend les fabricants au dépourvu : ces obligations de signalement concernent aussi les produits déjà commercialisés. Les produits déjà sur le marché, y compris ceux qui n’ont fait l’objet d’aucune intervention ni modification depuis, peuvent rester soumis à l’obligation de signalement. « Nous nous en occuperons lors du lancement d’un nouveau produit » n’est donc pas réellement une option pour de nombreuses entreprises. Le 27 juillet 2026, la Commission européenne a publié ses premières grandes orientations sur l’application pratique du CRA. Ce document d’environ 80 pages, élaboré à partir d’une consultation publique, s’adresse directement aux entreprises qui rencontrent le plus de difficultés à interpréter le règlement. Il n’est pas contraignant, mais constitue à ce jour l’indication la plus claire de la manière dont les règles seront effectivement appliquées. Une phrase de la communication publiée par la Commission pour accompagner ces orientations mérite que l’on s’y attarde. Elle cite explicitement les progrès récents des modèles d’IA de pointe dotés de capacités en cybersécurité comme une raison pour laquelle une mise en œuvre rapide et correcte du CRA est désormais encore plus importante. L’autorité qui a rédigé ce règlement vous indique directement que l’évolution des vulnérabilités, accélérée par l’IA, contribue à rendre ce calendrier déterminant. | Date | Dispositions applicables | | --- | --- | | **10 décembre 2024** | Entrée en vigueur du CRA | | **11 juin 2026** | Obligations pour les organismes d’évaluation de la conformité | | **27 juillet 2026** | Publication des premières orientations de la Commission | | **11 septembre 2026** | Signalement des vulnérabilités et des incidents à l’ENISA | | **11 décembre 2027** | Application intégrale, y compris des exigences essentielles et des obligations de test | ## Ce que signifient des tests « efficaces et réguliers » en pratique Lue conjointement avec deux autres dispositions du CRA, à savoir l’exigence de commercialiser des produits sans vulnérabilités exploitables connues (annexe I, partie I) et celle d’inclure dans la documentation technique les rapports des tests utilisés pour vérifier la sécurité (annexe VII), l’obligation de test prend un sens précis : les fabricants doivent tester, agir sur les problèmes identifiés et conserver les preuves de ces actions. C’est sur ce dernier point que la plupart des pratiques actuelles montrent discrètement leurs limites. Certaines habitudes deviennent plus difficiles à défendre lorsqu’un auditeur les examine directement : - Une **liste de résultats** sans évaluation des problèmes réellement exploitables - Un **rapport de test** qui ne précise pas ce qui a été testé et ce qui n’a pas pu l’être - Un **statut « corrigé »** sans vérification de l’efficacité réelle de la correction - Un **test unique avant la mise en production**, jamais répété après une évolution significative du produit Aucune de ces pratiques n’est inhabituelle. Elles ne résisteront tout simplement pas à un échange avec une autorité de surveillance du marché. ## À quelle fréquence faut-il tester dans le cadre du Cyber Resilience Act ? Le CRA ne fixe aucun intervalle entre les tests. Il s’agit d’un choix délibéré, et non d’un oubli. L’article 13 exige déjà des fabricants qu’ils évaluent le risque de cybersécurité associé à leur produit et qu’ils en tiennent compte dans sa conception, son développement et sa maintenance. L’interprétation qui en découle est que la fréquence des tests doit suivre la même logique : être guidée par le risque associé au produit et par son rythme d’évolution, plutôt que par une date fixe sans rapport avec l’un ou l’autre. En pratique, les tests cessent d’être une case à cocher avant la mise en production et sont déclenchés par les événements qui modifient réellement votre niveau de risque : - une modification de l’authentification ou des autorisations - un nouveau point de terminaison d’API ou une modification substantielle d’un point existant - une nouvelle intégration avec un tiers ou un fournisseur de modèles - une mise à jour de sécurité touchant une partie exposée du produit - des éléments indiquant qu’un composant dont dépend votre produit est activement exploité ailleurs Il n’existe pas de réponse universelle à la question « à quelle fréquence ? ». En revanche, il doit exister une réponse défendable à la question « pourquoi cette fréquence, pour ce produit ? ». ## Constituer les preuves de conformité au CRA avant décembre 2027 Pour le dire clairement : vous pouvez constituer progressivement un historique de tests dès maintenant, alors que l’échéance d’application intégrale est encore à plus d’un an, ou tenter de le reconstituer sous pression après qu’une autorité de contrôle ou l’équipe achats d’un client vous l’a déjà demandé. C’est précisément cet historique que les [tests continus validés par des experts humains](https://security.unguess.io/bug-bounty) produisent naturellement, sans nécessiter un exercice de conformité distinct. Lorsque chaque vulnérabilité est confirmée comme exploitable avant de vous être transmise, que les corrections sont à nouveau testées avant la clôture et que toutes les tentatives ayant *échoué* sont consignées aux côtés de celles qui ont réussi, vous obtenez le document réellement demandé par l’annexe VII : un compte rendu documenté de ce qui a été testé, de ce qui a été découvert et des corrections dont l’efficacité a été vérifiée. Produit au fil du travail, et non reconstitué après coup. C’est ce même principe qui guide le fonctionnement d’[UNGUESS Security](https://security.unguess.io/).   Si nécessaire, son réseau de hackers éthiques européens rend compte de chaque tentative d’exploitation, et pas uniquement de celles qui ont réussi. Le modèle prévoit une facturation uniquement pour les résultats confirmés et validés, plutôt que pour l’activité réalisée. Il se trouve que la rigueur qui rend un programme de bug bounty économiquement efficace est aussi celle qu’une autorité de contrôle souhaite voir documentée. Les entreprises qui adoptent cette habitude dès maintenant arriveront en décembre 2027 avec un historique de tests déjà constitué. Les autres devront le reconstituer rétroactivement, dans un délai qu’elles ne maîtriseront pas.   [Découvrez à quoi ressemblent concrètement les preuves issues de tests continus et validés](https://security.unguess.io/)   ## Frequently Asked Questions ### Qu’est-ce que le Cyber Resilience Act ? Le Cyber Resilience Act (règlement (UE) 2024/2847) est un règlement européen qui fixe des exigences obligatoires de cybersécurité pour les produits matériels et logiciels comportant des éléments numériques vendus dans l’Union européenne. Il couvre l’ensemble du cycle de vie du produit, de la conception à la gestion des vulnérabilités après sa commercialisation, et s’applique aux fabricants, aux importateurs et aux distributeurs. Il est entré en vigueur en décembre 2024. ### Quand le Cyber Resilience Act s’applique-t-il ? Le CRA s’applique par étapes. Les obligations pour les organismes d’évaluation de la conformité ont commencé le 11 juin 2026. Le signalement à l’ENISA des vulnérabilités activement exploitées et des incidents graves est obligatoire depuis le 11 septembre 2026. L’ensemble des exigences essentielles de cybersécurité, y compris les tests de sécurité réguliers, s’appliquera à partir du 11 décembre 2027. ### Quels tests de sécurité le Cyber Resilience Act exige-t-il ? L’annexe I, partie II, point 3 du CRA exige des fabricants qu’ils réalisent des tests et examens efficaces et réguliers de la sécurité de leur produit. Le règlement n’impose aucune méthode, fréquence ni aucun format. Combinée à l’interdiction de commercialiser des produits présentant des vulnérabilités exploitables connues et à l’obligation de documentation de l’annexe VII, cette exigence signifie que les fabricants doivent tester, corriger les problèmes identifiés et conserver les rapports des tests réalisés. ### À quelle fréquence faut-il tester un produit dans le cadre du CRA ? Le CRA ne fixe aucun intervalle entre les tests. Puisque l’article 13 lie les obligations du fabricant à une évaluation du risque de cybersécurité du produit, l’approche défendable est fondée sur le risque : tester lorsqu’un événement modifie ce risque, par exemple une modification de l’authentification, un nouveau point de terminaison d’API, une nouvelle intégration avec un tiers ou l’exploitation active d’un composant dont dépend le produit. Le fabricant doit pouvoir expliquer pourquoi la fréquence choisie est adaptée au produit. ### Quelles preuves de test un auditeur demandera-t-il dans le cadre du CRA ? L’annexe VII exige que la documentation technique contienne les rapports des tests réalisés pour vérifier que le produit satisfait aux exigences essentielles. En pratique, cela signifie documenter ce qui a été testé et ce qui ne l’a pas été, les vulnérabilités confirmées comme exploitables et la preuve que chaque correction a été à nouveau testée. Une liste de résultats de scanners dépourvue de ce contexte a peu de chances de satisfaire une autorité de surveillance du marché. ### Les obligations de signalement du CRA s’appliquent-elles aux produits déjà sur le marché ? Oui. L’obligation de signalement entrée en application le 11 septembre 2026 couvre également les produits mis sur le marché avant l’application intégrale du CRA, y compris ceux qui n’ont pas été modifiés depuis. Les fabricants ne peuvent pas reporter leur mise en conformité jusqu’à leur prochaine version. ### L’historique de tests commence maintenant Le Cyber Resilience Act ne vous dit pas comment tester. Il vous dit que vous devrez prouver que vous l’avez fait et que cette preuve doit être solide. Chaque mois de [tests continus](https://security.unguess.io/) entre aujourd’hui et décembre 2027 représente un mois de preuves que vous n’aurez pas à reconstituer plus tard. [Cybersecurity](https://blog.unguess.io/fr/tag/cybersecurity) [Share via Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fblog.unguess.io%2Ffr%2Fcyber-resilience-act-testing-requirements) [Share via Twitter](https://twitter.com/intent/tweet?url=https%3A%2F%2Fblog.unguess.io%2Ffr%2Fcyber-resilience-act-testing-requirements&text=Comment+interpr%26eacute%3Bter+l%26rsquo%3Bexigence+de+%26laquo%3B+tests+efficaces+et+r%26eacute%3Bguliers+%26raquo%3B+du+Cyber+Resilience+Act) [Share via Email](mailto:?subject=Comment+interpr%26eacute%3Bter+l%26rsquo%3Bexigence+de+%26laquo%3B+tests+efficaces+et+r%26eacute%3Bguliers+%26raquo%3B+du+Cyber+Resilience+Act&body=https%3A%2F%2Fblog.unguess.io%2Ffr%2Fcyber-resilience-act-testing-requirements) [Share via LinkedIn](https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Fblog.unguess.io%2Ffr%2Fcyber-resilience-act-testing-requirements&title=Comment+interpr%26eacute%3Bter+l%26rsquo%3Bexigence+de+%26laquo%3B+tests+efficaces+et+r%26eacute%3Bguliers+%26raquo%3B+du+Cyber+Resilience+Act&summary=Exigences+du+Cyber+Resilience+Act+%3A+ce+que+les+tests+doivent+d%C3%A9montrer.+Tests+efficaces+et+r%C3%A9guliers%2C+choix+des+fabricants+et+preuves+%C3%A0+conserver.) ## Similar posts Crowdtesting ### [Tout savoir sur les tests fonctionnels](https://blog.unguess.io/fr/tout-savoir-sur-les-tests-fonctionnels?hsLang=fr) Préparez votre application pour le succès en apprenant tout sur les tests fonctionnels, des tests unitaires aux tests de régression. Découvrez les... Thibault Geneen août 12, 2025 Cybersecurity ### [Priorisation des vulnérabilités en cybersécurité : ce qui compte vraiment](https://blog.unguess.io/fr/vulnerability-prioritization?hsLang=fr) Découvrez comment prioriser efficacement les vulnérabilités en cybersécurité et réduire les risques, même face à un volume croissant de CVEs. Luca Manara sept. 15, 2026 Cybersecurity ### [Tests continus : quelle est l'approche la plus efficace et la plus rentable?](https://blog.unguess.io/fr/tests-continus-quelle-est-lapproche-la-plus-efficace-et-la-plus-rentable?hsLang=fr) Le test continu consiste à vérifier en permanence les logiciels tout au long du cycle de développement afin de détecter les erreurs et les points... Angela Meduri janv. 23, 2025 Tests de régression ### [Comment créer une suite de tests de régression efficace](https://blog.unguess.io/fr/comment-cr%C3%A9er-une-suite-de-tests-de-r%C3%A9gression-efficace?hsLang=fr) Une suite de tests de régression est indispensable pour s'assurer que le logiciel fonctionne correctement après chaque modification. Quelles... Angela Meduri janv. 31, 2025 ![unguess-logo-1](https://blog.unguess.io/hubfs/unguess-logo-1.svg) **© 2023 UNGUESS S.r.l.** UNGUESS est une marque déposée de UNGUESS S.r.l.   - [![U2Y - Verified Carbon Footprint](https://blog.unguess.io/hs-fs/hubfs/U2Y%20-%20Verified%20Carbon%20Footprint.png?width=50&height=50&name=U2Y%20-%20Verified%20Carbon%20Footprint.png)](https://app.u2y.io/brands/314) - [![UNGUESS is a leader in Crowd Testing Tools on G2](https://images.g2crowd.com/uploads/report_medal/image/1004327/medal.svg)](https://www.g2.com/products/unguess/reviews?utm_source=rewards-badge) - [![UNGUESS is a leader in Test Management on G2](https://images.g2crowd.com/uploads/report_medal/image/1004327/medal.svg)](https://www.g2.com/products/unguess/reviews?utm_source=rewards-badge) - [![UNGUESS is a leader in Crowd Testing Tools on G2](https://images.g2crowd.com/uploads/report_medal/image/1004379/medal.svg)](https://www.g2.com/products/unguess/reviews?utm_source=rewards-badge) - [![UNGUESS is a leader in Europe Test Management on G2](https://images.g2crowd.com/uploads/report_medal/image/1004391/medal.svg)](https://www.g2.com/products/unguess/reviews?utm_source=rewards-badge) - [![UNGUESS is a leader in EMEA Test Management on G2](https://images.g2crowd.com/uploads/report_medal/image/1004447/medal.svg)](https://www.g2.com/products/unguess/reviews?utm_source=rewards-badge) #### SERVICES - [Ai Training](https://unguess.io/fr/services/ai-training-testing/) - [User Experience](https://unguess.io/fr/services/use-case/user-experience/) - [Software Quality](https://unguess.io/fr/services/use-case/software-quality/) - [Cyber Security](https://unguess.io/fr/services/use-case/cyber-security/) - [Accessibility](https://unguess.io/fr/services/accessibility-testing/) #### SHOWCASES - [Blog](https://blog.unguess.io/fr) - [Notre Crowd](https://unguess.io/fr/notre-crowd/) - [Tryber.me](https://tryber.me/) - [Intégrations](https://unguess.io/fr/integrations/) - [Partenaires](https://unguess.io/fr/partenaires/) #### ENTEPRISE [Rejoignez-nous](https://unguess.io/fr/la-vie-chez-unguess/#job-positions) [Prenez contact avec nous](https://unguess.io/get-started/) **Information génerales:** [info@unguess.io](mailto:info@unguess.io)   [Politique de confidentialité](https://unguess.io/fr/politique-de-confidentialite/)  | [ESG Policy](https://unguess.io/esg-policy/)  | [Avis de traitement des données personnelles: Clients et Fournisseurs](https://unguess.io/personal-data-processing-notice-customers-and-suppliers/) | [Modèle 231](https://unguess.io/model-231/) | [Code Éthique](https://unguess.io/ethical-code/) | [Paramètres des cookies](https://www.iubenda.com/privacy-policy/833252/full-legal)  |  [Conditions générales](https://unguess.io/fr/conditions-generales/)  |  [Rapport de Mission](https://drive.google.com/file/d/1m38m3-lzHGay26v0oSqNN1rl8N06fiDy/view) UNGUESS S.r.l. – VAT 01603290196   © 2022 Kalungi, Inc. - All Rights Reserved. [Powered by Atlas - a B2B SaaS HubSpot theme](https://www.kalungi.com/atlas-hubspot-theme-for-b2b-saas-software) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Luca Manara", "url" : "https://blog.unguess.io/fr/author/luca-manara" }, "dateModified" : "2026-10-08T07:36:51.373Z", "datePublished" : "2026-10-08T07:36:51.000Z", "headline" : "Comment interpréter l’exigence de « tests efficaces et réguliers » du Cyber Resilience Act", "image" : [ "https://blog.unguess.io/hubfs/Canva%20images/Canva%20Design%20DAHV7yf54O8.png" ], "mainEntityOfPage" : { "@id" : "https://blog.unguess.io/fr/cyber-resilience-act-testing-requirements", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://blog.unguess.io/hubfs/Unguess/Colour%20Horizontal-1.png" }, "name" : "UNGUESS" } } ```