Protéger les Environnements de Simulation en résumé

Évitez les situations embarrassantes en vous assurant que vous protégez correctement vos environnements de simulation.

La meilleure façon de le faire est d’utiliser l’authentification HTTP.

Votre environnement de simulation est déjà indexé par les moteurs de recherche? Pas de souci. Avec ce guide, vous apprendrez comment renverser la situation rapidement et efficacement.

On en voit tous les jours : des environnements de simulation ou de développement contenant des sites web en construction, laissez accessibles au monde entier. Et souvent, ils sont aussi indexés par les moteurs de recherche!

Vous ne me croyez pas?

Aller voir cette requête – inspiré par le tweet de Peter Nikolow (suivez-le sur Twitter, il est drôle et intelligent!).

En quoi avoir un environnement de simulation accessible est une mauvaise chose

Ou plutôt, une double mauvaise idée : une mauvaise idée d’un point de vue business et SEO.

D’un point de vue business

Est-ce que vous voulez vraiment que d’autres personnes puisses voir votre contenu “lorem impsum” et qu’elles s’en moquent? Ou pire encore : qu’elles y apprennent une annonce très importante comme une acquisition ou un changement d’image qui aurait du rester secret jusqu’au jour du lancement du nouveau site?

Ce n’est pas professionnel, et surtout pas très intelligent. C’est même une technique de ventes pour certaines agences : elles cherchent d’autres agences qui font ce genre d’erreur et en parlent à leurs clients, profitant de cette situation embarrassante.

Dawn Anderson
Dawn Anderson

Les URLs de simulation (indexés) permettent à la concurrence de voir vos futurs plans de développement. Ils ont juste besoin de suivre un URL de développement qu’ils auraient découvert pour accéder à tout l’environnement de simulation de votre site, c’est-à-dire que toute votre stratégie web futur et tous vos designs sont révélés. Une simple recherche Google de site:staging.* ou site:test.* ou n’importe quel autre nom communément donné aux sous-domaines par les équipes de développement pour leurs environnements de simulation nous donne pléthore d’environnements de simulation, appartenant même parfois à des marques connues qui n’ont pas suffisamment protégé leurs environnements.

De plus, les environnements de simulation étant souvent (au mieux) des produits à moitié construits, les visiteurs qui tombent sur ces sites auront une expérience utilisateur désastreuse, ce qui ne risque pas de faire bonne impression.

D’un point de vue SEO

En plus de tout ça, avoir un environnement de simulation qui est indexé par les moteurs de recherche peut mener à des problèmes de contenu dupliqué lorsque l’environnement de simulation et l’environnement de production sont très similaires.

Avoir un environnement de simulation accessible et indexé est complètement inutile, et c’est une situation facile à éviter. Dans cet article nous vous montrerons comment faire, quelle méthode utiliser et quoi faire si votre environnement de simulation a déjà été indexé.

À partir d’ici, lorsque nous ferons référence aux environnements de simulation, cela pourra aussi englober les environnements de simulation, de test, ainsi que les environnements de développement.

Lorsque je suis à la recherche de contenu dupliqué en faisant l’audit d’un site, je découvre régulièrement des environnements de simulation du site qui n’ont pas été correctement protégés. Parfois il s’agit de simulations obsolètes des versions précédentes du site, mais de temps en temps je découvre des sites en cours de développement qui n’ont pas encore été lancés et qui contiennent des informations confidentielles qui ne sont pas prêtes à être publiées. Les environnements de simulation non protégés ne sont pas seulement un problème de SEO : c’est aussi un risque pour les affaires qui devrait être traité avec précaution.

Sam McRoberts
Sam McRoberts

Je rencontre quotidiennement deux problèmes à ce sujet : les sites qui hébergent eux-mêmes la simulation (comme par exemple WPEngine qui génère staging.domain.com automatiquement), et les environnements de simulation qui sont sur les domaines de leurs développeurs (par ex. client.developer.com et developer.com/client/).

Dans le premier scénario, vous courrez le risque d’avoir du contenu dupliqué indexable sur votre propre domaine, et bloquer un domaine via le fichier robots.txt ne garantit pas qu’il ne sera pas indexé, en particulier si vous ou d’autres personnes le mette en lien (ce qui est fréquent, parce que les liens vers le site de développement se retrouvent souvent dans le code du site et sont oubliés lors du lancement).

