# Échelle et performances Dans cet article, nous verrons comment la plateforme Didomi est conçue pour évoluer selon les besoins de votre organisation et comment nous optimisons notre technologie pour fonctionner sur vos sites web et applications. * [Mise à l'échelle de la plateforme Didomi](#didomi-platform-scaling) * [Performances de la plateforme Didomi](#didomi-platform-performance) *** ### Mise à l'échelle de la plateforme Didomi Dans les sections ci-dessous, nous présentons les différentes façons dont certaines parties de la plateforme Didomi font évoluer leurs technologies :
Script

  • Le code JavaScript de Didomi est hébergé de manière statique sur AWS S3 et diffusé via Amazon CloudFront, avec réplication dans tous leurs points de présence dans le monde (y compris en Espagne). Didomi n'a aucun serveur unique sur ce chemin, et nous sommes convaincus que CloudFront peut évoluer sans problème.
  • La bannière, la fenêtre contextuelle et la gestion des tags (déclenchement de tout tag tiers nécessitant le consentement, l'API CMP de l'IAB, etc.) se font sans aucune requête serveur (le consentement est mis en cache localement dans un cookie), de sorte que l'expérience utilisateur final de votre organisation n'est pas impactée.
Serveurs back-end

  • Didomi envoie des requêtes HTTP lorsque le consentement est collecté ou pour compter les pages vues (nous échantillonnons le nombre de pages vues en comptant entre 10 % et 20 %). Ces requêtes sont asynchrones et se produisent toujours après toutes les opérations front-end, de sorte que, même en cas d'échec, cela n'aurait pas d'impact sur l'utilisateur final. Cela signifie également que si les serveurs de Didomi étaient indisponibles, l'expérience de vos utilisateurs finaux ne serait pas affectée et le consentement serait stocké localement puis envoyé à nos serveurs ultérieurement.
  • Les serveurs back-end sont surveillés 24 heures sur 24, 7 jours sur 7, avec des alertes via New Relic et AWS CloudWatch afin de garantir que Didomi soit notifié en cas de problème. Nous faisons évoluer automatiquement ces serveurs pour nous assurer d'ajouter (ou de retirer) des serveurs à notre infrastructure selon les besoins au cours de la journée ou lorsque nous intégrons de nouveaux clients.
  • En général, Didomi ne surveille pas les clients individuellement (nous pouvons le faire exceptionnellement de temps à autre), car nous nous concentrons sur le fait de garantir que toute notre infrastructure est élastique, peut évoluer sans aucune intervention humaine, et que l'indisponibilité de nos serveurs n'a pas d'impact sur le chemin critique de la collecte/gestion du consentement pour les utilisateurs finaux. Nous savons que nous pouvons gérer 10 fois plus de trafic qu'aujourd'hui sans aucun problème (et cette croissance s'est produite à plusieurs reprises au cours des derniers mois).
### Performances de la plateforme Didomi La règle générale chez Didomi est une obligation impérative de minimiser l'impact de notre présence sur les sites web. Afin d'y parvenir, nous avons mis en œuvre les mesures suivantes : * Utiliser un CDN (AWS CloudFront) et mettre en cache agressivement notre SDK pour garantir qu'il soit distribué aussi rapidement que possible partout dans le monde avec des points de présence locaux. * Réduire au minimum le nombre de requêtes HTTP que nous envoyons à nos serveurs. Le chargement initial (la première fois qu'un utilisateur final charge notre SDK) prend généralement deux requêtes HTTP, et les chargements ultérieurs du SDK ne nécessitent pas de requêtes HTTP pour la gestion du consentement. Nous intégrons la géolocalisation de l'utilisateur final ainsi que toute configuration spécifique à vos sites web dans une version de notre SDK propre au site web afin d'éviter des allers-retours supplémentaires. * Mettre en cache localement toutes les informations de consentement dans des cookies afin de garantir que nous puissions répondre immédiatement aux demandes de consentement sur la page. Cela signifie que nous ne retardons pas le chargement de vos balises publicitaires en chargeant des données depuis nos serveurs. * Pour les éditeurs non européens, nous restons autant que possible en retrait pour les utilisateurs finaux non européens et déclenchons immédiatement toutes les balises dont nous pouvons avoir la responsabilité, sans aucune requête vers nos serveurs. Nous chargeons une version spécifique de notre SDK qui n'inclut pas tous les composants d'interface utilisateur afin d'être plus léger dans ces cas : son seul rôle est de déclencher toutes les balises aussi rapidement que possible. Avec une configuration supplémentaire, nous pouvons également éviter complètement le chargement de notre SDK pour les utilisateurs finaux non européens et vous permettre de configurer Google Tag Manager de manière à ce qu'il n'y ait aucun délai/condition pour les utilisateurs finaux non européens. * Le SDK Didomi est déployé avec l'attribut "async" afin de garantir qu'il ne bloque pas votre contenu. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.didomi.io/fr/prise-en-main/general/echelle-et-performances.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.