Stockage cloud, bases de données et services de données

Un service de stockage doit convenir à la manière dont une application lit et modifie les données. Une base de données qui met à jour quelques enregistrements, une équipe qui modifie des documents partagés et un site web qui diffuse des photos ont des besoins différents.

Trois façons d’organiser les données

Un volume en mode bloc contient des blocs de taille fixe. Le système d’exploitation le formate avec un système de fichiers, comme il le ferait pour un disque physique. Il peut mettre à jour une petite partie d’un fichier sur place. Cela convient à une base de données qui effectue de nombreuses petites lectures et écritures. Un volume sert normalement une seule machine virtuelle ; son partage direct nécessite un disque compatible et un logiciel conçu pour les accès en cluster.

Le stockage en mode fichier fournit un dossier partagé sur un réseau. NFS est courant sous Linux ; SMB est courant sous Windows. Plusieurs clients peuvent ouvrir le même partage et le verrouillage des fichiers coordonne les accès. Une application existante qui utilise un chemin partagé peut conserver ce mode de fonctionnement sans être réécrite pour appeler une API objet.

Ce que contient un objet

Un objet contient ses données, une clé unique et des métadonnées, comme son type de contenu. Dans un compartiment à espace de noms plat, invoices/2026/10/inv-1042.pdf est une seule clé complète. Les barres obliques regroupent les noms par préfixe ; elles ne créent pas de dossiers ordinaires sur un disque.

Les applications chargent généralement les objets avec des requêtes PUT et les téléchargent avec des requêtes GET via HTTPS. L’accès général aux objets traite les données comme un objet : remplacer son contenu signifie généralement charger un objet de remplacement, tandis qu’un disque en mode bloc permet de petites écritures sur place. Certains services d’objets ajoutent des fonctions spécialisées d’ajout ou de répertoires. Un compartiment conserve un modèle d’accès différent de celui d’un serveur de fichiers partagé.

Le stockage en mode objet peut conserver des images, des enregistrements, des journaux et des sauvegardes dans une collection qui grandit sans qu’il faille provisionner un disque à chaque augmentation. Les classes standard en ligne servent les sites web actifs et l’analyse avec un accès en quelques millisecondes. Les délais de récupération concernent certaines classes d’archivage, et non le stockage en mode objet dans son ensemble.

Choisir le stockage d’une application

Une boutique en ligne utilise un disque en mode bloc pour son serveur de base de données, car les enregistrements changent fréquemment. Cinq serveurs web lisent des modèles de pages communs depuis un partage de fichiers NFS. Les photos des produits et 2 To de sauvegardes nocturnes sont placés dans un stockage en mode objet. La même application peut utiliser les trois types.

Le stockage temporaire de l’hôte, comme AWS instance store, Azure temporary disk et Google Cloud Local SSD, convient aux fichiers temporaires et aux caches qui peuvent être recréés. Une panne de l’hôte ou des événements du cycle de vie de la machine virtuelle peuvent l’effacer. Si tu ne conserves qu’une copie des données importantes, place-la sur un stockage persistant, qui existe indépendamment d’une machine virtuelle en fonctionnement.

La tarification suit le modèle de stockage. Le stockage en mode objet facture généralement les Go réellement stockés, ainsi que les requêtes et les transferts. Le stockage en mode bloc facture la capacité provisionnée, y compris l’espace inutilisé. Le stockage en mode fichier peut facturer l’espace utilisé, comme EFS, ou la capacité réservée. Commence par choisir selon le mode d’accès, puis compare la facture correspondant à ce mode.

Le stockage en mode objet sépare les données du serveur qui les utilise. Un compartiment ou un conteneur contient la collection, tandis que chaque objet possède sa propre clé. Les paramètres d’emplacement, d’accès et de restauration déterminent dans quelle mesure cette collection peut être utilisée en sécurité.

Associer les noms des fournisseurs

Un compte de stockage Azure peut aussi contenir des partages de fichiers, des files d’attente et des tables. Les noms des compartiments S3 à usage général, des compartiments Cloud Storage et des comptes de stockage Azure utilisent des espaces de noms partagés : un nom utilisé par un autre client peut donc être indisponible. Le nom fait aussi partie de l’adresse de l’objet. Par exemple, un blob Azure peut avoir l’adresse https://shopmedia.blob.core.windows.net/images/products/lamp-01.jpg.

Un compartiment S3 appartient à une région AWS. Les comptes de stockage Azure sont associés à une région et à un choix de redondance. Cloud Storage propose des emplacements régionaux, birégionaux et multirégionaux. L’emplacement influe sur la latence, le prix et la résidence des données, c’est-à-dire la zone où les données sont conservées.

Partager sans exposer la collection

Garde la collection privée et accorde les accès nécessaires à l’application par des permissions d’identité et des politiques de ressources. Pour un téléchargement temporaire, utilise une URL présignée S3, une signature d’accès partagé (SAS) Azure ou une URL signée Cloud Storage. Un lien vers une facture qui expire après 60 minutes donne un accès temporaire sans rendre public tout le compartiment. Toute personne qui possède un lien signé utilisable peut exercer les permissions associées pendant cette période.

Les objets stockés sont chiffrés par défaut avec des clés gérées par le fournisseur ; les clés gérées par le client donnent à celui-ci davantage de contrôle. HTTPS protège les données pendant leur transfert. Le chiffrement et les permissions répondent à des problèmes différents : une personne disposant d’une permission de lecture valide peut toujours lire un objet chiffré par l’intermédiaire du service.

Restaurer, conserver et charger

La gestion des versions conserve les versions antérieures d’un objet afin de pouvoir annuler un écrasement. Les versions stockées augmentent la facture. Azure et Google Cloud proposent aussi la suppression réversible, qui conserve les données supprimées pendant une période de récupération. Le stockage immuable, ou écriture unique et lectures multiples (WORM), bloque les modifications et la suppression pendant la durée de conservation. S3 Object Lock, le stockage immuable des blobs Azure et les politiques de conservation Cloud Storage avec verrouillage du compartiment en sont des exemples.

Les chargements volumineux peuvent être découpés en parties, envoyés en parallèle et relancés séparément. S3 appelle cela le chargement partitionné ; les chargements par blocs d’Azure et les chargements composites de Google proposent des approches similaires. Une interruption de connexion n’oblige pas à recommencer tout le transfert volumineux.

Dimensionner une collection croissante

Un million de photos d’une taille moyenne de 3 Mo occupent 3 000 000 Mo, soit 3 000 Go : 3 To en unités décimales. Avec 20 000 photos supplémentaires par jour, la collection augmente de 60 Go par jour. Sur 365 jours, cela représente 21,9 To supplémentaires. Le stockage en mode objet permet cette croissance sans réserver à l’avance un disque de taille fixe.

Dans les espaces de noms plats, déplacer un préfixe qui ressemble à un dossier implique de modifier les clés des objets. Les options hiérarchiques ajoutent de véritables opérations sur les répertoires, notamment Azure Data Lake Storage et l’espace de noms hiérarchique de Cloud Storage. Vérifie l’espace de noms avant de considérer un dossier affiché comme un répertoire.

Après avoir choisi un type de stockage, associe sa méthode d’accès et ses performances à un service. Un disque haute performance et un dossier partagé peuvent tous deux stocker des fichiers, mais ils répondent à des besoins différents des applications.

