Je vous propose ici un retour d’expérience pragmatique sur une utilisation de l’ESB qui sort des usages standardisés de simple médiation ou de réexposition de services.

Situation de l’enterprise :

L’entreprise est une grande compagnie dont le parc applicatif est très hétérogène : on y trouve une collection d’applications Mainframe qui compose le coeur de métier, des applications client-serveur, des applications web (et je ne m’étends pas sur les différentes technologies utilisées, les serveurs d’application, progiciels, etc).

La situation projet :

Le cœur de métier est éparpillé entre différents applicatifs qui ne communiquent pas entre eux. Or, dans le cadre de la création d’un nouveau poste de travail, il est nécessaire d’avoir une vision unifiée de tous les événements relatifs à un dossier client.

Afin de ne pas multiplier les appels vers les backend, principalement situés dans le Mainframe, pour aller récupérer ces événements, la création d’un dépôt central des événements a été décidée (je ne rentrerais pas ici dans le détail de ce système qui n’est pas l’objet de cet article).

Il faut ajouter à cela des besoins exprimés par d’autres applications d’exploiter ces mêmes événements en provenance des backends.

Ce dépôt d’événements doit bien entendu disposer de données de première fraicheur : la transmission des événements des backends doit donc se faire « au fil de l’eau ».

Une première idée :

L’entreprise dispose dans son catalogue applicatif d’une ESB embarquant un système JMS.
Une solution pouvait paraitre assez évidente au premier abord : le topic JMS ; chaque backend publie sur un topic ses événements puis chaque application consommatrice s’abonne au(x) topic(s) qui la concerne.

Problème : pour des questions de performances évaluées précédemment, utiliser les topics JMS est proscrit par la cellule architecture. Le timing du projet nous permettait difficilement de faire bouger les lignes sur ce sujet, et nous avons choisit de composer avec cette contrainte.

La solution développée :
Nous avons donc opté pour une solution basée sur des files JMS, et des composants développés dans l’ESB qui permettent de gérer le transit des messages entre les producteurs et les consommateurs d’événements.

Description des différents éléments du système :

• Le module d’entrée : Grâce à la connectivité de l’ESB, il a été très simple de créer deux canaux d’entrée : Un canal JMS et un canal web service SOAP. Ces deux points d’entrée permettent de faire transiter l’ensemble des événements, même si les structures XML des événements ne sont pas toujours les mêmes : une partie commune, l’entête technique est obligatoire (système d’origine, version de l’événement, etc), et la partie contenant les données métier de l’événement vient ensuite. Dans les XSD, cette partie métier est définie comme un CDATA (partie ignorée par les parseurs XML), ce qui permet d’y mettre n’importe quelle structure XML.

• Le module de validation : Comme décrit ci-dessus, le module d’entrée ne fait aucun contrôle sur les données métier de l’événement. Cette tâche est laissée au module de validation, qui à partir du numéro de version de l’événement détermine la XSD correspondante aux données métier de l’événement, et valide le format des données fournies. En cas de non-conformité, l’événement est mis de côté et l’origine de la non-conformité doit être déterminée manuellement par le backend émetteur.

• Le module de routage : Ce module se charge de vérifier les abonnements des applications consommatrices, et de router chaque événement vers les files JMS appropriées. Chaque application consommatrice dispose de sa propre file JMS.

Conclusion :

Au delà des aspects fonctionnels, deux points sont particulièrement importants :

• La performance : Suite à une campagne de test dans un environnement de préproduction, les temps varient entre 60 et 100 ms pour la transmission des messages entre le module d’entrée et la mise à disposition de celui-ci sur la/les files de sortie JMS. Ce temps est largement acceptable dans notre cadre d’informatique de gestion.

• Disponibilité : Tout le système de gestion des événements étant contenu dans l’ESB, la disponibilité du système repose entièrement sur celle de l’ESB. Celui-ci est en configuration haute disponibilité et satisfait l’exigence de disponibilité de la plateforme.

• PMO Projet
• PMO Support
• PMO Départemental
• PMO Stratégique

PMO Projet

Le PMO Projet a pour principale mission de maintenir le planning pour le compte de la direction de projet. Ce que je faisais par exemple sur un grand projet chez Digital Equipment Corp., avec Microsoft Project 95 (et oui, le temps passe !). Un chef de projet junior peut tenir ce rôle, et nous recevons de temps en temps des demandes de prestation dans ce sens. Le PMO fait chaque semaine le tour des équipes (voire plus souvent à certains moments du projet), pour collecter l’avancement et les restes à faire. Attention toutefois à ne pas interférer avec le rôle de chef de projet : le PMO alerte le chef de projet lorsqu’une tâche dérape, mais n’a en principe pas l’autorité pour challenger les restes à faire.

La charge de PMO au sein d’un projet dépend bien évidemment de la taille de l’équipe / des équipes, mais aussi de l’outillage disponible : maintenir un planning avec 40 personnes n’est pas la même chose si ces personnes utilisent ou non un outil de suivi des tâches lié à l’outil de planification… Une autre fonction généralement assignée au PMO au sein d’un projet est la collecte des indicateurs et la préparation des rapports de situation mais ce n’est pas le sujet de cet article.

PMO Support

Passons maintenant au PMO Support. Sa mission principale est de fournir aux projets les outils de pilotage, avec bien entendu le support et les formations nécessaires. Les outils de pilotage vont du simple outil de planification installé sur le poste de travail, aux solutions plus sophistiquées permettant de partager des pools de ressources et de planifier plus aisément des projets multi-entités / multi-sites. Le PMO Support peut avoir un rôle intéressant à jouer dans l’harmonisation des pratiques de pilotage de projet, en mettant à disposition des chefs de projets différents modèles, en fonction de l’outil retenu, comme par exemple des WBS (Work Breakdown Structure, en français Structure de Découpage de Projet) déclinées par cycles de vie, et des modèles de rapports d’avancement.

Au sein d’un très grand programme, le PMO Support peut jouer un rôle de coordinateur entre les différentes équipes : par exemple la construction d’un satellite de télécommunication, dans les années 90, a mobilisé plus de 1000 intervenants, avec un PMO de 40 personnes en charge de la planification globale du programme et du bon déroulement des réunions de coordination et d’avancement.

PMO Départemental

Le PMO Départemental est en charge du reporting au top management : il consolide les rapports de chaque projet pour en faire un rapport de synthèse. Au préalable, il faut avoir défini un modèle standard de rapport de projet, avec un ensemble d’indicateurs communs à tous les projets ; ces indicateurs peuvent être quantitatifs (tels que l’avancement calculé selon les règles de la valeur acquise) et / ou qualitatifs, selon le niveau de maturité de l’organisation. On y retrouve souvent un indicateur synthétique de santé du projet, sous forme de smileys, de feux tricolores ou de météos. Voici un exemple que j’avais proposé à l’un de mes clients :

Evidemment, il est nécessaire de définir les règles d’attribution des états, ainsi que la signification des flèches.

Le PMO Départemental doit mettre en évidence, dans son rapport de synthèse, les projets les plus risqués, qui méritent donc une attention particulière du management.

PMO Stratégique

Le PMO Stratégique couvre une autre dimension : le choix des projets ; son intervention se situe donc très en amont. En effet, les ressources dont disposent une DSI n’étant pas illimitées, il est fondamental pour la bonne marche d’une organisation de savoir identifier et prioriser les projets à lancer. Le PMO Stratégique va donc fournir au management l’outillage nécessaire pour gérer un portefeuille de projets. Selon la taille des organisations, cela peut aller d’un tableur un peu élaboré à un progiciel du marché perfectionné. Dans tous les cas, il est nécessaire de disposer de critères de choix à la fois quantitatifs (prix, charge, durée…) et qualitatifs (besoin métier important et urgent, exigence réglementaire, situation par rapport à la concurrence…). Le PMO Stratégique peut aussi apporter son expertise lors de la collecte des projets potentiels, et lors de l’arbitrage. Toutefois le choix des projets à lancer doit en dernier ressort incomber au management car c’est l’avenir de l’organisation qui est en jeu.

Les définitions étant posées, qu’en est-il dans la vraie vie ? Les 4 PMO évoqués ici ne doivent pas forcément être étanches. Dans une petite organisation, une structure de deux ou trois personnes peut être amenée à faire du support aux projets, du reporting au management, et du suivi du portefeuille des projets. J’y reviendrai dans un second article, où je détaillerai ce que nous avons mis en place dans une DSI d’une cinquantaine de personnes.

Les fonctionnalités des ESB peuvent être cataloguées en 3 classes distinctes. Initialement limitées à de la médiation technique entre un consommateur et un fournisseur de service qui communiquent dans des formats différents avec des protocoles différents à des cadences différentes, elles se sont progressivement étendues à l’orchestration de services de plusieurs fournisseurs au sein de processus métier décrits dans une notation standardisée (BPMN) exécutés dans un langage standardisé (BPEL). Arrivent aujourd’hui des fonctionnalités évoluées : elles déclenchent ou font progresser des processus grâce à des situations décrites dans un moteur de règles intégré ; elles tiennent des statistiques sur les processus exécutés pour en optimiser les étapes ; elles corrèlent des événements unitaires en événements complexes sur un laps de temps donné ; elles assurent la sécurité technique et / ou applicative des services. Sur l’ensemble de ces 3 classes, nous avons dénombré 18 types de fonctionnalités qu’il est pertinent d’étudier pour choisir un ESB : routage, transcodage, enrichissement, décomposition, agrégation, temporisation, conversion, adaptateur, abonnement, sécurité, monitoring, monitoring métier, qualité de service, processus techniques et métiers, contexte, règles, événements complexes, gouvernance. Au vue de ces possibilités, l’ESB devient une passerelle technico fonctionnelle qui maximise les traitements sur les flux en minimisant les temps de latence et ainsi cannibalise progressivement des outils amont ou aval qui ajoutent un hop supplémentaire. Le nouveau créneau des boitiers ESB témoigne de cette volonté hégémonique de faire toujours plus de traitements en toujours moins de temps.

Compétence et gouvernance

A la différence d’une brique d’infrastructure telle un serveur d’application dans lequel sont simplement installées des applications développées en mode projet, l’ESB demande une compétence et une gouvernance spécifiques pour coordonner de façon transverse les services et les processus qui s’y exécutent ou y transitent. Une équipe ESB peut être en charge de développer un « framework » :

