Ca émerge ou pas ?

De la présentation d’un symposium sur « le Web Sémantique qui émerge » (trouvez-moi une meilleure traduction SVP), je retiens les points suivants :

  • le WS permet aux machines d’automatiser, d’intégrer et de réutiliser des données entre applications
  • le WS requiert un langage de formalisation des connaissances
  • ces connaissances permettent, en s’appuyant sur des ontologies, de décrire le contenu de sources d’information et les conditions de fonctionnement de services Web
  • le modèle UML, les langages de description d’ontologies pour le web, le modèle et la syntaxe RDF, le dialecte XDD (tiens, je ne le connaissais pas, celui-là) sont des outils proposés pour le réalisateur d’applications web sémantiques
  • les services web trouvent dans le WS des dialectes XML de description, des solutions de découverte de nouveaux services appuyés sur des ontologies.
  • les ontologies permettent l’indexation sémantique de site web et peuvent s’appuyer sur des des framework d’annotation sémantique et des offres de solutions aux performances adéquates pour une utilisation à grande échelle
  • plusieurs ateliers logiciels sont proposés par les chercheurs pour l’intégration d’ontologies ; ces frameworks offrent une forte évolutivité (« scalabilité »), la résolution des contradictions entre ontologies et le support de formalisation hétérogènes d’ontologies

Autrement dit, la promesse du WS pour l’entreprise (notamment), selon ce symposium, c’est de permettre l’intégration des données de l’entreprise grâce à une formalisation des connaissances appuyée sur 1/ des spécifications techniques (langages, modèles) dédiée à l’expression de connaissances, 2/ des outils logiciels d’intégration de référentiels (ontologies).

Passé et avenir des services Web

Uche Ogbuji retrace l’historique des services web. En voici un résumé très schématique. IBM MQSeries était l’un des précurseurs de la tendance. En leur temps, vinrent CORBA et leurs pendants Microsoftesques COM et DCOM. Le protocole RMI pour Java naquit et les succès de niche de MQSeries donnèrent le jour à des technologies équivalentes chez Sun et Microsoft. Les services distribués prirent ensuite la forme de services Web (HTTP + XML) tout d’abord avec l’offre visionnaire e-Speak de HP (un peu trop en avance sur son temps ?) puis avec l’émergence du rustique mais simple et robuste XML-RPC au sein de la communauté opensource. Du côté des grosses entreprises, leurs besoins de transactions inter-organisations les menèrent de l’EDI façon Internet à l’ebXML (sponsorisé par Sun). C’est fin 1999 que SOAP (sponsorisé par Microsoft) fit son apparition. Une partie de la communauté opensource constituée autour de XML-RPC adopta peu à peu SOAP car cette spécification technique, pour une fois, semblait très ouverte. Plusieurs standards furent proposer pour décrire les services Web et c’est WSDL qui, sous le sponsorship d’IBM et de Microsoft s’affirma comme candidat le plus sérieux puis UDDI fut proposé en complément, pour constituer des annuaires de services Web. Aujourd’hui, c’est le trio SOAP + WSDL + UDDI qui est présenté comme la spécification moderne des services Web. SOAP connaît un certain succès « de terrain » auprès des développeurs notamment, malgré les problèmes d’interopérabilité qui subsistent lors des implémentations, tandis qu’à l’autre extrémité, UDDI, qui est sensé être un support pour des politiques « corporate » de gestion des services Web, à encore plus de mal à trouver ses marques.
D’après Uche Ogbuji, deux visions s’affrontent aujourd’hui parmi les promoteurs des technologies pour services Web : les uns pensent que les équipes amenées à implémenter des services Web devraient se composer d’experts en technologies XML (approche adéquate pour traiter des problématiques de communication inter-entreprises) ou de développeurs s’appuyant uniquements sur des boîtes à outils hermétiques (approche fréquente pour des périmètres spécifiquement internes aux entreprises). Microsoft (avec .Net) et IBM offrent de telles boîtes à outils. BEA, Iona et Apache offrent des fonctionnalités similaires. Etant donné le manque de maturité des technologies des services Web, les éditeurs de boîtes à outils risquent d’être l’objet d’importantes contraintes d’évolution lorsque des normes consensuelles émergeront et que leurs boîtes à outil devront tenter de s’y conformer. OASIS souhaite définir un modèle universel de composants pour services Web (WSCM) qui couvriraient des besoins tels que ceux aussi bien ciblés par CORBA ou COM que ceux ciblés par les composants visuels à la JavaBeans ou à la Delphi. De plus, l’avenir des services web pourrait être fortement influencé par l’évolution des bases d’objets et des technologies telles que le Web Sémantique. Pour l’instant, seul SOAP a fait l’objet d’implémentations fréquentes. Des spécifications technologiques complémentaires telles que UDDI, bien qu’émises depuis longtemps, n’ont toujours par pris forme en pratique et on peut s’interroger sur leur avenir.
Personnellement, je doute même de la pérennité, et surtout du bien-fondé, de SOAP qui, malgré sa séduisante et trompeuse simplicité d’implémentation auprès des développeurs, repose sur des principes architecturaux très éloignés du principe de « couplage faible » (loose coupling) qui a fait le succès des technologies Web. Le modèle REST semble bien plus satisfaisant à cet égard (chercher « REST » dans ce blog pour plus d’infos à ce sujet) bien que nécessitant un mode de conception d’applications + services Web inhabituel pour les développeurs, plus familiers du « j’ai une fonction/méthode, je lui passe des paramètres et j’obtiens un résultat en sortie » à la RPC.

