De l'idée au produit livré : les 5 étapes que je suis sur chaque projet
Beaucoup de projets échouent non pas parce que l'idée était mauvaise, mais parce que personne n'a posé les bonnes questions au bon moment. On code pendant six mois, on livre quelque chose de "fini"… que personne n'utilise. J'ai vu ce scénario se répéter dans des grands groupes comme dans des startups.
Après 11 ans dans le secteur — des datacenters de Cisco aux équipes produit de Chanel.com, en passant par Saana, un LLM médical souverain utilisé par des hôpitaux à Montpellier — j'ai affiné une façon de travailler qui évite ce piège. Voici les 5 étapes que j'applique sur chaque projet, avec ce que vous voyez concrètement à chaque stade.
Étape 1 — Cadrage & discovery : comprendre avant de construire
Avant d'ouvrir un éditeur de code, je consacre du temps à comprendre le problème réel. Pas le problème tel qu'il est formulé dans le brief, mais le problème tel qu'il existe pour les utilisateurs finaux.
Cette phase dure généralement une à deux semaines. On y définit ensemble :
- Qui utilise le produit et dans quel contexte (terrain, bureau, mobile, urgence ?)
- Quel est le périmètre minimal pour que le produit soit utile dès sa première version
- Ce qu'on ne fera pas — le périmètre exclu est aussi important que l'inclus
- Les critères de succès : comment saurons-nous que c'est un succès dans 6 mois ?
Ce que vous recevez à la fin de cette étape : un document de cadrage, une liste de fonctionnalités priorisées, et un premier chiffrage honnête. Pas de surprise budgétaire ensuite.
"Le périmètre exclu est aussi important que l'inclus."
Sur Saana, on a passé plusieurs semaines à interviewer des soignants avant d'écrire la première ligne de code. Ce travail en amont a évité de construire quelque chose de techniquement impressionnant mais inutilisable dans un couloir d'hôpital.
Étape 2 — Design & prototype : valider avant de coder
Une fois le périmètre posé, on conçoit. Maquettes, parcours utilisateurs, flux d'écrans. L'objectif est simple : vous permettre de réagir sur du concret avant que le développement commence.
Un prototype cliquable coûte dix fois moins cher à modifier qu'une application développée. C'est de la prévention, pas de la décoration.
Cette étape produit :
- Des maquettes de chaque écran principal
- Un prototype navigable que vous pouvez tester sur votre téléphone ou votre ordinateur
- Une session de validation avec vos futurs utilisateurs (même informelle, c'est précieux)
Vous gardez le contrôle : vous validez chaque écran, vous demandez des modifications, et le développement ne commence que quand vous êtes aligné sur ce que vous allez recevoir.
Étape 3 — Développement par sprints : des résultats réguliers, pas un tunnel
C'est ici que beaucoup de projets partent en vrille. On entre dans une "boîte noire" — des semaines sans nouvelle, puis une livraison globale qui ne correspond pas aux attentes.
Chez Twenty, on travaille en sprints de deux semaines. À chaque fin de sprint, vous participez à une démo : vous voyez ce qui a été construit, vous donnez votre retour, on ajuste pour le sprint suivant. Pas de tunnel, des résultats réguliers.
Cette approche, je l'ai rodée sur des contextes très différents — 6 équipes agiles simultanées chez Air Liquide, 110 personnes pilotées sur une roadmap produit, 2 équipes Scrum pour les pages produit de Chanel.com. À chaque fois, le principe est le même : le client voit l'avancée, et peut infléchir le cours du projet avant qu'il soit trop tard.
Ce que vous voyez à chaque sprint :
- Une version fonctionnelle, testable, du produit
- Un tableau de bord simple : ce qui est fait, ce qui est en cours, ce qui est prévu
- Un point de synchronisation pour décider des priorités suivantes
Concrètement, cette méthode nous a permis de réduire le temps de livraison de 30 % en moyenne sur nos projets.
Étape 4 — Mise en marché & lancement : le produit ne s'arrête pas à la mise en production
Mettre un produit en production, c'est une étape. Le faire adopter par ses utilisateurs, c'en est une autre. Et souvent, c'est là que les projets stagnent.
Le lancement chez Twenty couvre :
- La mise en production dans un environnement sécurisé (hébergement souverain si nécessaire, comme pour Saana)
- La formation des utilisateurs — pas un manuel de 80 pages, mais des sessions courtes, pratiques, adaptées au terrain
- Le suivi d'adoption les premières semaines : qui utilise le produit ? Quels écrans bloquent ?
Un produit livré mais non utilisé n'a aucune valeur. L'adoption fait partie du contrat.
Sur School Run — une application de calcul mental gamifiée que j'ai co-fondée, aujourd'hui dans 8 pays et 4e du Google Play Store dans sa catégorie — on a appris que la qualité du lancement conditionne la trajectoire à long terme. Un démarrage raté se rattrape difficilement.
Étape 5 — Run & amélioration continue : vous gardez le contrôle, on gère la technique
Une fois le produit lancé, la vie continue. Les utilisateurs remontent des retours, les besoins évoluent, la technologie avance. C'est le quotidien du Run.
Chez Twenty, vous pouvez nous déléguer :
- L'hébergement et la disponibilité de l'application
- La maintenance corrective et évolutive
- La sécurité — mises à jour, audits, conformité RGPD
- Les itérations futures, planifiées en fonction de vos priorités business
Vous gardez le contrôle via un reporting mensuel clair et des points réguliers. Vous décidez des priorités, on s'occupe de l'exécution. C'est exactement ce que je propose à mes clients qui ne veulent pas gérer une équipe technique en interne, mais qui veulent un produit qui évolue.
Ce que cette méthode change concrètement
Ce que cette méthode n'est pas
Elle n'est pas une recette magique. Elle demande de votre côté une implication régulière — pas intensive, mais régulière. Trente minutes par semaine pour valider une démo, c'est ce qui fait la différence entre un produit qui vous ressemble et un produit générique.
Elle n't adapte pas non plus à tout le monde : si vous cherchez quelqu'un pour exécuter un cahier des charges figé sans discussion, ce n'est pas ce que je propose. Mon rôle est d'être un partenaire, pas un prestataire exécutant.
Parlons de votre projet
Vous avez une idée de produit, un projet en cours qui patine, ou une équipe à structurer ? Je prends le temps d'un premier échange gratuit pour comprendre votre contexte et vous dire honnêtement ce que je peux apporter.
Contactez-moi directement :
- WhatsApp : +33 6 34 42 50 56
- Email : contact@twentyconsultancy.com
- LinkedIn : Dibrilou Diagne
Un projet bien cadré, c'est un projet qui a des chances d'aboutir. Commençons par là.