Le chiffre qui fait passer l'IA pour gratuite
Chiffrez une même tâche des deux façons. Un ticket de support trié par un modèle - le lire, le classer, l'aiguiller, rédiger l'accuse de réception - consomme environ 500 tokens en entrée et 50 en sortie, ce qui, sur Haiku 4.5 aux tarifs publiés, revient à $0.00075. Le même ticket traité par une personne a un coût chargé de $22 de l'heure, trente tickets par heure, coûte $0.73. C'est un écart d'environ 978 fois, et chaque chiffre qui le compose est une hypothèse que vous pouvez remplacer : payez $30 de l'heure, traitez 20 tickets, utilisez un modèle plus gros, l'écart reste large de trois ordres de grandeur.
| Tâche | Coût / tâche |
|---|---|
| IA · Haiku 4.5 | $0,00075 |
| Une personne | $0,73 |
| Humains contre IA | ~978× |
Ce que coûte une tâche
Tri de tickets, modélisé · échelle logarithmique, chaque graduation vaut 10×
Modélisé, pas mesuré : tri sur Haiku 4.5 aux tarifs publiés (500 tokens en entrée à $1 / 1M, 50 en sortie à $5 / 1M = $0.00075) contre une personne dont le coût chargé est de $22 de l'heure et qui traite 30 tickets par heure ($0.73). L'échelle est logarithmique. Le salaire, le débit et le nombre de tokens sont des variables que vous devriez remplacer par les votres ; l'écart subsiste avec n'importe quel jeu réaliste de ces valeurs.
Des chiffres pareils donnent l'impression que l'IA est un oui automatique, et c'est précisément ainsi que les dirigeants finissent déçus. Parce que le prix par tâche n'est pas la décision. C'est le plus petit chiffre de la pièce.
La vraie barrière, c'est le développement
Entre vous et ces fractions de centime se dresse un coût fixe : quelqu'un doit construire la fonctionnalité. La brancher à votre système de tickets, écrire et tester les prompts, gérer les cas limites, placer un écran de relecture devant, la déployer. Que ce soit un script à $3,000 ou une intégration à $20,000 depend du périmètre, et cela se comporte comme toute autre décision d'investissement que prend votre entreprise : il faut le récupérer sur les économies, mois après mois. L'IA n'a pas supprime cette logique ; elle a seulement rendu le coût marginal si faible que le développement représente pratiquement tout l'investissement. Si vous mettez cela en balance avec l'achat d'un outil prêt à l'emploi, c'est une décision à part entière, mais le calcul ci-dessous fonctionne de la même manière dans les deux cas.
La formule du seuil de rentabilité
Le modèle entier tient en une ligne : retour sur investissement en mois = coût du développement ÷ (tâches par mois × économie par tâche), où l'économie par tâche correspond à ce qu'une personne coûte pour l'accomplir moins ce que le modèle coûte. Le coût horaire chargé divisé par le nombre de tâches par heure donne le côté humain ; le calcul des tokens donne le côté IA. Trois valeurs d'entrée, une division, et chacune d'elles vous appartient et peut être corrigée : vos salaires, votre cadence, votre devis.
Le même développement à trois volumes
| Volume | Seuil de rentabilité |
|---|---|
| 10,000 tâches / mo | ~5 semaines |
| 3,000 tâches / mo | ~3,7 mo |
| 300 tâches / mo | ~3 an |
Le même développement à trois volumes
Développement $8,000; chaque tâche: IA ~$0,00075 contre une personne ~$0,73 (modélisé)
Coût cumulé de personnes effectuant la tâche (trois volumes) contre un développement unique à $8,000 fonctionnant sur l'IA. Hypothèses de tâche identiques au graphique ci-dessus ; la consommation d'IA à ces volumes va de $0.23 à $7.50 par mois, si bien que la courbe ambre apparaît plate. Le seuil de rentabilité tombe à environ 5 semaines pour 10,000 tâches par mois, 3.6 mois à 3,000, et à peu près 3 ans à 300. Mettez-y votre propre salaire, débit et devis de développement ; c'est la forme qui compte.
Voici le graphique qui tranche la plupart des débats développer-ou-non, parce que la seule chose qui change entre les trois courbes, c'est le volume. À 10,000 tâches par mois, le développement à $8,000 est récupéré en environ cinq semaines ; le même développement à 300 tâches par mois traîne sur environ trois ans, ce qui, en termes logiciels, est une tout autre décision. Rien concernant le modèle, les prompts ou la qualité n'a change. Le volume à lui seul a fait passer la réponse d'un oui évident à un non probable.
Le tableau du retour sur investissement
Trouvez votre colonne, trouvez votre devis, et vous obtenez une première réponse défendable avant que quiconque ouvre un IDE.
| 300 tâches / mois | 1,000 / mois | 3,000 / mois | 10,000 / mois | |
|---|---|---|---|---|
| Économie mensuelle | $220 | $733 | $2,198 | $7,326 |
| Développement à $3,000 rentabilisé en | 13.7 mois | 4.1 mois | 1.4 mois | 0.4 mois |
| Développement à $8,000 | 36.4 mois | 10.9 mois | 3.6 mois | 1.1 mois |
| Développement à $20,000 | 91.0 mois | 27.3 mois | 9.1 mois | 2.7 mois |
Deux lectures honnêtes de ce tableau. Le long d'une colonne : la discipline de périmètre paie, car à 1,000 tâches par mois, la différence entre un développement à $3,000 et un à $20,000 est la différence entre quatre mois et deux ans. Le long d'une ligne : le volume est un levier, car le même développement à $8,000 passe d'une erreur d'arrondi à un choix injustifiable selon le nombre de tâches que vous lui donnez réellement à traiter. Quand une estimation atterrit dans la zone grise du milieu, l'experience la moins chère est généralement un développement plus modeste qui teste l'hypothèse de volume, plutôt qu'un développement plus gros qui parie dessus.
Quand le prix des tokens compte vraiment
Le tri est une tâche bon marché ; tout ne l'est pas. Une tâche de rédaction qui lit un brief de 2,000 tokens et rédige un document de 1,500 tokens sur Opus 4.8 coûte environ $0.05 par tâche, et le travail en contexte long peut grimper bien au-delà. Cela se compare tout de même à $0.37 pour une seule minute de temps humain, donc l'écart subsiste, mais à des dizaines de milliers de tâches, la ligne marginale cesse d'être un simple décor : c'est la différence entre des tokens qui coûtent $8 par mois et $500. C'est là que les multiplicateurs cachés de la première partie et les leviers de la deuxième partie viennent s'imbriquer dans ce modèle : ils modifient l'économie par tâche, ce qui raccourcit le retour sur investissement. Ils font rarement basculer à eux seuls la décision de développer, mais ils déterminent à quel point une bonne décision devient meilleure.
Ce que ce modèle laisse de côté
Un peu d'honnêteté sur ses limites. Si une personne relit encore chaque sortie, votre économie par tâche est l'écart de temps de relecture, pas l'integralite des $0.73, et le retour sur investissement s'allonge en conséquence ; le modèle fait ses preuves là où il boucle entièrement la plupart des tâches et escalade le reste. Les erreurs ont un prix que cette formule ne voit pas, donc les tâches où une mauvaise réponse coûte cher ont besoin d'un contrôle peu coûteux dans la boucle avant que le calcul du volume ne veuille dire quoi que ce soit. Et le développement n'est pas la dernière facture : les prompts dérivent, les systèmes changent, quelqu'un maintient l'intégration. Rien de tout cela ne casse le modèle ; cela appartient simplement à la colonne du développement, et un pilote dimensionné pour tester votre hypothèse de volume est le moyen le moins cher de découvrir ce que les chiffres sont vraiment.
