Le développement logiciel nécessite une parfaite cohésion entre les différents intervenants du projet. C'est à cette condition que délais, budget et niveau de qualité sont respectés. Mais les outils font encore défaut. « Il n'existe aucune suite de développement logiciel intégrant des outils de collaboration et de gestion de projet » , déplore Franck Gonzales, fondateur du cabinet de conseil Osaxis. Difficile, dès lors, d'orchestrer le travail d'une équipe. D'autant que « les environnements de développement intégrés ne couvrent pas tous les besoins, et que les outils isolés communiquent mal entre eux » , constate Carl Zetie, analyste chez Forrester Research. Chefs de projet, architectes et développeurs travaillent aujourd'hui chacun de leur côté. Ce qui contraint les entreprises à s'organiser avec les moyens du bord : répertoires partagés pour échanger les documents d'analyse, envoi par courrier électronique des applications à déployer, liste de « à faire » transmise aux développeurs dans des fichiers Excel et à consolider ensuite pour le rapport d'activité, etc.

Cet artisanat se traduit par un taux d'échec record : seuls 16 % des projets tiennent leurs engagements, tandis que 37 % sont purement et simplement arrêtés en cours de route. Les 47 % restants dépassent les délais ou le budget initialement prévus. Telles sont les conclusions d'une étude menée par Borland auprès d'entreprises françaises.

La situation n'est pourtant pas désespérée. Contraintes par l'éloignement géographique et les barrières culturelles, les communautés open source ont commencé à industrialiser leurs projets logiciels. Basées sur des outils de collaboration, tel Sourceforge, associés à d'autres briques open source comme Mantis (gestion de bogues), CVS (gestion de configuration) ou Maven (gestion de builds), ces plates-formes de développement collaboratif ont fait leurs preuves sur plus de 70 000 projets. Elles sont encore imparfaitement intégrées aux outils des grands éditeurs. Néanmoins, elles rationalisent la collaboration des équipes. De grandes entreprises, telle BNP Paribas, s'en sont inspirées pour assembler des outils commerciaux et open source afin de construire leurs propres plates-formes de développement collaboratif. « Nous utilisons le gestionnaire de configuration Starteam de Borland comme référentiel pour stocker tout notre code, mais aussi les documents d'analyse, décrit Pascal Jarry, responsable architecture technique, BNP Paribas Securities Services. L'information est partagée par le biais d'un intranet et de listes de diffusion. Nous utilisons aussi les logiciels libres Maven et Jelly pour documenter et automatiser les builds, ainsi que JUnit et Clover pour les tests unitaires. »

Les entreprises sont cependant nombreuses à n'avoir ni les compétences techniques ni le temps pour assembler leur propre plate-forme, brique par brique. Conscients de cette lacune, Microsoft, IBM et Borland ont tous annoncé de nouvelles plates-formes de développement collaboratif pour l'année prochaine. Après avoir amélioré la productivité individuelle, les éditeurs cherchent désormais à associer leurs outils et à compléter leur couverture fonctionnelle pour couvrir tout le cycle de vie d'un projet. « C'est la seule façon d'améliorer la qualité et de gagner en productivité » , estime Bruno de Combiens, responsable marketing produits chez Borland.

Pour tenir cette promesse, IBM et Microsoft ont découpé leurs ateliers de développement en un ensemble de modules. Ceux-ci sont fédérés, côté serveur, par un socle d'intégration unique et, côté client, par un environnement de développement personnalisable.

Team Foundation, le socle d'intégration de Microsoft, concentre dans une base SQL Server toutes les données du projet : exigences, diagrammes UML, code source, résultats des tests, etc. Ces données sont ensuite exposées au travers d'une interface de programmation XML, accessible directement au sein de Visual Studio Team System ou via un portail. Grâce à ce couplage lâche, cette architecture dissocie l'évolution des outils de développement de celle des données des projets. Celle-ci offre aussi une plus grande ouverture. Editeurs et entreprises peuvent développer des solutions indépendantes de Visual Studio : rapports directement accessibles au sein d'un portail, compilations lancées à l'aide de scripts sans passer par l'environnement de développement, etc. Moins avancé sur cette partie serveur, IBM s'appuie, lui, sur sa gestion de configuration, dans laquelle il stocke les données du projet à l'aide de fichiers XML.

