Connecter un site web à Cloudflare

Comment connecter un site web à Cloudflare

Cloudflare peut se placer devant un site web de deux façons très différentes. Vous pouvez transférer l’ensemble du domaine vers le DNS et le proxy de Cloudflare, ou garder une configuration plus limitée et n’activer qu’une seule fonctionnalité à la fois. Ce choix modifie les étapes, les risques et le plan de retour en arrière.

Commencez par là. Un site vitrine de quelques pages n’a pas les mêmes besoins qu’un domaine d’entreprise fortement utilisé pour les e-mails, et un domaine qui héberge déjà un site корпоративatif demande une gestion plus prudente des enregistrements qu’un lancement tout juste créé. Si vous pensez aussi à la sécurité du site web, Cloudflare entre souvent dans la discussion pour cette raison en premier.

1. Déterminez si vous avez besoin d’un contrôle DNS complet ou d’une seule fonctionnalité Cloudflare

Cloudflare n’est pas un simple interrupteur. Il peut gérer le DNS, faire transiter le trafic web via un proxy, mettre le contenu en cache, filtrer les requêtes et se placer entre les visiteurs et votre serveur d’origine. Si vous ne voulez qu’une seule fonction, comme la gestion DNS ou une couche de sécurité, vous devez quand même savoir que les serveurs de noms du domaine sont généralement le point à partir duquel Cloudflare prend le contrôle.

Pour un simple site de présentation, un contrôle complet est souvent suffisant. Pour une configuration avec routage des e-mails, services de vérification et plusieurs sous-domaines, la décision est plus délicate. Une infrastructure réseau privée, par exemple, peut exiger que certains noms d’hôte restent hors du chemin du proxy, tandis que les pages web peuvent passer par Cloudflare sans problème.

Posez une question pratique : qu’est-ce qui doit impérativement fonctionner dès le premier jour ? Si la réponse inclut les e-mails, des rappels d’API ou un parcours de paiement, vous ne faites pas seulement “connecter un site web à Cloudflare” ; vous modifiez la façon dont le domaine se résout. Cette différence est importante.

Une règle simple aide beaucoup : ne supposez rien. Si le site dépend d’un service autre que le serveur web, listez-le avant de toucher aux serveurs de noms. Cette liste devient votre filet de sécurité.

2. Faites l’audit de votre configuration de domaine actuelle avant de changer les serveurs de noms

Avant de déplacer quoi que ce soit, vérifiez où le DNS est actuellement géré. Le registrar et l’hébergeur DNS ne sont pas toujours la même entreprise, et ce décalage provoque des erreurs évitables. Recherchez les serveurs de noms actuels, puis examinez les enregistrements de zone qui s’y trouvent.

Vous avez besoin d’une vue complète : enregistrements A et AAAA pour le site web, enregistrements CNAME pour les sous-domaines, enregistrements MX pour les e-mails, enregistrements TXT pour les vérifications, ainsi que tout enregistrement inhabituel utilisé par des outils tiers. Un enregistrement TXT manquant peut casser un flux de connexion. Un enregistrement MX incorrect peut interrompre le courrier.

Ne vous fiez pas à votre mémoire. Un domaine en ligne depuis des années peut contenir des enregistrements ajoutés par différentes personnes à différents moments, et certains ne sont peut-être documentés nulle part ailleurs. Si le propriétaire du site ne peut pas expliquer un enregistrement, c’est une bonne raison de le conserver jusqu’à ce que vous sachiez à quoi il sert.

C’est aussi le moment de relever les redirections et les anciens noms d’hôte. Si du trafic arrive encore sur un ancien sous-domaine, notez-le maintenant. Une redirection qui fonctionne à l’origine peut échouer plus tard si le nom d’hôte n’a pas été recopié dans Cloudflare.

Conservez une copie de la zone actuelle en dehors du compte du registrar. Un simple fichier texte suffit. Une feuille de calcul aussi. L’important, c’est de pouvoir restaurer.

3. Créez le site Cloudflare et importer enregistrements DNS Cloudflare existants

Après l’audit, ajoutez le domaine à Cloudflare. Cloudflare analysera les enregistrements DNS existants et essaiera de les importer dans sa zone. Cette analyse fait gagner du temps, mais elle ne garantit pas que tout a été transféré correctement.

Vérifiez les enregistrements importés ligne par ligne. Un enregistrement peut manquer, un sous-domaine peut être dupliqué, ou une valeur peut être obsolète. La première vérification porte sur l’exactitude, pas sur la rapidité. Si vous voyez un nom d’hôte qui devrait pointer vers votre serveur web mais qui pointe ailleurs, corrigez-le avant de toucher au registrar.

