Amazon et l’IA d’entreprise : répartition des modèles, responsabilités et support entre Bedrock, Nova, SageMaker et les services préintégrés

La bonne question : que signifie adopter une IA « d’Amazon » ?

Dire qu’une organisation va utiliser une IA « d’Amazon » résume excessivement une décision qui peut couvrir des produits différents. Cela peut vouloir dire invoquer un modèle de la famille Amazon Nova via une interface gérée ; accéder, depuis Amazon Bedrock, à un modèle développé par une autre entreprise ; personnaliser, entraîner ou déployer un modèle avec Amazon SageMaker AI ; ou activer une capacité d’IA intégrée à un autre service AWS. Chaque option modifie ce qui est contracté, ce qui est configuré, ce qui est enregistré et la partie à laquelle il revient d’examiner un changement ou un incident.

La marque de la plateforme ne supprime pas la nécessité d’identifier le modèle précis, sa version, la région, le compte AWS, le mode d’invocation et les conditions applicables. Dans Bedrock, de plus, un modèle tiers est traité contractuellement comme un contenu tiers. Le fait qu’un appel transite par une API AWS ne permet donc pas de conclure que les conditions d’utilisation, restrictions ou engagements du fournisseur du modèle sont identiques à ceux d’un modèle développé par Amazon.

Pour les achats technologiques, l’architecture et le risque, l’unité d’analyse utile n’est pas le nom du fournisseur cloud. Il s’agit d’une combinaison vérifiable : cas d’usage, service d’accès, modèle ou capacité exacts, configuration de sécurité, données traitées, région et responsable interne. Cet inventaire permet de distinguer les faits documentés des hypothèses relatives à la qualité, à la disponibilité future ou à la conformité réglementaire.

Cette distinction évite également deux erreurs fréquentes. La première consiste à assimiler un service géré à un transfert complet de l’exploitation : AWS peut exploiter l’infrastructure sous-jacente, tandis que le client conserve les décisions relatives aux identités, autorisations, classifications de données, destinations des journaux et configurations de protection. La seconde consiste à supposer qu’un catalogue de modèles constitue une recommandation technique ou juridique pour un cas particulier. La disponibilité est une condition d’accès ; elle ne démontre pas, à elle seule, la performance, l’adéquation, la résidence des données ou l’acceptabilité contractuelle.

Cartographie des couches : Nova, Bedrock, SageMaker AI et capacités intégrées

Amazon Nova désigne une famille de modèles d’Amazon. La fiche de service d’Amazon Nova 2 Lite situe son utilisation dans Amazon Bedrock et décrit les contrôles et limites du modèle du point de vue de l’IA responsable. Cette origine importe : lorsqu’un modèle Nova est invoqué par Bedrock, l’équipe doit évaluer à la fois les conditions et contrôles de Bedrock et la documentation spécifique au modèle retenu.

Amazon Bedrock est une couche de service permettant de travailler avec des modèles de fondation au moyen d’interfaces gérées. Son catalogue peut inclure des modèles Amazon et des modèles tiers. Il ne transforme pas tous ces modèles en produits développés par Amazon et n’uniformise pas automatiquement les obligations associées à chaque fournisseur. La documentation contractuelle d’AWS indique explicitement que les modèles tiers dans Bedrock constituent du contenu tiers et renvoie à des conditions additionnelles spécifiques.

Amazon SageMaker AI relève d’une autre catégorie de décision. Sa documentation de protection des données applique le modèle de responsabilité partagée : AWS protège l’infrastructure qui exploite le service, et le client conserve des responsabilités de configuration, de données, d’identités et d’utilisation sûre des ressources qu’il déploie. Dans une architecture utilisant SageMaker AI, le client peut disposer de davantage de contrôle sur le cycle opérationnel d’entraînement, de personnalisation ou d’endpoint, mais ce contrôle accroît le périmètre des décisions qu’il doit gouverner.

Enfin, certains services AWS contiennent des fonctions d’IA consommées dans le cadre du service lui-même. Elles ne doivent pas être assimilées automatiquement à une invocation directe d’un modèle dans Bedrock ni à un endpoint administré par le client dans SageMaker AI. L’évaluation doit commencer par la documentation du service concerné : quelles données la fonction accepte, où elle est traitée, quels journaux elle expose et quelles configurations de sécurité elle prend en charge.

