Quand l'inférence tombe en prod, jusqu'où le consultant MLOps est-il responsable ?

Le service de scoring temps réel du client est resté indisponible trois heures un jour de forte affluence commerciale. Pas de prédictions, donc pas de recommandations, donc des ventes perdues et des clients finaux mécontents. La direction veut un responsable, et le regard se tourne vers le consultant qui a conçu la plateforme d'inférence.

Mais une panne d'inférence sur Kubernetes peut avoir des dizaines de causes, et toutes n'engagent pas votre responsabilité de la même façon :

• Un KServe configuré pour scaler à zéro qui n'arrive pas à remonter assez vite face à un afflux (cold start GPU de plusieurs minutes).
• Un pod OOMKilled parce que la limite mémoire était trop basse pour la taille réelle du modèle.
• Un node GPU évincé par le cloud provider (spot instance) au pire moment.
• Une image de modèle indisponible dans le registry, ou un PVC qui ne se monte plus.
• Un changement de quota ou de configuration fait par l'équipe du client après votre départ.

Chacune de ces causes raconte une histoire juridique différente. Le réflexe « le consultant a conçu la plateforme, donc il est responsable » est faux. La question n'est pas qui a conçu, mais qui a commis la faute et jusqu'où allait sa mission.

Le droit français des contrats repose sur une distinction fondamentale pour les prestataires intellectuels.

L'obligation de moyens, la règle pour le conseil

Par défaut, un consultant est tenu à une obligation de moyens : il doit mettre en œuvre tout son savoir-faire de professionnel diligent, mais il ne garantit pas un résultat. Si le service tombe malgré une conception sérieuse et conforme à l'état de l'art, il n'y a pas forcément faute. Le client doit prouver que vous avez mal fait quelque chose, pas seulement que ça n'a pas marché.

L'obligation de résultat, le piège du contrat

Mais attention : certains contrats vous font basculer, parfois sans que vous le réalisiez, vers une obligation de résultat. Une clause qui vous engage sur un SLA de disponibilité de 99,9 %, ou qui vous rend garant du bon fonctionnement en production, transforme la nature de votre responsabilité. Là, dès que le service tombe sous le seuil, la faute est présumée et c'est à vous de prouver la cause étrangère.

La leçon : ne signez jamais un engagement de disponibilité chiffré sans en mesurer la portée juridique. Un « 99,9 % » glissé dans un contrat de conseil peut vous exposer bien au-delà de ce que vous maîtrisez réellement.

Lisez vos contrats à la loupe sur ce point. C'est souvent là, et non dans la technique, que se joue l'essentiel de votre exposition.

Même quand une faute existe, encore faut-il qu'elle soit la cause de la panne. C'est le deuxième filtre juridique, et il joue souvent en votre faveur.

Reprenons nos scénarios :

Cette grille montre l'essentiel : la conception fautive engage, l'arbitrage assumé par le client et le fait postérieur n'engagent pas. Un consultant qui documente ses choix, signale les risques d'une architecture économique et délimite la fin de sa mission se construit une défense solide. À l'inverse, l'absence de trace écrite laisse toute la place à l'interprétation — généralement à votre désavantage.

Le troisième levier, c'est le périmètre. Une plateforme d'inférence a deux vies : sa conception (que vous livrez) et son exploitation (qui dure des mois ou des années après). Confondre les deux est la première source de litige injuste.

Si votre mission s'arrête à la mise en production et au transfert de compétences, vous n'êtes pas responsable de ce que devient la plateforme ensuite : montées de version non maîtrisées, modifications de quota, absence de monitoring que le client devait assurer. Le préjudice d'une panne survenue six mois après, sur une config que vous ne maîtrisez plus, ne vous est en principe pas imputable.

D'où l'importance de poser noir sur blanc, dès le contrat :

• Ce que couvre votre mission : conception, mise en production, run, astreinte ? Chaque mot compte.
• La date de fin de responsabilité et le périmètre du transfert au client.
• Les prérequis d'exploitation que le client s'engage à respecter (monitoring, mises à jour, quotas).

Un consultant qui livre aussi des runbooks, des alertes et un plan de reprise démontre qu'il a outillé le client pour exploiter sereinement. C'est à la fois une bonne pratique technique et un bouclier juridique.

L'indisponibilité d'un service IA génère un préjudice commercial : ventes perdues, pénalités contractuelles du client envers ses propres clients, atteinte à l'image. C'est un dommage immatériel, terrain naturel de l'assurance RC Pro du consultant.

Concrètement, si une faute de conception de votre part est caractérisée et qu'elle est la cause de la panne, votre RC Pro :

• Indemnise le préjudice commercial subi par le client, dans la limite des plafonds, après déduction de sa propre part de responsabilité.
• Finance votre défense et l'expertise technique nécessaire pour établir la vraie cause de la panne — souvent l'étape décisive, car démontrer que la cause vous est étrangère vaut acquittement.
• Couvre la protection juridique pour négocier à l'amiable et éviter une procédure longue.

Ce que la RC Pro ne fait pas : transformer un aléa d'exploitation en faute. Si la panne vient d'un arbitrage assumé par le client, d'une cause postérieure ou d'un fait de tiers, il n'y a pas de faute à indemniser. Mais c'est précisément dans ces cas que la prise en charge des frais de défense vous évite de payer pour vous justifier. Pour un métier où une panne se chiffre vite en dizaines de milliers d'euros de manque à gagner, une RC Pro adaptée aux missions MLOps n'est pas une formalité : c'est ce qui sépare un incident géré d'une catastrophe financière. Découvrez les garanties adaptées à votre profil sur notre page consultant MLOps Kubernetes.

Pour les missions les plus exposées, pensez aussi à articuler votre RC Pro avec une couverture des outils que vous mobilisez : poste de travail, accès aux clusters, postes d'astreinte. Si votre matériel informatique tombe en panne au pire moment d'une intervention critique, votre capacité à rétablir le service rapidement protège autant votre client que votre responsabilité. L'enjeu n'est pas seulement d'indemniser après coup : c'est de rester opérationnel quand tout dépend de votre réactivité.