• Pour offrir des modes de médiation génériques (asynchrone, sécurisé, caché, audité, rejoué, routé, surveillé, capé…) mis à disposition sous forme de politiques d’accès, en recouvrement ou en extension des normes WS-*. Si les modes génériques ne suffisent pas, un projet peut demander à l’équipe d’en créer des spécifiques,
• Pour supporter des fonctionnalités d’orchestration basiques, comme des sous-processus pour attendre un événement avec timeout et relance, pour gérer les exceptions par appel aux opérations de compensation associées, pour invoquer un moteur de règles qui affecte une tâche à un utilisateur dont l’agenda est libre…,
• Pour assurer l’interopérabilité des services, en imposant des contraintes au-delà du BP 1.1, comme un entête SOAP avec le code des applications communicantes, la remonté d’exceptions normalisées des implémentations de service, la fourniture obligatoire d’opérations de compensation sur les opérations non transactionnelles…

Au-delà du framework, l’équipe peut également édicter des bonnes pratiques SOA comme :

• privilégier les appels asynchrones pour une meilleure tolérance aux fluctuations de performances et aux pannes,
• privilégier des transformations portables avec des standards XSLT, XPATH, XQUERY sur des mappings configurés dans l’ESB,
• obliger à publier les services dans un registre de conception au travers d’un workflow ou des acteurs techniques et métier valident techniquement et fonctionnellement les services.

Ce mode de gouvernance de l’ESB est alors principalement centralisé. On peut opter pour un mode plus décentralisé dans lequel les équipes projet ont des droits et des compétences pour définir des politiques, des sous-processus réutilisables, a minima les transformations…

Retour sur investissement

L’ESB n’est absolument pas nécessaire à une bonne SOA : il est un accélérateur potentiel mais dont on peut se passer techniquement et « méthodologiquement ». Il faut donc très tôt mettre en rapport ses produits potentiels avec ses charges certaines. Les gains ou les pertes d’un ESB sont principalement dépendantes de la capacité à le mutualiser pour un programme ou une société pour faire des gains d’échelle en qualité et en gouvernance sur le nombre de services à interconnecter et de processus à développer. L’idée directrice d’un ROI positif doit être « plus on a de services, plus on a de gains ». Les sections suivantes proposent des éléments pour estimer ce rapport.

Charges : le TOC

Le TCO significatif d’un ESB est le fait de plusieurs contraintes :

• Infrastructure : en tant que nœud central de la SOA, l’ESB constitue un point de panne unique qui impose son hébergement sur une infrastructure dédiée, performante et en très haute disponibilité.
• Framework : un ESB est livré vide. Il est du ressort d’une équipe ESB transverse de monter en compétence pour s’approprier le « langage » de l’ESB voire de définir un framework pour offrir des politiques de communication asynchrone, sécurisées, avec gestion de cache, de transformation…
• Licences : ses fonctionnalités allant de la simple médiation technique, l’orchestration de services métier jusqu’à des fonctions évoluées de corrélation d’événements, le coût d’une licence pour des produits commerciaux se chiffre en centaines de KE. A la licence socle s’ajoutent souvent des licences pour des fonctions ou connecteurs spécifiques.
• Support : les compétences de développement et d’administration d’un ESB sont spécifiques et donc plus couteuses qu’un simple développement Java ou de l’administration système.

L’infrastructure et le framework sont des investissements. Les licences et le support sont des coûts souvent récurrents à l’année.

Produits : le facteur accélerateur

Le facteur accélérateur de l’ESB se trouve dans son support au cycle de vie des services et processus, en particulier dans les phases de conception, développement, maintenance et dans la gouvernance en général. Pour le quantifier, nous proposons un facteur d’accélération pour chacun des 18 types de fonctionnalités répertoriés, estimé sur une échelle de 1 à 3,  un nombre de jours de réalisation sans ESB, pondérés par une importance, à fixer selon le contexte projet.

Variables du calcul

En complément des facteurs d’accélération et des jours de réalisation, il est pertinent d’estimer le pourcentage de services et de processus qui vont utiliser telles ou telles fonctionnalités de l’ESB. Les estimations de ces pourcentages proviennent idéalement d’une étude des besoins qui aboutit en synthèse aux nombres d’occurrence de telle ou telle fonctionnalité. Les variables majeures au retour sur investissement restent le cout de la licence socle et le nombre de services et processus.

Equilibre financier

Pour arriver à l’équilibre financier, 2 situations s’opposent aux extrêmes : un cout de licence faible et un nombre de services et processus faible vs. un cout de licence élevé et un nombre de services et processus élevé. Dans les 2 situations par contre, les gains en délai sont conséquents. Dès lors que l’on définit une gouvernance et qu’elle est supportée par un framework, des workflows et des développements autour de l’ESB, les gains d’échelle sont en théorie au rendez-vous.

Eléments pour le choix

Critères d’évaluation

La grille d’évaluation de la capacité d’un ESB à couvrir les 18 types de fonctionnalités que nous avons répertoriées se décline en 13 axes allant des aspects techniques (médiation, industrialisation…) jusqu’aux aspects commerciaux (support, licence…).  Chaque axe comporte entre 2 et 15 critères. Ces critères peuvent être pondérés selon une importance établie par une analyse des besoins. La notation d’un critère se fait sur une échelle discrète de 0 à 5 : 0 indique que la fonction n’est pas couverte, 5 qu’elle l’est selon « les attentes » de l’étude. La note globale se calcule selon les notations et pondérations associées à chaque critère. Le tableau ci-après liste propose 13 axes d’évaluation à utiliser pour classer les produits.

Fin des années 2000, le moteur de règles revient à la mode, sous l’acronyme BRMS (Business Rules Management System). Il est commercialisé seul ou packagé à des solutions ESB (Enterprise Service Bus) et / ou BPM (Business Process Management). On l’invoque si besoin pour retourner le résultat d’un calcul « complexe » (tarification, commissionnement… financier la plupart du temps). Il sert en mode « calculette » : des paramètres d’entrée et un paramètre de sortie. On l’enrobe avec de la verbalisation pour que les utilisateurs formalisent et exécutent les règles avec plus de confort : « au moins 1 contrat du client » remplace le cryptique « client.contrats.size >= 1 ». La verbalisation est internationalisée. Si nécessaire, on appelle le moteur plusieurs fois dans un flux potentiellement conditionnel : « si client.fidélité >= ‘gold’ alors invoquer_règle(tapis rouge) ». On appelle une base de données ou un Web Service pour compléter les faits à analyser. Le moteur est embarqué dans une application ou un ESB, ou appelé en Web Service depuis une application ou une étape de processus. Mais de central, le moteur de règles est devenu annexe. Une toute dernière tendance pourrait lui redonner le rôle central d’autrefois : le CEP (Complex Event Processing), qui vise à corréler des événements dans un laps de temps.

En 20 ans, le positionnement d’un moteur de règles dans le SI n’est pas passé de central à annexe voire central à nouveau uniquement pour des raisons de mode ou de commerce. Fin des années 80, bien que les règles aient le vent en poupe, la complexité d’écrire un ensemble cohérent reste aux mains de profils technico fonctionnels très isolés. Ces profils disparaissent et la discipline n’évolue plus depuis. Début des années 2010, cette complexité se retrouve. Elle est même accrue par la complexité de « synchroniser » le contexte du moteur de règles avec l’état des applications dont il dépend et qu’il alimente. Nouveau challenge dans lequel malheureusement peu de travaux théoriques et métodologiques viennent proposer des bonnes pratiques et où seuls les éditeurs avancent leurs pions sans savoir plus que nous les intégrateurs à quel jeu ils jouent !

État des lieux

Je n’ai pas encore trouvé d’entreprise (de taille moyenne à grande) qui ne possède que des applications de même technologie, comme par exemple des applications Web JEE développées en interne. Bien souvent, ces entreprises ont aussi des progiciels, qui viennent avec leur propre référentiel de données et leur propre politique de mots de passe. Pour les plus grandes, elles ont aussi des applications qui s’exécutent sur des serveurs à hautes capacité en termes de nombre de processeurs et de taille de mémoire : comme le système d’exploitation z/OS et son référentiel de sécurité RACF. Bien qu’évoluant régulièrement, z+RACF est d’une technologie et d’une philosophie différente des serveurs Windows+AD ou encore des serveurs Linux+LDAP.

Aujourd’hui, les Politiques de Sécurité des Systèmes d’Information (PSSI), recommandent l’utilisation de mots de passe complexes, avec des longueurs minimales et des durées de vies raccourcies. On veut croire (vœux pieux) que les progiciels sont suffisamment bien développés pour s’accorder sur ce point et respecter les recommandations des PSSI. Mais en ce qui concerne RACF, le champ mot de passe historique (PASSWORD) ne supporte pas la complexité imposée ni une longueur supérieure à 8 caractères. IBM propose l’utilisation d’un autre champ (PASSPHRASE) qui ne peut être adopté sans envisager un chantier de migration des formulaires d’authentification des pages Web mais aussi des mires TN 3270, CICS et TSO.

Une multitude de mots de passe

Sans unification totale des politiques de mots de passe de tous les systèmes de l’entreprise et sans SSO, nous pouvons aisément affirmer que les utilisateurs doivent retenir plusieurs mots de passe pour pouvoir s’authentifier sur chacune des applications auxquelles ils doivent accéder.

Chaque fois qu’un mot de passe doit être renouvelé, l’utilisateur est obligé d’en retenir un nouveau. Si, le premier jour où il arrive dans l’entreprise, il saisit le même mot de passe pour la plus part des systèmes, au bout de quelques mois, il devra en retenir 2 ou 3 voire n différents. Cela peut être dû au fait que, par exemple, certaines directions de l’entreprise définissent pour des systèmes sensibles un renouvellement tous les 45 jours alors que pour d’autres un renouvellement supérieur à 3 mois est suffisant.

Autre point important, sur un système comme RACF, et ce n’est pas le seul, la politique de mot de passe est insuffisante car elle n’autorise que 8 caractères, dont des lettres, des chiffres et ces trois caractères spéciaux : $, @, #.

Le coût du service Support

