Retour au blog
Développement et IA 19 min de lecture

Contrat de développement logiciel IA : les clauses indispensables à exiger

|

Mis à jour le

Contrat de développement logiciel IA : les clauses indispensables à exiger

Selon le Standish Group, seuls 17 % des projets informatiques respectent à la fois le budget et les délais prévus. Quand le prestataire utilise l'intelligence artificielle pour générer du code, entraîner des modèles ou automatiser des processus, les zones de flou contractuel se multiplient. Qui détient la propriété intellectuelle d'un code partiellement généré par IA ? Vos données métier peuvent-elles servir à entraîner un modèle réutilisé chez un concurrent ? Quelles garanties de conformité votre prestataire doit-il apporter face au Règlement européen sur l'IA (AI Act) ?

Le marché français du logiciel et des services numériques pèse 62,4 milliards d'euros en 2025, avec 78 % des entreprises qui développent désormais des solutions sur mesure (Syntec Numérique, 2025). Chaque contrat signé avec un prestataire de développement engage des actifs stratégiques : code source, données, algorithmes, modèles entraînés. Pourtant, la majorité des contrats standards n'intègrent aucune clause spécifique à l'IA.

Cet article détaille les clauses indispensables à insérer dans un contrat de développement logiciel à l'ère de l'IA — de la propriété intellectuelle aux garanties de livraison, en passant par la confidentialité des données d'entraînement et la conformité réglementaire.

TL;DR : Un contrat de développement logiciel intégrant de l'IA doit couvrir cinq domaines critiques : la cession explicite des droits de propriété intellectuelle (y compris sur le code généré par IA), la confidentialité et la non-réutilisation des données d'entraînement, les garanties de livraison et de conformité fonctionnelle, la conformité au RGPD et à l'AI Act, et les clauses de réversibilité. Sans ces protections, vous risquez de perdre la maîtrise de vos actifs numériques.

Pourquoi les contrats de développement logiciel classiques ne suffisent plus

Le code généré par IA crée un vide juridique inédit

Le droit d'auteur français repose sur un principe fondamental : seule une personne physique peut être auteur d'une oeuvre de l'esprit (article L111-1 du Code de la propriété intellectuelle). Lorsqu'un développeur utilise GitHub Copilot, ChatGPT ou un autre outil d'IA générative pour produire une partie du code, la question de la titularité des droits se pose avec acuité.

Aucun tribunal français n'a encore statué sur la protection par le droit d'auteur d'un code intégralement généré par une IA. Le vide juridique est réel. Et ce flou profite systématiquement à celui qui a rédigé le contrat — c'est-à-dire, dans la majorité des cas, au prestataire.

Un contrat de développement logiciel signé en 2024 ou 2025 sans clause spécifique à l'IA expose le donneur d'ordre à trois risques concrets : l'impossibilité de prouver la titularité des droits sur le code livré, la réutilisation potentielle de composants IA communs entre plusieurs clients, et l'absence de traçabilité sur l'origine du code produit.

L'AI Act impose de nouvelles obligations contractuelles

Le Règlement européen sur l'intelligence artificielle (AI Act), entré en vigueur le 1er août 2024, introduit un calendrier d'obligations progressif qui impacte directement la relation client-prestataire.

Le contrat doit préciser les responsabilités, la documentation attendue et les contrôles selon la qualification du système. L’AI Act suit un calendrier progressif : août 2026 n’est pas une date d’application complète à tous les systèmes à haut risque. Consultez le calendrier actualisé de la Commission européenne et le texte applicable. Les autres obligations, notamment celles relatives aux données personnelles, restent à vérifier pour le projet concerné.

Pour un donneur d'ordre, cela signifie que le contrat doit répartir clairement les obligations de conformité entre le client et le prestataire. Qui est responsable de la classification du risque IA ? Qui produit la documentation technique exigée ? Qui gère le marquage CE si le système relève de la catégorie « haut risque » ?

Les litiges informatiques coûtent cher et durent longtemps

