07 juin 2012

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.

29 commentaires:

  1. Réponses
    1. Non. Il faudrait que j'en fasse un billet. Ceci n'est pas un outil d'archivage des documents mais de partage. Si tu gère les versions tu réponds à un besoin, pas un usage. N'oublie pas la base ! Tu tombes dans le travers.

      Si on commence à gérer les versions, les gens ne l'utiliserons pas parce que ça finira trop compliqué. Là, on gère les documents de travail qu'on s'échange pour... travailler. Le versionnning sera géré par un autre outil, connexe.

      Ton profil blogger est à chier.

      Supprimer
    2. Bein ouais, mais pas de lien direct vers g+

      Sinon pas d'accord, le versioning doit faire partie intégrante de tout RSE ; je n'ai pas dis travail collaboratif, juste versioning, hein.
      Je partage mon document, avec un lien vers le document dans sa dernière version. Si je le modifie, je veux qu'un "commentaire" apparaisse, que le lien initial soit toujours dans la version la plus récente (mais avec le bouton qui va bien pour aller chercher les version précédente).

      Supprimer
    3. Pas d'accord. Il doit venir après. L'usage fera le besoin. Créons l'usage avant le besoin. C'est rigolo que tu penses comme ça, alors que c'est toi qui m'as fait réfléchir à cette différence fondamentale entre le besoin et l'usage.

      Supprimer
  2. Peut être te trompes-tu de Pierre ? Je ne connais pas ce Pierre.

    Le versioning, c'est pour nous ramener une gestion de document type Sharepoint, pour retomber dans les sentiers battus. Notre démarche est effectivement différente afin de partir de l'usage et de l'utilisabilité.

    Pour cela, deux idées. Le concept de widget rigolo est la fonctionnalité qui tue car tout système orienté usage soit créer un effet waoouuu immédiat non pas par des besoins couverts, même pressants, mais par des trucs visuels incroyables. On remarquera là la patte Apple dans ses méthodes. Donc développons les widgets rigolos même avant le reste.

    D'autre part, plus besoin de Cahier des Charges. La méthode doit être agile. Il n'y a plus qu'en France qu'on fait des cahiers des charges dans les SSII françaises démodées. Il faut aller vers du développement rapide itératif en mode quick code start, avec des outils de développement de félins comme Ruby on Rails ou un Frameworks de ce type.

    AGILITE, USAGE et RIGOLADE, voici la maxime de ce projet. Maintenant il nous faut des investisseurs et je propose un premier tour de table à 800 000 euros pour payer les versions alpha et bêta mais aussi les apéros des fondateurs pour des focus groups rigolos.

    RépondreSupprimer
    Réponses
    1. Hips. Je te réponds demain

      Supprimer
    2. Pour le "widget rigolo", tu as peut-être raison. Certainement pas pour le "Cahier des charges". Même avec Ruby (que mes collègues utilisent), il faut bien décrire ce que tu veux faire avant de commencer. L'informatique ne consiste pas à aligner des 0 et des 1 au hasard...

      Tu fais la même erreur que les informaticiens d'il y a 20 ans quand est apparu C++ (qui fut d'ailleurs un véritable scandale et a coûté la peau des fesses aux entreprises) : utiliser une notion "fonctionnelle" (l'objet) pour faire de la programmation (d'ailleurs, l'objet C++ n'est rien d'autre qu'une structure C avec une allocation de mémoire).

      La cahier des charges fonctionnel existe toujours, forcément. Tu ne fais pas un développement informatique sans savoir ce que tu veux faire fonctionnellement.

      Mais un cahier des charges peut faire 2 ou 3 pages, comme ici, pas nécessairement 300 comme on voit trop souvent.

      Supprimer
  3. L'autre, c'est un usurpateur ! Nouvelle forme de plagiat ! C'est un Troll déguisé en Pierre.

    RépondreSupprimer
  4. Ce Blog voit une réduplication des utilisateurs de Pierre, c'est un scandale.

    RépondreSupprimer
  5. Réponses
    1. Pierre qui roule n'amasse pas mousse, contrairement à moi, j'ai bu une quinzaine de mousses hier soir. Du coup, je vois les Pierre en double.

      Supprimer
  6. Je suis partiellement d'accord avec un Pierre (je ne sais plus lequel ;-) sur le versioning, ou au moins la nécessité pour tous les utilisateurs de savoir en ouvrant un doc que c'est le dernier en date. Sinon, la perte de confiance et l'abandon de l'outil ne sont pas loin...

    RépondreSupprimer
    Réponses
    1. Oui, mais je ne parle pas d'un intranet de gestion de la documentation, juste d'un machin pour partager n'importe quel fichier de travail, ce qu'on fait au quotidien.

      Il existe des tonnes d'outils pour gérer la documentation et les archivages.

      Il s'agit, pour moi, plus d'un machin pour dire "voila la dernière version du document de travail que nous étudierons lors de notre réunion".

      Supprimer
    2. Et je me répète, il ne s'agit pas de répondre à un besoin mais de générer un usage.

      Le besoin de gérer des versions ou d'échanger des documents est réel mais est déjà couvert : des intranet et autres pour gérer des versions, des mails pour échanger des documents.

      Supprimer
    3. OK mais finalement, ça ressemble plus à un outil ergonomique de gestion de projet (et c'est déjà énorme) qu'à un vrai RSE. Ce n'est pas une critique, d'autant que je ne crois pas que les RSE ont une raison d'être et une valeur ajoutée absolues et dans n'importe contexte.

      Supprimer
    4. Non. Ils ne servent à rien.

      Supprimer
  7. Revenir sur des histoires de versioning attriste le dossier qui est censé être révolutionnaire sur ses fonctions.

    RépondreSupprimer
    Réponses
    1. Ca veut dire quoi ?

      On peut parler longtemps de versioning mais dans ce cas, il faut remonter plus loin dans cette notion de version. C'est ce qui définit contractuellement une bonne version, celle qu'il faut utiliser, celle que le fournisseur doit utiliser, celle que le client a valider.

      Une gestion plus fine des versions tue l'évolutivité. Quand je bosse, j'utilise un numéro de séquence pour les "versions" consécutives des fichiers mais je distingue bien celles qui sont officielles (avec un numéro de version et pour être utilisée concrètement) des multiples versions de travail qui foisonnent au cours d'un projet.

      Supprimer
  8. Tu as raison, la gestion des versions peut aller très loin. Le versioning de document est en soi une fonction de gestion documentaire. Cela n'a rien à voir avec un RSE à widgets Rigolos.

    RépondreSupprimer
    Réponses
    1. Ça peut avoir à voir. Mais ce n'est pas ce que j'ai présenté.

      Supprimer
  9. Trop de Pierre et pas assez de Nicolas ici...
    Je viens rééquilibrer les choses. Je suis un développeur PHP, l'idée du RSE me plait.
    Si vous cherchez un développeur ou un concepteur pour la base de données, je peux être votre homme. J'ai aussi un métier, donc cela se ferait sur mon temps libre.

    Mettez-vous d'accord sur la politique de gestion des documents en attendant :)

    Nico

    RépondreSupprimer
  10. Réponses
    1. Moi, je me contente des spécifications du noyau...

      Supprimer
  11. noyau de cerise ! whaaarfff, y'a tout le boulot autour

    RépondreSupprimer
    Réponses
    1. Je sais. Chacun son métier. Je peux te dire que faire des bonnes spécifications est un métier.

      Supprimer
  12. Je vais appeler Brigitte Lahaie, elle sait peut être me répondre pour savoir faire le reste

    RépondreSupprimer

La modération des commentaires est activée. Je vous lis, voire vous publie, après la sieste.