MD Day - agilité, modélisation et modélisme

Jeudi dernier, le 25 novembre, se tenait le quatrième MD Day, une journée intéressante à plus d'un titre.

La conférence était hébergée dans le très beau centre de conférences de Microsoft à Issy, auquel le seul reproche que je puisse faire est une connectivité 3G limitée (et je n'avais pas les infos pour me connecter au réseau WiFi en tant qu'invité). Cela n'a pas empêché de nombreux commentaires sur Twitter.

Cette année le thème retenu était "Model-Driven et Agilité", un lien thématique qui se traduisait dans le programme: le mot "agilité" apparaissait dans le titre de quatre des 10 sessions prévues, plus une "table ronde" au sein de laquelle Xavier Warzee et votre serviteur avaient pour mission de représenter le point de vue Agile.

J'étais un peu anxieux à l'idée d'apporter en quelque sorte une "caution" Agile à un événement organisé autour d'une approche du développement, le fameux "model-driven", à laquelle je n'adhère personnellement pas et qui peut sembler aux antipodes du discours Agile: en caricaturant, elle semble marginaliser le rôle du développeur (remplacé par la génération automatique de code) au profit de celui de l'architecte (traçant des diagrammes de modèles dans le but de les convertir en code automatiquement).

Lors d'une intervention aux Valtech Days il y a quelque temps, j'avais ainsi opposé "modélisation" et "modélisme":

En fait de modélisation, on pratique trop souvent ce que j'appellerai le "modélisme": une activité somme toute assez prenante, et qui constitue un excellent passe-temps, mais qui ne produit pas des résultats très constructifs. Ma définition de "modèle" est la suivante: un modèle est une représentation d'une situation réelle, qui sans y être fidèle dans tous les détails est utile pour répondre à des questions concernant cette situation.

On peut illustrer le "modélisme" par ce diagramme par exemple, obtenu à l'aide d'un outil UML qui analyse du code existant. Trente classes différentes sur un seul diagramme ce n'est tout simplement pas lisible, pertinent, ou utile: c'est uniquement une perte de temps.

Il me semblait cependant important d'accepter l'invitation, pour plusieurs raisons. D'une part, je suis favorable aux échanges entre les diverses communautés de professionnels qui se retrouvent autour d'une volonté commune d'améliorer leur pratique d'un métier, en l'occurrence le développement de logiciels. D'autre part, la communauté "model driven" me semble avoir un rapport plus étroit avec le milieu de la recherche, privée ou publique, que la communauté Agile, et l'une des missions de l'Insittut est de resserrer ces liens.

De ce point de vue, l'important était de participer. Mais je me devais d'apporter un regard plus attentif, et dès le début de la journée je m'étais fixé comme objectif de répondre à la question suivante: la communauté "model driven" ici présente est-elle motivée par un réel intéret pour les pratiques agiles, ou s'agit-il (pour l'instant) d'une simple curiosité, piquée par le "buzz" de plus en plus présent autour de l'étiquette "Agile"?

Mon canevas d'évaluation était, comme il se doit, le Manifeste Agile et la liste des pratiques Agiles: lors des sessions, est-ce que les orateurs évoquaient ce qui, dans leurs solutions proposées, privilégiait les individus et les interactions, la livraison de logiciels opérationnels, la collaboration avec le client, et la réponse au changement? Est-ce que les orateurs mettaient en avant l'inclusion dans une stratégie "model-driven" de telle ou telle pratique appartenant à la "boîte à outils" Agile? J'ai prévenu les orateurs des différentes sessions auxquelles j'assistais, afin de ne pas les prendre en traitre, de mon intention de distribuer en fin de journée un "carnet de notes" avec mention des bons et des mauvais élèves.

Alors, quel bilan de cette journée?

Force est de constater qu'il y a encore loin de la coupe au lèvres, et que la communauté "model-driven" n'est pas encore pleinement Agile. Le mot "agile" était plus utilisé pour légitimer un discours déjà établi, que pour y chercher un véritable contenu pouvant constituer un apport.

La première présentation, celle de Grégory Weinbach et Jérémie Grodziski, se distinguait par un rappel explicite du Manifeste Agile, et un véritable "zoom" sur des pratiques, en l'occurrence le Behaviour-Driven Development (BDD) et le Ubiquitous Language issu de l'approche Domain-Driven Design. D'autres éléments Agiles y étaient présents, portant à... quatre le nombre des pratiques Agiles mentionnées lors de cette intervention. C'est honorable mais sans doute en-deça de ce qu'il serait possible de faire en combinant les deux approches, et je suis resté un peu sur ma faim.

Malheureusement, le reste de la journée n'allait pas combler mon appétit pour une mise en valeur de pratiques et de réalités de terrain: les autres sessions auxquelles j'ai assisté se résumaient à peu de choses près à des démos d'outils. La session proposée par l'éditeur W4 abordait (en passant) deux pratiques que j'ai pu reconnaitre comme issues du discours Agile, mais il aurait été plus juste de parler de RAD pour caractériser l'approche présentée. Pour les autres les retours clients étaient (à mon goût) réduits au strict minimum et laissaient la part belle au "pitch" de l'ingénieur commercial montrant (tout seul au clavier) ce qu'on peut faire avec l'outil.

J'ai été particulièrement frappé par une remarque d'un des orateurs, en fin de journée: "pour la suite je vous demande de m'excuser mais il va falloir que je rentre un peu dans les détails du métier de l'assurance...". Mais non, c'est justement l'attention portée au métier de vos clients qui fait, en tout cas pour moi et en tant "qu'Agiliste", toute la valeur et la saveur de votre retour d'expérience.

Car encore une fois, qu'est-ce que modéliser sinon poser des questions à un client dont, en tout cas en début de projet, on ne connaît pas le métier? Pour être vraiment convaincante, une démonstration de l'approche "model driven" soutenue par un outil devrait se tenir sous la forme suivante: on choisit au hasard dans l'assistance une personne qui propose une situation à traiter, issue d'un domaine d'expertise non technique - ou même de la vie courante, par exemple "gérer la fréquentation d'un musée" ou "réserver une table au restaurant" - et on construit en direct une solution à base de modèles. C'est à mon avis dans ce genre d'exercice qu'on s'apercevrait le mieux des bienfaits ou des limites de tel outil ou de telle approche.

Quand on l'aborde sous cet angle, celui où développer des logiciels consiste à encoder et formaliser des connaissances sur un domaine, la distinction entre "code source" et "modèle" commence à mon sens à s'effacer, proposition qui m'a servi de conclusion lors de la table ronde. Toutes les préoccupations que nous avons vis-à-vis du code source sont applicables aux modèles, dès lors que nous sortons du "modélisme" (faire de beaux documents visuels) et que nous cherchons à répondre à la demande d'un client: est-ce que le résultat est correct (ne donne pas des réponses fausses), est-ce qu'il est utilisable (son ergonomie s'adapte à l'utilisateur), est-ce qu'il créée de la valeur?

Dans une approche qui consiste à créer des modèles pour générer automatiquement du code source, cette seconde étape s'apparente à de la compilation, par conséquent le modèle devient le véritable code source. Mais d'un autre côté on constate que les langages modernes (par exemple Ruby) permettent de plus en plus, par le biais de l'abstraction et de techniques comme les DSL, de séparer les préoccupations purement techniques et algorithmiques de l'expression (dans le même langage) des connaissances sur le domaine fonctionnel et des exigences: le code source devient tout à fait adéquat pour exprimer ce qu'on appele en général le "modèle".