Progiciel et EHS

La fonction Environnement, Hygiène et Sécurité (EHS, EH&S, HS&E, appelez-là comme vous voudrez) n’est pas parfaitement couverte par les progiciels de gestion intégrée (ERP) tels que SAP. Cet article fait le point sur la question et donne quelques conseils à ceux qui sont amenés à lancer des projets d’acquisition de progiciels environnementaux également appelés EMIS (Environmental Management Information Systems).
Ce sont les investisseurs et non les managers (et encore moins les managers EHS) qui ont fait évoluer les systèmes comptables depuis les années 30. Ce n’est qu’avec l’Activity-Based Costing et l’Activity-Based Management que les managers EHS ont eu une opportunité de communiquer sur les technologies et actions de prévention de la pollution. Dans l’offre progicielle actuelle de SAP, le système comptable peut être interfacé avec un module EHS essentiellement tourné vers la gestion des substances dangereuses (à travers les fiches MSDS) mais fournissant également des fonctionnalités orientées santé, hygiène industrielle et sécurité. Les sociétés TechniDATA en Allemagne et Enterprism Solutions aux USA étendent ces fonctionnalités notamment en s’orientant vers la gestion des déchets. De grands pans de l’EHS ne sont donc pas encore couverts. Le reporting actuel « manque de robustesse » et les fonctionnalités EHS sont d’une grande pauvreté comparativement aux systèmes dédiés EHS ou aux logiciels EHS développés sur mesure.
Il ne faut pas se leurrer, nous rappelle l’article : ce sont les points de vue financiers et comptables qui influencent le plus les services informatiques. Et la sélection d’un progiciel EHS peut prendre des mois et impliquer un grand nombre de consultants et de prestataires. Ces projets sont donc complexes et requièrent une très forte clarification des rôles de chacun de ses acteurs, faute de quoi le projet peut tourner au renvoi réciproque des fautes et responsabilités, comme l’a montré l’exemple de Hershey Foods.
L’option du développement spécifique n’est pas à éliminer d’emblée : bien que risquée et coûteuse, elle permet d’obtenir des fonctionnalités très adéquates au besoin et offre une solution évolutive car implémentée de manière incrémentale. L’approche la plus couramment retenue dans les entreprises dotées d’un ERP consiste à se doter d’un progiciel EHS particulier, qui sera ensuite interfacé avec l’ERP comptable et financier. Des éditeurs EHS tels que Essential Technologies et Quantum Compliance Systems sont ainsi certifiés compatibles pour et par SAP.
Des organismes tels que l’EHS Software Development Group (EH&SSDG) peuvent être d’utiles conseillers dans de tels projets. Donley Technologies connaît également bien le marché des progiciels EHS et on trouvera quelques informations intéressantes sur http://www.ehsfreeware.com.

Un PDA, ça sert à quoi ?

Ils ont utilisé des PDA (Palm, Pocket PC, …) pendant longtemps. Finalement, à quoi ces curieuses petites choses leur ont-elles servi ? Un extrait des réponses :

  • lire des livres numérisés
  • jouer à des jeux électroniques
  • jouer aux échecs dans les toilettes
  • pointer son temps sur des projets et des clients pour pouvoir le refacturer
  • gérer RDV et contacts pour les nomades

On reproche aux PDAs :

  • la difficulté pour saisir des données de manière fluide et conviviale
  • la pauvreté de l’offre logicielle (surtout pour les Palm)
  • la lourdeur des synchronisations avec le poste de travail (attendre 10 à 30 minutes en fin de journée alors que c’est le moment de rentrer à la maison…)

Nombreux semblent être ceux pour qui les propriétaires de PDA essaient davantage de justifier l’utilité d’un symbole statutaire plutôt que de profiter d’usages réellement profitables de cet objet. Nombreux sont ceux, aussi, qui ont finalement abandonné leur PDA sur un coin de leur bureau après s’être amusés avec pendant quelques semaines. Pourtant, nombreux sont également ceux qui disent être devenus dépendants (notamment parmi les « nomades » ayant le plus de rendez-vous et de contacts à gérer au quotidien) ! Enfin, certains ont préféré le « Blackberry » de chez RIM, essentiellement pour son petit clavier ainsi que pour sa robustesse.

