Guillaume Macherey
Co-fondateur d'ALLOHOUSTON
Arrêtez d’écrire des specs que personne ne lit. Pendant des années, les projets IT ont été cadrés de la même manière : des documents de spécifications fonctionnelles de 40 pages, 200 tickets de user stories, des wireframes annotés et des diagrammes de flux. Résultat ? Le client valide sans vraiment lire, le développeur interprète à sa façon, et à la livraison tout le monde découvre que “ce n’est pas ce qu’on avait imaginé”. Le consultant-développeur aborde le cadrage différemment : en comprenant profondément les processus métier du client. Cette compréhension ne sert pas à figer un cahier des charges — elle permet de s’engager au forfait tout en conservant la capacité d’itérer. Parce que les ajustements en cours de projet deviennent peu chronophages quand on maîtrise le contexte métier.
Ordre de grandeur issu de diverses études (source : https://zipdo.co/software-project-failure-statistics/).
Le vrai problème des projets IT n’est pas le code. C’est ce qui se passe avant.
Après 10 ans à accompagner concevoir et développer des produits numériques pour des équipes métier, nous avons identifié un pattern récurrent dans la manière dont ces projets sont menés au sein des organisations. Le scénario classique se déroule toujours de la même façon : un cabinet de conseil analyse les besoins et produit un rapport exhaustif. Une ESN reprend le dossier pour développer. Le développeur découvre que les spécifications sont floues. Le client découvre que le produit ne correspond pas à ses attentes. Tout le monde se renvoie la balle.
Le coût réel de ce dysfonctionnement est brutal :
Pourquoi cela arrive-t-il systématiquement ? Parce que les cabinets de conseil sont excellents pour analyser, et les ESN sont excellentes pour coder. Mais entre les deux existe un fossé. Le consultant qui a compris le besoin n’est pas celui qui code. Le développeur qui code n’a pas accès au contexte métier. L’information se perd à chaque transmission.
C’est comme le jeu du téléphone. Sauf que ça coûte beaucoup d’argent.
Le problème n’est pas technique. Le problème n’est pas méthodologique. Le problème est structurel : on sépare ceux qui comprennent de ceux qui font.
Notre conviction : celui qui code doit être celui qui comprend. Celui qui comprend doit être capable de coder et contribuer à la réalisation. C’est pour cela que nous avons inventé le métier de consultant-développeur : un seul interlocuteur, double compétence, zéro perte d’information.
Et cette double compétence change radicalement la façon de cadrer un projet. Elle s’accompagne de quelques outils et garde-fous qui font l’objet de la suite de cet article.
On s’est posé une question simple : “Comment créer une base commune qui permette d’avancer ensemble ?”
La réponse n’est pas un cahier des charges plus détaillé. C’est un prototype qui matérialise notre compréhension des processus métier. Ce prototype n’est pas figé — c’est un point de départ partagé qui permet au client et aux futurs utilisateurs de réagir, de préciser, d’ajuster. Et parce que nous avons compris son métier, ces ajustements sont rapides en phase de conception initiale et restent peu chronophages en cours de développement.
Une immersion dans les processus métier
Avant de dessiner le moindre écran ou workflow métier, nous passons du temps à comprendre comment les équipes travaillent aujourd’hui. Pas ce qu’elles pensent vouloir, mais ce qu’elles font réellement au quotidien. Cette immersion nous permet d’anticiper les cas d’usage réels — les erreurs, les exceptions, les situations limites — qui représentent souvent jusqu’à 40% du temps de développement.
Des données réelles pour valider la compréhension
Nos prototypes utilisent les vraies listes, les vrais chiffres du client. Quand le directeur commercial voit son tableau de bord avec les noms de ses vrais clients et ses vraies données, il peut réagir immédiatement : “Ça, c’est exactement notre fonctionnement” ou “Non, là il manque quelque chose”. C’est cette réaction qui nous intéresse — pas une validation formelle.
Des règles métier explicitées ensemble
Chaque écran porte les règles de gestion que nous avons comprises lors de nos échanges. “Ce bouton n’apparaît que si le statut est X et que l’utilisateur a le rôle Y”. Si notre compréhension est incorrecte, le client nous corrige immédiatement. C’est beaucoup plus efficace qu’un document que personne ne lit vraiment.
Sur le projet SIAAP, nous avons livré un prototype Figma de 47 écrans. Chaque écran annoté avec les specs métier. Chaque interaction documentée. Les équipes métier ont pu naviguer dans l’application comme si elle existait déjà.
Le client a validé en regardant, pas en lisant.
Le principe qui change tout :
“Ce prototype est notre compréhension actuelle de votre métier. Faisons-le évoluer ensemble.”
Le prototype n’est pas un contrat figé — c’est une base de discussion. Ce qui compte, c’est que notre compréhension des processus métier soit juste. Parce qu’avec cette compréhension, les ajustements en cours de développement deviennent naturels et peu coûteux.
Ce que ça permet :
Pour Compliancy, une plateforme SaaS de trading de droits de douane, cette compréhension métier approfondie nous a permis de centraliser les données douanières et d’automatiser l’activité. Le produit a évolué pendant le développement — mais dans le bon sens, sans dérive, parce que nous comprenions les enjeux.
“Oui mais j’avais payé un cadrage, vous auriez dû le voir.”
Cette phrase, nous l’avons entendue très souvent dans nos premières années. Nous avons fait un atelier interne pour comprendre pourquoi nous n’arrivions pas à dire non aux demandes hors périmètre. Voici ce que nous avons découvert et ce que nous mettons en place pour combiner agilité forte et clarté sur le périmètre de notre engagement.
1. Le flou contractuel - On dit oui à des éléments “incertains” en pensant que “ça passera”. Le client élargit ensuite le périmètre sans même le savoir.
2. La définition trop vague - “Gestion des utilisateurs” peut signifier 2 jours ou 2 mois de développement. Sans précision, chacun imagine ce qu’il veut.
3. Le décisionnaire multiple - Damien valide, puis Franck, puis l’IT, puis finalement Marie. Chaque validation ajoute des demandes.
4. L’envie de satisfaire - On veut que le client soit content. On accepte des extras “pour la relation”.
5. La curiosité technique - “Ce serait intéressant de tester cette approche.” On ajoute de la complexité non demandée.
6. Les erreurs de conception - On a mal compris, on corrige, ça déborde. Difficile de facturer nos propres erreurs.
7. Les projets qui s’étirent - Au bout de 6 mois, on ne sait plus ce qui était prévu initialement. Le fonctionnement en sprint se perd.
La liste “inclus / non inclus”
Deux colonnes dans chaque chiffrage. “Cette fonctionnalité inclut X, Y, Z. Elle n’inclut PAS A, B, C.” Cette explicitation évite 80% des débats ultérieurs.
Les arbitrages faits en commun
D’abord : les processus complets avec discussion sur la priorisation. Ensuite : le prototype V1 uniquement. Cette séparation permet au client de voir tout ce qui serait possible, puis de choisir ce qui rentre vraiment dans le budget.
La gestion explicite des incertitudes
Chaque incertitude identifiée devient soit un élément à approfondir avant signature, soit une marge dans le chiffrage. Plus de zones grises qui explosent en cours de projet.
Les objectifs projet partagés
Marge cible, niveau de qualité attendu, suivi hebdomadaire des dérives. Tout est transparent entre le client et l’équipe.
L’insight clé :
Dire non, ce n’est pas refuser de servir le client. C’est protéger le projet de la dérive. Un projet qui dérape fait perdre tout le monde : le client paie plus et attend plus longtemps, l’équipe s’épuise et perd en qualité.
Le vrai service, c’est de poser les limites claires dès le début. Et s’y tenir.
“Combien ça coûte ?”
La question qui fait trembler tous les prestataires tech. Trop cher, on perd le projet. Pas assez cher, on perd de l’argent.
Estimer au doigt mouillé - “Ça devrait prendre 3 semaines.” Spoiler : ça en prend 6.
Multiplier par 2 “pour être sûr” - On perd en compétitivité. Et parfois ça ne suffit même pas.
Copier un projet similaire - Aucun projet n’est vraiment similaire. Le diable est dans les détails.
Découper finement
Pas “gestion des utilisateurs”. Mais : création, modification, suppression, gestion des rôles, permissions, import, export, historique des modifications, notifications… Chaque brique a un coût identifiable.
Identifier les incertitudes
Chaque zone de flou représente un risque de dépassement. Soit on creuse pour lever l’incertitude, soit on budgète une marge correspondante.
Référencer les fonctionnalités
Un “tableau de données avec filtres et export” a un coût connu dans notre référentiel. On capitalise sur l’expérience des projets précédents.
Séparer le certain de l’incertain
Le socle technique est prévisible. Les spécificités métier sont variables. Cette distinction permet d’afficher clairement ce qui est garanti et ce qui peut évoluer.
Fonctionnalité standard → Coût référentiel
+ Complexité métier → +20 à +50%
+ Incertitudes identifiées → +10 à +30%
+ Intégrations externes → +Variable
= Estimation réalistePour Les Marmites Volantes, cette approche nous a permis de cadrer un ERP complet couvrant la planification des repas, la production, la livraison et l’interface client pour les écoles. L’estimation initiale a été respectée parce que chaque brique avait été correctement évaluée et que les incertitudes avaient été traitées en amont.
Sous-estimer pour gagner le projet. Nous l’avons fait. Nous l’avons payé.
Un projet sous-estimé génère une équipe sous pression, une qualité qui baisse, un client mécontent et une relation dégradée. Personne n’y gagne.
Notre approche aujourd’hui :
Le client préfère un chiffrage réaliste qu’une surprise à +50% en cours de route. La transparence sur les incertitudes construit la confiance.
L’enseignement clé de notre expérience ne concerne pas le niveau de détail des spécifications. Il concerne la compréhension des processus métier.
Quand le consultant-développeur comprend vraiment comment les équipes travaillent, et qu’il a les bons outils pour présenter avec clarté le contenu d’un projet, deux choses deviennent possibles :
C’est cette combinaison qui fait la différence. On ne fige pas un cahier des charges qu’on exécute aveuglément. On construit une compréhension partagée qui permet de faire évoluer le produit dans le bon sens, sans que le projet dérape.
Le consultant-développeur est particulièrement efficace dans cette approche car il pense déjà au code quand il échange avec les équipes métier. Il sait quelles questions poser, quels détails vont impacter le développement, et comment absorber les évolutions sans dérive.
Le résultat : un produit digital qui fonctionne vraiment pour les équipes métier. Pas parce qu’on a tout spécifié à l’avance, mais parce qu’on a compris le métier assez profondément pour itérer intelligemment.
Vous préparez un projet de produit numérique B2B ou de transformation digitale ? Parlons compréhension métier avant de parler développement.
Cet article est le deuxième d’une série consacrée au métier de consultant-développeur.
Découvrez également notre premier article : Consultant-développeur : pourquoi le développeur qui comprend le métier change tout
Abonnez-vous à notre newsletter ci-dessous et restez au courant de toutes nos dernières actualités !
