Acheter et vendre une prestation IT à l'ère de l'IA : le nouveau cahier des charges

Une prestation IT peut aujourd'hui produire davantage avec moins de travail humain visible. Pour autant, l'acheteur ne peut pas simplement exiger une remise « parce qu'il y a de l'IA », et le prestataire ne peut plus traiter son automatisation comme une boîte noire. Le contrat doit changer de centre de gravité : moins contrôler les moyens mobilisés, davantage définir la preuve attendue, les évaluations, les droits de décision, les coûts technologiques, les responsabilités et les conditions de sortie.

La question devient particulièrement concrète pour les ESN. Selon l'Observatoire Numeum-Xerfi publié en juillet 2026, 49 % des ESN interrogées citent la pression sur les prix parmi leurs principaux freins et 58 % disent se repositionner par l'automatisation et l'IA. Dans le même temps, les gains de productivité liés à l'IA sont estimés par l'étude à 15 % en 2025 et 22,3 % en 2027 chez les ESN, mais Numeum souligne qu'ils restent difficiles à convertir en marge.

Voilà le nouveau problème contractuel : qui bénéficie du gain de productivité, qui supporte les nouveaux coûts, et qui assume lorsque l'automatisation se trompe ?

En bref

Le vrai sujet n'est pas de savoir combien d'IA le prestataire utilise

La tentation est compréhensible.

Un acheteur découvre qu'une ESN utilise des agents pour générer du code, écrire des tests, produire de la documentation ou préparer des analyses. Il en conclut que la prestation devrait coûter moins cher. Le prestataire, lui, craint que chaque gain de productivité ne se transforme immédiatement en remise commerciale.

Cette tension existe déjà côté conseil : une focalisation excessive sur le TJM peut pousser acheteurs et fournisseurs dans une négociation stérile, alors que la valeur se déplace vers la preuve, la gouvernance, les actifs et la capacité effectivement transférée au client. Le nouveau cahier des charges gagne à intégrer la preuve rapide, la gouvernance de l'IA, le rôle de l'humain et des livrables utilisables au-delà de la mission.

La transposition aux ESN doit toutefois être faite avec prudence. Une prestation IT ne produit pas seulement une recommandation : elle peut modifier un système en production, manipuler des données, introduire une vulnérabilité ou provoquer un incident. Il faut donc ajouter aux critères économiques les tests, l'observabilité, les responsabilités opérationnelles, les coûts de modèles et la réversibilité.

Le bon contrat ne doit ni interdire l'automatisation, ni l'accepter comme une boîte noire. Il doit rendre explicites les conséquences de cette automatisation.

Ce déplacement change profondément le cahier des charges.

Commencer par une baseline, pas par une promesse de productivité

« Nous allons être 30 % plus rapides grâce à l'IA » est une mauvaise base contractuelle.

D'abord parce qu'il n'existe pas de taux universel de productivité IA applicable à toutes les prestations. Les résultats diffèrent selon le type de tâche, la qualité de la codebase, la maturité des tests, le contexte fourni aux agents, l'expérience des équipes et le temps nécessaire à la vérification. Les chiffres sectoriels de Numeum sont des estimations et déclarations agrégées, pas une garantie applicable à un contrat particulier.

Ensuite parce que la productivité n'est pas nécessairement la valeur recherchée. Sur une TMA, le client peut vouloir réduire les incidents. Sur une migration, diminuer le délai. Sur une application critique, améliorer d'abord la fiabilité. Sur un centre de services, absorber davantage de volume sans augmenter les coûts.

La première annexe d'un contrat augmenté devrait donc documenter l'état de départ : coût complet, volumes, délais, taux de défaut, rework, disponibilité, incidents, charge humaine et dette lorsqu'elle peut être mesurée.

C'est cette baseline qui permettra ensuite de dire si la prestation s'est réellement améliorée.

À mesure que l'effort humain devient moins observable, la baseline devient plus importante que le staffing pour objectiver la valeur.

Exiger une preuve rapide avant de négocier la grande promesse

La deuxième évolution consiste à réduire le temps entre la promesse commerciale et la première preuve.

