Un paiement récurrent ne dit pas, à lui seul, ce que le client achète. Freelance, vous devez préciser si l’acheteur finance une disponibilité, un résultat remis ou les deux. Dans la série « Le choc de l’IA sur le freelancing », publiée au 10 octobre 2026, cette distinction aide à cadrer votre besoin sans garantir un résultat technique incertain. Un critère de recette est une condition observable, définie à l’avance, qui permet d’accepter ou de refuser un livrable. Selon le cas et l’usage prévu, la prestation gagne à nommer séparément le travail disponible et ce qui doit être remis. Le flou apparaît surtout lorsque l’IA intervient dans une mission de freelance.
Table of Contents
À retenir
- Un paiement récurrent peut couvrir une capacité, un livrable ou leur combinaison.
- La capacité réservée décrit un volume de ressources promis, pas forcément un résultat précis.
- Le livrable contractuel désigne ce qui doit être remis ou rendu accessible.
- Une recette repose sur des conditions observables définies avant la livraison.
- La présence d’IA ne fixe pas, à elle seule, les engagements des parties.
Pourquoi l’IA rend-elle le périmètre d’une mission récurrente plus flou ?
Deux missions utilisant le même outil peuvent avoir des périmètres et des risques différents. L’intelligence artificielle peut aider le prestataire, être intégrée au système du client ou influencer des décisions. Son rôle, et non sa seule présence, aide à préciser l’objet de la prestation et les responsabilités.
Le rôle de l’IA, et non sa seule présence, aide à préciser l’objet de la prestation et les responsabilités.
Dans un premier cas hypothétique, vous utilisez un outil pour produire des contenus, des images, des synthèses ou du code. Le client achète alors une prestation qui peut inclure des éléments assistés par IA. Les risques concernent notamment la qualité, la confidentialité et la traçabilité du travail remis.
Dans un autre cas hypothétique, le livrable contractuel comprend une IA intégrée au système d’information du client. Les accès, les erreurs et le fonctionnement de cette solution entrent alors dans le périmètre à décrire. Une IA copilote peut aussi planifier, répartir ou prioriser des tâches sans produire le livrable lui-même. Son influence sur les décisions mérite d’être reconnue.
Trois repères ne doivent pas être confondus :
- L’exposition des tâches indique qu’une activité pourrait être aidée ou transformée par l’IA.
- L’usage observé décrit le recours effectif à un outil dans une situation donnée.
- Les pertes d’emplois désignent un changement d’emploi, qui demande des données propres à son contexte.
L’exposition d’une tâche ne prouve pas son automatisation réelle, et l’usage observé ne prouve pas une perte d’emploi. Pour des constats chiffrés, consultez des travaux de l’OIT, de l’OCDE ou de l’INSEE, en tenant compte de leur date et de leur périmètre. L’analyse de l’OIT sur l’IA générative et les professions éclaire notamment les effets possibles selon les métiers. Une étude de plateforme ou de fournisseur ne décrit pas automatiquement tous les freelances. Le rôle attribué à l’IA conduit donc à préciser le choix contractuel lui-même.
IA et contrat récurrent : distinguer capacité réservée et livrables effectivement produits
Dans une mission d’exploration, vous pouvez réserver du temps sans pouvoir promettre à l’avance la performance d’un modèle. La capacité réservée correspond au volume de ressources promis, tandis que le livrable contractuel est ce qui doit être remis ou rendu accessible. Ces termes décrivent l’objet acheté, mais ne déterminent pas seuls la portée juridique de l’engagement.
Un besoin encore incertain peut évoluer pendant le travail. Il faut alors rendre lisibles le temps consacré, les résultats attendus et les conditions de réception. La rédaction acceptée par les parties compte davantage que l’étiquette donnée au modèle.
Ce que paie une capacité réservée
Une capacité peut couvrir du temps d’expertise, un créneau de support ou une ressource technique disponible. Elle permet d’organiser le travail autour d’un volume convenu, sans promettre automatiquement un livrable défini. L’acheteur peut notamment payer un accès à votre disponibilité pour examiner un problème ou orienter la suite.
Dans un exemple explicitement hypothétique, vous explorez plusieurs pistes pour automatiser une tâche interne. Le contrat cadre le temps de travail et les échanges, mais le résultat de l’IA reste incertain. Vous pouvez prévoir une note de suivi ou un état des essais sans transformer chaque piste en résultat garanti.
Ce qui constitue un livrable contractuel
Un livrable peut être du code documenté, un rapport, une API ou une interface. Ces exemples désignent des éléments remis ou rendus accessibles, sans garantir à eux seuls leur qualité ou leur adéquation. Pour éviter un désaccord, rattachez chaque élément à un besoin et à une preuve vérifiable.
La capacité réservée et le livrable peuvent coexister. Le tableau distingue leurs usages possibles, sans leur attribuer une obligation juridique automatique. La recette, notamment, doit être définie au contrat pour que les parties sachent comment accepter ou refuser le résultat.
| Critère | Capacité réservée | Livrable contractuel |
|---|---|---|
| Objet acheté | Temps d’expertise disponible | Rapport remis en format convenu |
| Preuve d’exécution | Compte rendu des interventions | Fichier ou accès remis à l’acheteur |
| Réorientation des priorités | Possible selon les règles convenues | Possible après accord sur le périmètre |
| Réception ou recette | Suivi de la capacité consommée | Critères de recette définis au contrat |
| Risque de désaccord | Disponibilité attendue mal délimitée | Résultat ou test d’acceptation imprécis |
Une formule hybride peut associer un créneau de support à la remise périodique d’un rapport ou d’une version de code. L’obligation juridique dépend des stipulations réelles et des engagements effectivement acceptés, pas d’une règle générale attachée à l’étiquette. La distinction devient utile lorsqu’elle se traduit en engagements vérifiables dans les clauses.
Pour un angle distinct, vous pouvez aussi consulter l’Anthropic Economic Index, consacré à l’analyse économique de l’IA.
Quelles clauses rendent la prestation vérifiable et sécurisée ?
Les clauses utiles transforment une intention générale en obligation contrôlable. Elles précisent les informations utilisées, les éléments remis et les vérifications attendues. Aucune clause unique ne garantit, à elle seule, la conformité de toute la prestation.
Faites correspondre chaque obligation au périmètre réel de la mission. Un outil de génération utilisé pour un brouillon ne soulève pas nécessairement les mêmes questions qu’un système intégré au service du client. Pour le droit applicable, distinguez les règles en vigueur des projets de texte et des scénarios envisagés.
Périmètre, données et propriété intellectuelle
Décrivez les données que vous pouvez transmettre à un outil, leur stockage et les personnes autorisées à y accéder. Précisez les conditions d’usage des outils et des fournisseurs, notamment les comptes et espaces de travail autorisés. Les informations sensibles ne doivent pas être confondues avec des données destinées à un service public.
La propriété intellectuelle mérite une répartition claire. Écrivez ce qui s’applique aux éléments créés par vous, aux contenus générés par l’IA et aux éléments combinés. Les usages autorisés des livrables et les restrictions utiles doivent être compréhensibles pour l’acheteur comme pour le prestataire.
La CNIL présente des points de vigilance sur les systèmes génératifs, notamment l’encadrement des usages, la sécurité des données et la vérification des résultats. Consultez ses questions-réponses sur l’utilisation d’un système d’IA générative pour situer ces sujets. Les conditions des fournisseurs et les obligations applicables doivent aussi être examinées selon la mission.
Traçabilité, recette et responsabilité
Convenez des usages pertinents de l’IA à déclarer et du niveau de détail attendu. Une déclaration peut porter sur une étape précise sans révéler les méthodes confidentielles du prestataire. Définissez aussi la recette, la méthode de test et les éléments qui permettront de contrôler le livrable.
Précisez la marche à suivre en cas d’erreur ou d’incident, ainsi que la responsabilité de chaque partie dans le contrôle. Un audit ou une vérification de conformité peut être prévu au contrat. Pour les règles applicables, consultez les sources primaires pertinentes, dont la CNIL, l’ANSSI et la Commission européenne, à la date de rédaction.
Le droit en vigueur, un projet de texte et un scénario futur ne sont pas interchangeables. Faites examiner le cadre pertinent pour votre situation, sans supposer qu’une mention générale suffit. Négociez ces éléments selon la phase du projet et l’incertitude réelle de la mission.
Comment organiser le contrat entre exploration, production et suivi ?
Une mission peut commencer par une phase exploratoire, puis devenir plus prévisible une fois les livrables définis. Vous pouvez faire évoluer le contrat en distinguant les périodes, la capacité réservée et les éléments remis. Les priorités, les heures non consommées et la recette doivent être traitées expressément.
Ne laissez pas une formule mensuelle masquer ce qui se passe si les demandes changent. Un échange écrit peut confirmer une réorientation ou modifier le périmètre. Les modalités doivent rester adaptées au besoin réel, plutôt qu’à une formule standard.
Cadrer la phase et la capacité disponible
Définissez les activités couvertes, la capacité disponible et la façon de prioriser les demandes. Indiquez ce qui se passe quand une tâche urgente entre en concurrence avec un travail déjà prévu. Décrivez aussi le traitement des heures non consommées : leur report ou leur expiration doit être expressément convenu.
Dans un exemple hypothétique, une équipe demande d’abord une étude de faisabilité, puis souhaite intégrer une solution au site web. Le contrat peut distinguer l’exploration et la mise en production, plutôt que de traiter chaque demande comme incluse d’office. En cas de changement, consignez l’accord et ses effets sur le travail attendu.
Organiser la recette et le suivi récurrent
Pour chaque livrable, nommez les critères de recette, la méthode de test et les retours attendus. Fixez une fréquence de revue qui convient aux parties, sans supposer qu’un rythme universel existe. Une revue périodique des priorités aide à repérer les demandes devenues secondaires.
Le tableau propose des cas entièrement hypothétiques. Ses exemples montrent comment relier une phase à une capacité, à un livrable possible et à une preuve de suivi. Ils ne fixent ni tarif, ni délai, ni seuil de performance applicable à tous les projets.
| Phase | Capacité réservée | Livrable possible | Preuve de suivi |
|---|---|---|---|
| Exploration, exemple hypothétique | Temps d’analyse des besoins et des pistes | Note présentant les options examinées | Compte rendu des essais et décisions |
| Production, exemple hypothétique | Disponibilité pour développer et corriger | Version de code remise avec documentation | Résultats des tests convenus |
| Maintenance, exemple hypothétique | Créneau de support pour les demandes acceptées | Correctif documenté ou mise à jour convenue | Journal des demandes et interventions |
Si les conditions de recette changent, décrivez la nouvelle méthode avant d’accepter le résultat. Un écrit de validation permet aussi de confirmer un changement de périmètre, au lieu de s’appuyer sur un accord oral ambigu. Une organisation claire ne supprime ni les limites techniques ni les risques de mauvais usage, qui doivent rester visibles.
Quelles limites et quels risques garder en tête ?
Un texte fluide produit par un outil n’est pas, à lui seul, une preuve de qualité ou de conformité. Les limites varient selon l’outil, la tâche et les données utilisées. Vérifiez les performances dans les conditions réelles de la mission, puis faites relire le résultat par une personne compétente.
Un texte fluide n’établit pas la qualité du livrable : vérifiez-le sur la tâche réelle et faites-le relire.
Une synthèse de contrat doit faire ressortir les informations utiles au pilotage, pas seulement les noms des clauses. Le classement automatique peut parfois regrouper des contrats selon des thèmes sémantiquement peu cohérents. Un outil de rédaction peut aussi proposer des clauses génériques sans expliquer leur choix ni assurer la cohérence de l’ensemble.
Avant de valider un livrable, vérifiez quatre points :
- La cohérence du contenu avec le besoin convenu.
- L’exactitude des éléments sensibles, comme une donnée ou une affirmation technique.
- Les droits et les sources des contenus repris ou générés.
- Le respect des règles convenues sur les données utilisées.
La responsabilité ne disparaît pas parce qu’une IA a participé au travail. Les travaux de recherche originaux et les organismes publics peuvent éclairer l’analyse, sans rendre équivalents l’exposition des tâches, l’usage observé et l’emploi. Pour un éclairage sur les PME et la main-d’œuvre, lisez l’étude de l’OCDE sur l’IA générative et la main-d’œuvre des PME. Pour votre prochain contrat récurrent, commencez par vérifier ce qui est promis et ce qui sera remis.
Conclusion
Avant de signer ou de renouveler, séparez par écrit la disponibilité promise des éléments à remettre. Notez la capacité réservée, chaque livrable contractuel et ses critères de recette. Cette lecture aide l’acheteur et le freelance à repérer une attente restée implicite.
Si le portage salarial correspond à votre situation, le simulateur de portage salarial peut fournir une estimation indicative. Il ne règle pas la négociation de votre prestation et ne garantit aucun revenu. Vérifiez d’abord le périmètre du contrat, puis effectuez une estimation indicative si vous envisagez cette option.
FAQ
Les heures non utilisées d’un contrat récurrent sont-elles reportables ?
Oui, si les parties l’ont expressément prévu au contrat. Celui-ci doit préciser la durée du report et le sort des heures après cette période. Il peut aussi prévoir leur expiration ou leur non-report. Sans règle claire, demandez une confirmation écrite avant de compter sur ces heures pour une période ultérieure.
Peut-on payer une prestation récurrente sans recevoir un livrable chaque mois ?
Oui, si la prestation rémunère clairement une capacité ou une disponibilité et si son périmètre est défini. Le contrat peut prévoir des éléments de suivi, comme un relevé des interventions ou un compte rendu, sans imposer un livrable mensuel. Décrivez ce que l’acheteur peut demander et comment les priorités seront fixées.
Comment fixer un critère de recette pour un livrable d’IA ?
Définissez avant le travail une méthode de test, un jeu de données pertinent et les seuils acceptés par les parties. Le test doit correspondre au besoin réel, plutôt qu’à une performance théorique isolée. Aucun seuil universel ne convient à tous les outils ou livrables. Précisez aussi qui exécute le test et comment les écarts seront traités.
Qui répond d’une erreur produite par un outil d’IA ?
L’usage de l’outil ne détermine pas à lui seul qui répond de l’erreur. Examinez le contrat, le rôle de chaque partie, les contrôles humains réalisés et les faits précis. Une sortie erronée peut être repérée avant remise, mais le niveau de contrôle dépend de la prestation convenue. En cas de doute, demandez un avis adapté à votre situation.
Puis-je transmettre des données client à un outil d’IA public ?
Pas sans vérifier au préalable la nature des données, les réglages et les conditions du fournisseur, ainsi que les autorisations nécessaires. Certaines informations peuvent être confidentielles ou personnelles. Vérifiez aussi les engagements pris envers le client et les règles applicables. Si le cadre reste incertain, suspendez la transmission et convenez d’une solution autorisée.
Dois-je déclarer au client chaque usage d’IA dans ma prestation ?
Pas nécessairement chaque usage : le contrat peut préciser les usages à déclarer et le niveau de détail attendu. Les parties peuvent cibler les étapes qui influent sur le livrable ou les décisions du client. La déclaration doit aussi préserver les informations confidentielles et les méthodes du prestataire, selon les engagements convenus.
Faut-il imposer une obligation de résultat pour tout livrable d’IA ?
Non, l’étiquette « livrable d’IA » ne crée pas automatiquement une obligation de résultat. Alignez l’engagement sur un résultat défini, vérifiable et réellement maîtrisable par la partie concernée. Si la performance dépend d’un modèle ou de données changeantes, décrivez les limites et les tests convenus. La rédaction effective du contrat reste déterminante.
