Faille PHP ce que l'on sait pour les sites brésiliens

La faille PHP divulguée le 21 octobre 2026 peut permettre à quelqu'un sur Internet d'exécuter des commandes sur le serveur sans se connecter. La faille PHP est une faiblesse dans le moteur qui traite les requêtes web, et non un simple défaut de plugin. Les failles ont reçu les codes CVE-2026-109618 et CVE-2026-109619, surnommées php2shell par la communauté de sécurité, ce qui a poussé la presse et des organismes officiels à demander une action le même jour.

Si vous êtes propriétaire de site, gestionnaire ou responsable d'un service en ligne et que vous ne programmez pas, la question pratique est ailleurs. Votre site est-il exposé, qui doit agir, et que demander par écrit à l'hébergeur ou au développeur. Ce texte s'adresse aussi au lecteur francophone qui ne vit pas au Brésil, car le cas brésilien reste l'axe de la journée, avec ses alertes officielles et ce qui, jusqu'au 21 octobre 2026, n'est pas confirmé en public. Il sépare ce que la presse a rapporté de ce que les sources officielles confirment.

Le guide technique de correction du php2shell du Basilisk décrit déjà le détail des correctifs. Ici, l'objectif est le contexte, la priorité et la décision pour faire pression sur le fournisseur sans devenir administrateur de serveur.

Que s'est-il passé avec PHP et pourquoi cela a fait la une#

Cela a fait la une parce que la faille PHP ne se trouve pas dans un plugin isolé, mais dans le moteur PHP qui traite les requêtes web. En langage simple, l'exécution de code à distance sans authentification signifie qu'un attaquant peut tenter de faire exécuter des commandes au serveur comme s'il était le système lui-même, sans identifiant ni mot de passe du site.

Ce que décrivent les sources techniques#

Le projet PHP a décrit deux faiblesses. L'une concerne un manque de mémoire. L'autre concerne un état interne qui persiste entre les requêtes. L'avis officiel figure dans les archives d'actualités 2026 de php.net. La gravité officielle en CVSS version 4.0 est de 9,2 sur 10 pour les deux failles. Certaines bases et reportages citent des notes dans d'autres versions du CVSS, comme 9,8 ou même 10,0. Pourtant, le chiffre que l'avis des 20 et 21 octobre 2026 du PHP et l'enregistrement CVE mettent en avant reste 9,2.

Ce que la presse a souligné le même jour#

Selon la BBC News Brasil, des gouvernements et organismes de plusieurs pays ont recommandé une correction urgente. Lorsque la correction ne pouvait pas tenir dans le délai, ils ont demandé une suspension temporaire de pages. L'article cite des coupures ou des précautions en Finlande, à la mairie d'Édimbourg et sur des plateformes de la BBC elle-même. Il mentionne aussi des organes aux Pays-Bas et des mesures de la Wikimedia autour de Wikipédia. La BBC a encore enregistré l'estimation selon laquelle environ 70 % d'Internet utiliserait PHP, tout en précisant qu'elle n'avait pas pu vérifier ce pourcentage.

En pratique, ce que je vois le plus souvent, c'est le gestionnaire qui croit avoir mis à jour WordPress dans le panneau et se sentir déjà protégé. Pour cette faille PHP, la protection complète passe par la version de PHP sur le serveur, et non seulement par le système de contenu. Traiter le sujet comme un problème de plugin retarde le seul remède que le projet PHP décrit lui-même comme sûr.

Chronologie publique de la faille PHP#

La chronologie publique de la faille PHP commence des mois avant le titre, puis se referme le 21 octobre 2026. Comprendre cette ligne aide à séparer la découverte discrète, l'avis préalable et la sortie des versions corrigées, sans confondre rumeur et avis officiel. Pour le lecteur francophone, cette chronologie explique aussi pourquoi la France et d'autres pays européens apparaissent dans la presse le même jour que les alertes brésiliennes.

De la découverte en août 2026 à l'avis préalable#

