Projet logiciel et produit logiciel

Projet logiciel et produit : deux engagements différents

Quand on cherche à comprendre la différence entre projet logiciel et produit, c'est généralement pour démêler deux mots employés indifféremment. Un projet logiciel est un travail borné : il a un périmètre, une échéance, un budget et un moment où il est déclaré terminé. Un produit logiciel est quelque chose que les gens continuent d'utiliser, il n'a donc pas de fin naturelle. On le juge à sa capacité à continuer de résoudre un problème pour un public défini.

Les deux sont légitimes. Une migration interne, une intégration ponctuelle ou un site de campagne se gèrent souvent mieux comme des projets. Un outil auquel les clients reviennent chaque semaine est un produit, même s'il a commencé comme un projet. Les difficultés commencent quand une équipe traite l'un comme l'autre : livrer un produit avec des habitudes de projet, ou alourdir une mission courte de rituels produit dont elle n'a pas besoin.

Ce qui change quand on parle de produit

L'étiquette détermine ce que signifie « terminé ». Dans un projet, terminé veut dire livré conformément à une spécification convenue. Dans un produit, la livraison marque le début de la collecte de preuves : on apprend si le problème était réel, si l'interface est utilisable et si les gens reviennent. Les éléments de la feuille de route deviennent donc des hypothèses plutôt que des promesses.

Cela change aussi la responsabilité et le coût. Un produit a besoin, après le lancement, d'une personne responsable du support, des corrections d'accessibilité, des mises à jour de sécurité et des petites améliorations. Si personne ne prendra ce travail en charge, il est plus honnête de cadrer l'effort comme un projet avec une date claire de transmission ou de retrait que de l'appeler produit et de le laisser se dégrader.

• Projet : le succès, c'est le périmètre convenu livré dans les délais et le budget
• Produit : le succès, c'est un changement mesurable pour un public identifié, maintenu dans la durée
• Dans les deux cas : un énoncé écrit du problème et de qui le rencontre

Commencer par la clarté du problème, puis livrer par petites étapes testables

Quel que soit le nom donné au travail, le premier livrable devrait être un énoncé du problème court et réfutable : qui rencontre une difficulté, laquelle, comment ces personnes s'en sortent aujourd'hui et ce qui s'améliorerait de façon visible. Si cela ne tient pas en quelques phrases, le périmètre n'est pas encore assez clair pour estimer un projet ou justifier un produit.

Ensuite, adaptez la réalisation à la question à laquelle vous devez répondre. Le guide d'IVRYN sur les prototypes, les MVP et les preuves de concept les distingue par leur finalité : un prototype explore l'expérience et vérifie si les gens la comprennent, une preuve de concept teste une hypothèse de faisabilité technique, et un MVP est une version réelle et bornée qui produit des preuves. Le guide précise explicitement qu'un MVP déployé ne prouve pas à lui seul l'adoption, le chiffre d'affaires ou l'adéquation produit-marché. Choisir le mauvais livrable gaspille des efforts, par exemple en peaufinant un MVP alors que la question ouverte est de savoir si une source de données est seulement accessible.

Les petites versions gardent projets et produits honnêtes. Chaque version devrait modifier une seule chose observable, afin qu'un résultat décevant pointe vers une cause plutôt que vers un empilement de changements simultanés. « Minimum » ne veut jamais dire non protégé : le guide rappelle qu'un MVP a toujours besoin d'authentification, de confidentialité, d'accessibilité, de gestion des erreurs, de supervision et de reprise partout où son contexte l'exige.

L'accessibilité et les résultats font partie de la définition

Un produit que certaines personnes ne peuvent pas utiliser a un public plus restreint que ne le suppose sa feuille de route. L'accès au clavier, un contraste lisible, des libellés clairs et des formulaires qui expliquent les erreurs méritent d'être prévus dès la première version ; à titre d'indication générale et non de constat mesuré, les ajouter après coup touche généralement une plus grande partie de l'interface. Les WCAG 2.2, que le guide d'IVRYN cite parmi ses sources principales, offrent une référence reconnue pour ces vérifications. Traitez-les comme des critères de mise en production, au même titre que les tests fonctionnels.

Les résultats mesurables complètent le tableau. Choisissez un ou deux signaux liés à l'énoncé du problème, comme les tâches accomplies sans aide ou la part des utilisateurs qui reviennent pour le même besoin, et décidez à l'avance quel résultat signifie continuer, changer de direction ou arrêter. Des totaux comme le nombre d'inscriptions montrent rarement si le problème est en train d'être résolu.

Exemple : cet outil de planification est-il un projet ou un produit ?

Il s'agit d'un exemple hypothétique, pas d'un cas traité par IVRYN. Une équipe de trois personnes au sein d'un petit réseau de cabinets médicaux veut un logiciel pour éviter les doubles réservations de salles. Le fondateur y voit un produit à vendre à d'autres cabinets ; le responsable des opérations y voit un projet interne.

En parcourant la checklist ci-dessous, l'équipe constate que le problème est clair pour ses propres sites mais non vérifié ailleurs. Une démarche raisonnable consiste à mener le développement interne comme un projet à périmètre fixe, tout en traitant la demande externe comme une hypothèse produit explorée avec un prototype présenté à quelques autres cabinets. Ce n'est que s'ils décrivent la même difficulté, et si quelqu'un est prêt à porter l'outil sur le long terme, qu'il passe au stade de MVP : un parcours de réservation borné, publié auprès d'utilisateurs réels, avec l'authentification, la confidentialité, l'accessibilité, la gestion des erreurs, la supervision et la reprise qu'exige une planification liée aux patients, et une décision identifiée que les preuves viendront éclairer.

• Pouvons-nous décrire le problème, le public et la solution de contournement actuelle en trois phrases ?
• Existe-t-il une date de fin naturelle, ou les gens s'appuieront-ils sur cet outil indéfiniment ?
• Qui prend en charge la maintenance, le support et l'accessibilité après la première version ?
• Quelle est la réalisation la moins coûteuse qui répond à notre question actuelle : preuve de concept, prototype ou MVP ?
• Quels un ou deux indicateurs montreront que cela fonctionne, et quel résultat signifie arrêter ?

Limites de ces conseils et cadre adopté par IVRYN

IVRYN, un studio parisien indépendant, gère chacun de ses produits comme une offre distincte, avec son propre domaine, ses utilisateurs cibles et sa page. Sa méthodologie publique décrit comment il construit, vérifie, exploite et explique ses produits, et fixe le niveau de preuve que ses notes de cas doivent atteindre, en privilégiant un périmètre resserré et une automatisation qui reste responsable. Cet article s'appuie sur cette position et sur le guide cité plus haut ; il ne rapporte aucune étude, aucun travail client ni aucun résultat mesuré, car aucun n'est revendiqué ici.

Ces conseils sont volontairement généraux. Les secteurs réglementés, les conditions contractuelles de livraison, les règles d'achat public et les logiciels critiques pour la sécurité peuvent imposer des exigences qui priment sur toute distinction entre projet et produit, et ces questions relèvent de conseillers qualifiés. Utilisez la checklist pour structurer une discussion, pas pour remplacer un examen par des spécialistes du domaine.