Archives mensuelles : décembre 2002

Les blogs

MSNBC le raconte très bien : des
blogs de toutes sortes sont apparus sur le Net : les blogs sont ce que le fait de « faire sa
home page » était il y a quelques années. Les bloggers sont motivés par un besoin
d’attention, une obsession pour le partage d’information et surtout, par le désir d’être « un
participant et non une patate » ! Souvent, un blog (ou « carnet web ») est un bon moyen pour
tenir au courant des amis ou de la famille. Les blogs sont devenus un phénomène social et on
a vu se former une blogosphère d’amas de blogs interconnectés, aux centres d’intérêts
similaires. David Weinberger, auteur d’un livre sur la cyberculture, déclare « Dans le futur,
tout le monde sera célèbre via le Web auprès d’une quinzaine de personnes ». Et on compte sur
les doigts de la main (plus les orteils) le nombre de blogs ayant atteint un statut de
carnet culte sur le Net. L’émergence des carnets web est notamment due à une petite société
informatique nommée « Pyra », dont les trois cofondateurs avaient pris l’habitude de tenir à
jour un blog pour diffuser des nouvelles d’un projet informatique qu’ils menaient. Ils ont
rapidement compris que nombreuses seraient les personnes qui seraient intéressées par leur
petit outil de mise à jour de site, Blogger. Ils l’ont alors mis à disposition sur le Net en
août 1999, avec le succès que l’on connaît. Le succès des blogs vient de la « faible barrière
à l’entrée » : la simplicité du format des blogs rend la publication extrêmement aisée et à
la portée de tous. Mais là où le blog prend tout son intérêt, c’est lorsque, par vos
commentaires et les liens que vous publiez, vous venez à préciser vos centres d’intérêt et à
vous mette en relation avec d’autres bloggueurs aux préoccupations similaires. L’ampleur du
phénomène blog a été révélée au grand jour suite aux attentats du 11 septembre 2001 et à la
multiplication des « bloggueurs de la guerre ». L’avenir semble être maintenant l’entrée des
blogs dans le monde de l’entreprise. On cite des expérimentations de « corporate blogging »
chez DuPont, Intel, Motoral ou encore Nokia. Le CEO de l’éditeur informatique Groove
Networks tient à jour un blog personnel. L’éditeur Macromedia a adopté les blogs pour mettre
en place des canaux de support peu coûteux pour informer et aider les utilisateurs de ses
produits logiciels (cf. un article que j’avais posté ici il y a quelques temps à ce sujet :
cherchez « blog » dans le formulaire de recherche de cette page). Le format des blogs semble
également se prêter, à l’intérieur de l’entreprise, à de nouvelles formes de reporting…

Liens bidirectionnels

Disenchanted l’a
inventé : le lien hypertexte bidirectionnel. Le principe est simple : chaque
page possédant cette fonctionnalité affiche des liens vers les pages qui lui
ont apporté des visiteurs. Comment ça marche : lorque vous arrivez sur une
page depuis une page, votre navigateur indique au serveur l’adresse Web de
la page de départ. A l’aide d’un petit script, on stocke la liste des
adresses de toutes ces « pages de départ » et ce petit script peut même aller
y faire un tour pour en extraire un titre ou un résumé à afficher à côté du
lien de départ. Un bon usage des technologies Web pour rendre nos sites plus
interatifs et favoriser les connexions au sein d’une même communauté
d’intérêt.

Topic Maps à la rescousse du B2B