Canaux d’accès et contrôle opérationnel

Une API gérée réduit le besoin d’exploiter une infrastructure d’inférence, mais elle ne supprime pas les décisions applicatives. Dans Bedrock, le client choisit toujours le modèle activé, la configuration des requêtes, les identités autorisées à l’invoquer et les mécanismes d’observabilité. Lorsque le modèle est tiers, il doit en outre intégrer au dossier d’approbation les conditions applicables à ce tiers. Cet examen n’est pas seulement administratif : il peut influer sur les usages autorisés, les restrictions et les obligations de conformité.

La personnalisation ou le déploiement d’un endpoint propre dans SageMaker AI déplacent le centre de gravité opérationnel. L’organisation obtient un cadre lui permettant de contrôler davantage d’éléments de la charge, mais elle doit concevoir et maintenir la configuration d’accès, de réseau, de chiffrement, de supervision et de cycle de vie correspondant à son architecture. La responsabilité partagée n’équivaut pas à une liste fixe de contrôles ; elle dépend des ressources et options effectivement employées.

Les fonctions d’IA préintégrées offrent un niveau d’abstraction encore plus élevé, mais une abstraction supérieure n’est pas synonyme de risque moindre. L’équipe doit vérifier quelles entrées sont générées par le service, quelles sorties sont ensuite consommées par un autre système, quelles autorisations permettent les actions et s’il existe un journal utile pour examiner les résultats. Une même tâche métier — par exemple, extraire des informations de documents — peut avoir des profils opérationnels différents selon qu’elle est traitée par une fonction intégrée, un flux Bedrock ou un endpoint SageMaker AI.

Le choix ne doit pas reposer uniquement sur la rapidité d’intégration. Il doit également prendre en compte la réversibilité. Une équipe doit savoir comment remplacer un modèle, comment tester un substitut, de quelle API ou de quel format d’entrée elle dépend et qui approuvera les changements. Cette question est particulièrement importante lorsque le résultat alimente des décisions, des communications externes ou des actions automatisées.

Responsabilité partagée appliquée aux données, prompts et actions

La documentation de protection des données de Bedrock présente le modèle de responsabilité partagée et décrit des mesures telles que le chiffrement, l’utilisation de TLS, l’intégration avec AWS CloudTrail et des options de connectivité privée via VPC et AWS PrivateLink. Ces capacités constituent des preuves de contrôles disponibles ou fournis par le service ; elles ne prouvent pas qu’ils sont activés ni qu’une mise en œuvre particulière est adaptée à une donnée ou à une réglementation donnée.

Cette même documentation distingue l’exploitation de Bedrock de celle des fournisseurs de modèles. Une revue sérieuse sépare donc trois niveaux : les responsabilités d’AWS en tant qu’opérateur du service, les conditions et restrictions du fournisseur lorsqu’un modèle tiers est utilisé, et les obligations du client qui conçoit le flux. Parmi ces dernières figurent habituellement l’attribution des autorisations, la sélection des données envoyées, la définition de la rétention dans les destinations choisies pour les journaux et la supervision des systèmes agissant sur une sortie.

La fiche d’Amazon Nova 2 Lite indique qu’AWS n’utilise pas les données d’entrée ni de sortie traitées via Bedrock pour entraîner les modèles Bedrock, y compris Nova 2 Lite. Cette déclaration est importante pour le traitement décrit par AWS, mais elle ne doit pas être étendue sans vérification à tous les produits, configurations, fournisseurs ou destinations auxiliaires d’une architecture. Par exemple, les journaux activés par le client constituent un autre flux de données et nécessitent une décision propre sur le stockage et l’accès.

Lorsqu’une application utilise la réponse d’un modèle pour exécuter des actions externes, la responsabilité s’étend à la conception des autorisations. Le modèle ne doit pas être considéré comme une autorité d’accès. L’application doit vérifier les droits, limiter les opérations autorisées, traiter les instructions reçues comme des données non fiables et conserver suffisamment d’éléments pour enquêter sur une action. Ce sont des mesures de conception recommandables ; les sources fournies ne permettent pas d’affirmer qu’une configuration donnée les applique par défaut.

Cycle de vie, régions, quotas et remplacement

