Attribuer la propriété des sujets entre équipes

Quand le marketing produit, le blog, la documentation support et une équipe régionale publient tous sur un seul domaine, la duplication est structurelle et non négligente : personne ne voit l'inventaire complet et chaque équipe est jugée sur sa propre production. Les audits de cannibalisation tournent alors sans fin, nettoyant les mêmes collisions chaque trimestre. Le correctif est en amont et organisationnel, attribuer les sujets à des responsables et router les demandes, ce qui explique qu'il soit d'ordinaire refusé au motif que ce n'est pas le travail du SEO.

Le fichier de compétence

---
name: topic-ownership-across-teams
description: À utiliser lorsque plusieurs équipes publient sur le même domaine et que deux d'entre elles produisent régulièrement des pages sur le même sujet.
---

# Attribuer la propriété des sujets entre équipes

Quand le marketing produit, le blog, la documentation support et une équipe régionale publient tous sur un seul domaine, la duplication est structurelle et non négligente : personne ne voit l'inventaire complet et chaque équipe est jugée sur sa propre production. Les audits de cannibalisation tournent alors sans fin, nettoyant les mêmes collisions chaque trimestre. Le correctif est en amont et organisationnel, attribuer les sujets à des responsables et router les demandes, ce qui explique qu'il soit d'ordinaire refusé au motif que ce n'est pas le travail du SEO.

## Ce qu’il vous faut d’abord

- un inventaire d'URL complet couvrant chaque sous-dossier et tout sous-domaine publiant sous la même marque
- la liste des équipes pouvant publier sans revue SEO, toujours plus longue que prévu
- la métrique de réussite propre à chaque équipe, puisque c'est elle qui détermine réellement ce qu'elle publie
- les collisions actuelles tirées d'un export requêtes par page, comme preuve

## Méthode

1. Inventoriez qui peut publier, pas qui devrait. Incluez les équipes travaillant dans un CMS où personne au SEO n'a de compte, car ce sont elles qui produisent les collisions que vous ne voyez jamais venir.
2. Rapportez l'inventaire existant à des sujets et marquez chaque sujet déjà tenu par deux équipes ou plus. Apportez cette preuve à la discussion, car les débats de propriété menés dans l'abstrait ne se tranchent pas.
3. Attribuez à chaque sujet exactement un responsable redevable. La copropriété est précisément le mode de défaillance que ce dispositif supprime, donc un sujet à deux responsables est une décision inachevée et non un compromis.
4. Attribuez selon qui détient l'expertise et l'obligation de mise à jour, pas selon qui veut le trafic. Un sujet tarifaire confié à une équipe sans autorité sur les tarifs sera périmé en deux trimestres.
5. Écrivez la règle de routage des demandes transversales : une équipe qui a besoin de voir couvert un sujet dont elle n'est pas responsable demande une section sur la page du responsable ou un lien interne, jamais une nouvelle URL. Rendez ce chemin plus court que celui de la publication de sa propre page, sinon elle publiera sa propre page.
6. Donnez à chaque responsable la liste des requêtes sur lesquelles son sujet est jugé, pour que la propriété soit mesurable et non nominale, et réattribuez explicitement la liste quand un sujet change de mains.
7. Ajoutez une vérification avant publication qui échoue quand une URL proposée vise une requête détenue ailleurs. Une gouvernance qui repose sur le fait que les gens se souviennent du registre est exacte pendant un mois et devient une fiction après la réorganisation suivante.

## Ce que ça produit

Un registre de propriété des sujets rattachant chaque sujet à une seule équipe redevable avec sa liste de requêtes, plus la règle de routage des demandes transversales.

## Là où ça dérape

- attribuer la propriété selon l'ambition de trafic plutôt que selon qui peut maintenir la page, ce qui produit des sujets attribués que personne ne met à jour
- laisser un sujet en copropriété pour éviter une discussion politique, ce qui garantit le retour de la même collision au trimestre suivant
- écrire le registre sans la vérification avant publication, si bien que le registre décrit une structure qui n'existe plus

---

Extrait de la bibliothèque de compétences QuQi - https://www.quqi.io/fr/skills/topic-ownership-across-teams

Ce qu’il vous faut d’abord

• un inventaire d'URL complet couvrant chaque sous-dossier et tout sous-domaine publiant sous la même marque
• la liste des équipes pouvant publier sans revue SEO, toujours plus longue que prévu
• la métrique de réussite propre à chaque équipe, puisque c'est elle qui détermine réellement ce qu'elle publie
• les collisions actuelles tirées d'un export requêtes par page, comme preuve

Méthode

1. 01 Inventoriez qui peut publier, pas qui devrait. Incluez les équipes travaillant dans un CMS où personne au SEO n'a de compte, car ce sont elles qui produisent les collisions que vous ne voyez jamais venir.
2. 02 Rapportez l'inventaire existant à des sujets et marquez chaque sujet déjà tenu par deux équipes ou plus. Apportez cette preuve à la discussion, car les débats de propriété menés dans l'abstrait ne se tranchent pas.
3. 03 Attribuez à chaque sujet exactement un responsable redevable. La copropriété est précisément le mode de défaillance que ce dispositif supprime, donc un sujet à deux responsables est une décision inachevée et non un compromis.
4. 04 Attribuez selon qui détient l'expertise et l'obligation de mise à jour, pas selon qui veut le trafic. Un sujet tarifaire confié à une équipe sans autorité sur les tarifs sera périmé en deux trimestres.
5. 05 Écrivez la règle de routage des demandes transversales : une équipe qui a besoin de voir couvert un sujet dont elle n'est pas responsable demande une section sur la page du responsable ou un lien interne, jamais une nouvelle URL. Rendez ce chemin plus court que celui de la publication de sa propre page, sinon elle publiera sa propre page.
6. 06 Donnez à chaque responsable la liste des requêtes sur lesquelles son sujet est jugé, pour que la propriété soit mesurable et non nominale, et réattribuez explicitement la liste quand un sujet change de mains.
7. 07 Ajoutez une vérification avant publication qui échoue quand une URL proposée vise une requête détenue ailleurs. Une gouvernance qui repose sur le fait que les gens se souviennent du registre est exacte pendant un mois et devient une fiction après la réorganisation suivante.

Ce que ça produit

Un registre de propriété des sujets rattachant chaque sujet à une seule équipe redevable avec sa liste de requêtes, plus la règle de routage des demandes transversales.

Là où ça dérape

• attribuer la propriété selon l'ambition de trafic plutôt que selon qui peut maintenir la page, ce qui produit des sujets attribués que personne ne met à jour
• laisser un sujet en copropriété pour éviter une discussion politique, ce qui garantit le retour de la même collision au trimestre suivant
• écrire le registre sans la vérification avant publication, si bien que le registre décrit une structure qui n'existe plus

Utiliser cette compétence dans votre propre IA

Le fichier téléchargé est un simple markdown dont l'en-tête porte le nom et le déclencheur. Quand un assistant sait charger des compétences tout seul, c'est cet en-tête qu'il lit pour décider que celle-ci s'applique.

Plus dans Stratégie de contenu