Deux contrôles simples permettent de repérer beaucoup d’erreurs. D’abord, comparez les enregistrements importés avec votre liste d’audit. Ensuite, confirmez que le domaine racine et le nom d’hôte “www” pointent tous deux au bon endroit. Ce sont les enregistrements que les utilisateurs utiliseront en premier.

Si vous gérez un site qui se comporte comme un site d’entreprise, surveillez attentivement les sous-domaines. Un portail d’assistance, un nom d’hôte de préproduction et un hébergeur de fichiers se trouvent souvent à côté du site principal, et un seul enregistrement manquant peut suffire à provoquer une panne difficile à diagnostiquer.

Petit aparté pratique : l’import de Cloudflare est utile, mais ce n’est pas une raison pour vous dispenser de votre propre vérification. L’analyse n’est qu’un point de départ. Votre audit est le contrôle final.

4. Choisissez quels enregistrements doivent rester proxyfiés et lesquels doivent rester en DNS seul

Cloudflare vous donne le choix pour de nombreux enregistrements. Le nuage orange signifie que le trafic passe par le proxy de Cloudflare. Le nuage gris signifie DNS seul. Ce choix n’est pas cosmétique. Il modifie la manière dont les requêtes circulent.

Le trafic web du site public est souvent proxyfié. Les enregistrements de messagerie ne le sont pas. Les enregistrements de vérification ne le sont pas non plus. Certains sous-domaines qui servent des API ou des outils spécialisés devraient également rester en DNS seul, à moins d’avoir testé soigneusement tout le parcours. Si vous voulez une règle rapide : proxyfiez le site web et laissez les services non web tranquilles, sauf si vous avez une raison de les changer.

Une erreur fréquente consiste à tout proxyfier parce que cela paraît propre. Cela ne le reste pas longtemps. Un enregistrement MX derrière le proxy échouera. Un nom d’hôte de vérification peut cesser d’être reconnu par un autre service. Un point de terminaison de transfert de fichiers peut se comporter étrangement parce qu’il n’a jamais été conçu pour passer par le proxy web.

Pensez en termes de fonction, pas d’apparence. Le site web peut être proxyfié pour des raisons de performance et de sécurité. Les e-mails devraient généralement rester en DNS seul. Si votre configuration inclut des pixels de suivi, des points de terminaison de webhooks ou des hôtes de vérification tiers, testez-les un par un.

Le trafic qui doit rester en DNS pur est souvent celui que vous souhaitez le moins casser. Gardez cette phrase en tête avant de cliquer trop souvent sur le nuage orange.

5. Mettez à jour les serveurs de noms du domaine chez votre registrar

Cloudflare attribuera deux serveurs de noms au domaine. Remplacez les serveurs de noms actuels chez votre registrar par ces deux valeurs. C’est l’étape qui transfère l’autorité DNS à Cloudflare, donc copiez-les exactement comme indiqué.

Chez le registrar, trouvez la section des serveurs de noms et supprimez l’ancienne paire. Puis saisissez la paire attribuée par Cloudflare. Enregistrez la modification.

Ne paniquez pas si le site ne bascule pas immédiatement. Les changements DNS ne sont pas synchronisés sur une horloge unique. Un visiteur peut encore atteindre l’ancien chemin pendant un certain temps, et c’est normal. Si l’ancien hébergeur DNS reste actif pendant la transition, vous réduisez le risque d’échec de résolution.

Une phrase courte ici : soyez exact. Une seule erreur de caractère dans l’entrée du serveur de noms peut empêcher la délégation de fonctionner.

Ne modifiez pas non plus plusieurs éléments à la fois. Si vous renommez des enregistrements, changez d’hébergeur et éditez les serveurs de noms dans la même session, le dépannage devient bien plus compliqué que nécessaire.

6. Vérifiez que le domaine est actif dans Cloudflare et testez de vrais parcours de trafic

Après le changement de serveurs de noms, Cloudflare devrait afficher le domaine comme actif. Si ce n’est pas le cas, le problème vient généralement de l’une de ces trois choses : la modification chez le registrar n’a pas été enregistrée, les serveurs de noms ont été saisis incorrectement, ou le registrar conserve encore des données en cache. Vérifiez cela avant d’accuser le serveur d’origine.

Testez ensuite de vrais parcours, pas seulement la page d’accueil. Ouvrez le domaine principal, la version “www”, une sous-page clé et tous les sous-domaines importants. Si le site possède une page de connexion, testez-la aussi. S’il propose un téléchargement de fichier ou l’envoi d’un formulaire, testez ces actions. Des pages peuvent se charger alors qu’un point de terminaison caché est cassé.

