Discovery technique en 5 jours: la méthode qu'on applique avant de chiffrer un projet web/IA

On a arrêté de chiffrer à l'aveugle après le troisième projet où le budget initial était épuisé avant la mise en production. Le pattern était le même : un devis basé sur une description fonctionnelle, une première estimation raisonnable, puis des découvertes successives, contraintes techniques non anticipées, intégrations complexes, données de mauvaise qualité, qui doublaient le scope réel.

La discovery technique est notre réponse à ce problème. Ce n'est pas une phase de spécification. C'est une phase d'investigation qui produit un chiffrage fondé sur des données réelles.

Ce qu'une discovery n'est pas

Une discovery n'est pas une phase de conception fonctionnelle. Ce travail (user stories, wireframes, parcours utilisateur) est utile mais séparé. On peut faire les deux, mais on ne les confond pas.

Une discovery n'est pas un POC livrable au client. On produit du code de validation, des mesures, des arbitrages, pas un produit fonctionnel.

Une discovery n'est pas gratuite. On facture systématiquement les 5 jours, entre 3 000 et 6 000 euros selon le projet. Si le client choisit ensuite de ne pas continuer avec nous, il repart avec les livrables. C'est une prestation autonome.

Les 5 jours en détail

Jour 1 : cartographie du système existant

La première journée est consacrée à comprendre l'existant. On demande l'accès à tous les éléments disponibles : documentation technique, architecture actuelle, extraits de données, APIs tierces concernées.

On produit un document d'une page qui répond à trois questions :

• Quelles sont les dépendances critiques du projet (APIs, bases de données, services tiers) ?
• Quels sont les volumes de données impliqués (ordres de grandeur) ?
• Quels sont les contraintes non négociables (réglementation, sécurité, compatibilité) ?

Cette journée révèle souvent des surprises. Un client qui décrit un projet de "simple intégration API" possède parfois un système legacy qui expose ses données via un export CSV mensuel, pas via une API REST.

Jour 2 : investigation des risques techniques

On identifie les trois à cinq zones de risque principal du projet et on passe la journée à les investiguer.

Pour un projet IA : on teste le modèle sur un échantillon réel de données. On mesure les taux d'erreur sur les cas nominaux et on commence à identifier les cas limites. On évalue la qualité et la représentativité des données disponibles.

Pour un projet d'intégration : on tente réellement d'appeler les APIs tierces avec des credentials de test. On documente les limitations de taux, les formats inattendus, les cas non documentés.

Pour un projet de migration : on mesure le volume réel à migrer, on identifie les incohérences dans les données sources, on teste une migration partielle.

L'objectif n'est pas de résoudre les problèmes. C'est de les confirmer et de les dimensionner.

Jour 3 : prototype de validation

On développe un prototype minimal qui valide le chemin critique. Pas une démonstration marketing, une validation technique des hypothèses les plus risquées.

Sur un projet de RAG (Retrieval-Augmented Generation), on ingère quelques centaines de documents réels, on teste les requêtes les plus représentatives, on mesure la pertinence des résultats. On sait alors si l'approche est viable avant d'avoir engagé 60 jours de développement.

Sur un projet de tableau de bord analytique, on connecte la source de données réelle, on exécute les requêtes les plus lourdes, on mesure les temps de réponse. On sait si on a besoin d'une couche de cache ou d'une refonte de l'architecture de données.

Jour 4 : arbitrages et options

À ce stade, on a suffisamment d'informations pour proposer des options au client. On structure les arbitrages en trois axes :

Périmètre. Quelles fonctionnalités sont critiques, quelles fonctionnalités sont optionnelles ? Quelles simplifications permettent de réduire le risque sans affecter la valeur métier principale ?

Architecture. Quelles sont les options techniques viables ? On documente deux ou trois approches avec leurs compromis en termes de coût, de délai, et de dette technique.

Risques résiduels. Quels sont les risques qu'on n'a pas pu éliminer pendant la discovery, et comment on les gère dans le projet (budget de contingence, jalons de validation, décision Go/No-Go intermédiaires) ?

Jour 5 : livrables et présentation

On produit trois documents.

Le rapport de discovery : 5 à 10 pages. Il synthétise les découvertes techniques, les risques identifiés et leur niveau de criticité, les arbitrages proposés, et les hypothèses qui restent ouvertes.

L'estimation argumentée : un chiffrage par phase avec fourchettes explicites. Chaque ligne est justifiée par une découverte de la discovery. Les incertitudes résiduelles sont documentées avec leur impact sur le budget.

La roadmap de validation : si le projet est long (plus de 3 mois), on découpe en jalons avec des critères d'acceptation mesurables. Chaque jalon est un Go/No-Go explicite.

On présente ces livrables au client le vendredi après-midi. La réunion dure 2 heures.

Ce que ça change sur les devis

Sur les projets où on a fait une discovery complète, notre taux de dépassement de budget est tombé à moins de 15%. Sur les projets où on a sauté la discovery (généralement sous pression commerciale), le taux reste autour de 60%.

Les devis post-discovery sont plus chers en surface, entre 15% et 30% de plus que nos estimations initiales avant discovery. Mais l'écart entre le devis et le réel est beaucoup plus faible. Le coût total du projet pour le client est inférieur.

Les objections qu'on entend

"On n'a pas le budget pour payer une discovery." Si le projet fait 80 000 euros, une discovery à 5 000 euros représente 6% du budget. Elle réduit le risque de dépassement de 60% à 15%. Le calcul est rapide.

"On est déjà en retard, on n'a pas le temps." C'est généralement le signe qu'on a encore plus besoin d'une discovery. Un projet commencé sous pression sans cadrage technique court droit vers les problèmes qu'on voulait éviter.

"Nos concurrents ne facturent pas ça." Exact. Certains intègrent le coût de la discovery dans le projet global (ce qui revient au même), d'autres ne la font pas et absorbent les dépassements (ou les facturent au client sous d'autres formes).

Les limites de la méthode

Cinq jours ne suffisent pas sur tous les projets. Pour des projets à fort enjeu de données, migration d'une base de plusieurs teraoctets, intégration avec des systèmes legacy complexes, on peut avoir besoin de 10 à 15 jours de discovery.

La discovery réduit l'incertitude, elle ne l'élimine pas. Sur les projets IA en particulier, la performance réelle en production peut différer de la performance mesurée pendant la discovery, parce que les données réelles diffèrent des échantillons de test. On le documente explicitement dans le rapport.

La vraie question qu'on retourne au client à la fin de chaque discovery : est-ce que les risques identifiés changent la priorité du projet, ou est-ce qu'il reste justifié de l'adresser maintenant avec le budget disponible ?