9 min de lecture - Clauses de cybersécurité pour contrats IA freelance et fournisseurs

Si vous réalisez des projets IA pour des clients (ou que vous en achetez), le langage contractuel s'est nettement affiné.

La raison est simple : les projets IA touchent très tôt à des éléments sensibles. Documents internes. Tickets clients. Logs de production. Et parfois des fournisseurs de modèles tiers. Une clause vague peut vite se transformer en incident de sécurité ou en litige sur les responsabilités.

Les clauses de cybersécurité dans les contrats IA relèvent donc moins du « vernis juridique » que de la définition d'une réalité opérationnelle : quelles données sont autorisées, comment elles sont traitées, ce qui est journalisé, et ce qui se passe en cas de problème.

Ceci n'est pas un conseil juridique. C'est une checklist pratique que vous pouvez soumettre à votre juriste, à vos achats, ou intégrer à vos propres modèles de contrats.

Ce que vous allez apprendre

• Les clauses spécifiquement déterminantes pour les projets IA (au-delà des conditions logicielles génériques)
• Ce sur quoi les freelances doivent insister pour ne pas hériter d'une responsabilité mal définie
• Ce sur quoi les acheteurs doivent insister pour que le projet passe la revue de sécurité
• Une checklist de clauses prête à l'emploi, à adapter à votre environnement

L'essentiel

