Contractualiser une mission IA : les clauses qui comptent

Le jour où le projet a basculé : l’histoire d’un livrable absent

En réunion, le 12 mars 2024, le responsable commercial d’un éditeur affirmait : « Notre solution IA générera automatiquement 30 % de leads qualifiés en six mois. » Trois semaines plus tard, lors de la revue mensuelle, le directeur marketing constatait que le modèle, livré sans jeu de données de test, classait 70 % des contacts existants comme non pertinents. Le code fonctionnait, mais personne n’avait vérifié son utilité réelle. L’éditeur invoquait une « période d’apprentissage nécessaire ». Le client exigeait un remboursement partiel. Le litige a duré huit mois.

Clause 1 : Définir les données d’entrée et de sortie

Un projet d’IA repose d’abord sur des données, pas sur un algorithme. Sans jeu de données de référence, vous ne pouvez ni mesurer le résultat ni exiger une amélioration.

• Données d’entrée : Listez les fichiers (Excel, CRM, transcription de calls), leurs formats, et leur qualité minimale. Exemple : « Le fichier clients doit contenir au moins 5 000 lignes avec un taux de complétude de 90 % sur les champs : nom, email, secteur d’activité, date de dernier contact. »
• Données de sortie : Précisez leur format et leur usage. Exemple : « Le fichier de leads qualifiés doit inclure pour chaque contact : nom, email, score de pertinence (0-100), et justification du score (extrait du texte analysé). »
• Jeu de test : Exigez un échantillon de 1 000 lignes représentatif de votre base, fourni avant le début du projet. Ce jeu servira de référence pour évaluer les livrables finaux.

Cas où cela ne marche pas : Un cabinet a livré un modèle de scoring sans fournir le jeu de test. Le client a découvert après coup que le modèle favorisait les grandes entreprises, car le jeu de données était majoritairement composé de contacts issus de salons professionnels. Le prestataire a refusé de corriger, arguant que le « biais était inhérent aux données ». Le contrat n’avait pas prévu de clause de rééquilibrage.

Clause 2 : Préciser les critères de performance avant le développement

La performance d’un modèle d’IA ne se mesure pas en « précision » ou en « recall », mais en adéquation avec votre processus métier. Définissez des indicateurs concrets, liés à une action que vous allez mener ensuite.

Exemple de clause : « Le modèle de détection de fraude sera considéré comme conforme si, lors des trois premiers mois d’utilisation en conditions réelles par l’équipe anti-fraude, le taux de faux positifs ne dépasse pas 5 % des alertes générées. »

À éviter : Les promesses de type « Le modèle aura une précision de 95 % ». Ce chiffre, calculé sur un jeu de données non représentatif de votre activité, ne garantit en rien son utilité.

Clause 3 : Prévoir un test pilote payant, avec sortie immédiate en cas d’échec

Ne signez jamais un contrat où le paiement intégral est dû avant validation en conditions réelles. Un test pilote doit être : limité dans le temps (1 à 2 mois), avec un volume de données réaliste, et assorti d’une clause de sortie sans pénalité.

• Durée : Un mois suffit pour évaluer la pertinence du modèle sur un échantillon de 10 000 lignes.
• Coût : Le prix du pilote doit représenter 20 à 30 % du budget total. Il est dû uniquement si le test est validé par votre équipe métier, pas par le prestataire.
• Sortie : Clause de « sortie propre » : « En cas d’échec du test pilote (moins de 70 % des indicateurs atteints), le client peut résilier le contrat sans frais et récupérer l’intégralité des données fournies. »

Cas où cela ne marche pas : Une PME a payé 80 % du projet avant le test pilote, sur la base d’un « prototype » non représentatif. Le modèle final, déployé en production, classait 90 % des clients comme inactifs, alors que l’éditeur avait utilisé un jeu de données obsolètes. Le client a dû renégocier en urgence, perdant trois mois et 40 000 €.

Clause 4 : Garantir la réversibilité des données et du code

Vous ne devez jamais être captif d’un prestataire, surtout si le projet ne répond pas à vos attentes. Exigez la livraison des codes sources, des modèles entrainés, et des jeux de données utilisés, dans un format standard (CSV, JSON, Python).

• Code : Le prestataire doit fournir un dépôt Git privé, accessible pendant deux ans après la fin du projet, avec les instructions de déploiement sur un cloud de votre choix (AWS, Azure, ou on-premise).
• Modèles : Les fichiers de poids (.pkl, .onnx) doivent être fournis, ainsi qu’un script de réentrainement avec les données de référence.
• Données : Vous devez récupérer l’intégralité des données utilisées pour l’entraînement et le test, même après la fin du projet.

Exemple de clause : « À l’issue du projet, le prestataire livrera : 1) un dépôt Git contenant le code source et les fichiers de configuration, 2) les jeux de données d’entrée et de sortie au format CSV, 3) les modèles entrainés au format .onnx. Ces éléments seront fournis sous licence MIT, permettant une réutilisation libre. »

À éviter : Les contrats qui limitent l’accès au code à une « utilisation en SaaS » ou qui imposent un hébergement exclusif sur les serveurs du prestataire.

Clause 5 : Prévoir une revue annuelle des performances et une clause de révision

L’IA n’est pas un achat ponctuel, mais un processus continu. Insérez une clause de révision annuelle, avec deux options : amélioration du modèle ou résiliation sans frais.

• Revue annuelle : Le prestataire doit fournir un rapport comparant les performances du modèle avec les indicateurs initiaux, et proposer des améliorations (re-training, changement de données, ajustement des critères).
• Option de résiliation : « Le client peut résilier le contrat à l’issue de chaque revue annuelle, sans indemnité, si les performances mesurées sont inférieures de plus de 20 % aux indicateurs cibles. »
• Coût de la maintenance : Si vous choisissez de poursuivre, le coût de la maintenance annuelle doit être précisé dès le contrat (ex : 15 % du budget initial par an).

Cas où cela ne marche pas : Une ETI a signé un contrat de trois ans sans clause de révision. Après 18 mois, le modèle de prédiction de la demande, initialement précis à 85 %, ne dépassait plus 60 % en raison de changements dans les habitudes d’achat. Le prestataire a refusé d’adapter le modèle sans renégociation financière, arguant que « le contrat était figé ». L’ETI a dû payer une refonte complète.

Ce que les contrats omettent souvent – et comment les combler

Les litiges naissent aussi de ce qui n’est pas écrit. Voici trois points souvent négligés :

• La propriété des données : « Les données fournies par le client restent sa propriété exclusive. Le prestataire ne peut les utiliser pour entraîner d’autres modèles sans accord écrit. »
• La maintenance des outils tiers : Si le projet dépend de bibliothèques open source (scikit-learn, TensorFlow), précisez qui prend en charge les mises à jour et les dépendances. Exemple : « Le prestataire s’engage à maintenir le code compatible avec les versions stables des bibliothèques utilisées pendant deux ans. »
• Les responsabilités en cas de faille : « En cas de fuite de données due à une faille dans le code fourni par le prestataire, celui-ci prend en charge les coûts de notification et de réparation, dans la limite de 50 000 €. »