Calculer le retour sur investissement d'un projet IA, avant et après

Pourquoi calculer avant de lancer

Un projet IA se décide souvent sur une impression. Une démonstration réussie, un concurrent qui communique, une équipe débordée qui réclame de l'aide. Ces signaux sont réels, mais ils ne disent pas si le projet rapportera plus qu'il ne coûtera. Le calcul du retour sur investissement sert à trancher cette question avant d'engager un budget, puis à vérifier après la mise en service que la réponse tenait.

Ce calcul n'a rien de sophistiqué. Il demande surtout de l'honnêteté sur deux points que les projets IA ont tendance à maquiller : les coûts qui continuent après la livraison, et le temps humain qui reste nécessaire une fois l'outil en place. Cet article détaille la méthode que nous suivons, poste par poste, avec une illustration chiffrée présentée comme telle. Pour un exemple appliqué à une équipe commerciale, notre article sur le FDE pour les équipes sales déroule déjà un calcul complet : nous ne le répétons pas ici.

Poser la bonne question avant de compter

Un calcul de retour sur investissement répond à une décision précise. Avant de sortir un tableur, écrivez la décision en une phrase : « faut-il automatiser la préparation des réponses aux demandes écrites de notre service client ? », « faut-il construire un outil de tri des pièces justificatives pour la comptabilité ? ». Une question floue produit un calcul flou, parce qu'on ne sait plus quels coûts et quels gains inclure.

Précisez ensuite l'alternative. Le projet se compare toujours à quelque chose : ne rien changer, embaucher, paramétrer un outil existant, ou passer par un connecteur du marché. Le retour sur investissement d'un projet IA n'a de sens que face à cette alternative. Si un simple paramétrage de votre logiciel actuel règle la moitié du problème, c'est ce paramétrage qui sert de point de comparaison, et le projet IA doit faire mieux que lui.

Les coûts complets, poste par poste

La plupart des estimations ne retiennent que le coût de construction. C'est le plus visible, et souvent pas le plus lourd sur la durée. Nous comptons quatre familles de coûts.

La construction

Elle couvre le cadrage, la conception, le développement, l'intégration aux outils existants et les tests. L'intégration est le poste le plus souvent sous-estimé : brancher un outil sur une API propre va vite, le brancher sur des exports manuels ou des données éparpillées dans plusieurs logiciels demande un vrai travail. Notre article sur ce que coûte un agent IA en production détaille ces postes et les questions à poser avant de chiffrer.

Ajoutez le temps de vos propres équipes. Les personnes qui expliquent leur métier, fournissent des exemples, testent les premières versions et valident les règles ne travaillent pas sur autre chose pendant ce temps. Ce temps interne est un coût réel, même s'il n'apparaît sur aucune facture.

L'exploitation

Un outil en production doit être hébergé, surveillé, sauvegardé et mis à jour. Les logiciels dont il dépend évoluent, les modèles de langage sont remplacés par de nouvelles versions, les règles métier changent. Prévoyez un budget récurrent de maintenance, même modeste, plutôt que de découvrir ce poste au premier incident.

La consommation

Chaque appel à un modèle de langage est facturé à l'usage. Chez Anthropic, par exemple, la grille publiée facture au million de jetons, avec un tarif différent pour le texte envoyé au modèle et pour le texte qu'il produit, la production étant plus chère. La même grille indique que le traitement par lots, pour les tâches qui n'ont pas besoin d'une réponse immédiate, divise par deux le prix des jetons, et que la mise en cache des consignes répétées réduit fortement le coût des lectures suivantes. Ces choix techniques changent la facture d'un même projet. Le coût de consommation se calcule donc par opération traitée, puis se multiplie par le volume attendu, en envisageant le cas où le volume double.

La consommation non maîtrisée figure d'ailleurs parmi les dix risques recensés par l'OWASP pour les applications à base de modèles de langage. Un plafond de dépense et un suivi par opération font partie du projet, au même titre que le code. Notre cadre CADRE pour piloter le coût de l'IA décrit comment organiser ce suivi.

