Imaginons un instant une entreprise dans laquelle les projets informatiques tourneraient au cauchemar : le périmètre fonctionnel est mal maîtrisé, les architectes techniques jouent aux divas de l'innovation, les développeurs sont peu productifs, les managers ne savent pas où en est le projet, chaque déploiement est une bataille, les délais et les coûts explosent, personne ne veut maintenir l'application, l’ensemble finit à la poubelle... Une caricature ? Bien sûr... Mais la réalité est-elle plus proche du discours marketing ambiant, fait de beaux outils et de bonnes pratiques, bourré d' « agilité », de « lifecycle management » et de « cloud » ? Depuis que des études comme celles du Standish Group (www.standishgroup.com) ont révélé que la majorité des projets informatiques ne se déroulaient pas comme prévu, on est en droit de se poser la question. Par Frédéric Esnault Directeur Technique Open Wide Technologies.

Cet article se propose de revisiter les tares courantes des projets d'informatique de gestion pour les confronter aux pratiques et outils disponibles. Le sujet étant très vaste, nous l'aborderons ici à travers les notions d' « usine de développement », de « forge » et d' « ALM » dans le cadre des technologies Java. L'objectif est de dégager des pistes de progrès pragmatiques et abordables car s'il est illusoire de faire du rêve une réalité, il y a sans doute moyen d'éviter le cauchemar !

Le cauchemar des DSI

Imaginons un instant que nous soyons confrontés à la pire situation pour une DSI et faisons un rapide tour d'horizon des problèmes rencontrés lors des projets informatiques. Si ce scénario peut paraître extrême, la nature des difficultés mentionnées n'est malheureusement pas absente du quotidien des DSI.

La première source de soucis concerne l'expression et la prise en compte des exigences, ce qu'on appelle aussi les spécifications fonctionnelles. Sans évoquer les carences d'organisation, il est courant de constater que les utilisateurs ont du mal à communiquer leurs besoins et à les faire prendre en compte par l'équipe qui réalise l'application.

Les attentes sont finalement mal exprimées et mal comprises et les fonctions réclameront en conséquence des ajustements tardifs, risqués et coûteux. Les demandes d'évolution, les dysfonctionnements sont mal remontés et les utilisateurs s'en accommodent dans la mesure où leur prise en compte est perçue comme aléatoire. Quand il y a de bonnes idées, elles sont lancées devant la machine à café et jetées avec les gobelets...

Le cauchemar continue du côté des équipes de réalisation. Quand il y a des règles de développement, pratiques reconnues ou choix d'entreprise, elles sont mal appliquées. Pire : on ne sait même pas dire si elles sont appliquées ou pas. Sans contrôle, chacun procède comme il veut, dans son coin. Certains choix se font de manière implicite, sans concertation ni justification, voire même sans aucune communication sur le fait qu'un choix a été fait. C'est ainsi qu'on découvrira trois ans plus tard qu'un framework open source a été intégré à une application dans une version non identifiée et avec une licence litigieuse.

Par ailleurs, on a peu de moyens d'assurer qu'une évolution n'entraînera pas une régression des autres fonctions. Il n'y a pas d'alternative entre les recettes coûteuses et la stratégie du « on verra bien ». Mais si une erreur a été commise, ses conséquences seront visibles si longtemps après qu'il sera difficile d'en comprendre la cause et de mettre en œuvre un correctif.

Il arrive souvent qu'un développeur passe des heures à résoudre un problème alors que quelqu'un dans l'équipe l'a déjà résolu. De toute façon, ce dernier a perdu les informations utiles. Et quand chaque développeur a terminé son travail, on s'aperçoit qu'on est loin du compte : produire le livrable final demande un effort colossal qui est lui-même source d'erreurs, corrigées à la va-vite. Le déploiement en production est ensuite une guerre de tranchées entre l'équipe d'exploitation et celle des développeurs. L'une est responsable, l'autre est coupable.

In fine, chaque projet produit une application différente du point de vue technique et les personnes chargées de la maintenance devront s’adapter à chacun de ces contextes, avec le risque de confusion que cela comporte. De toute manière, avec le temps, l'activité de maintenance ignore ce qui s'est passé pendant le développement initial : on a perdu l'historique, les documents sont introuvables ou inexploitables et il arrive même qu'on ne soit pas capable de retrouver le code source correspondant à l'exécutable en production... Le flou de la phase projet a laissé place à un épais brouillard. Les bons développeurs fuient cette activité périlleuse : la maintenance est un exercice d'équilibriste sans filet donné à des artistes de seconde zone. C'est pourtant là qu'il faudrait des prodiges !

