Un site lisible par Google et par les IA : le cas de ce CV

Quand un recruteur ou un pair cherche qui je suis, il a deux réflexes en 2026 : taper mon nom dans Google, ou poser la question à un assistant. Mon CV en ligne doit répondre correctement aux deux. Ce site est le premier cas concret de ce blog : voici ce que j’ai choisi d’y faire, pourquoi, et ce que je n’ai pas fait.

La version précédente de ce site était une application React compilée dans le navigateur. Sans JavaScript, le HTML ne contenait qu’une div vide. Googlebot sait rendre ce genre de page, de façon différée et coûteuse. Les robots d’OpenAI, d’Anthropic, de Perplexity ou de Meta, eux, ne rendent pas le JavaScript : ils lisent le HTML tel qu’il arrive. C’est ce qu’a mesuré l’étude de Vercel et MERJ en décembre 2024. Pour ces moteurs, mon CV n’existait pas.

La nouvelle version est un site statique : HTML, CSS, et moins de quinze kilo-octets de JavaScript qui ne servent qu’au confort (copier le lien d’un article, ouvrir le menu). Chaque fait est dans le HTML initial. On peut le vérifier avec curl sur n’importe quelle page de ce site : le nom, le poste, les dates, le lien vers mon profil LinkedIn apparaissent sans qu’aucun script ne s’exécute.

Google a publié en mai 2026 un guide officiel sur l’optimisation pour ses fonctionnalités d’IA. La condition de base y tient en une phrase : une page doit être indexée et éligible à l’affichage d’un extrait. Le reste, c’est du SEO ordinaire. Rendre le contenu lisible sans JavaScript est la première brique, et c’est elle qui manquait.

Un modèle de langage extrait des faits phrase par phrase. Si mon nom est dans le titre et que trois écrans plus bas une section dit « 2024 – 2025, chargé de projet SEO », le lien entre les deux n’est pas garanti. J’ai donc écrit le site de façon que les faits soient portés par des phrases complètes : « Théo Wizman est chef de projet SEO & ASO au Groupe TF1 depuis décembre 2025. » C’est moins élégant qu’un bloc graphique, c’est plus sûr.

Même logique pour la section « Questions fréquentes » de l’accueil. Elle répond aux questions telles qu’on les pose à un assistant : qui je suis, ce que je fais chez TF1, quel est mon parcours, quelles sont mes expertises, comment me contacter. Elle est en HTML, sans balisage FAQPage : Google a cessé d’afficher les résultats enrichis FAQ pour tous les sites le 7 mai 2026, et le balisage n’apportait plus rien.

Dernier point, le plus souvent négligé : la cohérence entre les sources. Les intitulés, les noms d’entreprises et les dates de ce site sont les mêmes que sur mon profil LinkedIn, et le profil doit renvoyer vers le site : c’est ce qui confirme le lien sameAs dans les deux sens. Quand deux sources se contredisent, un moteur baisse sa confiance dans les deux.

Le code de chaque page contient un graphe JSON-LD. Sur l’accueil : un nœud WebSite, un nœud ProfilePage dont l’entité principale est un nœud Person, et les organisations où j’ai travaillé. ProfilePage est le type que Google documente pour les pages d’auteur et les pages « à propos » ; il requiert une entité principale et recommande une date de création et une date de modification, que je maintiens à la main quand le contenu change.

Le nœud Person porte mon nom et ses variantes, mon poste, mon employeur, mes compétences et mon profil LinkedIn. Deux choix méritent une explication.

D’abord, le parcours. Schema.org n’a pas de propriété « ancien employeur ». J’utilise le motif Role documenté par schema.org : worksFor contient des objets OrganizationRole, chacun avec l’organisation, l’intitulé, une date de début et, pour les postes passés, une date de fin. Google n’en tire aucun résultat enrichi, donc aucune erreur possible dans le test des résultats enrichis, et un modèle y lit sans ambiguïté qui, où, quand.

Ensuite, les compétences. Les entrées de knowsAbout qui correspondent à un concept bien identifié pointent vers son identifiant Wikidata : Q180711 pour le SEO, Q3620772 pour l’ASO, Q28865 pour Python. Pour les autres, l’URL de la documentation officielle sert de désambiguïsation. Je n’ai rien ajouté que je ne puisse vérifier : mon école dans alumniOf et mes deux langues dans knowsLanguage, sur la page Parcours ; aucune photo de substitution dans image.

Les articles de ce blog portent un nœud BlogPosting dont l’auteur renvoie au nœud Person de l’accueil. L’accueil est la page auteur. Il n’y en a pas d’autre.