Dans le second scénario, avec un miroir de votre site sur le domaine d’un développeur, vous courrez le risque d’avoir un problème de contenu dupliqué à travers les deux domaines, et puisque le contenu était en premier lieu sur le domaine du développeur, il y a un risque que Google vous voit comme celui ou celle qui a dupliqué le contenu à la source originelle (ce qui n’est pas une bonne situation).

Bloquez toujours l’accès à votre environnement de simulation aux bots. Toujours. Et pas seulement avec un fichier robots.txt, mais avec quelque chose plus sécurisé (login/mot de passe, accès IP restreint, voir les deux).

Deuxièmement, assurez-vous toujours que vos développeurs vérifient tout le code de votre site lors du lancement et qu’ils enlèvent les liens vers l’environnement de simulation. Vous voulez que vos liens internes mènent au site en ligne et pas autre part.

Si vous faîtes les deux, vous vous en sortirez!

Qu’est ce qu’un environnement de simulation et un environnement de développement?

Lorsque vous travaillez sur un site complètement nouveau ou une nouvelle fonctionnalité, vous ne le faites pas sur votre site en ligne (souvent appelé “environnement de production”), parce que les sites web sont fragiles. Il vaut mieux travailler avec différents environnements séparés où vous pouvez développer et tester de nouvelles fonctionnalités.

Alors quels autres environnements y a t’il à part l’environnement de production?

  • L’Environnement de développement : c’est là que les développeurs testent d’abord leur code. Ils le font souvent sur des machines en local, et si c’est le cas, il n’y a aucun danger que cet environnement soit accessible aux autres et qu’il soit indexé par les moteurs de recherche. Si ce n’est pas gardé localement, mais par exemple sur un dev.exemple.com sous-domaine, il y a un risque qu’il soit accessible à d’autres et qu’il soit indexé.
  • L’Environnement de simulation (également souvent appelé “environnement de test”) : c’est là qu’on test étape par étape les prochaines publications et là où on teste les nouvelles fonctionnalités avant leurs sortie. Le nouveau contenu est publié ici pour qu’on puisse le vérifier et s’assurer qu’il ressemble bien à ce qu’on souhaite. Les environnements de simulation ne sont pas en local : différents membres de l’équipe doivent pouvoir y accéder facilement, et il fonctionne généralement via un sous-domaine ou un domaine séparé.

Astuce Pro : puisque vous vous renseignez sur la protection des environnements de simulation, vous allez probablement faire une migration de site bientôt. Pour une migration parfaite, lisez notre guide pour réussir les migrations de site web pour vous assurer que vous n’oubliez pas d’étapes cruciales pendant le processus de migration!

La sécurité par l’obscurité n’est pas une stratégie envisageable

Ne parler à personne de votre environnement de simulation “secret” s’apparente à un cas de “sécurité par l’obscurité”. Ce n’est pas une stratégie envisageable dans ce cas. Tout particulièrement si c’est la seule barrière de protection.

Et si quelqu’un publiait accidentellement un lien vers l’environnement de simulation? Ou si quelqu’un avec l’instruction push envoyait du code à l’environnement de production dans lequel il y aurait accidentellement des références canoniques ou hreflang à l’environnement de simulation?

Non seulement cela créerait des problèmes dans votre environnement de production, mais cela mettrait également les moteurs de recherche sur la piste de votre environnement de simulation. Et ils remonteront la piste pour pouvoir le crawler à moins que vous ne rendiez l’accès à votre environnement de simulation impossible, ou que vous leur donniez des règles à suivre.

Comment protéger vos environnements de développement et de simulation?

Il est clair désormais que vous devez protéger vos environnements de simulation et de développement. Mais comment faire? Il y a plusieurs façons de le faire, mais laquelle est la meilleure?

Nous parlerons des avantages et des inconvénients de chaque méthode, en prenant en compte :

  • La facilité d’utilisation : à quel point la méthode ne rajoute pas d’autres inconvénients.
  • L’accès à un tiers : à quel point la méthode empêche une tierce personne d’accéder à un environnement.
  • La compatibilité SEO : à quel point la méthode empêche les moteurs de recherche d’indexer un environnement.
  • La compatibilité avec le Monitoring : à quel point la méthode vous laisse surveiller les environnements protégés pour des gérer l’aspect SEO.
  • Le risque d’erreur humaine : à quel point cette méthode peut mener à des erreurs humaines, impactant le SEO.
