Comment je cadre un projet tech avant d'écrire la première ligne de code

Dans mon expérience, un projet tech peut perdre 3 à 6 mois avant même la première PR. Pas à cause du code, mais à cause d'un cadrage incomplet : mauvais problème, mauvais scope, mauvaises hypothèses.

En tant que partenaire tech, mon rôle ne commence pas au premier sprint. Il commence bien avant, au moment où le fondateur essaie de traduire une idée en quelque chose de réalisable. SaaS, webapp, app mobile : le type de produit change, mais les questions de cadrage restent les mêmes. À travers plusieurs projets, voici comment j'aborde cette phase.

Parce que ce qui se décide avant le code détermine souvent plus que le code lui-même.

Pourquoi la plupart des projets tech dérapent avant le code

Le schéma classique est toujours le même : idées ambitieuses, backlog trop large, stack choisie par habitude, puis première itération qui livre beaucoup de features et peu de résultat.

L'approche naïve, en général, consiste à choisir des technologies "modernes", lister 20 à 40 fonctionnalités, puis lancer le développement pour "apprendre en faisant". Le problème business est immédiat. Quand le besoin réel n'est pas clarifié, on optimise la vitesse de production, pas la valeur produite. Le coût monte vite, la confiance descend vite, ce qui aboutit au pire scénario : beaucoup de code, très peu d'impact.

Prenons l'exemple du projet INSTAT (Institut National de la Statistique de Madagascar), sur lequel je suis intervenu en tant que développeur en 2021 et qui nous servira de fil rouge pour cet article. La demande initiale de l'institution était : "Nous voulons un système pour recruter des enquêteurs en masse".

C'est typiquement le genre de brief qui pousse à l'erreur sans cadrage au préalable. Le projet était parti dans une direction où l'on prévoyait de développer, dès le MVP, un test de personnalité par IA pour chaque enquêteur. C'était impressionnant sur le papier, mais ce n'était ni aligné avec la priorité business, ni avec le budget. Le vrai enjeu, beaucoup plus terre-à-terre, était de pouvoir filtrer les enquêteurs géographiquement pour affecter ceux qui étaient déjà sur place, afin de réduire drastiquement les coûts logistiques.

Cette dérive technique, qui consiste à construire une fonctionnalité complexe plutôt que de résoudre le vrai problème business, je l'ai rencontrée avec plusieurs équipes sur des projets très différents.

Pour éviter ces dérapages coûteux et protéger le budget de mes clients, j'ai créé cette méthode de cadrage stricte. Avant même d'ouvrir le moindre backlog, il faut absolument clarifier trois choses :

1. Quel est le vrai problème ?
2. Qu'est-ce qu'on construit en premier ? (MVP)
3. Comment on sait si ça marche ? (KPI)

Cadrer le problème d'abord

Le point de départ n'est jamais la stack. C'est une phrase business testable:

"Pour [persona], je cherche à réduire [douleur] de [état actuel] à [état cible] en [délai]."

Cette phrase a l'air simple. En pratique, elle force trois décisions qu'on n'a souvent pas encore prises: qui est le vrai utilisateur, quel est le problème mesurable, et quel résultat on considère comme un succès.

Exemples concrets:

"Pour un DRH de PME (30-200 employés), je cherche à réduire le tri initial de candidatures de 4 jours à 24 heures en 60 jours de déploiement."

"Pour un directeur financier de PME, je cherche à réduire les factures en retard de 31% à 15% en 90 jours."

"Pour un responsable d'exploitation logistique, je cherche à réduire les livraisons en retard de 22% à 10% en 12 semaines."

Mais la phrase seule ne suffit pas. Elle donne la direction, pas l'échelle. Pour savoir ce qu'on peut réellement construire dans le budget et le délai, il faut poser les chiffres de contexte: combien d'utilisateurs, quel volume, quel coût max acceptable.

Pour moi, ce combo phrase business testable + échelle évite l'erreur la plus coûteuse : confondre fonctionnalité demandée et résultat visé. La demande, c'est souvent "un tableau de bord", alors que le résultat visé est "prendre une décision plus vite avec moins d'erreurs". Sans cette distinction dès le départ, on construit des écrans au lieu de résoudre des problèmes.

