Qui fait quoi dans un catalogue d’applications ? Rôles, preuves et responsabilités

Les neuf rôles utiles

L’éditeur du portefeuille définit la gouvernance commune. Le propriétaire produit certifie les capacités et limites. Le responsable du site-guide transforme ces faits en contenu compréhensible. Le mainteneur du registre publie les destinations typées. L’hébergeur assure la disponibilité technique. Le responsable sécurité fixe les frontières et incidents. Le responsable accessibilité vérifie l’usage. Le relecteur contrôle les sources. Enfin, l’utilisateur choisit et signale les écarts.

Une petite équipe peut cumuler plusieurs rôles, mais elle doit conserver les décisions distinctes. Une même personne ne doit pas faire disparaître l’origine d’une preuve simplement parce qu’elle a réalisé le build et rédigé la fiche.

• Éditeur : vocabulaire, politique de correction et cohérence.
• Produit : fonctions, profils, version et limites.
• Catalogue : type, statut et fraîcheur des destinations.
• Guide : explication autonome avant le CTA.
• Hébergement : version servie, domaine et rollback.
• Sécurité et confidentialité : données autorisées et refusées.
• Accessibilité : navigation et compréhension avec plusieurs modalités.
• Relecture : sources, date et conflits.
• Utilisateur : choix explicite et retour d’erreur.

Matrice RACI minimale

Une matrice RACI distingue la personne responsable de l’exécution, celle qui rend compte, celles consultées et celles informées. Pour une nouvelle destination, le produit est responsable de la preuve fonctionnelle ; le catalogue rend compte de sa publication ; sécurité et accessibilité sont consultées ; les lecteurs sont informés par la date et le statut visibles.

Pour une correction éditoriale, le site-guide réalise et assume le texte, le produit est consulté sur les promesses, et le registre est informé si un lien ou un statut change. Cette matrice empêche une correction de contenu de modifier silencieusement un contrat applicatif.

Preuve, attestation et observation

Une observation décrit ce qui a été vu : un code 200, un titre, une route ou un écran. Une attestation versionnée du propriétaire produit ajoute le contexte : profil, données, services externes, limites et version. Une preuve de site confirme que le contenu public reprend cette attestation sans divergence.

Ces trois niveaux ne sont pas interchangeables. Observer un écran de connexion ne prouve pas l’inscription ; voir un manifeste ne prouve pas l’installation sur chaque plateforme ; lire une démo ne prouve pas la persistance d’un compte réel. La fiche doit annoncer le niveau exact.

Que faire quand les sources se contredisent ?

Le registre ne choisit pas la formulation la plus flatteuse. Il suspend le CTA ou conserve la capacité stable la plus étroite, consigne le conflit, puis demande une nouvelle preuve au propriétaire compétent. Une donnée vivante provenant d’un endpoint de version peut actualiser un état technique ; elle ne réécrit pas seule la promesse éditoriale.

La résolution indique la source retenue, le motif et la date. L’ancienne valeur reste dans l’historique de changement ou le rollback, jamais dans la page canonique active si elle est fausse.

1. Identifier l’affirmation exacte en conflit.
2. Comparer périmètre, date, environnement et profil de chaque preuve.
3. Fermer le CTA si la conséquence utilisateur est incertaine.
4. Obtenir l’attestation de l’autorité compétente.
5. Mettre à jour registre et contenu dans le même lot.
6. Vérifier la route publique modifiée une fois.

Cas concret : une démonstration devient une application

Au départ, une destination peut être une démo fictive sans compte. La fiche publie alors « Essayer la démo » et décrit ses limites. Plus tard, le produit ouvre une inscription autonome et fournit une preuve de reconnexion et de persistance. Le registre ajoute une destination d’inscription distincte ; il ne renomme pas arbitrairement l’ancienne démo.

Si l’application réelle échoue mais que la démo reste disponible, les deux statuts peuvent diverger. Le catalogue masque seulement le CTA concerné. Cette granularité préserve un contenu utile et évite de déclarer tout le produit indisponible à partir d’un incident localisé.

Checklist de gouvernance

Avant publication, vérifiez que chaque phrase factuelle a un propriétaire, chaque CTA un type, chaque statut une date et chaque donnée un périmètre. La checklist doit être courte assez pour être appliquée à chaque changement, mais stricte sur les frontières.

• L’autorité de la promesse est nommée.
• Le profil et l’environnement de preuve sont précisés.
• Site, démo, application, installation et inscription restent séparés.
• Les limites sont visibles près des capacités.
• Le responsable de correction et le rollback sont identifiables.
• Aucun compte central n’est présenté comme propriétaire des données métier sans contrat.

Limites de cette méthode

Une matrice de responsabilités n’empêche ni une erreur humaine ni une panne. Elle rend l’erreur localisable et la correction traçable. Elle ne remplace pas un audit de sécurité, une recette avec les profils réels ou une analyse juridique adaptée au service.

Dans une équipe réduite, la séparation des rôles est surtout documentaire. L’essentiel est de ne pas laisser une même observation servir de preuve à toutes les affirmations. Une revue indépendante devient proportionnée lorsque le changement touche l’identité, les droits, les paiements, des données sensibles ou plusieurs produits.