Disques et copies

Les types de disques offrent des performances différentes. Les volumes sur disques durs conviennent aux grandes lectures séquentielles ; les SSD conviennent aux petites opérations fréquentes. IOPS désigne les opérations d’entrée-sortie par seconde. Choisis à la fois la capacité et les performances, car un grand disque n’est pas nécessairement adapté à une base de données très sollicitée.

Un volume EBS appartient à une zone de disponibilité et s’attache aux instances de cette zone. Les disques managés Azure sont localement redondants par défaut, avec une option de redondance interzone. Google propose des disques zonaux et des disques régionaux répliqués sur deux zones. Ces choix d’emplacement déterminent les pannes auxquelles un disque peut résister.

Un instantané capture un volume à un instant donné. Les instantanés standard EBS et Google sont incrémentiels : après la première copie, les instantanés suivants stockent les blocs modifiés. Azure propose des instantanés complets et incrémentiels. Si un volume contient 200 Go et que 5 Go changent, un instantané incrémentiel stocke environ 5 Go de nouveaux blocs. Sa restauration reconstitue tout de même le volume complet, et pas seulement la partie modifiée. Il peut devenir un nouveau disque dans une autre zone ; les instantanés peuvent aussi être copiés entre régions.

Fichiers partagés et logiciels compatibles

EFS est un système de fichiers NFS pour serveurs Linux dont la capacité augmente automatiquement, y compris pour des serveurs répartis entre zones de disponibilité. FSx propose Windows File Server, Lustre, NetApp ONTAP et OpenZFS. FSx for Windows File Server fournit SMB et une intégration à Active Directory ; Lustre convient aux grands ensembles de données exigeant une grande rapidité en calcul haute performance.

Azure Files propose des partages SMB et NFS pour les clients Windows, Linux et macOS compatibles. Azure NetApp Files prend en charge des charges de travail de fichiers d’entreprise exigeantes. Filestore fournit NFS managé sur Google Cloud ; NetApp Volumes fournit des partages fondés sur NetApp. Vérifie le protocole et les fonctions de système de fichiers nécessaires avant de comparer les prix de capacité.

Connecter un serveur de fichiers local

AWS Storage Gateway est une appliance virtuelle locale qui relie des interfaces habituelles de fichiers, de disques ou de bandes au stockage AWS. Elle met localement en cache les données fréquemment utilisées. Tape Gateway permet aux logiciels de sauvegarde existants d’utiliser des bandes virtuelles. Azure File Sync synchronise les serveurs de fichiers Windows avec Azure Files ; la hiérarchisation cloud conserve les fichiers fréquemment utilisés localement et récupère les fichiers moins utilisés à leur ouverture.

Pour une agence disposant de 8 To de fichiers partagés et d’un disque local de 2 To, la hiérarchisation peut garder à proximité les 2 To fréquemment utilisés, tandis que le cloud conserve l’ensemble. L’ouverture d’un fichier moins utilisé dépend alors de la connexion réseau.

La suppression d’une machine virtuelle ne supprime pas toujours ses disques de données ; un disque non attaché peut encore être facturé. La protection offerte par les instantanés dépend aussi de l’emplacement et de l’isolation du compte. Les instantanés EBS et Azure restent dans la région source, sauf s’ils sont copiés. Les instantanés standard Google sont placés par défaut dans la zone multirégionale la plus proche. Une copie de restauration isolée protège contre la compromission du compte source.

Un niveau de stockage modifie le prix payé pour conserver et récupérer des objets. Les niveaux chauds facturent davantage le stockage et moins l’accès. Les niveaux plus froids réduisent le tarif de stockage, mais peuvent ajouter des frais de récupération, des durées minimales et des délais de restauration.

Comparer les classes selon les besoins d’accès

S3 Standard-IA et One Zone-IA ont des durées minimales de 30 jours. Glacier Instant Retrieval et Flexible Retrieval ont des durées minimales de 90 jours ; Deep Archive impose 180 jours. La restauration avec Flexible Retrieval prend de quelques minutes à quelques heures. La récupération standard avec Deep Archive se termine sous 12 heures, et la récupération en masse sous 48 heures. S3 Express One Zone offre un accès rapide dans une seule zone.

Le niveau cool d’Azure impose un minimum de 30 jours, cold de 90 jours et archive de 180 jours. Hot, cool et cold offrent un accès en quelques millisecondes. Archive doit être réhydraté vers un niveau en ligne, ce qui peut prendre jusqu’à 15 heures. Un compte de stockage définit un niveau en ligne par défaut ; chaque blob peut avoir son propre niveau.

Cloud Storage Standard n’impose pas de durée minimale ; Nearline impose 30 jours, Coldline 90 et Archive 365. Google Archive reste en ligne, avec un accès en quelques millisecondes et des frais de récupération. Le seul mot « archive » ne dit pas combien de temps une lecture prendra.

La durée minimale est un engagement de facturation

Supprimer un blob Azure du niveau cool après 21 jours laisse 9 jours facturables sur son minimum de 30 jours. Supprimer un blob du niveau archive après 45 jours laisse 135 jours sur son minimum de 180 jours. Un objet Cloud Storage Archive supprimé après 100 jours laisse 265 jours. Quitter une classe trop tôt peut aussi déclencher ces frais.

Calculer la facture totale

Utilise des tarifs indicatifs de 0,020 dollar américain par Go-mois pour le stockage chaud et de 0,002 dollar américain pour l’archive, plus 0,02 dollar américain par Go récupéré depuis l’archive. Pour 50 000 Go conservés pendant 12 mois :

• Le stockage chaud coûte 12 000 dollars américains.
• Le stockage d’archive coûte 1 200 dollars américains.
• Lire toute l’archive une fois ajoute 1 000 dollars américains, soit 2 200 dollars américains au total.
• La lire chaque mois ajoute 12 000 dollars américains, soit 13 200 dollars américains au total.

Le tarif de stockage moins élevé perd son avantage lorsque les lectures sont fréquentes. Une estimation complète comprend aussi les frais de requête, de suppression anticipée et de transfert de données sortant, facturé lorsque les données quittent le cloud. Les chargements par Internet sont généralement gratuits ; les téléchargements sont couramment facturés.

Laisser les habitudes d’accès guider les changements

S3 Intelligent-Tiering déplace automatiquement les objets inutilisés après 30 et 90 jours et les replace lorsqu’ils sont consultés ; il facture des frais de surveillance, mais pas de récupération. Azure smart tier déplace les blobs entre hot, cool et cold selon leur utilisation. Cloud Storage Autoclass gère les classes d’un compartiment. Pour des calendriers fixes fondés sur l’ancienneté, les règles de cycle de vie offrent un contrôle explicite.

Les classes à zone unique échangent une partie de la protection contre les pannes contre un coût ou des performances différents. S3 One Zone-IA convient aux données secondaires ou recréables, car la perte de cette zone peut entraîner celle des données.

Les données deviennent souvent moins utiles avec le temps. Une politique de cycle de vie applique cette évolution à chaque nouvel objet, afin que personne n’ait à se souvenir de chaque déplacement ou suppression.

Une règle comporte trois parties