Le temps humain de relecture

C'est le poste que presque tous les calculs oublient, et celui qui fait le plus souvent échouer un projet sur le papier. Il mérite sa propre section.

Le temps de relecture, le coût qu'on oublie

Un outil IA ne rend presque jamais une tâche entièrement automatique. Il prépare, propose, trie ou résume, et une personne relit avant que le résultat ne parte. Cette relecture prend du temps, et ce temps doit être déduit du gain. Un brouillon de réponse qui demande autant de corrections que d'écrire la réponse soi-même ne rapporte rien.

Trois questions permettent d'estimer ce poste. Quelle part des cas l'outil traite-t-il correctement sans retouche ? Combien de temps prend la relecture d'un cas correct, et celle d'un cas à corriger ? Quelle part des cas l'outil ne sait pas traiter du tout, et renvoie donc au circuit manuel ?

À cela s'ajoute la supervision : relire régulièrement un échantillon des résultats, repérer les dérives, mettre à jour les consignes quand le métier change. Ce travail est récurrent, et il revient à une personne qui connaît bien le métier, donc dont le temps a de la valeur.

Certaines tâches exigent une relecture systématique, quel que soit le taux de réussite de l'outil. Tout ce qui engage l'entreprise, un prix, un délai, une référence contractuelle, doit être calculé par le système à partir de vos données et vérifié, jamais produit librement par le modèle. Nous l'expliquons dans pourquoi un agent IA ne doit jamais annoncer un prix. Ce contrôle a un coût, et il se compte.

Les gains à compter, et comment les exprimer

Les gains d'un projet IA se rangent en quatre familles. Toutes ne se mesurent pas avec la même précision, et c'est normal. L'important est de dire, pour chacune, comment on la mesure.

Le temps rendu

C'est le gain le plus fréquent et le plus facile à mesurer : le temps passé sur une tâche avant, moins le temps passé après, relecture comprise. Il se valorise au coût horaire chargé des personnes concernées. Une précision compte : ce temps n'a de valeur que s'il est réemployé. Si le temps libéré n'est affecté à rien, le gain reste théorique. Écrivez à quoi il servira : traiter plus de demandes, réduire les heures supplémentaires, absorber une croissance sans recruter, consacrer plus de temps aux dossiers complexes.

Les erreurs évitées

Une ressaisie évitée, c'est aussi une faute de frappe évitée. Une vérification automatique de cohérence, c'est une facture erronée qui ne part pas. Ce gain se mesure en comptant les erreurs avant et après, puis en estimant ce que coûte une erreur : le temps pour la corriger, l'avoir émis, le client mécontent. Quand ce coût unitaire est difficile à établir, gardez au moins le nombre d'erreurs comme indicateur.

Les délais raccourcis

Répondre plus vite à une demande, envoyer une proposition le jour même, clôturer un mois comptable plus tôt. Ces gains se mesurent en durée entre deux événements datés, par exemple entre la réception d'une demande et l'envoi de la réponse. Leur valeur financière est indirecte, mais elle se discute avec les métiers : une réponse plus rapide change-t-elle le taux de transformation, la satisfaction, la trésorerie ?

Les revenus

Certains projets créent du chiffre d'affaires : plus de demandes traitées, des relances qui ne tombent plus dans l'oubli, un service nouveau pour les clients. C'est le gain le plus séduisant et le plus difficile à attribuer, parce que d'autres facteurs jouent sur les ventes au même moment. Présentez-le à part, avec prudence, et ne fondez jamais la décision uniquement sur lui.

Mesurer avant : la ligne de base

Sans mesure de départ, aucun retour sur investissement ne peut être vérifié. La ligne de base décrit la situation actuelle avec des chiffres relevés, pas estimés de mémoire.