Le cycle de vie d’un modèle est une exigence opérationnelle, et non une simple note de catalogue. La documentation de Bedrock définit les états Active, Legacy et End-of-Life, et expose le champ modelLifecycle pour consulter l’état. Un modèle peut rester visible pendant une transition sans que cela implique qu’il doive être choisi pour une nouvelle mise en œuvre. Les équipes doivent détecter ces états dans leur inventaire et les relier aux flux de production dépendant du modèle.

La documentation du cycle de vie décrit les notifications et processus associés au retrait ou au remplacement. Toutefois, un plan interne ne devrait pas dépendre du fait qu’une notification suffise pour réagir. Il doit exister une procédure permettant de localiser les appels affectés, d’essayer une alternative, de comparer les résultats et de mettre à jour les configurations applicatives. Pour les usages à fort impact, ce remplacement requiert également une nouvelle évaluation des risques et des contrôles, et pas seulement un test de connectivité.

La région fait également partie de la décision. La configuration des journaux d’invocation de Bedrock est gérée par compte et par région. Les disponibilités de modèles, les quotas et les modalités d’accès peuvent aussi varier ; il n’est donc pas sûr de les déduire d’une autre région ou d’une expérience dans la console. Avant la mise en production, l’organisation doit vérifier la disponibilité en vigueur dans la région cible et documenter la preuve de cette vérification.

Les quotas déterminent la capacité réelle d’une conception, mais ils ne doivent pas être confondus avec des engagements de performance pour un cas métier. Le dossier technique doit enregistrer les limites pertinentes, la stratégie face aux erreurs ou à la limitation de débit, ainsi que le comportement sûr à adopter lorsque le modèle ou le service ne répond pas. Les sources fournies justifient la nécessité de vérifier ces variables, mais elles ne permettent pas d’établir des valeurs universelles de quota ou de disponibilité pour tous les modèles.

Sécurité publiée, contrôles configurables et traçabilité

Bedrock permet de configurer la journalisation des invocations dans Amazon CloudWatch Logs et Amazon S3. La documentation indique que cette journalisation est désactivée par défaut et que sa configuration est propre au compte et à la région. Elle décrit également qu’elle peut inclure des informations sur les entrées et sorties, le modèle, l’identité, l’opération, la région et les erreurs. Sa valeur pour l’audit dépendra de son activation par l’organisation, de la définition de destinations appropriées et du contrôle des personnes pouvant y accéder.

Cette fonctionnalité introduit une tension opérationnelle qui doit être résolue explicitement. Enregistrer davantage de contexte facilite l’enquête sur les incidents, la reproduction des résultats et l’attribution des appels ; mais les prompts et réponses peuvent contenir des données sensibles ou des informations d’entreprise. La décision doit relier la politique de journalisation à la classification des données, aux contrôles d’accès, au chiffrement, à la rétention et aux procédures de suppression applicables dans l’organisation. Il ne suffit pas d’affirmer que la journalisation est disponible.

CloudTrail, les options de réseau privé et les mécanismes de chiffrement décrits pour Bedrock peuvent faire partie d’une architecture défendable, mais leur efficacité dépend de la configuration et du périmètre du flux. De même, la documentation de SageMaker AI attribue au client des responsabilités de sécurité dans le cloud. L’approbation d’un cas d’usage doit demander des preuves de configuration, et ne pas se limiter à une liste de fonctionnalités du produit.

Il faut également distinguer les preuves techniques des preuves contractuelles. Les conditions de service peuvent définir des restrictions concernant des modèles tiers et des mesures automatisées de détection des abus, tandis que la documentation technique explique les comportements et options du service. Ni les unes ni les autres ne remplacent l’évaluation d’exigences réglementaires particulières, laquelle peut nécessiter une revue indépendante juridique, de confidentialité et de sécurité.

Matrice de décision selon le cas d’usage

Il n’existe pas de correspondance automatique entre un cas métier et un service. La matrice suivante ne recommande pas un produit précis : elle identifie les questions à résoudre avant le choix. Le résultat peut être une API gérée, une conception fondée sur SageMaker AI, une capacité intégrée ou la conclusion qu’il n’existe pas encore de preuves suffisantes pour la production.