Un filtre identifie les objets, comme les clés commençant par logs/ ou les objets portant une certaine balise. Une condition indique quand la règle s’applique, par exemple après un nombre de jours depuis la création ou, dans Azure, depuis le dernier accès. Une action change le niveau de stockage ou supprime l’objet. Les services correspondants sont S3 Lifecycle, la gestion du cycle de vie d’Azure Blob Storage et Cloud Storage Object Lifecycle Management.

Pour des journaux d’application souvent nécessaires pendant un mois et conservés sept ans, déplace-les vers un niveau d’accès peu fréquent au 30e jour et vers un niveau archive au 90e jour. Le niveau d’accès peu fréquent conserve chaque journal pendant 60 jours, ce qui dépasse son minimum de 30 jours. Programme la suppression après la période complète de conservation calendaire : sept ans peuvent comprendre deux jours bissextiles, donc 2 557 jours évitent une suppression anticipée. Une règle de 2 555 jours peut être insuffisante.

Compter le temps passé dans chaque niveau

L’âge de l’objet et le temps qu’il passe dans un niveau sont deux choses différentes. Si un objet entre dans un niveau dont le minimum est de 90 jours au 30e jour et le quitte au 60e jour, il n’y reste que 30 jours :

Il quitte ce niveau sans avoir utilisé 60 jours de la durée minimale, qui peuvent être facturés. Compte l’intervalle entre les transitions avant d’évaluer le coût d’une politique. Chaque transition entraîne aussi le coût d’une requête. Certaines classes plus froides imposent une taille minimale facturable par objet, comme 128 Ko dans S3 Standard-IA : les très petits objets peuvent donc générer peu d’économies ou coûter plus cher après leur déplacement.

Versions et conservation protégée

Les règles de cycle de vie peuvent supprimer les versions non courantes après un délai choisi, conserver un nombre limité de versions antérieures et nettoyer les chargements partitionnés incomplets. Sans ces règles, les versions et les parties abandonnées peuvent continuer à consommer du stockage payant.

Un verrou de conservation actif ou une conservation légale empêche les règles de cycle de vie de supprimer les données protégées. Pour des factures conservées pendant dix années civiles, un plan prévoit leur archivage après un an et leur suppression après 3 653 jours, en tenant compte d’un maximum de trois jours bissextiles. Un verrouillage en mode conformité empêche même les administrateurs de les supprimer avant cette date. La règle de cycle de vie gère les données selon leur ancienneté ; le verrou impose leur protection.

La récupération est une opération distincte

La réhydratation Azure à priorité élevée prend généralement moins d’une heure pour les blobs de moins de 10 Go, à un prix plus élevé. Les règles de cycle de vie Azure ne peuvent pas réhydrater un blob archivé ; sa restauration nécessite une demande distincte. Prévois une restauration avant de promettre une livraison urgente depuis une archive hors ligne.

Les actions de cycle de vie s’exécutent en arrière-plan, généralement dans un délai d’un ou deux jours après que la condition est remplie. Utilise la politique pour appliquer la conservation de façon cohérente à toute la collection et tiens compte de ce délai de traitement dans la planification des opérations.

Les données peuvent survivre à une panne tout en restant inaccessibles pendant celle-ci. La protection du stockage comporte donc deux mesures distinctes : la durabilité et la disponibilité.

Lire correctement les pourcentages

La durabilité décrit la protection contre la perte de données sur une année. S3 Standard est conçu pour une durabilité de 99,999999999 %, appelée onze neuf. La proportion de perte est de une sur 100 milliards par objet et par an. Pour 10 millions d’objets, la perte annuelle attendue est de 0,0001 objet : une moyenne d’un objet tous les 10 000 ans. Il s’agit d’une mesure statistique de conception, et non d’un calendrier de perte des objets.

La disponibilité décrit la proportion du temps pendant lequel les données sont accessibles. Un mois de 30 jours compte 43 200 minutes. Avec une disponibilité de 99,9 %, la part d’indisponibilité est de 0,1 %, soit 43,2 minutes. À 99,99 %, elle est de 4,32 minutes ; à 99 %, de 432 minutes, soit 7,2 heures. La disponibilité visée lors de la conception de S3 Standard est de 99,99 %. Un accord de niveau de service (SLA) est un engagement contractuel, souvent assorti de crédits ; son chiffre peut différer de l’objectif de conception.

Adapter les copies à la défaillance

Plusieurs copies dans un même centre de données protègent contre une panne matérielle. Des copies réparties entre zones de disponibilité protègent contre la panne d’un centre de données. Des copies dans une seconde région répondent au risque de sinistre régional, selon l’emplacement et la manière dont la réplication est effectuée.

La réplication synchrone confirme une écriture après réception d’un accusé des copies requises. Certains systèmes exigent toutes les copies désignées ; d’autres utilisent une majorité, ou quorum. La réplication asynchrone confirme l’écriture sur le site principal, puis transmet les modifications. Si le site principal est perdu, les modifications encore en transit peuvent être perdues. Ce retard de réplication doit rester dans le RPO de l’entreprise : la quantité maximale acceptable de données récentes perdues, mesurée en temps.

Comprendre la redondance Azure

LRS offre une durabilité d’au moins onze neuf, ZRS de douze et les options géoredondantes de seize. GRS possède six copies au total. Les données secondaires GRS/GZRS ordinaires ne sont pas accessibles en lecture avant la bascule ; RA-GRS et RA-GZRS ajoutent un accès en lecture à la région secondaire. Une région répliquée n’est pas nécessairement un remplacement immédiatement actif.

La plupart des classes S3 couvrent au moins trois zones ; les classes One Zone ne le font pas. La réplication S3 peut copier les objets vers un autre compartiment dans la même région ou dans une autre. Les compartiments régionaux Cloud Storage couvrent plusieurs zones, les compartiments birégionaux utilisent deux régions choisies et les compartiments multirégionaux couvrent une zone plus large. La réplication turbo facultative vise à copier les nouvelles données en 15 minutes dans le stockage birégional.

La résidence des données s’applique aussi aux copies secondaires. Si les données doivent rester dans un seul pays, vérifie l’emplacement de la seconde région. La réplication peut aussi transmettre des écrasements ou des suppressions indésirables, selon le service et ses paramètres. Elle fournit des copies résilientes de l’état actuel ; les versions protégées et les sauvegardes permettent de revenir à un état antérieur après une modification indésirable.

Une sauvegarde est une copie restaurable conservée en cas de suppression, de corruption, d’attaque ou de perte d’un site. Un plan de sauvegarde utile part de ce que l’entreprise peut perdre et de la durée pendant laquelle elle peut rester hors ligne.

Définir deux objectifs distincts

Une sauvegarde toutes les 24 heures peut laisser près de 24 heures de modifications sans protection si une panne survient juste avant la sauvegarde suivante. Elle respecte un RPO de 24 heures, mais pas un RPO de 1 heure. Des sauvegardes toutes les heures ou une réplication continue suffisamment à jour répondent à l’objectif plus court.

La vitesse de restauration est indépendante. Si la restauration de 3 To prend 6 heures et que le RTO est de 4 heures, le plan ne respecte pas l’objectif, même si la sauvegarde contient tous les enregistrements nécessaires. Un processus de restauration plus rapide ou une veille à chaud peut réduire le temps de reprise.