• Le volume. Combien de fois la tâche revient-elle par jour, par semaine, par mois ? Les journaux de vos outils, la messagerie ou le logiciel de gestion donnent souvent ce chiffre.
• Le temps unitaire. Combien de temps prend une occurrence ? Chronométrez sur un échantillon réel, en distinguant les cas simples des cas complexes. Les estimations déclaratives sont presque toujours fausses, dans un sens ou dans l'autre.
• La qualité. Combien d'erreurs, de reprises, de réclamations ? Choisissez un indicateur que vous saurez relever de la même façon après.
• Les délais. Quelle durée entre le début et la fin du processus ? Relevez-la à partir de dates enregistrées dans vos outils.

Cette mesure se fait sur le terrain, aux côtés des personnes qui font le travail. C'est exactement ce que fait un ingénieur en FDE as a service pendant la phase d'observation : il regarde les gestes réels, les chronomètre, et produit une ligne de base que l'équipe reconnaît comme juste.

Une illustration chiffrée, à lire comme une hypothèse

Les chiffres qui suivent sont des hypothèses posées pour illustrer la méthode. Ils ne décrivent aucun client et aucun résultat mesuré. Chaque organisation les remplace par sa propre ligne de base.

Prenons un service qui reçoit des demandes écrites de clients. Hypothèses : mille demandes par mois, douze minutes de traitement par demande aujourd'hui. Le temps actuel est donc de douze mille minutes, soit deux cents heures par mois.

Un outil IA prépare un projet de réponse à partir de l'historique du client et de la base documentaire. Hypothèses après mise en service : l'outil traite quatre-vingt-cinq pour cent des demandes, et chacune de ces demandes demande quatre minutes de relecture et d'ajustement. Les quinze pour cent restants sont trop particuliers et repartent dans le circuit manuel, à douze minutes chacune. La supervision, relecture d'échantillons et mise à jour des consignes, prend six heures par mois.

Le calcul donne huit cent cinquante demandes à quatre minutes, soit trois mille quatre cents minutes, plus cent cinquante demandes à douze minutes, soit mille huit cents minutes. Total : cinq mille deux cents minutes, environ quatre-vingt-sept heures, auxquelles s'ajoutent les six heures de supervision. Le temps après mise en service est d'environ quatre-vingt-treize heures par mois. Le gain est d'environ cent sept heures par mois.

Refaisons le calcul sans compter la relecture ni la supervision, comme le font beaucoup d'estimations rapides : seules les cent cinquante demandes manuelles resteraient, soit trente heures, et le gain affiché serait de cent soixante-dix heures. L'écart entre les deux calculs est considérable. Il vient uniquement du temps humain que l'outil ne supprime pas.

Pour passer en valeur, multipliez le gain horaire par votre coût horaire chargé. Retranchez le coût mensuel d'exploitation et de consommation. Le résultat est le gain net mensuel. Divisez le coût de construction par ce gain net pour obtenir le délai de retour. Si le gain net est faible ou négatif, le projet ne se justifie pas par le temps rendu, et il doit trouver sa justification ailleurs : erreurs évitées, délais, revenus, ou pas du tout.

Mesurer après, avec la même méthode

Une fois l'outil en service, refaites exactement les mêmes mesures : même indicateur, même méthode de relevé, même périmètre. Si vous avez chronométré un échantillon de demandes avant, chronométrez un échantillon comparable après. Si vous avez compté les erreurs à partir des avoirs émis, comptez-les de la même façon. Changer de méthode entre les deux mesures rend la comparaison inutilisable.

Laissez passer une période d'adaptation avant la mesure finale. Les premières semaines, les utilisateurs découvrent l'outil, se méfient de ses propositions et relisent tout deux fois. Mesurer trop tôt sous-estime le gain. Mesurer une seule fois, sur une période exceptionnellement calme ou chargée, fausse aussi le résultat.

Comparez enfin le réel à l'estimation, poste par poste. Le taux de cas traités est-il celui prévu ? La relecture prend-elle le temps attendu ? La consommation suit-elle le volume ? Cet écart est l'information la plus utile du projet : il montre quelle hypothèse était trop optimiste et où agir. C'est aussi la raison pour laquelle nous construisons par lots, en mesurant chaque lot avant de lancer le suivant, comme décrit dans notre méthode automatisation.