Pas nécessairement un POC spectaculaire. Une preuve utile peut être beaucoup plus modeste : un workflow exécuté de bout en bout sur un échantillon réel, une cinquantaine de tickets rejoués, un lot de code migré avec ses tests, un agent tournant en shadow mode ou un jeu d'évaluations appliqué à des cas historiques.

Plusieurs signaux vont dans cette direction. Chez Qonto, des évaluations LLM sont intégrées à la CI afin de tester les produits IA lors des modifications de code. Chez Alan, l'ouverture de la contribution à des non-ingénieurs reste assortie d'une décision finale de merge côté engineering. Chez Roundtable, l'automatisation permet de faire remonter à l'humain une petite fraction des cas problématiques sur un flux régulé. Ces trois cas montrent des formes différentes de la même logique :

automatiser n'enlève pas le besoin d'un critère de preuve et d'un point de contrôle.

Ils ne démontrent toutefois pas qu'un modèle unique soit applicable partout : ces cas restent issus d'un panel de trente entreprises sélectionnées pour leurs signaux organisationnels, non représentatif.

Une preuve rapide doit donc servir à tester les hypothèses du contrat, pas à fabriquer artificiellement un succès commercial.

Demander de la transparence sur l'automatisation, sans exiger l'ouverture totale de la cuisine

Un acheteur doit-il savoir si le code a été écrit par un humain ou par un agent ?

Dans certains cas, oui. Dans d'autres, la question pertinente est moins l'auteur du code que les conditions dans lesquelles il a été produit, testé et validé.