À force de devoir retenir plusieurs mots de passe, nous finissons par en oublier, voire tous les oublier (surtout, et c’est très fréquent, après quatre semaines de congés).

L’employé dans ce cas, se retrouve devant son ordinateur avec l’incapacité de se souvenir du mot de passe de session du poste de travail. Il regarde sous le clavier, derrière l’écran, mais le ménage a été fait et tous les post’its, sur lesquels il avait soigneusement écrit ses multiples mots de passe, ont disparu. Il aurait du écrire ses mots de passe sur une feuille qu’il aurait du ranger dans son tiroir, mais il a aussi égaré ses clés.

La seule solution est d’appeler le service Support de l’entreprise. Cela se passe en une succession d’étapes :

•  Recherche : l’employé recherche le numéro de téléphone du service Support, premièrement dans sa mémoire, puis en demandant à un collègue et finit par se déplacer pour demander à la secrétaire. Le temps varie de 5 à 20 minutes.
•  Attente : comme on est lundi matin, le service support ne décroche qu’après 10 à 15 minutes d’attente (d’autres on été plus rapide à appeler le service).
•  Identification : le service support demande à l’employé de s’identifier, avec le fameux identifiant unique, oublié par l’employé ; le service support finit par le retrouver grâce aux nom et prénom de l’employé. Le temps peut être assez court, de l’ordre de 1 à 3 minutes.
•  Authentification : Le service support ne peut et ne doit pas engager de procédure de remplacement de mot de passe sans avoir la certitude que celui qui en fait la demande est bien celui qui a perdu son propre mot de passe. Suivant les règles en la matière, l’authentification peut demander un temps important, si l’employé doit se déplacer ou si le service support doit contacter le manager ou un responsable ou un collègue pour s’assurer que la personne qui demande le renouvellement soit bien l’employée qu’elle dit être. Le temps peut varier de 5 à 30 minutes, voire même plus selon la disponibilité des personnes à contacter.
•  Traitement : Le service support engage la procédure de renouvellement. Le traitement peut durer 10 minutes sans considérer les processus de provisioning.
•  Gestion : la procédure de renouvellement par le service support implique que les actions soient journalisées par un principe de création de ticket. Le temps peut aussi être très court, de l’ordre de 2 à 3 minutes.

Au final, l’employé a ainsi pu renouveler son mot de passe en faisant perdre à l’entreprise, et à plusieurs employés, un peu plus d’une heure ?

Le self-service : une solution ?

Ce temps est précieux pour l’entreprise, sachant que plus grande est l’entreprise, plus les demandes de renouvellement au service support sont fréquentes. Donc plus important devient le coût de traitement de ces demandes. Ce temps de perdu est surtout inutile et sans aucune valeur métier.

Une solution alternative serait de mettre en place une solution de self-service : une solution avec laquelle l’employé se débrouille seul pour réinitialiser ses mots de passe et ne fait plus perdre de temps aux autres. Une solution qui n’enlève aucun savoir métier aux employés.

Cette solution passe par une phase d’apprentissage qui permet à chaque utilisateur de remplir un questionnaire personnel pour qu’il puisse être identifié et reconnu lorsqu’il en aura l’utilité.

Intrusion dans la vie privée : les QR

Les premières solutions disposaient d’une liste de questions prédéfinies auxquelles l’utilisateur devait répondre. Ces questions étaient simples et génériques pour que chacun puisse trouver une réponse. Par exemple « quel est le nom de jeune fille de votre mère ? ». Or la réponse à ce genre de question s’obtient sans trop de peine, sans vouloir apporter dans ce billet la méthode pour la trouver. De plus, ces questions étaient souvent trop personnelles et certains voient par là une intrusion dans leur vie privée.

Les solutions plus récentes ont une liste plus importante de questions, qui sont beaucoup plus neutres, et ne sont pas toutes proposées à tous les utilisateurs. La probabilité que 2 employés se voient proposer les mêmes questions est très faible.

Pour rendre le système encore plus sécurisé, une dernière question pourrait proposer à l’utilisateur de faire un calcul par exemple, comme additionner les années de naissance de ses enfants ou animaux de compagnies, ou…

Les solutions pour sécuriser le self-service sont multiples et infinies, ce qui rend ce système très intéressant et offre une véritable alternative au service support.

Conclusion

Encore dernièrement, j’ai été confronté au service support d’une entreprise très compétitive dans le domaine de l’industrie. J’ai perdu mon temps pendant plus d’une heure au téléphone, j’ai fait perdre son temps à une collègue pour utiliser sa messagerie et au final, le service rendu n’est pas à la hauteur parce que je n’ai toujours pas accès à ma messagerie.

Je me serais contenté d’un lien dans le portail intranet pour me rendre sur l’application de self-service et pour réinitialiser mon mot de passe en moins de 10 minutes.

Si le service support apporte la dimension humaine, il n’apporte pas toujours satisfaction. Une solution purement numérique n’est pas aussi chaleureuse mais peut, dans de nombreux cas, rendre au moins le même service.

Thierry ALBAIN

Afin de bien comprendre son utilité, partons du modèle d’habilitation IBAC (Identity Based Access Control) qui est moins évolué mais dont RBAC tire son origine.

Le modèle IBAC

Ce modèle est le plus simple et reste adapté lorsque, dans le SI, le nombre d’utilisateurs en fonction des ressources à protéger est très faible.

À chaque utilisateur, il permet de définir des droits d’accès aux ressources du SI, en lecture et en écriture.

Alors que le modèle IBAC ne permet de donner des droits qu’à l’utilisateur, représenté par son compte applicatif, le modèle RBAC s’intéresse d’abord à regrouper les utilisateurs en fonction d’attributs communs.

La gestion des rôles

Il existe différentes approches pour attribuer des rôles aux utilisateurs d’un SI.

La première approche s’attache à identifier les attributs communs des utilisateurs qui accèdent aux mêmes ressources pour en définir les rôles qui correspondent aux droits de ces utilisateurs, souvent à partir de leur fonction ou de leur profil métier.

La seconde approche permet de faire le travail inverse. Il s’agit d’identifier les ressources qui sont associées simultanément, les regrouper afin d’en définir un rôle, pour l’assigner aux utilisateurs qui ont accès à ces mêmes ressources.

La dernière approche est beaucoup plus empirique car elle s’intéresse d’abord à demander aux responsables d’identifier, parmi leurs subordonnés, ceux qui font le même travail. L’étape suivante consiste à vérifier que ces utilisateurs ont les mêmes privilèges et enfin, si c’est le cas, définir un rôle à assigner à ce groupe d’utilisateurs.

Le modèle RBAC

Comme son nom l’indique, le modèle RBAC est construit autour des rôles. Ou plus exactement, les rôles représentent le lien entre les utilisateurs et les ressources.

Dans certains cas, les rôles vont prendre le nom des différents métiers de l’entreprise, tels que comptable, commercial ou ressource humaine, … Dans d’autres cas, les rôles vont plutôt représenter des activités ou des projets en cours d’élaboration. Ils peuvent aussi représenter des personnes physiques comme les agents, les prestataires, les partenaires ou les clients qui, de par leur fonction au sein de l’entreprise, exercent une activité ayant vocation à leur permettre de bénéficier des applications et des ressources mises à disposition par cette même entreprise.

Il n’existe pas de définition générique d’un modèle de droit (basé sur les rôles) qu’une entreprise pourrait utiliser. Le modèle RBAC reste théorique et demande une étude approfondie sur le SI et ses utilisateurs avant de l’exploiter.

Nous voyons fréquemment plusieurs types de rôles dans les entreprises :

• Les rôles utilisateurs ou les profils, représentés par les métiers de l’entreprise par exemple
• Les rôles applicatifs qui déterminent la fonction que l’utilisateur pourra jouer sur le SI pour une application donnée (interrogation du solde, mise à jour des adresses, création de contrats, …)
• Les hiérarchies de rôles qui permettent d’organiser des rôles, définis finement, en rôles plus globaux

Par exemple, un utilisateur qui a le profil commercial et le rôle applicatif « création de contrats » a le droit de créer des contrats pour ses clients. Mais, ce commercial, dans une entreprise implantée dans plusieurs régions, n’aura pas ce droit sur un client qui n’est pas dans son secteur.

Extension du modèle RBAC

Le modèle RBAC atteint rapidement ses limites dès lors que les utilisateurs sont géographiquement différentiables, ou dès lors que l’entreprise est composée de services indépendants.

Par exemple, dans une société de services, les commerciaux sont attachés à des secteurs d’activités : un commercial chargé des affaires de l’industrie ne peut pas créer de contrat pour un client dans le secteur de la banque.

Autre exemple, un conseiller clientèle d’une banque dispose des droits de gestion de patrimoine et de gestion immobilière. Selon l’agence dans laquelle il travaille, il peut soit faire de la gestion de patrimoine soit de la gestion immobilière, soit les deux. Pour lui fournir un poste de travail adapté à ses attributions en fonction de l’agence dans laquelle il travaille, ses droits doivent être comparés aux possibilités offertes par ces agences. Ainsi, même s’il est conseiller en gestion de patrimoine et en gestion immobilière, dans une première agence il disposera d’un poste de travail restreint à la fonction de gestion immobilière – l’agent ne fera que de la gestion immobilière. Dans une autre agence il n’aura que celle de gestion de patrimoine – l’agent ne fera que de la gestion de patrimoine. Enfin, dans une troisième agence, son poste de travail lui proposera les deux fonctionnalités – l’agent pourra faire de la gestion de patrimoine ainsi que de la gestion immobilière.

Pour palier à cette limitation, nous voyons souvent apparaître la notion de groupe en plus de celle de rôle ou de profil. C’est ce qu’on appelle le RBAC étendu.

La gestion des rôles dans une telle organisation va s’intéresser à :

• Associer des profils, voire des profils de profils, aux utilisateurs
• Associer des rôles, voire des rôles de rôles, aux applications
• Différentier les utilisateurs et les applications en fonction de critères tels que la géographie ou encore le secteur d’activité

Cette extension du modèle RBAC porte le nom de modèle RBAC étendu.

Ce modèle est suffisant pour la plus part des entreprises, mais reste encore nettement insuffisant dans des contextes de travail comme les hôpitaux.

Le modèle ORBAC

