Archives pour la catégorie Développement

Comment concevoir un assistant de dépannage « bayesien » ?

A ceux qui auraient pu croire que la technologie des réseaux bayesiens permettrait d’un coup de baguette magique, d’introduire de l’intelligence artificielle à moindre frais dans les systèmes informatiques, John Locke, « ingénieur de la connaissance » de son état, prouve le contraire. En effet, il explique en détails comment concevoir un assistant de dépannage (« troubleshooter ») à l’aide de la technologie des réseaux bayesien. Et son explication montre qu’il s’agit d’une tâche de conception non triviale.
Au passage, on apprend que les réseaux bayesiens sont particulièrement efficaces lorsqu’il s’agit de diagnostiquer un problème complexe ayant un grand nombre de causes possibles à partir d’un seul vague symptôme. L’assistant de dépannage ainsi conçu collecte des indices et symptômes et s’appuie sur un graphe de causalité liant les problèmes, leurs causes possibles, les symptômes que celles-ci génèrent et les actions pour y remédier. Il s’agit donc pour le concepteur d’élaborer une bonne modélisation sous forme de graphe, d’apprendre ensuite au réseau bayesien quels sont les causes les plus probables pour quels symptômes et de paramétrer l’assistant de dépannage pour qu’il propose à son utilisateur les actions les plus efficaces (en prenant en compte leur facilité d’exécution notamment).

Workflow dans Plone

Ce document explique les phases du développement d’application de workflow s’appuyant sur Plone. Une fois Zope, Plone et CMFOpenflow installés, l’essentiel du travail consiste à modéliser le processus qu’il s’agit d’informatiser. Cette étape est critique car la modélisation de processus est en soit difficile. Elle requiert une grande rigueur et de bonnes compétences d’analyses fonctionnelles ainsi qu’une excellente communication entre l’analyste et le gestionnaire du processus. Une fois le workflow (modèle de processus) dessiné sur papier (analyse), il est facile de le transcrire dans OpenFlow. Ensuite, le développeur doit déclarer dans Zope les rôles utilisateur requis par le workflow puis aura à créer les formulaires de saisie de données de chaque étape du workflow ainsi que les éventuels scripts déclenchés lors des transitions entre étapes du processus. Un peu de test, et hop, ça tourne (du moins en théorie).
Il est bon de noter que la plupart des moteurs de workflows fournissent un éditeur graphique de Workflow. Cette interface semble extrêmement importante pour le novice qui examine ce type de produit. Cependant, il semblerait qu’un éditeur de ce type n’apporte pas grand chose de plus qu’une feuille de papier et un stylo. OpenFlow ne fournit pas d’éditeur de ce type mais seulement un visualisateur de workflow (une fois que les étapes du workflows ont été transcrites dans le paramétrage de OpenFlow). Cette lacune ne semble donc pas critique.
Plone a été initialement distribué avec un module de workflow « DCWorkflow », orienté document. OpenFlow est un autre produit de workflow pour Zope qui diffère de DCWorkflow par le fait qu’il est orienté « activité » et permet donc de modéliser des processus plus complexes et moins spécifiquement liés à la gestion de contenu Web. Cependant, OpenFlow est un produit Zope qui ne s’appuie pas sur le framework CMF. Par conséquent, il était difficile de développer des applications de gestion de contenu faisant appel aux fonctionnalités avancées d’OpenFlow. C’est pourquoi la communauté de développement d’OpenFlow a créé Reflow (également appelé CMFOpenFlow, apparemment) qui, lui, est sensé s’intégrer parfaitement dans CMF et donc a fortiori dans Plone.

Développer avec les Archetypes

