> For the complete documentation index, see [llms.txt](https://boundaryai.gitbook.io/boundaryai-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://boundaryai.gitbook.io/boundaryai-docs/boundaryai-docs-fr/api-et-webhooks/concepts-and-naming.md).

# Concepts et nomenclature

Comment les noms de l'API correspondent à ce que vous voyez dans le produit.

L'API parle le même modèle que le produit. Quatre noms couvrent presque tout :

| Nom d'API (recommandé)   | Dans le produit                                                                                     | Ce que c’est                                                                        |
| ------------------------ | --------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| `feedback_group`         | [Groupe de commentaires](/boundaryai-docs/boundaryai-docs-fr/groupes-de-retours/feedback-groups.md) | Le conteneur du projet. Tout ce qui concerne un programme se trouve dans un groupe. |
| `source`                 | Une source dans un groupe                                                                           | Un flux de retours : un sondage, un import, un connecteur ou votre envoi via l'API. |
| `champ`                  | Une question / colonne                                                                              | Un champ typé sur une source : texte libre, NPS, une échelle, des métadonnées.      |
| élément (dans `content`) | Une réponse / un commentaire                                                                        | Une donnée de feedback envoyée dans un champ.                                       |

Deux concepts du produit que vous rencontrerez dans les réponses :

* **Moniteurs** ([Surveillance personnalisée](/boundaryai-docs/boundaryai-docs-fr/analyser-vos-retours/custom-monitoring.md)) apparaissent dans les lectures d'analyse sous la `drapeaux` clé, et l'événement webhook associé est `flag.raised`. Ce sont les *anciens noms de transport* pour ce que le produit appelle désormais des moniteurs ; les charges utiles sont stables afin que les abonnés existants ne soient pas cassés.
* **Analyse** est asynchrone. L'envoi retourne immédiatement ; les thèmes, le sentiment et les correspondances de moniteurs apparaissent lorsque le traitement d'analyse est terminé (abonnez-vous à `analysis.completed` plutôt que de sonder). Pour une source dans un groupe qui [suit les retours dans le temps](/boundaryai-docs/boundaryai-docs-fr/analyser-vos-retours/tracking-feedback-over-time-evolution.md), la lecture d'analyse agrège chaque période analysée et renvoie `analysis_id: null`, car il n'existe pas une seule exécution globale à nommer ; utilisez comme clé `analysis_status` ("disponible" ou "aucun"), jamais sur `analysis_id`.

***

### Déjà intégré à l'ancien vocabulaire ?

Les intégrations créées lorsque l'API parlait `survey_series` / `survey` / `question` continuent de fonctionner sans changement : ces routes (`/survey_series/create`, `/survey/create`, `/content/push`, et consorts) utilisent les mêmes gestionnaires que les routes documentées ici, sont entièrement prises en charge et sont couvertes par la [politique de compatibilité](/boundaryai-docs/boundaryai-docs-fr/api-et-webhooks/changelog.md). Nous les gardons hors de la référence principale afin qu'il n'existe qu'une seule manière documentée de faire chaque chose ; ils sont listés sous **Vocabulaire classique (alias)**. La correspondance, si vous lisez du vieux code : `survey_series` = groupe de feedback, `survey` = source, `question` = champ.

***

### Types de champs

Lors de la création d'une source, chaque champ prend un `field_type`:

| Type          | À utiliser pour                                                                              |
| ------------- | -------------------------------------------------------------------------------------------- |
| `DEPTH_TEXT`  | Long texte libre : le champ que l'IA analyse pour les thèmes, le sentiment et les moniteurs. |
| `TEXT`        | Texte libre court : noms, phrases courtes.                                                   |
| `NPS`         | Le score de probabilité de recommandation de 0 à 10.                                         |
| `RATING`      | Une échelle numérique avec vos propres bornes (`min_value` / `max_value`).                   |
| `SCQ` / `MCQ` | Choix unique / multiple (`field_options`).                                                   |
| `DROPDOWN`    | Choix unique présenté sous forme de liste déroulante (`field_options`).                      |
| `RANKING`     | Les répondants classent le `field_options`.                                                  |
| `METADATA`    | Contexte pour la segmentation (région, niveau, agent) ; importé mais non analysé.            |

Les noms ne tiennent pas compte de la casse, et `long_answer` / `short_answer` sont acceptés comme synonymes de `DEPTH_TEXT` / `TEXT`. Une source accepte jusqu'à 100 champs par appel de création.

Le signal analytique le plus riche provient des `DEPTH_TEXT` champs ; `METADATA` les champs alimentent la segmentation dans les vues d'analyse, exactement comme avec [imports](/boundaryai-docs/boundaryai-docs-fr/importer-vos-retours/uploading-an-existing-dataset.md).

***

### `feedback_type`: indiquez à la plateforme de quoi il s'agit

Les sources prennent un `feedback_type` (`survey`, `call_transcript`, `app_review`, `support_ticket`, `chat`, `e-mail`, `social_media`, `review`, `other`; valeur par défaut `survey`). Il est repris dans les listes et aide la plateforme à interpréter correctement les données. Choisissez le plus proche plutôt que de tout mettre par défaut à `other`.