L’amateurisation de la publication

Sur son weblog, Clay Shirky discourt au sujet… des weblogs et
de l’amateurisation de masse de la publication. Naguère, au temps jadis d’avant, le processus de publication créait une
valeur non seulement parce que ce processus était coûteux (d’où une barrière à l’entrée et des opportunités d’échelle sur un
marché sans cesse plus concentré) mais aussi, du même coup, parce que l’éditeur devait sélectionner le contenu pour ne
publier que celui qui représenterait le plus de valeur sur le marché. Le développement de l’Internet et, aujourd’hui, des
weblogs, change la donne : le coût de publication est considérablement amoindri, les barrières à l’entrée se sont effacées,
et les auteurs n’ont plus à passer au travers du scepticisme professionnel de l’éditeur pour atteindre son public. Quels
modèles économiques peuvent se révéler intéressants dans ce contexte ? Créer une pénurie artificielle, en ne donnant accès au
contenu qu’aux seuls abonnés ayant payé est une solution envisageable. Mais l’abaissement des barrières à l’entrée rend très
probable l’apparition de « nouveaux entrants » sur le marché susceptibles de publier à coût plus bas voire nul. Restent les
revenus indirects : publicité, sponsorship et marketing direct. Le webloggeur (ou carnetier) peut également envisager de
demander des donations à ses lecteurs, éventuellement via une coopérative de webloggeurs. Enfin, il reste… la publication
sur papier. En effet, les rares personnes à gagner aujourd’hui de l’argent dans le monde des weblogs sont ceux qui ont publié
des livres décrivant le phénomène ! Mais la plus grande récompense pour le weblogueur n’est-elle pas simplement de participer
à la conversation ?

Agrégateurs de news RSS

L’OpenDirectory signale notamment les logiciels opensource suivants, parmi les nombreux agrégateurs de News RSS aujourd’hui disponibles : Aggie (.Net), AmphetaDesk (perl), MyHeadlines (PHP+MySQL), Peerkat (Python) et Reptile (en architecture peer-to-peer) . Parmi les logiciels signalés par l’OpenDirectory, j’ai notamment repéré fyuze, NewsApp de server.com,
NewzCrawler. Il faut également signaler les nombreux produits de syndication « in-bound » (=aggrégation) pour Zope, même si aucun n’offre de fonctionnalités « off-the-shelves », comme on dit (il faut coder un peu pour intégrer ces produits dans un site fait avec Zope).
Jon Udell citait (dans un article sur byte.com auquel, visiblement, on n’a plus accès à moinds de s’enregistrer auprès de byte.com ; le titre « personal RSS aggregators… ») les principaux aggrégateurs RSS. Amphetadesk et Peerkat m’ont paru les plus intéressants d’entre eux. J’ai installé Amphetadesk : ça marche bien malgré le
fait qu’Amphetadesk a repéré des centaines de canaux RSS lorsque je naviguais sur des sites de syndication tels que moreover,
newsisfree et syndic8. Du coup, ma liste de canaux disponibles est immense et bien peu utilisable ! Il manque encore des
fonctionnalités mais c’est un très bon début pour imaginer ce que seront les aggrégateurs personnels de demain. Reste à
tester Peerkat. Jon Udell, dans son article, cite de manière désordonnée les principales fonctionnalités attendues pour ce
genre d’agrégateurs (ou syndicateurs ?). Essayons d’y mettre un peu d’ordre :

  • présenter le contenu sur trois panneaux, à la façon des lecteurs de newsgroups (Usenet)
  • proposer des listes de canaux pré-enregistrés
  • lire les formats RSS 0.92, 1.0,
  • organiser les canaux par catégories
  • ouvrir une fenêtre d’alerte lorsqu’une actualité apparaît
  • organiser les actualités et canaux sous la forme d’un arbre « à l’Explorer »
  • lire les groupes de news NNTP (Usenet)
  • lire des sites web d’actualités (screen craping, web clipping)
  • ajouter de nouvelles sources facilement
  • faire lire les actualités par un synthétiseur vocal
  • faire défiler les actualités à l’écran sous la forme d’un prompteur
  • importer/exporter la liste de canaux
  • écrire des actualités
  • publier un canal
  • offrir une API (en XML/RPC par exemple)
  • supporter l’API de Blogger
  • sélectionner des actualités une à une, les filtrer, les annoter et afficher voire publier le résultat
  • avoir une interface claire, intuitive et conviviale
  • je vous laisse imaginer le reste

On ne tardera pas à voir apparaître des offres logicielles « corporate » pour la syndication de contenus. Sinon, il me reste encore à installer et tester peerkat.
Tiens, il y a aussi quelqu’un qui tente de définir Le Parfait Agrégateur RSS.

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.