Appliquer des politiques à plusieurs ressources

AWS Backup centralise les politiques de sauvegarde pour des ressources comme EBS, RDS, DynamoDB, EFS, FSx et S3. Azure Backup couvre notamment les machines virtuelles, les disques managés, Azure Files, les blobs et SQL Server sur machines virtuelles. Google Cloud propose Backup and DR Service. Les politiques définissent la fréquence, la conservation et les copies vers d’autres régions ou comptes.

Les bases de données managées effectuent aussi des sauvegardes et conservent les journaux de transactions. RDS, Azure SQL Database et Cloud SQL prennent en charge la restauration à un instant donné choisi dans la période de conservation. La conservation dans RDS peut atteindre 35 jours. Les journaux permettent une restauration entre deux sauvegardes, par exemple juste avant une mise à jour accidentelle.

Isoler une copie de restauration

La règle 3-2-1 guide la planification des sauvegardes : trois copies, sur deux types de stockage, dont une hors site. Dans le cloud, une autre région aide à faire face à la perte d’un site et un compte distinct aide à isoler les accès. Le verrouillage de la conservation protège davantage contre la suppression de la sauvegarde par un attaquant : AWS Backup Vault Lock, les coffres de sauvegarde immuables Azure et les coffres Google avec conservation imposée fournissent ce contrôle.

Une copie hors site quotidienne ne respecte pas un RPO de quatre heures en cas de sinistre régional. Elle peut avoir près d’un jour de retard même lorsque des instantanés locaux sont pris toutes les quatre heures.

Pour un partage de fichiers de 3 To avec un RPO de quatre heures et un RTO de huit heures, prends des instantanés toutes les quatre heures pour la restauration locale et crée une copie restaurable dans une autre région au moins toutes les quatre heures. Conserve les instantanés récents pendant sept jours et l’historique quotidien de restauration pendant 90 jours. Teste une restauration complète chaque trimestre et mesure si elle se termine en moins de huit heures.

Services de reprise et archives

AWS Elastic Disaster Recovery et Azure Site Recovery répliquent les serveurs pour qu’ils puissent démarrer ailleurs avec des objectifs de reprise courts, souvent de quelques minutes, moyennant un coût supplémentaire. Ils servent à remettre un système en fonctionnement, et pas seulement à conserver d’anciens fichiers.

Une archive conserve des documents inactifs pour une utilisation ou une conservation à long terme. Une sauvegarde permet de restaurer un système actuel avec un historique renouvelé régulièrement. Une archive économique peut être utile pour stocker des copies, mais son délai de récupération doit convenir au plan de reprise. Les tests de restauration vérifient à la fois que les données fonctionnent et la durée réelle de la reprise.

Une base de données relationnelle stocke des informations liées dans des tables. Un service managé exploite la plateforme de base de données pour toi, tandis que ton équipe reste responsable du fonctionnement des données et des requêtes.

Comprendre les tables et les clés

Une table contient des lignes pour les enregistrements et des colonnes pour les attributs. Son schéma définit ces colonnes et leurs types de données. Une clé primaire identifie une ligne de manière unique. Une clé étrangère fait référence à la clé primaire d’une autre table et relie les enregistrements entre tables.

Supposons que customers contienne Ana, dont l’identifiant client est 1 et le pays Brazil, ainsi que Kofi, dont l’identifiant est 2 et le pays Ghana. La table orders contient les commandes 501 et 503 pour le client 2, d’un montant respectif de 80 et 45, et la commande 502 pour le client 1, d’un montant de 120. SQL lit et modifie les données :

SELECT name FROM customers WHERE country = 'Ghana';

Cette requête renvoie Kofi. Une jointure sur customer_id relie Kofi aux commandes 501 et 503, dont le total est de 125. Le nom du client n’a pas besoin d’être répété dans chaque commande.

Garder une transaction comme un tout

Une transaction regroupe des modifications en une seule unité. Les propriétés ACID décrivent ses garanties :

• Atomicité : toutes les étapes réussissent, ou aucune ne réussit.
• Cohérence : les données validées respectent les règles définies.
• Isolation : les transactions simultanées ne peuvent pas interférer de façons interdites par le niveau d’isolation.
• Durabilité : une modification validée survit à une panne.

Un transfert de 50 débite un compte et en crédite un autre. Si la seconde modification échoue, l’atomicité annule aussi la première. C’est pourquoi les bases de données relationnelles conviennent aux commandes, aux stocks et aux paiements : les modifications liées peuvent être validées ensemble.

Choisir qui exploite la plateforme

Un service PostgreSQL managé fournit à une nouvelle application une maintenance automatisée de la plateforme. Une base de données ancienne qui nécessite une vieille version du moteur et un module du système d’exploitation peut avoir besoin d’une machine virtuelle. Un service managé ne signifie pas que le fournisseur choisit ton schéma, corrige les requêtes lentes ou accorde l’accès aux bons utilisateurs. Ton équipe choisit aussi la taille, la région et les paramètres de disponibilité.

Distinguer les copies supplémentaires

Une réplique de secours dans une autre zone permet une bascule si la base principale tombe en panne. RDS Multi-AZ, Azure SQL Database avec redondance de zone et Cloud SQL en haute disponibilité en sont des exemples. La bascule peut brièvement interrompre le service ; elle n’élimine pas toute interruption.

Une réplique en lecture répartit le trafic de lecture et peut être placée dans une autre région. Elle reçoit généralement les modifications de façon asynchrone et peut donc afficher une ancienne valeur juste après une écriture. Elle ne remplit pas le même rôle qu’une réplique de secours ou qu’une sauvegarde historique.

La mise à l’échelle verticale ajoute des processeurs ou de la mémoire, souvent avec une courte interruption. Les répliques en lecture répartissent le trafic de lecture, tandis que la croissance automatique du stockage ajoute de la capacité disque. Les sauvegardes et les journaux de transactions permettent une restauration à un instant donné après une modification nuisible que les répliques ont peut-être déjà copiée.

Commence le choix d’une base de données par l’application : son moteur, les fonctions nécessaires et l’échelle. Conserver le même moteur évite souvent de modifier le code. Un moteur cloud compatible peut offrir un comportement différent pour le stockage et la mise à l’échelle sans être identique à l’original.

Comparer les principaux services

Amazon RDS prend en charge MySQL, PostgreSQL, MariaDB, Oracle, SQL Server et IBM Db2. Aurora est un moteur AWS distinct, compatible avec MySQL ou PostgreSQL. Il stocke six copies dans trois zones de disponibilité, augmente automatiquement le stockage et propose Aurora Serverless pour les besoins de calcul changeants.

Azure SQL Database utilise le moteur SQL Server et propose des options sans serveur et Hyperscale. SQL Managed Instance prend en charge presque tous les comportements de SQL Server au niveau de l’instance, ce qui est utile pour les bases existantes qui dépendent de fonctions comme les tâches SQL Server Agent. Azure Database for PostgreSQL et Azure Database for MySQL exécutent leurs moteurs open source sous forme de serveurs flexibles managés. SQL Server on Azure Virtual Machines offre un contrôle complet du système d’exploitation, avec une maintenance à la charge du client.