L’une des problématiques essentielles de l’interconnexion d’applications
entre entreprises (les applications « B2B ») consiste à garantir que les
acteurs en présence interprètent bien de la même manière la signification
(la sémantique) des données échangées. La technologie
des topic maps pourrait contribuer à résoudre cette problématique.
Une
solution d’usage de ces topic maps pourrait consister à créer des
vocabulaires universels, expliquant la signification de toutes les données
potentiellement utiles dans un dialogue entre entreprises de manière à ce
que toutes les entreprises s’y réfèrent. Mais cette solution n’est pas
réaliste Les topic maps peuvent permettre d’établir une interopérabilité
entre des ontologies (référentiels de méta-données) suffisante pour la
plupart des problèmes rencontrés dans l’échange de données
inter-entreprises. Mais la mise en correspondance de ces ontologies, deux à
deux, quand bien-même elle serait exprimée à l’aide des topic maps, reste
aujourd’hui un travail « manuel » fastidieux et délicat. Heureusement, les
topic maps sont conçues pour se révéler « réutilisables » d’un échange à
l’autre, ce qui permettrait de capitaliser ce travail de mise en
correspondance, de manière à créer des « business maps ».

Googlez vos email

Jon Udell l’a testé pour vous : ZOË est un proxy mail (POP + SMTP) qui indexe tous vos mails et vous offre non seulement des fonctionnalités de recherche plein texte mais surtout des fonctionnalités (simples) de navigation dans les métadonnées de ces mails, principalement à partir des champs Subject, Date et From. Ce type de logiciel repose sur une architecture applicative que j’aimerais voir se répandre malgré son caractère paradoxal : il s’agit d’applications web déployés sur les postes clients avec des serveurs web « légers » ; et surtout, il s’agit d’application s’intégrant dans le travail quotidien de l’utilisateur puisqu’elle se présente sous la forme d’un proxy. Jon Udell regrette que les clients de messagerie ne supportent pas la gestion d’extensions des métadonnées transférables par messagerie.
Sans étendre les fonctionnalités des actuels clients de messagerie, un modèle d’architecture qui permettrait une exploitation plus poussées de métadonnées associées à des emails consisterait à ne pas utiliser de proxy POP comme dans ZOË mais un proxy acceptant du POP ou de l’IMAP comme source de données (serveur de messagerie) et offrant un service IMAP comme interface avec le client de messagerie. Ainsi, cette application offrirait par le biais de l’arborescence de dossiers IMAP une ou plusieurs vues arborescentes d’un graphe de méta-données associées aux emails qui circulent par le biais du proxy. L’interface web de l’application permettrait de pallier aux lacunes du client de messagerie en offrant toutes les fonctionnalités requises pour la gestion des méta-données. Malheureusement, il n’existe pas aujourd’hui, à ma connaissance, de proxy IMAP opensource et encore moins de proxy IMAP offrant des fonctionnalités de filtres (interception des requêtes et réponses) à la manière des filtres d’Apache 2. Mais bon, on peut toujours rêver… Dans tous les cas, ce type d’architecture à base de proxies filtrant (filtrant les usages du mail ici, mais aussi, plus simplement, filtrant les usages du web) semble être un excellent moyen de capturer des métadonnées de manière non perturbante pour l’utilisateur. Ceci constituerait une réponse judicieuse à la difficulté qu’aura le Web Sémantique à atteindre une taille critique : comment produire des méta-données pour alimenter le Web Sémantique ? par annotation manuelle ? par intégration de sources de données existantes ? par structuration automatique de sources non structurées ? ou bien par interception de méta-données comme dans le cas de ces proxies…
Wow, je viens de consommer mon quota annuel de buzzwords en un seul message !

Des treemaps, en veux-tu, en voila…

Ah, la, la ! Et dire qu’en prépa, en 1993, j’avais (ré-)inventé les « treemaps » sans le savoir ! Ce magnifique historique des treemaps ne me mentionne évidemment pas :-). Des treemaps, me direz-vous ?… Mais si ! Des treemaps … souvenez-vous : les algorithmes pour naviguer dans des graphes complexes, en regardant à travers les noeuds (« en s’asseyant sur un noeud » pour regarder le paysage disaient certains…). Je vais essayer de retrouver toutes les sources de mes expérimentations pour la construction de treemaps et de vous les publier par ici. Au menu à venir, donc : du Turbo Pascal et… du Delphi. A suivre…

Construire des communautés électroniques