Les contentieux liés aux contrats informatiques opposent le plus souvent une ESN ou un éditeur de logiciel à son client, sur des motifs récurrents : non-conformité du livrable au cahier des charges, instabilité fonctionnelle (bugs, anomalies), dépassement de délais, ou perte de données lors de l'installation.

Selon le Standish Group, 52,7 % des projets informatiques dépassent leur budget prévisionnel de 189 % en moyenne. Ces dépassements trouvent souvent leur origine dans des contrats insuffisamment précis, où les obligations de résultat, les critères de recette et les pénalités de retard restent flous. Avec l'IA en plus dans l'équation, les sources de litige potentiel se multiplient.

Propriété intellectuelle : les clauses qui protègent réellement vos actifs

La cession de droits selon l'article L131-3 du CPI

Le Code de la propriété intellectuelle est limpide sur un point : l'existence d'un contrat de prestation ne transfère pas automatiquement les droits d'auteur au client. L'article L131-3 du CPI exige que toute cession de droits mentionne explicitement :

  • Chaque droit cédé individuellement (reproduction, adaptation, distribution, représentation)
  • L'étendue et la destination de la cession
  • Le territoire couvert
  • La durée de la cession

Sans ces mentions, la cession est juridiquement nulle. Le prestataire reste propriétaire du code source, et le client se retrouve dépendant : il utilise un logiciel dont il n'est pas propriétaire, qu'il ne peut ni modifier ni confier à un autre prestataire.

Cette exigence de formalisme prend une dimension supplémentaire lorsque le code intègre des composants générés par IA. La clause de cession doit couvrir non seulement le code écrit par les développeurs humains, mais aussi les éléments produits ou assistés par des outils d'IA générative.

Ce que doit couvrir une clause de propriété intellectuelle complète en 2026

Élément à couvrir Détail contractuel requis Risque si absent
Code source humain Cession conforme L131-3 CPI : droits listés, étendue, durée, territoire Le prestataire reste propriétaire du code
Code généré par IA Cession étendue aux outputs d'outils IA utilisés pendant le développement Zone grise juridique exploitable par le prestataire
Modèles entraînés Transfert de propriété ou licence exclusive sur les modèles fine-tunés Le prestataire peut réutiliser le modèle chez un concurrent
Données d'entraînement Clause de non-réutilisation et restitution des jeux de données Vos données métier alimentent d'autres projets
Documentation technique Cession des droits sur specs, architecture, documentation API Dépendance au prestataire pour la maintenance
Composants open source Inventaire des licences tierces utilisées (GPL, MIT, Apache) Contamination virale non détectée (licence GPL)

La question spécifique des modèles fine-tunés sur vos données

Lorsque votre prestataire entraîne ou affine un modèle d'IA sur vos données métier, le contrat doit distinguer trois éléments :

Le modèle de base (foundation model) : il appartient généralement à un éditeur tiers (OpenAI, Anthropic, Mistral, Meta). Le contrat doit préciser sous quelle licence ce modèle est utilisé et quelles restrictions s'appliquent à votre usage commercial.

Les poids du modèle fine-tuné : ils constituent la valeur ajoutée spécifique à votre entreprise. Si le contrat ne prévoit pas explicitement leur transfert, le prestataire pourrait les réutiliser comme base pour un autre client — avec un avantage compétitif construit sur vos données.

Le pipeline d'entraînement : les scripts, configurations et méthodologies utilisés pour le fine-tuning. Leur transfert garantit votre autonomie pour les itérations futures.

Une clause de propriété intellectuelle robuste couvre ces trois couches et prévoit un mécanisme de vérification (audit technique) permettant de confirmer que les éléments livrés correspondent bien à ce qui est décrit dans le contrat.

Confidentialité des données d'entraînement : le nouveau champ de bataille contractuel

Pourquoi vos données métier sont en danger

Quand une ESN développe un logiciel intégrant de l'IA pour votre compte, elle manipule potentiellement trois types de données sensibles : vos données métier (transactions, clients, processus), les données utilisées pour entraîner ou affiner des modèles, et les données générées par le système en production.

