| |
| DECRYPTAGE
|
|
Fever is over, et maintenant ?
par Alain
Lefebvre, vice-président du groupe SQLI (www.sqli.com)
|
La correction boursière d'automne est aussi un signal
de fin de fête : elle nous indique que la ruée
vers le Web " visible " et spectaculaire
est terminée.
La dernière victime en date est Boxman, ce site de vente
de CD ne répond plus. Mais, généralement
on se trompe sur les causes réelles de ces chutes. Il
ne s'agit pas seulement d'une aventure qui s'achève faute
de cash, accélérée par une tempête
sur les marchés bousiers, il s'agit surtout [encore une
fois !] d'un site sanctionné pour son manque d'usabilité…
J'avais eu une expérience d'achat sur Boxman il y a quelques
mois et elle avait été lamentable : design avec
frames, contenus descriptifs absents, impossible de différencier
adresse de livraison et adresse de facturation, délai
de réponse long, service client inexistant, etc.
En fonction de cela, pas étonnant que l'aventure se termine.
Il faut se rendre à l'évidence et cela doit désormais
être pris comme un instrument de mesure : le niveau du
site reflète la qualité du travail. Un site mal
fini est significatif d'une équipe pas au niveau, d'un
travail bâclé et d'un destin scellé !
La troisième vague du Net
Au-delà de cette péripétie, nous entrons
maintenant dans " la 3ème vague du Net ". Après
la vague des sites de contenu et celle des sites marchands,
s'ouvre le début du volet " applicatif " sur
l'Internet. Au-delà d'une simple utilisation des standards
du Net (comme on l'a déjà vécu avec l'Intranet),
il s'agit cette fois d'aménager le passage du système
d'information au système de communication.
L'enjeu, c'est d'élargir le cercle d'utilisation des
applications de gestion afin de fédérer tous les
intervenants de l'entreprise (qui, souvent, sont plus nombreux
à l'extérieur qu'à l'intérieur même
de l'entreprise…) et ainsi aller plus vite !
C'est déjà ainsi que des grands exemples comme
Dell et Cisco fonctionnement. Dell donne accès à
son application de planification de la fabrication à
ses fournisseurs de façon à ce qu'ils puissent
d'eux-mêmes se caller leurs livraisons sur le rythme des
chaînes d'assemblages. Et il ne s'agit d'une anecdote,
il s'agit d'une attitude…
Cette notion de faire reposer l'accès aux applications
d'entreprises sur l'Internet a déjà connu de son
battage médiatique avec les fameux ASP (application services
providers). Les ASP proposent de vous louer l'accès à
des applications accessibles à travers l'Internet via
une simple interface Web plutôt que de vous vendre une
licence d'usage d'un logiciel à installer sur vos serveurs…
En théorie, c'est super, en pratique, les clients sont
moins chauds pour plonger !
Plus d'un an après les discours d'engagements dans cette
voie de grands acteurs comme Oracle et SAP, on attend encore
des résultats tangibles. Pour le moment, cela ressemble
plutôt à un faux-départ… Oracle s'attendait
à enregistrer des milliers de clients pour son offre
en la matière mais reste loin, très loin du compte
(à peine quelques centaines et principalement aux USA…).
Comment expliquer cette réticence du marché
?
Pour deux raisons : d'abord ce modèle exige une rupture
trop franche pour les clients, ensuite les relais (les intégrateurs,
les prestataires de services) n'ont pas embrayé…
Il faut comprendre les utilisateurs : ils ont développé
en interne leurs applications pendant des années et là,
on leur propose de laisser tomber complément la maîtrise
technique (qu'ils avaient bien du mal à assurer, il est
vrai…). La rupture proposée est un peu trop radicale
pour que l'adhésion soit immédiate, franche et
massive. Le modèle des ASP présente un contexte
bien trop favorable pour les grands éditeurs : récurrence
assurée, verrouillage automatique, évolution dirigée,
etc. Mais les prestataires de services qui sont des relais obligés
du marché n'ont aucun intérêt à pousser
vers les ASP qui ne bénéficient qu'aux éditeurs.
Reste donc l'approche classique du développement en interne…
Le dilemme du développement interne
Avec la prise en compte de l'ebusiness, il ne faut pas refaire
l'erreur du passé lorsque les entreprises ont préféré
les développements internes plutôt que d'utiliser
les progiciels. Résultats ?
Tout le monde s'est rué sur les ERP pour " passer
" l'an 2000 (un bon prétexte qui a également
servi à dissimuler que les entreprises étaient
fatiguées de maintenir des applications propriétaires,
difficile à gérer et à faible valeur ajoutée…)
!
Tous les arguments mis en avant année après année
pour justifier les développements spécifiques
n'ont finalement pas pesé lourds face aux contraintes
de l'environnement.
Avec l'Internet cette fois, on recommence. Les besoins applicatifs
dérivés de l'ebusiness sont énormes. Toutes
les entreprises veulent réduire leurs coûts de
fonctionnement et augmenter leurs parts de marché et
c'est ce qui explique la vague des marketplaces et de l'e-procurment.
Vers la syndication de processus
La bonne approche dans ce cadre n'est sans doute pas de développer
une application à chaque fois qu'on est capable d'identifier
un besoin précis. Le Web est plein de services utiles
et populaires qui peuvent être intégrés
par les entreprises sur leurs propres sites afin d'atteindre
leurs objectifs fonctionnels plus vite et à moindres
frais.
Cette notion nouvelle pourrait être appelée "
syndication de processus " en référence à
la syndication de contenus déjà bien pratiquée.
En effet, la syndication de contenu est largement utilisé
par les grands sites, elle permet d'intégrer un contenu
" étranger " (c'est-à-dire que vous
n'avez pas produit et qui est stocké sur un site distant)
au sein de vos propres pages. Nous aussi nous avons recours
à ce moyen bien pratique : sur notre site www.sqli.fr
nous affichons notre cours de bourse que nous sommes allés
chercher directement sur un site spécialisé et
ce à chaque fois qu'un utilisateur demande notre page
d'accueil.
L'intégration instantanée de contenus distants
n'est que le premier niveau de syndication, on peut aussi invoquer
des services, des processus, des transactions que l'on n'héberge
pas sur ses serveurs et n'afficher sur son propre site que les
résultats produits. Les grands portails comme Yahoo!
sont des clients des moteurs d'Inktomi ou Google qui sont sollicités
à chaque requête de recherche sans pour autant
être centralisés sur les serveurs du portail demandeur…
Ce type de technique n'est pas réservé qu'aux
" grands sites ", même le site animé
par ma femme (www.montessorienfrance.com) repose sur les services
de voila.fr pour son moteur de recherche. Mais dans ce dernier
cas, il ne s'agit que d'invocation à distance, pas de
véritable intégration puisque les résultats
s'affichent sur le site de voila.fr.
XML, toujours et encore
La standardisation du XML favorise ce type d'intégration
de processus via des échanges de données normalisés
mais on devrait bientôt pouvoir aller encore plus loin
dans cette logique d'intégration… En effet, des
développements récents du XML - encore lui -
vont bientôt nous apporter la RPC simple et standard que
l'on attend depuis 15 ans !
Les initiatives de RPC XML se multiplient pour permettre l'appel
de procédures à distance en utilisant le protocole
HTTP avec un document XML ne contenant que le nom du programme
à exécuter, les paramètres d'accompagnement
et les types de résultats escomptés. Dans ce domaine,
c'est bien SOAP qui paraît la plus prometteuse : proposée
initialement par Microsoft (c'est même la pièce
maîtresse de sa stratégie .net), soutenue par IBM
et en cours de normalisation par le W3C, SOAP se retrouve même
dans les développements XML du projet Apache !
Avec cette RPC XML, nous aurons tous les éléments
nécessaires pour utiliser l'Internet comme un immense
espace d'applications partagées et plus seulement comme
une mine inépuisable de documents !
Un exemple : si une société a besoin d'un système
d'enchères pour mettre en concurrence ses fournisseurs,
plutôt que d'en développer un à partir de
rien, il vaut mieux essayer d'abord de réutiliser les
processus spécialisés d'Ebay, de QXL, d'Ibazar
ou d'Aucland (ou d'autres). Car je doute fort qu'un effort isolé
aboutisse à un meilleur résultat (en terme de
fiabilité et de performances) dans ce domaine que ce
qu'on déjà obtenu les spécialistes du genre
avec des services qui sont mis à l'épreuve tous
les jours par des millions d'utilisateurs.
Pareil pour les autres besoins comme la gestion des voyages
d'affaires (qu'on commence à appeler etravel), la gestion
des approvisionnements (eprocurment) ou la gestion de projet
en ligne. Evidemment, on ne peut invoquer un processus à
distance sans l'accord de celui qui le fait tourner sur ses
machines !
Mieux que l'ASP
On voit donc apparaître un nouveau canal de commercialisation
pour des logiciels qui ne sont pas tout à fait des applicatifs…
C'est ainsi que linkuall.com propose, à la carte sa large
palette de services de gestion de projet. Grâce à
linkuall, vous pouvez, quasiment du jour au lendemain intégrer
sur votre site des processus de suivi de tâches, de gestion
de calendrier et d'alertes. Non seulement c'est moins cher que
de refaire dans son coin mais ça va plus vite et ce n'est
pas vous qui devez ensuite le maintenir et le faire évoluer.
Cette forme de commercialisation de logiciels à travers
la mise à disposition à distance de processus
pourrait bien se révéler la meilleure déclinaison
de la tendance ASP qui tarde à concrétiser ses
promesses.
Dans la foulée, on verra sans doute même apparaître
des intermédiaires en syndication de processus qui auront
pour rôle de faciliter le rapprochement entre les acteurs
(utilisateurs et fournisseurs) intéressés, voire
même d'héberger les interfaces…
Tous les espoirs sont permis, pensez-y quand vous envisagerez
de développer ou de faire développer votre prochaine
application pour votre extranet. Je ne suis pas en train de
prédire que les développements spécifiques
vont disparaître, simplement qu'ils vont de plus en plus
souvent servir à intégrer des services extérieurs
via la syndication de processus, grâce à XML.
[Alain
Lefebvre, vice-président du groupe SQLI]
|
|
|
|
Le
haut débit par satellite pour la communauté rurale est en pleine
croissance