Dans un prototype utilisant des données non sensibles, la rapidité d’accès peut être prioritaire, mais une frontière claire avec les données réelles et un examen des conditions applicables doivent être maintenus. Dans un système RAG d’entreprise, la question déterminante porte souvent sur le contrôle des sources documentaires, les autorisations de récupération, les journaux et le traitement des résultats. Pour l’automatisation avec des actions, l’attention se déplace vers l’autorisation, la validation et la traçabilité de chaque opération externe.

Une exigence de résidence, d’audit ou de rétention ne doit pas être satisfaite par une supposition fondée sur le nom du service. Il faut vérifier la région, la configuration des journaux, les destinations de données, le modèle sélectionné et les conditions applicables. Si l’un de ces éléments de preuve n’est pas disponible, la décision prudente consiste à classer l’exigence comme en attente, et non comme satisfaite.

Liste de vérification avant le déploiement

L’approbation de production doit produire un dossier lisible pour les équipes techniques et de contrôle. Son objectif n’est pas de démontrer que toute incertitude a disparu, mais de rendre clair ce qui a été vérifié, ce qui dépend d’une configuration et ce qui reste en attente. La liste doit être revue lorsque le modèle, son état de cycle de vie, la région, le fournisseur, les données ou les actions activées changent.

Commencez par identifier le contrat d’accès : service AWS, modèle, fournisseur du modèle s’il ne s’agit pas d’Amazon, et conditions additionnelles. Documentez ensuite le périmètre technique : compte, région, modalité d’invocation ou endpoint, identités, autorisations et limites. Troisièmement, décrivez séparément les flux de données : entrée, contexte récupéré, sortie, journaux et stockage ultérieur.

Testez ensuite les contrôles. Confirmez que les journaux, lorsqu’ils sont nécessaires, sont activés dans le compte et la région pertinents et que leurs destinations disposent de l’accès et de la rétention prévus. Vérifiez les autorisations d’invocation, les chemins réseau choisis et le traitement des erreurs. Si le flux exécute des actions, testez les défaillances, les réponses inattendues et les refus d’autorisation.

Enfin, définissez un plan de remplacement. Il doit indiquer comment un changement de cycle de vie sera détecté, quelle alternative sera évaluée, quel critère permettra de l’approuver et qui est responsable de la migration. Cette planification ne garantit pas qu’un modèle alternatif produise des résultats équivalents ; c’est précisément pourquoi elle exige des essais et une décision explicite.

Ce que le catalogue ne permet pas de conclure

Le catalogue Bedrock et l’existence de modèles Amazon Nova ne permettent pas de conclure qu’un modèle est adapté à une tâche donnée. La documentation relative à la disponibilité, au cycle de vie ou aux contrôles décrit des capacités et des états, mais la qualité dépend du cas d’usage, des données, de la conception des prompts, des évaluations et des critères d’acceptation définis par le client. La validation doit être réalisée à l’aide de tests représentatifs et avec une attention particulière aux éventuelles erreurs de sortie.

Ils ne permettent pas non plus de conclure qu’un modèle hébergé transfère toute la responsabilité à AWS ou au fournisseur du modèle. La documentation de Bedrock et de SageMaker AI maintient un rôle clair pour le client dans la configuration et la protection de son environnement. Les conditions des modèles tiers ajoutent une couche supplémentaire qui ne doit pas disparaître de l’examen du seul fait que l’accès technique est centralisé.

Enfin, contrôler davantage d’infrastructure ne revient pas à démontrer davantage de sécurité. Un endpoint et ses ressources peuvent offrir des options de conception supplémentaires, mais ils exigent aussi des configurations et des preuves supplémentaires. À l’inverse, une API gérée peut réduire les tâches d’infrastructure sans résoudre, à elle seule, la gouvernance des données, le contrôle d’accès, l’évaluation des résultats ou l’autorisation des actions.

La conclusion opérationnelle est volontairement limitée : AWS propose plusieurs couches pour adopter l’IA, et les sources examinées permettent de distinguer certaines responsabilités, certains contrôles et mécanismes de cycle de vie. Elles ne permettent pas de certifier la conformité d’un cas d’usage précis, d’anticiper la disponibilité future d’un modèle ou de déclarer une équivalence fonctionnelle entre des alternatives. Ces conclusions exigent une vérification actualisée et des preuves issues du déploiement réel.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.