Les contrats IA ont besoin de clauses de cybersécurité explicites, car les projets IA touchent souvent à des données internes sensibles, à des logs et à des fournisseurs de modèles tiers. Un bon jeu de clauses définit le périmètre des données, la journalisation et la rétention, la réponse aux incidents, ainsi que les obligations de sécurité (contrôle d'accès, gestion des secrets, usage des fournisseurs). Utilisez une checklist pour éviter les formulations vagues du type « sécurité raisonnable », qui échouent en revue d'achats et échouent à nouveau lors des incidents.

Commencez par le périmètre des données (tout le reste en dépend)

Le moyen le plus rapide de créer un problème de sécurité est de rédiger un contrat qui ne définit jamais quelles données sont concernées.

Avant de débattre des fournisseurs de modèles, commencez ici :

• Quelles catégories de données seront concernées ? (données personnelles, données de santé, données financières, données clients, propriété intellectuelle interne)
• Qu'est-ce qui est explicitement interdit ?
• Où les données peuvent-elles être stockées (et pendant combien de temps) ?
• Qu'est-ce qui peut être journalisé et qui peut accéder aux logs ?
• Les fournisseurs de modèles tiers sont-ils autorisés ? À quelles conditions ?

Si vous ne pouvez pas répondre à ces questions, votre « clause de sécurité » se réduira plus tard à un simple argument d'une ligne.

Le socle de clauses : ce qu'il faut couvrir pour les projets IA

Vous n'avez pas besoin de 40 pages de jargon sécurité. Vous avez besoin que les 10 à 15 bons sujets soient couverts clairement.

Voici les thématiques de clauses qui reviennent systématiquement dans les projets IA réels :

1. Données autorisées et données interdites. Nommez-les explicitement. Évitez les formulations fourre-tout du type « informations confidentielles ».
2. Usage de fournisseurs d'IA/de modèles tiers. Les API externes sont-elles autorisées ? Si oui, lesquelles et à quelles conditions ?
3. Entraînement et rétention. Précisez explicitement si les données peuvent servir à entraîner des modèles, et pour combien de temps elles peuvent être conservées.
4. Journalisation et télémétrie. Qu'est-ce qui est journalisé ? Le contenu est-il expurgé ? Qui peut consulter les logs ?
5. Contrôle d'accès. Principe du moindre privilège, MFA, et modalités d'octroi/de révocation des accès.
6. Gestion des secrets. Aucun secret dans les dépôts de code ; coffre-fort approuvé ; exigences de rotation.
7. Frontières entre environnements. Règles dev/staging/prod, et autorisation ou non d'accès à la production.
8. Normes de sécurité et attestations. Si l'entreprise exige SOC 2, ISO, ou des contrôles internes spécifiques, précisez les attentes.
9. Réponse aux incidents. Définitions des niveaux de gravité, délai de notification, et obligations de coopération.
10. Sous-traitants et sous-traitants ultérieurs. Qui d'autre peut accéder aux données ?
11. Gestion des vulnérabilités. Délais de correction, divulgation, et attentes en matière de remédiation.
12. Suppression et restitution des données. Ce qui se passe à la fin du contrat : restitution des données, confirmation de suppression, et révocation des accès.

L'objectif n'est pas la perfection. L'objectif est de supprimer l'ambiguïté.

Formulations de clauses concrètes (du langage clair, pas du théâtre juridique)

Votre juriste reformulera tout cela dans les règles de l'art. Pour les opérationnels, l'intérêt est de s'accorder sur le sens.

Voici des formulations, dans l'esprit d'une clause, qui réduisent les malentendus :

• Données interdites : « Le Prestataire ne traitera aucun identifiant d'authentification, clé privée, donnée de carte de paiement ou donnée personnelle client, sauf si elle est explicitement listée comme donnée autorisée à l'Annexe A. »
• Usage de modèles externes : « Le Prestataire ne peut recourir qu'aux fournisseurs de modèles tiers figurant sur la liste approuvée. Le Prestataire n'enverra aucune donnée interdite à un fournisseur tiers. »
• Pas d'entraînement : « Les données du Client ne peuvent pas être utilisées pour entraîner ou améliorer des modèles tiers. »
• Journalisation et rétention : « Les prompts et les réponses ne peuvent être journalisés que sous forme expurgée. La conservation du contenu brut est limitée à X jours et restreinte à des rôles nommément désignés. »
• Notification d'incident : « Le Prestataire notifiera le Client de tout incident de sécurité suspecté affectant les données du Client dans un délai de X heures, fournira un calendrier des faits, et coopérera à l'enquête. »
• Révocation des accès : « Dans un délai de X jours après la fin du contrat, le Prestataire révoquera les accès, supprimera les données du Client de ses systèmes, et confirmera cette suppression par écrit. »

Si un fournisseur refuse d'expliciter ces sujets, c'est un signal : il vous demande d'accepter un risque inconnu.

PME vs grands comptes : mêmes sujets, profondeur différente

Les PME se contentent souvent d'une annexe sécurité d'une page. Les grands comptes attendent quelque chose de plus proche d'un référentiel de sécurité complet.

Les sujets sont les mêmes ; ce qui change, c'est le niveau de preuve exigé :

• PME : « Voici notre périmètre de données et notre processus de gestion des incidents » suffit souvent.
• Grand compte : « Montrez-nous qui a accès, comment vous journalisez, comment vous faites tourner vos secrets, et quels sous-traitants touchent aux données » est la norme.

Si vous êtes freelance, ne combattez pas l'existence de la revue de sécurité des grands comptes. Réduisez plutôt le périmètre : engagez-vous sur ce que vous pouvez réellement opérer, et marquez le reste comme hors périmètre.

À copier-coller : checklist des clauses de cybersécurité IA

Utilisez-la comme grille de lecture lorsque vous relisez un contrat (côté acheteur ou côté fournisseur).

AI security clause checklist

Data boundary:
- Allowed data types:
- Prohibited data types:
- Storage locations:
- Retention period:

Model/provider usage:
- External model APIs allowed? (yes/no)
- Approved providers:
- Restrictions (no training, region, logging):

Access and environments:
- MFA required:
- Prod access allowed? (yes/no)
- Least privilege + access revocation:

Logging:
- What is logged:
- Redaction policy:
- Retention period:

Incident response:
- Notification window:
- Severity levels:
- Cooperation and forensics:

Termination:
- Data return:
- Data deletion confirmation:
- Credential revocation:

Deux points de négociation qui protègent les deux parties

Si vous êtes freelance ou fournisseur, ces deux points vous évitent d'hériter d'obligations impossibles à tenir :

• « Nous pouvons accepter des contrôles de sécurité raisonnables, mais nous avons besoin d'un périmètre de données explicite et d'un modèle de responsabilité partagée. »
• « Nous ne traiterons pas de données interdites, et nous avons besoin que le client fournisse des jeux de données assainis ou un accès approuvé. »

Si vous êtes acheteur, ces deux points empêchent le fournisseur de rester dans le flou :

• « Listez les fournisseurs tiers et sous-traitants ultérieurs qui accéderont aux données. »
• « Définissez le délai de notification des incidents et les preuves qui seront fournies. »

Responsabilité partagée (pour qu'aucune des parties ne présume que l'autre s'en occupe)

Les clauses de sécurité échouent souvent parce que chaque partie présume que l'autre est responsable du même contrôle.

Consignez par écrit la réalité de la « responsabilité partagée » :

Cela n'a pas besoin d'être parfait. Cela doit juste être suffisamment explicite pour que vous ne découvriez pas de trous dans la raquette pendant un incident.

Signaux d'alerte contractuels (ils entraînent des reprises de sécurité douloureuses plus tard)

• Le contrat ne mentionne jamais les fournisseurs de modèles tiers ni les sous-traitants ultérieurs.
• « Sécurité raisonnable » est la seule exigence de sécurité formulée.
• La journalisation/rétention n'est pas définie (« nous pouvons journaliser à des fins de débogage »).
• La notification d'incident reste vague (« rapidement ») sans délai précis.
• La fin du contrat ne prévoit ni confirmation de suppression des données, ni révocation des accès.

Si vous repérez ces signaux, corrigez-les tôt. Il est bien plus difficile de renégocier une fois le fournisseur déjà en plein cœur de la prestation.

Erreurs classiques (et comment les éviter)

• « Sécurité raisonnable » sans aucun détail échoue en revue d'achats et échoue à nouveau en réponse à incident. Utilisez une checklist.
• Aucune clarté sur les API de modèles externes entraîne des transferts de données surprises. Rendez-les explicites.
• Aucune clause de fin de contrat/suppression crée un risque persistant d'accès résiduel et de non-conformité.

Pour un point de référence supplémentaire, le Top 10 LLM de l'OWASP offre un cadre utile pour formuler les risques en termes simples.

Rendez les clauses explicites

Les clauses de cybersécurité dans les contrats IA méritent cet effort, car elles évitent la version coûteuse du « malentendu ». Lorsque le périmètre des données, l'usage des fournisseurs, la journalisation et les règles de réponse aux incidents sont explicites, acheteurs et fournisseurs avancent plus vite et dorment mieux. Besoin d'aide pour structurer les clauses de votre contrat IA ? Parlons-en.