Vous venez de livrer un automatisme IA, et votre client estime qu’un cas mal traité était compris. Dans cette situation hypothétique, vous devez décider s’il s’agit d’une correction, d’un dépannage ou d’une nouvelle demande. La série éditoriale « Le choc de l’IA sur le freelancing », datée du 10 octobre 2026, pose ce cadre pour les freelances en France et les consultants.
Une anomalie de conformité est un écart reproductible entre le comportement constaté de l’automatisme IA livré et le fonctionnement prévu dans les spécifications acceptées. Ce repère aide à séparer une erreur de livraison d’un changement de besoin, sans confondre les deux avec le support courant.
L’exposition de certaines tâches à l’IA ne prouve ni son usage observé dans chaque métier ni des pertes d’emplois démontrées. Ne généralisez pas les résultats d’une plateforme ou d’un fournisseur à tous les freelances. Aucun pourcentage de remplacement n’a de sens sans source primaire, date et périmètre précis. Les exemples de cet article restent hypothétiques, et aucune méthode ne promet des revenus.
Table of Contents
À retenir
- Écrivez les critères acceptés avant la livraison.
- Séparez correction, assistance et évolution du besoin.
- Définissez les délais de réponse dans le contrat.
- Gardez une trace des tests et versions livrés.
- Classez chaque demande avant le travail supplémentaire.
Le principe utile est simple : tout travail après livraison doit pouvoir être classé selon le périmètre accepté. La première frontière à poser distingue correction, maintenance et évolution.
Délimiter le support et les corrections après livraison d’un automatisme IA
Une correction relève du périmètre convenu si un écart reproductible empêche d’atteindre les critères acceptés, sous réserve du contrat et du droit applicable. Le critère décisif est l’écart aux spécifications, pas le fait qu’un client qualifie sa demande de bug. Les documents acceptés et les conditions du projet guident le classement.
La correction vise à rétablir le fonctionnement prévu, pas à ajouter une capacité absente des exigences acceptées. La garantie légale et une garantie contractuelle sont deux notions distinctes. Leur application dépend du contexte, des engagements écrits et du droit applicable. Ce repère général ne remplace pas un avis juridique adapté à votre situation.
Une correction rétablit la conformité aux spécifications acceptées. Une nouvelle fonction ou un entretien ne devient pas automatiquement une correction.
| Catégorie | Exemple hypothétique | Critère de classement | Traitement contractuel |
|---|---|---|---|
| anomalie de conformité | Une sortie ignore un critère accepté. | Écart reproductible aux critères convenus. | Correction selon les engagements prévus. |
| maintenance | Une tâche d’exploitation remet le système en état. | Intervention d’exploitation ou d’entretien. | Modalités et coût définis au contrat. |
| évolution | Le client demande un nouveau format. | Nouvelle fonction ou changement de besoin. | Nouveau périmètre, chiffrage à convenir. |
Ce tableau est une grille de négociation, pas une qualification juridique automatique. L’assistance à la prise en main répond aux questions d’usage. La maintenance couvre les interventions convenues, tandis qu’une évolution modifie le service attendu.
La correction rétablit le fonctionnement convenu
Par exemple, si un automatisme doit traiter un format défini dans les critères de recette, son rejet reproductible peut relever d’une anomalie de conformité. Le livrable, la version testée et les exigences acceptées permettent de vérifier le cas. Pour situer plus largement l’exposition des métiers, l’article de l’Organisation internationale du Travail sur l’IA générative et les professions examine cette question à l’échelle des occupations.
La maintenance et l’évolution répondent à d’autres besoins
Un changement de logiciel tiers ou l’ajout d’une étape métier peut demander un travail différent. Le contrat doit préciser les responsabilités, les exclusions et la façon de traiter ces interventions. Cette frontière doit être écrite avant livraison, avec les modalités du support courant clairement définies.
Que doit préciser le support après livraison ?
Un support « réactif » ne veut rien dire si les disponibilités et les étapes de réponse ne sont pas définies. Un cadre exploitable indique quand vous pouvez joindre le service, par quel canal et dans quelles conditions. Il précise aussi le volume inclus, le mode de facturation au-delà, les exclusions et les règles d’accès à distance.
Un engagement de service (SLA) doit décrire des objectifs négociés et mesurables, adaptés aux moyens réellement convenus. Fixez les jours et plages d’ouverture, plutôt que de laisser entendre une disponibilité permanente. L’accès distant doit suivre des règles de sécurité approuvées par les parties. Le support ne transforme pas toute correction en prestation gratuite.
Délimiter durée, volume, disponibilité et canaux
Une période d’hypercare est une assistance renforcée au démarrage, définie contractuellement et limitée à une période convenue. Elle peut aider les équipes à prendre en main le système dans son environnement réel. Écrivez son périmètre, ses interlocuteurs et son mode de facturation, au lieu de laisser la période ouverte.
- Horaires et jours couverts par le service.
- Canal de signalement accepté par les parties.
- Interlocuteur habilité à représenter le client.
- Conditions d’accès distant sécurisé au système.
- Mode de facturation au-delà du périmètre inclus.
Distinguer prise en compte et résolution
L’accusé de réception confirme qu’une demande a été reçue. Le diagnostic cherche ensuite la cause, et un contournement peut rétablir une partie du fonctionnement sans corriger la cause. La résolution désigne le retour au fonctionnement attendu, après vérification convenue.
Ces étapes ne se déroulent pas toujours dans le même temps. Un accès manquant, une erreur difficile à reproduire ou l’intervention d’un tiers peut ralentir le diagnostic. Indiquez séparément les objectifs de prise en compte et les engagements de résolution. La gravité opérationnelle doit guider la priorité, puis les niveaux de sévérité doivent être formulés clairement.
Comment classer un problème sans tout déclarer urgent ?
Une anomalie d’interface et un arrêt complet ne justifient pas le même ordre de traitement. L’impact constaté sur la production permet de distinguer un défaut gênant d’un blocage réel. Les engagements de service (SLA) doivent correspondre au contexte client, aux horaires couverts et aux moyens effectivement convenus.
| Niveau | Impact constaté | Exemple hypothétique | Engagement à définir |
|---|---|---|---|
| bloquant | Arrêt sans contournement disponible. | Le système ne traite aucune demande en production. | Objectif de prise en compte adapté et mesurable. |
| dégradé | Fonctionnement réduit, avec solution de secours. | Une équipe traite manuellement une partie des cas. | Objectif de prise en compte adapté et mesurable. |
| mineur | Défaut sans impact opérationnel important. | Un libellé d’écran reste incorrect. | Objectif de prise en compte adapté et mesurable. |
Un même défaut peut changer de niveau si un contournement devient disponible ou cesse de l’être. Une solution de secours peut préserver la continuité, mais ajouter du travail aux équipes. Décrivez donc ce qui fonctionne encore, ce qui est arrêté et les effets sur les personnes concernées.
Ne choisissez pas un niveau selon l’insistance du demandeur ou le ton du message. Les critères doivent porter sur la qualité du service, les conséquences visibles et les tests qui confirment l’impact. Les délais associés restent à négocier, sans promettre une résolution que le diagnostic ne permet pas encore d’estimer.
Invitez les deux parties à décrire des faits observables avant de classer le problème. Une qualification cohérente commence par un signalement reproductible, ou par une trace claire de ce qui empêche sa reproduction.
Quel processus suivre pour faire corriger une anomalie ?
Dans un cas hypothétique, une sortie erronée apparaît seulement avec une combinaison précise d’entrée et de version. Un signalement utile conserve ce contexte, au lieu de résumer le problème par « le système ne marche pas ». Le processus doit aboutir à un diagnostic convenu, puis à un test du correctif sur le cas d’origine.
Constituer un signalement exploitable
Le client et le freelance peuvent suivre la même séquence, sans supposer que chaque erreur sera reproductible :
- Consigner la date, le contexte d’usage et la version du système.
- Conserver les entrées et résultats utiles pour comprendre le cas.
- Documenter le comportement attendu et le comportement observé.
- Convenir du diagnostic à mener et de la personne responsable.
- Tester le correctif sur le cas signalé et les cas pertinents de non-régression.
Les journaux peuvent contenir des données personnelles ou sensibles. Limitez leur collecte aux éléments utiles, masquez ce qui n’est pas nécessaire et contrôlez les accès. Évitez de transmettre des données réelles par un canal qui n’a pas été convenu pour cela.
Valider le correctif sur le cas d’origine
La vérification porte sur le résultat attendu dans la même configuration. Elle doit aussi inclure des tests de non-régression pertinents, car un changement peut perturber une fonction déjà opérationnelle. Consignez la version testée, le résultat et les éventuelles limites connues.
Si l’erreur ne se reproduit pas, notez les entrées, la version, le moment et les conditions observées. Convenez d’une étape de diagnostic, comme comparer les journaux ou revoir la séquence d’actions. L’absence de reproduction ne prouve ni que le signalement est faux ni qu’un correctif immédiat est possible. Le processus ne rend pas automatiquement toute demande gratuite : le classement distingue une correction, la maintenance et une nouvelle prestation.
Quand une demande devient-elle maintenance ou évolution facturable ?
Un comportement contraire aux spécifications acceptées peut relever d’une correction ; une demande née d’un besoin modifié peut devenir une évolution. La cause du changement compte autant que la demande formulée. Le contrat et les documents de recette permettent de comparer le besoin actuel au périmètre livré.
Reconnaître une intervention de maintenance
L’entretien convenu peut couvrir des tâches définies d’exploitation ou de mise à jour. Le rétablissement après une cause exclue du contrat peut suivre d’autres conditions. Par exemple, dans un scénario hypothétique, un changement externe perturbe un système sans écart du livrable initial. Le diagnostic peut alors éclairer le classement sans présumer d’une faute.
Repérer un changement de périmètre
Une nouvelle source de données, une modification d’API ou un changement de logiciel tiers peut demander une adaptation. L’ajout d’une capacité métier est aussi une évolution si elle ne figurait pas dans les critères acceptés. Ces exemples hypothétiques n’établissent aucune règle tarifaire universelle.
Un changement de modèle, d’API, de données ou d’objectif peut nécessiter une analyse, des tests et un devis. La nécessité de ce travail ne démontre pas, à elle seule, une faute du freelance. Le prix ou la méthode de chiffrage doit être prévu dans les conditions convenues, sans supposer un tarif applicable à tous.
Consignez la cause identifiée et la décision de classement, même si les parties choisissent ensuite un autre mode de prise en charge. Pour un éclairage distinct sur les PME et les effets de l’IA générative sur leur main-d’œuvre, consultez l’étude de l’OCDE sur l’IA générative et les effectifs des PME. La maintenabilité dépend aussi des fichiers et historiques transmis, ainsi que des clauses et livrables prévus.
Quelles clauses et quels livrables sécurisent la reprise du système ?
Un système sans documentation ni version identifiée peut devenir difficile à diagnostiquer ou à transmettre à une autre équipe. Une reprise préparée donne au client les éléments utiles pour l’exploitation et la continuité du service. Annexez les documents de référence et identifiez précisément la version livrée.
- Spécifications et critères de recette acceptés par les parties.
- Documentation d’exploitation et de diagnostic du système.
- Version livrée des logiciels et configurations associées.
- Résultats des tests réalisés et limites connues.
- Consignes d’accès sécurisé et modalités de transfert.
Clarifiez aussi les droits d’utilisation et de modification, la sauvegarde, la gestion des versions et les dépendances logicielles. Prévoyez la formation utile aux équipes, ainsi que les pratiques de cybersécurité applicables au projet. Ces choix rendent le transfert plus lisible quand une autre personne doit intervenir.
Pour les données personnelles, la CNIL recommande d’évaluer les risques et de sécuriser les données fournies lors de l’usage d’une IA générative. Ses questions-réponses sur l’IA générative abordent aussi les rôles et, selon le cas, l’association du DPO ou une AIPD. Pour l’accès distant et la sécurité, appuyez-vous sur les ressources de l’ANSSI. Consultez les textes officiels à jour pour toute règle européenne applicable, sans confondre droit en vigueur, projet de texte et scénario possible.
Ces éléments peuvent être rattachés à un document court de pilotage. Il transforme les points de reprise en rubriques concrètes à remettre au client.
Quel livrable remettre au client à la fin du cadrage ?
Remettez une fiche de périmètre directement exploitable, plutôt qu’une clause vague promettant une assistance générale. Chaque rubrique doit laisser les parties préciser leurs engagements pour le projet. La fiche sert de repère partagé, sans remplacer un contrat adapté.
Une fiche utile nomme le livrable, les critères, les limites du service et les modalités de reprise.
Inscrivez des champs nommés : livrable et version de référence, critères d’acceptation, définition d’une anomalie, inclusions et exclusions. Ajoutez durée et volume du support, canal et modalités de signalement, niveaux de sévérité et étapes de validation du correctif. Précisez le tarif ou la méthode de devis hors périmètre, puis la documentation et les accès remis.
Avant de signer ou de livrer, vérifiez que les deux parties savent qui décide du classement et comment l’accord sera conservé. Adaptez cette fiche à votre prochain projet, sans la traiter comme un contrat prêt à l’emploi.
Conclusion
Chaque demande doit pouvoir être classée avant que le travail supplémentaire commence. Le périmètre, les délais de réponse et les évolutions gagnent à être convenus par écrit, pour que le client comme vous sachiez ce qui est attendu.
Préparez votre fiche de périmètre pour votre prochaine livraison et discutez-en avec le client avant le démarrage. Si votre situation professionnelle rend le portage salarial pertinent, utilisez le simulateur de portage salarial pour obtenir une estimation indicative. Son résultat n’est pas une promesse de revenu.
FAQ
Quelle est la différence entre un délai de réponse et un délai de résolution ?
Le délai de réponse concerne la prise en compte de la demande, tandis que le délai de résolution concerne le retour au fonctionnement attendu. La résolution dépend du diagnostic, de la possibilité de reproduire le problème, des accès disponibles et d’éventuels tiers. Le contrat peut fixer des objectifs distincts pour ces deux étapes, sans les confondre.
Qui paie si une API ou un logiciel tiers change après la livraison ?
La réponse dépend des dépendances et des exclusions prévues au contrat. Il faut distinguer un écart imputable au livrable d’une évolution extérieure qui modifie l’environnement. Par exemple, une nouvelle version d’API peut demander une adaptation qui n’était pas incluse. Les parties peuvent convenir d’un diagnostic puis d’un devis avant toute modification.
Que faire si le problème ne peut pas être reproduit ?
Conservez le contexte, la version, les entrées utiles et les journaux minimisés, puis convenez d’une étape de diagnostic. Notez aussi le moment et les conditions observées, sans transmettre inutilement des données personnelles. Une comparaison des versions ou des séquences d’actions peut aider à comprendre l’erreur. Ne promettez pas un correctif avant d’avoir établi une piste de travail.
Le freelance peut-il facturer le temps passé à diagnostiquer un bug ?
Oui, si les conditions convenues prévoient cette facturation, notamment lorsque la demande se révèle hors périmètre. Le contrat peut distinguer le diagnostic d’une anomalie de conformité et l’analyse d’une évolution. Il n’existe pas de règle tarifaire universelle à appliquer à chaque projet. Précisez la méthode de facturation avant le début des travaux concernés.
Faut-il proposer une assistance en dehors des horaires ouvrés ?
Une assistance hors horaires ouvrés se justifie si la continuité d’exploitation du client le demande et si les parties en conviennent. Définissez la disponibilité réelle, le canal de contact, le périmètre couvert et le coût. Sans engagement précis, le client ne peut pas déduire une permanence d’une formule générale comme « support réactif ».
Le client peut-il modifier lui-même le code de l’automatisme IA ?
Le client peut le faire si les droits de modification et les conditions d’accès le permettent. Vérifiez aussi comment les versions seront suivies et comment les changements seront testés. Une modification directe peut compliquer le diagnostic ou influer sur les engagements du prestataire. Convenez de la procédure de transfert et de validation avant toute intervention.