Dans un hôpital, un médecin n’est pas présent 24 heures sur 24 pour traiter chacun de ses patients. Pendant ses jours de repos, ses tâches sont assurées par un autre médecin, voire un troisième selon l’organisation en équipe mise au point dans son service. De même, l’équipe infirmière et aide-soignante qui travaille avec lui un jour n’est pas certaine de travailler avec lui le jour d’après, simplement parce qu’il n’est pas toujours possible de gérer chaque personnel médical en fonction d’un médecin, de ses jours de repos et de ses vacances.

L’organisation hospitalière implique donc que l’affectation des droits d’accès aux dossiers médicaux des patients, pour les médecins, les infirmiers et les aides-soignants soit malléable en fonction des jours, et des heures et même des services (chirurgie, urgences, pédiatrie, …).

Voici un exemple de modèle ORBAC, d’après Saidani et Nurcan, qui représente les contraintes contextuelles d’attribution des droits :

Dans ce schéma, l’auteur représente des contraintes externes qui permettent d’étendre le modèle RBAC pour limiter les droits des utilisateurs.

Conclusion

Le modèle RBAC, dans sa forme la plus simple ou la plus complexe, est devenu le modèle de gestion des habilitations le plus employé. Il permet, quand il est compris et maitrisé, d’augmenter la performance opérationnelle d’attribution des droits aux utilisateurs et apporte ainsi une réduction conséquente de coût sur la gestion des identités de l’entreprise.

Thierry ALBAIN

Les valeurs de l’agile suscitent de l’intérêt, notamment “l’empowerement” de l’équipe, la confiance en les personnes. Avec un petit recul, car c’est un changement de culture tant pour les équipes que pour le management.

Sur le déploiement agile (le fait de conduire le changement lui même sur un mode agile) l’idée d’appliquer la pratique des Démos au déploiement a beaucoup intéressé. Et avec elle, la pratique connexe : prendre en compte le changement si d’aventure les solutions déployées s’avèrent pouvoir être remplacées par d’autres plus immédiatement applicables ou porteuses de gains.

La complémentarité CMMI / Scrum n’a pas soulevée de questions précises : la chose paraissait claire ou acquise…

Cet après midi, nous étions présent au salon Solutions Bancaires avec Fabrice Offret et les représentants de Clear2Pay. La présentation portait sur l’agilité dans les grandes lignes : valeurs, avec un focus sur Scrum. Puis Clear2Pay (éditeur de solutions bancaires) a présenté son produit en expliquant comment tirer profit de l’agilité dans un projet d’implémentation de son framework.

Bon accueil également de ces notions, avec une question sur l’applicabilité de Scrum a de plus grosses équipes (Scrum de scrums).

A noter : tous les orateurs évoquent l’agilité de leur approche IT, mais sans jamais la développer.

Ce livre s’adresse aux directeurs informatiques, aux responsables des études, aux architectes, aux responsables de la production, aux chefs de projets et aux consultants.

Rares sont les ouvrages qui abordent l’efficacité des systèmes d’information sous l’angle technologique, c’est-à-dire en termes d’infrastructures, d’architectures ou d’outils. C’est ce que fait cet ouvrage en abordant méthodiquement les questions délicates sur le rôle du système d’information dans la performance de l’entreprise.

• La première partie introduit les concepts fondamentaux de la performance (temps de réponse, montée en charge, robustesse…) et les problématiques auxquelles sont confrontées aujourd’hui les équipes de la DSI.
• La deuxième partie souligne l’importance de l’architecture dans la performance et la robustesse des applications du SI.
• La troisième partie traite des infrastructures matérielles (réseaux, stockage…) et logicielles (applications, bases de données…), qui jouent un rôle clé dans le niveau de performance.
• La quatrième partie fournit des bonnes pratiques immédiatement utilisables, regroupées par thèmes avec les techniques de programmation, les tests de performance, la gestion de la production et les pratiques de gestion de projet.

Cette deuxième édition s’enrichit de mises à jour sur la continuité de service, les datacenters ou encore la gestion de la production.

Ces nouveaux chapitres s’attachent plus particulièrement aux aspects organisationnels.

Sommaire

La nécessité d’un SI performant. Problématiques de performance des SI. Les fondamentaux de la performance. L’organisation de la performance. Contractualiser la performance. Performance et architecture d’entreprise. Les enjeux architecturaux de la performance. Performances des services d’une SOA. Robustesse et performance d’un processus métier. Performance d’une solution métier. Optimiser les infrastructures. Les Datacenter. Les réseaux. Le stockage. Le clustering. Les bases de données. Les serveurs d’application. Les bonnes pratiques. Les tests de performance. La gestion de la production. La gestion de projet.

Il expose notre vision des complémentarités utiles et nécessaire entre l’agilité (Scum, XP, Kanban) et CMMI.

Utiles et nécessaires si on veut agiliser l’organisation, et non seulement une ou deux équipes projets.

Alcyonix-AgileTour2010-CMMIetAgile-v1.1-FR

Cette approche tayloriste s’est finalement émoussée au contact de contraintes de terrain qui ont globalement restreint son applicabilité à des processus d’entreprise de périmètres simples, étroits et spécialisés à l’opposé de ses prétentions initiales de portée complexe et transverse. Ces contraintes sont tout à la fois culturelles (savoir oral vs. écrit…), organisationnelles (concentration du savoir en quelques experts vs. démultiplication en une armée de « sachants »…), techniques (existant applicatif inflexible vs. SOA…), stratégiques (revalorisation de l’existant applicatif vs. investissement en refonte …) et forcent les programmes d’amélioration des processus métier à plus de modestie et de pragmatisme. De cet échec d’un BPM trop normatif a même émergé (ou ressuscité) un nouveau paradigme – l’Adaptive Case Management (ACM = gestion adaptive d’activité) – dans lequel l’humain reprend un rôle prépondérant en terme de « comment et quand » faire ses activités et où le SI se limite à proposer des activités à faire et d’en suivre et piloter la réalisation. La frontière n’en est pas devenue pour autant limpide entre ce que sait faire le SI et ce que sait faire l’humain mais ce paradigme de BPM « passif » reconnait au moins l’inadéquation du BPM « actif » à supporter des processus métier complexes et transverses.

Retour d’expérience : ACM né du contexte

Nous avons vécu ce changement d’approche au cours d’une mission pour laquelle nous avons participé à l’amélioration d’un sous ensemble des processus cœur de métier de l’entreprise. Notre première réponse a été classique : un BPM « actif » qui identifie, modélise et exécute les processus dans un moteur d’exécution de processus doit aboutir à l’objectif fixé : plus de clients servis en moins de jours. Cette approche a été immédiatement remise en cause pour des raisons d’au moins trois ordres :

• Culturelles : l’expertise est plus humaine plus qu’informatique. La connaissance s’enracine dans des experts qui savent appréhender les détails des cas les plus complexes,
• Techniques : le SI présente des applications cœur de métier dont les écrans et les traitements contiennent déjà des fragments de processus qu’il est inutile d’externaliser pour les porter dans une technologie BPM. Le SI est par ailleurs très peu orienté service,
• Stratégiques : les sponsors sont intéressés avant tout par la gestion d’activité  (Business Activity Monitoring (BAM) = quelles activités, faites par qui, à quels moments, en quels nombres, avec quels reste à faire sur le processus global…)) plutôt que par les activités elles-mêmes (comment se fait telle ou telle activité à l’intérieur des applications cœur de métier existantes).

Ce besoin de flexibilité dans le déroulement des processus métier nous a conduits à créer une architecture sur mesure dans laquelle des événements de rupture d’activité (réclamation client enregistrée…), des règles d’enchainement d’activité (après l’ouverture, missionner un expert si…), des fragments de processus techniques (relance de document par email au bot de 5 jours…) et fonctionnels (indemniser le client par virement et l’informer par courrier…) viennent compléter les applications existantes pour assurer l’instruction d’un dossier de prise en compte de réclamation.

Architecture applicative : un moteur BPM asservi

L’architecture proposée comporte 6 blocs applicatifs majeurs, chacun de périmètre fonctionnel complémentaire :

• Les applications (cœur de métier, messagerie, GED…) sont pleinement réutilisées et gardent les règles de présentation et métier de chacun des actes de gestion (ouverture de réclamation, missionnement d’expert, règlement de client…) et de contact (demande / réception de document au / du client…). Elles sont modifiées pour publier un événement technique dûment caractérisé lorsqu’un acte est terminé, qu’il ait été exécuté sous le contrôle de l’utilisateur ou de l’exécuteur de processus,
• Un coordinateur d’événements est placé en abonné des événements publiés par les applications. Un événement non associé à un dossier donne lieu à la création d’un nouveau dossier. Chaque événement est ajouté à son dossier pour audit, puis transmis à l’exécuteur de processus pour éventuellement réveiller un fragment de processus (demande / réception de document…). Il alimente enfin un exécuteur de règles pour éventuellement proposer à l’utilisateur un ou plusieurs fragments de processus à créer,
• Un exécuteur de règles (EdR) d’enchainement de fragments de processus. A partir d’un événement et du dossier associé, il suggère à l’utilisateur des fragments de processus pour continuer l’instruction du dossier (processus de missionnement d’un expert à la suite d’un événement de création d’une réclamation…). Le paramétrage de ces règles est à la main du métier pour assurer une souplesse dans la démarche,
• Un exécuteur de processus (EdP) qui instancie et exécute des fragments de processus suggérés par l’EdR et choisis par l’utilisateur. Les fragments de processus matérialisent soit des actes isolés (régler), soit des actes techniquement liés (missionnement expert suivi de demande, relance et réception de documents), soit des actes fonctionnellement liés (missionnement expert suivi de règlement client pour un dossier avec un montant faible). Dans ce dernier cas, des transitions complexes peuvent être déterminées par l’EdR pour passer d’une étape du processus à une autre.
• Un exécuteur de tâche (EdT) qui crée une tâche dans le contexte d’un fragment de processus ou hors processus (flexibilité de l’approche qui permet dynamiquement d’ajouter des tâches pour un dossier). Cette tâche représente un acte à effectuer manuellement dans une application. Elle est attribuée à une corbeille. Le statut de cette tâche suit un cycle de vie que l’utilisateur ou le moteur de règle font évoluer de « à traiter », à « en exécution », puis à « traitée ».
• Un portail qui permet aux utilisateurs habilités de consulter les dossiers avec les objets métier, les tâches et les événements qui les composent. Depuis ce portail, les utilisateurs ont accès à la liste des tâches des corbeilles auxquelles ils sont affectés. L’exécution d’une tâche correspond à une prise en traitement (réservation), à un débranchement sur l’écran pré-rempli des informations du dossier dans l’application associée et à une clôture automatique ou manuelle.