C’est là qu’un outil de surveillance devient utile. Si vous utilisez une plateforme d’analyse et de surveillance de site web, comparez les premières requêtes en production après le basculement avec le schéma normal. Une hausse soudaine des erreurs sur un nom d’hôte est souvent le premier signe qu’un enregistrement DNS ou un réglage du proxy nécessite une attention.

Utilisez un second navigateur ou une fenêtre privée pour un test propre. Les données en cache peuvent masquer des problèmes. Un ancien état de connexion aussi.

Si quelque chose échoue, testez le parcours du domaine vers l’extérieur : DNS, réponse en bordure, réponse de l’origine, puis logique applicative. Cet ordre fait gagner du temps.

7. Définissez les premiers réglages Cloudflare sûrs pour une nouvelle connexion

Une fois le domaine actif, gardez des réglages initiaux prudents. Choisissez un mode SSL/TLS compatible avec ce que votre origine peut réellement prendre en charge, et ne devinez pas. Si le certificat de l’origine n’est pas prêt, le navigateur peut afficher des erreurs ou Cloudflare peut refuser la connexion. C’est une mauvaise surprise le jour du lancement.

Les paramètres de sécurité de base doivent être l’étape suivante. Si la sécurité du site web est déjà une préoccupation, c’est ici que Cloudflare commence à apporter une aide au-delà du DNS. Commencez par les contrôles évidents, puis testez à nouveau le site. Les réglages agressifs peuvent attendre que vous connaissiez le comportement de base.

Le comportement du cache mérite aussi un premier examen attentif. Une page qui change souvent ne doit pas être traitée comme une page qui change à peine. Si vous hésitez, conservez d’abord le comportement par défaut, observez les réactions du site, puis modifiez un seul élément à la fois.

Une bonne habitude consiste à séparer “sûr maintenant” de “bien plus tard”. Le “sûr maintenant” comprend le bon fonctionnement du chemin SSL et la confirmation que le site s’ouvre toujours. Le “bien plus tard” comprend l’ajustement des en-têtes de cache ou le durcissement des règles une fois que vous avez des journaux à lire. Cet ordre évite les pannes auto-infligées.

Gardez cette phase réduite. Les petits changements sont plus faciles à annuler.

8. Vérifiez les cas limites : e-mails, sous-domaines, redirections et problèmes de contenu mixte

C’est là que beaucoup de sites trébuchent. Les e-mails dépendent généralement d’enregistrements DNS qui doivent rester en DNS seul. Vérifiez que les enregistrements MX pointent toujours vers le bon serveur de messagerie et que les enregistrements TXT SPF, DKIM ou DMARC ont bien été conservés. Si les e-mails s’arrêtent, le site peut sembler fonctionner parfaitement tandis que les messages professionnels disparaissent.

Les sous-domaines méritent leur propre liste de contrôle. Un nom d’hôte de préproduction, un hébergeur d’images et un point de terminaison d’envoi peuvent nécessiter un traitement différent. Si l’un d’eux a été proxyfié par erreur, vous ne verrez peut-être un comportement étrange que sur ce seul nom d’hôte. Ce genre de bug fait perdre du temps parce que la page d’accueil fonctionne.

Les redirections peuvent aussi révéler des erreurs. Si l’ancien site envoyait les visiteurs d’un nom d’hôte à un autre, testez à nouveau ce parcours après le basculement. Une chaîne de redirection qui fonctionnait auparavant peut désormais pointer vers un nom d’hôte jamais ajouté à Cloudflare. Un seul enregistrement manquant peut casser tout le parcours.

Les problèmes de contenu mixte apparaissent lorsque le site charge certaines ressources en HTTP alors que la page elle-même est servie en HTTPS. Les navigateurs n’aiment pas cette combinaison. Des images peuvent disparaître, des scripts peuvent échouer, et un formulaire peut cesser de s’envoyer. Corrigez les URL à la source, au niveau de l’application, pas seulement dans le navigateur.

Si votre domaine alimente un flux de travail de support de site après lancement, gardez une courte liste des hôtes les plus fragiles : messagerie, préproduction, envois, redirections et vérification tierce. Ce sont ces cinq zones où apparaissent généralement les premiers tickets.

Dernier contrôle pratique : essayez le site depuis un réseau que vous n’utilisez pas habituellement. Une connexion mobile peut révéler un problème de cache ou un délai DNS que votre réseau de bureau masque. Des chemins différents révèlent des problèmes différents.

Et si vous connectez un site qui a déjà des exigences opérationnelles strictes, documentez chaque enregistrement DNS touché. Pas plus tard. Maintenant.