Cloud SQL exécute MySQL, PostgreSQL et SQL Server. AlloyDB for PostgreSQL fournit un service compatible avec PostgreSQL optimisé pour les charges de travail exigeantes, notamment les requêtes analytiques. Spanner distribue les données relationnelles à l’échelle mondiale, s’étend horizontalement et maintient une cohérence forte entre les régions. Les configurations multirégionales offrent un accord de niveau de service prévoyant jusqu’à 99,999 % de disponibilité.

Choisir selon la fonction déterminante

Un commerçant régional utilisant MySQL peut choisir RDS for MySQL, Azure Database for MySQL ou Cloud SQL for MySQL. Une application SQL Server qui dépend de tâches au niveau de l’instance a besoin d’un service compatible avec ces fonctions, comme SQL Managed Instance ; vérifie la prise en charge des fonctions précises pour chaque cible. Une application PostgreSQL exigeante peut envisager Aurora PostgreSQL ou AlloyDB.

La réplication mondiale ne fonctionne pas toujours de la même manière. Aurora Global Database possède une région principale pour les écritures et des régions secondaires asynchrones pour les lectures locales et la reprise après sinistre. Spanner répond aux besoins de transactions distribuées à l’échelle mondiale avec une cohérence forte. Une petite application utilisée dans une seule région n’a généralement pas besoin de cette complexité mondiale.

Si la charge de travail est imprévisible ou souvent inactive, une option sans serveur peut ajuster la capacité. Si l’application nécessite un accès au système d’exploitation, choisis une machine virtuelle. « Managé » et « sans serveur » décrivent des choix d’exploitation ; ils ne rendent pas toutes les fonctions des moteurs interchangeables.

Inclure les licences et l’utilisation dans la facture

Les moteurs commerciaux comme Oracle, SQL Server et Db2 nécessitent une licence incluse ou un dispositif valide d’apport de licences existantes, appelé BYOL. Azure Hybrid Benefit permet de réutiliser les licences SQL Server éligibles. Les moteurs open source comme MySQL et PostgreSQL n’entraînent pas de frais de licence du moteur.

Les frais courants comprennent le calcul, les Go-mois de stockage, le stockage supplémentaire des sauvegardes, les données transférées vers l’extérieur et parfois les opérations d’entrée-sortie. Les frais des solutions sans serveur suivent la capacité utilisée au fil du temps. Compare l’ensemble du service et des conditions de licence, et pas seulement le prix horaire du calcul.

Les bases de données NoSQL organisent les données autour de modes d’accès précis. « Pas seulement SQL » désigne plusieurs modèles, et non un substitut unique à toutes les bases relationnelles. Choisis un modèle selon les questions que pose l’application et les garanties nécessaires pour ses réponses.

Associer le modèle à la question

Un stockage clé-valeur retrouve rapidement cart:58213 à partir de sa clé connue. Il offre moins de possibilités pour rechercher des attributs quelconques. Un document regroupe des champs liés, et les documents peuvent avoir des structures différentes :

{"orderId":"A-1042","customer":{"name":"Ana"},"items":[{"sku":"LAMP-01","qty":2},{"sku":"BULB-07","qty":4}]}

L’application peut lire ensemble cette commande et ses articles. La souplesse de la structure ne signifie pas qu’il n’y en a aucune : l’application a toujours besoin de champs exploitables et de clés soigneusement choisies. Certains services imposent aussi des règles de validation.

Les stockages à familles de colonnes traitent d’énormes volumes d’écritures, comme les relevés de millions de capteurs. Les stockages orientés graphes représentent explicitement les relations par des arêtes entre les nœuds. Suivre les liens entre des comptes est un problème de graphe, tandis que retrouver régulièrement un compte par son identifiant est une recherche par clé.

Utiliser la mémoire pour les lectures répétées

Un stockage en mémoire conserve les données dans la mémoire vive pour un accès très rapide, souvent inférieur à une milliseconde. Un modèle courant est le cache à la demande : consulter le cache ; en cas de défaut de cache, lire la base de données et mettre une copie en cache avec une durée d’expiration.

Pour une recherche dans le cache de 1 ms et une requête de base de données de 50 ms, avec un taux de succès de 90 %, un succès prend 1 ms et un défaut prend 51 ms. La moyenne est :

Le défaut comprend la recherche infructueuse dans le cache. Les données mises en cache peuvent expirer ou être évincées : un cache ordinaire ne doit donc pas contenir l’unique copie de référence. Les services de bases de données durables en mémoire constituent un choix distinct.

Choisir la cohérence en connaissance de cause

Avec la cohérence forte, une lecture renvoie la dernière écriture confirmée. La cohérence à terme permet à une réplique d’afficher brièvement une ancienne valeur pendant qu’elle rattrape les mises à jour. Cela peut permettre une latence plus faible, un coût inférieur ou une meilleure disponibilité pendant certaines pannes. Le comportement nécessaire dépend de la tâche : un solde qui vient d’être mis à jour et un compteur de recommandations peuvent avoir des besoins différents.

DynamoDB propose des lectures à cohérence à terme et à cohérence forte pour les opérations prises en charge. Cosmos DB propose cinq niveaux de cohérence. NoSQL ne signifie pas « aucune transaction » : de nombreux services prennent en charge les transactions, même si leur portée varie.

Les bases relationnelles conviennent aux relations complexes, aux jointures et aux transactions portant sur plusieurs lignes. NoSQL convient à la très grande échelle, aux enregistrements flexibles et aux modes d’accès connus. Une application peut conserver les commandes dans un stockage relationnel, les profils dans un stockage orienté documents et les lectures répétées de produits dans un cache.

Les services NoSQL cloud proposent différents modèles et choix d’exploitation. Détermine d’abord si la charge de travail nécessite des documents, des liens, des données à familles de colonnes ou un cache, puis compare la compatibilité et les frais de capacité.

Reconnaître les familles de services

Le tableau regroupe les services par usage ; cela ne signifie pas que leurs API sont identiques. DynamoDB est sans serveur, prend en charge l’accès clé-valeur et par documents et propose des tables mondiales réparties entre régions. DocumentDB vise la compatibilité avec MongoDB. Keyspaces est compatible avec Cassandra et Neptune stocke des graphes.

Cosmos DB est distribué à l’échelle mondiale et propose les API NoSQL, MongoDB, Cassandra, Gremlin et Table. Un compte utilise une seule API. Le service propose aussi cinq niveaux de cohérence. Azure Table Storage est un service clé-valeur distinct et simple, inclus dans un compte de stockage. Le partage d’une interface Table ne lui donne pas toutes les fonctions de distribution mondiale et de cohérence de Cosmos DB.

Firestore est une base de données orientée documents sans serveur, avec des mises à jour en temps réel et une prise en charge des appareils hors ligne. Bigtable traite de grandes charges de travail à familles de colonnes et à faible latence, et prend en charge l’API HBase. Les historiques de capteurs et la personnalisation à très grande échelle sont des utilisations courantes.

Distinguer cache et mémoire durable

ElastiCache prend en charge Valkey, Redis OSS et Memcached. Memorystore propose Valkey, Redis et Memcached, tandis qu’Azure Managed Redis fournit un cache Redis managé. Les requêtes sur des produits fréquemment répétées peuvent utiliser ces caches pour éviter de lire la base de données à chaque fois.