Archetypes est un produit Zope qui permet de développer des applications de gestion de contenu s’appuyant sur CMF (et sur Plone, par exemple). Une introduction didactique au fonctionnement d’Archetypes nous en explique le fonctionnement et la raison d’être : Archetypes permet au développeur de ne pas avoir à maîtriser la complexité (de l’API) du framework de gestion de contenu CMF, en lui permettant de générer de manière rapide des objets s’appuyant sur CMF. Archetypes constitue donc, en quelque sorte, l’essentiel d’un atelier de développement rapide d’applications de gestion de contenu.
Le principe général de fonctionnement est le suivant. Le développeur décrit en quelques lignes de Python le schéma de l’objet qu’il veut développer, en s’inspirant du schéma d’un objet existant : « ma classe d’objet ‘MonArticle’ a les mêmes propriétés et méthodes que les objets de la classe ‘Article’ mais possèdent également un champ de type texte, qui s’appelle ‘thème’, qui ne peut pas être vide et que l’utilisateur remplira à l’aide d’une ‘textarea’ HTML ». C’est ensuite le produit Archetypes qui transforme cette définition en un objet opérationnel qui peut être installé dans une instance Plone sans développement supplémentaire.

L’avenir de l’énergie

Dans la sérieuse revue Scientific American a été présenté un ouvrage faisant le point sur l’avenir énergétique de la planète. Selon l’auteur de ce livre, la question essentielle est de savoir comment mettre l’énergie à la portée des bourses des milliards de personnes pauvres sur la planète sans pour autant endommager de manière irrémédiable l’environnement mondial (et donc celui des pays riches notamment). L’ouvrage défend les thèses suivantes :

  • Nos civilisations ne seront pas de sitôt à cours d’énergie ; par contre elles sont presque déjà « à cours d’environnement ».
  • Il n’est pas prudent d’attendre des preuves supplémentaires de l’impact climatique des activités humaines ; cet impact est suffisamment probable pour devoir influencer nos politiques énergétiques dès à présent.
  • Il faut interrompre le subventionnement du marché de l’énergie, « internaliser » dans ce marché le coût induit par les changements climatiques liés à la production de gaz à effets de serre (« polleur payeur »), et fournir aux pays pauvres les technologies environnementales modernes qui leur éviteront de passer par les étapes les plus polluantes du développement industriel.

Economie sociale et ISR

Les acteurs de l’ économie sociale (coopératives, mutuelles et associations) seraient des champions de l’Investissement Socialement Responsable. Autre idée : la principale faiblesse de l’économie sociale est la difficulté à prendre des risques car les investisseurs ne sont pas rémunérés pour leur prise de risque ; d’où le besoin de sociétés de capital risque spécialisées dans les entreprises de l’économie sociale.

Pensez à l’offshore

Le Gartner Group évoque l’externalisation à l’offshore des activités de développement applicatif. Il précise que seule la phase de développement proprement dite peut se réaliser efficacement à l’offshore. Les activités de maintenance requièrent trop de présence sur site. Le Gartner indique également qu’il est parfois préférable d’externaliser auprès de fournisseurs nationaux plutôt que de se tourner vers l’offshore : en effet, le niveau de compétence et, surtout, la facilité de communication offerte par les fournisseurs locaux peut représenter un avantage déterminant sur le coût de la main d’oeuvre dans les pays en voie de développement. Les entreprises envisageant d’externaliser ces activités devraient donc prendre grandement en compte ces difficultés de communication dans l’organisation de leur projet. D’autres difficultés résident notamment dans la barrière du langage, la qualité des infrastructures de communication et, tout simplement, les différences culturelles. Hormi les cas pour lesquels l’offshore offre des coûts au jour.homme 6 fois moindres que les coûts d’un prestataire national, l’externalisation auprès de partenaires locaux semble raisonnable voire préférable.
Le Gartner conseille d’externaliser totalement la création graphique, le design Web et le développement HTML, d’externaliser partiellement l’administration système, l’administration de bases de données et le développement de composants applicatifs. Le Gartner conseille de ne pas externaliser l’analyse fonctionnelle et le contrôle qualité et déconseille formellement d’externaliser le webmastering et l’architecture.

La panoplie du parfait petit Zopeur