Pour INSTAT, la phrase business était : "Pour un coordinateur d'enquête à l'INSTAT, je cherche à réduire les coûts logistiques de déploiement de 70% en priorisant l'affectation d'enquêteurs locaux pour la prochaine campagne." C'est cette phrase qui a tué le test de personnalité IA du MVP. Elle rendait évident que le problème prioritaire était logistique et financier, pas psychométrique.

Scope MVP: définir ensemble ce qu'on inclut et ce qu'on exclut

La tension récurrente est celle-ci: la vision produit est souvent large et juste, mais la phase 1 ne peut pas tout porter.

Ma définition d'un MVP :

Un MVP (Minimum Viable Product) n'est pas la version petite du produit final. C'est l'expérience minimale qui valide la promesse business.

Mon rôle de partenaire tech est d'aider à concevoir cette expérience pour s'assurer qu'on ne construit pas dans le vide. Au lieu de faire une liste au père Noël de fonctionnalités, on part du parcours utilisateur indispensable, le fameux « Jobs To Be Done ».

1. L'histoire utilisateur indispensable

Je commence par décrire l'histoire utilisateur la plus basique possible pour répondre au problème qu'on a cadré plus tôt, résumée par une phrase du type :

Quand [situation], je veux [action], pour que [bénéfice].

Par exemple, pour l'INSTAT: "Quand j'ai une enquête à faire, je veux pouvoir filtrer les enquêteurs qualifiés par ville, pour que je puisse optimiser les coûts logistiques en affectant en priorité ceux qui sont sur place."

Ensuite, on ne garde que les étapes strictement indispensables pour que cette histoire se réalise de bout en bout. Tout ce qui sort de ce fil narratif direct part dans une colonne « plus tard ». Pas de "matching prédictif", pas de "tableau de bord global". Juste le flux principal qui valide l'hypothèse business.

2. Prioriser ce qui reste avec RICE

Même en étant strict, des idées périphériques vont revenir sur la table ("Ce serait quand même bien d'avoir un export PDF"). Pour les évaluer sans débat émotionnel, on utilise des frameworks de décision, et j'apprécie particulièrement RICE:

• Reach (Portée) : Combien d'utilisateurs cette fonctionnalité va-t-elle toucher au lancement ?
• Impact : À quel point cela contribue-t-il à valider notre KPI principal ?
• Confidence (Confiance) : Sommes-nous sûrs de notre estimation d'impact et d'effort ?
• Effort : Combien de jours de développement cela nécessite-t-il ?

Ce calcul nous donne un score objectif. Si une fonctionnalité demande un gros effort technique mais a un "Reach" limité (par exemple, un espace admin multi-rôles complexe pour une équipe de 2 fondateurs), son score s'effondre. Elle est mathématiquement exclue de la phase 1.

Cette double approche (Fil narratif strict + RICE pour les exceptions) a trois avantages:

1. Elle dépersonnalise le choix: on ne rejette pas l'idée du fondateur, on la confronte à l'histoire centrale et au score objectif.
2. Elle protège le budget: on s'assure de valider l'hypothèse business centrale avant d'investir dans le confort.
3. Elle assume les limites: on décide ensemble de ce qui sera manuel ou imparfait au lancement, et on l'accepte.

Un produit qui couvre le flux indispensable avec fiabilité se fait adopter. Un produit "complet" à 40 % de fiabilité se fait contourner.

KPI: définir le succès avant de coder

Un KPI (Key Performance Indicator), c'est l'indicateur clé qui nous permet de mesurer objectivement si le produit qu'on construit résout vraiment le problème ciblé. D'expérience, il est indispensable de définir quelques KPI précis avant même d'écrire la première ligne de code: on vient de décider ce qu'on va construire avec le MVP, il faut maintenant décider ensemble comment on mesurera son succès.

1. L'OMTM (One Metric That Matters)

Au lieu d'un tableau de bord complexe, on isole l'OMTM : l'unique métrique qui détermine le succès du MVP. Le grand avantage de notre cadrage strict, c'est qu'elle en découle naturellement.

