Vous avez une idée d'application métier, mais personne dans l'équipe ne sait encore si elle répond au bon problème. Le design sprint compresse en cinq jours ce qui traîne d'habitude pendant des semaines de réunions : cadrer la question, esquisser des solutions, trancher, fabriquer un prototype et le confronter à de vrais utilisateurs. Voici comment le mener sur un projet d'application sur mesure, et ce qu'il faut faire des résultats une fois le sprint terminé.

Le design sprint, une méthode née chez Google Ventures

La méthode a été mise au point par Jake Knapp au sein de Google Ventures entre 2010 et 2012, avant d'être formalisée et popularisée en 2016 dans le livre Sprint : résoudre les problèmes et tester de nouvelles idées en cinq jours, coécrit avec John Zeratsky et Braden Kowitz. L'idée de départ est simple : plutôt que de discuter indéfiniment d'une direction produit, on la teste en une semaine, avec une équipe resserrée et un protocole strict, avant d'engager le développement. Le design sprint ne remplace pas le développement d'une application métier : il sert à décider, avant d'écrire la première ligne de code utile, quelle version tester en premier.

Cinq jours, cinq étapes

Le déroulé original tient sur cinq journées consécutives, chacune avec un objectif fermé.

  • Jour 1, comprendre : l'équipe cartographie le problème, interroge les experts internes disponibles et fixe une question à laquelle le sprint doit répondre à la fin de la semaine.
  • Jour 2, diverger : chacun esquisse des solutions individuellement, sur papier, sans discussion collective prématurée qui écraserait les idées les moins consensuelles.
  • Jour 3, décider : les croquis sont affichés, critiqués en silence puis votés ; un décideur unique tranche la direction retenue pour éviter le compromis mou qui ne satisfait personne.
  • Jour 4, prototyper : l'équipe fabrique une façade cliquable, pas une application fonctionnelle : suffisamment crédible pour être testée, assez rapide à produire pour rester jetable.
  • Jour 5, tester : cinq entretiens individuels avec de vrais utilisateurs du métier concerné suffisent, dans la tradition des tests qualitatifs à petit échantillon, à faire remonter l'essentiel des problèmes d'utilisabilité.

Avant de lancer le sprint : ce qu'il faut réunir

Un design sprint mal préparé produit un joli prototype et aucune décision. Trois conditions conditionnent son utilité : une question fermée et testable, pas un vague « améliorons l'expérience » ; une équipe de cinq à sept personnes maximum, mêlant expertise métier, technique et un décideur qui a le dernier mot le jour 3 ; et un accès réel à des utilisateurs du métier pour le jour 5, réservé plusieurs jours à l'avance. Sans ce dernier point, mieux vaut décaler le sprint que le mener à vide.

Prioriser sans se mentir : la méthode MoSCoW

Le sprint fait remonter beaucoup plus d'idées qu'il n'en tient dans un premier prototype utile. La méthode MoSCoW, inventée par Dai Clegg vers 1994 et diffusée dans le cadre de la méthode DSDM (Dynamic Systems Development Method), donne un vocabulaire pour trancher sans s'éterniser : Must have, les fonctions sans lesquelles l'application n'a pas de sens ; Should have, importantes mais pas bloquantes pour un premier test ; Could have, un confort si le temps le permet ; Won't have this time, explicitement écarté de cette version, pas oublié pour autant. Appliquée à la sortie du sprint, elle sépare ce qui doit figurer dans le prototype testé le jour 5 de ce qui peut attendre une itération suivante, et elle donne un langage commun au commanditaire métier et à l'équipe technique pour ne pas rouvrir le débat à chaque réunion.

Du sprint au backlog : ce qui devient réellement du code

Un design sprint réussi se termine par une décision écrite, pas par un enthousiasme collectif. Ce qui doit sortir de la semaine : la question tranchée (on construit, on retravaille le prototype, ou on arrête), les retours des cinq entretiens classés par gravité, et un premier backlog produit hiérarchisé avec le vocabulaire MoSCoW. C'est ce backlog, pas le prototype cliquable lui-même, qui sert de base au chiffrage du développement réel. Le prototype du jour 4 est jetable ; le classement Must, Should, Could ne l'est pas, il continue de guider les arbitrages une fois le développement commencé.

Ce qu'un design sprint ne remplace pas

Le Standish Group, dans son rapport CHAOS 2020, chiffrait à 69 % la part des projets informatiques qui n'aboutissaient pas pleinement au succès (50 % de projets « challenged », livrés en retard, hors budget ou avec un périmètre réduit, et 19 % d'échecs purs), contre 31 % de succès complet. Un design sprint réduit le risque de construire la mauvaise chose, mais il ne sécurise ni la donnée, ni l'intégration avec l'existant, ni la charge réelle en production : ces questions se traitent en parallèle ou juste après, avant d'engager le développement complet.

Cinq erreurs reviennent souvent : convoquer toute l'équipe projet plutôt qu'un groupe resserré avec un vrai décideur ; sauter le jour 1 de cadrage pour foncer sur les solutions ; tester le prototype auprès de collègues au lieu d'utilisateurs réels du métier ; laisser le backlog du sprint dans une présentation qui ne sera jamais rouverte ; et vendre le prototype du jour 4 comme une version bêta alors qu'il n'est pas fonctionnel.

Questions fréquentes

Combien coûte un design sprint ?

Le coût principal est le temps immobilisé : cinq journées pleines pour cinq à sept personnes, plus la préparation des entretiens utilisateurs. Il n'y a pas de licence logicielle obligatoire ; un espace de travail, du papier et un outil de prototypage suffisent.

Peut-on faire un design sprint à distance ?

Oui, avec un tableau collaboratif en ligne pour les votes et les croquis, et des créneaux vidéo dédiés pour les entretiens du jour 5. La discipline du protocole, silence pendant les croquis et décideur unique, compte davantage que le lieu.

Le design sprint remplace-t-il le cahier des charges ?

Non. Il précède et nourrit le cahier des charges : il valide la direction et priorise les fonctions avant que le document de spécification ne soit rédigé, ce qui évite de spécifier en détail une fonctionnalité qui sera abandonnée après le test utilisateur.

Que faire si le test du jour 5 est négatif ?

C'est un résultat utile, pas un échec du sprint : mieux vaut le découvrir en une semaine sur un prototype jetable qu'après plusieurs mois de développement. La décision peut être de retravailler le prototype, de changer d'hypothèse, ou d'arrêter.

Un design sprint bien mené ne dispense pas de bâtir l'application ensuite, mais il évite de la bâtir sur une hypothèse jamais testée. Parlons de votre projet pour cadrer le vôtre avant d'engager le développement.