Ton portfolio est lu par des machines avant de l'être par des humains

Il y a un moment, dans presque tous les shōnen, où le héros doit se présenter avant le combat. Nom, école, technique. Ce n'est pas de la politesse : c'est l'information à partir de laquelle l'adversaire — et le public — décide si tu mérites l'attention.

Ton portfolio joue ce rôle. À une différence près : en 2026, celui qui te découvre n'est souvent pas humain.

Un client cherche « développeur Mobile Money Cameroun ». Il ne parcourt plus dix résultats. Il pose la question à un assistant, qui lit, synthétise et recommande deux ou trois noms. Si ton site n'est pas lisible par cette machine, tu n'existes pas dans la réponse.

Le portfolio invisible

Le portfolio de développeur type est une application React à rendu client. Tu ouvres le HTML servi et tu trouves ceci :

<div id="root"></div>
<script src="/assets/index-a1b2c3.js"></script>

C'est tout. Zéro contenu. Le texte apparaît après exécution du JavaScript.

Google exécute du JavaScript, mais avec un budget de rendu limité et un délai qui peut atteindre plusieurs jours. Beaucoup d'autres crawlers ne l'exécutent pas du tout. Et surtout : les robots des moteurs de réponse — ceux qui alimentent les assistants — privilégient massivement le HTML servi.

Le test se fait en une commande :

curl -s https://ton-site.com | grep -c "un mot de ton contenu"

Si ça affiche 0, ton contenu n'existe pas pour une bonne partie de tes lecteurs.

Ce que j'ai changé sur ce site

Le rendu serveur, non négociable

Ce portfolio est en TanStack Start avec rendu côté serveur. Le HTML servi contient l'intégralité du texte : parcours, études de cas, articles. Le JavaScript ajoute de l'interactivité, il ne crée pas le contenu.

Ce n'est pas une préférence esthétique. C'est la condition pour être lu.

Le contenu versionné plutôt qu'en base

Décision moins évidente : le parcours et les études de cas vivent dans le dépôt, en TypeScript, plutôt que dans une base de données.

La raison immédiate était la résilience — j'ai eu une panne qui a vidé le site pendant neuf jours. Mais le bénéfice de référencement est réel : le contenu est présent au build, il ne dépend d'aucun appel réseau, et il ne peut pas disparaître silencieusement pendant qu'un robot passe.

Le critère que j'applique désormais : si le contenu change moins souvent qu'on ne déploie, il appartient au dépôt.

Les données structurées, pour être compris et pas seulement lu

Le HTML dit quoi. Schema.org dit ce que c'est. Ce site déclare :

• Person — identité, compétences, formation, liens sociaux
• ProfessionalService — l'activité, les zones desservies, le catalogue de prestations
• ItemList — les projets et les articles, avec leur ordre
• FAQPage — les questions réellement posées en avant-vente
• BreadcrumbList — la hiérarchie de navigation

Le FAQPage est le plus rentable. Les questions qu'on me pose en clientèle — délai d'une intégration Mobile Money, reprise d'un projet existant, travail à distance — sont exactement celles qu'on pose à un assistant. Y répondre en balisage structuré, c'est fournir la réponse dans le format que la machine attend.

llms.txt, l'index pour les agents

C'est la partie la plus récente et la moins connue. La convention llms.txt propose un fichier à la racine, en markdown, qui présente le site aux modèles de langage : une accroche, puis des liens annotés.

L'erreur serait d'y mettre quatre liens en dur. Le mien est généré depuis le contenu réel : chaque projet et chaque article y figure avec sa description. Et j'ai ajouté /llms-full.txt, qui contient l'intégralité des études de cas en un seul fichier texte — pour les agents qui préfèrent une source unique à un parcours page par page.

Le robots.txt autorise explicitement les robots des moteurs de réponse. Beaucoup de sites les bloquent par réflexe défensif. Pour une vitrine professionnelle, c'est un contresens : être cité par un assistant vaut autant qu'un clic.

Ce qui compte vraiment, et qu'aucune technique ne remplace

Voici où je dois être honnête, parce que tout ce qui précède ne sert à rien sans ça.

Mon site affichait, avant refonte, des descriptions de projets du genre :

« Développement d'interfaces web et mobiles responsives avec Next.js et React Native. »

C'est vrai. C'est aussi interchangeable avec dix mille autres profils. Aucun moteur, aucun modèle, aucun humain ne peut en tirer une raison de me choisir.

Les fiches disent maintenant :

« Application mobile d'apprentissage du code de la route et back-office multi-tenant marque blanche pour auto-écoles, pensés offline-first avec paiement Mobile Money. »

Même longueur. Densité incomparable. On y trouve un domaine, une contrainte technique, un modèle de distribution, un moyen de paiement — autant de prises pour une recherche réelle.

Le référencement technique amplifie le contenu ; il ne le crée pas. Un site parfaitement optimisé qui ne dit rien de spécifique reste invisible, simplement plus vite.

La longueur, puisque la question revient toujours

« Combien de mots pour être indexé ? » Il n'y a pas de seuil officiel. Mais il y a une réalité observable : un article de trois cents mots n'a pas la place de traiter un sujet, donc rien à citer, donc aucune raison d'être remonté.

Ce qui fonctionne, d'après ce que je constate :

• Un sujet, traité entièrement. Mieux vaut un texte qui répond complètement à une question qu'un survol de cinq questions.
• Une structure explicite. Des titres qui sont des questions ou des affirmations, pas des mots-clés isolés. Les modèles extraient par section.
• Du concret vérifiable. Chiffres, commandes, messages d'erreur réels, extraits de code. C'est ce qui distingue un texte d'expérience d'un texte de synthèse — et ce qui se cite.
• Des liens internes. Un article qui pointe vers le projet dont il parle crée un maillage que les crawlers suivent.

Le problème actuel, pour nous tous

Le référencement change de nature. Pendant vingt ans, l'objectif était le clic. Il devient la citation.

Ça déplace le curseur :

• Les mots-clés comptent moins que la capacité à répondre à une question.
• La position dans un classement compte moins que le fait d'être la source retenue.
• Le trafic mesuré baisse alors que l'influence réelle monte — quelqu'un peut te recommander à un client sans que tu voies passer la moindre visite.

Ce dernier point est déstabilisant. Nos outils de mesure sont conçus pour un monde où l'attention se traduit en visites. Une bonne partie de la valeur devient invisible dans l'analytics.

Ma réponse pragmatique : je ne cherche plus à maximiser le trafic. Je cherche à être la meilleure source disponible sur les quelques sujets que je maîtrise réellement — Mobile Money, offline-first, produits pour marchés africains. Sur ces sujets, il y a peu de contenu francophone sérieux écrit par quelqu'un qui l'a fait.

C'est une stratégie de niche assumée. Elle ne fonctionne que si le contenu est vrai.

Ce que je te conseillerais de vérifier ce soir

1. curl -s ton-site | grep "ton contenu" → si zéro, commence par là.
2. Tes descriptions de projet sont-elles interchangeables avec celles de n'importe qui ? Réécris-les avec le domaine, la contrainte, le résultat.
3. Un llms.txt existe-t-il ? Trente minutes de travail.
4. Ton robots.txt bloque-t-il les robots des assistants sans que tu l'aies décidé ?
5. As-tu du balisage Person et FAQPage ?

Dans l'ordre. Le premier point conditionne tous les autres.

Ce site est décrit sur sa propre fiche projet, et tu peux lire son llms.txt. Si ton site ne remonte pas alors que ton travail le mérite, écris-moi.