Produit logiciel et processus logiciel

Produit logiciel et processus logiciel : deux notions liées mais distinctes

Quand on parle de produit logiciel et de processus logiciel, on désigne deux choses différentes. Le produit, c'est ce que les gens reçoivent réellement : le code qui s'exécute, l'interface, les données stockées, la configuration, la documentation et les supports d'aide. Le processus, c'est l'ensemble des activités et des décisions qui produisent et maintiennent ce produit. Il comprend la découverte, la conception, le développement, les tests, la mise en production, la supervision et le retrait de fonctionnalités. On peut examiner un produit directement. En général, on ne voit un processus qu'à travers ses effets.

Il est important de distinguer les deux avant d'agir. Une équipe insatisfaite de son logiciel peut changer de processus alors que le vrai problème vient du produit, ou l'inverse. Un nouveau mode de travail ne peut pas sauver une fonctionnalité dont personne n'a besoin. Une idée de fonctionnalité claire décevra quand même si elle est livrée sans soin.

Cet article est écrit du point de vue d'IVRYN, un studio produit indépendant basé à Paris. Les conseils reflètent la manière dont le studio documente sa propre approche. Ils ne reposent sur aucune étude, aucune enquête ni aucun résultat mesuré.

Comment le processus se voit dans le produit

Les choix de processus laissent des traces dans le produit. Si les tests n'ont lieu qu'à la fin, les défauts arrivent chez les utilisateurs par lots. Si les décisions de design ne sont jamais écrites, l'interface dérive et devient incohérente. Si les mises en production sont lourdes et rares, il devient difficile de savoir quel changement a provoqué quel effet. Vues sous cet angle, beaucoup de qualités du produit, comme la fiabilité, la cohérence et la clarté, sont en partie des résultats du processus.

Ce lien a cependant ses limites. Un processus rigoureux peut tout de même produire quelque chose dont personne n'a besoin, car la qualité du processus ne prouve pas l'utilité. Un processus peu structuré peut parfois produire un outil utile, mais c'est difficile à reproduire et à maintenir. Considérez donc le processus comme ce qui rend les bons résultats plus probables et plus faciles à vérifier. Il ne les garantit pas.

Clarifier le problème avant de choisir une méthode

La première étape la plus utile consiste à formuler le problème précisément par écrit. Indiquez qui le rencontre, dans quelle situation, ce que ces personnes font aujourd'hui et ce qui constituerait une amélioration. Si vous ne pouvez pas répondre à ces questions, débattre de Scrum contre Kanban, ou d'un monorepo contre des microservices, est prématuré. C'est l'énoncé du problème qui détermine quelles questions de processus valent la peine d'être posées.

La clarté du problème indique aussi quel type de livrable construire en premier. Le guide d'IVRYN sur les prototypes, les MVP et les preuves de concept les distingue selon la question à laquelle chacun répond. Une preuve de concept vérifie si quelque chose est techniquement faisable. Un prototype vérifie si la forme et l'enchaînement ont du sens pour les utilisateurs. Un produit minimum viable vérifie si de vrais utilisateurs tirent de la valeur d'une version fonctionnelle, même restreinte. Les confondre est une manière fréquente dont le processus dessert le produit. Par exemple, une équipe peut livrer une démo comme s'il s'agissait d'un MVP, puis interpréter l'absence de réaction comme un rejet.

Petites versions testables et interfaces accessibles

Les petites mises en production sont le lien le plus direct entre processus et produit. Chaque version devrait modifier une seule chose que l'on peut décrire et observer. Lorsque quelque chose s'améliore ou casse, vous pouvez alors en retrouver la cause. Les petites versions réduisent aussi le coût d'une erreur, ce qui compte surtout au début, quand les preuves sont rares.

L'accessibilité montre pourquoi certaines qualités du produit doivent être intégrées au processus plutôt qu'ajoutées à la fin. La navigation au clavier, un contraste lisible, des libellés explicites et des messages d'erreur clairs sont des propriétés du produit. Elles n'arrivent de façon fiable que si elles font partie de la manière dont le travail est conçu et relu. Des normes comme les Règles pour l'accessibilité des contenus web (WCAG) du W3C sont une référence pratique, mais respecter une checklist ne revient pas à être utilisable par tous. Suivre une norme est un minimum, pas une ligne d'arrivée.

Mesurer les résultats produit sans gonfler les affirmations

Les indicateurs de processus, comme les tickets fermés, la fréquence de déploiement ou les story points, décrivent l'activité. Les résultats produit décrivent si la situation des utilisateurs a changé : une tâche terminée plus vite, moins d'erreurs, un parcours moins souvent abandonné. Les deux sont utiles, mais seuls les résultats indiquent si le produit remplit son rôle. Choisissez une ou deux mesures de résultat liées à l'énoncé du problème avant de développer, pas après.

Faites attention à ce que les chiffres permettent réellement d'affirmer. Avec de petits groupes d'utilisateurs, des périodes courtes et des changements qui se chevauchent, il est risqué de tirer des conclusions fortes. La méthodologie publique d'IVRYN reflète cette retenue. Le studio privilégie un périmètre restreint, une utilité vérifiable et une automatisation qui reste responsable, et il évite les affirmations qui vont au-delà des preuves. L'automatisation dans le processus, comme les tests, les pipelines de déploiement ou le contenu généré, doit toujours avoir une personne responsable de ce qui parvient aux utilisateurs.

Exemple : une checklist de décision pour une équipe de trois personnes

Exemple (hypothétique) : une équipe de trois personnes a développé un outil interne de planification. Les utilisateurs le trouvent « laborieux », et l'équipe envisage une réécriture complète avec un nouveau mode de développement. Avant de décider, elle parcourt la checklist ci-dessous. Celle-ci l'aide à voir si le problème se situe dans le produit, dans le processus, ou dans les deux.

Dans ce cas hypothétique, les réponses suggèrent que le problème produit est une étape de réservation confuse. Le problème de processus vient du fait que chaque version regroupe de nombreux changements, ce qui masque les liens de cause à effet. La suite raisonnable consiste à publier une petite version qui corrige l'étape de réservation, et à s'engager à livrer un changement à la fois. C'est moins coûteux qu'une réécriture et plus facile à évaluer.

• Pouvons-nous énoncer le problème utilisateur en une phrase, en précisant qui le rencontre et quand ?
• Savons-nous quel livrable il nous faut ensuite : preuve de concept, prototype ou MVP ?
• La prochaine version peut-elle se décrire comme un seul changement observable ?
• Avons-nous choisi une mesure de résultat liée au problème, et non à l'activité de l'équipe ?
• L'accessibilité fait-elle partie de la revue de design, ou n'est-elle vérifiée qu'avant le lancement ?
• Chaque étape automatisée a-t-elle une personne nommément responsable de ce qu'elle produit ?
• Nos preuves soutiendraient-elles l'affirmation que nous comptons faire sur le résultat ?