Comment déployer des modèles d'IA

Comment déployer des modèles d'IA

En résumé : déployer un modèle d’IA implique de choisir un mode de diffusion (temps réel, traitement par lots, streaming ou périphérie), puis de rendre l’ensemble du processus reproductible, observable, sécurisé et réversible. En versionnant systématiquement l’ensemble du système et en mesurant la latence p95/p99 sur des charges utiles similaires à celles de la production, vous évitez la plupart des échecs liés aux tests réalisés sur un ordinateur personnel.

Points clés à retenir :

Modèles de déploiement : choisissez le mode temps réel, par lots, en flux continu ou en périphérie avant de vous engager sur les outils.

Reproductibilité : Versionnez le modèle, les fonctionnalités, le code et l'environnement pour éviter toute dérive.

Observabilité : Surveiller en continu les latences, les erreurs, la saturation et les distributions des données ou des sorties.

Déploiements sécurisés : utilisez des tests canary, bleu-vert ou shadow avec des seuils de retour en arrière automatiques.

Sécurité et confidentialité : Appliquer l’authentification, les limites de débit et la gestion des secrets, et minimiser les informations personnelles identifiables dans les journaux.

Comment déployer des modèles d'IA ? Infographie

Articles que vous pourriez aimer lire après celui-ci : 

🔗 Comment mesurer les performances de l'IA
Apprenez-en davantage sur les indicateurs, les points de référence et les vérifications concrètes pour obtenir des résultats fiables en matière d'IA.

🔗 Comment automatiser les tâches grâce à l'IA
Transformez les tâches répétitives en flux de travail grâce à des invites, des outils et des intégrations.

🔗 Comment tester les modèles d'IA
Conception d'évaluations, d'ensembles de données et de systèmes de notation pour comparer objectivement les modèles.

🔗 Comment parler à l'IA
Posez de meilleures questions, contextualisez et obtenez plus rapidement des réponses plus claires.

1) Ce que signifie réellement le terme « déploiement » (et pourquoi il ne s'agit pas simplement d'une API) 🧩

Quand on dit « déployer le modèle », cela peut faire référence à n'importe lequel des éléments suivants :

Le déploiement consiste donc moins à « rendre le modèle accessible » et davantage à :

  • packaging + diffusion + mise à l'échelle + surveillance + gouvernance + restauration ( Déploiement bleu-vert )

C'est un peu comme ouvrir un restaurant. Bien sûr, préparer un bon plat est important. Mais il faut aussi un bâtiment, du personnel, un réfrigérateur, des menus, une chaîne d'approvisionnement et un moyen de gérer le coup de feu du soir sans se retrouver à pleurer devant le congélateur. Ce n'est pas une métaphore parfaite… mais vous voyez l'idée. 🍝

2) Qu'est-ce qui fait une bonne version de « Comment déployer des modèles d'IA » ? ✅

Un déploiement réussi est d'une simplicité exemplaire. Il se comporte de manière prévisible sous pression, et lorsqu'il y a un problème, le diagnostic est rapide.

Voici à quoi ressemble généralement ce qui est « bien » :

  • Des builds reproductibles :
    même code + mêmes dépendances = même comportement. Pas de doutes du genre « ça marche sur mon portable » 👻 ( Docker : Qu’est-ce qu’un conteneur ? )

  • Contrat d'interface clair :
    entrées, sorties, schémas et cas limites sont définis. Pas de surprises à 2 h du matin. ( OpenAPI : Qu'est-ce qu'OpenAPI ? , Schéma JSON )

  • Des performances à la hauteur de la réalité :
    latence et débit mesurés sur du matériel similaire à celui utilisé en production et avec des charges utiles réalistes.

  • Une surveillance efficace :
    des indicateurs, des journaux, des traces et des contrôles de dérive qui déclenchent des actions (et non de simples tableaux de bord que personne ne consulte). ( Livre SRE : Surveillance des systèmes distribués )

  • Stratégie de déploiement sécurisée
    (Canary ou bleu-vert), restauration facile, gestion des versions sans aléas. ( Lancement Canary , Déploiement bleu-vert )

  • de la facture
    est une bonne chose, jusqu'à ce qu'elle ressemble à un numéro de téléphone 📞💸

  • Sécurité et confidentialité intégrées à
    la gestion des secrets, au contrôle d'accès, au traitement des informations personnelles identifiables et à l'auditabilité. ( Secrets Kubernetes , NIST SP 800-122 )