Chaque acteur sépare aujourd’hui ses robots en deux familles. Chez OpenAI, OAI-SearchBot alimente la recherche de ChatGPT et GPTBot l’entraînement des modèles (documentation OpenAI). Chez Anthropic, Claude-SearchBot et Claude-User d’un côté, ClaudeBot de l’autre (documentation Anthropic). Chez Google, le jeton Google-Extended couvre l’entraînement de Gemini et le grounding dans l’application Gemini, mais pas AI Overviews ni AI Mode, qui dépendent de Googlebot.

Pour les robots de recherche et de citation, la question ne se pose pas : les bloquer, c’est disparaître de ChatGPT, de Claude ou de Perplexity. Pour les robots d’entraînement, c’est un choix, et je l’ai fait : tout est autorisé. Un éditeur de presse a de bonnes raisons de refuser que ses articles servent à entraîner des modèles. Un CV a la raison inverse : je veux qu’un modèle sache qui je suis, même sans recherche en direct. Et bloquer Google-Extended me retirerait au passage des réponses de l’application Gemini.

Ce choix est réversible. Le 30 octobre 2026, Google, Microsoft, OpenAI et Anthropic ont annoncé le soutien d’un signal partagé d’opt-out d’entraînement dans robots.txt, User-agent: __usage_ai-training, en cours d’adoption pour 2027. Mon fichier contient ce bloc, commenté, avec les jetons propriétaires. Changer d’avis prendra trente secondes.

Ce site publie un llms.txt et un llms-full.txt, au format proposé sur llmstxt.org. Je le dis clairement : aucun grand assistant n’a déclaré utiliser ce fichier, et Google écrit dans son guide qu’aucun fichier de ce type n’est nécessaire. Ahrefs a mesuré sur 137 000 domaines que 97 % des fichiers llms.txt n’avaient reçu aucune requête en mai 2026.

Pourquoi le publier, alors ? Parce qu’il est généré automatiquement à chaque build, à partir des mêmes données que les pages, et qu’il ne peut donc pas se désynchroniser. Son coût est nul et il ne nuit à rien. Mais il ne figure pas dans la liste de ce qui compte. Si vous n’avez pas déjà réglé le HTML, les données structurées et la vitesse, il n’a aucun intérêt.

Les seuils officiels des Core Web Vitals sont un LCP inférieur ou égal à 2,5 s, un INP inférieur ou égal à 200 ms et un CLS inférieur ou égal à 0,1. Je me suis fixé plus strict : LCP sous 2 s, INP sous 200 ms, CLS sous 0,05, sur mobile avec un réseau limité.

Concrètement : les polices sont hébergées sur le site, en woff2, avec une police de repli ajustée pour que le texte ne bouge pas quand elles arrivent ; les images sont servies en AVIF avec repli WebP, dimensions déclarées, et l’image principale est chargée en priorité ; le CSS critique est dans la page ; il n’y a aucun script tiers, aucune police externe, aucune mesure d’audience par défaut. Un site statique de cette taille n’a aucune excuse pour être lent.

Rien de ce qui précède ne garantit d’être cité par un assistant. Les moteurs génératifs puisent dans un index de recherche et choisissent leurs sources ; un CV personnel ne sera cité que pour des questions qui portent sur son sujet, c’est-à-dire sur moi. Ce que je peux garantir, c’est que lorsque la question sera posée, la réponse sera disponible dans un format qu’aucune machine ne peut mal lire : du HTML clair, des phrases complètes, des entités identifiées, des dates explicites, et des fichiers techniques qui disent la même chose que les pages.

Je mesurerai le résultat avec le rapport « Generative AI » de la Search Console et avec les requêtes sur mon nom. Les articles suivants de ce blog reprendront ces sujets un par un, avec des tests reproductibles sur ce site.

Si vous travaillez sur ces questions dans un média ou une plateforme, écrivez-moi ou retrouvez-moi sur LinkedIn (nouvelle fenêtre).

Faut-il un fichier llms.txt pour apparaître dans les réponses des IA ?

Non. Google indique explicitement qu’aucun fichier spécifique n’est nécessaire, et aucun grand assistant n’a déclaré utiliser llms.txt. Ce site en propose un parce qu’il est généré automatiquement et ne coûte rien, pas parce qu’il rapporte quelque chose.

Bloquer GPTBot empêche-t-il d’apparaître dans ChatGPT ?

Non. GPTBot sert à l’entraînement des modèles ; la recherche de ChatGPT passe par OAI-SearchBot. Les deux se contrôlent séparément dans robots.txt. Ce site autorise les deux.

Les données structurées sont-elles indispensables pour les moteurs génératifs ?

Non. Google précise qu’elles ne sont pas requises pour ses fonctionnalités d’IA. Elles restent utiles pour les résultats enrichis et pour lever toute ambiguïté sur l’entité décrite, ce qui est l’objectif ici.