Flexibilité de la solution

Dans cette architecture, les processus métier tirent leur flexibilité d’une plus grande implication de l’utilisateur qui peut à tout moment aménager le déroulement d’un processus existant en ajoutant des tâches non prévues dans la gestion du dossier ou activer les règles d’enchainement d’activité pour choisir une activité suivante. La flexibilité est aussi apportée par la non nécessité de prévoir d’entrée l’exhaustivité des situations et les processus de bout en bout. Le métier peut ainsi progressivement améliorer en plusieurs itérations les fragments de processus tout en sachant que l’utilisateur peut toujours intervenir pour débloquer ou poursuivre dans des cas non anticipés.

La norme décrit les échanges entre le Service Provider (SP), qui protège les services, le Discovery Service (DS) qui permet à l’utilisateur d’indiquer son fournisseur d’identités et l’Identity Provider (IdP), qui assure l’authentification des utilisateurs.

Au sein d’une même entreprise, le déploiement d’une telle solution est comparable aux solutions de SSO standard, avec toutefois des avantages non négligeables.

Standard et souplesse d’intégration

Shibboleth n’est conçu que sur des standards reconnus et normalisés :

• XML pour les fichiers de configuration et les échanges entre les composants IdP, SP et DS
• SOAP pour l’enveloppe des assertions SAML
• WS-Signature pour la signature des assertions SAML
• WS-Encryption pour le chiffrement des assertions SAML
• SAML 2.0 pour le respect des profils de fédération d’identité
• LDAP/SQL pour l’accès aux référentiels d’identités et d’habilitations
• Redirections http pour la compatibilité avec les navigateurs du marché

L’IdP et le DS sont deux applications Java qui s’installent dans tous les serveurs d’applications Java du marché et de l’open source.

Le SP est composé d’une part d’un filtre serveur Web dont des versions compilées existent pour Apache et IIS et d’autre part d’un service autonome qui s’installe aussi bien sous Windows que sous Linux.

Bien que Shibboleth soit limité en fonctionnalité d’authentification, il est tout à fait envisageable de développer ses propres servlets d’authentification. Il est également possible de déléguer, assez facilement, l’authentification au célèbre outil de SSO, CAS (Central Authentication Service http://www.jasig.org/cas). Il permet les authentifications Active Directory, JAAS, JDBC, LDAP, Legacy, RADIUS, SPNEGO, Trusted et par certificats X.509.

Sécurité renforcée

Il est remarquable de constater que dans l’acronyme SSO, qui correspond à Single-Sign On, il n’y ait aucun « S » qui signifie « sécurité ». Or, avec Shibboleth, réduit à une simple fonctionnalité de SSO, la sécurité est belle et bien présente :

• L’authentification utilisateur, peut être renforcée, par l’usage de certificats X.509 clients, par exemple en connectant CAS à Shibboleth.
• Les SP importent les certificats serveurs des IdP qu’ils autorisent à leur fournir une authentification utilisateur. Ainsi, le cercle de confiance est bien défini et sécurisé : Les SP n’acceptent pas de n’importe quel IdP une authentification utilisateur.
• Les IdP peuvent aussi importer les certificats des SP. Ainsi, seuls les SP autorisés peuvent demander une authentification utilisateur.
• Les assertions sont chiffrées par des clés asymétriques (cf. WS-Encryption).
• Les assertions sont signées par les certificats serveurs, des IdP pour les SP et des SP pour les IdP (cf. WS-Signature).
• Chaque donnée d’utilisateur dans les assertions à destination des SP peut être chiffrée et signée, indépendamment de l’assertion, par le certificat serveur de l’IdP.
• Des mécanismes peuvent être configurés dans le but de présenter à l’utilisateur l’ensemble des données le concernant à destination du SP, pour validation, avant que l’IdP ne les transmette. Ainsi, l’utilisateur est maître des données le concernant qu’il veut transmettre aux services distants.

Atoûts

La plus part des solutions de SSO web se limitent à l’authentification des utilisateurs ; elles ne traitent pas des besoins liés aux autorisations (droits applicatifs) ni au transport d’attributs. En outre, leur base d’authentification est locale, au niveau du domaine de la compagnie. Les aspects inter-compagnies ne sont donc pas pris en compte.

Le projet Shibboleth propose un mécanisme de transport d’attributs et d’authentification inter-compagnies. Shibboleth sait transmettre des informations sur l’identité et les habilitations de l’utilisateur qui désire accéder à une ressource protégée. Ce que ne dit pas SAML, c’est l’art et la manière de récupérer ces attributs dans les référentiels.

La norme SAML prévoit le transport d’attributs supplémentaires avec les accréditations de l’utilisateur. Shibboleth est donc capable de transmettre, par exemple, le profil de l’utilisateur avec son identité, en même temps que la preuve d’une authentification réalisée avec succès.

Il est donc envisageable de pouvoir transmettre, en plus de l’identité de l’utilisateur, un ensemble d’attributs utiles au service que cet utilisateur veut atteindre, comme le rôle de l’utilisateur, son nom, son prénom ou son domaine d’appartenance…

Conclusion

Shibboleth, solution de fédération d’identité, est aussi une solution de Web-SSO interne à l’entreprise. Cette solution est fortement sécurisée et permet l’adjonction d’attributs propres aux utilisateurs comme le rôle permettant de déduire directement leurs privilèges.

Une application qui sait gérer le rôle de l’utilisateur en entrée, est beaucoup plus facile à réaliser. Seul les rôles sont à gérer au niveau de l’application et non l’ensemble des comptes autorisés à y accéder.

Dans un prochain billet, nous montrerons comment sont gérés les attributs des utilisateurs entre le référentiel d’identités/habilitations et l’application qui les demande.

Thierry ALBAIN

Impossible en une journée de détailler l’ensemble des projets en cours, l’accent a donc été mis sur les plus en vue, avec une présentation générale pour les sujets les plus récents, des retours d’expérience ainsi que des informations sur quelques nouveautés et les grandes lignes des différentes roadmaps.

Les sujets abordés ont été :

• OSGI :  Guillaume Nodet nous a proposé un aperçu des fonctionnalités OSGI intégrées à ServiceMix 4 via Felix Karaf (aka Karaf tout simplement). Pour rappel OSGI est une spécification définissant les concepts de modularité incluant (vision simpliste) la gestion des dépendances et l’activation des composants au sein d’un container. La démonstration était concluante et nous a permis de constater de visu la facilité d’approche et l’agilité de  la solution. De manière schématique, les déploiements peuvent être réalisés par simple glisser/déposer et la modification du paramétrage des différents composants peut s’opérer à la volée en live, à ne pas mettre entre toutes les mains ;o)… A quand les outils d’exploitation à la mesure de la simplicité et de la beauté des concepts ?
• Apache Camel :
  • Claus Ibsen nous a présenté les concepts de base d’Apache Camel, la notion de framework d’intégration, les patterns EIP, le DSL java. Il nous a également annoncé la realease 2.5.0  pour Octobre, l’avènement de la 3.0 pour le premier trimestre 2011 et bien entendu la sortie du livre “Camel in Action” chez Manning pour début 2011. Pour des informations relatives aux frameworks d’intégration vous pouvez consulter les billets précédemment publiés “L’intégration Java à la légère” et “Spring Integration – Apache Camel“.
  • James Strachan a terminé par une présentation du nouvel éditeur de routes “Camel Rider” : une interface web proposant de manipuler directement les patterns EIP, permettant de paramétrer les différents endpoints, de charger ou de sauvegarder la configuration xml, bref un outils qui va rapidement devenir incontournable et faire monter d’un cran le professionnalisme de la solution face à ses concurrents.
• ServiceMix :
  • Charles Moulliard nous a proposé un survol de l’étendue des fonctionnalités couvertes par l’ESB en version 4, dont on imagine plus aujourd’hui qu’il puisse y avoir des limites, au point même d’y intégrer un serveur FTP. Tout y est prévu pour interconnecter différentes typologies d’applications et prendre en charge de nombreux aspects transerves (logging, audit, sécurité, transaction…), tout cela sur la base d’un socle OSGI bien entendu.
  • Un retour d’expérience sur l’intégration de Fuse ESB (distribution de Service Mix) était également au programme mais j’avoue ne pas y avoir assister, privilégiant pendant ce temps une discussion avec Guillaume Nodet autour des fonctionnalités OSGI et de son image de marque auprès des grands SI. Cela dit je pense que d’autres en reparleront et les slides seront de toute façon mis à disposition sur le site de Fusesource.
• ActiveMQ :
  • retour d’expérience sur les architecture de messaging à base de brokers ActiveMQ : présentation de la mise en place d’un dispositif de haute disponibilité à partir de clusters de brokers, de structure maître/esclave et de persistance mutualisée. Cette intervention a au moins eu le mérite de valider que les patterns d’architecture proposés par la technologie fonctionnent conformément aux attentes en environnement de production.
  • l’autre retour plus mitigé s’intégrait dans un contexte d’utilisation beaucoup plus intensif au sein du LHC (sujet réellement passionnant en dehors de toute considération technique, les ordres de grandeurs à eux seuls forcent le respect). Ce volet couvrait en fait 2 projets, l’un sur l’alimentation d’une grille de calcul dans lequel il semble que certaines limites du produit aient été atteintes, de grands espoirs reposant sur l’arrivée de la version 6, l’autre ayant donné des résultats très satisfaisants pour du monitoring et dont la principale caractéristique a été de rester volontairement sur des cas d’utilisation simple (uniquement des topics et non des queues, pas de persistance…) afin de déléguer toute l’énergie disponible à l’acheminement des messages.

En fin de journée Rob Davies a présenté les prochaines étapes des projets connexes à la version 6.0.0 d’ActiveMQ. Inutile de rentrer ici dans les détails de version et de planning, les informations seront disponibles prochainement dans les slidesets en ligne sur le site de la communauté.