En août 2026, des chercheurs de Calif, d'OpenAI puis de Wiz ont identifié et approfondi les failles. Ils ont travaillé en divulgation coordonnée et discrète pendant que les correctifs étaient préparés, selon les récits techniques de ces entreprises et la couverture qui a croisé le processus. Le 20 octobre 2026, le projet PHP a annoncé qu'il y aurait une publication de sécurité le lendemain, à 14h00 UTC. La Fondation PHP a aussi enregistré que des identifiants CVE avaient circulé avec une note erronée de 10,0 et un horaire incorrect, ce qui a anticipé l'avis public.

Le 21 octobre 2026 et les versions corrigées#

Le 21 octobre 2026, les versions corrigées sont sorties et les failles ont commencé à être discutées ouvertement. Les versions officielles corrigées, selon php.net, la CISA et la Recommandation 19/2026 du CTIR Gov (centre brésilien de réponse aux incidents, rattaché au cabinet de sécurité institutionnelle), sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP 8.1 et les versions antérieures ne reçoivent plus de mise à jour régulière du projet. Il existe une mention publique de backports minimaux de code source pour 7.4, 8.0 et 8.1 pour qui compile à partir des sources ou dispose d'un fournisseur LTS. L'orientation officielle consiste donc à parler au fournisseur de la distribution ou à migrer vers une ligne supportée.

Où les sources divergent sur le périmètre#

Sur un point, les sources divergent et cela doit rester transparent. Des entreprises comme Google Cloud, Cloudflare et Wiz ont parlé d'un risque depuis des versions très anciennes, y compris à partir de PHP 5.4. L'enregistrement CVE et l'annonce de l'équipe de sécurité de PHP listent explicitement les lignes 8.2 à 8.5 corrigées, et traitent 8.1 et plus anciennes comme hors support officiel. Pour le propriétaire de site, la lecture prudente est la plus restrictive. Si votre environnement tourne encore sur un PHP ancien, ne supposez pas être hors périmètre seulement parce que le tableau CVE met en avant 8.2 et au-delà.

L'erreur qui coûte le plus cher ici est d'attendre la prochaine fenêtre de maintenance du mois comme s'il s'agissait d'une mise à niveau cosmétique. Le 21 octobre 2026, les agences ont demandé une action immédiate face à cette faille PHP. Le retard devient donc une exposition tant que des preuves de concept et des tentatives circulent déjà dans des récits ouverts.

Ce que l'on sait sur la faille PHP sites brésiliens#

Jusqu'au 21 octobre 2026, le dossier faille PHP sites brésiliens repose surtout sur des alertes officielles, et non sur un inventaire public d'incidents locaux nommés. Il existe une confirmation publique de réponse institutionnelle brésilienne. En revanche, les articles vérifiés pour cette rédaction ne montrent pas d'inventaire officiel de sites brésiliens mis hors ligne ni d'hébergeurs nationaux retenus comme compromis à cause de cette faille PHP.

Alertes fédérales brésiliennes jusqu'au 21 octobre 2026#

Le CTIR Gov a publié la Recommandation 19/2026 demandant d'identifier les systèmes avec PHP et de mettre à jour immédiatement. L'Alerte 93/2026 a renforcé la même ligne avec référence aux deux CVE. Le CISC GOV.BR, canal fédéral brésilien d'alertes de cybersécurité, a aussi enregistré une alerte sur les mêmes vulnérabilités. Cela montre une mobilisation du gouvernement fédéral. Cela ne prouve pas à lui seul combien de portails brésiliens sont sortis de l'air.

Ce que dit la presse et ce qui reste sans preuve locale#

Dans la couverture journalistique en portugais, l'article du UOL Cotidiano et la pièce de la BBC News Brasil traitent surtout du tableau international et de la pression pour retirer des services. La France, les Pays-Bas, la Finlande et d'autres exemples européens apparaissent avec des coupures préventives. Pour un lecteur en France ou dans un pays francophone, ces exemples européens sont familiers, tandis que l'impact au Brésil en nombre de sites hors ligne, d'entreprises touchées ou d'hébergeurs précis reste sans confirmation publique nommée jusqu'à la date de cet article.

Le thème php2shell au Brésil, à cette date, apparaît donc comme alerte et orientation, non comme inventaire d'incidents locaux. Cela ne signifie pas un risque faible pour le pays. Cela signifie que la preuve publique, au 21 octobre 2026, est celle de l'alerte et de l'orientation. Beaucoup de sites brésiliens utilisent PHP via WordPress, Joomla, Drupal, Magento et des systèmes sur mesure. Le risque existe partout où une installation vulnérable est exposée à Internet.

