Tests, Gemini Enterprise, coûts et nettoyage

1. Les tests sans clé

Test de test_vais_lab.py	Ce qu'il protège
`test_jsonl_une_ligne_par_document…`	le format du JSONL : `id`, `structData`, `content.uri`
`test_tous_les_documents_ont_un_fichier`	chaque entrée de `METADATA` a son `.txt`
`test_build_filter`	la syntaxe des filtres et le refus d'une tentative d'injection
`test_requetes_visent_l_application…`	`search` et `answer_query` portent le même filtre et visent la bonne serving config
`test_parse_answer_ne_garde_que…`	seuls les documents cités deviennent des sources

Les tests construisent de vrais objets discoveryengine_v1 (de.Answer, de.Answer.Citation…) sans les envoyer : on vérifie le code contre les types réels de la bibliothèque.

2. Le lien avec Gemini Enterprise

flowchart LR
  subgraph DE["Discovery Engine (location eu)"]
    DS["Data store lab-vais-docs"]
    A1["Application de recherche lab-vais-app"]
    A2["Application Gemini Enterprise"]
  end
  DS --> A1
  DS -.->|"rattachable"| A2
  A1 --> API["Votre code : search / answer_query"]
  A2 --> UI["Interface Gemini Enterprise pour les salariés (licences)"]

Gemini Enterprise range les sources de ses connecteurs (Cloud Storage, Drive, SharePoint…) dans des data stores ; l'import depuis Cloud Storage fait partie de ses sources documentées.
Un même data store peut donc servir à la fois votre application de recherche (API) et une application Gemini Enterprise (interface), sans dupliquer l'index.
Ce qui change avec Gemini Enterprise : l'identité de chaque utilisateur, les licences par personne, les connecteurs fédérés et l'interface de conversation.

On ne l'a pas créée ici (licences nécessaires). Le cours RAG sur vos documents Google Drive le fait en vrai, sous-projet « Gemini Enterprise natif ».

3. Les coûts

Poste	Facturation (voir la page de tarifs)	Pour ce lab
Requêtes de l'édition Enterprise	par tranche de 1 000 requêtes	une quinzaine de requêtes
Module LLM (réponses générées)	par tranche de 1 000 requêtes, en plus	une dizaine de réponses
Stockage de l'index	au Go par mois, au-delà d'un quota gratuit	quelques Ko, supprimé après 10 minutes
Bucket Cloud Storage	au Go par mois	quelques Ko, supprimé

Ordre de grandeur pour ce lab : quelques centimes. Pas de coût fixe à l'heure comme la base Spanner de RAG Engine, mais l'index reste facturé tant que le data store existe.

4. Le nettoyage

files/vais_lab.py

# L'application d'abord : un data store rattaché à une application ne peut pas être supprimé.
for label, delete, get, name in [("application", engines.delete_engine, engines.get_engine, ENGINE),
                                 ("data store", stores.delete_data_store, stores.get_data_store, DATA_STORE)]:
    try:
        delete(name=name)  # opération longue : on ne lit pas son résultat (vide, le SDK le refuse — vérifié)
    except NotFound:
        print(label, "déjà absent(e)")
        continue
    for _ in range(90):    # on attend que la ressource ait vraiment disparu
        try:
            get(name=name)
            time.sleep(10)
        except NotFound:
            print(label, "supprimé(e)")
            break

Vérification indépendante :

terminal

TOKEN=$(gcloud auth application-default print-access-token)
for r in dataStores engines; do
  curl -s -H "Authorization: Bearer $TOKEN" -H "x-goog-user-project: <projet>" \
    "https://eu-discoveryengine.googleapis.com/v1/projects/<projet>/locations/eu/collections/default_collection/$r"
done
gcloud storage ls --project <projet> | grep lab-vais

Pourquoi supprimer l'application avant le data store ?

La suppression renvoie une erreur « neither response nor error set ». Que conclure ?

Exercice : nettoyer ce qu'on aurait oublié

Un lecteur a lancé setup trois fois avec des préfixes différents et ne se souvient plus des noms. Comment retrouver et supprimer tout ce qui vient du lab ?

Voir la solution

Applications et data stores : list_engines / list_data_stores sur default_collection, en filtrant les noms qui commencent par lab- (c'est ce que fait la ligne de vérification de cleanup).
Buckets : ils portent le label formation-lab=vertex-ai-search :

gcloud storage buckets list --project <projet> --filter="labels.formation-lab=vertex-ai-search" --format="value(name)"

Puis on supprime dans l'ordre application → data store → bucket.

Résultat obtenu

Tests et nettoyage réels du 2026-10-15 :

$ python -m pytest -v
test_vais_lab.py::test_jsonl_une_ligne_par_document_avec_metadonnees_et_lien_gcs PASSED [ 20%]
test_vais_lab.py::test_tous_les_documents_ont_un_fichier PASSED          [ 40%]
test_vais_lab.py::test_build_filter PASSED                               [ 60%]
test_vais_lab.py::test_requetes_visent_l_application_et_portent_le_filtre PASSED [ 80%]
test_vais_lab.py::test_parse_answer_ne_garde_que_les_sources_citees PASSED [100%]
5 passed in 0.43s

$ python vais_lab.py cleanup        (2e passage : l'application avait été supprimée au 1er, qui a levé l'erreur du SDK)
application déjà absent(e)
data store supprimé(e)
bucket supprimé : lab-vais-<projet>
vérification : applications = [] | data stores = [] | bucket existe = False

$ curl …/dataStores  ->  {}
$ curl …/engines     ->  {}

Data store créé à 16 h 41, tout supprimé à 16 h 50.

Je sais faire

Tester le code Discovery Engine sans réseau avec les vrais types
Expliquer comment un data store se partage avec Gemini Enterprise
Citer les postes de coût de Vertex AI Search
Supprimer application, data store et bucket dans l'ordre et le prouver