[{"data":1,"prerenderedAt":181},["ShallowReactive",2],{"seo-verification":3,"blog-dora-resilience-operationnelle-hebergement-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"id":7,"slug":8,"slugs":9,"title":13,"excerpt":14,"readTime":15,"views":16,"isPinned":17,"publishedAt":18,"category":19,"categories":24,"featuredImage":26,"bgImage":27,"posterImage":28,"relatedSolution":26,"intro":29,"sections":30,"ctaTitle":123,"ctaBody":124,"ctaButton":125,"ctaUrl":126,"relatedPosts":127},328,"dora-resilience-operationnelle-hebergement",{"fr":8,"en":10,"ar":11,"es":12},"dora-what-the-regulation-requires-of-your-ict-contracts","dora-ما-يفرضه-النظام-على-عقود-تكنولوجيا-المعلومات","dora-lo-que-el-reglamento-exige-de-sus-contratos-tic","DORA : ce que le règlement exige de vos contrats TIC","DORA (UE 2022\u002F2554) impose des clauses précises dans tout contrat TIC. Articles 28 et 30 : obligations, droits d'audit, TLPT et localisation des données.",12,0,false,"2026-09-04T00:00:00+00:00",{"id":20,"name":21,"slug":22,"color":23,"icon":22},10,"Conformité & réglementation","conformite","bg-amber-500\u002F10 text-amber-400",[25],{"id":20,"name":21,"slug":22,"color":23,"icon":22},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fdora-resilience-operationnelle-hebergement-poster.svg","Depuis le 17 janvier 2025, le règlement DORA (UE 2022\u002F2554) est applicable dans l'ensemble de l'Union européenne. Toute entité financière — banque, assureur, prestataire de services de paiement, gestionnaire de fonds — doit démontrer que ses fournisseurs TIC satisfont à des exigences précises de résilience opérationnelle. L'hébergement de vos applications, de vos API et de vos bases de données entre directement dans ce périmètre. Voici ce que les articles 28, 29 et 30 imposent concrètement, et comment sélectionner un prestataire qui rend ces obligations vérifiables.",[31,35,44,47,50,69,72,104,107,110,114,117,120],{"type":32,"title":33,"body":34},"h2","Qu'est-ce que DORA et qui est vraiment concerné ?","Le règlement (UE) 2022\u002F2554, dit DORA pour Digital Operational Resilience Act, a été adopté le 14 décembre 2022 et est entré en application le 17 janvier 2025 — sans période de grâce. Son article 2 liste les entités couvertes : établissements de crédit, établissements de paiement, établissements de monnaie électronique, entreprises d'investissement, gestionnaires de fonds alternatifs, sociétés de gestion, plateformes de financement participatif, fournisseurs de services sur crypto-actifs, et compagnies d'assurance et de réassurance.\n\nLe périmètre est plus large que beaucoup ne l'anticipent. Une plateforme de paiement en ligne, un agrégateur de comptes bancaires ou une fintech proposant des services de change est soumise au règlement au même titre qu'une banque traditionnelle. Et dès qu'une entité financière sous-traite une fonction à un prestataire TIC — un hébergeur, un fournisseur cloud, un éditeur SaaS — ce prestataire entre dans le champ des obligations contractuelles de l'article 30.",{"type":36,"title":37,"items":38},"ul","Les cinq piliers de résilience que DORA impose",[39,40,41,42,43],"**Gestion des risques TIC** (articles 5 à 16) : cadre de gouvernance, cartographie des systèmes critiques, plans de continuité et de reprise documentés","**Gestion et classification des incidents** (articles 17 à 23) : détection, notification aux autorités compétentes dans des délais précis, rapports post-incident","**Tests de résilience opérationnelle** (articles 24 à 27) : tests de pénétration classiques annuels et TLPT (Threat-Led Penetration Testing) tous les trois ans pour les entités désignées","**Gestion des risques liés aux prestataires TIC tiers** (articles 28 à 44) : registre des contrats, due diligence, clauses contractuelles obligatoires, surveillance des fournisseurs critiques","**Partage d'information** (article 45) : participation volontaire aux dispositifs d'échange de renseignements sur les cybermenaces",{"type":32,"title":45,"body":46},"L'article 28 : le registre des contrats TIC comme fondation","L'article 28(3) de DORA exige que chaque entité financière tienne et mette à jour un **registre de tous les accords contractuels** conclus avec des prestataires TIC tiers. Ce registre n'est pas un simple tableau Excel : il doit être structuré selon les normes techniques d'exécution (ITS) publiées par les Autorités européennes de surveillance (EBA, ESMA, EIOPA) et être communicable aux autorités compétentes sur demande.\n\nConcrètement, chaque contrat d'hébergement VPS, de stockage objet ou de réseau de diffusion de contenu doit y figurer avec : le nom et le siège du prestataire, la description du service, la date de conclusion et d'expiration du contrat, la criticité de la fonction soutenue, la localisation des données et des centres de traitement, et les droits d'audit stipulés. Une mise à jour est obligatoire à chaque événement significatif : nouveau contrat, avenant, changement de sous-traitant, modification de localisation des données.\n\nLe registre doit être tenu aux niveaux individuel, consolidé et sous-consolidé — ce qui signifie que les groupes financiers doivent consolider les contrats de toutes leurs filiales concernées.",{"type":32,"title":48,"body":49},"L'article 30 : les clauses contractuelles minimales non négociables","L'article 30 de DORA définit le contenu minimal de tout contrat conclu entre une entité financière et un prestataire TIC tiers. Ces clauses ne sont pas des recommandations : leur absence expose l'entité financière à un écart réglementaire constaté lors d'un contrôle.\n\nL'article 30(2) impose pour tout contrat TIC : une description précise et complète des services fournis, les localisations — pays et centres de données — où les données sont traitées et stockées, les dispositions relatives à la disponibilité, à l'authenticité, à l'intégrité et à la confidentialité des données, la procédure en cas d'incident et les obligations d'assistance du prestataire, les droits de résiliation et les délais de préavis, et les obligations de coopération avec les autorités compétentes.\n\nL'article 30(3) ajoute, pour les fonctions critiques ou importantes, des obligations supplémentaires : droits d'audit complets et d'accès aux locaux du prestataire, participation du prestataire aux tests TLPT lorsque l'entité y est désignée, et stratégies de sortie documentées avec plan de transition vers un autre prestataire.",{"type":51,"title":52,"steps":53},"steps","Cinq vérifications à mener prestataire par prestataire",[54,57,60,63,66],{"title":55,"body":56},"Qualifier la criticité de la fonction hébergée","Avant d'examiner le contrat, classez la fonction que le prestataire supporte. Une base de données transactionnelle ou une API de paiement est critique. Un site vitrine sans données financières l'est probablement moins. La criticité détermine quelles clauses de l'article 30(3) s'appliquent — notamment les droits d'audit renforcés et la participation au TLPT.",{"title":58,"body":59},"Vérifier la localisation des données dans le contrat","L'article 30(2)(c) exige que les localisations — pays et centres de données — soient explicitement nommées. Un contrat qui dit « infrastructure européenne » sans préciser les pays ou les sites n'est pas conforme. Exigez une clause qui nomme les régions et stipule l'obligation de notification préalable en cas de déplacement des données.",{"title":61,"body":62},"Contrôler les droits d'audit et d'accès","Pour les fonctions critiques, l'article 30(3)(a) impose des droits d'audit complets — y compris l'accès physique aux locaux. Vérifiez que votre contrat ne limite pas l'audit à un questionnaire d'auto-évaluation ou à un rapport SOC 2 partagé. Ces documents peuvent compléter un audit, pas le remplacer. La clause doit stipuler un droit d'inspection par vos auditeurs internes ou externes.",{"title":64,"body":65},"Valider la clause de continuité et les délais de RTO\u002FRPO","DORA exige des plans de continuité documentés pour les fonctions critiques. Votre contrat doit mentionner les objectifs de temps de reprise (RTO) et de point de reprise (RPO) garantis par le prestataire, les procédures de notification en cas d'incident majeur, et les obligations de test périodique de ces plans. Un SLA de disponibilité seul ne suffit pas : il couvre la disponibilité nominale, pas la reprise après sinistre.",{"title":67,"body":68},"Documenter la stratégie de sortie","L'article 30(3)(e) rend obligatoire une stratégie de sortie pour les fonctions critiques. Elle doit couvrir : les délais de portabilité des données, les formats d'export, la durée de conservation des données après résiliation, et le plan de transition vers un autre prestataire. Sans cette clause, vous ne pouvez pas démontrer à votre autorité de contrôle que vous gérez le risque de concentration fournisseur.",{"type":32,"title":70,"body":71},"Le TLPT : qui est concerné et à quelle fréquence ?","Le Threat-Led Penetration Testing (TLPT), prévu par l'article 26 de DORA, est un test de pénétration avancé conduit sur les systèmes de production en conditions réelles, en s'appuyant sur des renseignements sur les menaces actuelles. Il se distingue des tests de pénétration classiques par sa profondeur et sa méthodologie pilotée par la menace.\n\nLe règlement délégué (UE) 2025\u002F1190, publié au Journal officiel le 18 juin 2025 et applicable depuis le 8 juillet 2025, fixe les normes techniques pour le TLPT. La fréquence est d'au moins une fois tous les trois ans. Ce n'est pas l'ensemble des entités financières couvertes par DORA qui doit s'y soumettre : les autorités compétentes désignent les entités significatives selon des critères d'impact, de stabilité financière et de risque TIC. Les estimations des Autorités européennes de surveillance portent sur environ 100 à 120 banques significatives, 40 à 60 groupes d'assurance, et une trentaine d'opérateurs d'infrastructures de marché pour le premier cycle 2025-2028.\n\nCe qui concerne directement l'hébergeur : lorsqu'une entité financière est désignée pour un TLPT, elle peut — et souvent doit — faire participer ses prestataires TIC fournissant des fonctions critiques. L'article 30(3)(b) oblige le prestataire à coopérer à ces tests. Si votre contrat d'hébergement ne prévoit pas cette clause, votre client financier est en écart réglementaire.",{"type":73,"title":74,"headers":75,"rows":79},"comparison","Contrat d'hébergement standard versus contrat conforme DORA",[76,77,78],"Clause","Contrat standard","Contrat conforme DORA art. 30",[80,84,88,92,96,100],[81,82,83],"Localisation des données","« Infrastructure européenne »","Pays et centres de données nommés, notification préalable obligatoire en cas de déplacement",[85,86,87],"Droits d'audit","Rapport SOC 2 partagé annuellement","Droit d'audit complet par auditeurs internes\u002Fexternes, accès aux locaux pour fonctions critiques",[89,90,91],"Gestion des incidents","Notification dans les 48 h","Procédure détaillée, classification, délais de notification aux autorités, rapport post-incident",[93,94,95],"Continuité","SLA de disponibilité mensuel","RTO\u002FRPO documentés, plan de continuité testé, obligations de test périodique",[97,98,99],"Participation aux tests","Non prévue","Clause de participation au TLPT obligatoire pour fonctions critiques (art. 30(3)(b))",[101,102,103],"Stratégie de sortie","Préavis de 30 jours","Plan de portabilité des données, formats d'export, durée de conservation post-résiliation documentée",{"type":32,"title":105,"body":106},"Localisation des données : pourquoi l'hébergement européen compte","DORA n'interdit pas l'hébergement hors Union européenne, mais il impose une traçabilité complète et une évaluation du risque de concentration géographique. Pour les fonctions critiques, l'article 28(4) exige d'évaluer les risques liés à la concentration des données dans un seul pays ou chez un seul prestataire dominant.\n\nEn pratique, les autorités de contrôle — l'ACPR pour les banques et assureurs français, l'AMF pour les entités de marché — regardent avec attention la localisation des données à caractère personnel financier, les données de paiement, et les données de marché. Un hébergement dans des datacenters situés en Union européenne simplifie la démonstration de conformité : la combinaison DORA + RGPD est plus facile à documenter quand les données ne franchissent pas les frontières de l'EEE.\n\nLes normes techniques de l'EBA précisent également que le registre des contrats doit mentionner si le prestataire recourt lui-même à des sous-traitants hors UE. Une chaîne de sous-traitance opaque est un point de fragilité lors d'un contrôle.",{"type":32,"title":108,"body":109},"Le risque de concentration fournisseur : ne pas mettre tous ses services chez un seul acteur","L'article 29 de DORA introduit la notion de **risque de concentration TIC**. Une entité financière doit évaluer le risque que représente le fait de confier plusieurs fonctions critiques à un même prestataire, ou à un petit nombre de prestataires appartenant au même groupe. Ce risque est systémique : si le prestataire subit un incident majeur, plusieurs fonctions critiques tombent simultanément.\n\nPour un acteur financier dont l'hébergement, la messagerie sécurisée et les API de reporting reposent sur un même fournisseur cloud dominant, DORA exige une stratégie de sortie et des alternatives documentées. Ce n'est pas une obligation de diversifier à tout prix, mais une obligation de prouver que la dépendance est connue, maîtrisée, et qu'un plan de continuité existe si ce prestataire devenait indisponible.\n\nCe cadre favorise les architectures distribuées : un hébergement VPS autonome pour les fonctions critiques, une solution de sauvegarde chez un second prestataire, et des procédures de bascule testées — plutôt qu'une dépendance totale à un hyperscaler unique dont les clauses contractuelles standard ne correspondent pas aux exigences de l'article 30.",{"type":111,"title":112,"body":113},"tip","Préparer le dossier prestataire avant le contrôle","Les autorités compétentes peuvent demander à consulter le registre des contrats TIC à tout moment. Constituez, pour chaque prestataire d'hébergement, un dossier comprenant : le contrat signé avec les clauses article 30 vérifiées, les certificats de conformité ou rapports d'audit disponibles (ISO 27001, SOC 2, attestation de pen test), la documentation de l'architecture hébergée et de la criticité de la fonction, et la procédure de sortie avec délais et formats d'export. Ce dossier n'est pas une formalité : c'est la preuve que vous avez exercé votre devoir de diligence tel qu'exigé par l'article 28(4).",{"type":32,"title":115,"body":116},"Sanctions : ce que DORA prévoit en cas de manquement","DORA ne fixe pas de plafond européen uniforme pour les sanctions pécuniaires visant les entités financières. L'article 50 du règlement demande à chaque État membre de conférer à ses autorités compétentes le pouvoir de prononcer des sanctions administratives et des mesures correctrices, en laissant les montants au droit national.\n\nEn France, le pouvoir de sanction appartient aux commissions des sanctions de l'ACPR (pour les établissements de crédit, établissements de paiement et assureurs) et de l'AMF (pour les acteurs de marché). Les dispositions françaises de transposition autorisent des amendes qui peuvent atteindre, selon les sources officielles consultées, jusqu'à 10 millions d'euros ou 5 % du chiffre d'affaires annuel total pour les entités, et jusqu'à 5 millions d'euros pour les personnes physiques responsables.\n\nAu-delà des amendes, les autorités disposent de mesures correctrices : injonctions de mise en conformité, astreintes, et dans les cas les plus graves, restrictions d'activité ou retrait d'agrément. La surveillance des fournisseurs TIC critiques relève d'un échelon européen : le **DORA Joint Oversight Department**, constitué en 2024 sous l'égide des trois Autorités européennes de surveillance (EBA, ESMA, EIOPA), coordonne la supervision directe des prestataires désignés critiques à l'échelle de l'UE.",{"type":32,"title":118,"body":119},"Ce que cela change concrètement pour le choix d'un hébergeur","Pour une entité financière soumise à DORA ou pour l'agence qui gère son infrastructure, le choix d'un hébergeur ne peut plus se faire uniquement sur des critères de prix ou de performance. Quatre critères opérationnels s'ajoutent au cahier des charges.\n\nPremièrement, la **documentabilité** : le prestataire peut-il fournir une description précise des services, la localisation des centres de données, et les garanties de disponibilité sous une forme intégrable au registre des contrats ? Deuxièmement, les **droits d'audit** : accepte-t-il contractuellement un droit d'audit par les auditeurs de l'entité financière, et pas seulement un partage de rapports tiers ? Troisièmement, la **résilience documentée** : dispose-t-il de plans de continuité testés, d'une alimentation redondante, d'un réseau dupliqué, et de sauvegardes dont la fréquence et la rétention sont contractuellement stipulées ? Quatrièmement, la **portabilité** : en cas de résiliation, sous quel délai et sous quel format les données sont-elles restituées ?\n\nCes quatre critères ne sont pas propres à DORA : ils définissent ce qu'un hébergement professionnel sérieux doit offrir à n'importe quelle organisation qui héberge des données sensibles. DORA les rend obligatoires et contrôlables pour les entités financières.",{"type":32,"title":121,"body":122},"DORA et CRA : deux règlements complémentaires, deux angles distincts","DORA et le Cyber Resilience Act (CRA, règlement (UE) 2024\u002F2847) sont souvent cités ensemble, mais ils ne couvrent pas la même chose. DORA s'adresse aux **entités financières et à leurs fournisseurs TIC** : il régit la résilience opérationnelle d'un secteur. Le CRA s'adresse aux **fabricants et éditeurs de produits comportant des éléments numériques** : il impose des exigences de cybersécurité sur les produits mis sur le marché de l'UE, indépendamment du secteur.\n\nEn pratique, une entité financière qui déploie des logiciels open source sur ses serveurs est concernée par les deux : par DORA pour la gestion du risque TIC de son prestataire d'hébergement, et potentiellement par le CRA si elle modifie ou distribue des composants logiciels. Pour le détail des obligations CRA applicables à l'hébergement, l'article \u003Ca href=\"\u002Fblog\u002Fcra-cyber-resilience-act-hebergement-2027\">CRA et hébergement\u003C\u002Fa> couvre ce volet.","Un hébergement dont chaque clause est vérifiable","ServOrbit héberge dans des datacenters européens avec alimentation redondante, réseau dupliqué et sauvegardes quotidiennes documentées. Les éléments que les articles 28 et 30 de DORA exigent de retrouver dans tout contrat avec un prestataire TIC à risque.","Voir les offres professionnelles","\u002Fsolutions\u002Fprofessionnels",[128,143,163],{"id":129,"slug":130,"slugs":131,"title":135,"excerpt":136,"readTime":137,"views":16,"isPinned":17,"publishedAt":138,"category":139,"categories":140,"featuredImage":26,"bgImage":27,"posterImage":142,"relatedSolution":26},267,"cra-cyber-resilience-act-hebergement-2027",{"fr":130,"en":132,"ar":133,"es":134},"cra-2027-what-the-cyber-resilience-act-changes-for-your-agency","cra-2027-ما-يغيره-قانون-المرونة-الإلكترونية-لوكالتك","cra-2027-cyber-resilience-act-agencias","CRA 2027 : ce que le Cyber Resilience Act change pour vous","Le Cyber Resilience Act (CRA) entre en vigueur en décembre 2027. Ce qu'il oblige, ce qu'il pénalise, et comment préparer votre agence dès maintenant.",11,"2026-08-15T00:00:00+00:00",{"id":20,"name":21,"slug":22,"color":23,"icon":22},[141],{"id":20,"name":21,"slug":22,"color":23,"icon":22},"\u002Fblog\u002Fcovers\u002Fcra-cyber-resilience-act-hebergement-2027-poster.svg",{"id":144,"slug":145,"slugs":146,"title":150,"excerpt":151,"readTime":137,"views":152,"isPinned":17,"publishedAt":153,"category":154,"categories":160,"featuredImage":26,"bgImage":27,"posterImage":162,"relatedSolution":26},317,"linux-hardening-vps-checklist",{"fr":145,"en":147,"ar":148,"es":149},"linux-vps-hardening-checklist-for-agencies","قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم","hardening-linux-vps-checklist-para-agencias-tras-la-entrega","Durcissement Linux VPS : checklist agence après livraison","Checklist de durcissement Linux pour agences : auditd, sudo, SSH par clé, UFW, fail2ban et désactivation root — traçabilité et runbook par client.",1,"2026-08-30T00:00:00+00:00",{"id":155,"name":156,"slug":157,"color":158,"icon":159},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[161],{"id":155,"name":156,"slug":157,"color":158,"icon":159},"\u002Fblog\u002Fcovers\u002Flinux-hardening-vps-checklist-poster.svg",{"id":164,"slug":165,"slugs":166,"title":170,"excerpt":171,"readTime":172,"views":152,"isPinned":17,"publishedAt":173,"category":174,"categories":178,"featuredImage":26,"bgImage":27,"posterImage":180,"relatedSolution":26},238,"heberger-serveur-email-vps-mailcow",{"fr":165,"en":167,"ar":168,"es":169},"hosting-your-own-email-server-on-a-vps-with-mailcow","استضافة-خادم-البريد-الإلكتروني-على-vps-باستخدام-mailcow","alojar-servidor-correo-vps-mailcow","Héberger son serveur e-mail sur VPS avec Mailcow","Installez Mailcow sur un VPS Linux pour héberger votre serveur e-mail souverain : installation, délivrabilité et migration depuis Google Workspace.",13,"2026-08-08T00:00:00+00:00",{"id":137,"name":175,"slug":176,"color":177,"icon":176},"E-mail professionnel","emails","bg-cyan-500\u002F10 text-cyan-400",[179],{"id":137,"name":175,"slug":176,"color":177,"icon":176},"\u002Fblog\u002Fcovers\u002Fheberger-serveur-email-vps-mailcow-poster.svg",1788538429212]