Laurent Bossavit : Contrairement à ce qui se passe lors de démarches plus conventionnelles, les personnes qui formulent XP ne se sont pas attachées à produire des études. XP est venu de la base, de développeurs qui essaient, de façon pragmatique, d'améliorer les choses dans leur coin. C'est plus tard que l'idée est venue d'étendre ces principes au niveau du projet ou de l'équipe. Nous avons des retours empiriques en très grande majorité positifs, dans le cadre de véritables projets, ayant déjà beaucoup impliqué les spécialistes métier. Ils proviennent de responsables marketing ravis de disposer de produits sans bogues ou de DSI contents de ne pas avoir de problèmes avec leurs utilisateurs. Evidemment, les développeurs témoignent également d'améliorations dans leur cadre de travail et dans leurs relations avec l'environnement non technique.

Les deux. Le travail collaboratif est une discipline qui nécessite des efforts, et de déléguer une responsabilité beaucoup plus grande aux développeurs, d'impliquer davantage le client. Pour que cela fonctionne, il ne suffit pas de le décréter. Pour avoir cette communication avec le client/utilisateur, certains comportements et attitudes doivent être modifiés.

Un logiciel, à mesure qu'il se complexifie, a tendance à s'écrouler sous le poids de sa propre complexité. A moins que l'on ne définisse une structure lui permettant de demeurer robuste face aux contraintes d'évolution technique ou du métier. Dans une approche plus classique, c'est l'architecte qui aura la charge de cette structure en dessinant des modèles Merise, UML ou autres. Avec XP, on va, bien sûr, tenir compte de ces modèles, mais davantage au niveau du développeur auquel on va demander de matérialiser dans son code les notions garantissant une bonne évolutivité. Le développeur et l'architecte se nourrissent à la même source : des modèles de conception, des notions de modularité ou de couplage.

Il y a forcément complémentarité. D'un côté, l'efficacité de certains provient de ce qu'ils savent représenter en quelques lignes la structure d'un système. D'autres auront la faculté de relier des points de détail du code à cette vision d'ensemble. Ces compétences vont cohabiter dans le cadre du projet. Une personne formée à UML ne sera pas distancée, mais elle devra redéfinir son rôle de façon à être vraiment efficace dans le mode de fonctionnement moins hiérarchique et moins séquentiel que propose Extreme Programming.

Ce serait vraiment une erreur d'imaginer que la partie la plus importante du travail consiste à modéliser le métier d'une entreprise. La réalité est plus subtile. L'interaction entre l'analyse d'une problématique métier et sa concrétisation dans un produit est un dialogue. Et c'est dans ce dialogue que réside la valeur pour l'entreprise. On ne pourra supprimer ni l'écriture du code ni la mise au point des modèles.

Il faut manier avec prudence la notion de nouveauté en informatique. Cela vaut pour les méthodes : on redécouvre des principes connus depuis vingt ou trente ans, comme le binôme, plus performant que deux développeurs travaillant chacun de son côté. Les militaires, par exemple, l'ont institué depuis très longtemps. A l'université aussi, on travaille souvent en binôme. De la même façon, on a depuis longtemps démontré l'importance de l'implication du client. L'informatique a bifurqué vers un formalisme massif pendant deux décennies, et on en a vu les résultats. Finalement, XP est une collection de bonnes vieilles recettes rassemblées en un tout plus efficace que la somme de ses parties.

Tout projet comporte des risques dans trois domaines : la qualité, la perte de la relation avec le client - on ne le comprend pas, donc on fait quelque chose d'inutile - et enfin les délais. XP est complet parce qu'il met en lumière un éventail complet des problèmes qui peuvent survenir dans un développement. L'un des dangers est de ne prendre de XP que ce qui passe facilement, ce qui est immédiatement compatible avec les modes de travail en place. Mais si l'on ne s'attaque pas aux problèmes fondamentaux, tels les litiges avec le client ou la qualité, on n'aura rien fait. Alors, si l'on me demande à quelles parties du projet on doit appliquer une logique de tests continus, je répondrai : « seulement à celles que vous voulez voir fonctionner ». Et si l'on me demande à quelles parties appliquer la pratique du dialogue avec le client, eh bien, je rétorquerai : « seulement à celles pour lesquelles le client doit être satisfait ».