Si la promesse du projet INSTAT est d'optimiser les coûts logistiques, notre OMTM est évident : c'est le coût logistique moyen par enquête.

C'est un outil de décision redoutable en plein sprint. Quand un débat éclate sur l'ajout d'une nouvelle fonctionnalité non prévue, la réponse ne dépend plus des opinions ou des égos. On pose une seule question : Est-ce que cette idée a un impact direct sur notre OMTM ? Si non, ça part dans le backlog « plus tard ».

2. Les métriques de contrepoids et de santé

L'OMTM ne doit pas être optimisé à l'aveugle. Si on réduit le coût logistique au minimum en ne recrutant que des enquêteurs inexpérimentés, la qualité des données va s'effondrer.

C'est pour ça que je préfère ajouter quelques KPI secondaires pour encadrer l'OMTM et surveiller la santé du système :

• Métrique de contrepoids : Taux de rejet des enquêtes terminées. Si notre coût logistique baisse mais que le taux de rejet explose, notre succès sur l'OMTM est une illusion.
• Métrique de santé technique : Temps de réponse du filtrage. Si l'application fige pendant 10 secondes à chaque recherche de ville, les coordinateurs contourneront l'outil.

Ces quelques KPI viennent encadrer l'OMTM pour s'assurer qu'on gagne de la valeur business sans détruire le reste de l'expérience.

Architecture, stack et conventions: le comment?

Une fois qu'on sait quel problème résoudre, quoi construire, et comment mesurer le succès, il reste à décider comment le construire. Pas pour faire de la sur-ingénierie, mais parce que les blocages des Sprints 2 et 3 viennent presque toujours d'un angle mort : l'architecture ne supporte pas la réalité du terrain.

L'architecture est dictée par les contraintes métier

Les décisions architecturales fondatrices pour un produit tech doivent toujours clarifier au minimum quatre éléments :

• Le style architectural : Monolithe modulaire, microservices, serverless, architecture hexagonale… Dans la majorité des produits en démarrage, un monolithe bien modulaire est la décision la plus professionnelle.
• Le paradigme de communication : Synchrone (REST, GraphQL) vs asynchrone (message broker, event bus). Si des parties de votre métier peuvent s’exécuter plus tard (email, génération de PDF, analyse), un bus d’événements interne rendra le système découplé et beaucoup plus résilient.
• La stratégie de données : Base unique ou persistance polyglotte ? La base relationnelle (PostgreSQL) pour les données structurées, éventuellement un stockage document/objet pour les fichiers, et un moteur de recherche séparé si nécessaire. Le cauchemar d'un MVP reste le remodelage constant des données parce qu'on a mal anticipé les relations.
• Le choix d’API et contrats d’interface : Définir comment vos frontends, clients mobiles ou partenaires parleront au système (versioning d’API, format de réponse unifié, politique de dépréciation).

Ces choix techniques ne se font pas au hasard, ils sont dictés par les contraintes qu'on a définies plus haut :

• L'échelle et le budget imposent le style architectural. Un budget MVP serré interdit d'emblée les "microservices" qui explosent les coûts d'infrastructure. On part sur un monolithe modulaire.
• Le scope du MVP impose la stratégie de données et les contrats d'interface. Si l'histoire utilisateur principale sert un client mobile et un tableau de bord web, un contrat d'API strict est imposé dès le premier jour.
• L'anticipation du passage à l'échelle : Il ne s'agit pas de sur-architecturer pour des millions d'utilisateurs qui n'existent pas encore, mais d'éviter le "mur tech" dans 6 mois. Si le projet prévoit des pics d'utilisation massifs (ex. : une billetterie), l'architecture devra d'emblée séparer les flux de lecture et d'écriture, ou s'orienter vers du serverless.
• Les contraintes "spéciales" dictent le paradigme de communication. Sur notre projet INSTAT, l'absence de réseau sur le terrain imposait instantanément une architecture hors-ligne (Local-first) synchronisée de manière asynchrone avec le serveur via un système d'événements, éliminant d'office une simple communication synchrone.