Chromatic nous dispense ses bons conseils pour réussir la constitution et l’animation de communautés électroniques par le biais de sites Web. Son premier conseil concerne les finalités du site : quelles sont les finalités de l’animateur ? quel bénéfice un utilisateur tirera-t-il de sa participation à la communauté ? quel intérêt aurait quelqu’un à rejoindre cette communauté ? Construire une communauté sans finalité explicite serait comme créer une entreprise en oubliant qu’il s’agira de trouver des clients prêts à payer. Ensuite, l’article de Chromatic explique les mécanismes de l’effet « réseau » ou « boule de neige » : ce sont les participants satisfaits qui attireront l’essentiel des nouveaux participants. Lorsque ce mécanisme est bien enclenché, la communauté acquière une certaine inertie : ses membres se sont appropriés le site support de la communauté et deviennent un frein à tout changement du site en question. Ce qui caractérise une communauté bien constituée, ce sont notamment ses clins d’oeil culturels internes, ses « private jokes », qui sont autant de signes de reconnaissance entre ses membres. Mais il ne faut pas oublier que dans toute communauté, les gens ne participent que de manière marginale : la plupart lisent et n’écrivent pas, et ceux qui écrivent ne le font qu’occasionnellement. Pour multiplier les membres actifs, il convient d’abaisser les barrières à franchir pour pouvoir contribuer. En particulier, le nombre de membres actifs est inversement proportionnel à l’effort nécessaire pour la première contribution (inscription, …).

Comment choisir un progiciel

GFI Consulting publie un vieil article sur les bonnes (et non moins vieilles) pratiques qui permettent de choisir un progiciel. En particulier, GFI signale que pour être qualifié de progiciel, un logiciel doit non seulement avoir fait l’objet de spécifications formelles pour chacune de ses versions mais doit également faire l’objet d’un effort régulier de commercialisation et de support. Enfin et surtout, il doit être garanti, maintenu et en évolution durable. GFI recommande de ne pas procéder à un choix de progiciel par émission d’un cahier des charges mais par élimination progressive des candidats potentiels dans une démarche plus interactive avec les éditeurs. En effet, aucun progiciel ne répond parfaitement à un cahier des charges spécifique ce qui conduit fréquemment à l’une des situations suivantes : développement spécifique « par dépit », modifications du progiciel par l’éditeur qui aboutissent à en faire un logiciel spécifique, adoption d’un progiciel tellement paramétrable qu’il devient une plate-forme de développement propriétaire au coût de développement/paramétrage comparable à celui d’un développement spécifique ou sélection du progiciel le moins pire par un « consensus mou ». Il ne s’agirait donc pas d’élaborer un cahier des charges détaillé mais seulement une expression générale des besoins fonctionnelles qu’il s’agira de compléter en fonction de la manière dont chaque progiciel étudié y répond. De toutes façon, il convient de retenir que les utilisateurs auront à modifier leurs processus et méthodes de travail pour s’adapter au progiciel (et non l’inverse).
En ce qui concerne la pérennité de l’offre d’un produit par un éditeur, il convient selon GFI de savoir qu’une telle offre n’atteint l’équilibre économique que lorsque le produit a été diffusé à plusieurs dizaines d’exemplaires. GFI considère qu’un progiciel de gestion intégré (ERP) devrait offrir un coût initial d’achat sensiblement inférieur au dixième du coût d’un développement spécifique. Tant que le progiciel n’a pas été commercialisé auprès de 40 clients, après 18 à 30 mois d’existence, sa pérennité économique reste fragile.
De plus, il convient d’estimer non pas le seul coût d’achat mais le coût complet de la solution pour l’ensemble de son cycle de vie, c’est-à-dire jusqu’à son remplacement par une solution impliquant une reprise des données et une nouvelle formation des utilisateurs.

Edition d’ontologies