Voici les ressources nécessaires à tout développeur francophone qui veut se plonger dans la technologie Zope avec la meilleure efficacité :

Externaliser en offshore : l’Ile Maurice plutôt que l’Inde ?

La tentation de l’externalisation des développements Web spécifique vers l’Inde est forte : des coûts relativement bas, un système éducatif performant et une parfaite maîtrise de la langue anglaise, plus des expériences réussies de sociétés américaines. Pourtant, pour les sociétés francophones, l’Ile Maurice pourrait s’avérer être un meilleur choix. L’Ile Maurice offre en effet deux avantages de taille pour une meilleure coordination des projets : un bilinguisme (et bi-culturalisme) français et anglais, ainsi qu’une plus grande proximité dans les fuseaux horaires (deux heures de décalage avec Paris).

Innovation technologique au service du développement durable

Une technologie innovante n’est pas en soi favorable ou défavorable au développement durable. Par contre, le processus d’innovation peut l’être davantage. La plupart des technologies qui sont adoptées pour renforcer une démarche de développement durable dans l’entreprise sont des technologies dites « additives » : elles s’ajoutent à un procédé existant pour en limiter les effets néfastes sur l’environnement ou d’économiser la consommation de ressources (eau, énergie, …) par exemple. Cependant, les entreprises communiquant le plus sur le développement durable privilégient la promotion des technologies intégrées au cycle de vie de leurs procédés, i.e. intervenant dès l’amont, lors de la conception d’un produit.

Prestations de services pour les associations

Une petite exploration des prestataires de services ayant une offre spécifiquement dédiée au marché associatif :

Structuration du secteur associatif

Le Crédit Coopératif présente sa segmentation du marché associatif. Tout d’abord, figure le secteur sanitaire et social, organisé en unions ou fédérations (UNIOPSS, FEHAP, UNAPEI, APAJH, FNARS, CCOMCEN, UNASSAD, …) pour lesquelles le Crédit Coopératif offre un fonds de garantie mutuelle, des services télématiques et de télétransmission pour gérants de tutelle professionnels. Ensuite vient le secteur de l’enseignement privé (90% d’établissements catholiques) et de la formation (OPCA), pour lequel le Crédit Coopératif propose des services de facilitation du cycle de gestion et des financements d’investissements avec garanties, ainsi que des services de gestion de fonds et de trésorerie. Puis on trouve les organisme confessionnels (congrégations et leurs oeuvres par exemple) auxquels le Crédit Coopératif propose des placements solidaires ou éthiques. Viennent ensuite les clubs, ligues, comités et fédérations du sport pour lesquels il est nécessaire de financer certains équipements spécifiques. Les associations de solidarité internationale ont, quant à elles, des besoins de transferts de fonds internationaux. Les organismes de défense de l’environnement peuvent trouver un complément de financement par le biais de placements solidaires gérés par le Crédit Coopératif. Enfin, le secteur des loisirs et du tourisme associatif fait l’objet de prestations de financement de travaux (création d’établissements hôteliers).

Alternatives open source à MS Access

Il semblerait qu’il apparaisse enfin des alternatives open source à MS Access : Rekall (distribué sous licence GPL ici et lu et discuté sur Slashdot) mais aussi un module d’OpenOffice (il doit être bien caché car la dernière fois que j’ai rapidement testé OpenOffice, je ne l’ai pas trouvé). Tiens, tiens, amusant, le langage de script de Rekall est Python !
Pour mémoire, toujours en Python, les produits zetadb et Formulator, dans l’environnement Zope, pourraient bien servir à faire la même chose mais en version Web.

Logiciel pour le financement associatif

