De l'idée au produit : les 11 jalons.

La carte du projet

Onze jalons, dans cet ordre. Chacun produit quelque chose de vérifiable : un document, une maquette, un logiciel qui tourne. Un jalon sans livrable n'est pas un jalon, c'est une réunion.

Phase 01 — Penser

On transforme une intuition en plan de fabrication. Aucune ligne de code n'est écrite. C'est contre-intuitif quand on est pressé, et c'est ce qui fait la différence entre un projet qui tient son budget et un projet qui double.

Jalon 01 — Cadrage et discovery

On aligne tout le monde sur le pourquoi, le pour qui et le périmètre. Tout ce qui suit y fera référence. Quatre-vingts pour cent des dérives projet viennent d'un cadrage bâclé — c'est le jalon qu'on a le plus envie de sauter, et celui qu'il ne faut jamais sauter.

On y travaille :

• La vision et des objectifs business mesurables.
• Les cibles utilisateurs prioritaires.
• La définition du MVP — ce qui sort en v1, ce qui attend.
• Les contraintes réelles : budget, délais, équipe, obligations légales.
• Les risques connus et les hypothèses à valider.

Livrables : une note de cadrage de dix à quinze pages, un backlog initial priorisé MVP / v2, une roadmap macro, une enveloppe budgétaire par phase. Durée : une à trois semaines.

Jalon 02 — Cahier des charges fonctionnel et technique