XML.com fait le point sur la construction d’ontologies. La construction d’ontologies se révèle utile dans des domaines tels que la recherche sur le Web Sémantique, la création de référentiels médicaux, la gestion de ressources d’information publiques, la cartographie de génomes, l’ingénierie en conception concurrente, l’analyse et la gesion des risques et l’automatisation des transactions commerciales entre entreprises.
L’ontologie permet de disposer d’un discours commun pour décrire un domaine donné et qui permet une exploitation automatisée par des règles d’inférence et de traitement logique. Les ontologies se composent habituellement de deux couches : un composant « terminologique » qui définit la structure du domaine à décrire et un composant « assertionnel » (assertional) qui alimente cette structure avec des instances ou individus qui incarnent les définitions terminologiques. On peut décider de stocker les concepts (structure terminologique) et les individus (instanciations des concepts) de manière distinctes mais le fait de traiter une ressource comme un concept ou comme un individu est une décision arbitraire et doit relever d’un choix volontaire lors de la conception de l’ontologie.
Pour bâtir une ontologie, on peut utiliser des langages de programmation logique classique tels que Prolog. Mais, plus souvent, on utilise des modèles et langages spécialisés pour la construction d’ontologies tels que OKBC, KIF et CL). On peut également utiliser des langages plus avancés tels que Loom, DAML+OIL ou le standard qui en émerge auprès du W3C : OWL (Ontology Web Language). Le choix du bon langage de développement dépend notamment du degré de nuance et de sophistication nécessaire pour répondre au besoin fonctionnel. De plus en plus, ces langages tendent à intégrer RDF comme technologie fondamentale pour intégrer les données présentes sur le Web.
Voici les étapes habituelles dans la construction d’une ontologie : acquérir la connaissance du domaine (à l’aide documentation et d’experts du domaine), organiser l’ontologie (à l’aide de méthodologie de conception d’ontologies), alimenter l’ontologie (par des concepts, des relations et des individus), vérifier la cohérence du résultat (cohérence syntaxique, logique et sémantique) et soumettre à la publication (validation par les experts du domaine).
Il existe plusieurs logiciels pour construire des ontologies (composant terminologique seulement ou bien ensemble de l’ontologie). On trouve des produits commerciaux offrant des fonctionnalités d’édition d’ontologie non spécifiques à un domaine, des logiciels d’édition intégrés à des solutions d’entreprises spécialisées et des logiciels d’édition issus du secteur public. Les outils intégrés à des solutions d’entreprise offrent des fonctionnalités de classification et d’analyse automatisées afin d’extraire de l’information à partir de contenus non structurés. Une fonctionnalité attendue mais actuellement non présente dans ces outils consiste à permettre, via une ontologie, de réconcilier des langages et vocabulaires XML spécialisés par domaines commerciaux. Pour le moment, l’interopérabilité est uniquement offerte par des fonctions d’import et d’export en différents langages de sérialisation d’ontologie (par exemple basés sur XML). Rares sont les logiciels d’édition offrant des fonctionnalités de fusion d’ontologies hétérogènes.
Trois logiciels d’édition sont remarquables : Protégé 2000 pour la richesse de ses fonctionnalités et son extensibilité via des plug-ins, Ontolingua et OpenCyc en tant qu’environnement de développement d’ontologies complexes ainsi que pour l’accès, par OpenCyc, à une ontologie globale de référence très complète (Cyc). Les fonctionnalités essentielles attendues pour ce type d’outil sont une visualisation et une manipulation confortables et intuitives des concepts et des relations qui composent l’ontologie. L’approche classique consiste à offrir une combinaison de vues sous formes d’arbres à la manière de l’explorateur de Windows. Une visualisation sous forme de graphe est plus rare. Elle doit alors offrir une fonctionnalité de zoom permettant de manipuler des graphes très étendus. Ce type de zoom peut par exemple prendre la forme d’une visualisateur hyperbolique ou d’un visualisateur « à la treemap » (les noeuds « enfants » d’un point de départ sont visualisés *à l’intérieur* du noeud parent et sont explorés par un zoom progressif pour descendre en profondeur à travers les noeuds…). Enfin, certains logiciels d’édition offrent la possibilité d’ajouter à l’ontologie des axiomes et règles d’inférence permettant d’évaluer cette ontologie dans un environnement de développement.

Zope vs Cocoon, Python vs Java

