Votre idée devient un produit utilisable. En deux semaines.

Le Design Sprint est né chez Google, rodé chez Google Ventures, repris par des équipes comme Slack ou LEGO : quelques jours pour décider, au lieu de mois de réunions. Il s'arrête d'habitude à une maquette. L'IA est ce qui permet de continuer : trois jours pour une première version utilisable, et le code source à vous.

Non. L'IA raccourcit la construction. Le lead design et le lead dev préparent le terrain avec vous : ce qui est gardé, ce qui est écarté, et comment le projet pourra être déployé ensuite. Vous repartez avec le code source, pas avec une boîte noire.

Non. Vous venez avec votre activité, vos clients et ce que vous voulez leur proposer. Nous venons avec les designers et les développeurs. Si un mot vous échappe, on le traduit.

Ce sont les fichiers qui font fonctionner le produit. Les posséder, c'est pouvoir le faire évoluer plus tard : avec nous, avec une personne que vous recrutez, ou avec une autre équipe. Vous n'êtes pas lié à Dev Together pour que le produit continue d'exister.

Une maquette montre l'intention. On peut parfois cliquer dessus, mais elle ne rend pas le service. Ici, les trois derniers jours servent à construire une première version utilisable. Le dessin n'est qu'une étape, pas le livrable.

Non, et ce n'est pas magique. On construit la première version utile : celle qui permet de montrer, de faire essayer, de voir si l'idée tient. Le lead design et le lead dev en profitent pour préparer le déploiement complet, ce qui vient après, sans repartir de zéro. Le périmètre de ces deux semaines est le sujet des deux premiers jours.

Pas de cahier des charges. Venez avec ce que vous savez de vos clients, un exemple de ce qui vous frustre aujourd'hui, et le résultat que vous aimeriez pouvoir montrer dans deux semaines. Le reste se précise ensemble.

C'est prévu. L'agilité du sprint tient dans ces cinq jours : on cherche, on écarte, on change de cap ensemble, avant de construire. Le tableau de bord garde la trace. Mieux vaut trancher autrement le quatrième jour que de livrer la mauvaise chose.

La documentation technique et les cartes sont en option. Les cartes décrivent, écran par écran, ce qui a été décidé. La documentation explique comment le produit est construit. Les deux servent surtout si une autre équipe reprend le sujet plus tard. Elles ne sont pas nécessaires pour utiliser la première version. Le nom de domaine, l'hébergement et la suite éventuelle se décident à part, avant d'engager la dépense.

Vous le faites avec nous. La coconstruction, c'est votre place dans les décisions : ce qu'on garde, ce qu'on laisse, ce qu'on ajuste. Nous amenons les designers, le tableau de bord et les développeurs. Vous n'avez pas à dessiner ni à coder pour être décideur.

Non. Vous pouvez vous arrêter, montrer le produit, ou continuer le déploiement complet avec nous. Le même lead design et le même lead dev peuvent porter la suite. Dans tous les cas, le code source vous appartient.