Les risques de trop tarder ou de trop hâter son expansion

Il n’est jamais trop tôt pour commencer à planifier la croissance future. Une fois que vous avez déterminé si vous construisez une bibliothèque ou un café, vous pouvez commencer à concevoir des stratégies adaptatives.

Nous avons mené des recherches sur notre base de clients et nous avons découvert trois signaux précoces qui semblent apparaître de manière constante chez les clients dont les communautés peinent :

  • Aucun cas d’utilisation clair / direction de lancement basique
  • Manque d’alignement des parties prenantes / propriété claire
  • Manque de progrès précoces (les choses s’enlisent après le lancement)

Si ces éléments clés ne sont pas pris en compte dès le début, ils deviennent un indicateur précurseur d’échec en aval.

Si vous les traitez trop tard, la communauté devient de plus en plus fragile et risque une fragmentation précoce. Voir Fragmentation de la communauté : quand la croissance devient votre obstacle.

Les risques d’agir trop tôt ne sont pas aussi élevés et ont tendance à se manifester sous forme de :

  • des processus plus complexes que nécessaire
  • une friction inutile pour les membres
  • une charge de travail lourde pour le personnel
  • des villes fantômes
  • l’absence de données significatives pour les rapports

Pour aller plus loin
Le cycle de vie de la communauté : du lancement à l’héritage

La communauté que je cite dans l’article ci-dessus est un bon exemple de communauté dont les processus étaient cassés en raison d’une évolutivité insuffisante. Nos protocoles de modération n’étaient pas évolutifs, nous avons donc saisi l’opportunité de les réexaminer lorsque nous sommes passés de vB à Discourse. C’était la bonne décision.

Quelqu’un d’autre a-t-il une histoire à raconter ?

6 « J'aime »

Merci de partager ce type de résultats de recherche. Évidemment, ce forum est un excellent exemple de communauté forum dynamique et un bel exemple d’utilisation appropriée du logiciel de forum Discourse. En tant que gestionnaire d’une petite communauté encore en croissance, il y a beaucoup à apprendre de l’exemple donné ici.

Votre volonté de partager les expériences tirées de votre base de clients est particulièrement utile et appréciée.

4 « J'aime »

J’ai une petite histoire amusante à propos du fait d’avoir trop tardé à passer à l’échelle pour l’une de mes communautés de 1,2 million de membres.

SkyscraperCity est l’une des plus grandes, sinon la plus grande communauté au monde consacrée à l’architecture, à l’environnement urbain et aux structures métropolitaines. Chaque région du monde ayant un niveau de développement urbain significatif et des structures plus importantes associées possède sa propre section. Naturellement, il y a une quantité massive d’images partagées au sein de cette communauté, car, eh bien, les membres de cette communauté adorent vraiment montrer et raconter les gratte-ciels qui sont discutés.

Le problème n’est pas apparu là où on pourrait s’y attendre.

Le problème ne résidait pas dans le fait de passer à l’échelle tardivement la gestion des images et des pièces jointes. C’était un facteur connu, et la plateforme était conçue pour le gérer.

Le problème est survenu avec la croissance du nombre de zones métropolitaines distinctes, et avec chaque nouvelle catégorie, sous-catégorie, sous-sous-sous-catégorie basée sur le continent, la nation, l’État et enfin la ville, pour lesquelles il pouvait y avoir un nombre quelconque de quartiers. L’architecture informationnelle de la communauté avait dépassé la capacité de la plateforme à gérer l’activation de chacune de ces zones. Elle pliait sous le poids de toutes ces catégories, et les performances avaient ralenti à une vitesse absolument glacial. Il était tout simplement douloureux de naviguer d’une page à l’autre, sans même parler de publier un message !

La plateforme spécifique était une version personnalisée plus ancienne de XenForo, construite sur des arbres de nœuds pour les catégories ; elle n’était pas conçue pour gérer des centaines ou des milliers de catégories individuelles faisant partie de la structure. La manière dont elle était construite, chaque nœud occupait une bonne quantité de ressources, et donc plus il y avait de nœuds à un certain point, moins la plateforme était stable. Nerd que je suis, la façon dont je l’ai décrite à la communauté pour la visualiser consistait à la comparer à un épisode particulier de Star Trek : The Next Generation, lorsqu’ils ont découvert que les moteurs à distorsion perçaient des trous dans la structure de l’espace-temps un peu trop fréquemment, affaiblissant l’espace dans une zone très fréquentée.

Les millions de catégories (sous-sous-sous-sous-catégories et ainsi de suite) causaient des “dommages” à la stabilité de la plateforme de la même manière que des centaines de moteurs à distorsion activés dans et autour d’une zone spatiale populaire provoquaient l’effondrement de cette zone.

La solution n’était pas si différente de celle de la Fédération, en ce sens que vous réduisez la vitesse et limitez les perforations. Nous avons donc effectué une révision complète de l’architecture informationnelle, fusionné un certain nombre de catégories de bas niveau et même certaines de haut niveau, et le système s’est stabilisé.

Bien sûr, ce problème n’apparaît pas avec Discourse, car Discourse traite les catégories bien mieux comme des conteneurs de premier ordre, plutôt que comme un gros arbre structurel unique. Un réseau mycélien ou des conduits de transdistorsion, si vous voulez. Mais c’est certainement l’un des exemples les plus frappants que j’ai de passage à l’échelle trop tôt, et pas exactement là où on s’attendrait à ce que le coup vienne.

1 « J'aime »

Excellente exemple ! Merci de l’avoir partagé.

J’ai déjà rencontré des cas similaires — pas dans les communautés que j’ai gérées, mais bien au sein de notre base de clients. Une grande marque, que je ne nommerai pas, est venue nous voir pour migrer sa communauté vers Discourse. Ils fournissent des logiciels de navigation et avaient créé des sous-catégories pour chaque localisation géographique qu’ils desservaient.

À l’époque, nous craignions la charge imposée aux fonctions administratives s’ils disposaient de milliers de catégories. Nous avons refusé de créer des niveaux plus profonds et avons essayé de les convaincre de la puissance des balises, mais ils n’ont pas cédé. Nous avons abandonné l’affaire, car elle ne fonctionnerait jamais de manière durable selon nos critères.

Concevoir une architecture de l’information évolutive est donc primordial.

1 « J'aime »