DeepSeek ⚠️ Interdiction US : IA chinoise & données
DeepSeek, IA chinoise et modèles ouverts : quelles règles d’interdiction US, risques sécurité des données et impacts pour votre souveraineté numérique ? Vérifiez.
DeepSeek écarté des agences américaines : ce que cette décision change vraiment
Interdire DeepSeek aux États-Unis peut facilement être résumé comme un nouvel épisode de la rivalité technologique entre Washington et Pékin. Ce raccourci dit quelque chose de vrai, mais il masque l'essentiel. La décision rapportée par la BBC vise l'usage de DeepSeek dans les systèmes de plusieurs agences civiles fédérales américaines. Et surtout : les agences du département de la Défense ne sont pas concernées.
L'enjeu ne se limite donc pas à un chatbot de plus ou de moins. DeepSeek s'est fait une place comme une option relativement peu coûteuse et performante, notamment pour des développeurs et des entreprises qui veulent intégrer des modèles sans dépendre exclusivement de grands fournisseurs américains. Restreindre l'usage dans des administrations pose alors des questions très concrètes : quelles données peut-on exposer à un outil externe ? Comment évaluer un modèle « accessible » quand il faut quand même vérifier ses garanties ? Et que doivent faire les organisations européennes qui l'utilisent déjà ?
Cet article reprend le périmètre annoncé, sépare les faits des accusations et propose une méthode pragmatique pour évaluer les risques liés à DeepSeek (ou à n'importe quel modèle utilisé en entreprise).
Ce que l'interdiction américaine prévoit réellement
D'après les informations publiées par la BBC, le département américain de la Sécurité intérieure (DHS) a interdit l'utilisation de DeepSeek dans les agences civiles fédérales. La mesure couvre aussi des technologies développées avec l'aide des modèles de l'entreprise. Elle vise notamment des administrations comme les départements du Trésor, d'État et de la Justice. Les entités relevant du département de la Défense sont, elles, exclues du périmètre décrit.
La décision aurait été rendue publique un lundi, alors que l'interdiction était déjà entrée en vigueur à la fin du mois de juillet. L'article ne précise pas quels risques précis ont motivé la mesure. Cette absence de détails compte : on ne peut pas en déduire que les autorités ont établi l'existence d'un comportement malveillant. On comprend plutôt que les agences concernées ont décidé de réduire leur exposition à un fournisseur jugé sensible dans un contexte de sécurité nationale.
Une mesure administrative, pas une interdiction générale
Dans ce type de dossier, trois niveaux sont souvent mélangés : l'usage par des administrations fédérales, la disponibilité commerciale aux États-Unis, et l'usage par des entreprises privées. Ce que décrit la BBC concerne le premier niveau. Ça ne veut pas dire, en soi, que les particuliers américains ne peuvent plus télécharger l'application, ni que toutes les entreprises américaines doivent retirer DeepSeek de leurs outils.
Pour les organisations européennes, c'est un point important. Une décision prise par une administration américaine n'est pas automatiquement une règle applicable en France ou dans l'Union européenne. En revanche, elle peut influencer des contrats publics, des politiques d'achat, des exigences de cybersécurité et, plus généralement, la façon dont des partenaires internationaux évaluent le risque.
Reste un autre détail : la formulation autour des systèmes « construits avec l'aide » des modèles. Si cette notion est interprétée largement, elle pourrait viser des logiciels qui intègrent une fonction DeepSeek, des services qui utilisent ses API, ou encore des outils internes dont le code a été généré avec ce modèle. Mais sans précision technique, il serait risqué d'affirmer que toute ligne de code produite avec un assistant tombe automatiquement sous le coup de la mesure. En pratique, l'application dépend généralement des définitions, des contrôles et des procédures propres à chaque agence.
Ce qui est établi, et ce qui reste allégué
Le contexte politique est clair : l'administration Trump présente la Chine comme un rival majeur dans le développement de l'intelligence artificielle. D'après une note interne citée par la BBC, un responsable technologique de la Maison-Blanche aurait aussi évoqué une exploitation malveillante des travaux d'entreprises américaines par des concurrents étrangers, principalement chinois.
Parallèlement, OpenAI et Anthropic ont, de leur côté, accusé certaines entreprises chinoises, dont DeepSeek, d'avoir copié ou distillé leurs modèles.
Dans ce cadre, il faut traiter ces éléments comme des déclarations et des accusations, pas comme des conclusions démontrées par l'article lui-même. La BBC indique que le DHS, DeepSeek et l'ambassade de Chine à Washington ont été sollicités pour commenter la mesure. Aucun de leurs retours n'est reproduit dans le contenu.
Pour une entreprise, la question n'est donc pas seulement : « DeepSeek est-il sûr ou dangereux ? ». Il faut regarder aussi le niveau de preuve disponible, la nature des données traitées, la configuration retenue et les garanties contractuelles. Un risque géopolitique peut peser dans la décision, mais il ne remplace pas une analyse technique et juridique adaptée à votre cas.
Pourquoi DeepSeek inquiète autant qu'il attire
DeepSeek occupe une place particulière sur le marché parce qu'il combine des modèles accessibles à des coûts d'utilisation plutôt faibles. Cette combinaison a attiré des développeurs, des jeunes pousses et des plateformes. Selon la BBC, certains fournisseurs de services - dont Snowflake, Vercel et OpenRouter - intègrent des modèles DeepSeek dans leurs offres. L'application grand public a aussi contribué à accroître sa visibilité.
Côté produit, le raisonnement est simple : si la qualité suffit pour une tâche donnée, payer beaucoup moins réduit le coût d'expérimentation et d'exploitation. L'intérêt est particulièrement marqué pour les usages répétitifs - génération de code, classification, synthèse, assistance documentaire - où le coût par requête finit par devenir un sujet « management », pas juste un détail technique.
L'avantage économique n'est pas un coût total
DeepSeek aurait indiqué que l'entraînement de sa première version aurait coûté environ 6 millions de dollars. À titre de comparaison, les coûts associés au développement de GPT-4 auraient été estimés à près de 100 millions de dollars. Ces chiffres ont alimenté les débats sur l'efficacité des investissements américains et chinois dans l'IA.
Mais on ne devrait pas les comparer directement sans prudence. Un coût d'entraînement annoncé n'est pas forcément le coût complet d'un modèle : il peut exclure la recherche préalable, les données, les essais non retenus, l'infrastructure, les salaires ou les coûts de déploiement. Les méthodes de calcul ne sont pas toujours identiques d'un acteur à l'autre. Le montant publié donne un indicateur, mais il ne prouve pas, à lui seul, qu'un modèle serait globalement moins cher à développer ou à exploiter dans tous les contextes.
Pour une entreprise européenne, le coût pertinent, c'est le système en production : le prix des appels au modèle, mais aussi l'intégration, l'orchestration, la supervision, la sécurité, la gestion des incidents et le travail nécessaire pour corriger les résultats. Un modèle moins cher par requête peut revenir plus cher si son intégration impose une infrastructure spécifique, ou si son taux d'erreur oblige à multiplier les vérifications humaines.
« Ouvert » ne veut pas dire « sans contrainte »
La disponibilité de modèles accessibles (et qualifiés d'« open source ») facilite les essais. Elle peut aussi permettre une exécution dans un environnement contrôlé, selon le modèle, sa licence et vos ressources techniques. Mais le terme « ouvert » couvre des réalités différentes : les poids, le code, les données d'entraînement et les conditions d'usage ne sont pas forcément publiés de la même manière.
Avant de conclure, il faut vérifier ce qui est réellement fourni et ce que la licence autorise. Et il faut distinguer l'exécution sur une infrastructure maîtrisée de l'usage d'un chatbot ou d'une API hébergés par un tiers. Dans le premier cas, l'organisation garde la main sur l'environnement, mais doit assumer la maintenance, la sécurité et la capacité de calcul. Dans le second, le déploiement est plus simple, mais les données et les opérations passent par le fournisseur, selon ses conditions.
Cette nuance est cruciale : déployer un modèle localement ne garantit pas, à lui seul, une conformité RGPD ou une conformité à la politique de sécurité de l'entreprise. Il reste à contrôler les journaux, les accès, les transferts de données, les dépendances logicielles et la façon dont les collaborateurs l'utilisent.
Les conséquences pour les entreprises européennes
La décision américaine ne crée pas, à elle seule, une obligation pour les entreprises françaises de retirer DeepSeek. Elle agit plutôt comme un signal à intégrer dans la gouvernance des fournisseurs d'IA. Les directions ne peuvent pas se limiter à comparer les performances et les prix. La provenance du service, les flux de données et la possibilité de changer de fournisseur comptent autant.
Pour les entreprises soumises au RGPD, le point central reste le traitement des données personnelles. Qui détermine les finalités ? Où les données sont-elles hébergées et traitées ? Sont-elles conservées, réutilisées, ou accessibles à des sous-traitants ? Le fournisseur agit-il comme sous-traitant, et les engagements contractuels reflètent-ils réellement le fonctionnement technique ? Tout dépend du mode d'usage : application publique, API commerciale, ou modèle déployé sur votre propre infrastructure.
La CNIL met à disposition des ressources sur la protection des données et les systèmes d'IA, notamment dans ses recommandations sur l'intelligence artificielle. Le cadre européen évolue aussi avec le règlement sur l'IA. Mais ces règles ne remplacent pas une analyse RGPD : la conformité dépend des traitements effectués, du niveau de risque et du contexte.
Le risque dépend du cas d'usage
Toutes les utilisations d'un modèle ne se valent pas. Résumer un texte public, aider à écrire un prototype ou classer des documents non confidentiels n'a pas le même niveau de sensibilité que traiter des dossiers clients, produire une recommandation médicale ou accéder à des données stratégiques.
Pour démarrer, une grille simple peut suffire :
- Données publiques ou fictives : confidentialité limitée, mais il faut vérifier les résultats, les licences et la sécurité des outils.
- Données internes non sensibles : l'entreprise doit contrôler les conditions de traitement, les accès et la conservation.
- Données personnelles ou confidentielles : analyse juridique et sécurité nécessaires avant déploiement, avec des règles strictes sur ce qu'on envoie au modèle.
- Décisions à impact élevé : l'IA ne doit pas entrer en production sans évaluer les obligations applicables, le risque d'erreur, les mécanismes de recours et le niveau de contrôle humain.
Le même raisonnement s'applique à un modèle américain, chinois ou européen. L'origine géographique peut peser sur des aspects comme la juridiction, la continuité de service et la dépendance stratégique, mais elle ne suffit pas à elle seule à remplacer un audit complet.
La dépendance fournisseur est un sujet opérationnel
Un modèle populaire et peu coûteux peut devenir une dépendance si toute une application s'appuie sur ses formats, ses outils ou ses comportements. Une évolution de licence, une restriction d'accès, une panne ou une décision politique peuvent alors obliger à migrer en urgence.
DeepSeek n'est pas le seul exemple : des services propriétaires peuvent changer leurs tarifs, leurs fonctionnalités ou leurs règles d'accès. Le bon réflexe, c'est de concevoir une couche d'intégration qui limite le couplage, de documenter les modèles utilisés et de tester une solution de remplacement pour les tâches critiques.
Le but n'est pas de multiplier les modèles pour chaque usage - ça augmente les coûts et la complexité. Il s'agit plutôt d'éviter qu'un seul fournisseur devienne « non remplaçable » quand la continuité est importante. Parfois, un modèle unique est le meilleur choix. D'autres fois, une bascule possible ou un déploiement local justifie son coût.
Une méthode pratique pour décider
Dans un projet concret, la décision ne devrait pas être prise à partir d'un débat abstrait sur l'origine des modèles. Il faut relier le modèle à un usage, à des données et à des conséquences mesurables. La méthode peut s'appliquer à DeepSeek, à un modèle propriétaire, ou à une solution open source hébergée en Europe.
1. Faire l'inventaire des usages
Commencez par identifier où le modèle est utilisé : application officielle, API, outil intégré par un prestataire, extension de développement ou déploiement interne. Les usages « cachés » arrivent plus souvent qu'on ne le croit : un développeur teste un service avec du code propriétaire, ou une équipe ajoute un assistant à un outil métier sans passer par le processus d'achat.
Pour chaque usage, notez le responsable, les utilisateurs, les données envoyées, le fournisseur et le niveau d'exposition. L'inventaire doit rester concret. « IA générative » ne veut pas dire grand-chose : il faut distinguer, par exemple, la reformulation de contenus publics de l'analyse de demandes de support contenant des informations personnelles.
2. Évaluer les données et les conditions du service
Passez en revue les conditions contractuelles et techniques : conservation des requêtes, réutilisation éventuelle pour l'entraînement, région de traitement, sous-traitants, options de suppression, chiffrement et gestion des comptes. Ne partez pas du principe que l'offre payante, l'API et le chatbot grand public offrent les mêmes garanties.
Si des données personnelles sont impliquées, impliquez le délégué à la protection des données et les équipes de sécurité. Et si vous ne savez pas où vont les données ni comment elles sont conservées, vous n'avez pas assez d'informations pour traiter un usage sensible.
3. Mesurer l'utilité dans le contexte réel
Un benchmark général ne prédit pas automatiquement ce que vous obtiendrez sur vos documents, votre code ou votre vocabulaire métier. Testez un échantillon représentatif, avec des critères définis à l'avance : qualité, taux d'erreur, latence, coût par tâche, facilité de correction et comportement sur les cas limites.
Incluez aussi des exemples difficiles, pas seulement des requêtes où le modèle « réussit ». En production, les erreurs rares mais coûteuses pèsent plus que les démonstrations. Pour un assistant de développement, mesurez par exemple le temps réellement gagné après revue du code, plutôt que le volume de code généré.
4. Décider avec une matrice de risque proportionnée
Vous pouvez organiser la décision avec une matrice simple :
| Niveau | Exemple d'usage | Décision possible |
|---|---|---|
| Faible | Expérimentation sur des données publiques | Autoriser sous réserve de vérification des conditions et des résultats |
| Modéré | Assistance sur des documents internes non sensibles | Encadrer les données, les accès et les validations humaines |
| Élevé | Traitement de données sensibles ou décision importante | Suspendre jusqu'à validation juridique, sécurité et métier |
Cette matrice n'est pas une certification. Elle sert à rendre les arbitrages visibles et à éviter qu'un outil soit « autorisé partout » parce qu'il a été validé pour une tâche peu risquée.
5. Prévoir une sortie avant de dépendre du modèle
Documentez la version du modèle, le fournisseur, la configuration, et les fonctions qui en dépendent. Testez une alternative si la continuité d'activité le justifie. Gardez aussi un processus pour désactiver l'intégration ou revenir à une procédure manuelle si le service devient indisponible.
Oui, cette précaution a un coût. Elle n'est pas utile pour chaque prototype interne. Elle devient pertinente quand une fonction sert des clients, traite un volume important, ou s'inscrit dans un engagement contractuel. En clair : on choisit aussi en fonction du coût d'une panne ou d'un changement, pas seulement par préférence.
Conclusion
La restriction américaine visant DeepSeek concerne d'abord les agences civiles fédérales, dans un contexte de rivalité stratégique et de préoccupations de sécurité qui ne sont pas détaillées dans l'annonce rapportée. Elle ne constitue pas une interdiction générale applicable aux entreprises françaises. En revanche, elle rappelle un point pratique : un modèle performant et peu coûteux ne se choisit pas uniquement sur ses résultats.
Pour décider, partez de votre usage réel : quelles données sont transmises, quel dommage une erreur pourrait-elle causer, quelles garanties propose le fournisseur et combien coûterait une migration ? Autorisez les tests à faible risque, encadrez les usages internes, et mettez en pause les traitements sensibles tant que vos contrôles ne sont pas au niveau.
La prochaine étape utile, concrètement, c'est de dresser l'inventaire des outils d'IA déjà utilisés dans votre organisation, y compris ceux ajoutés sans validation formelle. C'est à partir de cette cartographie - pas d'un débat « de principe » - que vous pourrez trier : où DeepSeek apporte une vraie valeur, où il faut l'encadrer, et où une autre solution est préférable.