Le financement des organismes sans buts lucratif a ses spécificités et constitue un segment particulier pour les offres logicielles, au moins en Grande-Bretagne. Là-bas, le produit largement leader sur le marché s’appelle « Raiser’s Edge » de la société Blackbaud, avec une base installée de plus de 1000 clients. Ce type de logiciels permet d’accepter les dons en ligne avec une intégration complète dans le système de comptabilité de l’association. Un challenger est Visual Alms de Westwood Forster. Les autres grandes fonctionnalités des logiciels de ce type concernent la gestion des membres et des cotisations ainsi que des fonctionnalités plus « classiques » telles que la gestion de la paye, la gestion financière, budgétaire, etc.
D’après la base de connaissances de lasa.org.uk, une association qui a des besoins simples et cherche un système mono-utilisateur pourrait trouver son bonheur pour environ 500 euros ; pour 2 à 5 utilisateurs, les logiciels un peu plus pointus et basés sur un outil bureautique tel que Microsoft Access coûteraient de l’ordre de 10 000 euros et autant en coût d’implémentation et de formation ; pour des systèmes conçus pour 5 à 25 utilisateurs et s’appuyant sur un serveur de base de données, forcément, ça coûte plus cher…

EJB : ce qu’il ne faut pas faire avec

A l’occasion de la sortie du livre « Bitter EJB », Slashdot fait le point sur ce qu’il ne faut pas faire avec les EJB. Il est rappelé que « bien qu’outils incroyablement puissants entre les mains d’architectes expérimentés, les EJBs sont le sujet d’un grand nombre de mauvais emploi par les développeurs novices qui en font un usage inapproprié ». C’est souvent la complexité des EJB qui tourne les entreprises vers d’autres plate-formes applicatives. Encore une fois, il est rappelé qu’un fusil à éléphant n’est pas forcément l’armement adéquat pour se débarrasser d’une souris domestique.
Mais les remarques les plus intéressantes viennent, comme souvent, des lecteurs/commentateurs de Slashdot. Ceux-ci, dans leur majorité, sont perplexes devant les EJBs. Ainsi, l’un d’entre eux affirme : « La grande majorité des gens avec qui j’ai parlé semble montrer qu’ils n’ont jamais rencontré de projet de développement pour lesquels l’utilisation d’EJB n’aurait pas été totalement superflue et pour lesquels des solutions plus simples, plus faciles à maintenir et moins coûteuses n’a pas été finalement retenue. » Encore un développeur amer au sujet des EJB : « [Avec les EJBs,] il vous faut construire 10 systèmes qui ne marchent pas avant de pouvoir deviner comment en faire un qui fonctionne. Franchement, les EJBs ne m’ont pas l’air de valoir la peine qu’il faut pour les apprendre. » Un peu plus loin : « Si il y a bien une technologie qui est en risque d’extinction dans le monde Java, c’est bien les EJBs. Pratiquement tous les nouveaux projets J2EE dont j’entend parler se tiennent bien à l’écart des EJBs et adoptent des solutions plus simples du type servlet/JSP avec JDO pour la persistence. Ensuite vous distribuez le système horizontalement avec mod_jk ou un équilibreur de charge matériel… Vue leur complexité et la nature restrictive de leur API, je n’ai vraiment pas besoin de cette technologie. » Un autre s’interroge : « Les EJBs… semblent causer plus de problèmes qu’elles n’en résolvent… Pour quel type d’usage sont-elles réellement appropriées ? Je n’ai pas été capable de le deviner la dernière fois que j’ai travaillé en environnement J2EE. ».
Heureusement, au moins un développeur Java cite un cas d’utilisation appropriée pour cette technologie : « Je suis un architecte qui travaille sur une application d’entreprise de plusieurs millions de dollars et notre expérience avec les EJB a été jusqu’ici extrêmement positive. Nous nous sommes bien gardés d’adopter les ‘entity beans’ en nous contentant d’une couche JDO… Avec du matériel modeste, nous remplaçons de manière assez rentable l’application mainframe que nous réécrivons ainsi. » Et un autre de conclure : « Si vous n’avez pas besoin d’une isolation transactionnelle dans le cadre d’un système distribué, les EJBs sont superflues. »