Pourquoi la qualité logicielle se joue avant la première ligne de code

• Produit

Parler de « qualité logicielle » renvoie à un imaginaire très technique : stratégies de tests, modularité, architecture, refactoring… Et c’est vrai : il y a souvent beaucoup à faire sur ces sujets. Mais, en amont, la conception fonctionnelle joue elle aussi un rôle capital. Bien des bugs vus par l’utilisateur sont en fait des défauts de conception, des cas-limites que l’on n’avait pas anticipés. Et avant cela, quel sens y aurait-il à développer avec excellence une application qui serait mal conçue, ou, pire, qui ne répondrait pas aux besoins de ses utilisateurs ?

Dans mon métier, il est impossible de ne pas s’intéresser à la conception fonctionnelle : Garbage in, garbage out.

La conception fonctionnelle, moment charnière entre Discovery et Delivery

Que faut-il comprendre par « conception fonctionnelle » ? Commençons par la situer, au milieu du flux de production logiciel :

• La Discovery : il s’agit de déterminer les problèmes auxquels sont confrontés les utilisateurs, et souvent creuser longtemps pour découvrir le vrai besoin derrière la demande exprimée. Établir des priorités entre ces problèmes est ensuite une question d’ordre stratégique, tant s’atteler à la résolution d’un problème plutôt qu’un autre engage l’entreprise.

• Le Design : une fois le problème clairement posé, on peut imaginer des solutions, souvent organisationnelles et logicielles. Reste alors à décrire de manière exhaustive et cohérente le comportement attendu, c’est-à-dire les fonctionnalités de l’application. Certains incluent cette étape dans la Discovery, je préfère l’en dissocier.

• La Delivery : et enfin la mise en œuvre à proprement parler, développement, test, mise en production. Je passe vite ici, car ce n’est pas l’objet aujourd’hui.

La conception fonctionnelle consiste donc à décrire le quoi avant de penser au comment. Autrement dit, modéliser votre métier tel qu’il serait si l’informatique n’existait pas, et décrire le comportement attendu de la part du logiciel (cela fait toujours partie du « quoi »).

Voici donc, pour rendre la chose plus concrète, quelques outils, pratiques et formalismes que vous pourriez utiliser lors de cette étape. Liste non exhaustive.

Votre boîte à outils fonctionnelle

• Définition de persona : ce sont vos utilisateurs types, auxquels vous donnerez un petit nom afin de susciter l’empathie de vos équipes. Outre le rôle/la fonction, il est important pour vous d’expliciter ce qui motive ces personnes, les raisons qui les poussent à utiliser votre produit ou vos services, le contexte dans lequel ils le font, leur aisance avec la chose informatique (computer litteracy), et les frustrations qu’ils rencontrent actuellement avec les produits et services concurrents. Ce travail est donc l’aboutissement d’une phase de recherche utilisateur, qualitative et quantitative.

• Les processus/workflows : il s’agit ici de décrire l’interaction de plusieurs acteurs avec le système dans le but d’atteindre un but commun (validation de la demande de congés d’un salarié, par exemple). Cette vision nous est généralement assez naturelle, et vous pourrez vous appuyer sur le formalisme d’UML pour plus de systématisme.

• L’étude de modularité : la modularisation est un sujet incontournable tant il conditionne l’évolutivité de votre système d’information sur le long terme, j’en ai souvent parlé. Ne vous méprenez pas, le sujet n’a rien de technique. Il est généralement porté par des tech guys, qui s’appuient sur les heuristiques du Domain-Driven Design, mais la délimitation des fameux bounded contexts repose bien sur l’étude de votre métier. Autrement dit, c’est un sujet totalement fonctionnel, tant et si bien que cette modularité structurera souvent votre offre produit, vue du client.

• Les processus et la modularité vous offrent une vision globale, en largeur, du système que vous souhaitez construire. Le User Story Mapping (Jeff Patton) est un outil de gestion du backlog qui conserve et s’appuie sur cette vision transversale, mais cette fois-ci centrée sur l’utilisateur et sa User Journey. Car c’est bien là le problème de la gestion de backlog : à trop ordonner des tickets, on a tôt fait d’oublier l’utilisateur, même si ces tickets sont censés être des User Stories. Peu importe à un manager de pouvoir s’authentifier par reconnaissance de l’iris si ensuite l’application ne lui permet pas de valider cette demande de congés.

• La conception fonctionnelle est un exercice subtil, qui demande de travailler dans le détail (exploration « en profondeur ») sans jamais perdre la vision globale (exploration « en largeur », que nous venons de voir). L’Example Mapping (Matt Wynne) est à mon sens la pratique idoine pour descendre à la granularité la plus fine (règles de gestion, exemples/tests), découvrir tout un tas de cas limites et constater, une fois de plus, que le diable se cache dans les détails. Cette pratique fait la différence entre le tout-venant des produits sur le marché et un très bon produit. À noter que cet exercice alimente également le backlog : à mesure que l’on va dans le détail, il devient évident que l’on ne pourra pas tout implémenter à la fois…

• L’Example Mapping va avec son propre formalisme, mais rien ne vous empêche de l’enrichir, le but étant que les différents acteurs autour de la table (PM, Dev, QA) se comprennent et épuisent autant que possible la complexité du sujet. Dans cette perspective, vous voudrez peut-être établir un Modèle Conceptuel de Données (un par bounded context). Le MCD ou « diagramme entités/relations » fait émerger les concepts du domaine – parfois implicites – et les relations qui les lient. Cette modélisation est indépendante de tout paradigme de langage, notamment la programmation orientée objet : le MCD n’est pas un diagramme de classes. Il modélise le « quoi », pas le « comment ».

• De manière générale, à vous de trouver le bon formalisme pour être efficace : ce seront parfois des maquettes d’écrans (n’hésitez pas à commencer par un simple crayonné, idéal pour laisser libre cours à la pensée), parfois des diagrammes de séquence UML, des diagrammes d’états-transitions pour représenter le fonctionnement d’un automate fini ou bien encore une matrice de rôles et droits applicatifs dans le cadre d’un système de contrôle d’accès basé sur les rôles (RBAC).

Conclusion : « C’est technique »… vraiment ?

Si ces considérations vous paraissent « techniques », soyez pourtant assuré que nous n’avons parlé ici que du comportement attendu de l’application, autrement dit d’aspects purement fonctionnels. De toute manière, ce mot (« technique ») ne veut rien dire : je mets au défi quiconque de m’en proposer une définition univoque – quelqu’un devrait à ce moment précis me parler de Heidegger 😉

Exemple : vous concevez un produit SaaS consommable par API (API First). Détailler la signature de chaque endpoint, c’est technique ?