Menu

Questions fréquentes · orientation numérique

FAQ des catalogues, portails, PWA et livrets numériques

Réponses pratiques sur les catalogues d’applications, l’installation Web, le hors-ligne, les liens profonds, les livrets privés, l’indexation, les comptes et la continuité des accès.

Un portail et une application, est-ce la même chose ?

Non. Un portail oriente vers plusieurs ressources ou services ; une application réalise un parcours métier précis. Le portail peut décrire une destination, son public et ses limites sans exécuter ses fonctions ni partager ses données.

La distinction évite de croire qu’un catalogue central contrôle les comptes, les paiements ou les contenus des applications qu’il référence. Dans My DOHM, chaque produit reste indépendant et la fiche du catalogue renvoie vers le site-guide, la démo ou l’application seulement lorsque cette destination est qualifiée.

Faut-il créer un compte pour utiliser un catalogue ?

Pas lorsque le besoin consiste à découvrir ou retrouver des ressources publiques. Un compte ajoute identité, reconnexion, récupération, sécurité, droits et durée de conservation ; cette complexité doit répondre à une personnalisation ou à des données privées réellement nécessaires.

My DOHM expose son catalogue sans compte. Les comptes éventuels appartiennent aux applications concernées. Le catalogue ne déduit jamais qu’une personne possède déjà un compte et ne transporte pas une session d’une application à l’autre.

Qu’est-ce qu’une PWA ?

Une Progressive Web App est une application Web qui peut combiner un manifest, un service worker et des comportements adaptés à l’installation. Le manifest décrit notamment le nom, les icônes et l’URL de démarrage ; le service worker peut gérer certaines requêtes et ressources en cache.

Le sigle ne garantit ni installation sur tous les appareils, ni fonctionnement complet hors ligne, ni présence dans un Store. Ces capacités doivent être vérifiées sur les navigateurs et parcours visés.

Installer une PWA revient-il à télécharger une application native ?

Non. L’installation Web ajoute généralement une expérience au lanceur ou à l’écran d’accueil à partir du navigateur. Elle ne prouve pas l’existence d’un APK, d’un AAB, d’un paquet iOS ou d’une publication sur un Store.

Un CTA « installer » n’est honnête que si le domaine applicatif est public et si le parcours d’installation a été qualifié. Quand seule une démo existe, le site doit proposer de la tester et masquer l’installation non prouvée.

Une PWA fonctionne-t-elle forcément hors connexion ?

Non. Le hors-ligne dépend des fichiers et données effectivement mis en cache, de leur version, du quota disponible, des migrations et de la manière dont l’interface gère une requête impossible. Un shell peut s’ouvrir sans que le parcours métier soit utilisable.

La preuve doit donc nommer les routes et actions testées hors réseau. Les données changeantes, les droits, les paiements et les opérations partagées ne doivent pas être présentés comme disponibles hors ligne sans contrat spécifique.

Quelle différence entre une démo et l’application publique ?

Une démo illustre un parcours avec des données fictives ou isolées et doit le signaler. Elle peut être publique sans ouvrir les comptes, notifications, paiements ou intégrations réelles attendus du produit.

L’application publique est qualifiée pour les profils et capacités annoncés sur sa cible canonique. Le registre My DOHM conserve ces deux destinations séparées : TESTEZ L’APP vise la démo ; S’INSCRIRE, OUVRIR ou INSTALLER n’apparaît qu’avec une preuve applicative correspondante.

Comment savoir si une capacité est réellement ouverte ?

Lire le périmètre vérifié, la limite et la date de révision de la fiche. Une preuve publique précise le profil, la destination, la version et la nature des données utilisées. Une capture, un écran de connexion ou une recette locale ne suffisent pas à qualifier une inscription publique.

Quand une fonction reste en vision ou validée seulement localement, elle doit être écrite au futur ou retirée du CTA. Le site-guide ne complète jamais une URL absente et ne transforme pas une démonstration en service réel.

Qu’est-ce qu’un lien profond ?

Un lien profond conduit vers une fonction ou un contenu précis, par exemple une recette, une mission ou un guide, au lieu d’envoyer systématiquement vers l’accueil. Il réduit les étapes à condition que son format soit stable et que la destination sache interpréter les paramètres autorisés.

Le lien doit prévoir un fallback accessible lorsque l’application ne s’ouvre pas. Il ne doit transporter que des identifiants publics ou des références opaques prévues par contrat, jamais un stock, une liste, une adresse, un message privé ou un secret.

Pourquoi une ancienne URL doit-elle parfois rediriger ?

Un changement de nom ou de domaine ne doit pas casser les favoris, les liens éditoriaux et les références externes. Une redirection HTTP peut conduire l’ancienne route vers la nouvelle origine canonique tout en conservant la version précédente comme rollback technique.

La cible doit préserver la route profonde lorsque le contenu existe encore. Servir deux copies indexables avec des canonicals divergents crée de l’ambiguïté ; supprimer l’ancienne origine avant vérification retire la possibilité de revenir en arrière.

Le canonical protège-t-il une page privée ?

Non. Le lien canonical indique l’URL de référence d’un contenu indexable ; il n’empêche ni l’accès, ni le partage, ni l’exploration. Une page privée exige un contrôle d’accès applicatif et une politique de cache adaptée.

