Mes choix ont été les suivants :

• Comme mon site était déjà servi en application/xhtml+xml, j'ai choisi de continuer à le servir ainsi, d'où l'emploi du terme XHTML5 et non HTML5.
• Le site devait satisfaire à l'affichage, être validé par Validator.nu ainsi que par le validateur classique du W3C.

Pour être franc, cela a beaucoup été du travail de préparation, quelques essais pour voir où cela pêchait, un peu de nouvelles balises et de nouveaux attributs… et principalement du remplacement automatique.

Côté préparation :

• Mon site était déjà valide par défaut (vu qu'il était servi en application/xhtml+xml, la validation était obligatoire, sinon aucun affichage sur les navigateurs pouvant l'afficher ainsi).
• Les CSS ont toutes été vérifiées afin de supporter les changements de code, par exemple que nav id="bandeau" soit bien stylé via #bandeau et non pas via div#bandeau (qui n'aurait pas marché). De ce côté-là, les changements ont été mineurs, fort heureusement d'ailleurs, vu que j'ai plus de 20 styles alternatifs à l'instant où je publie cet article.

Certaines balises ont dû être changées ou oubliées :

• La balise acronym est obsolète en HTML5, elle a donc été remplacée par abbr.
• Le méta-tag ICRA pose problème également, fort heureusement, on peut s'en passer en utilisant la déclaration via fichier RDF.
• Toutes les entités HTML comme le célèbre   gênent le parsing des navigateurs permettant l'affichage comme application/xhtml+xml… il a donc fallu les remplacer par leurs équivalents unicode comme   pour l'espace insécable.
• Les spécifications de langue dans certaines balises via par exemple xml:lang="en" ont dû être doublées via lang="en", sinon le validateur W3C râle… curiosité, le validateur mobile du même W3C conseillait de ne plus les doubler (?!). Étrange contradiction.
• Le méta content-type est obsolète en HTML5, dans l'idée, tout se fait via les headers, comme c'était déjà le cas pour mon site, pas de souci.

Plus facile, de nouvelles balises et attributs ont fait leur entrée :

• Côté code HTML, le !DOCTYPE html tout simple, nav, article, header, footer et section remplacent avantageusement certaines div et le doctype XHTML 1 Strict.
• Côté accessibilité, j'ai ajouté l'attribut role que HTML5 intègre nativement (WAI-ARIA), cela nous donne body role="document", nav id="bandeau" role="navigation", div class="contenu" role="main", footer id="infos" role="contentinfo", etc.

Quelques petits couacs à prendre en compte :

• Si comme moi, vous utilis(i)ez la fonction htmlentities pour éviter que le code soit interprété dans les commentaires, oubliez-la ! Les entités HTML posent problème pour les parseurs des navigateurs si votre site est servi en application/xhtml+xml comme je l'ai indiqué plus haut. Pour ma part, j'ai solutionné ce problème en utilisant la fonction htmlspecialchars pour contourner le problème.
• Il faut inclure un fichier javascript pour l'abominable Internet Explorer (8 et versions inférieures) afin de créer au préalable ces éléments dans leur DOM sous peine de ne rien afficher du tout pour les éléments utilisant les nouvelles balises. Ce n'est pas très compliqué. Pour ma part, j'ai repris celui trouvé sur Brain Cracking, que je remercie au passage pour les bons conseils qu'il prodigue !
• L'extension HTML validator que j'utilise depuis fort longtemps… se vautre lamentablement à valider du HTML5 et affiche des erreurs (même si le code est parfaitement valide), il faut donc valider à la main avec les deux validateurs !
• Curiosité, même si le prologue XML sur mon site indique l'encodage, le validateur du W3C conseille d'ajouter le meta charset="utf-8"… pour le cas ou votre fichier soit enregistré et consulté hors-ligne. Pas totalement idiot, même si cela fait un peu doublon.
• Comme je l'ai indiqué plus haut, doubler les attributs lang via lang="en" xml:lang="en" est un peu fastidieux… le conseil était de les garder il y a quelques années, ensuite de supprimer le lang="en" pour ne garder que xml:lang="en" dans mon cas. Et là, il faut les remettre… bizarre et pas très heureux.
• Ajout : comme découvert plus tard, Internet Explorer a quelques problèmes avec les versions imprimables et les balises HTML5.
• Ajout : comme (re)découvert plus tard, certains méta-tags spécifiques à Internet Explorer comme imagetoolbar ne sont plus valides en HTML5, il faut passer par les commentaires conditionnels d'Internet Explorer pour l'en faire bénéficier.
• Autre ajout : il est possible d'utiliser HTML5 sans Javascript, la méthode a été testée avec succès.
• Ajout du 21 Juin 2011 : certains attributs ou métas sont invalides en HTML5, notamment sur les nouveaux type de champs de formulaires.
• Ajout du 4 Septembre 2011 : un rappel de quelques astuces pour servir son site en application/xhtml+xml avec IE.

En conclusion : migrer un site vers HTML5 n'est pas excessivement compliqué, cela nécessite surtout un bon outil de remplacement automatique (pour les fichiers) et également quelques remplacements dans la base de données, un peu de temps pour préparer votre site, un peu de patience pour faire quelques essais qui se révèlent vite fructueux, et éventuellement de casser quelques petites habitudes (j'ai du mal à oublier le   !).

Je suppose que j'ai eu le cas le plus compliqué, XHTML5 nécessitant une validation de facto vu qu'il est servi en application/xhtml+xml (sinon les pages ne s'affichent pas et on se prend une erreur XML dans la tête).
Produire du HTML5 sans cette contrainte est beaucoup plus aisé. On peut considérer que j'ai surtout pris du temps pour me documenter et faire quelques essais… la migration ayant été au final assez rapide (une grosse journée de travail).

Ajout très pratique : pensez à la Webdevelopper Toolbar pour gagner du temps à valider du HTML5 avec Validator.nu.

Plus que jamais, une bonne séparation structure/présentation ainsi qu'une structure solide permet d'éviter de longues et pénibles mises à jour : savoir que votre feuille de style encaissera des changements de balises sans broncher apporte une certaine tranquillité d'esprit. La qualité coûte moins de temps à être reprise.