Du contexte du choix d’une solution 2.0

Le choix d’une plateforme 2.0 ne se fait pas de la même manière d’un contexte professionnel à un autre.  Pour bien comprendre le dit « contexte », je pense qu’il convient de prendre en considération trois aspects :

  • Identification des acteurs clés dans le processus de choix et convergence de leurs attentes
  • Définition de l’étendue du projet : en terme d’usages, de métiers à représenter et du nombre d’utilisateurs à cibler
  • Anticipation des évolutions.

Soyez lucides : repérer les acteurs et les différentes attentes

Cette phase implique, assez souvent, plus qu’un acteur. Le schéma classique MOA / DSI reste toujours valable :

  • La maitrise d’ouvrage (MOA) – représente les métiers, les utilisateurs, leurs besoins et leurs ambitions en terme d’usages. Parfois, plusieurs maitrises d’ouvrage représentants différents « clients » sont identifiées pour un même projet.
  • La direction informatique (DSI) – défini les champs du « techniquement possible » dans le contexte de l’entreprise et dans le cadre du budget alloué.

Assez souvent le contexte est propice à des conflits d’intérêts (budgétaires, stratégiques, techniques). Malgré l’image parfois dégradée d’une DSI qui impose les règles, la réalité montre que son implication dans un tel projet est toujours une garantie de réussite et de pérennité technique.

Naturellement la DSI optera pour les produits qui s’alignent sur sa stratégie technique en terme de technologies, de compétences internes et de fournisseurs (etc.).

De l’autre coté les MOA jouent un rôle sensible couvrant non seulement la compréhension des besoins mais aussi l’apport, proposition et accompagnement de nouveaux usages non encore déployés, ni exprimés (parfois), au sein de l’entreprise.

La MOA doit également avoir son mot à dire dans le choix et optera pour les produits qui conviennent le mieux à ses exigences fonctionnelles et à ses attentes en matière d’ergonomie et d’interface utilisateur.

Aussi, trouver un consensus entre les deux n’est pas toujours facile. Dans certains cas, la double compétence technico fonctionnelle de la DSI et sa proximité des utilisateurs et de la MOA  joue beaucoup en faveur d’un choix rapide et efficace.

Bien analyser l’étendue des usages et la volumétrie

L’étendue du projet est un élément très important, duquel peuvent découler des critères déterminants dans le choix d’une plateforme. Le choix est toujours plus facile pour un besoin local pour une communauté donnée dans un contexte particulier. Les usages sont d’autant plus complexes (multiples, variés) que le nombre des utilisateurs est important.

Attention aussi à  « l’aspect viral » du déploiement d’une solution 2.0 qui peut se transformer en un piège. En effet, certains déploiement « locaux » risquent de montrer rapidement leurs limites : ne pas couvrir toutes les attentes, limitations techniques de scalabilité, etc.

La « viralité » est un mode de déploiement et non une méthode de choix d’une solution.

Contraintes techniques de performance et de scalabilité

C’est là où l’étendue ou l’importance du périmètre du projet – en terme d’usages et de nombre d’utilisateurs est critique pour le choix. A ce niveau il est possible d’étudier différentes stratégies de choix tels que :

  • Opter pour plusieurs solutions à intégrer pour couvrir différents besoins et usages
  • Opter pour une solution pour tout faire, quitte à sacrifier quelques besoins

Chacune de ces stratégies a ses points forts et ses points faibles.

Si avec le premier scénario on arrive à répondre au plus près des attentes des utilisateurs grâce au choix des meilleurs modules fonctionnels (de blogging, de wiki, de réseau social, de microbloging, …) – on rencontre les risques et difficultés d’intégration, de gestion d’identité unique, d’harmonisation de l’interface utilisateur ou aussi de maintenance technique.

Le deuxième scénario de la solution à tout faire est séduisant à premier abord. Ceci se traduit par l’optimisation des efforts d’intégration et de maintenance. Mais la réalité montre que si toutes les solutions du marché essaient de tout couvrir en se transformant en des « suites 2.0 », aucune n’est pour l’instant (en 2010) assez complète et entièrement satisfaisante.

Ne pas perdre de vue les évolutions et la roadmap

Assez souvent les usages évoluent au fur et à mesure de l’appropriation d’une plateforme. D’où l’importance de bien évaluer les premiers usages ciblés, d’élaborer une sorte de feuille de route prévoyant les éventuelles évolutions et de mesurer jusqu’à quel point les choix effectués répondront à ces attentes.

Ceci peut se mesurer de différentes manières :

  • la couverture fonctionnelle du produit
  • ses fréquences de mise à jour et sa propre feuille de route
  • son extensibilité par un système de plugins
  • l’écosystème autour de l’éditeur (partenaires) et l’implication de la communauté des développeurs (pour l’open source)

Maintenant quels critères concrets pour évaluer sa solution 2.0 ?

Je propose pour aborder ce sujet : une liste de billets abordant chacun une typologie de plateformes

10
août 2010
AUTEUR
POSTÉ DANS Réflexions
DISCUSSION 0 Comments

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>