Une idée logicielle prometteuse peut sembler évidente dans une conversation : rendre une tâche plus rapide, supprimer une frustration quotidienne ou connecter des services qui ne fonctionnent pas bien ensemble. Transformer cette idée en un produit réellement utilisable est plus difficile. Les équipes doivent déterminer quel problème elles résolvent, décider ce qu’elles doivent construire en premier et continuer à vérifier si le résultat convient à de vrais utilisateurs.
Ce processus commence avant que quiconque n’écrive du code. La première étape pratique consiste à décrire le problème en termes simples. Qui le rencontre ? Que cherche-t-il à faire ? Qu’est-ce qui rend la tâche difficile aujourd’hui ? Une équipe incapable de répondre à ces questions risque de produire une solution élégante pour résoudre le mauvais problème.
Bjarne Stroustrup, l’informaticien qui a créé C++, a résumé ce défi ainsi : « L’aspect le plus important du développement logiciel est d’avoir une idée claire de ce que l’on cherche à construire. » Cette citation figure dans un recueil de citations sur l’ingénierie logicielle ; le conseil qu’elle contient constitue également un test utile pour les équipes produit. Si l’équipe ne peut pas expliquer le résultat visé sans recourir au jargon technique, elle n’a peut-être pas encore défini un objectif suffisamment clair.
Une étape suivante utile consiste à identifier les hypothèses cachées dans l’idée. Peut-être les clients utiliseront-ils le produit chaque semaine. Peut-être paieront-ils pour une fonctionnalité qui leur prend actuellement plusieurs heures à réaliser manuellement. Peut-être un système existant sera-t-il facile à connecter. Ce ne sont pas des faits tant qu’ils n’ont pas été testés. Les équipes peuvent interroger des utilisateurs potentiels, étudier les flux de travail existants, créer un prototype approximatif ou mener un petit essai avant de s’engager dans un effort de développement majeur.
L’objectif n’est pas d’éliminer toute incertitude avant le début du développement. Cela est rarement possible. Il s’agit plutôt d’identifier tôt les hypothèses les plus risquées, à un moment où changer de direction reste relativement peu coûteux. Un croquis ou un prototype cliquable peut révéler que les utilisateurs ne comprennent pas l’interface. Une courte expérimentation technique peut montrer si une intégration envisagée est réalisable. Un petit pilote peut permettre de vérifier si un flux de travail s’intègre aux habitudes des clients.
C’est pourquoi le développement produit réussi est rarement un chemin direct, de l’idéation au lancement. Philippe Heilman, fondateur et PDG d’une entreprise proposant des solutions logicielles sur mesure, a mentionné que « une grande partie de l’essence de la construction d’un programme réside, en réalité, dans le débogage de la spécification ». Autrement dit, les équipes ne déboguent pas seulement le code ; elles découvrent et corrigent également les malentendus concernant ce que le logiciel doit faire.
Définir ce que doit faire la première version
Une fois le problème compris, l’équipe doit réduire le périmètre. La première version devrait résoudre une partie significative du problème, sans chercher à inclure toutes les fonctionnalités que quelqu’un pourrait éventuellement souhaiter. Un produit doté d’un objectif central clair est plus facile à construire, tester, expliquer et améliorer.
Cela ne signifie pas livrer quelque chose d’peu fiable. Une version réduite doit néanmoins bien fonctionner pour les personnes qu’elle est censée servir. La distinction se situe entre la réduction du périmètre et la baisse de la qualité. Par exemple, un produit de planification peut commencer avec une seule intégration de calendrier et un processus de réservation fiable, plutôt qu’avec une douzaine d’intégrations et des rapports avancés. L’équipe peut ajouter des fonctionnalités une fois qu’elle sait lesquelles les clients nécessitent réellement.
Leah Culver, entrepreneure dans le domaine du logiciel, a exprimé une idée similaire dans une citation recueillie par Kartaca : « Apprenez à ne pas ajouter trop de fonctionnalités tout de suite, et construisez et testez d’abord l’idée centrale. » Ce conseil est particulièrement pertinent lorsque la liste des fonctionnalités commence à croître plus vite que la compréhension qu’a l’équipe de ses clients.
Les équipes peuvent rendre la priorisation plus concrète en posant trois questions pour chaque fonctionnalité proposée : Aide-t-elle à résoudre le problème central de l’utilisateur ? Quels éléments montrent que les utilisateurs en ont besoin ? Quelle complexité supplémentaire introduira-t-elle ? Ces questions ne produisent pas un classement parfait, mais elles aident à relier les décisions à l’objectif du produit, plutôt qu’à l’enthousiasme pour une technologie particulière ou à une demande insistante d’une seule partie prenante.
Construire par étapes courtes et révisables
Une fois le périmètre initial convenu, le développement peut avancer par petits incréments. Divisez le travail en éléments qui peuvent être implémentés, examinés et testés sans attendre que le produit entier soit terminé. Des démonstrations fréquentes permettent à l’équipe de repérer les lacunes alors qu’il reste encore du temps pour y répondre.
Cette approche modifie également la manière de planifier. Un plan n’est pas la promesse que chaque détail est connu à l’avance. C’est une estimation provisoire, fondée sur les meilleures informations disponibles, qui doit être mise à jour lorsque les éléments de preuve évoluent. En 2001, les auteurs du Manifeste pour le développement logiciel agile ont écrit qu’ils accordaient de la valeur à « répondre au changement plutôt que suivre un plan ». Ils ont également écrit que le « logiciel fonctionnel » compte plus que la « documentation exhaustive », tout en précisant que les éléments situés à droite conservent leur valeur.
Cette nuance est importante. Le développement agile ne signifie pas abandonner la planification ou la documentation. Il signifie les considérer comme des outils, et non comme des substituts au travail avec les utilisateurs et à la livraison de logiciels. Les équipes ont toujours besoin d’une documentation suffisante pour expliquer les décisions, faciliter la maintenance et intégrer de nouveaux collègues. Elles devraient éviter de produire des documents que personne n’utilise, uniquement pour montrer qu’un processus a été suivi.
Les tests font partie de l’ensemble du travail, et pas seulement de sa phase finale. Les tests automatisés peuvent vérifier que les fonctions importantes continuent de se comporter comme prévu lorsque le code évolue. Les tests manuels permettent d’évaluer si un flux de travail est logique pour une personne utilisant le produit. Les équipes doivent également tester dans des conditions proches de l’utilisation réelle, plutôt que de supposer qu’une fonctionnalité qui fonctionne sur l’ordinateur d’un développeur fonctionnera pour tout le monde.
Le lancement est une étape d’apprentissage
Un lancement est souvent considéré comme une ligne d’arrivée. Pour une équipe logicielle, il s’agit plus précisément du moment où le produit rencontre un éventail plus large d’utilisateurs, d’appareils, de données et d’attentes. L’équipe doit prévoir comment elle gérera les signalements de défaillances, mesurera si les utilisateurs peuvent accomplir les tâches importantes et déterminera comment prioriser ce qu’elle apprend.
Avant la mise en ligne, les équipes peuvent réduire les risques en testant le produit avec un petit groupe, en préparant un plan de retour arrière et en surveillant le produit après son déploiement. Elles doivent faciliter le signalement des problèmes par les utilisateurs et la compréhension de ce qui s’est produit par l’équipe. Une liste de contrôle de lancement peut inclure la vérification des parcours utilisateurs essentiels, le contrôle des droits d’accès, la documentation des limites connues et l’attribution de responsabilités pour la surveillance du système.
Après le lancement, la mesure devrait porter sur les résultats plutôt que sur des indicateurs vaniteux. Le nombre de téléchargements ne suffit pas à montrer si un produit résout le problème. Des signaux plus utiles peuvent inclure la capacité des utilisateurs à accomplir une tâche clé, la fréquence de leurs retours, la durée de la tâche ou l’endroit où ils abandonnent un parcours. Les meilleures mesures dépendent du produit et de l’objectif fixé par l’équipe au départ.
Le cycle de développement recommence alors : recueillir des données, décider quoi améliorer et livrer la prochaine évolution utile. Le produit peut avoir besoin de nouvelles fonctionnalités, mais il peut aussi avoir besoin d’instructions plus claires, de moins d’étapes, d’une meilleure fiabilité ou d’une conception plus simple.
Mike Krieger, cofondateur d’Instagram, est cité par Kartaca : « On ne peut pas lancer un produit simplement en le construisant. Il faut savoir pourquoi on le construit, sinon on peut s’engager dans une mauvaise direction, perdre du temps et semer la confusion. Passer de longs après-midis avec un carnet de croquis ou discuter de ses idées avec d’autres personnes peut permettre d’économiser une année de développement logiciel par la suite. »
Le chemin qui mène de l’idée au lancement n’est pas une formule rigide. C’est une méthode disciplinée d’apprentissage : définir le problème, tester les hypothèses, construire une première version ciblée et prêter attention à ce qui se passe lorsque les gens l’utilisent. Une équipe qui considère chaque version comme une occasion d’apprendre est mieux placée pour créer un logiciel qui reste utile une fois passée l’enthousiasme initial.
