MySQL 9.7 LTS, la version de MySQL pour l'IA : ce qui marche vraiment

Le 21 avril 2026, MySQL 9.7 est sorti : première version LTS depuis la 8.4, support assuré jusqu'en avril 2031 et étendu jusqu'en avril 2034. C'est donc la version sur laquelle un projet va s'installer pour plusieurs années, et celle qui portera ses usages d'intelligence artificielle. La question qui compte n'est pas de savoir ce qu'elle annonce, mais ce qu'elle permet réellement.

La recherche par le sens, en une minute

Une recherche classique compare des caractères. Si votre catalogue dit « brodequin de marche » et que le client tape « chaussure de randonnée », il ne trouve rien, alors que les deux désignent le même produit.

La recherche vectorielle compare le sens. Un modèle transforme chaque fiche en une empreinte numérique, et deux contenus proches par le sens produisent deux empreintes proches, même sans un mot en commun. C'est ce qui permet à un moteur de comprendre une demande formulée avec les mots du client plutôt qu'avec ceux du vendeur.

Depuis la version 9.0, MySQL sait stocker ces empreintes. C'est à partir de là que les choses méritent d'être regardées de près.

Stocker n'est pas chercher

Sur un MySQL que vous installez vous-même, vous pouvez enregistrer ces empreintes et les relire. Vous ne pouvez pas les comparer entre elles.

La fonction qui mesure la proximité entre deux contenus existe bien, mais le manuel officiel de MySQL est explicite : elle n'est disponible que dans l'offre cloud d'Oracle. Ni la version Community, celle que presque tout le monde utilise, ni même la version Commercial payante ne la contiennent.

Pour une fonctionnalité dont l'intérêt entier repose sur la comparaison, la nuance n'est pas un détail. Elle décide de l'hébergement, et donc du budget d'exploitation sur toute la durée de vie du projet.

Ce que 9.7 change, et ce qu'elle ne change pas

La vraie nouvelle de cette version est son statut, pas ses vecteurs. Une LTS, c'est une base sur laquelle une entreprise s'engage plusieurs années sans subir la course trimestrielle aux mises à jour. Pour un projet qui démarre aujourd'hui, c'est la bonne cible, et le choix est facile à défendre.

Côté recherche par le sens en revanche, la situation n'a pas bougé entre la 9.0 et la 9.7. Rien n'a été ajouté à la version libre en trois ans. Il manque toujours la fonction de comparaison, et il manque aussi l'optimisation qui permettrait de chercher vite dans un gros volume : sans elle, chaque recherche parcourt la totalité des lignes. Sur mille produits c'est indolore, sur un million c'est une autre histoire.

Les trois chemins praticables

Changer de serveur sans changer de base. Percona distribue une version de MySQL qui ajoute la fonction de comparaison, utilisable sur n'importe quel hébergement. C'est un remplacement direct, pas une migration, et il reste libre.

Aller dans le cloud d'Oracle. C'est le chemin prévu par l'éditeur, et il fonctionne. Il suppose d'accepter l'hébergement et la facturation qui vont avec : une décision d'architecture avant d'être une décision technique.

Mettre un moteur dédié à côté. Garder MySQL pour les données métier et confier la recherche par le sens à un service spécialisé. Plus de pièces à maintenir, mais chaque pièce fait son métier, et vous ne dépendez du calendrier de personne pour une fonction centrale.

Et du côté de PostgreSQL ?

La comparaison s'impose, parce que c'est l'autre base libre que l'on retrouve sur les mêmes projets, et que la réponse y est très différente.

PostgreSQL ne porte pas la recherche par le sens dans son moteur : elle lui est ajoutée par une extension libre, pgvector, dont la version courante est sortie le 1er octobre 2026. Et cette extension fait ce que la version libre de MySQL ne fait pas : comparer deux contenus, et chercher vite dans un gros volume grâce à des index conçus pour ça.

Elle est par ailleurs proposée en standard par la plupart des hébergeurs gérés, des offres d'Amazon aux plateformes spécialisées. Vous n'êtes donc enfermé chez personne.

Le tableau, sans jargon

Une précaution si vous partez sur PostgreSQL : exigez une version récente de l'extension. Les versions antérieures à 0.8.2 portent une faille corrigée depuis, et c'est le genre de détail qu'un hébergeur ne vous signalera pas spontanément.

Alors, qu'est-ce qu'on recommande ?

Projet neuf où la recherche par le sens est centrale : PostgreSQL, sans hésiter. La fonction est là, libre, mature, hébergeable partout. Choisir MySQL dans ce cas revient à payer plus tard, en hébergement imposé ou en pièce rapportée.

Projet déjà sur MySQL, où le besoin est secondaire : ne migrez pas la base pour ça. Changer de moteur de base de données est un chantier à part entière, avec ses risques et son budget. La version de MySQL distribuée par Percona ajoute la fonction manquante sur n'importe quel hébergement, et un moteur dédié posé à côté règle le reste. Les deux coûtent une fraction d'une migration.

Projet déjà sur MySQL, où le besoin devient central : la question de la migration est légitime. Elle se pose alors comme un projet chiffré, avec un état des lieux, un plan et une recette, pas comme une décision prise un vendredi soir.

Le vrai critère n'est pas la base de données préférée de votre prestataire. C'est de savoir si la recherche par le sens est au coeur de votre produit ou à sa périphérie. Au coeur, elle justifie de choisir le moteur autour d'elle. À la périphérie, elle ne justifie jamais de tout refaire.

La question à se poser avant tout ça

En avez-vous besoin ?

Sur un catalogue de quelques centaines de références, une recherche classique bien réglée, avec gestion des synonymes et tolérance aux fautes de frappe, répond à la quasi-totalité des cas pour une fraction de la complexité. La recherche par le sens devient intéressante quand le volume est important, quand le vocabulaire de vos clients ne recoupe pas celui de votre catalogue, ou quand il faut rapprocher des contenus qui n'ont aucun mot en commun.

L'ajouter à un site qui n'en a pas besoin, c'est financer un coût de calcul, une dépendance supplémentaire et un poste de maintenance, pour un gain que personne ne mesurera.

Ce que nous en retenons

MySQL avance vers l'IA, la direction est prise et les versions suivantes combleront l'écart. Mais une fonctionnalité annoncée n'est pas une fonctionnalité disponible, et la différence se lit dans le manuel plutôt que dans les communiqués.

C'est un arbitrage qui se pose au cadrage et non en cours de route, parce qu'il engage l'hébergement et le coût d'exploitation sur plusieurs années. Si votre projet soulève ces questions, notre page conseil et accompagnement IT décrit la façon dont nous les instruisons, et le travail sur l'architecture du code est ce qui permet de changer de moteur de recherche plus tard sans tout réécrire.