À quoi ressemble le « Prêt pour l'entreprise » selon vous ? (Opinions tranchées acceptées !)

J’aimerais poser une question à la communauté des gestionnaires de communautés professionnels présents ici, une question que j’ai vue abordée de manière superficielle dans d’autres contextes, mais jamais vraiment creusée selon des critères satisfaisants.

Quelle est, selon vous, votre définition de ce qui serait considéré comme « prêt pour l’entreprise » (enterprise-ready) en tant que condition pour votre communauté ? Je parle ici à la fois de la maturité et de la préparation de la plateforme communautaire, ainsi que du contenu et de l’activité de base établis. Je suis impatient de me voir contredire sur le fait que c’est davantage un art qu’une science, et qu’il existe certains modèles clairs et partagés en jeu ici !

L’activité est probablement plus facile à évaluer, car il existe de nombreuses références.

L’une des définitions fréquemment citées de « actif » dans les forums est celle de Reddit pour ce qui constitue un subreddit « actif », que j’ai utilisée par le passé comme règle empirique pour mesurer le succès de l’établissement d’un noyau critique. Historiquement, cela signifie « au moins cinq publications par jour ». Reddit comptait auparavant une communauté active comme un subreddit avec au moins cinq publications ou commentaires en une journée donnée. Je sais avoir atteint une activité autosuffisante dans une nouvelle communauté si j’obtiens ce nombre de publications ou commentaires quotidiens, sans nécessiter d’intervention ni de relance. C’est également un excellent test pour une nouvelle zone de discussion ou sous-catégorie. Si vous créez une nouvelle catégorie et que vous parvenez à la faire monter à 5+ interventions par jour sans votre intervention directe, vous avez une catégorie solide.

Pour le « prêt pour l’entreprise », surtout pour les communautés B2B ou clients, je modifierais cette définition en disant 5+ publications ou commentaires par jour, PLUS une réponse garantie de type SLA à 80 % des sujets dans un délai de 48 heures. Je pense qu’il est important de s’assurer qu’aucune nouvelle publication ne reste isolée et sans réponse, mais aussi de laisser au sujet le temps de respirer et l’opportunité d’une réponse organique.

Avez-vous une formule que vous préférez ? Suis-je complètement fou avec ce taux de réponse ? :grin:

Et sans vouloir trop diviser le sujet, à quoi ressemble le « prêt pour l’entreprise » pour vous au niveau de la plateforme ? Dans ma liste de critères, je dirais : une taxonomie / architecture de l’information solide pour les premières catégories, une fonction de réponse résolue ou de meilleures réponses, des notifications et un routage intelligents pour rester dans les limites des temps de réponse attendus pour les nouveaux sujets, et au moins quelques personnes prêtes à s’engager dans la modération. Je tiens également beaucoup à ce que le thème corresponde à l’organisation pour laquelle la communauté est construite, mais c’est entièrement une question de préférence.

Quel est votre point de vue (qu’il soit populaire, controversé ou contrariant) sur ce à quoi ressemble une communauté « Prête pour l’Entreprise » selon vous ?

7 « J'aime »

Quand j’entends « prêt pour l’entreprise », je pense à la fiabilité, la disponibilité et les performances à grande échelle, ce qui ne correspond pas nécessairement à la question que vous posez.

Une disponibilité du site de quatre 9 (99,99 %), et selon votre conception de la disponibilité, faire fonctionner un service dans une architecture haute disponibilité ou extensible horizontalement, où la perte d’un composant pourrait entraîner une perte de capacité plutôt qu’une indisponibilité.

Aller plus loin impliquerait de prendre en compte l’équilibrage de charge global, l’équilibrage de charge inter-régions, ou des scénarios de reprise après sinistre hors région.

Je réfléchis à la taille de la population d’utilisateurs et aux niveaux d’activité (les statistiques intégrées comme les DAU/MAU et autres offrent d’excellentes données).