Reste le management. Dans ce cauchemar, le chef de projet se trouve coincé entre des utilisateurs qui demandent l'impossible et des techniciens qui le mènent en bateau. Il lui est difficile d'évaluer des charges et d'arbitrer sur des priorités. Comment identifier les points urgents et stratégiques quand l'information est parcellaire, peu fiable, difficile à analyser dans son ensemble ? S'en suivent des décisions arbitraires, des choix incohérents, des efforts mal ciblés. Cueilli à froid le manager aura du mal à détailler où en est son projet car il faut du temps pour préparer un reporting pertinent. Forcément, la réactivité s'en ressent et les dérapages sont corrigés tardivement, quand ils peuvent l'être.

Le rêve de l'usine de développement

Tous ces acteurs semblent bien inefficaces ! Pourtant, ce n'est pas forcément dû à une incompétence individuelle. Chacun fait comme il peut dans le cadre qui lui est donné. Ne pourrait-on pas offrir aux projets un cadre plus favorable ?

Le cadre idyllique est fait d'agilité, ce qui sous-tend une bonne communication et une grande réactivité. Dans ce rêve, on se donne les moyens de détecter tout écart dès qu'il survient et de mettre en œuvre l'action corrective au plus vite. Les problèmes ne sont pas niés mais tués dans l’œuf. Les décisions sont prises en toute connaissance de cause et tous les acteurs sont impliqués.

Ces pratiques s'organisent via des méthodes de projet dites « agiles » telles que Scrum (http://www.scrum.org). S'y adjoignent des habitudes complémentaires, principalement issues du monde du logiciel libre. Ainsi la dispersion des acteurs, l'esprit communautaire et bénévole du contexte open source ont paradoxalement aidé à rationaliser les processus des projets informatiques d'entreprise.

La notion de « forge », partie de l'idée de créer un site internet pour représenter les projets sur le réseau, prend finalement la forme d'un portail collaboratif qui centralise toutes les informations, favorise les échanges et permet à tous les acteurs d’œuvrer dans le bon sens.

A l'heure où la construction d'une application exécutable ne se limite plus à une phase de compilation du code, l'automatisation du « build » s'est imposée et s'étend à des pratiques que l'on rassemble sous le terme d'« intégration continue ».

Tous ces usages permettent d'aboutir à une « industrialisation » des projets et on parle alors d' « usine de développement » à l'image de ce qui se passe dans l'industrie. On met ainsi en place la « supply chain » de la production logicielle. Voilà une image rassurante mais en quoi consiste-t-elle finalement ?

La planification et le pilotage

Pour commencer, il s'agit de recueillir les demandes des utilisateurs, de les valider, puis de planifier leur prise en compte en définissant des priorités et des moyens.

Dans une forge de développement, les principes du « bug tracker » sont généralisés à toute demande nécessitant une action et un pilotage de celle-ci. Qu'il s'agisse d'une anomalie à corriger, d'une tâche à accomplir ou d'une simple échange d'information, on peut tout suivre. Les utilisateurs peuvent donc exprimer leurs attentes et leurs remarques, l'équipe de réalisation y répondre et les managers superviser ces dialogues, décider des priorités, planifier les travaux et s'assurer de leur aboutissement.

L'approvisionnement

Le code source est stocké et partagé dans un référentiel, dont la fonction est assurée par un système dit de « gestion de configuration ». Ce dernier ne se contente pas de sauvegarder le code de certaines versions identifiées mais va jusqu'à conserver la totalité des évolutions qui ont eu lieu de manière à pouvoir retracer toutes les transformations, en comprendre la logique et si besoin opérer des retours en arrière. Le code source constitue ainsi la matière première entrant dans notre usine. A ce titre, le développeur n'est pas un ouvrier mais un fournisseur qui vient déposer ce qu'il a produit dans cet entrepôt.

D'ailleurs, comme les applications reposent souvent sur des briques externes au projet, à commencer par les frameworks open source, il convient aussi d'en organiser l'approvisionnement. On dispose ainsi d'un référentiel de bibliothèques, sorte d'entrepôt de pièces détachées. Les briques logicielles réutilisables y sont soigneusement stockées par fournisseur et par version pour pouvoir en faire usage le moment venu.