Avec l'apparition du référentiel projet, les outils de développement côté client ont, eux aussi, subi un sérieux lifting. Pour répondre aux besoins de l'ensemble des acteurs d'un projet, sont apparus des modules de test, de modélisation et de suivi de projet. Borland a récemment racheté Estimate pour la gestion de projet. Atlantic, d'IBM, et Visual Studio 2005 Team System, de Microsoft, permettent au chef de projet d'affecter des tâches à des développeurs et de suivre automatiquement le déroulement du projet. Celui-ci peut, par exemple, recevoir chaque matin un bilan complet sur l'état d'avancement des développements. Notamment le nombre de classes développées et testées, les statistiques du projet par lot, par développeur ou par indicateur (comme le pourcentage de bogues). Il peut aussi être alerté en fonction d'événements paramétrables.

Outre l'extension fonctionnelle, ces environnements de développement reposent sur une nouvelle architecture technique, liée à l'apparition du serveur et à la volonté des éditeurs de fournir un seul outil client. Architecte, développeur et chef de projet partagent désormais le même environnement personnalisé à l'aide de plug in, en fonction de leur rôle : module de modélisation pour l'architecte, éditeur de code pour le développeur, tableau de bord pour le chef de projet. N'apparaissent à l'écran que les menus et fonctions auxquels l'utilisateur a le droit d'accéder. Si bien que chaque profil possède un poste de travail taillé sur mesure et entièrement personnalisable. Microsoft suit la même démarche. Visual Studio 2005 est un socle modulaire, sur lequel les entreprises connectent les plug in issus d'éditeurs spécialisés.

Au-delà d'une meilleure intégration, ces outils industrialisent le cycle de développement en intégrant une dimension méthodologique et en automatisant la chaîne de production des applications. La personnalisation de l'environnement de développement sert à respecter une méthodologie précise. Cela en obligeant certains profils à effectuer des tâches dans un ordre donné ou en les contraignant à respecter des étapes de validation. Pour ajouter une classe dans la gestion de configuration, le développeur devra, par exemple, l'avoir préalablement testée ou validée auprès de son responsable technique. Cette gestion de processus s'appuie sur les Enterprise Templates chez Microsoft, et sur les Perspectives d'Eclipse chez IBM. Pour être efficace, cette démarche impose cependant de formaliser les processus et le rôle de chaque individu. Forrester Research estime ainsi que, comme pour les progiciels de gestion intégrés, le paramétrage initial des premiers projets nécessitera un important investissement. Microsoft propose donc des modèles de projets préconfigurés (XP, CMMI...) et adaptables pour accélérer le déploiement de Visual Studio 2005 Team System.

Ces plates-formes fiabilisent et accélèrent également le projet en automatisant la fin du cycle de développement au sein d'une usine logicielle (Software Factory). Lorsqu'un code source est déposé sur la gestion de configuration, le serveur prend le relais. Entre autres, ce dernier assemble et compile le code fourni par plusieurs développeurs, effectue des tests, et publie les builds dans le référentiel. Un travail méticuleux, parfaitement adapté au potentiel d'un robot, et qui, en outre, décharge les développeurs. Lesquels peuvent alors se consacrer à des tâches à plus valorisantes.

Même s'ils font gagner du temps aux développeurs, ces outils sont contraignants. Par ailleurs, de par leur capacité de suivi, ils peuvent être perçus comme des instruments de contrôle. Pour obtenir l'adhésion, « il faut donc former et sensibiliser les acteurs du projet à ces nouvelles dimensions » , conseille Jean-François Vallet, consultant chez Osaxis. Souvent aussi, les équipes auront à réorganiser leur cycle de développement à la journée pour être capables d'automatiser la production des builds dans une logique de Software Factory. L'impact de ces outils n'est donc pas neutre en termes d'organisation et de conduite du changement.

Dans tous les cas, la migration risque d'être progressive. « La possibilité de n'utiliser que les modules désirés au fur et à mesure de l'évolution de nos besoins sera un facteur déterminant » , assure Olivier Bourassé, directeur architecture du système d'information de Radio France International. De plus, les outils de développement actuellement utilisés en entreprise n'ont que très rarement été conçus pour dialoguer avec les nouvelles API d'Eclipse ou de Visual Studio Team System Foundation. Les entreprises risquent donc d'attendre, avant de migrer progressivement, que les outils qu'elles utilisent aujourd'hui s'intègrent à ces nouvelles plates-formes de développement collaboratif.