Microsites de services : quand un site distinct se justifie, et comment éviter leur prolifération

Un test de décision pour savoir si un service, un programme ou une campagne obtient son propre microsite ou une section du site principal, plus des règles de nommage et de domaine, un formulaire d'approbation, un cycle de vie avec date de fin et un modèle de registre pour les organisations qui gèrent de nombreux sites.

Toutes les grandes organisations connaissent le même débat. Le service des parcs veut son propre site parce que le site principal est trop lent à faire évoluer. L'équipe du tourisme veut un site avec son propre style. Un programme financé par une subvention doit être en ligne dans trois semaines. Chaque demande est raisonnable prise isolément. Dix ans plus tard, on compte quarante sites, une douzaine de domaines dont personne ne se souvient de l'achat, six pages de contact différentes et personne pour dire lesquels sont encore maintenus. Ce guide vous donne un test pour dire oui ou non, les règles à associer à un oui, et une méthode pour retirer les sites avant qu'ils ne se dégradent.

Ce que nous entendons par microsite

Un microsite est tout site web situé hors de la navigation et des modèles de votre site principal, avec sa propre adresse. Il peut s'agir d'un sous-domaine (parks.example.gov), d'un domaine distinct (visitexample.com) ou d'un site sur une plateforme tierce. Une section du site principal (example.gov/parks) n'est pas un microsite, même si elle a sa propre bannière. La distinction compte, car une section hérite de vos modèles, de votre recherche, de votre navigation, de vos corrections d'accessibilité et de votre processus de relecture. Un microsite n'hérite de rien de tout cela, sauf si vous le prévoyez.

Le test de décision

Demandez à l'équipe demandeuse de répondre par écrit à ces sept questions. Un microsite ne se justifie que si la réponse est oui à au moins deux des quatre premières questions, et oui aux trois dernières.

#	Question	Pourquoi c'est important
1	Le public est-il surtout composé de personnes qui ne visiteraient jamais le site principal (touristes, investisseurs, public national) ?	Si le public est constitué d'habitants ou de membres, ils chercheront d'abord sur le site principal
2	A-t-il besoin d'une identité visuelle différente de celle de l'organisation mère, pour une raison qui dépasse les préférences de l'équipe (un partenariat, un organisme à gouvernance distincte) ?	« Nous voulons notre propre style » n'est pas une raison ; « c'est une coentreprise avec deux autres comtés » en est une
3	A-t-il besoin de fonctions que le site principal ne peut pas offrir (boutique, réservations, espace membres) ?	Vérifiez d'abord si la plateforme principale peut les ajouter
4	S'agit-il d'une campagne limitée dans le temps avec une date de fin claire ?	Les campagnes sont le cas le plus adapté, à condition qu'elles se terminent vraiment
5	Y a-t-il un propriétaire nommé, par fonction, qui le maintiendra pendant toute sa durée de vie ?	C'est sur les sites sans propriétaire que s'accumulent les contenus obsolètes et inaccessibles
6	Utilisera-t-il les modèles approuvés de l'organisation ou respectera-t-il le même niveau d'exigence en accessibilité et en sécurité ?	Un microsite reste votre contenu ; au titre de l'ADA Title II, un contenu fourni par un prestataire reste celui de l'entité publique
7	Existe-t-il un budget pour son fonctionnement et pour son retrait ?	Les domaines, l'hébergement, les tests et le travail de fermeture coûtent de l'argent chaque année

Si la demande échoue, proposez une section du site principal avec une page d'accueil distincte. La plupart des équipes qui demandent un microsite veulent en réalité trois choses : de la rapidité, une page qu'elles maîtrisent et une adresse courte. Une bonne section avec une édition déléguée et une redirection courte leur apporte les trois.

Section, sous-domaine ou domaine distinct

Une fois qu'une présence distincte est justifiée, choisissez son adresse en connaissance de cause.

Option	À utiliser quand	Coûts et risques
Section : example.gov/parks	Le choix par défaut pour tout service ou programme permanent	Suppose que la plateforme principale soit assez simple à modifier pour le service
Sous-domaine : parks.example.gov	Une application distincte ou un site sur une autre plateforme, clairement rattaché à l'organisation	Les moteurs de recherche peuvent le traiter comme un site distinct ; analytique et certificats séparés à gérer
Domaine distinct : visitexample.com	Publics extérieurs à votre territoire, partenariats, campagnes portant leur propre nom	Renouvellement annuel, risque de sosies utilisés pour l'hameçonnage, les habitants ne peuvent pas savoir qu'il est officiel, autorité de liens partant de zéro
Redirection courte : example.gov/fair	Une campagne qui a besoin d'une adresse imprimable	Aucun qui vaille la peine d'être mentionné ; utilisez-les sans retenue

Pour les organismes publics américains, il existe une raison supplémentaire de tout garder sous un même nom. Le registre .gov, géré par la CISA, indique que les organisations ne peuvent généralement pas obtenir plus d'un domaine .gov, variantes de nom comprises. Un service qui veut son propre nom finit donc généralement sur un domaine commercial, auquel les habitants ont moins de raisons de faire confiance. Un sous-domaine de votre .gov conserve le signal officiel.

