jegounblog.overblog.com

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.

http://bit.ly/Mqtwod