Devis sur projet IA: pourquoi on s'est arrêté de sous-estimer d'un facteur 2 systématique

Sur nos quatre premiers projets IA en production, on a dépassé le budget de 40%, 70%, 90%, et 120%. Sur le cinquième, on a livré dans les temps. La différence entre les cinq : la méthode de chiffrage, pas la complexité technique.

Ce n'est pas une confession de mauvaise gestion. C'est un pattern qu'on voit dans toutes les agences qui se lancent dans l'IA générative. Les raisons sont structurelles.

Pourquoi l'IA générative résiste aux estimations classiques

Dans un projet web classique, on estime en décomposant les fonctionnalités en tâches connues : une page, un formulaire, un endpoint, une intégration. La variance est limitée parce que la technologie est maîtrisée. On sait qu'un formulaire avec validation prend 4 heures.

Un projet IA générative comporte des phases qu'on ne sait pas estimer sans avoir commencé :

L'itération sur les prompts. Un prompt qui fonctionne à 80% nécessite en général 3 à 5 cycles d'itération pour atteindre 95%. Chaque cycle demande de générer des exemples, d'identifier les cas d'échec, de reformuler, de retester. On sous-estime systématiquement ce temps parce qu'on pense "c'est juste du texte à écrire".

La gestion des cas limites. Un LLM produit des sorties non déterministes. Sur les cas nominaux, tout fonctionne. Ce sont les 5% de cas limites, entrées ambiguës, requêtes hors scope, formats inattendus, qui consomment 30% du temps de développement.

L'évaluation. Comment mesure-t-on qu'une réponse générée est "correcte" ? Sur un projet d'extraction de données, on a passé deux semaines à construire un jeu d'évaluation représentatif avant de pouvoir mesurer les progrès. Ce temps n'était pas dans le devis initial.

Les changements de direction client. Les clients découvrent ce que l'IA peut faire en voyant les premières démos. Invariablement, le scope change. Pas par mauvaise foi, par enthousiasme face à des possibilités qu'ils n'avaient pas anticipées.

Les erreurs qu'on faisait

On estimait le cas nominal. On dessinait le chemin heureux, on estimait chaque étape, on ajoutait 20% de marge. La marge ne couvrait pas l'itération sur les prompts.

On confondait POC et production. Un POC qui fonctionne sur 100 exemples manuels ne prédit pas le comportement sur 10 000 entrées réelles. Le passage de l'un à l'autre, nettoyage des données, gestion des erreurs, monitoring, représente souvent 40% du travail total.

On ne chiffrait pas l'incertitude. Si on ne sait pas combien d'itérations de prompt seront nécessaires, ce n'est pas une raison de ne pas mettre ce coût dans le devis. C'est une raison de le chiffrer avec une fourchette explicite.

Ce qu'on fait maintenant

Séparer la discovery du développement

On ne livre plus de devis sur un projet IA sans avoir fait une discovery technique préalable de 3 à 5 jours (voir notre article sur la discovery). Sans discovery, on estime dans le vide.

La discovery produit un chiffrage basé sur des données réelles : quelques centaines d'exemples traités, une première mesure de performance, une identification des cas limites. Cela divise par 3 la variance de l'estimation.

Chiffrer les phases d'itération explicitement

On a maintenant des lignes de devis explicites pour les phases d'itération :

• Itération sur les prompts : 3 à 6 jours selon la complexité de la tâche
• Construction du jeu d'évaluation : 2 à 4 jours
• Tests de charge et optimisation des coûts : 2 à 3 jours
• Gestion des cas limites et edge cases : 20% du temps de développement total

Ces lignes ne sont pas des marges cachées. On les explique au client. En général, cela ouvre une conversation productive sur ce qui rend les projets IA différents des projets web classiques.

Utiliser des fourchettes, pas des valeurs ponctuelles

On ne dit plus "ce projet coûte 45 000 euros". On dit "ce projet coûte entre 38 000 et 58 000 euros selon le nombre d'itérations nécessaires sur la qualité des sorties". On explique ce qui déplace l'estimation dans la fourchette haute ou basse.

Cette transparence change la relation client. On est partenaires dans la gestion de l'incertitude, pas responsables de l'avoir mal estimée.

Définir un critère d'arrêt

Avant de commencer, on définit avec le client ce que "ça marche" signifie. Pour un projet d'extraction de données : taux d'extraction correct supérieur à 95% sur un jeu de test représentatif de 500 documents. Pour un chatbot : note de satisfaction supérieure à 4/5 sur 100 conversations testées.

Sans critère d'arrêt, le projet est potentiellement infini. Le client peut toujours vouloir un peu mieux. Avec un critère, on sait quand on a fini.

Ce que ça change pour le client

Les devis sont plus chers en surface. Sur les deux derniers projets, nos propositions étaient 25% à 35% plus élevées que nos concurrents directs. On en a perdu un. L'autre, on l'a livré dans les temps et dans le budget.

Le client qu'on a perdu a signé avec l'agence moins chère. Six mois plus tard, il nous a recontacté. Le projet était en retard de huit mois et le budget initial avait été doublé.

Ce n'est pas systématique. Mais c'est un pattern qu'on voit régulièrement.

La limite de notre approche

On a calibré notre méthode sur des projets de taille intermédiaire : 30 000 à 150 000 euros, 3 à 9 mois. Sur des POC exploratoires à budget fixe, la logique est différente : on livre ce qu'on peut faire avec le budget, on ne promet pas de résultat.

La vraie question qu'on n'a pas encore résolue : comment communiquer l'incertitude des projets IA à des clients habitués aux prix fixes du web agency classique ? La fourchette est honnête, mais elle est inconfortable pour un client qui veut un engagement ferme.