15/09/2009.

Nous laissons cet article en l’état cet article, pour mémoire : à l’usage, les services de 000webhost constituent une anarque, et fonctionnent plutôt mal, mais ils sont idéals pour héberger des sites expérimentaux ou poubelles. En cas de problème, les services payants de Hosting24 sont proposés, mais il ne valent guère mieux. Autant être prévenu !

</addendum>

Avec 000webhost, nous pensons avoir trouvé l’hébergeur idéal :

• 350 Mega-octets d’espace disque,
• 100 Giga-octets de bande passante,
• Php et MySql en version 5,
• activation immédiate du compte, y compris de l’accès Ftp et de la base MySql,
• hébergement en nom de domaine, ou en sous domaine avec une adresse comme http://chezmoi.site40.net,
• installation en un clic des plates-formes de weblogue (WordPress, Nucleus, b2evolution…), de Sgc (Drupal, Joomla, Typo3…) et cetera pour les moins chevronnés,
• haute disponibilité,
• sans publicité,
• serveur de mel,
• gratuit.

Autrement dit, ce service propose l’ensemble des fonctionnalités d’un hébergeur classique, mais il est gratuit. Le modèle économique repose sur les dons et, essentiellement, sur les souscriptions payantes à des services supplémentaires.

Les serveurs sont situés aux États-Unis d’Amérique, mais les temps de réponse sont comparables à ceux d’un hébergeur situé (au hasard…) en Allemagne !

L’assistance technique est limitée à un forum de discussion, mais semble aussi réactive que les hotliners des hébergements classiques à l’entendement parfois limité.

Cette offre est idéale pour débutants, par exemple sous WordPress : plutôt qu’installer une version du weblogue en local au risque de ne pas savoir exporter la base de données avec la mise en production, il est plus utile d’utiliser un serveur dès ses premiers pas.

Sont parfois à déplorer certaines sautes du serveur, qui durent le plus souvent quelques secondes. Cet écueil n’est guère gênant pour les sites amateurs.

Désormais, nous ne connaissons plus d’erreur 500 sur nos sites ni de problème d’allocation de mémoire Php. Notre vie de concepteur de sites a changé grâce à 000webhost !

Pour contourner l’interruption de service en cas de changement d’hébergeur, quelques scripts sont disponibles, mais nous n’avions nullement envie d’investir du temps en bidouillage. Une solution pérenne et fiable nous semblait préférable.

Aussi avons-nous tenu le raisonnement suivant… Si nous copions nos données vers un hébergeur B en les laissant intact sur l’hébergeur A, nos sites ne devraient pas connaître d’interruption de service. Les serveurs de noms locaux qui auront pris en compte la modification vers B dirigeront les visiteurs vers B ; les serveurs de noms locaux qui n’auront pas pris en compte la modification vers B dirigeront les visiteurs vers A.

Se pose, certes, la question du transfert par Ftp du contenu vers le nouvel hébergeur, tant que l’adresse n’est pas résolue : au lieu d’utiliser l’adresse ftp.monsite.com, il suffit d’indiquer à titre temporaire l’adresse Ip indiquée par l’hébergeur.

Pour l’anecdote, nous avons changé d’hébergeur trois sites, durant la journée du 21 août 2008, entre 15 h 00 et 20 h 00. (Pour les amateurs de géographie, l’ancien serveur était situé à Karlsruhe, en Allemagne, le nouveau à Las Vegas, aux États-Unis d’Amérique.) Deux possédaient la Tld .info, l’autre la Tld .com. (La précision est donnée, car il semble que la vitesse de propagation des Dns soit différente selon l’extension.) Nous avons utilisé l’outil réseau Traceroute pour mesurer le temps pris par le changement d’hébergeur après déclaration des nouvelles directions Dns auprès de notre Registar :

• notre premier site en .info a demandé trois heures pour être correctement redirigé,
• notre deuxième site en .com a demandé deux heures pour être correctement redirigé,
• notre troisième site en .info a demandé deux heures pour être correctement redirigé.

(Nota. Ces mesures n’ont assurément aucune valeur, hormis informative !)

Nous sommes loin des 24 à 48 heures prévues ; cette hypothèse nous conforte dans l’idée que nous avions mal appréhendé la question.

Sur le plan chronologique, nous avons effectué la migration dans l’ordre suivant :

• copie de nos répertoires et de nos pages par Ftp;
• copie de nos bases de données Sql via phpMyAdmin ;
• déclaration des nouvelles directions Dns auprès de notre Registar.

(Sous WordPress, aucune réinstallation n’a été nécessaire.)

Nous avons choisi de ne pas modifier le contenu de nos sites pendant quelques heures pour simplifier la gestion de la procédure (le problème serait fort différent pour un vendeur en ligne !). Aucune donnée n’a été perdue, hormis quelques logs de connexion des visiteurs récupérés manuellement chez l’ancien hébergeur.

L’unique contrainte de l’opération consiste à disposer des services de son ancien hébergeur, pendant quelques jours.

En vérifiant le positionnement de l’article dans les moteurs de recherche, nous venons de nous apercevoir que Francis avait commis un article similaire, concernant WordPress !