La Commission européenne a publié en 2025 des clauses contractuelles types actualisées pour les systèmes d'IA dans les marchés publics, conformément à l'article 25.4 de l'AI Act. Ces modèles contractuels illustrent un principe fondamental : la contractualisation de la protection des données est devenue indispensable, pas optionnelle.

Le risque principal est la réutilisation non autorisée. Un prestataire qui travaille pour plusieurs clients du même secteur peut, en l'absence de clause restrictive, utiliser les insights tirés de vos données pour améliorer son offre générale — ou pire, nourrir un modèle IA réutilisé chez un concurrent direct.

Les cinq clauses de confidentialité à exiger

1. Non-réutilisation des données pour l'entraînement

Le contrat doit interdire explicitement toute réutilisation de vos données pour entraîner, affiner ou évaluer des modèles d'IA destinés à d'autres clients ou à l'amélioration de produits internes du prestataire, sauf accord écrit préalable. Cette clause va au-delà de la confidentialité classique : elle cible spécifiquement l'usage en tant que données d'entraînement.

2. Propriété exclusive des données

Le contrat doit stipuler sans équivoque que le client reste l'unique propriétaire de ses données. Le prestataire ne bénéficie que d'un droit d'usage strictement limité à l'exécution du contrat, avec une obligation de suppression vérifiable à l'issue de la prestation.

3. Isolation technique des environnements

Au-delà de l'engagement contractuel, exigez des garanties techniques : vos données doivent être traitées dans un environnement isolé, sans mutualisation avec les données d'autres clients. Cette clause est particulièrement critique quand le prestataire utilise des plateformes cloud partagées.

4. Traçabilité des accès et des traitements

La CNIL recommande que les systèmes d'IA soient conçus avec une transparence opérationnelle incluant des capacités d'enregistrement des événements. Votre contrat doit prévoir des journaux d'accès aux données, consultables sur demande, identifiant qui a accédé à quoi, quand et dans quel but.

5. Interdiction de transfert hors EEE sans garanties

Les transferts de données hors de l'Espace économique européen nécessitent des garanties adaptées (clauses contractuelles types, mécanismes équivalents). Cette obligation, issue du RGPD, prend une importance accrue quand le prestataire utilise des API d'IA hébergées aux États-Unis ou en Asie.

Conformité RGPD : les obligations spécifiques à l'IA

Le développement d'un logiciel intégrant de l'IA soulève des questions RGPD spécifiques que le contrat doit anticiper. La CNIL a publié des recommandations explicites pour le développement des systèmes d'IA.

