Le sujet du jour, si vous le voulez bien, sera consacré à un éternel problème:
Comment choisir sa solution *CM (Gestion de Contenus)?
(* représentant une lettre de votre choix mais communément un E ou W)
(* représentant une lettre de votre choix mais communément un E ou W)
Cette question sous-entend de nombreuses questions, comprend de nombreuses méthodologies et est propre à chaque contexte projet. En d'autres termes il n'est pas facile (voire impossible) de standardiser une seule et unique approche du problème. Néanmoins il est possible d'éviter les principaux écueils et d'utiliser les meilleures pratiques. C'est ce que nous allons essayer de voir par la suite grâce à une série de règles.
Remarque : L'ensemble des règles sont issus des différents retours d'expérience que je cite en référence à la fin de ce post. Elle n'envisage que moi et ne saurait être le remède miracle pour choisir sa solution...
Règle n° 1 : Quels sont mes besoins ?
Dois-je rappeler qu'il s'agit de la base... Sans une définition LITTERALE des besoins, sans des cas d'utilisations SCHEMATISES avec des explications LITTERALE, sans une HISTOIRE des demandes fonctionnelles est il nécessaire de démarrer un projet qui aura pour conséquence le choix d'une solution inadaptée ?
On parle bien ici du fameux QUOI pour Quel est le futur cadre de mon travail ?
Dans les projets de gestion documentaire, il faut identifier les types de documents que le système devra gérer. Quels sont leurs formats, leurs tailles moyennes, leurs fréquences de création, de modification, de suppression. Qui est responsable de ces données...?
Règle n° 2 : Quelles sont mes contraintes techniques ?
Suivant la recommandation de mes urbanistes je dois pouvoir récupérer des informations provenant d'une application de mon SI. Existe t il un connecteur avec cette application ou quels sont les moyens envisagés dans la solution susceptible de récupérer ces informations ?Lorsque ce genre de contraintes est connu en amont alors il est beaucoup plus simple (aussi bien pour le client que pour le fournisseur) de choisir une solution adaptée. Ces contraintes peuvent ainsi constituer une liste de MUST-HAVE qui pourrait être discriminant lors d'une comparaison d'offres. A vous de placer le curseur sur l'importance des critères (en sachant bien évidemment que rares sont les solutions remplissant tous les critères )
Suivant les directives de mes architectes, ma future solution doit être basée sur une architecture comprenant des EJB3 et doit pouvoir être installé sur un socle Linux Ubuntu.
Le service d'exploitation a besoin de surveiller la future application via JMX.
Règle n° 3 : Les petits ruisseaux font les grandes rivières
En partant de ce principe ou du fameux KISS (Keep It Simple Stupid), il vaux mieux commencer simplement, rapidement et humblement pour ensuite vérifier, valider et voir recommencer afin dans un second temps d'étoffer les fonctionnalités offertes. Cette approche permet d'avoir un retour l'utilisateur final plus rapide et améliore ainsi l'adhésion au projet et donc à l'outil.
Dans le domaine du développement on appelle cela le développement Agile ;o)
Règle n° 4 : Pour choisir une solution, la grille de notation tu banniras !
Pour avoir pratiqué l'exercice aussi bien en tant que consultant qu'en temps qu'utilisateur les grilles ne servent en fait... pas à grand chose. Sauf à prouver et à dire ce que vous voulez!
Pour ceux qui n'en aurait jamais vu, voici un petit descriptif :
Il s'agit en général d'un fichier Excel avec une liste de critères regroupés en famille, qui eux même sont regroupés en groupe, qui eux même sont regroupés en catégorie. Ils Chaque critère possède ensuite une pondération. Celle ci est parfois aussi envisagée pour les familles, les groupes et les catégories... Cette liste constitue l'axe des Y (de haut en bas).
Ensuite sur l'axe des X (gauche à droite), on va ajouter les différentes solutions que l'on veut soumettre au traitement de la matrice.
L'intersection des lignes de critères avec la colonne de la solution est ensuite complétée par une combinaison de note comprise entre 0 et 5.
Au final en bas de la feuille Excel, il y a la note finale. Résultant de la moyenne des produits entre pondérations et notes, cette note au combien symbolique est le salut pour le responsable du choix de solution puisqu'elle indique l'heureux vainqueur incontestable!
Dis comme cela c'est simple non ? :o)
Le principal reproche de cette pratique vient de la "partialité" lors du choix des critères, de la pondération et de la note.
Exemple :
Partons du besoin :
Les équipes techniques (conceptrice de nos produits) ont besoin de pouvoir partager leurs bonnes pratiques de manière collaborative.
Critère envisageables :
Intégration d'un wiki.
Réponses possibles :
- Réponse d'un consultant : Pour la solution X, il existe une possibilité d'intégrer une solution de Wiki via l'API du système de GED.
- Réponse d'un éditeur : La solution Y, Une de nos fonctionnalités permet de gérer un système de wiki.
- Réponse d'un intégrateur : Avec un peu de code, il est possible de créer un système de wiki simple que l'on pourra brancher au système de GED de la solution Z.
Au fait avez vous pensez à demander quelle est la syntaxe du moteur ? Votre équipe technique voudra-t-elle écrire en apprenant qu'un mot entre le symbole ' indique un italique, avec [ qu'il s'agit d'un lien... ou bien voudriez vous plutôt un éditeur de texte simple ou riche, avec l'intégration de médias comme des images...?
Ensuite avez vous pensez à comment sont stockés ces contenus ? Comment ils peuvent être réutilisés, partagés et indexés ? et j'en passe...
Maintenant mettriez vous la même note ?
Voilà en substance les limites du système matriciel...
Règle n° 5 : Pour demander le choix d'une solution dans un appel d'offre la grille de critères tu banniras!
Corollaire du point précédent, si tu ne veux pas que les réponses données soient fausse, alors ne demande pas de remplir une grille. Simple isn't it...
Règle n° 6 : Avec qui ai je envie de travailler ?
Règle simple mais pas toujours appliqué. N'est-il pas plus simple de travailler avec des personnes que l'on connait et avec qui on a noué des liens de confiance, de respect, d'honnêteté et d'efficacité ?
N'hésitez donc pas à rencontrer les différentes personnes qui vont intervenir aussi bien dans la phase de choix, de conception que celle de réalisation. Ceux sont ces personnes qui sont avant tout garantes de la réussite de votre projet.
Règle n° 7 : Vous connaissez votre budget ? Alors dites-le!
Je sais que ce choix peut paraitre osé suivant les projets, mais il va vous permettre de gagner du temps ! D'une part parce qu'il vous permettra de savoir qui sont les fournisseurs réellement intéressés par le projet, d'autres part il vous permettra de choisir la gamme de produit pouvant répondre à votre problématique.
Remarque : Parlant souvent de solutions open-source, je tiens à rappeler qu'une solution Open Source N'est PAS GRATUITE!
Règle n° 8 : Open Source ou Propriétaire même combat ou dit autrement aucun préjugé tu dois avoir!
Bien que je sois un fervent supporter de l'open source, le propriétaire n'est pas à exclure du choix d'une solution (et vice-versa!). Dans le choix d'une solution seul compte votre besoin (et votre budget...)!
Si ce besoin est mieux couvert par une solution propriétaire et que celle ci entre dans le budget fixé, pourquoi se priver ? (et vice-versa!).
Règle n° 9 : Un prototype tu demanderas!
Parfois dans les critères de sélection, on trouve la mention : "Expérience utilisatrice à 2.0", ou "Ergonomie et Experience Enrichie". Si vous n'avez jamais installé le produit ou utilisé le produit comment pouvez vous vous fiez à une note ou à une description. C'est dans ces moments la que l'on constate l'utilité d'un prototype.
Petit rappel : Un prototype ne consiste pas à faire en quelques jours ce que le projet demande de faire en plusieurs mois.
Le but d'un prototype est de montrer les forces et faiblesses d'un produit sur un cas d'utilisation particulier. En outre, il vous permettra de voir le degré de maitrise de la solution par un intégrateur, ou le degré d'adaptabilité d'un produit par un éditeur. Ce n'est pas à l'éditeur de montrer ce que le produit sait faire mais bien au produit de montrer ce qu'il sait faire dans votre contexte. Et si le prototype "plante" ce n'est pas grave, il montre au contraire sur quoi il faut réellement travailler.
Règle n° 10 : Je n'y comprends rien...
Vous avez du mal à comprendre les principes régissant un projet de gestion documentaire. Demandez de l'aide tout simplement !
Voilà en quelques points ma vision de comment choisir sa solution de gestion de contenus.
L'ensemble de cet article n'aurait été possible sans les innombrables articles traitant du sujet sur le web. Voici quelques morceaux choisis :
[FR] BPMBulletin :
[ENG] BIG MEN ON CONTENT
[ENG] BLEND INTERACTIVE
[ENG] CMS WATCH
- http://www.cmswatch.com/Trends/1657-Beyond-the-RFP
- http://www.cmswatch.com/Feature/97-Implementation-Choices
[ENG] CONTENT HERE (My favourite!)
- http://www.contenthere.net/2008/11/leading-requirements.html
- http://www.contenthere.net/2007/05/how-to-select-a-cms.html
- http://www.contenthere.net/2009/11/when-it-is-not-all-about-the-software.html
- http://www.contenthere.net/2008/02/the-rfp-is-dead-long-live-the-rfp.html
- http://www.contenthere.net/2008/02/to-tell-or-not-to-tell.html
[ENG] JON ON TECH (A lire absolument !)
2 commentaires: on "Comment choisir sa solution de gestion de contenus ?"
Voilà une note qui devrait servir de base à bon nombre de personnes qui se posent la question régulièrement de savoir comment procéder.
J'y ajouterais quelques éléments que je pense importants :
La règle 1 peut être complétée par "quels sont mes problèmes au quotidien ?", en effet c'est un point de départ pertinent que de chercher à résoudre ses difficultés et de mettre en avant les souffrances vécues par les utilisateurs concernés. L'expression de besoins découlera ensuite tout naturellement de l'expression des problèmes rencontrés et décrits.
De même en amont de la définition d'une typologie de documents, j'ajouterais de ne pas omettre la définition du modèle organisationnel : comment va-t-on gérer le fond documentaire et ensuite de quoi est-il constitué.
Autre vision bien personnelle, s'attacher à coller au mode de fonctionnement le plus standard possible du produit envisagé est une saine réaction. Bon nombre d'entreprises ont entamé des projets de decustomisation de leurs applications car celles-ci devenaient ingérables. Mieux vaut contourner l'absence d'une fonctionnalité particulière que de chercher à la mettre en oeuvre à tout prix avec comme résultante de complexifier la maintenabilité de l'application.
Pour ce qui est des grilles de sélection, j'abonde en ton sens, ne perdons pas de vue qu'aucun éditeur ou intégrateur ne passera à côté de la possibilité de mettre 'OUI' partout, et que bien souvent ces questionnaires sont évalués à la simple lecture du 'OUI' ou du 'NON' sans pondération particulière, tout cela ne sert donc pas à grand-chose.
Enfin, prototype or not prototype? Il est vrai que maquetter peut permettre de se rendre compte de l'usage possible du produit et de ses limites. Il ne faut pas perdre de vue que ceci a un coût, financier souvent, humain toujours, et que faire plusieurs maquettes (condition sine qua none pour comparer des éditeurs) est très consommateur.Plutôt que prototype, j'aurais tendance à penser "pilote - première application" pour jouer la carte de la réutilisabilité.
Voilà donc quelques ajouts, en tout cas le débat est intéressant et merci de l'avoir lancé.
Bonjour JC et merci beaucoup pour le retour!
Tes remarques sont très pertinentes mais elle soulève aussi un autre problème lorsque tu parles de respecter le comportement standard du produit.
Je crois qu'en effet l'utilisateur voudra toujours modifier l'interface graphique par défaut ! C'est inné et c'est un des moyens pour qu'il a trouvé pour s'approprier la solution. Il peut ainsi dire c'est ma solution et pas celle du voisin.
La question lors du choix d'une solution est de savoir où et comment modifier cette interface ? N'est il pas plus sage de créer une nouvelle interface simple et fonctionnelle basée sur les services exportés (API, Webservices, services REST...) ? Quel est le degré de modification autorisé par l'outil et quels sont les populations en interne susceptible de vouloir modifier leurs interfaces pour être plus productif ?
Dans ce cas je pense que lors du choix de la solution il faudra prendre en compte soit l'aspect export de services, soit le niveau de customisation que la solution me propose.
N'hésitez pas à demander conseil à votre architecte le plus proche ;)
Ensuite je conçoit très bien que le prototype est coûteux et long à mettre en place et ne correspond pas au besoin de chaque projet. Par contre j'insiste énormément sur le fait qu'il faut avoir TESTER/UTILISER les différents produits. Un consultant sera toujours là pour vous guider au besoin mais c'est bien le ressenti utilisateur à la fin qui doit primer avant tout.
Vous choisiriez une voiture sans l'avoir testé ? ;o)
Enregistrer un commentaire