La chaîne de fabrication

Selon les principes de l'intégration continue, le processus de « build », se compose de plusieurs étapes automatisées et standardisées, de la compilation au packaging. Même la production de documentation peut s'y soumettre.

A la fin de cette étape, on dispose au minimum d'un exécutable fraîchement constitué à partir du dernier état du code source et des dépendances définies envers des bibliothèques externes, tout ceci étant issu des référentiels. Peuvent s'y adjoindre d'autres artefacts, comme la documentation ou une extraction du code source qui a servi à cette fabrication.

Le contrôle qualité

Au sein de la chaîne se glissent des phases de tests automatisés : des tests unitaires qui valident le fonctionnement individuel des composants, des tests d'intégration qui vérifient leur bonne cohabitation, des tests de montée en charge qui simulent des situations extrêmes auxquelles l'application pourra être confrontée pour contrôler la fiabilité et les performances.

A cela s'ajoutent des audits de qualité automatiques basés sur des métriques et des règles de développement prédéfinies. C'est ainsi qu'en plus de vérifier la réponse à certaines attentes fonctionnelles, on évalue la qualité de la production, de quoi mettre au rebut le produit s'il n'est pas satisfaisant... Évidemment, un rapport détaillé permettra d'identifier les problèmes et d'initier des actions correctives pour la prochaine fabrication.

La distribution

Il ne suffit pas de produire des livrables encore faut-il les livrer... Que le destinataire soit un client final, l'équipe d'exploitation ou celle de réalisation pour usage interne, l'objectif est de pouvoir retrouver facilement les artefacts en sachant à quelle version ils correspondent.

C'est ainsi que ceux-ci sont stockés et classés dans des zones dédiées, avec une distinction entre les fichiers binaires et les documents. En complément, on peut même envisager un déploiement automatisé sur un serveur pour que le produit soit opérationnel sans aucune intervention extérieure.

Le support

Le support prend avant tout la forme d'un « service après-vente » proposé aux utilisateurs. Ceux-ci peuvent remonter leurs remarques et poser leurs questions. Mais l'activité concerne aussi les échanges internes au sein de l'équipe projet, un développeur pouvant lui-même signaler un problème ou demander assistance à ses collègues.. Dans tous les cas, le support se concrétise par différents moyens de communication complémentaires. Le premier d'entre eux est le « bug tracker » puisqu'il va recueillir les questions et remarques puis donner un cadre aux réponses qui y seront apportées.

Ensuite, il y a des canaux moins formels, comme les forums de discussions ou les systèmes de messagerie instantanée. Leur caractère moins structuré favorise les échanges, le foisonnement d'idées. Enfin, le wiki et la base documentaire permettent de centraliser les informations durablement tout en fluidifiant leur mise à jour et ce, par un maximum d'intervenants.

Bénéfices

On le comprend, l'usine de développement, fortement basée sur l'automatisation des tâches, le travail collaboratif et la centralisation des communications, permet d'éviter de nombreux écueils.

L'enchaînement des tâches de construction et de contrôle étant automatisé, on a tout intérêt à l'exécuter quotidiennement de manière à vérifier au jour le jour la qualité du code produit et à réaliser si besoin les actions correctives nécessaires. Ces dernières se font alors sans douleur puisqu'elles concernent des portions de code limitées, bien identifiées et écrites récemment.

Comme le livrable est reconstruit tous les jours selon le même procédé, on peut montrer l’application à tout instant, demander l'avis des utilisateurs régulièrement et constater très concrètement le travail accompli. La finalisation avant livraison n'est plus une épreuve stressante mais le simple constat que les travaux sont terminés. Sur ce principe, on peut diffuser des évolutions très rapidement tout en limitant les risques. On dispose ainsi des moyens concrets d'application des méthodes agiles.

Enfin, la systématisation des principes du tracker permet de recueillir les exigences, d'arbitrer sur les priorités, de planifier les travaux et de suivre leur exécution à travers des tableaux de bord exhaustifs. Le wiki et les forums assurent la pérennité d'informations complémentaires.

Retour à la réalité