Méthode Facilité d’utilisation Accès à un tiers Compatibilité SEO Compatibilité Monitoring Risque d’erreur humaine
Authentification HTTP no no no no no
VPN no no no no no
Le fichier Robots.txt no no no no no
Robots.txt no no no no no
Liens canoniques no no no no no
Mettre sur liste blanche des user-agents spécifiques no warning no no no

Méthode 1: L’authentification HTTP - votre meilleure option 🏆

La meilleure façon d’empêcher utilisateurs et moteurs de recherche d’accéder à vos environnement de production en de simulation est d’utiliser l’Authentification HTTP. Assurez-vous cependant de l’implémenter en utilisant HTTPS, vous ne voulez pas que les noms d’utilisateurs et les mots de passe voyagent en texte brut sur le réseau.

Nous vous recommandons de white-lister les adresses IP à votre bureau, et de fournir aux personnes externes et aux membres d’équipe éloignés un accès via une combinaison de nom d’utilisateur et de mot de passe.

De cette façon les moteurs de recherche ne peuvent accéder à rien, et vous avez un contrôle total de qui peut voir quoi. Vous pouvez préparer votre environnement de simulation avec le même fichier robots.txt que vous utiliserez pour l’environnement de production, ainsi que les balises robots et les non liens canoniques. Cela vous permet d’avoir une bonne représentation de votre environnement de production lorsque vous le monitorez pour surveiller les éventuels problèmes et changements avant un lancement.

Autre avantage : cela évite aux développeurs d’oublier de publier le bon fichier robots.txt, les balises robots et les liens canoniques sur l’environnement de production.

C’est une bien meilleure approche que d’utiliser un fichier robots.txt ou des balises robots noindex et des liens canoniques car cela n’empêche pas d’autres personnes d’y accéder et les moteurs de recherche n’honorent pas toujours ces directives.

De plus, lorsque vous utilisez l’authentification HTTP il est toujours possible d’utiliser les outils de test Google comme AMP, l’outil de test d’optimisation mobile et l’outil de test de données structurées. Il suffit de créer un tunnel.

Comment mettre une authentification HTTP en place?

Vous trouverez ci-dessous des ressources pour mettre en place un authentification HTTP sur Apache, nginx et IIS :

Dean Cruddace
Dean Cruddace
Cultured Digital

Les mots de passe protègent votre environnement de simulation, point. Rien de très élaboré, protégez le simplement avec un mot de passe. Google ne peut pas voir ce qu’il y a derrière une protection par mot de passe (à moins de mettre en place un tunnel pour effectuer des tests). Même en utilisant un robots.txt Disallow: / et des meta robots noindex, il est toujours possible que certaines pages soient indexées si il y a assez de liens et/ou d’autres signaux qui y mènent.

Beaucoup d’outils SEO dont ContentKing sont configurés pour gérer l’authentification HTTP pour crawler et tester ce genre de configuration. Il est prudent de crawler les environnements de simulation plus lentement que d’habitudes parce qu’ils n’ont pas autant de ressources à disposition ou ont une configuration de cache qui demande à être plus prudent que d’habitude.

Tomek Rudzki
Tomek Rudzki

Les environnements de simulations devraient toujours être bien protégés. Les utilisateurs ne devraient pas être en mesure de les voir. Votre nouvel environnement de test flambant neuf peut avoir beaucoup de bugs, ce qui peut avoir un impact négatif sur la confiance des utilisateurs et des utilisatrices. Il peut aussi être vulnérable aux attaques de hackers. De plus, vous ne voulez pas que Google l’indexe (pour éviter les problèmes de contenu dupliqué).

Mais comment tester un environnement de simulation en utilisant les outils Google? Comment faire si vous voulez utilisez l’outil d’Inspection URL pour être sûr que Google affiche votre site correctement? Et si vous voulez tester votre implémentation Schema.org en utilisant l’outil de test de données structurées?

Vous avez deux options :

  • Vous pouvez mettre un tunnel en place (comme mentionné précédemment).
  • Vous pouvez utiliser une solution proposée par David Sottimano. Vous pouvez whitelister les adresses IP de Google (66.x) et ainsi leur autoriser l’accès. Parce que cette méthode peut être épineuse, vous devez limiter la période pendant laquelle vous avez whitelisté les adresses IP de Google et pendant toute cette période vous devez vous assurer que votre version de simulation est non-indexable!