Une transparence contractuelle utile devrait au minimum permettre de comprendre où l'IA intervient (analyse, code, test, documentation, support, décision, action sur le SI), quel est son niveau d'autonomie (suggestion, production sous review, exécution après approbation, exécution autonome limitée), quels fournisseurs tiers interviennent (modèles, clouds, plateformes d'agents et composants structurants), quelles données leur sont accessibles, ce qui est journalisé, et qui valide le résultat.

Cela ne signifie pas que le client doit automatiquement recevoir chaque prompt, chaque instruction système ou l'intégralité du savoir-faire propriétaire de l'ESN.

Il est recommandé d'identifier la structure contractuelle pertinente et les conditions imposées par les composants et modèles tiers, qui peuvent peser sur les droits d'utilisation du système.

La transparence pertinente porte sur le risque, les responsabilités et les dépendances. Elle ne doit pas se transformer en obligation générale de dévoiler toute la propriété intellectuelle du fournisseur.

Les évaluations doivent entrer dans le contrat

La recette traditionnelle repose volontiers sur une logique binaire : une fonction fait ce qui était prévu ou ne le fait pas.

Un système utilisant un modèle génératif introduit une difficulté supplémentaire : deux exécutions peuvent produire des résultats différents, et certains défauts apparaissent seulement sur des catégories particulières de cas.

Il est recommandé d'adapter la procédure de recette : conserver une traçabilité des tests et de leurs résultats, convenir de niveaux de performance acceptables, définir des seuils de tolérance et documenter les écarts ainsi que les mesures correctives.

C'est le rôle des évaluations : des tests reproductibles permettant de mesurer le comportement d'un système ou d'un agent sur un ensemble de cas pertinents.

Une annexe contractuelle pourrait ainsi préciser le corpus de référence, les cas critiques, les seuils minimaux, le taux d'erreur toléré, les modalités d'échantillonnage humain, les tests de non-régression et la procédure applicable lorsqu'un changement de modèle dégrade les résultats.

Cela change aussi la relation commerciale.

Le vendeur ne dit plus seulement : « notre agent fonctionne ».

L'acheteur peut demander : « sur quels cas l'avez-vous testé, avec quel niveau de résultat, et que se passe-t-il lorsque ce niveau n'est plus atteint ? »

Écrire noir sur blanc ce que l'humain doit encore décider

« Human-in-the-loop » est devenu une formule facile. Contractuellement, elle ne vaut presque rien si l'on ne précise pas à quel endroit se trouve réellement l'humain.

Valide-t-il un échantillon ? Chaque mise en production ? Seulement les cas à faible confiance ? Les actions irréversibles ? Les opérations de sécurité ? Peut-il arrêter l'agent ?

Plusieurs modèles de partage du travail existent entre humains et agents. Le modèle « humain sur les exceptions » exige notamment le suivi du taux d'exception, du taux d'erreur et du rework. Le modèle de développement agentique conserve également une étape d'arbitrage humain après production et première review automatisées.

La cybersécurité impose une vigilance supplémentaire. L'ANSSI recommande que les interactions critiques entre un système d'IA et le SI puissent être contrôlées par un humain et que l'assistance IA au développement de composants sensibles fasse l'objet de contrôles et de tests réguliers. En 2026, le CERT-FR a encore durci ce message pour certains outils agentiques sur postes de travail : lorsqu'une commande système ou une action à effet de bord est envisagée, il recommande une validation humaine obligatoire et une exécution isolée.

Le contrat doit donc comporter une véritable matrice d'autorité : ce que l'agent peut proposer, produire ou exécuter ; ce que le prestataire doit approuver ; ce qui exige l'autorisation du client ; et qui porte finalement la responsabilité.

Traiter les coûts de modèles comme une composante économique du service

L'automatisation n'est pas gratuite.

Aux coûts humains s'ajoutent désormais, selon les architectures, l'inférence, les abonnements, le stockage de contexte, les plateformes d'orchestration, l'observabilité, les tests et parfois plusieurs modèles utilisés en parallèle.

Cette économie crée de nouvelles questions de négociation.

Le prix comprend-il une enveloppe de consommation ? Un dépassement est-il refacturé ? À quel tarif ? Le prestataire peut-il changer de modèle pour réduire son coût ? Le client peut-il imposer un modèle plus cher pour des raisons de souveraineté ou de qualité ? Que se passe-t-il si un fournisseur tiers modifie brutalement ses prix ou ses conditions ?

La bonne métrique n'est d'ailleurs pas nécessairement le nombre de tokens. Un acheteur n'achète généralement pas des tokens : il achète un service.

Le suivi pertinent se déplacera probablement vers un coût technologique par outcome, par ticket résolu, changement livré, dossier traité ou transaction conforme, complété par des garde-fous sur la consommation.

Cette question est d'autant plus importante que Numeum constate simultanément la progression des gains de productivité et leur difficulté à se transformer en marge dans les ESN.

Redessiner la responsabilité autour d'une chaîne de fournisseurs

Un contrat IT avait déjà rarement un acteur unique. L'IA accentue ce phénomène.

Une ESN peut assembler un modèle d'un fournisseur, une plateforme cloud, une base vectorielle, un framework d'agents, des données client et ses propres actifs.

Qui répond alors d'un défaut ?

Il est recommandé de traiter explicitement cette architecture contractuelle : contrat séparé entre client, intégrateur et fournisseur de modèle, ou responsabilité globale portée par un prestataire ; prise en compte des conditions tierces ; répartition des responsabilités relatives aux données, aux tests et à l'exploitation.

Cette clarification devient encore plus importante depuis le 2 août 2026, date à laquelle la Commission européenne a commencé, avec les autorités nationales, à mettre en application de nouvelles dispositions de l'AI Act, dont certaines obligations de transparence.

Cela ne signifie pas que toute prestation IT utilisant un LLM relève des mêmes obligations : le rôle de chaque acteur, la nature du système et son niveau de risque restent déterminants. Le cadre contractuel doit justement permettre de savoir qui est quoi dans la chaîne de valeur.

La CNIL rappelle également que les modèles et systèmes utilisant des données personnelles peuvent relever du RGPD et insiste sur la sécurité et la documentation des traitements.

Le contrat IA n'est donc pas seulement un contrat de performance. C'est aussi un contrat de répartition du risque.

La propriété intellectuelle ne peut plus tenir dans une clause générique de trois lignes

Un projet augmenté peut contenir les actifs déjà détenus par l'ESN, le code spécifique produit pour le client, les données client, les prompts et configurations, les jeux d'évaluations, les données de contexte, les outputs générés, un modèle ou une plateforme appartenant à un tiers, et des améliorations génériques découvertes pendant la mission.

Il est recommandé de clarifier les droits applicables notamment aux données d'apprentissage, aux données d'entrée, aux résultats générés et au système personnalisé. Des composants tiers peuvent en outre imposer leurs propres restrictions de licence.

La recherche d'un principe simple « tout appartient au client » ou « toute la plateforme reste au prestataire » est donc souvent insuffisante.

Une architecture plus robuste consiste à distinguer au moins les actifs préexistants du prestataire, les éléments spécifiques développés pour le client et les données ou configurations propres au client.

L'enjeu commercial est majeur : si une ESN doit céder à chaque mission tous les actifs qu'elle industrialise, elle aura du mal à sortir du modèle fondé sur les jours. Mais si elle verrouille le client dans un actif impossible à reprendre, elle transforme son avantage en risque d'achat.

La réversibilité doit être conçue avant le démarrage, pas lors de la rupture

La réversibilité devient plus difficile lorsque le service dépend d'un ensemble de modèles, d'agents, de corpus, d'évaluations, de connecteurs et de règles d'orchestration.

À l'expiration du contrat, plusieurs questions doivent trouver réponse : le client peut-il continuer à utiliser le système, le confier à un tiers, récupérer ses données et obtenir l'effacement de certains éléments chez le prestataire ?

Pour une prestation IT augmentée, il faut aller plus loin et identifier ce qui est indispensable à une reprise effective : documentation d'architecture, données et formats d'export, configurations utiles, tests et évaluations, inventaire des dépendances, procédures d'exploitation, version des composants et conditions permettant à un autre prestataire de reprendre le service.

La réversibilité ne signifie pas nécessairement remettre au client tout le savoir-faire propriétaire du fournisseur. Elle signifie que changer de prestataire ne doit pas provoquer la perte du service ou de la connaissance spécifique du client.

C'est une différence essentielle.

Le contre-exemple à garder en tête : plus automatisé ne signifie pas automatiquement meilleur

Une erreur serait de transformer le taux d'automatisation en KPI contractuel principal.

Le cas Klarna est instructif précisément parce qu'il résiste à cette lecture. L'entreprise a très fortement automatisé son support et réduit ses effectifs avant de revenir vers un modèle plus hybride sur certains moments de service. On y observe à la fois des gains d'efficacité et le constat ultérieur du CEO selon lequel la recherche de réduction des coûts avait été poussée trop loin au détriment de la qualité.

Ce cas ne prouve pas qu'un fort taux d'automatisation dégrade nécessairement le service. Il prouve autre chose : le taux d'automatisation n'est pas, en lui-même, un résultat client.

Pour une prestation IT, la même prudence s'impose.

Un agent capable de résoudre 70 % des tickets peut constituer une excellente solution si la qualité reste élevée et les exceptions correctement traitées. Il peut également simplement déplacer la charge vers des incidents plus complexes, du rework ou une équipe de supervision saturée.

Le cahier des charges doit donc mesurer le système complet.

Ce que les données disponibles ne permettent pas d'affirmer

Nous ne disposons pas aujourd'hui d'une base solide permettant de décréter qu'une prestation utilisant l'IA devrait coûter 15 %, 20 % ou 30 % moins cher.

Nous ne pouvons pas non plus conclure que le client doit systématiquement connaître le pourcentage exact de travail généré par l'IA, que tout système agentique doit comporter la même validation humaine ou qu'un modèle outcome-based est toujours préférable à un forfait ou à la régie.

Les données disponibles décrivent une transition.

Numeum observe à la fois des gains de productivité, une forte pression tarifaire et une difficulté à convertir ces gains en marge. Un panel d'entreprises documente des organisations très agentiques, mais aussi des entreprises comme Lucca où l'IA s'intègre sans refonte fondamentale des équipes.

La conclusion raisonnable est donc moins spectaculaire : l'IA ne crée pas un nouveau contrat universel. Elle rend certains contrats historiques incomplets.

Acheter autrement implique aussi de vendre autrement

Le nouveau cahier des charges ne doit pas devenir une liste d'exigences imposées par les achats à une ESN défensive.

Le fournisseur a lui aussi intérêt à clarifier le jeu.

Plutôt que promettre une productivité abstraite, il peut proposer une baseline et une preuve. Plutôt que masquer ses agents pour protéger sa marge, il peut expliquer leur rôle et les contrôles qui les entourent. Plutôt que refacturer indistinctement des coûts technologiques, il peut rendre l'économie du service lisible. Plutôt que céder toute sa propriété intellectuelle pour gagner un appel d'offres, il peut distinguer clairement ce qui constitue son actif industriel de ce qui doit rester maîtrisé par le client.

Le contrat devient alors moins un instrument de défiance qu'un design du système de delivery.

C'est probablement le changement le plus important.

Checklist contractuelle : vingt questions avant de signer

Cette grille sert à cadrer acheteurs, commerciaux, delivery, DSI, RSSI et juristes. Elle ne remplace pas l'analyse juridique propre au contrat.

• •Avons-nous une baseline chiffrée du coût, des délais, de la qualité et du volume avant transformation ?
• •L'outcome attendu est-il formulé autrement qu'en nombre de jours ou d'ETP ?
• •Une preuve rapide est-elle prévue avant l'industrialisation ou l'engagement complet ?
• •Le périmètre dans lequel l'IA ou les agents interviennent est-il explicitement documenté ?
• •Les fournisseurs de modèles et composants tiers structurants sont-ils identifiés ?
• •Les règles applicables en cas de changement de modèle ou de fournisseur sont-elles prévues ?
• •Les données accessibles aux modèles, leur localisation, leur conservation et leur éventuelle réutilisation sont-elles définies ?
• •Les évaluations, cas limites et jeux de tests sont-ils définis avant la recette ?
• •Des seuils de performance et de tolérance sont-ils contractualisés ?
• •Existe-t-il un mécanisme de non-régression lorsque modèle, prompt ou architecture évoluent ?
• •Les décisions que l'agent peut prendre seul sont-elles distinguées de celles exigeant une validation humaine ?
• •Les actions critiques disposent-elles d'une approbation, d'une journalisation et d'un mécanisme d'arrêt ou de rollback adaptés ?
• •Les responsabilités respectives du client, de l'ESN et des fournisseurs tiers sont-elles explicites ?
• •Les coûts de modèles, calcul, licences et dépassements sont-ils intégrés dans une règle économique compréhensible ?
• •Le contrat prévoit-il ce qui se passe si un fournisseur tiers augmente fortement ses tarifs ou modifie ses conditions ?
• •Les actifs préexistants de l'ESN, les développements spécifiques, les données client, les entrées et les outputs sont-ils distingués en matière de propriété intellectuelle ?
• •Le client dispose-t-il des droits dont il aura réellement besoin pour exploiter la solution après la mission ?
• •La réversibilité couvre-t-elle données, documentation, dépendances, tests, évaluations et conditions de reprise par un tiers ?
• •Les indicateurs suivent-ils qualité, erreurs, exceptions et rework, et pas seulement volume automatisé ou vitesse ?
• •Acheteur et prestataire savent-ils comment seront partagés les gains de productivité si la prestation devient sensiblement plus efficace ?

La conviction

À l'ère de l'IA, l'acheteur ne doit pas chercher à savoir combien de jours humains il peut supprimer. Et l'ESN ne doit pas chercher à conserver artificiellement les mêmes jours en utilisant l'automatisation en coulisses.

Le contrat doit organiser un partage explicite de la productivité, du risque et de la responsabilité.

La prestation la plus mature n'est donc pas celle qui automatise le plus. C'est celle dans laquelle les deux parties peuvent répondre clairement à sept questions : d'où partons-nous ? Que doit-on prouver ? Comment le résultat sera-t-il évalué ? Que fait réellement l'IA ? Où l'humain garde-t-il l'autorité ? Qui paie et assume les dépendances technologiques ? Comment le client peut-il reprendre la main ?

Le cahier des charges devient, en quelque sorte, le premier acte de l'organisation hybride humains + agents.