Un nouveau projet de spécification propose la création d’un attribut HTML destiné à indiquer aux indexeurs et aux robots d’exploration quelles portions d’une page web sont produites par **IA**. Ce sujet gagne en importance à mesure que des obligations réglementaires européennes entrent en vigueur dans les prochains mois, mais cette solution soulève aussi des réserves sur sa pertinence technique et sémantique.
Signaler le contenu généré par l’IA
La proposition émane de David E. Weekly (profil LinkedIn). Il observe que, aujourd’hui, la plupart des approches proposées offrent un signal global indiquant qu’une page entière est produite par **IA**, mais qu’il n’existe pas de mécanisme standardisé permettant d’annoter uniquement une partie d’une page qui, par ailleurs, reste majoritairement écrite par un humain.
Weekly souligne la réalité opérationnelle du web moderne : beaucoup de pages mêlent contenu humain et passages automatisés. Un cas d’usage fréquent est celui des sites d’information qui ajoutent, par exemple, des **résumés générés par l’IA** dans une colonne latérale ou un encadré. La proposition vise précisément à pouvoir distinguer ce type de sections au niveau du balisage HTML.
Concrètement, l’idée est d’introduire un attribut HTML appliqué au niveau d’un bloc (section) de la page, et d’exploiter pour cela l’élément sémantique <aside>, déjà prévu pour marquer des contenus périphériques ou connexes. Cette approche cherche à tirer parti d’un élément sémantique existant plutôt que de créer une structure totalement nouvelle.
Weekly explique le besoin :
« Une page d’actualité peut contenir un article d’enquête rédigé par un humain et, en parallèle, un encadré de synthèse produit par **IA**. Les solutions existantes ne prennent en charge que la divulgation au niveau de la page (la balise proposée dans whatwg/html#9479) ou via des signaux au niveau de la réponse HTTP (IETF draft-abaris-aicdh-00). Aucune de ces approches ne permet de marquer des sections individuelles d’une page, ce que plus de 42 commentateurs sur l’issue WHATWG ont identifié comme une lacune importante. L’article 50 de la loi IA de l’UE (applicable en août 2026) exige un marquage lisible par machine du texte généré par des systèmes automatisés, ce qui crée une demande réglementaire pour un tel standard. »
Usage et rôle de l’élément <aside>
L’élément <aside> en HTML est conçu pour marquer des portions d’un document qui sont complémentaires par rapport au contenu principal : encadrés, barres latérales, suggestions d’articles, publicités contextuelles, etc. Sa valeur réside dans sa sémantique : il indique aux agents utilisateurs (navigateurs, lecteurs d’écran, robots) que le contenu est périphérique ou tangentiel.
La documentation de référence décrit l’élément comme suit :
Définition MDN de l’élément <aside>
« L’élément HTML <aside> représente une portion d’un document dont le contenu n’est que indirectement lié au contenu principal. Les asides sont fréquemment présentés sous forme de barres latérales ou de boîtes de mise en évidence. »
Dans ce cadre, utiliser <aside> pour marquer un bloc de **contenu généré par l’IA** paraît logique si ce bloc est vraiment périphérique. Mais la question se complique lorsque le contenu automatisé est, en pratique, intimement lié au fil narratif principal — par exemple un **résumé** qui condense l’article principal et en fait partie intégrante pour l’utilisateur.
Lorsque la sémantique entre en tension avec la conformité
Le problème central est donc sémantique : la règle d’or de l’élément <aside> exige que son contenu soit tangentiellement lié. Or un **résumé** est, par définition, une condensation du contenu principal. Que ce résumé soit rédigé par un humain ou produit par **IA**, il conserve la même relation sémantique avec l’article — il n’est pas forcément périphérique. En conséquence, appliquer un attribut réglementaire à un **<aside>** pour satisfaire une exigence légale peut créer une dissonance entre l’intention sémantique et l’usage réel.
La proposition reste débattue
Sur le dépôt GitHub qui héberge la discussion autour de cette proposition, le débat est animé. Plusieurs contributeurs pointent des préoccupations liées à l’accessibilité, à la robustesse du signal pour les crawlers et au fait que la proposition semble surtout motivée par la conformité réglementaire, plutôt que par une amélioration évidente de l’écosystème web.
Un intervenant note :
« J’ai examiné la proposition et les discussions associées, y compris les arguments pour et contre. Plus je lis, plus je doute de la nécessité pratique d’introduire ce balisage au niveau de la plateforme. À l’heure actuelle, cette approche semble principalement destinée à répondre à des exigences formelles ou réglementaires, sans démontrer clairement un bénéfice général pour l’écosystème web. »
Le point clef résumé par ce commentaire : la norme proposée risquerait d’être adoptée pour satisfaire la loi IA de l’UE sans que son utilité technique et sémantique pour les utilisateurs, les développeurs et les outils d’indexation soit pleinement prouvée. La pression réglementaire peut pousser à intégrer des balises dans des éléments sémantiques existants, même lorsque l’usage réel de ces éléments n’est pas parfaitement aligné avec la règle sémantique d’origine.
Aspects d’accessibilité et conséquences pratiques
Plusieurs voix ont attiré l’attention sur l’impact potentiel sur l’accessibilité. Les lecteurs d’écran et autres technologies d’assistance s’appuient sur la structure sémantique pour offrir une navigation efficace. Si des contenus essentiels sont enveloppés dans un <aside> simplement pour indiquer une origine « générée par **IA** », cela peut modifier la façon dont ces outils présentent l’information aux utilisateurs, voire la masquer derrière une hiérarchie inadaptée.
En outre, l’introduction d’un nouvel attribut normalisé exige un consensus sur la syntaxe, la valeur attendue (par ex. true/false, niveau de confiance, métadonnées sur le modèle) et sur la manière dont les moteurs et les systèmes automatisés doivent interpréter ce signal. Sans unifier ces aspects, on risque d’engendrer des implémentations hétérogènes et des interprétations divergentes par les robots d’indexation.
Alternatives techniques et solutions possibles
Il existe plusieurs approches alternatives ou complémentaires à l’application d’un attribut sur <aside>. Chacune a ses avantages et limites en termes de sémantique, interopérabilité et conformité :
1) Balises META au niveau de la page
Une balise <meta> dans l’en-tête document peut indiquer qu’une page contient du contenu généré par l’IA. C’est simple à implémenter, lisible par les machines et déjà exploitée pour d’autres usages SEO. Son inconvénient majeur est qu’elle ne permet pas de distinguer quelles sections spécifiques sont concernées : elle est binaire au niveau de la page.
2) Entêtes HTTP
Un signal via l’en-tête HTTP (par exemple un en-tête personnalisé) peut communiquer des informations aux crawlers sans modifier le DOM. C’est utile pour les plateformes qui contrôlent le serveur et veulent transmettre une information indépendante du code HTML. Là encore, granularity reste limitée si l’on veut marquer des segments précis.
3) Données structurées (JSON-LD / schema.org)
L’emploi de JSON-LD et de vocabulaires schema.org permet d’ajouter des métadonnées précises et extensibles. Par exemple, on peut annoter des fragments de texte comme des objets CreativeWork avec un champ précisant le type d’auteur ou le générateur. Cette méthode est déjà utilisée pour l’optimisation des résultats enrichis et offre un marquage lisible par machine sans altérer la structure sémantique du document. Cependant, elle nécessite des conventions partagées pour décrire précisément la provenance « générée par **IA** ».
4) Attributs data-* personnalisés
Les attributs HTML personnalisés (data-*) offrent une solution pragmatique : par exemple data-ai-generated="true". Ils sont aisément ajoutables et lisibles par scripts et crawlers. Mais sans normalisation officielle, chaque site ou plateforme peut employer des conventions différentes, ce qui complique l’interprétation par des tiers.
5) Étiquetage visible pour l’utilisateur
Indiquer visiblement, dans le rendu, qu’un bloc est produit par **IA** (par exemple via un petit libellé ou une icône accompagnée d’un texte explicatif) est la méthode la plus transparente pour les lecteurs humains. Cette approche répond à l’esprit de nombreuses réglementations, qui visent avant tout à informer les personnes, mais elle n’assure pas automatiquement la conformité technique requise par les systèmes de contrôle automatisés.
Conséquences pour le référencement (SEO) et les moteurs
Pour les moteurs de recherche, un signal standardisé indiquant qu’un segment est produit par **IA** pourrait avoir plusieurs usages : filtrage, priorisation d’indexation, affichage d’étiquettes dans les résultats, ou encore support pour des contrôles réglementaires automatisés. Mais l’impact exact sur le classement ou l’affichage n’est pas garanti : les moteurs resteront libres d’utiliser ou non ce signal dans leurs algorithmes.
Du point de vue du SEO, plusieurs points sont à considérer :
- Si l’attribut est interprété comme un contenu secondaire (via <aside>), les moteurs pourraient lui donner moins de poids en matière de pertinence.
- Un marquage visible pour les utilisateurs peut améliorer la confiance et la transparence, ce qui, indirectement, peut favoriser l’engagement et le référencement.
- Des balises hétérogènes ou mal utilisées risquent de créer des signaux contradictoires envoyés aux crawlers, affectant potentiellement l’indexation.
Exemple d’implémentation (illustratif)
Voici un exemple simple montrant comment un site pourrait marquer un encadré produit par **IA**. Il s’agit d’une illustration, non d’une prescription normative :
<article>
<h1>Enquête : impact climatique </h1>
<p>Contenu principal rédigé par un journaliste humain...</p>
<aside data-ai-generated="true" class="ai-summary">
<h2>Résumé généré automatiquement</h2>
<p>Résumé synthétique produit par un modèle d'IA.</p>
</aside>
</article>
Si la communauté standardise un nom d’attribut et des valeurs, ce type d’annotation deviendrait plus utile pour les outils automatisés et les autorités de conformité.
Risques et limites de la proposition
Plusieurs risques doivent être pris en compte avant d’adopter une solution fondée sur l’élément <aside> :
- Discordance sémantique : Recourir au <aside> pour un résumé faisant partie du flux principal casse la sémantique et peut nuire à l’accessibilité.
- Fragmentation : Sans standard unique, la multiplication des conventions (data-*, meta, header) rend la détection et la gouvernance difficiles.
- Contournement : Les acteurs peu scrupuleux peuvent masquer la provenance ou utiliser des balises non standard pour échapper à la réglementation.
- Complexité d’interprétation : Un simple booléen « généré par IA » peut être insuffisant : il faudra probablement préciser le degré d’automatisation, l’auteur humain éventuel, le modèle utilisé, et la date de génération.
Questions ouvertes
Plusieurs aspects restent à clarifier avant qu’une solution générale soit adoptée :
- Quel niveau de détail doit être exigé pour le marquage lisible par machine (simple indicateur vs. métadonnées complètes) ?
- Comment concilier la sémantique HTML et la nécessité réglementaire ?
- Quels tests d’accessibilité devront accompagner le déploiement d’un tel attribut pour éviter des régressions pour les utilisateurs de technologies d’assistance ?
- Qui fera respecter la conformité et selon quels critères ?
Bonnes pratiques recommandées pour les éditeurs
En attendant une normalisation définitive, voici quelques recommandations pragmatiques pour les éditeurs et développeurs :
- Favoriser la clarté pour l’utilisateur : fournir, à la fois visuellement et dans les métadonnées, une indication claire lorsqu’un bloc est produit par **IA**;
- Respecter la sémantique HTML : n’utiliser <aside> que si le contenu est réellement périphérique ; sinon préférer <section> ou des éléments sémantiques adaptés;
- Inclure des métadonnées supplémentaires via JSON-LD lorsque possible (par ex. champ « generator » ou « author » clarifiant la provenance);
- Documenter les conventions internes (noms d’attributs, valeurs) et les rendre publiques pour faciliter l’interopérabilité;
- Tester l’impact sur l’accessibilité et sur les outils d’indexation avant déploiement massif;
- Surveiller l’évolution des recommandations de la WHATWG, de l’IETF et des autorités compétentes pour rester conforme.
Exemple d’annotation JSON-LD complémentaire
Voici un schéma illustratif montrant comment on peut compléter le balisage HTML par des métadonnées JSON-LD :
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Enquête : impact climatique",
"author": {
"@type": "Person",
"name": "Journaliste Exemple"
},
"hasPart": [
{
"@type": "WebPageElement",
"name": "Résumé AI",
"isAccessibleForFree": true,
"text": "Bref résumé ...",
"creator": {
"@type": "SoftwareApplication",
"name": "Modèle de génération X",
"softwareVersion": "v1.2"
}
}
]
}
</script>Conclusion : utilité réelle vs. conformité réglementaire
La proposition d’ajouter un attribut HTML pour marquer des sections « générées par **IA** » répond à une préoccupation légitime : rendre la provenance des contenus traçable et conforme à des obligations comme l’article 50 de la loi IA de l’UE. Cependant, l’usage d’un élément sémantique existant comme <aside> crée des tensions entre l’objectif réglementaire et la précision sémantique nécessaire au bon fonctionnement du web et des technologies d’assistance.
De nombreuses alternatives techniques existent (balises <meta>, en-têtes HTTP, JSON-LD, attributs data-*, étiquetage visible). Chacune présente des avantages et des inconvénients. La meilleure voie sera probablement hybride : une indication visible pour les personnes, soutenue par un marquage lisible par machine normalisé et des métadonnées structurées, le tout sans déformer la sémantique HTML et en préservant l’accessibilité.
La discussion en cours sur GitHub montre qu’il reste des désaccords importants. Avant d’imposer une nouvelle norme, il est essentiel d’évaluer l’impact sur les outils d’indexation, sur les pratiques d’implémentation et sur les utilisateurs finaux. Une solution durable devra concilier conformité, interopérabilité, respect des standards sémantiques et accessibilité.