De même, robots.txt et noindex donnent des consignes aux robots mais ne remplacent pas l’autorisation. La RFC 9309 précise que le protocole d’exclusion des robots n’est pas une mesure de contrôle d’accès.

Qu’est-ce qu’un livret numérique ?

Un livret numérique rassemble des informations destinées à accompagner un contexte, par exemple un séjour. Sa lecture peut être proposée sans compte, mais cela ne rend pas son contenu public ni indexable.

Le guide public explique le concept et les précautions ; le moteur applicatif contrôle le contenu, l’accès, l’expiration et les actifs associés. mydohm.com ne reçoit aucune donnée de réservation, d’hébergement ou de séjour.

Consulter un livret signifie-t-il le conserver ?

Non. Consultation et conservation sont deux actions différentes. La première permet de lire ce qui a été transmis ; la seconde garderait une référence ou une information au-delà de cette lecture et doit donc être proposée séparément.

Une conservation facultative doit expliquer sa finalité, sa durée ou son critère, ainsi que le retrait possible. My DOHM ne publie aucun CTA de conservation tant qu’une passation applicative publique n’a pas qualifié ce parcours.

Pourquoi éviter les données de séjour dans une URL ?

Une URL peut apparaître dans l’historique, des captures, des journaux, des outils de diagnostic et des en-têtes de référence. Nom, dates, adresse, réservation, code d’accès et message personnalisé ne doivent donc pas y être encodés.

Quand une référence est nécessaire, elle reste opaque, bornée, révocable et vérifiée côté service. Une adresse difficile à deviner n’est pas à elle seule une autorisation.

Un cache long est-il toujours préférable ?

Non. Les actifs immuables et versionnés bénéficient d’un cache long parce que leur adresse change avec leur contenu. Une page éditoriale peut utiliser une revalidation raisonnable. Un statut, un prix, une disponibilité ou un programme daté exige une fraîcheur plus courte.

Une réponse personnalisée ou authentifiée ne doit jamais rejoindre un cache partagé sans conception explicite. La politique doit définir la clé, la durée, l’invalidation, le rollback et le comportement hors ligne.

Les applications DOHM partagent-elles automatiquement leurs données ?

Non. Les produits sont indépendants et leurs données, comptes et règles ne fusionnent pas par défaut. Un lien contextuel vers une autre application ne transmet pas le dossier métier en arrière-plan.

Une interopérabilité future doit reposer sur un contrat versionné, un consentement adapté, une quantité minimale de données et un mécanisme de révocation. My DOHM sert de hub d’orientation ; il n’est pas un entrepôt transverse.

Que faire si une destination ne répond plus ?

Vérifier d’abord si le problème concerne le site-guide, la démo, l’application ou une route profonde. Une page 404 réelle vaut mieux qu’un faux succès renvoyant l’accueil pour toute adresse inconnue, car elle permet de distinguer une route absente.

Le catalogue doit masquer un CTA devenu non qualifié, conserver la preuve et proposer un repli officiel lorsqu’il existe. Il ne doit ni inventer une URL voisine, ni maintenir une promesse au présent pendant que la destination est indisponible.

Comment signaler une erreur dans une fiche ?

Indiquer la page, le passage concerné et une source vérifiable sans transmettre de donnée de compte, de séjour ou de métier. La correction relit le canonique produit, met à jour la date de révision et contrôle les autres pages utilisant le même fait.

Une affirmation devenue invérifiable est qualifiée ou retirée. L’historique technique et le rollback sont conservés ; ils ne deviennent pas pour autant une seconde version indexable.

My DOHM remplace-t-il les sites-guides spécialisés ?

Non. My DOHM résume les applications et leurs accès vérifiés. Chaque site-guide développe le problème, les besoins, les familles de solutions, leurs limites, la réponse du produit et une bibliothèque encyclopédique propre au domaine.

Le hub évite de devoir mémoriser chaque domaine. Il renvoie vers le guide spécialisé avant la démo ou l’application lorsque le lecteur doit comprendre, comparer ou préparer une décision.

Comment choisir entre favoris, document, portail et PWA ?

Commencer par le public, le nombre de destinations, leur fréquence de changement, le besoin de contexte, la confidentialité et la portabilité. Quelques liens individuels stables peuvent rester dans des favoris ; une équipe peut préférer un document maintenu ; un public large bénéficie d’un annuaire ou d’un portail ; un usage mobile récurrent peut justifier une PWA.

Le compte n’est pertinent que si des droits ou préférences privées sont nécessaires. Le comparatif dédié détaille les critères, profils, coûts de maintenance et limites sans attribuer de classement commercial.

À quelle fréquence faut-il réviser un catalogue ?

Il n’existe pas de fréquence universelle. Une destination changeante, un statut produit ou un programme daté demande une vérification plus rapprochée qu’une définition issue d’un standard stable. Chaque fiche doit indiquer sa date de révision et sa preuve.

Un contrôle est aussi déclenché par un changement de nom, de domaine, de version publique, de CTA ou de limite. La révision porte sur les routes transverses concernées, sans relancer une campagne globale sur les sites inchangés.

Sources

Éditeur : DOHM — Digital Operations Hub & Modules · informations revues le . Signaler une correction.