La stack est dictée par les contraintes humaines

Une fois l'architecture dessinée (ex: "Il nous faut un monolithe avec une base relationnelle et un worker asynchrone"), on choisit les outils pour la construire. Et ici, ce sont souvent les contraintes humaines qui dictent la loi.

• La taille et le niveau de l'équipe dev : Le projet va-t-il démarrer avec un développeur solo ou une équipe de 5 ? Quel est le langage de prédilection de l'équipe technique actuelle ?
• La maintenabilité : Si vous faites appel à des freelances, trouverez-vous facilement des développeurs sur cette technologie dans 6 mois ?

Une stack "parfaite" sur le papier est un désastre absolu si l'équipe met 3 mois à la maîtriser. On choisit la stack dans laquelle l'équipe est la plus rapide pour livrer de la valeur aujourd'hui.

Les conventions : Les règles du jeu qu'on fixe avant le développement

Même avec la meilleure architecture du monde, une équipe sans règles communes finira par s'embourber. Au-delà du choix des outils, il est indispensable de poser un socle de conventions pour éviter les débats interminables et les bugs d'inattention.

Pour un fondateur, cela peut sembler anecdotique, mais c'est en réalité ce qui garantit la vélocité et la fiabilité de l'équipe :

• Les conventions de nommage : On définit à l'avance comment nommer les fichiers, les variables et les tables de base de données. Comme pour une méthode de classement partagée dans une entreprise, une fois la règle fixée, chacun retrouve l'information immédiatement.
• L'organisation du code : On décide de la structure des dossiers pour éviter que chaque développeur n'invente sa propre logique d'architecture dans son coin au bout de trois sprints.
• La gestion des erreurs : On pose une règle stricte pour différencier une "erreur utilisateur" (ex: "L'enquêteur est déjà assigné") d'une "erreur système" (ex: "Le serveur est hors ligne"). Cela permet d'afficher des messages clairs à vos clients au lieu d'écrans de plantage incompréhensibles.
• Le flux de validation : On met en place des règles automatiques avant qu'une ligne de code ne soit déployée en production (tests automatiques, relecture obligatoire par un autre membre de l'équipe). C'est votre filet de sécurité pour ne rien casser en cours de route.

Ce n'est pas de la bureaucratie. C'est du temps de cerveau gagné pour que l'équipe technique se concentre exclusivement sur la création de valeur et le fameux OMTM pendant l'exécution des sprints.

NB : Cette section sur l'architecture et les conventions est une vulgarisation (en réalité, le "COMMENT" technique est bien plus complexe que ça). Mon but n'est pas de vous transformer en développeur senior, mais de vous donner la grille de lecture nécessaire pour savoir, de l'extérieur, si votre équipe technique pose les bonnes questions et travaille de la bonne manière. En tant que fondateur, soyez intraitable sur le QUOI (le problème et le MVP) et le POURQUOI (l'OMTM). Mais pour le COMMENT, faites confiance à un professionnel technique capable de traduire vos contraintes business en un socle technologique robuste.

En résumé : Place à l'action

Le cadrage d'un projet tech pour moi consiste à avoir :

1. Un problème business clair : une phrase de valeur, pas une fonctionnalité vague.
2. Un scope MVP assumé : ce que l'on construit, mais surtout ce que l'on refuse de construire.
3. L'OMTM et ses contrepoids : la boussole pour trancher les débats en cours de développement.
4. Les décisions architecturales : déduites des contraintes métier, pas d'un concours de mode.
5. Les règles du jeu : pour que l'équipe technique délivre sans friction.

D'après les années que j'ai passées dans la tech, si vous respectez cela, votre projet sera armé pour livrer de la valeur concrète sans exploser votre budget ni vos délais.

Si vous construisez un produit tech (SaaS, WebApp, App Mobile) et que vous sentez le besoin d'un partenaire expérimenté pour challenger votre vision, cadrer votre MVP et poser des bases architecturales solides, parlons-en. Mon accompagnement commence par une session de cadrage gratuite de 30 minutes, sans engagement, pensée pour vous éviter les angles morts et vous faire gagner des mois de développement.