Quand un dev colle 500 lignes de code dans Daybreak ou un chat Anthropic, ce n'est pas anodin. Le code source d'une boîte, c'est généralement son actif le plus sensible juridiquement et stratégiquement. Le transférer à un éditeur d'IA américain pose 4 questions concrètes que la plupart des DSI n'ont pas tranchées. Voici de quoi cadrer ça avant la prochaine demande de validation.
Question 1 : c'est un transfert international au sens RGPD ?
Pas toujours. Le RGPD encadre les données personnelles. Du code source sans données personnelles dedans n'est pas un traitement RGPD. Donc en première approximation, transmettre du code-c-pure à OpenAI n'est pas un sujet RGPD.
Mais :
- Si votre code contient des identifiants techniques liés à des personnes (UUID de users, structures de données nommées avec des PII en exemple, commentaires citant des noms), vous retombez dans le RGPD.
- Si Daybreak analyse aussi tes logs (et c'est probable à terme), là vous envoyez presque toujours des données personnelles indirectes (IP, user agents, identifiants de session).
- Si vous utilisez OpenAI pour analyser tes tickets support ou tes emails clients dans la même plateforme, là c'est plein RGPD.
Du coup : la cartographie des données qui passent par Daybreak/Mythos doit être faite avant le déploiement, pas après le premier incident.
Question 2 : c'est un transfert vers les US — et alors ?
OpenAI et Anthropic sont des sociétés américaines. Le Cloud Act (2018) permet aux autorités américaines de demander des données stockées par une société US, même hors territoire US. Donc même si OpenAI te garantit un stockage "EU region", les autorités américaines peuvent en théorie demander accès.
Le mécanisme de transfert légal post-Schrems II repose sur :
- DPF (Data Privacy Framework) : OpenAI et Anthropic sont (ou peuvent être) certifiés, ce qui couvre une partie des transferts.
- SCC (Standard Contractual Clauses) : à signer en plus pour les cas non couverts.
- Analyse d'impact transferts (TIA) : à documenter — vous démontrez que les transferts sont proportionnés aux risques.
En pratique, la majorité des entreprises françaises qui utilisent OpenAI Enterprise ou Anthropic Claude for Business ont signé DPF + SCC + TIA. C'est tenable juridiquement. Mais ça ne veut pas dire "zéro risque" — ça veut dire "risque cadré et documenté".
Question 3 : et le secret des affaires ?
C'est la question vraiment compliquée. Le secret des affaires (directive UE 2016/943, transposée en droit français Code de commerce L151-1) protège votre code et votre savoir-faire à condition que vous prennes des mesures raisonnables pour les protéger.
Si vous envoyez votre code à OpenAI sans :
- Contrat de confidentialité spécifique signé,
- Training opt-out documenté,
- Mécanisme de purge des logs,
- Restriction des collaborateurs autorisés à le faire,
... un juge pourrait considérer que vous n'avez pas pris les mesures raisonnables, et donc que votre code n'est plus protégé. Ça paraît théorique tant qu'il n'y a pas de litige, mais c'est exactement ce que vos investisseurs et vos acquéreurs vont regarder en due diligence.
Question 4 : qu'est-ce que disent les contrats Daybreak / OpenAI / Anthropic ?
À date de mai 2026, les contrats enterprise OpenAI (avec Daybreak inclus) prévoient typiquement :
- Pas de training sur les données enterprise par défaut — opt-in seulement.
- Rétention 30 jours des prompts/responses (puis suppression), sauf demande légale.
- DPF + SCC pour les transferts.
- Engagement de confidentialité sur les données traitées.
Anthropic propose des termes proches. Les deux acceptent des avenants négociés sur les gros comptes (typiquement > 100 K€/an) : data residency UE, durée de rétention raccourcie, droit d'audit.
Le piège : si vous signez le contrat "self-serve" standard pour 200 €/mois et que vos équipes l'utilisent comme une plateforme enterprise, les clauses standard ne te protègent pas autant. Le passage en "enterprise" change le contrat, pas seulement le prix.
Les alternatives souveraines existantes (et leurs limites)
| Solution | Niveau de souveraineté | Limite réelle | |---|---|---| | Mistral (Le Chat Enterprise) | Hébergement UE possible | Niveau modèle inférieur à GPT-5.5/Claude sur tâches cyber complexes | | Modèles open-source self-hosted (Llama, Qwen) | Total | Pas au niveau Mythos/Daybreak côté capacités | | Azure OpenAI région EU | Mixte (Microsoft EU) | Cloud Act applicable (Microsoft est US) | | OpenAI Enterprise EU region + SCC | Cadré juridiquement | Reste un transfert vers les US au sens Schrems II |
Du coup, en vrai, aucune solution n'est parfaite. Le bon arbitrage dépend de la sensibilité de ce que vous envoyez, pas d'un dogme général.
Décision pragmatique selon la sensibilité du code
| Sensibilité du code | Action recommandée | |---|---| | Code public / OSS | Daybreak ou Mythos sans souci | | Code privé non stratégique | OpenAI Enterprise EU + SCC + opt-out training | | Code stratégique (algos cœur, IP) | Self-hosted (Mistral, Llama) ou pas d'IA externe du tout | | Code client sous NDA | Interdiction sauf consentement écrit du client |
Ce que je recommande de faire avant le prochain pilote
- Cartographier ce que vos équipes envoient déjà à OpenAI / Anthropic aujourd'hui (souvent il y a déjà des fuites informelles via les comptes perso ChatGPT).
- Choisir un type de code "envoyable" et un type "non envoyable", et l'écrire dans une politique.
- Mettre un proxy entreprise devant les API IA (Cloudflare Workers, Helicone, ou un dev custom) pour logger et bloquer ce qui ne doit pas sortir.
- Négocier le DPA enterprise — pas le contrat self-serve.
Donc voilà : le sujet n'est pas "OpenAI c'est mal, faut tout faire en France". Le sujet c'est "qu'est-ce que j'envoie, à qui, sous quel contrat, et qu'est-ce que j'aurais à raconter à mon comex en cas de fuite". Si vous pouvez répondre à ces 4 questions, vous pouvez utiliser Daybreak ou Mythos l'esprit tranquille.