Méthode 2: l’accès VPN

Un VPN (Virtual Private Network) est un réseau privé virtuel. Vous vous connectez simplement à votre ordinateur local au réseau de l’entreprise pour en faire partie. Et maintenant que vous faites partie de l’entreprise, vous pouvez accéder à l’environnement de simulation. Quiconque ne fait pas partie du réseau ne peut y accéder. Ce qui signifie qu’une tierce personne ou les moteurs de recherche ne peuvent pas accéder à l’environnement de simulation.

Avoir un accès via un VPN offre la plupart des avantages de l’authentification HTTP. Il y a cependant un gros inconvénient : les solutions de monitoring qui ne fonctionnent pas en local peuvent ne pas très bien fonctionner, voir ne pas fonctionner du tout. Ne pas pouvoir surveiller les progrès de l’équipe de développement est périlleux, et cela peut devenir véritablement problématique lorsque vous avez affaire à de très gros sites.

Méthode 3: Les balises robots

Les balises directives sont utilisées pour communiquer vos préférences en matière de crawling et d’indexation. Par exemple vous pouvez demander aux moteurs de recherche de ne pas indexer certaines pages ou de ne pas suivre (certains) des liens.

Vous pouvez définir les balises robots dans l’en-tête HTTP d’une page (l’en-tête X-Robots-Tag), ou via la balise meta robots dans la section <head>. Comme vous n’aurez pas seulement des pages mais aussi d’autres types de contenu dans votre environnement de simulation, il est recommandé d’utiliser l’en-tête X-Robots-Tag pour être sûr que les fichiers PDF, par exemple, ne soient pas indexés.

Les balises robots, comme indiqué dans leurs noms, sont faites pour les robots (“crawlers”). Elles ne bloquent pas l’accès à un tierce personne. Elles envoient un signal relativement fort aux moteurs de recherche pour qu’ils n’indexent pas les pages. Je dis “relativement” parce que les moteurs de recherche peuvent toujours décider d’ignorer les balises robots et indexer vos pages. Ce n’est pas une solution compatible avec le monitoring, car comme elles sont similaires au fichiers robots.txt, cela peut donner de faux résultats positifs envoyés pas les outils SEO.

En plus de tout ça, il y a un gros risque d’erreur humaine, parce que les balises robots de l’environnement de simulation sont souvent transposées vers l’environnement de production.

Méthode 4: Le fichier Robots.txt

Le fichier robots.txt énonce les règles d’engagement pour les crawlers, donc en utilisant le fichier robots.txt vous pouvez demander aux moteurs de recherche de rester hors de votre environnement de simulation. La façon la plus courante de le faire et d’inclure le contenu suivant dans le fichier robots.txt :

User-agent: * Disallow: /

Cela empêchera les moteurs de recherche de crawler le site, mais il est possible qu’ils l’indexent quand même s’ils trouvent un lien y menant, ce qui mène à des listes comme celles-ci :

Google description not available robots.txt

Certaines personnes ajoutent la balise non-officielle Noindex dans leur fichier robots.txt. Nous vous recommandons de ne pas le faire, parce que c’est la pire façon d’empêcher l’accès à votre environnement de simulation comparé à la balise Disallow, à cause du fait qu’elle n’est pas une balise officielle.

Votre fichier robots.txt n’offre aucune protection efficace contre l’accès du site à une tierce personne, et il perturbe aussi grandement les outils de monitoring SEO, ce qui peut donner de mauvaises informations. De plus, vous créez un énorme risque d’erreur humaine : là encore, le fichier robots.txt de l’environnement de simulation est souvent accidentellement transféré vers l’environnement de production.

Dawn Anderson
Dawn Anderson

Ajouter simplement un fichier robots.txt à un environnement de simulation, ou ajouter le fichier de l’environnement de simulation au site en ligne n’est pas une stratégie recommandée parce que vous donnez un accès direct vers votre environnement à la concurrence (ou n’importe qui d’autre).

