Aller au contenu
SwankyForge
SwankyForge
Toutes les analyses
Article13 min de lecture

Quand l'IA réduit les heures, un prix fixe par jalon sur des tarifs publiés partage l'économie au lieu de la cacher

La facturation à l'heure donne chaque heure économisée au client, un prix fixe opaque la donne au prestataire ; un exemple chiffré montre une voie médiane que les deux parties peuvent vérifier.

Les assistants de code IA ont rendu certaines parties du travail d'ingénierie moins chères à produire. Les acheteurs le savent et réclament l'économie. Cette note porte sur qui la garde, et sur la raison pour laquelle la réponse dépend moins de l'outil que de la façon dont le travail est tarifé.

La version courte, si vous achetez

Il existe trois manières courantes de tarifer un même travail.

  • À l'heure. Vous payez chaque heure travaillée. Si les outils IA réduisent les heures, vous payez moins. Vous portez aussi le risque de dépassement, et le prestataire gagne moins pour être devenu plus rapide : la tarification ne lui donne donc aucune raison d'accélérer.
  • Prix fixe, sans détail. Vous connaissez le prix d'avance. Si le travail est devenu moins cher à produire, vous ne le voyez pas. Le prestataire garde toute l'économie jusqu'à ce que quelqu'un renégocie.
  • Tarifs publiés, prix fixe par jalon. Le prestataire montre les heures par rôle aux tarifs publiés, fixe le prix de chaque jalon et ne facture qu'après votre recette sur une métrique convenue avant le début du travail. Vous payez moins qu'avant et connaissez le chiffre à l'avance. Le prestataire garde la marge sur l'efficacité qu'il obtient réellement, et porte le risque s'il ne l'obtient pas.

La troisième est le modèle que nous proposons : des tarifs sur la page des tarifs, un calculateur qui multiplie les heures par rôle par ces tarifs, un prix fixé une fois le périmètre convenu, et une facture par jalon après recette. L'exemple chiffré ci-dessous montre le calcul avec des chiffres illustratifs.

Ce que fait le marché

La pression est explicite, et elle atteint les contrats avant même leur renouvellement.

  • Les clients veulent l'économie maintenant. En août 2026, Reuters a rapporté que les clients des grandes sociétés de services informatiques exigeaient « le même travail pour 25 % à 30 % de moins », selon les mots du directeur général de Persistent Systems. TCS a indiqué qu'environ 80 % des contrats de son segment finance, RH et services aux entreprises reposent désormais sur des mesures de résultat, ce qu'une personne au fait du dossier a décrit comme le double de la part de fin 2023. Le même article décrit un contrat d'automatisation de Cognizant qui partage les économies liées à l'IA entre prestataire et client, selon des personnes au fait de ses termes.
  • La renégociation n'attend pas le renouvellement. Un article de juin 2026 republié par HFS Research décrit des clients qui rouvrent des contrats dans les 24 mois pour capter les gains d'efficacité de l'IA, les contrats de plus de 50 millions de dollars par an étant sous la plus forte pression. Le directeur général de HFS a décrit une conversation qui s'éloigne des ETP et des grilles tarifaires pour aller vers des engagements de productivité, une tarification au résultat et le partage des gains.
  • Les marges ont jusqu'ici globalement tenu. UpperEdge a examiné les résultats du T2 2026 de onze grands prestataires. Plusieurs ont élargi leur marge opérationnelle : Wipro de 80 points de base à 17,3 %, Tech Mahindra de 60 à 11,1 %, Accenture de 20 à 17,0 %. La marge de TCS s'est contractée à 24,0 %, ce qu'UpperEdge attribue aux hausses de salaires et aux dépenses d'infrastructure IA, et la marge d'EBITDA ajusté de Kyndryl est passée de 17,3 % à 14,2 %. La lecture d'UpperEdge est que l'investissement dans l'IA « se finance lui-même plutôt que de générer de nouvelles dépenses clients ». L'analyse note aussi que TCS affirme désormais pouvoir s'engager sur une amélioration de 10–15 % grâce à l'IA dès le premier jour d'un contrat, contre les 3–5 % traditionnels étalés sur la durée du contrat.
  • La direction est fixée. IDC s'attend à ce que 30 % de tous les engagements avec des prestataires de services soient au résultat d'ici 2029.

Les grands contrats d'externalisation ne sont pas le marché d'un laboratoire de deux ingénieurs. La mécanique est pourtant la même à 15 000 $ qu'à 50 millions de dollars. Quelqu'un décide qui garde l'économie, et le contrat montre cette décision ou la cache.

Quelle est l'ampleur de l'économie ? Plus faible et plus incertaine que ne le disent les titres

