Par Chahid Naoufel

Publié le · Modifié le · Vérifié le

Les points essentiels

  • “Open source” et “poids ouverts” ne décrivent pas le même niveau d’accès.[1][2]
  • Le pays d’origine ne détermine pas à lui seul le trajet des données ; l’API et l’hébergement sont décisifs.[1][2]
  • L’auto-hébergement ne crée pas automatiquement conformité ou sécurité.[1][2]
  • La licence, la documentation, la chaîne d’approvisionnement et les usages interdits doivent être examinés version par version.[1][2]
  • La décision doit reposer sur des tests métier et un scénario de sortie.[1][2]

Remplacer une question de confiance par des preuves

Une origine nationale peut déclencher des exigences de risque légitimes, mais elle ne remplace pas l’analyse technique, juridique et opérationnelle. Deux déploiements du même modèle peuvent exposer les données de manière très différente.[1][2]

L’évaluation compare licence, artefacts publiés, opérateur de l’API, lieu d’hébergement, télémétrie, dépendances, sécurité, capacité de correction et qualité sur vos tâches.[1][2]

Les distinctions à établir avant un pilote

  • Des poids téléchargeables ne signifient pas nécessairement code, données et méthode ouverts.[1][2]
  • Une licence peut limiter des usages, des tailles d’entreprise, des territoires ou des dérivés.[1][2]
  • Un appel API envoie les données à l’opérateur défini par le service utilisé.[1][2]
  • Un déploiement local peut encore dépendre de bibliothèques, images ou téléchargements externes.[1][2]
  • Le RGPD exige une analyse du traitement, pas un label géographique simplifié.[1][2]
  • Les accusations publiques de copie ou de distillation doivent rester qualifiées tant qu’elles ne sont pas établies.[1][2]

Choisir le mode d’accès

API de l’éditeur

Vérifiez entité contractante, régions, transferts, rétention, entraînement, sous-traitants et incidents.

API d’un hébergeur européen

Contrôlez que le traitement reste réellement dans le périmètre annoncé et qui maintient le modèle.

Auto-hébergement

Budgétez GPU, disponibilité, observabilité, mises à jour, correctifs et expertise.[1][2]

Renoncer ou isoler

Écartez le modèle si la licence est ambiguë, la provenance invérifiable ou les contrôles incompatibles avec l’usage.[1][2]

Comparer les preuves de maîtrise

Comparer les preuves de maîtrise
DimensionAPI externeAuto-hébergement
DonnéesDépend du contrat et de la régionDépend de votre architecture
Mises à jourGérées par l’opérateurÀ votre charge
CoûtUsage et optionsInfra et exploitation
ContrôleParamètres du servicePlus fin mais exigeant
RéversibilitéExport et alternativesPoids, formats et compétences

Séparer open source, poids ouverts et service accessible

Examiner les artefacts réellement publiés

Poids, code d’inférence, code d’entraînement, documentation et données peuvent avoir des niveaux d’accès différents. Décrivez ce qui est disponible pour la version choisie au lieu d’appliquer une étiquette globale.[1][2]

Lire la licence comme une exigence produit

Archivez le texte et la version, puis vérifiez droits commerciaux, redistribution, modification, attribution, restrictions d’usage et obligations sur les dérivés. Une licence compatible avec un prototype peut ne pas couvrir la mise en production prévue.

Qualifier les accusations de copie ou de distillation

Distinguez déclaration d’un acteur, analyse technique, procédure officielle et fait établi. Ces éléments peuvent justifier une revue renforcée, mais ne doivent pas être reformulés comme une certitude sans preuve correspondante.

Tracer les données selon le mode de déploiement

API externe

Cartographiez contenu des requêtes, métadonnées, entité opératrice, région, journaux, rétention, usage pour amélioration, support et sous-traitants. Le nom du modèle ne répond pas à ces questions.[1][2]

Déploiement sous votre contrôle

Vérifiez téléchargements, télémétrie, images de conteneur, registre de paquets, accès administrateur, sauvegardes et journaux. Local ne signifie pas isolé tant que les dépendances et flux sortants ne sont pas contrôlés.

Décider avec vos tests plutôt qu’avec un classement public

  • Cas représentatifs dans les langues utilisées.[1][2]
  • Entrées ambiguës, longues et contradictoires.[1][2]
  • Exactitude factuelle et respect du format.[1][2]
  • Refus, biais et erreurs à conséquence élevée.[1][2]
  • Résistance aux injections et fuites.[1][2]
  • Latence, capacité et coût complet sur votre infrastructure.[1][2]

Conserver une responsabilité identifiable

Nommez le propriétaire du cas d’usage, la personne qui accepte la version, l’équipe qui traite les incidents et l’autorité qui peut suspendre le service. Un modèle téléchargeable ne fournit pas à lui seul ces fonctions.[1][2]