Votre site peut-il accueillir 10 000 utilisateurs actifs simultanés sans ralentissement lors du téléchargement de photos ou de l’utilisation des fonctionnalités de chat ?

À partir de quand les utilisateurs commencent-ils à percevoir des problèmes de performance, ou des latences/délais ?

Notez que je crois à deux choses : l’architecture détermine le coût, et comprendre comment vous souhaitez aborder la conception de la communauté dès le départ est crucial à grande échelle. C’est complexe car, à moins d’être à l’échelle entreprise dès le premier jour, ce dont vous avez besoin pour 100 utilisateurs peut être radicalement différent de ce dont vous avez besoin pour 1 000, ou 10 000.

Il y a beaucoup de choses à détailler concernant la simplicité de l’architecture monolithique, les risques de points de défaillance uniques par rapport aux objectifs de disponibilité, et la manière dont des approches comme Docker et Kubernetes ajoutent de la complexité tout en permettant l’extension horizontale.

Je suis un grand fan de Discourse, ma communauté est minuscule, et je n’ai pas passé de temps significatif à évaluer comment je transformerais un logiciel comme Discourse en SaaS (ce que je suppose que les géniaux gars chez Meta ont déjà résolu et rendu simple en apparence).

Changeons d’angle : ce à quoi vous faites peut-être référence sont les SLA (accords de niveau de service, qui impliquent des contrats) ou les SLO (objectifs de niveau de service, qui peuvent être utilisés pour définir des attentes). Cela renvoie également à la conception.

Combien de modérateurs ou de membres du personnel avez-vous, quel est le ratio modérateurs/utilisateurs, comment cela se compare-t-il au volume de publications et au ratio de publications signalées par rapport à l’ensemble des publications (à titre d’exemple) ? Si vous avez un seul administrateur, et même 100 utilisateurs, je ne suis pas sûr d’oser m’engager sur un SLO d’un jour ouvrable.

Les derniers points que je vais soumettre sont de commencer avec l’objectif final en tête, et de construire votre conception sur la base de exigences claires.

J’espère que cela a été utile ! Bonne chance !

3 « J'aime »

Merci pour cette excellente réponse. Et c’est vraiment intéressant que la définition ici mette beaucoup l’accent sur les performances à grande échelle, le temps de disponibilité et l’expérience utilisateur au niveau du serveur.

Les performances sont l’un de ces sujets dont on parle peu dans les cercles de gestion de communauté, mais c’est clairement un domaine où Discourse a des avantages considérables.

Mais c’est certainement un facteur majeur. L’un des exemples les plus frappants que je puisse citer est lorsque j’ai géré Skyscraper City, qui fonctionnait sur une ancienne version de XenForo. C’est une immense communauté B2C d’enthousiastes, et en raison du nombre gigantesque de catégories et sous-catégories avec une multitude de zones de discussion réparties par région et zone géographique, le site ralentissait et était tout simplement insupportable à utiliser. Il recevait certainement l’une des plus grandes quantités de plaintes concernant les performances, malgré une richesse de contenu unique au monde.

En ce qui concerne la conception de la communauté elle-même, la différence pour le « prêt pour l’entreprise » est infrastructurelle plutôt que liée aux performances. Bien que je ne sois pas sûr qu’il existe des études sur les seuils de tolérance des communautés elles-mêmes – nous avons bien la recherche sur les Core Web Vitals. Chromium Blog: The Science Behind Web Vitals J’ai toujours eu tendance à penser que la tolérance et la patience face à de faibles performances sont une fonction inverse de l’engagement : plus les membres actifs d’une communauté sont engagés, plus leur tolérance est élevée.

Je serais curieux de savoir si d’autres ont des opinions sur les éléments indispensables à la définition d’une communauté « prête pour l’entreprise » au-delà du prérequis souvent négligé « Il doit être rapide. Vroom vroom ! » :high_voltage:

3 « J'aime »