La société ArielPartners a publié
une étude comparative de Zope et de Cocoon
, deux environnements objets faisant office de serveurs d’applications Web pour les sites Internet et intranet orientés publication de contenu. Leur conclusion présente Zope comme un environnement plus puissant, plus mûr et mieux documenté, avec une avance de une à deux années sur Cocoon et les environnements de publication Java similaires à Cocoon. En particulier, Zope offre des fonctionnalités satisfaisantes de gestion des transactions, de la sécurité et une évolutivité remarquable (scalabilité).
ArielPartners publie également une
comparaison détaillée des langages Python (associé à Zope) et Java (associé notamment à Cocoon)
. Cette comparaison soutient la thèse suivante : il suffit d’adopter Python ET Java pour couvrir l’intégralité des besoins de développement courant en informatique d’entreprise. Python offre les avantages suivants :

  • le code Python est plus concis (3 à 5 fois plus concis qu’en Java) et le codage est plus rapide et facile
  • le langage évolue plus rapidement que Java car Java a acquis plus d’inertie
  • Python impose moins de contraintes pour le codage, au prix d’un plus grand risque d’erreurs lors de l’exécution du code
  • Python est plus facile à apprendre pour les débutants tout en étant satisfaisant pour les experts : sa courbe d’apprentissage est plus douce
  • Zope est un serveur d’application python reconnu.
  • La syntaxe de Python est plus claire et plus lisible
  • Python, comparativement à Java, offre un code plus facilement maintenable.
  • L’interpréteur Python compile le code à sa première exécution et exonère ainsi le développeur de phases de compilation fastidieuses.
  • Python est un choix judicieux pour la majorité des tâches de développement en entreprise.
  • Les domaintes d’excellence de Python sont : le scripting, le prototypage rapide, l’intégration de systèmes (langage « glue »), les applications web, les outils graphiques, les outils de traitement XML.

Les avantages de Java sont les suivants :

  • on compte 3 millions de développeurs Java dans le monde contre un demi million de développeurs Python
  • Le code Java, plus contraint pour le développeur, offre moins de risque de bug
  • Java s’accompagne d’offres mûres et nombreuses en matière de serveurs d’application grâce à J2EE, RMI, Jini et JavaSpaces. Les principaux serveurs d’application sont BEA WebLogic, IBM WebSphere, Sun One Application Server et JBoss (opensource).
  • Java offre des modèles à base de composants adaptés à l’entreprise avec les modèles JavaBeans et EJB.
  • Java s’accompagne d’outils de conception graphique, de documentation et de débuggage très avancés.
  • Java, comparativement à Python, offre un code plus performant.
  • Java se présente comme un choix complémentaire intelligent pour tous les cas …
    • … où Python n’a pas encore fait ses preuves (Aspect-Oriented Programming, recherche sur les technologies SOAP/WSDL/UDDI, utilisation d’outils de modélisation UML avancés)
    • … où les performances brutes sont critiques
    • … où il s’agit de mettre en place des systèmes distribués ou parallélisés à très grande échelle
    • … où la facilité de recrutement de compétences de développement ou la disponibilité d’outils de développement est critique

L’art et la manière de réussir un projet Progiciel