Amazon MemoryDB est conçu comme une base de données durable en mémoire. Un cache ordinaire peut évincer ou perdre une entrée ; le rôle de MemoryDB comme base de données durable est différent. Détermine si les données sont une copie remplaçable avant de choisir uniquement selon le temps de réponse.

Payer un débit réservé ou utilisé

Avec la capacité provisionnée, réserve le débit à l’avance. DynamoDB utilise des unités de capacité de lecture et d’écriture ; Cosmos DB utilise des unités de requête par seconde, ou RU/s. Une demande stable et prévisible peut rendre ce modèle économique. Avec la capacité à la demande ou sans serveur, les frais suivent les requêtes et la capacité s’ajuste à la demande. Le stockage est facturé séparément.

Un nouveau panier d’achat soumis à des pics imprévisibles peut commencer avec DynamoDB à la demande ou Cosmos DB sans serveur. Une application mobile de documents qui doit fonctionner hors ligne peut utiliser les fonctions de Firestore pour les appareils. Une équipe antifraude qui suit les liens entre des comptes a besoin d’un service de graphes, et pas simplement d’une recherche par clé plus rapide.

Le service distinct Cosmos DB for PostgreSQL est en cours de retrait ; ce n’est pas une autre API de compte. Microsoft dirige les nouveaux projets PostgreSQL distribués vers Elastic Clusters dans Azure Database for PostgreSQL. Vérifie le service et l’API utilisés avant de supposer qu’une application existante est compatible.

Avant de choisir un outil pour un chargement volumineux, il faut faire un calcul. Détermine la capacité réseau que la migration peut réellement utiliser, puis compare cette durée au processus complet de transfert hors ligne.

Exprimer taille et débit dans des unités compatibles

Le stockage utilise des octets ; les réseaux utilisent des bits par seconde. Un octet contient 8 bits. En unités décimales, 1 Go représente un milliard d’octets, 1 To représente 1 000 Go et 1 Gbit/s représente un milliard de bits par seconde. Un Gio binaire représente environ 1,074 Go : vérifie donc l’unité affichée par l’outil.

Pour 100 To sur une liaison à 1 Gbit/s, les données contiennent 800 mille milliards de bits. La division par un milliard donne 800 000 secondes, soit environ 9,3 jours. Si le débit effectif atteint 80 % du débit de la liaison, divise par 0,8 Gbit/s : 1 000 000 de secondes, soit environ 11,6 jours. À 100 Mbit/s, même à plein débit, le transfert prend environ 93 jours. Une liaison à 1 Gbit/s transfère au maximum 125 Mo/s, soit environ 10,8 To par jour, et non 1 Go/s.

Associer les outils en ligne à l’interface

DataSync comprend la planification, le chiffrement et les contrôles d’intégrité et peut transférer des sources de systèmes de fichiers ou d’objets prises en charge vers S3, EFS ou FSx. Transfer Family convient aux partenaires qui envoient déjà des fichiers à l’aide de protocoles de transfert établis. Une copie ponctuelle et une synchronisation continue sont deux tâches différentes.

Comparer avec le transfert hors ligne

Les appareils Azure Data Box offrent jusqu’à 120 To ou 525 To, et Data Box Disk convient aux ensembles plus petits. Google Transfer Appliance transfère aussi les données sur du matériel expédié. Inclus le temps de commande, de copie, d’expédition et de chargement par le fournisseur ; le processus complet peut prendre d’une à quelques semaines. Chiffre l’appareil et vérifie les données obtenues.

AWS Snowball Edge n’est plus proposé aux nouveaux clients et sa prise en charge dans les régions commerciales prend fin le 31 décembre 2026. Les solutions AWS actuelles comprennent DataSync et Data Transfer Terminal, un emplacement physique réservé où les clients apportent leurs disques pour des chargements à haut débit.

Un site dispose d’une liaison à 200 Mbit/s, dont la moitié est disponible pour la migration. Le débit effectif est de 100 Mbit/s. Le transfert de 300 To prend 24 millions de secondes, soit environ 278 jours, ce qui rend un appareil hors ligne intéressant. Le transfert de 2 To prend 160 000 secondes, soit environ 1,9 jour : l’expédition ajouterait donc un délai.

Les transferts répétés nécessitent une liaison permanente

AWS Direct Connect, Azure ExpressRoute et Google Cloud Interconnect fournissent une connectivité privée dédiée avec un débit et une latence plus constants. Ils peuvent convenir aux transferts volumineux et continus. Un appareil hors ligne permet de créer une copie initiale, mais ne synchronise pas les modifications ultérieures.

Inclus les frais du service de transfert et les futurs frais de transfert sortant dans l’estimation. Le transfert entrant par Internet est généralement gratuit ; les téléchargements depuis le cloud sont couramment facturés par Go. Utilise le chiffrement pendant le transfert et des sommes de contrôle ou des vérifications d’intégrité équivalentes pour confirmer que la copie à destination est complète.

Déplacer les octets d’une base de données n’est qu’une partie de la migration. La cible doit comprendre le schéma, l’application doit fonctionner avec elle et les dernières modifications doivent arriver avant la bascule des utilisateurs.

Identifier ce qui change

Une migration homogène conserve le moteur, par exemple de PostgreSQL vers PostgreSQL managé. Une migration hétérogène le change, par exemple d’Oracle vers PostgreSQL. Cela peut nécessiter la conversion des types de données, des schémas, des procédures stockées et du code de l’application.

Une migration vers le même moteur peut tout de même nécessiter des vérifications de version ou de fonctions. Un rapport de conversion est utile précisément parce qu’il identifie ce qui n’est pas transféré automatiquement.

Limiter l’interruption

Une migration hors ligne arrête l’application pour l’exportation, le transfert et l’importation. Une migration en ligne commence par un chargement complet pendant que la source reste utilisée. La capture des modifications de données (CDC) transmet ensuite les nouvelles modifications à la cible. La copie initiale seule est déjà dépassée si les utilisateurs ont continué à écrire pendant sa réalisation.

La bascule exige une séquence contrôlée :

1. Arrêter les écritures sur la source.
2. Appliquer les modifications capturées restantes et confirmer que la cible est à jour.
3. Rendre la cible autonome lorsque cela est nécessaire.
4. Rediriger l’application et vérifier qu’elle fonctionne.

La réplication continue réduit la fenêtre finale ; elle ne supprime pas le besoin de cette fenêtre ni des tests. Conserver l’ancienne source en lecture seule pendant un certain temps peut fournir une solution de repli sans permettre des écritures concurrentes.

Choisir les outils de découverte, de conversion et de migration

AWS DMS déplace les bases de données et prend en charge la réplication continue. AWS SCT et DMS Schema Conversion évaluent et convertissent les structures et le code des bases de données. Application Discovery Service recueille des informations sur les serveurs ; Application Migration Service réhéberge les serveurs. Migration Hub suit le travail et Migration Evaluator aide à établir l’analyse de rentabilité.

Azure Migrate découvre, évalue et migre les serveurs, les bases de données et les applications web. Azure Database Migration Service prend en charge les migrations compatibles de SQL Server, PostgreSQL et MySQL, en ligne ou hors ligne. Data Box transporte de grandes copies de données hors ligne ; il ne convertit pas les schémas.

