Un poste prévu peut rester mal chiffré

Prévoir du temps pour intégrer un service d’IA, contrôler ses résultats et le maintenir ne dit pas encore combien il en faudra. La charge dépend des demandes à traiter, de la qualité exigée et du travail nécessaire pour corriger les résultats insuffisants. Une estimation peut ainsi couvrir les bons postes sans décrire correctement ce qu’ils vont représenter. La difficulté n’est pas nécessairement un oubli dans le budget ; elle peut venir d’une hypothèse encore mal éprouvée.

Le retour technique de Honeycomb sur Query Assistant en 2023 illustrait cette difficulté. Cet assistant transformait une demande en langage naturel en requête pour interroger des données techniques. Selon l’entreprise, la majeure partie du travail avait relevé du développement produit ordinaire, de l’interface aux essais. Certains besoins étaient même déjà envisagés dans l’annonce de lancement de mai 2023, comme la modification de requêtes existantes : tout n’était pas à découvrir après le lancement.

Les usages avaient cependant précisé les adaptations nécessaires. Face à des demandes allant d’instructions détaillées à un simple « slow », améliorer la précision pouvait réduire la capacité à traiter les formulations vagues. L’équipe devait travailler ce compromis. Dans son bilan d’octobre, Honeycomb rapportait aussi avoir adapté l’accueil des utilisateurs qui n’avaient pas remarqué la fonction. Le travail concernait donc le comportement du service autant que son adoption. Ces adaptations étaient décrites sans comparaison chiffrée entre budget initial et dépenses réalisées.

Avec un système agentique, l’incertitude peut également porter sur le travail que le système déclenche lui-même. Une recherche ouverte n’emprunte pas nécessairement le même chemin à chaque exécution : les premières réponses peuvent conduire à d’autres recherches, à des vérifications ou à des reprises. Le nombre de demandes reçues ne suffit alors pas à déterminer le volume de calcul.

Dans son retour d’ingénierie publié en juin 2025, Anthropic avait décrit des premières versions de son système de recherche multi-agent qui dupliquaient des recherches ou poursuivaient un travail déjà suffisant. L’équipe avait précisé la répartition des tâches et la manière de proportionner l’effort. Ce travail d’ingénierie, dont le coût financier n’était pas publié, visait notamment à réduire les consommations inutiles. Anthropic rapportait aussi des améliorations sur les recherches adaptées au travail en parallèle : la charge supplémentaire devait être appréciée face au résultat obtenu, pas uniquement face au prix d’une interaction simple.

Une faible facture ne suffit pas à justifier l’investissement

Les adaptations découvertes à l’usage ne conduisent pas nécessairement à une exploitation coûteuse. Dans son bilan d’octobre 2023, Honeycomb déclarait une facture OpenAI moyenne de 30 dollars par mois pour Query Assistant. Avec l’infrastructure associée, l’entreprise situait son coût d’exploitation à quelques centaines de dollars mensuels, hors investissement de construction. La fonction produisait des réponses courtes et utilisait notamment GPT-3.5 ; ces montants décrivaient ce service en 2023, pas le prix d’un projet d’IA en général.

Honeycomb avait néanmoins mobilisé des ressources de recherche et développement ainsi que de marketing. Le faible coût récurrent ne suffisait pas à établir que cet investissement était amorti. L’utilisation de l’assistant était associée à une poursuite plus fréquente des requêtes manuelles chez les nouvelles équipes, mais les résultats étaient inégaux selon les usages observés. Le bilan ne chiffrait pas un retour sur investissement complet.

Pour une entreprise qui attend surtout un gain de temps, la question se déplace vers le travail réellement économisé. Produire une réponse plus rapidement ne garantit pas que le processus complet soit plus court. La sollicitation de l’outil, la vérification et les corrections peuvent absorber une partie du gain. Même les personnes qui réalisent ce travail peuvent mal apprécier le solde.

Une étude publiée en juillet 2025 par l’organisme de recherche Model Evaluation & Threat Research (METR) avait mis en évidence cet écart chez seize développeurs expérimentés, sur des projets open source familiers. Entre février et juin 2025, l’IA avait été autorisée ou exclue par tirage au sort pour chaque tâche. À partir des durées de travail déclarées, corrections comprises, l’étude avait estimé un temps de réalisation supérieur de 19 % lorsque l’IA était autorisée. Les participants estimaient pourtant, après l’expérience, avoir gagné 20 % de temps.

Dans sa mise à jour de février 2026, METR jugeait probable que les développeurs bénéficient davantage des outils récents, mais considérait sa nouvelle estimation comme peu fiable. METR signalait que certains développeurs refusaient de participer ou écartaient des tâches pour ne pas avoir à travailler sans IA, et jugeait que cette sélection pouvait conduire à sous-estimer les gains. La baisse de la rémunération des participants avait aussi pu contribuer à cette sélection ; le travail simultané avec plusieurs agents compliquait la déclaration du temps. Le ralentissement observé dans le contexte de 2025 ne pouvait donc pas servir de coefficient de surcoût pour les projets actuels.