Si vous parvenez à le faire régulièrement, vous avez déjà une longueur d'avance sur la plupart des équipes. Soyons honnêtes.

3) Choisissez le bon modèle de déploiement (avant de choisir les outils) 🧠

Inférence API en temps réel ⚡

Idéal lorsque :

  • Les utilisateurs ont besoin de résultats instantanés (recommandations, vérifications de fraude, chat, personnalisation)

  • Les décisions doivent être prises lors d'une demande

Attention :

Notation par lots 📦

Idéal lorsque :

  • Les prédictions peuvent être différées (évaluation des risques pendant la nuit, prédiction du taux de désabonnement, enrichissement ETL) ( Amazon SageMaker Batch Transform ).

  • Vous recherchez une rentabilité accrue et des opérations simplifiées

Attention :

  • fraîcheur des données et remplissage des données

  • conserver la logique des fonctionnalités cohérente avec l'entraînement

Inférence en flux continu 🌊

Idéal lorsque :

  • Vous traitez les événements en continu (IoT, flux de clics, systèmes de surveillance)

  • Vous souhaitez des décisions quasi instantanées sans une stricte relation requête-réponse

Attention :

Déploiement en périphérie 📱

Idéal lorsque :

Attention :

Choisissez d'abord le motif, puis la pile. Sinon, vous risquez de forcer un modèle carré à s'exécuter dans un environnement rond. Ou quelque chose comme ça. 😬

4) Emballage du modèle pour qu'il résiste au contact avec la production 📦🧯

C’est là que la plupart des « déploiements faciles » s’éteignent discrètement.

Versionnez tout (oui, tout)

  • Artefact du modèle (poids, graphe, tokenizer, cartes d'étiquettes)

  • Logique des fonctionnalités (transformations, normalisation, encodeurs)

  • Code d'inférence (pré/post-traitement)

  • Environnement (Python, CUDA, bibliothèques système)

Une approche simple qui fonctionne :

  • traiter le modèle comme un artefact de publication

  • stockez-le avec une étiquette de version

  • nécessite un fichier de métadonnées de type fiche de modèle : schéma, métriques, notes sur l’instantané des données d’entraînement, limitations connues ( Fiches de modèle pour la génération de rapports de modèle )

Les contenants sont utiles, mais ne les idolâtrez pas 🐳

Les conteneurs sont formidables car ils :

Mais vous devez tout de même gérer :

Standardiser l'interface

Définissez votre format d'entrée/sortie dès le début :

  • JSON pour plus de simplicité (plus lent, mais convivial) ( Schéma JSON )

  • Protobuf pour optimiser les performances ( Présentation de Protocol Buffers )

  • Charges utiles basées sur des fichiers pour les images/l'audio (plus les métadonnées)

Veuillez valider les données saisies. Les données non valides sont la principale cause des tickets d'incident du type « pourquoi la fonction renvoie-t-elle des réponses incohérentes ? ». ( OpenAPI : Qu'est-ce qu'OpenAPI ? , Schéma JSON )

5) Options de diffusion – de l’API simple aux serveurs de modèles complets 🧰

Il existe deux itinéraires courants :

Option A : Serveur d’application + code d’inférence (approche de type FastAPI) 🧪

Vous créez une API qui charge le modèle et renvoie les prédictions. ( FastAPI )

Avantages :

  • facile à personnaliser

  • idéal pour les modèles plus simples ou les produits en phase de démarrage

  • authentification, routage et intégration simples

Inconvénients :

  • vous êtes responsable du réglage des performances (traitement par lots, multithreading, utilisation du GPU)

  • Vous allez réinventer la roue, peut-être mal au début

Option B : Serveur modèle (approche de type TorchServe / Triton) 🏎️

Serveurs spécialisés qui gèrent :

Avantages :

  • des performances améliorées dès la sortie de la boîte

  • Séparation plus claire entre la logique de service et la logique métier

Inconvénients :

  • complexité opérationnelle supplémentaire

  • La configuration peut sembler… fastidieuse, comme le réglage de la température d'une douche

Un motif hybride est très courant :

6) Tableau comparatif - méthodes de déploiement populaires (en toute franchise) 📊😌

Vous trouverez ci-dessous un aperçu pratique des options réellement utilisées pour déterminer comment déployer des modèles d'IA .