Comparer le coût complet et préparer la sortie

Coût exploité, pas prix d’appel

Additionnez infrastructure, optimisation, disponibilité, sécurité, évaluation, supervision, support et mises à jour. Rapportez le total au résultat métier accepté.[1][2]

Conditions de refus ou remplacement

Renoncez si licence ou provenance restent incompatibles, si les contrôles ne peuvent être démontrés ou si la qualité exige trop de reprise. Conservez formats, corpus et interfaces permettant d’évaluer une alternative.[1][2]

Maintenir une fiche par version réellement déployée

  • Nom, version, hachage et source de téléchargement.[1][2]
  • Licence archivée et restrictions.[1][2]
  • Format des poids et dépendances.[1][2]
  • Matériel, quantification et paramètres de service.[1][2]
  • Évaluations métier et sécurité.[1][2]
  • Données envoyées ou journalisées.[1][2]
  • Correctifs, fin de support et propriétaire.[1][2]
  • Alternative testée et procédure de retrait.[1][2]

Réexaminer la confiance à chaque changement matériel

Une nouvelle version, une licence modifiée, une dépendance compromise ou un hébergeur différent peut changer le risque sans changer le nom commercial. Déclenchez une revue ciblée et empêchez la mise à jour automatique de contourner les validations.[1][2]

La décision finale combine provenance suffisamment documentée, droit d’usage, sécurité du paquet, qualité sur vos tâches, coût d’exploitation et capacité de sortie. Aucun pays d’origine ni label open source ne remplace cette analyse.[1][2]

Garde-fous et points de contrôle

  • Licence archivée avec la version.[1][2]
  • Checksum et provenance des artefacts.[1][2]
  • Analyse des dépendances.[1][2]
  • Tests de fuite et d’injection.[1][2]
  • Journalisation minimisée et protégée.[1][2]
  • Plan de remplacement du modèle.[1][2]

Déployer par étapes

  • Définir les données interdites.[1][2]
  • Qualifier licence et opérateurs.[1][2]
  • Évaluer un jeu de cas réel.[1][2]
  • Tester sécurité et exploitation.[1][2]
  • Piloter sur données non sensibles.[1][2]
  • Décider avec critères et seuils écrits.[1][2]

Mesurer le résultat complet

  • Taux de réussite métier.[1][2]
  • Erreurs critiques.[1][2]
  • Coût par tâche.[1][2]
  • Latence et capacité.[1][2]
  • Incidents de sécurité.[1][2]
  • Temps de migration vers une alternative.[1][2]

Vérifier les textes et la version du produit

Les règles, modèles, tarifs et interfaces évoluent. Les sources officielles ci-dessous doivent être relues au moment de la décision, avec les contrats et paramètres du compte réellement utilisé.[1][2]

Questions fréquentes

Poids ouverts signifie-t-il open source ?

Pas forcément. Il faut examiner la licence, le code, les données et les droits de modification.

Un modèle hébergé en Europe envoie-t-il des données en Chine ?

Pas par nature. Vérifiez l’architecture, l’opérateur, les dépendances et la télémétrie du déploiement réel.[1][2]

Est-il automatiquement compatible RGPD ?

Non. La conformité dépend du traitement, des rôles, de la base, des transferts, des droits et des mesures.[1][2]

L’auto-hébergement coûte-t-il moins cher ?

Pas toujours. Incluez infrastructure, ingénierie, disponibilité, sécurité et mises à jour.[1][2]

Peut-on se fier aux benchmarks ?

Utilisez-les pour présélectionner, puis testez les cas, langues et erreurs propres à votre activité.

Quand renoncer ?

Lorsque licence, provenance, sécurité, qualité ou capacité d’exploitation ne respectent pas vos seuils.[1][2]

Sources

  1. General-purpose AI models in the AI Act — Commission européenne. Consulté le . ↩1↩2↩3↩4↩5↩6↩7↩8↩9↩10↩11↩12↩13↩14↩15↩16↩17↩18↩19↩20↩21↩22↩23↩24↩25↩26↩27↩28↩29↩30↩31↩32↩33↩34↩35↩36↩37↩38↩39↩40↩41↩42↩43↩44↩45↩46↩47↩48↩49↩50↩51↩52↩53↩54↩55↩56↩57↩58↩59
  2. Intelligence artificielle — CNIL. Consulté le . ↩1↩2↩3↩4↩5↩6↩7↩8↩9↩10↩11↩12↩13↩14↩15↩16↩17↩18↩19↩20↩21↩22↩23↩24↩25↩26↩27↩28↩29↩30↩31↩32↩33↩34↩35↩36↩37↩38↩39↩40↩41↩42↩43↩44↩45↩46↩47↩48↩49↩50↩51↩52↩53↩54↩55↩56↩57↩58↩59

Poursuivre votre lecture