Les règles de nommage à adopter

Les sous-domaines utilisent le nom du service que les gens recherchent (parks, library, permits), jamais des noms de divisions internes ou des sigles.
Un seul mot si possible, sans tirets ni chiffres. Les conseils de get.gov pour les noms en .gov (mémorables, faciles à prononcer, sans tirets ni chiffres) sont aussi une bonne règle pour les sous-domaines.
Les domaines distincts sont enregistrés par l'informatique centrale, au nom de l'organisation, sur le compte de l'organisation, jamais avec la carte d'un employé.
Les enregistrements défensifs des sosies évidents d'un domaine distinct méritent d'être envisagés, car les habitants comme les fraudeurs les trouvent.
Le pied de page de chaque site nomme l'organisation mère et renvoie au site principal.

Le formulaire de demande de microsite

Copiez-le dans votre formulaire de demande. Obliger le demandeur à rédiger ses réponses écarte à lui seul la plupart des demandes fragiles.

Champ	Réponse
Nom du site et adresse proposée
Service demandeur et fonction du propriétaire (pas seulement le nom d'une personne)
Fonction du propriétaire suppléant
Public visé et les trois principales tâches qu'il effectuera
Réponses au test des sept questions
Pourquoi une section du site principal ne convient pas
Plateforme et modèle à utiliser
Fonctions nécessaires (formulaires, réservations, boutique, espace membres)
Date de lancement et date de fin ou de révision prévue
Budget annuel, y compris domaine, tests et retrait
Qui approuve les contenus avant leur mise en ligne
Plan de tests d'accessibilité avant le lancement

Gérer tous les sites depuis un seul endroit

Le vrai coût des microsites n'est pas leur création. C'est que chacun finit sur une plateforme différente, avec un identifiant différent, un prestataire différent et une idée différente de ce que signifie « terminé ». La règle la plus efficace est que chaque microsite approuvé soit construit sur une plateforme que l'équipe web centrale peut voir et gérer. Vous obtenez ainsi :

Une liste de tous les sites, avec leur statut, que personne n'a à tenir à la main.
Des modèles et une identité visuelle partagés : une correction de l'en-tête ou un changement de couleur se fait une seule fois.
Des accès que vous pouvez retirer quand quelqu'un s'en va, sans rien demander à un prestataire.
Une étape de relecture que vous contrôlez avant la mise en ligne de tout site.
Un historique de qui a modifié quoi.

Une liste de sites avec recherche, étiquettes et une colonne de statut affichant Active et Invited — Tous les sites d'une même marque dans une seule liste, avec étiquettes et statut. Sur notre marque de démonstration, les sites sont des entreprises fictives ; dans une organisation, ce seraient des services et des programmes.

Les couleurs et polices de la marque définies une seule fois pour tous les sites. Les services partent du même style au lieu d'en inventer un.

Déléguer sans perdre le contrôle

Les services demandent des microsites surtout parce qu'ils veulent publier sans attendre. Donnez-leur cette possibilité, dans certaines limites :

Peut le faire sans demander	Nécessite une validation centrale
Modifier les textes, images et événements de son propre site	Lancer le site, et le relancer après une refonte
Ajouter des actualités et des pages dans le cadre du modèle	Connecter un nouveau domaine
Inviter des collègues à modifier le site	Ajouter une boutique, des paiements ou un espace membres
Demander une redirection courte	Changer le modèle ou les couleurs de la marque

Les réglages d'un site avec sa limite de sites et des interrupteurs pour la publication, la connexion de son propre domaine, l'affichage du code, le blog, la boutique, les formulaires et le SEO — Des interrupteurs par site déterminent ce que le site de chaque service peut faire : publier, connecter son propre domaine, gérer un blog, une boutique ou des formulaires.

Un cycle de vie avec une fin

Les microsites meurent rarement de façon délibérée. Prévoyez la fin dès le départ.

Approuvez avec une date de fin (campagnes) ou une date de révision à deux ans maximum (programmes).
Lancez uniquement après le test d'accessibilité et la relecture des contenus.
Révisez chaque année. Le propriétaire est-il toujours en poste ? Les visites justifient-elles le coût ? Les contenus sont-ils à jour ? Le site réussit-il toujours le test des sept questions ?
Retirez en déplaçant dans le site principal tout ce qui reste utile, en redirigeant chaque ancienne URL vers sa nouvelle adresse ou la page pertinente la plus proche, en archivant ce qui doit être conservé, et en gardant le domaine enregistré pendant un temps pour que personne ne puisse l'acheter et se faire passer pour vous.
Supprimez le site du registre, révoquez les accès et consignez la date.

Un journal d'audit listant les actions récentes avec des colonnes heure, action et utilisateur — Un journal d'audit des actions de l'organisation : utile au moment de la révision pour voir qui a modifié quoi sur quel site.

Le registre des microsites

Tenez un seul tableau. Les premières étapes proposées par ADA.gov pour la règle web du Title II commencent par savoir combien de sites vous avez ; ce registre en est la réponse, tenue à jour.

Site	Adresse	Fonction du propriétaire	Plateforme	Lancement	Date de révision ou de fin	Dernier test d'accessibilité	Statut
Exemple : Lecture d'été 2027	example.gov/read	Responsable des services jeunesse	Plateforme principale	2027-05	Fin 2027-09	2027-04	En ligne

Les erreurs qui se répètent

Laisser le prestataire détenir le domaine. Quand le contrat prend fin, l'adresse part avec lui. Notre plan de sortie d'un prestataire explique comment tout récupérer.
Un microsite à chaque réorganisation. Les services fusionnent et changent de nom ; les adresses doivent suivre les services rendus, pas les organigrammes.
Les contenus en double. Les mêmes horaires d'ouverture sur le site principal et sur le microsite divergeront en moins d'un an. Gardez une seule source et faites un lien vers elle.
Plus de propriétaire après la fête de lancement. La personne qui a porté le site passe à autre chose ; nommez une fonction, pas une personne.
Sauter la relecture parce que ce n'est « qu'une campagne ». Les sites de campagne sont des contenus publics comme les autres.

Intégrez les règles ci-dessus à votre politique de gouvernance web pour qu'elles survivent aux changements de personnel, et ajoutez les exigences de plateforme à votre appel d'offres lors de votre prochaine consultation.

La place de We.Inc

We.Inc est une plateforme web en marque blanche : une marque, de nombreux sites, gérés depuis un même espace d'administration. Une organisation peut y apposer son propre nom et donner à chaque service ou programme son propre site. Ce qui est vrai aujourd'hui :

Une liste de tous les sites de la marque, avec étiquettes et statut.
Des réglages de marque partagés (logo, couleurs, polices) et des modèles communs.
Des rôles propriétaire, administrateur et membre, plus des interrupteurs par site pour la publication, les domaines personnalisés, les formulaires, le blog et la boutique.
Une approbation facultative en une étape avant la mise en ligne d'un site.
Des domaines personnalisés par site, un journal d'audit des actions de l'organisation, et le téléchargement complet du code ou l'export GitHub.

Les sites sont créés par IA à partir de modèles et d'instructions : chaque site nécessite donc toujours votre propre relecture d'accessibilité et de contenu avant le lancement ; nous ne prétendons pas qu'un site soit conforme aux WCAG. Pour voir une marque configurée avec plusieurs sites de services, réservez une démo. La présentation pour le secteur public se trouve sur notre page administrations publiques.

Sources

Dernière vérification le 2026-10-25.

get.gov (CISA), Choosing a .gov domain name (un domaine par organisation, conseils de nommage).
get.gov (CISA), Requirements for operating a .gov domain.
ADA.gov, First Steps Toward Complying with the Title II Web and Mobile Application Accessibility Rule (inventaire des sites web).
ADA.gov, Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments (contenus confiés à des prestataires).

Ce guide fournit des informations générales, pas un conseil juridique.

Questions fréquentes

Quand un service doit-il avoir son propre microsite ?

Quand son public ne visiterait pour l'essentiel pas le site principal, qu'il a besoin d'une identité distincte pour une raison qui dépasse les préférences, qu'il a besoin de fonctions que le site principal ne peut pas offrir, ou qu'il s'agit d'une campagne limitée dans le temps, et qu'il a en outre un propriétaire nommé, respecte le même niveau d'exigence en accessibilité et en sécurité, et dispose d'un budget pour son fonctionnement et son retrait.

Les sites de services doivent-ils utiliser un sous-domaine ou un sous-répertoire ?

Une section du site principal est le choix par défaut pour les services et les programmes permanents. Utilisez un sous-domaine pour une application distincte clairement rattachée à l'organisation, et un domaine distinct uniquement pour des publics extérieurs, des partenariats ou des campagnes portant leur propre nom.

Une ville peut-elle obtenir un domaine .gov distinct pour chaque service ?

En général, non. get.gov indique que les organisations ne peuvent généralement pas obtenir plus d'un domaine .gov, variantes de nom comprises : les services utilisent donc généralement des sections ou des sous-domaines du .gov principal.

Comment retirer un microsite en toute sécurité ?

Déplacez dans le site principal les contenus encore utiles, redirigez chaque ancienne URL, archivez ce qui doit être conservé, gardez le domaine enregistré pendant un temps pour que personne d'autre ne puisse l'utiliser, puis révoquez les accès et mettez à jour le registre.

We.Inc peut-il gérer de nombreux sites de services sous une même marque ?

Oui. We.Inc gère de nombreux sites sous une même marque avec une identité partagée, des rôles, des droits par site, une approbation facultative de publication en une étape, un journal d'audit, des domaines personnalisés et l'export du code. Chaque site nécessite toujours vos propres tests d'accessibilité.