Réseau Social d'Entreprise : le cahier des charges

Quand on se lance dans une suite sur les Réseaux Sociaux d’Entreprise (RSE), il faut en faire un dernier : voila donc le cahier des charges pour celui qui développera notre brave produit qui aura un succès mondial et qui nous rendra très riches, Pierre et moi.

Objet :

Le RSE est destiné à devenir une application Intranet d’entreprise qui sera hébergée sur son propre serveur ou sur des serveurs de nos prestataires. Il a vocation à devenir la page d’accueil du navigateur, le point d’entrée de la messagerie, de l’agenda partagé et des différentes applications de l’Intranet de l’entreprise, voire des Extranet.

L’utilisateur sera identifié par son adresse mail professionnel. Une identification dans le produit devra permettre l’identification dans les Intranet et Extranet, selon les capacités techniques de ceux-ci.

L’utilisateur sera inscrit à plusieurs « domaines » (qui pourront couvrir n’importe qu’elle structure de l’entreprise, comme une équipe projet ou les membres du CHSCT) par les « propriétaires » de ses domaines.

Au chargement du FS, la page d’accueil contiendra, outre les liens vers les Intranet, en son centre : les derniers statuts mis à jours pour les différents domaines auxquels il est inscrit.

A la différence des réseaux sociaux grand public, comme Facebook ou Google+, les utilisateurs ne pourront pas publier de statut sauf s’ils sont connectés en tant qu’administrateurs de domaine.

Principe :

Le produit sera très proche de Google, fonctionnellement et ergonomiquement. C’est surtout une commodité pour le présent Cahier des Charges où les spécifications seront décrites en fonction des différences avec le modèle.

Utilisateurs :

Les utilisateurs seront gérés par l’administrateur (les gens n’auront pas la possibilité de s’inscrire eux-mêmes). Ils ont, en principe, une adresse email dans l’entreprise.

Des utilisateurs extérieurs pourront être créés par l’administrateur à la demande des responsables de domaines. Néanmoins, leurs utilisations seront limitées en fonction des règles de sécurité choisies. Par exemple, si l’application est installée sur le serveur de l’entreprise, celle-ci devra être accessible par Internet (ce qui permettra d’ailleurs aux salariés de travailler de chez eux).

Les utilisateurs devront pouvoir avoir la possibilité de se reconnecter en tant qu’administrateur des pages qu’ils gèrent.

Ergonomie :

L’ergonomie sera proche de Google+ :

-         en colonne de gauche, la possibilité d’accéder aux différents volets de l’application,

-         la partie supérieure est décrite ci-après (chapitre « en-tête »),

-         un champ de recherche juste en dessous,

-         une zone permettant la mise à jour des statuts,

-         en dessous, le « mur »,

-         la partie à droite sera utilisable par le client selon les même modalités de ce qui est décrit dans la partie « en-tête ».

En-tête :

L’en-tête est personnalisable par le client (il en va de même pour la colonne de droite de l’écran). Il pourra y mettre notamment son logo et des liens vers les applications de l’Intranet.

La personnalisation doit être faisable par un moyen standard du marché (le mieux, à ce stade, étant probablement de l’HTML).

Dans la colonne de gauche, il sera possible de mettre des widgets rigolos, comme un widget twitter pour que les salariés puissent déconner un peu.

Colonne de gauche :

Dans la première version, il y aura :

-         l’accueil,

-         le profil,

-         la messagerie (avec l’affichage du nombre de mails non lus),

-         l’agenda partagé,

-         les documents (à la place des photos).

Les trois derniers pourront être masqués par l’administrateur sont paramétrables par l’administrateur mais devra être disponible dans la première version en natif dans l’application (l’administrateur pourra remplacer la messagerie et l’agenda par « un interfaçage » avec des applications externe – notamment si elles sont Google Apps si Google développe le produit).

Au fur et à mesure de développements ultérieurs par le fournisseur, l’administrateur aura la possibilité d’activer de nouvelles fonctionnalités dans cette colonne de gauche.

Pages (domaines)

Les domaines sont l’équivalent des « pages » et pourront concerner tout ce qu’il aura choisi, y compris son équipe de collègue avec qui il va manger tous les jours à la cantine.

Ils pourront être créés par tous les utilisateurs avec un formulaire. L’administrateur du RSE sera informé par mail de la création de toute page afin de lui permettre de procéder à des contrôles au nom de la direction de l’entreprise. Non mais sans blague. Au moment de la création du domaine, le créateur en sera averti.

Les utilisateurs ne pourront pas s’inscrire à une page, c’est un administrateur de la page qui pourra ajouter des « abonnés » (c’est l’inverse de Google+, en somme).

Il y a trois types d’utilisateurs :

-         normal,

-         auteur,

-         administrateur.

L’auteur pourra publier des statuts et des documents. L’administrateur pourra, en plus, créer des utilisateurs et définir leurs types.

Les pages devront avoir :

-         un nom,

-         un avatar,

-         une rapide description.

Statuts ou publications :

Comme on ne peut pas s’abonner à des gens (« les mettre dans des cercles » dira-t-on chez Google), ça ne servira à rien, pour un utilisateur lambda de déposer son statut : il ne sera vu par personne, sauf si quelqu’un y est mentionné (@nom d’utilisateur, comme Google + et Facebook). Les personnes mentionnées recevront une notification par mail (la notification devra contenir l’intégralité de la publication).

En fait, seuls les statuts publiés par les responsables des domaines (auteurs et administrateurs) sont intéressants et apparaitront dans les murs des utilisateurs.

A la publication d’un statut, l’auteur aura la possibilité d’envoyer automatiquement une notification par mail à tous les abonnés au domaine. Ces abonnés devront avoir la possibilité de se désinscrire des notifications par mail.

Tous les membres ayant accès aux statuts ou publications pourront les commenter.

Documents :

Les documents remplacent les photos de Google+. Il peut s’agir de n’importe quel fichier. Ils seront classés par dossiers et sous-dossiers (uniquement deux niveaux de hiérarchie dans un premier temps, sinon il faudrait, en plus gérer un « explorateur »).

En publiant un document, l’auteur aura la possibilité d’envoyer un mail de notification, avec une option pour mettre le document dans le corps du mail. Si des membres du domaine sont extérieurs à l’entreprise, un avis sera affiché présentant les risques en matière de sécurité et une demande de confirmation.

La possibilité de se désinscrire des notifications n’est pas laissée au choix des utilisateurs, contrairement aux statuts.

Tous les membres ayant accès aux documents pourront les commenter.

Profil :

Le contenu du profil sera largement personnalisable par l’administrateur au même titre que les en-têtes.

Seuls importent deux éléments :

-         le nom de l’utilisateur,

-         son adresse mail,

-         le nom de son service (en cas d’homonymes).

L’utilisateur devra pouvoir accéder à un espace pour gérer ses paramètres.

Paramètres :

Seuls deux paramètres sont nécessaires (à ce stade) :

-         l’avatar de l’utilisateur (des avatars standard pourront être proposés par l’administrateur qui aura la possibilité de mettre un avatar par défaut, par exemple la photo du lascar,

-         la liste des domaines auquel l’utilisateur est inscrit, avec pour chacune d’entre elle, la possibilité de désactivé les mails de notification lors de publications et la possibilité de supprimer une inscription à un groupe (auquel cas, un écran de mail de confirmation sera affiché en précisant que les administrateurs du domaine seront avisés par notification).

Je crois que j’ai fait le tour pour aujourd’hui.