De plus, les moteurs de recherche pourront toujours indexer les URLs ajoutés à un fichier robots.txt, en particulier si un URL est mis en lien (par ex. lorsqu’un développeur télécharge un fichier en ligne sur lequel il y a un lien vers l’environnement de simulation, ce qui peut booster sa popularité). On voit souvent des pages indexées qui ne devraient pas l’être et la meta description dit simplement quelque chose du style : nous n’avons pas plus d’informations sur cela puisque le moteur de recherche ne peut pas accéder à la page pour voir ce qu’il y a (parce que l’URL a simplement été découverte et indexé sur la base d’autres signaux).

Bartłomiej Kudyba
Bartłomiej Kudyba

Vous devriez toujours empêcher l’indexation de votre environnement de simulation. S’il est indexé, cela pourrait provoquer des problèmes de contenu dupliqué , ou il pourrait être vu comme étant pauvre en terme de contenu. Votre “lorem ipsum” peut être indexé et vous devrez alors faire les démarches pour le désindexer.

Si vous voulez cacher votre environnement de simulation des moteurs de recherche et des utilisateurs, un mot de passe protégeant l’environnement est indispensable.

Lorsque vous devez montrer temporairement une page à vos utilisateurs et utilisatrices, vous pouvez aussi la protéger des crawlers de moteurs de recherche, mais n’oubliez pas de réfléchir à la manière dont vous voulez la dévoiler aux utilisateurs et aux crawlers lorsqu’elle sera prête.

Lorsque nous avons publié Onely, tout était une question de timing : il fallait que ça tombe en même temps que notre inauguration et nous avons rencontré des problèmes concernant les règles de fichier robots.txt utilisés pour sécuriser notre page temporaire. Le jours suivant l’inauguration, Googlebot ne pouvait toujours pas crawler notre site web parce que le fichier robots.txt n’avait pas encore été rafraîchi. Comme l’a dit John Mueller en réponse à ce scénario : “Nous gardons le fichier robots.txt en cache pendant un jour à peu près…

Méthode 5: Les liens canoniques

Le lien canonique (ou URL canonique) informe les moteurs de recherche de la version canonique de la page. Si l’environnement de simulation fait référence à l’environnement de production, tous les signaux devraient être consolidés avec l’environnement de production.

Sinon, les liens canoniques ressemblent aux balises robots, en particulier dans leurs défauts :

  • Ils laissent toujours les tierces parties accéder à l’environnement de simulation.
  • Ils ne sont pas une solution très compatible avec le monitoring car ils peuvent envoyer de faux positifs aux outils SEO.
  • Il y a une risque d’erreur humaine, puisque les directives canoniques se retrouvent parfois accidentellement dans l’environnement de production.

Méthode 6: Whitelister des user agents spécifiques

Whitelister des user agents spécifiques pour accéder à un environnement de simulation peut être utiliser pour autoriser les spécialistes SEO à monitorer un environnement de simulation, du moment que leurs outillages SEO permettent de paramétrer les user agents. Ils peuvent créer un user agent et l’utiliser tout en bloquant tous les autres user agents (navigateurs compris).

Mais ce n’est pas très agréable à faire en tant qu’utilisateur parce que la vérification manuelle via votre navigateur est difficile. Ce n’est pas non plus une très bonne approche côté sécurité : lorsqu’une tierce personne sait que vous travaillez pour ou chez X entreprise, et qu’elle connaît votre user agent (peut être parce qu’il s’agit de clients mécontents), elle peut obtenir l’accès à l’environnement de simulation.

Comment savoir si votre environnement de simulation est indexé?

Il y a plusieurs moyens de savoir si votre environnement de simulation est indexé. Voici les deux façons les plus courantes :

Option 1: requête de site

Si vous savez que votre environnement de simulation tourne sur un sous-domaine, vous pouvez essayer une requête de site comme : site:exemple.com -inurl:www

Cette requête renvoie toutes les pages indexées par Google pour le domaine exemple.com excepté celles qui contiennent “www”.

Voici un lien vers un exemple de requête.

Option 2: Google Analytics

Si vous ne connaissez pas l’URL de votre environnement de simulation, vous pouvez essayer de vérifier dans Google Analytics :

  • Allez dans Audience > Technologie et choisissez Réseau.
  • Sélectionnez Nom d'hôte en tant que Dimension Principale.
  • Cherchez les noms d’hôte qui ont un domaine différent, ou qui contiennent des sous-domaines comme staging, test ou dev.

Retirer de l’index votre environnement de simulation déjà indexé