Outil / Approche Public Prix Pourquoi ça marche
Docker + FastAPI (ou similaire) Petites équipes, startups Gratuit Simple, flexible, rapide à déployer – mais vous « ressentirez » chaque problème de mise à l'échelle ( Docker , FastAPI ).
Kubernetes (à faire soi-même) Équipes de plateforme Dépendant de l'infrastructure Contrôle et évolutivité… mais aussi beaucoup de boutons, dont certains sont maudits ( Kubernetes HPA ).
Plateforme de ML gérée (service de ML cloud) Les équipes qui souhaitent moins d'opérations Paiement à l'utilisation Flux de travail de déploiement intégrés, points d'ancrage de surveillance - parfois coûteux pour les points de terminaison toujours actifs ( déploiement de Vertex AI , inférence en temps réel de SageMaker )
Fonctions sans serveur (pour l'inférence légère) Applications événementielles Paiement à l'utilisation Idéal pour les pics de trafic, mais les démarrages à froid et la taille du modèle peuvent vous gâcher la journée 😬 ( Démarrages à froid AWS Lambda )
Serveur d'inférence NVIDIA Triton équipes axées sur la performance Logiciels gratuits, coût d'infrastructure Excellente utilisation du GPU, traitement par lots, multi-modèles - la configuration demande de la patience ( Triton : traitement par lots dynamique ).
TorchServe Équipes fortement axées sur PyTorch Logiciel libre Modèles de service par défaut corrects ; peuvent nécessiter un réglage pour une utilisation à grande échelle ( documentation TorchServe ).
BentoML (emballage + service) ingénieurs en apprentissage automatique Service de base gratuit, options supplémentaires variables Packaging soigné, expérience développeur agréable – il vous faut encore des options d'infrastructure ( packaging BentoML pour le déploiement ).
Ray Serve Les spécialistes des systèmes distribués Dépendant de l'infrastructure Évolutivité horizontale, idéal pour les pipelines – donne une impression de « gros gabarit » pour les petits projets ( Documentation Ray Serve )

Note : « Presque gratuit » est une expression courante. Parce que rien n'est jamais vraiment gratuit. Il y a toujours un prix à payer, même si c'est votre sommeil. 😴

7) Performance et mise à l'échelle - latence, débit et vérité 🏁

L'optimisation des performances est un art qui se révèle dans le déploiement. L'objectif n'est pas la rapidité, mais une vitesse suffisamment élevée et constante .

Indicateurs clés qui comptent

Leviers courants à actionner

  • Le regroupement
    des requêtes permet d'optimiser l'utilisation du GPU. Idéal pour le débit, mais peut nuire à la latence en cas d'utilisation excessive. ( Triton : Regroupement dynamique )

  • La quantification
    à faible précision (comme INT8) peut accélérer l'inférence et réduire la mémoire. Elle peut légèrement dégrader la précision. Parfois, étonnamment, non. ( Quantification post-entraînement )

  • Compilation/optimisation :
    export ONNX, optimiseurs de graphes, flux de type TensorRT. Puissant, mais le débogage peut s'avérer complexe 🌶️ ( ONNX , optimisations de modèles d'exécution ONNX )

  • Mise en cache :
    Si les entrées se répètent (ou si vous pouvez mettre en cache les embeddings), vous pouvez réaliser d'importantes économies.

  • autoscaling
    s'adapte à l'utilisation du processeur/GPU, à la profondeur de la file d'attente ou au débit de requêtes. La profondeur de la file d'attente est sous-estimée. ( Kubernetes HPA )

Un conseil aussi étrange que vrai : effectuez vos mesures avec des charges utiles de taille similaire à celles utilisées en production. Les petites charges utiles de test sont trompeuses. Elles semblent polies au premier abord, mais vous trahiront plus tard.

8) Surveillance et observabilité - ne volez pas à l'aveugle 👀📈

La surveillance des modèles ne se limite pas à la surveillance de leur disponibilité. Vous souhaitez savoir si :

Éléments à surveiller (ensemble minimal viable)

Service de santé

Comportement du modèle

  • distributions des caractéristiques d'entrée (statistiques de base)

  • normes d'intégration (pour les modèles d'intégration)

  • distributions des résultats (confiance, répartition des classes, plages de scores)

  • Détection d'anomalies sur les entrées (données erronées en entrée, données erronées en sortie)

Dérive des données et dérive des concepts

Consigner les données, mais pas dans l'optique de « tout consigner indéfiniment » 🪵

Enregistrer:

Soyez vigilant quant à la protection de vos données personnelles. Vous ne voulez pas que vos journaux d'activité deviennent une source de fuites de données. ( NIST SP 800-122 )

9) Stratégies CI/CD et de déploiement : traitez les modèles comme de véritables versions 🧱🚦

Pour des déploiements fiables, mettez en place un pipeline. Même un pipeline simple.

Un flux solide

  • Tests unitaires pour le prétraitement et le post-traitement

  • Test d'intégration avec un ensemble de référence d'entrée-sortie connu

  • test de charge de référence (même léger)

  • Créer un artefact (conteneur + modèle) ( Meilleures pratiques de construction Docker )

  • Déploiement vers la zone de préparation

  • Lancement progressif auprès d'une petite partie du trafic ( Lancement progressif )

  • Augmenter progressivement l'intensité

  • Restauration automatique en fonction des seuils clés ( déploiement bleu-vert )

Des modèles de déploiement qui vous sauvent la vie

  • Canary : déploiement progressif auprès de 1 à 5 % du trafic ( Déploiement Canary )

  • bleu-vert : exécuter la nouvelle version en parallèle de l’ancienne, basculer de l’une à l’autre une fois prêt ( Déploiement bleu-vert )

  • Tests fantômes : envoyer du trafic réel à un nouveau modèle sans utiliser les résultats (idéal pour l’évaluation) ( Microsoft : Tests fantômes )

Et versionnez vos points de terminaison ou vos routes par version de modèle. Vous vous en féliciterez plus tard. Vous vous en féliciterez aussi aujourd'hui, mais en silence.

10) Sécurité, confidentialité et « merci de ne rien divulguer » 🔐🙃

La sécurité a tendance à arriver en retard, comme un invité surprise. Mieux vaut l'inviter tôt.

liste de contrôle pratique

  • Authentification et autorisation (qui peut appeler le modèle ?)

  • Limitation du débit (protection contre les abus et les surcharges accidentelles) ( limitation du débit de la passerelle API )

  • Gestion des secrets (aucune clé dans le code, ni dans les fichiers de configuration…) ( AWS Secrets Manager , Secrets Kubernetes )

  • Contrôles réseau (sous-réseaux privés, politiques de service à service)

  • Journaux d'audit (en particulier pour les prédictions sensibles)

  • Minimisation des données (ne stockez que ce qui est nécessaire) ( NIST SP 800-122 )

Si le modèle touche à des données personnelles :

  • occulter ou hacher les identifiants

  • éviter d'enregistrer les charges utiles brutes ( NIST SP 800-122 )

  • définir les règles de conservation

  • flux de données du document (ennuyeux, mais protecteur)

De plus, l'injection de prompts et l'utilisation abusive des résultats peuvent avoir des conséquences importantes pour les modèles génératifs. Voir aussi : ( OWASP Top 10 pour les applications LLM , OWASP : Injection de prompts )

  • règles de nettoyage des entrées

  • filtrage des sorties le cas échéant

  • garde-fous pour les appels d'outils ou les actions de base de données

Aucun système n'est parfait, mais on peut le rendre moins fragile.

11) Pièges courants (ou les pièges habituels) 🪤

Voici les classiques :

Si vous lisez ceci et que vous pensez « oui, nous en faisons deux », bienvenue au club. Le club propose des en-cas et un léger stress. 🍪

12) Conclusion - Comment déployer des modèles d'IA sans perdre la tête 😄✅

Le déploiement est l'étape où l'IA devient un produit concret. Ce n'est pas glamour, mais c'est là que la confiance se gagne.

Petit récapitulatif

Et oui, déployer des modèles d'IA peut donner l'impression de jongler avec des boules de bowling enflammées au début. Mais une fois le pipeline stabilisé, c'est étrangement satisfaisant. Un peu comme ranger enfin un tiroir encombré… sauf que le tiroir, c'est le trafic de production. 🔥🎳

FAQ

Que signifie déployer un modèle d'IA en production ?

Le déploiement d'un modèle d'IA implique généralement bien plus que la simple mise à disposition d'une API de prédiction. Concrètement, il comprend le packaging du modèle et de ses dépendances, le choix d'un mode de diffusion (temps réel, traitement par lots, streaming ou périphérie), la mise à l'échelle avec fiabilité, la surveillance de l'état et des dérives, ainsi que la mise en place de procédures de déploiement et de restauration sécurisées. Un déploiement robuste reste stable et prévisible sous charge et permet un diagnostic précis en cas de problème.

Comment choisir entre le déploiement en temps réel, par lots, en flux continu ou en périphérie ?

Choisissez le modèle de déploiement en fonction du moment où les prédictions sont nécessaires et des contraintes opérationnelles. Les API en temps réel conviennent aux expériences interactives où la latence est critique. Le traitement par lots est optimal lorsque les délais sont acceptables et que la rentabilité prime. Le streaming est adapté au traitement continu d'événements, notamment lorsque la sémantique de diffusion devient complexe. Le déploiement en périphérie est idéal pour un fonctionnement hors ligne, la confidentialité ou les exigences de très faible latence, bien que la gestion des mises à jour et des variations matérielles soit plus difficile.

Quelle version utiliser pour éviter les échecs de déploiement du type « fonctionne sur mon ordinateur portable » ?

Ne vous contentez pas de versionner les poids du modèle. En général, vous aurez besoin d'un artefact de modèle versionné (incluant les tokenizers ou les tables de correspondance d'étiquettes), de la logique de prétraitement et d'extraction de caractéristiques, du code d'inférence et de l'environnement d'exécution complet (Python/CUDA/bibliothèques système). Considérez le modèle comme un artefact de publication avec des versions étiquetées et des métadonnées légères décrivant les attentes du schéma, les notes d'évaluation et les limitations connues.

Faut-il déployer un service simple de type FastAPI ou un serveur de modèles dédié ?

Un serveur d'applications simple (de type FastAPI) convient parfaitement aux premiers produits ou aux modèles simples, car il permet de conserver le contrôle du routage, de l'authentification et de l'intégration. Un serveur de modèles (de type TorchServe ou NVIDIA Triton) offre des performances accrues en matière de traitement par lots, de concurrence et d'utilisation du GPU, prêtes à l'emploi. De nombreuses équipes optent pour une solution hybride : un serveur de modèles pour l'inférence et une API légère pour l'authentification, la gestion des requêtes et les limitations de débit.

Comment améliorer la latence et le débit sans compromettre la précision

Commencez par mesurer la latence p95/p99 sur du matériel similaire à celui de la production, avec des charges utiles réalistes, car les tests à petite échelle peuvent être trompeurs. Parmi les leviers courants, citons le traitement par lots (meilleur débit, mais latence potentiellement plus élevée), la quantification (plus petite et plus rapide, parfois avec de légers compromis sur la précision), les flux de compilation et d'optimisation (de type ONNX/TensorRT) et la mise en cache des entrées ou des plongements répétés. L'autoscaling basé sur la profondeur de la file d'attente peut également empêcher l'augmentation de la latence de queue.

Quel type de surveillance est nécessaire au-delà de la simple constatation que « le terminal est opérationnel » ?

La disponibilité ne suffit pas, car un service peut sembler fonctionner correctement alors que la qualité des prédictions se dégrade. Il est essentiel de surveiller au minimum le volume de requêtes, le taux d'erreur et la distribution des latences, ainsi que les indicateurs de saturation tels que l'utilisation du processeur, du GPU et de la mémoire, et le temps d'attente. Pour analyser le comportement du modèle, suivez la distribution des entrées et des sorties, ainsi que les signaux d'anomalie de base. Mettez en place des contrôles de dérive qui déclenchent des actions plutôt que des alertes intempestives, et consignez les identifiants de requête, les versions du modèle et les résultats de la validation du schéma.

Comment déployer en toute sécurité de nouvelles versions de modèles et rétablir rapidement le service ?

Considérez les maquettes comme des versions complètes, avec un pipeline CI/CD qui teste le prétraitement et le post-traitement, effectue des vérifications d'intégration sur un ensemble de référence et établit une charge de base. Pour les déploiements progressifs, les déploiements Canary augmentent le trafic graduellement, tandis que le modèle bleu-vert maintient une version antérieure en ligne pour un basculement immédiat. Les tests en arrière-plan permettent d'évaluer une nouvelle maquette sur un trafic réel sans impacter les utilisateurs. La restauration doit être une fonctionnalité essentielle, et non une solution de dernier recours.

Les pièges les plus courants lors de l'apprentissage du déploiement de modèles d'IA

