On a pas mal parlé de l’opposition entre le pourquoi et le comment dans la mise en place des projets web, et particulièrement des projets web collaboratifs chez les grands comptes, et c’est quelque chose que je conçois bien : plutôt que de vous demander comment vous allez le faire, demandez-vous plutôt pourquoi.

Effectivement, justifier du pourquoi est indispensable quand on va à l’encontre des credo du milieu, et des méthodes de management ancrées depuis parfois des décennies. Il faut de bonnes raisons non solum pour bousculer des habitudes bien ancrées dans la maison, sed etiam pour faire changer les modes de travail de ceux qui en sont les gardiens. Le pourquoi devant évidemment démontrer en amont en quoi le changement aura un impact positif sur le sacro-saint ROI, quelle que soit la manière de le calculer.

Pourtant, je ne suis pas d’accord avec la plupart des ténors de ce qu’on appellera pudiquement l’entreprise 2.0, le terme ayant pour moi autant de sens que web 2.0, comme s’il y avait eu un jour avant et un jour après.

Le comment est au moins aussi important que le pourquoi, ne vous déplaise.

Il y a d’abord le comment en termes de conduite du changement procédural. L’étude du sujet pourrait mener à la publication d’un nombre impressionnant d’ouvrages, tant le modus operandi dépend à la fois des particularités internes à l’entreprise et à ce fameux pourquoi. Ce n’est pas mon propos, bien que mon quotidien m’ait donné pas mal de grain à moudre le sujet.

Il y a ensuite le comment en termes de conduite du changement technologique, et là, j’ai le sentiment que les forces d’inertie sont encore plus importantes que lorsqu’il s’agit de faire migrer les processus. Sans vouloir rentrer dans les clichés, le plus dur sera globalement de rentrer dans le pré carré des DSI. Pour beaucoup d’entre-elles, et on les comprends, un système d’information qui fonctionne n’a surtout pas vocation à changer. Contrairement à ce que j’ai pu penser un certain temps, il n’y a pas toujours que de la flemme et une volonté d’immobilisme derrière ce credo, mais bien un soucis de qualité de service qui se traduit en fin de trimestre par des statistiques de disponibilité.

Il y a également une question d’intégration avec l’existant, laquelle n’est pas à prendre à la légère. Pour beaucoup d’entre nous, changer d’outil est déjà pénible ; changer de méthodes de travail pour le moins déconcertant ; devoir également changer totalement d’écosystème, ou pire, faire cohabiter deux écosystèmes en parallèle sans dénominateur commun est certainement le meilleur moyen de partir dans le mur. Et là encore, le comment n’est pas une mince affaire : intégration avec un annuaire LDAP existant, à minima, avec un système de messagerie, une charte graphique des applications internes… Et ne parlons pas de s’interfacer avec des applications métier parfois vieilles de 10 ans afin de récupérer des flux d’informations…

J’ai lu dernièrement pas mal de conneries bullshit choses sur la phase techniques du déploiement des applications web collaboratives en entreprise. Une fois la décision prise, il semble que ce soit d’une simplicité déconcertante : du passé faisons table rase, de toutes manières l’existant a vécu, le ROI supposé s’impose à la technique, et nous serons les seuls sur terre dans un système d’information tombé en désuétude et dès lors forcément rangé aux oubliettes pendant la phase d’avant projet.

J’aurais envie de paraphraser Pierre Desproges, mon grand maître à penser, qui disait qu’en politique, l’adulte, lui ne croit plus au Père Noël : il vote. Dans le joyeux monde de l’entreprise 2.0, le consultant ne vote pas, mais il croit qu’il va changer le monde en déployant un wiki.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: