Ce qu'AWS a annoncé
Le 5 août 2026, AWS a annoncé qu'Amazon DynamoDB gère désormais la recherche vectorielle de façon native, sans qu'il soit nécessaire de construire ni de maintenir un index vectoriel séparé. L'entreprise annonce une latence de quelques millisecondes avec un rappel supérieur à 99 pour cent, avec une montée en charge jusqu'à des milliers de milliards de vecteurs. SiliconANGLE et InfoWorld ont couvert l'annonce de façon indépendante le jour même, la décrivant comme une capacité native plutôt qu'un service rapporté.
Le mécanisme est simple : la recherche vectorielle s'exécute désormais sur la même table qui contient déjà les données principales de l'application. Il n'y a plus de seconde base de données à provisionner, ni d'étape d'export puis d'import, ni de pipeline chargé de maintenir un index vectoriel séparé synchronisé avec les changements de la table source.
C'est justement ce dernier point qui mérite l'attention. Supprimer le pipeline de synchronisation supprime le décalage entre la mise à jour d'un enregistrement et son apparition dans les résultats de recherche, et il supprime toute une classe de bugs qui naît quand deux magasins de données divergent l'un de l'autre.
La catégorie de fournisseurs menacée
Depuis deux ou trois ans environ, ajouter une recherche sémantique ou une génération augmentée par récupération (RAG) à un produit signifiait presque toujours adopter une seconde base de données, conçue spécifiquement pour les vecteurs, à côté de la base qui détenait déjà les données réelles. Pinecone, Weaviate et Milvus ont bâti leurs activités précisément sur cet écart, et les extensions de Postgres répondaient au même besoin pour les équipes qui voulaient rester sur un seul moteur.
Ce schéma est devenu presque une ligne budgétaire par défaut dans les plans de projets d'IA : budget pour un fournisseur de base de données vectorielle, budget de temps d'ingénierie pour un pipeline de synchronisation, et budget pour une seconde revue de sécurité parce que les données des utilisateurs passent désormais par un second sous-traitant. Aucun de ces coûts n'était exotique, mais tous étaient tenus pour nécessaires.
Ce qu'AWS a livré le 5 août n'efface pas cette catégorie de fournisseurs, mais il lui retire la justification automatique dans un cas large et courant : toute équipe dont les données principales d'application vivent déjà dans DynamoDB. Pour ce groupe, l'argument en faveur d'une base de données vectorielle séparée doit désormais être redémontré, et non plus supposé.
Ce qu'il faut revoir avant le prochain feu vert d'un projet d'IA
La consigne pratique ici est simple et immédiate. Avant de signer un contrat avec un fournisseur de base de données vectorielle, et avant d'assigner un ingénieur à la construction d'un pipeline de synchronisation de DynamoDB vers une base de données vectorielle, quelqu'un devrait vérifier si DynamoDB peut désormais faire le travail à lui seul.
Cela compte surtout pour les plans déjà rédigés. Tout plan de projet d'IA écrit ces deux dernières années qui comporte une ligne 'ajouter une base de données vectorielle' a été rédigé selon des contraintes qu'AWS vient de changer pour les utilisateurs de DynamoDB. Rouvrir ce plan coûte une après-midi ; ne pas le rouvrir coûte un contrat fournisseur et un pipeline de maintenance qui n'était peut-être pas nécessaire.
La vérification elle-même est étroite : les données principales de l'application vivent-elles déjà dans DynamoDB, et l'échelle et la latence requises entrent-elles dans ce qu'AWS a publié ? Si les deux réponses sont oui, la base de données vectorielle séparée devient facultative plutôt que supposée.
Où une base de données vectorielle séparée garde du sens
Rien de tout cela ne signifie qu'il faille abandonner toute base de données vectorielle dédiée. Les équipes qui opèrent à une échelle extrême, ou sur plusieurs fournisseurs cloud à la fois, peuvent encore avoir des raisons qui n'ont rien à voir avec la nouvelle capacité de DynamoDB.
Les architectures déjà construites et stables autour de Pinecone, Weaviate ou Milvus n'ont pas non plus besoin de changer sur la seule foi d'une annonce. Une migration a son propre coût, et un système qui fonctionne et répond à ses exigences ne mérite pas automatiquement d'être perturbé.
La position honnête est qu'il s'agit d'une revérification, pas d'un mandat. Certaines équipes feront la vérification et garderont leur base de données vectorielle séparée parce qu'elles ont une vraie raison de le faire. L'erreur n'est pas de vérifier, mais de ne pas vérifier du tout et de s'en tenir à l'ancienne hypothèse par habitude.
Ce qu'il faut surveiller ensuite
La conséquence la plus immédiate pour les équipes de protection des données de l'UE et du Royaume-Uni est une conséquence de conformité : toute équipe qui déplace sa recherche vectorielle vers DynamoDB supprime un second sous-traitant et un second accord de traitement des données de sa revue fournisseurs, puisque les données des utilisateurs n'ont plus besoin de transiter par un fournisseur de base de données vectorielle séparé.
Il vaut la peine d'observer comment réagiront les fournisseurs dédiés de bases de données vectorielles. Une capacité de ce type, livrée par le fournisseur qui détient déjà une grande part des données sous-jacentes, est le genre de mouvement qui tend à forcer les concurrents à se différencier nettement ou à se battre plus fort sur le prix.
Il vaut aussi la peine d'observer si d'autres grands fournisseurs de bases de données cloud intègrent une capacité vectorielle similaire dans leurs propres bases de données principales dans les mois qui viennent. Si le mouvement d'AWS est reproduit ailleurs, l'hypothèse selon laquelle les fonctionnalités d'IA exigent une base de données séparée deviendra dépassée bien au-delà de DynamoDB.
À lire ensuite: Le carnet valait 1,5 milliard. L'obligation aussi. | La manne de la pénurie est partie en rachat