L’écart de 2025 reste pertinent pour une décision fondée sur des gains déclarés : l’impression d’aller plus vite peut persister alors que le travail complet prend davantage de temps. La mise à jour rappelle également que la mesure doit suivre l’évolution des usages. Le temps pendant lequel un agent travaille n’est pas nécessairement du temps humain immobilisé ; inversement, un résultat livré rapidement peut demander une longue reprise.

Les conséquences économiques diffèrent selon la manière dont cette charge est absorbée. Si une équipe salariée consacre davantage de temps au contrôle, sa rémunération mensuelle peut rester identique, mais une autre activité dispose de moins de capacité. Si l’entreprise doit acheter une prestation supplémentaire pour terminer le travail, une dépense nouvelle apparaît. Et si le temps gagné est simplement inférieur à l’estimation, c’est d’abord une partie du bénéfice attendu qui manque. Un budget tenu peut ainsi accompagner un investissement moins intéressant que prévu, sans qu’une facture ait dérapé.

Jusqu’où engager l’entreprise sur une estimation incertaine ?

Toutes les inconnues ne peuvent pas être levées avant de commencer. Elles n’ont pas non plus la même importance : une variation limitée d’une dépense secondaire ne remet pas le choix en cause comme peut le faire une charge de contrôle absorbant l’essentiel du gain attendu. L’évaluation doit permettre de repérer cette différence.

Les méthodes existantes offrent des moyens de l’examiner. Le Green Book de HM Treasury, dans son édition 2026, traite explicitement du cycle de vie, des scénarios, des essais et de l’analyse de sensibilité. Ce cadre britannique d’évaluation des décisions publiques prévoit notamment de rechercher les valeurs d’une hypothèse qui feraient changer le choix. Il envisage aussi la possibilité de conserver de la flexibilité lorsque de nouvelles informations doivent apparaître.

Appliquée à une décision d’entreprise, cette logique conduit à examiner les hypothèses dont dépend réellement l’intérêt du projet. Si l’économie prévue repose sur une réduction du temps de traitement, à partir de quelle durée de vérification disparaît-elle ? Si le service nécessite davantage de recherches ou de reprises que prévu, reste-t-il préférable à la manière actuelle de travailler ? Les réponses ne demandent pas nécessairement un modèle complexe. Elles demandent en revanche de comparer un résultat de qualité équivalente et de ne pas traiter la meilleure exécution observée comme le fonctionnement ordinaire.

Une réserve budgétaire peut couvrir une dépense supplémentaire jusqu’à un certain montant. Elle ne rétablit pas, à elle seule, le gain que cette dépense devait permettre. De même, limiter la consommation d’un agent protège l’enveloppe consacrée au calcul, mais peut l’empêcher de terminer certaines tâches. Le travail non accompli doit alors être abandonné, repris ou réalisé autrement. La maîtrise du budget et le maintien du service doivent être examinés ensemble.

Un pilote devient utile lorsqu’il permet d’observer ces relations : consommation pour un résultat accepté, temps humain réellement mobilisé, reprises et cas qui exigent une autre prise en charge. Il coûte lui-même du temps et des moyens ; son ampleur doit dépendre de l’enjeu de la décision. Un essai limité à des demandes simples et à des utilisateurs très accompagnés renseigne mal sur une généralisation à d’autres équipes. Les adaptations de Honeycomb et les difficultés de mesure de METR montrent aussi que les usages peuvent évoluer pendant l’observation. Accumuler des mesures ne suffit pas si les tâches ou le résultat attendu ont changé.

Lorsque le projet ne reste intéressant qu’à condition que presque aucun résultat ne soit repris, cette condition doit être éprouvée avant d’engager une généralisation difficile à inverser. Si une incertitude décisive subsiste, limiter le déploiement permet de ne pas engager immédiatement tous les moyens prévus. Encore faut-il pouvoir modifier ou arrêter le service : les travaux de transfert, les engagements contractuels et les moyens nécessaires pour poursuivre l’activité autrement font partie de cette décision. Un arrêt annoncé comme possible n’est pas une véritable protection s’il impose une charge que l’entreprise ne peut pas supporter.

Les méthodes d’évaluation des coûts peuvent donc fonder une décision d’investissement IA fiable si elles éprouvent les gains attendus et permettent d’identifier les charges qui feraient changer le choix. Elles ne garantissent pas l’exactitude de chaque dépense. Tant qu’une incertitude décisive subsiste, l’engagement doit rester proportionné aux conséquences que l’entreprise peut supporter. La décision porte alors autant sur ce qu’elle choisit d’engager maintenant que sur ce qu’elle pourra encore modifier après les premiers usages.