La preuve d'une exploitation déjà réussie au Brésil est une autre affirmation, et elle n'apparaît pas encore confirmée dans les sources officielles ouvertes consultées. Beaucoup pensent que l'absence de manchette locale équivaut à l'absence de risque, et presque toujours ils se trompent, parce que l'attaquant n'a pas besoin d'une une nationale pour balayer Internet. Le critère utile reste la version de PHP de votre serveur et l'exposition publique, pas le volume de reportages avec le mot Brésil dans le titre, y compris quand on parle de faille PHP.

Qui est vraiment exposé et qui l'est probablement moins#

Est vraiment exposé celui qui a un site ou un système web tournant avec une version de PHP antérieure aux versions corrigées et accessible depuis Internet. La faille PHP concerne donc d'abord l'exposition publique, pas le seul fait d'avoir un CMS.

Sites et systèmes exposés sur Internet#

L'avis du PHP inclut les installations qui traitent des requêtes web en PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet lui-même évalue un risque plus élevé avec mod_php, avec une exploitation démontrée par une requête sans connexion avant même que le code du site ne s'exécute. La CISA et le NCSC du Royaume-Uni ont aligné la même urgence pour les organisations avec un PHP orienté web.

Qui passe en priorité plus basse et les pièges#

N'est probablement pas au même niveau d'urgence celui qui n'utilise pas PHP sur le serveur public. Les exemples incluent les sites statiques sans moteur PHP, ou les applications dans d'autres langages sans composant PHP intégré. Il reste toutefois un piège. Des produits, panneaux, appliances et images de conteneurs peuvent embarquer PHP sans que le gestionnaire s'en aperçoive. La CISA a rappelé que PHP est souvent un composant d'un autre logiciel et que sa présence peut ne pas être évidente dans l'inventaire.

Une autre nuance compte. Mettre à jour le thème WordPress ou installer un plugin de sécurité ne ferme pas cette faille PHP. La correction complète consiste à mettre à jour le PHP du serveur vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou à recevoir un backport fiable du fournisseur lorsque la ligne est ancienne. Un pare-feu d'application web peut réduire l'exposition sur certains chemins. Cloudflare a communiqué des protections dans le WAF. Pourtant, le projet PHP et la CISA traitent la mise à jour comme seul remède complet. Une mitigation temporaire ne devient pas un certificat de sécurité.

En pratique, ce que je vois le plus souvent dans les entreprises moyennes, c'est le site institutionnel en hébergement mutualisé et l'ERP interne sur un autre serveur, avec seule l'équipe marketing sollicitée. Les deux ont besoin d'inventaire. Si l'ERP parle PHP et a une interface web, il entre dans la file de priorité avec le blog, car la faille PHP ne choisit pas le service selon l'organigramme.

Ce que le propriétaire de site doit faire le 21 octobre 2026#

Le 21 octobre 2026, la réponse pratique de vulnérabilité PHP que faire pour le non-spécialiste consiste à exiger des preuves. Ce n'est pas d'improviser des commandes sur le serveur. Les étapes ci-dessous portent sur la gestion et la priorité face à la faille PHP. Le détail technique du correctif reste dans le guide technique de correction du php2shell.

Inventaire et version exacte#

1. Listez où il existe un site ou un système web sous votre responsabilité, y compris boutique, espace étudiant, intranet exposé, formulaire de médiation et panneau d'affiliés. Incluez ce qu'un fournisseur héberge pour vous.
2. Écrivez à l'hébergeur ou à l'équipe informatique pour obtenir la version exacte de PHP qui tourne dans chaque environnement, au format majeur.mineur.patch, par exemple 8.3.36. La réponse « PHP 8 » sans le patch ne suffit pas.
3. Exigez confirmation que la version est déjà en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou que le fournisseur a appliqué une correction backport documentée pour une ligne ancienne. Précisez aussi le délai et l'horaire prévus si ce n'est pas encore fait.

Priorité, surveillance et ce qu'il faut refuser#

