Gérer les serveurs d'intelligence artificielle personnalisés

SquashTM fournit un mécanisme, les serveurs d'IA personnalisés, pour configurer et utiliser n'importe quelle API LLM.

Paramètres

Un serveur d'IA personnalisé possède les mêmes paramètres que les autres serveurs d'IA (Nom, Fournisseur d'API, URL et Description) à l'exception du Modèle qui n'est pas applicable.
L'URL doit être celle de l'endpoint (point de terminaison) d'API qui gère la complétion de chat.

Vous devez définir :

• le modèle du corps de la requête qui sera utilisé pour générer la requête JSON envoyée à l'endpoint (point de terminaison) d'API ;
• le chemin JSON du texte généré qui sera utilisé pour extraire la réponse générée par l'IA.

Il est possible de configurer jusqu'à cinq en-têtes HTTP, chacun défini par son nom et un modèle utilisé pour calculer sa valeur.
L'en-tête HTTP Content-Type: application/json ne doit pas être défini car SquashTM l'ajoutera automatiquement.

Vous pouvez définir un Timeout de requête comme pour les autres serveurs d'IA.

Écrire des modèles

Le modèle du corps de la requête et les modèles de la valeur d'en-tête sont évalués en utilisant Handlebars.

Les variables suivantes sont disponibles :

• messages : la liste des messages.
  Chaque message a un role et un content.
  La valeur de role ne doit pas être utilisée directement ; les helpers isSystem, isUser et isModel (voir ci-dessous) doivent être utilisés à la place.
• apiKey : la valeur de la clé d'API.

Les helpers (méthodes) suivants sont disponibles :

• isSystem (prend en entrée une chaîne de caractères contenant un rôle, retourne un booléen) : teste si c'est un message système (aussi appelé prompt système) ;
• isUser (prend en entrée une chaîne de caractères contenant un rôle, retourne un booléen) : teste si c'est un message utilisateur (aussi appelé prompt utilisateur) ;
• isModel (prend en entrée une chaîne de caractères contenant un rôle, retourne un booléen) : teste si c'est un message de l'IA ;
• convertToJsonString (prend en entrée une chaîne de caractères, retourne une chaîne de caractères) : convertit une chaîne en chaîne JSON (incluant les guillemets doubles de début et de fin) en échappant les caractères spéciaux.

Nous détaillons ici deux exemples de modèles et les résultats de leurs applications.

Exemple 1 : OpenAI

Le corps de la requête JSON, les en-têtes HTTP et le corps de la réponse JSON sont décrits ici.

(Veuillez garder à l'esprit que ceci est fourni ici comme exemple d'utilisation de modèle. Si vous envisagez d'utiliser des modèles OpenAI, vous devriez simplement configurer un tel modèle.)

Configuration

• modèle du corps de la requête :

  {
      "model": "gpt-4.1",
      "messages": [
          {{#each messages}}{
              "role": "{{#if (isSystem role)}}system{{/if}}{{#if (isUser role)}}user{{/if}}{{#if (isModel role)}}assistant{{/if}}",
              "content": {{convertToJsonString content}}
          }{{#unless @last}},
          {{/unless}}{{/each}}
      ],
      "temperature": 0.7,
      "seed": 42
  }
  

• nom d'en-tête HTTP 1 : Authorization
• modèle de valeur d'en-tête HTTP 1 : Bearer {{apiKey}}

Application

En supposant ces messages :

et cette clé d'API : sec_DEADBEEF.

SquashTM génèrera ce corps de requête JSON :

{
  "model": "gpt-4.1",
  "messages": [
    {
      "role": "system",
      "content": "Vous êtes un assistant QA qui aide avec la planification des tests."
    },
    {
      "role": "user",
      "content": "J'ai besoin de créer une charte de test exploratoire pour notre flux de commande. Par où dois-je commencer ?"
    },
    {
      "role": "assistant",
      "content": "Commencez par identifier les principales zones de test : flux utilisateur, méthodes de paiement, gestion des erreurs et sécurité. Concentrez-vous d'abord sur le \"chemin heureux\", puis sur les cas limites. Quelle est la partie la plus critique de votre processus de commande ?"
    },
    {
      "role": "user",
      "content": "La validation du paiement est cruciale. Nous avons eu des problèmes avec des utilisateurs bloqués sur l'écran de \"traitement\" auparavant."
    },
    {
      "role": "assistant",
      "content": "C'est un domaine clé à explorer. Pour la validation du paiement, testez des scénarios comme les timeouts réseau, les cartes refusées et l'expiration de session. Documentez ce qui se passe quand les utilisateurs actualisent pendant le traitement ou naviguent ailleurs en cours de transaction."
    },
    {
      "role": "user",
      "content": "Dois-je créer différents personas d'utilisateurs pour mes tests exploratoires, comme les nouveaux utilisateurs versus les clients récurrents ?"
    }
  ],
  "temperature": 0.7,
  "seed": 42
}

Authorization: Bearer sec_DEADBEEF
Content-Type: application/json

Exemple 2 : Gemini pour développeurs

Le corps de la requête JSON, les en-têtes HTTP et le corps de la réponse JSON sont décrits ici.

(Veuillez garder à l'esprit que ceci est fourni ici comme exemple d'utilisation de modèle. Si vous envisagez d'utiliser des modèles Gemini, vous devriez utiliser Vertex AI plutôt que l'API Gemini développeur et simplement configurer un tel modèle.)

Configuration

• modèle du corps de la requête :

  {
    {{#each messages}}{{#if (isSystem role)}}"system_instruction": {     {{! system prompt }}
      "parts": [
        {
          "text": {{convertToJsonString content}}
        }
      ]
    },{{/if}}{{/each}}
    "contents": [
      {{#each messages}}{{#if (isUser role)}}{                           {{! user inputs (prompts) }}
        "role": "user",
        "parts": [
          {
            "text": {{convertToJsonString content}}
          }
        ]
      }{{#unless @last}},
      {{/unless}}{{/if}}{{#if (isModel role)}}{                          {{! model's answers }}
        "role": "model",
        "parts": [
          {
            "text": {{convertToJsonString content}}
          }
        ]
      }{{#unless @last}},
      {{/unless}}{{/if}}{{/each}}
    ],
    "generationConfig": {
      "stopSequences": [
        "Title"
      ],
      "temperature": 1.0,
      "topP": 0.8,
      "topK": 10
    }
  }
  

• nom d'en-tête HTTP 1 : x-goog-api-key
• modèle de valeur d'en-tête HTTP 1 : {{apiKey}}

Application

En supposant ces messages :

et cette clé d'API : sec_DEADBEEF.

SquashTM génèrera ce corps de requête JSON :

{
  "system_instruction": {
    "parts": [
      {
        "text": "Vous êtes un assistant QA qui aide avec la planification des tests."
      }
    ]
  },
  "contents": [
    {
      "role": "user",
      "parts": [
        {
          "text": "J'ai besoin de créer une charte de test exploratoire pour notre flux de commande. Par où dois-je commencer ?"
        }
      ]
    },
    {
      "role": "model",
      "parts": [
        {
          "text": "Commencez par identifier les principales zones de test : flux utilisateur, méthodes de paiement, gestion des erreurs et sécurité. Concentrez-vous d'abord sur le \"chemin heureux\", puis sur les cas limites. Quelle est la partie la plus critique de votre processus de commande ?"
        }
      ]
    },
    {
      "role": "user",
      "parts": [
        {
          "text": "La validation du paiement est cruciale. Nous avons eu des problèmes avec des utilisateurs bloqués sur l'écran de \"traitement\" auparavant."
        }
      ]
    },
    {
      "role": "model",
      "parts": [
        {
          "text": "C'est un domaine clé à explorer. Pour la validation du paiement, testez des scénarios comme les timeouts réseau, les cartes refusées et l'expiration de session. Documentez ce qui se passe quand les utilisateurs actualisent pendant le traitement ou naviguent ailleurs en cours de transaction."
        }
      ]
    },
    {
      "role": "user",
      "parts": [
        {
          "text": "Dois-je créer différents personas d'utilisateurs pour mes tests exploratoires, comme les nouveaux utilisateurs versus les clients récurrents ?"
        }
      ]
    }
  ],
  "generationConfig": {
    "stopSequences": [
      "Title"
    ],
    "temperature": 1.0,
    "topP": 0.8,
    "topK": 10
  }
}

x-goog-api-key: sec_DEADBEEF
Content-Type: application/json

Valider le modèle du corps de la requête

Écrire un modèle JSON est difficile. Afin d'aider à sa configuration, avant d'essayer d'envoyer un message à l'endpoint de l'API, il est fortement conseillé de valider la génération du corps de la requête.

Cette validation consiste à générer le corps de la requête d'une discussion incluant un prompt système, et une séquence prompt utilisateur / réponse modèle / prompt utilisateur / réponse modèle / prompt utilisateur. Une clé d'API factice est également fournie au cas où celle-ci devrait être incluse dans le corps de la requête. (Des valeurs par défaut sont fournies pour tous ces champs, elles devraient être adéquates pour le test, mais vous pouvez les modifier.)

En cliquant sur le bouton [Tester le modèle du corps de la requête], SquashTM va :

1. traiter le modèle avec Handlebars
2. valider que le texte résultant est du JSON valide

Si une erreur est détectée durant l'une de ces deux étapes, un message d'erreur s'affiche.

1. Exemple d'une syntaxe Handlebars invalide (ici {{/each}} a été mal saisi comme {{/Each}}) :
   

2. Exemple d'un JSON invalide (ici une virgule manque) :
   

Si aucune erreur n'est détectée, le JSON généré s'affiche. Vous devez vérifier soigneusement qu'il correspond à ce qui est attendu par l'endpoint de l'API.

Définir le chemin JSON du texte généré

Le chemin JSON définit où se trouve le texte généré par l'IA dans le corps de la réponse.

Par exemple, une réponse OpenAI a la structure suivante (en utilisant le même exemple que ci-dessus) :

{
  "id": "chatcmpl-ByhUZb4oqcLYnSm2fz19BRXDs2jwp",
  "object": "chat.completion",
  "created": 1753806563,
  "model": "gpt-4.1-2025-04-14",
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "Absolument ! Créer des personas d'utilisateurs ajoute de la profondeur et du réalisme à vos tests exploratoires. Différents personas peuvent révéler des problèmes et des flux uniques. Voici comment l'aborder :\n\n**1. Identifier les Personas Clés :**  \n- **Nouveaux Utilisateurs :** Acheteurs pour la première fois, possiblement sans comptes.  \n- **Clients Récurrents :** Utilisateurs connectés avec des informations sauvegardées.  \n- **Utilisateurs de Commande Invité :** Utilisateurs qui ne veulent pas créer de compte.  \n- **Utilisateurs Internationaux :** Différentes langues, devises ou adresses.  \n- **Utilisateurs avec des Besoins d'Accessibilité :** S'appuyant sur des lecteurs d'écran ou la navigation au clavier.\n\n**2. Varier les Scénarios :**  \nTestez comment chaque persona interagit avec le flux de commande—quelles informations leur sont demandées, quelles erreurs ils pourraient rencontrer, et comment la validation du paiement répond.\n\n**3. Domaines de Focus :**  \n- Étapes de création de compte ou de connexion  \n- Adresses sauvegardées ou méthodes de paiement  \n- Remplissage automatique et erreurs de validation  \n- Timeouts de session pour les utilisateurs lents ou distraits  \n- Gestion des informations de paiement incomplètes ou incorrectes\n\n**4. Documenter les Découvertes :**  \nNotez tous les points de friction uniques à chaque persona.\n\n**Résumé :**  \nUtiliser des personas aide à s'assurer que votre flux de commande fonctionne bien pour tous les types d'utilisateurs du monde réel et rend vos tests exploratoires plus complets.",
        "refusal": null,
        "annotations": []
      },
      "logprobs": null,
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 177,
    "completion_tokens": 242,
    "total_tokens": 419,
    "prompt_tokens_details": {
      "cached_tokens": 0,
      "audio_tokens": 0
    },
    "completion_tokens_details": {
      "reasoning_tokens": 0,
      "audio_tokens": 0,
      "accepted_prediction_tokens": 0,
      "rejected_prediction_tokens": 0
    }
  },
  "service_tier": "default",
  "system_fingerprint": "fp_51e1070cf2"
}

Tester la configuration

Une fois que vous avez terminé la configuration, vous devez la tester comme pour tout serveur IA.