Chiffrer une feature IA : méthode qu'on utilise pour ne plus se tromper d'un facteur 3

Le premier projet IA qu'on a chiffré sérieusement, on l'a livré avec un dépassement de 280 %. Pas parce que l'équipe était incompétente, parce qu'on avait estimé comme un projet logiciel classique. L'IA a des propriétés qui cassent les modèles d'estimation habituels, et il a fallu un peu de douleur pour les identifier clairement.

Ce texte documente la méthode qu'on utilise depuis, avec les cases concrètes à vérifier avant de signer un devis.

Pourquoi les estimations IA déraillent

Il y a trois raisons structurelles, pas des erreurs d'inattention.

La première : l'itération sur le prompt n'est pas gratuite. Dans un projet web classique, corriger un bug de logique prend quelques minutes. Corriger un comportement LLM insatisfaisant demande de reformuler, retester sur un jeu de cas, mesurer la régression sur les cas qui fonctionnaient, recommencer. Un cycle d'amélioration de prompt prend 2 à 4 heures quand il est bien outillé, une journée quand il ne l'est pas. Et on en fait beaucoup plus qu'on ne le prévoit.

La deuxième : le coût d'évaluation est systématiquement oublié. Construire un jeu d'évaluation représentatif, maintenir une vérité terrain, annoter des exemples, faire tourner les évaluations, tout ça prend du temps non facturable en développement visible. C'est souvent 20 à 30 % du projet.

La troisième : les intégrations data sont sous-estimées. Le prompt est prêt, le modèle répond bien en sandbox, mais les données réelles arrivent dans un format inattendu, avec des cas limites non documentés, des encodages cassés, des champs manquants. Le nettoyage et la transformation des données représentent systématiquement plus que prévu.

La structure d'estimation qu'on utilise

On décompose chaque feature IA en cinq postes.

1. Exploration et cadrage (10-15 % du budget)

Avant d'écrire une ligne de code, on passe du temps à comprendre le problème réellement. Ça inclut : analyser 50-100 exemples réels d'inputs, identifier les cas limites, définir ce que "succès" signifie mesuralement. Cette phase est non négociable. Si on la saute, on la paie triple en refonte.

Durée type : 1 à 3 jours selon la complexité du domaine.

2. Prototype et évaluation initiale (20-25 % du budget)

Un prototype fonctionnel sur les cas principaux, pas sur les cas limites. Mais surtout : un jeu de 30 à 50 cas d'évaluation construits manuellement avec la vérité terrain. Ce jeu devient la référence pour toutes les itérations suivantes.

Jeu d'évaluation minimal :
- 15 cas "normaux" représentatifs du trafic attendu
- 10 cas limites identifiés pendant l'exploration
- 10 cas de régression après chaque modification majeure
- 5 cas adversariaux (inputs mal formés, attaques prompt injection)

Sans ce jeu, les itérations suivantes sont à l'aveugle.

3. Itérations prompt et logique (30-35 % du budget)

C'est le poste le plus mal estimé. On fixe un nombre maximum d'itérations en début de projet et on le respecte. Chaque itération a une définition de "done" : la métrique cible sur le jeu d'évaluation.

La règle qu'on s'est donnée : si on n'atteint pas la cible au bout de 5 itérations, on revoit le scope ou l'approche, on n'itère pas indéfiniment.

4. Intégration et pipeline data (15-20 % du budget)

Connexion aux sources de données réelles, traitement des formats inattendus, gestion des erreurs API, retry logic, timeout, fallback. On estime ce poste en examinant les sources de données réelles, pas en faisant confiance à la documentation.

# Exemple de ce qu'on trouve toujours en production
# que la doc ne mentionne pas :
def safe_extract_text(document: dict) -> str:
    # Champ "content" parfois absent, parfois None, parfois liste
    content = document.get("content")
    if content is None:
        return document.get("body", document.get("text", ""))
    if isinstance(content, list):
        return " ".join(str(c) for c in content if c)
    return str(content)

Ce type de code prend 10 minutes à écrire et 3 heures à découvrir qu'il manque.

5. Observabilité et mise en production (10-15 % du budget)

Logging des traces, monitoring des coûts, alertes, documentation du prompt versionné, procédure de rollback. Ce poste est souvent découpé du projet initial "pour aller vite". C'est une erreur : sans observabilité, la maintenance devient aveugle.

La grille de risque qu'on applique

Après avoir estimé les cinq postes, on applique des multiplicateurs de risque.

Ces multiplicateurs se combinent. Un projet sur des données non vues dans un domaine subjectif, c'est ×1.56 sur l'estimation brute. Ce n'est pas du pessimisme, c'est l'historique de nos projets.

Ce qu'on fait systématiquement avant de signer

Une checklist courte :

• [ ] On a vu au moins 50 exemples réels d'inputs (pas des mocks)
• [ ] On a une définition mesurable du succès (métrique, seuil, jeu d'évaluation)
• [ ] Le coût d'inférence mensuel est calculé sur le volume cible
• [ ] Le poste "évaluation et itérations prompt" est explicitement dans le devis
• [ ] Le client comprend que le nombre d'itérations est borné
• [ ] Il y a un plan de fallback si le LLM ne tient pas les performances requises

Ce dernier point est important. Un fallback peut être : une approche rule-based pour les cas simples, un modèle plus petit pour les cas non critiques, ou une escalade vers un humain pour les cas limites. Savoir qu'il existe calme beaucoup de discussions sur les garanties de performance.

Ce que ça donne en pratique

Sur un projet récent, un assistant de qualification de leads B2B, l'estimation initiale brute était de 18 jours. Après application de la grille (données non vues, domaine subjectif) : 26 jours. Livraison réelle : 24 jours. Écart de 8 %.

L'ancien modèle d'estimation aurait donné 18 jours et une livraison à 32 jours.

La méthode ne garantit pas la précision. Elle garantit de ne pas se tromper d'un facteur 3 sur les lignes de coût que tout le monde oublie.

La limite qu'on n'a pas encore résolue : comment estimer une feature IA quand le comportement cible n'est pas encore clairement défini par le client ? C'est souvent le cas sur des projets d'exploration. On travaille alors sur des time-boxes avec des critères de go/no-go intermédiaires, mais ça change la nature du contrat, pas seulement l'estimation.