1. Priorisez ce qui est sur Internet public. La CISA recommande de mettre hors ligne ce qui ne peut pas être corrigé immédiatement, surtout en PHP 8.1 ou antérieur sans correctif du fournisseur. Cette décision a un coût métier et doit être consciente, non théâtrale.
2. Faites décrire au fournisseur ce qu'il surveillera dans les heures et jours suivants, comme des processus PHP inhabituels, des fichiers nouveaux et des connexions sortantes inattendues. Surveiller ne remplace pas le correctif, et aide à détecter un abus si quelqu'un est arrivé avant.
3. Refusez le nettoyage miracle vendu par message froid ou publicité. Sans diagnostic et sans preuve, cela devient souvent une arnaque ou une dépense inutile. Le chemin légitime reste le fournisseur contracté, l'équipe interne ou un professionnel avec contrat et responsabilité définis.
4. Si votre organisation a déjà, ou devrait avoir, un programme de gestion des vulnérabilités, utilisez cet incident pour tester si l'inventaire logiciel existe vraiment. Si personne ne sait où tourne PHP, le problème est plus large que cette CVE.

Chaque recommandation ci-dessus a une limite. Obtenir la version ne garantit pas une réponse honnête. Mettre le site hors ligne peut interrompre un service public ou une vente. La surveillance ne fonctionne que si quelqu'un lit l'alerte. Le bénéfice est de réduire la fenêtre pendant laquelle un attaquant trouve encore le serveur vulnérable. Le risque de ne pas agir est de laisser la porte ouverte pendant que des preuves de concept circulent autour de la faille PHP.

Le chemin que je recommande à la plupart des gestionnaires sans équipe propre est un e-mail court le 21 octobre 2026, avec copie au commercial de l'hébergement et à celui qui paie la facture, demandant version, statut du correctif et délai. Une relance documentée change la priorité du fournisseur plus vite qu'un ticket générique de vérification de sécurité.

Que demander à l'hébergeur ou au développeur#

Posez des questions dont la réponse soit vérifiable, afin d'éviter le « tout va bien » sans numéro. Pour hébergement PHP mettre à jour, le critère reste la version complète et l'horaire d'application. Sans ces deux éléments, vous n'avez pas de preuve que la faille PHP a été traitée sur votre environnement.

Checklist écrite pour l'hébergeur#

Commencez par la version actuelle de PHP sur chaque site, puis l'horaire auquel la correction a été ou sera appliquée. Vérifiez ensuite s'il y a eu redémarrage des processus PHP après la mise à jour. Clarifiez s'il existe un WAF et s'il a été ajusté seulement comme couche supplémentaire. Interrogez aussi le plan prévu si la mise à jour casse un système legacy. Ensuite, faites confirmer à nouveau le numéro de version au format complet.

Clarifiez aussi ce qui arrive avec PHP 8.1, 8.0, 7.4 ou plus ancien dans votre contrat. Le projet PHP ne maintient pas ces lignes dans le flux normal. Soit le fournisseur a un backport, soit la migration vers une ligne supportée a besoin d'un délai et de tests. Une réponse du type « nous allons évaluer » sans date est faible pour une faille de cette classe.

Comment relier hébergeur et développeur#

Pour une institution publique et une entreprise avec un fournisseur de logiciel sur mesure, incluez la question sur les produits qui embarquent PHP sans ressembler à un site WordPress. Panneaux, portails de protocole et systèmes d'inscription cachent souvent le langage. Le CTIR Gov a demandé précisément que les institutions identifient systèmes, serveurs, applications et services qui utilisent PHP, et non seulement la page d'accueil institutionnelle.

Un piège courant est d'accepter une capture d'écran du panneau disant serveur sécurisé sans numéro de version. Un autre est de confondre la mise à jour du panneau d'hébergement avec la mise à jour du PHP du site. Si la réponse reste vague, rouvrez le ticket avec les identifiants CVE-2026-109618 et CVE-2026-109619, pour que l'équipe technique sache exactement quel avis traiter.

En pratique, ce que je vois le plus souvent, c'est le développeur de l'application qui dit que son code va bien et l'hébergeur qui dit que le client doit autoriser la montée de version. Les deux peuvent avoir partiellement raison pendant que le site reste vulnérable au milieu. Votre question doit relier les bouts et nommer qui applique le binaire PHP, sinon la faille PHP reste ouverte entre deux responsabilités.