Database Migration Service de Google prend en charge les migrations vers Cloud SQL ou AlloyDB, notamment les migrations continues et les conversions hétérogènes vers PostgreSQL compatibles. Migration Center découvre les ressources, les évalue et estime les coûts. Choisis un chemin source-cible pris en charge, et non simplement un service dont le nom contient « migration ».

Étudier une migration avec changement de moteur

Une boutique ouverte 24 heures par jour, 7 jours par semaine migre une base Oracle de 2 To vers une cible managée compatible avec PostgreSQL. Évalue d’abord la conversion. Crée la cible et convertis le schéma, réécris les procédures signalées comme nécessitant une intervention manuelle, puis lance le chargement complet et la capture des modifications de données. Teste l’application pendant que la réplication continue. Effectue ensuite la bascule contrôlée. Un dossier de fichiers exportés dans un compartiment est un élément de transfert utile, mais les utilisateurs ont besoin d’une base cible cohérente et en fonctionnement.

Le système qui enregistre les transactions d’aujourd’hui n’a pas le même rôle que celui qui explique cinq années d’histoire de l’entreprise. L’analyse combine des données de nombreuses sources sans faire attendre les transactions courantes derrière de longs parcours de données.

Reconnaître les formes de données et les charges de travail

Les données structurées ont une structure fixe, comme une table de ventes. Les données semi-structurées portent des libellés sans suivre une structure de table unique et fixe, comme JSON ou XML. Les données non structurées comprennent les images, les fichiers audio et les documents de forme libre.

Le traitement transactionnel en ligne (OLTP) effectue de nombreuses petites lectures et écritures sur des enregistrements actuels. Le traitement analytique en ligne (OLAP) exécute de grandes requêtes sur des données historiques. Les rapports lourds exécutés sur une base de production peuvent ralentir les commandes et les paiements : l’analyse utilise donc couramment une copie distincte.

Comparer lac, entrepôt et lakehouse

Un entrepôt combine les sources dans des tables cohérentes. Son stockage en colonnes peut ne lire que les colonnes nécessaires. Si une table de 2 To contient 100 colonnes de même taille et qu’une requête en nécessite trois, le volume parcouru est d’environ 60 Go, et non 2 To.

Un lac conserve des fichiers bruts pour l’exploration, la science des données et l’apprentissage automatique, y compris des données dont l’utilisation ultérieure n’est pas connue. Sans catalogue ni responsable, il devient difficile de trouver quoi que ce soit ou de s’y fier : c’est un « marécage de données ». Les lakehouses ajoutent une gestion de type entrepôt à l’aide de formats comme Apache Iceberg et Delta Lake. Un lac et un entrepôt peuvent coexister, car ils répondent à des étapes et à des besoins différents.

Suivre un pipeline

Un pipeline de données ingère les données, les stocke, les transforme, les analyse, puis présente les résultats ou agit à partir de ceux-ci. Avec l’ETL, l’extraction est suivie de la transformation, puis du chargement. Avec l’ELT, les données sont d’abord chargées, puis transformées à destination. Les entrepôts cloud peuvent fournir la capacité de traitement nécessaire à l’ELT.

Le traitement par lots traite les données recueillies sur une période, comme le chargement nocturne des ventes. Le traitement en flux traite les événements à leur arrivée : il convient aux tableaux de bord en direct, aux paiements suspects ou aux alertes de capteurs. Un rapport historique mensuel peut bien fonctionner par lots ; une réaction nécessaire en quelques secondes appelle un traitement en flux.

Garder des données utilisables et fiables

La gouvernance définit des règles et des processus pour l’accès, la conservation, la signification et la qualité. Un catalogue indique ce qui existe et ce que cela signifie. Le lignage retrace l’origine des données et les transformations qui les ont modifiées. Ensemble, ils aident une équipe à expliquer un nombre dans un tableau de bord.

Les contrôles de qualité portent sur l’exhaustivité, l’exactitude, la cohérence, l’actualité, la validité et l’unicité. Un code de région manquant nuit à l’exhaustivité ; des paiements en double nuisent à l’unicité ; un flux obsolète nuit à l’actualité. La qualité est utile avant l’analyse comme avant l’IA. Les formats ouverts et les outils interopérables facilitent le partage et réduisent les silos de données isolés et la dépendance envers un fournisseur.

Un service d’analyse occupe une place précise sur le chemin qui mène des événements aux décisions. Identifie son rôle avant de choisir un produit : capturer un flux, le nettoyer, l’interroger et l’afficher sont des opérations différentes.

Entrepôts et requêtes sur les fichiers

Redshift propose des entrepôts provisionnés et sans serveur. BigQuery est sans serveur, sépare le stockage du calcul et propose une tarification des requêtes fondée sur le volume parcouru ou sur la capacité. Microsoft Fabric combine des fonctions d’entrepôt et de lakehouse ; Synapse Analytics reste disponible, Fabric étant privilégié pour les nouveaux développements.

Athena exécute du SQL sans serveur sur les fichiers dans S3 ; il ne stocke pas les données qu’il interroge. Les tables externes BigQuery peuvent lire les fichiers Cloud Storage et les tables du lakehouse Fabric dans OneLake disposent d’un point de terminaison d’analyse SQL. Interroger les fichiers sur place est différent du chargement d’une autre copie dans une base de données.

Préparer les données et traiter les événements

AWS Glue transforme les données et maintient un Data Catalog qui décrit leur structure et leur emplacement. Azure Data Factory crée et planifie des pipelines. Google Dataflow exécute des traitements par lots et en flux avec Apache Beam.

Pour Spark et les frameworks apparentés de traitement des données massives, utilise Amazon EMR, Azure Databricks ou Fabric Spark, et Managed Service for Apache Spark de Google, anciennement Dataproc. Ils fournissent des frameworks de traitement ; leur rôle diffère de celui d’un tableau de bord ou d’un service de messagerie.

Pour les flux, Amazon Kinesis capture et traite les données en temps réel et Data Firehose charge les flux vers leurs destinations. Azure Event Hubs ingère les événements ; Stream Analytics ou Fabric Real-Time Intelligence les analyse. Google Pub/Sub transporte les messages et Dataflow les traite.

Suivre un événement jusqu’au tableau de bord

Pour le tableau de bord en direct d’une boutique, les événements de commande entrent dans Kinesis, Event Hubs ou Pub/Sub. Les copies brutes sont déposées dans S3, Azure Data Lake Storage ou Cloud Storage. Glue, Data Factory ou Dataflow nettoie les enregistrements. Redshift, Fabric ou BigQuery prend en charge l’analyse, et Quick Sight, Power BI ou Looker affiche les résultats.

Looker peut définir les indicateurs métier de manière centralisée afin que les équipes donnent le même sens à des mesures comme le chiffre d’affaires. Amazon OpenSearch Service a un autre rôle : indexer les textes et les journaux pour la recherche et l’analyse.

Réduire les frais de requête fondés sur le volume parcouru

Avec un tarif indicatif de 5 dollars américains par To parcouru, lire 2 To coûte 10 dollars américains. Si un format en colonnes comme Parquet permet à la requête de lire trois colonnes de même taille sur 100, elle lit 60 Go, soit 0,06 To, pour un coût de 0,30 dollar américain. Si les fichiers sont aussi partitionnés par jour et que la requête ne nécessite qu’un jour de même taille sur 30, le volume parcouru tombe à 2 Go, pour un coût de 0,01 dollar américain.