Il est en tout cas important de noter que l’ensemble de l’évènement s’est déroulé dans d’excellentes conditions, que les personnes présentes sont restées disponibles et restent accessibles et particulièrement à l’écoute de toute proposition ou retour des utilisateurs.

N’hésitez donc pas à prendre une part active à ces projets multi-tenants !

Stéphane Delplanque.

Je vous propose dans les paragraphes suivants quelques réflexions, constats et idées qui viennent à l’esprit dès lors que l’on commence à vouloir profiter pleinement du potentiel de la machine.

Où sont-ils ?

Premier constat, restreint au paysage français et vu de ma petite fenêtre : on voit très peu d’Ipad ! que ce soit en réunion, dans les transports en communs, dans les cafés, dans les lieux public. Les propriétaires ont-ils peur de susciter les jalousies, n’assument-ils pas leur côté “early-adopters”, ou simplement ne l’utilisent-ils pas ?

Nous n’en sommes qu’au début je vous le concède, il faut se laisser encore un peu de recul pour obtenir des statistiques pertinentes, au demeurant particulièrement rares sur le web, mais quand on commence à entrevoir les possibilités d’utilisation de la machine, on n’a qu’une envie, en abuser !

Le scénario

Afin d’illustrer les propos de cette réflexion, mettons nous en situation à partir d’un cas relativement simple : un client fait appel à mes services pour lancer une étude, nous organisons donc une réunion de lancement, laquelle doit aboutir à une restitution permettant de valider le cadrage et le périmètre de l’intervention. La suite de l’article a pour finalité de déterminer le degré de réalisme de ce cas d’école et sa faisabilité en l’état des technologies proposées.

Détaillons un peu le scénario :

1. Réunion de lancement chez le client : comme je suis un adepte du “no paper” et que j’ai besoin de prendre des notes incluant des schémas, des couleurs, des annotations et toute sorte de fioritures, je décide de me munir l’Ipad et d’utiliser l’une des nombreuses applications de prise de notes disponibles. En outre je trouve plutôt élégant de sortir un cahier numérique plutôt qu’un portable que je déplie devant les yeux du client pour me cacher derrière l’écran (en évitant au passage les bruits de frappe sur le clavier, particulièrement désagréables sur le long terme).
2. Fort de ces informations, je rentre au siège de ma société, je me place devant mon poste fixe, je lance mon éditeur de présentation et je commence à mettre en forme une ébauche de cadrage de l’étude avec de jolis diagrammes. L’un de ces diagrammes est d’ailleurs issu d’une map que j’ai créé avec mon application de mindmapping préférée.
3. Tard dans la soirée, je rentre chez moi sans avoir terminé la rédaction du document. Je profite du trajet de retour pour relire mes notes et la présentation sur mon Ipad.
4. Au passage je note quelques idées pour la future mission dans une todo-list ou quelques post-it virtuels que je prends bien soin de labelliser (taguer) pour ne pas les égarer parmi tant d’autres.
5. Bien plus tard, comme je voue corps et âme à mon travail, je décide de me remettre sur la rédaction de la présentation depuis mon poste fixe personnel, plus pratique que l’Ipad pour la saisie rapide, et plus ergonomique pour l’élaboration des schémas (écran plus grand, souris, clavier). Je précise que je ne choisis pas l’option d’adapter un clavier et une souris sur l’Ipad, il resterait de toute façon le sujet de la taille d’écran à traiter.
6. Le lendemain matin, dans le train, je relis le document sur mon Ipad, corrige quelques fautes de frappes, et ajuste un peu la map d’un des schémas.
7. De retour chez le client, je sors mon Ipad, branche le vidéo-projecteur et déroule la présentation.



8. On procède à quelques modifications en live et je restitue le document au client via une clé USB.
9. Je rentre au siège, dépose tous les documents afférants au projet dans la GED de capitalisation : le cadrage de la mission est terminée, affaire rondement menée.

Les problématiques

A aucun moment dans l’énoncé précédent je n’ai pris en compte les contraintes du monde réel et les besoins sous-jacents aux différents cas d’utilisation. Il est temps de s’y intéresser et de savoir si cet enchaînement de situations est raisonnablement envisageable.

Hypothèse purement arbitraire et volontairement restrictive de cette analyse : mon Ipad ne bénéficie pas de l’option 3G, je ne peux donc échanger des données qu’en Wifi ou en connectant la machine à un ordinateur via la câble fourni par défaut.

Reprenons maintenant les différentes étapes décrites plus haut et analysons plus finement les questions qu’elles soulèvent :

1. Prendre des notes sur un cahier, c’est plutôt naturel, on sort des crayons et on couche nos pensées sur le papier au gré de notre inspiration, quelque soit  leur représentation, graphique, textuelle, mono ou multi-chrome, avec ou sans surlignements ou encadrements diverses, en sténo pour ceux qui savent, bref on représente des idées et des concepts. Qu’en est-il de l’expérience Ipad ?
2. Cette partie de la démarche ne pose pas de problème particulier, d’un côté on lit sur l’Ipad, de l’autre on travaille comme à son habitude sur le fixe avec deux applications différentes.
3. La relecture de notes est triviale, il suffit d’allumer l’Ipad et de démarrer l’application de gestion de notes. En revanche c’est un tout autre problème pour la lecture de la présentation, et on aborde là deux points essentiels sur les échanges de données :
   1. la compatibilité : quelles applications Ipad sont capables de lire les documents que j’ai créés à partir de mes applications locales ?
   2. le transfert : par quel moyen le document créé sur le poste fixe se retrouve-t-il sur l’Ipad ?
4. A l’heure actuelle, le système d’exploitation de l’Ipad ne gère pas le multi-tâches, ce qui impose de repasser par  le bureau pour basculer d’une application à l’autre, et accessoirement de perdre le fil de son activité si l’application ne gère pas les points de reprise correctement. Prendre des notes à la  volée n’est donc pas une action triviale, à moins de pouvoir inclure directement les notes dans l’application de lecture. En supposant que l’on prenne des notes dans une application spécifique qui permette d’apposer des labels ou des catégories, comment être certain de retrouver ses petits à posteriori et de centraliser l’accès à tous les documents relatifs à un sujet, une mission, un contact ? Le moteur  de recherche de l’Ipad ne prend pas en compte les tags posés localement dans les différentes applications, il  faut donc savoir sur quel document on a travaillé et ouvrir les applications une par une pour y récupérer les informations pertinentes.
5. On retrouve ici, mais dans l ‘autre sens cette fois, les problématiques abordées lors de l’étape 3
6. On peut étendre le sujet de l’échange de données à la synchronisation : comment être certain que le document modifié depuis mon fixe personnel est bien celui qui est sur l’Ipad au moment où je le relis ? Une fois le document existant sur les deux machines, il faut s’assurer de ne pas travailler sur d’anciennes versions. En outre la modification de la map ne peut se faire que si elle a également été transférée sur le périphérique et nécessite de pouvoir la ré-inclure dans le support de présentation une fois modifiée.
7. La présentation doit pouvoir être projetée depuis l’Ipad vers un vidéo-projecteur à l’aide d’une interface de connexion standard du type connecteur VGA.
8. Modifier le document se fait de la même façon que dans l’étape 6, mais est-il possible de le copier ensuite sur une clé USB ? Si cette opération ne s’avère pas réalisable, peut-on passer par un autre moyen ? Une connexion WIFI par exemple ? plutôt rare dans un contexte d’entreprise sécurisé. Un transfert via câble USB ? A voir.
9. A nouveau il faut s’assurer de la bonne synchronisation des documents et d’avoir récupérer tous les éléments relatifs au projet et disséminés dans plusieurs applications.

Les éléments de réponses

L’exercice se poursuit en tentant d’apporter des solutions, lorsqu’elle existent, aux questions posées dans le paragraphe précédent. L’idée est de trouver une réponse à moindre coût énergétique bien entendu, sinon il est toujours possible de refaire le terminal ou de changer son utilisation, alternative que nous ne traiterons pas ici.

Analysons donc la scène au ralenti :

1. Toutes les applications de prise de note présentes dans l’Appstore proposent d’utiliser le mode texte via le clavier virtuel, quelques une ajoutent des fonctionalités graphiques pour y inclure des schémas, et plus rares sont celles qui permettent la prise de note manuscrite. Encore faut-il, pour le dernier point, pouvoir écrire au doigt : rappelons que l’écran tactile est capacitif et non résistif, il est donc impensable d’utiliser un stylet en plastique, bien pratique sur les anciens PDA et autres terminaux de la même génération, mais inutilisable désormais. Le problème, lorsqu’on écrit avec le doigt, c’est qu’on ne voit pas vraiment ce qu’on fait, à moins d’écrire assez gros, de zoomer, d’utiliser un mécanisme qui déplace la zone d’écriture au fur et à mesure que l’on avance, ou un autre qui décale la zone d’écriture par rapport au doigt, bref des contournements qui ne valent pas un bon vieux stylo fin.
   La solution peut être de se tourner vers des produits adaptés à l’écriture sur ce type d’écrans tels que le pogo sketch. Et si le prix vous rebute ou que vous souhaitez faire preuve d’originalité, vous pouvez toujours essayer de le fabriquer … du plus bel effet chez le client. Quelque soit la solution, il faudra composer avec les moyens du bord et adapter sa façon de noter.