Ce que l'on ignore encore au 21 octobre 2026#

Il n'est pas encore tranché, dans une source officielle unique, la portée réelle d'une exploitation réussie en production au 21 octobre 2026. Cette incertitude concerne aussi bien le Brésil que le reste du monde, et elle n'annule pas l'urgence de la faille PHP.

Exploitation observée ou non selon les agences#

La CISA a écrit qu'au moment de la publication de l'alerte, elle n'avait pas observé d'exploitation de ces vulnérabilités. Elle a tout de même classé le risque comme urgent si le correctif n'est pas appliqué. Le Centre canadien pour la cybersécurité a enregistré des récits ouverts de preuve de concept et a affirmé n'avoir pas identifié d'exploitation active à ce moment-là, avec la réserve que cela peut changer vite. Cloudflare, de son côté, a communiqué des protections dans le WAF et dit avoir observé du trafic d'attaque tôt dans la journée, en traitant la protection comme palliatif tant que le correctif n'arrive pas.

Ce qui manque encore côté Brésil et versions anciennes#

Il n'y a pas non plus, jusqu'à cette date, de confirmation publique consolidée du nombre de sites brésiliens compromis ni du nombre d'hébergeurs nationaux ayant déjà fermé 100 % de la base. Il n'existe pas de liste officielle simple de tous les produits touchés au Brésil, parce que PHP apparaît embarqué dans des piles différentes. Et la situation de chaque ancienne version n'est pas résolue de façon identique. Les fournisseurs LTS et les distributions peuvent publier des paquets à des rythmes distincts.

Cette incertitude n'autorise pas l'attente. Elle signifie que le gestionnaire doit traiter le correctif comme une priorité haute même sans avoir vu le nom de son entreprise dans le journal. Ce qui change la réponse, c'est une nouvelle preuve d'exploitation massive ou le communiqué de votre fournisseur indiquant que l'environnement est déjà sur les versions corrigées.

L'erreur qui coûte le plus cher ici est de transformer « pas encore confirmé » en « alors je suis en sécurité ». En sécurité, l'absence de confirmation publique d'abus n'est pas un certificat négatif. C'est seulement l'état de la connaissance à cet horaire face à la faille PHP.

Ce que disent les sources officielles et où suivre#

Les sources qui comptent pour le fait technique sont l'avis de php.net, les advisories GHSA du dépôt php-src, les enregistrements CVE et les alertes d'agences. Au Brésil, suivez le CTIR Gov, le CISC GOV.BR et les communications de votre secteur. Aux États-Unis, la CISA a publié une alerte le 21 octobre 2026 demandant un correctif immédiat et, si nécessaire, de retirer de la ligne les systèmes PHP sans correction. Au Royaume-Uni, le NCSC a décrit le problème de corruption lié au manque de mémoire et le risque d'exécution à distance sans authentification.

Pour le gestionnaire, la règle pratique reste simple. La manchette explique le climat. L'avis officiel définit la version corrigée et ce qui compte comme remède complet contre la faille PHP. Si un réseau social dit qu'il existe déjà un exploit universel pour n'importe quel site, vérifiez sur php.net et auprès de l'agence avant de payer un service d'urgence à un inconnu.

Suivre signifie aussi demander au fournisseur un retour après le correctif, et non seulement la promesse. Version installée, date et heure, et s'il y a eu régression sur une application. Une mise à jour précipitée peut casser un système ancien. Une coupure contrôlée à une heure convenue reste préférable à une intrusion silencieuse.

Beaucoup pensent qu'il suffit d'enregistrer le lien de la news dans le groupe de l'équipe, et presque toujours ils se trompent, parce que le lien ne change pas la version du serveur. Le suivi utile se referme avec une preuve de votre environnement, pas avec une capture de titre sur la faille PHP.

Questions fréquentes sur la faille PHP#

Ces questions regroupent les doutes les plus courants des propriétaires de site et des gestionnaires sans formation technique. Les réponses sont volontairement courtes, pour que vous puissiez les réutiliser dans l'e-mail à l'hébergeur ou dans la réunion avec le développeur encore le 21 octobre 2026, sans devoir reformuler le jargon des CVE ni celui des agences, y compris lorsque le sujet porte sur la faille PHP dans un contexte brésilien.