Le code n'est qu'une fraction du travail. Le Technology Report 2025 de Bain a constaté que les équipes qui utilisent des assistants de code IA gagnent 10–15 % de productivité. Des gains de 25–30 % n'apparaissent que là où l'IA s'accompagne d'une refonte de tout le processus. Écrire et tester le code représente environ 25–35 % du temps entre l'idée et le lancement, donc même une forte accélération de l'écriture du code fait beaucoup moins bouger le total.

La mesure est difficile. L'essai randomisé de METR de 2025 a montré que des développeurs open source expérimentés mettaient 19 % de temps en plus avec les outils IA. En février 2026, METR a indiqué que ses données de suivi montraient « quelques indices d'accélération » et que les développeurs étaient probablement plus rapides début 2026 que début 2025. Il a aussi qualifié ces données de preuve très faible de l'ampleur du changement, parce que de plus en plus de développeurs refusaient de travailler sans IA et sortaient ainsi de la comparaison. Ses deux nouveaux intervalles de confiance incluent toujours l'absence d'effet.

Promettre une économie à l'avance est un pari. Dans le même article de Reuters, le directeur général de Tech Mahindra a déclaré que certains concurrents intégraient dans leurs prix des gains de productivité de 70–80 % sur cinq à sept ans et garantissaient des prix sur cette base, et que son entreprise avait choisi de ne pas prendre ce risque.

Nous n'avons pas non plus mesuré notre propre économie. Un contrat qui promet une remise IA d'un pourcentage fixe promet quelque chose que personne ne peut encore vérifier. Un contrat qui fixe le prix d'un jalon et laisse le risque d'estimation au prestataire n'a pas besoin de ce chiffre.

Un exemple chiffré (illustratif)

Tout dans cette section est illustratif. Les heures économisées sont une hypothèse, pas une mesure. Les chiffres de coût sont des valeurs provisoires, pas notre structure de coûts.

Référence. Prenez le modèle de copilote RAG de notre calculateur : 310 heures réparties sur cinq rôles, 14 500 € aux tarifs publiés et en complexité standard. Considérez-le comme l'estimation sans assistance IA. Supposez ensuite que l'assistance IA réduit les heures consacrées au code répétitif, aux tests et à la documentation, rôle par rôle :

Rôle Tarif (USD/h) Heures avant Heures après (supposées) Où vont les heures
Ingénieur ML 50 120 108 (−10 %) harnais d'évaluation et loaders ; la conception de l'évaluation est inchangée
Ingénieur data 45 60 52 (−13 %) ossature d'ingestion, tests de données
Ingénieur backend 40 60 45 (−25 %) ossature d'API, tests d'intégration
Ingénieur MLOps 55 40 32 (−20 %) configuration de la CI, tableaux de bord, runbooks
Product manager 40 30 30 (0 %) métrique, périmètre, échanges avec le client
Total 310 h = 14 500 € 267 h = 12 500 € −43 h, −13,9 %

Nous avons choisi 13,9 % parce que ce chiffre se situe dans la fourchette de 10–15 % de Bain pour les assistants seuls.

Deux valeurs provisoires de plus. Une heure de réalisation coûte au prestataire 60 % de son tarif facturé, et les outils IA coûtent 300 € sur la durée du jalon.

Quatre façons de le tarifer :

Tarification Le client paie Coût prestataire Marge prestataire Marge par heure travaillée
A. À l'heure, avant l'IA (310 h travaillées) 14 500 € 8 700 € 5 800 € (40,0 %) 18,71 €
B. À l'heure, après l'IA (267 h) 12 500 € 7 800 € 4 700 € (37,6 %) 17,60 €
C. Fixe à l'ancien prix, après l'IA (267 h) 14 500 € 7 800 € 6 700 € (46,2 %) 25,09 €
D. Jalon fixe chiffré à 288 h, livré en 267 h 13 480 € 7 800 € 5 680 € (42,1 %) 21,27 €

Le calcul. En A, le coût vaut 60 % × 14 500 €. En B, C et D, il vaut 60 % × 12 500 € + 300 €. La marge par heure travaillée est la marge divisée par les heures réellement travaillées : 310 en A, 267 dans les autres cas. En D, le prestataire s'engage sur une estimation qui compte la moitié de l'économie attendue dans chaque rôle : ML 114 h, data 56, backend 52, MLOps 36, PM 30. Cela fait 288 heures, et 13 480 € aux tarifs publiés. (Le calculateur arrondit chaque rôle à la centaine de dollars la plus proche, il afficherait donc 13 500 €.)