2. RAS
3. La compatibilité entre applications n’est pas en soi un réel problème dès lors que l’on reste dans le monde Apple. Passer de la version de Keynotes du MacBook à son petit frère ne devrait pas poser de gros soucis. Mais soyons réalistes un instant, ce que veut le client, c’est un fichier Powerpoint, ça ne se discute pas. Eh bien finalement la situation n’est pas désespérée puisque le fameux Keynotes importe le format .ppt pour le transformer en format interne. Et si vos présentations sont faites sous Google Docs, on peut les lire pour l’instant avec une application comme Godocs, et peut-être bientôt les modifier.
   Maintenant que nous sommes rassurés sur le fait que nous allons pouvoir consulter nos documents, comment procède-t-on pour les transférer entre le poste fixe et la tablette ? La réponse est loin d’être triviale et universelle. Les méthodes disponibles pour l’instant, au gré des applications, chacune privilégiant une ou plusieurs solutions, sont les suivantes :
   1. Si l’application se conforme à la philosophie Apple, le plus direct est de passer par ITunes : on ajoute notre fichier dans la liste des fichiers partagés correspondant à l’application et il sera automatiquement chargé sur l’Ipad à la prochaine synchronisation. Il faut évidemment suivre cette procédure pour chaque fichier que l’on souhaite voir partager, et même si la sélection multiple est possible, l’opération reste manuelle. En outre il faut brancher l’Ipad via le câble USB pour activer la synchronisation, le mode ‘over the air’ n’étant pas disponible. Même si cette solution a le mérite d’être standard, elle reste inadaptée à certains besoins : si on décide d’ouvrir le document avec une autre application, il faut le dupliquer dans son propre espace de fichiers partagés. Impossible de transférer un document d’une application vers une autre, l’information est organisée en silos étanches.
   2. Solution un peu plus ‘geek-esque’ : l’application a la possibilité de démarrer un serveur web local sur lequel on se connecte depuis le poste fixe pour y charger les fichiers via une page web. J’ai de sérieux doutes sur le succès de cette méthode chez les utilisateurs lambda.
   3. Le cloud : à l’heure du stockage en ligne et des services ‘in the cloud’, il est nécessaire de composer avec les nouvelles pratiques des internautes. Certaines applications proposent donc de charge les fichiers à partir de son espace de stockage online pour les visualiser localement. Cependant, face à la quantité grandissante de fournisseurs d’espace de stockage, chaque application choisit ses partenaires et même si certains sortent du lot, tels que DropBox ou box.net que l’on retrouve souvent, d’autres peinent à s’imposer de manière systématique (même pas IDisk…). Mais encore une fois, même si on accède à ses documents distants, la synchronisation reste manuelle, il faut explicitement demander un rechargement du fichier en local pour obtenir la dernière version. Encore une manipulation de trop lorsque chaque clic compte.
   4. Plutôt que de charger un document à partir d’une application, pourquoi ne pas faire l’inverse et, comme on en a l’habitude sur nos postes fixes, parcourir notre espace documentaire pour sélectionner le fichier que l’on souhaire ouvrir sans présumer de l’application à utiliser. C’est ce que proposent les applications telles que Connect pour GoogleDocs, Dropbox pour le service du même nom ou iSmeStorage qui permet de centraliser les différents espaces de stockage dans un espace local partagé. La solution semble élégante, on se sent comme à la maison à un détail près, toujours le même, l’automatisation de la synchronisation qui est pratiquement inexistante, hormis éventuellement au cas par cas pour chaque document (Dropbox).
   5. Pour les adeptes des échanges asynchrones il est toujours possible de passer par le mail et d’ouvrir le document en pièce jointe. Valable occasionnellement, mais difficilement gérable au quotidien, d’autant qu’il faut être certain que les mails soient chargés localement sur la tablette.
   6. Certaines applications possèdent leur propre espace de stockage en ligne, citons par exemple Evernote qui propose de synchroniser l’ensemble des documents vers et depuis l’Ipad de manière quasi-transparente. Cette application a également comme avantage d’exister à la fois en version mobile et fixe. Elle souffre cependant d’un inconvénient qui peut s’avérer bloquant pour une utilisation intensive, à savoir l’impossibilité d’ouvrir certains document dans des applications spécifiques (ex: pdf). Elle propose en effet dans ces cas un visualiseur interne qui est loin d’offrir les fonctionnalités qu’on pourrait en attendre.
4. Si on met de côté les aspects multitâches, directement liés au fonctionnement interne de la machine, il n’existe pas vraiment de réponse au problème des labels ou de la recherche centralisée, à part l’utilisation d’applications comme Evernote (ou ReadItLater pour des documents web). En effet même les solutions de cloud-storage n’offrent pas la possibilité de tagger les documents qu’elles gèrent.
5. On retrouve ici essentiellement les mêmes éléments que dans le point 3, à quelques détails près dont il faut tenir compte :
   1. la synchronisation depuis Itunes vers le disque local n’est pas automatique tant que le document n’est pas enregistré la première fois manuellement
   2. pour synchroniser un document sur un espace de stockage en ligne, il faut explicitement l’exporter depuis l’application dès qu’on le modifie
   3. certaines applications comme KeyNotes n’exportent que dans leur format spécifique, il n’est donc par exemple plus possible de retrouver le format d’origine du document
6. L’inclusion d’un document dans un autre ne se fait que sur des technologies de type OLE chez Microsoft, ou par simple copier coller de capture d’écran. La dernière solution reste accessible sur l’Ipad (touches Home+Power) puisque par défaut l’image est disponible dans la librairie interne de l’Ipad. Encore faut-il que l’application réceptrice soit capable d’inclure une image provenant de la librairie interne, et même dans ce cas, si on utilise une autre application pour modifier la capture d’écran, on a le pré-requis inverse.
7. Toutes les applications ne permettent pas aujourd’hui de passer par l’interface VGA, il ne sera donc possible de projeter directement depuis l’Ipad que dans certains cas.
8. Autant la modification en live de la présentation ne présente pas d’écueil particulier, autant le transfert via clé USB est tout simplement impossible, la seule interface utilisable par l’Ipad ne permettant que de charger des photos depuis un appareil numérique. Il faudra donc trouver un autre moyen de transfert.
9. Pas de solution miracle sur ce point, organiser la cohérence des documents doit passer par une application spécifique si elle existe ou se faire manuellement.

Que lui manque-t-il pour réussir ?

On a l’impression quand on essaye d’utiliser l’Ipad de manière fluide et plutôt naturelle que l’on est plutôt dans une démarche d’adaptation à l’outil plutôt que l’inverse. D’accord c’est un peu exagéré, mais frustrant quand même.

Si seulement, sans parler d’avoir une vue complète sur le système de fichier on pouvait au moins partagé une partie de l’arborescence, une sorte de dossier qu’on pourrait pour l’exemple appeler ‘Mes documents’, une partie des problèmes se vaporiserait d’elle-même.

Il faudrait également pouvoir gérer une synchronisation automatique, soit en mode connecté par le câble, soit en mode Wifi, en évitant de se poser la question de savoir si toutes les applications sont correctement configurées, si on n’a pas oublié de transférer un document, si on a activé tous les mécanismes spécifiques, démarré tous les serveurs, bref sans y penser.

La réponse au premier point pourrait en outre permettre de gérer des labels sur les documents répartis dans le disque interne, comme on le fait naturellement maintenant sur les mails, une organisation qui fait ses preuves, et d’utiliser de fait le moteur de recherche pour retrouver simplement un ensemble de ressources liées.

L’absence de multi-tâches reste évidemment une coquille dont nous savons qu’elle ne va pas résister bien longtemps.

Enfin et c’est évidemment le souhait de tous, il devient vite indispensable lorsqu’on utilise ce genre de machines en tant que productrices d’informations, de pouvoir échanger librement les produits obtenus entre différents systèmes et différentes plateformes physique sans se heurter à des problèmes de compatibilité, même si on accepte évidemment les limitations techniques et physique de chacune des versions. Or jusqu’à présent les applications restent plutôt spécifiques à l’Ipad et les formats de fichiers difficilement interchangeables.

Les limites d’utilisation

Une fois qu’on commence à jouer avec l’engin, on a envie de jeter les autres appareils et de tout faire avec, y compris la cuisine. Alors qu’est-ce qui nous empêche encore de le faire ?

D’une part les choix technologiques, l’écran capacitif ne permet pas d’utiliser des crayons fins ou non conducteurs, il faut donc s’en satisfaire.

D’autre part les contraintes de format, d’aucuns pourraient considérer que lire une page de livre en entier sur cette taille d’écran sans zoomer ni se déplacer s’avère rude pour les yeux, en particulier pour des journaux au format A4 ou des bandes dessinées. Mais c’est le prix à payer pour pouvoir l’emporter dans son sac.

Ensuite les interfaces, les adeptes du clavier-souris vont devoir apprendre à taper sur un clavier en verre sans retour de touches et graisser l’écran en se tordant pour tenter de regarder derrière le doigt ce qu’ils sont en train de faire. J’entends des voix me murmurer qu’il suffit de se procurer les accessoires ad hoc, mais j’attends de les voir taper un document Word dans le train avec un clavier portatif …

Enfin certains champs d’applications seront clairement inadaptés à un écran d’une telle dimension ou simplement à un écran tactile, c’est le cas pour les progiciels de conception 3D, la retouche photos poussée, le développement logiciel.

Verdict

Le bilan est quand même avouons-le extrêmement positif. Nous n’en sommes qu’aux prémices, l’Appstore gonfle de jours en jours, les idées fusent, les versions se succèdent, bref on va dans le bon sens, tout n’est peut-être qu’une question de mois avant que nous n’atteignions tous la félicité.

En attendant, la solution n’est-elle simplement pas de suivre l’adage ”Pour vivre heureux vivons connectés” ? La 3G est là pour nous permettre de rester en permanence liés à notre patrimoine documentaire, il suffit donc de choisir le bon abonnement et d’utiliser la bonne déclinaison de machine.

Pour ma part je m’y refuse encore, je pense qu’il est tout à fait raisonnable de penser que dans un avenir proche nous pourrons travailler efficacement en mode déconnecté ou asynchrone. Les applications manquent encore de maturité, il n’existe pas encore de réel consortium entre les éditeurs pour convenir d’un moyen simple d’échanger les données, le cloud n’est pas encore bien entré dans les moeurs. En outre il existe des pistes d’amélioration comme les formats de fichier ouverts pour l’inter-opérabilité ou le HTML 5 pour la gestion du mode hors ligne.

Armons-nous donc de patiente, et pour les plus frustrés, il reste toujours les solutions extrêmes (et fortement déconseillées bien entendu) comme le jailbreak ou l’installation de ChromeOS sur Ipad …

Stéphane Delplanque.

Le nouveau nom de ce blog est donc désormais “Architecture, processus et gouvernance SI” et il sera désormais accessible à partir de l’URL blog.alcyonix.com. L’ancienne URL blog.architectes.it sera désactivée dans quelques semaines.

Pensez à mettre à jour vos bookmarks.