Fixez aussi, dès le départ, un scénario prudent et un critère d'arrêt. Refaites le calcul avec un taux de cas traités plus bas et une relecture plus longue : si le projet reste rentable, la décision est solide. Et si le gain mesuré après la période d'adaptation reste sous le seuil choisi, l'outil est corrigé ou retiré.

Les pièges qui faussent le calcul

• Compter le temps gagné sans la relecture. L'illustration ci-dessus montre l'ampleur de l'erreur.
• Oublier la consommation en cas de succès. Un outil apprécié est plus utilisé que prévu. Calculez le coût par opération et regardez ce qu'il devient si le volume augmente.
• Additionner des gains qui se recouvrent. Une erreur évitée fait aussi gagner le temps de sa correction. Ne comptez pas ce temps deux fois, dans le temps rendu et dans les erreurs évitées.
• Valoriser du temps qui ne sera pas réemployé. Des minutes éparpillées dans la journée de chacun ne se transforment pas toujours en capacité utile.
• Extrapoler un prototype. Un prototype fonctionne sur des cas choisis. En production, les cas difficiles arrivent, et le taux de réussite baisse. Notre article sur les prérequis de mise en production d'un POC détaille ce qui change entre les deux.
• Ignorer la qualité des données. Si les données d'entrée sont incomplètes, l'outil produit des résultats à reprendre, et le gain fond. Un travail préalable de data et intégration est parfois le vrai premier chantier.
• Changer de méthode de mesure en route. Une mesure avant déclarative et une mesure après chronométrée ne se comparent pas.

Par où commencer

Choisissez une tâche fréquente, mesurable et pénible, dont vous pouvez relever le volume et le temps unitaire dès maintenant. Écrivez la décision à prendre et l'alternative. Relevez la ligne de base sur un échantillon réel. Vous aurez alors de quoi juger n'importe quelle proposition, la nôtre comprise.

Si vous voulez faire ce travail avec nous, notre diagnostic IA commence par cette mesure : il identifie les tâches où un outil rend réellement du temps, chiffre les coûts complets avec vous, et vous remet un calcul que vous pourrez vérifier après la mise en service.

Sources

• Anthropic, grille tarifaire de l'API Claude (jetons d'entrée et de sortie, traitement par lots, mise en cache)
• OWASP, Top 10 des risques pour les applications à base de LLM (2025), dont LLM10 Unbounded Consumption

Questions fréquentes

Peut-on calculer un retour sur investissement sans connaître encore le coût du projet ?

Oui, en partie. La ligne de base et l'estimation du gain se calculent sans connaître le coût de construction. Vous obtenez alors le montant maximal qu'il est raisonnable d'investir, ce qui aide à juger les propositions que vous recevrez.

Faut-il valoriser le temps gagné au salaire brut ou au coût chargé ?

Au coût chargé, c'est-à-dire ce que l'heure coûte réellement à l'entreprise. Votre service paie ou votre expert-comptable peut vous donner ce montant par profil. Gardez le même coût horaire pour la mesure avant et après.

Que faire si les équipes refusent d'être chronométrées ?

Expliquez que la mesure porte sur la tâche, jamais sur la personne, et que les résultats ne serviront pas à évaluer qui que ce soit. Les journaux des outils donnent souvent une bonne partie des volumes et des délais sans chronomètre. Associer un représentant de l'équipe au relevé aide aussi à le faire accepter.

Un projet non rentable en temps gagné peut-il quand même valoir la peine ?

Oui, si un autre gain le justifie clairement : une obligation réglementaire mieux tenue, des erreurs coûteuses évitées, un délai client décisif. Il faut alors l'écrire explicitement et mesurer ce gain-là avec la même rigueur.

Qui doit porter le calcul en interne ?

Idéalement la personne qui sera responsable du processus après la mise en service, avec l'appui de la finance pour les coûts horaires. Le prestataire peut préparer le calcul, mais c'est à l'entreprise de valider les hypothèses et de relever la mesure après.