Le principe central : les données collectées pour une finalité ne peuvent pas être réutilisées pour un usage radicalement différent. L'entraînement d'un modèle d'IA constitue une nouvelle finalité qui nécessite une base légale distincte. Le contrat doit documenter cette base légale et prévoir les mécanismes d'exercice des droits des personnes concernées (droit d'accès, de rectification, d'opposition, d'effacement).

Un point souvent négligé : le « droit à l'oubli » appliqué aux modèles d'IA. Si un utilisateur demande la suppression de ses données et que celles-ci ont servi à entraîner un modèle, le simple effacement de la base de données ne suffit pas — les patterns appris par le modèle persistent. Le contrat doit prévoir une procédure technique pour gérer cette situation (ré-entraînement, machine unlearning, ou justification documentée de l'impossibilité technique).

Garanties de livraison : transformer les promesses en obligations contractuelles

Obligation de moyens vs obligation de résultat : trancher sans ambiguïté

La distinction entre obligation de moyens et obligation de résultat reste le point de friction principal dans les litiges informatiques. En obligation de moyens, le prestataire s'engage à mettre en oeuvre les ressources nécessaires — sans garantir le résultat. En obligation de résultat, il s'engage sur un livrable conforme à des spécifications définies.

Pour un développement logiciel intégrant de l'IA, le contrat devrait combiner les deux approches :

Phase du projet Type d'obligation Justification
Analyse et conception Obligation de moyens renforcée L'exploration technique nécessite une marge d'incertitude
Développement des fonctionnalités déterministes Obligation de résultat Le code classique doit respecter les spécifications
Développement des composants IA Obligation de moyens avec seuils de performance Les performances IA dépendent de la qualité des données
Intégration et recette Obligation de résultat Le livrable final doit passer les tests définis
Maintenance corrective Obligation de résultat Les bugs identifiés doivent être corrigés

Cette approche granulaire évite deux écueils : un contrat tout en obligation de résultat qui découragerait les prestataires sérieux (l'IA implique une part d'expérimentation), et un contrat tout en obligation de moyens qui vous laisserait sans recours en cas de livrable non fonctionnel.

Définir des critères de recette mesurables pour les composants IA

Les composants IA d'un logiciel ne se recettent pas comme du code déterministe. Un algorithme de classification peut atteindre 95 % de précision sur un jeu de test et 78 % en production. Le contrat doit anticiper cet écart en définissant des critères objectifs.

Voici les métriques à contractualiser selon le type de composant IA :

Pour un modèle de classification : précision (accuracy), rappel (recall), score F1, avec des seuils minimaux définis sur un jeu de test représentatif validé conjointement.

Pour un modèle de génération de texte : taux d'hallucination maximal acceptable, score de pertinence évalué par un panel humain, conformité aux guidelines de marque.

Pour un système de recommandation : taux de clic (CTR) minimal, diversité des recommandations, absence de biais discriminatoire mesurable.

Pour un chatbot ou agent conversationnel : taux de résolution au premier contact, temps de réponse, taux d'escalade vers un humain.

Le contrat doit préciser la méthodologie d'évaluation (quel jeu de données, quelle fréquence de test, qui valide les résultats) et prévoir une période de validation en conditions réelles (A/B testing, shadow mode) avant la recette définitive.

Pénalités, jalons et mécanismes de sortie

Un contrat de développement logiciel IA robuste structure le projet en jalons vérifiables avec des conditions de passage claires :

Jalons de livraison : chaque jalon correspond à un livrable défini (maquettes validées, MVP fonctionnel, version bêta, version de production). Le contrat associe à chaque jalon une date limite, un livrable précis et des critères d'acceptation.

Pénalités de retard : elles doivent être proportionnelles et progressives. Un standard courant : 0,5 % à 1 % du montant du jalon par jour de retard, plafonné à 10-15 % du montant total. Des pénalités trop faibles n'incitent pas au respect des délais ; des pénalités trop élevées poussent le prestataire à livrer un produit bâclé pour éviter les sanctions.

Clause de sortie anticipée : si le prestataire accumule un retard supérieur à un seuil défini (par exemple, 30 jours cumulés), le client doit pouvoir résilier le contrat avec récupération des livrables produits, du code source, des modèles et de la documentation — sans pénalité pour le client.

Garantie de bon fonctionnement : une période de garantie post-livraison (3 à 12 mois selon la complexité) pendant laquelle le prestataire corrige gratuitement les anomalies bloquantes et majeures.

Réversibilité et continuité : préparer la sortie dès la signature

Le piège de la dépendance technique

La réversibilité est la capacité à reprendre le contrôle de votre logiciel — en interne ou avec un autre prestataire — si la relation contractuelle prend fin. Sans clause de réversibilité, vous risquez le vendor lock-in : un enfermement technique qui rend le changement de prestataire prohibitivement coûteux.

Ce risque est amplifié avec les projets IA. Un modèle entraîné sur une infrastructure spécifique, avec des dépendances propriétaires, peut être techniquement impossible à migrer si la réversibilité n'a pas été anticipée contractuellement.

Les éléments à récupérer en fin de contrat

Le contrat doit lister explicitement les éléments que le prestataire s'engage à transférer en cas de fin de relation :

  • Code source complet avec historique de versioning (dépôt Git)
  • Modèles IA entraînés dans un format standard et portable (ONNX, SavedModel, etc.)
  • Jeux de données d'entraînement et de test utilisés
  • Documentation technique complète (architecture, API, procédures de déploiement)
  • Configurations d'infrastructure (scripts IaC, fichiers Docker, pipelines CI/CD)
  • Secrets et credentials (clés API, certificats, tokens d'accès)
  • Licences tierces nécessaires à l'exploitation

Le transfert doit s'accompagner d'une période de transition (typiquement 1 à 3 mois) pendant laquelle le prestataire sortant accompagne la reprise, avec une obligation d'assistance documentée et facturée à un tarif prédéfini.

L'escrow de code source : une garantie supplémentaire

Le dépôt du code source chez un tiers de confiance (escrow) offre une protection en cas de défaillance du prestataire (liquidation judiciaire, cessation d'activité). Le code est libéré au profit du client si un événement déclencheur contractuellement défini survient.

Pour les projets IA, l'escrow doit inclure non seulement le code, mais aussi les modèles entraînés et les pipelines de données. Un dépôt trimestriel ou à chaque version majeure constitue une bonne pratique.

Conformité réglementaire : intégrer l'AI Act dans le contrat

Répartir les responsabilités de conformité

L'AI Act distingue plusieurs rôles : le fournisseur (provider), le déployeur (deployer) et l'utilisateur du système d'IA. Chaque rôle porte des obligations spécifiques. Le contrat doit clarifier quel rôle occupe chaque partie.

Dans la majorité des projets de développement sur mesure, le prestataire agit comme fournisseur du système d'IA et le client comme déployeur. Cette répartition implique :

Obligations du prestataire (fournisseur) :

  • Évaluation et classification du niveau de risque du système
  • Production de la documentation technique exigée par l'AI Act
  • Mise en place d'un système de gestion des risques
  • Garantie de la qualité des données d'entraînement
  • Tests de conformité pré-déploiement

Obligations du client (déployeur) :

  • Utilisation conforme aux instructions du fournisseur
  • Surveillance humaine du système en production
  • Signalement des incidents et dysfonctionnements
  • Information des personnes concernées par le traitement IA

Le contrat doit prévoir une clause d'adaptation : si la classification du risque évolue (une IA initialement classée « risque limité » qui bascule en « haut risque » après modification), les obligations sont ajustées et les coûts de mise en conformité répartis selon une clé définie à l'avance.

La documentation technique comme livrable contractuel

Le contrat doit préciser les responsabilités, la documentation attendue et les contrôles selon la qualification du système. L’AI Act suit un calendrier progressif : août 2026 n’est pas une date d’application complète à tous les systèmes à haut risque. Consultez le calendrier actualisé de la Commission européenne et le texte applicable. Les autres obligations, notamment celles relatives aux données personnelles, restent à vérifier pour le projet concerné.

Le contrat doit inclure cette documentation parmi les livrables obligatoires, avec un niveau de détail conforme aux exigences de l'AI Act :

  • Description générale du système et de sa finalité
  • Informations sur les données d'entraînement, de validation et de test
  • Métriques de performance et leurs limites connues
  • Mesures de cybersécurité et de robustesse
  • Instructions d'utilisation pour le déployeur
  • Procédures de contrôle humain

Checklist : les 20 clauses à vérifier avant de signer

Voici la grille de contrôle à utiliser avant de valider tout contrat de développement logiciel intégrant de l'IA :

Propriété intellectuelle

  1. Cession de droits conforme à l'article L131-3 du CPI (droits listés, étendue, durée, territoire)
  2. Extension explicite de la cession au code généré par IA
  3. Transfert de propriété des modèles IA fine-tunés sur vos données
  4. Inventaire des composants open source et de leurs licences
  5. Clause de garantie contre la contrefaçon (le prestataire garantit ne pas violer les droits de tiers)

Confidentialité et données 6. Interdiction de réutilisation des données pour l'entraînement de modèles tiers 7. Propriété exclusive du client sur ses données 8. Isolation technique des environnements de traitement 9. Traçabilité des accès aux données (journaux consultables) 10. Encadrement des transferts de données hors EEE

Garanties de livraison 11. Qualification explicite du type d'obligation (moyens/résultat) par phase 12. Critères de recette mesurables pour les composants IA (métriques, seuils) 13. Jalons de livraison avec dates et critères d'acceptation 14. Pénalités de retard proportionnelles et progressives 15. Garantie de bon fonctionnement post-livraison (durée, périmètre)

Réversibilité 16. Liste exhaustive des éléments à transférer en fin de contrat 17. Période de transition avec assistance obligatoire du prestataire 18. Format de livraison des modèles IA (ONNX ou équivalent portable) 19. Escrow du code source et des modèles

Conformité réglementaire 20. Répartition des responsabilités AI Act (fournisseur/déployeur) et clause d'adaptation

FAQ

Un prestataire peut-il refuser de céder la propriété du code source ?

Oui. En droit français, l'auteur d'un logiciel (le prestataire) reste propriétaire de son code en l'absence de cession écrite. Aucune obligation légale ne le contraint à céder ses droits. La cession est une négociation contractuelle. Si le prestataire refuse, négociez au minimum une licence exclusive, perpétuelle et irrévocable couvrant tous les usages nécessaires à votre exploitation.

Le code généré par GitHub Copilot ou ChatGPT est-il protégé par le droit d'auteur ?

La question n'a pas encore été tranchée par les tribunaux français. Le droit d'auteur exige une « empreinte de la personnalité de l'auteur », ce qui suppose un auteur humain. Un code intégralement généré par IA pourrait ne pas être protégeable. Le contrat doit anticiper cette incertitude en prévoyant une cession élargie couvrant explicitement les outputs d'outils d'IA, quelle que soit leur qualification juridique future.

Quelles sanctions prévoit l'AI Act en cas de non-conformité ?

L'AI Act prévoit des amendes pouvant atteindre 35 millions d'euros ou 7 % du chiffre d'affaires annuel mondial pour les pratiques interdites, 15 millions d'euros ou 3 % pour les violations relatives aux systèmes à haut risque, et 7,5 millions d'euros ou 1 % pour la fourniture d'informations incorrectes. Le contrat doit prévoir quelle partie assume la responsabilité financière selon la nature de l'infraction.

Comment vérifier que mon prestataire n'utilise pas mes données pour entraîner d'autres modèles ?

Exigez contractuellement un droit d'audit technique (réalisable par un tiers indépendant), des journaux d'accès aux données horodatés, une clause de destruction certifiée des données en fin de contrat, et une isolation technique documentée des environnements. Complétez par des pénalités contractuelles dissuasives en cas de violation avérée.

Faut-il exiger une obligation de résultat pour les composants IA ?

Pas systématiquement. Les performances d'un modèle IA dépendent fortement de la qualité et du volume des données fournies par le client. Une obligation de moyens renforcée avec des seuils de performance contractuels (précision minimale, taux d'erreur maximal) constitue généralement l'approche la plus équilibrée — et la plus défendable en cas de litige.

Que se passe-t-il si le prestataire fait faillite en cours de projet ?

Sans clause de réversibilité et sans escrow, vous perdez potentiellement l'accès au code source, aux modèles et à la documentation. Le dépôt de code chez un tiers de confiance (escrow) avec libération automatique en cas de procédure collective est la meilleure protection. Prévoyez également des livraisons intermédiaires régulières pour limiter l'exposition.


AI Coder Squad : des contrats clairs pour des projets IA maîtrisés

Chaque projet livré par AI Coder Squad s'accompagne d'un cadre contractuel transparent — cession de propriété intellectuelle complète, code source livré à chaque jalon, documentation technique incluse dans les livrables. Les problématiques de propriété du code, de confidentialité des données et de réversibilité sont traitées dès la proposition commerciale.

AI Coder Squad conçoit des applications sur mesure et des agents IA pour les entreprises qui veulent aller vite sans sacrifier la qualité — avec des développeurs senior et une approche propulsée par l'IA.

Démarrez votre projet et découvrez comment AI Coder Squad peut accélérer votre prochaine réalisation.