Ce que dit le tableau :

  • B, c'est ce que la facturation à l'heure fait à un prestataire qui devient plus rapide. Le client économise 2 000 €. La marge du prestataire baisse de 1 100 €, et sa marge par heure travaillée tombe 6 % sous son niveau d'avant l'IA. Il ne la récupère que s'il peut vendre les 43 heures libérées à quelqu'un d'autre. Une grande société avec une file d'attente de travail le peut. Un laboratoire de deux ingénieurs avec un ou deux projets simultanés ne le peut souvent pas. Dans les deux cas, la tarification récompense la lenteur.
  • C, c'est ce que fait un prix fixe opaque. Le prestataire garde toute l'économie et gagne 34 % de plus par heure travaillée qu'en A. Le client ne peut pas le voir. Quand il le découvre, le résultat est la renégociation en cours de contrat que décrivent les articles ci-dessus.
  • D partage l'économie au grand jour. Le client paie 1 020 € (7,0 %) de moins qu'avant l'IA, connaît le chiffre avant le début du travail et ne paie qu'après la recette du jalon. Le prestataire gagne environ 14 % de plus par heure travaillée qu'en A. Les deux parties peuvent voir comment le prix a été construit : heures par rôle, multipliées par des tarifs publiés.

D a aussi un inconvénient, et il revient au prestataire. Si l'économie n'apparaît pas et que le travail prend les 310 heures complètes, le coût est de 9 000 € (60 % × 14 500 € + 300 €) et la marge tombe à 4 480 € (33,2 %). Le client paie toujours 13 480 €. Porter ce risque est ce qui donne droit au prestataire au gain potentiel.

Par rapport à B, le client en D paie 980 € de plus sur le papier. En échange, il obtient un chiffre fixe au lieu d'un compteur ouvert, et ne paie qu'après recette. Savoir si cela vaut 980 € dépend de la confiance que vous accordez à l'estimation. C'est pour cela que les heures sont publiées.

Pourquoi la métrique et l'étape de recette comptent

Un prix fixe sans définition de ce qui est « terminé » ne fait que déplacer le débat à la fin du projet. Deux choses font fonctionner l'option D.

La métrique est convenue avant l'entraînement et inscrite au contrat. Pour un copilote RAG, par exemple, cela pourrait être la part des réponses jugées correctes sur un jeu de questions convenu, plus une limite de temps de réponse.

La recette précède la facture. Vous vérifiez le jalon par rapport à la métrique avant de payer. Si du code écrit par l'IA a pris un raccourci, cela apparaît à la recette, pas après le paiement final.

C'est plus étroit que la tarification au résultat au sens où l'entendent IDC et TCS, qui lie les honoraires aux résultats de l'entreprise. Pour les systèmes de ML, un résultat métier comme le chiffre d'affaires dépend aussi des prix, du stock, du marketing et de la saison, dont aucun n'est contrôlé par le prestataire. Une métrique du système que les deux parties peuvent mesurer à la recette est ce sur quoi on peut honnêtement engager un prestataire. Le résultat métier se mesure ensuite, par un test A/B.

Où cela ne fonctionne pas

Le risque de recherche. Si personne ne sait si les données peuvent soutenir le modèle, un prix fixe est un pari pour les deux parties. Faites d'abord un cadrage payant ; le teardown gratuit vous dit si vous en avez besoin. Le nôtre prend 2–3 semaines et coûte 6k–14k €.

Un périmètre qui change chaque semaine. Un jalon fixe exige un périmètre figé pour ce jalon. Si c'est impossible, une facturation à l'heure plafonnée est plus honnête.

Des économies qui n'arrivent jamais jusqu'au devis suivant. Avec D, le prestataire garde la marge supplémentaire sur ce jalon. Dans le devis suivant, les heures par rôle doivent refléter ce qu'il a appris. Si elles ne baissent pas, demandez pourquoi. C'est ce contrôle qui empêche D de dériver vers C.

Quoi demander à un prestataire au sujet des économies liées à l'IA

  1. Quelles parties de ce travail seront assistées par l'IA, et quel effet supposez-vous sur les heures, rôle par rôle ?
  2. Cette hypothèse est-elle intégrée au prix que vous avez proposé ? Montrez les heures et les tarifs.
  3. Qui paie si l'estimation est fausse, dans un sens ou dans l'autre ?
  4. Que recettons-nous avant chaque facture, et sur quelle métrique ?
  5. Avez-vous mesuré votre propre gain de vitesse ? Comment, et sur quelle fenêtre ? Une auto-évaluation n'est pas une mesure : les participants de METR pensaient être 20 % plus rapides alors qu'ils étaient 19 % plus lents.
  6. Qui relit le code écrit par l'IA, et quels contrôles s'exécutent à chaque changement ?
  7. Quels outils IA verront notre code et nos données, et à quelles conditions ?
  8. Le prochain devis reflétera-t-il ce que vous avez appris sur celui-ci ?

Un prestataire qui répond vite à ces questions a déjà fait le calcul. Le nôtre commence par le calculateur de la page des tarifs, qui montre les heures et les tarifs par rôle pour votre projet.

Sources

Un processus vous coûte trop cher ?

Parlez-nous-en. Le premier appel est gratuit, et si l'IA n'est pas la réponse, nous le disons.

Discuter de votre tâche