Lancement d’un nouvel ouvrage co-écrit par 4 experts SQLI (Dunod)

Préface d’Adrian Joseph, Directeur Général de Google Enterprise EMEALa plate-forme Google Apps existe depuis plus de trois ans et apparaît comme l’offre de Cloud Computing la plus mature et la plus aboutie du marché. Au départ centrée sur la messagerie et l’agenda, elle s’est considérablement enrichie pour couvrir aujourd’hui la quasi-totalité des usages de la bureautique et du portail collaboratif.

Sa mise en œuvre dans les Systèmes d’Information d’entreprise est devenue courante et l’on compte déjà plus de 2 millions d’entreprises utilisatrices dans le monde, de la PME à la multinationale. SQLI a été l’un des pionniers en l’adoptant dès 2008 et en généralisant son usage auprès de ses 2000 collaborateurs. Depuis, le Groupe a déployé cette plate-forme au sein de nombreuses entreprises clientes.

Co-écrit par Manuel Alves (Manager Alcyonix SQLI Paris), Pascal Cadet (Manager Alcyonix SQLI Genève), Pirmin Lemberger (Consultant R&D Alcyonix SQLI), et Médéric Morel (Directeur de la practice Architecture d’Entreprise, Alcyonix), cet ouvrage est le fruit des retours d’expérience des auteurs. Il a pour objectif de délivrer tous les éléments de réflexion nécessaires à la prise de décision, à la mise en œuvre et au déploiement d’une solution de Cloud Computing : impacts du Cloud Computing sur la DSI, aspects pratiques, questions techniques telles que l’intégration avec les référentiels d’identité…

Il s’articule en 4 grandes parties :

• La première partie rappelle les concepts du Cloud Computing, de ses déclinaisons (SaaS, Paas, IaaS) et ses en enjeux en termes de sécurité des données ;
• La seconde présente et décrit l’ensemble des composants de la suite Google Apps ;
• La troisième traite de l’intégration de Google Apps dans le Système d’Information ;
• La dernière traite de la mise en œuvre d’un projet de migration en fonction des objectifs et de la taille de l’entreprise concernée.

Cet ouvrage s’adresse aussi bien aux décideurs qui souhaitent comprendre les enjeux liés au déploiement d’une solution Cloud Computing dans leur entreprise, qu’aux maîtrises d’ouvrage confrontées à ce type de projet, aux architectes et développeurs intégrés au sein d’une DSI ou encore aux utilisateurs qui souhaitent découvrir le fonctionnement de ces nouveaux outils.

Le communiqué de presse SQLI.

Acheter l’ouvrage sur le site d’Amazon.

Tibco AMX BPM n’est pas une simple évolution de IProcess, mais un produit nouveau dont l’ensemble du runtime a été redéveloppé afin de palier les manques de l’offre IProcess.

Voici les points principaux que je retiens de cette nouvelle offre :

• Le nouveau runtime se base sur OSGi pour plus de modularité, aussi bien pour le moteur lui-même, qui fonctionne sur le socle Active Matrix de Tibco, que pour les déploiements qui se font maintenant par package (processus + éléments complémentaires – services, formulaires, etc) alors que seul le processus était déployé dans IProcess.
• Tibco AMX BPM résout un des problèmes majeur d’IProcess : il permet de gérer des objets complexes (par exemple issus d’une XSD ou d’une structure de base de données) là où il fallait se contenter d’objets simples ou de tableaux d’objets simples (date / nombre / chaine de caractères) avec IProcess
• Le système de gestion des tâches humaines basique d’IProcess (une corbeille par utilisateur ou groupe d’utilisateurs) est remplacé par un système de base de données dynamique, qui attribut les tâches en fonction des droits (éventuellement issus d’un annuaire LDAP) et de l’occupation des utilisateurs.
• L’outillage progresse avec notamment l’ajout d’un mode « debug » pour les processus, à la manière de ce qui existe actuellement pour l’ESB BusinessWorks.
• Une véritable orientation web 2.0 des interfaces utilisateur : deux nouveaux clients sont fournis avec AMX BPM : OpenSpace, qui est un gadget web développé avec GWT (Google Web Toolkit), ainsi que MobileSpace qui est un portage d’OpenSpace pour terminaux mobiles (support uniquement de l’iPhone dans sa version actuelle). Le client Ajax d’IProcess, “workspace”, est conservé tel quel, mais ce n’est à mon sens pas un outil pour les utilisateurs finaux.

Il est également à noter que les processus modélisés avec les dernières versions de  Business Studio (l’IDE de développement pour IProcess et AMX BPM) sont également déployables sur TIBCOSilver BPM, l’offre Cloud Computing de Tibco.

Je pense que ce renouveau de l’offre BPM permet à Tibco de se repositionner de manière favorable sur ce marché, là où l’offre IProcess, de par ses limitations, se révélait plutôt être un choix par défaut pour les clients utilisant déjà des produits Tibco, et l’ESB BusinessWorks en particuliers.

Arnaud DAMME

Un annuaire LDAP, qu’il soit un produit d’éditeur ou une solution open source, est aujourd’hui compatible LDAP V3.

Comme la norme n’est jamais suffisante pour les besoins des entreprises les plus exigeantes, certains éditeurs proposent des fonctionnalités supplémentaires comme des politiques de mots de passe évoluées, implémentées directement dans l’annuaire LDAP.

Le choix des éditeurs

IETF travaille depuis 1999 sur la normalisation les politiques de mots de passe des annuaires LDAP. Aujourd’hui, la norme est toujours marquée draft, en est à la version 10 et date de l’année dernière.

Vu la lenteur d’élaboration du document, en version finale, de description des politiques de mots de passe dans les annuaires LDAP, nous comprenons assez aisément que les éditeurs aient pris de l’avance dans ce terrain pour répondre à la demande des clients.

L’avance des éditeur par rapport à la norme doit permettre au document final, qui décrira cette norme, d’être très complet vis-à-vis de la demande du marché. La contrepartie est que lorsque le document sera sorti, les éditeurs devront s’aligner sur la norme tout en gardant et faisant évoluer leur existant déjà bien implémenté chez bon nombre de leurs clients.

Les politiques

Le document de normalisation propose une série de règles qui contrôlent comment les mots de passe sont utilisés et administrés dans les annuaires LDAP.

En effet, pour accroitre la sécurité des annuaires LDAP et pour les rendre résistants faces aux attaques, il est nécessaire de faire respecter une série de règles sur l’utilisation des mots de passe.

Ces règles sont faites pour s’assurer que les utilisateurs changent leurs mots de passe régulièrement, que les mots de passe suivent certaines préconisation de construction, que la réutilisation des derniers mots de passe soit interdit et pour dissuader les attaques quelles que soient la méthode employée.

Conclusion

Ce document est attendu, mais il ne résoudra pas les failles de sécurité des applications : ce n’est pas parce qu’un utilisateur change son mot de passe tous les mois, que son mot de passe est « très » compliqué et que l’annuaire est imperméable aux attaques que le SI de l’entreprise en sera mieux protégé.

L’avènement d’une norme apporte toute fois d’autres avantages :

• Elle permet des implémentations, de la norme, équivalentes entre différentes solutions
• Elle permet de pouvoir changer de solution sans avoir à tout redévelopper, à partir du moment où la norme a été respectée
• Elle permet d’être assuré de la pérennité de son choix de solution

Thierry ALBAIN

Le nouvel ensemble ainsi formé adresse l’ensemble des besoins des DSI : stratégie et gouvernance IT, amélioration des processus et architecture du système d’information.

Alcyonix devient ainsi le cabinet de conseil du groupe SQLI avec des implantations en France, en Suisse, au Canada et au Maroc.

Nos nouvelles coordonnées sont :

111 Av Victor Hugo
75116 Paris

Tél : 01 45 05 31 36

Pour nous rejoindre en transport en commun :

• RER A : Station Charles-de-Gaulle Etoile
• Métro Ligne 2 : Station Victor-Hugo

Pour nous rejoindre en voiture :

• Parking public place Victor-Hugo

View Larger Map

La documentation

Aussi fiable soit-il, un framework n’aura pas sa place dans un environnement industriel sans une documentation exhaustive, pratique et facilement utilisable.

La pérennité

Les fonctionnalités

Le développement

Conclusion

Globalement les 2 solutions présentées se valent en terme de fonctionnalité, de maturité et de pérennité. Les taux de pénétration sur le marché sont difficilement évaluables à l’heure actuelle et ne permettent pas de dégager une tendance claire en matière d’adoption.

En toute objectivité on ne peut toutefois pas rester indifférent à la simplicité de mise en oeuvre apportée par Camel grâce à son DSL java, à ses conversions implicites et à ses fonctions transverses telles que les politiques de rejeu, le BAM, la piste d’audit, les tests. On peu également considérer que le composant camel-springintegration fourni par Apache est un pied-de-nez à son concurrent direct, ou simplement une ouverture d’esprit…

Spring Integration intéressera forcément les aficionados du framework IOC idoine et c’est peut-être justement un point sur lequel l’éditeur pêche par excès : hors Spring point de salut. En outre, point abordé précédemment, la configuration des échanges par fichier XML peut très vite devenir difficile à maintenir et à interpréter.

Comme le dit Willy Antoine, architecte applicatif chez BNP Paribas – Personal Finance, à propos d’un vaste projet d’intégration de progiciels de gestion de crédits (plusieurs dizaines de milliers de JH) :

Le choix d’utiliser un framework d’intégration nous a permis de mettre en oeuvre une première phase du projet, alors que nous ne dispositions pas encore d’un ESB.  Ce type d’approche est un  premier pas vers le déploiement de la solution cible du groupe assurant une trajectoire simple et directe.

Notre choix c’est porté sur Apache Camel pour sa facilité d’apprentissage au  niveau des développements,  grâce au DSL permettant de décrire simplement les routes et à la documentation proposant une double approche:  EIP ou Composant. Le nombre de composants disponnibles nous permet de concentrer les développements sur les parties spécifiques au métier qui pourront être reprises lors de la mise en oeuvre du bus de communication. La proximité de Progress, spécialiste des solutions d’intégration, a également favorisé le choix de Camel pour l’assurance d’un support de qualité.

Liens et références

Stéphane Delplanque