Mon site utilise WordPress. Mettre à jour WordPress suffit-il ?#

Non, pas à lui seul. WordPress s'exécute sur le PHP du serveur. La correction complète exige que l'hébergeur ou l'administrateur mette à jour PHP vers l'une des versions corrigées ou applique un backport du fournisseur. Mettre à jour seulement le noyau, le thème ou un plugin WordPress ne remplace pas cela, même si ces mises à jour restent utiles pour d'autres risques liés à la faille PHP côté serveur.

Si l'hébergeur a un pare-feu, puis-je attendre ?#

Un pare-feu d'application peut réduire certains chemins d'attaque, et des fournisseurs de protection comme Cloudflare ont communiqué des règles spécifiques. Le projet PHP et la CISA traitent la mise à jour de PHP comme seule solution complète. Attendre uniquement derrière le pare-feu laisse un risque résiduel et peut échouer lorsque l'attaquant change la forme de la requête face à la faille PHP.

Des organismes et entreprises au Brésil ont-ils déjà été touchés ?#

Jusqu'au 21 octobre 2026, il existe des alertes et recommandations du CTIR Gov et du CISC, et il n'y a pas, dans les sources vérifiées pour cet article, de confirmation publique nommée d'un compromis massif de sites brésiliens par cette faille. L'absence de liste publique n'élimine pas le risque de votre environnement s'il reste encore vulnérable à la faille PHP.

Un PHP ancien, comme 7.4 ou 8.1, est-il hors de danger ?#

Non. Le projet PHP ne livre pas de correctif régulier sur ces lignes et recommande de parler au fournisseur LTS ou de migrer. Il existe des backports minimaux de code source pour qui compile, et des distributions peuvent publier leurs propres paquets. Tant qu'aucune correction n'est appliquée sur votre serveur, le risque lié à la faille PHP demeure.

Payer une entreprise qui propose un nettoyage php2shell est-il une bonne idée ?#

En général, non, si l'approche est froide, sans contrat préalable et sans diagnostic. Le chemin sûr est le fournisseur qui opère déjà le serveur, l'équipe interne ou un professionnel contracté avec un périmètre écrit. Mettre le site hors ligne et appliquer le correctif officiel traite la vulnérabilité. Un nettoyage sans preuve d'intrusion devient souvent une dépense ou une arnaque autour de la faille PHP.

Où vérifier l'information officielle sans dépendre des réseaux sociaux ?#

Commencez par l'avis sur php.net, les enregistrements CVE-2026-109618 et CVE-2026-109619, l'alerte de la CISA et, au Brésil, les publications du CTIR Gov. Pour votre cas concret, la confirmation qui compte est la version de PHP indiquée par écrit par l'hébergeur ou par l'informatique, car c'est elle qui ferme ou laisse ouverte la faille PHP.

Conclusion#

La faille PHP divulguée le 21 octobre 2026 est assez grave pour faire retirer des pages dans plusieurs pays et pour déclencher des alertes officielles au Brésil, et pourtant le geste qui protège votre site reste prosaïque. Découvrir la version exacte de PHP, exiger la mise à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou le backport du fournisseur, et ne pas confondre cela avec la seule mise à jour du système de contenu.

Pour la plupart des propriétaires de site et gestionnaires sans équipe de sécurité, le premier pas est l'e-mail documenté à l'hébergeur et au développeur encore le 21 octobre 2026, avec les deux CVE dans l'objet et la demande de version complète après le correctif. La réponse change si le système est legacy sans support, s'il existe une obligation de continuité de service public ou s'il y a déjà un indice d'abus. Dans ces cas, la décision peut inclure un isolement temporaire et un appui spécialisé, toujours avec le coût et le risque explicites.

Ignorez qui vend un miracle et ignorez aussi la tentation de croire que l'absence de manchette avec le nom de votre entreprise est un bouclier. La protection réelle apparaît lorsque la version corrigée est installée et qu'une personne responsable le confirme par écrit.

Ce texte a un caractère informatif et éducatif sur la faille PHP et l'impact potentiel sur les sites au Brésil. Il ne remplace pas l'évaluation de votre fournisseur d'hébergement, de votre équipe de sécurité ou d'un professionnel contracté pour votre environnement précis.