Les économies proviennent de l’exclusion effective des colonnes et des partitions inutiles. Le simple stockage d’un fichier en mode objet ne garantit pas un faible volume parcouru. Les réservations de capacité BigQuery sont une option de facturation ; elles n’obligent pas le client à administrer les serveurs de l’entrepôt.

Les services cloud d’IA vont des API prêtes à l’emploi aux plateformes d’entraînement de modèles. Le meilleur niveau de départ dépend de la tâche de l’entreprise, des données et des compétences de l’équipe.

Relier les notions principales

L’intelligence artificielle couvre les systèmes qui accomplissent des tâches comme la reconnaissance d’images ou la compréhension du langage. L’apprentissage automatique est une approche de l’IA : un modèle apprend des régularités à partir de données. L’apprentissage profond utilise des réseaux de neurones à nombreuses couches. L’intelligence artificielle générative crée des contenus comme du texte, des images ou du code à partir d’une instruction. Un modèle de fondation est entraîné sur des données variées pour pouvoir être adapté à de nombreuses tâches ; un grand modèle de langage, ou LLM, est centré sur le langage.

L’entraînement produit ou ajuste un modèle à partir de données. L’inférence utilise un modèle entraîné sur de nouvelles entrées. L’entraînement d’un petit modèle peut ne nécessiter qu’un processeur ordinaire ; les grands modèles d’apprentissage profond nécessitent souvent des GPU ou des TPU. Attribuer un score de risque de fraude à un nouvel achat est une inférence, même si le modèle a été entraîné plusieurs mois auparavant.

La classification prédit une catégorie ; la régression prédit un nombre. Ces méthodes peuvent simplifier des règles compliquées, prévoir la demande, personnaliser les recommandations et détecter des anomalies. L’IA agentique ajoute la planification et l’utilisation d’outils afin qu’un agent puisse accomplir une tâche, comme rechercher des informations et appeler une application.

Choisir un niveau de service

1. Les API préentraînées traitent des tâches établies comme la traduction ou la reconnaissance de la parole sans créer de modèle.
2. Les plateformes génératives fournissent des modèles de fondation, des moyens d’ancrage et des outils pour les agents : Amazon Bedrock, Microsoft Foundry et Gemini Enterprise Agent Platform, anciennement Vertex AI.
3. Les plateformes d’apprentissage automatique créent, entraînent et déploient des modèles personnalisés : SageMaker AI, Azure Machine Learning et Gemini Enterprise Agent Platform. AutoML réduit le code nécessaire pour entraîner un modèle à partir de tes données.
4. L’apprentissage automatique dans les services de données, comme BigQuery ML et Redshift ML, permet aux équipes de travailler avec SQL là où les données se trouvent déjà.

Un commerçant qui traduit des descriptions peut utiliser une API de traduction. Un assistant conversationnel qui répond à partir des manuels de l’entreprise peut utiliser la génération augmentée par récupération (RAG) : récupérer les passages pertinents des manuels et les fournir avec chaque question. Une prévision de la demande fondée sur les ventes du commerçant peut utiliser AutoML, l’apprentissage automatique dans une base de données ou une plateforme d’apprentissage automatique. Tout créer de toutes pièces demande un effort supplémentaire lorsqu’un service existant convient déjà.

Évaluer les données et les résultats

Des exemples d’entraînement manquants, dépassés ou biaisés peuvent produire des résultats médiocres ou injustes. Vérifie l’exhaustivité, l’exactitude, la cohérence, l’actualité, la validité et l’unicité. Une IA responsable exige aussi l’équité, le respect de la vie privée, la sécurité, la transparence, l’explicabilité, la supervision humaine et des responsabilités clairement définies.

Une réponse générative assurée peut contenir une hallucination, c’est-à-dire une affirmation fluide mais fausse. Ancre les résultats importants dans des informations fiables et vérifie-les. Le fournisseur sécurise son service ; le client contrôle les données fournies, les accès et l’utilisation des résultats. La génération augmentée par récupération fournit des éléments au modèle, mais sa présence seule ne garantit pas une réponse correcte.

De nombreuses tâches courantes d’IA disposent déjà d’un service préentraîné. Une application envoie des données par une API et reçoit des résultats sans que ses développeurs aient d’abord à entraîner un modèle.

Associer les entrées et les résultats

Les services de vision trouvent les objets, les scènes et le texte dans les images ; Video Intelligence API de Google traite l’analyse vidéo. La reconnaissance automatique de la parole transcrit les fichiers audio, tandis que la synthèse vocale génère une sortie parlée à partir d’un texte écrit. L’analyse de texte identifie les sentiments, les entités, les expressions clés ou les catégories. La traduction change la langue du texte.

Les services de traitement des documents conservent les relations dans les formulaires, par exemple la date associée à la mention « Date de facture » ou le montant correspondant au total d’un tableau. La détection générale du texte dans les images trouve le texte, mais ne fournit pas la même compréhension du formulaire. Un processus de traitement des factures nécessite donc une extraction de documents, et pas seulement des libellés d’images.

Combiner les services autour d’un processus métier

Un centre de contact peut transcrire les appels enregistrés, analyser le sentiment exprimé dans chaque transcription et afficher sur un tableau de bord les sujets récurrents de mécontentement. La transcription produit les mots ; l’analyse du langage interprète certains aspects de ces mots.

Un assureur peut extraire les noms, les dates et les montants des déclarations de sinistre avec un service de traitement des documents et transmettre les résultats à faible confiance à une personne. Cette vérification fait partie du processus : un champ détecté est une prédiction, et non une garantie que la valeur est correcte.

Amazon Lex crée des agents conversationnels vocaux ou textuels et peut fonctionner avec Amazon Connect, un centre de contact cloud. Amazon Q fournit une assistance générative aux utilisateurs métier et aux développeurs. Microsoft Foundry et Gemini Enterprise Agent Platform fournissent des outils pour les assistants conversationnels et les agents. Azure Vision, Speech, Language et les API associées font partie de Foundry Tools, anciennement Azure AI services.

Estimer l’utilisation avant le prix

Les services peuvent facturer par image, minute d’audio, page, caractère traduit ou jeton généré. Compte l’unité pertinente, puis applique le tarif. Utilise un tarif indicatif de traduction de 15 dollars américains par million de caractères. Deux mille descriptions de 500 caractères chacune contiennent un million de caractères. La traduction en dix langues traite dix millions de caractères et coûte 150 dollars américains. Ne compter que le texte source omettrait le traitement répété pour chaque langue.

Préentraîné ne signifie pas toujours que le comportement est fixe. Les vocabulaires de transcription personnalisés peuvent faciliter la reconnaissance des noms de produits ; les libellés d’images personnalisés peuvent reconnaître les produits d’une entreprise ; les classificateurs de documents personnalisés peuvent trier ses formulaires. Ces options permettent d’adapter un service sans projet complet de création de modèle.

Les images, les voix et les documents peuvent contenir des données personnelles. Fournis-les pour une finalité licite, obtiens le consentement lorsqu’il est requis et contrôle les accès et la conservation. Choisis le service selon sa tâche et ses besoins en données avant de décider qu’un entraînement personnalisé est nécessaire.