Oh oh. Votre environnement de simulation a déjà été indexé par les moteurs de recherche, et vous êtes la personne qui va devoir arranger ça. Et bien, la bonne nouvelle, c’est que si vous suivez les étapes ci-dessous, vous vous en sortirez. Et facilement en plus.

Étape 1: masquer les résultats de recherche

Vérifiez l’environnement de simulation dans les outils webmaster tels que Google Search Console et Bing Webmaster Tool et l’outil de suppression d’URL (voir la documentation Google et la documentation Bing là-dessus). Pour Google, cette requête est souvent satisfaite en quelques heures (Bing prend un peu plus longtemps), et ensuite votre environnement de simulation n’apparaîtra plus dans aucun résultat de recherche. Seulement voilà l’embrouille : il se trouve toujours dans les index de Bing et Google, c’est juste qu’il n’est plus montré. Dans le cas de Google, votre environnement de simulation est seulement masqué pendant 90 jours. Pendant ce laps de temps, vous devez vous assurer de demander la suppression de vos pages des index de moteurs de recherche de la bonne manière : via la directive noindex.

Étape 2: appliquer la directive noindex et obtenir un nouveau crawling des pages

Assurez-vous d’appliquer la directive noindex sur chaque page de votre environnement de simulation. Pour accélérer le processus d’un nouveau crawling de ces pages, envoyez un XML sitemap. Maintenant cherchez dans vos registres de serveur les requêtes des crawleurs de moteurs de recherche pour vos pages précédemment indexées ( maintenant “no[n]index[ées]”), pour vous assurer que le message a bien été reçu.

Dans la plupart des cas, ces 90 jours suffisent pour signaler aux moteurs de recherche qu’ils devraient retirer les pages de l’environnement de simulation de leurs index. Mais si ce n’est pas le cas, recommencez l’opération.

Une fois que tout est fait, protégez l’environnement de simulation en utilisant une authentification HTTP pour s’assurer que ça ne se reproduise pas et retirez le XML sitemap de Google Search Console et Bing Webmaster Tools.

Suganthan Mohanadasan
Suganthan Mohanadasan

Vous pouvez ajouter une balise “noindex” aux pages indexées de l’environnement de simulation et présenter un nouveau sitemap via Google Search Console et Bing Webmaster Tools. Je recommande de soumettre le sitemap pour être sûr que les moteur de recherche puissent voir la balise “noindex”. Une fois que les moteurs de recherche crawlent de nouveau les pages indexées de l’environnement de simulation, ils devraient commencer retirer ces pages de leurs index. Une fois que c’est fait vous pouvez vous débarrasser du sitemap. Vous pouvez passer à autre chose et sécuriser l’environnement de simulation en bloquant un nouveau crawling des moteurs de recherche (et une nouvelle indexation). La meilleure façon de le faire est d’ajouter une authentification HTTP.

Autres ressources utiles

Voici d’autres ressources utiles (en anglais)sur la protection de l’environnement de simulation :

Et maintenant, continuez à apprendre!

Maintenant que vous en savez plus sur la meilleure façon de protéger votre environnement de simulation, continuez votre apprentissage avec ces articles :

ContentKing Academy Content Team
Steven van Vessum
Steven van Vessum

Steven est le Chef de l’expérience client dans l’entreprise ContentKing. Cela signifie qu’il s’occupe de tout lié avec les clients et avec l’inbound marketing. C’est là où il veut être. Il aime améliorer le référencement des sites web dans les moteurs de recherche et parler de l’inbound marketing.

Vojtěch Zach
Vojtěch Zach

Vojtěch is ContentKing’s Customer Support & Localization Manager. He is the one who will answer your questions when you reach out to us. He is a studied translator, so apart from making our users happy, he also loves to take on our localization challenges.

Vincent van Scherpenseel
Vincent van Scherpenseel

Vincent est le directeur en chef de ContentKing. Le management de produit le passionne et il aime particulièrement son travail lorsque le design, le développement et le commerce s’entremêlent. Ce qui fait de ContentKing un challenge idéal pour lui.

Commencer votre essai gratuit de 14 jours

Vous pouvez commencer en 20 secondes

Insérez un nom de domaine valide, s'il vous plaît (www.exemple.fr).
  • La carte de crédit n'est pas requise
  • Aucune installation requise
  • Sans engagement