Évidemment, la réalité est moins rose... Mais supposons qu'une entreprise vive plutôt le scénario du cauchemar, que peut-elle faire concrètement pour se rapprocher de celui du rêve ? Existe-t-il une usine de développement telle que nous l'avons décrite ?

Les outils open source

Commençons par une bonne nouvelle : les outils décrits dans notre rêve existent bel et bien. Deuxième bonne nouvelle : beaucoup sont même disponibles en tant que logiciels libres et peuvent donc être évalués et adoptés sans passer par la case achat.

Il serait difficile de passer tous ces outils en revue, mais une petite liste, non exhaustive, s'impose :

• pour les fonctions de tracker : Mantis, Trac, BugZilla, Flyspray, Codendi...
• pour le gestionnaire de code source : CVS, Subversion, Mercurial, Git...
• pour le référentiel de bibliothèques : Nexus, Artifactory, Archiva...
• pour le processus de build : Ant, Maven associés à Continuum, CruiseControl, Hudson ou Jenkins...
• pour l'audit de code et la qualimétrie : XRadar, QALab, Maven Dashboard Report, Squale, Sonar...
• pour les forums de discussion : phpBB, SMF, MyBB, Vanilla, vBulletin...
• pour le wiki : XWiki, MoinMoin, DokuWiki, MediaWiki, PhpWiki...

Bref, il y a de quoi trouver son bonheur. Malheureusement, on pressent que malgré l'accès libre et gratuit à tous ces logiciels, un effort conséquent s'avère nécessaire avant de disposer de l'usine de développement dans son ensemble. En effet, il va falloir choisir les outils en veillant à ce qu'ils puissent cohabiter, puis pour chaque outil l'installer, le paramétrer et plus tard l'administrer en réalisant les sauvegardes et les mises-à-jour. En outre, ces différents éléments vont avoir du mal à communiquer entre eux, ce qui va quand même limiter l'efficacité de la démarche. Il suffit d'imaginer que la création d'un nouveau projet ou l'enregistrement d'un nouvel utilisateur va demander des actions dans une petite dizaine d'outils pour comprendre qu'on est loin de l'idéal.

Les solutions intégrées

Avec le constat qui vient d'être fait, le besoin d'une solution globale apparaît évident. Celles-ci existent, en particulier chez les grands éditeurs : IBM Rational Team Concert, Microsoft Team Foundation Server, Oracle Team Productivity Center, Borland StarTeam...

Ce sont des solutions dites d'ALM (« Application Lifecycle Management »). Évidemment, ce sont des outils monolithiques, spécifiques car fortement propriétaires et plutôt coûteux. Choisir une telle solution peut être pertinent mais c'est un investissement lourd qui sous-entend un choix durable et généralisé, avec une dépendance forte envers l'éditeur concerné. La marche est donc haute et elle n'est probablement pas adaptée à tous les contextes. Force est de constater que les entreprises qui se sont dotées d'une suite ALM de ce type sont encore très minoritaires.

L'approche pragmatique

Le salut vient sans doute d'une voie intermédiaire. Elle repose sur l’existence de solutions intégrées, elles-mêmes basées sur les outils open source déjà évoqués. Ainsi, il est possible d'aborder des pratiques et des outils qui à défaut d'être des standards sont tout de même très répandus. Cela permet de reprendre facilement un existant éventuel, de rester ouvert aux évolutions rapides de ces logiciels, aux futurs formats d'échanges et à des outils complémentaires. Enfin, leur coût se révèle nettement moins élevé que les solutions lourdes des grands éditeurs.

On commence à voir apparaître de telles usines de développement clé en main. Dans ce cadre, l'essentiel du produit est en open source mais on peut aussi bénéficier d'un accompagnement professionnel notamment pour le support. On dispose ainsi d'une solution qui permet une mise en place de l'usine de développement avec « agilité », de manière progressive et ouverte. En complément, certains en proposent même l'hébergement dans le cloud pour un accès en mode SAAS de manière à disposer des bienfaits sans avoir à supporter l'infrastructure et les tâches d'administration. Ainsi le rêve devient même abordable pour les sociétés aux moyens modestes. Bien sûr, l'outillage ne règle pas tout. Pour être efficace, il doit être associé à une volonté et une organisation adaptées mais c'est là la preuve qu'on est bien dans le réel.

Frédéric Esnault Directeur Technique Open Wide Technologies