Du répertoire de liens au catalogue PWA : histoire pratique des portails et livrets numériques

Des listes et classeurs aux liens hypertextes

Avant le Web, une organisation regroupait déjà ses ressources dans des index, classeurs, catalogues imprimés ou listes de contacts. Leur force était la lisibilité locale ; leur limite venait de la mise à jour et de la diffusion. Une nouvelle édition devait être imprimée ou transmise, et le lecteur ne pouvait pas vérifier automatiquement si une destination restait disponible.

Le Web proposé au CERN en 1989 puis mis en œuvre autour d’un navigateur, d’un serveur et d’adresses reliées par hypertexte a rendu possible une autre forme de catalogue : chaque entrée peut conduire vers une ressource autonome. Le lien ne garantit cependant ni la qualité de la destination, ni son statut, ni le droit d’y accéder. Le travail éditorial demeure : décrire, classer, vérifier et corriger.

1. Avant le Web · Répertoires matériels

   Classeurs, listes et catalogues rassemblent les références mais vieillissent dès qu’une destination change.

2. 1989–1990 · Le Web relie des ressources

   Le projet du CERN associe hypertexte, adresses, serveur et navigateur pour consulter des documents reliés.

3. Web public · Annuaires, favoris et moteurs

   La découverte, la sélection personnelle et la recherche deviennent trois fonctions distinctes.

4. Services en ligne · Portails et comptes

   Des organisations réunissent accès, identité et services, au risque de confondre orientation et centralisation.

5. Applications Web · Manifeste et installation

   Un manifeste fournit des métadonnées d’application ; l’installation reste différente de l’usage et du compte.

Six notions à ne pas confondre

Les mots ci-dessous décrivent une fonction dominante. Un même produit peut en réunir plusieurs, mais cette réunion doit être visible et contrôlable.

Du site au service installable : le rôle des standards

HTTP définit la sémantique commune des requêtes et réponses du Web, mais pas le sens métier d’une fiche produit. Une URL identifie une ressource ; elle ne doit pas transporter une donnée privée par commodité. Le canonical éditorial indique la version de référence d’une page publique, sans transformer une origine technique en identité de produit.

Le Web Application Manifest du W3C décrit des métadonnées associées à une application Web, comme son nom, ses icônes et son URL de démarrage. Il peut contribuer à une expérience installable ; il ne crée ni compte, ni stockage durable garanti, ni accès hors ligne à lui seul. Ces capacités dépendent du navigateur, du code et des données réellement disponibles.

La définition NIST du cloud distingue notamment libre-service, accès réseau, mutualisation, élasticité et mesure. Elle aide à qualifier un mode de fourniture, mais ne dit pas si un portail est ergonomique, si les données sont minimisées ou si le service convient à un parcours donné.

Acteurs et responsabilités d’un catalogue fiable

L’éditeur du portefeuille nomme les produits, leurs périmètres et leurs limites. Le responsable du catalogue vérifie les fiches, les liens et les statuts. L’équipe de chaque produit fournit la preuve fraîche de sa destination et de ses capacités. Le lecteur choisit selon son besoin et décide séparément d’ouvrir, d’installer ou de créer un compte lorsque ces actions existent.

Ces rôles limitent les affirmations circulaires. Un catalogue ne certifie pas une fonction simplement parce qu’il l’affiche ; il consomme une preuve versionnée du produit. Une fiche peut rester publique avec un statut honnête même si son application est indisponible, à condition de masquer le bouton concerné.

• Éditeur : gouvernance des noms, promesses et corrections.
• Produit : preuve de la version, des profils et des destinations.
• Catalogue : présentation cohérente et boutons conditionnels.
• Site-guide : réponse éditoriale indépendante de l’installation.
• Utilisateur : choix explicite entre lire, ouvrir, installer ou s’inscrire.

Cycle de vie d’une fiche et d’un lien

Une fiche commence par un identifiant stable, une promesse bornée, un public, une limite et une page-guide. Une destination reçoit un type — site, démonstration, application, installation ou inscription — et un statut. Le catalogue ne l’affiche qu’après vérification, puis conserve la date et la preuve qui ont motivé la décision.

Lorsqu’une URL change, l’ancienne origine reste disponible pour rollback ou redirige vers la nouvelle référence si cette continuité est validée. Une redirection ne doit pas masquer un changement de produit ou conduire vers une page générique. Si la preuve expire ou si la destination échoue, le bouton est retiré sans supprimer la fiche ni inventer un remplacement.

1. Définir l’identifiant, le besoin, le public et la limite.
2. Publier une page-guide utile avant le CTA.
3. Qualifier séparément site, démo, application, installation et inscription.
4. Vérifier la destination avec le profil réellement autorisé.
5. Afficher le bouton et dater sa preuve.
6. Surveiller l’expiration, corriger ou masquer sans casser la fiche.
7. Conserver l’origine précédente et la procédure de rollback.

Livrets numériques : orientation publique, contenu privé

Le livret reprend une fonction ancienne — rassembler les informations utiles à un lecteur — dans une forme consultable par lien. La page publique peut expliquer la méthode, les rôles et les précautions ; le contenu d’un séjour ne devient pas pour autant une page éditoriale. Dates, adresse, code d’accès, identité ou consignes privées restent hors du sitemap, des données structurées et des mesures publiques.

La consultation sans compte et la conservation facultative sont deux décisions. Un catalogue peut orienter vers le guide général sans recevoir le contenu du livret. Si une conservation devient disponible, elle nécessite un choix explicite, une finalité, une durée, un retrait et une preuve applicative distincte.

Avantages, limites et erreurs fréquentes

Un catalogue commun réduit la recherche répétée, rend les statuts comparables et fournit un point de correction. Sa limite principale est la fraîcheur : une fiche exacte hier peut devenir trompeuse après un changement de version, de domaine ou d’accès. La centralisation peut aussi donner l’illusion d’un compte ou d’un partage de données qui n’existe pas.

Les erreurs fréquentes consistent à afficher tous les boutons par symétrie, appeler démonstration une simple page marketing, envoyer vers une racine générique, déduire l’installation de la présence d’un manifeste, ou copier des données métier dans le catalogue. La correction consiste à séparer les types de destinations et à fermer par défaut lorsqu’une preuve manque.

Checklist de maintenance éditoriale

La qualité d’un catalogue dépend moins du nombre de fiches que de la discipline de révision. Cette checklist s’applique à chaque changement de nom, domaine, version ou capacité.

• La promesse et la limite proviennent-elles du référentiel canonique ?
• Le guide répond-il au besoin avant de proposer une action ?
• Chaque bouton décrit-il exactement son type et son état ?
• La destination a-t-elle été vérifiée avec le bon profil et la bonne version ?
• Les données métier et identifiants sensibles restent-ils hors URL et analytics ?
• Canonical, sitemap et redirections désignent-ils une seule origine active ?
• La date de révision, la preuve et le rollback sont-ils conservés ?
• Une correction peut-elle être signalée sans exposer le contenu concerné ?