Le CIGREF a réuni dans un document des recettes de bon sens pour réussir un projet
progiciel. Le magazine L&S a repris l’essentiel de ce document dans un article
dont il ressort les points
suivants:
Le coût de licences ne représente que 20% des dépenses totales de ce genre de
projet. Ce type de projet donne habituellement lieu à un appel d’offres, rationnel et
contradictoire. Mais l’organisation d’un appel d’offres engendre des coûts et délais souvent
sous-estimés. Le choix du progiciel doit s’appuyer sur une approche à trois dimensions : par
les besoins fonctionnels, par l’offre du marché et par l’existant dans le système
d’information de l’entreprise. Le choix s’effectue en trois étapes : définition du cahier
des charges pour l’appel d’offre et inventaire de l’existant, identification d’environ 6
progiciels offerts par le marché, réduction à un échantillon de 2 ou 3 candidats puis choix
du progiciel à acheter. Le cahier des charges doit contenir au minimum les principales
règles de gestion et les principes d’organisation exprimant le besoin fonctionnel. Les
critères de choix pour identifier la solution répondant au mieux à ce besoin doivent
comporter toutes les dimensions suivantes : durabilité du fournisseur, durabilité du
progiciel, caractéristiques des données traitées (volumes, formats, interfaces),
caractéristiques informatiques, coûts (pour chaque étape de vie du progiciel), performance,
sécurité, services du fournisseur. Le choix doit s’appuyer sur une comparaison de progiciels
sur la base de jeux d’essai donnés au fournisseur, sur le prototypage des fonctionnalités
spécifiques et les spécifications des adaptations nécessaires. En particulier, la
faisabilité de l’interfaçage du progiciel avec l’architecture du S.I. existant doit être
examinée en détail. En ce qui concerne le degré de flexibilité du progiciel, on remarquera
que plus un progiciel est paramétrable et adaptable aux spécifications fonctionnelles
détaillées, plus le travail de paramétrage et d’adaptation sera long et coûteux. A l’inverse
un progiciel rigide implique des coûts d’adaptation des processus de travail. Afin de
procéder à la comparaison des progiciels candidats, il est judicieux d’élaborer une grille
d’évaluation comme outil de réflexion mais il convient de savoir s’abstraire de tout système
de notation pour prendre une décision ultime de manière responsable. Une grille d’évaluation
peut permettre de constater que, quelque soit, la pondération affectée à chaque critère de
notation, une solution se dégage (ou non) comme préférable auquel cas il convient d’en tirer
des conséquences lors du choix final. Enfin, il ne faut pas s’arrêter à la comparaison des
coûts logiciels dans la mesure où une offre moins complète entraîne des surcoûts de
développements complémentaires.
En ce qui concerne le prototypage, il est particulièrement utile puisque qu’il doit se
focaliser sur les processus métiers considérés comme essentiels ou posant le plus de
problèmes de faisabilité, de compatibilité technique avec l’existant ou de qualité
d’ergonomie. Il permet de prendre en compte les contraintes techniques imposées par le
projet et d’étudier les performances et limites du progiciel en se concentrant sur les 20%
de cas qui couvrent 80% des volumes ou les 20% de cas les plus complexes à traiter.
L’article détaille également les bonnes pratiques pour les phases de paramétrage, de test,
de conduite du changement, de migration et de reprise de données, d’adaptation, de
documentation et de contractualisation. Il insiste en particulier sur l’importance, pour ce
dernier point, de se faire accompagner dans le choix par un juriste et par un acheteur seuls
capables de prévenir les écueils courants pour ce type de projets.

NTFS et FAT32

Ma soeur me demande : « C’est quoi des nfts et des fat32 ? » Je ne suis pas un spécialiste de la question, mais voici ce que je lui ai répondu.
Ce sont des « systèmes de fichiers », i.e. la manière dont une partition d’un disque dur est organisée pour stocker des fichiers. NTFS est le système de fichier de Windows NT. FAT32 est le système de fichier de Windows 95, 98, 98SE et 98ME. Windows NT et Windows 2000 connaissent les deux systèmes de fichier. Windows XP connaît sans doute également les deux mais, moi, je ne fréquente pas Windows XP.
Linux organise ses fichiers selon d’autres systèmes de fichiers. Mais Linux connaît aussi NTFS et FAT32 donc tu peux lire des partitions NTFS et FAT32 depuis un linux.
L’avantage de NTFS sur FAT32 est que ce système permet de contrôler que seuls certains utilisateurs de ton Windows ont le droit de faire certaines actions sur certains fichiers et répertoires. A priori, NTFS est également plus « robuste » que FAT32, i.e. qu’il y a moins de risque de pertes de données en cas de plantage de l’ordinateur. Je ne connais pas les inconvénients de NTFS sur FAT32 si ce n’est qu’une partition organisée en NTFS ne sera pas lisible depuis un Windows qui ne connaît que FAT32.