Le déséquilibre entre l'entraînement et la production est un cas classique : le prétraitement diffère entre l'entraînement et la production, et les performances se dégradent insidieusement. Un autre problème fréquent est l'absence de validation du schéma, lorsqu'une modification en amont perturbe subtilement les entrées. Les équipes sous-estiment également la latence résiduelle et se concentrent trop sur les moyennes, négligent les coûts (les GPU inactifs s'accumulent rapidement) et omettent de planifier les restaurations. Se contenter de surveiller la disponibilité est particulièrement risqué, car un système « disponible mais dysfonctionnel » peut être pire qu'un système « hors service ».

Références

  1. Amazon Web Services (AWS) - Amazon SageMaker : Inférence en temps réel - docs.aws.amazon.com

  2. Amazon Web Services (AWS) - Transformation par lots Amazon SageMaker - docs.aws.amazon.com

  3. Amazon Web Services (AWS) - Amazon SageMaker Model Monitor - docs.aws.amazon.com

  4. Amazon Web Services (AWS) - Limitation du débit des requêtes API Gateway - docs.aws.amazon.com

  5. Amazon Web Services (AWS) - AWS Secrets Manager : Introduction - docs.aws.amazon.com

  6. Amazon Web Services (AWS) - Cycle de vie de l'environnement d'exécution AWS Lambda - docs.aws.amazon.com

  7. Google Cloud - Vertex AI : Déployer un modèle sur un point de terminaison - docs.cloud.google.com

  8. Google Cloud - Présentation de la surveillance des modèles d'IA Vertex - docs.cloud.google.com

  9. Google Cloud - Vertex AI : Surveiller l’asymétrie et la dérive des caractéristiques - docs.cloud.google.com

  10. Blog Google Cloud - Dataflow : modes de diffusion « une seule fois » et « au moins une fois » - cloud.google.com

  11. Google Cloud - Modes de diffusion Cloud Dataflow - docs.cloud.google.com

  12. Livre Google SRE - Surveillance des systèmes distribués - sre.google

  13. Recherche Google - La queue à grande échelle - research.google

  14. LiteRT (Google AI) - Présentation de LiteRT - ai.google.dev

  15. LiteRT (Google AI) – Inférence LiteRT sur l'appareil – ai.google.dev

  16. Docker - Qu'est-ce qu'un conteneur ? - docs.docker.com

  17. Docker - Bonnes pratiques de création d'images Docker - docs.docker.com

  18. Kubernetes - Les secrets de Kubernetes - kubernetes.io

  19. Kubernetes - Mise à l'échelle automatique horizontale des pods - kubernetes.io

  20. Martin Fowler - Canary Release - martinfowler.com

  21. Martin Fowler - Déploiement bleu-vert - martinfowler.com

  22. Initiative OpenAPI - Qu'est-ce qu'OpenAPI ? - openapis.org

  23. Schéma JSON - (site référencé) - json-schema.org

  24. Protocol Buffers - Présentation de Protocol Buffers - protobuf.dev

  25. FastAPI - (site référencé) - fastapi.tiangolo.com

  26. NVIDIA - Triton : Traitement par lots dynamique et exécution simultanée de modèles - docs.nvidia.com

  27. NVIDIA - Triton : Exécution simultanée de modèles - docs.nvidia.com

  28. Documentation du serveur d'inférence NVIDIA Triton - docs.nvidia.com

  29. PyTorch - TorchServe - docs.pytorch.org

  30. BentoML - Packaging pour le déploiement - docs.bentoml.com

  31. Ray - Ray Serve - docs.ray.io

  32. TensorFlow - Quantification post-entraînement (Optimisation du modèle TensorFlow) - tensorflow.org

  33. TensorFlow - Validation des données TensorFlow : détection du déséquilibre entre l’entraînement et le déploiement - tensorflow.org

  34. ONNX - (site référencé) - onnx.ai

  35. ONNX Runtime - Optimisations du modèle - onnxruntime.ai

  36. NIST (Institut national des normes et de la technologie) - NIST SP 800-122 - csrc.nist.gov

  37. arXiv - Fiches de modèles pour la présentation des modèles - arxiv.org

  38. Microsoft - Tests fantômes - microsoft.github.io

  39. OWASP - Top 10 OWASP pour les candidatures au LLM - owasp.org

  40. Projet de sécurité OWASP GenAI - OWASP : Injection d'invite - genai.owasp.org

Découvrez les dernières fonctionnalités d'IA sur la boutique officielle des assistants IA

À propos de nous

Retour au blog