Le CDC fonctionnel répond à quatre questions : qui (les types d'utilisateurs et leurs droits), quoi (la liste exhaustive des fonctionnalités, par module), comment (les parcours écran par écran, cas nominaux et cas d'erreur) et pourquoi (l'intention métier derrière chaque fonctionnalité).

Le CDC technique précise, lui :

• La stack web — front, back, base de données.
• La stack mobile — natif ou cross-platform.
• L'hébergement et l'infrastructure.
• Les intégrations tierces : paiement, mail, SMS.
• Les exigences de sécurité et de conformité RGPD.
• La performance et la charge attendue.

Livrables : un CDC de quarante à soixante pages, les spécifications d'API, le schéma de base de données. Si vous arrivez avec un pré-cahier des charges déjà écrit, on gagne une à deux semaines.

Jalon 03 — UX research et personas

On confronte le produit imaginé à de vrais utilisateurs, avant de dessiner. Mieux vaut découvrir un malentendu sur une feuille de papier que sur trois mois de code.

Règle d'or : cinq à huit entretiens suffisent pour faire émerger l'essentiel des problèmes d'usage. Au-delà, on confirme ce qu'on sait déjà. Quarante-cinq minutes par entretien, retranscrits et analysés, plus trois à quatre personas, un parcours type de la découverte à la fidélisation, et un benchmark de cinq à dix produits du marché.

Le bénéfice réel : cette étape élimine en général près d'un tiers des fonctionnalités initialement prévues. Ce n'est pas une dépense, c'est une économie — et elle arrive avant que le code ne soit écrit.

Jalon 04 — Wireframes et maquettes

On dessine d'abord en noir et blanc, puis on habille. Cette séparation a une raison précise : elle évite de débattre de la couleur du bouton avant d'être d'accord sur le parcours.

• Wireframes low-fi — zonage, hiérarchie, parcours. On valide la structure.
• Wireframes hi-fi — composants détaillés, micro-copy, et les états qu'on oublie toujours : vide, erreur, chargement.
• Maquettes finales — couleurs, typographie, illustrations. Le produit est vu pour la première fois.

Pour le web responsive, iOS et Android. Sous Figma, avec un design system partagé, et une revue écran par écran avec vous.

Jalon 05 — Prototypage

Les maquettes s'animent : on teste le parcours sur un téléphone comme si le produit était développé. Ce n'est encore que du dessin animé, et c'est exactement ce qu'il faut à ce stade.

• Tester avec cinq utilisateurs — observer où ça coince, corriger sans coût.
• Convaincre — investisseurs, partenaires, premiers clients voient tous la même chose.
• Cadrer le développement — moins de zones grises, moins d'aller-retours.
• Affiner le chiffrage — sur un prototype solide, l'estimation technique est précise à ±10 %.

C'est le point de bascule du projet. À la fin de la phase 01, vous avez quelque chose à montrer, à tester et à chiffrer précisément, et vous avez engagé environ un quart du budget. Si le projet doit être abandonné ou repensé, c'est ici que ça coûte le moins cher.

Phase 02 — Construire

Jalon 06 — Développement par sprints

On fabrique par cycles de deux semaines. À chaque fin de cycle, vous voyez du concret. Pas de tunnel de six mois.

L'anatomie d'un sprint :

• Lundi, semaine 1 — planification. On choisit ce qu'on livre.
• Chaque jour — point de quinze minutes, l'équipe seule.
• Deux semaines — fabrication, avec la QA en continu.
• Vendredi, semaine 2 — démonstration. Vous validez ce qui est livré.
• Vendredi, semaine 2 — rétrospective. Ce qui a bien et mal marché.

Comptez six à dix sprints pour un MVP web et mobile, et de votre côté environ deux heures par semaine : une démonstration, un point d'arbitrage. Ce n'est pas négociable à la baisse — un projet sans arbitre disponible s'enlise.

Jalon 07 — QA et tests

On ne livre pas du code aux utilisateurs, on livre du code testé. La qualité n'est pas une phase à la fin : elle est continue, dès le premier sprint.

• Tests unitaires — chaque brique est vérifiée, automatiquement.
• Tests d'intégration — les briques fonctionnent ensemble.
• Tests de bout en bout — le parcours utilisateur se déroule sans casse, sur les chemins critiques.
• Recette manuelle — on vit le produit comme un vrai utilisateur. Celle-là ne s'automatise pas.

Et trois niveaux de défauts, avec une règle claire pour chacun :

Avant la mise en production : deux à quatre semaines de recette finale. Vous testez le produit complet sur vos vrais appareils, et dix à vingt bêta-testeurs externes le font aussi.

Jalon 08 — Mise en production

Le jour J. Ce n'est pas une ligne d'arrivée, c'est une ligne de départ. La stratégie qui marche se déroule en trois temps :

• J-30, mise en ligne discrète — accès restreint à un cercle proche. On observe.
• J-15, bêta ouverte — inscription libre, communication maîtrisée. On absorbe les premiers retours.
• J0, lancement public — communication, marketing, partenaires. Le produit est stabilisé.

Ce qui doit être en place avant, du domaine aux sauvegardes en passant par le plan de retour arrière, tient en dix-huit points : la checklist avant lancement.

Phase 03 — Faire vivre

Jalons 09 et 10 — Mesurer, puis itérer

Sans données, on dispute des opinions. Avec des données, on tranche en cinq minutes. L'analytics s'instrumente pendant le développement, pas après — rajouter la mesure sur un produit déjà lancé coûte trois fois plus cher.

Quatre familles d'indicateurs suffisent pour commencer :

Puis un rythme d'itération après le lancement :

• J+30 — premier bilan. Données chaudes, retours utilisateurs, gains rapides identifiés.
• J+90 — décision v1.1. Ce qu'on garde, ce qu'on retire, ce qu'on ajoute en priorité.
• J+180 — cadrage v2. Sur base réelle cette fois. On reprend le cycle, en plus court.

Jalon 11 — Gouvernance

Transverse, du premier au dernier jour. Un projet qui patine est presque toujours un projet où personne ne sait qui décide. Deux associés qui se contredisent valent mieux qu'aucun arbitre, mais pas de beaucoup.

On pose donc les rôles dès le cadrage. Quatre acteurs : vous, la direction de projet, l'équipe de développement, et les utilisateurs. Selon votre organisation, nous tenons la direction de projet et le développement, ou seulement le développement sous votre pilotage.

Vision et stratégie produit

Vous tranchez et vous produisez. La direction de projet est consultée, les utilisateurs aussi.

Cahier des charges fonctionnel

Vous tranchez. La direction de projet rédige. L'équipe technique et les utilisateurs sont consultés.

Choix techniques — stack, architecture

L'équipe de développement tranche et produit. Vous êtes informé, la direction de projet consultée. C'est le seul sujet où vous ne décidez pas : vous en portez les conséquences, pas l'expertise.

Design et parcours utilisateur

Vous tranchez. La direction de projet produit. Équipe technique et utilisateurs consultés.

Priorisation du backlog

Vous tranchez. La direction de projet produit et propose. L'équipe technique est consultée sur la faisabilité.

Qualité du code livré

L'équipe de développement tranche et produit. Vous êtes informé. C'est notre responsabilité, pas la vôtre.

Recette et validation finale

Vous tranchez — c'est vous qui acceptez ou refusez la livraison. La direction de projet organise.

Mise en production

Vous tranchez le moment. L'équipe de développement exécute.

Communication de lancement

Vous tranchez et vous produisez. La direction de projet est consultée.

Comment se répartit une enveloppe

Les montants dépendent du périmètre ; les proportions, beaucoup moins. Sur un produit web et mobile construit de zéro, la répartition tourne autour de ceci :

Deux mises en garde. La réserve n'est pas de la graisse : un projet sans réserve arbitre au rabais dès le premier imprévu. Et ces ratios ne couvrent pas les coûts récurrents après le lancement — hébergement, licences, supervision, support. Chez nous cette ligne est de 800 € HT par mois ; ailleurs elle porte un autre nom, mais elle existe toujours.

Pour les ordres de grandeur en euros et un projet réel chiffré, voir combien coûte l'externalisation du développement.

Les sept pièges classiques

Aucun n'est théorique. Chacun coûte cher, et chacun s'évite par construction si la méthode est tenue.

01 · « On verra à l'usage »

Lancer le développement sans cahier des charges clair. Coût caché : deux à trois fois le prix, en aller-retours et en reprises.

02 · Tout faire en v1

Vouloir lancer un produit « complet ». Un MVP n'est pas un produit pauvre, c'est un produit focalisé.

03 · Aucun utilisateur testé

Concevoir entre soi. On découvre les vrais problèmes après trois mois de développement — trop tard.

04 · Le gros tunnel

Six mois sans rien voir, puis une grosse livraison. Toujours décevant. Mieux vaut des petits pas visibles.

05 · Pas de décideur unique

Deux associés qui se contredisent, et le projet s'enlise. Il faut définir qui tranche, sujet par sujet.

06 · Sous-traiter sans piloter

Confier le projet « clés en main » sans vérification continue. Risque sur la qualité comme sur le périmètre — y compris avec nous.

07 · Oublier l'après-lancement

Tout le budget englouti au lancement. Sans v1.1, un produit meurt en six mois. Gardez de quoi continuer.

Ce que l'IA change dans cette méthode

Nous utilisons Claude Code et Claude Design en production, tous les jours. Ce n'est pas un argument de vente : c'est un outil de fabrication qui change ce que vous obtenez pour le budget engagé.

• Côté fabrication — écriture accélérée, tests générés, revue de code à chaque livraison, documentation technique tenue à jour plutôt que promise.
• Côté conception — prototypes cliquables en heures plutôt qu'en semaines, donc plus d'itérations de design possibles dans la même enveloppe, avant que le code ne coûte cher.

L'IA exécute, l'humain décide. Un développeur senior relit, corrige et signe chaque livraison ; aucune décision produit n'est déléguée à la machine. Vous gardez la main à chaque étape, et les droits de fusion sur votre dépôt.

Les quatre premières semaines

Concrètement, si on travaille ensemble sur un projet complet :

• Semaine 1 — atelier de cadrage. Deux jours ensemble. On en sort avec une note de cadrage validée.
• Semaine 2 — cahier des charges. On consolide, on chiffre précisément. Engagement budgétaire ferme à l'issue.
• Semaine 3 — UX research. Entretiens, personas, benchmark. Vous repartez avec une dizaine d'enseignements actionnables.
• Semaine 4 — premiers wireframes. Le produit prend forme, sans qu'une ligne de code ait été écrite.

Un projet digital ne s'improvise pas : il se pilote. Et la plupart des projets qui échouent n'échouent pas sur la technique.